With Praxis and AdaCore now teaming up to offer an integration of SPARK technology inside GPS (see http://www.adacore.com/home/products/sparkpro/), many GPS users will be interested in trying out the proof capabilities of SPARK on their own Ada programs. Of course it’s a little more involved than that. SPARK is not only a set of tools for verifying high-assurance systems, but also incorporates a language that must be learned.

The SPARK language is made up of two parts, one of which is a subset of Ada (whose features will obviously already be familiar to Ada programmers!), meant to facilitate code understanding and proofs, and the other part being a specification language, meant to express properties of programs. Quite conveniently, the SPARK specifications (a.k.a. SPARK annnotations, to distinguish them from Ada specifications) are expressed within stylized Ada comments of the following form:

         --# <some annotation here>

so SPARK annotations don’t interfere with normal Ada compilation.

This Gem and the next one demonstrate various of the properties you can prove with SPARK, and how these relate to the SPARK annotations written by the user. As a simple example, we will take a procedure which searches linearly for a value in an array, and returns the index, if any, at which the value is found.

Here is the specification file search.ads:

package Search is

  type IntArray is array (Integer range <>) of Integer;

  procedure Linear_Search
    (Table : in IntArray;
     Value : in Integer;
     Found : out Boolean;
     Index : out Integer);

end Search;

And the body file search.adb:

package body Search is

  procedure Linear_Search
    (Table : in IntArray;
     Value : in Integer;
     Found : out Boolean;
     Index : out Integer) 
  is
     I : Integer := 0;
  begin
     Found := False;

     while I <= Table’Last loop
        if Table(I) = Value then
           Found := True;
           Index := I;
           exit;
        end if;
        I := I + 1;
     end loop;
  end Linear_Search;

end Search;

Let’s first get set up for using SPARK:

1. Copy the files search.ads and search.adb into a directory named search.
2. Open GPS with a default project in the same directory.
3. Expand file search.adb.
4. Select SPARK/SPARKMake from the menu. This generates a file search.idx.
5. Copy the following code to a file called search.cfg:

  package Standard is
     type Integer is range -2**31 .. 2**31-1;
  end Standard;

6. From the Menu, select Project/Edit Project Properties.
7. Go to the page Switches/Examiner.
8. Select the following options:

  Index File            : search.idx
  Configuration File    : search.cfg
  Analysis              : Data Flow only
  Generate VCs          : yes (check it)

That’s it!

Now open search.adb and select SPARK/Examine File. The SPARK Examiner runs and outputs the following messages:

       Flow Error 602 - The undefined initial value of Index may be
                         used in the derivation of Index
       Warning 402 - Default assertion planted to cut the loop
       Note - Information flow analysis not carried out

The Flow Error indicates that, although Index is an out parameter, it is not initialized on all paths through Linear_Search. One could argue that our intent here is to access Index only when Found is set to True. SPARK considers initialization errors too serious to allow such subtleties, and requires that all paths through the procedure must initialize all out parameters. Let’s comply and initialize Index:

  begin
     Found := False;
     Index := 0;

After we rerun the Examiner, we are left with a Note that is simply a reminder of our choice of options, and a Warning that we will explain in the next Gem.

Now, we can continue with proving that our procedure is free from run-time errors, such as integer overflow and out-of-bounds array accesses. Select SPARK/Simplify All. The SPARK Simplifier runs. To see the result of this tool’s execution, select SPARK/POGS. This opens a file search.sum, which summarizes all the proofs in the following table:

VCs for procedure_linear_search :
--————————————————————————–
     |       |                     |  --—Proved In—–  |       |       |
#    | From  | To                  | vcg | siv | plg | prv | False | TO DO |
--————————————————————————–
1    | start | rtc check @ 13      |     | YES |     |     |       |       | 
2    | start |    assert @ 15      |     | YES |     |     |       |       | 
3    | 15    |    assert @ 15      |     | YES |     |     |       |       | 
4    | 15    | rtc check @ 16      |     |     |     |     |       |  YES  | 
5    | 15    | rtc check @ 18      |     | YES |     |     |       |       | 
6    | 15    | rtc check @ 21      |     |     |     |     |       |  YES  | 
7    | 15    |    assert @ finish  | YES |     |     |     |       |       | 
8    | 15    |    assert @ finish  | YES |     |     |     |       |       | 
--————————————————————————–

Each line corresponds to a Verification Condition (VC), which must be proved in order to guarantee that the program is free from run-time errors. Each column corresponds to the result of the proof attempt. If YES appears in one of the 4 “Proved In” columns, the proof was successful. If YES appears in the “False” column, there is something definitely wrong. If “YES” appears in the “TO DO” column, we don’t know: either the program is wrong, or it is too complex to prove.

Since column “TO DO” is not empty here, not all proofs were successful. In the next Gem, we will give you more details about failed proofs. The reason for the failures here is that program Linear_Search is incorrect, meaning that run-time errors can be raised. To see this, just complete the program with the following code in main.adb, and build the executable.

with Search;
use Search;

procedure Main is
   Table : IntArray(1..10) := (others => 0);
   Found : Boolean;
   Index : Integer;
begin
   Linear_Search(Table, 0, Found, Index);
end Main;

Now run the executable, and it raises an exception:

   raised CONSTRAINT_ERROR : search.adb:16 index check failed

This is because we are passing an array to Linear_Search that starts at index 1 in its parameter Table, whereas Linear_Search loop assumes that the array starts at index 0. SPARK correctly assumes that we can pass in such an array to Linear_Search, and thus it fails to prove that Linear_Search is free from run-time errors.

Let’s correct the code of Linear_Search:

  procedure Linear_Search
    (Table : in IntArray;
     Value : in Integer;
     Found : out Boolean;
     Index : out Integer) is
  begin
     Found := False;
     Index := 0;

     for I in Integer range Table’Range loop
        if Table(I) = Value then
           Found := True;
           Index := I;
            exit;
        end if;
     end loop;
  end Linear_Search;

Let’s do it again: Examine, Simplify All, POGS …
This time, columns “False” and “TO DO” are empty, meaning that all proofs were successful.

VCs for procedure_linear_search :
--————————————————————————–
     |       |                     |  --—Proved In—–  |       |       |
#    | From  | To                  | vcg | siv | plg | prv | False | TO DO |
--————————————————————————–
1    | start | rtc check @ 11      |     | YES |     |     |       |       | 
2    | start | rtc check @ 13      |     | YES |     |     |       |       | 
3    | start |    assert @ 13      |     | YES |     |     |       |       | 
4    | 13    |    assert @ 13      |     | YES |     |     |       |       | 
5    | 13    |    assert @ 13      |     | YES |     |     |       |       | 
6    | 13    | rtc check @ 14      |     | YES |     |     |       |       | 
7    | 13    | rtc check @ 16      |     | YES |     |     |       |       | 
8    | 13    |    assert @ finish  | YES |     |     |     |       |       | 
9    | 13    |    assert @ finish  | YES |     |     |     |       |       | 
--————————————————————————–

Thus, we have proved that procedure Linear_Search is free from run-time errors.

In the next Gem, after the summer break, we will prove that procedure Linear_Search actually respects a given contract.

When you open GPS initially, it shows a number of views: the Messages window (which can never be closed), the Project View, showing the list of files in your project, the Outline View, which shows the list of subprograms in the current edit, the Scenario View listing the scenario variables in your project, and a Welcome window to help you get started.

When several windows share the same screen area (which is the case for the project view and the outline view in the default desktop), they are organized into notebooks, and it’s possible to show any view by clicking on its associated tab. By default, GPS will now show the tabs if there is only one window in a given area, to save screen real estate. This behavior can be changed through the “Notebook Tabs Policy” preference. You can also change the location of the tabs (which by default appear below the window) through the “Notebook Tabs Position” preference. This latter preference configures the default location, though, and you can change it on a per-notebook basis by right-clicking in any of the tabs and changing the tabs position.

Windows can also be made to float. They are then put under the control of the operating system (or the window manager), and you can move them to another screen, another virtual desktop, iconify them, and so on. The window will have its own entry in your systems panel (the bar that is generally displayed at the bottom of the screen and shows all open windows). GPS has a mode where all windows it creates are made floating by default (this is the “All Floating” preference). When this mode is not activated, you can move a floating window back into GPS using one of two methods: the /Window/Floating menu, or by clicking on the [x] in the window’s title bar when the “Destroy Floating” preference is unset; at that point, instead of closing the window, GPS will simply put it back in its own window. If you really want to close it, you have to click a second time on [x].

Only one of the views has the focus at any given time, and it receives all keyboard input. Its title bar is then highlighted in a different color (which you configure in the preferences). To save some space on the screen, you could choose to hide the title bars. Indeed, it is obvious most of the time what each window is after you have used them a few times. The only case where you might be missing info is for editors (since the title bar includes the full name of the file). However, this name also appears in GPS’s own title bar. When the title bar is hidden, the notebook’s tab will be color highlighted to show the currently active window.

When a window is not currently visible on the screen (most often this will be when the Messages window is below the Locations window for instance), its tab is highlighted in a special color to bring attention to it and encourage you to check what has changed in that window.

It is rather obvious (or so we hope) that the views can be resized as you see fit simply by dragging the separators between those windows (that is, click on the separator, hold the mouse button, and move the mouse up/down or left/right, depending on the orientation of the separator). The resizing can take one of two forms: either a simple line overlaid on top of the windows to show where the separator will end up when you release the mouse, or by redrawing the windows each time you move the mouse. This behavior can also be configured in the preferences.

However, did you know that you can actually create any number of new areas on the desktop (which we call the MDI, for Multiple Document Interface)? This can be done in a number of ways. The easiest to discover is to use the menu /Window/Split Side-by-Side or /Window/Split Up-Down. For instance, assuming you have the default desktop loaded in GPS, select the project view. Then select the menu /Window/Split Up-Down. This will put the outline view in its own area below the project view, allowing you to see both at the same time.

However, the most flexible way to reorganize windows is by using drag and drop. Start by clicking on the title bar or the tab of any window. Then, without releasing the mouse button, move your mouse to where you would like to put the window you clicked on. Note how a pop-up window appears on top of the GPS window to describe what will happen when you release the mouse. There are six places where you can drop a window: if you release the mouse in the middle of an existing window, the two windows will be stacked into a notebook; if you release on any of the sides of an existing window (there is a margin a few pixels wide on each side), the existing window will be split and the window you are moving will be displayed next to it; finally, you can also release the mouse outside of the GPS window altogether to make the window floating.

As an additional bonus, if you press the shift key when you are dropping an editor window, a new view will be created (showing the same contents) instead of moving the initial editor. This allows you to view several locations in a given file, which is often useful when you want to view data structures when writing code, or when comparing several sections of code.

My own preferred organization (on a wide screen) is as follows: I have two editors side by side (for instance spec and body). Then on the left side I display the Windows view (/Tools/Views/Windows menu), which provides a fast way to select and bring to the front any window no matter where it currently is on the screen. This is a also a convenient place from which to start the drag-and-drop operations (clicking on a file and dropping it where I want to put the editor). Below this Windows view I have the Bookmarks view, which allows me to save places within any of the editors (through the /Edit/Create Bookmark menu), and come back to them later. Below the two editors, I display the Messages window and the Locations window side by side, so that I can see compilation errors easily, while keeping an eye on whether GPS has reported an error in its messages window. Finally, on the right-hand side of the screen I display the Outline view, since this is such a great way to move fast within a file, and the Tasks view that shows what’s being executed in the background (and provides a way to monitor the progress of compilations when using the -d switch to gnatmake). As you see, there are quite a number of views. To save space, I usually hide title bars (which as explained above are not necessary once you know what the windows are for), as well as the status bar at the bottom of the GPS window (since the task view displays the same information already).

Once you have found a layout that you like, however, you probably want to reuse it every time you open GPS. This is called saving the desktop. This process is very configurable, to adapt to the various needs that people might have:

- The default is for GPS to save the project-specific desktop. This means that the layout you have just created will be saved automatically on exit, and reapplied when loading the same project later on. If you load another project, the default layout will be used. One reason to do that is to save the currently opened files in the desktop (this is controlled by another preference, “Save Editor is Desktop”, where you decide whether you want to save editors or not, and if you do, whether only project-specific editors will be saved or any file that happens to be opened at that time.

- If you want to reuse the same layout for all projects on which you work, you should make sure the preference “General/Save Project-Specific Desktop on Exit” is disabled. This means that a single version of the desktop will be saved, and will apply to all projects (in this case it might be a good idea to remove the file $HOME/desktop.xml prior to launching GPS the first time, so that any trace of project-specific desktop is wiped out). In such a case, one of the drawbacks is that you might not want to save the editors since they would not necessarily match the next project you load.

The method I have been using is the following: after removing the desktop.xml file as described above, I launch GPS and set up the various views as I like, but do not open any editor. I then save the current desktop as the default through the menu /File/Save Move/Default Desktop. I then ensure that the preference to save project-specific desktops is on, as well as the preference to save the editors in the desktop. This ensures that every time I open a project that I’ve never opened before, I get the default desktop (with no editor), but when I open a project that I have already opened before, then I get the same editors (and in the same location) as the last time I exited GPS.

AdaCore has recently introduced GNATbench 2.3.0. This release introduces many new features including preference control for “Quick Fix” for Ada, Eclipse “feature” deployment, and builder enhancements. This webinar will describe and demo some of the new features introduced in 2.3.0. As always, we will allow a question and answer session at the end enabling you to talk directly with the designers of GNATbench. This webinar will appeal to Ada developers that are using, or are interested in using, GNAT Pro and the Eclipse development environment in their projects.

To register, please visit:
http://www.adacore.com/home/products/gnatpro/webinars