Talk:cpp/language/reinterpret cast

Where does this extra remark in the Type aliasing section come from: "...this makes it safe to obtain a usable pointer to a struct or union given a pointer to its non-static member or element."?

I can't find it from the standard, and it's used as the rationale in this Stack Overflow answer: https://stackoverflow.com/a/38001005/4029784

khuttun (talk) 11:34, 1 September 2017 (PDT)
 * Standard doesn't generally provide rationales (it's one of the reasons cppreference exists!). I see I added that sentence. I don't recall if there was a discussion that led to that edit, but I think I was combining basic.lval/8.6 with class.mem/25, since class.mem/25 is (the?) one case when casting from member to enclosing class is defined at all. --Cubbi (talk) 13:12, 1 September 2017 (PDT)
 * It's not clear if that rule is even relevant in C++ - see core issue 2051. T. Canens (talk) 15:00, 1 September 2017 (PDT)
 * Is the "Structure and union types also have problematic aliasing properties" C standard rationale relevant when considering whether the aggregate type exception to the aliasing rules should apply in C++?: https://www.lysator.liu.se/c/rat/c3.html#3-3 --khuttun (talk) 01:20, 7 September 2017 (PDT)
 * No. C models structure/union assignment as accessing the whole object, but C++ models it as an assignment operator call. The assignment operator operates on individual members (or for unions, on the object representation), not the entire object as a whole. T. Canens (talk) 17:26, 8 September 2017 (PDT)

Revisiting strict aliasing
As noted above, our current presentation of the strict aliasing rule doesn't appear to be correct: we parrot the standard's meaningless and/or redundant bullets (see core issue 2051 and a somewhat more extended discussion in c++std-core-26491), but then add our own embellishments that actually misinterpret the rule. It doesn't help that a class member access isn't an "access" in the sense of the strict aliasing rule, which is a frequent source of confusion.

Typically UB with reinterpret_cast hackery come from three places:
 * 1) UB in intermediate steps, such as undefined pointer arithmetic performed during the hackery, or performing a class member access on a nonexistent object (which is UB by omission);
 * 2) The resulting abstract pointer value may not point to the object;
 * 3) Strict aliasing violations when the result is used to access the object.

We don't really cover #2, and the note being questioned appears to be a case of trying to lump it into #3. T. Canens (talk) 21:44, 8 September 2017 (PDT)