CSC313 High Integrity Systems/CSCM13 Critical Systems. CSC313/CSCM13 Chapter 2 1/ 221

Transcription

1 CSC313 High Integrity Systems/CSCM13 Critical Systems CSC313/CSCM13 Chapter 2 1/ 221

2 CSC313 High Integrity Systems/ CSCM13 Critical Systems Course Notes Chapter 2: SPARK Ada Sect. 2 (f) Anton Setzer Dept. of Computer Science, Swansea University csetzer/lectures/ critsys/current/index.html October 30, 2017 CSC313/CSCM13 Chapter 2 2/ 221

3 2 (a) Introduction into Ada 2 (b) Architecture of SPARK Ada 2 (c) Language Restrictions in SPARK Ada 2 (d) Data Flow Analysis 2 (e) Information Flow Analysis 2 (g) Verification Cond. (Range, Loops, Procedures, Functions) 2 (h) Example: A railway interlocking system CSC313/CSCM13 Chapter 2 3/ 221

4 2 (a) Introduction into Ada 2 (b) Architecture of SPARK Ada 2 (c) Language Restrictions in SPARK Ada 2 (d) Data Flow Analysis 2 (e) Information Flow Analysis 2 (g) Verification Cond. (Range, Loops, Procedures, Functions) 2 (h) Example: A railway interlocking system CSC313/CSCM13 Sect. 2 (f) 142/ 221

