Content deleted Content added
mNo edit summary |
mNo edit summary |
||
Line 3:
The techniques used in extended static checking come from various fields of [[Computer Science]], including [[static analysis]], [[model checking]], [[abstract interpretation]], [[satisfiability modulo theories|SAT solving]] and [[automated theorem proving]]. One characteristic is that ESC is generally performed only at an intraprocedural level (rather than an [[interprocedural optimization|interprocedural]] one). Furthermore, it aims to report errors by exploiting user-supplied specifications, in the form of [[precondition|pre-]] and [[postcondition|post-conditions]], [[loop invariant|loop invariants]] and [[class invariant|class invariants]].
Extended static checkers typically operate by propagating [[predicate transformer semantics#Strongest postcondition|
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 [[Lint (software)]] and [[FindBugs]]. A number of other languages have adopted ESC, including [[Spec Sharp|Spec#]] and [[SPARK (programming language)|SPARKada]]. However, there is currently no widely used programming language that provides extended static checking.
|