[cfe-dev] Fwd: [LLVMdev] RFC: Adding attribute(nonnull) to things in libc++

[Marshall Clow]

Re-send because the original went to the old lists.
-- Marshall

---------- Forwarded message ----------
From: Marshall Clow <mclow.lists at gmail.com>
Date: Tue, Aug 11, 2015 at 10:50 AM
Subject: Re: [LLVMdev] [cfe-dev] RFC: Adding attribute(nonnull) to things
in libc++
To: Chandler Carruth <chandlerc at google.com>
Cc: Nick Lewycky <nlewycky at google.com>, "cfe-dev at cs.uiuc.edu Developers" <
cfe-dev at cs.uiuc.edu>, LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>


On Mon, Aug 3, 2015 at 7:20 PM, Chandler Carruth <chandlerc at google.com>
wrote:

> I just want to revive this thread.
>
> 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.
>
> To get an idea of how widespread this is on at least the Linux platform,
> they went into glibc over a decade ago:
>
> https://sourceware.org/git/?p=glibc.git;a=commit;f=string/string.h;h=be27d08c05911a658949ba7b84f4321a65a2dbf4
>
> 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.
>
>
I put up http://reviews.llvm.org/D11948 for review.

-- Marshall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150811/50ab5314/attachment.html>