C++ Logo


Advanced search

Re: [wg14/wg21 liaison] (SC22WG14.19371) n2743 Volatile C++ Compatibility

From: JF Bastien <cxx_at_[hidden]>
Date: Tue, 25 May 2021 06:58:42 -0700
On Tue, May 25, 2021 at 1:56 AM Aaron Peter Bachmann <aaron_ng_at_[hidden]>

> Hello!
> I am strongly opposed to:
> "Simple assignments where the left operand is an lvalue of
> volatile-qualified
> type is an obsolescent feature unless the expression is note valuated or
> is a
> void expression("
> Removing this will break a lot of existing perfectly fine code.
> Even deprecating without the intend to remove it,
> is not convincing.
> For new code we had to use atomic_load[_explicit]() and
> atomic_store[_explicit]().
> The volatile semantic is more appropriate, since volatile accesses are
> only ordered
> in respect to each other.
> I am involved with projects where nearly 1 % of the lines look like:
> #define STM32L4_CRC_DR (*((volatile uint32_t
> *const)(STM32L4_CRC_BASE + 0x00u)))
> and the later we find:
> STM32L4_CRC_DR=...

I think you’re objecting to:


Which isn’t being deprecated. What is being deprecated is


Hardware will neither reorder nor tear such accesses and that is
> guaranteed (in my case by ARM).
> Otherwise the memory mapped devices could not fulfill the intended purpose.
> Arguable the snippet given lakes the use of _Atomic.
> Code like this often predates C11.
> I would go into the opposite direction:
> Rather than taking away useful parts of C I would add semantic:
> are defined to a value !=0 we shall guarantee in the standard that there
> is no tearing
> on load and store even without _Atomic.
> That is what all implementations I am aware of do.
> It is just missing from the standard.

Implementations frequently do things like replace large accesses with
memcpy or memset, which don’t have the guarantees you request.

> Sidenote:
> Some interoperability between C and C++ is valuable,
> e. g. linkage compatibility with extern "C", or common header files.
> But I never understood why C or the use of C should be restricted by C++,
> while at the same time C++ would not be restricted by C.
> This asymmetry cripples C and hinders progress.

That’s partly the point of this working group.

I like other aspects of the paper.
> Mixing bitfileds and volatile just makes no sense,
> so forbidding it and thus reducing undefined behavior is good.

Unfortunately, that’s not quite true. For example some Arm processors
frequently have volatile bit fields.

> volatile sometype *b;
> writing
> a=*b=c;
> is not desirable.
> I am not opposed of addressing this in the standard,
> but see no big gain either, since
> I know no one who would ever write this.

I personally know of codebases that did this and had bugs due to it. In
fact I know of a compiler that has workarounds for that codebase

Regards, Aaron Peter Bachmann
> On 5/22/21 4:08 PM, Robert Seacord wrote:
> > 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:
> >
> > http://robertseacord.com/wp/2021/05/22/volatile-c-compatibility/
> > <http://robertseacord.com/wp/2021/05/22/volatile-c-compatibility/>
> >
> > Thanks,
> > rCs
> >

Received on 2021-05-25 08:58:56