>
> 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 at 10:42 PM Brian Bi <bbi5291_at_[hidden]> wrote:

> 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.
>