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.


Best,
Martin