> Paul Jarc wrote: >> Paul Schlie 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.
- undefined behavior is only invoked if the value is a trap representation. >> 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. - that's not what is says, a pointer value may be/become a trap representation when the object pointed to by that value is not or ceases to be a legitimate member of the pointers type, thereby the pointer's value is/becomes an illegitimate member of that pointers type, ergo a trap representation. >> (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. - agreed, and thereby objects having no legitimate trap representation, such as most if not all implementations of integers and floating point objects on most if not all current target machines, and thereby their access does not invoke an undefined behavior. Just as: volatile int* port = (int*)PORT_ADDRESS; int input = *port; supposedly invoking an undefined behavior. is required to be well specified, effectively reading through a pointer an un-initialized object's value, and then assigning that unspecified value to the variable input; as otherwise the language couldn't be utilized to write even the most hardware drivers required of all computer systems. (however regardless, I acquiesce to those to continue to wish otherwise, to the apparent continued destruction of the language for no apparent particularly useful purpose by increasingly striving to render it undefined)
