Richard Hipp writes:
>
> On Wed, May 25, 2011 at 4:40 AM, Jan Hudec wrote:
>
> > I need condition
> >
> >object_id = side_id & ~(1 << 63)
> >
> > but that's not valid syntax.
> >
>
> Yeah it is. Try, for example:
>
> SELECT 1234 & ~(1<<63);
> SELECT (-1234) & ~(1<<63);
Wow, th
On Wed, May 25, 2011 at 4:40 AM, Jan Hudec wrote:
> I need condition
>
>object_id = side_id & ~(1 << 63)
>
> but that's not valid syntax.
>
Yeah it is. Try, for example:
SELECT 1234 & ~(1<<63);
SELECT (-1234) & ~(1<<63);
--
D. Richard Hipp
d...@sqlite.org
__
On May 26, 2011, at 2:54 AM, Jan Hudec wrote:
> Gotcha! No, it's not. -1-x is equivalent, but -x-1 is not:
>
>sqlite> select -1-(1<<63), -(1<<63)-1;
>9223372036854775807|9.22337203685478e+18
>
> Besides my point was not that it's not possible, but that it would
> be more readable with de
Igor Tandetnik writes:
> Jan Hudec wrote:
> > (it would be nicest if sqlite could get bitwise not one day).
>
> -x-1 is equivalent, assuming two's complement representation.
Gotcha! No, it's not. -1-x is equivalent, but -x-1 is not:
sqlite> select -1-(1<<63), -(1<<63)-1;
922337203685
Richard,
At 13:07 25/05/2011, you wrote:
>It turns out that the "expected" behavior does not happen in modern C
>compilers. Overflow of signed integers is undefined behavior in C. So if
>you have a signed integer overflow, it might wrap the result (the
>"expected"
>result) or it might segfault
Jan Hudec wrote:
> (it would be nicest if sqlite could get bitwise not one day).
-x-1 is equivalent, assuming two's complement representation.
--
Igor Tandetnik
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mail
Richard Hipp writes:
>
> On Wed, May 25, 2011 at 4:40 AM, Jan Hudec 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://w
On Wed, May 25, 2011 at 4:40 AM, Jan Hudec 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
> thoug
Radovan Antloga writes:
> http://www.sqlite.org/releaselog/3_7_6.html
Ok, I see it's mentioned there. Given that it changes semantics I would have
expected it to be mentioned more prominently though.
Now may I ask why it was done? Are there some known real world cases where it
is better (I have
On 25 mai 2011, at 10:40, Jan Hudec wrote:
> 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)
[...]
> Regard
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 mentione
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.
12 matches
Mail list logo