[cfe-dev] Clang Static Analyzer: False Positive Suppression Support
Devin Coughlin via cfe-dev
cfe-dev at lists.llvm.org
Thu Aug 25 10:31:41 PDT 2016
> On Aug 24, 2016, at 4:56 PM, p23 power <p23power at gmail.com> wrote:
> Hi Anna,
> The main in-source suppression mechanism that the clang static analyzer supports is the ‘__clang_analyzer__’ macro. I am not sure if you tried using it or not... so I am curious what are the main limitations of it that you are seeing.
> The doc page you refer to says: "use this macro to selectively exclude code the analyzer examines" ... so wouldn't this potentially create false positives later in the code path? For example, by excluding code that initializes variables that is required later in the path, the analyzer may then warn about a garbage values.
> Additionally, our customers do not want to, and some times are not allow to, add such annotations into the code, especially when it's maintained by another team or company.
> The static analyzer already has support for suppression hashes in tree. The CodeChecker tool (https://github.com/Ericsson/codechecker <https://github.com/Ericsson/codechecker>) is using them to provide user workflows such as baselining and issue suppression.
> Where I like this tool, it imposes on the developer that all warnings need to viewed through that interface and it also requires the company to setup the tool in the first place. Many developers just want to run the analyzer locally and either view the stdout or html reports.
I have found the text output to be not very helpful in understanding typical static analyzer reports — and in some cases actively harmful since an unhelpful report is more likely to be interpreted as a false positive. I view the text output as primarily a mechanism for testing the analyzer.
I also think a good goal is to eventually get the static analyzer itself out of the business of generating HTML. It seems to me that decisions about the user workflow of how to present/filter/navigate issues are much better implemented outside of clang itself. I agree that it is important to be able to run the analyzer and view reports without setup — but I think we can achieve this without sticking the UI logic in the compiler.
> Lastly, you didn't comment on the idea of feeding a yaml/json file containing the issue hashes back into the analyzer for suppression the output. What are your thoughts on this solution?
I think the biggest benefit of using a yaml/json file is for issue baselining rather than suppression and I would support incorporating this functionality in clang for that purpose. It is important that the format be easily diffable and stored in version control — i.e. not sqlite database.
In my view, the key different between baselining and suppression is that suppressions typically have lifecycle comments associated when them. These comments often include:
- A justification for the suppression. This is typically an explanation of why the diagnostic is a false positive.
- A criterion for when the suppression can be removed. This is often in the form of a bug filed against the static analyzer to fix the false positive or a bug filed against the codebase under analysis to follow proper coding conventions (e.g., for memory management and ownership).
Suppression lifecycle comments are important so that when the code in question changes someone can evaluate whether the suppression is still needed and make sure it is not hiding a true positive in the changed codebase. These comments can either be represented in the code itself (in which case the external yaml/json suppressions file would presumably not be needed) or viewed and stored by some external tool like CodeChecker (in which case this suppression/filtering logic is probably better implemented there).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev