On 12/04/2023 22.36, Hans Boehm wrote:
>
>
> On Wed, Apr 12, 2023 at 12:05 PM Jens Maurer <jens.maurer_at_[hidden] <mailto:jens.maurer_at_[hidden]>> wrote:
>
>
> On 11/04/2023 00.30, Hans Boehm wrote:
> > Agreed, but where is the restriction of plain memcpy() to trivially copyable types?
>
> Here:
>
> [basic.types.general] p3
>
> The question is not whether you can apply memcpy (you always can do that),
> but the issue is whether the result of the copy is an "alive" object,
> or just a bunch of bytes that you scribbled into memory.
>
> For non-trivially-copyable types, there is no guarantee the result of
> the copy yields a usable object.
>
> The "seqlock" example needs "alive" objects after the copy.
>
> Thanks! That makes sense.
>
> I guess the same reasoning applies to atomic_X_per_byte_memcpy(), so technically the wording is already correct?

Yeah, I guess so.

> This does seem way too subtle, so some sort of clarification would be nice.

Indeed.

> > I would suggest copying that, but I can't find it. The main definition is in [cstring,syn], which refers to the C standard.
>
> See above; maybe the library wording should refer to "as if by memcpy" with
> a cross-reference to [basic.types.general].
>
> > This also made me worry about atomic_ref C++, but I think that's worded to make it clear that would introduce a data race, so we're probably OK there, too.
>
> Yes, I think so.
>
> > Maybe there should be an explicit note that the only concurrent conflicting accesses would be from the other function in this section?
>
> I don't understand what you're trying to say here.
>
> Basically an atomic_X_per_byte_memcpy() is only allowed to race with another atomic_X_per_byte_memcpy(). Nothing else produces defined behavior and a usable result.

Seems so, yes. Is that the intended design?

Jens