Simon Josefsson <[EMAIL PROTECTED]> writes:
> - *(uint32_t *) &ctx->buffer[bytes + pad] = SWAP (ctx->total[0] << 3);
> - *(uint32_t *) &ctx->buffer[bytes + pad + 4] = SWAP ((ctx->total[1] << 3) |
> - (ctx->total[0] >> 29));
> + ctx->buffer[(by
Simon Josefsson <[EMAIL PROTECTED]> writes:
> I get this on freebsd 4.11:
>
> In file included from smbutil.c:34:
> lib/des.h:62: conflicting types for `des_setkey'
> /usr/include/unistd.h:128: previous declaration of `des_setkey'
> *** Error code 1
>
> Should I rename the des_* functions to gl_de
Jim Meyering <[EMAIL PROTECTED]> writes:
> Paul Eggert <[EMAIL PROTECTED]> wrote:
>> How about the following idea? If gettimeofday, clock_gettime,
>> etc. fail with EOVERFLOW, invoke xtime_overflow, which prints a
>> warning to stderr and returns the maximum time value.
>
> I like it. But why tr
I was using --tests-base=gl/tests and I got this:
Creating directory ./gl/tests
cp: cannot create regular file `./tests/test-gc-hmac-md5.c.tmp': No such file
or directory
So I installed this.
2005-10-23 Simon Josefsson <[EMAIL PROTECTED]>
* gnulib-tool: Fix --tests-base.
--- gnulib-
I get this on freebsd 4.11:
In file included from smbutil.c:34:
lib/des.h:62: conflicting types for `des_setkey'
/usr/include/unistd.h:128: previous declaration of `des_setkey'
*** Error code 1
Should I rename the des_* functions to gl_des_* or is there some
cleaner approach?
__
How about this? Similar to the md4 fix.
Caveat: I had md5 self test failures on x86-solaris recently, but
could not figure out what the reason was. I replaced the md5.? files
with the files from coreutils 4.5.5 to see if any changes we have
applied to gnulib recently caused the problem, but I g
Paul Eggert <[EMAIL PROTECTED]> wrote:
...
>> Anyone who sets the system clock past 2038 and then runs a
>> gnulib-based program that they've compiled in
>> hamstrung-to-32-bit-time_t mode deserves whatever misbehavior they
>> provoke.
>
> I suppose a clock-hardware problem could provoke this, so i
Jim Meyering <[EMAIL PROTECTED]> writes:
> At first I thought this meant we'd have to change gettime to
> return an indication of success or failure. However, I am now
> inclined to leave it as is.
Yes, that sounds right to me, too.
> Anyone who sets the system clock past 2038 and then runs a
>
