On Wed, Apr 14, 2021 at 11:00 AM Uecker, Martin <
Martin.Uecker_at_[hidden]> wrote:

> Am Mittwoch, den 14.04.2021, 08:54 -0700 schrieb JF Bastien via Liaison:
> > On Tue, Apr 13, 2021 at 11:40 AM Peter Sewell <Peter.Sewell_at_[hidden]
> >
> > wrote:
>
>
> > > - reading uninitialised representation bytes and padding bytes is also
> > > necessary for other bytewise polymorphic operations: memcmp,
> marshalling,
> > > encryption, and hashing (deferring what one knows about the results of
> > > such reads for a moment). It's not clear how generally these operations
> > > have to be supported, and we would like more data. Atomic cmpxchg on
> large
> > > structs, implemented with locks, would do a memcmp/memcpy combination
> (in
> > > fact is described as such in the standard).
> > >
> >
> > For atomics with padding, C++20 adopted the following change (and I
> expect
> > that compilers will implement it in previous versions as well):
> > http://wg21.link/P0528
>
> I am not terribly excited about this solution.
>
> I think C should stick to the memcmp/memcpy semantics of cmpxchg
> which operate on the representation including padding. This fits
> to the hardware instructions, simplifies compiler design (no
> need to look into each type), is easy to explain, handles all
> cases consistently including unions, and is what most
> C programmers would expect.
>

OK, but it doesn't work, as explained in the paper.