Function contracts improve checking C programs with loops and calls
Function Contracts for Bounded Model Checking of C Programs
Software Engineering
Summary
Checking C programs that have loops inside functions can create big challenges because the checking tool has to handle the loop multiple times for each function call. The authors introduced a way to describe what a function is allowed to change using contracts, so the checking tool can verify the function once and then just trust parts of the contract later. This makes the checking faster and uses less memory. They built this approach into an existing tool called ESBMC and showed it works well on different real-world programs and benchmarks.
What this means in practice
- •For embedded software engineers: Verify complex C programs with loops more efficiently by using function contracts to reduce solver workload during model checking.
- •For security software developers: Check critical software modules like cryptographic parsers and memory allocators more feasibly by modular verification using contract-based checking.
Authors
Weiqi Wang, Marie Farrell, Liping Zhao, Lucas C. Cordeiro
Abstract
Bounded model checking unrolls a program into a single formula, so a function holding a loop costs the solver a fresh copy of that loop at every call site. Function contracts break that coupling. Verify the body once against its contract, then replace each call by a stub derived from it. CBMC supports this through dynamic frame condition checking, applied at industrial scale, but with no formal account of why the replacement is sound and no characterisation of what the frame check costs. We present the function-contract framework for ESBMC. The clause syntax, both phases, and the first assigns enforcement the tool has had are all introduced here. Its technical core is an observational frame rule: snapshot the locations the contract does not permit the function to write, then compare them at exit. The encoding emits a number of verification conditions set by how many globals the program has, not by how many writes the body performs, while dynamic frame condition checking grows with the write count. That is a property of the encoding rather than a timing, so it moves with neither the machine nor the solver. The rule itself is the classical one; what we add is its bounded form inside a BMC encoding, with the pipeline's algebraic skeleton machine-checked in Lean 4 and the limits of that model stated. We evaluate on synthetic sweeps, SV-COMP tasks, an ANSSI X.509 parser, the FreeRTOS heap_1 allocator, and the ML-KEM reference implementation whose CBMC contracts we reuse unchanged. At the coefficient count FIPS-203 mandates, neither tool finishes on the monolithic route inside ten minutes, and both finish on the modular one. The framework is merged into ESBMC master. Contracts are what is left when unrolling runs out of room.