Hi Paul,

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.