Correctness Witnesses with Function Contracts

2025-01-21

AI Summary

The existing Software Verification Witnesses format (v2.0) lacks structured support for function contracts—i.e., preconditions and postconditions—hindering result reproducibility and interoperability across verification tools. Method: We introduce function-contract semantics into the witness format for the first time, extending its XML Schema to support ACSL-style features (e.g., ` esult`, `old`, `at`), thereby overcoming its prior limitation to loop invariants and location assertions. We formally model contract syntax and adapt static analysis tool interfaces to enable standardized, function-level correctness evidence exchange. Contribution/Results: This extension enables precise, tool-agnostic representation of contract-based verification evidence, significantly improving accuracy, trustworthiness, and reproducibility in multi-tool collaborative verification. It establishes a novel paradigm for semantic enhancement and standardization of verification witnesses, advancing interoperable, contract-aware software verification infrastructure.

Technology Category

• Constraint Satisfaction and Optimization: Satisfiability Modulo Theories
• Knowledge Representation and Reasoning: Automated Reasoning and Theorem Proving
• Data Mining & Knowledge Management: Representing, Reasoning, and Using Provenance, Trust

Application Category

• Systems and Infrastructure for Web, Mobile and WoT: Web performance, measurement, and characterization
• Security and Privacy: Data transparency and provenance
• Semantics and Knowledge: Provenance, trust, security and privacy, and ethical issues in managing semantic data

Abstract

Software verification witnesses are a common exchange format for software verification tools. They were developed to provide arguments supporting the verification result, allowing other tools to reproduce the verification results. Correctness witnesses in the current format (version 2.0) allow only for the encoding of loop and location invariants using C expressions. This limits the correctness arguments that verifiers can express in the witness format. One particular limitation is the inability to express function contracts, which consist of a pre-condition and a post-condition for a function. We propose an extension to the existing witness format 2.0 to allow for the specification of function contracts. Our extension includes support for several features inspired by ACSL ( esult, old, at). This allows for the export of more information from tools and for the exchange of information with tools that require function contracts.

Problem

• Software Verification
• Witness Language Limitations
• Inter-tool Communication

Innovation

• Extended Verification Witness
• Function Contract Description
• ACSL-inspired Elements