On 23 Jul 2014 at 12:07, Richard Hipp <d...@sqlite.org> wrote: > We are looking into adding hexadecimal integer literals to SQLite. In > other words, we are looking to enhance SQLite to understand 0x1234 as > another way of writing 4660. Hex literals are useful in conjunction with > the bit-wise AND and OR operators (& and |) and in applications that make > use of bit fields. > > The question is what to do with hex literals that are larger than 64 bits. > In other words, what number is represented by (say): > > 0x123456789abcdef01
I would say take up to 64 bits. More than that to be handled as an error in the same way that a too-long string of decimal digits would be for an integer, or a floating value that won't fit because the exponent is too large. Equally, if the string contains a character invalid for the type, handle all in the same way. E.g.: 0x1234zz 1234zz 1.234zz should have the same error treatment, if any. I note that "select 1234zz;" in the shell gives a good error message but I don't know if that's just the shell being clever or the library is picking it up. Regarding signed/unsigned, what is done for integers? Perhaps if a hex literal is prefixed with a minus, that simply forces the sign bit on. -- Cheers -- Tim
_______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
