Ada 2005 allows the use of anonymous access types in a more general manner, adding considerable power to the object-oriented programming features of the language. The accessibility rules have been correspondingly augmented to ensure safety by preventing the possibility of dangling references. The new rules have been designed with programming flexibility in mind, as well as to allow the compiler to enforce checks statically.

The accessibility levels in the new contexts for anonymous access types are generally determined by the scope where they are declared. This makes it possible to perform compile-time accessibility checks.

Another rule that allows for static accessibility checks relates to derived types: a type derivation does not create new accessibility level for the derived type, but just takes that of the parent type:

     procedure Example_1 is
        type Node is record
           N : access Integer;
        end record;
        List : Node

        procedure P is
           type Other_Node is new Node;
        begin
           declare
              L : aliased Integer := 1;
              Data : Other_Node := Other_Node’(N => L’Access);
              --  L’Access is illegal!
           begin
              List := Node (Data);
           end;
        end P;

     begin
        P;
     end Example_1;

In the above example, we don’t need to worry about expensive run-time checks on assignment or return of an object of type Other_Node; we know it has the same accessibility level as type Node, making the Access attribute illegal. If this were not prevented, after returning from P, List.N would be a dangling reference.

Ada 2005 also allows functions to return objects of anonymous access types. In this case, the accessibility level of the object is statically determined by the scope of the function declaration. Consider the following example:

     procedure Example_2 is
        type Rec is record
           V : access Integer;
           …
        end record;

        Global : aliased Integer := 1;

        function F1 (X : Boolean) return Rec is
           Local : aliased Integer := 2;

           --  Nested function returns anonymous access values
           --  with different nesting depths

           function F2 (Y : Boolean) return Access Integer is
           begin
              if Y then
                 return Global’Access;
              else
                 return Local’Access;
              end if;
           end F2;

        begin
           return (V => F2 (X), …); -- Illegal
        end F1;

        Data : Rec;
     begin
        Data := F1 (True);
     end Example_2;

In this example, applying the aforementioned rule, the compiler statically determines that this accessibility level is the scope where F2 is declared, which is deeper than the accessibility level of Rec. So even though the call F1 (True) would provide a valid value for V, the code is illegal. The accessibility restriction is conservative, to keep the rules simple, and so that the compiler is not required to perform data flow analysis to determine legality (not to mention that in general the legality would be undecidable).

The new rules also take into account discriminants of an anonymous access type (which are technically referred to as access discriminants). In Ada 2005, access discriminants are now permitted for nonlimited types. Consequently, it’s necessary to disallow defaults for access discriminants of nonlimited types. Thus, the following declaration is illegal:

     Default : aliased Integer := …
     type Rec (D : access Integer := Default’Access) is record
        …

This restriction is needed to prevent the discriminant from creating a dangling reference due to an assignment of the record object; it ensures that the object and the discriminant are bound together for their lifetime.

Special care must be taken when types with access discriminants are used with allocators and return statements. The accessibility rules require the compiler to perform static checks when new objects containing access discriminatns are created or returned. Consider the following example:

    procedure Example_3 is
       type Node (D : access Integer) is record
          V : Integer;
       end record;
       type Ptr is access all Node;

       Global_Value : aliased Integer := 1;
       Other_Data   : Integer := 2;
   
       procedure P is
          Local : aliased Integer := 3;
          R1 : Ptr;
          R2 : Ptr;
       begin
          R1 := new Node’(D => Global_Value’Access, V => Other_Data);
          --  This is legal

          R2 := new Node’(D => Local_Value’Access, V => Other_Data);
          --  This is illegal
       end P;
    begin
       null;
    end Example_3;

The allocator for R1 is legal, since the accessibility level of Global’Access is the same as the accessibility level of D. However the allocator for R2 is illegal, because the accessibility level of Local’Access is deeper than the accessibility level of D, and assigning R2 to an object outside P could lead to a dangling reference.

In summary, these rules forbid the creation of an object in a storage pool that contains an access discriminant pointing to some area of memory, be it a part of the stack or some other storage pool, with a shorter lifetime, thus preventing the discriminant from pointing to a nonexistent object.

OOP took programming by storm about twenty years ago. Its supreme merit is said to be its flexibility. But flexibility is somewhat like freedom discussed in the Introduction – the wrong kind of flexibility can be an opportunity that permits dangerous errors to intrude.

The key idea of OOP is that the objects dominate the programming and subprograms (methods) that manipulate objects are properties of objects. The other, older, view sometimes called Function-Oriented (or structured) programming, is that programming is primarily about functional decomposition and that it is the subprograms that dominate program organization, and that objects are merely passive things being manipulated by them.

