Richard Hipp <drh@...> writes: > > On Wed, May 25, 2011 at 4:40 AM, Jan Hudec <bulb@...> wrote: > > > Hello All, > > > > 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), > > > > 4th bullet here: http://www.sqlite.org/releaselog/3_7_6.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. > > > > It turns out that the "expected" behavior does not happen in modern C > compilers. Overflow of signed integers is undefined behavior in C.
Yes, I know. That's why I always use unsigned on the C side. However since sqlite does not have unsigned numbers, it would be useful if it was defined for what it does have. > So if > you have a signed integer overflow, it might wrap the result (the "expected" > result) or it might segfault, or it might reformat your hard drive (probably > not, but it could and still comply with the spec!) Recent compilers will > take advantage of this undefined behavior to take shortcuts with signed > integer arithmetic, meaning that different things happen on different > compilers and with different optimization settings. Yes it will, if there are any. > > 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) > > > > Surprisingly, the first does *not* work in C - at least not all the time. Well, it will, for the simple reason that the result will be declared unsigned and (besides not being overflow in that case) unsigned wrap around is defined. > The answer is undefined. It gives the "expected" answer often, especially > when optimizations are disabled. But if you crank up the optimization on a > recent version of GCC or Clang, you'll likely get something different from > what you expect, unfortunately. In fact, there is no optimization it could do in this particular case. Also it can't take any shortcuts in the SQLite evaluator code, because it has to compile each operation separately, so it can't apply any transformations, whether they assume overflow does not happen or not. > > 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). It seems there are not many people doing bit operations in sqlite, so I'll just switch to the less obvious, but more correct variant. (it would be nicest if sqlite could get bitwise not one day). Regards, Jan _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
