[cfe-dev] GSoC 2012: Static Function Blacklisting

Matthieu Monrocq matthieu.monrocq at gmail.com
Fri Mar 30 12:21:21 PDT 2012


Le 30 mars 2012 19:44, David Chisnall <csdavec at swan.ac.uk> a écrit :

> On 30 Mar 2012, at 17:01, Anna Zaks wrote:
>
> > - Come up with a framework of storing the intermediate results between
> the analyzes of different translation units. Most likely, this is the
> direction the current clang static analyzer will take at some point;
> however, this is a challenging problem.
>
> This, by itself, would make a good GSoC project.  A persistence framework
> for adding annotations to functions, so that the analyser could run as in
> two passes, one collecting metadata and another applying it would not be a
> massively complex project by itself, but would be hugely useful for a whole
> range of analyses.
>
> David
>


Indeed, this would be a first step enabling many inspections. One could
imagine a simple database (sqlite ?) to record all this information, and
perhaps a simple python script on the side to query it once the analysis is
complete.


Regarding the issue of tagging functions with properties, I agree that each
property should have a default state. Whether this default is chosen to be
the safest or the most convenient option is of course debatable. I'd like
to personally err on the side of safety.

Regarding the issue of external libraries, once you have the concept of
default values, then all you need is a set of "configuration files"
(ideally one per library to ease maintenance) that declare the non-default
properties of the functions that are used. The tool can them "assume" the
default properties for all functions, and overwrite the defaults with the
properties passed via those configuration files. An optimization could
consist in either lazy loading the files (only loading up to the necessary
functions) or having an initialization phase consisting in condensing the
information in a custom file / DB ala pre-compiled header (which can then
be lazily deserialized in the former case).

One good thing about those configuration files, is that they can actually
be checked against the implementation. For example, if one file declares
"myproject::bar(int, int)" as being "reentrant" and we encounter a
declaration/definition of "myproject::bar(int, int)" that declares it is
*not* reentrant, then it is an error.

And this where they can really shine, since you can actually create them on
the fly (with a specific option). For example, if "myproject::bar(int,
int)" is (unfortunately) not annotated, then you can write a an "assumption
file" (same format than a configuration file), recording the assumption you
had to make about it. Then, this assumption file should get pulled in the
set of "configuration files" for the other TUs so that the assumptions can
be validated. It can also be completed when analyzing them, of course.

The command line I have in mind would look like:

./analyzer-tool [OPTIONS] --add-annotation-file=one.annot
--add-annotation-file=two.annot  --merged-annotation-file=merged.annot
--assumption-file=assumption.annot  src/*.cpp

(with bonus points for recursivity in --add-annotation-file)

Note: in the absence of an assumption file, refuse non-annotated functions
(unless the default values fit the use cases, of course).

Note: it means that the first file to be analyzed could declare a
non-annotated functions later assumed to have default properties.
Therefore, the analysis is incomplete if the assumption file was changed
during the session. This can be solved either by completing the "annotation
files" so that the "assumption file" is not needed any longer (or treating
it as a configuration file...) or simply by running the analysis twice.


Thus the configuration files allow both a form of persistence across TU
*and* a way to annotate 3rd party headers. A persistence framework would be
great, of course, but this simple hack should get you on track should you
prefer to continue in this avenue.

-- Matthieu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120330/56d18e8e/attachment.html>


More information about the cfe-dev mailing list