Both views have their place and fanatical devotion to just a strict object view is often inappropriate.

Ada strikes an excellent balance and enables either approach to be taken according to the needs of the application. Indeed Ada has incorporated the idea of objects right from its inception in 1980 through the concept of packages which encapsulate types and the operations upon them, and tasks that encapsulate independent activities.

Read Chapter 5 in full

Note: All chapters of this booklet will, in time, be available on the Ada 2005 home page.

Ada has the notion of “streams” that are much like those of other languages: sequences of elements comprising values of arbitrary, possibly different, types. Placing a value into a stream is easy using the language-defined “stream attributes”. The programmer simply calls the type-specific attribute routine and specifies the stream and the value. For example, to place an Integer value V into a stream S, one could write the following:

Integer’Write (S, V);

Strictly speaking, S is not a stream but, rather, an access value designating a stream. The Integer’Write routine will convert the value of V into an array of “stream elements” – essentially an array of storage elements – and then put them into the stream designated by S. Actually, placing the bytes into the stream is accomplished by dynamically dispatching to a procedure specific to the stream representation.

Although this discussion is couched in terms of placing values into streams, you should understand that reading values from streams is very similar to writing them and that the same efficiency issue and solution apply.

For composite types, such as array or record types, each component value is individually written to the stream using the approach described above. Consider an array type “A” specifying Integer as the component type. The default version of A’Write will call Integer’Write for each component. Thus, each Integer value is converted to the array of storage elements and written to the stream. This component-driven behavior is necessary because programmers can define their own versions of the stream attributes, and naturally will expect them to be called even when the types in question are used as component types within enclosing array or record types.

But suppose the array type is structurally just a sequence of contiguous bytes, and the component type does not have a user-defined stream attribute defined. In that case, calling the component-specific attribute for each array component is unnecessary and inefficient.

For example, suppose you are working with Military-Standard 1553B for communicating application values between remote devices. Ultimately, Mil-Std-1553B sends and receives 32-word buffers, where each word is an unsigned 16-bit value. Suppose as well that you want to write and read these buffers to and from streams. We can override the stream attributes so that a whole buffer value is written directly to the stream instead of writing it one buffer component at a time.

The buffer type could be declared as follows:

   type Buffer is array (1..32) of Interfaces.Unsigned_16;

We can then override the stream attributes for type Buffer.

First we declare the routines:

   procedure Read_Buffer
      (Stream : not null access Ada.Streams.Root_Stream_Type’Class;
       Item   : out Buffer);

   procedure Write_Buffer
      (Stream : not null access Ada.Streams.Root_Stream_Type’Class;
       Item   : in Buffer);

All such stream attributes have the same formal parameter types, i.e., an access parameter designating the class-wide root stream type defined by the language, and the type to be written to, or read from, that stream.

We then “tie” the routines to the stream attributes for type Buffer, thereby overriding the default versions:

   for Buffer’Read  use Read_Buffer;
   for Buffer’Write use Write_Buffer;

The language-defined root stream type and array element type are declared in package Ada.Streams:

package Ada.Streams is

   type Root_Stream_Type is abstract tagged limited private;

   type Stream_Element is mod 2 ** Standard’Storage_Unit;

   type Stream_Element_Offset is range
     -(2 ** (Standard’Address_Size - 1)) ..
     +(2 ** (Standard’Address_Size - 1)) - 1;

   …

   type Stream_Element_Array is
      array (Stream_Element_Offset range <>) of aliased Stream_Element;

   procedure Read
     (Stream : in out Root_Stream_Type;
      Item   : out Stream_Element_Array;
      Last   : out Stream_Element_Offset)
   is abstract;

   procedure Write
     (Stream : in out Root_Stream_Type;
      Item   : Stream_Element_Array)
   is abstract;

   …
end Ada.Streams;

The user-defined Read_Buffer and Write_Buffer routines will call these stream-oriented Read and Write procedures (via dynamic dispatching) once for the entire Buffer array value, instead of calling them once per array component. Both routines are very similar, so we will omit the body of of Read_Buffer for the sake of brevity and show just the implementation of Write_Buffer:

   procedure Write_Buffer
      (Stream : not null access Ada.Streams.Root_Stream_Type’Class;
       Item   : in Buffer)
   is
      Item_Size : constant Stream_Element_Offset :=
                     Buffer’Object_Size / Stream_Element’Size;

      type SEA_Pointer is
         access all Stream_Element_Array (1 .. Item_Size);

      function As_SEA_Pointer is
         new Ada.Unchecked_Conversion (System.Address, SEA_Pointer);
   begin
      Ada.Streams.Write (Stream.all, As_SEA_Pointer (Item’Address).all);
   end Write_Buffer;

