On Wed, Jul 23, 2014 at 1:07 PM, Richard Hipp <d...@sqlite.org> wrote:

> The current SQLite implementation (on the "hex-literal" branch) works by
> converting hex literals of 64 bits or less into a signed 64-bit integer.
>

Overflow/underflow are unspecified for signed types, and the <</>> ops
could certainly overflow.


> 1.84467440737096e+19. This approach means that all hexadecimal literals are
> positive numbers, except literals 0x8000000000000000 through
> 0xffffffffffffffff which are negative.  There is this range of negative
> values smack in the middle of an otherwise uniformly increasing sequence of
> positive numbers.  That negative range seems discombobulating.
>

Indeed.

(1) Keep the current prototype behavior.  Hex literals of 64 bits or less
> are converted into twos-complement 64-bit integers, meaning that some
> values are negative.  Hex literals of 65 bits or more are converted into a
> floating-point approximation.
>

Sounds reasonable.


> (2) Declare that the values of hex literals greater than 64 bits are
> "undefined" and convert them into random 64-bit integers.

 Seriously: use
> the random number generator to convert oversized hex literals into
> integers, and thereby discourage programmers from using oversized hex
> literals.
>

i wouln't go quite that far, but converting to NULL might be a middle
ground.


> (4) Silently truncate all hexadecimal literals to 64-bits, like SQL Server
> does.
>

Is reasonable, given that overflow for signed types is undefined (so any
approach is "not wrong").


> (7) Have the parser convert oversized hex literals into NULL, or throw
> errors, and have attempts to coerce oversized hex literals strings into
> numeric values fail, thus preventing affinity conversions.
>

+1 for NULL (sounds simplest and least surprising)


> (8) Work like PostgreSQL and Oracle and legacy SQLite and simply do not
> support hexadecimal integer literals.
>

Also good. Maybe, instead, add functions which take hex strings and return
an int. Then you've got much more freedom in terms of error reporting, as
it all happens via the function:

select hexint('0x10')
16


-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to