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

[Jeffrey Yasskin]

On Mon, Dec 5, 2011 at 6:19 PM, Ted Kremenek <kremenek at apple.com> wrote:
> 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?

Yes, sorry, I wasn't as clear as I should have been. The warning was
obnoxious only because it asserted that a possibly-null pointer was
definitely being dereferenced, when it meant that either a
possibly-null pointer was being dereferenced OR there was a redundant
check, and it always hid the location of the possibly-redundant check.
I would value getting the "redundant check or null dereference"
warning in my own code: I just want the analyzer to be honest about
what it's finding and not make overly-certain claims based on dodgy
assumptions.

Jeffrey