Am 14. April 2021 20:51:53 MESZ schrieb Ville Voutilainen <ville.voutilainen_at_[hidden]>:
>On Wed, 14 Apr 2021 at 21:47, Jens Gustedt via Liaison
><liaison_at_[hidden]> wrote:
>>
>> Am 14. April 2021 20:07:18 MESZ schrieb JF Bastien
><cxx_at_[hidden]>:
>>>
>>> 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.
>>
>>
>> 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

I remember having done that already several times, but I don't remember much that helped me to move forward for C.

As said, our model in C is different, we only have values and representations, but no "value representation".

Jens

-- 
Jens Gustedt - INRIA & ICube, Strasbourg, France