> Robert wrote: >> Paul Schlie wrote: >> - 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. > > First of all, trap representations of COURSE exist for floating-point > objects, I guess you don't know fpt formats (most people don't).
- as trap representation within the context of C is a value representation which is not defined to be a member of a type, where if accessed or produced evokes undefined behavior; so admit as to the best of my knowledge all potentially enclosable values for IEEE floats and doubles are defined, it would seem trap representations don't exist in typical fp implementations, as such an implementation would require more bits of encoding than the type itself requires. > But in any case, your reasoning here is once again based on the language > you wish you had, rather than the formal semantic language defined by > the standard, which has no notion of "no legitimate trap representation". > > The standard says an uninitialized variable can have a trap > representation. Therefor it can. - yes that is consistent, one wouldn't want to have to think about reality. > There is no license to reason about how you think code is generated, any > compiled is allowed to generate code AS IF a trap representation were present. - yes, and thereby inconsistent with reality, and thereby wrong. (as may and may not are equivalent possibilities) > I think you often miss this distinction between > > generated code at the implementation level > > as if behavior from the rules in the standard >> >> 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. > > Looks unspecified to me, but in any case reasoning which says > > The standard must say X, since otherwise I could not write "hardware > drivers required of all computer systems", is bogus. There is nothing > that says valid C can be used to write such drivers. - I buy the value is unspecified, the semantics are not.
