Instrumenting C Programs With Nested Word Monitors

In classical automata-theoretic model checking of safety properties [6], a system model generates a language L of words modeling system executions, and verification involves checking if L ∩ L′ = ∅, L′ being the language of words deemed “unsafe” by the specification. This view is also used in recent program analyzers like Blast [5] and Slam [2], where a specification is a word automaton (or monitor) with finite-state control-flow that accepts all “unsafe” program executions. Typical analysis constructs the “product” of a program and a monitor, in effect instrumenting the program with extra commands and assertions, so that the input program fails its specification if and only if the product program fails an assertion. The latter is then checked for possible assertion failures. Monitors also find use in testing and runtime verification, where we try finding assertion violations in the product program at runtime