cplusplus / CWG

Core Working Group
23 stars 7 forks source link

[expr.unary.op] The resolution of C DR076 should also apply to C++ and be extended to cover `typeid` expressions #464

Closed frederick-vs-ja closed 8 months ago

frederick-vs-ja commented 8 months ago

Full name of submitter (unless configured in github; will be published with the issue): Jiang An

Reference (section label): [expr.unary.op], [expr.sub], [expr.typeid]

Link to reflector thread (if any):

Issue description:

WG14 N721 (the resolution of C DR076) made the following example well-defined:

int a[10], *p;
for (p = &a[0]; p < &a[10]; p++)
    /* ... */

In this example, the built-in operator[] in a[10] are not actually evaluated because of the outer &. However, this is not yet true when the code snippet is treated as C++, and there may still be UB when evaluating a[10] (see CWG2823).

Given CWG232 is closed as NAD, perhaps we should just adapt the resolution in C (not to evaluate built-in operator*/operator[] in certain cases) to resolve such incompatibility. Morever, it seems that type built-in operator* should not be evaluated in the exceptional case specified in [expr.id] p3.

Suggested resolution:

t3nsor commented 8 months ago

CWG1954 covers the typeid case.

I do not think CWG is interested in adopting the rule from C.

It was pointed out to me once that in C++, if we adopted the rule from C for raw pointers, we introduce an inconsistency in which smart pointers are unable to replicate this behavior, because operator* returns a reference, and it is UB to attempt to create a null reference, even though it might immediately be consumed by the address-of operator.

jensmaurer commented 8 months ago

If someone wants to have the C rule in C++, please write a paper targeted at EWG.

Given that we closed CWG232 as NAD and had great struggles with the typeid odditiy in CWG1954, I'm not seeing any consensus to introduce such a rule as a core issue.