Is this type punning well-defined?

Question

Reading quote in this answer about strict aliasing rule, I see the following for C++11:

If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:

• ...

• an aggregate or union type that includes one of the aforementioned types among its elements or non-static data members (including, recursively, an element or non-static data member of a subaggregate or contained union),

• ...

So I take it to mean that the following code doesn't break strict aliasing rule:

#include <iostream>
#include <cstdint>
#include <climits>
#include <limits>

struct PunnerToUInt32
{
    std::uint32_t ui32;
    float fl;
};

int main()
{
    static_assert(std::numeric_limits<float>::is_iec559 &&
                  sizeof(float)==4 && CHAR_BIT==8,"Oops");
    float x;
    std::uint32_t* p_x_as_uint32=&reinterpret_cast<PunnerToUInt32*>(&x)->ui32;
    *p_x_as_uint32=5;
    std::cout << x << "\n";
}

So OK, strict aliasing rule is satisfied. Does this still exhibit undefined behavior for any other reason?

Answer 1

You cannot do this: &reinterpret_cast<PunnerToUInt32*>(&x)

The rules on reinterpret_cast state:

When a pointer or reference to object whose dynamic type is DynamicType is reinterpret_cast (or C-style cast) to a pointer or reference to object of a different type AliasedType, the cast always succeeds, but the resulting pointer or reference may only be used to access the object if one of the following is true:

• AliasedType is (possibly cv-qualified) DynamicType
• AliasedType and DynamicType are both (possibly multi-level, possibly cv-qualified at each level) pointers to the same type T
• AliasedType is the (possibly cv-qualified) signed or unsigned variant of DynamicType
• AliasedType is an aggregate type or a union type which holds one of the aforementioned types as an element or non-static member (including, recursively, elements of subaggregates and non-static data members of the contained unions): this makes it safe to obtain a usable pointer to a struct or union given a pointer to its non-static member or element.
• AliasedType is a (possibly cv-qualified) base class of DynamicType
• AliasedType is char or unsigned char: this permits examination of the object representation of any object as an array of unsigned char

Because none of these are true for the combination of DynamicType being float and AliasedType being PunnerToUInt32 the pointer may not be used to access the object, which you are doing. Making the behavior undefined.

For more information see: Why Doesn't reinterpret_cast Force copy_n for Casts between Same-Sized Types?

EDIT:

Breaking down the 4^th bullet int bite size chunks yields:

1. "AliasedType"
   Here taken to be PunnerToUInt32

2. "is an aggregate type or a union type"
   PunnerToUInt32 qualifies since it meets the qualifications of an aggregate type:

   • array type
   • class type (typically, struct or union), that has
     • no private or protected non-static data members
     • no user-provided constructors, including those inherited from public bases (explicitly defaulted or deleted constructors are allowed)
     • no virtual, private, or protected base classes
     • no virtual member functions

3. "which holds one of the aforementioned types as an element or non-static member (including, recursively, elements of subaggregates and non-static data members of the contained unions)"
   Again PunnerToUInt32 qualifies because of it's float fl member

4. "this makes it safe to obtain a usable pointer to a struct or union"
   This is the final correct part as AliassedType is a PunnerToUInt32
5. "given a pointer to its non-static member or element"
   This is a violation, because the DynamicType which is x is not a member of PunnerToUInt32

Because of the violation of part 5 operating on this pointer is undefined behavior.

If you care for some recommended reading you can check out Empty Base Optimization if not I'll give you the primary relevance here:

Empty base optimization is required for StandardLayoutTypes in order to maintain the requirement that the pointer to a standard-layout object, converted using reinterpret_cast, points to its initial member

Thus you could exploit reinterpret_cast's 4^th bullet by doing this:

PunnerToUInt32 x = {13, 42.0F};
auto y = reinterpret_cast<PunnerToUInt32*>(&x.ui32);

Live Example

Answer 2

If p_x_as_uint32 were somehow pointing to x¹, then *p_x_as_uint32=5 would access an object of type float through a glvalue of type uint32_t, which would result in undefined behavior.

The "access" at issue is the assignment, and all that matters are the type of the glvalue used (uint32_t) and the actual type of the object accessed (float). The tortured series of casts used to obtain the pointer is irrelevant.

It's worth remembering that the strict aliasing rule exists to enable type-based alias analysis. However tortured the route taken is, if you can legally "create a situation where an int* and a float* can simultaneously exist and both can be used to load or store the same memory, you destroy TBAA". If you think the standard's wording somehow allowed you to do this, you are probably wrong, but if you were right, then all you've found is a defect in the standard wording.

---

¹ The class member access is undefined behavior (by omission) because there's no actual PunnerToUInt32 object. However, a class member access is not an "access" within the meaning of the strict aliasing rule; the latter means "to read or modify the value of an object".