On October 10, 2026 6:06:41 AM jim x <xmh970252187_at_[hidden]> wrote:

> I didn't say the standard defined the undefined behavior in this way.
> Undefined behavior is defined as:
>
> behavior for which this document imposes no requirements
>
>
> The standard explicitly specifies which operations cause the program to
> have undefined behavior in its document.

Behavior that is not described in the standard is also undefined. The
standard explicitly acknowledges some cases as UB to ensure that no
behavior requirements are implied.

> The crux is that you think this
> program in this question has undefined behavior because the program
> contains a data race, and whether a program contains a data race is stated
> by [intro.race] p17, then we focus on the condition that *"at least one of
> which is not atomic". *This is the key point I asked in this question: why
> the semantics that are defined as equivalent to
> `std::atomic_ref::load()/store()` are still not considered as atomic from
> the perspective of the C++ standard under [intro.race] p17? In other
> words, why do you think such defined semantics still satisfy the condition *"at
> least one of which is not atomic"* such that the program is stated to
> contain a data race? Can you explain this point?

Your original program didn't contain any atomic operations and concurrently
read and wrote to a shared object, so the program did exhibit a data race
and UB.

You only brought up atomics as one possible implementation of volatiles.
And to that the response is that the standard doesn't make that
requirement, and still considers your program UB.