Date: 2013-04-15.00:00:00

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

Date: 2012-02-15.00:00:00

Proposed resolution (February, 2012):

This issue is resolved by the resolution of issue 616.

Date: 2008-05-15.00:00:00

Additional note (May, 2008):

The C committee is dealing with a similar issue in their DR338. According to this analysis, they plan to take almost the opposite approach to the one described above by augmenting the description of their version of the lvalue-to-rvalue conversion. The CWG did not consider that access to an unsigned char might still trap if it is allocated in a register and needs to reevaluate the proposed resolution in that light. See also issue 129.

Date: 2006-11-15.00:00:00

Proposed Resolution (November, 2006):

1. Add the indicated words to 6.9 [basic.types] paragraph 4:

   ... For trivial types, the value representation is a set of bits in the object representation that determines a value, which is one discrete element of an implementation-defined set of values. Any use of an indeterminate value (7.6.2.8 [expr.new], 9.5 [dcl.init], 11.9.3 [class.base.init]) of a type other than unsigned char results in undefined behavior.

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

   If the object to which the lvalue 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.

Date: 2026-07-27.15:54:01

7.3.2 [conv.lval] paragraph 1 says,

If the object to which the lvalue 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.

I think there are at least three related issues around this specification:

1. Presumably assigning a valid value to an uninitialized object allows it to participate in the lvalue-to-rvalue conversion without undefined behavior (otherwise the number of programs with defined behavior would be vanishingly small :-). However, the wording here just says "uninitialized" and doesn't mention assignment.

2. There's no exception made for unsigned char types. The wording in 6.9.3 [basic.fundamental] was carefully crafted to allow use of unsigned char to access uninitialized data so that memcpy and such could be written in C++ without undefined behavior, but this statement undermines that intent.

3. It's possible to get an uninitialized rvalue without invoking the lvalue-to-rvalue conversion. For instance:

           struct A {
               int i;
               A() { } // no init of A::i
           };
           int j = A().i;  // uninitialized rvalue
   

   There doesn't appear to be anything in the current IS wording that says that this is undefined behavior. My guess is that we thought that in placing the restriction on use of uninitialized objects in the lvalue-to-rvalue conversion we were catching all possible cases, but we missed this one.

In light of the above, I think the discussion of uninitialized objects ought to be removed from 7.3.2 [conv.lval] paragraph 1. Instead, something like the following ought to be added to 6.9 [basic.types] paragraph 4 (which is where the concept of "value" is introduced):

Any use of an indeterminate value (7.6.2.8 [expr.new], 9.5 [dcl.init], 11.9.3 [class.base.init]) of any type other than char or unsigned char results in undefined behavior.

John Max Skaller:

A().i had better be an lvalue; the rules are wrong. Accessing a member of a structure requires it be converted to an lvalue, the above calculation is 'as if':

    struct A {
        int i;
        A *get() { return this; }
    };
    int j = (*A().get()).i;

and you can see the bracketed expression is an lvalue.

A consequence is:

    int &j= A().i; // OK, even if the temporary evaporates

j now refers to a 'destroyed' value. Any use of j is an error. But the binding at the time is valid.