[cfe-dev] [Static Analyzer Query] Why is suppress-null-return-paths enabled by default?

[Karthik Bhat]

Hi Anna, Jordan,
Thanks for the response. Yes it does seem reasonable to suppress warning
than emit false alarms. I will dig more into core and see if it is possible
to differentiate plausible cases as mentioned by jordan.
Thanks!


On Fri, Aug 23, 2013 at 12:18 AM, Anna Zaks <ganna at apple.com> wrote:

>
> On Aug 22, 2013, at 3:52 AM, Karthik Bhat <blitz.opensource at gmail.com>
> wrote:
>
> > Hi,
> > I was running the following code through clang SA -
> >
> > #include <stdlib.h>
> > int* myAlloca(int i,int maxCount) {
> >   if (i >= maxCount)
> >     return 0;
> >   int* k = (int*) malloc(sizeof(int));
> >   return k;
> > }
> >
> > int main() {
> >   int max = 1;
> >   for(int i =0;i< 2;i++) {
> >     int* k = myAlloca(i,max);
> >     *k = 1;
> >   }
> >   return 0;
> > }
> >
> > This code will result in Null Deference in the second iteration of for
> loop.
> > When i debugged i found that the reason for it is by default null return
> paths are suppressed by clang SA.
> >
> > Running the above code with suppress-null-return-paths=false gives the
> desired result.
> >
> > Any particular reason why this flag is enabled by default in clang SA?
> >
>
> This is a part of our rude false positive suppression heuristic. If a NULL
> pointer is assumed to be NULL in a called function or returned from a
> called function, we suppress the report.
>
> The idea is that if a pointer is assumed to be NULL in a callee "if (p ==
> 0)", it's often the case that the callee is overly defensive and does not
> know that the pointer cannot be NULL (inlined defensive checks is the term
> we use internally to describe it). Some of the reports will not be false
> positives, but currently, we have no way of telling the difference. Having
> this suppression gets rid of numerous false positive reports.
>
> Similarly, we suppress the reports where NULL is returned. The
> justification here is a bit more murky. The main idea is that NULL is
> returned when some other condition is false, like "i >= maxCount" in your
> case. However, again, it is often the case of the callee being overly
> defensive and there are callers that know that the condition is never
> false. Currently, we do not have a more refined heuristic to tell the
> difference and we always go for less false positives. Jordan has ran some
> experiments on llvm codebase and, I believe, he found that this suppression
> is worth it.
>
> Cheers, Anna.
>
> > Isn't it common in code to return null from a function in case we have a
> failure and hence can result in deref if used further?
> >
> > Shouldn't we be disabling this by default? or am i missing something?
> >
> > Thanks
> > Karthik Bhat
> >
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130823/c556ec4f/attachment.html>