Jim Meyering <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>> The "verify" module is GPL. If you re-license it, md4 would be able
>> to use it.
>
> Changing it to LGPL is fine with me. Paul?
OK, done.
___
bug-gnulib mailin
Simon Josefsson <[EMAIL PROTECTED]> wrote:
...
>> And it also assumes no holes in integer representations.
>> This is more portable:
>>
>> verify (offsetof (struct S, member_m) % alignof (uint32_t) == 0);
>>
>> where alignof is defined as with md5.c etc.
>
> The "verify" module is GPL. If you re
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> - md4_process_block (memcpy (ctx->buffer, buffer, 64), 64, ctx);
>> + md4_process_block (memcpy (ctx->buffer, buffer, 16), 64, ctx);
>
> The patch in md4.c:243 doesn't look right. But otherwise it looks more
>
Simon Josefsson wrote:
> - md4_process_block (memcpy (ctx->buffer, buffer, 64), 64, ctx);
> + md4_process_block (memcpy (ctx->buffer, buffer, 16), 64, ctx);
The patch in md4.c:243 doesn't look right. But otherwise it looks more
robust than previously.
Bruno
Bruno Haible <[EMAIL PROTECTED]> writes:
>> > 17) gc.m4
>> >
>> > I don't understand what happens when someone specifies
>> > --disable-random-device. Then NAME_OF_RANDOM_DEVICE will be set to "no",
>> > the AC_CHECK_FILE will check for a file named "no" and bail out.
>>
>> Hm. How can this be so
Paul Eggert <[EMAIL PROTECTED]> writes:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> verify (offsetof (struct S, member_m) % 4 == 0);
>>
>> Hmm... that assumes 8-bit bytes.
>
> And it also assumes no holes in integer representations.
> This is more portable:
>
> verify (offsetof (struct S,
Jim Meyering <[EMAIL PROTECTED]> writes:
> verify (offsetof (struct S, member_m) % 4 == 0);
>
> Hmm... that assumes 8-bit bytes.
And it also assumes no holes in integer representations.
This is more portable:
verify (offsetof (struct S, member_m) % alignof (uint32_t) == 0);
where alignof is
Jim Meyering <[EMAIL PROTECTED]> writes:
> Putting a compile-time assertion like the following,
> right after the struct definition, adds some clout :-)
>
> verify (offsetof (struct S, member_m) % 4 == 0);
>
> Hmm... that assumes 8-bit bytes.
You could multiply by CHAR_BIT and check for a multi
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Simon Josefsson wrote:
>> > you don't need it,
>> > because the rules for struct layout in C guarantee that a structure field
>> > is aligned to a multiple of the alignment of the previous field.
>>
>> Are you saying that even if we don't change the type o
Simon Josefsson wrote:
> > you don't need it,
> > because the rules for struct layout in C guarantee that a structure field
> > is aligned to a multiple of the alignment of the previous field.
>
> Are you saying that even if we don't change the type of buffer to
> char, we don't need that alignment
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hi Simon,
>
> Here are a few random remarks regarding the new code. It's a bit terse, but
> I hope you can decipher the meaning.
Hi! Many thanks. I have been pushing gc into gnulib rather rapidly
because we want to release GnuTLS 1.2.9 with that stuff
Hi Simon,
Here are a few random remarks regarding the new code. It's a bit terse, but
I hope you can decipher the meaning.
1) crc.h
#if HAVE_INTTYPES_H
# include
#endif
#if HAVE_STDINT_H
# include
#endif
Correct this to
#include
because
- On old platforms with neither nor , these
includ
12 matches
Mail list logo