In the above, we cannot simply convert the value of Item, of array type Buffer, to a value of type Stream_Element_Array, so we work with pointers instead. We define an access type designating a Stream_Element_Array that is the exact size, in terms of Stream_Elements, of the incoming Buffer value. Note the use of the Buffer’Object_Size attribute in that computation. That attribute gives us the size of objects of the type Buffer, a wise approach since in general the size of a type may not equal the size of objects of that type. We can then use unchecked conversion to convert the address of the formal parameter Item to this access type. Dereferencing that converted access value (via .all) gives us a value of type Stream_Element_Array that we can pass to the call to Ada.Streams.Write.

Thus we avoid processing each component of type Buffer, instead writing the entire Buffer value at once. That’s a much more efficient approach. As we said earlier, reading values from streams is analogous to writing values to them and only differs in obvious, minor ways. That is true for using the default stream attributes as well as in the implementation of Read_Buffer.

When speaking of buildings, a good architecture is one whose design gives the required strength in a natural and unobtrusive manner and thereby provides a safe environment for the people within. An elegant example is the Pantheon in Rome whose spherical shape has enormous strength and provides an uncluttered space. Many ancient cathedrals are not so successful, and need buttresses tacked on the outside to prop up the walls. In 1624, Sir Henry Wooton summed the matter up in his book, The Elements of Architecture, by saying “Well building hath three conditions – commoditie, firmenes & delight”. In modern terms, it should work, be strong and be beautiful as well.

A good architecture in a program should similarly provide unobtrusive safety for the detailed workings of the inner parts within a clean framework. It should permit interaction where appropriate and prevent unrelated activities from accidentally interfering with each other. And a good language should enable the writing of programs with a good architecture.

There is perhaps an analogy with the architecture of office spaces. An arrangement where everyone has an individual office can inhibit communication and the flow of ideas. On the other hand, an open plan office often causes problems because noise and other distractions interfere with productivity.

The structure of an Ada program is based primarily around the concept of a package, which groups related entities together and provides a natural framework for hiding implementation details from its clients.

Read Chapter 4 in full

Note: All chapters of this booklet will, in time, be available on the Ada 2005 home page.

To recap Part 1, protected types add an efficient building block to the tasking facilities of Ada. Mutual exclusion is automatically provided and condition synchronization is directly expressed via entry barriers, all without the expense of task switching. As such, protected types are a natural implementation approach for a circular bounded buffer used in a concurrent programming context. The complete declaration of the generic package and encapsulated protected type are shown below, including now the private part. (We have omitted the comments in the code since we cover them in the description.)

with System;

generic
   type Element is private;
package GNAT.Bounded_Buffers is
   pragma Pure;

   type Content is array (Positive range <>) of Element;

   Default_Ceiling : constant System.Priority := System.Default_Priority;

   protected type Bounded_Buffer
      (Capacity : Positive;
       Ceiling : System.Priority)
   is
      pragma Priority (Ceiling);

      entry Insert (Item : Element);
      entry Remove (Item : out Element);

      function Empty  return Boolean;
      function Full   return Boolean;
      function Extent return Natural;

   private
      Values   : Content (1 .. Capacity);
      Next_In  : Positive := 1;
      Next_Out : Positive := 1;
      Count    : Natural  := 0;
   end Bounded_Buffer;

end GNAT.Bounded_Buffers;

The private part of type Bounded_Buffer contains the encapsulated data that can only be accessed via the exported routines. The abstraction is that of a bounded buffer, and it uses the component Values, of the array type Content, to hold the buffer values. The discriminant Capacity determines the actual upper bound on the array component, which is how different Bounded_Buffer objects can have different capacities. As a circular buffer, two array indexes are required, one to indicate where the next inserted value will be placed, and one to indicate where the next removed value will come from. These indexes are components Next_In and Next_Out, respectively. Finally, each Bounded_Buffer object contains a count of the number of elements currently held by the buffer. This counter is used to provide the condition synchronization required to prevent inserting items into a full buffer or removing items from an empty buffer. There are other ways to determine whether the buffer is full or empty but this counter-based approach is clear and is also useful for the function Extent.

The generic package body contains only the body of the protected type, and likewise, the protected body only contains the bodies of the exported entries and functions, so we omit the lines for the declarations of the package and protected type bodies and focus instead on the routines themselves.

