Extended static checking: Difference between revisions

Revision as of 23:22, 9 July 2010

Revision as of 23:23, 9 July 2010

Line 5:

Extended static checkers typically operate by propagating [[predicate transformer semantics#Strongest postcondition|strong postconditions]] (resp. [[predicate transformer semantics#Weakest precondition|weak preconditions]]) intraprocedurally through a method starting from the precondition (resp. postcondition). At each point during this process an intermediate condition is generated that captures what is known at that program point. This is combined with the necessary conditions of the program statement at that point to form a ''verification condition''. An example of this is a statement involving a division, whose necessary condition is that the [[divisor]] be non-zero. The verification condition arising from this effectively states: ''given the intermediate condition at this point, it must follow that the divisor is non-zero''. All verification conditions must be shown correct in order for a method to pass extended static checking. Typically, some form of automated theorem prover is used to discharge verification conditions.

Extended Static Checking was pioneered in ESC/Modula-3<ref>An extended Static Checker for Modula-3, K. Rustan M. Leino and Greg Nelson. In Proceedings of the Conference on Compiler Construction, pages 302--305, 1998. doi: http://dx.doi.org/10.1007/BFb0026418</ref> and, later, [[ESC/Java]]. Its roots originate from more simplistic static checking techniques, such as used in [[linkLint (software)]] and [[findbugsFindBugs]]. A number of other languages have adopted the approach, including [[Spec Sharp|Spec#]] and [[SPARK (programming language)|SPARKada]]. However, there is currently no widely used programming language that provides extended static checking.