On Tue, May 25, 2021 at 1:56 AM Aaron Peter Bachmann <aaron_ng_at_[hidden]>
wrote:

> 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(6.3.2.2)"
>
> 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:

STM32L4_CRC_DR=Something;

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

SomethingElse=STM32L4_CRC_DR=Something;



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:
> Whenever ATOMIC_INT_LOCK_FREE or ATOMIC_LONG_LOCK_FREE, ...
> 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.


Given
> 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
specifically.


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
> >
>
>