Section: Research Program
Static program analysis
Static program analysis is concerned with obtaining information about the runtime behaviour of a program without actually running it. This information may concern the values of variables, the relations among them, dependencies between program values, the memory structure being built and manipulated, the flow of control, and, for concurrent programs, synchronisation among processes executing in parallel. Fully automated analyses usually render approximate information about the actual program behaviour. The analysis is correct if the information includes all possible behaviour of a program. Precision of an analysis is improved by reducing the amount of information describing spurious behaviour that will never occur.
Static analysis has traditionally found most of its applications in the area of program optimisation where information about the runtime behaviour can be used to transform a program so that it performs a calculation faster and/or makes better use of the available memory resources. The last decade has witnessed an increasing use of static analysis in software verification for proving invariants about programs. The Celtique project is mainly concerned with this latter use. Examples of static analysis include:

Dataflow analysis as it is used in optimising compilers for imperative languages. The properties can either be approximations of the values of an expression (â€śthe value of variable $\mathrm{\u0111\u0165\u2014\u2018}$ is greater than 0â€ť or $\mathrm{\u0111\u0165\u2014\u2018}$ is equal to $\mathrm{\u0111\u0165\u2014\u2019}$ at this point in the programâ€ť ) or more intensional information about program behaviour such as â€śthis variable is not used before being redefinedâ€ť in the classical â€śdeadvariableâ€ť analysis [74] .

Analyses of the memory structure includes shape analysis that aims at approximating the data structures created by a program. Alias analysis is another data flow analysis that finds out which variables in a program addresses the same memory location. Alias analysis is a fundamental analysis for all kinds of programs (imperative, objectoriented) that manipulate state, because alias information is necessary for the precise modelling of assignments.

