On 16/10/2026 11:25, jim x via Std-Discussion 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.

This is complete nonsense. Questions don't have to have definitive
answers, even if the question is posed to expect a yes/no answer. "Is
imagination green, rather than a different colour?" That is correct
grammar, with a clear interpretation, and no definitive answer. When
questions are asked in English, you might call it a false dilemma, or
loaded question, or "not even wrong". When it is in a computer
language, it is "undefined behaviour" - there is /no/ definitive answer
to "INT_MAX + INT_MAX", so it is undefined behaviour. In maths, it is
also "undefined" - "which real number is the square root of -1?" or
"what is 0 / 0?" has no defined answer.

You are desperately trying to get fixed, definite answers to questions
that do not have an answer. You need to understand that this is also a
possibility. Don't ask "how do we define this?" until you have first
asked "/Can/ we define this?".

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

I don't think that is true.

> If an operation cannot be classified
> into any of these specific buckets, then there is a flaw in the
> definition itself.

I don't think that is true.

No formal system is ever going to be powerful enough to be useful, and
also consistent and able to answer every question you want - that is the
result of Gödel's incompleteness theorem in mathematics, and it holds
true in computer languages too. And C++ is very far from being a formal
system or being rigorously defined, so this applies ever more so here.

And even if it /were/ true, you are talking about something else. You
are talking about the behaviour of a specific program with a specific
implementation - the C++ standards talk about behaviour defined by the
language and standard library on an abstract machine. These are not
necessarily the same.

(And yes, the C++ standards are flawed - new standard versions not only
introduce new features, but refine the wording and definitions of
existing features. Feel free to write proposals for wording change that
can improve the standards.)

You have spend a long time trying to ask certain questions, and people
who know a lot about the C++ standards have told you there is no answer
in the way you want. Live with that, and move on.

David



>
>
> On Thu, Oct 15, 2026 at 10:42 PM Brian Bi <bbi5291_at_[hidden]
> <mailto:bbi5291_at_[hidden]>> wrote:
>
> On Thu, Oct 15, 2026, 1:15 AM jim x <xmh970252187_at_[hidden]
> <mailto: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.
>
>