> Paul Jarc wrote: >> Paul Schlie <[EMAIL PROTECTED]> wrote: >> x = x ; perfectly fine; as lvaue x clearly designates an object (no trap) > > Can you cite the part of the standard that says that? The fact that > an expression designates an object does not exclude that object from > holding a trap representation. A trap representation, as defined by > the standard (6.2.6.1p5), is unrelated to dereferencing an invalid > pointer. The word "trap" is also sometimes used to refer to > dereferencing an invalid pointer, but that's not relevant here, since > the standard uses a different definition.
In context: - Certain object representations need not represent a value of the object type. - 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. - If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined.41) - Such a representation is called a trap representation. Means: a trap representation is a value representation which does not constitute a valid member of an object's type except if a char; and if such an object value representation is read or produced by an lvalue expression, the behavior is undefined (because simply any operation which produces or attempts to utilize a value whose representation does not validly represent a member of that object's type, it's behavior is sensibly undefined; i.e. access or store a value having the logical representation of the value 7 in association with an object having a specified enum range of 0..5, and all bets are off with respect to how that object's value may be subsequently interpreted, as such an access may be recognized as being invalid and be trapped). Just as the dereference of an indeterminate lvalue may be trapped if its value is an illegitimate member of that type. However as the only thing C says about uninitialized variables is that its value will be initialized with an indeterminate value; which could be a trap representation, but as most object type implementations inclusive of ints don't have any invalid value representations; and as the standard very clearly requires a trap representation be read or stored by the lvalue expression to invoke undefined behavior, the only circumstance in which this may typically validly occur in conventional implementations is upon storing or reading an pointer, struct or emum object type with an illegitimate (trap) value representation.