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.
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.
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@evidente.se
www.evidente.se
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
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@evidente.se
www.evidente.se
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