gc-sha1

2005-10-11 Thread Simon Josefsson
I have installed this. Index: m4/ChangeLog === RCS file: /cvsroot/gnulib/gnulib/m4/ChangeLog,v retrieving revision 1.737 diff -u -p -r1.737 ChangeLog --- m4/ChangeLog12 Oct 2005 01:33:44 - 1.737 +++ m4/ChangeLog

Re: hmac-sha1

2005-10-11 Thread Simon Josefsson
Simon Josefsson <[EMAIL PROTECTED]> writes: > What do you think? This is very similar to the hmac-md5 module. I installed the patch below. It didn't touch on any existing module, so I thought the impact was low. > The reason the modules are separate is that I don't want to force > hmac-sha1 us

gc split

2005-10-11 Thread Simon Josefsson
This make it possible to use only parts of gc, without requiring all sub-modules. This will be more important later on, when there will be many gc-* sub-modules. I have installed the patch below. There is a problem (not introduce by this patch though), in that the gc modules does not use "depend

Re: gc_hash_buffer

2005-10-11 Thread Simon Josefsson
Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> + The required size of OUT depends on HASH, and is generally >> + GC__DIGEST_SIZE. For example, for GC_MD5 the output buffer >> + must be 16 bytes. */ >> extern int >> gc_hash_buffer (int hash, const void *in, size_t inl

Re: syncing md5 against glibc

2005-10-11 Thread Simon Josefsson
Jim Meyering <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> wrote: >> Let's not wait for glibc to install my patch... What do you think >> about installing the following in gnulib now? It would sync gnulib >> with my proposed libc-patch. It also fixes the sha1 module to be >>

Re: syncing md5 against glibc

2005-10-11 Thread Jim Meyering
Simon Josefsson <[EMAIL PROTECTED]> wrote: > Let's not wait for glibc to install my patch... What do you think > about installing the following in gnulib now? It would sync gnulib > with my proposed libc-patch. It also fixes the sha1 module to be > standalone. I like it. Thanks for the clean-u

Re: gc_hash_buffer

2005-10-11 Thread Simon Josefsson
Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> + >> +/* Compute a hash value over buffer IN of INLEN bytes size using the >> + algorithm HASH, placing the result in the pre-allocated buffer OUT. >> + The required size of OUT depends on HASH, and is generally >> + GC__DI

Re: gc_hash_buffer

2005-10-11 Thread Bruno Haible
Simon Josefsson wrote: > + The required size of OUT depends on HASH, and is generally > + GC__DIGEST_SIZE. For example, for GC_MD5 the output buffer > + must be 16 bytes. */ > extern int > gc_hash_buffer (int hash, const void *in, size_t inlen, char *out); So GC_MD5 is a valid value for H

Re: syncing md5 against glibc

2005-10-11 Thread Simon Josefsson
Let's not wait for glibc to install my patch... What do you think about installing the following in gnulib now? It would sync gnulib with my proposed libc-patch. It also fixes the sha1 module to be standalone. Thanks. Index: m4/ChangeLog

Re: new module 'c-strcase'

2005-10-11 Thread Bruno Haible
Paul Eggert wrote: > OK, I see now. OK. In the absence of other objections, I committed both modules. Bruno ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: gc_hash_buffer

2005-10-11 Thread Bruno Haible
Simon Josefsson wrote: > + > +/* Compute a hash value over buffer IN of INLEN bytes size using the > + algorithm HASH, placing the result in the pre-allocated buffer OUT. > + The required size of OUT depends on HASH, and is generally > + GC__DIGEST_SIZE. For example, for GC_MD5 the output bu

Re: crc

2005-10-11 Thread Paul Eggert
Simon Josefsson <[EMAIL PROTECTED]> writes: > Ok to install the crc module? Yes, it's fine with me. Thanks. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: gc_hash_buffer

2005-10-11 Thread Simon Josefsson
Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> Review most appreciated, as always. >> ... >> +/* Hashes. */ >> +extern int >> +gc_hash_buffer (int hash, const void *in, size_t inlen, char *out); > > About the specification of this function: I can guess what 'in' and 'inlen' >

Re: new module 'c-strcase'

2005-10-11 Thread Paul Eggert
Bruno Haible <[EMAIL PROTECTED]> writes: > The result is then well-defined but not related to the behaviour of > the C locale on such systems, and the name of the module would be a > misnomer :-) OK, I see now. I had understood "C" to stand for the traditional C behavior and not the less-well-sp

Re: crc

2005-10-11 Thread Simon Josefsson
Paul Eggert <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: > >> The comment before the function include references and the copyright. >> Should I make it shorter, i.e.: >> >> /* >> * The following function was extracted from RFC 1952 by Simon >> * Josefsson. It was mo

Re: crc

2005-10-11 Thread Simon Josefsson
Paul Eggert <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: > >> Perhaps I should work on making the ax_create_stdint.m4 macro part of >> gnulib, and change these modules to use uint8_t*? Applications could >> then install the header file generated by ax_create_stdint.m4

Re: new module 'c-strcase'

2005-10-11 Thread Bruno Haible
Paul Eggert wrote: > > More precisely, one of the string arguments must be an ASCII string; > > the other one can also contain non-ASCII characters (but then the > > comparison result will be nonzero). > > Why is this restriction needed? It is needed to guarantee that the result is equivalent to t