Invariant Relations: an Automated Tool to Analyze Loops

Since their introduction more than four decades ago, invariant assertions have, justifiably, dominated the analysis of while loops, and have been the focus of sustained research interest in the seventies and eighties, and renewed interest in the last decade. In this paper, we tentatively submit an alternative concept for the analysis of while loops, explore its attributes, its applications, and its relationship to invariant assertions. Also, we discuss the design, implementation and use of a tool that analyzes while loops using this concept.


INTRODUCTION
In Hoare (1969), Hoare introduced the concept of an invariant assertion as a pivotal tool in the analysis of while loops.The study of invariant assertions, and their use in the analysis of while loops, have been the focus of active research in the seventies and eighties, and the subject of renewed interest in the last few years Fu and Bastani and Yen (2008); Carette and Janicki (2007); Berdine (et al 2007); Jebelean and Giese (2007); Ernst, et al (2006); Carbonnell and Kapur (2004); Colon and Sankaranarayana and Sipma (2003); Sankaranarayana and Sipma and Manna (2004); Kovacs andJebelean (2004, 2005).In this paper we discuss an alternative concept to the analysis of while loops, namely the concept of invariant relation Mili, et al (2009).Also, we explore the attributes of invariant relations, and their relationship to invariant assertions and to loop semantics.Specifically, • Whereas an invariant assertion is an assertion that holds after any number of iterations of the loop (including zero iterations, i.e. at the precondition), an invariant relation is a relation that holds between two states, say s and s ′ , that are separated by an arbitrary number of iterations (including zero).
• Whereas an invariant assertion is dependent not only on the loop, but also on the context of the loop (its pre-condition and post-condition), an invariant relation is intrinsic to the loop, and does not depend on where the loop is used.
• Given an invariant relation and a precondition, we can use them to generate an invariant assertion; on the other hand, any invariant assertions can be derived from an invariant relation and a pre-condition.
• Given an invariant assertion, we can use it to generate an invariant relation; but not all invariant relations stem from invariant assertions.On the basis of this premise, we submit that invariant relations are a more general concept than invariant assertions.
• At the LIPAH laboratory, University of Tunis, we are evolving an automated tool that generates invariant relations of while loops written in C-like languages, using pre-stored patterns that represent programming knowledge and domain knowledge; we refer to these patterns as recognizers.
• We are also evolving and maintaining a tool, programmed in Mathematica ( c ⃝Wolfram Research), that uses the invariant relations of a loop to compute or approximate the function of the loop.
In section 2 we briefly introduce the mathematical background that is needed subsequently for our discussions.In section 3 we discuss the concept of invariant relation (introduced in Mili, et al (2009)) and briefly present the main results pertaining to the properties of invariant relations and their relationship to invariant assertions Jilani, et al (2011).In section 4 we discuss how invariant relations can be used to compute (or approximate) loop functions, and to compute invariant assertions; and we compare our approach to alternative approaches for generating invariant assertions.In section 5 we discuss the generation of invariant relations from a static analysis of their source code, and in section 6 we summarize and assess our main findings and identify future research directions.

Definitions and Notations
We consider a set S defined by the values of some program variables, say x, y and z; we typically denote elements of S by s, and we note that s has the form s = ⟨x, y, z⟩.We use the notation x(s), y(s), z(s) to denote the x-component, y-component and z-component of s.We may sometimes use x to refer to x(s) and x ′ to refer to x(s ′ ), when this raises no ambiguity.We refer to elements s of S as states of the program and to S as the space of the program.A relation on S is a subset of the cartesian product S × S. Constant relations on some set S include the universal relation, denoted by L, the identity relation, denoted by I, and the empty relation, denoted by ∅.

Operations on Relations
Because relations are sets, we apply the usual set theoretic operations between relations: union (∪), intersection (∩), and complement (R).Operations on relations also include: • The converse is denoted by R, and defined by Given a predicate t, we denote by T the relation defined as T = {(s, s ′ )|t(s)}.We admit without proof that the pre-restriction of a relation R to predicate t can be written as T ∩ R or as (I ∩ T ) • R, and the post-restriction of relation R to predicate t can be written as R ∩ T or as R • (I ∩ T ).
• The domain of relation R is defined as • The range of relation R is denoted by rng(R) and defined as dom( R).
• The n th power of relation R, for natural number n, is denoted by R n and defined by: R 0 = I, • The transitive closure of relation R is defined as the relation denoted by R + and defined by • The reflexive transitive closure of relation R is the relation denoted by R * and defined by We apply the usual conventions with regards to operator precedence.

