restrict.m4: do not punish autoconf 2.59 users

I like | checking for C/C++ restrict keyword... __restrict | checking for C/C++ restrict keyword... (cached) __restrict much better than | checking for C/C++ restrict keyword... __restrict | checking for C/C++ restrict keyword... restrict in case both gl_C_RESTRICT and AC_C_RESTRICT are used. In

Re: generic crypto

Simon Josefsson <[EMAIL PROTECTED]> writes: > * Perhaps the /dev/*random reading should be separated into a separate > module? It might be useful outside of the gc layer too. Absolutely. I've been meaning to do that for months (for a "shuffle" program I want to add to coreutils), but hadn't g

Re: hmac-md5

Simon Josefsson <[EMAIL PROTECTED]> writes: > Is there a portability requirement that 'char foo = 0xAA' end > up with 10101010 in the memory buffer (void*)&foo? No for C, but yes for POSIX. The main problem with char * is that, in principle, an implementation can dump core if you do something li

Re: memxor

Simon Josefsson <[EMAIL PROTECTED]> writes: > The module depend on restrict, but the AC_REQUIRE in m4 wasn't > present. I added it. But is it necessary? Shouldn't depending on > the restrict module be sufficient? No, sorry, I missed the fact that the module depends on restrict. In that case yo

Re: Bug report: sort.c or AIX compiler

Jim Meyering <[EMAIL PROTECTED]> writes: > That looks fine. OK, I installed it into coreutils. Also into gnulib. I'm CC:ing this message to bug-gnulib so here is the patch again, relative to gnulib. The original bug report is here:

Re: hmac-md5

I have installed this. Index: m4/hmac-md5.m4 === RCS file: m4/hmac-md5.m4 diff -N m4/hmac-md5.m4 --- /dev/null 1 Jan 1970 00:00:00 - +++ m4/hmac-md5.m4 6 Oct 2005 15:54:59 - @@ -0,0 +1,11 @@ +# hmac-md5.m4 serial 1 +dnl

Re: stdint license

On Wednesday, October 05, 2005 at 18:12, Bruno Haible wrote: > > I just noticed that the 'stdint' module was GPL. Would it be possible > > to re-license it? > > Yes, done (assuming Oskar's agreement). Of course, I don't think I coded anything in it anyway (I only came up with the idea). Regards

Re: generic crypto

Ralf Wildenhues <[EMAIL PROTECTED]> writes: > * Simon Josefsson wrote on Thu, Oct 06, 2005 at 03:39:20PM CEST: >> >> I'm sure there are plenty of other problems too, but this passes self >> tests in GNU SASL so it is fairly complete... Once this is installed, >> I can continue to add the modules

Re: generic crypto

* Simon Josefsson wrote on Thu, Oct 06, 2005 at 03:39:20PM CEST: > > I'm sure there are plenty of other problems too, but this passes self > tests in GNU SASL so it is fairly complete... Once this is installed, > I can continue to add the modules that GnuTLS needs, which include > encryption modu

generic crypto

This is a first attempt at a "middle layer" crypto module. I have installed it in GNU SASL, which only need gc_md5, gc_hmac_md5 and gc_nonce. I have not tested this much. To see a more complete gc.h compare: http://josefsson.org/cgi-bin/viewcvs.cgi/gsasl/lib/crypto/Attic/gc.h?rev=1.5&hideattic=

Re: hmac-md5

Paul Eggert <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: > >> Has anyone used md5_buffer from the md5 module on a platform with char >> that is larger than 1 byte? > > Do you mean a host where UCHAR_MAX > 255? I doubt whether anyone has > done that. POSIX requires th

Re: memxor

Paul Eggert <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: > >> I am not sure about the prototype. Should it use 'char*'? 'int*'? > > If its name is mem* then it should use void *, for consistency. > > The current implementation uses 'restrict', so memxor.m4 should > A

Re: FYI: getdelim.c needs SIZE_MAX

Derek Price <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: > >>Derek Price <[EMAIL PROTECTED]> writes: >> >> >>>may not be defined. I've installed the attached patch, ripped verbatim >>>from serveral other modules. >>> >>> >> >>Shouldn't we use the size_max module instead? >> >> > >