>
> So I am able to screw up the value of 'maybe_extra_byte' by memcpy'ing
> over the A object that exists inside B. Is this what the committee
> intended?


If the objects are potentially-overlapping or not TriviallyCopyable, the
behavior of memcpy is not specified and may be undefined.
A subobject is potentially overlapping if it is a base class subobject or a
non-static data member declared with the [[no_unique_address]]
attribute(since C++20).



On Wed, Nov 29, 2023 at 4:11 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:

> On Wed, Nov 29, 2023 Lénárd Szolnoki via Std-Proposals wrote:
> >
> > The precondition for memcpy is trivially copyable *and* not potentially
> > overlapping. The former doesn't imply the latter.
> >
> > https://godbolt.org/z/xhsqdoz3s
>
>
> I've been playing around with this on GodBolt:
>
> https://godbolt.org/z/Ecd338Go8
>
> The output of this program on Linux x86_64 GNU g++ 13.2.0 is:
>
> Address of b.a.i == 140727507144480
> Address of b.a.ch == 140727507144484
> Address of b.maybe_extra_byte == 140727507144485
> 77
> 0
>
> So I am able to screw up the value of 'maybe_extra_byte' by memcpy'ing
> over the A object that exists inside B. Is this what the committee
> intended?
>
> If this _is_ what the compiler intended, then should every C++
> compiler issue a diagnostic whenever you pass the address of a
> 'no_unique_address' object to memcpy?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>