Date: Fri, 8 Jan 2016 22:50:41 -0500
std::launder() is one of the scariest things I've seen, but it's part of
the pleasure of working on WG21 :)
2016-01-08 22:35 GMT-05:00 Hubert Tong <hubert.reinterpretcast_at_[hidden]>:
> 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
>>
>>
>
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>
>
the pleasure of working on WG21 :)
2016-01-08 22:35 GMT-05:00 Hubert Tong <hubert.reinterpretcast_at_[hidden]>:
> 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
>>
>>
>
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>
>
Received on 2016-01-09 04:50:43