The first routine in the protected body is that of the entry Insert. Note the barrier “Count /= Capacity” providing the condition synchronization for the state “not full”. Callers to Insert are kept waiting until the barrier is True. As is the case for any protected entry or protected procedure, callers automatically execute with mutually exclusive access to the encapsulated data.

      entry Insert (Item : Element) when Count /= Capacity is
      begin
         Values (Next_In) := Item;
         Next_In := (Next_In mod Capacity) + 1;
         Count := Count + 1;
      end Insert;

The body of Insert is straightforward. Note that we have the index Next_In wrap around the allowed index values based on the capacity. We could not use a modular type for either index because that would require a static value for the modulus, but we only have the Capacity discriminant to work with.

The body for entry Remove is similar to that of Insert, with expected differences.

      entry Remove (Item : out Element) when Count > 0 is
      begin
         Item := Values (Next_Out);
         Next_Out := (Next_Out mod Capacity) + 1;
         Count := Count - 1;
      end Remove;

An important point for each entry is the handling of the Count component. When either entry completes, the other entry is examined to see if the barrier has become true. If so, a waiting caller (if any) is allowed to execute and the process repeats itself. Thus, a very simple expression of the condition is provided by the barriers and these are automatically evaluated whenever they could possibly change.

The function bodies are even simpler than the entry bodies. It is worth repeating a point made in Part 1 of this gem, namely that the state of a protected object can change immediately after a call to such a function returns.

      function Empty return Boolean is
      begin
         return Count = 0;
      end Empty;

      function Full return Boolean is
      begin
         return Count = Capacity;
      end Full;

      function Extent return Natural is
      begin
         return Count;
      end Extent;

Clients can query the capacity of any given Bounded_Buffer object by simply reading the Capacity discriminant. The discriminant cannot be changed, so the effect is much the same as a function.

As Niklaus Wirth once wrote (citing Hoare), once you get the data structures right, the code just writes itself. Admittedly, he didn’t use those exact words, but I think you will agree that the data structures used in type Bounded_Buffer, when combined with the semantics of protected types, make the bodies of the routines trivial to write.

Primitive man made a huge leap forward with the discovery of fire. Not only did this allow him to keep warm and cook and thereby expand into more challenging environments but it also enabled the creation of metal tools and thus the bootstrap to an industrial society. But fire is dangerous when misused and can cause tremendous havoc; observe that society has special standing organizations just to deal with fires that are out of control.

Software similarly made a big leap forward in its capabilities when the notion of pointers or references was introduced. But playing with pointers is like playing with fire. Pointers can bring enormous benefits but if misused can bring immediate disaster such as a blue screen, or allow a rampaging program to destroy data, or create the loophole through which a virus can invade.

High integrity software typically limits drastically the use of pointers. The access types of Ada have the semantics of pointers but in addition carry numerous safeguards on their use, which makes them safe in the most demanding safety-critical programs.

Read Chapter 3 in full

Note: All chapters of this booklet will, in time, be available on the Ada 2005 home page.

This issue features:

The bounded buffer is a classic concurrent programming component exhibiting asynchronous task interactions. The concept is that of a buffer of a fixed size that is accessed by multiple tasks, some inserting items and some removing them, concurrently and asynchronously. Hence the buffer implementation must be protected against race conditions in which the tasks access the implementation in an interleaved manner and thereby corrupt the representation. In addition to this “mutually exclusive access”, the buffer also requires “condition synchronization”, in which callers are kept waiting until the requested buffer has the necessary state. For example, a task cannot remove an item from a buffer when the buffer is empty. Likewise, an item cannot be put into a buffer when the buffer is full.

Prior to Ada 95, programmers wanting to write portable code had to use the rendezvous to achieve mutual exclusion, with guards to implement the condition synchronization, because no other synchronization mechanism was provided by the language. Although the extended rendezvous has a number of advantages and was a step forward in language design, it has significant overhead when compared to lower-level mechanisms such as semaphores, and is a synchronous mechanism as well. (Ada 80 had a built-in “Semaphore” task type, intended to be implemented efficiently and used as the name suggests, but mixing the higher-level rendezvous with the much lower-level semaphore abstraction was considered poor language design.) In addition, the rendezvous is only available between tasks, meaning that the buffer would have to be implemented as a task too, like the accessing threads. As a result, inserting and removing items would involve expensive task switching, which is the primary source of the comparative inefficiency.

The protected type construct added in Ada 95 addresses this issue directly. Protected types provide efficient mutually exclusive access to encapsulated data, with direct expression of condition synchronization when required. Protected types do not define threads of control, so their use does not involve task switching, and although they do more than simple semaphores, their overhead is comparable.

generic
   type Element is private;
package GNAT.Bounded_Buffers is

