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
Paul Eggert <[EMAIL PROTECTED]> writes:
> Thanks for explaining all that.
>
>> Is it ok to install the GC module as-is meanwhile?
>
> It's fine with me. One (hopefully easy) suggestion: perhaps your
> explanation could go into the source code somewhere, in a TODO area?
I added it to gc.h and ins
Thanks for explaining all that.
> Is it ok to install the GC module as-is meanwhile?
It's fine with me. One (hopefully easy) suggestion: perhaps your
explanation could go into the source code somewhere, in a TODO area?
___
bug-gnulib mailing list
bug
Paul Eggert <[EMAIL PROTECTED]> writes:
> 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"
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
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
* 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
===
RCS file: modules/gc
diff -N modules/gc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ modules/gc 5 Oct 2005 15:46:17 -
@@ -0,0 +1,37 @@
+Description:
+Core files for generic crypto package
+
+Files:
+lib/gc.h
+lib/gc-libgcrypt.c
+lib/gc-gnulib.c
+m4/gc.m4
+lib/md5.h
+lib/md5.c
19 matches
Mail list logo
