On Fri, Jan 8, 2016 at 9:41 PM, David Krauss <david_work_at_[hidden]> wrote:

>
> On 2016–01–09, at 1:54 AM, Hubert Tong <hubert.reinterpretcast_at_[hidden]>
> wrote:
>
> My two cents: even when memcpy becomes capable of initiating the lifetime
> of (and initializing) an object in an "aligned_storage blob", the kosher
> way of accessing that object would require std::launder.
>
>
> Then the question becomes, does std::launder require a static type? I was
> under the impression that it does. In type erasure, memcpy needs to
> support polymorphism.
>
Yes, std::launder requires a static type; however, it does not limit the
ability of memcpy to operate without knowing the type of the object being
copied. The std::launder call is involved *after* the completion of memcpy
to access the object that the memcpy initialized.


> Now, I am not sure if it is a copy/paste error, my misunderstanding of the
> code, or what, but it seems that (2) crashes because "&erasure()" and
> "&storage" overlap (and if the memcpy UB was not enough, it probably does
> not do what you intended).
>
>
> Oops, copy-paste error. It should say &o.storage. (I just double-checked,
> the post does differ from the defective test.)
>
> It’s a good thing you mentioned it, because I ran some more tests and now
> it looks like an inlining issue, not cleverness in alias analysis.
> Apparently it works whenever both memcpy arguments are function calls; it
> doesn’t matter what type they cast to.
>
> So, my bugfix didn’t clarify types at all; it merely obfuscated the object
> identities. The port works, but it’s still as UB as ever.
>
>
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>
>