This is the mail archive of the
mailing list for the GCC project.
Re: Signed int overflow behavior in the security context
- From: Robert Dewar <dewar at adacore dot com>
- To: Paul Schlie <schlie at comcast dot net>
- Cc: Andreas Bogk <andreas at andreas dot org>, gcc at gcc dot gnu dot org
- Date: Fri, 26 Jan 2007 19:08:48 -0500
- Subject: Re: Signed int overflow behavior in the security context
- References: <C1DFFFA7.FAE0email@example.com>
Paul Schlie wrote:
Robert Dewar wrote:
People always say this, but they don't really realize what they are
saying. This would mean you could not put variables in registers, and
would essentially totally disable optimization.
- can you provide an example of a single threaded program where the
assignment of variable to a machine register validly changes its
observable logical results?
Well any VALID program is not affected, but this whole discussion
is about INVALID programs (e.g. those that have undefined overflow).
The common case where assigning a variable to a register changes the
results is when the variable is referenced before it has been
initialized. Very often you find that if the value is in memory
you get some nice value like zero, but once it is assigned to a
register, you get rubbish.
By the way, GNAT has a nice feature for going after uninitialized
variables. If you use pragma Initialize_Scalars, then ALL scalars
are initialized with a pattern you can change at link time, or even
at run time with an environment variable, and you can see if your
program depends on the pattern chosen, which of course it should
The -O2 flag is exactly a request to do optimizations that may cause
wrong programs to generate different results.
- well this is certainly an interesting definition of -O2; and implicit
definition of any program which invokes an undefined behavior as being
"wrong"; as opposed to being arguably more accurately non-portable;
no undefined means undefined, it does not mean non-portable. There is
a BIG difference between undefined (= wrong) and implementation defined
the standard enables compilers to specify a well defined behavior to
that otherwise specified as being undefined. (nor seemingly particularly
clever, as intentionally invoking a behavior not previously expressed
seems like a great way to silently inject bugs into a program debugged
utilizing lesser degrees of optimization as is typically done.)
Yes, but the standard leaves things undefined (as opposed to
implementation defined) *precisely* in those cases where it is
considered inappropriate to require a definition of the behavior.
The C standard committee carefully decides on a case by case
basis how to identify each situation.