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
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
