Abstract interpretation

Abstract interpretation is a theory of sound approximation of the semantics of computer programs, based on monotonic functions over ordered sets, especially lattices. It can be viewed as a partial execution of a computer program which gains information about its semantics (e.g. control structure, flow of information) without performing all the calculations.

Its main concrete application is formal static analysis, the automatic extraction of information about the possible executions of computer programs; such analyses have two main usages:

• inside compilers, to analyse programs in order to decide whether certain optimisations or transformations are applicable;
• for debugging or even the certification of programs against classes of bugs.

Abstract interpretation was formalized by Pr Patrick Cousot.

Contents

1 Intuition 2 Abstract interpretation of computer programs 3 Formalization 4 Examples of abstract domains 5 Tools 6 See also 7 External links

Intuition

We shall now illustrate what abstract interpretation would mean on concrete, not computing examples.

Let us consider the people in a conference room. If we wish to prove that some persons were not present, one concrete method is to look up a list the names and social security numbers of all participants. Since no two persons have the same number, it is possible to prove or disprove the presence of a participant simply by looking up his or her number in the list.

We may however have restricted ourselves to registering only their names. If the name of a person is not found in the list, we may safely conclude that that person was not present; but if it is, we cannot conclude definitely without further enquiries, due to the possibility of homonyms. Let us note that this imprecise information will still be adequate for most purposes, because homonyms are rare in practice. However, in all rigor, we cannot say for sure that somebody was present in the room; all we can say is that he or she was possibly here. If the person we are looking up is a criminal, we will issue an alarm; but there is of course the possibility of issuing a false alarm. Similar phenomena will occur in the analysis of programs.

If we are only interested in some specific information, say, "was there a person of age n in the room", keeping a list of all names and dates of births is unnecessary. We may safely and without loss of precision restrict ourselves to keeping a list of the participants' ages. If this is already too much to handle, we might keep only the minimal m and maximal M ages. If the question is about an age strictly lower than m or strictly higher than M, then we may safely respond that no such participant was present. Otherwise, we may only be able to say that we do not know.

In the case of computing, concrete, precise information is in general not computable within finite time and memory (see Rice's theorem and the halting problem). Abstraction is used to simplify problems up to problems amenable to automatic solutions. One crucial issue is to diminish precision so as to make problems manageable while still keeping enough precision for answering the questions (such as "may the program crash?") one is interested in.

Abstract interpretation of computer programs

Given a programming or specification language, abstract interpretation consists in giving several semantics linked by relations of abstraction. A semantics is a mathematical characterization of the possible behaviors of the program. The most precise semantics, describing very closely the actual execution of the program, is called the concrete semantics. For instance, the concrete semantics of an imperative programming language may associate to each program the set of execution traces it may produce – an execution trace being a sequence of possible consecutive states of the execution of the program; a state typically consists of the value of the program counter and the memory locations (globals, stack and heap). More abstract semantics are then derived; for instance, one may consider only the set of reachable states in the executions (which amounts to considering the last states in finite traces).

For goals of static analysis, some computable abstract semantics must be derived at some point. For instance, one may choose to represent the state of a program manipulating integer variables by forgetting the actual values of the variables and only keeping their signs (+, - or 0). For some elementary operations, such as multiplication, such an abstraction does not lose any precision: to get the sign of a product, it is sufficient to know the sign of the operands. For some other operations, the abstraction may lose precision: for instance, it is impossible to know the sign of a sum whose operands are respectively positive and negative.

Such loss of precision may not, in general, be avoided so as to make a decidable semantics (see Rice's theorem, halting problem). There is, in general, a compromise to be made between the precision of the analysis and its tractability, either from a computability point of view or from a complexity point of view.

In general, abstractions used must be tailored to the kinds of properties one desires to prove, and to the kind of programs that one wants to analyze.

Formalization

Let L be an ordered set, called a concrete set and let L' be another ordered set, called an abstract set. These two sets are related to each other by defining total functions that map elements from one to the other.

A function α is called an abstraction function if it maps an element x in the concrete set L to an element α(x) in the abstract set L'. That is, element α(x) in L' is the abstraction of x in L.

A function γ is called a concretization function if it maps an element x' in the abstract set L' to an element γ(x') in the concrete set L. That is, element γ(x') in L is a concretization of x' in L'.

Let L₁, L₂, L'₁ and L'₂ be ordered sets. The concrete semantics f is a monotonic function from L₁ to L₂. A function f' from L'₁ to L'₂ is said to be a valid abstraction of f if for all x'₁ in L'₁, f ∘ γ(x') ≤ γ ∘ f'(x').

