Re: Is it OK that gcc optimizes away overflow check?

[Jeffrey Walton <noloader@gmail.com>]

On Sat, Jul 23, 2011 at 4:13 PM, Agner Fog <agner@agner.org> wrote:
> I have a program where I check for integer overflow. The program failed, and
> I found that gcc has optimized away the overflow check. I filed a bug report
> and got the answer:
>>
>> Integer overflow is undefined. You have to check before the fact, or
>> compile
>> >  with -fwrapv.
>
> ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49820 )
>
> I disagree for several reasons:
>
> 1). It is often easier and more logical to check for overflow after it
> happens than before. It can be quite complicated to write a code that
> predicts an overflow before it happens, in a portable way that works with
> all integer sizes. Checking for overflow after it happens is the only way
> that is sure to work in a hypothetical system that uses something else than
> 2's complement representation.
>
> 2). This is a security problem. It takes a very twisted mind to predict that
> your code is not safe when you are actually checking for overflow.
>
> 3). I think that you are interpreting the C/C++ standard in an over-pedantic
> way. There are good reasons why the standard says that the behavior in case
> of integer overflow is undefined. 2's complement wrap-around is not the only
> possible behavior in case of overflow. Other possibilities are: saturate,
> signed-magnitude wrap-around, reserve a bit pattern for overflow, throw an
> exception. If a future implementation uses internal floating point
> representation for integers then an overflow might variously cause loss of
> precision, INF, NAN, or throw an exception. I guess this is what is meant
> when the standard says the behavior is undefined. What the gcc compiler is
> doing is practically denying the existence of overflow (
> http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg105239.html ) to
> the point where it can optimize away an explicit check for overflow. I
> refuse to believe that this is what the standard-writers intended. There
> must be a sensible compromize that allows the optimizer to make certain
> assumptions that rely on overflow not occurring without going to the extreme
> of optimizing away an overflow check.
>
> 4). The bug in my case disappears if I compile with -fwrapv or
> -fno-strict-overflow or without -O2, but this is not my point. My point is
> that gcc should be useful to a programmer with average skills.
>
> 5). I have tested many different C++ compilers, and gcc turned out to be the
> one that optimizes best. You guys are doing a fantastic job! Gcc has the
> potential to beat the expensive commercial compilers. But one obstackle to
> its use is that it has a well-deserved reputation for being over-pedantic.

Its really too bad that GCC does not offer something for overflow and
carry. There's been a couple of feature requests for overflow and
carry testing when the CPU supports it, but I don't believe its gained
any momentum (what does that say about secure programming practices?):
 * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
 * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49467

Jeff