You really didn't get the point of that...

On Fri, Oct 16, 2026 at 2:26 AM jim x via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> 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.
>
I've never beat my wife - did I stop? Either way implies I had beat her in
the first place.

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.
>>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>