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.

Ada is a block-structured language, which means the programmer can nest blocks of code inside other blocks. At the end of a block, all objects declared inside of it go out of scope, meaning they no longer exist, so the language disallows pointers to objects in blocks with a deeper nesting level.

In order to prevent dangling references, every entity is associated with a number, called its “accessibility level”, according to a Ada’s accessibility rules. When certain references are made to an entity of an access type (Ada’s parlance for pointer), the accessibility level of the entity is checked against the level allowed by the context so that no dangling pointers can occur.

Consider the following example:

     procedure Static_Check is
        type Global is access all Integer;
        X : Global;

        procedure Init is
           Y : aliased Integer := 0;
        begin
           X := Y'Access; -- Illegal!
        end Init;
   
     begin
        Init;
        …
     end Static_Check;

The assignment is illegal because when the procedure Init finishes, the object Y no longer exists, thus making X a danging pointer. The compiler will detect this situation and flag the error.

The beauty of the accessibility rules is that most of them can be checked and enforced at compile time, just by using statically known accessibility levels.

However, there are cases when it is not possible to statically determine the accessibility level that an entity will have during program execution. In these cases, the compiler will insert a run-time check to raise an exception if a dangling pointer can be created:

     procedure Access_Params is
        type Integer_Access is access all Integer;
        Data : Integer_Access;

        procedure Init_Data (Value : access Integer) is
        begin
           Data := Integer_Access (Value);
           -- this conversion performs a dynamic accessibility check
        end;

        X : aliased Integer := 1;

     begin
        Init_Data (X'Access); -- This is OK 

        declare  
           Y : aliased Integer := 2;
        begin
           Init_Data (Y'Access); --  Trouble!
        end;
	--  Y no longer exists!

	Process (Data);
     end;

In the example above, we cannot know at compile time the accessibility level of the object that will be passed to Init_Data, so the compiler inserts a run-time check to make sure that the assignment ‘Data := …’ does not cause a dangling reference — and to raise an exception if it would.

In summary, when it comes to dangling references, Ada makes it very hard for you to shoot yourself in the foot!

Syntax is often considered to be a rather boring mechanical detail. The argument being that it is what you say that matters but not so much how it is said. That of course is not true. Being clear and unambiguous are important aids to any communication in a civilized world.

Similarly, a computer program is a communication between the writer and the reader, whether the reader be that awkward thing: the compiler, another team member, a reviewer or other human soul. Indeed, most communication regarding a program is between two people. Clear and unambiguous syntax is a great help in aiding communication and, as we shall see, avoids a number of common errors.

An important aspect of good syntax design is that it is a worthwhile goal to try to ensure that typical simple typing errors cause the program to become illegal and thus fail to compile, rather than having an unintended meaning. Of course it is hard to prevent the accidental typing of X rather than Y or + rather than * but many structural risks can be prevented. Note incidentally that it is best to avoid short identifiers for just this reason. If we have a financial program about rates and times then using identifiers R and T is risky since we could easily type the wrong identifier by mistake (the letters are next to each other on the keyboard). But if the identifiers are Rate and Time then inadvertently typing Tate or Rime will be caught by the compiler. This applies to any language of course.

Read Chapter 1 in full

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

The notion of preconditions and postconditions is an old one. A precondition is a condition that must be true before a section of code is executed, and a postcondition is a condition that must be true after the section of code is executed.

In the context we are talking about here, the section of code will always be a subprogram. Preconditions are conditions that must be guaranteed by the caller before the call, and postconditions are results guaranteed by the subprogram code itself.

It is possible, using pragma Assert (as defined in Ada 2005, and as implemented in all versions of GNAT), to approximate run-time checks corresponding to preconditions and postconditions by placing assertion pragmas in the body of the subprogram, but there are several problems with that approach:

1. The assertions are not visible in the spec, and preconditions and postconditions are logically a part of (in fact, an important part of) the spec.

2. Postconditions have to be repeated at every exit point.

3. Postconditions often refer to the original value of a parameter on entry or the result of a function, and there is no easy way to do that in an assertion.

The latest versions of GNAT implement two pragmas, Precondition and Postcondition, that deal with all three problems in a convenient way. The easiest way to describe these is to use an example:

    package Arith is
       function Sqrt (Arg : Integer) return Integer;
       pragma Precondition (Arg >= 0);
       pragma Postcondition
        (Sqrt'Result >= 0
           and then
        (Sqrt'Result ** 2) <= Arg
           and then
        (Sqrt'Result + 1) ** 2 > Arg);
    end Arith;

    with Arith; use Arith;
    with Text_IO; use Text_IO;
    procedure Main is
    begin
       Put_Line (Sqrt (9)'Img);
       Put_Line (Sqrt (10)'Img);
       Put_Line (Sqrt (-3)'Img);
    end;

Now if we compile with -gnata (which enables preconditions and postconditions), and we have a correct body for Sqrt, then when we run Main we will get:

     3
     3

    raised SYSTEM.ASSERTIONS.ASSERT_FAILURE :
       Precondition failed at arith.ads:3

Now if there was something wrong with the body of Sqrt that gave the wrong answer, we might get:

    raised SYSTEM.ASSERTIONS.ASSERT_FAILURE :
      postcondition failed at arith.ads:4

Indicating that we have a bug in the body of Sqrt that we must investigate.

There is one more thing to mention, which is the promised ability to refer to the old value of parameters. A new attribute ‘Old allows this as shown in this example:

    procedure Write_Data (Total_Writes : in out Natural);
    --  Write out the data incrementing Total_Writes to
    --  show number of write operations performed.
    pragma Postcondition (Total_Writes > Total_Writes'Old);

The preconditions and postconditions serve three functions
1. They provide valuable formal documentation in the spec
2. They provide input to proof tools
3. They help find bugs in the course of normal debugging as shown by the example above.

Support for preconditions and postconditions will be available in GNAT Pro 6.2.1 and forthcoming versions of GNAT GPL. If you are a GNAT Pro user and you want to try this feature out today, request a wavefront by using GNAT Tracker.

The aim of this booklet is to show how Ada 2005 addresses the needs of designers and implementers of safe and secure software. The discussion will also show that those aspects of Ada that make it ideal for safety-critical and security-critical application areas will also simplify the development of robust and reliable software in many other areas.

The world is becoming more and more concerned about both safety and security. Moreover, software now pervades all aspects of the workings of society. Accordingly, it is important that software which is concerned with systems for which safety or security are a major concern should be safe and secure.

There has been a long tradition of concern for safety going back to the development of railroad signaling and more recently with aviation. Vital software systems such as those that control aircraft navigation and landing have to meet well established certification and validation criteria.

More recently there has been growing concern with security in systems such as banking and communications generally. This has been heightened with concern for the activities of terrorists.

Safety and security are intertwined through communication. An interesting characterization of the difference is
▪ safety – the software must not harm the world,
▪ security – the world must not harm the software.

So a safety-critical system is one in which the program must be correct, otherwise it might wrongly change some external device such as an aircraft flap or a railroad signal, with serious real-world consequences.

And a security-critical system is one in which it must not be possible for some incorrect or malicious input from the outside to violate the integrity of the system, for example by corrupting a password checking mechanism and stealing social security information.

The key to guarding against both problems is that the software must be correct in the aspects affecting the system’s integrity. And by correct we mean that it meets its specification. Of course if the specification is incomplete or itself incorrect then the system will be vulnerable. Capturing requirements correctly is a hard problem and is the focus of much attention from the lean software development community.

One of the trends of the second half of the twentieth century was a universal concern with freedom. But there are two aspects of freedom. The ability of the individual to do whatever they want conflicts with the right to be protected from the actions of others. Maybe A would like the freedom to smoke in a pub whereas B wants freedom from smoke in a pub. Concern with health in this example is changing the balance between these freedoms. Maybe the twenty-first century will see further shifts from “freedom to” to “freedom from”.

In terms of software, the languages Ada and C have very different attitudes to freedom. Ada introduces restrictions and checks, with the goal of providing freedom from errors. On the other hand C gives the programmer more freedom, making it easier to make errors.

One of the historical guidelines in C was “trust the programmer”. This would be fine were it not for the fact that programmers, like all humans, are frail and fallible beings. Experience shows that whatever techniques are used it is hard to write “correct” software. It is good advice therefore to use tools that can help by finding bugs and preventing bugs. Ada was specifically designed to help in this respect. There have been three versions of Ada – Ada 83, Ada 95 and now Ada 2005.

The purpose of this booklet is to illustrate the ways in which Ada 2005 can help in the construction of reliable software, by illustrating some aspects of its features. It is hoped that it will be of interest to programmers and managers at all levels.

It must be stressed that the discussion is not complete. Each chapter selects a particular topic under the banner of Safe X where Safe is just a brief token to designate both safety and security. For the most critical software, use of the related SPARK language appears to be very beneficial, and this is outlined in Chapter 11.

A topic with which Ada has much synergy is lean software development – there is not enough space in this booklet to expand on this concept but the reader is encouraged to explore its good ideas elsewhere.

As the twenty-first century progresses we will see software becoming even more pervasive. It would be nice to think that software in automobiles for example was developed with the same care as that in airplanes. But that is not so. My wife recently had an experience where her car displayed two warning icons. One said “stop at once”, the other said “drive immediately to your dealer”. Another anecdotal motor story is that of a driver attempting to select channel 5 on the radio, only to see the car change into 5th gear! Luckily he did not try Replay.

For a fuller description of Ada 2005, SPARK, and lean software development and papers on related topics please consult the bibliography.

Read on…

Note: All chapters will also be available on the Ada 2005 home page.

This Gem presents a basic introduction the Ada Web Server (AWS). The core components of AWS comprise a Web server which supports the HTTP protocol. This Web server can be embedded into any application. Common usages are:

- To develop a full Web application.
- Adding a GUI to a mostly batch-oriented application like a long-running simulation that we want to get control of from time to time.
- To develop a distributed application exchanging messages using the HTTP or SOAP protocols.

The AWS HTTP module handles the decoding of the HTTP request and encoding of the user’s response. It uses a callback mechanism to interact with the user’s application. Let’s take the famous Hello World example and see how it could be translated into the AWS framework.

First the user’s hello_world callback, which is a function with a single parameter of type Status.Data and returning a Response.Data object:

   with AWS.MIME;
   with AWS.Response;
   with AWS.Status;

   package body CB is
      use AWS;
      function Hello_World (Request : in Status.Data) return Response.Data is
      begin
         return Response.Build (MIME.Text_HTML, "<p>Hello World!</p>");
      end Hello_World;
   end CB;

The AWS.Response unit contains many constructors. Response.Build is one. Another is Response.File, for returning a file. Various high-level constructors are provided, such as for streaming data.

Now here’s the main subprogram with the server:

   with AWS.Server;
   with CB;
   procedure Hello_World is
      use AWS;
      HTTP : Server.HTTP;
   begin
      Server.Start (HTTP, "Hello_World", Callback => CB.Hello_World'Access);
      delay 60.0;
      Server.Shutdown (HTTP);
   end Hello_World;

That’s it. The start routine registers the CB.Hello_World procedure as the user’s callback and starts the server using the default port, which is 8080. After running the hello_world executable, by entering the URL http://localhost:8080/ into your web browser you’ll receive the message “Hello World”, and this will occur for any URI. So entering http://localhost:8080/whatever will also return “Hello World”. After 60 seconds the server will shut down and the program will exit.

All HTTP parameters are available from the Request parameter of the Hello_World callback. So let’s add a local constant to get the actual URI received:

   URI : constant String := Status.URI (Request);

Then we change the Response.Build call to:

   return Response.Build
      (MIME.Text_HTML, "<p>Hello World! URI=" & URI & "</p>");

After restarting the server, entering http://localhost:8080/home into the web browser will display “Hello World! URI=/home”.

An if/elsif construction can be used to test for each URI that must be handled by the server:

   if URI = "…" then
      …
   elsif URI = "…" then
      …
   else
      return Response.Build
         (MIME.Text_HTML,
          "<p>Not found : URI=" & URI & "</p>",
          Status_Code => Messages.S404);
   end if;

Using callbacks is simple, but when the application becomes larger it’s easier to use dispatchers. So let’s change the Hello World program to use dispatchers:

   with AWS.Response;
   with AWS.Status;
   with AWS.Dispatchers;
   package CB is
      use AWS;

      type Hello_World is new Dispatchers.Handler with null record;

      overriding function Dispatch
        (Handler : in Hello_World;
         Request : in Status.Data) return Response.Data;
   private
      overriding function Clone (Element : in Hello_World) return Hello_World;
   end CB;

The body of Dispatch is identical to the Hello_World callback above. The Dispatchers.Handler type has a clonable interface, and Clone in this case is trivial:

   overriding function Clone (Element : in Hello_World) return Hello_World is
   begin
      return Element;
   end Clone;

In this case the main subprogram is slightly larger:

   with AWS.Config;
   with AWS.Server;
   with AWS.Services.Dispatchers.URI;
   with CB;

   procedure Hello_World is
      use AWS;
      HTTP : Server.HTTP;
      Conf : Config.Object;
      HW   : CB.Hello_World;
      Root : Services.Dispatchers.URI.Handler;
   begin
      Services.Dispatchers.URI.Register (Root, "/hello", HW);
      Server.Start (HTTP, Root, Conf);
      delay 60.0;
      Server.Shutdown (HTTP);
  end Hello_World;

The main difference is that we have registered the HW dispatcher to be used only for URI “/hello” (http://localhost:8080/hello). For any other URL, a 404 error message will be sent by the dispatcher module. It’s also possible to use a regular expression or a prefix if needed. The configuration object can be set to change any server settings, such as the port, the number of simultaneous connections, timeouts, etc.

Many kinds of dispatchers exist, not only for supporting URIs (as in this example), but also for handling virtual hosts, request methods (POST/GET) and services for linking dispatchers, as well as dispatching based on timers (see child units of AWS.Services.Dispatchers). For an example of a simple API for converting a callback to a dispatcher see AWS.Dispatchers.Callback.

Various other services are offered directly by AWS, including HTTP/SOAP, WSDL, Ajax, SMTP, and a templates engine. But covering all of those is beyond the scope of this introduction.

Related Source Code

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

The reason for that is that the change of representation operation can be very expensive, since in general it can require component by component copying, changing the representation on each comoponent.

Let’s have a look at the -gnatG expanded code to see what is hidden under thecovers here. For example, the conversion Arr (Input_Data) from last week’s example generates the following expanded code:

   B26b : declare
      [subtype p__TarrD1 is integer range 1 .. 16]
      R25b : p__TarrD1 := 1;
   begin
      for L24b in 1 .. 16 loop
         [subtype p__arr___XP3 is
           system__unsigned_types__long_long_unsigned range 0 ..
           16#FFFF_FFFF_FFFF#]
         work_data := p__arr___XP3!((work_data and not shift_left!(
           16#7#, 3 * (integer(L24b - 1)))) or shift_left!(p__arr___XP3!
           (input_data (R25b)), 3 * (integer(L24b - 1))));
         R25b := p__TarrD1'succ(R25b);
      end loop;
   end B26b;

That’s pretty horrible! In fact one of the Ada experts here thought that it was too gruesome and suggested simplifying it for this gem, but we have left it in its original form, so that you can see why it is nice to let the compiler generate all this stuff so you don’t have to worry about it yourself.

Given that the conversion can be pretty inefficient, you don’t want to convert backwards and forwards more than you have to, and the whole approach is only worth while if will be doing extensive computations involving the value.

The expense of the conversion explains two aspects of this feature that are not obvious. First, why do we require derived types instead of just allowing subtypes to have different representations, avoiding the need for an explicit conversion?

The answer is precisely that the conversions are expensive, and you don’t want them happening behind your back. So if you write the explicit conversion, you get all the gobbledygook listed above, but you can be sure that this never happens unless you explicitly ask for it.

This also explains the restriction we mentioned in last week’s gem from RM 13.1(10):

10 For an untagged derived type, no type-related representation items are allowed if the parent type is a by-reference type, or has any user-defined primitive subprograms.

It turns out this restriction is all about avoiding implicit changes of representation. Let’s have a look at how type derivation works when there are primitive subprograms defined at the point of derivation. Connsider this example:

  type My_Int_1 is range 1 .. 10;

  function Odd (Arg : My_Int_1) return Boolean;

  type My_Int_2 is new My_Int_1;

Now when we do the type derivation, we inherit the function Odd for My_Int_2. But where does this function come from? We haven’t written it explicitly, so the compiler somehow materializes this new implicit function. How does it do that?

We might think that a complete new function is created including a body in which My_Int_2 replaces My_Int_1, but that would be impractical and expensive. The actual mechanism avoids the need to do this by use of implicit type conversions. Suppose after the above declarations, we write:

  Var : My_Int_2;
  ...
  if Odd (Var) then
     …

The compiler translates this as:

  Var : My_Int_2;
  ...
  if Odd (My_Int_1 (Var)) then
     …

This implicit conversion is a nice trick, it means that we can get the effect of inheriting a new operation without actually having to create it. Furthermore, in a case like this, the type conversion generates no code, since My_Int_1 and My_Int_2 have the same representation.

But the whole point is that they might not have the same representation if one of them had a rep clause that made the representations different, and in this case the implicit conversion inserted by the compiler could be expensive, perhaps generating the junk we quoted above for the Arr case. Since we never want that to happen implicitly, there is a rule to prevent it.

The business of forbidding by-reference types (which includes all tagged types) is also driven by this consideration. If the representations are the same, it is fine to pass by reference, even in the presence of the conversion, but if there was a change of representation, it would force a copy, which would violate the by-reference requirement.

So to summarize these two gems, on the one hand Ada gives you a very convenient way to trigger these complex conversions between different representations. On the other hand, Ada guarantees that you never get these potentially expensive conversions happening unless you explicitly ask for them.

Ada has two kinds of integer type: signed and modular:

    type Signed_Integer is range 1..1_000_000;
    type Modular is mod 2**32;

Operations on signed integers can overflow: if the result is outside the base range, Constraint_Error will be raised. The base range of Signed_Integer is the range of Signed_Integer'Base, which is chosen by the compiler, but is likely to be something like -2**31..2**31-1.

Operations on modular integers use modular (wraparound) arithmetic.

For example:

      X : Modular := 1;
      X := - X;

Negating X gives -1, which wraps around to 2**32-1, i.e. all-one-bits.

But what about a type conversion from signed to modular? Is that a signed operation (so it should overflow) or is it a modular operation (so it should wrap around)? The answer in Ada is the former — that is, if you try to convert, say, Integer'(-1) to Modular, you will get Constraint_Error:

      I : Integer := -1;
      X := Modular (I);  –  raises Constraint_Error

In Ada 95, the only way to do that conversion is to use Unchecked_Conversion, which is somewhat uncomfortable. Furthermore, if you’re trying to convert to a generic formal modular type, how do you know what size of signed integer type to use? Note that Unchecked_Conversion might malfunction if the source and target types are of different sizes.

A small feature added to Ada 2005 solves the problem: the Mod attribute:

    generic
       type Formal_Modular is mod <>;
    package Mod_Attribute is
       function F return Formal_Modular;
    end Mod_Attribute;

    package body Mod_Attribute is

       A_Signed_Integer : Integer := -1;

       function F return Formal_Modular is
       begin
          return Formal_Modular’Mod (A_Signed_Integer);
       end F;

    end Mod_Attribute;

The Mod attribute will correctly convert from any integer type to a given modular type, using wraparound semantics. Thus, F will return the all-ones bit pattern, for whatever modular type is passed to Formal_Modular.

Related Source Code

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