Is reinterpret_cast type punning actually undefined behavior?

by

I believe your misunderstanding lies here:

This reads to me as an explicit statement that the result of reinterpret_cast<T&>(v) is an lvalue reference to an object of type T, to which access is clearly “through a glvalue of” “the dynamic type of the object”.

[basic.lval]/8 is a bit misleading because it talks about the dynamic type “of the object” when the dynamic type is actually a property of the glvalue [defns.dynamic.type] used to access the object rather than the object itself. Essentially, the dynamic type of the glvalue is the type of the object that is currently living in the place that the glvalue refers to (effectively, the type of the object that was constructed/initialized in that piece of memory) [intro.object]/6. For example:

float my_float = 42.0f;
std::uint32_t& ui = reinterpret_cast<std::uint32_t&>(my_float);

here, ui is a reference that refers to the object created by the definition of my_float. Accessing this object through the glvalue ui would invoke undefined behavior (per [basic.lval]/8.1), however, because the dynamic type of the glvalue is float while the type of the glvalue is std::uint32_t.

There are few valid uses of a reinterpret_cast like that, but use cases other than just casting to void* and back exist (for the latter, static_cast would be sufficient, as you noted yourself). [basic.lval]/8 effectively gives you a complete list of what they are. For example, it would be valid to examine (and even copy if the dynamic type of the object is trivially-copyable [basic.types]/9) the value of an object by casting the address of the object to char*, unsigned char*, or std::byte* (not signed char*, however). It would be valid to reinterpret_cast an object of signed type to access it as its corresponding unsigned type and vice versa. It would also be valid to cast a pointer/reference to a union to a pointer/reference to a member of that union and access that member through the resulting lvalue if that member is the active member of the union…

The main reason why type punning through casts like this is undefined in general is that making it defined behavior would prohibit some extremely vital compiler optimizations. If you’d allow any object of any type to simply be accessed through an lvalue of any other type, then the compiler would have to assume that any modification of an object through some lvalue can potentially affect the value of any object in the program unless it can prove otherwise. As a result, it would basically be impossible, for example, to keep stuff around in registers for any useful period of time because any modification of anything would immediately invalidate whatever you may have in registers at the moment. Yes, any good optimizer will perform aliasing analysis. But, while such methods certainly work and are powerful, they can, out of principle, only cover a subset of cases. Disproving or proving aliasing in general is basically impossible (equivalent to solving the halting problem I would think)…

More Related Contents:

  1. casting via void* instead of using reinterpret_cast [duplicate]
  2. What is the modern, correct way to do type punning in C++?
  3. When to use reinterpret_cast?
  4. Efficient unsigned-to-signed cast avoiding implementation-defined behavior
  5. Aliasing T* with char* is allowed. Is it also allowed the other way around?
  6. Is there a (semantic) difference between the return value of placement new and the casted value of its operand?
  7. Does accessing the first field of a struct via a C cast violate strict aliasing?
  8. Why doesn’t this reinterpret_cast compile?
  9. Is casting std::pair const& to std::pair const& safe?
  10. Is it a strict aliasing violation to alias a struct as its first member?
  11. Should I use a C++ reinterpret_cast over a C-style cast?
  12. C++ When should we prefer to use a two chained static_cast over reinterpret_cast
  13. Why Doesn’t reinterpret_cast Force copy_n for Casts between Same-Sized Types?
  14. Why do we have reinterpret_cast in C++ when two chained static_cast can do its job?
  15. Multi-character constant warnings
  16. Will std::string always be null-terminated in C++11?
  17. Can I assume (bool)true == (int)1 for any C++ compiler?
  18. Cast pointer to member function to normal pointer
  19. C++ auto vs auto&
  20. Is circumventing a class’ constructor legal or does it result in undefined behaviour?
  21. Why is f(i = -1, i = -1) undefined behavior?
  22. Passing shared_ptr as shared_ptr
  23. Why is the std::initializer_list constructor preferred when using a braced initializer list?
  24. What happened to the “aggregate or union type that includes one of the aforementioned types” strict aliasing rule?
  25. Can I Reference Previous Members of an Initializer List?
  26. Does reinterpret_cast lead to undefined behavior?
  27. Understanding gsl::narrow implementation
  28. Is it Undefined Behaviour to cast away the constness of a function parameter?
  29. Why is reinterpret_cast not constexpr?
  30. Does the standard mandate an lvalue-to-rvalue conversion of the pointer variable when applying indirection?

Leave a Comment