Properties of Relations
We say that R is deterministic (or that it is a function)

Refinement Ordering
We denote this relation by R ⊒ R ′ or R ′ ⊑ R. Given a program g on space S, we let G be the function defined as: We admit that, modulo traditional definitions of total correctness Morgan (1990);Dijkstra (1976); Gries (1981); Manna (1974), the following propositions hold: • A program g is correct with respect to a specification R if and only if G ⊒ R.
• R ⊒ R ′ implies that any program correct with respect to R is correct with respect to R ′ .
Intuitively, R refines R ′ if and only if R represents a stronger requirement than R ′ .

Lattice Properties
We admit without proof that the refinement relation is a partial ordering.In Boudriga and Elloumi and Mili (1992) Boudriga et al. analyze the lattice properties of this ordering and find: • Any two relations R and R ′ have a greatest lower bound, which we call the meet, denote by ⊓, and define by: • Two relations R and R ′ have a least upper bound if and only if they satisfy the following condition (which we call the consistency condition): Under this condition, their least upper bound is referred to as the join, is denoted by ⊔, and is defined by: Intuitively, the join of R and R ′ , when it exists, behaves like R outside the domain of R ′ , behaves like R ′ outside the domain of R, and behaves like the intersection of R and R ′ on the intersection of their domain.The consistency condition ensures that the domain of their intersection is identical to the intersection of their domains.
• Two relations R and R ′ have a least upper bound if and only if they have an upper bound.
• The lattice of refinement admits a universal lower bound, which is the empty relation, and admits no universal upper bound.
• Maximal elements of this lattice are total deterministic relations.

INVARIANT RELATIONS AND INVARIANT ASSERTIONS
In this section, we present relational definitions for invariant relations Mili, et al (2009) and invariant assertions Hoare (1969), to set the stage for our subsequent comparative analysis.We consider a while loop of the form w = while t do b on space S, which we assume to terminate for all states in S; in Mili and Aharon and Nadkarni (2009), we explain why, in theory, this hypothesis does not affect the generality of our study; in practice, this hypothesis does pose a problem, and we envision to lift it in future research.The following theorem defines the semantics of while loops.
Theorem 1 (Mili et al, 2009 Mili andAharon andNadkarni (2009)) We consider a while loop w = while t do b that terminates for all the states in S.
Then its function W is given by (where T is the vector defined by t and B is the function of b): A proof of this simple theorem is given in Mili and Aharon and Nadkarni (2009).To illustrate our discussions, we use a simple running example, which is the following while loop on natural variables n, f , k, such that 1 ≤ k ≤ n + 1: We apply the formula of this theorem:

Invariant Assertions
Traditionally Manna (1974);Hoare (1969), an invariant assertion α for the while loop w = while t do b with respect to a precondition/ postcondition pair (p, q) is defined as a predicate on S that satisfies the following conditions: • {α ∧ t}b{α}, and For the sake of uniformity, we recast these conditions in relational terms, representing the precondition p by the vector P = {(s, s ′ )|p(s)}, the postcondition q by the vector Q = {(s, s ′ )|q(s)}, and the predicate α by the vector A = {(s, s ′ )|α(s)}.
Definition 2 Given a while statement of the form, w = while t do b, an invariant assertion for w with respect to precondition P and postcondition Q is a vector A on S that satisfies the following conditions: If we consider the sample loop introduced earlier, and take the precondition f = 1 ∧ k = 1 and the postcondition f = n!, then we find that f = (k − 1)! is an adequate invariant assertion for this program (adequate in the sense: sufficiently large to meet the first condition, sufficiently small to meet the third condition).

Invariant Relations
The concept of invariant relation was introduced by Mili et al. in Mili, et al (2009); it is defined as follows.
Definition 3 Given a while loop of the form w = while t do b on space S, we say that a relation R is an invariant relation for w if and only if it is a reflexive and transitive superset of (T ∩ B).
To illustrate this concept, we consider again the loop of the running example, and we submit the following relation: This relation is clearly reflexive and transitive; we leave it to the reader to check that it is a superset of (T ∩ B).

