> Joseph Myers wrote: > DR#260 seems clear enough that indeterminate values may be treated > distinctly from determinate values including randomly changing at any > time. <http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm>
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. Further, regardless of the recommendations; and presuming absents of any possibility of a trap representation for a given implementation; x ^= x remains well defined, although not necessarily equivalent to 0; as although lvalue x remains well defined, its rvalue is proposed to remain repetitively unspecified until being assigned the result of the dynamically evaluated xor operation having two potentially differing unspecified operand values. (as the undefined behavior referenced in the DR is related to a pointer becoming indeterminate because it was assigned an indeterminate value, or the object it had referenced has been freed and thereby no longer a valid object of the pointer's type, and thereby although the pointer's value has not changed, it's value is now considered a trap representation; not because the value it references has been assigned an indeterminate value)
