[intro.races] p2 Whether an opaque type reads the same memory location is unclear

[xmh0511]

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

[intro.races] p2 says:

Two expression evaluations conflict if one of them

• 2.1 modifies ([defns.access]) a memory location ([intro.memory]) or
• 2.2 starts or ends the lifetime of an object in a memory location

and the other one

• 2.3 reads or modifies the same memory location or
• 2.4 starts or ends the lifetime of an object occupying storage that overlaps with the memory location.

The definition of a memory location is

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.

Consider this example:

#include <string>
#include <thread>

alignas(std::string) unsigned char buffer[sizeof(std::string)];
auto ptr = new (buffer) std::string{};

int main() {    
    std::jthread t1([]() {
        new (buffer) char{};  // #1
    });
    std::jthread t2([]() {
        auto r = ptr->size();  // #2
    });
}

In this example, #1 is an evaluation that starts the lifetime of an object in a memory location called L. #2 is an evaluation that reads the string object. In [intro.races] p2, only bullet 2.3 mentions reading a memory location, that is, only 2.3 can apply to #2, therefore, 2.2 applies to #1.

However, std::string is a type whose private members are opaque. We don't know whether a std::string object comprises a scalar member object in the memory location L, such that the read to std::string will read the scalar object, which will conflict with #1.

In addition, consider another example:

#include <thread>

alignas(int) unsigned char buffer[8];

int main() {
    auto ptr = new (buffer) int{};
    std::jthread t1([&]() {
        new (buffer) char{};  // #1
    });
    std::jthread t2([&]() {
        auto n = *ptr;  // #2
    });
}

Similarly, only 2.3 can apply to #2; #1 starts the lifetime of an object of type char in memory location L. However, the size of the object of type int is larger than int. In this case, can we say that reading a larger memory location reads the same memory location as L?

Suggested Resolution:

Change 2.3 bullet to

reads or modifies a memory location that overlaps with the above-mentioned memory location or

[t3nsor]

However, std::string is a type whose private members are opaque. We don't know whether a std::string object comprises a scalar member object in the memory location L, such that the read to std::string will read the scalar object, which will conflict with #1.

So what?

[xmh0511]

However, std::string is a type whose private members are opaque. We don't know whether a std::string object comprises a scalar member object in the memory location L, such that the read to std::string will read the scalar object, which will conflict with #1.

So what?

So, it's unclear to reason about whether the program comprises a data race or not.

[t3nsor]

However, std::string is a type whose private members are opaque. We don't know whether a std::string object comprises a scalar member object in the memory location L, such that the read to std::string will read the scalar object, which will conflict with #1.

So what?

So, it's unclear to reason about whether the program comprises a data race or not.

The standard is not required to make it possible for the user to reason about the behavior of a program if the user has chosen to write the program in a way that depends on unspecified implementation details.

[frederick-vs-ja]

Evaluation of u.s doesn't contain access, so there won't be data race, IIUC. If you concurrently call any member function on u.s, the behavior should be considered undefined because u.s shouldn't be in its lifetime. Although the current wording isn't clear for this, see CWG2863.

[xmh0511]

If you concurrently call any member function on u.s, the behavior should be considered undefined because u.s shouldn't be in its lifetime. Although the current wording isn't clear for this, see CWG2863.

Even with CWG2863, we cannot say #2 is in a storage-only phase of that string object.

The first bullet:

E happens after the storage which O will occupy is allocated and E does not happen after the lifetime of O starts; or

#2 happens after the storage is allocated, and #2 happens after the initialization of the string object at #0. So, this bullet is not applicable.

For the second bullet:

E does not happen before the lifetime of O ends and E happens before the storage which O occupied is reused or released.

Because #1 and #2 are concurrent, "E does not happen before the lifetime of O ends" is true; however, "E happens before the storage which O occupied is reused or released" is false. Similarly, this bullet is not applicable.

IIUC, evaluation #2 is not in a storage-only phase of that string object.

[xmh0511]

