=====================================================================
INTERNATIONAL STANDARD ISO/IEC 8652:2012(E)
with Cor 1:2016
=====================================================================
Information technology - Programming
Languages - Ada
1 General
2.a/4 Discussion: This Annotated Ada Reference Manual (AARM) contains
the entire text of the third edition of the Ada Reference Manual
as updated by Technical Corrigendum 1 (the Ada 2012 RM), plus
certain annotations. The annotations give a more in-depth analysis
of the language. They describe the reason for each nonobvious
rule, and point out interesting ramifications of the rules and
interactions among the rules (interesting to language lawyers,
that is). Differences between Ada 83, Ada 95, Ada 2005, and Ada
2012 are listed. (The text you are reading now is an annotation.)
2.b/3 The AARM stresses detailed correctness and uniformity over
readability and understandability. We're not trying to make the
language "appear" simple here; on the contrary, we're trying to
expose hidden complexities, so we can more easily detect language
bugs. The Ada 2012 RM, on the other hand, is intended to be a more
readable document for programmers.
2.c The annotations in the AARM are as follows:
2.d/3 * Text that is logically redundant is shown [in square brackets,
like this]. Technically, such text could be written as a
Note in the Ada 2012 RM (and the Ada 95 and 2005 RMs before
it), since it is really a theorem that can be proven from the
nonredundant rules of the language. We use the square brackets
instead when it seems to make the Ada 2012 RM more readable.
2.e * The rules of the language (and some AARM-only text) are
categorized, and placed under certain sub-headings that
indicate the category. For example, the distinction between
Name Resolution Rules and Legality Rules is particularly
important, as explained in 8.6.
2.f * Text under the following sub-headings appears in both
documents:
2.g * The unlabeled text at the beginning of each clause or
subclause,
2.h * Syntax,
2.i * Name Resolution Rules,
2.j * Legality Rules,
2.k * Static Semantics,
2.l * Post-Compilation Rules,
2.m * Dynamic Semantics,
2.n * Bounded (Run-Time) Errors,
2.o * Erroneous Execution,
2.p * Implementation Requirements,
2.q * Documentation Requirements,
2.r * Metrics,
2.s * Implementation Permissions,
2.t * Implementation Advice,
2.u * NOTES,
2.v * Examples.
2.w/3 * Text under the following sub-headings does not appear in the
Ada 2012 RM:
2.x * Language Design Principles,
2.y * Inconsistencies With Ada 83,
2.z * Incompatibilities With Ada 83,
2.aa * Extensions to Ada 83,
2.bb/2 * Wording Changes from Ada 83,
2.bb.1/2 * Inconsistencies With Ada 95,
2.bb.2/2 * Incompatibilities With Ada 95,
2.bb.3/2 * Extensions to Ada 95,
2.bb.4/3 * Wording Changes from Ada 95,
2.bb.5/3 * Inconsistencies With Ada 2005,
2.bb.6/3 * Incompatibilities With Ada 2005,
2.bb.7/3 * Extensions to Ada 2005,
2.bb.8/3 * Wording Changes from Ada 2005.
2.bb.9/4 * Inconsistencies With Ada 2012,
2.bb.10/4 * Incompatibilities With Ada 2012,
2.bb.11/4 * Extensions to Ada 2012,
2.bb.12/4 * Wording Changes from Ada 2012.
2.cc * The AARM also includes the following kinds of annotations.
These do not necessarily annotate the immediately preceding
rule, although they often do.
2.dd Reason: An explanation of why a certain rule is necessary, or why
it is worded in a certain way.
2.ee Ramification: An obscure ramification of the rules that is of
interest only to language lawyers. (If a ramification of the rules
is of interest to programmers, then it appears under NOTES.)
2.ff Proof: An informal proof explaining how a given Note or
[marked-as-redundant] piece of text follows from the other rules
of the language.
2.gg Implementation Note: A hint about how to implement a feature, or a
particular potential pitfall that an implementer needs to be aware
of.
2.hh Change: Change annotations are not used in this version. Changes
from previous versions have been removed. Changes in this version
are marked with versioned paragraph numbers, as explained in the
"Corrigendum Changes" clause of the "Introduction".
2.ii Discussion: Other annotations not covered by the above.
2.jj To be honest: A rule that is considered logically necessary to the
definition of the language, but which is so obscure or pedantic
that only a language lawyer would care. These are the only
annotations that could be considered part of the language
definition.
2.kk Glossary entry: The text of a Glossary entry - this text will also
appear in Annex N, "Glossary".
2.ll/3 Discussion: In general, the Ada 2012 RM text appears in the normal
font, whereas AARM-only text appears in a smaller font. Notes also
appear in the smaller font, as recommended by ISO/IEC style
guidelines. Ada examples are also usually printed in a smaller
font.
2.mm If you have trouble finding things, be sure to use the index. Each
defined term appears there, and also in italics, like this.
Syntactic categories defined in BNF are also indexed.
2.nn A definition marked "[distributed]" is the main definition for a
term whose complete definition is given in pieces distributed
throughout the document. The pieces are marked "[partial]" or with
a phrase explaining what cases the partial definition applies to.
1.1 Scope
1/3 {AI05-0299-1} This International Standard specifies the form and meaning
of programs written in Ada. Its purpose is to promote the portability of Ada
programs to a variety of computing systems.
2/3 {AI05-0299-1} Ada is a programming language designed to support the
construction of long-lived, highly reliable software systems. The language
includes facilities to define packages of related types, objects, and
operations. The packages may be parameterized and the types may be extended to
support the construction of libraries of reusable, adaptable software
components. The operations may be implemented as subprograms using
conventional sequential control structures, or as entries that include
synchronization of concurrent threads of control as part of their invocation.
Ada supports object-oriented programming by providing classes and interfaces,
inheritance, polymorphism of variables and methods, and generic units. The
language treats modularity in the physical sense as well, with a facility to
support separate compilation.
3/4 {AI05-0269-1} {AI05-0299-1} {AI12-0056-1} The language provides rich
support for real-time, concurrent programming, and includes facilities for
multicore and multiprocessor programming. Errors can be signaled as exceptions
and handled explicitly. The language also covers systems programming; this
requires precise control over the representation of data and access to
system-dependent properties. Finally, a predefined environment of standard
packages is provided, including facilities for, among others, input-output,
string manipulation, numeric elementary functions, random number generation,
and definition and use of containers.
1.1.1 Extent
1 This International Standard specifies:
2 * The form of a program written in Ada;
3 * The effect of translating and executing such a program;
4 * The manner in which program units may be combined to form Ada programs;
5 * The language-defined library units that a conforming implementation is
required to supply;
6 * The permissible variations within the standard, and the manner in
which they are to be documented;
7 * Those violations of the standard that a conforming implementation is
required to detect, and the effect of attempting to translate or
execute a program containing such violations;
8 * Those violations of the standard that a conforming implementation is
not required to detect.
9 This International Standard does not specify:
10 * The means whereby a program written in Ada is transformed into object
code executable by a processor;
11 * The means whereby translation or execution of programs is invoked and
the executing units are controlled;
12 * The size or speed of the object code, or the relative execution speed
of different language constructs;
13 * The form or contents of any listings produced by implementations; in
particular, the form or contents of error or warning messages;
14 * The effect of unspecified execution.
15 * The size of a program or program unit that will exceed the capacity of
a particular conforming implementation.
1.1.2 Structure
1/3 {AI05-0299-1} This International Standard contains thirteen clauses,
fifteen annexes, and an index.
1.a/3 Discussion: {AI05-0299-1} What Ada 83 called a "chapter" and Ada
95 (and Ada 2005) called a "section" is called a "clause" in this
Standard. Similarly, what Ada 83 called a "section" and Ada 95
(and Ada 2005) called a "clause" is called a "subclause" in this
Standard. Confused yet? This terminology is out of our hands; it
is (and was) forced by ever-changing ISO rules for drafting
Standards.
2 The core of the Ada language consists of:
3/3 * {AI05-0299-1} Clauses 1 through 13
4 * Annex A, "Predefined Language Environment"
5 * Annex B, "Interface to Other Languages"
6 * Annex J, "Obsolescent Features"
7 The following Specialized Needs Annexes define features that are needed by
certain application areas:
8 * Annex C, "Systems Programming"
9 * Annex D, "Real-Time Systems"
10 * Annex E, "Distributed Systems"
11 * Annex F, "Information Systems"
12 * Annex G, "Numerics"
13 * Annex H, "High Integrity Systems"
14 The core language and the Specialized Needs Annexes are normative, except
that the material in each of the items listed below is informative:
15 * Text under a NOTES or Examples heading.
16/3 * {AI05-0299-1} Each subclause whose title starts with the word "
Example" or "Examples".
17 All implementations shall conform to the core language. In addition, an
implementation may conform separately to one or more Specialized Needs Annexes.
18 The following Annexes are informative:
19 * Annex K, "Language-Defined Aspects and Attributes"
20 * Annex L, "Language-Defined Pragmas"
21/3 * {AI05-0004-1} Annex M, "Summary of Documentation Requirements"
22 * Annex N, "Glossary"
23 * Annex P, "Syntax Summary"
23.1/3 * {AI05-0262-1} Annex Q, "Language-Defined Entities"
23.a Discussion: The idea of the Specialized Needs Annexes is that
implementations can choose to target certain application areas.
For example, an implementation specifically targeted to embedded
machines might support the application-specific features for
Real-time Systems, but not the application-specific features for
Information Systems.
23.b The Specialized Needs Annexes extend the core language only in
ways that users, implementations, and standards bodies are allowed
to extend the language; for example, via additional library units,
attributes, representation items (see 13.1), pragmas, and
constraints on semantic details that are left unspecified by the
core language. Many implementations already provide much of the
functionality defined by Specialized Needs Annexes; our goal is to
increase uniformity among implementations by defining standard
ways of providing the functionality.
23.c/2 {AI95-00114-01} We recommend that the certification procedures
allow implementations to certify the core language, plus any set
of the Specialized Needs Annexes. We recommend that
implementations not be allowed to certify a portion of one of the
Specialized Needs Annexes, although implementations can, of
course, provide uncertified support for such portions. We have
designed the Specialized Needs Annexes assuming that this
recommendation is followed. Thus, our decisions about what to
include and what not to include in those annexes are based on the
assumption that each annex is certified in an "all-or-nothing"
manner.
23.d An implementation may, of course, support extensions that are
different from (but possibly related to) those defined by one of
the Specialized Needs Annexes. We recommend that, where
appropriate, implementations do this by adding library units that
are children of existing language-defined library packages.
23.e An implementation should not provide extensions that conflict with
those defined in the Specialized Needs Annexes, in the following
sense: Suppose an implementation supports a certain error-free
program that uses only functionality defined in the core and in
the Specialized Needs Annexes. The implementation should ensure
that that program will still be error free in some possible full
implementation of all of the Specialized Needs Annexes, and that
the semantics of the program will not change. For example, an
implementation should not provide a package with the same name as
one defined in one of the Specialized Needs Annexes, but that
behaves differently, even if that implementation does not claim
conformance to that Annex.
23.f Note that the Specialized Needs Annexes do not conflict with each
other; it is the intent that a single implementation can conform
to all of them.
24/4 {AI05-0299-1} {AI12-0056-1} Each clause is divided into subclauses that
have a common structure. Each clause and subclause first introduces its
subject. After the introductory text, text is labeled with the following
headings:
Language Design Principles
24.a These are not rules of the language, but guiding principles or
goals used in defining the rules of the language. In some cases,
the goal is only partially met; such cases are explained.
24.b/3 {AI05-0005-1} This is not part of the definition of the language,
and does not appear in the Ada 2012 RM.
Syntax
25 Syntax rules (indented).
Name Resolution Rules
26/3 {AI05-0299-1} Compile-time rules that are used in name resolution,
including overload resolution.
26.a Discussion: These rules are observed at compile time. (We say "
observed" rather than "checked," because these rules are not
individually checked. They are really just part of the
Legality Rules in Clause 8 that require exactly one interpretation
of each constituent of a complete context.) The only rules used in
overload resolution are the Syntax Rules and the
Name Resolution Rules.
26.b When dealing with nonoverloadable declarations it sometimes makes
no semantic difference whether a given rule is a
Name Resolution Rule or a Legality Rule, and it is sometimes
difficult to decide which it should be. We generally make a given
rule a Name Resolution Rule only if it has to be. For example, "
The name, if any, in a raise_statement shall be the name of an
exception." is under "Legality Rules."
Legality Rules
27 Rules that are enforced at compile time. A construct is legal if it obeys
all of the Legality Rules.
27.a Discussion: These rules are not used in overload resolution.
27.b Note that run-time errors are always attached to exceptions; for
example, it is not "illegal" to divide by zero, it just raises an
exception.
Static Semantics
28 A definition of the compile-time effect of each construct.
28.a Discussion: The most important compile-time effects represent the
effects on the symbol table associated with declarations (implicit
or explicit). In addition, we use this heading as a bit of a grab
bag for equivalences, package specifications, etc. For example,
this is where we put statements like so-and-so is equivalent to
such-and-such. (We ought to try to really mean it when we say such
things!) Similarly, statements about magically-generated implicit
declarations go here. These rules are generally written as
statements of fact about the semantics, rather than as a
you-shall-do-such-and-such sort of thing.
Post-Compilation Rules
29 Rules that are enforced before running a partition. A partition is legal
if its compilation units are legal and it obeys all of the
Post-Compilation Rules.
29.a Discussion: It is not specified exactly when these rules are
checked, so long as they are checked for any given partition
before that partition starts running. An implementation may choose
to check some such rules at compile time, and reject
compilation_units accordingly. Alternatively, an implementation
may check such rules when the partition is created (usually known
as "link time"), or when the partition is mapped to a particular
piece of hardware (but before the partition starts running).
Dynamic Semantics
30 A definition of the run-time effect of each construct.
30.a Discussion: This heading describes what happens at run time.
Run-time checks, which raise exceptions upon failure, are
described here. Each item that involves a run-time check is marked
with the name of the check - these are the same check names that
are used in a pragma Suppress. Principle: Every check should have
a name, usable in a pragma Suppress.
Bounded (Run-Time) Errors
31 Situations that result in bounded (run-time) errors (see 1.1.5).
31.a Discussion: The "bounds" of each such error are described here -
that is, we characterize the set of all possible behaviors that
can result from a bounded error occurring at run time.
Erroneous Execution
32 Situations that result in erroneous execution (see 1.1.5).
Implementation Requirements
33 Additional requirements for conforming implementations.
33.a Discussion: ...as opposed to rules imposed on the programmer. An
example might be, "The smallest representable duration,
Duration'Small, shall not be greater than twenty milliseconds."
33.b It's really just an issue of how the rule is worded. We could
write the same rule as "The smallest representable duration is an
implementation-defined value less than or equal to 20
milliseconds" and then it would be under "Static Semantics."
Documentation Requirements
34 Documentation requirements for conforming implementations.
34.a Discussion: These requirements are beyond those that are
implicitly specified by the phrase "implementation defined". The
latter require documentation as well, but we don't repeat these
cases under this heading. Usually this heading is used for when
the description of the documentation requirement is longer and
does not correspond directly to one, narrow normative sentence.
Metrics
35 Metrics that are specified for the time/space properties of the execution
of certain language constructs.
Implementation Permissions
36 Additional permissions given to the implementer.
36.a Discussion: For example, "The implementation is allowed to impose
further restrictions on the record aggregates allowed in code
statements." When there are restrictions on the permission, those
restrictions are given here also. For example, "An implementation
is allowed to restrict the kinds of subprograms that are allowed
to be main subprograms. However, it shall support at least
parameterless procedures." - we don't split this up between here
and "Implementation Requirements."
Implementation Advice
37 Optional advice given to the implementer. The word "should" is used to
indicate that the advice is a recommendation, not a requirement. It is
implementation defined whether or not a given recommendation is obeyed.
37.a/2 Implementation defined: Whether or not each recommendation given
in Implementation Advice is followed - see M.3, "
Implementation Advice" for a listing.
37.b/1 Discussion: The advice generally shows the intended
implementation, but the implementer is free to ignore it. The
implementer is the sole arbiter of whether or not the advice has
been obeyed, if not, whether the reason is a good one, and whether
the required documentation is sufficient. It would be wrong for
the ACATS to enforce any of this advice.
37.c For example, "Whenever possible, the implementation should choose
a value no greater than fifty microseconds for the smallest
representable duration, Duration'Small."
37.d We use this heading, for example, when the rule is so low level or
implementation-oriented as to be untestable. We also use this
heading when we wish to encourage implementations to behave in a
certain way in most cases, but we do not wish to burden
implementations by requiring the behavior.
NOTES
38 1 Notes emphasize consequences of the rules described in the
(sub)clause or elsewhere. This material is informative.
Examples
39 Examples illustrate the possible forms of the constructs described. This
material is informative.
39.a Discussion:
The next three headings list all language changes between Ada 83
and Ada 95. Language changes are any change that changes the set
of text strings that are legal Ada programs, or changes the
meaning of any legal program. Wording changes, such as changes in
terminology, are not language changes. Each language change falls
into one of the following three categories:
Inconsistencies With Ada 83
39.b This heading lists all of the upward inconsistencies between Ada
83 and Ada 95. Upward inconsistencies are situations in which a
legal Ada 83 program is a legal Ada 95 program with different
semantics. This type of upward incompatibility is the worst type
for users, so we only tolerate it in rare situations.
39.c (Note that the semantics of a program is not the same thing as the
behavior of the program. Because of Ada's indeterminacy, the "
semantics" of a given feature describes a set of behaviors that
can be exhibited by that feature. The set can contain more than
one allowed behavior. Thus, when we ask whether the semantics
changes, we are asking whether the set of behaviors changes.)
39.d/4 This is not part of the definition of the language, and does not
appear in the Ada 95, Ada 2005, or Ada 2012 RM.
Incompatibilities With Ada 83
39.e This heading lists all of the upward incompatibilities between Ada
83 and Ada 95, except for the ones listed under "
Inconsistencies With Ada 83" above. These are the situations in
which a legal Ada 83 program is illegal in Ada 95. We do not
generally consider a change that turns erroneous execution into an
exception, or into an illegality, to be upwardly incompatible.
39.f/4 This is not part of the definition of the language, and does not
appear in the Ada 95, Ada 2005, or Ada 2012 RM.
Extensions to Ada 83
39.g This heading is used to list all upward compatible language
changes; that is, language extensions. These are the situations in
which a legal Ada 95 program is not a legal Ada 83 program. The
vast majority of language changes fall into this category.
39.h/4 This is not part of the definition of the language, and does not
appear in the Ada 95, Ada 2005, or Ada 2012 RM.
39.i
As explained above, the next heading does not represent any
language change:
Wording Changes from Ada 83
39.j/2 This heading lists some of the nonsemantic changes between the Ada
83 RM and the Ada 95 RM. It is incomplete; we have not attempted
to list all wording changes, but only the "interesting" ones.
39.k/4 This is not part of the definition of the language, and does not
appear in the Ada 95, Ada 2005, or Ada 2012 RM.
39.l/2 Discussion:
The next three headings list all language changes between Ada 95
and Ada 2005 (the language defined by the Ada 95 standard plus
Technical Corrigendum 1 plus Amendment 1). Each language change
falls into one of the following three categories:
Inconsistencies With Ada 95
39.m/2 This heading lists all of the upward inconsistencies between Ada
95 and Ada 2005. Upward inconsistencies are situations in which a
legal Ada 95 program is a legal Ada 2005 program with different
semantics.
39.n/3 {AI05-0005-1} Inconsistencies marked with Corrigendum: are
corrections to the original Ada 95 definition introduced by
Corrigendum 1. Inconsistencies marked with Amendment Correction:
are corrections to the original Ada 95 definition added by
Amendment 1. Formally, these are inconsistencies caused by Ada
Issues classified as Binding Interpretations; implementations of
Ada 95 are supposed to follow these corrections, not the original
flawed language definition. Thus, these strictly speaking are not
inconsistencies between Ada 95 and Ada 2005. Practically, however,
they very well may be, as early Ada 95 implementations might not
follow the recommendation. Inconsistencies so marked are not
portable between Ada 95 implementations, while usually Ada 2005
will have more clearly defined behavior. Therefore, we document
these for completeness.
39.o/4 This is not part of the definition of the language, and does not
appear in the Ada 2005 or Ada 2012 RM.
Incompatibilities With Ada 95
39.p/2 This heading lists all of the upward incompatibilities between Ada
95 and Ada 2005, except for the ones listed under "
Inconsistencies With Ada 95" above. These are the situations in
which a legal Ada 95 program is illegal in Ada 2005.
39.q/3 {AI05-0005-1} As with inconsistencies, incompatibilities marked
with Corrigendum: are corrections to the original Ada 95
definition introduced by Corrigendum 1. Incompatibilities marked
with Amendment Correction: are corrections to the original Ada 95
definition added by Amendment 1. Formally, these are
incompatibilities caused by Ada Issues classified as Binding
Interpretations; implementations of Ada 95 are supposed to follow
these corrections, not the original flawed language definition.
Thus, these strictly speaking are not incompatibilities between
Ada 95 and Ada 2005. Practically, however, they very well may be,
as early Ada 95 implementations might not follow the
recommendation. Therefore, some Ada 95 implementations may be able
to compile the examples, while others might not. In contrast, Ada
2005 compilers will have consistent behavior. Therefore, we
document these for completeness.
39.r/4 This is not part of the definition of the language, and does not
appear in the Ada 2005 or Ada 2012 RM.
Extensions to Ada 95
39.s/2 This heading is used to list all upward compatible language
changes; that is, language extensions. These are the situations in
which a legal Ada 2005 program is not a legal Ada 95 program. The
vast majority of language changes fall into this category.
39.t/3 {AI05-0005-1} As with incompatibilities, extensions marked with
Corrigendum: are corrections to the original Ada 95 definition
introduced by Corrigendum 1. Extensions marked with Amendment
Correction: are corrections to the original Ada 95 definition
added by Amendment 1. Formally, these are extensions allowed by
Ada Issues classified as Binding Interpretations. As corrections,
implementations of Ada 95 are allowed to implement these
extensions. Thus, these strictly speaking are not extensions of
Ada 95; they're part of Ada 95. Practically, however, they very
well may be extensions, as early Ada 95 implementations might not
implement the extension. Therefore, some Ada 95 implementations
may be able to compile the examples, while others might not. In
contrast, Ada 2005 compilers will always support the extensions.
Therefore, we document these for completeness.
39.u/4 This is not part of the definition of the language, and does not
appear in the Ada 2005 or Ada 2012 RM.
39.v/2
As explained above, the next heading does not represent any
language change:
Wording Changes from Ada 95
39.w/2 This heading lists some of the nonsemantic changes between the Ada
95 RM and the Ada 2005 RM. This heading lists only "
interesting" changes (for instance, editorial corrections are not listed).
Changes which come from Technical Corrigendum 1 are marked
Corrigendum; unmarked changes come from Amendment 1.
39.x/4 This is not part of the definition of the language, and does not
appear in the Ada 2005 or Ada 2012 RM.
39.y/3 Discussion:
The next three headings list all language changes between Ada 2005
(the language defined by the Ada 95 standard plus Technical
Corrigendum 1 plus Amendment 1) and Ada 2012 (the language defined
by the third edition of the Standard). Each language change falls
into one of the following three categories:
Inconsistencies With Ada 2005
39.z/3 This heading lists all of the upward inconsistencies between Ada
2005 and Ada 2012. Upward inconsistencies are situations in which
a legal Ada 2005 program is a legal Ada 2012 program with
different semantics.
39.aa/3 Inconsistencies marked with Correction: are corrections to the
original Ada 2005 definition added by the third edition of the
Standard. Formally, these are inconsistencies caused by Ada Issues
classified as Binding Interpretations; implementations of Ada 2005
are supposed to follow these corrections, not the original flawed
language definition. Thus, these strictly speaking are not
inconsistencies between Ada 2005 and Ada 2012. Practically,
however, they very well may be, as early Ada 2005 implementations
might not follow the recommendation. Inconsistencies so marked are
not portable between Ada 2005 implementations, while usually Ada
2012 will have more clearly defined behavior. Therefore, we
document these for completeness.
39.bb/4 This is not part of the definition of the language, and does not
appear in the Ada 2012 RM.
Incompatibilities With Ada 2005
39.cc/3 This heading lists all of the upward incompatibilities between Ada
2005 and Ada 2012, except for the ones listed under "
Inconsistencies With Ada 2005" above. These are the situations in
which a legal Ada 2005 program is illegal in Ada 2012.
39.dd/3 As with inconsistencies, incompatibilities marked with Correction:
are corrections to the original Ada 2005 definition added by the
third edition. Formally, these are incompatibilities caused by Ada
Issues classified as Binding Interpretations; implementations of
Ada 2005 are supposed to follow these corrections, not the
original flawed language definition. Thus, these strictly speaking
are not incompatibilities between Ada 2005 and Ada 2012.
Practically, however, they very well may be, as early Ada 2005
implementations might not follow the recommendation. Therefore,
some Ada 2005 implementations may be able to compile the examples,
while others might not. In contrast, Ada 2012 compilers will have
consistent behavior. Therefore, we document these for completeness.
39.ee/4 This is not part of the definition of the language, and does not
appear in the Ada 2012 RM.
Extensions to Ada 2005
39.ff/3 This heading is used to list all upward compatible language
changes; that is, language extensions. These are the situations in
which a legal Ada 2012 program is not a legal Ada 2005 program.
The vast majority of language changes fall into this category.
39.gg/3 As with incompatibilities, extensions marked with Correction: are
corrections to the original Ada 2005 definition added by the third
edition. Formally, these are extensions allowed by Ada Issues
classified as Binding Interpretations. As corrections,
implementations of Ada 2005 (and sometimes Ada 95) are allowed to
implement these extensions. Thus, these strictly speaking are not
extensions of Ada 2005; they're part of Ada 2005. Practically,
however, they very well may be extensions, as early Ada 2005
implementations might not implement the extension. Therefore, some
Ada 2005 implementations may be able to compile the examples,
while others might not. In contrast, Ada 2012 compilers will
always support the extensions. Therefore, we document these for
completeness.
39.hh/4 This is not part of the definition of the language, and does not
appear in the Ada 2012 RM.
39.ii/3
As explained above, the next heading does not represent any
language change:
Wording Changes from Ada 2005
39.jj/3 This heading lists some of the nonsemantic changes between the Ada
2005 RM and the Ada 2012 RM. This heading lists only "
interesting" changes (for instance, editorial corrections are not listed).
Items marked Correction: come from Ada Issues classified as
Binding Interpretations and strictly speaking belong to Ada 2005;
other items only belong to Ada 2012.
39.kk/4 This is not part of the definition of the language, and does not
appear in the Ada 2012 RM.
39.ll/4 Discussion:
The next three headings list all language changes between original
Ada 2012 (the language defined by unmodified ISO/IEC 8652:2012(E))
and current Ada 2012 (the language defined by ISO/IEC 8652:2012(E)
as corrected by the Corrigendum ISO/IEC 8652:2012/Cor 1:2016).
Each language change falls into one of the following three
categories:
Inconsistencies With Ada 2012
39.mm/4 This heading lists all of the upward inconsistencies between
original and current Ada 2012. Upward inconsistencies are
situations in which a legal original Ada 2012 program is a legal
current Ada 2012 program with different semantics.
39.nn/4 Inconsistencies marked with Corrigendum: are corrections to the
original Ada 2012 definition added by Technical Corrigendum 1 to
Ada 2012. Formally, these are inconsistencies caused by Ada Issues
classified as Binding Interpretations; implementations of Ada 2012
are supposed to follow these corrections, not the original flawed
language definition. Thus, these strictly speaking are not
inconsistencies between current and original Ada 2012.
Practically, however, they very well may be, as early Ada 2012
implementations might not follow the recommendation.
Inconsistencies so marked are not portable between Ada 2012
implementations. Therefore, we document these for completeness.
39.oo/4 This is not part of the definition of the language, and does not
appear in any version of the Ada RM.
Incompatibilities With Ada 2012
39.pp/4 This heading lists all of the upward incompatibilities between
original and current Ada 2012, except for the ones listed under
"Inconsistencies With Ada 2012" above. These are the situations in
which a legal original Ada 2012 program is illegal in current Ada
2012.
39.qq/4 As with inconsistencies, incompatibilities marked with
Corrigendum: are corrections to the original Ada 2012 definition
added by Corrigendum 1 to Ada 2012 Formally, these are
incompatibilities caused by Ada Issues classified as Binding
Interpretations; implementations of Ada 2012 are supposed to
follow these corrections, not the original flawed language
definition. Thus, these strictly speaking are not
incompatibilities between current and original Ada 2012.
Practically, however, they very well may be, as early Ada 2012
implementations might not follow the recommendation. Therefore,
some Ada 2012 implementations may be able to compile the examples,
while others might not. Therefore, we document these for
completeness.
39.rr/4 This is not part of the definition of the language, and does not
appear in any version of the Ada RM.
Extensions to Ada 2012
39.ss/4 This heading is used to list all upward compatible language
changes; that is, language extensions. These are the situations in
which a legal current Ada 2012 program is not a legal original Ada
2012 program. The vast majority of language changes fall into this
category.
39.tt/4 As with incompatibilities, extensions marked with Corrigendum: are
corrections to the original Ada 2012 definition added by
Corrigendum 1 to Ada 2012. Formally, these are extensions allowed
by Ada Issues classified as Binding Interpretations. As
corrections, implementations of Ada 2012 (and sometimes Ada 95)
are allowed to implement these extensions. Thus, these strictly
speaking are not extensions of Ada 2012; they're part of Ada 2012.
Practically, however, they very well may be extensions, as early
Ada 2012 implementations might not implement the extension.
Therefore, some Ada 2012 implementations may be able to compile
the examples, while others might not. Therefore, we document these
for completeness.
39.uu/4 This is not part of the definition of the language, and does not
appear in any version of the Ada RM.
39.vv/4
As explained above, the next heading does not represent any
language change:
Wording Changes from Ada 2012
39.ww/4 This heading lists some of the nonsemantic changes between the
original and corrected Ada 2012 RM. This heading lists only "
interesting" changes (for instance, editorial corrections are not
listed). Items marked Corrigendum: are included in Corrigendum 1
to Ada 2012. These items come from Ada Issues classified as
Binding Interpretations and strictly speaking belong to Ada 2012.
39.xx/4 This is not part of the definition of the language, and does not
appear in any version of the Ada RM.
1.1.3 Conformity of an Implementation with the Standard
Implementation Requirements
1 A conforming implementation shall:
1.a Discussion: The implementation is the software and hardware that
implements the language. This includes compiler, linker, operating
system, hardware, etc.
1.b We first define what it means to "conform" in general - basically,
the implementation has to properly implement the normative rules
given throughout the standard. Then we define what it means to
conform to a Specialized Needs Annex - the implementation must
support the core features plus the features of that Annex.
Finally, we define what it means to "conform to the Standard" -
this requires support for the core language, and allows partial
(but not conflicting) support for the Specialized Needs Annexes.
2 * Translate and correctly execute legal programs written in Ada,
provided that they are not so large as to exceed the capacity of the
implementation;
3 * Identify all programs or program units that are so large as to exceed
the capacity of the implementation (or raise an appropriate exception
at run time);
3.a Implementation defined: Capacity limitations of the implementation.
4 * Identify all programs or program units that contain errors whose
detection is required by this International Standard;
4.a Discussion: Note that we no longer use the term "rejection" of
programs or program units. We require that programs or program
units with errors or that exceed some capacity limit be "
identified". The way in which errors or capacity problems are
reported is not specified.
4.b An implementation is allowed to use standard error-recovery
techniques. We do not disallow such techniques from being used
across compilation_unit or compilation boundaries.
4.c See also the Implementation Requirements of 10.2, which disallow
the execution of illegal partitions.
5 * Supply all language-defined library units required by this
International Standard;
5.a Implementation Note: An implementation cannot add to or modify the
visible part of a language-defined library unit, except where such
permission is explicitly granted, unless such modifications are
semantically neutral with respect to the client compilation units
of the library unit. An implementation defines the contents of the
private part and body of language-defined library units.
5.b An implementation can add with_clauses and use_clauses, since
these modifications are semantically neutral to clients. (The
implementation might need with_clauses in order to implement the
private part, for example.) Similarly, an implementation can add a
private part even in cases where a private part is not shown in
the standard. Explicit declarations can be provided implicitly or
by renaming, provided the changes are semantically neutral.
5.c Wherever in the standard the text of a language-defined library
unit contains an italicized phrase starting with "
implementation-defined", the implementation's version will replace
that phrase with some implementation-defined text that is
syntactically legal at that place, and follows any other
applicable rules.
5.d Note that modifications are permitted, even if there are other
tools in the environment that can detect the changes (such as a
program library browser), so long as the modifications make no
difference with respect to the static or dynamic semantics of the
resulting programs, as defined by the standard.
6 * Contain no variations except those explicitly permitted by this
International Standard, or those that are impossible or impractical to
avoid given the implementation's execution environment;
6.a Implementation defined: Variations from the standard that are
impractical to avoid given the implementation's execution
environment.
6.b Reason: The "impossible or impractical" wording comes from AI-325.
It takes some judgement and common sense to interpret this.
Restricting compilation units to less than 4 lines is probably
unreasonable, whereas restricting them to less than 4 billion
lines is probably reasonable (at least given today's technology).
We do not know exactly where to draw the line, so we have to make
the rule vague.
7 * Specify all such variations in the manner prescribed by this
International Standard.
8 The external effect of the execution of an Ada program is defined in terms
of its interactions with its external environment. The following are defined
as external interactions:
9 * Any interaction with an external file (see A.7);
10 * The execution of certain code_statements (see 13.8); which
code_statements cause external interactions is implementation defined.
10.a Implementation defined: Which code_statements cause external
interactions.
11 * Any call on an imported subprogram (see Annex B), including any
parameters passed to it;
12 * Any result returned or exception propagated from a main subprogram
(see 10.2) or an exported subprogram (see Annex B) to an external
caller;
12.a Discussion: By "result returned" we mean to include function
results and values returned in [in] out parameters.
12.a.1/1 {8652/0094} {AI95-00119-01} The lack of a result from a program
that does not terminate is also included here.
13 * [Any read or update of an atomic or volatile object (see C.6);]
14 * The values of imported and exported objects (see Annex B) at the time
of any other interaction with the external environment.
14.a/3 To be honest: {AI05-0229-1} Also other uses of imported and
exported entities, as defined by the implementation, if the
implementation supports such importing or exporting.
15 A conforming implementation of this International Standard shall produce
for the execution of a given Ada program a set of interactions with the
external environment whose order and timing are consistent with the
definitions and requirements of this International Standard for the semantics
of the given program.
15.a Ramification: There is no need to produce any of the "internal
effects" defined for the semantics of the program - all of these
can be optimized away - so long as an appropriate sequence of
external interactions is produced.
15.b Discussion: See also 11.6 which specifies various liberties
associated with optimizations in the presence of language-defined
checks, that could change the external effects that might be
produced. These alternative external effects are still consistent
with the standard, since 11.6 is part of the standard.
15.c Note also that we only require "an appropriate sequence of
external interactions" rather than "the same sequence..." An
optimizer may cause a different sequence of external interactions
to be produced than would be produced without the optimizer, so
long as the new sequence still satisfies the requirements of the
standard. For example, optimization might affect the relative rate
of progress of two concurrent tasks, thereby altering the order in
which two external interactions occur.
15.d/2 Note that the Ada 83 RM explicitly mentions the case of an "exact
effect" of a program, but since so few programs have their effects
defined that exactly, we don't even mention this "special" case.
In particular, almost any program that uses floating point or
tasking has to have some level of inexactness in the specification
of its effects. And if one includes aspects of the timing of the
external interactions in the external effect of the program (as is
appropriate for a real-time language), no "exact effect" can be
specified. For example, if two external interactions initiated by
a single task are separated by a "delay 1.0;" then the language
rules imply that the two external interactions have to be
separated in time by at least one second, as defined by the clock
associated with the delay_relative_statement. This in turn implies
that the time at which an external interaction occurs is part of
the characterization of the external interaction, at least in some
cases, again making the specification of the required "exact
effect" impractical.
16 An implementation that conforms to this Standard shall support each
capability required by the core language as specified. In addition, an
implementation that conforms to this Standard may conform to one or more
Specialized Needs Annexes (or to none). Conformance to a Specialized Needs
Annex means that each capability required by the Annex is provided as
specified.
16.a Discussion: The last sentence defines what it means to say that an
implementation conforms to a Specialized Needs Annex, namely, only
by supporting all capabilities required by the Annex.
17/3 {AI05-0229-1} An implementation conforming to this International Standard
may provide additional aspects, attributes, library units, and pragmas.
However, it shall not provide any aspect, attribute, library unit, or pragma
having the same name as an aspect, attribute, library unit, or pragma
(respectively) specified in a Specialized Needs Annex unless the provided
construct is either as specified in the Specialized Needs Annex or is more
limited in capability than that required by the Annex. A program that attempts
to use an unsupported capability of an Annex shall either be identified by the
implementation before run time or shall raise an exception at run time.
17.a Discussion: The last sentence of the preceding paragraph defines
what an implementation is allowed to do when it does not "conform"
to a Specialized Needs Annex. In particular, the sentence forbids
implementations from providing a construct with the same name as a
corresponding construct in a Specialized Needs Annex but with a
different syntax (e.g., an extended syntax) or quite different
semantics. The phrase concerning "more limited in capability" is
intended to give permission to provide a partial implementation,
such as not implementing a subprogram in a package or having a
restriction not permitted by an implementation that conforms to
the Annex. For example, a partial implementation of the package
Ada.Decimal might have Decimal.Max_Decimal_Digits as 15 (rather
than the required 18). This allows a partial implementation to
grow to a fully conforming implementation.
17.b A restricted implementation might be restricted by not providing
some subprograms specified in one of the packages defined by an
Annex. In this case, a program that tries to use the missing
subprogram will usually fail to compile. Alternatively, the
implementation might declare the subprogram as abstract, so it
cannot be called. Alternatively, a subprogram body might be
implemented just to raise Program_Error. The advantage of this
approach is that a program to be run under a fully conforming
Annex implementation can be checked syntactically and semantically
under an implementation that only partially supports the Annex.
Finally, an implementation might provide a package declaration
without the corresponding body, so that programs can be compiled,
but partitions cannot be built and executed.
17.c To ensure against wrong answers being delivered by a partial
implementation, implementers are required to raise an exception
when a program attempts to use an unsupported capability and this
can be detected only at run time. For example, a partial
implementation of Ada.Decimal might require the length of the
Currency string to be 1, and hence, an exception would be raised
if a subprogram were called in the package Edited_Output with a
length greater than 1.
Documentation Requirements
18 Certain aspects of the semantics are defined to be either implementation
defined or unspecified. In such cases, the set of possible effects is
specified, and the implementation may choose any effect in the set.
Implementations shall document their behavior in implementation-defined
situations, but documentation is not required for unspecified situations. The
implementation-defined characteristics are summarized in M.2.
18.a Discussion: We used to use the term "implementation dependent"
instead of "unspecified". However, that sounded too much like "
implementation defined". Furthermore, the term "unspecified" is
used in the ANSI C and POSIX standards for this purpose, so that
is another advantage. We also use "not specified" and "not
specified by the language" as synonyms for "unspecified." The
documentation requirement is the only difference between
implementation defined and unspecified.
18.b Note that the "set of possible effects" can be "all imaginable
effects", as is the case with erroneous execution.
19 The implementation may choose to document implementation-defined behavior
either by documenting what happens in general, or by providing some mechanism
for the user to determine what happens in a particular case.
19.a Discussion: For example, if the standard says that library unit
elaboration order is implementation defined, the implementation
might describe (in its user's manual) the algorithm it uses to
determine the elaboration order. On the other hand, the
implementation might provide a command that produces a description
of the elaboration order for a partition upon request from the
user. It is also acceptable to provide cross references to
existing documentation (for example, a hardware manual), where
appropriate.
19.b Note that dependence of a program on implementation-defined or
unspecified functionality is not defined to be an error; it might
cause the program to be less portable, however.
19.c/2 Documentation Requirement: The behavior of implementations in
implementation-defined situations shall be documented - see M.2
, "Implementation-Defined Characteristics" for a listing.
Implementation Advice
20 If an implementation detects the use of an unsupported Specialized Needs
Annex feature at run time, it should raise Program_Error if feasible.
20.a.1/2 Implementation Advice: Program_Error should be raised when an
unsupported Specialized Needs Annex feature is used at run time.
20.a Reason: The reason we don't require Program_Error is that there
are situations where other exceptions might make sense. For
example, if the Real Time Systems Annex requires that the range of
System.Priority include at least 30 values, an implementation
could conform to the Standard (but not to the Annex) if it
supported only 12 values. Since the rules of the language require
Constraint_Error to be raised for out-of-range values, we cannot
require Program_Error to be raised instead.
21 If an implementation wishes to provide implementation-defined extensions
to the functionality of a language-defined library unit, it should normally do
so by adding children to the library unit.
21.a.1/2 Implementation Advice: Implementation-defined extensions to the
functionality of a language-defined library unit should be
provided by adding children to the library unit.
21.a Implementation Note: If an implementation has support code ("
run-time system code") that is needed for the execution of
user-defined code, it can put that support code in child packages
of System. Otherwise, it has to use some trick to avoid polluting
the user's namespace. It is important that such tricks not be
available to user-defined code (not in the standard mode, at
least) - that would defeat the purpose.
NOTES
22 2 The above requirements imply that an implementation conforming to
this Standard may support some of the capabilities required by a
Specialized Needs Annex without supporting all required capabilities.
22.a Discussion: A conforming implementation can partially support a
Specialized Needs Annex. Such an implementation does not conform
to the Annex, but it does conform to the Standard.
1.1.4 Method of Description and Syntax Notation
1 The form of an Ada program is described by means of a context-free syntax
together with context-dependent requirements expressed by narrative rules.
2 The meaning of Ada programs is described by means of narrative rules
defining both the effects of each construct and the composition rules for
constructs.
3 The context-free syntax of the language is described using a simple
variant of Backus-Naur Form. In particular:
4 * Lower case words in a sans-serif font, some containing embedded
underlines, are used to denote syntactic categories, for example:
5 case_statement
6 * Boldface words are used to denote reserved words, for example:
7 array
8 * Square brackets enclose optional items. Thus the two following rules
are equivalent.
9/2 {AI95-00433-01} simple_return_statement ::= return [expression];
simple_return_statement ::= return; | return expression;
10 * Curly brackets enclose a repeated item. The item may appear zero or
more times; the repetitions occur from left to right as with an
equivalent left-recursive rule. Thus the two following rules are
equivalent.
11 term ::= factor {multiplying_operator factor}
term ::= factor | term multiplying_operator factor
12 * A vertical line separates alternative items unless it occurs
immediately after an opening curly bracket, in which case it stands
for itself:
13 constraint ::= scalar_constraint | composite_constraint
discrete_choice_list ::= discrete_choice {| discrete_choice}
14 * If the name of any syntactic category starts with an italicized part,
it is equivalent to the category name without the italicized part. The
italicized part is intended to convey some semantic information. For
example subtype_name and task_name are both equivalent to name alone.
14.a Discussion: The grammar given in this International Standard is
not LR(1). In fact, it is ambiguous; the ambiguities are resolved
by the overload resolution rules (see 8.6).
14.b We often use "if" to mean "if and only if" in definitions. For
example, if we define "photogenic" by saying, "A type is
photogenic if it has the following properties...," we mean that a
type is photogenic if and only if it has those properties. It is
usually clear from the context, and adding the "and only if" seems
too cumbersome.
14.c When we say, for example, "a declarative_item of a
declarative_part", we are talking about a declarative_item
immediately within that declarative_part. When we say "a
declarative_item in, or within, a declarative_part", we are
talking about a declarative_item anywhere in the
declarative_part, possibly deeply nested within other
declarative_parts. (This notation doesn't work very well for
names, since the name "of" something also has another meaning.)
14.d When we refer to the name of a language-defined entity (for
example, Duration), we mean the language-defined entity even in
programs where the declaration of the language-defined entity is
hidden by another declaration. For example, when we say that the
expected type for the expression of a delay_relative_statement is
Duration, we mean the language-defined type Duration that is
declared in Standard, not some type Duration the user might have
declared.
14.1/3 {AI95-00285-01} {AI05-0004-1} {AI05-0262-1} The delimiters, compound
delimiters, reserved words, and numeric_literals are exclusively made of the
characters whose code point is between 16#20# and 16#7E#, inclusively. The
special characters for which names are defined in this International Standard
(see 2.1) belong to the same range. [For example, the character E in the
definition of exponent is the character whose name is "LATIN CAPITAL LETTER
E", not "GREEK CAPITAL LETTER EPSILON".]
14.e/2 Discussion: This just means that programs can be written in plain
ASCII characters; no characters outside of the 7-bit range are
required.
14.2/3 {AI95-00395-01} {AI05-0227-1} {AI05-0299-1} When this International
Standard mentions the conversion of some character or sequence of characters
to upper case, it means the character or sequence of characters obtained by
using simple upper case mapping, as defined by documents referenced in the
note in Clause 1 of ISO/IEC 10646:2011.
14.e.1/3 This paragraph was deleted.
15 A syntactic category is a nonterminal in the grammar defined in BNF under
"Syntax." Names of syntactic categories are set in a different font,
like_this.
16 A construct is a piece of text (explicit or implicit) that is an instance
of a syntactic category defined under "Syntax".
16.a Ramification: For example, an expression is a construct. A
declaration is a construct, whereas the thing declared by a
declaration is an "entity."
16.b Discussion: "Explicit" and "implicit" don't mean exactly what you
might think they mean: The text of an instance of a generic is
considered explicit, even though it does not appear explicitly (in
the nontechnical sense) in the program text, and even though its
meaning is not defined entirely in terms of that text.
17 A constituent of a construct is the construct itself, or any construct
appearing within it.
18 Whenever the run-time semantics defines certain actions to happen in an
arbitrary order, this means that the implementation shall arrange for these
actions to occur in a way that is equivalent to some sequential order,
following the rules that result from that sequential order. When evaluations
are defined to happen in an arbitrary order, with conversion of the results to
some subtypes, or with some run-time checks, the evaluations, conversions, and
checks may be arbitrarily interspersed, so long as each expression is
evaluated before converting or checking its value. [Note that the effect of a
program can depend on the order chosen by the implementation. This can happen,
for example, if two actual parameters of a given call have side effects.]
18.a Discussion: Programs will be more portable if their external
effect does not depend on the particular order chosen by an
implementation.
18.b Ramification: Additional reordering permissions are given in
11.6, "Exceptions and Optimization".
18.c There is no requirement that the implementation always choose the
same order in a given kind of situation. In fact, the
implementation is allowed to choose a different order for two
different executions of the same construct. However, we expect
most implementations will behave in a relatively predictable
manner in most situations.
18.d Reason: The "sequential order" wording is intended to allow the
programmer to rely on "benign" side effects. For example, if F is
a function that returns a unique integer by incrementing some
global and returning the result, a call such as P(F, F) is OK if
the programmer cares only that the two results of F are unique;
the two calls of F cannot be executed in parallel, unless the
compiler can prove that parallel execution is equivalent to some
sequential order.
NOTES
19 3 The syntax rules describing structured constructs are presented in
a form that corresponds to the recommended paragraphing. For example,
an if_statement is defined as:
20 if_statement ::=
if condition then
sequence_of_statements
{elsif condition then
sequence_of_statements}
[else
sequence_of_statements]
end if;
21 4 The line breaks and indentation in the syntax rules indicate the
recommended line breaks and indentation in the corresponding
constructs. The preferred places for other line breaks are after
semicolons.
Wording Changes from Ada 95
21.a/2 {AI95-00285-01} We now explicitly say that the lexical elements of
the language (with a few exceptions) are made up of characters in
the lower half of the Latin-1 character set. This is needed to
avoid confusion given the new capability to use most ISO 10646
characters in identifiers and strings.
21.b/2 {AI95-00395-01} We now explicitly define what the Standard means
by upper case, as there are many possibilities for ISO 10646
characters.
21.c/2 {AI95-00433-01} The example for square brackets has been changed
as there is no longer a return_statement syntax rule.
Wording Changes from Ada 2005
21.d/3 {AI05-0227-1} Correction: Upper case is defined by "simple upper
case mapping", because "full case folding" is a mapping (mostly)
to lower case.
1.1.5 Classification of Errors
Implementation Requirements
1 The language definition classifies errors into several different
categories:
2 * Errors that are required to be detected prior to run time by every Ada
implementation;
3 These errors correspond to any violation of a rule given in this
International Standard, other than those listed below. In particular,
violation of any rule that uses the terms shall, allowed, permitted,
legal, or illegal belongs to this category. Any program that contains
such an error is not a legal Ada program; on the other hand, the fact
that a program is legal does not mean, per se, that the program is
free from other forms of error.
4 The rules are further classified as either compile time rules, or post
compilation rules, depending on whether a violation has to be detected
at the time a compilation unit is submitted to the compiler, or may be
postponed until the time a compilation unit is incorporated into a
partition of a program.
4.a Ramification: See, for example, 10.1.3, "
Subunits of Compilation Units", for some errors that are detected
only after compilation. Implementations are allowed, but not
required, to detect post compilation rules at compile time when
possible.
5 * Errors that are required to be detected at run time by the execution
of an Ada program;
6 The corresponding error situations are associated with the names of
the predefined exceptions. Every Ada compiler is required to generate
code that raises the corresponding exception if such an error
situation arises during program execution. [If such an error situation
is certain to arise in every execution of a construct, then an
implementation is allowed (although not required) to report this fact
at compilation time.]
7 * Bounded errors;
8 The language rules define certain kinds of errors that need not be
detected either prior to or during run time, but if not detected, the
range of possible effects shall be bounded. The errors of this
category are called bounded errors. The possible effects of a given
bounded error are specified for each such error, but in any case one
possible effect of a bounded error is the raising of the exception
Program_Error.
9 * Erroneous execution.
10 In addition to bounded errors, the language rules define certain kinds
of errors as leading to erroneous execution. Like bounded errors, the
implementation need not detect such errors either prior to or during
run time. Unlike bounded errors, there is no language-specified bound
on the possible effect of erroneous execution; the effect is in
general not predictable.
10.a Ramification: Executions are erroneous, not programs or parts of
programs. Once something erroneous happens, the execution of the
entire program is erroneous from that point on, and potentially
before given possible reorderings permitted by 11.6 and elsewhere.
We cannot limit it to just one partition, since partitions are not
required to live in separate address spaces. (But implementations
are encouraged to limit it as much as possible.)
10.b Suppose a program contains a pair of things that will be executed
"in an arbitrary order." It is possible that one order will result
in something sensible, whereas the other order will result in
erroneous execution. If the implementation happens to choose the
first order, then the execution is not erroneous. This may seem
odd, but it is not harmful.
10.c Saying that something is erroneous is semantically equivalent to
saying that the behavior is unspecified. However, "erroneous" has
a slightly more disapproving flavor.
Implementation Permissions
11 [ An implementation may provide nonstandard modes of operation. Typically
these modes would be selected by a pragma or by a command line switch when the
compiler is invoked. When operating in a nonstandard mode, the implementation
may reject compilation_units that do not conform to additional requirements
associated with the mode, such as an excessive number of warnings or violation
of coding style guidelines. Similarly, in a nonstandard mode, the
implementation may apply special optimizations or alternative algorithms that
are only meaningful for programs that satisfy certain criteria specified by
the implementation. In any case, an implementation shall support a standard
mode that conforms to the requirements of this International Standard; in
particular, in the standard mode, all legal compilation_units shall be
accepted.]
11.a Discussion: These permissions are designed to authorize explicitly
the support for alternative modes. Of course, nothing we say can
prevent them anyway, but this (redundant) paragraph is designed to
indicate that such alternative modes are in some sense "
approved" and even encouraged where they serve the specialized needs of a
given user community, so long as the standard mode, designed to
foster maximum portability, is always available.
Implementation Advice
12 If an implementation detects a bounded error or erroneous execution, it
should raise Program_Error.
12.a.1/2 Implementation Advice: If a bounded error or erroneous execution
is detected, Program_Error should be raised.
Wording Changes from Ada 83
12.a Some situations that are erroneous in Ada 83 are no longer errors
at all. For example, depending on the parameter passing mechanism
when unspecified is possibly nonportable, but not erroneous.
12.b Other situations that are erroneous in Ada 83 are changed to be
bounded errors. In particular, evaluating an uninitialized scalar
variable is a bounded error. The possible results are to raise
Program_Error (as always), or to produce a machine-representable
value (which might not be in the subtype of the variable).
Violating a Range_Check or Overflow_Check raises Constraint_Error,
even if the value came from an uninitialized variable. This means
that optimizers can no longer "assume" that all variables are
initialized within their subtype's range. Violating a check that
is suppressed remains erroneous.
12.c The "incorrect order dependences" category of errors is removed.
All such situations are simply considered potential
nonportabilities. This category was removed due to the difficulty
of defining what it means for two executions to have a "different
effect." For example, if a function with a side effect is called
twice in a single expression, it is not in principle possible for
the compiler to decide whether the correctness of the resulting
program depends on the order of execution of the two function
calls. A compile time warning might be appropriate, but raising of
Program_Error at run time would not be.
1.2 Normative References
1/3 {AI05-0299-1} The following documents, in whole or in part, are
normatively referenced in this document and are indispensable for its
application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any
amendments) applies.
1.1/3 {AI05-0127-2} {AI05-0299-1} ISO 639-3:2007, Codes for the representation
of names of languages - Part 3: Alpha-3 code for comprehensive coverage of
languages.
2 ISO/IEC 646:1991, Information technology - ISO 7-bit coded character set
for information interchange.
3/2 {AI95-00415-01} ISO/IEC 1539-1:2004, Information technology - Programming
languages - Fortran - Part 1: Base language.
4/2 {AI95-00415-01} ISO/IEC 1989:2002, Information technology - Programming
languages - COBOL.
4.1/3 {AI05-0127-2} {AI05-0299-1} ISO/IEC 3166-1:2006, Codes for the
representation of names of countries and their subdivisions - Part 1: Country
Codes.
5 ISO/IEC 6429:1992, Information technology - Control functions for coded
graphic character sets.
5.1/2 {AI95-00351-01} ISO 8601:2004, Data elements and interchange formats -
Information interchange - Representation of dates and times.
6/3 {AI05-0299-1} ISO/IEC 8859-1:1998, Information technology - 8-bit
single-byte coded graphic character sets - Part 1: Latin alphabet No. 1.
7/3 {AI95-00415-01} {AI05-0266-1} ISO/IEC 9899:2011, Information technology -
Programming languages - C.
8/3 {8652/0001} {AI95-00124-01} {AI95-00285-01} {AI05-0266-1} ISO/IEC
10646:2011, Information technology - Universal Multiple-Octet Coded Character
Set (UCS).
8.a.1/2 This paragraph was deleted.{8652/0001} {AI95-00124-01}
{AI95-00285-01}
9/3 {AI95-00376-01} {AI05-0266-1} ISO/IEC 14882:2011, Information technology -
Programming languages - C++.
10/2 {AI95-00285-01} ISO/IEC TR 19769:2004, Information technology -
Programming languages, their environments and system software interfaces -
Extensions for the programming language C to support new character data types.
10.a Discussion: POSIX, Portable Operating System Interface (POSIX) -
Part 1: System Application Program Interface (API) [C Language],
The Institute of Electrical and Electronics Engineers, 1990.
Wording Changes from Ada 95
10.b/2 {AI95-00285-01} {AI95-00376-01} {AI95-00415-01} Updated references
to the most recent versions of these standards. Added C++ and time
standards. Added C character set technical report.
Wording Changes from Ada 2005
10.c/3 {AI05-0127-2} Added language and country code standards for locale
support.
10.d/3 {AI05-0266-1} Updated references to the most recent versions of
these standards.
1.3 Terms and Definitions
1/2 {AI95-00415-01} Terms are defined throughout this International Standard,
indicated by italic type. Terms explicitly defined in this International
Standard are not to be presumed to refer implicitly to similar terms defined
elsewhere. Mathematical terms not defined in this International Standard are
to be interpreted according to the CRC Concise Encyclopedia of Mathematics,
Second Edition. Other terms not defined in this International Standard are to
be interpreted according to the Webster's Third New International Dictionary
of the English Language. Informal descriptions of some terms are also given in
Annex N, "Glossary".
1.a Discussion: The index contains an entry for every defined term.
1.a.1/2 {AI95-00415-01} The contents of the CRC Concise Encyclopedia of
Mathematics, Second Edition can be accessed on
http://www.mathworld.com. The ISBN number of the book is ISBN
1584883472.
1.b Glossary entry: Each term defined in Annex N is marked like this.
1.c/3 Discussion: Here are some AARM-only definitions: The Ada
Rapporteur Group (ARG) interprets the Ada Reference Manual. An Ada
Issue (AI) is a numbered ruling from the ARG. Ada Issues created
for Ada 83 are denoted as "AI83", while Ada Issues created for Ada
95 are denoted as "AI95" in this document. Similarly, Ada Issues
created for Ada 2005 are denoted as "AI05" The Ada Commentary
Integration Document (ACID) is an edition of the Ada 83 RM in
which clearly marked insertions and deletions indicate the effect
of integrating the approved AIs. The Uniformity Rapporteur Group
(URG) issued recommendations intended to increase uniformity
across Ada implementations. The functions of the URG have been
assumed by the ARG. A Uniformity Issue (UI) was a numbered
recommendation from the URG. A Defect Report and Response is an
official query to WG9 about an error in the standard. Defect
Reports are processed by the ARG, and are referenced here by their
ISO numbers: 8652/nnnn. Most changes to the Ada 95 standard
include reference(s) to the Defect Report(s) that prompted the
change. The Ada Conformity Assessment Test Suite (ACATS) is a set
of tests intended to check the conformity of Ada implementations
to this standard. This set of tests was previously known as the
Ada Compiler Validation Capability (ACVC).
Generated by dwww version 1.15 on Fri May 24 09:12:32 CEST 2024.