You’re absolutely right that a static analysis tool (or really any program analysis tool trying to do deep analysis of a program) won’t understand all the quirky patterns out there in real code, and there will be definitely times that programmers will want to silence the tool.

Your suggestion of using something like pragma blocks is similar to my suggestion about annotations (except that annotations usually have a finer granularity). Ideally, we would want such “escape hatches” to be check-specific, so that a programmer doesn’t inadvertently silence the tool for all warnings.

Similarly, programmers can amplify checks by annotating their code; for example, the GCC nonnull attribute allows user to specify that a function argument should never be NULL, and the static analysis tool can flag warnings appropriately (this is something that isn’t in there right now, but is easy to do and is in our queue).

Your comment also ties in with some of our goals for enhancing the workflow of such tools. Commercial tools like Coverity’s Prevent allow users to track issues across multiple runs of the tool, with the ideal situation being that users only need to inspect fresh issues. In the general case it’s both a hard problem from both a tool infrastructure and UI perspective, but I think that even limited issue tracking across analysis runs would be valuable. Users simply don’t want to look at the same false positive more than once, and even some bugs are intentionally left in because they aren’t slotted to be fixed. Repeatedly issuing warnings about the latter is noise that should be avoided if possible.

We’re going to keep the development of the tool very community (and demand) driven. When users find that a particular check is emitting too much noise, hopefully they will file a bug report so that we can either fix the problem in the analyzer itself or otherwise provide the facility to silence the particular problem that the programmer is seeing.

Somewhat ironically, your comment was a false positive for the spam filter which is why it’s only appearing now (I had to go in and unmark it as spam).

As for false positives, I didn’t consider them a big deal as I know it’s early and that you guys will be refining it as time goes on. I think that no tool will be perfect in that regard and that maybe the focus should be to specify arbitrary blocks to be ignored by the checker. For instance, I’ve turned off the gcc check for shadowed variables because it would complain about me using the variable “index” (which I use a lot) because of some header somewhere that defined it. The point being that users may stop using the tool if it bugs them too much about the same thing over and over. I can see there being some odd pattern that the checker could not be reasonably catch but the programmer wants to leave the way it is. Giving the ability to have the checker skip these instances would do a lot towards alleviating this type of issue.

I’ll also send you an email about it but I just wanted to say that it’s a great tool and I’ve already found it useful in a production setting.

Inter-procedural analysis only is a partial solution, since the implementations of these functions might not be available to the static analysis tool (e.g., if they are buried in a library whose source is unavailable). A complementary solution is to provide attributes that can be affixed to the function prototypes of wrapper functions (which are declared in headers) that the checker can leverage to understand the a function has a certain functionality and thus reduce false positives. This solution is nice because it makes the checking more modular, and documents the interface of the function without requiring full-blown inter-procedural analysis. The syntax of these attributes would be similar to GCC attributes, but could easily be sugared with the use of preprocessor macros:

http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes

Would attribute support like this be useful? Conceptually, we would add a few checker-specific attributes to Clang, and provide a header file that #defined a set of macros that expanded to these attributes when using Clang and would expand to nothing when not using Clang. That way GCC eats your code with no problems.

If this sounds like a good feature, feel free to shoot me an email directly, or send an email to the Clang developers’ mailing list:

http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev