Paul Schlie <[EMAIL PROTECTED]> wrote: > One can only hope that the recommendations won't see the light of day in > their present form, as it's fairly clear that once an unspecified value is > read (presuming absents of a trap representation), it becomes logically > visible, and thereby clearly no longer logically indeterminate.
An unspecified value was never indeterminate in the first place. The terms are not synonymous. And an object holding an indeterminate value does not stop being indeterminate when its value is read; reading it invokes undefined behavior. This is true Because The Standard Says So, no matter how illogical it may seem. > presuming absents of any possibility of a trap representation for a > given implementation That's an unreliable presumption. As noted in the defect report, a trap representation can have the same bit pattern as a valid value. Trapness depends not just on the bit pattern, but also how the bit pattern was produced. So even if there are no hardware-level traps, if you read an indeterminate object, a compiler is allowed to produce the same behavior as if there were hardware-level traps. > (as the undefined behavior referenced in the DR is related to a pointer > becoming indeterminate *Some* of the DR relates to pointers. But reading the value of any object (pointer or otherwise) holding a trap representation invokes undefined behavior. paul
