Context Generation from Formal Specifications for C Analysis Tools

Abstract

Analysis tools like abstract interpreters, symbolic execution tools and testing tools usually require a proper context to give useful results when analyzing a particular function. Such a context initializes the function parameters and global variables to comply with function requirements. However it may be error-prone to write it by hand: the handwritten context might contain bugs or not match the intended specification. A more robust approach is to specify the context in a dedicated specification language, and hold the analysis tools to support it properly. This may mean to put significant development efforts for enhancing the tools, something that is often not feasible if ever possible.

This paper presents a way to systematically generate such a context from a formal specification of a C function. This is applied to a subset of the ACSL specification language in order to generate suitable contexts for the abstract interpretation-based value analysis plug-ins of Frama-C, a framework for analysis of code written in C. The idea here presented has been implemented in a new Frama-C plug-in which is currently in use in an operational industrial setting.

M. Alberti—This work was done when the first author was at CEA LIST, Software Reliability and Security Laboratory.

A Response to Reviewer Comments

1.1 A.1 Reviewer 1

• The reviewer points out that one important issue has not been addressed in the paper: how our code generation might be tailored for.

  The reviewer is right. While we argue in the introduction that our system may be used for different analysis techniques, this is not demonstrated in the paper since CfP has only been evaluated with 2 different abstract interpreters for the time being. We are however confident about the possible tailoring because the theoretical construction, which is the core of our work, remains the same. Also, adapting the code generator to other settings would not require many efforts, even if we leave it as future work. We have clarified our stance by adding in the Conclusion the following sentence:

  “It [Future work] also includes evaluating the presented system for different techniques such as symbolic execution or testing tools.”

• The reviewer assumes we rely implicitly on some formal semantics, and thinks that it would be better to specify them in the paper.

  Indeed, Theorem 1 relies on a formal definition of $\varSigma \,\models \, \mathcal {C}$, while we only provide its intuition in the paper. The formal definition has been omitted because we have not enough room to add it and because it does not represent the core of our system. It should be clearer now because we have added “, its formal definition being omitted here” after introducing symbol $\models$.

• The reviewer thinks that work for code generation from executable specification languages should be mentioned as well (notably, Lustre and logic synthesis in hardware).

  We have added a brief comparison with Lustre, but none for logic synthesis in hardware. Indeed our paper already referred to program synthesis, which is closer to our work that logic synthesis in hardware, while still quite different.

1.2 A.2 Reviewer 2

• The only reviewer’s important comment is about a lack of precision in our sentence “For a 64-bit architecture, 256 bytes is the size of 64 values of type unsigned long.”. The reviewer is right. We have rewritten the sentence as follows: “Assuming that the size of unsigned long is 4 bytes, 256 bytes is the size of 64 values of type unsigned long.”

  Previously, in the same section, we have also rewritten “(assuming a 64-bit architecture)” by “(assuming that the size of unsigned long is 4 bytes)” and we have added a footnote indicating that this kind of system-dependent information is customizable within Frama-C.

• All the reviewer’s minor comments and typos have been addressed.

1.3 A.3 Reviewer 3

• The only reviewer’s concern is that the paper gives no evidence of generating code from specifications of other functions besides that from the initial motivating example. (S)he has consequently related questions.

  We have extended the first paragraph of Sect. 5 (Implementation and Evaluation) as follows:

  “In this latter use case, CfP is used, among others, to generate contexts for customizing the initialization of structure md5_context needed by functions md5_starts, md5_update and md5_process. This structure is defined as follows.

  <code example added>”

  Also, we have extended the paragraph explaining why DNF explosion is not an issue in practice as follow: “Concretely, CfP and its use in combination with TIS-Analyzer or EVA have never suffered from the state-explosion problem or any other unefficiency issue in practice.”

1.4 A.4 Other Improvements

• Several minor changes (fixing typos, or using better/more standard math symbols) have been made.