Hello All, [Is this correct place to report a bug, or can I create it in Fossil somehow?]
Semantics of operations on integers changed between 3.7.5 and 3.7.6. It does not seem to be mentioned in change log (http://www.sqlite.org/news.html), though it may affect existing applications: * Up to 3.7.5, integer operations are always carried out in 64-bit integers and overflow as expected for that type. * From 3.7.6 on, integer operands of *some operations* (left shift being notable exception) are converted to real if the operation would overflow. I don't think either behaviour is specified anywhere. However, the old behaviour was IMO consistent and was very useful for two cases: * When working with unsigned numbers on the application side (arithmetic operations except division (/) and right shift (>>) don't consider sign). * To get some bit patterns when doing bitwise operations (since there are & and |, but no negation and no hexadecimal literals). On the other hand the new behaviour will: * Give MIN_INT64 for all operations that overflowed (the application expects integer, so will probably read with sqlite3_column_int64 and conversion of too large reals *is* specified to return MIN_INT64). * Give inprecise result for cases where the overflows cancel out (e.g. a + b - c where a + b overflows, but a + (b - c) does not. Would you be so kind and at least visibly document this change, consider which behaviour is actually prefered and document the behaviour. Thanks. As for my particular case, I have a database with table (let's call it "objects") with large integeral primary key and many other tables refering to it. And another table (let's call it "sides"), which needs *two* rows for each row in "objects". Since "integer primary key" is faster than "primary key (object_id, side)" and since the rows are mostly handled independenty (and have many other things refer to them), I construct a primary key with: object_id | (side << 63) Now when I need to join "sides" and "objects", I need condition object_id = side_id & ~(1 << 63) but that's not valid syntax. There are two alternatives: (1 << 63) - 1 or -1 - (1 << 63) I used the first, because it is more readable to me (while the later is exact alternative to the bitwise not, it's not common knowledge, because other languages do have bitwise not). But it stopped working in 3.7.6 (the later still does, so I can convert it, but it's error-prone situation). Regards, Jan -- - Jan Hudec <b...@ucw.cz> _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
