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
