Solution [LWN.net]

Solution

Posted Apr 17, 2008 0:44 UTC (Thu) by clugstj (subscriber, #4020)
Parent article: GCC and pointer overflows

How about this obvious solution.  When compiling old crusty code, don't use the
latest-and-greatest compiler optimizations?  (I'm assuming this one can be turned off.)

The older, and less recently maintained, the code, the more conservative the optimization
should be.

(Log in to post comments)

Solution

Posted Apr 17, 2008 15:27 UTC (Thu) by proski (subscriber, #104) [Link]

Bugs exist not only in old crusty code. Just because the code was written recently, it doesn't make the code better or safer. Even if the code was developed with the new compiler but was not specifically tested for overflows, it still can have that problem.

Solution

Posted Apr 17, 2008 17:24 UTC (Thu) by clugstj (subscriber, #4020) [Link]

OK, how about this: if you don't trust the code, don't use the latest whiz bang optimizations!

The documentation for GCC should specifically warn about optimizations that can do bad things
with questionable code.  As an example, here is a quote from the "Sun Workshop 6 update 2" man
page:

            -xO3 In addition to optimizations performed at the
                    -xO2 level, also optimizes references and
                    definitions for external variables.  This
                    level does not trace the effects of pointer
                    assignments.  When compiling either device
                    drivers that are not properly protected by
                    volatile, or programs that modify external
                    variables from within signal handlers, use
                    -xO2

Let's not penalize GCC because of how some people will use/abuse it.