Movatterモバイル変換

[Moved to DR at the April, 2013 meeting.]

Additional note (August, 2012):

It was observed that the phrase in thefourth bullet of the change to 7.3.2 [conv.lval] paragraph 2that reads “is not a local variable” should probablybe changed to “does not have automatic storageduration,” because objects with static storage duration arezero-initialized and thus cannot have an indeterminate value. Theissue was returned to "review" status for discussion of this point.

Proposed resolution (October, 2012):

1. Change 7.3.2 [conv.lval] paragraphs 1 and 2 asfollows (including changing the running text of paragraph 2 intobullets):

A glvalue (7.2.1 [basic.lval]) of a non-function, non-arraytypeT can be converted to a prvalue.⁵³ IfT is an incomplete type, a program that necessitates thisconversion is ill-formed.If the object to which the glvaluerefers is not an object of typeT and is not an object of atype derived fromT, or if the object is uninitialized, aprogram that necessitates this conversion has undefinedbehavior. IfT is a non-class type, the type of theprvalue is the cv-unqualified version ofT. Otherwise, thetype of the prvalue isT.⁵⁴

When an lvalue-to-rvalue conversion occurs in an unevaluatedoperand or a subexpression thereof (Clause 7 [expr]) thevalue contained in the referenced object is not accessed.In allother cases, the result of the conversion is determined accordingto the following rules:

• IfT is (possibly cv-qualified)std::nullptr_t, the result is a null pointer constant(7.3.12 [conv.ptr]).

• Otherwise, ifthe glvalueT hasa class type, the conversion copy-initializes a temporary of typeT from the glvalue and the result of the conversion is aprvalue for the temporary.

• Otherwise, if the object to which the glvalue refers containsan invalid pointer value (6.8.6.5.3 [basic.stc.dynamic.deallocation],_N4885_6.7.5.5.4 [basic.stc.dynamic.safety]), the behavior isimplementation-defined.

• Otherwise, ifT is a (possibly cv-qualified)unsigned character type (6.9.2 [basic.fundamental]), and the objectto which the glvalue refers contains an indeterminate value(7.6.2.8 [expr.new], 9.5 [dcl.init], 11.9.3 [class.base.init]), and that object does not have automatic storageduration or the glvalue was the operand of a unary&operator or it was bound to a reference, the result is an unspecifiedvalue. [Footnote: The value may be different each time thelvalue-to-rvalue conversion is applied to the object. Anunsignedchar object with indeterminate value allocated to a registermight trap. —end footnote]

• Otherwise, if the object to which the glvalue refers containsan indeterminate value, the behavior is undefined.

• Otherwise, if the glvaluehas (possibly cv-qualified) typestd::nullptr_t, the prvalueresult is a null pointer constant (7.3.12 [conv.ptr]).Otherwise, the value contained in the object indicated by the glvalueis the prvalue result.

2. Change 7.6.1.5 [expr.ref] paragraph 4 second bullet asfollows:

• IfE2 is a static data member...

• ...IfE1 is an lvalue, thenE1.E2 is anlvalue;ifE1 is an xvalue, thenotherwiseE1.E2 is an xvalue; otherwise, it is aprvalue. Let the notation...

• IfE2 is a (possibly overloaded) memberfunction...

3. Change 7.6.4 [expr.mptr.oper] paragraph 6 as follows:

...The result of a.* expression whose second operand is apointer to a data member isof the same value category(7.2.1 [basic.lval]) as its first operandan lvalueif the first operand is an lvalue and an xvalue otherwise. Theresult of a.* expression whose second operand is a pointerto a member function...

This resolution also resolves issues129,240,312,623, and1013.

(See alsoissue 1213.)

The C++ Standard uses the phrase “indeterminate value”without defining it. C99 defines it as “either an unspecifiedvalue or a trap representation.” Should C++ follow suit?

In addition, 7.3.2 [conv.lval] paragraph 1 says thatapplying the lvalue-to-rvalue conversion to an “object[that] is uninitialized” results in undefined behavior;this should be rephrased in terms of an object with anindeterminate value.