Comparative Analysis
The first question we ask is: can we derive an invariant assertion from an invariant relation?
Proposition 1 Let w be a while loop on space S and let R be an invariant relation for w.Then A = RP is an invariant assertion for w with respect to the precondition P and the postcondition Q = T ∩ RP .
Proof.According to Definition 2, we must prove three conditions: The first condition stems readily from the reflexivity of R. The second condition is a result from Jilani, et al (2011).The third condition is a tautology.qed As an illustration, we consider the invariant relation we had proposed earlier for the sample loop, and we let P be the following vector, representing possible initial conditions of the loop: The invariant assertion that we then obtain is the following: which is the invariant assertion we had proposed earlier.
Because invariant relations depend exclusively on the loop whereas invariant assertions depend on the context of the loop in addition to the loop (the context being defined by the precondition and the postcondition), it is difficult to compare them meaningfully.Hence we consider a context-free version of invariant assertions, which we introduce below.
Definition 4 Given a while loop on space S of the form w = while t do b, and given a vector U on S, we say that U is an inductive assertion for w if and An inductive assertion is an assertion that satisfies the second condition of invariant assertions, but not the first nor the third (both of which refer to its context).The first result that we propose is a generalization of Proposition 1.
Proposition 2 Let w be a while loop on space S and let R be an invariant relation for w and V be an arbitrary vector on S. Then A = RV is an inductive assertion for w.
This Proposition is due to Jilani, et al (2011), where it is proved; we content ourselves here with illustrating it.We take the invariant relation and the following vectors: If we let A 0 , A 1 , ... A 5 be the inductive assertions derived from the selected invariant relation by applying vectors V 0 , V 1 , ... V 5 , we find The next question that we address is, naturally: can we generate an invariant relation from any inductive assertion.
Proposition 3 Let A be an inductive assertion for the while loop w; then R = A ∪ A is an invariant relation for w.
Proof.By set theory, the condition transitive for any vector V .qed We illustrate this proposition by means of a simple example, using the sample factorial loop.We consider the following inductive assertion, and we apply the formula dictated by this Proposition: Now that we know how to generate an inductive assertion from an invariant relation (Proposition 1) and an invariant relation from an inductive assertion (Proposition 3), can we infer that invariant relations and inductive assertions are equally powerful?The answer is no, because the question we need to pose instead is whether all invariant relations can be derived from inductive assertions, and whether all inductive assertions can be derived from invariant relations.The following proposition answers the second question.
Proposition 4 Let w be a while loop on space S and let A be an inductive assertion for w.Then there exists an invariant relation R and a vector V such that A = RV .
The proof of this proposition is given in Jilani, et al (2011), where R is taken as A ∪ A and V is taken as A. The interest of this proposition is threefold: First, it proves that by focusing on generating invariant relations, we cover all possible inductive assertions; Second, it provides a structure for all inductive assertions, as the inverse of an invariant relation composed with a vector; Third, it separates two components of an inductive assertion, namely R, which depends exclusively on the loop, and V , which depends on the context (initialization) of the loop.
As to the question of whether any invariant relation can be derived from an inductive assertion, we have reason to believe it is not the case.Consider that according to Proposition 3, the search for inductive assertions is amenable to the search for invariant relations of a certain kind, namely relations that are inductive.Since not all invariant relations are inductive, it is legitimate to infer that invariant relations are a more general concept than inductive assertions.

INVARIANT RELATIONS AND LOOP ANALYSIS
Proposition 1 shows how, given an invariant relation and a precondition to a loop, we can constructively generate a postcondition for the loop.While this is an interesting result, it is not the only application of invariant relations, nor the most useful: the following proposition, due to Mili and Aharon and Nadkarni (2009), shows that invariant relations can also be used to compute or approximate the function of a loop.
Proposition 5 Let w = while t do b be a while loop on space S; let R be an invariant relation for w and let W be the function of w.Then W ⊒ R ∩ T .
According to this proposition, we can transform an invariant relation of w into a lower bound (in the refinement ordering) of its function W .Because by hypothesis W is total and determninistic, it is maximal in the lattice of refinement, hence it is possible to compute it or approximate it using nothing but lower bounds.To this effect, we gather as many invariant relations as we can, from which we generate lower bounds of the loop's function.Then we take the join of all the lower bounds, which we test for totality and determinacy; if it is total and deterministic, then it is the function of the loop, if not it is the best approximation we can derive from the invariant relations at hand.
As an illustration, we consider the running sample loop, for which we know the following invariant relation: from this, we derive the following lower bound This relation is total but is not deterministic, hence we seek another invariant relation for w, say R = {(s, s ′ )|n = n ′ }, from which we derive the following lower bound: Taking the join (in this case, the intersection) of these two lower bounds produces the following relation: This is the function we had found above, by application of Theorem 1.If this loop is initialized by any segment such as: k=1; f=1; or k=2; f=1; or k=3; f=2; or any segment whose postcondition is In the remainder of this section, we consider a number of sample loops; for each loop, we generate the invariant relations derived by our tool, from which we compute the function of the loop (using Proposition 5) and an invariant assertion (using Proposition 1).For the sake of comparison, we show what other tools generate for the same loops, most notably: Aligator Kovacs and Voronkov (2009); Daikon Ernst, et al (2006), andLoopFrog Kroening, et al (2010).The code is written in C++, with slight modifications: while C++ requires all program constants to be assigned values, we merely declare them as constants; also, we may sometimes put several statements on the same line, to save space, even though C++ compilers do not allow that.We compare the performance of our tool against the other tools at the end of the experiment, rather than after each sample program, because many of our observations apply repeatedly.

