[basic.type.qualifier] *const object* definition does not include objects nested within const objects by byte arrays that provide storage

[MitalAshok]

Full name of submitter (unless configured in github; will be published with the issue): Mital Ashok

Reference (section label): [basic.type.qualifier]

Link to reflector thread (if any):

Issue description:

const object is used to define what objects are UB to modify ([dcl.type.cv]p4). The current definition only mentions subobjects of another const object, but when a byte array provides storage ([intro.object]p3) for another object, it is not a subobject. However, it should still be UB to modify.

For example, this program appears to be well defined:

struct X {
    X() {
        p = new (storage) int(7);
    }
    alignas(int) std::byte storage[sizeof(int)];
    int* p;
};

int main() {
    const X x;
    *x.p = 0;
    return *x.p;
}

Since the int object created by the new-expression is of type int and is not a subobject ([intro.object]p3 explicitly says it's a complete object), it is not a const object, so [dcl.type.cv]p4 does not make this modification undefined behaviour.

Also consider const arrays providing storage for objects with mutable subobjects:

struct A {
    mutable int i;
};

struct X {
    X() {
        new (storage) A{ 7 };
    }
    alignas(A) std::byte storage[sizeof(A)];
};

int main() {
    const X x;
    const A* p = std::launder(reinterpret_cast<const A*>(x.storage));
    p->i = 0;
    return p->i;
}

Suggested resolution:

Modify [basic.type.qualifier]p(1.1) as follows:

A const object is an object of type const T or a non-mutable subobject of a const object or a non-mutable subobject of a const object or an object where there exists a const object that provides storage for the complete object ([intro.object]p5) of that object.

Similarly modify [basic.type.qualifiers]p(1.2) as follows:

A volatile object is an object of type volatile T or a subobject of a volatile object or an object where there exists a volatile object that provides storage for the complete object of that object.

And similarly modify [basic.type.qualifier]p(1.3) as follows:

A const volatile object is

• an object of type const volatile T,
• a non-mutable subobject of a const volatile object,
• a const subobject of a volatile object, or
• a non-mutable volatile subobject of a const object,
• an object where there exists a const volatile object that provides storage for the complete object of that object,
• a const object where there exists a volatile object that provides storage for the complete object of that object, or
• a volatile object where there exists a const object that provides storage for the complete object of that object.

It also might be possible to write it as:

A const volatile object is an object that is both a const object and a volatile objectof type const volatile T, a non-mutable subobject of a const volatile object, a const subobject of a volatile object, or a non-mutable volatile subobject of a const object.

---

Related discussion: LWG3870, CWG2514

[t3nsor]

First of all, it's very strange for "const object" to mean anything other than "object whose type is const-qualified". I think we should simply define const object accordingly (and, perhaps, at a later time, editorially replace all references to "const object"). CWG3051 is relevant.

I don't think that an object whose storage is provided by a const object should actually itself be implicitly given a const-qualified type, so I don't think that it should be a const object. Instead, we should try to clarify that an access to an object is also an access (of the same kind) to any object of cv unsigned char or cv std::byte type that occupies part of that object's storage.

[MitalAshok]

I was under the impression that "const object" means "object for which const semantics apply" ([dcl.type.cv]p4, "Any attempt to modify a const object during its lifetime results in undefined behavior"), which should include "objects nested within const byte arrays". And without CWG3051 clarifying, member/base class subobjects don't gain the cv-qualifications of their containing objects, which seems to be why the current definition is 'const T or non-mutable subobject of a different const object'.

Also, the similar wording for volatile does not use "volatile object", it instead says "object defined with volatile-qualified type" ([dcl.type.cv]p5). So currently it seems like const_casting away volatile from subobjects of volatile class type objects doesn't actually result in UB, and that [class.mem.general] Note 10 is wrong. This would also be fixed by CWG3051.

[frederick-vs-ja]

Looks like that there's an adjacent issue. Currently, we don't say an array of a cv-qualified type can provide storage. And in this case, the array was initially of a cv-unqualified type during construction of the class object, but its type is considered to become const when the construction is completed.

It would be weird to consider to array to stop providing storage at the completion of construction.

[languagelawyer]

the array was initially of a cv-unqualified type during construction of the class object

Was it?

[frederick-vs-ja]

the array was initially of a cv-unqualified type during construction of the class object

Was it?

IIUC it was, per [class.ctor.general] p4.

[languagelawyer]

I've thought objects are created of their declared types (ignoring NRVO issues), and, even though X and const X are different types, const X NSDM types are the same as X ones