[cfe-dev] RFC: Nullability qualifiers

Douglas Gregor dgregor at apple.com
Tue Mar 3 06:18:33 PST 2015


> On Mar 2, 2015, at 11:42 PM, Daniel Marjamäki <Daniel.Marjamaki at evidente.se> wrote:
> 
> 
> Hello!
> 
> Basically a good idea.
> 
>> It is obvious to a programmer who knows the semantics of strchr that
>> it's important to check for a returned null, because null is used as the
>> sentinel for "not found". 
> 
> In most cases that is very true.
> 
> 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.

> 
> Is there some better function that could have such an attribute? I guess if its return value is unpredictable and can be null at any time then it's a good candidate.
> 
> Personally I would not say malloc/realloc are good candidates neither. Since they only return null if there is oom. if there is oom then a null pointer dereference that crash the program may not be a problem.


malloc/realloc are interesting because many developers don’t care to handle out-of-memory (and some platforms will terminate the process rather than provide null).

	- Doug





More information about the cfe-dev mailing list