Hi Alejandro,
On Wed, Nov 17, 2021 at 1:06 AM Alejandro Colomar (man-pages) via
cfe-dev <cfe-...@lists.llvm.org> wrote:
> On 11/16/21 13:34, Alejandro Colomar (man-pages) wrote:
> > $ cat _Nonnull.c
> > #include <stdlib.h>
> >
> > int *_Nonnull f(int *_Nullable p)
> > {
> > if (!p)
> > exit(1);
> > return p;
> > }
> >
> >
> > - I get a warning from f().
> > Ideally,
> > a programmer should not need to cast
> > (casts are dangerous),
> > to convert a nullable pointer to a _Nonnull pointer.
> > For that,
> > appropriate checks should be in the preceeding code.
> > Otherwise, a diagnostic should be issued.
> > To be on the safe side,
> > if a compiler has doubts,
> > it should diagnose.
> >
> > There's some Clang document that talks about something similar.
> > I don't know its validity,
> > or if it was a draft before _Nonnull qualifiers.
> > <https://clang.llvm.org/docs/analyzer/developer-docs/nullability.html>
>
> That document suggests that I shouldn't get a diagnostic from f().
> Why did I get a diagnostic? (I tried clang 11, 13 & 14(experimental))
>
>
> Is it talking about a different nonnull attribute/qualifier?
> Was it about a proposal prior to the current _Nonnull?
> Why is it not in use? Was it too difficult to implement?
The false positive you're getting is from the Clang warning
-Wnullable-to-nonnull-conversion. It is a simple type-based check that
does not take dataflow information into account. In other words, the
reason for the nullability false positive in your example is identical
to the reason for the integer conversion false positive here:
```
#include <stdlib.h>
#include <stdint.h>
#include <limits.h>
uint8_t f(uint32_t x) {
if (x > UINT8_MAX)
exit(1);
return x;
}
```
warning: implicit conversion loses integer precision: 'uint32_t' (aka
'unsigned int') to 'uint8_t' (aka 'unsigned char')
[-Wimplicit-int-conversion]
This webpage
https://clang.llvm.org/docs/analyzer/developer-docs/nullability.html
describes Clang Static Analyzer, is a sophisticated path-sensitive
static analysis tool. It is unfortunately often too slow to enable in
regular compilation.
> Do you think Clang could be improved to not warn on f()?
Absolutely. We can implement a dataflow-based check that takes the
flow condition into account. Flow-sensitive diagnostics should scale a
lot better than path-sensitive, and they should be fast enough to
become a compiler warning. We are currently upstreaming a dataflow
analysis framework that should make implementing such diagnostics
easier. https://lists.llvm.org/pipermail/cfe-dev/2021-October/069098.html
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <griboz...@gmail.com>*/
