Paul Eggert <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>> -#define K1 0x5a827999L
>> -#define K2 0x6ed9eba1L
>> +#define K1 0x5a827999
>> +#define K2 0x6ed9eba1
>
> That fixes the bug on hosts where int is 32 bits and long is 64 bits,
> but if I understand the prob
Simon Josefsson <[EMAIL PROTECTED]> writes:
> -#define K1 0x5a827999L
> -#define K2 0x6ed9eba1L
> +#define K1 0x5a827999
> +#define K2 0x6ed9eba1
That fixes the bug on hosts where int is 32 bits and long is 64 bits,
but if I understand the problem you found, then surely the bug remains
on hosts w
Bruno Haible <[EMAIL PROTECTED]> writes:
> The less you have to think when manipulating some code, the better.
True, but there are other concerns. When I read C code like this:
(char *)
I stop mentally and ask "why is that cast there?" Casts like that are
dangerous, and I need to
Paul Eggert wrote:
> > So, _Bool and bool are _not_ integer types.
>
> No, because ISO C99 section 6.2.5 paragraph 6 says:
>
> The type _Bool and the unsigned integer types that correspond to the
> standard signed integer types are the _standard unsigned integer types_.
You're right. I overloo
Bruno Haible <[EMAIL PROTECTED]> writes:
> ISO C 99, section 6.2.5 paragraph 17, defines the term "integer types":
>
> The type char, the signed and unsigned integer types, and the enumerated
> types are collectively called integer types.
>
> So, _Bool and bool are _not_ integer types.
No
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hi Simon,
>
> When compiling all of gnulib with SunPRO C 5.9 on Linux/x86, there is only
> one file with warnings.
>
> c89 -Xa -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\"
> -DLIBDIR=\"/packages/inst-sunpro/lib\" -I. -I. -I.. -I../intl -xO5 -c des.c
>
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> FYI, a few of the gnulib tests currently fail:
> On x86_64-unknown-linux-gnu (omitting passed tests):
...
> md4 1 mismatch. expected:
> a4 48 01 7a af 21 d8 52 5f c1 0a e8 7a a6 72 9d
> computed:
> 29 e6 63 dd dc 61 52 69 91 85 da 92 ed 96 c8 b1
> FAIL
Mark D. Baushke wrote:
> > static inline char *
> > xstrcat (size_t argcount, va_list args)
> > {
> > char *result;
>
> ...elided...
>
> > /* Allocate and fill the result string. */
> > result = (char *) xmalloc (totalsize + 1);
>
> Why is the cast needed? I was under the impression that GNU
