<div dir="ltr">Hi Anna, Jordan,<div>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 <span style="font-family:arial,sans-serif;font-size:13px">plausible cases as mentioned by jordan. </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">Thanks!</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 23, 2013 at 12:18 AM, Anna Zaks <span dir="ltr"><<a href="mailto:ganna@apple.com" target="_blank">ganna@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Aug 22, 2013, at 3:52 AM, Karthik Bhat <<a href="mailto:blitz.opensource@gmail.com">blitz.opensource@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
> I was running the following code through clang SA -<br>
><br>
> #include <stdlib.h><br>
> int* myAlloca(int i,int maxCount) {<br>
>   if (i >= maxCount)<br>
>     return 0;<br>
>   int* k = (int*) malloc(sizeof(int));<br>
>   return k;<br>
> }<br>
><br>
> int main() {<br>
>   int max = 1;<br>
>   for(int i =0;i< 2;i++) {<br>
>     int* k = myAlloca(i,max);<br>
>     *k = 1;<br>
>   }<br>
>   return 0;<br>
> }<br>
><br>
> This code will result in Null Deference in the second iteration of for loop.<br>
> When i debugged i found that the reason for it is by default null return paths are suppressed by clang SA.<br>
><br>
> Running the above code with suppress-null-return-paths=false gives the desired result.<br>
><br>
> Any particular reason why this flag is enabled by default in clang SA?<br>
><br>
<br>
</div>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.<br>
<br>
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.<br>

<br>
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.<br>

<br>
Cheers, Anna.<br>
<div class="im HOEnZb"><br>
> 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?<br>
><br>
> Shouldn't we be disabling this by default? or am i missing something?<br>
><br>
> Thanks<br>
> Karthik Bhat<br>
><br>
><br>
><br>
</div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
</div></div></blockquote></div><br></div>