<div dir="ltr">Re-send because the original went to the old lists.<div>-- Marshall</div><div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Marshall Clow</b> <span dir="ltr"><<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>></span><br>Date: Tue, Aug 11, 2015 at 10:50 AM<br>Subject: Re: [LLVMdev] [cfe-dev] RFC: Adding attribute(nonnull) to things in libc++<br>To: Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>><br>Cc: Nick Lewycky <<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>>, "<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a> Developers" <<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a>>, LLVM Developers Mailing List <<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>><br><br><br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Mon, Aug 3, 2015 at 7:20 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br></span><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I just want to revive this thread.<div><br></div><div>I'm not really endorsing this particular use of non-null in API design (I agree with the committee that we should permit 'nullptr, 0' arguments). However, I think that we should add these attributes for memcpy and friends. Why? Because glibc has already shipped with these attributes which means that portable code will never be able to pass a null pointer here without running the risk of miscompile. Even if the standard were to retract the dubious wording, we would have a very large number of glibc installations in the world with the attributes and a large number of compilers that will miscompile code by optimizing based on them. We should, IMO, annotate it everywhere so that warnings and tools like UBSan can find all of these bugs waiting to happen.</div><div><br></div><div>To get an idea of how widespread this is on at least the Linux platform, they went into glibc over a decade ago:</div><div><a href="https://sourceware.org/git/?p=glibc.git;a=commit;f=string/string.h;h=be27d08c05911a658949ba7b84f4321a65a2dbf4" target="_blank">https://sourceware.org/git/?p=glibc.git;a=commit;f=string/string.h;h=be27d08c05911a658949ba7b84f4321a65a2dbf4</a><br></div><div><br></div><div>I just spent a pile of time cleaning up LLVM and Clang. It would be great to get more help keeping us in this clean state.</div><div><br></div></div></blockquote><div><br></div></span><div>I put up <a href="http://reviews.llvm.org/D11948" target="_blank">http://reviews.llvm.org/D11948</a> for review.</div><span><font color="#888888"><div><br></div><div>-- Marshall</div><div> </div></font></span></div><br></div></div>
</div><br></div></div>