<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 3, 2015 at 12:21 AM, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>></span> wrote:<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 1 June 2015 at 07:20, Marshall Clow <span dir="ltr"><<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>></span> wrote:<br><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">This weekend, I got an email from Nuno Lopes informing me that UBSAN now paid attention to attribute(nonnull), and he was having some problems with it going off when using libc++.</div></blockquote><div><br></div></span><div>FYI, I also looked into turning this on, but with libstdc++, and found that they annotated basic_string<T>::assign(pointer, len) with attribute nonnull. That's a problem, because it's valid to call basic_string<T>::assign(nullptr, 0), but the reasoning why it's valid makes me want to ask the committee whether this is what they intended.</div><div><br></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">The language std text claims that the pointer must point to an array of 'n' (second argument) length</span>, but earlier in the text it also states that in the library, whenever it says "array" it means any pointer upon which address computations and accesses to objects (that would be valid if the pointer did point to the first element of such an array). Thus, nullptr is valid if 'n' is zero.</div><div><br></div><div>This was changed in DR2235:<br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__cplusplus.github.io_LWG_lwg-2Ddefects.html-232235&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=qWWobq8tJTAgytR0zHtK8nTZ1DcWszk2BFMbTnwZRTI&s=L1aJ06GiBGnAq3UajsCB29a-yiQx-HeurymfyzUm6tE&e=" target="_blank">http://cplusplus.github.io/LWG/lwg-defects.html#2235</a></div><div>The text and discussion of DR2235 sound like they intend to make the behaviour of assign match that of the constructor that takes the same arguments. What they actually did was change the constructor to match the behaviour of assign, and it doesn't look like removing the requirement of a nonnull pointer was considered and intended.<br></div><div><br></div><div>At this point I made a note that somebody should ask the committee when they get the chance, and never got back around to it.</div><div><br></div></div></div></div></blockquote><div><br></div><div>I think that the reference in the discussion to [res.on.arguments] (the relevant section there is paragraph 1.2) make it clear that the change was deliberate - to allow (null, 0) as a set of parameters.</div><div><br></div><div>I do agree that this is different behavior than memcpy, memmove, etc. </div><div>That should make Joerg happy :-)</div><div><br></div><div>-- Marshall</div></div></div></div>