Abstract interpretation based tool construction for ...laser.inf.ethz.ch/2011/Elba/cousot/Cousot-LASER-2011-6.pdf · see K. Jensen and N. Wirth: Pascal User Manual and Report, Second
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Observe that the code defining the transformer could be directly generatedfrom the program text and so we have a model of an abstract compiler.
(An alternative would use a computer representation of the equations andan abstract interpreter would be used to evaluate the transformer by calls tothe interval abstract domain). �
3.9 Verification
The abstract interpreter that we have designed is a sound static analyzer.Given a program it produces interval information always valid at runtime.
We can turn it into a verifier checking an interval specification.The specification can be provided by the user or remain implicit (e.g. ab-
sence of runtime errors such as overflows).One kind of user specification is a type declaration, for example an interval
declaration for integer variables like var x : 1⇤⇤100;.Let us understand this declaration as: “only values between 1 and 100 can
be assigned to x, otherwise execution stops” (with a runtime error).Observe that this does not mean that x always has a value betwwen 1 and
100 because it can be initialized with any integer value.13.For the following exampleP ⇥ � var x : 1⇤⇤100 ; 1x := 1 ; while 2(x <= 100) do 3x := (x + 1); od4.
the abstract interval equations become⇤⌃⌃⌃⌃⌃⌃⇧⌃⌃⌃⌃⌃⌃⌅
X1 = {x � [min_int⌅ max_int]}X2 = {x � �[1⌅ 1] ⌅ L X3(x) = ⇤ ? ⇤ : let [�⌅ ⇥] = X3(x) in
since execution stops if and when a value outside [1⌅ 100] is going to beassigned to x. The result of the analysis is now the following. This declarationis encoded in OC� � as follows 14.
13This interpretation of the interval declaration is that of the P��⇥�� programming language,see K. Jensen and N. Wirth: Pascal User Manual and Report, Second Edition, Springer, 1975.
14Notice that the restriction of the mathematical invariance equations to machine integers aswell as the verification of absence of overflow could have been encoded in the same way, seeexercice 3-1.
The verification of absence of errors checks that at any point during anexecution without error up to some point in the computation will not have anerror at the next execution step.(* verifier .ml , interval invariant abstract domain *)let pwarning (b1 , b2 , b3 , b4) =
let m = " Potential error at line " inif not b1 then print_string (m ^"1\ n ");if not b2 then print_string (m ^"2\ n ");if not b3 then print_string (m ^"3\ n ");if not b4 then print_string (m ^"4\ n ");;
let pverify leq f a =let b = leq (f a) a in
pwarning b;
The abstract interpreter performs the iterative abstract reachability fixpointoverapproximation with widening/narrowing and intersection with the decla-ration, then prints the least fixpoint result, and finally checks for errors.(* reachability verification with widening and narrowing *)open Invariantopen InvariantWideningopen InvariantNarrowingopen TransformerBoundedopen Iteratoropen Declarationopen Verifierlet verifier () =
let fw x = ( pmeet ( pwiden x (f x)) d) inlet w = ( lfp pless pbot fw) in
let fn x = pnarrow x (f x) inlet a = ( lfp pgreater w fn) in
The verification of absence of errors checks that at any point during anexecution without error up to some point in the computation will not have anerror at the next execution step.(* verifier .ml , interval invariant abstract domain *)let pwarning (b1 , b2 , b3 , b4) =
let m = " Potential error at line " inif not b1 then print_string (m ^"1\ n ");if not b2 then print_string (m ^"2\ n ");if not b3 then print_string (m ^"3\ n ");if not b4 then print_string (m ^"4\ n ");;
let pverify leq f a d =let b = leq (f a) d in
pwarning b;
The abstract interpreter performs the iterative abstract reachability fixpointoverapproximation with widening/narrowing and intersection with the decla-ration, then prints the least fixpoint result, and finally checks for errors.(* reachability verification with widening and narrowing *)open Invariantopen InvariantWideningopen InvariantNarrowingopen TransformerBoundedopen Iteratoropen Declarationopen Verifierlet verifier () =
let fw x = ( pmeet ( pwiden x (f x)) d) in
14Notice that the restriction of the mathematical invariance equations to machine integers aswell as the verification of absence of overflow could have been encoded in the same way, seeexercice 3-1.
The verification of absence of errors checks that at any point during anexecution without error up to some point in the computation will not have anerror at the next execution step.(* verifier .ml , interval invariant abstract domain *)let pwarning (b1 , b2 , b3 , b4) =
let m = " Potential error at line " inif not b1 then print_string (m ^"1\ n ");if not b2 then print_string (m ^"2\ n ");if not b3 then print_string (m ^"3\ n ");if not b4 then print_string (m ^"4\ n ");;
let pverify leq f a d =let b = leq (f a) d in
pwarning b;
The abstract interpreter performs the iterative abstract reachability fixpointoverapproximation with widening/narrowing and intersection with the decla-ration, then prints the least fixpoint result, and finally checks for errors.(* reachability verification with widening and narrowing *)open Invariantopen InvariantWideningopen InvariantNarrowingopen TransformerBoundedopen Iteratoropen Declarationopen Verifierlet verifier () =
let fw x = ( pmeet ( pwiden x (f x)) d) in
14Notice that the restriction of the mathematical invariance equations to machine integers aswell as the verification of absence of overflow could have been encoded in the same way, seeexercice 3-1.
let w = ( lfp pless pbot fw) inlet fn x = pnarrow x (f x) in
let a = ( lfp pgreater w fn) inpprint a; pverify cless f a d;;
verifier ();;
The result of the analysis is now the following.% ocamlc interval .ml intervalWidening .ml intervalNarrowing .ml \? invariant .ml invariantWidening .ml invariantNarrowing .ml \? transformerBounded .ml iterator .ml declaration .ml \? verifier .ml reachability_narrowing_declaration .ml% time ./a. out
1:( -1073741824 ,1073741823) 2:(1 ,100) 3:(1 ,100) 4:_|_Potential error at line 20.000 u 0.000 s 0:00.00 0.0% 0+0 k 0+0 io 0pf +0w%
Observe that the program execution always stops at program point 3 withan overflow outside the range [1� 100] so program point 4 is now unreachable(with an overapproximation we can prove the presence of dead code but notits absence).
Notice that the error is signaled as potential (with an overapproximationwe can prove the values to definitely be within given bounds but not to provethat execution ever assigns a given value to a variable). Here is a trace of theanalysis.% ocamlc interval .ml intervalWidening .ml intervalNarrowing .ml \? invariant .ml invariantWidening .ml invariantNarrowing .ml \? transformerBounded .ml iteratorTrace .ml declaration .ml\? verifier .ml reachability_narrowing_declaration_trace .ml% time ./a. out
1:( -1073741824 ,1073741823) 2:(1 ,100) 3:(1 ,100) 4:_|_Potential error at line 20.000 u 0.000 s 0:00.00 0.0% 0+0 k 0+0 io 0pf +0w%
Observe that the program execution always stops at program point 3 withan overflow outside the range [1� 100] so program point 4 is now unreachable(with an overapproximation we can prove the presence of dead code but notits absence).
Notice that the error is signaled as potential (with an overapproximationwe can prove the values to definitely be within given bounds but not to provethat execution ever assigns a given value to a variable). Here is a trace of theanalysis.% ocamlc interval .ml intervalWidening .ml intervalNarrowing .ml \? invariant .ml invariantWidening .ml invariantNarrowing .ml \? transformerBounded .ml iteratorTrace .ml declaration .ml\? verifier .ml reachability_narrowing_declaration_trace .ml% time ./a. out
Potential error at line 20.000 u 0.000 s 0:00.00 0.0% 0+0 k 0+0 io 0pf +0w%
Notice that in general the verification cannot be done during the analysissince a widening may cause an overapproximation potentially raising a poten-tial error while the narrowing may refine the analysis well enough to that thispotential error disappears.
Correcting the declaration(* declarationCorrect .ml *)open Intervalopen Invariant
1:( -1073741824 ,1073741823) 2:(1 ,100) 3:(1 ,100) 4:_|_Potential error at line 20.000 u 0.000 s 0:00.00 0.0% 0+0 k 0+0 io 0pf +0w%
Observe that the program execution always stops at program point 3 withan overflow outside the range [1� 100] so program point 4 is now unreachable(with an overapproximation we can prove the presence of dead code but notits absence).
Notice that the error is signaled as potential (with an overapproximationwe can prove the values to definitely be within given bounds but not to provethat execution ever assigns a given value to a variable). Here is a trace of theanalysis.% ocamlc interval .ml intervalWidening .ml intervalNarrowing .ml \? invariant .ml invariantWidening .ml invariantNarrowing .ml \? transformerBounded .ml iteratorTrace .ml declaration .ml\? verifier .ml reachability_narrowing_declaration_trace .ml% time ./a. out
Potential error at line 20.000 u 0.000 s 0:00.00 0.0% 0+0 k 0+0 io 0pf +0w%
Notice that in general the verification cannot be done during the analysissince a widening may cause an overapproximation potentially raising a poten-tial error while the narrowing may refine the analysis well enough to that thispotential error disappears.
Correcting the declaration(* declarationCorrect .ml *)open Intervalopen Invariant
1:( -1073741824 ,1073741823) 2:(1 ,100) 3:(1 ,100) 4:_|_Potential error at line 20.000 u 0.000 s 0:00.00 0.0% 0+0 k 0+0 io 0pf +0w%
Observe that the program execution always stops at program point 3 withan overflow outside the range [1� 100] so program point 4 is now unreachable(with an overapproximation we can prove the presence of dead code but notits absence).
Notice that the error is signaled as potential (with an overapproximationwe can prove the values to definitely be within given bounds but not to provethat execution ever assigns a given value to a variable). Here is a trace of theanalysis.% ocamlc interval .ml intervalWidening .ml intervalNarrowing .ml \? invariant .ml invariantWidening .ml invariantNarrowing .ml \? transformerBounded .ml iteratorTrace .ml declaration .ml\? verifier .ml reachability_narrowing_declaration_trace .ml% time ./a. out
Potential error at line 20.000 u 0.000 s 0:00.00 0.0% 0+0 k 0+0 io 0pf +0w%
Notice that in general the verification cannot be done during the analysissince a widening may cause an overapproximation potentially raising a poten-tial error while the narrowing may refine the analysis well enough to that thispotential error disappears.
Correcting the declaration(* declarationCorrect .ml *)open Intervalopen Invariant
3.10 ExercicesExercice 3-1Write the machine invariant equations (3.2) as a restriction of the mathemat-ical invariant equations (3.1) to machine integers in the declarative style ofsection 3.9.
Exercice 3-2Add an appropriate interval declaration for x in the following program
P � 1x := 1 ; while 2(x <= 100) do 3x := (x + 4); od4.
and verify its correctness by interval abstract interpretation.
3.11 Answers to ExercicesAnswer to exercice 3-1Let X = �(X ) be the mathematical invariant equations (3.1). Define D = ⇤D1⌥D2⌥ D3⌥ D4⌅ be the declaration such that D⇤ = [min_int⌥ max_int], ⇤ = 1⌥ ⌃ ⌃ ⌃ ⌥ 4with [⌅⌥ ⇥] � {⇧ ⇥ N | ⌅ ⇥ ⇧ ⇥ ⇥}. Then the machine invariant equations (3.2)are X = �(X ) ⇧ D where ⇧ is the pointwise meet X ⇧ Y � ⇤X1 ⇧ Y1⌥ X2 ⇧ Y2⌥X3 ⇧Y3⌥ X4 ⇧Y4⌅, which is the in the declarative style of section 3.9. Of course,when implementing this transformer, the machine computation of � must avoidoverflows in the analyser.
Answer to exercice 3-2The program
P � � var x : 1⌃⌃105 ; 1x := 1 ; while 2(x <= 100) do 3x := (x + 4); od4.
has the following abstract interval equations
26 P. C�⌅⇥�⇤
tial error while the narrowing may refine the analysis well enough to that thispotential error disappears.
Correcting the declaration(* declarationCorrect .ml *)open Intervalopen Invariantlet d =
yields no error, the verification is completed.% ocamlc interval .ml intervalWidening .ml intervalNarrowing .ml \? invariant .ml invariantWidening .ml invariantNarrowing .ml \? transformerBounded .ml iterator .ml declarationCorrect .ml \? verifier .ml reachability_narrowing_declaration_correct .ml% time ./a. out
1:( -1073741824 ,1073741823) 2:(1 ,101) 3:(1 ,100) 4:(101 ,101)0.000 u 0.000 s 0:00.00 0.0% 0+0 k 0+0 io 0pf +0w%
3.11 ConclusionIn this chapter 3 we introduced static analysis and verification methods basedon the idea of abstraction by the sole mean of examples. The mathematicalsoundness of the approach was taken for granted, in particular the correctnessof the invariance and interval equations and the existence of a least solu-tion was postulated. In the following chapters we provide the mathematicalfoundations justifying the correctness of these examples and study in detailthe notion of abstraction and its application to the semantics, proof, automaticanalysis and verification of computer programs.
3.12 BibliographyThe static interval analysis with widening/narrowing was introduced by (Cousotand Cousot, 1976) 15
15Interval static analysis uses intervals to overapproximate all possible computations of aprogram without ever executing so that all possible execution paths are taken into account.It should not be confused with Moore interval analysis or interval mathematics originating
1:( -1073741824 ,1073741823) 2:(1 ,100) 3:(1 ,100) 4:_|_Potential error at line 20.000 u 0.000 s 0:00.00 0.0% 0+0 k 0+0 io 0pf +0w%
Observe that the program execution always stops at program point 3 withan overflow outside the range [1� 100] so program point 4 is now unreachable(with an overapproximation we can prove the presence of dead code but notits absence).
Notice that the error is signaled as potential (with an overapproximationwe can prove the values to definitely be within given bounds but not to provethat execution ever assigns a given value to a variable). Here is a trace of theanalysis.% ocamlc interval .ml intervalWidening .ml intervalNarrowing .ml \? invariant .ml invariantWidening .ml invariantNarrowing .ml \? transformerBounded .ml iteratorTrace .ml declaration .ml\? verifier .ml reachability_narrowing_declaration_trace .ml% time ./a. out
Potential error at line 20.000 u 0.000 s 0:00.00 0.0% 0+0 k 0+0 io 0pf +0w%
Notice that in general the verification cannot be done during the analysissince a widening may cause an overapproximation potentially raising a poten-tial error while the narrowing may refine the analysis well enough to that thispotential error disappears.
Correcting the declaration(* declarationCorrect .ml *)open Intervalopen Invariant
--- All answers given by the abstract semantics are alwayscorrect with respect to the concrete semantics;--- Because of the information loss, not all questions canbe definitely answered with the abstract semantics;--- The more concrete semantics can answer more ques-tions;--- The more abstract semantics are more simple.
! P. Cousot 75 TASE 2007 Tutorial June 5th, 2007 — 9:00-11:00 AM
--- Automatic inference/refinement of abstractions:-- Mathematically, a most abstract sound and completeabstraction always exists for proving correctness;-- Finding such a sound and complete abstraction is log-ically equivalent to the discovery of an inductive ar-gument and checking of a proof obligation [1];-- In practice: I have no hope!Reference
[1] P. Cousot. Partial Completeness of Abstract Fixpoint Checking. In Proc. 4th Int. Symp. SARA’2000,LNAI 1864, pp. 1–25, Springer, 2000.
! P. Cousot 79 TASE 2007 Tutorial June 5th, 2007 — 9:00-11:00 AM
- Representation problem for the refined abstract domain [2]
What Can We Do When Too Much Information IsLost?
--- Automatic inference/refinement of abstractions:-- Mathematically, a most abstract sound and completeabstraction always exists for proving correctness;-- Finding such a sound and complete abstraction is log-ically equivalent to the discovery of an inductive ar-gument and checking of a proof obligation [1];-- In practice: I have no hope!Reference
[1] P. Cousot. Partial Completeness of Abstract Fixpoint Checking. In Proc. 4th Int. Symp. SARA’2000,LNAI 1864, pp. 1–25, Springer, 2000.
! P. Cousot 79 TASE 2007 Tutorial June 5th, 2007 — 9:00-11:00 AM
[2] P. Cousot, P. Ganty, and J.F. Raskin. Fixpoint-Guided Abstraction Refinements, In Proc. 14th Int. Symp.
What Can We Do When Too Much Information Is Lost?What Can We Do When Too Much Information Is
Lost? (Cont’d)
--- A modest alternative:-- Interactive choice of abstractions within a predefinedbroad spectrum;-- Manual decomposition of complex specifications intopartial requirements;-- User-interaction in the form of abstract testing.
! P. Cousot 80 TASE 2007 Tutorial June 5th, 2007 — 9:00-11:00 AM
E!ective computable approximations of an[in]finite set of points; Octagons 5
x
y
8
>
>
>
<
>
>
>
:
1 » x » 9x+ y » 771 » y » 9x` y » 07
5 A. Miné. A New Numerical Abstract Domain Based on Di!erence-Bound Matrices. PADO ’2001. LNCS2053, pp. 155–172. Springer 2001. See the The Octagon Abstract Domain Library on http://www.di.
ens.fr/~mine/oct/
! P. Cousot 86 TASE 2007 Tutorial June 5th, 2007 — 9:00-11:00 AM
E!ective computable approximations of an[in]finite set of points; Polyhedra 6
x
y
!
19x+ 77y » 200720x+ 07y – 0
6 P. Cousot & N. Halbwachs. Automatic discovery of linear restraints among variables of a program. ACMPOPL, 1978, pp. 84–97.
! P. Cousot 87 TASE 2007 Tutorial June 5th, 2007 — 9:00-11:00 AML. Chen, A. Mine, P. Cousot. A Sound Floating Point Polyhedra Abstract Domain, APLAS 2009, LNCS 5356,Springer, 2008, pp. 3--18.
Abstraction/refinement by tuning the cost/precision ratio inAstrée
– Approximate reduced product of a choice of coarsenable/refinableabstractions– Tune their precision/cost ratio by- Globally by parametrization- Locally by (automatic) analysis directivesso that the overall abstraction is not uniform.
Example of abstract domain choice in Astrée/* Launching the forward abstract interpreter *//* Domains: Guard domain, and Boolean packs (based on Absolutevalue equality relations, and Symbolic constant propagation(max_depth=20), and Linearization, and Integer intervals, andcongruences, and bitfields, and finite integer sets, and Floatintervals), and Octagons, and High_passband_domain(10), andSecond_order_filter_domain (with real roots)(10), andSecond_order_filter_domain (with complex roots)(10), andArithmetico-geometric series, and new clock, and Dependencies(static), and Equality relations, and Modulo relations, andSymbolic constant propagation (max_depth=20), and Linearization,and Integer intervals, and congruences, and bitfields, andfinite integer sets, and Float intervals. */
Parameterized abstractions– Parameterize the cost / precision ratio of abstractions in thestatic analyzer
– Examples:
- array smashing: --smash-threshold n (400 by default)! smash elements of arrays of size > n, otherwise individu-alize array elements (each handled as a simple variable).
- packing in octogons: (to determine which groups of variablesare related by octagons and where)´ --fewer-oct: no packs at the function level,´ --max-array-size-in-octagons n: unsmashed array ele-ments of size > n don’t go to octagons packs
Parameterized widenings– Parameterize the rate and level of precision of widenings in thestatic analyzer– Examples:- delayed widenings: --forced-union-iterations-at-beginning n (2by default)- thresholds for widening (e.g. for integers):
Analysis directives– Require a local refinement of an abstract domain– Example:
% cat repeat1.ctypedef enum {FALSE=0,TRUE=1} BOOL;int main () {int x = 100; BOOL b = TRUE;__ASTREE_boolean_pack((b,x));while (b) {x = x - 1;b = (x > 0);
}}% astree –exec-fn main repeat1.c |& egrep "WARN"repeat1.c:5.8-13::[call#main@2:loop@4>=4:]: WARN: signed int arithmeticrange [-2147483649, 2147483646] not included in [-2147483648, 2147483647]%
... Analysis with CBMCScript started on Tue Jul 29 23:44:00 2008% time ./cbmc filter.c...Starting Bounded Model CheckingUnwinding loop 1 iteration 1Unwinding loop 1 iteration 2...Unwinding loop 1 iteration 95479cbmc(34799) malloc: *** mmap(size=2097152) failed (error code=12)*** error: can’t allocate region*** set a breakpoint in malloc_error_break to debugterminate called after throwing an instance of ’std::bad_alloc’what(): St9bad_alloc
“The properties that can be proved by static analyzers are oftensimple” [2]Like in mathematics:
– May be simple to state (no overflow)
– But harder to discover (P 2 [`1325:4522; 1325:4522])– And di⌃cult to prove (since it requires finding a non trivialnon-linear invariant for second order filters with complexroots [Fer04], which can hardly be found by exhaustive enu-meration)
Reference
[2] Vijay D’Silva, Daniel Kroening, and Georg Weissenbacher. A Survey of Automated Techniques for Formal Software Verification.IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, Vol. 27, No. 7, July 2008.
Trace partitioning– State partitionning by program points (9)
– Trace partitionning (10)
– Trace partitionning abstract interpretation combines the ef-fects of case analysis and symbolic execution [MR05, RM07]
(9) all reachable states corresponding to a given program point are over-approximated by a local invariant on memory states reachable at thatprogram points
(10) portions of traces starting at a given program point for given memory values and finishing at a given program point are analyzed by anoverapproximating abstract execution
Example of iterated forward/backward analysisAdding an auxiliary counter k decremented in the loopbody and asserted to be null on loop exit:{x=y+2k,x>=y}
while (x <> y) do{x=y+2k,x>=y+2}
k := k - 1;{x=y+2k+2,x>=y+2}
x := x - 1;{x=y+2k+1,x>=y+1}
y := y + 1{x=y+2k,x>=y}
od{x=y,k=0}
assume (k = 0){x=y,k=0}
Moreover the di!er-ence of x and y mustbe even for proper ter-mination
! P. Cousot 100 TASE 2007 Tutorial June 5th, 2007 — 9:00-11:00 AM
program Variant_of_McCarthy_91_function;var X; Y : integer;function F(X : integer) : integer;beginif X > 100 then F := X ` 10else F := F(F(F(F(F(F(F(F(F(F(X +
9190))))))))));
end;begin
readln(X);{% X > 100 %}
Y := F(X);{% sometime true %}
end:
Example of cycle: F(100) ! F(190) ! F(180) ! F(170) ! F(160) ! F(150)
[AGM93] G. Amato, F. Giannotti, and G. Mainetto. Data sharing analysis for a database programming languagevia abstract interpretation. In R. Agrawal, S. Baker, and D.A.Bell, editors, Proc. 19th Int. Conf.on Very Large Data Bases, pages 405–415, Dublin, IE, 24–27 Aug. 1993. MORGANKAUFMANN.
[BCC+03] B. Blanchet, P. Cousot, R. Cousot, J. Feret, L. Mauborgne, A. Miné, D. Monniaux, and X. Rival.A static analyzer for large safety-critical software. In Proc. ACM SIGPLAN’2003 Conf. PLDI,pages 196–207, San Diego, CA, US, 7–14 June 2003. ACM Press.
[BPC01] J. Bailey, A. Poulovassilis, and C. Courtenage. Optimising active database rules by partial evaluationand abstract interpretation. In Proc. 8th Int. Work. on Database Programming Languages, LNCS2397, pages 300–317, Frascati, IT, 8–10 Sep. 2001. Springer.
[BS97] V. Benzaken and X. Schaefer. Static integrity constraint management in object-oriented databaseprogramming languages via predicate transformers. In M. Aksit and S. Matsuoka, editors, Proc. 11th
European Conf. on Object-Oriented Programming, ECOOP ’97, LNCS 1241. Springer, Jyväskylä,FI, 9–13 June 1997.
[CC76] P. Cousot and R. Cousot. Static determination of dynamic properties of programs. In Proc. 2nd Int.Symp. on Programming, pages 106–130, Paris, FR, 1976. Dunod.
[CC77] P. Cousot and R. Cousot. Abstract interpretation: a unified lattice model for static analysis ofprograms by construction or approximation of fixpoints. In 4th POPL, pages 238–252, Los Angeles,CA, 1977. ACM Press.
[CC79] P. Cousot and R. Cousot. Systematic design of program analysis frameworks. In 6th POPL, pages269–282, San Antonio, TX, 1979. ACM Press.
[CC92a] P. Cousot and R. Cousot. Comparing the Galois connection and widening/narrowing approaches toabstract interpretation, invited paper. In M. Bruynooghe and M. Wirsing, editors, Proc. 4th Int.Symp. on PLILP ’92, Leuven, BE, 26–28 Aug. 1992, LNCS 631, pages 269–295. Springer, 1992.
[CC92b] P. Cousot and R. Cousot. Inductive definitions, semantics and abstract interpretation. In 19th
[CC95] P. Cousot and R. Cousot. Formal language, grammar and set-constraint-based program analysis byabstract interpretation. In Proc. 7th FPCA, pages 170–181, La Jolla, CA, US, 25–28 June 1995.ACM Press.
[CC00] P. Cousot and R. Cousot. Temporal abstract interpretation. In 27th POPL, pages 12–25, Boston,MA, US, Jan. 2000. ACM Press.
[CC02] P. Cousot and R. Cousot. Systematic design of program transformation frameworks by abstractinterpretation. In 29th POPL, pages 178–190, Portland, OR, US, Jan. 2002. ACM Press.
[CC03] P. Cousot and R. Cousot. Parsing as abstract interpretation of grammar semantics. Theoret. Comput.Sci., 290(1):531–544, Jan. 2003.
[CC04] P. Cousot and R. Cousot. An abstract interpretation-based framework for software watermarking. In31st POPL, pages 173–185, Venice, IT, 14–16 Jan. 2004. ACM Press.
[CCF+07] P. Cousot, R. Cousot, J. Feret, L. Mauborgne, A. Miné, D. Monniaux, and X. Rival. Varieties ofstatic analyzers: A comparison with Astrée, invited paper. In M. Hinchey, He Jifeng, and J. Sanders,editors, Proc. 1st TASE ’07, pages 3–17, Shanghai, CN, 6–8 June 2007. IEEE Comp. Soc. Press.
[CCF+08] P. Cousot, R. Cousot, J. Feret, L. Mauborgne, A. Miné, D. Monniaux, and X. Rival. Combinationof abstractions in the Astrée static analyzer. In M. Okada and I. Satoh, editors, 11th ASIAN06,pages 272–300, Tokyo, JP, 6–8 Dec. 2006, 2008. LNCS 4435, Springer.
[CGJ+00] E.M. Clarke, O. Grumberg, S. Jha, Y. Lu, and H. Veith. Counterexample-guided abstractionrefinement. In E.A. Emerson and A.P. Sistla, editors, Proc. 12th Int. Conf. CAV ’00, Chicago, IL,US, LNCS 1855, pages 154–169. Springer, 15–19 Jul. 2000.
[CGR07] P. Cousot, P. Ganty, and J.-F. Raskin. Fixpoint-guided abstraction refinements. In G. Filé andH. Riis-Nielson, editors, Proc. 14th Int. Symp. SAS ’07, Kongens Lyngby, DK, LNCS 4634, pages333–348. Springer, 22–24 Aug. 2007.
[CH78] P. Cousot and N. Halbwachs. Automatic discovery of linear restraints among variables of a program.In 5th POPL, pages 84–97, Tucson, AZ, 1978. ACM Press.
[CMC08] L. Chen, A. Miné, and P. Cousot. A sound floating-point polyhedra abstract domain. To appear inThe Sixth ASIAN SYMP on Programming Languages and Systems, APLAS 2008, Bangalore, India,9–11 December, 2008, 2008.
[Cou97] P. Cousot. Types as abstract interpretations, invited paper. In 24th POPL, pages 316–331, Paris,FR, Jan. 1997. ACM Press.
[Cou00] P. Cousot. Partial completeness of abstract fixpoint checking, invited paper. In B.Y. Choueiry andT. Walsh, editors, Proc. 4th Int. Symp. SARA ’2000, Horseshoe Bay, TX, US, LNAI 1864, pages1–25. Springer, 26–29 Jul. 2000.
[Cou02] P. Cousot. Constructive design of a hierarchy of semantics of a transition system by abstractinterpretation. Theoret. Comput. Sci., 277(1—2):47–103, 2002.
[Cou03] P. Cousot. Verification by abstract interpretation, invited chapter. In N. Dershowitz, editor, Proc.Int. Symp. on Verification – Theory & Practice – Honoring Zohar Manna’s 64th Birthday,pages 243–268. LNCS 2772, Springer, Taormina, IT, 29 June – 4 Jul. 2003.
[Dan07] V. Danos. Abstract views on biological signaling. In Mathematical Foundations of ProgrammingSemantics, 23rd Annual Conf. (MFPS XXIII), 2007.
[DS07] D. Delmas and J. Souyris. Astrée: from research to industry. In G. Filé and H. Riis-Nielson, editors,Proc. 14th Int. Symp. SAS ’07, Kongens Lyngby, DK, LNCS 4634, pages 437–451. Springer, 22–24Aug. 2007.
[Fer04] J. Feret. Static analysis of digital filters. In D. Schmidt, editor, Proc. 30th ESOP ’2004, Barcelona,ES, volume 2986 of LNCS, pages 33–48. Springer, Mar. 27 – Apr. 4, 2004.
[Fer05a] J. Feret. The arithmetic-geometric progression abstract domain. In R. Cousot, editor, Proc. 6th Int.Conf. VMCAI 2005, pages 42–58, Paris, FR, 17–19 Jan. 2005. LNCS 3385, Springer.
[Fer05b] J. Feret. Numerical abstract domains for digital filters. In 1st Int. Work. on Numerical & SymbolicAbstract Domains, NSAD”05, Maison Des Polytechniciens, Paris, FR, 21 Jan. 2005.
[GM04] R. Giacobazzi and I. Mastroeni. Abstract non-interference: Parameterizing non-interference byabstract interpretation. In 31st POPL, pages 186–197, Venice, IT, 2004. ACM Press.
[Gra89] P. Granger. Static analysis of arithmetical congruences. Int. J. Comput. Math., 30:165–190, 1989.
[GRS00] R. Giacobazzi, F. Ranzato, and F. Scozzari. Making abstract interpretations complete. J. ACM,47(2):361–416, 2000.
[JP06] Ph. Jorrand and S. Perdrix. Towards a quantum calculus. In Proc. 4th Int. Work. on QuantumProgramming Languages, ENTCS, 2006.
[Min04a] A. Miné. Relational abstract domains for the detection of floating-point run-time errors. In D.Schmidt, editor, Proc. 30th ESOP ’2004, Barcelona, ES, volume 2986 of LNCS, pages 3–17.Springer, Mar. 27 – Apr. 4, 2004.
[Min04b] A. Miné. Weakly Relational Numerical Abstract Domains. Thèse de doctorat en informatique,École polytechnique, Palaiseau, FR, 6 Dec. 2004.
[Min06] A. Miné. The octagon abstract domain. Higher-Order and Symbolic Computation, 19:31–100,2006.
[Mon08] D. Monniaux. The pitfalls of verifying floating-point computations. TOPLAS, 30(3):Article No. 12,may 2008.
[MR05] L. Mauborgne and X. Rival. Trace partitioning in abstract interpretation based static analyzer. In M.Sagiv, editor, Proc. 14th ESOP ’2005, Edinburg, UK, volume 3444 of LNCS, pages 5–20. Springer,Apr. 2Ñ-10, 2005.
[PCJD07] M. Dalla Preda, M. Christodorescu, S. Jha, and S. Debray. Semantics-based approach to malwaredetection. In 34th POPL, pages 238–252, Nice, France, 17–19 Jan. 2007. ACM Press.
[Per06] S. Perdrix. Modèles formels du calcul quantique : ressources, machines abstraites et calcul parmesure. PhD thesis, Institut National Polytechnique de Grenoble, Laboratoire Leibniz, 2006.
[RM07] X. Rival and L. Mauborgne. The trace partitioning abstract domain. TOPLAS, 29(5), Aug. 2007.
[RT04] F. Ranzato and F. Tapparo. Strong preservation as completeness in abstract interpretation. In D.Schmidt, editor, Proc. 30th ESOP ’04, volume 2986 of LNCS, pages 18–32, Barcelona, ES, Mar. 29– Apr. 2 2004. Springer.
[RT06] F. Ranzato and F. Tapparo. Strong preservation of temporal fixpoint-based operators by abstractinterpretation. In A.E. Emerson and K.S. Namjoshi, editors, Proc. 7th Int. Conf. VMCAI 2006,pages 332–347, Charleston, SC, US, 8–10 Jan. 2006. LNCS 3855 , Springer.