Book contents
- Frontmatter
- Dedication
- Contents
- Road map
- Acknowledgments
- 1 Introduction
- I Generic separation logic
- II Higher order separation logic
- III Separation logic for CompCert
- 22 Verifiable C
- 23 Expressions, values, and assertions
- 24 The VST separation logic for C light
- 25 Typechecking for Verifiable C
- 26 Derived rules and proof automation for C light
- 27 Proof of a program
- 28 More C programs
- 29 Dependently typed C programs
- 30 Concurrent separation logic
- IV Operational semantics of CompCert
- V Higher-order semantic models
- VI Semantic model and soundness of Verifiable C
- VII Applications
- Bibliography
- Index
25 - Typechecking for Verifiable C
from III - Separation logic for CompCert
Published online by Cambridge University Press: 05 August 2014
- Frontmatter
- Dedication
- Contents
- Road map
- Acknowledgments
- 1 Introduction
- I Generic separation logic
- II Higher order separation logic
- III Separation logic for CompCert
- 22 Verifiable C
- 23 Expressions, values, and assertions
- 24 The VST separation logic for C light
- 25 Typechecking for Verifiable C
- 26 Derived rules and proof automation for C light
- 27 Proof of a program
- 28 More C programs
- 29 Dependently typed C programs
- 30 Concurrent separation logic
- IV Operational semantics of CompCert
- V Higher-order semantic models
- VI Semantic model and soundness of Verifiable C
- VII Applications
- Bibliography
- Index
Summary
Most presentations of Hoare logics assume that expressions (in a current environment) are interchangeable with their values. Implicit in this presentation is that every expression evaluates to a value in the evaluation relation. This is convenient for users of these logics in accomplishing program verification: connecting a program with a mathematical specification.
Unfortunately, C expressions do not always evaluate to values (and occasionally evaluate to unusable values). Although this occurs only in limited and predictable cases, we do not want to lose the power to reason about expressions and values interchangeably in the many cases where expressions can be statically guaranteed to evaluate. We will avoid the cases where expressions may not evaluate, because we will show that they do not arise in verified programs. We integrate a typechecker with our Hoare-logic rules to detect these cases, and (mostly) restore the link between expressions and values.
CompCert's inductive definition of eval_expr does not assume that expressions always evaluate. CompCert denotes failure to evaluate by omitting tuples from the inductive definition of the compcert.Clight.eval-expr relation, following standard principles of contemporary structural operational semantics. In program verification, however, the cost to using an inductive definition is that in order to relate an expression to a value you must say something like: ∃ν. e ⇓ ν Λ P(ν), “there exists some value such that e evaluates to ν and P holds on ν.”
- Type
- Chapter
- Information
- Program Logics for Certified Compilers , pp. 173 - 183Publisher: Cambridge University PressPrint publication year: 2014