On Mon, Dec 19, 2016 at 10:52:13AM -0700, Jeff Law wrote:
> > > > None look like real bugs to me.
> > >
> > > They do to me. There are calls in gengtype.c to a function decorated
> > > with attribute nonnull (lbasename) that pass to it a pointer that's
> > > potentially null. For example below. get_input_file_name returns
> >
> > Most pointers passed to functions with nonnull attributes are, from the
> > compiler POV, potentially NULL. Usually the compiler just can't prove it
> > can't be non-NULL, it is an exception if it can.
> True. But what's happening here IIUC is that there is an explict NULL for
> those arguments in the IL, most likely due to path isolation.
>
> I would agree that a random pointer which we know nothing about could be
> NULL, but we shouldn't warn for it. That would generate too many false
> positives.
>
> What those guidelines do mean is that various transformations and
> optimizations may make warnings appear or disappear seemingly randomly.
> That's unfortunate, but inherent in this class of problems until we have a
> real static analyzer.
>From the testcases posted, there is a clear difference between "pointer is
compared to NULL in the current function and soon after that is passed
to a function which expects non-NULL", everything in one function,
from a NULL pointer checked in inline function called from 3 other inline
functions. If you test for a NULL pointer in the same function, the
likelyhood that you actually do it because NULL could be passed in is much
higher, over when somebody else wrote some other function that just happens
to test for NULL somewhere.
For path isolation it is the same thing, but IMHO not so for
warnings. So, if we want to catch the first case, we shouldn't rely on path
isolation to sometimes trigger if it is beneficial, but rather than have
infrastructure which allows us to answer whether there is a high probability
user expects a pointer might be NULL (or value might be 0 or whatever other
constant), and use that in the warning for some -Wmaybe-* variant of
selected warnings. We'd then warn regardless if path isolation is
beneficial or not, but wouldn't warn if it is unlikely useful to warn (or
there could be different levels between what we want to catch and what
amount of false positives we allow).
Jakub
