CWG2957 [intro.memory] References should be memory locations

[Eisenwave]

Reference (section label): [intro.memory]

Issue description

int x, y;
struct awoo_t {
    int *p, &r;
} awoo{&x, x};

void thread_w() {
    new (&awoo) awoo{&y, y}; // transparent replacement
}

void thread_p() {
    auto p = awoo.p; // data race
}

void thread_r() {
    auto& r = awoo.r; // OK ?! refer to x or y?
}

Assuming that thread_w(), thread_p(), and thread_r() are executed concurrently, thread_r has well-defined behavior despite binding a reference to a glvalue which changes the identity that it determines concurrently.

Paradoxically (and unlike thread_p(), in which a data race occurs), this is well-defined because a memory location is

• currently, "an object of scalar type", or
• after the current resolution of CWG1953, "the storage occupied by the object representation of an object of scalar type".

Therefore, storage occupied by references (which is possible; see [dcl.ref] p4) is immune from data races, but it should not be.

Suggested resolution

This resolution is relative to CWG1953, 2024-10-25.

Update [intro.memory], paragraph 3 as follows:

A memory location is the storage occupied by the object representation of either

• an object of scalar type that is not a bit-field, or
• a maximal sequence of adjacent bit-fields all having nonzero width., or
• an object in which a reference is nested.

[jensmaurer]

Looks like this is very much related to #634, which highlights that we also need to refine the notion of "access" to cover the situation.

[Eisenwave]

Oh yeah, it seems pretty much identical to #634 then.

[t3nsor]

CWG decided yesterday that this will be split off into a separate issue.

[jensmaurer]

CWG2957

[languagelawyer]

thread_r has well-defined behavior

[basic.life]/4: The properties ascribed to objects and references throughout this document apply for a given object or reference only during its lifetime.

This needs to be clarified (maybe even editorially) that «during lifetime» == «after lifetime starts»+«before lifetime ends», where «before» and «after» in the subclause has known meaning http://eel.is/c++draft/basic.life#12

So, thread_r has undefined behavior since there is no happen-before relation between thread_r and thread_w. The same is true for thread_p. No change to the definition of memory location is required.

[frederick-vs-ja]

This needs to be clarified (maybe even editorially) that «during lifetime» == «after lifetime starts»+«before lifetime ends», where «before» and «after» in the subclause has known meaning http://eel.is/c++draft/basic.life#12

This part is addressed by CWG2863. I'd use memcpy ([basic.types.general] p3) to avoid the issues with reconstruction.