On Wed, 29 Nov 2023 at 12:41, Andrey Semashev via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On 11/29/23 15:18, Jonathan Wakely via Std-Proposals wrote:
>
>
> On Wed, 29 Nov 2023 at 11:13, Giuseppe D'Angelo via Std-Proposals
> <std-proposals@lists.isocpp.org <mailto:std-proposals@lists.isocpp.org>>
> wrote:
>
>     Il 29/11/23 11:46, Breno Guimarães via Std-Proposals ha scritto:
>     > I don't think that's UB. Not calling the destructor is not UB.
>
>     I was referring to the memset. But indeed I can't seem to find a
>     provision that you can't just overwrite bytes of an arbitrary object
>     using it. Interesting pub quiz question...
>
>
> There's no guarantee that the bytes of std::future<bool> are contiguous,
> so memset could overwrite something that's not part of the object.
>
> And clearly zeroing out the bytes of a std::vector and then expecting it
> to keep working afterwards isn't reasonable. I think fiddling with the
> underlying bytes is only valid for trivially copyable types.

Not even then, I think. It is permitted for std::optional<T> to store
the "populated" flag in the tail padding of the stored object (e.g. by
creating an object of a class that derives from T), which means that the
memset would corrupt that flag.

I don't think compilers will reuse tail padding of trivially-copyable types, precisely because using memcpy to change the value of a trivially copyable type is allowed.

In any case, using memset can produce an invalid object even on trivially-copyable types. The object representation created by memset might not be a valid value representation for the type. Only memcpy of bytes from a valid value representation of another object is guaranteed to work.

But this is all a diversion from the fact that this abandon proposal is just a bad idea.