CWG2535 [expr.ref] Class member access with "bad" object expression

[languagelawyer]

Full name of submitter (unless configured in github; will be published with the issue): C++ community

Reference (section label): [expr.ref]

Issue description:

struct C { int m; };

int i = 0;
int j = reinterpret_cast<C&>(i).m; // the same as `int j = i` ?

Currently, the standard doesn't clearly say that this has undefined behavior. [expr.ref]/(6.2):

If E2 is a non-static data member and the type of E1 is “cq1 vq1 X”, and the type of E2 is “cq2 vq2 T”, the expression designates the corresponding member subobject of the object designated by the first expression

is not very convincing and also can't always be applied to claim UB (when base classes are involved, there is, in some sense, the corresponding member subobject, except that it is at a «wrong offset»).

Suggested resolution:
From https://lists.isocpp.org/core/2020/02/8431.php:
Append to [expr.ref]/7, after the Note:

Similarly, the behavior is undefined if E2 is a non-static data member or a non-static member function and if the result of E1 is not an object whose type is the type of E1 (ignoring cv-qualifications).

(Maybe, «is a non-static data member or a non-static member function» can be just «is a non-static member»)

[jensmaurer]

CWG2535

[languagelawyer]

@jensmaurer Please use correct suggested resolution. Requiring the dynamic type of E1 to contain E2 doesn't work:

struct A { int i; };
struct B { int j; };
struct D: A, B {};

B b;
reinterpret_cast<D&>(b).B::j;

Dynamic type of reinterpret_cast<D&>(b) is B and it «contains» B::j. However, this code is nonsensical and shall have UB.

([expr.mptr.oper]/4 is likely defective in its «dynamic type» requirement)

[jensmaurer]

We should fix expr.mptr.oper, too, then.

This seems to be a good example:

struct A { int i; };
struct B { int j };
struct D : A, B {};
D d;
static_cast<B&>(d).j;   // ok
reinterpret_cast<B&>(d).j;   // undefined behavior

[jensmaurer]

@languagelawyer , please have another look.

[languagelawyer]

To me,«similar» looks better than «same type (ignoring cv-qualifiers)» (not only here, but in the rest of the standard).

[jensmaurer]

So, happiness all around.