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

Transcription

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

2 CSC313 High Integrity Systems/ CSCM13 Critical Systems Course Notes Chapter 2: SPARK Ada Anton Setzer Dept. of Computer Science, Swansea University csetzer/lectures/ critsys/current/index.html December 23, 2017 CSC313/CSCM13 Chapter 2 2/ 356

3 Remark Sections 2 (a) - (g) will be highly based on John Barnes: High Integrity Software. The SPARK approach. [Ba03]. CSC313/CSCM13 Chapter 2 3/ 356

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 (f) Verification Conditions (Simple Programs) 2 (g) Verification Cond. (Range, Loops, Procedures, Functions) 2 (h) Example: A railway interlocking system CSC313/CSCM13 Chapter 2 4/ 356

5 2 (a) Introduction into Ada 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 (f) Verification Conditions (Simple Programs) 2 (g) Verification Cond. (Range, Loops, Procedures, Functions) 2 (h) Example: A railway interlocking system CSC313/CSCM13 Sect. 2 (a) 5/ 356

6 Ada Lovelace ( )

7 2 (a) Introduction into Ada Ada Lovelace ( ) Ada Lovelace wrote programs for Charles Babbage analytical machine. The first general purpose computer (mechanical; Turing complete). Therefore often regarded as the first computer programmer. CSC313/CSCM13 Sect. 2 (a) 7/ 356

8 2 (a) Introduction into Ada A Basic Introduction into Ada In this subsection we introduce the basic features from Ada used in our introduction into SPARK Ada. This is not a thorough introduction into Ada. It is not necessary to have a complete understanding of Ada for this module. You only need to be able to understand the SPARK Ada code used. There is no need to write full Ada programs. CSC313/CSCM13 Sect. 2 (a) 8/ 356

9 2 (a) Introduction into Ada Motivation for Developing Ada Original problem of Department of Defence in USA (DOD): Too many languages used and created for military applications (>450). Languages largely incompatible and not portable. Often minimal software available. Competition restricted, since often only one vendor of compilers and other tools for one language. Existing languages too primitive. No modularity. Hard to reuse. Problems particularly severe in the area of embedded systems. 56% of the software cost of DOD in 1973 for embedded systems. Most money spent on maintaining software, not developing it. CSC313/CSCM13 Sect. 2 (a) 9/ 356

10 2 (a) Introduction into Ada Ada Decision by DOD: Development of new standard programming language for military applications. First release: Ada 83 (1983 same year C++ was released). Ada 95: Revision of Ada, integration of object-orientation. Ada 2012: Revision of Ada, including many features of SPARK Ada into the core language. Allows therefore what in Eiffel is called Design by Contract (TM). CSC313/CSCM13 Sect. 2 (a) 10/ 356

11 2 (a) Introduction into Ada Imperative Programming Language Ada can be seen as the culmination of the development of imperative programming languages. It was developed at a time when object oriented languages started to be used widely. Syntax of object orientation added to Ada was not as easy to use as in other object-oriented languages. CSC313/CSCM13 Sect. 2 (a) 11/ 356

12 2 (a) Introduction into Ada Reasons for Using Ada in Critical Systems Ada is the often required standard for military applications in the US, and has therefore adopted by the Western military industry. Software for military applications forms a large portion of critical systems. Therefore lots of tools for critical systems support Ada. Ada was developed taking into account its use in real-time critical systems: It is possible to write efficient code and code close to assembler code, while still using high level abstractions. Features were built in which prevent errors (e.g. array bound checks, no writing to arbitrary memory locations). CSC313/CSCM13 Sect. 2 (a) 12/ 356

13 2 (a) Introduction into Ada Basic Imperative Features Ada is an imperative language. There are global variables. Instead of methods we have functions and procedures. procedures are like methods with return type void (i.e. no return type), functions are like methods with a genuine return type (not void). CSC313/CSCM13 Sect. 2 (a) 13/ 356

14 2 (a) Introduction into Ada Not Case Sensitive Ada is not case sensitive. So x and X are the same, HelloWorld, Helloworld and helloworld are the same. SPARKAda will replace in generated code all variables by their lower case versions. CSC313/CSCM13 Sect. 2 (a) 14/ 356

15 2 (a) Introduction into Ada Compilation One can compile ada programs using the gps system, which will be discussed in the next subsection. One can compile Ada as well on the command line using the gcc-ada compiler (available under Linux). The command is gnatmake file This will automatically compile the file and all packages referred to in the file. CSC313/CSCM13 Sect. 2 (a) 15/ 356

16 2 (a) Introduction into Ada Division into Specification and Implementation All units in Ada (programs, functions, packages) have two parts The specification. It declares the interface visible to the outside. E.g. for a function the specification declares its arguments and return type: function Myfunction (A : Integer) return Integer; The implementation. E.g. for a function it would be function Myfunction (A : Integer) return Integer is begin return A ** 3; end Myfunction; ** means here exponentiation. Note that that the implementation repeats the specification. (sect2a/example2a-1/) CSC313/CSCM13 Sect. 2 (a) 16/ 356

17 2 (a) Introduction into Ada Examples References such as sect2a/example2a-1/ in the slides refer to the examples. These can be found at csetzer/lectures/critsys/current/ SPARK Ada/examplesFromLecture/ examplesfromlectureinstructions.html CSC313/CSCM13 Sect. 2 (a) 17/ 356

18 2 (a) Introduction into Ada Division into Specification and Implementation Usually specification and implementation are separated into two files: file.ads contains the specification. file.adb contains the implementation. CSC313/CSCM13 Sect. 2 (a) 18/ 356

19 2 (a) Introduction into Ada Basic Syntax Typing is written as in Haskell X : A stands for X has type A. In Java or C this is written as A X. -- introduces a comment. CSC313/CSCM13 Sect. 2 (a) 19/ 356

20 2 (a) Introduction into Ada Enumeration Types We have enumeration types. E.g. type Genders is (Male,Female); introduces a new type having elements Male and Female. (sect2a/example2a-2) CSC313/CSCM13 Sect. 2 (a) 20/ 356

21 2 (a) Introduction into Ada Ranges in Ada Ada allows to define ranges. subtype Year is Integer range ; Myyear : Year := 3010; results in a compiler error. If an out of range error is detected at compile time, the compiler will report an error. If it isn t detected at compile time we get a run time error: Get(Myyear); If you enter at runtime 2101 we get: raised CONSTRAINT ERROR : example5.adb:15 range check failed (sect2a/example2a-3/) CSC313/CSCM13 Sect. 2 (a) 21/ 356

22 2 (a) Introduction into Ada Ranges in Ada We have as well subranges of enumerations: type Day is (Mon,Tue,Wed,Thu,Fri,Sat,Sun); subtype Weekday is Day range Mon.. Fri; (sect2a/example2a-3/) CSC313/CSCM13 Sect. 2 (a) 22/ 356

23 2 (a) Introduction into Ada Arrays Arrays are declared and used as follows: type myarrayrange is new Integer range ; type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun); type myarraytype is array (myarrayrange) of Day; myarray : myarraytype; myarray(17) := Sun; One can have as well anonymous arrays (index type is not defined separately): (sect2a/example2a-4/) type Vector is array ( ) of Integer; CSC313/CSCM13 Sect. 2 (a) 23/ 356