Given this generic formal profile, users can instantiate the generic as required. For example, given an appropriate generic actual parameter type named “Job”, we could instantiate it as follows:

   package Jobs is new GNAT.Bounded_Buffers (Element => Job);

The package declaration contains a pragma Pure so that the generic can be used during library unit elaboration without a potential access-before-elaboration problem. That effect is achieved because Pure units are preelaborated, in addition to other semantics.

Next the package declares the array type used internally in the representation of the bounded buffer type:

   type Content is array (Positive range <>) of Element;

The array type must be declared outside the protected type, rather than inside in the private part as a hidden implementation artifact. This is an unfortunate holdover from the fact that protected types were originally named “protected records”, with record type semantics: record types cannot declare such things as other types! This limitation was known during the Ada 2005 revision but other revision aspects were more important, so this undesirable restriction remains.

The next declaration in the package is a constant value of type System.Priority:

   Default_Ceiling : constant System.Priority := System.Default_Priority;

In a real-time application using the Real-Time Systems Annex, protected types are given a “ceiling” priority. The constant declared here is a default for that purpose so that applications not using that Annex can ignore this aspect.

Finally the package declares the protected type itself, with two discriminants:

   protected type Bounded_Buffer
      (Capacity : Positive;
       Ceiling  : System.Priority)
   is
      pragma Priority (Ceiling);

The first discriminant is the capacity of the instance object, that is, the maximum number of values it can contain. This value will be used in the declaration of a hidden array object of type Content. With this approach, different objects of the one buffer type can have different capacities. The second discriminant represents the ceiling priority value, used in the pragma Priority. This is where the Default_Ceiling constant would be used in non-real-time applications. Note that we cannot use the Default_Ceiling constant as a default discriminant value because the language does not allow some discriminants to have defaults unless all have defaults.

Continuing with our “Jobs” example instantiation, declaration of a bounded buffer specifies these discriminant values:

   Buffer : Jobs.Bounded_Buffer (Capacity => 20,
                                 Ceiling => Jobs.Default_Ceiling);

In this example we have arbitrarily set the capacity of Buffer to 20. Note that the Bounded_Buffer type is provided directly as a protected type, rather than as a limited private type completed with a protected type. With this approach, clients have full flexibility to do all that protected types allow, such as timed and conditional calls.

Next the protected type declares the visible operations. The two primary operations are Insert and Remove, defined as entries for the sake of the barriers that specify the required condition synchronization. (Only protected entries can have barriers, unlike protected procedures and functions.) The barriers express the “not full” and “not empty” conditions and keep their callers waiting until those conditions hold.

      entry Insert (Item : Element);
      entry Remove (Item : out Element);

Then three functions are declared. The names “Empty” and “Full” describe the purpose of the first two functions. The third, “Extent”, returns the number of elements currently held in the buffer. It is worth noting that the state of a buffer to which these functions may be applied can change immediately after the call returns.

      function Empty return Boolean;
      function Full return Boolean;
      function Extent return Natural;

In part two of this Gem we will explore the private part of the protected type, the package body, and the body of the protected type.

Related Source Code

Ada Gems example files are distributed by AdaCore and may be used or modified for any purpose without restrictions.

Safe typing is not about preventing heavy-handed use of the keyboard, although it can detect errors made by typos!

Safe typing is about designing the type structure of the language in order to prevent many common semantic errors. It is often known as strong typing.

Early languages such as Fortran and Algol treated all data as numeric types. Of course, at the end of the day, everything is indeed held in the computer as a numeric of some form, usually as an integer or floating point value and usually encoded using a binary representation. Later languages, starting with Pascal, began to recognize that there was merit in taking a more abstract view of the objects being manipulated. Even if they were ultimately integers, there was much benefit to be gained by treating colors as colors and not as integers by using enumeration types (just called scalar types in Pascal).

Ada take this idea much further as we shall see, but other languages still treat scalar types as just raw numeric types, and miss the critical idea of abstraction, which is to distinguish semantic intent from machine representation. The Ada approach provides more opportunities for detecting programming errors.

Read Chapter 2 in full

Note: All chapters of this booklet will, in time, be available on the Ada 2005 home page.

Today’s interconnected critical systems must be both safe and secure; software developers and decision makers need to understand the operative certification standards and their implications on technology choice and system development. This presentation first summarizes the DO-178B avionics safety standard and the Common Criteria / Common Evaluation Methodology security standard. It identifies the requirements that these standards impose on programming language technology and development tools, and explains how safety and security considerations are similar and how they differ. It describes how modern programming language features such as Object-Oriented Programming affect safety and security certification, and assesses several current language family approaches — C / C++, Ada / SPARK, and Java — against safety and security requirements.