0508108 - arXiv:cs/0508108v1 [cs.SE] 24 Aug 2005 Proving or...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: arXiv:cs/0508108v1 [cs.SE] 24 Aug 2005 Proving or Disproving Likely Invariants with Constraint Reasoning Tristan Denmat 1 , Arnaud Gotlieb 2 , and Mireille Ducass e 1 1 IRISA/INSA 2 IRISA/INRIA Campus universitaire de Beaulieu 35042 Rennes Cedex, France { denmat,gotlieb,ducasse } @irisa.fr Abstract A program invariant is a property that holds for every execu- tion of the program. Recent work suggest to infer likely-only invariants, via dynamic analysis. A likely invariant is a property that holds for some executions but is not guaranteed to hold for all executions. In this pa- per, we present work in progress addressing the challenging problem of automatically verifying that likely invariants are actual invariants. We propose a constraint-based reasoning approach that is able, unlike other approaches, to both prove or disprove likely invariants. In the latter case, our approach provides counter-examples. We illustrate the approach on a motivating example where automatically generated likely invariants are verified. 1 Introduction A program invariant is a property that holds over every execution of the program. Examples of program invariants include loop invariants pre- sented by Hoare in the weakest precondition calculus [12] or pre-post con- ditions of the design by contracts approach [14]. Invariants have proved to be crucial in various fields of software engineering such as specifica- tion refinement, software evolution or software verification. Unfortunately, writing invariants is a tedious task and few programmers write program invariants by themselves. In order to palliate this problem, a trend of research aims at inferring invariants a posteriori . In this case, invariants correspond to the actual behaviors of programs, not to their intended behaviors. A common approach is to use static analysis, which infers invariants from the source code. For example, abstract interpretation-based analyses In A. Serebrenik and S. Munoz-Hernandez (editors), Proceedings of the 15th Work- shop on Logic-based methods in Programming Environments, October 2005, Spain. COmputer Research Repository (http://www.acm.org/corr/), cs.SE/0508108; whole proceedings: cs.PL/0508078. 2 generate different kinds of invariants, depending on the abstract domain used : intervals [3], polyhedra [4] or octagons [15], to name a few. These methods generate sound invariants but the abstractions used to address problems of termination and complexity may lead to a weak accuracy. Ernst et al. introduced Daikon, a tool performing dynamic inference of properties using actual values computed during program executions [6]. The advantage is that the generated properties are in general more precise than those generated with a static inference. The drawback of this method is that the properties may not hold for particular executions....
View Full Document

This note was uploaded on 02/24/2012 for the course CSE 503 taught by Professor Davidnotikin during the Spring '11 term at University of Washington.

Page1 / 15

0508108 - arXiv:cs/0508108v1 [cs.SE] 24 Aug 2005 Proving or...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online