Am 14. April 2021 20:51:53 MESZ schrieb Ville Voutilainen <ville.voutilainen@gmail.com>:

On Wed, 14 Apr 2021 at 21:47, Jens Gustedt via Liaison
<liaison@lists.isocpp.org> wrote:

 Am 14. April 2021 20:07:18 MESZ schrieb JF Bastien <cxx@jfbastien.com>:

 On Wed, Apr 14, 2021 at 11:00 AM Uecker, Martin <Martin.Uecker@med.uni-goettingen.de> 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@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.


 Well, there is actually not much of an explanation in the paper.

 And doesn't work isn't much of a description

You need to look at the R0 revision
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0528r0.html