I agree that we should make things compatible. I do think that C++ should revert the compound assignment deprecation though (and C shouldn't adopt it in the first place).

I don't know that this group has talked through http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2327r0.pdf yet. I think it was on the agenda with the deprecating volatile paper, but that we didn't have time to discuss it.

For the compound operators, I will highlight section 2.3 in P2327R0. We are trading one source of bugs (people misunderstanding RMW cycles) for another set of bugs (incomplete copy / pastes). The RMW cycle category of bugs can generally be fixed with education and code review. The incomplete copy / pastes are much harder to address. From P2327R0...

UART1−>UCSR0B |= (1<<UCSZ01 ) ;// original code
UART1−>UCSR0B = UART1−>UCSR0B | (1<<UCSZ01 ) ;// correct replacement
UART2−>UCSR0B = UART1−>UCSR0B | (1<<UCSZ01 ) ;// incorrect replacement

In practice, memory mapped registers often have cryptic names with numbers in them, making typos and copy / paste errors particularly annoying to spot.

My suggestion to implementers would be to provide an off-by-default warning that diagnoses compound volatile assignment. This way programmers have the tools to find potentially buggy code and determine for themselves if they would prefer duplication or not.

P2327R0 De-deprecating volatile compound operations<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2327r0.pdf>
Number: P2327R0 Title: De-deprecating volatile compound operations Project: ISOJTC1/SC22/WG21: ProgrammingLanguageC++ Audience: SG14,SG1,SG22,EWG,WG21 Date: 2021-04-15 Authors: PaulM.Bendixen<paulbendixen_at_[hidden]> Contributors: JensMaurer ArthurO’Dwyer BenSaks Email: paulbendixen_at_[hidden] Reply to: PaulM.Bendixen Revision history 1 Introduction TheC++ ...
www.open-std.org


________________________________
From: Liaison <liaison-bounces_at_[hidden]> on behalf of Aaron Ballman via Liaison <liaison_at_[hidden]>
Sent: Saturday, May 22, 2021 10:25 AM
To: WG14/WG21 liaison mailing list <liaison_at_[hidden]>
Cc: Aaron Ballman <aaron_at_[hidden]>
Subject: [EXTERNAL] Re: [wg14/wg21 liaison] n2743 Volatile C++ Compatibility

On Sat, May 22, 2021 at 10:49 AM Philipp Klaus Krause via Liaison
<liaison_at_[hidden]> wrote:
>
> Am 22.05.21 um 16:08 schrieb Robert Seacord via Liaison:
> > I'm looking for reviews / comments for n2743 Volatile C++ Compatibility
> > before submission. If you are interested in reviewing, you can find a
> > PDF of the proposal here:
> >
> > https://urldefense.com/v3/__http://robertseacord.com/wp/2021/05/22/volatile-c-compatibility/__;!!FbZ0ZwI3Qg!7Yu05pctEl1XYnq3M4GCocO9OqOSfo11xSkwBukxu79IHlmrY8WdISCcVqNc$
> > <https://urldefense.com/v3/__http://robertseacord.com/wp/2021/05/22/volatile-c-compatibility/__;!!FbZ0ZwI3Qg!7Yu05pctEl1XYnq3M4GCocO9OqOSfo11xSkwBukxu79IHlmrY8WdISCcVqNc$ >
> >
> > Thanks,
> > rCs
>
> People use compound operators, increment and decrement on memory-mapped
> I/O registers.
> The justification of basically 'compound operators are misleading, since
> they look as if there was only one memory access instead of a read
> followed by a write' seems very weak to me. Users of volatile tend to be
> working close to the hardware, knowing how the hardware works.

FWIW, my personal experience has been that this is a significant cause
of confusion even for people who are experienced working close to the
hardware.

> The remaining rationale apparently is just 'C++ removed the feature, so
> we should, too', which also seems a rather weak one to me.

Some of the deprecations touch on interfaces that would plausibly show
up in headers shared between C and C++ (specifically, volatile on
return types and on parameter types), so those particular cases are of
importance for compatibility between C and C++.

~Aaron

>
> Philipp
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/liaison__;!!FbZ0ZwI3Qg!7Yu05pctEl1XYnq3M4GCocO9OqOSfo11xSkwBukxu79IHlmrY8WdIVgKSfCK$
> Link to this post: https://urldefense.com/v3/__http://lists.isocpp.org/liaison/2021/05/0583.php__;!!FbZ0ZwI3Qg!7Yu05pctEl1XYnq3M4GCocO9OqOSfo11xSkwBukxu79IHlmrY8WdId_Ys7fr$
_______________________________________________
Liaison mailing list
Liaison_at_[hidden]
Subscription: https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/liaison__;!!FbZ0ZwI3Qg!7Yu05pctEl1XYnq3M4GCocO9OqOSfo11xSkwBukxu79IHlmrY8WdIVgKSfCK$
Link to this post: https://urldefense.com/v3/__http://lists.isocpp.org/liaison/2021/05/0585.php__;!!FbZ0ZwI3Qg!7Yu05pctEl1XYnq3M4GCocO9OqOSfo11xSkwBukxu79IHlmrY8WdIQZJ2C0f$