Control flow analysis will find a safe approximation to the order in which the instructions of a program are executed. This is particularly relevant in languages where parameters or functions can be passed as arguments to other functions, making it impossible to determine the flow of control from the program syntax alone. The same phenomenon occurs in objectoriented languages where it is the class of an object (rather than the static type of the variable containing the object) that determines which method a given method invocation will call. Control flow analysis is an example of an analysis whose information in itself does not lead to dramatic optimisations (although it might enable inlining of code) but is necessary for subsequent analyses to give precise results.
Static analysis possesses strong semantic foundations, notably abstract interpretation [57] , that allow to prove its correctness. The implementation of static analyses is usually based on wellunderstood constraintsolving techniques and iterative fixpoint algorithms. In spite of the nice mathematical theory of program analysis and the solid algorithmic techniques available one problematic issue persists, viz., the gap between the analysis that is proved correct on paper and the analyser that actually runs on the machine. While this gap might be small for toy languages, it becomes important when it comes to reallife languages for which the implementation and maintenance of program analysis tools become a software engineering task. A certified static analysis is an analysis that has been formally proved correct using a proof assistant.
In previous work we studied the benefit of using abstract interpretation for developing certified static analyses [55] , [77] . The development of certified static analysers is an ongoing activity that will be part of the Celtique project. We use the Coq proof assistant which allows for extracting the computational content of a constructive proof. A Caml implementation can hence be extracted from a proof of existence, for any program, of a correct approximation of the concrete program semantics. We have isolated a theoretical framework based on abstract interpretation allowing for the formal development of a broad range of static analyses. Several case studies for the analysis of Java byte code have been presented, notably a memory usage analysis [56] . This work has recently found application in the context of Proof Carrying Code and have also been successfully applied to particular form of static analysis based on term rewriting and tree automata [4] .
Static analysis of Java
Precise contextsensitive controlflow analysis is a fundamental prerequisite for precisely analysing Java programs. Bacon and Sweeney's Rapid Type Analysis (RTA)Â [48] is a scalable algorithm for constructing an initial callgraph of the program. Tip and PalsbergÂ [80] have proposed a variety of more precise but scalable call graph construction algorithms e.g., MTA, FTA, XTA which accuracy is between RTA and 0'CFA. All those analyses are not contextsensitive. As early as 1991, Palsberg and SchwartzbachÂ [75] , [76] proposed a theoretical parametric framework for typing objectoriented programs in a contextsensitive way. In their setting, contextsensitivity is obtained by explicit code duplication and typing amounts to analysing the expanded code in a contextinsensitive manner. The framework accommodates for both callcontexts and allocationcontexts.
To assess the respective merits of different instantiations, scalable implementations are needed. For Cecil and Java programs, Grove et al.,Â [64] , [63] have explored the algorithmic design space of contexts for benchmarks of significant size. Later on, Milanova et. al.,Â [71] have evaluated, for Java programs, a notion of context called objectsensitivity which abstracts the callcontext by the abstraction of the this pointer. More recently, Lhotak and HendrenÂ [69] have extended the empiric evaluation of objectsensitivity using a BDD implementation allowing to cope with benchmarks otherwise outofscope. Besson and JensenÂ [53] proposed to use datalog in order to specify contextsensitive analyses. Whaley and LamÂ [81] have implemented a contextsensitive analysis using a BDDbased datalog implementation.
Controlflow analyses are a prerequisite for other analyses. For instance, the security analyses of Livshits and LamÂ [70] and the race analysis of Naik, AikenÂ [72] and WhaleyÂ [73] both heavily rely on the precision of a controlflow analysis.
Controlflow analysis allows to statically prove the absence of certain runtime errors such as "message not understood" or cast exceptions. Yet it does not tackle the problem of "null pointers". Fahnrich and LeinoÂ [60] propose a typesystem for checking that after object creation fields are nonnull. Hubert, Jensen and Pichardie have formalised the typesystem and derived a typeinference algorithm computing the most precise typingÂ [67] . The proposed technique has been implemented in a tool called NITÂ [66] . Null pointer detection is also done by bugdetection tools such as FindBugsÂ [66] . The main difference is that the approach of findbugs is neither sound nor complete but effective in practice.
Quantitative aspects of static analysis
Static analyses yield qualitative results, in the sense that they compute a safe overapproximation of the concrete semantics of a program, w.r.t. an order provided by the abstract domain structure. Quantitative aspects of static analysis are twosided: on one hand, one may want to express and verify (compute) quantitative properties of programs that are not captured by usual semantics, such as time, memory, or energy consumption; on the other hand, there is a deep interest in quantifying the precision of an analysis, in order to tune the balance between complexity of the analysis and accuracy of its result.
The term of quantitative analysis is often related to probabilistic models for abstract computation devices such as timed automata or process algebras. In the field of programming languages which is more specifically addressed by the Celtique project, several approaches have been proposed for quantifying resource usage: a nonexhaustive list includes memory usage analysis based on specific type systemsÂ [65] , [47] , linear logic approaches to implicit computational complexityÂ [49] , cost model for Java byte codeÂ [46] based on size relation inference, and WCET computation by abstract interpretation based loop bound interval analysis techniquesÂ [58] .
We have proposed an original approach for designing static analyses computing program costs: inspired from a probabilistic approachÂ [78] , a quantitative operational semantics for expressing the cost of execution of a program has been defined. Semantics is seen as a linear operator over a dioid structure similar to a vector space. The notion of longrun cost is particularly interesting in the context of embedded software, since it provides an approximation of the asymptotic behaviour of a program in terms of computation cost. As for classical static analysis, an abstraction mechanism allows to effectively compute an overapproximation of the semntics, both in terms of costs and of accessible statesÂ [54] . An example of cache miss analysis has been developed within this frameworkÂ [79] .
Certified static analysis
In spite of the nice mathematical theory of program analysis (notably abstract interpretation) and the solid algorithmic techniques available one problematic issue persists, viz., the gap between the analysis that is proved correct on paper and the analyser that actually runs on the machine. While this gap might be small for toy languages, it becomes important when it comes to reallife languages for which the implementation and maintenance of program analysis tools become a software engineering task.
A certified static analysis is an analysis whose implementation has been formally proved correct using a proof assistant. Such analysis can be developed in a proof assistant like CoqÂ [45] by programming the analyser inside the assistant and formally proving its correctness. The Coq extraction mechanism then allows for extracting a Caml implementation of the analyser. The feasibility of this approach has been demonstrated inÂ [6] .
We also develop this technique through certified reachability analysis over term rewriting systems. Term rewriting systems are a very general, simple and convenient formal model for a large variety of computing systems. For instance, it is a very simple way to describe deduction systems, functions, parallel processes or state transition systems where rewriting models respectively deduction, evaluation, progression or transitions. Furthermore rewriting can model every combination of them (for instance two parallel processes running functional programs).
Depending on the computing system modelled using rewriting, reachability (and unreachability) permits to achieve some verifications on the system: respectively prove that a deduction is feasible, prove that a function call evaluates to a particular value, show that a process configuration may occur, or that a state is reachable from the initial state. As a consequence, reachability analysis has several applications in equational proofs used in the theorem provers or in the proof assistants as well as in verification where term rewriting systems can be used to model programs.
For proving unreachability, i.e. safety properties, we already have some results based on the overapproximation of the set of reachable termsÂ [61] , [62] . We defined a simple and efficient algorithmÂ [59] for computing exactly the set of reachable terms, when it is regular, and construct an overapproximation otherwise. This algorithm consists of a completion of a tree automaton, taking advantage of the ability of tree automata to finitely represent infinite sets of reachable terms.
To certify the corresponding analysis, we have defined a checker guaranteeing that a tree automaton is a valid fixpoint of the completion algorithm. This consists in showing that for all term recognised by a tree automaton all his rewrites are also recognised by the same tree automaton. This checker has been formally defined in Coq and an efficient Ocaml implementation has been automatically extractedÂ [4] . This checker is now used to certify all analysis results produced by the regular completion tool as well as the optimised version ofÂ [50] .