Checkin http://www.sqlite.org/src/info/6f53fc7106 is an important behavior
change for SQLite.
The check-in above changes the behavior of REAL-to-INTEGER casts where the
REAL value is larger than the largest possible integer. For example:
SELECT CAST(9223372036854775808.0 to INTEGER);
All historic versions of SQLite running on x86/x64 hardware generate an
answer of -9223372036854775808 for the above. This is what casting an
over-size double to a long long int on intel hardware does, and since
SQLite was developed primarily on x86 workstations that is the behavior it
has previously exhibited. The change causes the query to yield
9223372036854775807, which seems a more sensible answer, and is in fact
what sparc hardware does. SQLite now always gives the second answer (the
sparc answer) regardless of the platform it is running on.
One might argue that this is an incompatible change, but I'd like to argue
that it is a bug fix.
Cross-posted to sqlite-...@sqlite.org because this is an important change
that needs to be reviewed carefully before the next release.
On Tue, Nov 26, 2013 at 8:26 AM, Richard Hipp <d...@sqlite.org> wrote:
>
>
>
> On Tue, Nov 26, 2013 at 6:39 AM, Jan Staněk <jsta...@redhat.com> wrote:
>
>> Hello,
>> I'm trying to build sqlite for aarch64 (ARMv8) and one of the expression
>> tests is failing (specifically e_expr-31.2.4) with:
>> > Expected: [integer -9223372036854775808]
>> > Got: [integer 9223372036854775807]
>> From the comment, I gather that this should test correct CASTing from
>> REAL to INT, and that somehow it returns the wrong extreme (largest
>> positive integer instead of largest negative).
>>
>> Can someone point me where in the source is that implemented? I would
>> like to try to fix it, but I'm unable to find the actual execution of
>> the CAST.
>>
>
> The test in question is this:
>
> SELECT cast(9223372036854775809.0 AS INT);
>
> The expected answer is (surprisingly) -9223372036854775808. This goes
> back to a change in 2008. We added a comment in 2009 saying that this is
> the intended behavior. See
> http://localhost:591/sqlite/info/7f3be3608542bbc6
>
> The idea was apparently to emulate the behavior seen in this test program:
>
> #include <stdio.h>
> int main(int argc, char **argv){
> long long int x;
> double r;
> r = 9223372036854775809.0;
> x = (long long int)r;
> printf("%lld\n", x);
> return 0;
> }
>
> The test program above, on linux, returns -9223372036854775808. Now, 5
> years later, I'm having my doubts. Maybe I should change the behavior of
> SQLite to make sense, rather than to emulate the behavior of floating point
> hardward on x86 linux...
>
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
