<div dir="ltr">std::launder() is one of the scariest things I&#39;ve seen, but it&#39;s part of the pleasure of working on WG21 :)<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-08 22:35 GMT-05:00 Hubert Tong <span dir="ltr">&lt;<a href="mailto:hubert.reinterpretcast@gmail.com" target="_blank">hubert.reinterpretcast@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Fri, Jan 8, 2016 at 9:41 PM, David Krauss <span dir="ltr">&lt;<a href="mailto:david_work@me.com" target="_blank">david_work@me.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On 2016–01–09, at 1:54 AM, Hubert Tong &lt;<a href="mailto:hubert.reinterpretcast@gmail.com" target="_blank">hubert.reinterpretcast@gmail.com</a>&gt; wrote:</div><br><div><div dir="ltr"><div><div>My two cents: even when memcpy becomes capable of initiating the lifetime of (and initializing) an object in an &quot;aligned_storage blob&quot;, the kosher way of accessing that object would require std::launder.<br></div></div></div></div></blockquote><div><br></div></span><div>Then the question becomes, does <font face="Courier">std::launder</font> require a static type? I was under the impression that it does. In type erasure, <font face="Courier">memcpy</font> needs to support polymorphism.</div></div></div></blockquote></span><div>Yes, <span style="font-family:monospace,monospace">std::launder</span> requires a static type; however, it does not limit the ability of <span style="font-family:monospace,monospace">memcpy</span> to operate without knowing the type of the object being copied. The <span style="font-family:monospace,monospace">std::launder</span> call is involved <i>after</i> the completion of <span style="font-family:monospace,monospace">memcpy</span> to access the object that the <span style="font-family:monospace,monospace">memcpy</span> initialized.<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div style="word-wrap:break-word"><div><span><br><blockquote type="cite"><div><div dir="ltr"><div>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 &quot;&amp;erasure()&quot; and &quot;&amp;storage&quot; overlap (and if the memcpy UB was not enough, it probably does not do what you intended).<br></div></div></div></blockquote><div><br></div></span><div>Oops, copy-paste error. It should say <font face="Courier">&amp;o.storage</font>. (I just double-checked, the post does differ from the defective test.)</div></div><br><div>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 <font face="Courier">memcpy</font> arguments are function calls; it doesn’t matter what type they cast to.</div><div><br></div><div>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.</div><div><br></div></div><br></span><span class="">_______________________________________________<br>
ub mailing list<br>
<a href="mailto:ub@isocpp.open-std.org" target="_blank">ub@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/ub" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/ub</a><br>
<br></span></blockquote></div><br></div></div>
<br>_______________________________________________<br>
ub mailing list<br>
<a href="mailto:ub@isocpp.open-std.org">ub@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/ub" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/ub</a><br>
<br></blockquote></div><br></div>