Paul Eggert writes:
> On 05/18/2012 01:29 PM, Serge Belyshev wrote:
>
>> this part does exactly the same: increment ctx->total [1] by one, where
>> larger increment may be needed.
>
> OK, I see. But this bug can only happen on unusual hosts, right?
> I.e., hosts where size_t is wider than 64 bit
On 05/18/2012 01:29 PM, Serge Belyshev wrote:
> this part does exactly the same: increment ctx->total [1] by one, where
> larger increment may be needed.
OK, I see. But this bug can only happen on unusual hosts, right?
I.e., hosts where size_t is wider than 64 bits, or where
uint64_t does not ex
> I don't see a bug in sha512.c, though;
> could you please elaborate? Thanks.
sha512.c:489:
/* First increment the byte count. FIPS PUB 180-2 specifies the possible
length of the file up to 2^128 bits. Here we only compute the
number of bytes. Do a double word increment. */
c
On 05/18/2012 08:47 AM, Serge Belyshev wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=14090
Thanks for the heads-up. For gnulib I see the bug in
md4.c, md5.c, sha1.c, and sha256.c, so I installed the
following patch. I don't see a bug in sha512.c, though;
could you please elaborate? T
This is a cross-post from glibc bugreport:
http://sourceware.org/bugzilla/show_bug.cgi?id=14090
In short, the code below handles blocks larger than 8 GB incorrectly because
they require ctx->total[1] incremented more than by 1:
---
Il 16/05/2012 21:16, Erik Faye-Lund ha scritto:
> From: theoleblond
>
> SwitchToThread() only gives away the rest of the current time
> slice to another thread in the current process. So if the
> thread that feeds the file decscriptor we're polling is not
> in the current process, we get busy-wai
