gcc-python-plugin January 2013

gcc-python-plugin@lists.stg.fedorahosted.org

2 participants
1 discussions

RFC: "firehose" : an interchange format for static code analysis results
by David Malcolm 05 Feb '13

05 Feb '13

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/00022… 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

2 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

gcc-python-plugin January 2013