Public Comment Number PC-UK0277 ISO/IEC CD2 9899 (SC22N2794) Public Comment =========================================== Date: 1998-12-12 Author: C.D.W.Feather Author Affiliation: Self Postal Address: Demon Internet Ltd. 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Category: Inconsistency Committee Draft subsection: 6.2.6.1, 6.5.2.3 Title: Effects on other members of assigning to a union member Detailed description: 6.5.2.3p5 has wording concerning the storing of values into a union member: With one exception, if the value of a member of a union object is used when the most recent store to the object was to a different member, the behavior is implementation-defined. When this wording was written, "implementation-defined" was interpreted more loosely and there was no other relevant wording concerning the representation of values. Neither of these is the case anymore. The requirement to be implementation-defined means that an implementation must ensure that all stored values are valid in the types of all the other members, and eliminates the possibility of them being trap representations. It also makes it practically impossible to have trap representations at all. This is not the intention of other parts of the Standard. It turns out that the wording of 6.2.6.1 is sufficient to explain the behavior in these circumstances. Type punning by unions causes the same sequence of bytes to be interpreted according to different types. In general, 6.2.6.1 makes it clear that bit patterns can be trap values, and so the programmer can never be sure that the value is safe to use in a different type. One special case that should be considered is the following: union { unsigned short us; signed int si; unsigned int ui; } x; If x.si is set to a positive value, the requirements of 6.2.5 and 6.2.6.1 will mean that x.ui holds the same value with the same representation. This appears to be a reasonable assumption. A similar thing happens if x.ui is set to a value between 0 and INT_MAX. If x.si is set to a negative value, or x.ui to a value greater than INT_MAX, the other might be set to a trap representation if there are any padding bits; if there are none, then it must be the case that the extra bit in x.ui overlaps the sign bit of x.si. Finally, if x.ui is set to some value and x.us does not have any padding bits and does not overlap any padding bits of x.ui, then x.us will have some value determinable from the arrangement of bits in the two types (this might be the low bits of x.ui, the high bits, or some other combination). None of these cases should be particularly surprising. The cited wording in 6.5.2.3 merely muddles the issue by implying that all possible members take sensible (non-trap) values. It should be removed; the rest of the paragraph can stand alone.