On 9/20/16, Scott Hess wrote:
> I also see that some systems
> include __builtin_mul_overflow() intrinsics, which can use the CPU's
> overflow flag, if available, which seems plausible.
>
I too have seen this, and look forward to the wide-spread availability
of these routines.
Yes - once the undefined behavior has happened, the compiler can
dispense with everything else, so if it can prove that your
after-the-fact checks can only happen in case of signed overflow, it
can simply omit them. Great fun.
Dr Hipp landed https://www.sqlite.org/src/info/db3ebd7c52cfc5fc ,
In time, ignore my previous reply to this thread as SQLite portability
requirements make it invalid (at least I think they would). According to
the C language standard, signed overflow is undefined behavior and,
therefore, should not be relied upon.
There is also a simpler way to check it
On 09/20/2016 04:51 PM, Scott Hess wrote:
No patch suggested, though I wouldn't be surprised if my brain makes a
suggestion after things simmer for an hour or so. If either value
needs less than 31 bits, it can't happen, but there's not a simple bit
pattern to check, AFAICT.
Unless
A new ticket has been created at
https://www.sqlite.org/src/info/1ec41379c9c1e400
On 9/20/16, Scott Hess wrote:
> sqlite3MulInt64() in util.c appears to try to detect integer overflow
> by dividing the inputs by 2^32. If both inputs are 0 when divided by
> 2^32, it does
sqlite3MulInt64() in util.c appears to try to detect integer overflow
by dividing the inputs by 2^32. If both inputs are 0 when divided by
2^32, it does the 64-bit multiplication and moves on.
In the case of something like |SELECT 3452005775*3452005775|, both
inputs are greater than 2^31 but
6 matches
Mail list logo