Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CWG2957 [expr.ref] Evaluating a non-static reference member is not access #634

Open
frederick-vs-ja opened this issue Nov 6, 2024 · 4 comments

Comments

@frederick-vs-ja
Copy link

frederick-vs-ja commented Nov 6, 2024

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

Reference (section label): [expr.ref], [intro.memory]

Link to reflector thread (if any):

Issue description:

Currently, the following example is rejected by some implementation, because they think volatile reading is performed (Godbolt link).

int n{};
struct S { int& r; };
constexpr S s{n};
constexpr volatile S s2{n};

static_assert(&static_cast<const volatile S&>(s).r == &n); // GCC rejects this
static_assert(&s2.r == &n); // GCC and Clang reject this

However, the standard wording doesn't ever seem to consider s or s2 to be accessed. It's unclear whether this is intended.

Also, assuming f1 and f2 are concurrently executed in different threads in the following example.

struct S { int& r; }; // Note that S is trivially copyable and thus memcpy/memmove calls can be well-defined.

S s{/* ... */};

void f1() {
  int* p = &s.r;
  // operations unrelated to s
}

void f2(const S& s2) {
  std::memcpy(&s, &s2, sizeof(S));
}

It seems that there can't be data race (in the standard meaning) due to the current specification because s is not considered accessed in f1. But presumably there should be UB due to data race.

A note in [intro.memory] suggests that this falls into the "additional memory location" case. However, the current specification doesn't seem to allow such additional memory location to be observable or accessed.

Suggested resolution:

@jensmaurer
Copy link
Member

C++ does not acknowledge that references are kept in storage, and that's causing unspecified vacuum in some places.

@t3nsor
Copy link

t3nsor commented Nov 8, 2024

We don't allow reading the value of even a constexpr volatile int in a constant expression, so presumably it is intended that &s2.r == &n (for example) is not a constant expression.

@jensmaurer
Copy link
Member

I think CWG1953 will help the second case, because we're redefining "memory location" as the storage of the object representation.

@jensmaurer
Copy link
Member

CWG2957

@jensmaurer jensmaurer changed the title [expr.ref] Evaluating a non-static reference member is not access CWG2957 [expr.ref] Evaluating a non-static reference member is not access Nov 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants