Am Mittwoch, den 14.04.2021, 11:07 -0700 schrieb JF Bastien:
> 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_cl.cam.ac.uk
> > >
> > > 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.

You are repeating this statement, but I do not believe
this is true. I also do not see where the paper explains
this in a convincing way.

I believe that either your anaylsis must be wrong or it
does not apply to C.

Best,
Martin