Results 11  20
of
48
A case study of C source code verification: the SchorrWaite algorithm
 In 3rd IEEE Intl. Conf. SEFM’05
, 2005
"... We describe an experiment of formal verification of C source code, using the CADUCEUS tool. We performed a full formal proof of the classical SchorrWaite graphmarking algorithm, which has already been used several times as a case study for formal reasoning on pointer programs. Our study is origina ..."
Abstract

Cited by 13 (0 self)
 Add to MetaCart
We describe an experiment of formal verification of C source code, using the CADUCEUS tool. We performed a full formal proof of the classical SchorrWaite graphmarking algorithm, which has already been used several times as a case study for formal reasoning on pointer programs. Our study is original with respect to previous experiments for several reasons. First, we use a generalpurpose tool for C programs: we start from a real source code written in C, specified using an annotation language for arbitrary C programs. Second, we use several theorem provers as backends, both automatic and interactive. Third, we indeed formally establish more properties of the algorithm than previous works, in particular a formal proof of termination is made 1. Keywords: Formal verification, FloydHoare logic, Pointer programs, Aliasing, C programming language. The SchorrWaite algorithm is the first moutain that any formalism for pointer aliasing should climb. — Richard Bornat ([4], page 121) 1.
Combining Coq and Gappa for Certifying FloatingPoint Programs ⋆
"... Abstract. Formal verification of numerical programs is notoriously difficult. On the one hand, there exist automatic tools specialized in floatingpoint arithmetic, such as Gappa, but they target very restrictive logics. On the other hand, there are interactive theorem provers based on the LCF approa ..."
Abstract

Cited by 12 (1 self)
 Add to MetaCart
Abstract. Formal verification of numerical programs is notoriously difficult. On the one hand, there exist automatic tools specialized in floatingpoint arithmetic, such as Gappa, but they target very restrictive logics. On the other hand, there are interactive theorem provers based on the LCF approach, such as Coq, that handle a generalpurpose logic but that lack proof automation for floatingpoint properties. To alleviate these issues, we have implemented a mechanism for calling Gappa from a Coq interactive proof. This paper presents this combination and shows on several examples how this approach offers a significant speedup in the process of verifying floatingpoint programs. 1
Handling polymorphism in automated deduction
 In 21th International Conference on Automated Deduction (CADE21), volume 4603 of LNCS (LNAI
, 2007
"... Abstract. Polymorphism has become a common way of designing short and reusable programs by abstracting generic definitions from typespecific ones. Such a convenience is valuable in logic as well, because it unburdens the specifier from writing redundant declarations of logical symbols. However, top ..."
Abstract

Cited by 12 (1 self)
 Add to MetaCart
Abstract. Polymorphism has become a common way of designing short and reusable programs by abstracting generic definitions from typespecific ones. Such a convenience is valuable in logic as well, because it unburdens the specifier from writing redundant declarations of logical symbols. However, top shelf automated theorem provers such as Simplify, Yices or other SMTLIB ones do not handle polymorphism. To this end, we present efficient reductions of polymorphism in both unsorted and manysorted first order logics. For each encoding, we show that the formulas and their encoded counterparts are logically equivalent in the context of automated theorem proving. The efficiency keynote is to disturb the prover as little as possible, especially the internal decision procedures used for special sorts, e.g. integer linear arithmetic, to which we apply a special treatment. The corresponding implementations are presented in the framework of the Why/Caduceus toolkit. 1
Formal Translation of Bytecode into BoogiePL
 BYTECODE
, 2007
"... Many modern program verifiers translate the program to be verified and its specification into a simple intermediate representation and then compute verification conditions on this representation. Using an intermediate language improves the interoperability of tools and facilitates the computation of ..."
Abstract

Cited by 10 (1 self)
 Add to MetaCart
Many modern program verifiers translate the program to be verified and its specification into a simple intermediate representation and then compute verification conditions on this representation. Using an intermediate language improves the interoperability of tools and facilitates the computation of small verification conditions. Even though the translation into an intermediate representation is critical for the soundness of a verifier, this step has not been formally verified. In this paper, we formalize the translation of a small subset of Java bytecode into an imperative intermediate language similar to BoogiePL. We prove soundness of the translation by showing that each bytecode method whose BoogiePL translation can be verified, can also be verified in a logic that operates directly on bytecode.
Expressing Polymorphic Types in a ManySorted Language
, 2011
"... Abstract. In this paper, we study translation from a firstorder logic with polymorphic types à la ML (of which we give a formal description) to a manysorted or onesorted logic as accepted by mainstream automated theorem provers. We consider a threestage scheme where the last stage eliminates pol ..."
Abstract

Cited by 10 (1 self)
 Add to MetaCart
Abstract. In this paper, we study translation from a firstorder logic with polymorphic types à la ML (of which we give a formal description) to a manysorted or onesorted logic as accepted by mainstream automated theorem provers. We consider a threestage scheme where the last stage eliminates polymorphic types while adding the necessary “annotations” to preserve soundness, and the first two stages serve to protect certain terms so that they can keep their original unannotated form. This protection allows us to make use of provers ’ builtin theories and operations. We present two existing translation procedures as sound and complete instances of this generic scheme. Our formulation generalizes over the previous ones by allowing us to protect terms of arbitrary monomorphic types. In particular, we can benefit from the builtin theory of arrays in SMT solvers such as Z3, CVC3, and Yices. The proposed methods are implemented in the Why3 tool and we compare their performance in combination with several automated provers. 1
Implementing Polymorphism in SMT solvers ∗
"... Based on our experience with the development of AltErgo, we show a small number of modifications needed to bring parametric polymorphism to our SMT solver. The first one occurs in the typing module where unification is now necessary for solving polymorphic constraints over types. The second one con ..."
Abstract

Cited by 10 (1 self)
 Add to MetaCart
Based on our experience with the development of AltErgo, we show a small number of modifications needed to bring parametric polymorphism to our SMT solver. The first one occurs in the typing module where unification is now necessary for solving polymorphic constraints over types. The second one consists in extending triggers ’ definition in order to deal with both term and type variables. Last, the matching module must be modified to account for the instantiation of type variables. We hope that this experience is convincing enough to raise interest for polymorphism in the SMT community. 1
HOLBoogie  An Interactive Prover for the Boogie ProgramVerifier
"... Boogie is a program verification condition generator for an imperative core language. It has frontends for the programming languages C# and C enriched by annotations in firstorder logic. Its verification conditions — constructed via a wp calculus from these annotations — are usually transferred to ..."
Abstract

Cited by 9 (1 self)
 Add to MetaCart
Boogie is a program verification condition generator for an imperative core language. It has frontends for the programming languages C# and C enriched by annotations in firstorder logic. Its verification conditions — constructed via a wp calculus from these annotations — are usually transferred to automated theorem provers such as Simplify or Z3. In this paper, however, we present a proofenvironment, HOLBoogie, that combines Boogie with the interactive theorem prover Isabelle/HOL. In particular, we present specific techniques combining automated and interactive proof methods for codeverification. We will exploit our proofenvironment in two ways: First, we present scenarios to "debug" annotations (in particular: invariants) by interactive proofs. Second, we use our environment also to verify "background theories", i.e. theories for datatypes used in annotations as well as memory and machine models underlying the verification method for C.
Mind the Gap A Verification Framework for LowLevel C
"... Abstract. This paper presents the formal Isabelle/HOL framework we use to prove refinement between an executable, monadic specification and the C implementation of the seL4 microkernel. We describe the refinement framework itself, the automated tactics it supports, and the connection to our previous ..."
Abstract

Cited by 9 (5 self)
 Add to MetaCart
Abstract. This paper presents the formal Isabelle/HOL framework we use to prove refinement between an executable, monadic specification and the C implementation of the seL4 microkernel. We describe the refinement framework itself, the automated tactics it supports, and the connection to our previous C verification framework. We also report on our experience in applying the framework to seL4. The characteristics of this microkernel verification are the size of the target (8,700 lines of C code), the treatment of lowlevel programming constructs, the focus on high performance, and the large subset of the C programming language addressed, which includes pointer arithmetic and typeunsafe code. 1
A Glimpse of a Verifying C Compiler – Extended Abstract –
"... The goal of the Verifying C Compiler project is to bring design by contract to C. More specifically, we are developing a verifying compiler, code name vcc, that takes annotated C programs, generates logical verification conditions from them and passes those verification conditions on to an automatic ..."
Abstract

Cited by 9 (2 self)
 Add to MetaCart
The goal of the Verifying C Compiler project is to bring design by contract to C. More specifically, we are developing a verifying compiler, code name vcc, that takes annotated C programs, generates logical verification conditions from them and passes those verification conditions on to an automatic theorem prover to either prove the correctness of the program or find errors in it. C Intricacies. The vcc compiler is designed to support the verification of operating system code. As a consequence it does not only handle the type safe subset of C, but also deals with pointer arithmetic, reinterpretation of data and volatile data access. This flexibility is for example needed to verify low level system code like memory allocators, where data is interpreted in different ways by different parts of the system, or to verify algorithms implemented over polymorphic compare and swap operations. The vcc compiler uses different background axiomatizations to abstract from C’s implementation defined behavior. For example the size of character type, or how integers are implemented (typically two’s complement) is dealt with not by
Extending the Loop Language with HigherOrder Procedural Variables
 Special issue of ACM TOCL on Implicit Computational Complexity
, 2010
"... We extend Meyer and Ritchie’s Loop language with higherorder procedures and procedural variables and we show that the resulting programming language (called Loop ω) is a natural imperative counterpart of Gödel System T. The argument is twofold: 1. we define a translation of the Loop ω language int ..."
Abstract

Cited by 9 (6 self)
 Add to MetaCart
We extend Meyer and Ritchie’s Loop language with higherorder procedures and procedural variables and we show that the resulting programming language (called Loop ω) is a natural imperative counterpart of Gödel System T. The argument is twofold: 1. we define a translation of the Loop ω language into System T and we prove that this translation actually provides a lockstep simulation, 2. using a converse translation, we show that Loop ω is expressive enough to encode any term of System T. Moreover, we define the “iteration rank ” of a Loop ω program, which corresponds to the classical notion of “recursion rank ” in System T, and we show that both translations preserve ranks. Two applications of these results in the area of implicit complexity are described. 1