6

It appears to be widely-held that type punning via reinterpret_cast is somehow prohibited (properly: "undefined behavior", that is, "behavior for which this International Standard imposes no requirements", with an explicit note that implementations may define behavior) in C++. Am I incorrect in using the following reasoning to disagree, and if so, why?

[expr.reinterpret.cast]/11 states:

A glvalue expression of type T1 can be cast to the type “reference to T2” if an expression of type “pointer to T1” can be explicitly converted to the type “pointer to T2” using a reinterpret_­cast. The result refers to the same object as the source glvalue, but with the specified type. [ Note: That is, for lvalues, a reference cast reinterpret_­cast<T&>(x) has the same effect as the conversion *reinterpret_­cast<T*>(&x) with the built-in & and * operators (and similarly for reinterpret_­cast<T&&>(x)).  — end note ] No temporary is created, no copy is made, and constructors or conversion functions are not called.

with the footnote:

75) This is sometimes referred to as a type pun.

/11 implicitly, via example, carries the restrictions of /6 through /10, but perhaps the most common usage (punning objects) is addressed in [expr.reinterpret.cast]/7:

An object pointer can be explicitly converted to an object pointer of a different type. When a prvalue v of object pointer type is converted to the object pointer type “pointer to cv T”, the result is static_­cast<cv T*>(static_­cast<cv void*>(v)). [ Note: Converting a prvalue of type “pointer to T1” to the type “pointer to T2” (where T1 and T2 are object types and where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value.  — end note ]

Clearly the purpose cannot be conversion to/from pointers or references to void, as:

  1. the example in /7 clearly demonstrates that static_cast should suffice in the case of pointers, as do [expr.static.cast]/13 and [conv.ptr]/2; and
  2. [conversions to] references to void are prima facie invalid.

Further, [basic.lval]/8 states:

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:

(8.1) the dynamic type of the object,

(8.2) a cv-qualified version of the dynamic type of the object,

(8.3) a type similar to the dynamic type of the object,

(8.4) a type that is the signed or unsigned type corresponding to the dynamic type of the object,

(8.5) a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object,

(8.6) 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),

(8.7) a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,

(8.8) a char, unsigned char, or std​::​byte type.

And if we return to [expr.reinterpret.cast]/11 for a moment, we see "The result refers to the same object as the source glvalue, but with the specified type." 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". This sentence also addresses the argument that various paragraphs of [basic.life] apply via the spurious claim that the results of such conversions refer to a new object of type T, the lifetime of which has not yet begun, which just happens to reside at the same memory address as v.

It seems nonsensical to explicitly define such conversions only to disallow standard-defined use of the results, particularly in light of footnote 75 noting that such [reference] conversion is "sometimes referred to as a type pun."

Note that my references are to the final publicly-available draft for C++17 (N4659), but the language in question is little-changed from N3337 (C++11) through N4788 (C++20 WD) (tip link will likely refer to later drafts in time). In fact the footnote to [expr.reinterpret.cast]/11 is made even more explicit in the most recent draft:

This is sometimes referred to as a type pun when the result refers to the same object as the source glvalue.

