Accessing inactive union member and undefined behavior?

by

The confusion is that C explicitly permits type-punning through a union, whereas C++ (c++11) has no such permission.

c11

6.5.2.3 Structure and union members

95) If the member used to read the contents of a union object is not the same as the member last used to
store a value in the object, the appropriate part of the object representation of the value is reinterpreted
as an object representation in the new type as described in 6.2.6 (a process sometimes called ‘‘type
punning’’). This might be a trap representation.

The situation with C++:

c++11

9.5 Unions [class.union]

In a union, at most one of the non-static data members can be active at any time, that is, the value of at
most one of the non-static data members can be stored in a union at any time.

C++ later has language permitting the use of unions containing structs with common initial sequences; this doesn’t however permit type-punning.

To determine whether union type-punning is allowed in C++, we have to search further. Recall that c99 is a normative reference for C++11 (and C99 has similar language to C11 permitting union type-punning):

3.9 Types [basic.types]

4 – The object representation of an object of type T is the sequence of N unsigned char objects taken up by
the object of type T, where N equals sizeof(T). The value representation of an object is the set of bits that
hold the value of type T. For trivially copyable types, the value representation is a set of bits in the object
representation that determines a value, which is one discrete element of an implementation-defined set of
values. 42
42) The intent is that the memory model of C++ is compatible with that of ISO/IEC 9899 Programming Language C.

It gets particularly interesting when we read

3.8 Object lifetime [basic.life]

The lifetime of an object of type T begins when:
— storage with the proper alignment and size for type T is obtained, and
— if the object has non-trivial initialization, its initialization is complete.

So for a primitive type (which ipso facto has trivial initialization) contained in a union, the lifetime of the object encompasses at least the lifetime of the union itself. This allows us to invoke

3.9.2 Compound types [basic.compound]

If an object of type T is located at an address A, a pointer of type cv T* whose value is the
address A is said to point to that object, regardless of how the value was obtained.

Assuming that the operation we are interested in is type-punning i.e. taking the value of a non-active union member, and given per the above that we have a valid reference to the object referred to by that member, that operation is lvalue-to-rvalue conversion:

4.1 Lvalue-to-rvalue conversion [conv.lval]

A glvalue of a non-function, non-array type T can be converted to a prvalue.
If T is an incomplete type, a program that necessitates this conversion is ill-formed. If the object to which the glvalue refers is not an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program that necessitates this conversion has undefined behavior.

The question then is whether an object that is a non-active union member is initialized by storage to the active union member. As far as I can tell, this is not the case and so although if:

  • a union is copied into char array storage and back (3.9:2), or
  • a union is bytewise copied to another union of the same type (3.9:3), or
  • a union is accessed across language boundaries by a program element conforming to ISO/IEC 9899 (so far as that is defined) (3.9:4 note 42), then

the access to a union by a non-active member is defined and is defined to follow the object and value representation, access without one of the above interpositions is undefined behaviour. This has implications for the optimisations allowed to be performed on such a program, as the implementation may of course assume that undefined behaviour does not occur.

That is, although we can legitimately form an lvalue to a non-active union member (which is why assigning to a non-active member without construction is ok) it is considered to be uninitialized.

More Related Contents:

  1. When does invoking a member function on a null instance result in undefined behavior?
  2. Has C++ standard changed with respect to the use of indeterminate values and undefined behavior in C++14?
  3. Optimizing away a “while(1);” in C++0x
  4. Does initialization entail lvalue-to-rvalue conversion? Is `int x = x;` UB?
  5. Do I need to cast to unsigned char before calling toupper(), tolower(), et al.?
  6. Is `reinterpret_cast`ing between hardware SIMD vector pointer and the corresponding type an undefined behavior?
  7. Why does left shift operation invoke Undefined Behaviour when the left side operand has negative value?
  8. Does “Undefined Behavior” really permit *anything* to happen? [duplicate]
  9. Where exactly does C++ standard say dereferencing an uninitialized pointer is undefined behavior?
  10. Difference between Undefined Behavior and Ill-formed, no diagnostic message required
  11. Is passing a C++ object into its own constructor legal?
  12. Are multiple mutations of the same variable within initializer lists undefined behavior pre C++11
  13. Does not evaluating the expression to which sizeof is applied make it legal to dereference a null or invalid pointer inside sizeof in C++?
  14. In C++11, does `i += ++i + 1` exhibit undefined behavior?
  15. So why is i = ++i + 1 well-defined in C++11?
  16. Why is f(i = -1, i = -1) undefined behavior?
  17. Implementing a std::vector like container without undefined behavior
  18. Are pointer variables just integers with some operators or are they “symbolic”?
  19. The behaviour of floating point division by zero
  20. Can branches with undefined behavior be assumed unreachable and optimized as dead code?
  21. Dangling references and undefined behavior
  22. In which versions of the C++ standard does “(i+=10)+=10” have undefined behaviour?
  23. Observable behavior and undefined behavior — What happens if I don’t call a destructor?
  24. memcpy/memmove to a union member, does this set the ‘active’ member?
  25. A positive lambda: ‘+[]{}’ – What sorcery is this? [duplicate]
  26. Why is out-of-bounds pointer arithmetic undefined behaviour?
  27. Is `long` guaranteed to be at least 32 bits?
  28. Can std::launder be used to convert an object pointer to its enclosing array pointer?
  29. Why do (only) some compilers use the same address for identical string literals?
  30. Can we apply content not explicitly cited from the normative references to the C++ standard?

Leave a Comment