The standard is not required to make it possible for the user to reason about the behavior of a program if the user has chosen to write the program in a way that depends on unspecified implementation details.

Well, consider the second example in the issue. The memory location corresponding to the object created at #1 has 1 byte, and the memory location corresponding to the int object created at #0 has more than 1 byte. The memory locations with different sizes, reasonably, cannot be said to be the same memory location. IIUC, the bullet still cannot apply to the case.

[safocl]

Even without the race, such code would contradict the general criteria for using memory locations and pointers (references) and observing object lifetimes.
[intro.object#3]
[basic.life#7]
[basic.life#8]

[frederick-vs-ja]

For the second bullet:

E does not happen before the lifetime of O ends and E happens before the storage which O occupied is reused or released.

Because #1 and #2 are concurrent, "E does not happen before the lifetime of O ends" is true; however, "E happens before the storage which O occupied is reused or released" is false. Similarly, this bullet is not applicable.

This seems to be a bug in the currently proposed resolution. Maybe we should strike "reused or".

It also seems problematic to have "reused or" in current [basic.life] p7 and [basic.life] p8. The current wording seemingly indicates that if the storage of some object is reused by an unrelated new object, it's not allowed to even evaluate the glvalue designating it. There is possibly implicit UB or incompleteness of specification.

[safocl]

This seems to be a bug in the currently proposed resolution. Maybe we should strike "reused or".

It also seems problematic to have "reused or" in current [basic.life] p7 and [basic.life] p8.

but here the Standard clearly distinguishes between two different cases — when storage was reused, and when storage was released:

alignas(int) unsigned char buffer[8];

int main() {
    auto ptr_int = new (buffer) int{};
    auto ptr_char = new (buffer) char{}; // #1 storage for `int` was reused
    auto storage_ptr = new (&buffer) unsigned char[8]; // #2 storage for `char` was released
}

[jensmaurer]

My understanding is that "storage release" means calling operator delete or free or exiting a function (for storage associated with automatic variables).

[safocl]

My understanding is that "storage release" means calling operator delete or free or exiting a function (for storage associated with automatic variables).

In my example above, do you think #2 is a reuse of storage?
From my perspective, the storage itself was recreated here (released and created new array).

[languagelawyer]

@safocl array object is not storage. You ended prev. object lifetime, it is not «release»

[safocl]

@safocl array object is not storage

I will allow myself to disagree here because:
[intro.object#3]

3 If a complete object is created ([expr.new]) in storage associated with another object e of type “array of N unsigned char” or of type “array of N std​::​byte” ([cstddef.syn]), that array provides storage for the created object if
(3.1) the lifetime of e has begun and not ended, and
(3.2) the storage for the new object fits entirely within e, and
(3.3) there is no array object that satisfies these constraints nested within e.

[Note 3: If that portion of the array previously provided storage for another object, the lifetime of that object ends because its storage was reused ([basic.life]).
— end note]
[Example 1: // assumes that sizeof(int) is equal to 4

struct AlignedUnion {
  alignas(T...) unsigned char data[max(sizeof(T)...)];
};
int f() {
  AlignedUnion<int, char> au;
  int *p = new (au.data) int;           // OK, au.data provides storage
  char *c = new (au.data) char();       // OK, ends lifetime of *p
  char *d = new (au.data + 1) char();
  return *c + *d;                       // OK
}

struct A { unsigned char a[32]; };
struct B { unsigned char b[16]; };
alignas(int) A a;
B *b = new (a.a + 8) B;                 // a.a provides storage for *b
int *p = new (b->b + 4) int;            // b->b provides storage for *p
                                        // a.a does not provide storage for *p (directly),
                                        // but *p is nested within a (see below)

— end example]

[languagelawyer]

@safocl not sure what do you want to say by that quote. From it, it is pretty clear that objects are created in storage, storage is associated with objects, not that array objects == storage

[safocl]

@safocl not sure what do you want to say by that quote. From it, it is pretty clear that objects are created in storage, storage is associated with objects, not that array objects == storage

“array of N unsigned char” or of type “array of N std​::​byte” provides storage for the created object