pandorafalters
  • 162
  • 10
  • 4
    I haven't noticed that belief being held even narrowly. – molbdnilo Jan 01 '19 at 13:19
  • It appears to come and go, much like similar beliefs regarding punning with `union`s or `memcpy`. – pandorafalters Jan 01 '19 at 14:09
  • 1
    *This reads to me as an explicit statement that the result of reinterpret_cast(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"*. No, you're wrong here. I don't understand why you think this. If you access the result, you access it through the type `T`, not the dynamic type of `v`. – geza Jan 01 '19 at 14:19
  • The reference is an lvalue or xvalue, both proper subsets of glvalue. Said glvalue has [dynamic] type `T&`. Said glvalue is a reference to the object also referred to by glvalue `v`. – pandorafalters Jan 01 '19 at 14:33
  • 1
    A glvalue does't have a dynamic type. A glvalue is a value and values just have a type. The only kind of entity that has a dynamic type is an object. A value is not an object. – Michael Kenzel Jan 01 '19 at 14:35
  • @MichaelKenzel "_A glvalue is a value_" What is that value? – curiousguy Jan 02 '19 at 07:48
  • It was _very_ well known in the C++ committee that the original C++ std had syntax for these casts but no defined semantics, not even for accessing the first member of a POD. – curiousguy Jan 02 '19 at 09:13
  • 1
    No object of type `T` exists (reinterpret_cast does not create an object) – M.M Jan 03 '19 at 07:35
  • 4
    @MichaelKenzel No; *dynamic type* is a property that an expression has (it's not a property of an object). An object just has its type. An expression may have different dynamic type to its static type , in the case that the expression designates a base class subobject – M.M Jan 03 '19 at 07:38
  • @M.M You are correct, I was looking for a definition but somehow overlooked it in [defns.dynamic.type]. And my understanding was incorrect. Apologies and thanks for pointing that out, always glad to learn something! – Michael Kenzel Jan 04 '19 at 19:51
  • I would like to point out, however, that that doesn't really change anything about the fact that a glvalue is not an object (the point I was trying to make) and that the explanation in my answer below as to why OP's reasoning is incorrect should still hold… – Michael Kenzel Jan 04 '19 at 19:55

3 Answers3

8

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)…

user17732522
  • 53,019
  • 2
  • 56
  • 105
Michael Kenzel
  • 15,508
  • 2
  • 30
  • 39
  • Your answer ignores the standard itself saying that (a reference to) the _same object_ is returned _with a different type_. How can the object retain its original type _and_ be returned from the conversion operator with a different type? You mention sign conversion, but this is the first time in over 20 years that I've seen that even implied to be a type pun. You also mention casting to `char*` et al., but those are only relevant to _pointer_ conversions - in which case why explicitly allow _reference_ conversions which cannot be so used? (Note that this rule long predates `std::byte` types.) – pandorafalters Jan 01 '19 at 14:07
  • 2
    A `reinterpret_cast` does *not* return an object. It's an expression that evaluates to a value which either *points* or *refers* to an object. The standard doesn't say anything about the type of the object being changed. It simply states that a glvalue is returned that has a different type but *refers* to the same object. We're not talking about sign conversions here, we're talking about interpreting the value of an object as another type, which is *fundamentally* different from a conversion. Reference conversion can be used in some of the cases listed in [basic.lval]/8 as described above. – Michael Kenzel Jan 01 '19 at 14:18
  • Very well; the `reinterpret_cast` expression _results in_ a reference to the same object with a different type. "The result refers to the same object as the source glvalue, but with the specified type." What, precisely, is the value imputed to allowing objects and values to have different types if you then require them to have types which don't even _require_ a `reinterpret_cast` in order to make valid use of `reinterpret_cast`? – pandorafalters Jan 01 '19 at 14:42
  • The issue of "interpreting" is a red herring and clearly addressed by [\[expr.reinterpret.cast\]/3](https://timsong-cpp.github.io/cppwp/n4659/expr.reinterpret.cast#3): "[ Note: The mapping performed by reinterpret_­cast might, or might not, produce a representation different from the original value.  — end note ]". – pandorafalters Jan 01 '19 at 14:43
  • 3
    Again, there are some things that can only be achieved via `reinterpret_cast`. For example, how would you cast a pointer to an integer and back without `reinterpret_cast`? How would you cast a function pointer to a different function pointer type and back? Just because there are cases where `reinterpret_cast` is effectively just a shorthand or just one of several ways to get the same result doesn't mean that there's no justification for it to exist at all. Just because not every possible use of feature X is also a valid use of that feature doesn't mean there are no valid uses of feature X… – Michael Kenzel Jan 01 '19 at 15:09
  • There are many other cases in the language, e.g., also with other types of casts, where functionalities overlap to some degree. Your argument is essentially the same as saying "if I can only use a lambda as a function pointer if the capture is empty, then what's the point of lambda captures at all?"… – Michael Kenzel Jan 01 '19 at 15:09
  • You seem under the impression that [expr.reinterpret.cast]/3 somehow concerns the value of whatever object the result of `reinterpret_cast` may potentially point/refer to. At least to my understanding, this note actually concerns the result of the `reinterpret_cast` itself. For example, if you were to cast a pointer to a pointer of the same type, the result will have the same type and value, but the representation of that value may be different from the original. Pointers, e.g., may have multiple representations for the same value, imagine a platform where addresses take only a subset of bits… – Michael Kenzel Jan 01 '19 at 15:34
  • 1
    "_The lifetime of an object of type T begins when: (1.1) storage with the proper alignment and size for type T is obtained_" So there is an object there. – curiousguy Jan 02 '19 at 16:22
  • @curiousguy I'm not sure whether this is meant as a reply to me or to OP, or what exactly you mean by "there"… – Michael Kenzel Jan 02 '19 at 21:30
  • @MichaelKenzel If there is sufficient size and proper alignement for a scalar type, there is an object there. Its lifetime has started, even if it's usually not initialized (there are infinitely many object lifetime started, so almost all are uninitialized). "_the type of the object that is currently living in a given place_" is undefined; many objects are "living" (but not initialized). – curiousguy Jan 02 '19 at 23:46
  • 2
    @curiousguy sorry, I have no idea what you're talking about. There can only be one complete object alive in any piece of memory at any given moment. As soon as another object is created in some piece of storage, the lifetime of whatever object may currently reside in there ends [\[basic.life\]/1.4](http://eel.is/c++draft/basic.life#1.4). One of the defining characteristics of the very concept of an object is that an object has an identity. In the C++ object model, that means that no two complete objects can have the same address [\[intro.object\]/9](http://eel.is/c++draft/intro.object#9). – Michael Kenzel Jan 03 '19 at 01:36
  • @MichaelKenzel You meant to quote "_The lifetime of an object o of type T ends when: ... (1.4) the storage which the object occupies is released, or is reused by an object that is not nested_"? I see your changed comment now. – curiousguy Jan 03 '19 at 01:36
  • 1
    Yes, sorry, I already noticed that but had to delete my original comment as the time for editing had already passed… – Michael Kenzel Jan 03 '19 at 01:38
  • I am not quite sure I understand that C++ object model, or that anyone does. (The notion of complete object seems esp. bizarre.) Or that serious people take it seriously. Anyway, "The lifetime of an object of type T begins when: (1.1) storage with the proper alignment and size for type T is obtained" implies that raw memory has all objects that don't have a constructor already ready for use, which is obviously needed for **any** C compatibility. (So it's just common sense that you don't need to construct an `int`.) Anyway the "model" is clearly "work in progress". – curiousguy Jan 03 '19 at 01:45
  • If you admit that object lifetime is one of the most central, primitive and essential concept of a programming language, and you notice that the mention of union had to be added extremely late in the definition of lifetime in C++, in various places (also of nested), you can only conclude that it's a trainwreck. – curiousguy Jan 03 '19 at 01:50
  • 4
    I don't understand how a philosophical discussion on the potential merits or lack thereof of the C++ object model is relevant to the question or my answer here. The quote above concerns the lifetime of an object. Before you can talk about the lifetime of an object, you first need an object to talk about. [\[basic.memobj\]/1](http://eel.is/c++draft/basic.memobj#intro.object-1) clearly specifies what language constructs give rise to objects. Just because the C++ standard is not absolutely flawless doesn't mean that nothing can be said about anything and any interpretation is equally valid… – Michael Kenzel Jan 03 '19 at 02:26
  • 1
    "_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_" Exactly what we have now. Or what every other programming language except Fortran I guess. – curiousguy Jan 03 '19 at 20:46
  • @M.M thank you very much for pointing that out! My understanding concerning the concept of dynamic type was indeed incorrect. I believe to have fixed my answer. Would be glad if you could let me know whether you'd agree that it is correct now, or whether there's still something wrong. – Michael Kenzel Jan 04 '19 at 20:02
  • 1
    My understanding is that if the glvalue has type `int` and the object at the designated location type `string`, it's not correct to say that the dynamic type of the glvalue is `string`. The dynamic type of the glvalue is still the same as the static type. The only case where the dynamic type differs from the static type is where the static type is a base class subobject (and there is actually such a base class subobject at the designated location). I admit this is not perfectly clear from defns.dynamic.type but I believe that is the intent, and the definition could have its wording improved – M.M Jan 04 '19 at 22:10
  • `std::byte8`, really? – curiousguy Jan 04 '19 at 22:35
  • @M.M [defns.dynamic.type] defines the dynamic type as the *"type of the most derived object […] to which the glvalue refers"*. The most derived object is specified in [intro.object]/6 as *"If a complete object, a data member, or an array element is of class type, its type is considered the most derived class, […]; an object of a most derived class type or of a non-class type is called a most derived object."* While a bit convoluted, this definition would seem to me not restricted to class types and to effectively mean (simplified): "the type of the object located at that place in memory"!? – Michael Kenzel Jan 04 '19 at 22:39
  • @MichaelKenzel "_[basic.memobj]/1 clearly specifies what language constructs give rise to objects_" It does not. It's probably the most ridiculously out there part of the standard. It's lunar. – curiousguy Jan 04 '19 at 23:17
  • @MichaelKenzel the glvalue doesn't refer to the other object in this case (even though that object is at the same memory location that the glvalue designates) – M.M Jan 05 '19 at 23:44
  • @MichaelKenzel _There can only be one complete object alive in any piece of memory at any given moment._ Indeed, this is the intent of the standard, but the current wording is defective and allows more than one alive complete object starting at the same address. https://groups.google.com/a/isocpp.org/d/msg/std-discussion/GHwA_pOc4CA/RF4qoKgZAAAJ – Language Lawyer Jan 08 '19 at 08:19
2

[basic.lval]/8 says when the behavior will surely be undefined, but this does not necessarily mean that if you do something from the list in [basic.lval]/8 the behavior will be defined.

[basic.lval]/8 hasn't been changed much since C++98 and it has inaccurate wording such as the use of an undefined term "dynamic type of the object". (C++ defines dynamic types for expressions).

Behavior definedness, in case you do something allowed by [basic.lval]/8, depends on other parts of the standard. Even if it might be agreed that the result of signed/unsigned reinterpretation could be derived from wording in [basic.types], I can't imagine how is it possible to predict the result of an access to an object containing references or virtual methods through char glvalue.

C++17's new pointer and glvalue casting rules made [basic.lval]/8 more useless, because now it is not formally possible to achieve the aims [basic.lval]/8 intended to guarantee (for example, to read the bytes in an object through char glvalue). As you pointed out, per [expr.reinterpret.cast]/7, after reinterpret_cast to a reference to T, the resulting glvalue still refers to the object the argument of reinterpret_cast referred to.

Per [conv.lval]/(3.4), the result of the lvalue-to-rvalue conversion is the value contained in the object to which the converted glvalue refers. For example, these rules mean that the result of the lvalue-to-rvalue conversion applied to reinterpret_cast<char&>(i), where i is an int variable, is the value stored in the i int object. The type of the prvalue is char ([conv.lval]/1) and if the value of i is not representable by char, according to [expr]/1 the behavior is undefined. Trying to read an int object through char glvalue will result in UB if the value of the object is not representable by char, even though this access is "allowed" by [basic.lval]/(8.8). This proves what have been said in the first paragraph.

Language Lawyer
  • 3,378
  • 1
  • 12
  • 29
1

A reference built using reinterpret_cast (I include casting a pointer and then dereferencing) can be roundtripped to the original type, if the intermediate types had equal or less stringent alignment requirements.

Most other uses are undefined behavior, due to the strict aliasing rule. (no language citation needed because the question already quotes it)

Notable legal cases where the expression final type does not match the object's dynamic type include aliasing through narrow character types, and the common initial sequence rule for structures.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720