## 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] .