Sequential Loop Body
We consider the following loop, whose loop body consists of a sequence of assignment statements to numeric variables; note that function f is not declared explicitly, as we do not need to know its explicit expression to analyze the loop.

Non Trivial Calculations
We consider the following loop, which manipulates numeric variables, and includes non trivial numeric computations. # In order to generate an invariant assertion for this loop, we need to choose a vector P that represents initial conditions (as per Proposition 1).We let P be defined by the following initial conditions: This yields the following invariant assertion: Aligator could not process this loop; when we removed all the statements that it could not parse, it produced the following assertion: Daikon did not object to any statement, and produced i + j − 31 = 0 ∧ nc = np ∧ x = 3. LoopFrog produced nc = np.

Non Integer Data
We consider the following loop, which performs a fixpoint computation on real numbers.
#include <iostream> #include <math.h>int main () {float x, y, z; while (fabs(y-x)!=0) {y=x; x=1+z/x;}} Our algorithm finds the following invariant relation: By generating a lower bound from this invariant relation, we find the following approximation of W : Indeed, this program has two fixpoints, and it converges to one or the other depending on the initial value of x.Note that because this relation is not deterministic (though it is total), we cannot say that it equals W ; we can only say that it is refined by W .
Aligator and LoopFrog find no loop invariant.Daikon finds: x ̸ = y ∧ x > z ∧ y > z.The characterization of x ̸ = y as an invariant assertion is misleading, since this is the condition of the loop (the loop condition is not an invariant assertion, since it is not true at the exit point).

Non Numeric Data
We consider the following program, which handles data of type list.

Comparisons
The deployment of our tool, along with competing tools, on an eclectic sample of loops, leads to make the following observations: • All of Aligator, Daikon and LoopFrog handle only numeric variables, and often only integer variables.By contrast, our tool can handle any data type, provided the system has the relevant recognizers for it.
• Because it produces invariants of a certain form, Aligator also has restrictions on the kinds of numeric operations we can have in the loop.By contrast, our tool has no limit on the form of invariant relations that it produces; whatever we store in recognizers gets generated upon a successful match.
• Because it focuses exclusively on empirical observations, Daikon has no way to distinguish between properties that stem from the loop versus properties that stem from the data; so that changing the data on which the loop executes changes the invariant that Daikon finds, even though the loop has not changed.By contrast, our tool is focused exclusively on capturing functional properties of the loop, regardless of the value that the data takes at any particular execution.
• Because it tries to generate whatever clause it believes to hold, Daikon tends to produces many clauses that are of little value, i.e. tell us very little about the loop.For large loops, this may lead to very low precision, where only very few clauses are relevant.By contrast, our tool focuses on functional properties that enable us to compute the function of the loop -a rigorous test of relevance.
• Because they are not goal oriented (they are not generating invariants for a specific verification goal), Aligator, Daikon and LoopFrog offer no warranty as to how strong their invariant assertions are; in practice these can be arbitrarily weak/ uninformative, leading to poor recall.By contrast, our tool attempts to generate invariant relations that are sufficiently strong to compute the function of the loop; and it tests whether it has found them or not, by whether or not the corresponding lower bounds produce a total deterministic relation.
• Whenever it is applied to the same loop, our tool generates an invariant assertion that subsumes (logically implies) the invariant assertions generated by the other tools.Note that in the examples above, we find that some of the clauses generated by other tools are not generated by ours, but that is because we had to remove statements from the loop before we applied the other tools, hence we are not dealing with the same loop any more.
In fairness, we must also acknowledge the single most critical weakness of our tool: it can only handle loops for which it has relevant recognizers; hence its superior performance exhibited in the examples above carries over only as far as its database of recognizers allows.But two important qualification must be made: • Whereas the limitations of the other tools are inherent to their respective algorithms, the limitations of our tool are circumstantial, in the sense that they are dependent on the current status of the recognizer database, and can be readily fixed by adding the missing recognizers.For example, if Daikon or Aligator or LoopFrog cannot handle a program on non numeric data types, there is typically no simple fix that can break the limitation; by contrast, if our tool is unable to handle a particular code configuration, all we have to do is add the missing recognizer and run it again, without changing the core algorithm.
• We justify the dependence of our tool on recognizers by observing that recognizers are merely the way in which we codify the programming knowledge and domain knowledge that is needed to analyze loops adequately.In the other tools, this knowledge is hard-wired into the algorithm.

