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.
There is, of course, a definitive answer to that: either you have stopped, or you haven't. You cannot exist in a quantum superposition where you are beating your wife while simultaneously hugging her—this is not Schrödinger’s cat.
Given that the C++ standard categorizes operations into well-defined, implementation-defined, unspecified, and undefined behavior, any given operation must necessarily fall into one of these categories. It is just like how biological sex is divided into male and female: a person is either male or female, not both. If an operation cannot be classified into any of these specific buckets, then there is a flaw in the definition itself.
On Thu, Oct 15, 2026, 1:15 AM jim x <xmh970252187@gmail.com> 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.