C++ Logo

std-proposals

Advanced search

Re: [std-proposals] void std::optional<T>::abandon(void) noexcept

From: Sebastian Wittmeier <wittmeier_at_[hidden]>
Date: Wed, 29 Nov 2023 16:29:58 +0100
The compiler would not easily know (in general cases): memcpy receives the (pointer to the) A object as parameter and the [no_unique_address] attribute is inside the declaration of B.   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 29.11.2023 16:11 Betreff:Re: [std-proposals] void std::optional<T>::abandon(void) noexcept An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; 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

Received on 2023-11-29 15:29:59