Movatterモバイル変換

[Moved to DR at the February, 2014 meeting.]

Proposed resolution (September, 2013):

Change 7.3.2 [conv.lval] paragraph 2 as follows:

When an lvalue-to-rvalue conversionoccurs in an unevaluatedoperand or a subexpression thereof (Clause 7 [expr])is applied to an expressione, and either

• e is not potentially evaluated, or

• the evaluation ofe results in the evaluation of amemberex of the set of potential results ofe, andex names a variablex that is not odr-used byex (6.3 [basic.def.odr]),

the value contained in the referenced object is not accessed.[Example:

  struct S { int n; };  auto f() {    S x { 1 };    constexpr S y { 2 };    return [&](bool b) { return (b ? y : x).n; };  }  auto g = f();  int m = g(false); // undefined behavior due to access ofx.n outside its lifetime  int n = g(true);  // OK, does not accessy.n

—end example] In all other cases, the resultof the conversion...

Consider an example like the following:

  struct Base {    virtual int call() = 0;  };  Base *foo() {    constexpr int x = 0;    struct Local : Base {      virtual int call() { return x; }    };    static Local local;    return &local;  }  int main() {    return foo()->call();  }

While the likely intention is that the lvalue-to-rvalue conversion ofthe block-scope constant is implemented by using the value of the constantexpression in place of reading from storage, it seems that the wording of7.3.2 [conv.lval] paragraph 2 does not prevent this program frombeing subject to undefined behaviour caused by lifetime violation. Inparticular, it seems that a name expression that appears in apotentially-evaluated expression such that the object named is not odr-used(by that instance of the name) may still be evaluated, in theory, as anlvalue through which the object named or a subobject thereof isaccessed.