On Apr 22, 2009, at 11:49 AM, [email protected] wrote:
>
>> This is probably not a bug. There are places in the SQLite code
>> where
>> we deliberately discard all but the lower 8 bits of an integer. But,
>> if you like to tell us *where* in the code this occurs, I'll be happy
>> to verify it for you.
>
>
> In sqlite3.c big file, it's in static u8 randomByte(void) function, on
> line 16707 :
>
> wsdPrng.j += wsdPrng.s[i] + k[i];
>
> wsdPrng.j = 246, and wsdPrng.s[i] + k[i] = 28, so adding it will be
> more
> than 255. If it's deliberate, a bitmask 0xFF would solve the problem.
This is not error in the SQLite code. The code here is correct. The
bug is in your compiler.
Adding a work-around so that this will work in your compiler makes the
code rather more complicated:
wsdPrng.j = (wsdPrng.j + wsdPrng.s[i] + k[i]) & 0xff;
I am opposed to obfuscating the code in this way because of your
compiler bug. Is there some command-line option or something on your
compiler that can turn off the silly overflow check?
D. Richard Hipp
[email protected]
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
