Many still import (chibi), and as (scheme base) is somewhat more
expensive to load at present these are changed to cond-expand.
Many libraries also rely on (srfi 33), and these have been changed
to a cond-expand first trying (srfi 60) where available.
Also fixing a few portability concerns (duplicate imports of the
same binding), and adding a few libraries missing from lib-tests.scm.
is bound in only one of the environments. This is necessary in the
case where a library uses an unbound keyword (e.g. "with" in (chibi
loop)), but you want to use it along with a binding for the
keyword (e.g. "with" in (chibi show)). The alternative to work with
the current logic is to always require such keywords to be bound, in
this case to add a dummy "with" auxiliary syntax binding to (chibi
loop), however this doesn't seem any safer than the new logic, and the
whole point of the feature is convenience. Fixes issue #221.
First we check for C99 support in Makefile.detect, looking for the
header we need and verifying whether it is the right one by using
a definition required by C99 standard to be present in that header.
uintN_t types are optional, but implementations are required to
provide corresponding limit #defines for the types they support,
so we can check for this with preprocessor only.
Finally, we define SEXP_UINTN_DEFINED for any sexp_uintN_t we have
so that the code can use #ifs to check for exact integer support.
- Fixed some typos in sha-native.scm
- Removed unnecessary structs and unions from sha_context
- Used more efficient implementation of hex32
- Made (scheme base) a common import in (chibi crypto sha2)
This change concerns only Chibi. The portable implementation is
still kept around because it is... well... portable and can be
used by other Scheme implementations.
We can't use 'integer->hex-string' alone to print out SHA-224/256
digest because it rightly converts #x00001234 into "1234", while
we need to keep the padding zero nibbles and get "00001234".
'hex' got renamed into 'hex32' because SHA-512 will need some
different 'hex64' which returns 16-character-long strings.
* Boundary cases
Both SHA-224 and SHA-256 use 512-bit data chunks and have a special
behavior when chunk size is near the 448-bit boundary.
* Source type support
Basic smoke tests for accepting bytevectors and binary input ports
as valid arguments.
The original Scheme implementation is astonishingly slow. Rewriting
SHA-2 in C yields around x10000 speed boost for premade strings and
bytevectors. For input ports this is alleviated to x100 boost.
The implementation is divided into two parts: native computational
backend and thin Scheme interface. It is tedious to properly do IO
from C, so the Scheme code handles reading data from an input port
and the C code performs actual computations on byte buffers (which
is also used to handle strings and bytevectors directly).
Scheme wrapper reads data in chunked manner with 'read-bytevector'.
Currently, the chunk size has insignificant impact on performance
as soon as it is bigger than 64. Also, using simply read-bytevector
turned out to be 33% faster than preallocating a buffer and filling
it with read-bytevector!
One tricky part is how to get exact 32-bit integers in C89. We have
no <inttypes.h> there, so instead we use <limits.h> to see whether
we have a standard type with suitable boundaries.
The other one is how to return a properly tagged sha_context from C.
Chibi FFI currently cannot handle the case when a procedure returns
either a C pointer (which needs to be boxed) or an exception (which
should be left as is). To workaround this sexp_start_sha() receives
a dummy argument of type sha_context; this makes Chibi FFI to put a
proper type tag into 'self', which is then extracted in the C code.
This commits adds a new shared library 'crypto$(SO)' with intent to
keep there all native code of (chibi crypto) libraries. This allows
to simply put any future native implementation of SHA-512 or MD5 in
some md5.c and just include those files into crypto.stub.
