Re: Signed int overflow behavior in the security context

[James Dennett <jdennett at acm dot org>]

Paul Schlie wrote:
>> Paul Jarc wrote:
>>> Paul Schlie wrote:
>>> if it has an indeterminate value [...] has no bearing on an rvalue
>>> access to a well defined storage location
>> You might think so, but that's actually not true in the C standard's
>> terminology.  It sounds like you interpret "indeterminate value" to
>> mean what the standard defines as "unspecified value" (3.17.3): "valid
>> value of the relevant type where this International Standard imposes
>> no requirements on which value is chosen in any instance".  But
>> "indeterminate value" is defined differently (3.17.2), and any
>> reasoning based on your common-sense understanding of the term,
>> instead of the standard's definition of it, has no relevance to the
>> standard.  The standard is not intuitive; it can only be understood by
>> careful reading.
>>
>> The key concept that you seem to be missing is trap representations.
>> See 6.2.6.1p5, also keeping in mind that "lvalue", as used in the
>> standard, probably means something slightly different from what you
>> might expect; see 6.3.2.1p1.
> 
> Thanks, however I interpret the standard to clearly mean:
> 
>  int x; int* y;
> 
>  x = x ; perfectly fine; as lvaue x clearly designates an object (no trap)

This expression uses lvalue to rvalue conversion on
the object x, which has an indeterminate value that
may be a trap value.

Just because x refers to an int, does not mean that
reading from x is valid.  It's hard to understand
what you are trying to say.  Your comment above says
why it's OK to *write* to x, but says nothing of the
problem with *reading* from x.

Here is a very similar example:

int x;
int z;
z = x;

In this, x and z name two objects, each with an
indeterminate initial value.  The assignment reads
from the indeterminate value of x (which gives
undefined behavior) and writes to z.  If x were
initialized, this would be well-defined, as there
would be no reading of a trap value.

comp.std.c and comp.std.c++ may be better places
for much of this discussion.

-- James