I've merged the "proposed-plugin-api" branch into "master"
by David Malcolm
I'm working on adding support for using the plugin with gcc 4.8
prereleases, and so it was time to "bite the bullet" and merge the
"proposed-plugin-api" branch.
This adds a "gcc-c-api" subdirectory: an intermediate C layer that's
intended to shield the plugin from changes to GCC's own API (and
hopefully eventually become an API for all GCC plugins to use). The 4.7
vs 4.8 differences can live there.
I also plan a big symbol renaming: given that all of the gcc-c-api's
symbols begin with gcc_, it's somewhat confusing to have symbols within
the plugin proper that use such naming. So I plan to rename plugin
symbols so that they are prefixed with PyGcc and use
CamelCase_WithOneUnderscore, like Python itself. (this is a slight
violation of PEP 7 in that you're not meant to use "Py" as a prefix, but
I don't see it being an issue).
This should make it easy to distinguish the gcc-c-api layer
(lower_case_with_multiple_underscores) from the python plugin layer
(CamelCase_WithOneUnderscore).
Dave
11 years, 1 month
Fwd: plugin to replace CHAR* with a a"smart pointer string" ??
by y a
Hi all****
** **
I am simply awed by the gcc-python-plugin ;) ****
It looks like a fantastic effort****
** **
However, I cant find any sample which actually modifies the original C
program****
** **
For example, how to add a runtime reference count to each CHAR *
Obviously, this is a large, long term project****
For C++, this replaces CHAR* with an object****
For C, I might do a simpler effort and just add an additional counter
variable for each char* ****
** **
But is the python-plugin even suitable for this or should I go for a native
gcc plugin ?****
It will be great to get any links to something similar ** **
** **
Yaniv****
** **
11 years, 2 months
plugin to replace CHAR* with a a"smart pointer" ??
by y a
On Feb 10, 2013 11:20 AM
> Hi all
>
>
>
> I am simply awed by the gcc-python-plugin ;)
>
> It looks like a fantastic effort
>
>
>
> However, I cant find any sample which actually modifies the original C
program
>
>
>
> For example, how to add a reference count to each CHAR *
>
> Obviously, this is a large, long term project
>
> For C++, this replaces CHAR* with an object
>
> For C, I might do a simpler effort and just add an additional counter
variable for each char*
>
>
>
> But is the python-plugin even suitable for this or should I go for a
native gcc plugin ?
>
> It will be great to get any links to something similar
>
>
>
> Yaniv
>
yaniv
11 years, 2 months
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
