Created on 2007-02-02.00:00:00 last changed 75 months ago
[Moved to DR at the April, 2013 meeting.]
Additional note (August, 2012):
It was observed that the phrase in the fourth bullet of the change to 7.1 [conv.lval] paragraph 2 that reads “is not a local variable” should probably be changed to “does not have automatic storage duration,” because objects with static storage duration are zero-initialized and thus cannot have an indeterminate value. The issue was returned to "review" status for discussion of this point.
Proposed resolution (October, 2012):
Change 7.1 [conv.lval] paragraphs 1 and 2 as follows (including changing the running text of paragraph 2 into bullets):
A glvalue (6.10 [basic.lval]) of a non-function, non-array type T can be converted to a prvalue.53 If T is an incomplete type, a program that necessitates this conversion is ill-formed.
If the object to which the glvalue refers is not an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program that necessitates this conversion has undefined behavior.If T is a non-class type, the type of the prvalue is the cv-unqualified version of T. Otherwise, the type of the prvalue is T.54
When an lvalue-to-rvalue conversion occurs in an unevaluated operand or a subexpression thereof (Clause 8 [expr]) the value contained in the referenced object is not accessed.
the glvaluehas a class type, the conversion copy-initializes a temporary of type T from the glvalue and the result of the conversion is a prvalue for the temporary.
Otherwise, if the glvalue has (possibly cv-qualified) type std::nullptr_t, the prvalue result is a null pointer constant (7.11 [conv.ptr]).Otherwise, the value contained in the object indicated by the glvalue is the prvalue result.
Change 8.2.5 [expr.ref] paragraph 4 second bullet as follows:
If E2 is a static data member...
...If E1 is an lvalue, then E1.E2 is an
if E1 is an xvalue, then
E1.E2 is an xvalue ; otherwise, it is a
prvalue. Let the notation...
If E2 is a (possibly overloaded) member function...
Change 8.5 [expr.mptr.oper] paragraph 6 as follows:
...The result of a .* expression whose second operand is a pointer to a data member is
of the same value category (6.10 [basic.lval]) as its first operand. The result of a .* expression whose second operand is a pointer to a member function...
(See also issue 1213.)
The C++ Standard uses the phrase “indeterminate value” without defining it. C99 defines it as “either an unspecified value or a trap representation.” Should C++ follow suit?
In addition, 7.1 [conv.lval] paragraph 1 says that applying 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 an indeterminate value.
|2014-03-03 00:00:00||admin||set||status: drwp -> cd3|
|2013-10-14 00:00:00||admin||set||status: dr -> drwp|
|2013-05-03 00:00:00||admin||set||messages: + msg4364|
|2013-05-03 00:00:00||admin||set||status: ready -> dr|
|2012-11-03 00:00:00||admin||set||status: review -> ready|
|2012-09-24 00:00:00||admin||set||messages: + msg3887|
|2012-09-24 00:00:00||admin||set||status: ready -> review|
|2012-02-27 00:00:00||admin||set||status: review -> ready|
|2011-09-06 00:00:00||admin||set||messages: + msg3496|
|2011-09-06 00:00:00||admin||set||status: open -> review|