1. Why Hi-Lite Ada?
J´rˆme Guitton, Johannes Kanig,
eo
Yannick Moy (AdaCore)
Boogie Workshop - August 1st, 2011

2. Overview
Introduction
Ada 2012 and Alfa
Ada and Why
The translation

3. Outline
Introduction
Ada 2012 and Alfa
Ada and Why
The translation

4. Unit Proof - I
Motivation
Allow gradual replacement of tests by program verification
Provide other means of verification when formal verification
fails:
VCs too complex for automated tools
manual proofs too costly
program constructs out of scope
aspects to be proved out of scope (timing, memory,
termination)
Concept
Apply formal verification and tests on a per-function basis
Tests still available to complement program verification
Has been applied at Airbus to avionics software Level A

5. Unit Proof - II
Problems
Expertise: required for writing contracts and carrying proof
Duplication: contract not shared between testing and proof
Isolation: unit test and unit proof cannot be combined
Confusion: not the same semantics for testing and proof
Debugging: contracts and proof cannot be executed

6. Hi-Lite : Test and Proof
French research project started in May 2010, over 3 years
Motivation
Source language: Ada
Combine test and proof in a single contract based technology
Same language and semantics for test and proof
Application to existing projects should be possible
Ease of use: Automation
The upcoming avionics standard DO-178C

7. Outline
Introduction
Ada 2012 and Alfa
Ada and Why
The translation

8. New Forms of Expressions in Ada 2012
if-expressions:
( if X = 0 then 0 else 1 / X )
case-expressions:
type Week_Day is
( Mon , Tue , Wed , Thu , Fri , Sat , Sun ) ;
...
( case X is
when Mon .. Fri = > True
when others = > False )
quantified expressions:
( for all I in X ’ Range = > X ( I ) > 0)
( for some I in X ’ Range = > X ( I ) > 0)

9. Contracts
A function with pre- and postcondition
function Search ( S : String ; C : Character )
return Natural
with
Pre = > ( S /= " " ) ,
Post = >
(( if Search ’ Result /= 0 then
S ( Search ’ Result ) = C )
and
( for all X in
S ’ First .. Search ’ Result - 1 = >
S ( X ) /= C ) ) ;

10. The Alfa Subset of Ada
Definition
Includes all features suitable for program verification
Excludes pointers, concurrency, exceptions
No side effects in annotations
No ambiguous expressions
Classification of each function
Non-Alfa: only very light restrictions
Partially in Alfa: signature and contract of the function are in
Alfa, no restriction on the body
(Entirely) in Alfa: signature, contract and body of the
function are in Alfa, only functions at least partially in Alfa
are called

11. Alfa and Ada
Alfa and Non-Alfa code can be freely mixed
Automatic detection of functions that are (partially or fully) in
Alfa
Only those functions are translated to Why
Remaining code can be covered by testing
Rationale
You don’t need to write all your code in Alfa
Application to legacy code base
Allow packages with complex code (pointers, concurrency)

12. Outline
Introduction
Ada 2012 and Alfa
Ada and Why
The translation

13. The GNATprove tool

14. Automatic Effects Computation
Procedure
First phase of GNATprove
Compute localized effects of each function (do not take into
account effects of called functions)
A few restrictions to Ada to maintain correctness
No function pointers
No implicit aliasing
These situations are recognized by the compiler (work in
progress)

15. An Ada Program
Spec for package A
types
global vars
function decls
contracts
Body for package A
local types
local vars
functions

16. An Ada Program
Spec for package A
types
Spec for package B
global vars
function decls
contracts
Body for package A
local types Body for package B
local vars
functions

17. An Ada Program
Spec for package A
types
Spec for package B
global vars
function decls
contracts
Body for package A
local types Body for package B
local vars
functions

18. An Ada Program
Spec for package A
types
Spec for package B
global vars
function decls
contracts
Body for package A
local types Body for package B
local vars
functions

19. A First Idea for Why Files
code for
spec of A
code for
body of A

20. A First Idea for Why Files
code for code for
spec of A spec of B
code for code for
body of A body of B

21. A First Idea for Why Files
code for code for
spec of A spec of B
code for code for
body of A body of B

22. A First Idea for Why Files
code for code for
spec of A spec of B
code for code for
body of A body of B

23. A First Idea for Why Files
code for code for
spec of A spec of B
Achieved
Ada visibility modeled
circular dependencies
avoided
code for code for (mutual) recursion even
body of A body of B across packages

