Section: Scientific Foundations
Proof of Imperative and Object-Oriented programs
Participants : Romain Bardou, François Bobot, Sylvie Boldo, Jean-Christophe Filliâtre, Johannes Kanig, Claude Marché, Yannick Moy, Christine Paulin-Mohring, Wendi Urribarrí.
A foundation step of the project is the PhD thesis of Jean-Christophe Filliâtre [5] that proposes to establish soundness of a program with imperative features (assignments, while loops, but also exceptions and exception handlers) by means of a translation into an equivalent purely functional program with logical annotations. Such an annotated functional program is very-well suited to be expressed in Coq 's type theory, hence this approach allowed for the first time to prove imperative programs with Coq [85] .
Following this thesis, a new tool called Why was developed. It takes as input an imperative program and a specification that this program is expected to fulfil. It produces on one hand a set of verification conditions (VCs): logical formulas which have to be proved in the Coq system ; and on the other hand a Coq -term which contains a functional translation of the imperative program and a proof of correctness of this program based on the VCs. It was early remarked that this tool was independent of Coq , because the VCs can be validated in other interactive tools (such as PVS, Isabelle/HOL, etc.) or with automatic provers (such as Simplify, SMT solvers, etc.). This multi-prover architecture is a powerful feature of Why : it spreads this technology well beyond the Coq community.
Since 2002, we tackle programs written in “real” programming languages. We first considered Java source code annotated with JML (Java Modeling Language). This method was implemented in a new tool called Krakatoa [10] . The approach is based on a translation from annotated Java programs into the specific language of Why , we then can reuse Why 's VCG mechanism and choose between different provers for establishing these VCs.
From 2003, we followed the same approach for programs written in ANSI C, in collaboration with Gemalto company and Dassault Aviation company, and started the development of a tool called Caduceus [7] .
The Why platform
We develop a platform combining several of our own tools and other ones. The tool playing the central role in our platform is Why , implementing the proof of programs approach proposed by Jean-Christophe Filliâtre [5] . The programs handled by Why are written in a specific language, they are annotated with pre and post conditions (similar to classical Hoare's logic). Why generates VCs, the validity of which ensures correctness of the program with respect to the original specification. In Why , these VCs are first-order formula that can be translated into the syntax of different provers: interactive higher-order provers like Coq , PVS, HOL-light or Mizar or automatic provers such as Simplify, Alt-Ergo , haRVey or SMT provers (Yices, Z3, CVC3). This multi-prover architecture is clearly a strong advantage of the tool. Why is a tool which is regularly evolving. We integrate aspects which are not necessarily in the theory but which are needed for practical applications.
We develop Why front-ends for dealing with real C or Java source code. Our approach is based on a translation from source code into an equivalent program written in Why , leading to the architecture shown in Figure 1 . The central issue for the design of our platform is the modeling of memory heap for Java and C programs, handling possible aliasing (two different pointer or object expressions representing the same memory location): the Why tool does not handle aliasing by itself, indeed it does not support any form of complex data structures like objects, structures, pointers. On the other hand, Why supports declaration of a kind of algebraic specifications: abstract data types specified by first-order functions, predicates and axioms. As a consequence, there is a general approach for using Why as a target language for programming the semantics of higher-level programming languages [98] . The Krakatoa and the Caduceus memory models are inspired by the `component-as-array' representation due to Bornat, following an old idea from Burstall, and commonly used to verify pointers programs. Each field declaration f in a Java class or a C structure introduces a Why variable Mf in the model, which is a map (or an array) indexed by addresses. We extended this idea to handle Java arrays and JML annotations [10] and pointer arithmetic in C [7] .
The Frama-C Platform
We are developing, in collaboration with CEA-List, a platform called Frama-C for static analysis of C programs (http://www.frama-c.cea.fr/ ). This platform has an open architecture, structured as plugins around a shared kernel. The kernel reuse the CIL software from Berkeley University (USA) for parsing and typing C source code and annotations. Plugins include abstract interpretation techniques (analyses of values, aliasing, effects), Verification Condition Generators, code slicing. In particular, a part of our Why platform called Jessie is available as a Frama-C plugin.
This platform is under development, as part of the ANR CAT project, and is distributed under open-source licence.
Applications and case studies
The techniques we are developing can be naturally applied in domains which require to develop critical software for which there is a high need of certification.
The Krakatoa tool was successfully used for the formal verification of a commercial smart card applet [89] proposed by Gemalto. This case study have been conducted in collaboration with LOOP and Jive groups. Banking applications are concerned with security problems that can be the confidentiality and protection of datas, authentication, etc. The translation of such specifications into assertions in the source code of the program is an essential problem. We have been working on a Java Card applet for an electronic purse Demoney [62] developed by the company Trusted Logic for experimental purpose. Other Java Card case studies have been conducted in collaboration with Gemalto by J. Andronick and N. Rousset, in particular on global properties and Java Card transactions [46] , [96] .
To illustrate the effectiveness of the Caduceus tool, T. Hubert and C. Marché performed a full verification of a C implementation of the Schorr-Waite algorithm [8] , using Caduceus and Coq . This is an allocation-free graph-marking algorithm used in garbage collectors, which is considered as a benchmark for verification tools. Other case studies have been investigated by T. Hubert (with Dassault Aviation) and by Y. Moy (with France Telecom).
