[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