24. A First Idea for Why Files
code for code for
spec of A spec of B
Achieved
Ada visibility modeled
circular dependencies
avoided
code for code for (mutual) recursion even
body of A body of B across packages
Problem
Effects on local variables introduce new dependencies
Example: function in B modifies indirectly local variable of A

25. A First Idea for Why Files
code for code for
spec of A spec of B
Achieved
Ada visibility modeled
circular dependencies
avoided
code for code for (mutual) recursion even
body of A body of B across packages
Problem
Effects on local variables introduce new dependencies
Example: function in B modifies indirectly local variable of A
circular dependency!

26. Our Proposed Solution
code for types and
vars in spec of A
code for types and
vars in body of A
code for funcs
in spec of A
code for funcs
in body of A

27. Our Proposed Solution
code for types and
vars in spec of A
code for types and
vars in body of A
code for funcs
in spec of A
code for funcs
in body of A

28. Our Proposed Solution
code for types and code for types and
vars in spec of A vars in spec of B
code for types and code for types and
vars in body of A vars in body of B
code for funcs code for funcs
in spec of A in spec of B
code for funcs code for funcs
in body of A in body of B

29. Our Proposed Solution
code for types and code for types and
vars in spec of A vars in spec of B
code for types and code for types and
vars in body of A vars in body of B
code for funcs code for funcs
in spec of A in spec of B
code for funcs code for funcs
in body of A in body of B

30. Our Proposed Solution
code for types and code for types and
vars in spec of A vars in spec of B
code for types and code for types and
vars in body of A vars in body of B
code for funcs code for funcs
in spec of A in spec of B
code for funcs code for funcs
in body of A in body of B

31. Outline
Introduction
Ada 2012 and Alfa
Ada and Why
The translation

32. Ada Integer Types
New type definition:
type One_Ten is range 1 .. 10;
Subtype (inherits base range):
subtype One_Ten_Integer is
Integer range 1 .. 10;
Inserted checks
Range check on assignment (or parameter passing)
Overflow check on intermediate operations on the base type

33. Ada Integer Types in Why
type t
predicate t_in_range (x : int) = -128 <= x <= 127
logic t_to_int : t -> int
logic t_of_int : int -> t
parameter t_of_int_ :
n : int ->
{ t_in_range (n) } t { t_to_int (result) = n }
parameter t_in_range_ :
n : int ->
{ t_in_range (n) } int { result = n }
axiom t_range :
forall x : t. t_in_range (t_to_int (x))
...

34. Execution Semantics for Assertions - I
Objective
Same semantics for test and proof
Assertions should be runtime error free
Possibilities
Consider assertions with runtime errors as false
Implicit assumptions in the case of preconditions
Consider assertions with runtime errors as incorrect
Additional VCs to prove absence of runtime errors in specs
No implicit assumptions
Hi-Lite: second possibility has been chosen for clarity

35. Execution Semantics for Assertions - II
Example in Ada
function Add (X , Y : One_Ten ) return One_Ten
with Pre = > ( X + Y < 10) ;
Translation to Why
let add (x : one_ten) (y : one_ten) =
{ true }
ignore
(one_ten_range_
(one_ten_to_int (x) + one_ten_to_int (y)) < 10);
assume
{ one_ten_to_int (x) + one_ten_to_int (y) < 10 };
... (* translated body of function Add *)

36. Loop Assertions - I
The trivial translation:
Ada loop Why translation
while C loop
pragma Assert ( P ) ; while C do
... { P }
end loop ; ...
done
Does not reflect runtime behavior:
Assertion not executed when C is always false
Assertion not executed after end of loop

37. Loop Assertions - II
Our translation
if c then
try
while true do (* infinite loop *)
{ invariant c and p}
...
if not c then raise Exit
done
with Exit -> ();

38. Quantified Expressions
A pathological example
( for all J in 1 .. 10 = >
( if J = 5 then J /= 1 / 0 else False ) )
A simple approach
∀ 1 ≤ j ≤ 10. if j = 5 then 0 = 0 else true
Proposed by an anonymous referee
∀ 1 ≤ j ≤ 10.
(∀ 1 ≤ j ≤ j − 1. if j = 5 then 0 = 0 else true) and
(∀ 1 ≤ j ≤ j − 1. if j = 5 then j = 1/0 else false)
⇒ if j = 5 then 0 = 0 else true

39. Conclusion
Hi-Lite
Allow combining test and proof
Easy adoption of formal verification, applied to new and
existing projects
Future Work
Migration to Why3
Verification of consistency of contracts