D. Richard Hipp a écrit :
> This is not error in the SQLite code. The code here is correct. The
> bug is in your compiler.
Sorry but I don't agree at all.
> Adding a work-around so that this will work in your compiler makes the
> code rather more complicated:
>
> wsdPrng.j = (wsdPrng
The compiler is not broken. If this behavior in the compiler bugs you,
(pun intended) you can disable the warning locally or globally.
This change is not obfuscating the code. It is not a work-around. It
is making your intentions clear. When I read the line as written, I
have to research fo
On Apr 22, 2009, at 11:49 AM, sql...@fauvelle.net 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
> 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 randomBy
On Apr 22, 2009, at 11:23 AM, sql...@fauvelle.net wrote:
> Hello all,
>
> I'm compiling sqlite 3.6.13 with Visual 2003, and RunTime Check
> activated, and it gives this error :
>
> Run-Time Check Failure #1 -
> A cast to a smaller data type has caused a loss of data. If this was
> intentional, y
5 matches
Mail list logo
