On Sat, Jul 23, 2011 at 4:13 PM, Agner Fog <agner@xxxxxxxxx> 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@xxxxxxxxxxxxxx/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
