See this: http://www.sqlite.org/releaselog/3_7_6.html
Regards, R.Antloga S, Jan Hudec piše: > 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 > > > > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
