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

[Marshall Clow]

On Wed, Jun 3, 2015 at 12:21 AM, Nick Lewycky <nlewycky at google.com> wrote:

> On 1 June 2015 at 07:20, Marshall Clow <mclow.lists at gmail.com> wrote:
>
>> 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++.
>>
>
> 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.
>
> The language std text claims that the pointer must point to an array of
> 'n' (second argument) length, 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.
>
> This was changed in DR2235:
> http://cplusplus.github.io/LWG/lwg-defects.html#2235
> 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.
>
> 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.
>
>
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.

I do agree that this is different behavior than memcpy, memmove, etc.
That should make Joerg happy :-)

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