<div dir="ltr">On Mon, Sep 9, 2013 at 3:03 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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 class="HOEnZb"><font color="#888888"><br>


</font></span></div><span class="HOEnZb"><font color="#888888"><div></div></font></span></div></blockquote></div><br></div><div class="gmail_extra">Does copy assignment have the same issue?</div><div class="gmail_extra">
<br></div><div class="gmail_extra">Being more consistent seems like a good idea.  And I agree that performing this checking in defaulted copy-constructors probably isn't productive.</div><div class="gmail_extra"><br></div>
<div class="gmail_extra">-Eli</div></div>