Section: Scientific Foundations

Certified Tools

The goal of this theme is to guarantee the soundness of the tools we develop. Indeed it goes beyond that: our goal is to promote our future Why3 environment so that others could develop certified tools. Tools like automated provers or program analysers are good candidate case studies because they are mainly performing symbolic computations, and as such they are usually programmed in a mostly purely functional style.

We conducted several experiments of development of certified software in the past. First, we have a strong expertise in the development of libraries in Coq: the Coccinelle library  [74] formalizing term rewriting systems, the Alea library  [45] for the formalization of randomized algorithms, several libraries formalizing floating-point numbers (Floats  [58] , Gappalib  [97] , and now Flocq [5] which unifies the formers). Second we recently conducted the development of a certified decision procedure  [93] that corresponds to a core part of Alt-Ergo, and a certified verification condition generator for a language [28] similar to Why. On-going work aims at building, still in Coq, a certified VC generator for C annotated in ACSL  [55] , based on the operational semantics formalized in the CompCert certified compiler project  [92] .

To go further, we have several directions of research in mind.

Formalization of Binders

Using the Why3 programming language instead of Coq allows more freedom. For example, it should allow one to use a bit of side-effects when the underlying algorithm justify it (e.g. hash-consing, destructive unification). On the other hand, we will lose some Coq features like dependent types that are usually useful when formalizing languages. Among the issues that should be studied, we believe that the question of the formalization of binders is both central and challenging (as exemplified by the POPLmark international challenge  [47] ).

The support of binders in Why3 should not be built-in, but should be under the form of a reusable Why3 library, that should already contain a lot of proved lemmas regarding substitution, alpha-equivalence and such. Of course we plan to build upon the former experiments done for the POPLmark challenge. Although, it is not clear yet that the support of binders only via a library will be satisfactory. We may consider addition of built-in constructs if this shows useful. This could be a form of (restricted) dependent types as in Coq, or subset types as in PVS.

Theory Realizations, Certification of Transformations

As an environment for both programming and proving, Why3 should come with a standard library that includes both certified libraries of programs, but also libraries of specifications (e.g. theories of sets, maps, etc.).

The certification of those Why3 libraries of specifications should be addressed too. Why3 libraries for specifying models of programs are commonly expressed using first-order axiomatizations, which have the advantage of being understood by many different provers. However, such style of formalization does not offer strong guarantees of consistency. More generally, the fact that we are calling different kind of provers to discharge our verification conditions raises several challenges for certification: we typically apply various transformations to go from the Why3 language to those of the provers, and these transformations should be certified too.

A first attempt in considering such an issue was done in [29] . It was proposed to certify the consistency of a library of specification using a so-called realization, which amounts to “implementing” the library in a proof assistant like Coq. This will be an important topic of the new ANR project BWare.

Certified Theorem Proving

The goal is to develop certified provers, in the sense that they are proved to give a correct answer. This is an important challenge since there have been a significant amount of soundness bugs discovered in the past, in many tools of this kind.

The former work on the certified core of Alt-Ergo  [93] should be continued to support more features: more theories (full integer arithmetic, real arithmetic, arrays, etc.), quantifiers. Development of a certified prover that supports quantifiers should build upon the previous topic about binders.

In a similar way, the Gappa prover which is specialized to solving constraints on real numbers and floating-point numbers should be certified too. Currently, Gappa can be asked to produce a Coq proof of its given goal, so as to check a posteriori its soundness. Indeed, the idea of producing a trace is not contradictory with certifying the tool. For very complex decision procedures, the goal of developing a certified proof search might be too ambitious, and the production of an internal trace is a general technique that might be used as a workaround: it suffices to instrument the proof search and to develop a certified trace checker to be used by the tool before it gives an answer. We used this approach in the past for certified proofs of termination of rewriting systems  [75] . This is also a technique that is used internally in CompCert for some passes of compilation  [92] .

Certified VC generation

The other kind of tools that we would like to certify are the VC generators. This will be a continuation of the on-going work on developing in Coq a certified VC generator for C code annotated in ACSL. We would like to develop such a generator in Why3 instead of Coq. As before, this will build upon a formalization of binders.

There are various kinds of VC generators that are interesting. A generator for a simple language in the style of those of Why3 is a first step. Other interesting cases are: a generator implementing the so-called fast weakest preconditions  [91] , and a generator for unstructured programs like assembly, that would operate on an arbitrary control-flow graph.

On a longer term, it would be interesting to be able to certify advanced verification methods like those involving refinement, alias control, regions, permissions, etc.

An interesting question is how one could certify a VC generator that involves a highly expressive logic, like higher-order logic, as it is the case of the CFML method  [70] which allows one to use the whole Coq language to specify the expected behavior. One challenging aspect of such a certification is that a tool that produces Coq definitions, including inductive definitions and module definitions, cannot be directly proved correct in Coq, because inductive definitions and module definitions are not first-class objects in Coq. Therefore, it seems necessary to involve, in a way or another, a “deep embedding”, that is, a formalization of Coq in Coq, possibly by reusing the deep embedding developed by B. Barras [52] .