Ada 95 Quality and Style Guide Chapter 7
Discussions concerning portability usually concentrate on the diferences in computer systems, but the development and run-time environment may also change:
Most portability problems are not pure language issues. Portability involves hardware (byte order, device I/O) and software (utility libraries, operating systems, run-time libraries). This chapter will not address these challenging design issues.
This chapter does identify the more common portability problems that are specific to Ada when moving from one platform or compiler to another. It also suggests ways that nonportable code can be isolated. By using the implementation hiding features of Ada, the cost of porting can be significantly reduced.
In fact, many language portability issues are solved by the strict definition of the Ada language itself. In most programming languages, different dialects are prevalent as vendors extend or dilute a language for various reasons: conformance to a programming environment or features for a particular application domain. The Ada Compiler Validation Capability (ACVC) was developed by the U.S. Department of Defense at the Ada Validation Facility, ASD/SIDL, Wright-Patterson Air Force Base, to ensure that implementors strictly adhered to the Ada standard.
As part of the strict definition of Ada, certain constructs are defined to be erroneous, and the effect of executing an erroneous construct is unpredictable. Therefore, erroneous constructs are obviously not portable. Erroneous constructs and bounded errors are discussed in Guideline 5.9.10 and are not repeated in this chapter.
Most programmers new to the language expect Ada to eliminate all portability problems; it definitely does not. Certain areas of Ada are not yet covered by validation. The definition of Ada leaves certain details to the implementor. The compiler implementor's choices, with respect to these details, affect portability.
The revisions to the Ada language approved in the 1995 standard generate a new area of portability concerns. Some programs are intended to have a long life and may start in Ada 83 (Ada Reference Manual 1983) but transition to Ada 95 (Ada Reference Manual 1995). Although this style guide focuses on the current Ada standard and does not address transition issues, there are portability issues relating to using certain features of the language. These issues revolve around the language features designated as obsolescent in Annex J of the Ada Reference Manual (1995).
The constructs of the language have been developed to satisfy a series of needs. These constructs can legitimately be used even though they may impact portability. There are some general principles to enhancing portability that are exemplified by many of the guidelines in this chapter. They are:
These guidelines cannot be applied thoughtlessly. Many of them involve a detailed understanding of the Ada model and its implementation. In many cases, you will have to make carefully considered tradeoffs between efficiency and portability. Reading this chapter should improve your insight into the tradeoffs involved.
The material in this chapter was largely acquired from three sources: the Ada Run-Time Environments Working Group (ARTEWG) Catalogue of Ada Runtime Implementation Dependencies (ARTEWG 1986); the Nissen and Wallis book on Portability and Style in Ada (Nissen and Wallis 1984); and a paper written for the U.S. Air Force by SofTech on Ada Portability Guidelines (Pappas 1985). The last of these sources (Pappas 1985) encompasses the other two and provides an in-depth explanation of the issues, numerous examples, and techniques for minimizing portability problems. Conti (1987) is a valuable reference for understanding the latitude allowed for implementors of Ada and the criteria often used to make decisions.
This chapter's purpose is to provide a summary of portability issues in the guideline format of this book. The chapter does not include all issues identified in the references but only the most significant. For an in-depth presentation, see Pappas (1985). A few additional guidelines are presented here and others are elaborated upon where applicable. For further reading on Ada I/O portability issues, see Matthews (1987), Griest (1989), and CECOM (1989).
Some of the guidelines in this chapter cross reference and place stricter constraints on other guidelines in this book. These constraints apply when portability is being emphasized.
Guidelines in this chapter are frequently worded "consider . . ." because hard and fast rules cannot apply in all situations. The specific choice you make in a given situation involves design tradeoffs. The rationale for these guidelines is intended to give you insight into some of these tradeoffs.
Ten years of reflection on the use of Ada 83 led to the conclusion that some features of the original language are not as useful as originally intended. These features have been replaced with others in the Ada 95 revision. It would have been desirable to remove the obsolescent features completely, but that would have prevented the upward compatible transition of programs from Ada 83 to Ada 95. Thus, the obsolescent features remain in the language and are explicitly labeled as such in Annex J of the Ada Reference Manual (1995). The features listed in Annex J are candidates for removal from the language during its next revision. If a program's lifetime may extend beyond the next language revision, it should avoid the obsolescent language features unless backward compatibility with Ada 83 forces their use.
exceptions
When you instantiate Ada.Text_IO.Float_IO, the values of the Default_Fore and Default_Aft fields are set from the values of the 'Fore and 'Aft attributes of the actual floating-point type used in the instantiation. If you declare a reduced accuracy floating-point type that you then use to instantiate Ada.Text_IO.Float_IO, the output field widths are determined from the reduced accuracy type, although the implementation accuracy is unchanged (Rationale 1995, �3.3).
Some assumptions must be made with respect to certain implementation-specific values. The exact values assumed should cover the majority of the target equipment of interest. Choosing the lowest common denominator for values improves portability. Implementations may supply an alternate character set specific to a locale or environment. For instance, the implementation on an IBM-compatible PC may support that machine's native character set rather than Latin 1. As a result, some character values may or may not be supported, for example, the smiley face.
notes
Of the microcomputers currently available for incorporation within embedded systems, 16-bit and 32-bit processors are prevalent. Using current representation schemes, 6 decimal digits of floating point accuracy imply a representation mantissa at least 21 bits wide, leaving 11 bits for exponent and sign within a 32-bit representation. This correlates with the data widths of floating point hardware currently available for the embedded systems market. A 32-bit minimum on fixed-point numbers correlates with the accuracy and storage requirements of floating point numbers. The 16-bit example for Root_Integer expressions matches that for Integer storage. (The 32-bit integers can be assumed if the application will only be considered for 32-bit processors with a corresponding 32-bit operating system and supporting compiler.)
The values for the range and accuracy of values of the predefined type Duration are the limits expressed in the Ada Reference Manual (1995, �9.6). You should not expect an implementation to provide a wider range or a finer granularity.
A standard-mode Ada character set of Latin 1 can be assumed in most cases for the contents and internal behavior of type Character and packages Character.Latin_1, Character.Handling, and Strings.Maps. However, this does not mean that the target hardware platform is capable of displaying the entire character set. You should not use a nonstandard Ada character set unless intentionally producing a nonportable user interface with a specific purpose.
------------------------------------------------------------------------ package Memory_Mapped_IO is -- WARNING - This package is implementation specific. -- It uses absolute memory addresses to interface with the I/O -- system. It assumes a particular printer's line length. -- Change memory mapping and printer details when porting. Printer_Line_Length : constant := 132; type Data is array (1 .. Printer_Line_Length) of Character; procedure Write_Line (Line : in Data); end Memory_Mapped_IO; ------------------------------------------------------------------------ with System; with System.Storage_Elements; package body Memory_Mapped_IO is -- WARNING: Implementation specific memory address Buffer_Address : constant System.Address := System.Storage_Elements.To_Address(16#200#); --------------------------------------------------------------------- procedure Write_Line (Line : in Data) is Buffer : Data; for Buffer'Address use Buffer_Address; begin -- Write_Line -- perform output operation through specific memory locations. ... end Write_Line; --------------------------------------------------------------------- end Memory_Mapped_IO; ------------------------------------------------------------------------
example
The following example encapsulates the arguments for a hypothetical "execution mode" argument passed from the environment. It encapsulates both the expected position and the expected values of the argument, as well as provides a default in cases where the environment was unable to provide the information:
package Environment is type Execution_Mode is (Unspecified, Interactive, Batch); function Execution_Argument return Execution_Mode; ... end Environment; ---------------------------------------------------------------------- with Ada.Command_Line; use Ada.Command_Line; with Ada.Strings.Unbounded; use Ada.Strings.Unbounded; package body Environment is function Execution_Argument return Execution_Mode is Execution_Argument_Number : constant := 1; Interactive_Mode_String : constant String := "-i"; Batch_Mode_String : constant String := "-b"; begin if Argument_Count < Execution_Argument_Number then return Unspecified; elsif To_Unbounded_String (Argument (Execution_Argument_Number)) = Interactive_Mode_String then return Interactive; elsif To_Unbounded_String (Argument (Execution_Argument_Number)) = Batch_Mode_String then return Batch; else return Unspecified; end if; end Execution_Argument; end Environment;
rationale
The predefined language environment declares the package Ada.Command_Line, providing a standardized way for a program to obtain the values of a command line. Because all Ada compilers must implement the packages in the predefined language environment, you can create a program that is more portable, maintainable, and readable by using this package. You should, however, be aware that even though the language defines the objects and type profiles of this package, it does not force a relationship between the function results and any other entity or operation, and thus, allows the possibility of a nonportable behavior and specification.
The value returned by the function Ada.Command_Line.Argument_Count is implementation-dependent. Different operating systems follow different conventions regarding the parsing and meaning of command line parameters. To enhance your program's portability, assume the simplest case: that the external execution environment does not support passing arguments to a program.
Some operating systems are capable of acquiring and interpreting returned integer values near 0 from a function, but many others cannot. Further, many real-time, embedded systems will not be designed to terminate, so a function or a procedure having parameters with modes out or in out will be inappropriate to such applications.
This leaves procedures with in parameters. Although some operating systems can pass parameters into a program as it starts, others are not. Also, an implementation may not be able to perform type checking on such parameters even if the surrounding environment is capable of providing them.
notes
Real-time, embedded applications may not have an "operator" initiating the program to supply the parameters, in which case it would be more appropriate for the program to have been compiled with a package containing the appropriate constant values or for the program to read the necessary values from switch settings or a downloaded auxiliary file. In any case, the variation in surrounding initiating environments is far too great to depend upon the kind of last-minute (program) parameterization implied by (subprogram) parameters to the main subprogram. POSIX 5 provides a standard operating system command line interface that might be a more appropriate alternative to the Ada command line facility depending on the implementation family of an application.
7.1.5 Encapsulating Implementation Dependencies
See Guideline 7.1.3.
rationale
Encapsulating hardware and implementation dependencies in a package allows the remainder of the code to ignore them and, thus, to be fully portable. It also localizes the dependencies, making it clear exactly which parts of the code may need to change when porting the program.
Some implementation-dependent features may be used to achieve particular performance or efficiency objectives. Commenting these objectives ensures that the programmer can find an appropriate way to achieve them when porting to a different implementation or explicitly recognize that they cannot be achieved.
Interrupt entries are implementation-dependent features that may not be supported (e.g., VAX Ada uses pragmas to assign system traps to "normal" rendezvous). However, interrupt entries cannot be avoided in most embedded, real-time systems, and it is reasonable to assume that they are supported by an Ada implementation. The value for an interrupt is implementation-defined. Isolate it.
notes
You can use Ada to write machine-dependent programs that take advantage of an implementation in a manner consistent with the Ada model but that make particular choices where Ada allows implementation freedom. These machine dependencies should be treated in the same way as any other implementation-dependent features of the code.
7.1.6 Implementation-Added Features
Vendor-added features are not likely to be provided by other implementations. Even if a majority of vendors eventually provide similar additional features, they are unlikely to have identical formulations. Indeed, different vendors may use the same formulation for (semantically) entirely different features. See Guideline 7.5.2 for further information on vendor-supplied exceptions.
Ada has introduced a number of new pragmas and attributes that were not present in Ada 83 (Ada Reference Manual 1983). These new pragmas and attributes may clash with implementation-defined pragmas and attributes.
exceptions
There are many kinds of applications that require the use of these features. Examples include multilingual systems that standardize on a vendor's file system, applications that are closely integrated with vendor products (i.e., user interfaces), and embedded systems for performance reasons. Isolate the use of these features into packages.
If a vendor-supplied package is provided in compilable source code form, use of the package does not make a program nonportable provided that the package does not contain any nonportable code and can be lawfully included in your program.
7.1.7 Specialized Needs Annexes
The Specialized Needs Annexes define standards for specific application areas without extending the syntax of the language. You can port a program with specific domain needs (e.g., distributed systems, information systems) across vendor implementations more easily if they support the features standardized in an annex rather than rely on specific vendor extensions. The purpose of the annexes is to provide a consistent and uniform way to address issues faced in several application areas where Ada is expected to be used. Because different compilers will support different sets of annexes if any, you may have portability problems if you rely on the features defined in any given annex.
The Specialized Needs Annexes provide special capabilities that go beyond the core language definition. Because compilers are not required to support the special-purpose annexes, you should localize your use of these features where possible. By documenting their usage, you are leaving a record of potential porting difficulties for future programmers.
7.1.8 Dependence on Parameter Passing Mechanism
example
The output of this program depends on the particular parameter passing mechanism that was used:
------------------------------------------------------------------------ with Ada.Integer_Text_IO; procedure Outer is type Coordinates is record X : Integer := 0; Y : Integer := 0; end record; Outer_Point : Coordinates; --------------------------------------------------------------------- procedure Inner (Inner_Point : in out Coordinates) is begin Inner_Point.X := 5; -- The following line causes the output of the program to -- depend on the parameter passing mechanism. Ada.Integer_Text_IO.Put(Outer_Point.X); end Inner; --------------------------------------------------------------------- begin -- Outer Ada.Integer_Text_IO.Put(Outer_Point.X); Inner(Outer_Point); Ada.Integer_Text_IO.Put(Outer_Point.X); end Outer; ------------------------------------------------------------------------
If the parameter passing mechanism is by copy, the results on the standard output file are:
0 0 5
If the parameter passing mechanism is by reference, the results are:
0 5 5
The following code fragment shows where there is a potential for bounded error when a procedure is called with actual parameters denoting the same object:
procedure Test_Bounded_Error (Parm_1 : in out Integer; Parm_2 : in out Integer) is procedure Inner (Parm : in out Integer) is begin Parm := Parm * 10; end Inner; begin Parm_2 := 5; Inner (Parm_1); end Test_Bounded_Error;
In executing the procedure Test_Bounded_Error, both Parm_1 and Parm_2 denote the object Actual_Parm. After executing the first statement, the object Actual_Parm has the value 5. When the procedure Inner is called, its formal parameter Parm denotes Actual_Parm. It cannot be determined whether it denotes the old value of Parm_1, in this case 1, or the new value, in this case 5.
Actual_Parm : Integer := 1; . . . Test_Bounded_Error (Actual_Parm, Actual_Parm); -- potential bounded error
rationale
Certain composite types (untagged records and arrays) can be passed either by copy or by reference. If there are two or more formal parameters of the same type, one or more of which is writable, then you should document whether you assume that these formal parameters do not denote the same actual object. Similarly, if a subprogram that has a formal parameter of a given subtype also makes an up-level reference to an object of this same type, you should document whether you assume that the formal parameter denotes a different object from the object named in the up-level reference. In these situations where an object can be accessed through distinct formal parameter paths, the exception Program_Error may be raised, the new value may be read, or the old value of the object may be used (Ada Reference Manual 1995, �6.2).
See also Guideline 8.2.7.
exceptions
Frequently, when interfacing Ada to foreign code, dependence on parameter-passing mechanisms used by a particular implementation is unavoidable. In this case, isolate the calls to the foreign code in an interface package that exports operations that do not depend on the parameter-passing mechanism.
7.1.9 Arbitrary Order Dependencies
The output of this program depends upon the order of evaluation of subprogram parameters, but the Ada Reference Manual (1995, �6.4) specifies that these evaluations are done in an arbitrary order:
package Utilities is function Unique_ID return Integer; end Utilities; package body Utilities is ID : Integer := 0; function Unique_ID return Integer is begin ID := ID + 1; return ID; end Unique_ID; end Utilities; -------------------------------------------------------------------------------- with Ada.Text_IO; with Utilities; use Utilities; procedure P is begin Ada.Text_IO.Put_Line (Integer'Image(Unique_ID) & Integer'Image(Unique_ID)); end P;
If the parameters to the "&" function are evaluated in textual order, the output is:
1 2
If the parameters are evaluated in the reverse order, the output is:
2 1
rationale
The Ada language defines certain evaluations to occur in arbitrary order (e.g., subprogram parameters). While a dependency on the order of evaluation may not adversely affect the program on a certain implementation, the code might not execute correctly when it is ported. For example, if two actual parameters of a subprogram call have side effects, the effect of the program could depend on the order of evaluation (Ada Reference Manual 1995, �1.1.4). Avoid arbitrary order dependencies, but also recognize that even an unintentional error of this kind could prohibit portability.
The second and third examples below are not representable as subranges of Integer on a machine with a 16-bit word. The first example below allows a compiler to choose a multiword representation, if necessary.
Use:
type Second_Of_Day is range 0 .. 86_400;
rather than:
type Second_Of_Day is new Integer range 1 .. 86_400;
or:
subtype Second_Of_Day is Integer range 1 .. 86_400;
rationale
An implementor is free to define the range of the predefined numeric types. Porting code from an implementation with greater accuracy to one of lesser accuracy is a time consuming and error-prone process. Many of the errors are not reported until run-time.
This applies to more than just numerical computation. An easy-to-overlook instance of this problem occurs if you neglect to use explicitly declared types for integer discrete ranges (array sizes, loop ranges, etc.) (see Guidelines 5.5.1 and 5.5.2). If you do not provide an explicit type when specifying index constraints and other discrete ranges, a predefined integer type is assumed.
The predefined numeric types are useful when you use them wisely. You should not use them to avoid declaring numeric types�then you lose the benefits of strong typing. When your application deals with different kinds of quantities and units, you should definitely separate them through the use of distinct numeric types. However, if you are simply counting the number of iterations in an iterative approximation algorithm, declaring a special integer type is probably overkill. The predefined exponentiation operators ** require an integer as the type of its right operand.
You should use the predefined types Natural and Positive for manipulating certain kinds of values in the predefined language environment. The types String and Wide_String use an index of type Positive. If your code indexes into a string using an incompatible integer type, you will be forced to do type conversion, reducing its readability. If you are performing operations like slices and concatenation, the subtype of your numeric array index is probably insignificant and you are better off using a predefined subtype. On the other hand, if your array represents a table (e.g., a hash table), then your index subtype is significant, and you should declare a distinct index type.
notes
There is an alternative that this guideline permits. As Guideline 7.1.5 suggests, implementation dependencies can be encapsulated in packages intended for that purpose. This could include the definition of a 32-bit integer type. It would then be possible to derive additional types from that 32-bit type.
rationale
The Numerics Annex defines the accuracy and performance requirements for floating- and fixed-point arithmetic. The Annex provides a "strict" mode in which the compiler must support these requirements. To guarantee that your program's numerical performance is portable, you should compile and link in the strict mode. If your program relies upon the numeric properties of the strict mode, then it will only be portable to other environments that support the strict numerics mode.
The accuracy of floating-point numbers is based on what machine numbers can be represented exactly in storage. A computational result in a register can fall between two machine numbers when the register contains more bits than storage. You can step through the machine numbers using the attributes 'Pred and 'Succ. Other attributes return values of the mantissa, exponent, radix, and other characteristics of floating- and fixed-point numbers.
7.2.6 Subexpression Evaluation
example
This example is adapted from the Rationale (1995, �3.3):
with Ada.Text_IO; with Ada.Integer_Text_IO; procedure Demo_Overflow is -- assume the predefined type Integer has a 16-bit range X : Integer := 24_000; Y : Integer; begin -- Demo_Overflow y := (3 * X) / 4; -- raises Constraint_Error if the machine registers used are 16-bit -- mathematically correct intermediate result if 32-bit registers Ada.Text_IO.Put ("("); Ada.Integer_Text_IO.Put (X); Ada.Text_IO.Put (" * 3 ) / 4 = "); Ada.Integer_Text_IO.Put (Y); exception when Constraint_Error => Ada.Text_IO.Put_Line ("3 * X too big for register!"); end Demo_Overflow;
rationale
The Ada language does not require that an implementation perform range checks on subexpressions within an expression. Ada does require that overflow checks be performed. Thus, depending on the order of evaluation and the size of the registers, a subexpression will either overflow or produce the mathematically correct result. In the event of an overflow, you will get the exception Constraint_Error. Even if the implementation on your program's current target does not result in an overflow on a subexpression evaluation, your program might be ported to an implementation that does.
abs (X - Y) <= Float_Type'Model_Small -- (1) abs (X - Y) <= Float_Type'Base'Model_Small -- (2) abs (X - Y) <= abs X * Float_Type'Model_Epsilon -- (3) abs (X - Y) <= abs X * Float_Type'Base'Model_Epsilon -- (4)
abs X <= Float_Type'Model_Small -- (1) abs X <= Float_Type'Base'Model_Small -- (2) abs X <= abs X * Float_Type'Model_Epsilon -- (3) abs X <= abs X * Float_Type'Base'Model_Epsilon -- (4)
Strict relational comparisons ( <, >, =, /= ) are a general problem with computations involving real numbers. Because of the way comparisons are defined in terms of model intervals, it is possible for the values of the comparisons to depend on the implementation. Within a model interval, the result of comparing two values is nondeterministic if the values are not model numbers. In general, you should test for proximity rather than equality as shown in the examples. See also Rationale (1995, ��G.4.1 and G.4.2.).
Type attributes are the primary means of symbolically accessing the implementation of the Ada numeric model. When the characteristics of the model numbers are accessed by type attributes, the source code is portable. The appropriate model numbers of any implementation will then be used by the generated code.
Although 0 is technically not a special case, it is often overlooked because it looks like the simplest and, therefore, safest case. But in reality, each time comparisons involve small values, you should evaluate the situation to determine which technique is appropriate.
notes
Regardless of language, real-valued computations have inaccuracy. That the corresponding mathematical operations have algebraic properties usually introduces some confusion. This guideline explains how Ada deals with the problem that most languages face.
7.2.8 Decimal Types and the Information Systems Annex
example
-- The salary cap today is $500,000; however this can be expanded to $99,999,999.99. type Executive_Salary is delta 0.01 digits 10 range 0 .. 500_000.00; ------------------------------------------------------------------------------ package Currency is type Dollars is delta 0.01 digits 12; type Marks is delta 0.01 digits 12; type Yen is delta 0.01 digits 12; function To_Dollars (M : Marks) return Dollars; function To_Dollars (Y : Yen) return Dollars; function To_Marks (D : Dollars) return Marks; function To_Marks (Y : Yen) return Marks; function To_Yen (D : Dollars) return Yen; function To_Yen (M : Marks) return Yen; end Currency;
rationale
The Ada language does not provide any predefined decimal types. Therefore, you need to declare decimal types for the different scales you will need to use. Differences in scale and precision must be considered in deciding whether or not a common type will suffice (Brosgol, Eachus, and Emery 1994).
You need different types for objects measured in different units. This allows the compiler to detect mismatched values in expressions. If you declare all decimal objects to be of a single type, you forego the benefits of strong typing. For example, in an application that involves several currencies, each currency should be declared as a separate type. You should provide appropriate conversions between different currencies.
You should map data with no particular unit of measure to a small set of types or a single type to avoid the explosion of conversions between numeric types.
Separate the range requirement on a decimal type from its precision, i.e., the number of significant digits required. From the point of view of planning for change and ease of maintenance, you can use the digit's value to accommodate future growth in the values to be stored in objects of the type. For example, you may want to anticipate growth for database values and report formats. You can constrain the values of the type through a range constraint that matches current needs. It is easier to modify the range and avoid redefining databases and reports.
Ada automatically truncates toward 0. If your requirements are to round the decimal result, you must explicitly do so using the 'Round attribute.
The core language defines the basic syntax of and operations on decimal types. It does not specify, however, the minimum number of significant digits that must be supported. Nor does the core language require the compiler to support values of Small other than powers of 2, thus enabling the compiler effectively to reject a decimal declaration (Ada Reference Manual 1995, �3.5.9). The Information Systems Annex provides additional support for decimal types. It requires a minimum of 18 significant digits. It also specifies a Text_IO.Editing package that provides support analogous to the COBOL picture approach.
7.3.2 Access-to-Subprogram Values
The Ada Reference Manual (1995, �3.10.2) explains that an "implementation may consider two access-to-subprogram values to be unequal, even though they designate the same subprogram. This might be because one points directly to the subprogram, while the other points to a special prologue that performs an Elaboration_Check and then jumps to the subprogram." The Ada Reference Manual (1995, �4.5.2) states that it is "unspecified whether two access values that designate the same subprogram but are the result of distinct evaluations of Access attribute references are equal or unequal."
See also Guideline 5.3.4.
exceptions
If you must compare an access-to-subprogram value, you should define a constant using the access-to-subprogram value and make all future comparisons against the constant. However, if you attempt to compare access-to-subprogram values with different levels of indirection, the values might still be unequal, even if designating the same subprogram.
See the Ada Reference Manual 1995, §13.11.2).
You use allocators as before. Instead of using unchecked deallocation, you maintain your own free lists of objects that are no longer in use and available for reuse.
You use allocators and possibly unchecked deallocation; however, you implement a storage pool and associate it with the access type(s) via a Storage_Pool clause. You can use this technique to implement a mark/release storage management paradigm, which might be significantly faster than an allocate/deallocate paradigm. Some vendors may provide a mark/release package as part of their Ada environment.
You do not use allocators, but instead use unchecked conversion from the address and do all your own default initialization, etc. It is unlikely you would use this last option because you lose automatic default initialization.
The order in which task objects are activated is left undefined in the Ada Reference Manual (1995, §9.2). See also Guideline 6.1.5.
The rationale for this appears in Guideline 6.1.7. In addition, the treatment of delay statements varies from implementation to implementation, thereby hindering portability.
Using knowledge of the execution pattern of tasks to achieve timing requirements is nonportable. Ada does not specify the underlying scheduling algorithm, and there is no guarantee that system clock ticks will be consistently precise between different systems. Thus, when you change system clocks, your delay behavior also changes.
7.4.3 Package Calendar, Type Duration, and System.Tick
Such a correlation is not required, although it may exist in some implementations.
7.4.4 Select Statement Evaluation Order
The language does not define the order of these conditions, so assume that they are arbitrary.