[cfe-dev] RFC: Nullability qualifiers

[Douglas Gregor]

> On Mar 8, 2015, at 5:14 AM, Daniel Marjamäki <Daniel.Marjamaki at evidente.se> wrote:
> 
> 
> Hello!
> 
>>> However strchr is not a good example imho where this could be used.
>>> 
>>> The strchr return value is well defined, therefore you don't always need to check if it returns null. For instance:
>>> 
>>>   strcat(s,"abcd");
>>>   char *c = strchr(s,'c');
>>> 
>>> I would personally say a warning after this code about missing null pointer check is a FP.
> 
>> Feeding constant or mostly-known inputs into a function nearly always means that you know a lot more about its return value than the static type system could describe. Technically, yes, it’s a false positive, but it’s a completely uninteresting one, and if you’re in a place where you are “sure” that the result is going to be non-null… write an assertion so your fellow programmers and tools know that you’re “sure” and that assumption will survive subsequent refactoring.
> 
> 
> Yes this is true.
> 
> However I still don't think strchr is a good example where this could be used.
> 
> As I understand it we're talking about adding this attribute in glibc which means it's not just clang that will see it.
> 
> Are you saying that all compilers and tools that use this attribute must have extra intelligence about assertions also?
> 
> This FP may be acceptable for Clang but other tools may not accept it.

It's trivial to make these double-underscored keywords disappear for compilers that don't support it:

#if !defined(__has_feature)
#  define __has_feature(x) 0
#endif

#if !__has_feature(nullability)
#  define __nonnull
#  define __nullable
#  define __null_unspecified
#endif

> 
> I still think this attribute is a good idea basically. but personally I don't think strchr in glibc is a good example where it can be used. 


We've annotated several thousand APIs with this information.

	- Doug