[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