On Thu, Oct 15, 2026, 1:15 AM jim x <xmh970252187_at_[hidden]> wrote:

> But my question isn't about implementation conformance; that is, I didn't
> ask whether a conforming implementation can specify a concrete behavior for
> the undefined behavior program; of course, it can. I'm asking what the
> program's behavior should be, given the current wording, within the scope
> the standard leaves to implementations to define the semantics of access.
> In other words, since the premise based on which we say the program is
> undefined is that the program contains a data race as per [intro.race] p17,
> which depends on whether the condition "at least one of which is not
> atomic" is true, the current wording is unclear about whether the
> operations at `#1` and `#2` are non-atomic even if the implementations
> define the semantics as being equivalent to
> `std::atomic_ref::load()/store()`.
>

The behavior of the program in the hypothetical implementation is clear,
though. You are not asking any concrete question about the behavior. You're
asking whether it falls into the category of "undefined behavior" or
"implementation-defined behavior" and this is the flaw in your question.
These terms come from the standard, so they have no meaning outside of
specifying implementation compliance. Your insistence on the standard
providing you with a categorization is frustrating. It feels like you're
asking "have you stopped beating your wife yet, yes or no?" and repeatedly
refusing to accept that the question is not answerable in that form.

In terms of the concrete behavior, I believe it's clear for the following
reason. First, let me introduce new terms: "bounded" and "unbounded". An
execution of a program on an implementation has "unbounded" behavior if the
program can crash, launch missiles, or otherwise exhibit any behavior that
is possible for an executable under the implementation's operating system
and hardware. An execution of a program on an implementation is "bounded"
if it is not unbounded. Now, if a hypothetical implementation documents
that volatile accesses behave as if they are accesses through `atomic_ref`,
what is the documentation trying to tell us? Is the behavior of your
program bounded or unbounded? It is obviously bounded---the program will
behave the same as if either #1 or #2 happened before the other, and
exhibit no observable behavior besides the two volatile accesses---because
boundedness of potentially concurrent conflicting operations is the
quintessential property of atomic operations. So, it would be bizarre and
extremely misleading if the implementors were to document that volatile
accesses behave like `atomic_ref` accesses if they did not mean that the
behavior of a program like this one is bounded. That would be like claiming
to be a married bachelor.