This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Signed int overflow behavior in the security context
- From: Paul Schlie <schlie at comcast dot net>
- To: Paul Jarc <prj at po dot cwru dot edu>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Sun, 28 Jan 2007 02:16:38 -0500
- Subject: Re: Signed int overflow behavior in the security context
> Paul Jarc wrote:
>> Paul Schlie <schlie@comcast.net> wrote:
>> your corresponding supporting standard citation to the contrary?
>
> C99 3.17.2 defines "indeterminate value" as "either an unspecified
> value or a trap representation". 6.2.6.1p5 says of trap
> representations: "If the stored value of an object has such a
> representation and is read by an lvalue expression that does not have
> character type, the behavior is undefined." Possibly other parts of
> the standard also also make it undefined behavior to access an
> uninitialized character-type variable; I haven't looked too closely.
- an lvalue expression is the target expression of an assignment, and
thereby if it has an indeterminate value, it's sensible that it's
semantics are undefined, as in effect it specifies value is being
assigned to an indeterminate storage location (which obviously isn't
a good or determinate thing to do; but has no bearing on an rvalue
access to a well defined storage location returning an indeterminate
value). i.e. lvalue = rvalue :: known_location = indeterminate_value;
or in the case of x ^= x :: known_location = x_value ^ x_value :: 0.
(sorry, or more generally an lvalue expression represent a storage
location designation, either source or target, which if indeterminate
doesn't arguably have a reasonably well specified behavior; which isn't
the case with x ^= x, where all storage location designations are well
defined)