Program semantics are generally described using fixed points in the presence of loops or recursive procedures. Let us suppose that L is a complete lattice and let f be a monotonic function from L into L. Then, any x' such that f'(x') ≤ x' is an abstraction of the least fixed-point of f, which exists, according to the Knaster-Tarski theorem.

The difficulty is now to obtain such an x'. If L' is of finite height, or at least verifies the "ascending chain condition" (all ascending sequences are ultimately stationary), then such an x' may be obtained as the stationary limit of the ascending sequence x'_n defined by induction as follows: x'₀=⊥ (the least element of L') and x'_n+1=f'(x'_n).

In other cases, it is still possible to obtain such an x' through a widening operator ∇: for all x and y, x ∇ y should be greater or equal than both x and y, and for all sequence y'_n, the sequence defined by x'₀=⊥ and x'_n+1=x'_n ∇ y'_n is ultimately stationary. We can then take y'_n=f(x'_n).

In some cases, it is possible to define abstractions using Galois connections (α, γ) where α if from L to L' and γ is from L' to L. This supposes the existence of best abstractions, which is not necessarily the case. For instance, if we abstract sets of couples (x,y) of real numbers by enclosing convex polyhedra, there is no optimal abstraction to the disc defined by x²+y² ≤ 1.

Examples of abstract domains

One can assign to each variable x available at a given program point an interval [l_x,h_x]. A state assigning the value v(x) to variable x will be a concretization of these intervals if for all x, then v(x) is in [l_x,h_x]. From the intervals [l_x,h_x] and [l_y,h_y] for variables x and y, one can easily obtain intervals for x+y ([l_x+l_y,h_x+h_y]) and for x-y ([l_x-h_y,h_x-l_y]); note that these are exact abstractions, since the set of possible outcomes for, say, x+y, is precisely the interval ([l_x+l_y,h_x+h_y]). More complex formulas can be derived for multiplication, division, etc., yielding so-called interval arithmetics.

Let us now consider the following very simple program:

y = x;
z = x - y;

With reasonable arithmetic types, the result for z should be zero. But if we do interval arithmetics starting from x in [0,1], one gets z in [-1,1]. While each of the operations taken individually was exactly abstracted, their composition isn't.

The problem is evident: we did not keep track of the equality relationship between x y; actually, this domain of intervals does not take into account any relationships between variables, and is thus a non-relational domain. Non-relational domains tend to be fast and simple to implement, but imprecise.

Relational numerical abstract domains to exist. Let us cite:

• convex polyhedra – with some high computational costs
• "octagons"
• difference-bound matrices
• linear equalities

and combinations thereof.

When one chooses an abstract domain, one typically has to strike a balance between keeping fine-grained relationships, and high computational costs.

Tools

• ASTRÉE (http://www.astree.ens.fr)
• PAG (http://www.absint.com/pag) and PAG/WWW (http://www.program-analysis.com)

See also

• DAEDALUS
• Standard interpretation
• model checking

External links

• Citations from CiteSeer (http://citeseer.org/cs?q=abstract+interpretation)
• Search results from MetaCrawler (http://metacrawler.com/info.metac/search/redir.htm?qkw=abstract+interpretation&qexact=on)de:Abstrakte Interpretation

fr:interprétation abstraite