Common specification language for static and dynamic analysis of C programs

Abstract

Various combinations of static and dynamic analysis techniques were recently shown to be beneficial for software verification. A frequent obstacle to combining different tools in a completely automatic way is the lack of a common specification language. Our work proposes to translate a Pre-Post based specification into executable C code. This paper presents E-ACSL, subset of the ACSL specification language for C programs, and its automatic translator into C implemented as a FRAMA-C plug-in. The resulting C code is executable and can be used by a dynamic analysis tool. We illustrate how the PATHCRAWLER test generation tool automatically treats such pre-and postconditions specified as C functions.

First international Competition on Runtime Verification: rules, benchmarks, tools, and final results of CRV 2014

“…E-ACSL [41] (Executable ANSI/ISO C Specification Language) is both a formal specification language and a monitoring tool which are designed and developed at CEA LIST, Software Security Labs. They are integrated to the Frama-C platform [63], which is an extensible and collaborative platform dedicated to source-code analysis of C software.…”

“…In the formal specification language E-ACSL [41] based on behavioral first-order logic, this specification may be described by the following function contract: The first requires clause states that each cell of the array must be correctly allocated, the second one states that the array must be sorted, and the third one indicates that the length must be positive. Then, the first behavior says that if the searched key exists in the array, the result of the function must be an array index corresponding to this key, while the second behavior says that the function returns -1 if there is no such index.…”

“…In the formal specification language E-ACSL [41] based on behavioral first-order logic, this specification may be described by the following function contract: The two first requirements indicate that the lengths l1 and l2 of the input arrays t1 and t2 must be positive, while the two other requirements say that these arrays must be sorted. If the requirements of the function are satisfied, it must ensure 4 postcondition provided by the ensures clause.…”

“…Specification-based trace analysis is a topic of particular interest due to the many different logics and supporting tools that have been developed over the last decade, including the following to just mention a few [5,6,9,10,28,34,36,38,41,42,44,50,67,70,71,74,75]. Unlike proof-oriented techniques, such as theorem proving or model checking, that aim to verify exhaustively whether a property is satisfied for all the possible system executions, specification-based RV automatically checks only if a single execution trace is correct, and it therefore does not suffer from the classic manual labor and state-explosion problems, typically associated with theorem proving and model checking.…”

Third International Competition on Runtime Verification

“…In the following of this section, we provide a short overview of the tools involved in the competition. We note that the E-ACSL tool [7] from CEA LIST, France entered the C track but was the only tool to do so.…”