From Fedora Project Wiki

Line 43: Line 43:
dmalcolm: for Fedora 17 I [http://fedoraproject.org/wiki/Features/StaticAnalysisOfPythonRefcounts attempted to run all of the Python C extension code in Fedora] through my [https://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html cpychecker] cpychecker tool.  I want to repeat this analysis, but this time to capture the results in a database.
dmalcolm: for Fedora 17 I [http://fedoraproject.org/wiki/Features/StaticAnalysisOfPythonRefcounts attempted to run all of the Python C extension code in Fedora] through my [https://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html cpychecker] cpychecker tool.  I want to repeat this analysis, but this time to capture the results in a database.


This is 3 parts:
This is 4 parts:
* IN PROGRESS: "firehose" : an interchange format so we can capture results from all static analyzers in a consistent format.  This consists of: an XML serialization format, a Python module for in-memory creation/manipulation, and parsers:
* IN PROGRESS: "firehose" : an interchange format so we can capture results from all static analyzers in a consistent format.  This consists of: an XML serialization format, a Python module for in-memory creation/manipulation, and parsers:
** DONE: gcc warnings
** DONE: gcc warnings
Line 52: Line 52:
* TODO: "mock-with-analysis" (need better name?): a way of doing a mock rebuild of a src.rpm with minimal effect on the main build, whilst injects a side-effect of running static analyzers on each c/c++ file compiled (other languages?), and drops firehose XML files into the chroot as results as it goes, so that they can be slurped into a database
* TODO: "mock-with-analysis" (need better name?): a way of doing a mock rebuild of a src.rpm with minimal effect on the main build, whilst injects a side-effect of running static analyzers on each c/c++ file compiled (other languages?), and drops firehose XML files into the chroot as results as it goes, so that they can be slurped into a database
* TODO: "firehose-ui": a db and web UI for summarizing reviewing results from many analyzers across many packages, with nice workflows
* TODO: "firehose-ui": a db and web UI for summarizing reviewing results from many analyzers across many packages, with nice workflows
* TODO: gluing all of the above together and deploying it.
** having a team that comes up with filters that achieve a decent signal:noise ratio, so that J Random package maintainer doesn't have to wade through so much noise




[[Category:SIGs]]
[[Category:SIGs]]

Revision as of 15:41, 20 January 2013

Fedora Static Analysis Special Interest Group (SIG)

(Note that this SIG is merely tentative for now)

Goal and Scope

TBD

dmalcolm is interested in making it easy to run static code analysis tools on all of Fedora, and having a sane system for getting useful information from the firehose of data that doing so is likely to generate. See http://lists.fedoraproject.org/pipermail/devel/2012-December/175232.html

See also the Formal Methods SIG with which there's clearly an overlap.

Mission and Plan

TBD

Members

Communication

TBD; Fedora's main devel list for now

Tasks

Packaging

Static Code Analysis tools already in Fedora

TODO

  • gcc - arguably we should pay more attention to the compiler warnings that gcc already generates: sometimes it's correctly pointing out a bug.
  • clang static analyzer (in Fedora as "clang-analyzer" subpackage of "llvm")
  • cpychecker (part of gcc-python-plugin)
  • flawfinder (that page has a great list of links to other static analysis tools)
  • cppcheck Cppcheck is a static analysis tool for C/C++ code.
  • sparse - a Semantic Parser for C, primarily used by kernel developers.

Package Want List

TODO

"firehose"

dmalcolm: for Fedora 17 I attempted to run all of the Python C extension code in Fedora through my cpychecker cpychecker tool. I want to repeat this analysis, but this time to capture the results in a database.

This is 4 parts:

  • IN PROGRESS: "firehose" : an interchange format so we can capture results from all static analyzers in a consistent format. This consists of: an XML serialization format, a Python module for in-memory creation/manipulation, and parsers:
    • DONE: gcc warnings
    • IN PROGRESS: cppcheck warnings
    • IN PROGRESS: cpychecker warnings
    • TODO: clang-static-analyzer
    • others?
  • TODO: "mock-with-analysis" (need better name?): a way of doing a mock rebuild of a src.rpm with minimal effect on the main build, whilst injects a side-effect of running static analyzers on each c/c++ file compiled (other languages?), and drops firehose XML files into the chroot as results as it goes, so that they can be slurped into a database
  • TODO: "firehose-ui": a db and web UI for summarizing reviewing results from many analyzers across many packages, with nice workflows
  • TODO: gluing all of the above together and deploying it.
    • having a team that comes up with filters that achieve a decent signal:noise ratio, so that J Random package maintainer doesn't have to wade through so much noise