<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi, Karthik. It's true that the suppress-null-return-paths option suppresses many real errors. However, it also handles keeps us from reporting a huge number of false positives. Consider this silly example involving DenseMap:</div><div><br></div><div>llvm::DenseMap<const void*, const MemRegion *> map;</div><div>const MemRegion *getBaseRegion(const void *key) {</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>return map[key]->getBaseRegion();</div><div>}</div><div><br></div><div>In this case, "key" is known to be in the map, so we just look up the value and immediately dereference it. However, the analyzer isn't smart enough to model a DenseMap, so it considers the case where the key is not in the map, which means a default-constructed value is inserted and returned (in this case, a null pointer). And we get a warning. Using an assert to silence the warning requires rewriting the code in terms of find(), which is not as clean.</div><div><br></div><div>Another instance is a case where some API wraps a dyn_cast (or equivalent):</div><div><br></div><div>RValue *getOperand(int i) {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>return dyn_cast<RValue>(getRawOperand(i));</div><div>}</div><div><br></div><div>In the general case, you don't know if the operand is actually an RValue, but in some particular case (such as dealing with the arguments of a known builtin), you might have that information already. But again, the analyzer doesn't know that, so if you try to use the result of getOperand() immediately, we get a warning.</div><div><br></div><div>if (getOperand(0)->isConstant()) { ... }</div><div><br></div><div>Silencing this warning requires introducing a new temporary variable. It's not impossible, but it's the sort of hassle that makes people give up on the static analyzer.</div><div><br></div><div>These two examples are based on a ridiculous number of false positives reported in LLVM before we added this suppression. I think Anna and Ted and I all agree that it could be <i>much</i> better, to catch cases where the use really is plausible and accidental. But it's hard to differentiate those. So, patches and suggestions welcome.</div><div><br></div><div>Hope that answers your question. (This should probably be put in some advanced analyzer FAQ somewhere...)</div><div>Jordan</div><div><br></div><br><div><div>On Aug 22, 2013, at 3:52 , Karthik Bhat <<a href="mailto:blitz.opensource@gmail.com">blitz.opensource@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi,<div>I was running the following code through clang SA -</div><div><br></div><div><div>#include <stdlib.h></div><div>int* myAlloca(int i,int maxCount) {</div><div> if (i >= maxCount)</div><div> return 0;</div>
<div> int* k = (int*) malloc(sizeof(int));</div><div> return k;</div><div>}</div><div><br></div><div>int main() {</div><div> int max = 1;</div><div> for(int i =0;i< 2;i++) {</div><div> int* k = myAlloca(i,max);</div>
<div> *k = 1;</div><div> }</div><div> return 0;</div><div>}</div></div><div><br></div><div>This code will result in Null Deference in the second iteration of for loop. </div><div>When i debugged i found that the reason for it is by default null return paths are suppressed by clang SA.</div>
<div> </div><div>Running the above code with suppress-null-return-paths=false gives the desired result.</div><div><br></div><div>Any particular reason why this flag is enabled by default in clang SA? </div><div><br></div>
<div>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? </div><div><br></div><div>Shouldn't we be disabling this by default? or am i missing something?</div>
<div><br></div><div>Thanks</div><div>Karthik Bhat</div><div><br></div><div><br></div><div><br></div></div>
_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></blockquote></div><br></body></html>