Re: What does Coverity/clang static analysis actually do?

[Jérôme M. Berger]

Walter Bright wrote:

Nick Sabalausky wrote:

"Walter Bright" <newshou...@digitalmars.com> wrote in message

2. possible dereference of NULL pointers (some reaching definitions of a pointer are NULL) 2. Optimizer collects the info, but ignores this, because people are annoyed by false positives.

If you mean something like this:

Foo f;
if(cond)
    f = new Foo();
f.bar();

Then I *want* the compiler to tell me. C# does this and I've never been annoyed by it, in fact I've always appreciated it. I'm not aware of any other C# user that has a problem with that either. If that's not what you mean though, then could you elaborate?

The problem crops up when there are two connected variables:

  void foo(bool flag)
  {
    char* p = null;
    if (flag)
    p = "hello";
    ...
    if (flag)
    bar(*p);
  }





Does this happen in practice? Yes.

The code is logically correct, there is no null pointer dereference possible. However, the data flow analysis will see the *p and see two reaching definitions for p: null and "hello", even though only one actually reaches. Hence the false positive. To eliminate the false error report, the user would have to insert a redundant null check.

                Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr

I don't know about Coverity/clang, but I have used Klocwork a couple of times and it will work properly in the example you have given. I.e it sees that both conditions are linked and that you don't use p if you haven't initialized it. Of course, if the condition is more complex or if the condition might be modified by another thread (even if you know it isn't), there comes a point at which it will give a warning.

signature.asc
Description: OpenPGP digital signature