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)

[edit] 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)

[edit] Accessing the object representation

// type aliasing through pointer
    char* p2 = reinterpret_cast<char*>(&i);
    std::cout << (p2[0] == '\x7' ? "This system is little-endian\n"
                                 : "This system is big-endian\n");

i is an int that is being accessed through a pointer to char. Per the strict alliasing rule, this is fine. However, p1839 says that when this pointer is derefernced the value of the expression should be the value of the whole int object. Unlike the example from the paper, this is not UB, because the value of the int in our example (7) is representable by char, however, that still means this technique does not determine endianness since accessing the pointer always yields 7. Can the example be amended to fix this in some way? If not, should we remove it, considering the fact that there is no way any sane implementation breaks it?--172.68.62.34 01:24, 25 June 2023 (PDT)

the paper describes a wording defect and reasserts that both the intent and practice is for such code to work as written. --Cubbi (talk) 20:17, 25 June 2023 (PDT)