On Tue, Feb 23, 2021 at 1:12 PM Henry Miller via SG14 <sg14_at_[hidden]>
wrote:

> On Mon, Feb 22, 2021, at 16:28, Paul M. Bendixen via SG14 wrote:
>
> If anyone can come up with a formulation of the "We don't know what we are
> getting.If it is possible to get atomicity we would love it, but we know
> that is rarely the case" sentence that doesn't sound completely idiotic,
> I'll credit whoever can come up with it with coauthor credits. :D
>
> Seeing as nobody else has replied (at least not publicly) I'll make my
> poor stab at this:
>
> "It shall be implementation defined what conditions are required for the
> memory modification to be an atomic operation. In all other situations, if
> the value in the memory changes between the read and write, then result of
> this operation is undefined. Note that there is no requirement for any
> atomic updates."
>

FWIW, I interpreted the original request as asking for
- some informal language to put in the paper to describe why embedded
programmers want this syntax to compile, assuming that we'd keep the old
(lack of) formal semantics.
Not as asking for
- new standardese describing new semantics we'd like `volatile` to have.

The point of Paul's paper, as I understand it, is *not *to firm up the
rules around volatile, but simply to undeprecate some syntactic constructs.

Situation in the 1990s through 2020: `vx += y;` compiles, with unclear
formal semantics, but if you don't care about portability then you can use
it and not get any diagnostics.
Situation post-2020: `vx += y;` compiles, with unclear formal semantics,
but if you don't care about portability then you can use it; but the
implementation is *formally encouraged* to give you a deprecation
diagnostic.
Situation Paul is trying to achieve: `vx += y;` compiles, with unclear
formal semantics, but if you don't care about portability then you can use
it and not get any diagnostics. (This is identical to the pre-2020
situation.)

Goal for the paper: Through informal language, convince WG21 that
"Situation Paul is trying to achieve" is somehow *better* than "Situation
post-2020."

I'm still extremely unconvinced myself — mainly due to lack of examples in
the paper — but even with examples, you still need to explain why "add
-Wno-deprecated to your makefile" isn't a reasonable medium-term solution.
(ISTM that the long-term solution does have to be either to formalize the
behavior per Henry's suggestion, or get programmers to stop using the
syntax.)

–Arthur