5 Pre- and Post-Conditions Two kinds of annotations are relevant: Pre-conditions, e.g.: with Pre => M >= 0 and N < 0; Expressing: at the beginning variable M is 0 and variable N is < 0. Post-conditions, e.g.: with Post => M = M Old + 1; Expressing: after having executed the procedure the value of M is the same as the value of M when beginning the procedure (denoted by M Old, incremented by 1. Then examiner generates formulae which express: If the pre-conditions hold, and the procedure is executed, afterwards the post-condition holds. If there are no pre-conditions, then the formula expresses that the post-condition holds always. (sect2f/example2f-1/) CSC313/CSCM13 Sect. 2 (f) 143/ 221

6 Notation in pre-2014 SPARK Ada -- #pre M >= 0 and N < 0; -- #post M = M +1; Here M is the pre-2014 SPARK Ada notation for X Old. CSC313/CSCM13 Sect. 2 (f) 144/ 221

7 Hoare Logic The basic formal system which takes pre- and post-conditions in an imperative program and derives generated verification conditions, is called Hoare Logic Named after Sir Tony Hoare (Professor emeritus from Oxford and Microsoft Research, Cambridge), Computer Scientist. Winner of the Turing Award Knighted by the Queen for his achievements in Computer Science. CSC313/CSCM13 Sect. 2 (f) 145/ 221

8 Tony Hoare with his Wife Jill (After having been knighted by the Queen.) CSC313/CSCM13 Sect. 2 (f) 146/ 221

9 Quotation Tony Hoare The most important property of a program is whether it accomplishes the intention of its user. CSC313/CSCM13 Sect. 2 (f) 147/ 221

10 Verification Conditions In post-conditions, X Old stands for the value of X before executing the procedure, X stands for the value after executing it, e.g. X=X Old+1; expresses: The value of X after executing the procedure is the value of X before executing it + 1. X Old can occur only in post-conditions (especially not in assert statements introduced later); seems to be due to a restriction of Ada. CSC313/CSCM13 Sect. 2 (f) 148/ 221

11 Verification Conditions On the white board I will sometimes write for brevity X instead of X Old. For instance we write X = X + 1 instead of X = X Old + 1 CSC313/CSCM13 Sect. 2 (f) 149/ 221

12 Connectives in Verification Conditions Formulae are built using: Boolean valued expressions E.g. N = M, N < M or F(N), if F(N) of type Boolean, Boolean connectives and, or, not, xor, if condition then conclusion which stands for condition conclusion if condition then ifcondition else elsecondition which stands for (condition ifcondition) ( (condition) elsecondition) quantifiers for all => for some => Remark: If in the pre-condition there are occurrences of quantifiers, the whole pre-condition is at the moment ignored. In the post-condition they are treated correctly. CSC313/CSCM13 Sect. 2 (f) 150/ 221

13 Example (Verification Conditions) Example (not very meaningful): with => Pre => ((M >= 0 xor N < 0) or (if not (N > 0) then M > 0) and (if N > 0 then M > 0 else M < 0)), Post => ((for all X in => g(x,m )) or (for some X in Integer => X = M Old + 1)); (sect2f/example2f-2/, example2f-3/, example2f-3b/) CSC313/CSCM13 Sect. 2 (f) 151/ 221

14 Remark on X Old X Old should only be used if X is an input-output parameter (locally or globally) If it is an input parameter only, then it cannot be changed, so X and X Old are always the same. In that case SPARK Ada issues a warning. If it is an output parameter only, then it has no initial value, so X Old is in fact undefined. In that case SPARK Ada doesn t (yet?) issue a warning. An output parameter of a procedure cannot occur in the pre-condition, because its initial value is undefined. (sect2f/example2f-5/) CSC313/CSCM13 Sect. 2 (f) 152/ 221

15 Example 1 (Verification Conditions) Assume the following wrong program: procedure Wrong Increment(X : in out Integer) with Depends => (X => X), Pre => X >= 0, Post => X = X Old + 1 and X >= 1; procedure body Wrong Increment(X : in out Integer) is begin X := X + X; end Wrong Increment; The mistake in this program is that the body should read X:= X + 1; instead of X := X + X;. The post-condition is not fulfilled in general. (sect2f/example2f-6/) CSC313/CSCM13 Sect. 2 (f) 153/ 221

16 Example (Cont.) procedure Wrong Increment(X : in out Integer) with Depends => (X => X), Pre => X >= 0, Post => X = X Old + 1 and X >= 1; procedure body Wrong Increment(X : in out Integer) is begin X := X + X; end Wrong Increment; When going through the program we see that at the end X = X Old + X Old Therefore, replacing X by X Old + X Old the post-condition reads: X Old + X Old = X Old + 1 X Old +X Old 1 CSC313/CSCM13 Sect. 2 (f) 154/ 221

17 Example 1 (Verification Conditions) procedure Wrong Increment(X : in out Integer) with Depends => (X => X), Pre => X >= 0, Post => X = X Old + 1 and X >= 1; procedure body Wrong Increment(X : in out Integer) is begin X := X + X; end Wrong Increment; That the pre-condition implies the post-condition therefore reads X Old 0 X Old + X Old = X Old + 1 X Old Here binds more than therefore the formula is the same as X Old 0 (X Old + X Old = X Old + 1 X Old + X Old 1) We call the above the from the pre- and post-conditions. generated verification condition derived CSC313/CSCM13 Sect. 2 (f) 155/ 221

18 Example (Verification Conditions) We use in this module usually verification conditions for the conditions you write in the code, and generated verification conditions for the ones derived by using Hoare Logic. Since in mathematics one usually writes lower case characters we replace X by x. Since there are only occurrences of x Old, we replace them by x. We obtain x 0 x + x = x + 1 x + x 1 This above formulae has to be treated as being implicitly universally quantified, and stands for x.(x 0 x + x = x + 1 x + x 1) CSC313/CSCM13 Sect. 2 (f) 156/ 221

19 Example (Verification Conditions) x.(x 0 x + x = x + 1 x + x 1) This corresponds to what the correctness of the function means: For all inputs x, we have that, if x fulfils the pre-condition, then after executing the program it fulfils the post-condition. That the above formula does not hold can be shown by giving a counter example: Take x := 0. Then x 0 holds, but not x + x = x + 1. The program is incorrect, since the generated verification conditions don t hold (universally). In order for the program to be correct it needs to be correct for all arguments. Note that for x = 1 the formula is true, but the program is still incorrect. CSC313/CSCM13 Sect. 2 (f) 157/ 221

20 Why3 Platform SPARK Ada uses the Why3 system (without the user interface), which is free software developed by the French research organisation INRIA. Why3 is a tool which converts imperative code from the intermediate languages mlw and code from the language why3 into generated verification conditions which are then fed into various automated theorem provers Alt-ergo, CVC3, CVC4, and Z3. interactive theorem provers Coq and Isabelle. CSC313/CSCM13 Sect. 2 (f) 158/ 221

21 Architecture of Why3 Platform (Source: CSC313/CSCM13 Sect. 2 (f) 159/ 221

22 Why3 Platform SPARK Ada uses the why3 system to generate verification conditions and feed them into the automated theorem prover alt-ergo. It then reports whether they have been proven or not proven. One can feed the conditions as well into other automated theorem provers and interactive theorem provers such as Coq. In order to display the generated verification conditions, it is useful to install why3 separately and run why3 on the.mlw files generated by SPARK Ada. CSC313/CSCM13 Sect. 2 (f) 160/ 221

23 Result of Applying Why3 to.mlw Files CSC313/CSCM13 Sect. 2 (f) 161/ 221

24 Current Problems with Why3 The version used in the Linux Lab currently displays error messages as on the following screen These error messages are due to the fact that the spark ada version refers to a different version of why3 then the why3 ide we are using. You can ignore error messages of the form. File..., line..., characters...: axiom... does not contain any local abstract symbol The SPARK Ada documentation doesn t mention the why3 system they use why3 without the GUI, but don t intend the verification conditions to be viewed uwing the why3 with GUI. CSC313/CSCM13 Sect. 2 (f) 162/ 221

25 Error Messages of Why3 CSC313/CSCM13 Sect. 2 (f) 163/ 221

26 Main Generated Verification Conditions in Why3 (with Range Check) CSC313/CSCM13 Sect. 2 (f) 164/ 221

27 Interpreting the Output of Why3 Machine integers have a limited amount of bytes. Therefore the integers cannot be arbitrarily big and and small. There exists a maximum and minimum machine integer. SPARK Ada adds conditions guaranteeing that the integers are between the minimum and maximum integer. It has a relation in_range1 o expressing that o is between the minimum and maximum integer. There occurs as well a relation dynamic_property1 first1 last1 x which is automatically generated, but is equal to in_range1 x CSC313/CSCM13 Sect. 2 (f) 165/ 221

28 Interpreting the Output of Why3 The above is sufficient for understanding the output of why3 if one uses progressively split for generating verification conditions (recommended). Otherwise one will see when using wh3 as well a data type integer which are machine integers and therefore bounded, a data type int which are unbounded mathematical integers, and an operation to_int : integer int CSC313/CSCM13 Sect. 2 (f) 166/ 221

29 Significance of Range Checks For a program SPARK Ada generates verification conditions which check that in each step of the program all integers stay in the range of machine integers. Note that it is necessary to have these range checks, because otherwise we could indeed get overflow errors. If x is a very large integer, x + x might actually be out of range and result in an overflow error at run time. CSC313/CSCM13 Sect. 2 (f) 167/ 221

30 Turning Off Check for Range Conditions When learning SPARK Ada, it is good to initially ignore the range conditions. We have provided a file mainwithoutrangecheck.gpr which is an alternative to the main.gpr file. When using this file range checks will be switched off The main change is that the switch in main.gpr for Default_Switches ( ada ) use ( -gnatwa ); have been replaced by for Default_Switches ( ada ) use ( -gnato33 ); CSC313/CSCM13 Sect. 2 (f) 168/ 221

31 Simplified Generated Verification Conditions In this section we will discuss the verification condition excluding the range conditions. We will show however as as well the verification conditions including the range conditions. In the next subsection I will discuss how one can enhance the pre-, post- and other conditions so that SPARK Ada proves that the integers stay within the range of machine integers. CSC313/CSCM13 Sect. 2 (f) 169/ 221

32 Main Verification Conditions in Why3 Without Range Check CSC313/CSCM13 Sect. 2 (f) 170/ 221

33 Simplified Generated Verification Conditions Using a format used in pre-2014 Spark Ada we can write the generated verification condition (excluding range check) as follows: H1 : x 0. H2 : x1 = x + x. C1 : x1 = x + 1. C2 : x1 1. In the above (a format used in pre-2014 SPARK Ada) H1, H2,... are hypotheses, C1, C2,... are conclusions and the above formula stands for x 0 x1 = x + x x1 = x + 1 x1 1 CSC313/CSCM13 Sect. 2 (f) 171/ 221

34 Simplified Generated Verification Conditions We choose the above since usually generated verification conditions will have the form H1 H2 Hn C1 C2 Cm CSC313/CSCM13 Sect. 2 (f) 172/ 221

35 Simplified Generated Verification Conditions H1 : x 0. H2 : x1 = x + x. C1 : x1 = x + 1. C2 : x1 1. We simplify this to H1 : x 0. C1 : x + x =x + 1. C2 : x + x 1 which is the formula we obtained before: x 0 x + x = x + 1 x + x 1 CSC313/CSCM13 Sect. 2 (f) 173/ 221

36 Main Generated Verification Conditions in Why3 with Range Check CSC313/CSCM13 Sect. 2 (f) 174/ 221

37 Additional Generated Verification Conditions for Range Checks CSC313/CSCM13 Sect. 2 (f) 175/ 221

38 Additional Generated Verification Conditions for Range Checks CSC313/CSCM13 Sect. 2 (f) 176/ 221

39 Example 2 (Verification Conditions) Assume the correct program: procedure Correct Increment(X : in out Integer) with Depends => (X => X), Pre => X >= 0, Post => X = X Old + 1 and X >= 1; procedure body Correct Increment(X : in out Integer) is begin X := X + 1; end Correct Increment; (sect2f/example2f-7/) CSC313/CSCM13 Sect. 2 (f) 177/ 221

40 Example 2 (Cont.) procedure Correct Increment(X : in out Integer) with Depends => (X => X), Pre => X >= 0, Post => X = X Old + 1 and X >= 1; procedure body Correct Increment(X : in out Integer) is begin X := X + 1; end Correct Increment; When going through the program, we see that at the end X = X Old + 1. Therefore the post-condition reads X Old + 1 = X Old + 1 X Old CSC313/CSCM13 Sect. 2 (f) 178/ 221

41 Example 2 (Cont.) procedure Correct Increment(X : in out Integer) with Depends => (X => X), Pre => X >= 0, Post => X = X Old + 1 and X >= 1; procedure body Correct Increment(X : in out Integer) is begin X := X + 1; end Correct Increment; The complete generated verification condition is therefore X Old 0 X Old + 1 = X Old + 1 X Old which is then written as x 0 x + 1 = x + 1 x CSC313/CSCM13 Sect. 2 (f) 179/ 221

42 Output of Why3 Applied to Output from Spark Ada (Without Range Check) CSC313/CSCM13 Sect. 2 (f) 180/ 221

43 Example 2 (Cont.) This reads in the pre-spark 2014 syntax as follows: H1 : x 0 H2 : x1 = x + 1 C1 : x1 = x + 1 C2 : x1 1 The last condition can be simplified to H1 : x 0 C1 : x+1 = x + 1 C2 : x+1 1 CSC313/CSCM13 Sect. 2 (f) 181/ 221

44 Example 2 (Cont.) H1 : x 0 C1 : x+1 = x + 1 C2 : x+1 1 This condition is the same as what we obtained by hand: x 0 x + 1 = x + 1 x This condition would be provable. The range conditions regarding machine integers are not provable, as reported by SPARK Ada. CSC313/CSCM13 Sect. 2 (f) 182/ 221

45 Main Output of Why3 With Range Conditions CSC313/CSCM13 Sect. 2 (f) 183/ 221

46 Additional Range conditions CSC313/CSCM13 Sect. 2 (f) 184/ 221

47 Additional Range conditions CSC313/CSCM13 Sect. 2 (f) 185/ 221

48 Assert And Cut Condition One can insert in between the procedures an assert_and_cut condition. Now the formulae express: From the pre-condition follows at that position the assert_and_cut-condition. From the assert_and_cut-condition at that position follows the post-condition. Assert_and_cut conditions serve therefore as intermediate proof-goals. CSC313/CSCM13 Sect. 2 (f) 186/ 221

49 SPARK Ada Syntax for Assert And Cut The pre-2014 syntax was -- # assert X = 1; The new syntax is pragma Assert_And_Cut (X = 1); CSC313/CSCM13 Sect. 2 (f) 187/ 221

50 Several Assert And Cut Conditions One can have as well several assert_and_cut-conditions. If one has 2 assert_and_cut-conditions for instance the conditions express From the pre-condition follows the first assert_and_cut-condition (at its place). From the the first assert_and_cut-condition follows the second assert_and_cut-condition (at its place) From the the second assert_and_cut-condition follows the post-condition. CSC313/CSCM13 Sect. 2 (f) 188/ 221

51 Example Assert And Cut Condition Consider the program: procedure Ex Assert And Cut(X : in out Integer) with Depends => (X => X), Pre => X = 0, Post => X = 3; procedure Ex Assert And Cut(X : in out Integer) is begin X := X + 1; pragma Assert_And_Cut (X = 1); X := X + 1; pragma Assert_And_Cut (X = 2); X := X + 1; end Ex Assert Cut; (sect2f/example2f-9/) CSC313/CSCM13 Sect. 2 (f) 189/ 221

52 Example Assert And Cut Condition The implication from the pre-condition to the first assert_and_cut condition is: X Old = 0 X Old+1 = 1. That the first assert_and_cut condition implies the second assert_and_cut condition is the following: X = 1 X+1 = 2; That the second assert_and_cut condition implies the post-condition is the following: X = 2 X+1 = 3; CSC313/CSCM13 Sect. 2 (f) 190/ 221

53 Why3 Precondition implies Assert And Cut 1 (Without Range Check) CSC313/CSCM13 Sect. 2 (f) 191/ 221

54 Example 2 (Cont.) Pre condition implies first assert_and_cut-condition H1 : x = 0 H2 : x1 = x + 1 C1 : x1 = 1 This can be simplified to H1 : x = 0 C1 : x+1 = 1 CSC313/CSCM13 Sect. 2 (f) 192/ 221

55 Why3 Assert And Cut1 to Assert And Cut2 (Without Range Check) CSC313/CSCM13 Sect. 2 (f) 193/ 221

56 Example 2 (Cont.) First assert_and_cut-condition implies second assert_and_cut-condition H1 : x = 0 H2 : x1 = 1 H3 : x2 = x1 + 1 C1 : x2 = 2 This can be simplified to (omitting superfluous x) H1 : x1 = 1 C1 : x1 +1 = 2 CSC313/CSCM13 Sect. 2 (f) 194/ 221

57 Additional Use of Pre-Condition Note that the pre-condition was added here (and later) as an axiom. Therefore it can be used for proving all statements including from first Assert_And_Cut statement follows second Assert_And_Cut statement, from last Assert_And_Cut statement follows post-condition. It looks as if this is there to keep compatibilty with previous versions of SPARK Ada. CSC313/CSCM13 Sect. 2 (f) 195/ 221

58 Why3 Assert And Cut3 to Post Condition CSC313/CSCM13 Sect. 2 (f) 196/ 221

59 Example 2 (Cont.) Second assert_and_cut-condition implies post-condition H1 : x = 0 H2 : x1 = 2 H3 : x2 = x1 + 1 C1 : x2 = 3 This can be simplified to (omitting superfluous x) H1 : x1 = 2 C1 : x1 +1 = 3 CSC313/CSCM13 Sect. 2 (f) 197/ 221

60 Why3 Precondition implies Assert And Cut 1 (With Range Check) CSC313/CSCM13 Sect. 2 (f) 198/ 221

61 Why3 Assert And Cut1 to Assert And Cut2 (With Range Check) CSC313/CSCM13 Sect. 2 (f) 199/ 221

62 Why3 Assert And Cut3 to Post Condition (With Range Check) CSC313/CSCM13 Sect. 2 (f) 200/ 221

63 Why3 Range Condition 1 CSC313/CSCM13 Sect. 2 (f) 201/ 221

64 Why3 Range Condition 2 CSC313/CSCM13 Sect. 2 (f) 202/ 221

65 Why3 Range Condition 3 CSC313/CSCM13 Sect. 2 (f) 203/ 221

66 Assert Condition vs Assert And Cut There is as well an assert directive. The difference is: If one has an assert_and_cut directive, then previous verification conditions are not included in the next step. If one has an assert directive, then previous verification conditions are included. So if one has two assert conditions then the generated verification condition are From the pre-condition follows the first assert-condition (at its place). From the pre-condition and the first assert-condition (at its place) follows the second assert-condition (at its place) From the pre-condition and the first assert-condition (at its place) and the second assert-condition (at its place) follows the post-condition. CSC313/CSCM13 Sect. 2 (f) 204/ 221

67 Assert vs Assert And Cut If one has assert conditions instead, then the first condition is as before, but the second and third are From the pre-condition follows the first assert-condition (at its place). From the first assert-condition (at its place) follows the second assert-condition (at its place) From the second assert-condition (at its place) follows the post-condition. CSC313/CSCM13 Sect. 2 (f) 205/ 221

68 SPARK Ada Syntax for Assert The pre-2014 syntax was --# check X = 1; The new syntax is pragma Assert (X = 1); CSC313/CSCM13 Sect. 2 (f) 206/ 221

69 Example Assert Condition Consider the program: procedure One Assert(X : in out Integer) with Depends => (X => X), Pre => X = 0, Post => X = 2; procedure body One Assert(X : in out Integer) is begin X := X + 1; pragma Assert (X = 1); X := X + 1; end One Assert; That the pre-condition implies the assert condition is the following generated verification condition: X Old = 0 X Old+1 = 1; (sect2f/example2f-8/) CSC313/CSCM13 Sect. 2 (f) 207/ 221

70 Example Assert Condition Consider the program: procedure One Assert(X : in out Integer) with Depends => (X => X), Pre => X = 0, Post => X = 2; procedure body One Assert(X : in out Integer) is begin X := X + 1; pragma Assert (X = 1); X := X + 1; end One Assert; That the pre- and the assert-condition implies the post-condition is the following generated verification condition: X Old = 0 X Old+1 = 1 (X Old+1) + 1 = 2; CSC313/CSCM13 Sect. 2 (f) 208/ 221

71 Why3 - Pre Condition implies Assert Condition (Without Range Check) CSC313/CSCM13 Sect. 2 (f) 209/ 221

72 Generated Verification Conditions Pre condition implies assert-condition (range conditions omitted, as well int the following): H1 : x = 0 H2 : x1 = x + 1 C1 : x1 = 1 which is just or simplified: H1 : x = 0 C1 : x+1 = 1 x = 0 x + 1 = 1 CSC313/CSCM13 Sect. 2 (f) 210/ 221

73 Why3 - Pre Condition + Assert implies Post Condition CSC313/CSCM13 Sect. 2 (f) 211/ 221

74 Generated Verification Conditions Condition that pre- condition and assert condition imply post-condition reads H1 : x = 0 H2 : x1 = x + 1 H3 : x1 = 1 H4 : x2 = x1 + 1 C1 : x2 = 2 or simplified: H1 : x = 0 H2 : x+1= 1 C1 : (x+1)+1 = 2 which is just x = 0 x + 1 = 1 (x + 1) + 1 = 2 CSC313/CSCM13 Sect. 2 (f) 212/ 221

75 Why3 - Pre Condition implies Assert Condition (With Range Check) CSC313/CSCM13 Sect. 2 (f) 213/ 221

76 Why3 - Pre Condition + Assert implies Post Condition (With Range Check) CSC313/CSCM13 Sect. 2 (f) 214/ 221

77 Why3 - Range Condition 1 CSC313/CSCM13 Sect. 2 (f) 215/ 221

78 Why3 - Range Condition 2 CSC313/CSCM13 Sect. 2 (f) 216/ 221

79 Assert in Other Languages Many many languages (e.g. C++, Java) have an assert directive. The condition is then usually checked at run time, e.g. in C++ #include <assert.h> assert (myint!=null); Checking of this condition can be disabled using #define NDEBUG In the Boost library for C++ there is as well a static assert. It allows to check at compile time whether certain values which are determined by the template mechanism have certain values: BOOST STATIC ASSERT(std::numeric limits<int>::digits >= 32); This doesn t allow to check values of the program which are obtained after the execution of some code. CSC313/CSCM13 Sect. 2 (f) 217/ 221

80 Assert, Pre- and Post Conditions in Standard Ada In Ada 2005 assert was introduced to be used similarly to other languages: depending on pragmas (Assert, Assertion_Policy), the assert statement is checked with messages being printed out, or it is ignored. Therefore they were meant to be decidable conditions. That explains why X Old is not allowed in assert statements, since it would require the compiler to keep track of the original value of X. In Ada 2012 pre- and post-conditions were added, which can be treated similarly. In Ada 2012 the intention for pre- and post-conditions and assert pragmas was that they can be be used as well for verification tools, such as in SPARK Ada. CSC313/CSCM13 Sect. 2 (f) 218/ 221

81 Work Around for X Old not allowed in Assert statements X Old is not allowed in the pragmas Assert and Assert_And_Cut. The way around this is to use an auxiliary constant which contains a copy of X Old: Example: procedure Test(X : in out Integer) with Depends => (X => X), Post => (X = X Old + 2); procedure body Test(X : in out Integer) is Xold : constant Integer := X; begin X := X + 1; pragma Assert_And_Cut (X = Xold + 1); X := X + 1; end Test CSC313/CSCM13 Sect. 2 (f) 219/ 221

82 Work Around for X Old not allowed in Assert statements The above example was (example2f-11/) This is legal in SPARK Ada, although Xold is not used in the Ada code, since it occurs in the assert statement. It works because one of the axioms added by SPARK Ada is that Xold = X Old, which can be used in proving the two verification conditions. This is formulated as an axiom, which can be used in all verification conditions. CSC313/CSCM13 Sect. 2 (f) 220/ 221

83 2 (h) Example: A railway interlocking system Sections 2 (g) - (h) will be distributed later CSC313/CSCM13 Sect. 2 (h) 221/ 221