> Note that we recommend using -fwrapv with gcc, so that it doesn't break
> code that depends on this type of test. (If int4inc isn't working then
> there are probably a lot of other places that are broken too.) I imagine
> LLVM has the same or similar switch.
llvm-gcc has the -fwrapv flag, but Clang does not, nor does Intel CC.
>> There are several easy ways to fix this code. One would be to test arg
>> against INT_MAX before incrementing. Another would be to cast arg to
>> unsigned, increment it, then do the check.
> None of these proposals are improvements over what's there. The
> fundamental problem is that if the compiler chooses to believe that
> overflow doesn't exist, it can optimize away *any* test that could only
> succeed in overflow cases. Finding a form of the test that fails to be
> optimized away by today's version of gcc doesn't protect you against
> tomorrow's version.
Your assessment is not quite correct. The existing function -- when passed
INT_MAX as the argument -- executes an operation with undefined behavior,
and a correct C compiler can optimize away the check.
The alternate tests do not execute operations with undefined behavior for
any argument value. Therefore, any compiler which removes the test is
wrong. Both the GCC and LLVM groups will be happy to fix a bug of that
kind if it exists.
In response to
pgsql-bugs by date
|Next:||From: Tom Lane||Date: 2010-04-14 19:30:10|
|Subject: Re: [BUGS] BUG #5412: test case produced, possible race condition. |
|Previous:||From: Tom Lane||Date: 2010-04-14 19:18:51|
|Subject: Re: BUG #5421: pg_attribute broken |