On 11/17/11 19:42, Ian Beckwith wrote:
> Yes, that fixed it, thanks.
OK, thanks, I pushed it, with a couple of minor further fixes:
a URL in the ChangeLog was wrong (Jim Meyering pointed this out),
and I had forgotten to remove the dependency of
crypto/gc-arctwo on crypto/bitrotate.
On Thu, Nov 17, 2011 at 01:59:27PM -0800, Paul Eggert wrote:
> I introduce that problem when I added stdalign.
> Does the following patch fix things for you?
Yes, that fixed it, thanks.
Ian.
--
Ian Beckwith - i...@erislabs.net - http://erislabs.net/ianb/
GPG fingerprint: AF6C C0F1 1E74 424B BCD
epends-on):
Depend conditionally on crypto/arcfour.
* modules/crypto/gc-arctwo (Depends-on):
Depend conditionally on crypto/arctwo.
* modules/crypto/gc-des (Depends-on):
Depend conditionally on crypto/des.
* modules/crypto/gc-hmac-md5 (Depends-on):
Depend conditionally on crypto/hmac-md5.
* modules/
Hi,
crypto/gc-hmac-md5, crypto/gc-hmac-sha1, and crypto/gc-pbkdf2-sha1 all fail
with:
gcc -DHAVE_CONFIG_H -I. -I.. -DGNULIB_STRICT_CHECKING=1 -g -O2 -MT sha1.o
-MD -MP -MF .deps/sha1.Tpo -c -o sha1.o sha1.c
sha1.c:29:22: fatal error: stdalign.h: No such file or directory
or
gcc
Simon Josefsson wrote:
> > Yes, I try to avoid 'unsigned char *' for that reason'. ...
>
> Then perhaps hmac-md5 should use 'char*'.
The big downsides of 'char *' are:
- It is not closer to the meaning of the data than 'void *'.
T
with uc ...
>
> rather than use 'unsigned char *'. It's a little more verbose but
> avoids the warnings and it's perfectly portable. The tricy part is
> converting the unsigned char back to char. But I'm usually lazy and
> just store it (e.g., "*p = uc
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
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
er anyone has
> done that. C has required that sizeof (char) == 1 for ages.
Ok, then perhaps 'char*' is better than 'void*' for hmac-md5. When I
think more about it, also the encoding of the bytes inside 'char*'
matter. Is there a portability requirement that &
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 that UCHAR_MAX == 255. A small fraction of
GNU code
Bruno Haible <[EMAIL PROTECTED]> writes:
> For 'uint8_t', you can use the gnulib module 'stdint'. Or use 'unsigned char'
> if you don't want to.
I just noticed that the 'stdint' module was GPL. Would it be possible
to re-license it? Oth
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> This is the HMAC-MD5 module, that depends on the MD5 module.
>> What do you think? Ok to install?
>>
>> The reason I'm using hmac.h instead of hmac-md5.h is that I think
>> hmac.h sh
Simon Josefsson wrote:
> This is the HMAC-MD5 module, that depends on the MD5 module.
> What do you think? Ok to install?
>
> The reason I'm using hmac.h instead of hmac-md5.h is that I think
> hmac.h should contain the prototype for hmac_sha1 too, eventually.
> That wou
Hi. This is the HMAC-MD5 module, that depends on the MD5 module.
What do you think? Ok to install?
The reason I'm using hmac.h instead of hmac-md5.h is that I think
hmac.h should contain the prototype for hmac_sha1 too, eventually.
That would be a separate module with a hmac-s
14 matches
Mail list logo
