Tom, on the list you said:
"I would be ecstatic if we could write
int4pl like this:
if (sum_overflows(arg1, arg2))
elog(ERROR, "overflow");
else
return arg1 + arg2;
"
This is effectively what our clang patch does (automatically, for all
integer operations).
Right now our stuff isn't very efficient (~20% slowdown in SPEC INT) but
LLVM does support intrinsics for detecting overflows using processor
flags. Currently we cannot use these because they're buggy but we're
working to get them fixed. I'd expect our integer-checked binaries to
be pretty efficient once this is all working.
John
On 8/2/2010 10:16 AM, Tom Lane wrote:
> John Regehr<regehr@cs.utah.edu> writes:
>> On 08/02/2010 09:06 AM, Tom Lane wrote:
>>> John: how did you detect this?
>
>> One of my students has hacked Clang to detect integer undefined
>> behaviors in C, like this shift problem or signed overflows.
>
> Cool.
>
>> This was
>> the only problem that came up during a "make check" of a postgresql with
>> this checking turned on, which is pretty cool.
>
> Hrm, I'd have expected you to see a few integer overflows during the
> regression tests --- we do test that the overflow checks in places
> like int4pl work. You might be interested in this concurrent thread:
> http://archives.postgresql.org/pgsql-hackers/2010-08/msg00024.php
> particularly the comments about overflow.
>
>> I'd expect to be able to find more problems if I could get hold of a
>> good fuzz tester for postgresql, or at least some much larger test
>> inputs. Are there any of these you folks would suggest that I use?
>
> Yeah, the PG regression tests aren't amazingly good coverage-wise
> (although running the contrib tests as well as core helps --- did you
> do that?). I'm afraid I haven't got a good suggestion for you.
>
> regards, tom lane
>
