> 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)
x = *y ; undefined, as lvalue *y is indeterminate (may trap if referenced)
*y = x ; undefined, as above.
As otherwise further given:
volatile int* z = (int*)ADDRESS ;
x = *z ; would also be undefined, as with lvalue x above, lvaue *z
; references an object who's rvalue has not been initialized;
; and hopefully a more clearly a wrong interpretation; as
; these semantics are critical to writing low-level drivers.