GENERATING INVARIANT RELATIONS
While in the previous section we discussed how to use invariant relations, in this section we discuss how to generate them.The first question we need to address is: do all loops have invariant relations.
Proposition 6 Let w = while t do b be a loop on space S. Then R = (T ∩ B) * is an invariant relation for w.
Proof.The reflexive transitive closure of (T ∩ B) is known to be the smallest reflexive transitive superset of (T ∩ B).Hence it is a reflexive transitive superset of (T ∩ B), i.e. an invariant relation for w. qed This trivial proposition is useful for two reasons: first, because it assures us of the existence of invariant relations; second, because it highlights the property that smaller invariant relations are better.
The following proposition gives us means to obtain small invariant relations.
Proposition 7 Let w be a while loop on space S and let R and R ′ be invariant relations for w; then R ∩ R ′ is an invariant relation for w.
Proof.The intersection of two reflexive relations is reflexive; the intersection of two transitive relations is transitive; and the intersection of two supersets of (B ∩ T ) is a superset of (B ∩ T ).qed Hence we can compute small invariant relations by taking the intersection of arbitrary invariant relations, which are not necessarily small.As to the question of how we generate elementary invariant relations, we first offer the following proposition.
Proposition 8 Let w be a while loop while t do b on space S. Then R = (I ∪ T (T ∩ B)) is an invariant relation for w.
Proof.We must prove that R is reflexive, transitive, and is a superset of (T ∩ B).Reflexivity is trivial, by construction.To prove transitivity, we proceed as follows: To prove that R is a superset of (T ∩ B), we write qed Intuitive interpretation of this proposition: If s ′ is obtained from s by an arbitrary number of iterations, then either s ′ = s or t(s) and s ′ is in the range of (T ∩ B).
As for how to generate more general invariant relations, consider that in order to find supersets of (B ∩ T ), it helps to write it as an intersection, such as: Because then, any superset of B 1 is a superset of (B ∩ T ); any superset of B 1 ∩ B 2 is a superset of (B ∩ T ); any superset of B 1 ∩ B 2 ∩ B 3 is a superset of (B ∩ T ); etc.This gives us a priceless divide-andconquer strategy: we can derive invariant relations for an arbitrarily large loop, once the function of its loop body is written as an intersection, by looking at one term at a time, or two at a time, or three at a time, etc.In practice, our algorithm proceeds as follows: • The source code is mapped into a notation that rewrites the function of the loop body as an intersection; when the loop body is merely a sequence of assignments, this can be done by eliminating sequential dependencies.When the loop body has a more complex control structures, we invoke a more general procedure, which we discuss subsequently.
• We deploy a pattern-matching algorithm that matches the terms of the intersection one a time, then two at a time, then three at a time against pre-stored patterns (the recognizers) for which we store the corresponding invariant relation pattern.Whenever a match is successful, we instantiate the invariant relation pattern to obtain an actual invariant relation.So far, we have limited ourselves to looking at no more than three terms at a time in order to control the combinatorics of the pattern-matching step; but as we consider more complex programs, we are envisioning to increase the number of terms that need to be considered.
• We take the intersection of all the invariant relations that are generated, to obtain a smaller invariant relation.
It is easy to write the function of the loop body as an intersection whenever the loop body is made up of a sequence of assignments; we do so by eliminating the functional dependencies between sequential statements, and summarizing the effect of the sequence of statements on each individual variable.When the loop body contains more complex control structures, such as nested if-then-else statements, then the outermost structure of the function of loop body is a union (not an intersection).In that case, we apply the pattern matching algorithm discussed above to each term of the union, to obtain an invariant relation as an intersection of larger invariant relations, of the form: This relation is a superset of the function of the loop body, and it is reflexive; but it is not transitive, as the union of transitive relations is not transitive.To derive an invariant relation from it, we deploy a routine (written in Mathematica, c ⃝Wolfram Research), to merge the terms of this union into a single term, structured as an intersection.The key idea of the routine is to identify common supersets of the terms of the union, and take their intersection.To explain the merger routine, we consider two terms of the union, where each term is the intersection of two terms: If we find, for example, that (R 21 ∩ R 22 ) ⊆ R 11 then we conclude that R 11 is an invariant relation, since it is reflexive and transitive (by construction), and it is a superset of each term of the union (hence a superset of the union).If, for example, we find also that (R 11 ∩ R 12 ) ⊆ R 22 then we can infer (for the same reasons as above) that R 22 is an invariant relation.From which we conclude that R 11 ∩ R 22 is an invariant relation.As an illustration, consider the following simple loop: while (y!=0) {if (y%2==0) {y=y/2;x=2*x;} else {z=z+x;y=y-1;}} As a reflexive transitive superset of the first branch (which we call B 1 ), our tool finds R As a reflexive transitive superset of the second branch (which we call B 2 ), our tool finds construction); and it is reflexive (as the union of reflexive relations); but it is not necessarily transitive (as the union of transitive relations).However, we note that R 22 is a superset of R 1 (by inspection); on the other hand, it is also a superset of R 2 (any term of an intersection is a superset of the intersection).Hence R 22 is a superset of R 1 ∪ R 2 ; because by construction R 1 ⊇ B 1 and R 2 ⊇ B 2 we infer that R 22 is a superset of B 1 ∪ B 2 , which is (T ∩ B).On the other hand, because it is generated by our tool, R 22 is by construction reflexive and transitive.As a reflexive transitive superset of (T ∩ B), R 22 is an invariant relation for the while loop.
Figure 1 shows a sample of recognizers that we currently have in our database; some of them have been used in the examples shown in this paper.

