Title
Aliasing and qualification conversions
Status
cd1
Section
7.2.1 [basic.lval]
Submitter
Mike Stump

Created on 1999-08-20.00:00:00 last changed 196 months ago

Messages

Date: 2002-04-15.00:00:00

[Moved to DR at 4/02 meeting.]

Date: 2001-04-15.00:00:00

Proposed resolution (04/01):

Add a new bullet to 7.2.1 [basic.lval] paragraph 15, following "a cv-qualified version of the dynamic type of the object:"

  • A type similar (as defined in 7.3.6 [conv.qual]) to the dynamic type of the object,
Date: 2000-11-18.00:00:00

7.2.1 [basic.lval] paragraph 15 lists the types via which an lvalue can be used to access the stored value of an object; using an lvalue type that is not listed results in undefined behavior. It is permitted to add cv-qualification to the actual type of the object in this access, but only at the top level of the type ("a cv-qualified version of the dynamic type of the object").

However, 7.3.6 [conv.qual] paragraph 4 permits a "conversion [to] add cv-qualifiers at levels other than the first in multi-level pointers." The combination of these two rules allows creation of pointers that cannot be dereferenced without causing undefined behavior. For instance:

    int* jp;
    const int * const * p1 = &jp;
    *p1;    // undefined behavior!

The reason that *p1 results in undefined behavior is that the type of the lvalue is const int * const", which is not "a cv-qualified version of" int*.

Since the conversion is permitted, we must give it defined semantics, hence we need to fix the wording in 7.2.1 [basic.lval] to include all possible conversions of the type via 7.3.6 [conv.qual].

History
Date User Action Args
2008-10-05 00:00:00adminsetstatus: wp -> cd1
2003-04-25 00:00:00adminsetstatus: dr -> wp
2002-05-10 00:00:00adminsetmessages: + msg664
2002-05-10 00:00:00adminsetstatus: ready -> dr
2001-11-09 00:00:00adminsetstatus: review -> ready
2001-05-20 00:00:00adminsetmessages: + msg484
2001-05-20 00:00:00adminsetstatus: open -> review
1999-08-20 00:00:00admincreate