On Fri, Jan 8, 2016 at 9:41 PM, David Krauss <david_work@me.com> wrote:

On 2016–01–09, at 1:54 AM, Hubert Tong <hubert.reinterpretcast@gmail.com> 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