> Paul Jarc wrote: >> Paul Schlie <[EMAIL PROTECTED]> 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)
