[cfe-dev] Bug: Unexpected dereference claim on --analyze

Ted Kremenek kremenek at apple.com
Mon Dec 5 18:19:10 PST 2011


On Dec 5, 2011, at 4:43 PM, Jeffrey Yasskin wrote:

> Klocwork has a similar heuristic, and it proved obnoxious in practice.
> ~75%-90% of the time, the real problem in the code was that someone
> was checking against 0, but the pointer was actually guaranteed not to
> be 0, so the check was redundant. Unless the analyzer has other
> evidence that the pointer may actually be 0, it should treat
> "dereference null" and "redundant check" as similar likelihood and
> include both in the warning, or omit the warning.


Hi Jeffrey,

Excellent points.  I think the heuristic is still valuable, however.  Either the pointer could be null, and thus result in a null dereference, or the logic is redundant, and thus the invariants of the code aren't well documented or well understood.  I agree that the latter is less severe than the other.  In such cases, I'd argue that the runtime check should be an assert() or the code should use __attribute__((nonnull)) to document the assumptions in the code.  The analyzer cues off of either of these, and so do other programmers.

Do you think it would be reasonable to still emit a warning here, but categorize it differently in the places where we are less certain that the issue is a null dereference?

Cheers,
Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111205/a274d683/attachment.html>


More information about the cfe-dev mailing list