Hello

I've put up a new version of my chjmodule on

http://scheme.mine.nu/gambit/chjmodule

which, besides some other modules and changes, now contains an md5 module compatible with the chicken one. You can also look at the latter (and it's dependencies) at

http://scheme.mine.nu/gambit/chjmodule/from-chjmodule-20050711/

There is one serious problem with the md5 module, though: if you feed md5:digest a port which is delivering more than 1024 bytes, it will only digest the first 1024. It seems this is a problem in read-subu8vector, which returns with length 0 after the first 1024 bytes. I'm using gambit 4.0 beta 13 (on Debian ppc).

I also have some questions:

- the documentation on read-subu8vector doesn't explicitely say how to reliably find out whether eof has been reached (as opposed to a timeout). What's the correct usage?

- how can I (pre-)allocate datastructure *per thread*? I'm currently caching buffers to save gc overhead, but that's surely not thread safe. I could try using parameters, but then how do I find out if the current content of a parameter stems from a previous thread or not? (short of saving the current thread id in the parameter as well, which starts looking complicated)

md5.scm is also missing better error handling in in ___BEGIN_CFUN_u8vector_to_pointer better: one should add argpos to the error (how?), and use "the" correct error message (___STOC_U8_ERR is clearly not right) or create a new one (hm).

I'm also not sure atm whether C checks arguments like "uint8 a[16]" for the correct length. If so, it would be nice if the FFI would allow to define C types with the length - I can't see how to do that currently, given that only one string can be fed to c-define-type.

Cheers Christian.