<div class="gmail_quote">Le 30 mars 2012 19:44, David Chisnall <span dir="ltr"><<a href="mailto:csdavec@swan.ac.uk">csdavec@swan.ac.uk</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 30 Mar 2012, at 17:01, Anna Zaks wrote:<br>
<br>
> - 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.<br>

<br>
</div>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.<br>

<span class="HOEnZb"><font color="#888888"><br>
David</font></span><br></blockquote></div><br><br>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.<br>
<br><br>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.<br>
<br>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).<br>
<br>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.<br>
<br>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.<br>
<br>The command line I have in mind would look like:<br><br>./analyzer-tool [OPTIONS] --add-annotation-file=one.annot  --add-annotation-file=two.annot  --merged-annotation-file=merged.annot  --assumption-file=assumption.annot  src/*.cpp<br>
<br>(with bonus points for recursivity in --add-annotation-file)<br><br>Note: in the absence of an assumption file, refuse non-annotated functions (unless the default values fit the use cases, of course).<br><br>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.<br>
<br><br>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.<br>
<br>-- Matthieu.<br>