Re: Signed int overflow behavior in the security context

[Robert Dewar <dewar at adacore dot com>]

Paul Schlie wrote:
> > Brooks Moses wrote:
> > <http://gcc.gnu.org/ml/gcc/2007-01/msg01119.html> ...
> > Does that logic work for you?
>
> no, as although a variable's value may not have been previously defined
> within the context of a particular program, a variable's access semantics
> are orthogonal to what ever value may result from that variable's access;
> and thereby although it's resulting value may be indeterminate, successive
> logical references must sensibly be presumed to yield equivalent values
> baring the variable being declared as being volatile, or having an
> intervening assignment.

Paul, you really really need to read the C standard. It's beginning
to sound as though you haven't, since you keep making things up that
are just not justified by the standard.
> (there seems to be too much desire to arbitrarily justify anything at the
> drop of a hat given an opportunity to associate it directly or indirectly
> with an undefined behavior, regardless of its sensibly

There is no question about what the C standard makes undefined here.
That of course does not preclude giving it defined semantics in a
particular language, thus effectively extending the language, but the
C standard committee in making something undefined is very deliberately
deciding that it is more appropriate than making it implementation
defined.

In the case of access to uninitialized variables in C, no one (or
almost no one, I realize you are an exception), would favor trying
to make this implementation defined. The only way you will get this
is by creating a variant of gcc for your own use yourself :-)

Now a special mode for debugging which does initialize all
uninitialized variables to a specified value, a la GNAT's
pragma Initialize_Scalars, could be useful. But anyone relying
on Paul Schlie semantics for uninitialized variables is writing
rubbish instead of C!