Paul Schlie wrote: >> 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;
Here's a crucial point; int *can* have such invalid value representations according to the C and C++ standards. However: in many implementations, all bit patterns that can be stored in an object of type int *do* correspond to valid values. Therefore, a case can be made that *for an implementation in which a type has no trap values*, an indeterminate value must correspond to some specific value. In other words: reading an uninitialized int is undefined behavior only if int includes trap representations in a given implementation. Otherwise, all we have is an unspecified (but valid) value, which is a common assumption. I'm not sure that I like this conclusion, but I've not seen a really good argument against it. -- James