24 2 (a) Introduction into Ada Conversion between Types To convert from one type to another one uses the notation Mytype(X), which converts a variable X of some type into Mytype. You can convert from a type to a subtype and back. For instance, if X : Integer then Year(X) : Year and if Y : Year then Integer(Y) : Integer Conversion to a subtype is generally unsafe. SPARK Ada will generate verification conditions for that. (sect2a/example2a-4b/) CSC313/CSCM13 Sect. 2 (a) 24/ 356

25 2 (a) Introduction into Ada If Clauses The syntax for if and nested ifs is as follows: if Answer = y then Put Line ( You said yes ); elsif Answer = n then Put Line ( You said no ); else Put Line ( You must type y or n ); end if; (sect2a/example2a-5/) CSC313/CSCM13 Sect. 2 (a) 25/ 356

26 2 (a) Introduction into Ada Loops The basic loop statement is an infinite loop with an exit statement. E.g. Answer : Character; loop Put( Answer yes (y) or no (no) ); Get(Answer); if Answer = y then Put Line ( You said yes ); exit; elsif Answer = n then Put Line ( You said no ); exit; else Put Line ( You must type y or n ); end if; end loop; (sect2a/example2a-6/) CSC313/CSCM13 Sect. 2 (a) 26/ 356

27 2 (a) Introduction into Ada For and While Loops For loops are written as follows: for N in loop Put ( - ); end loop; A while loop is written as follows: while (X > 0.0) loop Y := Y + 1.0; exit when Y > 5.0; X := X - 1.0; end loop; (sect2a/example2a-7/) CSC313/CSCM13 Sect. 2 (a) 27/ 356

28 2 (a) Introduction into Ada Nested Loops can be Labelled One can label loops. This allows to exit not only to the currently innermost loop. Example: Outer Loop: for J in 1.. M loop for K in 1.. M loop <SomeCode> exit Outer loop when A = 0; <SomeCode> end loop; end loop Outer Loop; -- when exit statement is executed, -- we continue here (sect2a/example2a-8/) CSC313/CSCM13 Sect. 2 (a) 28/ 356

29 2 (a) Introduction into Ada In - out - parameters In Ada all parameters have to be labelled as input parameters; symbol: in, Value parameters. The same as a non-var parameter in Pascal. All parameters in Java are in parameters. output parameters; symbol: out, input/output parameters; symbol: in out. Reference parameters. The same as a var parameter in Pascal In Java non-constant instance variables of object parameters behave essentially as in out parameters. Example: procedure ABC(A: in Float; B: out Integer; C: in out Colour) (sect2a/example2a-9/) CSC313/CSCM13 Sect. 2 (a) 29/ 356

30 2 (a) Introduction into Ada In Out In Out Parameters out and in out parameters can only by instantiated by variables. Assume for instance a procedure procedure Myproc(B: out Integer) is begin B:= 0; end Myproc; It doesn t make sense to make a call Myproc(0) (Compiler error) it only makes sense to call Myproc(C) where C is a variable that can be changed. We see as well that the variable we instantiate it with cannot be an in parameter itself, because then it cannot be changed. (sect2a/example2a-10/) CSC313/CSCM13 Sect. 2 (a) 30/ 356

31 2 (a) Introduction into Ada In Out In Out Parameters in parameters can be instantiated by arbitrary terms. Consider: procedure Myproc(B: in Integer,C: out Integer) is begin C:= B; end Myproc; It makes sense to call Myproc(0,D) where D is a variable that can be changed. It makes as well sense to call Myproc(3 + 5,D) or Myproc(f(E,F),D) where f is a function with result type Integer. (sect2a/example2a-11/) CSC313/CSCM13 Sect. 2 (a) 31/ 356

32 2 (a) Introduction into Ada In Out In Out Parameters In Java Parameters are always passed by value, and behave like in parameters. The value of an object which is passed as a parameter is the pointer to that object. A method will use a copy of that pointer to that object. Changing the pointer will have no effect outside of the method. However, we can change the instance variables of an object (possibly by invoking methods of the object) and such changes are visible to the outside. So instance variables in objects are passed by reference. This is different from Ada where, if a record is passed on as an in parameter, no fields can be changed. (sect2a/example2a-12-java/, sect2a/example2a-13/ ) CSC313/CSCM13 Sect. 2 (a) 32/ 356

33 2 (a) Introduction into Ada Example Parameters in Java public static void exchange(int a, int b){ int tmp = a; a = b; b = tmp;} -- The above doesn t exchange a and b -- since integers are passed by value -- so the method works only on a copy of those integers -- Define a wrapper class for integers class myint{ public int theint ; public myint(int theint){ this.theint = theint;} } CSC313/CSCM13 Sect. 2 (a) 33/ 356

34 2 (a) Introduction into Ada Example Parameters in Java public static void exchange(myint a, myint b){ myint tmp = a; a = b; b = tmp;} -- The above doesn t exchange a and b -- since the references to the objects are passed by value -- so the method works only on a copy of those references public static void exchange2(myint a, myint b){ int tmp = a.theint; a.theint = b.theint; b.theint = tmp;} -- The above does exchange a and b CSC313/CSCM13 Sect. 2 (a) 34/ 356

35 2 (a) Introduction into Ada Packages Programs are divided into packages. A package is a collection of types, global variables (with their types), functions and procedures. Packages are specified (in the.ads file) as follows: package Mypackage is -- Specification of the types, functions and procedures -- of this package end Mypackage; CSC313/CSCM13 Sect. 2 (a) 35/ 356

36 2 (a) Introduction into Ada Packages The implementation (in the.adb file) of packages is given as follows: package body Mypackage is -- Implementation of all types functions and procedures -- of this package begin -- Initialisation part of the packages -- Initialises global variables end Mypackage; CSC313/CSCM13 Sect. 2 (a) 36/ 356

37 2 (a) Introduction into Ada Types Defined in Packages Types defined in different packages are different. If you want to use the same type in several packages you need to import it from a common package. For instance, you could have a package only containing definitions of types for that purpose. CSC313/CSCM13 Sect. 2 (a) 37/ 356

38 2 (a) Introduction into Ada Initialisation of Variables Variables in a package can be initialised In their declaration e.g. Sum: Integer := 0; declares a new variable Sum of type Integer which is initialised to 0. CSC313/CSCM13 Sect. 2 (a) 38/ 356

39 2 (a) Introduction into Ada Initialisation of Variables Variables in a package can be initialised Or in the initialisation part of the procedure, e.g. (sect2a/example2a-14/) package body MyPackage is X : Integer range ; -- Declaration of procedures begin X := 0; end MyPackage CSC313/CSCM13 Sect. 2 (a) 39/ 356

40 2 (a) Introduction into Ada Using other Packages If one wants to refer to another package, one has to write before the procedure/package: with nameofpackagetobeused; Then no identifiers are directly visible, they have to be used in the form If one adds in addition nameofpackagetobeused.x use nameofpackagetobeused; then the identifier X can be used directly. CSC313/CSCM13 Sect. 2 (a) 40/ 356

