[gambit-list] md5 module, bug(?) in read-subu8vector, and some questions
Christian
christian at pflanze.mine.nu
Mon Jul 11 09:11:00 EDT 2005
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.
More information about the Gambit-list
mailing list