[cfe-dev] RFC: Nullability qualifiers

[Daniel Marjamäki]

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.

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. 

Best regards,
Daniel Marjamäki


..................................................................................................................
Daniel Marjamäki Senior Engineer
Evidente ES East AB  Warfvinges väg 34  SE-112 51 Stockholm  Sweden

Mobile:                 +46 (0)709 12 42 62
E-mail:                 Daniel.Marjamaki at evidente.se

www.evidente.se

________________________________________
Från: Douglas Gregor [dgregor at apple.com]
Skickat: den 3 mars 2015 15:18
Till: Daniel Marjamäki
Cc: cfe-dev Developers
Ämne: Re: RFC: Nullability qualifiers

> 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