CONCLUDING REMARKS
This paper reports on our ongoing work to analyze while loops by means of invariant relations, a concept we had introduced in Louhichi and Mraihi and Jilani and Mili (2009).The focus of this paper is on the tool that we are developing and evolving to generate invariant relations from a static analysis of its source code.We have presented the following results: • Invariant relations can be used to compute or approximate the function of a loop.
• Invariant relations subsume invariant assertions, in the sense that any invariant assertion can be derived from an invariant relation.
• Any invariant assertion can be structured as the combination of an invariant relation, which is intrinsic to the loop, with the precondition of the loop, which reflects the loop's initialization.
• Invariant relations can be derived from an analysis of the source code of the loop, using a divide-and-conquer algorithm that enables us to handle large loops in nearly linear time.
• To the extent that it is applied to data structures and control structures that have previously been modeled in recognizers, our tool produces better/ more complete results than the tools we have compared it against.
Our tool for generating invariant relations is based on a pattern matching algorithm that matches pre-stored code patterns, the recognizers, against a representation of the loop, and generates corresponding invariant relations whenever a match is successful.We believe that the task of computing the function of a loop is essentially a mapping from a domain neutral notation, namely the programming language, to a domain-specific notation, namely the application domain of the program, with its attendant abstractions, notations, axiomatizations, etc.As long as we are handling only numeric data types (integers, reals, etc), then the distinction between programming notation and domain notation is moot, since numeric data types are native to all (C-like) programming languages.But as soon as we need to analyze programs that handle non native data types, we must be able to codify and integrate domain information in order for the tool to carry out a meaningful analysis.In our approach, domain knowledge is codified in the recognizers, and in the axiomatizations that we use after invariant relations are generated to compute the function of the loop.
The examples that we have shown in section 4 show our tool in a favorable light by comparison with other tools, but that is only because we chose the examples according to our current repository of recognizers.In its current status, our prototype tool includes about 50 recognizers, and our algorithm operates by syntactic matching.We envision three important extensions of it: • Replace the current syntactic matching algorithm by a semantic matching algorithm; whereas we currently match statements of the loop with recognizer patterns token by token, we want to replace this by semantic match, which declares a match if the actual expression and the formal expression are identical, when instantiated by the same variable names.We envision to use Mathematica for this purpose.
• Replace the current repository of recognizers by a set of more general recognizers, and increase the scope of the repository in size (number of recognizers), as well as in genericity (range of code patterns that semantically match each recognizer).
• Develop domain-specific sub-repositories, that can be deployed for code dealing with specific application domains, and would then use domain-specific abstractions, notations, and axiomatizations.