This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 110d. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
[Moved to DR at the April, 2013 meeting.]
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.3.2 [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.
Proposed resolution (October, 2012):
Change 7.3.2 [conv.lval] paragraphs 1 and 2 as follows (including changing the running text of paragraph 2 into bullets):
A glvalue (7.2.1 [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 7 [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.3.12 [conv.ptr]).Otherwise, the value contained in the object indicated by the glvalue is the prvalue result.
Change 22.214.171.124 [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 7.6.4 [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 (7.2.1 [basic.lval]) as its first operand. The result of a .* expression whose second operand is a pointer to a member function...
This resolution also resolves issues 129, 240, 312, 623, and 1013.
(See also issue 1213.)
Additional note (August, 2012):
It was observed that the phrase in the fourth bullet of the change to 7.3.2 [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.