41 2 (a) Introduction into Ada Record Types A record is essentially a class without methods. Syntax in Ada: type Person is record Yearofbirth : Integer; Gender : Genders; end record This example declares a type Person which has two fields Yearofbirth and Gender. If a: Person, then we have that a.yearofbirth : Integer and a.gender : Genders. One can make assignments like a.gender := Male. (sect2a/example2a-14/) CSC313/CSCM13 Sect. 2 (a) 41/ 356

42 2 (a) Introduction into Ada Record Types If a : Person one can give a value to its fields by saying a := (1975,Male); or a := (Yearofbirth => 1975,Gender => Male); There are as well Variant Records, where the type of other fields depends on one field. See additional material. CSC313/CSCM13 Sect. 2 (a) 42/ 356

43 2 (a) Introduction into Ada Polymorphism Ada allows to introduce a new name for a type. Then functions for the new type inherit the functions from the old type. However functions can be overridden. CSC313/CSCM13 Sect. 2 (a) 43/ 356

44 2 (a) Introduction into Ada Example for Use of Polymorphism type Integer is <SomeCode>; -- Some definition. function + (X, Y : Integer) return Integer; -- + can be used infix type Length is new Integer; -- We can use a + b : Length for a,b : Length type Angle is new Integer; function + (X, Y : Angle) return Angle; -- Now we have overridden + for Angle by a new function. (Example taken from S. Barbey, M. Kempe, and A. Strohmeier: Object-Oriented Programming with Ada 9X. CSC313/CSCM13 Sect. 2 (a) 44/ 356

45 2 (a) Introduction into Ada Polymorphism - Deciding Which Function is Used Note in case of polymorphism, which function to be chosen, can be decided at compile time, since it only depends on the (fixed) type of the argument. CSC313/CSCM13 Sect. 2 (a) 45/ 356

46 2 (a) Introduction into Ada Executable File In order to create an exectuable file one needs to have a file filename.adb with one procedure having name filename. One can compile it From the command line by using gnatmake filename.adb From gps by clicking on the current file and running Build Project Build <current file> This will create an executable file with filename which can be executed from a shell. For pure Ada files one can use from libraries Ada.Text Io and Ada.Integer Text IO Put for printing a string or integer on the console Get for getting as input a string or integer on the console. New Line for a printing a line break. CSC313/CSCM13 Sect. 2 (a) 46/ 356

47 2 (a) Introduction into Ada Example Executable Program: example2.adb The following example pprogram will demontrate how to use IO. It will raise if one inputs something which is not a number on the console an error, because Get(Number) requires that the input is a number. Later, when using SPARK Ada we will use a wrapper class, which avoids this problem. CSC313/CSCM13 Sect. 2 (a) 47/ 356

48 2 (a) Introduction into Ada Example Executable Program: example2.adb with Ada.Text Io, Ada.Integer Text IO, Myfunction; use Ada.Text Io, Ada.Integer Text IO; procedure example2 is Number : Integer; begin Get(Number); Put( Test ); Put( f(x)= ); Put(Myfunction(Number)); New Line(1); end Example2 CSC313/CSCM13 Sect. 2 (a) 48/ 356

49 2 (a) Introduction into Ada Example Executable Program: example2.adb procedure Example2; CSC313/CSCM13 Sect. 2 (a) 49/ 356

50 2 (a) Introduction into Ada Example Executable Program: myfunction.adb function Myfunction (A : Integer) return Integer is begin return A 3; end Myfunction; CSC313/CSCM13 Sect. 2 (a) 50/ 356

51 2 (a) Introduction into Ada Example Executable Program: myfunction.ads function Myfunction (A : Integer) return Integer; (sect2a/example2a-1/) CSC313/CSCM13 Sect. 2 (a) 51/ 356

52 2 (a) Introduction into Ada Input of Strings from Console In order to obtain a user input from the console, you need to declare a variable of type String. Ada requires to determine the maximum length of the strings. This is done by writing (taking as length 20): S : String(1.. 20); You can initialize a string to have only blanks by using the following: S : String(1.. 20):= (others => ); A string is an array of characters and the instruction (others => ) means that all positions in this array are set to the character for blank. Once you have a variable User Input of type string one can obtain a user input by using Get Line(User Input, Last); The variable Last needs to be of type Integer or Natural (Natural are the non-negative natural numbers) In the variable Last the length of the input by the user is stored. Any characters occurring after position Last in User Input will be unchanged by the instruction Get Line. CSC313/CSCM13 Sect. 2 (a) 51a/ 356

53 2 (a) Introduction into Ada Input of Strings from Console After an input of an integer from console, there are still some characters in the input buffer, which would be used by a Get Line command. So before having a proper Get Line command, you need to clear the input bufffer by using a Get Line command and ignoring its output: Get Line(User Input, Last); An exampe can be found in the lecture examples collection at misc/conversion24hrclock12hrampmclock /vers2onlyadawithiointegersnolibrary/ CSC313/CSCM13 Sect. 2 (a) 51b/ 356

54 2 (a) Introduction into Ada Functions vs Procedures Functions are like Java methods with return type not being void. Usually they shouldn t have side effects In fact in previous versions of SPARK Ada it was not allowed to have functions with side effects. Procedures are like Java methods with return type void. So they only have side effects and no return value. CSC313/CSCM13 Sect. 2 (a) 52/ 356

55 2 (a) Introduction into Ada Example example13.adb with Ada.Text Io, Ada.Integer Text IO; use Ada.Text Io, Ada.Integer Text Io; package body Example13 is procedure Myproc( B : in Integer; C : out Integer) is begin Put( B= ); Put(B); New Line; C := B; Put( C= ); Put(C); New Line; end MyProc; CSC313/CSCM13 Sect. 2 (a) 53/ 356

56 2 (a) Introduction into Ada Example example13.adb (Cont.) function F(B,C : in Integer) return Integer is begin return B C; end F; CSC313/CSCM13 Sect. 2 (a) 54/ 356

57 2 (a) Introduction into Ada Example example13.ads (Cont.) package Example13 is procedure Myproc(B : in Integer; C : out Integer); function F(B,C : in Integer) return Integer; end Example13; (sect2a/example2a-11/) CSC313/CSCM13 Sect. 2 (a) 55/ 356

58 2 (b) Architecture of SPARK Ada 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 (f) Verification Conditions (Simple Programs) 2 (g) Verification Cond. (Range, Loops, Procedures, Functions) 2 (h) Example: A railway interlocking system CSC313/CSCM13 Sect. 2 (b) 56/ 356

59 2 (b) Architecture of SPARK Ada Overview and History of SPARK Ada SPARK Ada is a Subset of Ada. Original definition by B. Carré and T. Jennings, Univ. of Southampton, Several revisions carried out by Praxis Critical Systems Ltd. Adapted to Ada95 and recently to Ada 2012 (SPARK 2014). Commercial tools available from Adacore and Altran. GPL version available via CSC313/CSCM13 Sect. 2 (b) 57/ 356

60 2 (b) Architecture of SPARK Ada Examples of Industrial Uses of SPARK Ada (from Barnes: Programming in Ada 2012, p. 848) Mission Computer of the Lockheed Martin C130J, contains 100 KLOC (KLOC= 1000 lines of code), most of which is written in SPARK Ada. Nearly all safty critical systems in the EuroFighter Typhoon aircraft are programmed in SPARK Ada. The security critical aspects of the smartcard OS Multos were developed in SPARK Ada. ifacts, which provides tools for predictive tools in air traffic control consist of 200 KLOC of RavenSPARK Source code (RavenSPARK combines SPARK with concurrency) 120,000 Verification conditions were generated to prove exception-freedom. CSC313/CSCM13 Sect. 2 (b) 58/ 356

61 2 (b) Architecture of SPARK Ada Instructions of How to Install and Use SPARK Ada You will need to install GNAT Ada GPL 2014 and then SPARK GPL The following page contains material about how to use SPARK Ada including the examples from the lectures: csetzer/lectures/ critsys/current/spark Ada/index.html Instructions on how to setup SPARK Ada in the linux lab can be found at csetzer/lectures/critsys/current/ SPARK Ada/ settingupmachineforsparkadaforusagefromfilemanagerusingscript.html Examples from the lecture can be found here: csetzer/lectures/critsys/current/ SPARK Ada/examplesFromLecture/guideToExamples.html CSC313/CSCM13 Sect. 2 (b) 59/ 356

62 2 (b) Architecture of SPARK Ada SPARK Ada Annotations to Ada. Some required for data and information flow analysis. Others allow to generate and prove verification conditions. It is as well possible to integrate unchecked or even unimplemented Ada code. SPARK Ada code compiles with the GNAT/gcc compiler infrastructure. For the avr-ada compiler for the avr 8-bit microcontroller: We were only able to compile SPARK Ada files by preprocessing it, deleting annotations related to SPARK Ada. Possible reasonn might be that the compiler hasn t been upgraded to Ada The same problem might arise with other Ada compilers, but preprocessing by removing SPARK Ada annotations should always work. Apart from special SPARK Ada annotations SPARK Ada is just a subset of Ada. CSC313/CSCM13 Sect. 2 (b) 60/ 356

63 2 (b) Architecture of SPARK Ada 3 Levels of Analysis of SPARK Ada Level 1 Analysis Correct Ada syntax used. SPARK-subset of Ada chosen, as described in the next subsection. Level 2 Analysis Data flow analysis. Information flow analysis. Level 3 Analysis Generation of verification conditions. Proof of verification conditions using automated and interactive theorem provers. When running Spark Ada always Level 1 and Level 2 Analysis is carried out. There might however be a switch (pragma) to restrict analysis to Level 1 analysis only. CSC313/CSCM13 Sect. 2 (b) 61/ 356

64 2 (b) Architecture of SPARK Ada Two components of Level 2 Analysis Data flow analysis. Checks input/output behaviour of parameters and variables. Checks initialisation of variables. Checks that changed and imported variables are used later (possibly as output variables). Information flow analysis. Verifies interdependencies between variables. CSC313/CSCM13 Sect. 2 (b) 62/ 356

65 2 (b) Architecture of SPARK Ada Level 3 Analysis Annotations are added to the program expressing the correctness of the program. (Called Pre- and Post-conditions, more about this later.) SPARK Ada extracts verification conditions They express that the program fulfils these correctness conditions. These verification are then fed into an automated theorem prover. The automated theorem prover is not always able to prove the correctness of the verification conditions, even if they are true. In that case one needs to feed verification conditions into an interactive theorem prover, e.g. the theorem prover Coq. CSC313/CSCM13 Sect. 2 (b) 63/ 356

66 2 (b) Architecture of SPARK Ada Three Levels of Analysis Idea is that the 3 different levels of analysis are applied depending on the criticality of the program. Some non-critical parts of the program might not be checked at all. CSC313/CSCM13 Sect. 2 (b) 64/ 356

67 2 (b) Architecture of SPARK Ada Annotations in Pre-2014 SPARK Ada In SPARK Ada additional annotations are added to the Ada code. Specific to the 3 levels of analysis. In the versions of SPARK Ada up to 2012 Referred to in the following as Pre-2014 SPARK Ada these annotations were written as Ada comments: Ignored by Ada compilers. Used by the SPARK Ada tools. Syntax: start with -- # Example: -- # global in out MyGlobalVariable; CSC313/CSCM13 Sect. 2 (b) 65/ 356

68 2 (b) Architecture of SPARK Ada SPARK Ada Commands in SPARK 2014 In Ada 2012 pragmas and aspects have been added to Ada which allow to add annotations to the language. Therefore SPARK Ada 2014 uses now these commands as part of its language. Since one of the two main books on SPARK Ada hasn t been updated yet, in this module we will use SPARK 2014 syntax but outline as well how to write the same in SPARK Pre-2014 syntax using comments. CSC313/CSCM13 Sect. 2 (b) 66/ 356

69 2 (b) Architecture of SPARK Ada GUI of SPARK Ada Started using command gps. After setup script run in the linux lab, it is started by clicking on a file with extension.gpr, usually called main.gpr In Bottom right you can see the command line commands executed, which you can use for executing commands from a command line directly (faster). I use gnatprove -P <path>/main.gpr however sometimes use options such as - -proof=per path. CSC313/CSCM13 Sect. 2 (b) 67/ 356

70 2 (b) Architecture of SPARK Ada GUI of SPARK Ada CSC313/CSCM13 Sect. 2 (b) 68/ 356

71 2 (b) Architecture of SPARK Ada GUI of SPARK Ada CSC313/CSCM13 Sect. 2 (b) 69/ 356

72 2 (b) Architecture of SPARK Ada GUI of SPARK Ada CSC313/CSCM13 Sect. 2 (b) 70/ 356

73 2 (b) Architecture of SPARK Ada Usage of GPS Usage instructions for GPS can be found at csetzer/lectures/ critsys/current/spark Ada/basicUsageOfSparkAda.html CSC313/CSCM13 Sect. 2 (b) 71/ 356

74 2 (c) Language Restrictions in SPARK Ada 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 (f) Verification Conditions (Simple Programs) 2 (g) Verification Cond. (Range, Loops, Procedures, Functions) 2 (h) Example: A railway interlocking system CSC313/CSCM13 Sect. 2 (c) 72/ 356

75 2 (c) Language Restrictions in SPARK Ada Activation of SPARK Mode To turn SPARK mode on: Add in front of a compilation unit: pragma SPARK_Mode; or pragma SPARK_Mode(On); or add after a package or procedure: with SPARK_Mode; or with SPARK_Mode => On; To turn it off: Add in front of a compilation unit: pragma SPARK_Mode(Off); or add after a package or procedure: with SPARK_Mode => Off; If spark mode is off it needs to be turned off in all units used by it. CSC313/CSCM13 Sect. 2 (c) 73/ 356

76 2 (c) Language Restrictions in SPARK Ada Switching of SPARK Mode (of/off) Even with SPARK mode off, the first two levels of analysis are carried out. However no verification conditions are generated. You can turn in file.ads file SPARK Mode on and in file.adb SPARK Mode off. This means that another module with spark mode on can refer to file.ads. However it is not checked that file.adb file fulfils the spark part of file.adb. However, Ada requires file.adb file to fulfil the Ada part of the specification in file.ads. This allows to refer from spark ada code to non-spark ada course Used for instance in the library spark-text io. (sect2c/example2c-15/) CSC313/CSCM13 Sect. 2 (c) 74/ 356

77 2 (c) Language Restrictions in SPARK Ada Pragmas Pragma are annotations to a unit in Ada. They occur at the beginning of a file. They were originally compiler directives, but are used in SPARK Ada for giving correctness conditions. Syntax: pragma Mypragma; or pragma Mypragma(parameter); CSC313/CSCM13 Sect. 2 (c) 75/ 356

78 2 (c) Language Restrictions in SPARK Ada Aspects Aspects are annotations to a package, procedure or function. They are used in SPARK Ada to give correctness annotations to a unit. Syntax: procedure A (X : in Integer) with keyword; or with keyword => value; or with keyword => (keyword2 => value,keyword3 => value); CSC313/CSCM13 Sect. 2 (c) 76/ 356

79 2 (c) Language Restrictions in SPARK Ada Factors for Programming Languages Addressed by SPARK Ada Logical Soundness. Problem: statement like Y:=F(X) + G(X): Order of evaluation not specified in Ada. Problem if F(X) and G(X) have side effects. E.g. F(X) has effect Z:=0, G(X) has effect Z:= 1. (sect2c/example2c-1/) CSC313/CSCM13 Sect. 2 (c) 77/ 356

80 2 (c) Language Restrictions in SPARK Ada SPARK Ada Concepts Solution in many languages: define order of evaluation. Not possible, if SPARK Ada should compile on standard compilers. Solution in older versions of SPARK Ada: Functions are not allowed to have side-effects. The above is still what is stated in the reference manual of SPARK 2014 (vers 19.0w). However, SPARK Ada actually behaves as follows: (sect2c/example2c-18/) Functions can have side effects. But if the order of evaluation matters, functions with side effects are not allowed. CSC313/CSCM13 Sect. 2 (c) 78/ 356

81 2 (c) Language Restrictions in SPARK Ada SPARK Ada Concepts Simplicity of language definition. Omission of too complex principles. No variant records. They are a form of dependent types, but without compile time checking. See Additional Material for Sect. 2 (a). No threads (concurrency). No generic types. CSC313/CSCM13 Sect. 2 (c) 79/ 356

82 2 (c) Language Restrictions in SPARK Ada SPARK Ada Concepts Expressive power. Hiding of variables allowed. Allows to specify strong assertions about variables E.g. that a variable is only read but not written an input variable or only written but not read an output variable. CSC313/CSCM13 Sect. 2 (c) 80/ 356

83 2 (c) Language Restrictions in SPARK Ada SPARK Ada Concepts Security. Features already supported by Ada: Array bound are checked. Programs does not stray outside the computational model (one cannot jump or write to an arbitrary memory location). Feature enforced by SPARK Ada: In order to be verifiable at compile-time: Constraints (array bounds, ranges) have to be static (determined at compile time). (sect2c/example2c-5/) (This makes it as well easier to create verification conditions, since one doesn t have to switch between integers, anonymous subtypes of the integers and declared subtypes of the integers). CSC313/CSCM13 Sect. 2 (c) 81/ 356

84 2 (c) Language Restrictions in SPARK Ada SPARK Ada Concepts Verifiability Support of automated verifiability: Extra annotations control of data flow, control of information flow, proof annotations (more below). CSC313/CSCM13 Sect. 2 (c) 82/ 356

85 2 (c) Language Restrictions in SPARK Ada SPARK Ada Concepts Support of Verifiability (Cont.) Some restrictions in previous versions of SPARK Ada have been relaxed: Restrictions of procedures having no return statement and functions having exactly one return statement have been removed. (sect2c/example2c-4/) Restrictions regarding jumping out of if statements and loops have been removed. (sect2c/example2c-2/, sect2c/example2c-3/, sect2c/example2c-4/ CSC313/CSCM13 Sect. 2 (c) 83/ 356

86 2 (c) Language Restrictions in SPARK Ada SPARK Ada Concepts No structures which are too complex to grasp. Almost no subtyping. Details about subtyping can be found in Additional Material. CSC313/CSCM13 Sect. 2 (c) 84/ 356

87 2 (c) Language Restrictions in SPARK Ada SPARK Ada Concepts Language should be as explicit as possible. Rules regarding polymorphism from pre-2014 SPARK Ada now relaxed Overloading of functions and operators is now allowed. (sect2c/example2c-7/) default parameters are allowed from SPARK 2014 onwards. (sect2c/example2c-9/) default record components are not allowed. (sect2c/example2c-10/) However Array sliding is not allowed: Assignment, comparison, operations on arrays only allowed on arrays with same array index sets. (sect2c/example2c-8/) Ada behaves in an unexpected way in this case. No concatenation of arrays allowed. However, for strings such kind of operations are allowed. CSC313/CSCM13 Sect. 2 (c) 85/ 356

88 2 (c) Language Restrictions in SPARK Ada SPARK Ada Concepts Bounded space and time requirements. arrays without bounds or with dynamically allocated bounds. Can be declared, but only subtypes of it can be used. No pointers (called access types in Ada). However Recursion (disallowed in pre-2014 SPARK Ada) is now allowed, so no bounded space guaranteed. (sect2c/example2c-13/, example2c-12/, example2c-11/) CSC313/CSCM13 Sect. 2 (c) 86/ 356

89 2 (c) Language Restrictions in SPARK Ada Avoiding Aliasing Problem If a procedure has one input or input-output parameter and another output or input-output parameter, then it is not allowed to instantiate both parameters by the same variable. This is disallowed because it could cause the aliasing problem: If it were allowed and the output parameter is changed while the input parameter is still used then the input parameter would be changed in the middle of the code. Under these circumstances correctness is no longer guaranteed. CSC313/CSCM13 Sect. 2 (c) 87/ 356

90 2 (c) Language Restrictions in SPARK Ada Example: Wrong Exchange program procedure Exchange (X : in out Boolean; Y : in out Boolean) is begin X := X xor Y; Y := X xor Y; X := X xor Y; end Exchange; procedure Main (X : in out Boolean) is begin Exchange (X, X); -- input/output parameter X and input/output parameter Y -- are instantiated by the same variable X end Main; (sect2c/example2c-14/) CSC313/CSCM13 Sect. 2 (c) 88/ 356

91 2 (c) Language Restrictions in SPARK Ada Error Message by SPARK Ada SPARK Ada reports at the call Exchange(X,X) for both parameters: main.adb:7:16: writable actual for X overlaps with actual for Y which is exported. CSC313/CSCM13 Sect. 2 (c) 89/ 356

92 2 (c) Language Restrictions in SPARK Ada Sophisticated Built-in Checks SPARK Ada has lots of very sophisticated checks for programming errors built in. Example: code if A = 5 then if A = 6 then is rejected, because the second statement is unreachable. the following code is accepted: if A = 5 then if A + 0 = 6 then The number of features for detecting programming errors is growing with each version. CSC313/CSCM13 Sect. 2 (c) 90/ 356

93 2 (d) Data Flow Analysis 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 (f) Verification Conditions (Simple Programs) 2 (g) Verification Cond. (Range, Loops, Procedures, Functions) 2 (h) Example: A railway interlocking system CSC313/CSCM13 Sect. 2 (d) 91/ 356

94 2 (d) Data Flow Analysis Data Flow Analysis Parameters Remember the use of in/out/in-out parameters in Ada. in - parameters are input parameters. Can be instantiated by terms. Parameter can be used but not be modified. out- parameters. Can only be instantiated by variables. Input cannot be used, parameter can be modified. in-out- parameters. Can only be instantiated by variables. Input can be used, parameter can be modified. CSC313/CSCM13 Sect. 2 (d) 92/ 356

95 2 (d) Data Flow Analysis Data Flow Analysis Parameters Examiner verifies that Input parameters are not modified, but used at least once, not necessarily in every branch of the program but at least once; output parameters are not read before being initialised, initialised. Has to take place in all branches of the program. input/output parameters are read, (at least once) and changed (at least once). CSC313/CSCM13 Sect. 2 (d) 93/ 356

96 2 (d) Data Flow Analysis Initialisation of Variables Initialisation of variables needs to happen in all branches of a conditional. For instance after the following statement if Y > Z then X:= 0.0; end if; X is considered as not initialised unless it has been initialised before. (sect2d/example2d-3/) CSC313/CSCM13 Sect. 2 (d) 94/ 356

97 2 (d) Data Flow Analysis Example 1 (Data Flow Analysis) Consider the following wrong program, which should exchange X and Y: procedure Wrong Exchange(X,Y: in out Float) is T:Float; begin T:= X; X:= Y; Y:= X; end Wrong Exchange; Mistake:??? (sect2d/example2d-5c/) CSC313/CSCM13 Sect. 2 (d) 95/ 356

98 2 (d) Data Flow Analysis Example 1 (Data Flow Analysis) procedure Wrong Exchange(X,Y: in out Float) is T:Float; begin T:= X; X:= Y; Y:= X; end Wrong Exchange; SPARK Ada reports 4 error messages: At Wrong Exchange (X, Y : in out Float) : warning: unused initial value of X. At T : Float; : warning: variable T is assigned but never read At T := X : warning: useless assignment to T, value never referenced warning: unused assignment (sect2d/example2d-5c/) CSC313/CSCM13 Sect. 2 (d) 96/ 356

99 2 (d) Data Flow Analysis Example 1 (Data Flow Analysis) procedure Wrong Exchange(X,Y: in out Float) is T:Float; begin T:= X; X:= Y; Y:= X; end Wrong Exchange; Note that SPARK Ada doesn t notice that Y doesn t change (that de-facto Y an in parameter). It would be complicated, to deal with such kind of phenomena in general. (sect2d/example2d-5c/) CSC313/CSCM13 Sect. 2 (d) 97/ 356

100 2 (d) Data Flow Analysis Dependency Graph (Example 1) The following illustrates the dependencies of the variables X, Y, T on the original values X Old, Y Old (X Old is Ada notation for the value of X when starting the procedure) T X Old Y Old T := X X:= Y Y := X End Exchange X Y CSC313/CSCM13 Sect. 2 (d) 98/ 356

101 2 (d) Data Flow Analysis Example 1 Corrected The correct program is as follows: procedure Exchange(X,Y: in out Float) is T:Float; begin T:= X; X:= Y; Y:= T; end Exchange; (sect2d/example2d-5b/) CSC313/CSCM13 Sect. 2 (d) 99/ 356

102 2 (d) Data Flow Analysis Dependency Graph (Example 1 Corrected) T X Old Y Old T := X X:= Y Y := T End Exchange X Y CSC313/CSCM13 Sect. 2 (d) 100/ 356

103 2 (d) Data Flow Analysis Example 2 (Data Flow Analysis) Here is another wrong program, which should exchange X and Y: procedure Wrong Exchange(X,Y: in out Float) is begin X:= Y; Y:= X; end Wrong Exchange; SPARK Ada reports the following error message: At procedure Wrong Exchange (X, Y : in out Float) warning: unused initial value of X sect2d/example2d-6c/ CSC313/CSCM13 Sect. 2 (d) 101/ 356

104 2 (d) Data Flow Analysis Dependency Graph (Example 2) X Old Y Old X:= Y Y := X End Exchange X Y CSC313/CSCM13 Sect. 2 (d) 102/ 356

105 2 (d) Data Flow Analysis Example 2 Corrected If we want to correct the signature of the program while keeping the body we obtain the following: procedure Strange Exchange(X: out Float; Y: in out Float) is begin X:= Y; Y:= X; end Strange Exchange; Note that program does not exchange X and Y, therefore the name. The program fulfils the specification given by the signature however the specification (signature) is not the correct one for an exchange program (sect2d/example2d-6d/) Having Y as an in parameter only will result in the following error: example.adb:7:16: assignment to in mode parameter not allowed. CSC313/CSCM13 Sect. 2 (d) 103/ 356

106 2 (d) Data Flow Analysis Example 3 Assume a procedure with body Y := X; Z := Y; Then The value of X is used, but never changed. So X is an input variable (keyword in ). The value of Y is changed, but the original value is never used It seems to be used in the 2nd line, but what is used is actually the value of X. So Y is an output variable, but not an input variable (keyword out ). (sect2d/example2d-7/) CSC313/CSCM13 Sect. 2 (d) 104/ 356

107 2 (d) Data Flow Analysis Example 3 Y := X; Z := Y; The value of Z is changed, but not used. So Z is an output variable (keyword out ). CSC313/CSCM13 Sect. 2 (d) 105/ 356

108 2 (d) Data Flow Analysis Dependency Graph (Example 3) The following illustrates the dependencies of the variables on the original values X Old, Y Old, Z Old: X Old Y Old Z Old Y := X Z := Y (sect2d/example2d-7/) X Y Z CSC313/CSCM13 Sect. 2 (d) 106/ 356

109 2 (d) Data Flow Analysis Data Flow Analysis Global Variables Global variables must be given status as input or output or input/output variables by the aspect global. Syntax examples: procedure test (X : in out Integer) with Global => (Input => A, Output => B, In_Out => C); Or (after the same procedure declaration line) with Global => (Output => B); Or (after the same procedure declaration line) with Global => (In_Out => C); Data flow analysis carries out the same analysis as for parameters. (sect2d/example2d-1/) CSC313/CSCM13 Sect. 2 (d) 107/ 356

110 2 (d) Data Flow Analysis Global variables pre-2014 syntax procedure test (X : in out Integer) -- # global in A; out B; in out C; Or (after the same procedure declaration line) -- # global out B; Or (after the same procedure declaration line) -- # global in out C; CSC313/CSCM13 Sect. 2 (d) 108/ 356

111 2 (d) Data Flow Analysis Data Flow Analysis Functions Functions can have only input parameters (no keyword required). Functions have only read access to global parameters. Therefore the syntax for global parameters is simply with Global => A,B,C; Neither parameters nor global variables can be changed. Therefore functions don t have side effects. (sect2d/example2d-2/) CSC313/CSCM13 Sect. 2 (d) 109/ 356

112 2 (d) Data Flow Analysis Global Annotation pre-2014 SPARK Ada -- # global A; or -- # global A,B,C; CSC313/CSCM13 Sect. 2 (d) 110/ 356

113 2 (d) Data Flow Analysis State Variables from Other Packages If you are using a different package, you can change global variables in that other package. However you need to annotate them using the Global aspect. You need as well to have a use clause to access that other variable, even if only using variables in aspects. If state variables are not declared in the.ads file but the.adb file, then the situation is a bit more complicated. You need to have abstract state variables in the specification which are refined in the implementation file deal with those abstract and refined variables in the package making use of it. (sect2d/example2d-9/) CSC313/CSCM13 Sect. 2 (d) 111/ 356

114 2 (d) Data Flow Analysis Example (Content of.ads Files) File example.ads: package Example with SPARK_MODE is Glob : Integer; procedure Init with Global => (Output => Glob); end Example; File main.ads: with Example; use Example; -- Needed, although used only in annotations procedure Main with SPARK_MODE, Global => (Output => Glob); (sect2d/example2d-10/) CSC313/CSCM13 Sect. 2 (d) 112/ 356

115 2 (d) Data Flow Analysis Abstract State Variables in Packages To declare in a specification file about the existence of an abstract state write with Abstract State => AbstractStateVariable If the package initialises that variabel you write in the specification file with Initializes => AbstractStateVariable If a procedure changes the abstract state, you write with Global => (In_out => AbstractStateVariable) or with Global => (Input => AbstractStateVariable) or with Global => (Output => AbstractStateVariale) CSC313/CSCM13 Sect. 2 (d) 113/ 356

116 2 (d) Data Flow Analysis Concrete State Variables in Packages In the implementation you now declare that AbstractStateVariable is represented by (possibly several) concrete state variables e.g. A1, A2, A3: with Refined State => (AbstractStateVariable => (A1,A2,A3)) CSC313/CSCM13 Sect. 2 (d) 114/ 356

117 2 (d) Data Flow Analysis Pre-2014 Syntax In pre-2014 SPARK Ada abstract and private state variable were declared by package test -- # own X,Y; The syntax for initialisation was package test with initializes => X; -- # own X,Y; -- #initializes X; CSC313/CSCM13 Sect. 2 (d) 115/ 356

118 2 (d) Data Flow Analysis IO Using Input- and Output-Streams For dealing with Input/Output ( IO) we use a package SPARK.Text_IO, which deals with file I/O and standard I/O (via console). In the coursework we use wrapper classes AS_IO_Wrapper, which hides problems such as error messages during input of integers. These packages have internal state variables Standard_Output representing all outputs made up to now by the program. Standard_Input representing all inputs made up to now, which were not yet used by the program, CSC313/CSCM13 Sect. 2 (d) 116/ 356

119 2 (d) Data Flow Analysis Input and Output Streams When we make some output (eg. print some characters on the console), we add some elements to the Standard_Output. Therefore the new Standard_Output depends on the previous Standard_Output and any reasons for making that output. When we get some input (here from console), we take some first elements off Standard_Input. Therefore the new Standard_Input depends on the previous Standard_Input and any reasons for requesting that input. Any variables changed because of some input depend as well on Standard_Input CSC313/CSCM13 Sect. 2 (d) 117/ 356

120 2 (d) Data Flow Analysis Procedure Print State As an example we consider a procedure Print State, which will be defined in Sect. 2 (h), which prints the state to console, using the parameters Segment State and Signal State. The procedure, which prints the state to console, has the following specification: procedure Print State (Segment State : in Segment State Types; Signal State : in Signal State Types) with Global => (In_Out => Standard Output); CSC313/CSCM13 Sect. 2 (d) 118/ 356

121 2 (d) Data Flow Analysis Procedure Get Action The procedure Get Action which inputs from console input the mode of the next action (ouptput parameter The Mode) and the route (parameter Route) to which it is applied, will have the following specification: procedure Get Action(Route : out Route Type; The Mode : out Mode ) with Global => (In_Out => (Standard Input,Standard Output)); Note that Standard Input is as well In_Out, since the system writes a prompt asking the user for some input. (simple_railway.ads in sect2h/vers11final) CSC313/CSCM13 Sect. 2 (d) 119/ 356

122 2 (e) Information Flow Analysis 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 (f) Verification Conditions (Simple Programs) 2 (g) Verification Cond. (Range, Loops, Procedures, Functions) 2 (h) Example: A railway interlocking system CSC313/CSCM13 Sect. 2 (e) 120/ 356

123 2 (e) Information Flow Analysis Additional annotations on how variables depend on each other. Syntax examples: with Depends => (Y => X); meaning Y depends on X. Several dependencies: with Depends => (Y => X, X => Y); If X gets a value independent of other variables: with Depends => (Y => null); or depending on two variables: with Depends => (X => (Y,Z)); Often the new value of a variable depends on its own values, so we may have e.g. with Depends => (X => X); or with Depends => (X => (X,Y)); CSC313/CSCM13 Sect. 2 (e) 121/ 356 Use of Aspects for Annotating Information Flow

124 2 (e) Information Flow Analysis Syntax in pre 2014 SPARK Ada -- #derives X from Y; -- #derives X from Y & -- # Y from X; -- #derives X from ; -- #derives X from X; -- #derives X from X, Y; CSC313/CSCM13 Sect. 2 (e) 122/ 356

125 2 (e) Information Flow Analysis Information Flow Analysis Information flow verifies that these dependencies are fulfilled CSC313/CSCM13 Sect. 2 (e) 123/ 356

126 2 (e) Information Flow Analysis Example 1 Consider the following wrong program, which should exchange X and Y and count the number of exchanges in Z: procedure Exchange And Count(X,Y,Z: in out Integer) with Depends => (X => Y, Y => X, Z => Z); procedure Exchange And Count(X,Y,Z: in out Integer) is T: Integer; begin T:= X; X:= Y; Y:= T; Z:= Z + T; end ExchangeAndCount; The error is the line Z:= Z + T; should be replaced by Z:= Z + 1; (sect2e/example2e-2/) CSC313/CSCM13 Sect. 2 (e) 124/ 356

127 2 (e) Information Flow Analysis Example 1 Data flow analysis succeeds without problems. Information flow analysis gives an error, since Z depends on Z and X (via T): warning: missing dependency Z => X After correcting the specification to procedure Exchange And Count(X,Y,Z: in out Integer) with Depends => (X => Y, Y => X, Z => (X,Z)); information analysis succeeds. (sect2e/example2e-3/) CSC313/CSCM13 Sect. 2 (e) 125/ 356

128 2 (e) Information Flow Analysis Example 1 However the Depends clause in the corrected version doesn t express the intended meaning of the program, namely that Z should simply be incremented, and therefore Z should only depend on Z. Therefore the program is incorrect w.r.t. the intended meaning of it. To fix it we need to replace Z:= Z + T by Z := Z + 1 see next slide CSC313/CSCM13 Sect. 2 (e) 126/ 356

129 2 (e) Information Flow Analysis Dependency Graph (Example 1) T X Old Y Old Z Old T := X X:= Y Y := T Z := Z + T End X Y Z CSC313/CSCM13 Sect. 2 (e) 127/ 356

130 2 (e) Information Flow Analysis Example 1 Corrected procedure Exchange And Count(X,Y,Z: in out Integer) with Depends => (X => Y, Y => X, Z => Z); procedure Exchange And Count(X,Y,Z: in out Integer) is T: Integer; begin T:= X; X:= Y; Y:= T; Z:= Z + 1; end ExchangeAndCount; Now the Depends express the extended meaning. The program passes information flow analysis and is correct. (sect2e/example2e-2corrected/) CSC313/CSCM13 Sect. 2 (e) 128/ 356

131 2 (e) Information Flow Analysis Dependency Graph (Example 1 Corrected) T X Old Y Old Z Old T := X X:= Y Y := T Z := Z + 1 End X Y Z CSC313/CSCM13 Sect. 2 (e) 129/ 356

132 2 (e) Information Flow Analysis Example 2 What happens if we vary this program as follows? procedure Exchange And Count(X,Y,Z: in out Integer) with Depends => (X => Y, Y => X, Z => Z); procedure Exchange And Count(X,Y,Z: in out Integer) is T: Integer; begin T:= X; X:= Y; Y:= T; Z:= T; end ExchangeAndCount; (sect2e/example2e-4/) CSC313/CSCM13 Sect. 2 (e) 130/ 356

133 2 (e) Information Flow Analysis Example 2 warning: unused initial value of Z warning: missing dependency null => Z warning: missing dependency Z => X warning: incorrect dependency Z => Z CSC313/CSCM13 Sect. 2 (e) 131/ 356

134 2 (e) Information Flow Analysis Dependency Graph (Example 2) T X Old Y Old Z Old T := X X:= Y Y := T Z := T End X Y Z CSC313/CSCM13 Sect. 2 (e) 132/ 356

135 2 (e) Information Flow Analysis Example 2 Corrected procedure Exchange And Count(X,Y: in out Integer; Z : out Integer) with Depends => (X => Y, Y => X, Z => X); procedure Exchange And Count(X,Y: in out Integer; Z : out Integer) is T: Integer; begin T:= X; X:= Y; Y:= T; Z:= T; end ExchangeAndCount; (sect2e/example2e-5/) Remark: The corrected program passes the information flow analysis. However, the depends clauses don t express what we intended. The program is incorrect w.r.t. the intention we had, to have Z as a counter. CSC313/CSCM13 Sect. 2 (e) 133/ 356

136 2 (e) Information Flow Analysis Example 3 Assume as in data flow analysis example 3 a procedure with body Y := X Z := Y X does not derive from anywhere, since it is not changed (no output variable). Y derives from X. Z derives from X, (not from Y!). Note that only output and input/output variables can derive from somewhere, and they can only derive from input and input/output variables. CSC313/CSCM13 Sect. 2 (e) 134/ 356

137 2 (e) Information Flow Analysis Dependency Graph (Example 3) X Old Y Old Z Old Y:= X Z := Y End X Y Z CSC313/CSCM13 Sect. 2 (e) 135/ 356

138 2 (e) Information Flow Analysis Example 4 procedure Decrease Increase( X,Y : in out Integer; Z : in Integer) with Depends => (X => (X,Z), Y => (X,Y,Z); procedure Decrease Increase( X,Y : in out Integer; Z : in Integer) is begin loop exit when Z < 0 or X < 0; X := X - 1; Y:= Y + 1; end loop; end Decrease Increase; (sect2e/example2e-6/) CSC313/CSCM13 Sect. 2 (e) 136/ 356

139 2 (e) Information Flow Analysis Example 4 Y depends on X,Z although the only assignment to Y is Y := Y + 1; This is since the resulting value of Y depends on how often the loop is executed. The condition for terminating the loop depends on Z and X, therefore Y depends on X,Z (and Y). The program is correct (no information flow errors found). CSC313/CSCM13 Sect. 2 (e) 137/ 356

140 2 (e) Information Flow Analysis Global Variables, including Input and Output Streams Dependencies for and on Global Variables are denoted in the same way as for local variables. As an example we consider the treatment of Standard Input and Standard Output as discuessed in the previous section. CSC313/CSCM13 Sect. 2 (e) 138/ 356

141 2 (e) Information Flow Analysis Procedure Print State In the procedure Print State, Standard Output depends on on the two parameters Segment State and Signal State. It depends as well on itself, since the new output is appended to the old output stream. The dependency clauses are as follows: procedure Print State (Segment State : in Segment State Types; Signal State : in Signal State Types) with Global => (In_Out => Standard Output), Input => (Segment State, Signal State)), Depends => (Standard Output => (Standard Output, Segment State, Signal State)); CSC313/CSCM13 Sect. 2 (e) 139/ 356

142 2 (e) Information Flow Analysis Procedure Get Action In the procedure Get Action Route and The Mode are determined from, and therefore depend on Standard Input. Standard Input only depends on itself, since it is modified. Standard Output depends on itself but as well on Standard Input, since we ask the user questions, and possibly repeat asking for some input if the input was not in the correct format. The resulting code can be found on the following slide: CSC313/CSCM13 Sect. 2 (e) 140/ 356

143 2 (e) Information Flow Analysis Procedure Get Action procedure Get Action(Route : out Route Type; The Mode : out Mode ) with Global => (In_Out => (Standard Input,Standard Output)), Depends => (Standard Output => (Standard Output, Standard Input), Standard Input => Standard Input, Route => Standard Input, The Mode => Standard Input); (simple_railway.ads in sect2h/vers11final) CSC313/CSCM13 Sect. 2 (e) 141/ 356

144 2 (f) Verification Conditions (Simple Programs) 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 (f) Verification Conditions (Simple Programs) 2 (g) Verification Cond. (Range, Loops, Procedures, Functions) 2 (h) Example: A railway interlocking system CSC313/CSCM13 Sect. 2 (f) 142/ 356

145 2 (f) Verification Conditions (Simple Programs) 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/ 356

146 2 (f) Verification Conditions (Simple Programs) 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/ 356

147 2 (f) Verification Conditions (Simple Programs) 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/ 356

148 2 (f) Verification Conditions (Simple Programs) Tony Hoare with his Wife Jill (After having been knighted by the Queen.) CSC313/CSCM13 Sect. 2 (f) 146/ 356

149 2 (f) Verification Conditions (Simple Programs) 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/ 356

150 2 (f) Verification Conditions (Simple Programs) 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/ 356

151 2 (f) Verification Conditions (Simple Programs) 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/ 356

152 2 (f) Verification Conditions (Simple Programs) 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/ 356

153 2 (f) Verification Conditions (Simple Programs) 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/ 356

154 2 (f) Verification Conditions (Simple Programs) 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/ 356

155 2 (f) Verification Conditions (Simple Programs) 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/ 356

156 2 (f) Verification Conditions (Simple Programs) 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/ 356

157 2 (f) Verification Conditions (Simple Programs) 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 generated verification condition derived from the pre- and post-conditions. CSC313/CSCM13 Sect. 2 (f) 155/ 356

158 2 (f) Verification Conditions (Simple Programs) 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/ 356

159 2 (f) Verification Conditions (Simple Programs) 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/ 356

160 2 (f) Verification Conditions (Simple Programs) 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/ 356

161 2 (f) Verification Conditions (Simple Programs) Architecture of Why3 Platform (Source: CSC313/CSCM13 Sect. 2 (f) 159/ 356

162 2 (f) Verification Conditions (Simple Programs) 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/ 356

163 2 (f) Verification Conditions (Simple Programs) Result of Applying Why3 to.mlw Files CSC313/CSCM13 Sect. 2 (f) 161/ 356

164 2 (f) Verification Conditions (Simple Programs) 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/ 356

165 2 (f) Verification Conditions (Simple Programs) Error Messages of Why3 CSC313/CSCM13 Sect. 2 (f) 163/ 356