<div dir="ltr">On 9 September 2013 15:33, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Use a ctor-initializer for OldSanOpts.</div>
</blockquote><div><br></div><div>Done.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>Do you need to handle the assignment operator too? A test for move constructors / move assignments would be great, too (not that I expect any problems there).<br></div></div></blockquote><div><br></div>
<div>Yep, I do. Fixed, tests added. Furthermore, this caused me to notice a bug in the previous patch where I failed to call reset() when AggregatedStmts was empty. Also fixed (no testcase because no symptoms known).</div>
<div><br></div><div>Move assignment is broken, pending the other patch: <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130909/088366.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130909/088366.html</a>.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div></div>
<div>Do you care that the UBSan checks will still be enabled when CGF.getLangOpts().getGC() != LangOptions::NonGC? We seem to also fail to memcpy non-GC'd fields in that case too =)<br></div></div></blockquote><div><br>
</div><div>I punt to a later patch. The issue with us not memcpy'ing these fields is a problem all on its own, and I would need input from the ObjC folks to know how to proceed.</div><div><br></div><div>Updated patch attached! Please review, but note that it depends on the other patch.</div>
<div><br></div><div>Nick</div><div>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div></div><div class="gmail_extra">
<span style="color:rgb(80,0,80)">On Mon, Sep 9, 2013 at 3:03 PM, Nick Lewycky </span><span dir="ltr" style="color:rgb(80,0,80)"><<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>></span><span style="color:rgb(80,0,80)"> wrote:</span><br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>
<div dir="ltr">The attached patch disables the bool and enum sanitizers when emitting the implicitly-defined copy constructor.<div><br></div><div>To start with an example:</div><div> struct X { X(); X(const X&); };</div>
<div> struct Y { X x; bool b; };</div><div>if you don't initialize Y::b then try to copy an object of Y type, ubsan will complain. Technically, with the standard as written, ubsan is correct. However, this is a useful thing to do -- you may have a discriminator which decides which elements are not interesting and therefore never initialize or read them. Secondly, it's a departure from the rules in C, making well-defined C code have undefined behaviour in C++ (structs are never trap values, see C99 6.2.6.1p6). Thirdly, it's checked incompletely right now -- if you make subtle changes (f.e. add an "int i;" member to Y) ubsan will stop complaining. The semantic I'm implementing is as if the implicit copy constructor is copying the value representation (the bytes) not the object representation (the meaning of those bytes).<span><font color="#888888"><br>
</font></span></div><span><font color="#888888"><div><br></div><div>Nick<br></div></font></span></div>
<br></div></div>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div>