This section 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 non-portable 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 are discussed in Guideline 5.9, 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 leave certain details to the implementor. The compiler implementor's choices with respect to these details affect portability.
There are some general principles to enhancing portability exemplified by many of the guidelines in this chapter. They are:
The material in this chapter was largely acquired from three sources: the Ada Run Time Environment Working Group (ARTEWG) Catalogue of Ada Run Time 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.
In this chapter...
7.1.1 Global Assumptions
7.1.2 Actual Limits
7.1.4 Main Subprogram
7.1.5 Encapsulating Implementation Dependencies
7.1.6 Implementation-Added Features
7.2 Numeric Types and Expressions
7.2.1 Predefined Numeric Types
7.2.2 Ada Model
7.2.4 Accuracy Constraints
7.2.6 Precision of Constants
7.2.7 Subexpression Evaluation
7.2.8 Relational Tests
7.3 Storage Control
7.3.1 Representation Clause
7.4.1 Task Activation Order
7.4.2 Delay Statements
7.4.4 Select Statement Evaluation Order
7.4.5 Task Scheduling Algorithm
7.4.7 Shared Variables and Pragma
7.5.1 Predefined Exceptions
7.5.3 Implementation-Defined Exceptions
7.6 Representation Clauses And Implementation-Dependent Features
7.6.1 Representation Clauses
7.6.3 Machine Code Inserts
7.6.4 Interfacing Foreign Languages
7.6.5 Implementation-Defined Pragmas and Attributes
7.6.6 Unchecked Deallocation
7.6.7 Unchecked Conversion
7.6.8 Run Time Dependencies
7.7.2 File Closing
7.7.3 I/O on Access Types
numeric types and expressions
representation clauses and implementation-dependent features