[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