One of the grounds for your claim that the program exhibits undefined behavior is that you determined it contains a data race based on [intro.race] p17. But the very issue is: where does the standard state that an access to a volatile glvalue is non-atomic? The standard does not even define the semantics of such accesses and leaves them implementation-defined, making it even less possible to assert that accesses to a volatile glvalue are non-atomic. How, then, can you conclude based on [intro.race] that this program contains a data race?
On Saturday, 10 October 2026 03:09:02 Eastern Daylight Time jim x via Std-
Discussion wrote:
> However, saying a program has undefined behaviour could imply the program
> is *unconditionally* undefined behavior; I don't think this is true.
It is true. The behaviour, *according to the Standard*, is undefined.
But machines are deterministic. Once compiled, the program will have *some*
behaviour. Data races and non-atomic accesses may have one of multiple
deterministic behaviours, but which one cannot be determined ahead of time.
That does not change the Standard. The fact that some implementation may define
a specific undefined behaviour to be very specifically determined does not remove
the fact that the Standard still said it was undefined.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Principal Engineer - Intel Data Center - Platform & Sys. Eng.
--
Std-Discussion mailing list
Std-Discussion@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion