Results 11 - 20
of
41
A Hoare Logic for Call-by-Value Functional Programs
"... Abstract. We present a Hoare logic for a call-by-value programming language equipped with recursive, higher-order functions, algebraic data types, and a polymorphic type system in the style of Hindley and Milner. It is the theoretical basis for a tool that extracts proof obligations out of programs ..."
Abstract
-
Cited by 11 (1 self)
- Add to MetaCart
Abstract. We present a Hoare logic for a call-by-value programming language equipped with recursive, higher-order functions, algebraic data types, and a polymorphic type system in the style of Hindley and Milner. It is the theoretical basis for a tool that extracts proof obligations out of programs annotated with logical assertions. These proof obligations, expressed in a typed, higher-order logic, are discharged using off-theshelf automated or interactive theorem provers. Although the technical apparatus that we exploit is by now standard, its application to callby-value functional programming languages appears to be new, and (we claim) deserves attention. As a sample application, we check the partial correctness of a balanced binary search tree implementation. 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 8 (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
Handling polymorphism in automated deduction
- In 21th International Conference on Automated Deduction (CADE-21), 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 8 (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 SMT-LIB ones do not handle polymorphism. To this end, we present efficient reductions of polymorphism in both unsorted and many-sorted 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
Varieties of Static Analyzers: A Comparison with ASTRÉE
"... We discuss the characteristic properties of ASTRÉE, an automatic static analyzer for proving the absence of runtime errors in safety-critical real-time synchronous controlcommand C programs, and compare it with a variety of other program analysis tools. 1 ..."
Abstract
-
Cited by 8 (2 self)
- Add to MetaCart
We discuss the characteristic properties of ASTRÉE, an automatic static analyzer for proving the absence of runtime errors in safety-critical real-time synchronous controlcommand C programs, and compare it with a variety of other program analysis tools. 1
Implementing Polymorphism in SMT solvers ∗
"... Based on our experience with the development of Alt-Ergo, 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 8 (1 self)
- Add to MetaCart
Based on our experience with the development of Alt-Ergo, 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
A unified memory model for pointers
- 12th International Conference on Logic for Programming Artificial Intelligence and Reasoning (LPAR-12), volume 3835 of LNCS
, 2005
"... Abstract. One of the challenges in verifying systems level code is the low-level, untyped view of the machine state that operating systems have. We describe a way to faithfully formalise this view while at the same time providing an easy-to-use, abstract and typed view of memory where possible. We h ..."
Abstract
-
Cited by 7 (4 self)
- Add to MetaCart
Abstract. One of the challenges in verifying systems level code is the low-level, untyped view of the machine state that operating systems have. We describe a way to faithfully formalise this view while at the same time providing an easy-to-use, abstract and typed view of memory where possible. We have used this formal memory model to verify parts of the virtual memory subsystem of the L4 high-performance microkernel. All formalisations and proofs have been carried out in the theorem prover Isabelle and the verified code has been integrated into the current implementation of L4. 1
HOL-Boogie -- An Interactive Prover for the Boogie Program-Verifier
"... Boogie is a program verification condition generator for an imperative core language. It has front-ends for the programming languages C# and C enriched by annotations in first-order logic. Its verification conditions — constructed via a wp calculus from these annotations — are usually transferred to ..."
Abstract
-
Cited by 7 (1 self)
- Add to MetaCart
Boogie is a program verification condition generator for an imperative core language. It has front-ends for the programming languages C# and C enriched by annotations in first-order 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, HOL-Boogie, 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 proof-environment 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 data-types used in annotations as well as memory and machine models underlying the verification method for C.
Sufficient preconditions for modular assertion checking
- In: VMCAI’08. LNCS
, 2008
"... Abstract. Assertion checking is the restriction of program verification to validity of program assertions. It encompasses safety checking, which is program verification of safety properties, like memory safety or absence of overflows. In this paper, we consider assertion checking of program parts in ..."
Abstract
-
Cited by 6 (0 self)
- Add to MetaCart
Abstract. Assertion checking is the restriction of program verification to validity of program assertions. It encompasses safety checking, which is program verification of safety properties, like memory safety or absence of overflows. In this paper, we consider assertion checking of program parts instead of whole programs, which we call modular assertion checking. Classically, modular assertion checking is possible only if the context in which a program part is executed is known. By default, the worst-case context must be assumed, which may impair the verification task. It usually takes user effort to detail enough the execution context for the verification task to succeed, by providing strong enough preconditions. We propose a method to automatically infer sufficient preconditions in the context of interpretation, weakest precondition calculus and quantifier elimination. We instantiate this method to prove memory safety for C and Java programs, under some memory separation conditions. 1
Combining Coq and Gappa for Certifying Floating-Point 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 6 (0 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 general-purpose logic but that lack proof automation for floating-point 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 floating-point programs. 1
A scalable memory model for low-level code
- In Conf. on Verification, Model Checking and Abstract Interpretation (VMCAI
, 2009
"... Abstract. Because of its critical importance underlying all other software, lowlevel system software is among the most important targets for formal verification. Low-level systems software must sometimes make type-unsafe memory accesses, but because of the vast size of available heap memory in today ..."
Abstract
-
Cited by 6 (2 self)
- Add to MetaCart
Abstract. Because of its critical importance underlying all other software, lowlevel system software is among the most important targets for formal verification. Low-level systems software must sometimes make type-unsafe memory accesses, but because of the vast size of available heap memory in today’s computer systems, faithfully representing each memory allocation and access does not scale when analyzing large programs. Instead, verification tools rely on abstract memory models to represent the program heap. This paper reports on two related investigations to develop an accurate (i.e., providing a useful level of soundness and precision) and scalable memory model: First, we compare a recently introduced memory model, specifically designed to more accurately model low-level memory accesses in systems code, to an older, widely adopted memory model. Unfortunately, we find that the newer memory model scales poorly compared to the earlier, less accurate model. Next, we investigate how to improve the soundness of the less accurate model. A direct approach is to add assertions to the code that each memory access does not break the assumptions of the memory model, but this causes verification complexity to blow-up. Instead, we develop a novel, extremely lightweight static analysis that quickly and conservatively guarantees that most memory accesses safely respect the assumptions of the memory model, thereby eliminating almost all of these extra type-checking assertions. Furthermore, this analysis allows us to create automatically memory models that flexibly use the more scalable memory model for most of memory, but resorting to a more accurate model for memory accesses that might need it. 1

