gcc-python-plugin
January 2013
gcc-python-plugin@lists.fedorahosted.org
- 2 participants
- 1 discussions
RFC: "firehose" : an interchange format for static code analysis results
by David Malcolm
Short version: there's a new branch of gcc-python-plugin named
"firehose", which adds a new external dependency on a new "firehose"
package for use by the "libcpychecker" functionality. I hope to merge
this into master once the churn-rate within the firehose API subsides.
Long version:
I've been working on running various static analysis tools on a large
subset of the packages in Fedora, trying to coerce the results into a
consistent output format, so that I can build a tracking tool (e.g.
"what new warnings were caused due to this commit?")
I'm calling my format "firehose" (since reading reports from some code
analysis tools can feel like "drinking from a firehose").
It can be seen at:
https://github.com/fedora-static-analysis/firehose
(Free Software, GPLv3 or later)
You can see some examples here:
https://github.com/fedora-static-analysis/firehose/tree/master/examples
It's XML so that it can be easily validated: there's a RELAX-NG schema
here:
https://github.com/fedora-static-analysis/firehose/blob/master/firehose.rng
Essentially a code issue is a message, with additional metadata (such as
file/line/column, optional CWE identifier), and optionally a trace of
execution to reach the error (so that an analysis tool can identify e.g.
that a memory leak happens on a particular error-handling path after
once through a loop, or whatever, potentially including a view of the
changing variables in the code).
The format's not set in stone yet (hence this RFC) - anything I've
missed?
I have parsers:
* for GCC warnings (textual parsing, assuming LANG=C)
* for clang-analyzer (the --plist format)
* for cppcheck (its XMLv2 format).
There's also a Python API and extensive unit tests (though the API is
not set in stone yet either).
I've created a "firehose" branch of gcc-python-plugin in which the
cpychecker uses the firehose API as its internal representation of
errors, using that to emit gcc warnings and generate HTML trace reports
(I plan to refactor the error trace visualization code from out of my
gcc-python-plugin and into the firehose thing, so that other projects
can use it). It can thus "natively" emit XML. My plan is for this to
replace the JSON experiments from
https://lists.fedorahosted.org/pipermail/gcc-python-plugin/2012-March/000...
My plan is to merge this into master, adding the firehose dependency
(for the cpychecker parts of the source tree, at least), though I can't
do this until firehose achieves some level of API stability... and an
official tarball release :)
Hope this of interest - would anyone here be interested in using this in
their own analysis scripts?
Dave
FWIW you can see some notes on what I'm building with this at
http://lists.fedoraproject.org/pipermail/devel/2012-December/175232.html
http://lists.fedoraproject.org/pipermail/devel/2013-January/176872.html
http://lists.fedoraproject.org/pipermail/devel/2013-January/177633.html
11 years, 2 months
- 2
- 6
- ← Newer
- 1
- Older →