Ada 95 Quality and Style Guide Chapter 7
Discussions concerning portability usually concentrate on the differences 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.1 through 5.9.10 and are not repeated in this chapter.
<
p>
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.
This section introduces some generally applicable principles of writing portable Ada programs. It includes
guidelines about the assumptions you should make with respect to a number of Ada features and their
implementations and guidelines about the use of other Ada features to ensure maximum portability.
7.1.1 Obsolescent Features
guideline
exceptions
7.1.2 Global Assumptions
guideline
instantiation
notes
7.1.3 Comments
guideline
example
rationale
Explicitly commenting each breach of portability will raise its visibility and aid in the porting process. A
description of the nonportable feature's expectations covers the common case where vendor documentation of
the original implementation is not available to the person performing the porting process.
7.1.4 Main Subprogram
guideline
example
rationale
guideline
7.1.6 Implementation-Added Features
guideline
rationale
exceptions
7.1.7 Specialized Needs Annexes
guideline
7.1.8 Dependence on Parameter Passing Mechanism
guideline
example
guideline
A great deal of care was taken with the design of the Ada features related to numeric computations to ensure that
the language could be used in embedded systems and mathematical applications where precision was important.
As far as possible, these features were made portable. However, there is an inevitable tradeoff between maximally
exploiting the available precision of numeric computation on a particular machine and maximizing the portability
of Ada numeric constructs. This means that these Ada features, particularly numeric types and expressions, must
be used with great care if full portability of the resulting program is to be guaranteed.
7.2.1 Predefined Numeric Types
guideline
notes
guideline
rationale
7.2.3 Accuracy Analysis
guideline
rationale
guideline
rationale
7.2.5 Comments
guideline
rationale
7.2.6 Subexpression Evaluation
guideline
example
7.2.7 Relational Tests
guideline
example
guideline
example
rationale
The management of dynamic storage can vary between Ada environments. In fact, some environments do not
provide any deallocation. The following Ada storage control mechanisms are implementation-dependent and
should be used with care in writing portable programs.
7.3.1 Representation Clause
guideline
rationale
notes
7.3.2 Access-to-Subprogram Values
guideline
rationale
guideline
example
The definition of tasking in the Ada language leaves many characteristics
of the tasking model up to the implementor. This allows a vendor
to make appropriate tradeoffs for the intended application domain,
but it also diminishes the portability of designs and code employing
the tasking features. In some respects, this diminished portability
is an inherent characteristic of concurrency approaches (see Nissen
and Wallis 1984, 37).
A discussion of Ada tasking dependencies when employed in a distributed
target environment is beyond the scope of this book. For example,
multiprocessor task scheduling, interprocessor rendezvous, and
the distributed sense of time through package Calendar
are all subject to differences between implementations. For more
information, Nissen and Wallis (1984) and ARTEWG (1986) touch
on these issues, and Volz et al. (1985) is one of many research
articles available.
If the Real-Time Systems Annex is supported, then many concurrency
aspects are fully defined and, therefore, a program can rely on
these features while still being portable to other implementations
that conform to the
Real-Time Systems Annex. The following sections provide
guidelines based on the absence of this annex.
7.4.1 Task Activation Order
guideline
rationale
guideline
guideline
guideline
7.1 FUNDAMENTALS
rationale
rationale
example
rationale
notes
rationale
example
rationale
7.2 NUMERIC TYPES AND EXPRESSIONS
example
7.3 STORAGE CONTROL
7.4 TASKING
rationale
7.4.3 Package Calendar, Type Duration, and System.Tick
rationale
7.4.4 Select Statement Evaluation Order
rationale
Chapter 7 continued on next page.
In This Guide:
Table of Contents
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Chapter 6
Chapter 7
Chapter 8
Chapter 9
Chapter 10
Chapter 11
Appendix
References
Bibliography
Index