home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
High Voltage Shareware
/
high1.zip
/
high1
/
DIR9
/
A9X_0610.ZIP
/
9X-GUIDE.HLP
next >
Wrap
Text File
|
1993-06-10
|
37KB
|
635 lines
Form G104-1092a
9X-GUIDE.HLP
Ada Information Clearinghouse, 1-800-AdaIC-11, 1-703/685-1477
(This has been later published in the November/December 1992 issue of ACM
SIGAda's Ada Letters.)
HOW TO PROGRAM IN Ada 9X, USING Ada 83
Erhard Ploedereder, Ph.D.
Tartan, Inc.
300 Oxford Drive
Monroeville, PA, 15146
ploedere@tartan.com
Abstract
Existing software will have to be transitioned from Ada 83 to Ada 9X. This
paper explains presently known incompatibilities between the existing Ada
standard and its proposed revision. It provides guidelines to users, which
will make their Ada 83 code upward compatible with Ada 9X.
1. Introduction
Ada 9X is approaching rapidly. Initiation of the formal ANSI and ISO
standardization processes is expected in late 1993. Although attracted by the
added functionality of Ada 9X, many users are concerned about the eventual
cost of upgrading their Ada applications to the revised standard. Of
particular interest are any incompatibilities that might exist between Ada 83
and Ada 9X. The detection and analysis of such incompatibilities, and the
resulting program changes, add risk and cost to the transition to Ada 9X.
Avoiding such incompatibilities has been a central design goal of the Ada 9X
revision effort. However, in some cases, they are a necessary consequence of
changes to the semantics of existing language features, in order to correct
problems in Ada 83. In early 1992, the Ada 9X Mapping Team compiled a list of
incompatibilities [1] for the then existing Mapping Specification [2,3].
Since that time, refinements of the Mapping Specification have steadily
reduced the number of incompatibilities. Still, some incompatibilities will
remain.
In this article, we provide practical guidelines to Ada 83 programmers, so
that their Ada 83 code will be upward compatible with the Ada 9X standard.
The information presented in this paper is based on the current state (July
'92) of the revision proposal, which is widely regarded as fairly stable.
Nevertheless, it is work in progress, subject to change and all it implies for
the accuracy of the presented information.
While it is conceivable that additional incompatibilities will still be
discovered, it is reassuring to know that, since the time the cited list was
established, review of the Mapping has not revealed previously unknown
incompatibilities. Hence, adherence to the presented guidelines will help
significantly to reduce the effort of migrating to Ada 9X.
Moreover, we believe that these guidelines do not seriously constrain the use
of Ada 83; some of them could be regarded as good style guidelines in any
case. Even if continued work on Ada 9X eliminates some of the
incompatibilities, these guidelines will not have a detrimental effect on the
produced Ada code.
For ease of reference, we first enumerate the guidelines and then explain them
in more detail. We do not attempt to provide any comprehensive rationale for
the underlying language changes; for such information, we refer the reader to
[1] and its future revisions or replacements.
2. The Guidelines at a Glance
Most of the upward incompatibilities imply that some legal Ada 83 programs are
no longer legal in Ada 9X. Any Ada 9X compiler is guaranteed to identify and
reject all such incompatible situations, safeguarding users against
unrecognized changes in program behavior. However, there is also a very small
number of language changes that alter the meaning of Ada 83 programs while
retaining their legality when compiled with an Ada 9X compiler. Unless the
compiler issues friendly informational messages about such situations, these
changes could go unnoticed. They deserve special attention by the users.
Guidelines 2, 5, 9, and 12 address these particular situations.
The incompatibilities likely to be encountered with some frequency are
addressed by Guidelines 8, 10, and possibly 1.
For some of the guidelines, we have consciously preferred a simpler, more
memorable rule to a more precise, but also more complicated one. Guidelines 3
and 7 are examples, where a less encompassing rule would also suffice.
The guidelines for Ada 83 programs are:
1. Do not use the following Ada 9X keywords as Ada 83 identifiers in
your program: aliased, protected, requeue, tagged, until.
2. Do not declare the identifiers WIDE_STRING and WIDE_CHARACTER in
package specifications.
3. Do not apply use-clauses to package SYSTEM.
4. Do not declare the identifier APPEND_FILE in a package
specification. Alternatively, do not apply use-clauses to package
TEXT_IO and instantiations of SEQUENTIAL_IO.
5. For type CHARACTER, be prepared that the enumeration will comprise
256, rather than 128, literals. Similarly, for type FILE_MODE, be
prepared for the added literal APPEND_FILE.
6. Do not use accuracy constraints in subtype declarations.
7. Put representation clauses for real types immediately after the
type declaration.
8. All library unit packages must have bodies, even if such bodies
are empty.
9. Do not derive from a type declared in the same package. Or, if
you do, derive the new types before redefining any predefined
operations on the parent type.
10. Add a distinctive comment to all generic formal private types that
can be legally instantiated with unconstrained types.
11. Do not assume "too much" about the state of the computation when
exceptions are implicitly raised. Do not cause implicit
exceptions knowingly. Be prepared for the elimination of the
exception NUMERIC_ERROR.
12. Be prepared for attribute values of real types to more closely
reflect the actual hardware. Be aware that accuracy requirements
for operations combining fixed-point types with differently based
'SMALL may be lessened.
3. The Guidelines in Detail
Guideline 1:
Do not use the following Ada 9X keywords as Ada 83 identifiers in your
program: aliased, protected, requeue, tagged, until.
These reserved keywords have been added to Ada 9X. Clearly, programs
containing such identifiers will be rejected as syntactically illegal by any
Ada 9X compiler. See declaration (1) in Figure 1 for an example.
For existing programs, editor scripts can be easily written to check for the
absence of such identifiers. If they are present, consistent replacement with
a different identifier makes the code upward compatible. Note, however, that
the choice of a replacement identifier must not coincide with another name
already visible in any of the contexts, in which the conflicting identifier
occurs. A cross-reference listing of the program may greatly assist in
finding unique replacement identifiers.
------------------------------------------------------------------------------
| |
| |
| package PKG is |
| type WIDE_STRING is ....; |
| APPEND_FILE: INTEGER; |
| end PKG; |
| |
| with PKG; use PKG; |
| with TEXT_IO; use TEXT_IO; |
| package NAME_CONFLICTS is |
| |
| PROTECTED: BOOLEAN := true; -- (1) -- illegal in Ada 9X |
| -- 'protected' is now a keyword|
| |
| STR: WIDE_STRING; -- (2) -- in Ada 83, denotes PKG.WIDE_STRING |
| -- in Ada 9X, denotes STANDARD.WIDE_STRING|
| |
| X: INTEGER := APPEND_FILE; -- (3) |
| -- illegal in Ada 9X. Due to new presence |
| -- of name APPEND_FILE in TEXT_IO, the |
| -- name is no longer directly visible |
| |
| |
| end NAME_CONFLICTS; |
| |
| |
| Figure 1: Incompatibilities Caused by New Predefined Names and Keywords |
| |
------------------------------------------------------------------------------
Guideline 2:
Do not declare the identifiers WIDE_STRING and WIDE_CHARACTER in package
specifications.
These identifiers have been added to package STANDARD of Ada 9X. As a
consequence, user-defined names with the same identifier, when made directly
visible via use-clauses, will no longer denote the imported definitions but
those in package STANDARD. The rules of Ada give precedence to directly
visible names over names made directly visible by use-clauses. Theoretically,
the program will still be legal, but behave differently in execution. In
practice, however, it is likely that program illegalities will occur as a
consequence of the altered binding. See declaration (2) in Figure 1 for an
example.
For existing programs, the analysis and correction described for guideline 1
applies.
A secondary consequence of the appearance of the new types WIDE_CHARACTER and
WIDE_STRING for the support of international character sets is that operations
involving only character or string literals may become ambiguous, since the
operation could be for either the Ada 83 types or the new Ada 9X types. For
example, the equalities in
if 'a' = 'b' then ...
if "abc" = "def" then ...
are now ambiguous. The same applies, if the operands are overloaded function
calls that cannot be disambiguated by their parameters. Given that no
competent programmer would compare two string or character literals, this
situation is not worth a guideline. However, preprocessors might generate
such code. The solution is to type-qualify one of the arguments of the
expression. The appearance of a variable anywhere in the expression avoids
the ambiguity.
Guideline 3:
Do not apply use-clauses to package SYSTEM.
This is generally a good Ada 83 guideline, since implementors are free to add
additional declarations to package SYSTEM. Consequently, a new release of a
compiler may declare new names in the package, causing visibility conflicts or
ambiguities in code that already makes equally named declarations from other
packages directly visible via use-clauses. Ada 9X adds additional predefined
names in package SYSTEM and, hence, can cause this problem. Unlike the
situation discussed in Guideline 2, encountering this incompatibility will
make the Ada 83 program illegal in Ada 9X, since the Ada visibility rules will
then make the conflicting, non-overloadable declarations from neither package
directly visible. See Guideline 4 for an analogous problem and example.
Guideline 4:
Do not declare the identifier APPEND_FILE in a package specification.
Alternatively, do not apply use-clauses to package TEXT_IO and instantiations
of SEQUENTIAL_IO.
Ada 9X adds the enumeration literal APPEND_FILE to the FILE_MODE type in these
packages. As an additional name in a predefined package, this can create the
problems already described under Guideline 3. See declaration (3) in Figure 1
for an example.
For existing code, the remedies given under Guideline 1 apply.
Guideline 5:
For type CHARACTER, be prepared that the enumeration will comprise 256, rather
than 128, literals. Similarly, for type FILE_MODE, be prepared for the added
literal APPEND_FILE.
------------------------------------------------------------------------------
| |
| |
| if ASCII.DEL = CHARACTER'LAST then -- (1) |
| -- always true in Ada 83 (until recently -- see explanation)|
| -- always false in Ada 9X |
| |
| case CHAR is -- (2) |
| -- illegal in Ada 9X, since not all choices are covered |
| when CHARACTER'VAL(0) .. CHARACTER'VAL(63) => ...; |
| when CHARACTER'VAL(64) .. CHARACTER'VAL(127) => ...; |
| end case; |
| |
| subtype ASCII_CHARACTER is CHARACTER |
| range ASCII.NUL ... ASCII.DEL; -- (3) |
| |
| case ASCII_CHARACTER'(CHAR) is -- (4) |
| -- legal in both Ada 83 and Ada 9X |
| when CHARACTER'VAL(0) .. CHARACTER'VAL(63) => ...; |
| when CHARACTER'VAL(64) .. CHARACTER'VAL(127) => ...; |
| end case; |
| |
| case CHAR is -- (5) |
| -- legal in both Ada 83 and Ada 9X |
| when CHARACTER'VAL(0) .. CHARACTER'VAL(63) => ...; |
| when CHARACTER'VAL(64) .. CHARACTER'VAL(127) => ...; |
| when others => ... ; -- Ada 9X alternative |
| end case; |
| |
| type GOOD_CHAR_TABLE is array(CHARACTER) of INTEGER; |
| type BAD_CHAR_TABLE is array(0..127) of INTEGER; |
| GOOD_TT: GOOD_CHAR_TABLE; |
| BAD_TT: BAD_CHAR_TABLE; |
| |
| for CHR in GOOD_TT'RANGE loop |
| GOOD_TT(CHR) := ....; -- (6) |
| end loop; |
| |
| for CHR in CHARACTER'FIRST .. CHARACTER'LAST loop |
| BAD_TT(CHARACTER'POS(CHR)) := ....; -- (7) |
| end loop; |
| |
| |
| Figure 2: Examples of Character Set (In)compatibilities |
| |
------------------------------------------------------------------------------
These changes have two major consequences:
- The 'LAST attribute applied to type CHARACTER (or any of its
derived types) will yield a value with an encoding of 255 rather
than 127. See the example (1) in Figure 2. Similarly,
FILE_MODE'LAST will now yield APPEND_FILE. Whether this impacts
an algorithm, depends entirely on the programmer's assumptions.
If the assumption was to obtain truly the last character in the
enumeration, regardless of its encoding, the code will still
operate as intended. If the specific value is important, the
explicit literal (or a declared constant) should be used in lieu
of the attribute. An analogous reasoning applies to the 'RANGE
attribute applied to arrays with such index types or to any
implicit assumptions about the magnitude of the enumeration.
Examples (6) and (7) in Figure 2 show how Ada 83 code will (not)
be upward compatible. The loop (7) will result in a
CONSTRAINT_ERROR in Ada 9X, besides being poor style in Ada 83.
- Case statements over expressions of such types need to account for
the possible choices added by Ada 9X. Otherwise the statements
will be illegal in Ada 9X. Since a superfluous others or an empty
range choice is legal in Ada, case statements, whose choices do
not already cover all values permitted by Ada 9X should be written
with such an added choice. Alternatively, one can also qualify
the case expression with a static subtype, reflecting the Ada 83
range of types CHARACTER and FILE_MODE, respectively. Examples
(2) through (5) in Figure 2 illustrate the situation. The choice
of solution will depend on the circumstances. If the algorithm is
guaranteed to be applied only to the first 128 characters,
qualified expressions should be used, as shown by example (4).
Otherwise, the modification of example (5) should be applied after
giving thought to programming the Ada 9X branch of the case
statement. An addition of the form
when others => null;
is almost certainly the wrong solution.
ISO/IEC JTC1/SC22 WG9, the group chartered to issue interpretations of the
existing Ada standard, has recently voted to permit this definitional change
of type CHARACTER in Ada 83 implementations. Consequently, this problem could
already arise with the next release of an Ada 83 compiler, rather than with an
Ada 9X compiler, when the change becomes mandatory.
For existing programs, the necessary changes are somewhat problematic, since
they are not easily found by syntactic searches, nor is it easy to determine
whether or not the intent of the algorithms is affected by the language
change.
Fortunately, for the large class of programs that are intended and guaranteed
to deal only with the ASCII character set even after Ada 9X has been adopted,
there is a very simple guideline that prevents the incompatibility. Rather
than using the type CHARACTER, such programs should define a subtype of
CHARACTER, as shown in example (3) of figure 2, and consistently use this
subtype in lieu of type CHARACTER. In Ada 83, this subtype encompasses all
values of type CHARACTER; in Ada 9X, it will ensure the constraint to the
ASCII characters. None of the above compatibility problems arise. Similarly,
for existing such programs, a global substitution of CHARACTER by the subtype
name and the addition of suitable context-clauses to make the subtype name
visible renders the programs upward compatible with Ada 9X.
For type FILE_MODE, an analogous approach is complicated by the fact that
multiple instantiations of SEQUENTIAL_IO yield different such types. It is
probably easier to correct the few places in the code, where the expansion of
the enumeration type makes any difference.
Guideline 6:
Do not use accuracy constraints in subtype declarations.
Accuracy constraints in subtype declarations will be removed from the
language. It is surmised that all existing Ada implementations simply ignore
such subtype constraints, computing and storing results in the accuracy of the
respective type, anyhow.
In existing programs, such accuracy constraints should be removed. They can
be found via editor scripts or syntactic searches. In an example adapted from
the Ada Reference Manual [4],
type VOLT is delta 0.125 range 0.0 .. 255.0;
subtype ROUGH_VOLTAGE is VOLT delta 1.0 range 0.0 .. 100.0;
should be replaced with
type VOLT is delta 0.125 range 0.0 .. 255.0;
subtype ROUGH_VOLTAGE is VOLT range 0.0 .. 100.0;
Guideline 7:
Put representation clauses for real types immediately after the type
declaration.
Ada 9X solves an obscure problem in Ada 83 by mandating that such
representation clauses be given before any subtypes or derived types of the
given type are declared.
In existing programs, once the situation is identified, the correction is very
simple: merely move the representation clause to precede the subtype or
derived type declarations.
Guideline 8:
All library unit packages must have bodies, even if such bodies are empty.
Ada 83 allows the omission of packages bodies if none is needed to complete
the specification. A usage problem results, since library unit bodies that
are semantically optional, but vital to the functioning of the program, are
omitted from executables, when they happen to be obsolete. Ada 9X mandates
the existence of previously optional bodies for library units to eliminate
this usage problem. Users should therefore add such empty bodies, e.g.,
package body <name> is end <name>;
in the source files after the package specification.
For existing programs, simple Ada library queries provide the necessary
information to produce these bodies.
Guideline 9:
Do not derive from a type declared in the same package. Or, if you do, derive
the new types before redefining any predefined operations on the parent type.
------------------------------------------------------------------------------
| |
| |
| package DERIVATIONS is |
| |
| type BYTE is array (0..7) of BOOLEAN; |
| function "and"(L,R: BYTE) return BYTE; |
| -- redefine "and" for whatever reason |
| |
| type CHAR is new BYTE; |
| -- in Ada 83, this type inherits the predefined "and" |
| -- in Ada 9X, this type inherits the redefined "and" of Byte |
| |
| end DERIVATIONS; |
| |
| |
| Figure 3: Inheritance of Operations for Derived Types |
| |
| |
------------------------------------------------------------------------------
In Ada 83, subprograms become derivable only at the end of the visible part of
the package in which the type is declared. In Ada 9X, they are immediately
derivable. As shown in Figure 3, a sequence of declarations, interspersing
redefinitions of pre-defined operations with derived type declarations yields
different definitions of these operations for the derived type. The guideline
avoids this situation, which has surprised many first-time Ada users. (Note
that deriving from a derived type in the same package is already illegal in
Ada 83. The situation therefore arises only if the parent type is declared by
means of a type definition.)
In existing programs, these situations can best be identified by searching for
redefinitions of pre-defined operations, which should be relatively rare, and
inspecting the context of these redefinitions for subsequent derived type
declarations. If such situations are found, a simple reordering of the
declarations makes the programs upward compatible.
Guideline 10:
Add a distinctive comment to all generic formal private types that can be
legally instantiated with unconstrained types.
In Ada 83, the instantiation of a generic with an unconstrained type can be
illegal, depending on the use of the type in the generic unit, e.g., in an
object declaration. In Ada 9X, this instantiation will always be illegal,
unless the formal type is identified as one that can be instantiated with an
unconstrained type (in which case, the instantiation will always be legal, and
the generic must not contain conflicting uses of the type). Ada 9X uses the
box notation for this purpose. See Figure 4 for an example. The legality of
the instantiation (1) will depend on the use of type X in the body of
'Ada_83'.
This is the single instance, where Ada 83 code cannot be written to be upward
compatible with Ada 9X. Consequently, we recommend the use of a distinctive
comment convention, as shown at the beginning of the example, so that, upon
transition to Ada 9X, the necessary source changes are easily located and
made.
------------------------------------------------------------------------------
| |
| |
| generic |
| type X is private; --Ada 9X: add (<>) |
| procedure Ada_83; |
| |
| type SHORT_STRING is new STRING(1..8); |
| |
| procedure GOOD_ONE is new Ada_83(SHORT_STRING); |
| |
| procedure DUBIOUS_ONE is new Ada_83(STRING); |
| -- may be illegal in Ada 83, depending on generic body in Ada_83 |
| -- will always be illegal in Ada 9X |
| |
| generic |
| type X(<>) is private; -- Ada 9X notation; illegal in Ada 83 |
| procedure Ada_9X; |
| |
| procedure BETTER_ONE is new Ada_9X(STRING); -- always legal |
| |
| |
| Figure 4: Instantiations with Unconstrained Types |
| |
| |
------------------------------------------------------------------------------
For existing programs, there is a mechanical method of establishing whether or
not such a comment should be added: Identify all generic units with formal
private types and instantiate them with unconstrained types. All such
instantiations not rejected by the Ada 83 compilation system (possibly at link
time) are candidates to be commented as indicated.
Guideline 11:
Do not assume "too much" about the state of the computation when exceptions
are implicitly raised. Do not cause implicit exceptions knowingly. Be
prepared for the elimination of the exception NUMERIC_ERROR.
Software engineers generally agree that knowingly utilizing implicitly raised
exceptions as a control flow mechanism is a highly dubious practice. The
interpretation of Ada 83 regarding the execution order in the presence of
implicitly raised exceptions is far from clear. Efficient support of RISC,
pipe-lined, super-scalar, and massively parallel architectures makes it
necessary to deviate from a purely sequential execution model. Ada 9X is
likely to better codify permission for such support by compilers.
Consequently, users should not rely in their algorithms on the specific point
in the sequential execution order where an implicit exception may get raised.
A good, although over-conservative, guideline is to assume that, in any
exception frame, the raising of implicit exceptions may occur as early as the
beginning of the frame or as late as the end of the frame, regardless of where
the exception occurs in the sequential execution order.
This guideline applies already to Ada 83 code, regardless of Ada 9X. Yet, it
will avoid additional surprises when upgrading the code to Ada 9X.
In some situations, where Ada 83 mandates the raising of CONSTRAINT_ERROR, the
semantics of Ada 9X will cause the "expected" result, rather than an
exception. Since all these (three) cases are at the fringes of the language
usage, and since programmers should not cause CONSTRAINT_ERROR intentionally,
they are not worth a guideline.
Ada 9X is very likely to eliminate the exception NUMERIC_ERROR from the
language definition. An official Ada 83 interpretation advises non-bindingly
that Ada 83 implementations should use CONSTRAINT_ERROR instead of
NUMERIC_ERROR. Users whose compilers already adhere to this interpretation,
should cease to reference NUMERIC_ERROR. In existing programs, the name
should be deleted from exception choices or replaced by CONSTRAINT_ERROR, as
appropriate. For users, whose Ada 83 compilers do not adhere to this
non-binding interpretation, the situation is more difficult. It would be best
to apply the above source modification at the time of transition to Ada 9X.
(There is an upward compatible alternative described in [1], involving the
introduction of a superfluous user-defined NUMERIC_ERROR exception in a
separate package to be imported into all contexts that reference
NUMERIC_ERROR. However, we hesitate to recommend this approach, since it
certainly is confusing to the reader of the program.)
Guideline 12 (Numerics):
Be prepared for attribute values of real types to more closely reflect the
actual type representation. Be aware that accuracy requirements for
operations combining fixed-point types with differently based 'SMALL may be
lessened.
For the casual user of real types, these language changes are most unlikely to
have any impact. In particular, users of the predefined floating-point types
should have no problems in upgrading to Ada 9X. For numeric applications that
parameterize algorithms by means of real type attributes, however, the changes
to attribute values may have some effect, albeit a positive one, since such
applications are presumably interested in more accurate attribute values.
(For example, it is proposed that the attribute 'SMALL return the actual
smallest representation increment, rather than the increment between model
numbers.) Such code is typically written by numerical analysts, who as a
group have requested these changes to be made to Ada 83. The reduced accuracy
requirements for operations combining fixed-point types with differently based
scales is unlikely to have any significant impact, because such operations are
exceedingly rare. Also, many Ada 83 compilers support only binary and decimal
'SMALLs, thereby making it rather unlikely that existing code applies such
operations and rely on the accuracy required in Ada 83.
4. Summary
Most of the incompatibilities and guidelines arise from language changes
proposed to correct Ada 83 problems. Some of the incompatibilities are so
specialized that the probability of encountering them is minimal. To many
users, the primary practical incompatibility will be the mandatory presence of
library unit bodies.
The given guidelines address virtually all of the known incompatibilities,
thus providing for Ada 9X compatible Ada 83 code. Only the incompatibility
discussed by Guideline 10 (generics instantiated with unconstrained types)
and, depending on the Ada 83 compiler implementation, the disappearance of the
exception NUMERIC_ERROR cannot be addressed in today's Ada 83 code.
For most incompatibilities, locating their occurrence can be largely automated
and the corrections needed are straightforward. Only the incompatibility
avoided by Guideline 5 does not fit this description; yet it is a necessary
consequence of allowing for 8-bit character representations and the capability
to append to files. Still, there is a simple guideline to ensure
compatibility for all those programs that will be exposed only to ASCII
character input.
Finally we advice that users intending to upgrade to Ada 9X should obtain
early releases of Ada 9X compilers (e.g., the freely available GNU-Ada
implementation, to be released in late 1993) to check their Ada 83 code for
upward compatibility problems.
Acknowledgements
The incompatibilities addressed by the presented guidelines were originally
identified and documented by the Ada 9X Mapping Team at Intermetrics. Many of
the guidelines are but an update and repackaging of information contained in
the original publication [1]. I appreciate the comments from several
reviewers of an earlier draft of this paper, in particular Bryce Bardin, Bob
Duff, Art Evans, and Philippe Kruchten, who helped to improve the guidelines
and the presentation.
Bibliography
[1] Ada 9X Mapping Document, Volume I, Mapping Rationale, Version 4.1., Office
of the Under Secretary of Defense for Acquisition, US Department of Defense,
March 1992.
[2] Ada 9X Mapping Document, Volume II, Mapping Specification, Version 4.0.,
Office of the Under Secretary of Defense for Acquisition, US Department of
Defense, December 1991.
[3] Ada 9X Mapping Document, Volume II, Mapping Specification, Annexes,
Version 4.0., Office of the Under Secretary of Defense for Acquisition, US
Department of Defense, March 1992.
[4] Reference Manual for the Ada Programming Language,
ANSI/MIL-STD-1815A-1983, US Department of Defense, February 17, 1983.
**********************
Reprinted with permission.
Ada Information Clearinghouse (AdaIC)
P.O. Box 46593
Washington, DC 20050-6593
703/685-1477, 800/AdaIC-11, FAX 703/685-7019
adainfo@ajpo.sei.cmu.edu; CompuServe 70312,3303
The AdaIC is sponsored by the Ada Joint Program Office and operated by IIT
Research Institute.
