Date: Sat, 27 May 2023 20:41:35 +0000
On Sat, May 27, 2023 at 8:16 PM Jason McKesson via Std-Discussion
<std-discussion_at_[hidden]> wrote:
> The UB started when you did a `memcpy` of a type which is not
> trivially copyable. Just because there is an object of a certain type
> there does not mean that you get to copy bits into it and get valid
> behavior. `std::string` is not trivially copyable and therefore the
> affordances provided by [basic.types]/2 do not apply.
The std::memcpy itself is perfectly well-defined (all it does is copy the
source to the destination as an unsigned char array); it simply fails to
implicitly create an std::string at the field's address, or an 's' that can
be laundered. I suppose if you attempted this with a recursively
implicit-lifetime class that isn't trivially copyable, then you'd obtain an
unspecified value (which could be indeterminate, for all I know).
<std-discussion_at_[hidden]> wrote:
> The UB started when you did a `memcpy` of a type which is not
> trivially copyable. Just because there is an object of a certain type
> there does not mean that you get to copy bits into it and get valid
> behavior. `std::string` is not trivially copyable and therefore the
> affordances provided by [basic.types]/2 do not apply.
The std::memcpy itself is perfectly well-defined (all it does is copy the
source to the destination as an unsigned char array); it simply fails to
implicitly create an std::string at the field's address, or an 's' that can
be laundered. I suppose if you attempted this with a recursively
implicit-lifetime class that isn't trivially copyable, then you'd obtain an
unspecified value (which could be indeterminate, for all I know).
Received on 2023-05-27 20:41:47