--- /dev/null
+This is aarm2012.info, produced by texi2any version 5.2 from
+aarm2012.texinfo.
+
+INFO-DIR-SECTION GNU Ada tools
+START-INFO-DIR-ENTRY
+* Ada Reference Manual: (arm2012).
+* Annotated ARM: (arm2012).
+END-INFO-DIR-ENTRY
+
+\1f
+File: aarm2012.info, Node: Top, Next: Front Matter, Up: (dir)
+
+Annotated Ada Reference Manual
+******************************
+
+Ada Reference Manual, ISO/IEC 8652:2012(E)
+
+ Annotated Ada Reference Manual
+
+ ISO/IEC 8652:2012(E)
+
+ Language and Standard Libraries
+
+* Menu:
+
+* Front Matter:: Copyright, Foreword, etc.
+* 1 :: General
+* 2 :: Lexical Elements
+* 3 :: Declarations and Types
+* 4 :: Names and Expressions
+* 5 :: Statements
+* 6 :: Subprograms
+* 7 :: Packages
+* 8 :: Visibility Rules
+* 9 :: Tasks and Synchronization
+* 10 :: Program Structure and Compilation Issues
+* 11 :: Exceptions
+* 12 :: Generic Units
+* 13 :: Representation Issues
+* Annex A :: Predefined Language Environment
+* Annex B :: Interface to Other Languages
+* Annex C :: Systems Programming
+* Annex D :: Real-Time Systems
+* Annex E :: Distributed Systems
+* Annex F :: Information Systems
+* Annex G :: Numerics
+* Annex H :: High Integrity Systems
+* Annex J :: Obsolescent Features
+* Annex K :: Language-Defined Aspects and Attributes
+* Annex L :: Language-Defined Pragmas
+* Annex M :: Summary of Documentation Requirements
+* Annex N :: Glossary
+* Annex P :: Syntax Summary
+* Annex Q :: Language-Defined Entities
+* Index :: Index
+
+\1f
+File: aarm2012.info, Node: Front Matter, Next: 1, Prev: Top, Up: Top
+
+Front Matter
+************
+
+Copyright © 1992, 1993, 1994, 1995 Intermetrics, Inc.
+
+Copyright © 2000 The MITRE Corporation, Inc.
+
+Copyright © 2004, 2005, 2006 AXE Consultants
+
+Copyright © 2004, 2005, 2006 Ada-Europe
+
+Copyright © 2008, 2009, 2010, 2011, 2012 AXE Consultants
+
+
+
+
+
+
+
+Ada Reference Manual - Language and Standard Libraries
+
+Copyright © 1992, 1993, 1994, 1995, Intermetrics, Inc.
+
+This copyright is assigned to the U.S. Government. All rights reserved.
+
+This document may be copied, in whole or in part, in any form or by any
+means, as is or with alterations, provided that (1) alterations are
+clearly marked as alterations and (2) this copyright notice is included
+unmodified in any copy. Compiled copies of standard library units and
+examples need not contain this copyright notice so long as the notice is
+included in all copies of source code and documentation.
+
+-------
+
+Technical Corrigendum 1
+
+Copyright © 2000, The MITRE Corporation. All Rights Reserved.
+
+This document may be copied, in whole or in part, in any form or by any
+means, as is, or with alterations, provided that (1) alterations are
+clearly marked as alterations and (2) this copyright notice is included
+unmodified in any copy. Any other use or distribution of this document
+is prohibited without the prior express permission of MITRE.
+
+You use this document on the condition that you indemnify and hold
+harmless MITRE, its Board of Trustees, officers, agents, and employees,
+from any and all liability or damages to yourself or your hardware or
+software, or third parties, including attorneys' fees, court costs, and
+other related costs and expenses, arising out of your use of this
+document irrespective of the cause of said liability.
+
+MITRE MAKES THIS DOCUMENT AVAILABLE ON AN "AS IS" BASIS AND MAKES NO
+WARRANTY, EXPRESS OR IMPLIED, AS TO THE ACCURACY, CAPABILITY, EFFICIENCY
+MERCHANTABILITY, OR FUNCTIONING OF THIS DOCUMENT. IN NO EVENT WILL MITRE
+BE LIABLE FOR ANY GENERAL, CONSEQUENTIAL, INDIRECT, INCIDENTAL,
+EXEMPLARY, OR SPECIAL DAMAGES, EVEN IF MITRE HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+
+
+Amendment 1
+
+Copyright © 2004, 2005, 2006, 2007, AXE Consultants. All Rights
+Reserved.
+
+This document may be copied, in whole or in part, in any form or by any
+means, as is, or with alterations, provided that (1) alterations are
+clearly marked as alterations and (2) this copyright notice is included
+unmodified in any copy. Any other use or distribution of this document
+is prohibited without the prior express permission of AXE.
+
+You use this document on the condition that you indemnify and hold
+harmless AXE, its board, officers, agents, and employees, from any and
+all liability or damages to yourself or your hardware or software, or
+third parties, including attorneys' fees, court costs, and other related
+costs and expenses, arising out of your use of this document
+irrespective of the cause of said liability.
+
+AXE MAKES THIS DOCUMENT AVAILABLE ON AN "AS IS" BASIS AND MAKES NO
+WARRANTY, EXPRESS OR IMPLIED, AS TO THE ACCURACY, CAPABILITY, EFFICIENCY
+MERCHANTABILITY, OR FUNCTIONING OF THIS DOCUMENT. IN NO EVENT WILL AXE
+BE LIABLE FOR ANY GENERAL, CONSEQUENTIAL, INDIRECT, INCIDENTAL,
+EXEMPLARY, OR SPECIAL DAMAGES, EVEN IF AXE HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+Third Edition
+
+Copyright © 2008, 2009, 2010, 2011, 2012 AXE Consultants. All Rights
+Reserved.
+
+This document may be copied, in whole or in part, in any form or by any
+means, as is, or with alterations, provided that (1) alterations are
+clearly marked as alterations and (2) this copyright notice is included
+unmodified in any copy. Any other use or distribution of this document
+is prohibited without the prior express permission of AXE.
+
+You use this document on the condition that you indemnify and hold
+harmless AXE, its board, officers, agents, and employees, from any and
+all liability or damages to yourself or your hardware or software, or
+third parties, including attorneys' fees, court costs, and other related
+costs and expenses, arising out of your use of this document
+irrespective of the cause of said liability.
+
+AXE MAKES THIS DOCUMENT AVAILABLE ON AN "AS IS" BASIS AND MAKES NO
+WARRANTY, EXPRESS OR IMPLIED, AS TO THE ACCURACY, CAPABILITY, EFFICIENCY
+MERCHANTABILITY, OR FUNCTIONING OF THIS DOCUMENT. IN NO EVENT WILL AXE
+BE LIABLE FOR ANY GENERAL, CONSEQUENTIAL, INDIRECT, INCIDENTAL,
+EXEMPLARY, OR SPECIAL DAMAGES, EVEN IF AXE HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+
+
+Ada 2005 Consolidated Standard
+
+Copyright © 2004, 2005, 2006, Ada-Europe.
+
+This document may be copied, in whole or in part, in any form or by any
+means, as is, or with alterations, provided that (1) alterations are
+clearly marked as alterations and (2) this copyright notice is included
+unmodified in any copy. Any other use or distribution of this document
+is prohibited without the prior express permission of Ada-Europe.
+
+You use this document on the condition that you indemnify and hold
+harmless Ada-Europe and its Board from any and all liability or damages
+to yourself or your hardware or software, or third parties, including
+attorneys' fees, court costs, and other related costs and expenses,
+arising out of your use of this document irrespective of the cause of
+said liability.
+
+ADA-EUROPE MAKES THIS DOCUMENT AVAILABLE ON AN "AS IS" BASIS AND MAKES
+NO WARRANTY, EXPRESS OR IMPLIED, AS TO THE ACCURACY, CAPABILITY,
+EFFICIENCY MERCHANTABILITY, OR FUNCTIONING OF THIS DOCUMENT. IN NO EVENT
+WILL ADA-EUROPE BE LIABLE FOR ANY GENERAL, CONSEQUENTIAL, INDIRECT,
+INCIDENTAL, EXEMPLARY, OR SPECIAL DAMAGES, EVEN IF ADA-EUROPE HAS BEEN
+ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
+
+* Menu:
+
+* 0.1 :: Foreword to this version of the Ada Reference Manual
+* 0.2 :: Foreword
+* 0.3 :: Introduction
+* 0.99 :: International Standard
+
+\1f
+File: aarm2012.info, Node: 0.1, Next: 0.2, Up: Front Matter
+
+0.1 Foreword
+============
+
+1/3
+ISO (the International Organization for Standardization) and IEC (the
+International Electrotechnical Commission) form the specialized system
+for worldwide standardization. National bodies that are members of ISO
+or IEC participate in the development of International Standards through
+technical committees established by the respective organization to deal
+with particular fields of technical activity. ISO and IEC technical
+committees collaborate in fields of mutual interest. Other
+international organizations, governmental and non-governmental, in
+liaison with ISO and IEC, also take part in the work. In the field of
+information technology, ISO and IEC have established a joint technical
+committee, ISO/IEC JTC 1.
+
+1.1/3
+International Standards are drafted in accordance with the rules given
+in the ISO/IEC Directives, Part 2.
+
+2/3
+The main task of the joint technical committee is to prepare
+International Standards. Draft International Standards adopted by the
+joint technical committee are circulated to national bodies for voting.
+Publication as an International Standard requires approval by at least
+75 % of the national bodies casting a vote.
+
+2.1/3
+Attention is drawn to the possibility that some of the elements of this
+document may be the subject of patent rights. ISO and IEC shall not be
+held responsible for identifying any or all such patent rights.
+
+3/3
+International Standard ISO/IEC 8652 was prepared by Joint Technical
+Committee ISO/IEC JTC 1, Information Technology Subcommittee SC22,
+Programming languages, their environments and system software
+interfaces.
+
+4/3
+{AI05-0299-1AI05-0299-1} This third edition cancels and replaces the
+second edition (ISO/IEC 8652:1995), which has been technically revised.
+It also incorporates the Technical Corrigendum ISO/IEC
+8652:1995:COR.1:2001 and Amendment ISO/IEC 8652:1995:AMD 1:2007.
+
+5.a/3
+ Discussion: This document is the Annotated Ada Reference
+ Manual (AARM). It contains the entire text of the Ada 2012
+ standard (ISO/IEC 8652:201x), plus various annotations. It is
+ intended primarily for compiler writers, validation test
+ writers, and other language lawyers. The annotations include
+ detailed rationale for individual rules and explanations of
+ some of the more arcane interactions among the rules.
+
+\1f
+File: aarm2012.info, Node: 0.2, Next: 0.99, Prev: 0.1, Up: Front Matter
+
+0.2 Introduction
+================
+
+1
+This is the Annotated Ada Reference Manual.
+
+2
+Other available Ada documents include:
+
+3/3
+ * {AI95-00387-01AI95-00387-01} {AI05-0245-1AI05-0245-1} Ada 2012
+ Rationale. This gives an introduction to the changes and new
+ features in Ada 2012, and explains the rationale behind them.
+ Programmers should read this rationale before reading this Standard
+ in depth. Rationales for Ada 83, Ada 95, and Ada 2005 are also
+ available.
+
+3.a/3
+ Discussion: {AI05-0245-1AI05-0245-1} As of this writing
+ (December 2012), only five chapters of the Ada 2012 Rationale
+ have been published. Additional chapters are in development
+ and should be published during 2013.
+
+4/1
+ * This paragraph was deleted.
+
+5/3
+ * The Ada Reference Manual (RM). This is the International Standard
+ -- ISO/IEC 8652:201x.
+
+Design Goals
+
+6/3
+{AI95-00387-01AI95-00387-01} Ada was originally designed with three
+overriding concerns: program reliability and maintenance, programming as
+a human activity, and efficiency. The 1995 revision to the language was
+designed to provide greater flexibility and extensibility, additional
+control over storage management and synchronization, and standardized
+packages oriented toward supporting important application areas, while
+at the same time retaining the original emphasis on reliability,
+maintainability, and efficiency. This third edition provides further
+flexibility and adds more standardized packages within the framework
+provided by the 1995 revision.
+
+7
+The need for languages that promote reliability and simplify maintenance
+is well established. Hence emphasis was placed on program readability
+over ease of writing. For example, the rules of the language require
+that program variables be explicitly declared and that their type be
+specified. Since the type of a variable is invariant, compilers can
+ensure that operations on variables are compatible with the properties
+intended for objects of the type. Furthermore, error-prone notations
+have been avoided, and the syntax of the language avoids the use of
+encoded forms in favor of more English-like constructs. Finally, the
+language offers support for separate compilation of program units in a
+way that facilitates program development and maintenance, and which
+provides the same degree of checking between units as within a unit.
+
+8
+Concern for the human programmer was also stressed during the design.
+Above all, an attempt was made to keep to a relatively small number of
+underlying concepts integrated in a consistent and systematic way while
+continuing to avoid the pitfalls of excessive involution. The design
+especially aims to provide language constructs that correspond
+intuitively to the normal expectations of users.
+
+9
+Like many other human activities, the development of programs is
+becoming ever more decentralized and distributed. Consequently, the
+ability to assemble a program from independently produced software
+components continues to be a central idea in the design. The concepts
+of packages, of private types, and of generic units are directly related
+to this idea, which has ramifications in many other aspects of the
+language. An allied concern is the maintenance of programs to match
+changing requirements; type extension and the hierarchical library
+enable a program to be modified while minimizing disturbance to existing
+tested and trusted components.
+
+10
+No language can avoid the problem of efficiency. Languages that require
+over-elaborate compilers, or that lead to the inefficient use of storage
+or execution time, force these inefficiencies on all machines and on all
+programs. Every construct of the language was examined in the light of
+present implementation techniques. Any proposed construct whose
+implementation was unclear or that required excessive machine resources
+was rejected.
+
+Language Summary
+
+11
+An Ada program is composed of one or more program units. Program units
+may be subprograms (which define executable algorithms), packages (which
+define collections of entities), task units (which define concurrent
+computations), protected units (which define operations for the
+coordinated sharing of data between tasks), or generic units (which
+define parameterized forms of packages and subprograms). Each program
+unit normally consists of two parts: a specification, containing the
+information that must be visible to other units, and a body, containing
+the implementation details, which need not be visible to other units.
+Most program units can be compiled separately.
+
+12
+This distinction of the specification and body, and the ability to
+compile units separately, allows a program to be designed, written, and
+tested as a set of largely independent software components.
+
+13
+An Ada program will normally make use of a library of program units of
+general utility. The language provides means whereby individual
+organizations can construct their own libraries. All libraries are
+structured in a hierarchical manner; this enables the logical
+decomposition of a subsystem into individual components. The text of a
+separately compiled program unit must name the library units it
+requires.
+
+14
+Program Units
+
+15
+A subprogram is the basic unit for expressing an algorithm. There are
+two kinds of subprograms: procedures and functions. A procedure is the
+means of invoking a series of actions. For example, it may read data,
+update variables, or produce some output. It may have parameters, to
+provide a controlled means of passing information between the procedure
+and the point of call. A function is the means of invoking the
+computation of a value. It is similar to a procedure, but in addition
+will return a result.
+
+16
+A package is the basic unit for defining a collection of logically
+related entities. For example, a package can be used to define a set of
+type declarations and associated operations. Portions of a package can
+be hidden from the user, thus allowing access only to the logical
+properties expressed by the package specification.
+
+17
+Subprogram and package units may be compiled separately and arranged in
+hierarchies of parent and child units giving fine control over
+visibility of the logical properties and their detailed implementation.
+
+18
+A task unit is the basic unit for defining a task whose sequence of
+actions may be executed concurrently with those of other tasks. Such
+tasks may be implemented on multicomputers, multiprocessors, or with
+interleaved execution on a single processor. A task unit may define
+either a single executing task or a task type permitting the creation of
+any number of similar tasks.
+
+19/2
+{AI95-00114-01AI95-00114-01} A protected unit is the basic unit for
+defining protected operations for the coordinated use of data shared
+between tasks. Simple mutual exclusion is provided automatically, and
+more elaborate sharing protocols can be defined. A protected operation
+can either be a subprogram or an entry. A protected entry specifies a
+Boolean expression (an entry barrier) that must be True before the body
+of the entry is executed. A protected unit may define a single
+protected object or a protected type permitting the creation of several
+similar objects.
+
+20
+Declarations and Statements
+
+21
+The body of a program unit generally contains two parts: a declarative
+part, which defines the logical entities to be used in the program unit,
+and a sequence of statements, which defines the execution of the program
+unit.
+
+22
+The declarative part associates names with declared entities. For
+example, a name may denote a type, a constant, a variable, or an
+exception. A declarative part also introduces the names and parameters
+of other nested subprograms, packages, task units, protected units, and
+generic units to be used in the program unit.
+
+23
+The sequence of statements describes a sequence of actions that are to
+be performed. The statements are executed in succession (unless a
+transfer of control causes execution to continue from another place).
+
+24
+An assignment statement changes the value of a variable. A procedure
+call invokes execution of a procedure after associating any actual
+parameters provided at the call with the corresponding formal
+parameters.
+
+25
+Case statements and if statements allow the selection of an enclosed
+sequence of statements based on the value of an expression or on the
+value of a condition.
+
+26
+The loop statement provides the basic iterative mechanism in the
+language. A loop statement specifies that a sequence of statements is
+to be executed repeatedly as directed by an iteration scheme, or until
+an exit statement is encountered.
+
+27
+A block statement comprises a sequence of statements preceded by the
+declaration of local entities used by the statements.
+
+28
+Certain statements are associated with concurrent execution. A delay
+statement delays the execution of a task for a specified duration or
+until a specified time. An entry call statement is written as a
+procedure call statement; it requests an operation on a task or on a
+protected object, blocking the caller until the operation can be
+performed. A called task may accept an entry call by executing a
+corresponding accept statement, which specifies the actions then to be
+performed as part of the rendezvous with the calling task. An entry
+call on a protected object is processed when the corresponding entry
+barrier evaluates to true, whereupon the body of the entry is executed.
+The requeue statement permits the provision of a service as a number of
+related activities with preference control. One form of the select
+statement allows a selective wait for one of several alternative
+rendezvous. Other forms of the select statement allow conditional or
+timed entry calls and the asynchronous transfer of control in response
+to some triggering event.
+
+29
+Execution of a program unit may encounter error situations in which
+normal program execution cannot continue. For example, an arithmetic
+computation may exceed the maximum allowed value of a number, or an
+attempt may be made to access an array component by using an incorrect
+index value. To deal with such error situations, the statements of a
+program unit can be textually followed by exception handlers that
+specify the actions to be taken when the error situation arises.
+Exceptions can be raised explicitly by a raise statement.
+
+30
+Data Types
+
+31
+Every object in the language has a type, which characterizes a set of
+values and a set of applicable operations. The main classes of types
+are elementary types (comprising enumeration, numeric, and access types)
+and composite types (including array and record types).
+
+32/2
+{AI95-00285-01AI95-00285-01} {AI95-00387-01AI95-00387-01} An enumeration
+type defines an ordered set of distinct enumeration literals, for
+example a list of states or an alphabet of characters. The enumeration
+types Boolean, Character, Wide_Character, and Wide_Wide_Character are
+predefined.
+
+33
+Numeric types provide a means of performing exact or approximate
+numerical computations. Exact computations use integer types, which
+denote sets of consecutive integers. Approximate computations use
+either fixed point types, with absolute bounds on the error, or floating
+point types, with relative bounds on the error. The numeric types
+Integer, Float, and Duration are predefined.
+
+34/2
+{AI95-00285-01AI95-00285-01} {AI95-00387-01AI95-00387-01} Composite
+types allow definitions of structured objects with related components.
+The composite types in the language include arrays and records. An
+array is an object with indexed components of the same type. A record
+is an object with named components of possibly different types. Task
+and protected types are also forms of composite types. The array types
+String, Wide_String, and Wide_Wide_String are predefined.
+
+35
+Record, task, and protected types may have special components called
+discriminants which parameterize the type. Variant record structures
+that depend on the values of discriminants can be defined within a
+record type.
+
+36
+Access types allow the construction of linked data structures. A value
+of an access type represents a reference to an object declared as
+aliased or to an object created by the evaluation of an allocator.
+Several variables of an access type may designate the same object, and
+components of one object may designate the same or other objects. Both
+the elements in such linked data structures and their relation to other
+elements can be altered during program execution. Access types also
+permit references to subprograms to be stored, passed as parameters, and
+ultimately dereferenced as part of an indirect call.
+
+37
+Private types permit restricted views of a type. A private type can be
+defined in a package so that only the logically necessary properties are
+made visible to the users of the type. The full structural details that
+are externally irrelevant are then only available within the package and
+any child units.
+
+38
+From any type a new type may be defined by derivation. A type, together
+with its derivatives (both direct and indirect) form a derivation class.
+Class-wide operations may be defined that accept as a parameter an
+operand of any type in a derivation class. For record and private
+types, the derivatives may be extensions of the parent type. Types that
+support these object-oriented capabilities of class-wide operations and
+type extension must be tagged, so that the specific type of an operand
+within a derivation class can be identified at run time. When an
+operation of a tagged type is applied to an operand whose specific type
+is not known until run time, implicit dispatching is performed based on
+the tag of the operand.
+
+38.1/2
+{AI95-00387-01AI95-00387-01} Interface types provide abstract models
+from which other interfaces and types may be composed and derived. This
+provides a reliable form of multiple inheritance. Interface types may
+also be implemented by task types and protected types thereby enabling
+concurrent programming and inheritance to be merged.
+
+39
+The concept of a type is further refined by the concept of a subtype,
+whereby a user can constrain the set of allowed values of a type.
+Subtypes can be used to define subranges of scalar types, arrays with a
+limited set of index values, and records and private types with
+particular discriminant values.
+
+40
+Other Facilities
+
+41/2
+{AI95-00387-01AI95-00387-01} Aspect clauses can be used to specify the
+mapping between types and features of an underlying machine. For
+example, the user can specify that objects of a given type must be
+represented with a given number of bits, or that the components of a
+record are to be represented using a given storage layout. Other
+features allow the controlled use of low level, nonportable, or
+implementation-dependent aspects, including the direct insertion of
+machine code.
+
+42/2
+{AI95-00387-01AI95-00387-01} The predefined environment of the language
+provides for input-output and other capabilities by means of standard
+library packages. Input-output is supported for values of user-defined
+as well as of predefined types. Standard means of representing values
+in display form are also provided.
+
+42.1/2
+{AI95-00387-01AI95-00387-01} The predefined standard library packages
+provide facilities such as string manipulation, containers of various
+kinds (vectors, lists, maps, etc.), mathematical functions, random
+number generation, and access to the execution environment.
+
+42.2/2
+{AI95-00387-01AI95-00387-01} The specialized annexes define further
+predefined library packages and facilities with emphasis on areas such
+as real-time scheduling, interrupt handling, distributed systems,
+numerical computation, and high-integrity systems.
+
+43
+Finally, the language provides a powerful means of parameterization of
+program units, called generic program units. The generic parameters can
+be types and subprograms (as well as objects and packages) and so allow
+general algorithms and data structures to be defined that are applicable
+to all types of a given class.
+
+Language Changes
+
+Paragraphs 44 through 57 have been removed as they described differences
+from the first edition of Ada (Ada 83).
+
+57.1/3
+{AI95-00387-01AI95-00387-01} This International Standard replaces the
+second edition of 1995. It modifies the previous edition by making
+changes and additions that improve the capability of the language and
+the reliability of programs written in the language. This edition
+incorporates the changes from Amendment 1 (ISO/IEC 8652:1995:AMD
+1:2007), which were designed to improve the portability of programs,
+interfacing to other languages, and both the object-oriented and
+real-time capabilities.
+
+57.2/3
+{AI95-00387-01AI95-00387-01} {AI05-0299-1AI05-0299-1} Significant
+changes originating in Amendment 1 are incorporated:
+
+57.3/3
+ * Support for program text is extended to cover the entire ISO/IEC
+ 10646:2003 repertoire. Execution support now includes the 32-bit
+ character set. See subclauses *note 2.1::, *note 3.5.2::, *note
+ 3.6.3::, *note A.1::, *note A.3::, and *note A.4::.
+
+57.4/3
+ * The object-oriented model has been improved by the addition of an
+ interface facility which provides multiple inheritance and
+ additional flexibility for type extensions. See subclauses *note
+ 3.4::, *note 3.9::, and *note 7.3::. An alternative notation for
+ calling operations more akin to that used in other languages has
+ also been added. See subclause *note 4.1.3::.
+
+57.5/3
+ * Access types have been further extended to unify properties such as
+ the ability to access constants and to exclude null values. See
+ clause *note 3.10::. Anonymous access types are now permitted more
+ freely and anonymous access-to-subprogram types are introduced.
+ See subclauses *note 3.3::, *note 3.6::, *note 3.10::, and *note
+ 8.5.1::.
+
+57.6/3
+ * The control of structure and visibility has been enhanced to permit
+ mutually dependent references between units and finer control over
+ access from the private part of a package. See subclauses *note
+ 3.10.1:: and *note 10.1.2::. In addition, limited types have been
+ made more useful by the provision of aggregates, constants, and
+ constructor functions. See subclauses *note 4.3::, *note 6.5::,
+ and *note 7.5::.
+
+57.7/3
+ * The predefined environment has been extended to include additional
+ time and calendar operations, improved string handling, a
+ comprehensive container library, file and directory management, and
+ access to environment variables. See subclauses *note 9.6.1::,
+ *note A.4::, *note A.16::, *note A.17::, and *note A.18::.
+
+57.8/3
+ * Two of the Specialized Needs Annexes have been considerably
+ enhanced:
+
+57.9/2
+ * The Real-Time Systems Annex now includes the Ravenscar
+ profile for high-integrity systems, further dispatching
+ policies such as Round Robin and Earliest Deadline First,
+ support for timing events, and support for control of CPU
+ time utilization. See subclauses *note D.2::, *note
+ D.13::, *note D.14::, and *note D.15::.
+
+57.10/3
+ * The Numerics Annex now includes support for real and
+ complex vectors and matrices as previously defined in
+ ISO/IEC 13813:1997 plus further basic operations for
+ linear algebra. See subclause *note G.3::.
+
+57.11/3
+ * The overall reliability of the language has been enhanced by a
+ number of improvements. These include new syntax which detects
+ accidental overloading, as well as pragmas for making assertions
+ and giving better control over the suppression of checks. See
+ subclauses *note 6.1::, *note 11.4.2::, and *note 11.5::.
+
+57.12/3
+{AI05-0245-1AI05-0245-1} In addition, this third edition makes
+enhancements to address two important issues, namely, the particular
+problems of multiprocessor architectures, and the need to further
+increase the capabilities regarding assertions for correctness. It also
+makes additional changes and additions that improve the capability of
+the language and the reliability of programs written in the language.
+
+57.13/3
+{AI05-0245-1AI05-0245-1} {AI05-0299-1AI05-0299-1} The following
+significant changes with respect to the 1995 edition as amended by
+Amendment 1 are incorporated:
+
+57.14/3
+ * New syntax (the aspect specification) is introduced to enable
+ properties to be specified for various entities in a more
+ structured manner than through pragmas. See subclause *note
+ 13.1.1::.
+
+57.15/3
+ * The concept of assertions introduced in the 2005 edition is
+ extended with the ability to specify preconditions and
+ postconditions for subprograms, and invariants for private types.
+ The concept of constraints in defining subtypes is supplemented
+ with subtype predicates that enable subsets to be specified other
+ than as simple ranges. These properties are all indicated using
+ aspect specifications. See subclauses *note 3.2.4::, *note
+ 6.1.1::, and *note 7.3.2::.
+
+57.16/3
+ * New forms of expressions are introduced. These are if expressions,
+ case expressions, quantified expressions, and expression functions.
+ As well as being useful for programming in general by avoiding the
+ introduction of unnecessary assignments, they are especially
+ valuable in conditions and invariants since they avoid the need to
+ introduce auxiliary functions. See subclauses *note 4.5.7::, *note
+ 4.5.8::, and *note 6.8::. Membership tests are also made more
+ flexible. See subclauses *note 4.4:: and *note 4.5.2::.
+
+57.17/3
+ * A number of changes are made to subprogram parameters. Functions
+ may now have parameters of all modes. In order to mitigate
+ consequent (and indeed existing) problems of inadvertent order
+ dependence, rules are introduced to reduce aliasing. A parameter
+ may now be explicitly marked as aliased and the type of a parameter
+ may be incomplete in certain circumstances. See subclauses *note
+ 3.10.1::, *note 6.1::, and *note 6.4.1::.
+
+57.18/3
+ * The use of access types is now more flexible. The rules for
+ accessibility and certain conversions are improved. See subclauses
+ *note 3.10.2::, *note 4.5.2::, *note 4.6::, and *note 8.6::.
+ Furthermore, better control of storage pools is provided. See
+ subclause *note 13.11.4::.
+
+57.19/3
+ * The Real-Time Systems Annex now includes facilities for defining
+ domains of processors and assigning tasks to them. Improvements
+ are made to scheduling and budgeting facilities. See subclauses
+ *note D.10.1::, *note D.14::, and *note D.16::.
+
+57.20/3
+ * A number of important improvements are made to the standard
+ library. These include packages for conversions between strings
+ and UTF encodings, and classification functions for wide and wide
+ wide characters. Internationalization is catered for by a package
+ giving locale information. See subclauses *note A.3::, *note
+ A.4.11::, and *note A.19::. The container library is extended to
+ include bounded forms of the existing containers and new containers
+ for indefinite objects, multiway trees, and queues. See subclause
+ *note A.18::.
+
+57.21/3
+ * Finally, certain features are added primarily to ease the use of
+ containers, such as the ability to iterate over all elements in a
+ container without having to encode the iteration. These can also
+ be used for iteration over arrays, and within quantified
+ expressions. See subclauses *note 4.1.5::, *note 4.1.6::, *note
+ 5.5.1::, and *note 5.5.2::.
+
+Instructions for Comment Submission
+
+58/1
+Informal comments on this International Standard may be sent via e-mail
+to ada-comment@ada-auth.org. If appropriate, the Project Editor will
+initiate the defect correction procedure.
+
+59
+Comments should use the following format:
+
+60/3
+ !topic Title summarizing comment
+ !reference Ada 2012 RMss.ss(pp)
+ !from Author Name yy-mm-dd
+ !keywords keywords related to topic
+ !discussion
+
+ text of discussion
+
+61/3
+where ss.ss is the clause or subclause number, pp is the paragraph
+number where applicable, and yy-mm-dd is the date the comment was sent.
+The date is optional, as is the !keywords line.
+
+62/1
+Please use a descriptive "Subject" in your e-mail message, and limit
+each message to a single comment.
+
+63
+When correcting typographical errors or making minor wording
+suggestions, please put the correction directly as the topic of the
+comment; use square brackets [ ] to indicate text to be omitted and
+curly braces { } to indicate text to be added, and provide enough
+context to make the nature of the suggestion self-evident or put
+additional information in the body of the comment, for example:
+
+64
+ !topic [c]{C}haracter
+ !topic it[']s meaning is not defined
+
+65
+Formal requests for interpretations and for reporting defects in this
+International Standard may be made in accordance with the ISO/IEC JTC 1
+Directives and the ISO/IEC JTC 1/SC 22 policy for interpretations.
+National Bodies may submit a Defect Report to ISO/IEC JTC 1/SC 22 for
+resolution under the JTC 1 procedures. A response will be provided and,
+if appropriate, a Technical Corrigendum will be issued in accordance
+with the procedures.
+
+Acknowledgements for the Ada 83 edition
+
+65.1/3
+Ada is the result of a collective effort to design a common language for
+programming large scale and real-time systems.
+
+65.2/3
+The common high order language program began in 1974. The requirements
+of the United States Department of Defense were formalized in a series
+of documents which were extensively reviewed by the Services, industrial
+organizations, universities, and foreign military departments. The Ada
+language was designed in accordance with the final (1978) form of these
+requirements, embodied in the Steelman specification.
+
+65.3/3
+The Ada design team was led by Jean D. Ichbiah and has included Bernd
+Krieg-Brueckner, Brian A. Wichmann, Henry F. Ledgard, Jean-Claude
+Heliard, Jean-Loup Gailly, Jean-Raymond Abrial, John G.P. Barnes, Mike
+Woodger, Olivier Roubine, Paul N. Hilfinger, and Robert Firth.
+
+65.4/3
+At various stages of the project, several people closely associated with
+the design team made major contributions. They include J.B. Goodenough,
+R.F. Brender, M.W. Davis, G. Ferran, K. Lester, L. MacLaren, E. Morel,
+I.R. Nassi, I.C. Pyle, S.A. Schuman, and S.C. Vestal.
+
+65.5/3
+Two parallel efforts that were started in the second phase of this
+design had a deep influence on the language. One was the development of
+a formal definition using denotational semantics, with the participation
+of V. Donzeau-Gouge, G. Kahn, and B. Lang. The other was the design of
+a test translator with the participation of K. Ripken, P. Boullier, P.
+Cadiou, J. Holden, J.F. Hueras, R.G. Lange, and D.T. Cornhill. The
+entire effort benefitted from the dedicated assistance of Lyn Churchill
+and Marion Myers, and the effective technical support of B. Gravem, W.L.
+Heimerdinger, and P. Cleve. H.G. Schmitz served as program manager.
+
+65.6/3
+Over the five years spent on this project, several intense week-long
+design reviews were conducted, with the participation of P. Belmont, B.
+Brosgol, P. Cohen, R. Dewar, A. Evans, G. Fisher, H. Harte, A.L. Hisgen,
+P. Knueven, M. Kronental, N. Lomuto, E. Ploedereder, G. Seegmueller, V.
+Stenning, D. Taffs, and also F. Belz, R. Converse, K. Correll, A.N.
+Habermann, J. Sammet, S. Squires, J. Teller, P. Wegner, and P.R.
+Wetherall.
+
+65.7/3
+Several persons had a constructive influence with their comments,
+criticisms and suggestions. They include P. Brinch Hansen, G. Goos,
+C.A.R. Hoare, Mark Rain, W.A. Wulf, and also E. Boebert, P. Bonnard, H.
+Clausen, M. Cox, G. Dismukes, R. Eachus, T. Froggatt, H. Ganzinger, C.
+Hewitt, S. Kamin, R. Kotler, O. Lecarme, J.A.N. Lee, J.L. Mansion, F.
+Minel, T. Phinney, J. Roehrich, V. Schneider, A. Singer, D. Slosberg,
+I.C. Wand, the reviewers of Ada-Europe, AdaTech, Afcet, those of the
+LMSC review team, and those of the Ada Tokyo Study Group.
+
+65.8/3
+These reviews and comments, the numerous evaluation reports received at
+the end of the first and second phase, the nine hundred language issue
+reports and test and evaluation reports received from fifteen different
+countries during the third phase of the project, the thousands of
+comments received during the ANSI Canvass, and the on-going work of the
+IFIP Working Group 2.4 on system implementation languages and that of
+the Purdue Europe LTPL-E committee, all had a substantial influence on
+the final definition of Ada.
+
+65.9/3
+The Military Departments and Agencies have provided a broad base of
+support including funding, extensive reviews, and countless individual
+contributions by the members of the High Order Language Working Group
+and other interested personnel. In particular, William A. Whitaker
+provided leadership for the program during the formative stages. David
+A. Fisher was responsible for the successful development and refinement
+of the language requirement documents that led to the Steelman
+specification.
+
+65.10/3
+The Ada 83 language definition was developed by Cii Honeywell Bull and
+later Alsys, and by Honeywell Systems and Research Center, under
+contract to the United States Department of Defense. William E. Carlson
+and later Larry E. Druffel served as the technical representatives of
+the United States Government and effectively coordinated the efforts of
+all participants in the Ada program.
+
+Acknowledgements for the Ada 95 edition
+
+66
+This International Standard was prepared by the Ada 9X Mapping/Revision
+Team based at Intermetrics, Inc., which has included: W. Carlson,
+Program Manager; T. Taft, Technical Director; J. Barnes (consultant); B.
+Brosgol (consultant); R. Duff (Oak Tree Software); M. Edwards; C.
+Garrity; R. Hilliard; O. Pazy (consultant); D. Rosenfeld; L. Shafer; W.
+White; M. Woodger.
+
+67
+The following consultants to the Ada 9X Project contributed to the
+Specialized Needs Annexes: T. Baker (Real-Time/Systems Programming --
+SEI, FSU); K. Dritz (Numerics -- Argonne National Laboratory); A.
+Gargaro (Distributed Systems -- Computer Sciences); J. Goodenough
+(Real-Time/Systems Programming -- SEI); J. McHugh (Secure Systems --
+consultant); B. Wichmann (Safety-Critical Systems -- NPL: UK).
+
+68
+This work was regularly reviewed by the Ada 9X Distinguished Reviewers
+and the members of the Ada 9X Rapporteur Group (XRG): E. Ploedereder,
+Chairman of DRs and XRG (University of Stuttgart: Germany); B. Bardin
+(Hughes); J. Barnes (consultant: UK); B. Brett (DEC); B. Brosgol
+(consultant); R. Brukardt (RR Software); N. Cohen (IBM); R. Dewar (NYU);
+G. Dismukes (TeleSoft); A. Evans (consultant); A. Gargaro (Computer
+Sciences); M. Gerhardt (ESL); J. Goodenough (SEI); S. Heilbrunner
+(University of Salzburg: Austria); P. Hilfinger (UC/Berkeley); B.
+Källberg (CelsiusTech: Sweden); M. Kamrad II (Unisys); J. van Katwijk
+(Delft University of Technology: The Netherlands); V. Kaufman (Russia);
+P. Kruchten (Rational); R. Landwehr (CCI: Germany); C. Lester
+(Portsmouth Polytechnic: UK); L. Månsson (TELIA Research: Sweden); S.
+Michell (Multiprocessor Toolsmiths: Canada); M. Mills (US Air Force); D.
+Pogge (US Navy); K. Power (Boeing); O. Roubine (Verdix: France); A.
+Strohmeier (Swiss Fed Inst of Technology: Switzerland); W. Taylor
+(consultant: UK); J. Tokar (Tartan); E. Vasilescu (Grumman); J. Vladik
+(Prospeks s.r.o.: Czech Republic); S. Van Vlierberghe (OFFIS: Belgium).
+
+69
+Other valuable feedback influencing the revision process was provided by
+the Ada 9X Language Precision Team (Odyssey Research Associates), the
+Ada 9X User/Implementer Teams (AETECH, Tartan, TeleSoft), the Ada 9X
+Implementation Analysis Team (New York University) and the Ada
+community-at-large.
+
+70
+Special thanks go to R. Mathis, Convenor of ISO/IEC JTC 1/SC 22 Working
+Group 9.
+
+71
+The Ada 9X Project was sponsored by the Ada Joint Program Office.
+Christine M. Anderson at the Air Force Phillips Laboratory (Kirtland
+AFB, NM) was the project manager.
+
+Acknowledgements for the Corrigendum version
+
+71.1/3
+The editor [R. Brukardt (USA)] would like to thank the many people whose
+hard work and assistance has made this update possible.
+
+71.2/1
+Thanks go out to all of the members of the ISO/IEC JTC 1/SC 22/WG 9 Ada
+Rapporteur Group, whose work on creating and editing the wording
+corrections was critical to the entire process. Especially valuable
+contributions came from the chairman of the ARG, E. Ploedereder
+(Germany), who kept the process moving; J. Barnes (UK) and K. Ishihata
+(Japan), whose extremely detailed reviews kept the editor on his toes;
+G. Dismukes (USA), M. Kamrad (USA), P. Leroy (France), S. Michell
+(Canada), T. Taft (USA), J. Tokar (USA), and other members too numerous
+to mention.
+
+71.3/1
+Special thanks go to R. Duff (USA) for his explanations of the previous
+system of formatting of these documents during the tedious conversion to
+more modern formats. Special thanks also go to the convenor of ISO/IEC
+JTC 1/SC 22/WG 9, J. Moore (USA), without whose help and support the
+Corrigendum and this consolidated reference manual would not have been
+possible.
+
+Acknowledgements for the Amendment 1 version
+
+71.4/3
+The editor [R. Brukardt (USA)] would like to thank the many people whose
+hard work and assistance has made this update possible.
+
+71.5/2
+Thanks go out to all of the members of the ISO/IEC JTC 1/SC 22/WG 9 Ada
+Rapporteur Group, whose work on creating and editing the wording
+corrections was critical to the entire process. Especially valuable
+contributions came from the chairman of the ARG, P. Leroy (France), who
+kept the process on schedule; J. Barnes (UK) whose careful reviews found
+many typographical errors; T. Taft (USA), who always seemed to have a
+suggestion when we were stuck, and who also was usually able to provide
+the valuable service of explaining why things were as they are; S. Baird
+(USA), who found many obscure problems with the proposals; and A. Burns
+(UK), who pushed many of the real-time proposals to completion. Other
+ARG members who contributed were: R. Dewar (USA), G. Dismukes (USA), R.
+Duff (USA), K. Ishihata (Japan), S. Michell (Canada), E. Ploedereder
+(Germany), J.P. Rosen (France), E. Schonberg (USA), J. Tokar (USA), and
+T. Vardanega (Italy).
+
+71.6/2
+Special thanks go to Ada-Europe and the Ada Resource Association,
+without whose help and support the Amendment and this consolidated
+reference manual would not have been possible. M. Heaney (USA) requires
+special thanks for his tireless work on the containers packages.
+Finally, special thanks go to the convenor of ISO/IEC JTC 1/SC 22/WG 9,
+J. Moore (USA), who guided the document through the standardization
+process.
+
+Acknowledgements for the Ada 2012 edition
+
+71.7/3
+The editor [R. Brukardt (USA)] would like to thank the many people whose
+hard work and assistance has made this revision possible.
+
+71.8/3
+Thanks go out to all of the members of the ISO/IEC JTC 1/SC 22/WG 9 Ada
+Rapporteur Group, whose work on creating and editing the wording changes
+was critical to the entire process. Especially valuable contributions
+came from the chairman of the ARG, E. Schonberg (USA), who guided the
+work; T. Taft (USA), whose insights broke many logjams, both in design
+and wording; J. Barnes (UK) whose careful reviews uncovered many
+editorial errors; S. Baird (USA), who repeatedly found obscure
+interactions with the proposals that the rest of us missed. Other ARG
+members who substantially contributed were: A. Burns (UK), J. Cousins
+(UK), R. Dewar (USA), G. Dismukes (USA), R. Duff (USA), P. Leroy
+(France), B. Moore (Canada), E. Ploedereder (Germany), J.P. Rosen
+(France), B. Thomas (USA), and T. Vardanega (Italy).
+
+71.9/3
+Special thanks go to Ada-Europe and the Ada Resource Association,
+without whose help and support this third edition of the Ada Standard
+would not have been possible. A special mention has to go to A.
+Beneschan (USA) for his efforts in eliminating sloppiness in our
+wording. M. Heaney (USA) also deserves a mention for his efforts to
+improve the containers packages. Finally, special thanks go to the
+convenor of ISO/IEC JTC 1/SC 22/WG 9, J. Tokar (USA), who guided the
+document through the standardization process.
+
+Changes
+
+72
+The International Standard is the same as this version of the Reference
+Manual, except:
+
+73
+ * This list of Changes is not included in the International Standard.
+
+74
+ * The "Acknowledgements" page is not included in the International
+ Standard.
+
+75
+ * The text in the running headers and footers on each page is
+ slightly different in the International Standard.
+
+76
+ * The title page(s) are different in the International Standard.
+
+77
+ * This document is formatted for 8.5-by-11-inch paper, whereas the
+ International Standard is formatted for A4 paper (210-by-297mm);
+ thus, the page breaks are in different places.
+
+77.1/3
+ * This paragraph was deleted.
+
+77.2/3
+ * {AI05-0299-1AI05-0299-1} The "Using this version of the Ada
+ Reference Manual" subclause is not included in the International
+ Standard.
+
+77.3/3
+ * Paragraph numbers are not included in the International Standard.
+
+Using this version of the Ada Reference Manual
+
+77.4/3
+This document has been revised with the corrections specified in
+Technical Corrigendum 1 (ISO/IEC 8652:1995/COR.1:2001) and Amendment 1
+(ISO/IEC 8652/AMD 1:2007), along with changes specifically for this
+third edition. In addition, more annotations have been added and a
+variety of editorial errors have been corrected.
+
+77.5/3
+Changes to the original 8652:1995 can be identified by the version
+number following the paragraph number. Paragraphs with a version number
+of /1 were changed by Technical Corrigendum 1 or were editorial
+corrections at that time, while paragraphs with a version number of /2
+were changed by Amendment 1 or were more recent editorial corrections,
+and paragraphs with a version number of /3 were changed by the third
+(2012) edition of the Standard or were still more recent editorial
+corrections. Paragraphs not so marked are unchanged by the third
+edition, Amendment 1, Technical Corrigendum 1, or editorial corrections.
+Paragraph numbers of unchanged paragraphs are the same as in the 1995
+edition of the Ada Reference Manual. Inserted text is indicated by
+underlining, and deleted text is indicated by strikethroughs. Some
+versions also use color to indicate the version of the change.Where
+paragraphs are inserted, the paragraph numbers are of the form pp.nn,
+where pp is the number of the preceding paragraph, and nn is an
+insertion number. For instance, the first paragraph inserted after
+paragraph 8 is numbered 8.1, the second paragraph inserted is numbered
+8.2, and so on. Deleted paragraphs are indicated by the text This
+paragraph was deleted. Deleted paragraphs include empty paragraphs that
+were numbered in the 1995 edition of the Ada Reference Manual. Similar
+markings and numbering are used for changes to annotations.
+
+77.a/3
+ To be honest: The paragraph number is considered part of the
+ paragraph; when a paragraph is moved to a different paragraph
+ number, it is marked as changed even if the contents have not
+ changed.
+
+\1f
+File: aarm2012.info, Node: 0.99, Prev: 0.2, Up: Front Matter
+
+0.99
+====
+
+========== INTERNATIONAL STANDARD ISO/IEC 8652:2012(E)
+
+==========
+
+Information technology -- Programming
+Languages -- Ada
+
+
+
+\1f
+File: aarm2012.info, Node: 1, Next: 2, Prev: Front Matter, Up: Top
+
+1 General
+*********
+
+2.a/3
+ Discussion: This Annotated Ada Reference Manual (AARM)
+ contains the entire text of the third edition of the Ada
+ Reference Manual (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 *note 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.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 *note Annex N::, "*note 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.
+
+* Menu:
+
+* 1.1 :: Scope
+* 1.2 :: Normative References
+* 1.3 :: Terms and Definitions
+
+\1f
+File: aarm2012.info, Node: 1.1, Next: 1.2, Up: 1
+
+1.1 Scope
+=========
+
+1/3
+{AI05-0299-1AI05-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-1AI05-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/3
+{AI05-0269-1AI05-0269-1} {AI05-0299-1AI05-0299-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, and random number
+generation, and definition and use of containers.
+
+* Menu:
+
+* 1.1.1 :: Extent
+* 1.1.2 :: Structure
+* 1.1.3 :: Conformity of an Implementation with the Standard
+* 1.1.4 :: Method of Description and Syntax Notation
+* 1.1.5 :: Classification of Errors
+
+\1f
+File: aarm2012.info, Node: 1.1.1, Next: 1.1.2, Up: 1.1
+
+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.
+
+\1f
+File: aarm2012.info, Node: 1.1.2, Next: 1.1.3, Prev: 1.1.1, Up: 1.1
+
+1.1.2 Structure
+---------------
+
+1/3
+{AI05-0299-1AI05-0299-1} This International Standard contains thirteen
+clauses, fifteen annexes, and an index.
+
+1.a/3
+ Discussion: {AI05-0299-1AI05-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-1AI05-0299-1} Clauses 1 through 13
+
+4
+ * *note Annex A::, "*note Annex A:: Predefined Language Environment"
+
+5
+ * *note Annex B::, "*note Annex B:: Interface to Other Languages"
+
+6
+ * *note Annex J::, "*note Annex J:: Obsolescent Features"
+
+7
+The following Specialized Needs Annexes define features that are needed
+by certain application areas:
+
+8
+ * *note Annex C::, "*note Annex C:: Systems Programming"
+
+9
+ * *note Annex D::, "*note Annex D:: Real-Time Systems"
+
+10
+ * *note Annex E::, "*note Annex E:: Distributed Systems"
+
+11
+ * *note Annex F::, "*note Annex F:: Information Systems"
+
+12
+ * *note Annex G::, "*note Annex G:: Numerics"
+
+13
+ * *note Annex H::, "*note 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-1AI05-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
+ * *note Annex K::, "*note Annex K:: Language-Defined Aspects and
+ Attributes"
+
+20
+ * *note Annex L::, "*note Annex L:: Language-Defined Pragmas"
+
+21/3
+ * {AI05-0004-1AI05-0004-1} *note Annex M::, "*note Annex M:: Summary
+ of Documentation Requirements"
+
+22
+ * *note Annex N::, "*note Annex N:: Glossary"
+
+23
+ * *note Annex P::, "*note Annex P:: Syntax Summary"
+
+23.1/3
+ * {AI05-0262-1AI05-0262-1} *note Annex Q::, "*note 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 *note
+ 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-01AI95-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/3
+{AI05-0299-1AI05-0299-1} Each section 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-1AI05-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-1AI05-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 *note 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 *note 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 *note 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 *note M.3::,
+ "*note 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/3
+ 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/3
+ 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/3
+ 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/3
+ 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-1AI05-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/3
+ 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-1AI05-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/3
+ 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-1AI05-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/3
+ 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/3
+ 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/3
+ 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/3
+ 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/3
+ 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/3
+ This is not part of the definition of the language, and does
+ not appear in the Ada 2012 RM.
+
+\1f
+File: aarm2012.info, Node: 1.1.3, Next: 1.1.4, Prev: 1.1.2, Up: 1.1
+
+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 *note 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 *note A.7::);
+
+10
+ * The execution of certain code_statements (see *note 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 *note Annex B::), including
+ any parameters passed to it;
+
+12
+ * Any result returned or exception propagated from a main subprogram
+ (see *note 10.2::) or an exported subprogram (see *note 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/00948652/0094} {AI95-00119-01AI95-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 *note
+ C.6::);]
+
+14
+ * The values of imported and exported objects (see *note Annex B::)
+ at the time of any other interaction with the external environment.
+
+14.a/3
+ To be honest: {AI05-0229-1AI05-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 *note 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 *note
+ 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-1AI05-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 *note 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
+ *note M.2::, "*note 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.
+
+\1f
+File: aarm2012.info, Node: 1.1.4, Next: 1.1.5, Prev: 1.1.3, Up: 1.1
+
+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-01AI95-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 *note 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-01AI95-00285-01} {AI05-0004-1AI05-0004-1}
+{AI05-0262-1AI05-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 *note 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-01AI95-00395-01} {AI05-0227-1AI05-0227-1}
+{AI05-0299-1AI05-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
+ *note 11.6::, "*note 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-01AI95-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-01AI95-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-01AI95-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-1AI05-0227-1} Correction: Upper case is defined by
+ "simple upper case mapping", because "full case folding" is a
+ mapping (mostly) to lower case.
+
+\1f
+File: aarm2012.info, Node: 1.1.5, Prev: 1.1.4, Up: 1.1
+
+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, *note 10.1.3::, "*note
+ 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
+ *note 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.
+
+\1f
+File: aarm2012.info, Node: 1.2, Next: 1.3, Prev: 1.1, Up: 1
+
+1.2 Normative References
+========================
+
+1/3
+{AI05-0299-1AI05-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-2AI05-0127-2} {AI05-0299-1AI05-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-01AI95-00415-01} ISO/IEC 1539-1:2004, Information technology
+-- Programming languages -- Fortran -- Part 1: Base language.
+
+4/2
+{AI95-00415-01AI95-00415-01} ISO/IEC 1989:2002, Information technology
+-- Programming languages -- COBOL.
+
+4.1/3
+{AI05-0127-2AI05-0127-2} {AI05-0299-1AI05-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-01AI95-00351-01} ISO 8601:2004, Data elements and
+interchange formats -- Information interchange -- Representation of
+dates and times.
+
+6/3
+{AI05-0299-1AI05-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-01AI95-00415-01} {AI05-0266-1AI05-0266-1} ISO/IEC 9899:2011,
+Information technology -- Programming languages -- C.
+
+8/3
+{8652/00018652/0001} {AI95-00124-01AI95-00124-01}
+{AI95-00285-01AI95-00285-01} {AI05-0266-1AI05-0266-1} ISO/IEC
+10646:2011, Information technology -- Universal Multiple-Octet Coded
+Character Set (UCS).
+
+8.a.1/2
+ This paragraph was deleted.{8652/00018652/0001}
+ {AI95-00124-01AI95-00124-01} {AI95-00285-01AI95-00285-01}
+
+9/3
+{AI95-00376-01AI95-00376-01} {AI05-0266-1AI05-0266-1} ISO/IEC
+14882:2011, Information technology -- Programming languages -- C++.
+
+10/2
+{AI95-00285-01AI95-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-01AI95-00285-01} {AI95-00376-01AI95-00376-01}
+ {AI95-00415-01AI95-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-2AI05-0127-2} Added language and country code
+ standards for locale support.
+
+10.d/3
+ {AI05-0266-1AI05-0266-1} Updated references to the most recent
+ versions of these standards.
+
+\1f
+File: aarm2012.info, Node: 1.3, Prev: 1.2, Up: 1
+
+1.3 Terms and Definitions
+=========================
+
+1/2
+{AI95-00415-01AI95-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
+*note Annex N::, "*note Annex N:: Glossary".
+
+1.a
+ Discussion: The index contains an entry for every defined
+ term.
+
+1.a.1/2
+ {AI95-00415-01AI95-00415-01} The contents of the CRC Concise
+ Encyclopedia of Mathematics, Second Edition can be accessed on
+ http://www.mathworld.com (http://www.mathworld.com). The ISBN
+ number of the book is ISBN 1584883472.
+
+1.b
+ Glossary entry: Each term defined in *note 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).
+
+\1f
+File: aarm2012.info, Node: 2, Next: 3, Prev: 1, Up: Top
+
+2 Lexical Elements
+******************
+
+1/3
+{AI05-0299-1AI05-0299-1} [The text of a program consists of the texts of
+one or more compilations. The text of a compilation is a sequence of
+lexical elements, each composed of characters; the rules of composition
+are given in this clause. Pragmas, which provide certain information
+for the compiler, are also described in this clause.]
+
+* Menu:
+
+* 2.1 :: Character Set
+* 2.2 :: Lexical Elements, Separators, and Delimiters
+* 2.3 :: Identifiers
+* 2.4 :: Numeric Literals
+* 2.5 :: Character Literals
+* 2.6 :: String Literals
+* 2.7 :: Comments
+* 2.8 :: Pragmas
+* 2.9 :: Reserved Words
+
+\1f
+File: aarm2012.info, Node: 2.1, Next: 2.2, Up: 2
+
+2.1 Character Set
+=================
+
+1/3
+{AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+{AI05-0266-1AI05-0266-1} The character repertoire for the text of an Ada
+program consists of the entire coding space described by the ISO/IEC
+10646:2011 Universal Multiple-Octet Coded Character Set. This coding
+space is organized in planes, each plane comprising 65536 characters.
+
+1.a/2
+ This paragraph was deleted.{AI95-00285-01AI95-00285-01}
+
+1.b/2
+ This paragraph was deleted.{AI95-00285-01AI95-00285-01}
+
+1.c/3
+ Discussion: {AI95-00285-01AI95-00285-01}
+ {AI05-0266-1AI05-0266-1} It is our intent to follow the
+ terminology of ISO/IEC 10646:2011 where appropriate, and to
+ remain compatible with the character classifications defined
+ in *note A.3::, "*note A.3:: Character Handling".
+
+ _Syntax_
+
+ Paragraphs 2 and 3 were deleted.
+
+3.1/3
+ {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+ {AI05-0266-1AI05-0266-1} A character is defined by this
+ International Standard for each cell in the coding space described
+ by ISO/IEC 10646:2011, regardless of whether or not ISO/IEC
+ 10646:2011 allocates a character to that cell.
+
+ _Static Semantics_
+
+4/3
+{AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+{AI05-0079-1AI05-0079-1} {AI05-0262-1AI05-0262-1}
+{AI05-0266-1AI05-0266-1} The coded representation for characters is
+implementation defined [(it need not be a representation defined within
+ISO/IEC 10646:2011)]. A character whose relative code point in its
+plane is 16#FFFE# or 16#FFFF# is not allowed anywhere in the text of a
+program. The only characters allowed outside of comments are those in
+categories other_format, format_effector, and graphic_character.
+
+4.a
+ Implementation defined: The coded representation for the text
+ of an Ada program.
+
+4.b/2
+ Ramification: {AI95-00285-01AI95-00285-01} Note that this rule
+ doesn't really have much force, since the implementation can
+ represent characters in the source in any way it sees fit.
+ For example, an implementation could simply define that what
+ seems to be an other_private_use character is actually a
+ representation of the space character.
+
+4.1/3
+{AI95-00285-01AI95-00285-01} {AI05-0266-1AI05-0266-1}
+{AI05-0299-1AI05-0299-1} The semantics of an Ada program whose text is
+not in Normalization Form KC (as defined by Clause 21 of ISO/IEC
+10646:2011) is implementation defined.
+
+4.c/2
+ Implementation defined: The semantics of an Ada program whose
+ text is not in Normalization Form KC.
+
+5/3
+{AI95-00285-01AI95-00285-01} {AI05-0266-1AI05-0266-1}
+{AI05-0299-1AI05-0299-1} The description of the language definition in
+this International Standard uses the character properties General
+Category, Simple Uppercase Mapping, Uppercase Mapping, and Special Case
+Condition of the documents referenced by the note in Clause 1 of ISO/IEC
+10646:2011. The actual set of graphic symbols used by an implementation
+for the visual representation of the text of an Ada program is not
+specified.
+
+6/3
+{AI95-00285-01AI95-00285-01} {AI05-0266-1AI05-0266-1} Characters are
+categorized as follows:
+
+6.a/3
+ Discussion: {AI05-0005-1AI05-0005-1} {AI05-0262-1AI05-0262-1}
+ {AI05-0266-1AI05-0266-1} Our character classification
+ considers that the cells not allocated in ISO/IEC 10646:2011
+ are graphic characters, except for those whose relative code
+ point in their plane is 16#FFFE# or 16#FFFF#. This seems to
+ provide the best compatibility with future versions of ISO/IEC
+ 10646, as future characters can already be used in Ada
+ character and string literals.
+
+7/2
+
+ This paragraph was deleted.{AI95-00285-01AI95-00285-01}
+
+8/2
+{AI95-00285-01AI95-00285-01} letter_uppercase
+ Any character whose General Category is defined to be
+ "Letter, Uppercase".
+
+9/2
+{AI95-00285-01AI95-00285-01} letter_lowercase
+ Any character whose General Category is defined to be
+ "Letter, Lowercase".
+
+9.a/1
+ This paragraph was deleted.{8652/00018652/0001}
+ {AI95-00124-01AI95-00124-01}
+
+9.1/2
+{AI95-00285-01AI95-00285-01} letter_titlecase
+ Any character whose General Category is defined to be
+ "Letter, Titlecase".
+
+9.2/2
+{AI95-00285-01AI95-00285-01} letter_modifier
+ Any character whose General Category is defined to be
+ "Letter, Modifier".
+
+9.3/2
+{AI95-00285-01AI95-00285-01} letter_other
+ Any character whose General Category is defined to be
+ "Letter, Other".
+
+9.4/2
+{AI95-00285-01AI95-00285-01} mark_non_spacing
+ Any character whose General Category is defined to be
+ "Mark, Non-Spacing".
+
+9.5/2
+{AI95-00285-01AI95-00285-01} mark_spacing_combining
+ Any character whose General Category is defined to be
+ "Mark, Spacing Combining".
+
+10/2
+{AI95-00285-01AI95-00285-01} number_decimal
+ Any character whose General Category is defined to be
+ "Number, Decimal".
+
+10.1/2
+{AI95-00285-01AI95-00285-01} number_letter
+ Any character whose General Category is defined to be
+ "Number, Letter".
+
+10.2/2
+{AI95-00285-01AI95-00285-01} punctuation_connector
+ Any character whose General Category is defined to be
+ "Punctuation, Connector".
+
+10.3/2
+{AI95-00285-01AI95-00285-01} other_format
+ Any character whose General Category is defined to be
+ "Other, Format".
+
+11/2
+{AI95-00285-01AI95-00285-01} separator_space
+ Any character whose General Category is defined to be
+ "Separator, Space".
+
+12/2
+{AI95-00285-01AI95-00285-01} separator_line
+ Any character whose General Category is defined to be
+ "Separator, Line".
+
+12.1/2
+{AI95-00285-01AI95-00285-01} separator_paragraph
+ Any character whose General Category is defined to be
+ "Separator, Paragraph".
+
+13/3
+{AI95-00285-01AI95-00285-01} {AI05-0262-1AI05-0262-1} format_effector
+ The characters whose code points are 16#09# (CHARACTER
+ TABULATION), 16#0A# (LINE FEED), 16#0B# (LINE
+ TABULATION), 16#0C# (FORM FEED), 16#0D# (CARRIAGE
+ RETURN), 16#85# (NEXT LINE), and the characters in
+ categories separator_line and separator_paragraph.
+
+13.a/2
+ Discussion: ISO/IEC 10646:2003 does not define the names of
+ control characters, but rather refers to the names defined by
+ ISO/IEC 6429:1992. These are the names that we use here.
+
+13.1/2
+{AI95-00285-01AI95-00285-01} other_control
+ Any character whose General Category is defined to be
+ "Other, Control", and which is not defined to be a
+ format_effector.
+
+13.2/2
+{AI95-00285-01AI95-00285-01} other_private_use
+ Any character whose General Category is defined to be
+ "Other, Private Use".
+
+13.3/2
+{AI95-00285-01AI95-00285-01} other_surrogate
+ Any character whose General Category is defined to be
+ "Other, Surrogate".
+
+14/3
+{AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+{AI05-0262-1AI05-0262-1} graphic_character
+ Any character that is not in the categories
+ other_control, other_private_use, other_surrogate,
+ format_effector, and whose relative code point in its
+ plane is neither 16#FFFE# nor 16#FFFF#.
+
+14.a/2
+ This paragraph was deleted.
+
+14.b/2
+ Discussion: {AI95-00285-01AI95-00285-01} We considered basing
+ the definition of lexical elements on Annex A of ISO/IEC TR
+ 10176 (4th edition), which lists the characters which should
+ be supported in identifiers for all programming languages, but
+ we finally decided against this option. Note that it is not
+ our intent to diverge from ISO/IEC TR 10176, except to the
+ extent that ISO/IEC TR 10176 itself diverges from ISO/IEC
+ 10646:2003 (which is the case at the time of this writing
+ [January 2005]).
+
+14.c/2
+ More precisely, we intend to align strictly with ISO/IEC
+ 10646:2003. It must be noted that ISO/IEC TR 10176 is a
+ Technical Report while ISO/IEC 10646:2003 is a Standard. If
+ one has to make a choice, one should conform with the Standard
+ rather than with the Technical Report. And, it turns out that
+ one must make a choice because there are important differences
+ between the two:
+
+14.d/2
+ * ISO/IEC TR 10176 is still based on ISO/IEC 10646:2000
+ while ISO/IEC 10646:2003 has already been published for a
+ year. We cannot afford to delay the adoption of our
+ amendment until ISO/IEC TR 10176 has been revised.
+
+14.e/2
+ * There are considerable differences between the two
+ editions of ISO/IEC 10646, notably in supporting
+ characters beyond the BMP (this might be significant for
+ some languages, e.g. Korean).
+
+14.f/2
+ * ISO/IEC TR 10176 does not define case conversion tables,
+ which are essential for a case-insensitive language like
+ Ada. To get case conversion tables, we would have to
+ reference either ISO/IEC 10646:2003 or Unicode, or we
+ would have to invent our own.
+
+14.g/2
+ For the purpose of defining the lexical elements of the
+ language, we need character properties like categorization, as
+ well as case conversion tables. These are mentioned in
+ ISO/IEC 10646:2003 as useful for implementations, with a
+ reference to Unicode. Machine-readable tables are available
+ on the web at URLs:
+
+14.h/2
+ http://www.unicode.org/Public/4.0-Update/UnicodeData-4.0.0.txt (http://www.unicode.org/Public/4.0-Update/UnicodeData-4.0.0.txt)
+ http://www.unicode.org/Public/4.0-Update/CaseFolding-4.0.0.txt (http://www.unicode.org/Public/4.0-Update/CaseFolding-4.0.0.txt)
+
+14.i/2
+ with an explanatory document found at URL:
+
+14.j/2
+ http://www.unicode.org/Public/4.0-Update/UCD-4.0.0.html (http://www.unicode.org/Public/4.0-Update/UCD-4.0.0.html)
+
+14.k/2
+ The actual text of the standard only makes specific references
+ to the corresponding clauses of ISO/IEC 10646:2003, not to
+ Unicode.
+
+15/3
+{AI95-00285-01AI95-00285-01} {AI05-0266-1AI05-0266-1} The following
+names are used when referring to certain characters (the first name is
+that given in ISO/IEC 10646:2011):
+
+15.a/3
+ Discussion: {AI95-00285-01AI95-00285-01}
+ {AI05-0266-1AI05-0266-1} This table serves to show the
+ correspondence between ISO/IEC 10646:2011 names and the
+ graphic symbols (glyphs) used in this International Standard.
+ These are the characters that play a special role in the
+ syntax of Ada.
+
+ graphic symbol name graphic symbol name
+ " quotation mark : colon
+ # number sign ; semicolon
+ & ampersand < less-than sign
+ ' apostrophe, tick = equals sign
+ ( left parenthesis > greater-than sign
+ ) right parenthesis _ low line, underline
+ * asterisk, multiply | vertical line
+ + plus sign / solidus, divide
+ , comma ! exclamation point
+ - hyphen-minus, minus % percent sign
+ . full stop, dot, point
+
+ _Implementation Requirements_
+
+16/3
+{AI05-0286-1AI05-0286-1} An Ada implementation shall accept Ada source
+code in UTF-8 encoding, with or without a BOM (see *note A.4.11::),
+where every character is represented by its code point. The character
+pair CARRIAGE RETURN/LINE FEED (code points 16#0D# 16#0A#) signifies a
+single end of line (see *note 2.2::); every other occurrence of a
+format_effector other than the character whose code point position is
+16#09# (CHARACTER TABULATION) also signifies a single end of line.
+
+16.a/3
+ Reason: {AI05-0079-1AI05-0079-1} {AI05-0286-1AI05-0286-1} This
+ is simply requiring that an Ada implementation be able to
+ directly process the ACATS, which is provided in the described
+ format. Note that files that only contain characters with
+ code points in the first 128 (which is the majority of the
+ ACATS) are represented in the same way in both UTF-8 and in
+ "plain" string format. The ACATS includes a BOM in files that
+ have any characters with code points greater than 127. Note
+ that the BOM contains characters not legal in Ada source code,
+ so an implementation can use that to automatically distinguish
+ between files formatted as plain Latin-1 strings and UTF-8
+ with BOM.
+
+16.b/3
+ We allow line endings to be both represented as the pair CR LF
+ (as in Windows and the ACATS), and as single format_effector
+ characters (usually LF, as in Linux), in order that files
+ created by standard tools on most operating systems will meet
+ the standard format. We specify how many line endings each
+ represent so that compilers use the same line numbering for
+ standard source files.
+
+16.c/3
+ This requirement increases portability by having a format that
+ is accepted by all Ada compilers. Note that implementations
+ can support other source representations, including structured
+ representations like a parse tree.
+
+ _Implementation Permissions_
+
+17/3
+{AI95-00285-01AI95-00285-01} {AI05-0266-1AI05-0266-1} The categories
+defined above, as well as case mapping and folding, may be based on an
+implementation-defined version of ISO/IEC 10646 (2003 edition or later).
+
+17.b/3
+ Ramification: The exact categories, case mapping, and case
+ folding chosen affects identifiers, the result of
+ '[[Wide_]Wide_]Image, and packages Wide_Characters.Handling
+ and Wide_Wide_Characters.Handling.
+
+17.c/3
+ Discussion: This permission allows implementations to upgrade
+ to using a newer character set standard whenever that makes
+ sense, rather than having to wait for the next Ada Standard.
+ But the character set standard used cannot be older than
+ ISO/IEC 10646:2003 (which is essentially similar to Unicode
+ 4.0).
+
+ NOTES
+
+18/2
+ 1 {AI95-00285-01AI95-00285-01} The characters in categories
+ other_control, other_private_use, and other_surrogate are only
+ allowed in comments.
+
+19.a/3
+ This paragraph was deleted.{AI05-0286-1AI05-0286-1}
+
+ _Extensions to Ada 83_
+
+19.b
+ Ada 95 allows 8-bit and 16-bit characters, as well as
+ implementation-specified character sets.
+
+ _Wording Changes from Ada 83_
+
+19.c/3
+ {AI95-00285-01AI95-00285-01} {AI05-0299-1AI05-0299-1} The
+ syntax rules in this subclause are modified to remove the
+ emphasis on basic characters vs. others. (In this day and
+ age, there is no need to point out that you can write programs
+ without using (for example) lower case letters.) In
+ particular, character (representing all characters usable
+ outside comments) is added, and basic_graphic_character,
+ other_special_character, and basic_character are removed.
+ Special_character is expanded to include Ada 83's
+ other_special_character, as well as new 8-bit characters not
+ present in Ada 83. Ada 2005 removes special_character
+ altogether; we want to stick to ISO/IEC 10646:2003 character
+ classifications. Note that the term "basic letter" is used in
+ *note A.3::, "*note A.3:: Character Handling" to refer to
+ letters without diacritical marks.
+
+19.d/2
+ {AI95-00285-01AI95-00285-01} Character names now come from
+ ISO/IEC 10646:2003.
+
+19.e/2
+ This paragraph was deleted.{AI95-00285-01AI95-00285-01}
+
+ _Extensions to Ada 95_
+
+19.f/2
+ {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+ Program text can use most characters defined by
+ ISO-10646:2003. This subclause has been rewritten to use the
+ categories defined in that Standard. This should ease
+ programming in languages other than English.
+
+ _Inconsistencies With Ada 2005_
+
+19.g/3
+ {AI05-0299-1AI05-0299-1} {AI05-0266-1AI05-0266-1} An
+ implementation is allowed (but not required) to use a newer
+ character set standard to determine the categories, case
+ mapping, and case folding. Doing so will change the results
+ of attributes '[[Wide_]Wide_]Image and the packages
+ [Wide_]Wide_Characters.Handling in the case of a few rarely
+ used characters. (This also could make some identifiers
+ illegal, for characters that are no longer classified as
+ letters.) This is unlikely to be a problem in practice.
+ Moreover, truly portable Ada 2012 programs should avoid using
+ in these contexts any characters that would have different
+ classifications in any character set standards issued since
+ 10646:2003 (since the compiler can use any such standard as
+ the basis for its classifications).
+
+ _Wording Changes from Ada 2005_
+
+19.h/3
+ {AI05-0079-1AI05-0079-1} Correction: Clarified that only
+ characters in the categories defined here are allowed in the
+ source of an Ada program. This was clear in Ada 95, but
+ Amendment 1 dropped the wording instead of correcting it.
+
+19.i/3
+ {AI05-0286-1AI05-0286-1} A standard source representation is
+ defined that all compilers are expected to process. Since
+ this is the same format as the ACATS, it seems unlikely that
+ there are any implementations that don't meet this
+ requirement. Moreover, other representations are still
+ permitted, and the "impossible or impractical" loophole (see
+ *note 1.1.3::) can be invoked for any implementations that
+ cannot directly process the ACATS.
+
+\1f
+File: aarm2012.info, Node: 2.2, Next: 2.3, Prev: 2.1, Up: 2
+
+2.2 Lexical Elements, Separators, and Delimiters
+================================================
+
+ _Static Semantics_
+
+1
+The text of a program consists of the texts of one or more compilations.
+The text of each compilation is a sequence of separate lexical elements.
+Each lexical element is formed from a sequence of characters, and is
+either a delimiter, an identifier, a reserved word, a numeric_literal, a
+character_literal, a string_literal, or a comment. The meaning of a
+program depends only on the particular sequences of lexical elements
+that form its compilations, excluding comments.
+
+2/3
+{AI95-00285-01AI95-00285-01} {AI05-0262-1AI05-0262-1} The text of a
+compilation is divided into lines. In general, the representation for
+an end of line is implementation defined. However, a sequence of one or
+more format_effectors other than the character whose code point is
+16#09# (CHARACTER TABULATION) signifies at least one end of line.
+
+2.a
+ Implementation defined: The representation for an end of line.
+
+3/2
+{AI95-00285-01AI95-00285-01} [In some cases an explicit separator is
+required to separate adjacent lexical elements.] A separator is any of
+a separator_space, a format_effector, or the end of a line, as follows:
+
+4/2
+ * {AI95-00285-01AI95-00285-01} A separator_space is a separator
+ except within a comment, a string_literal, or a character_literal.
+
+5/3
+ * {AI95-00285-01AI95-00285-01} {AI05-0262-1AI05-0262-1} The character
+ whose code point is 16#09# (CHARACTER TABULATION) is a separator
+ except within a comment.
+
+6
+ * The end of a line is always a separator.
+
+7
+One or more separators are allowed between any two adjacent lexical
+elements, before the first of each compilation, or after the last. At
+least one separator is required between an identifier, a reserved word,
+or a numeric_literal and an adjacent identifier, reserved word, or
+numeric_literal.
+
+7.1/3
+{AI05-0079-1AI05-0079-1} One or more other_format characters are allowed
+anywhere that a separator is[; any such characters have no effect on the
+meaning of an Ada program].
+
+8/2
+{AI95-00285-01AI95-00285-01} A delimiter is either one of the following
+characters:
+
+9
+ & ' ( ) * + , - . / : ; < = > |
+
+10
+or one of the following compound delimiters each composed of two
+adjacent special characters
+
+11
+ => .. ** := /= >= <= << >> <>
+
+12
+Each of the special characters listed for single character delimiters is
+a single delimiter except if this character is used as a character of a
+compound delimiter, or as a character of a comment, string_literal,
+character_literal, or numeric_literal.
+
+13
+The following names are used when referring to compound delimiters:
+
+ delimiter name=> arrow
+.. double dot
+** double star, exponentiate
+:= assignment (pronounced: "becomes")
+/= inequality (pronounced: "not equal")
+>= greater than or equal
+<= less than or equal
+<< left label bracket
+>> right label bracket
+<> box
+ _Implementation Requirements_
+
+14
+An implementation shall support lines of at least 200 characters in
+length, not counting any characters used to signify the end of a line.
+An implementation shall support lexical elements of at least 200
+characters in length. The maximum supported line length and lexical
+element length are implementation defined.
+
+14.a
+ Implementation defined: Maximum supported line length and
+ lexical element length.
+
+14.b
+ Discussion: From URG recommendation.
+
+ _Wording Changes from Ada 95_
+
+14.c/3
+ {AI95-00285-01AI95-00285-01} {AI05-0299-1AI05-0299-1} The
+ wording was updated to use the new character categories
+ defined in the preceding subclause.
+
+ _Extensions to Ada 2005_
+
+14.d/3
+ {AI05-0079-1AI05-0079-1} Correction: Clarified that
+ other_format characters are allowed anywhere that separators
+ are allowed. This was intended in Ada 2005, but didn't
+ actually make it into the wording.
+
+\1f
+File: aarm2012.info, Node: 2.3, Next: 2.4, Prev: 2.2, Up: 2
+
+2.3 Identifiers
+===============
+
+1
+Identifiers are used as names.
+
+ _Syntax_
+
+2/2
+ {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+ identifier ::=
+ identifier_start {identifier_start | identifier_extend}
+
+3/2
+ {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+ identifier_start ::=
+ letter_uppercase
+ | letter_lowercase
+ | letter_titlecase
+ | letter_modifier
+ | letter_other
+ | number_letter
+
+3.1/3
+ {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+ {AI05-0091-1AI05-0091-1} identifier_extend ::=
+ mark_non_spacing
+ | mark_spacing_combining
+ | number_decimal
+ | punctuation_connector
+
+4/3
+ {AI95-00395-01AI95-00395-01} {AI05-0091-1AI05-0091-1} An identifier
+ shall not contain two consecutive characters in category
+ punctuation_connector, or end with a character in that category.
+
+4.a/3
+ Reason: This rule was stated in the syntax in Ada 95, but that
+ has gotten too complex in Ada 2005.
+
+ _Static Semantics_
+
+5/3
+{AI95-00285-01AI95-00285-01} {AI05-0091-1AI05-0091-1}
+{AI05-0227-1AI05-0227-1} {AI05-0266-1AI05-0266-1}
+{AI05-0299-1AI05-0299-1} Two identifiers are considered the same if they
+consist of the same sequence of characters after applying
+locale-independent simple case folding, as defined by documents
+referenced in the note in Clause 1 of ISO/IEC 10646:2011.
+
+5.a/3
+ Discussion: {AI05-0227-1AI05-0227-1} Simple case folding is a
+ mapping to lower case, so this is matching the defining (lower
+ case) version of a reserved word. We could have mentioned
+ case folding of the reserved words, but as that is an identity
+ function, it would have no effect.
+
+5.a.1/3
+ {AI05-0227-1AI05-0227-1} The "documents referenced" means
+ Unicode. Note that simple case folding is supposed to be
+ compatible between Unicode versions, so the Unicode version
+ used doesn't matter.
+
+5.3/3
+{AI95-00395-01AI95-00395-01} {AI05-0091-1AI05-0091-1}
+{AI05-0227-1AI05-0227-1} After applying simple case folding, an
+identifier shall not be identical to a reserved word.
+
+5.b/3
+ Implementation Note: We match the reserved words after
+ applying case folding so that the rules for identifiers and
+ reserved words are the same. Since a compiler usually will
+ lexically process identifiers and reserved words the same way
+ (often with the same code), this will prevent a lot of
+ headaches.
+
+5.c/3
+ Ramification: {AI05-0227-1AI05-0227-1} The rules for reserved
+ words differ in one way: they define case conversion on
+ letters rather than sequences. This means that it is possible
+ that there exist some unusual sequences that are neither
+ identifiers nor reserved words. We are not aware of any such
+ sequences so long as we use simple case folding (as opposed to
+ full case folding), but we have defined the rules in case any
+ are introduced in future character set standards. This
+ originally was a problem when converting to upper case: "if"
+ and "acceß" have upper case conversions of "IF" and "ACCESS"
+ respectively. We would not want these to be treated as
+ reserved words. But neither of these cases exist when using
+ simple case folding.
+
+ _Implementation Permissions_
+
+6
+In a nonstandard mode, an implementation may support other upper/lower
+case equivalence rules for identifiers[, to accommodate local
+conventions].
+
+6.a/3
+ Discussion: {AI95-00285-01AI95-00285-01}
+ {AI05-0227-1AI05-0227-1} For instance, in most languages, the
+ simple case folded equivalent of LATIN CAPITAL LETTER I (an
+ upper case letter without a dot above) is LATIN SMALL LETTER I
+ (a lower case letter with a dot above). In Turkish, though,
+ LATIN CAPITAL LETTER I and LATIN CAPITAL LETTER I WITH DOT
+ ABOVE are two distinct letters, so the case folded equivalent
+ of LATIN CAPITAL LETTER I is LATIN SMALL LETTER DOTLESS I, and
+ the case folded equivalent of LATIN CAPITAL LETTER I WITH DOT
+ ABOVE is LATIN SMALL LETTER I. Take for instance the following
+ identifier (which is the name of a city on the Tigris river in
+ Eastern Anatolia):
+
+6.b/3
+ DIYARBAKIR -- The first i is dotted, the second isn't.
+
+6.c/3
+ A Turkish reader would expect that the above identifier is
+ equivalent to:
+
+6.d/3
+ diyarbakir
+
+6.d.1/3
+ However, locale-independent simple case folding (and thus Ada)
+ maps this to:
+
+6.d.2/3
+ dIyarbakir
+
+6.e/3
+ which is different from any of the following identifiers:
+
+6.f/2
+ diyarbakir
+ diyarbakir
+ diyarbakir
+ diyarbakir
+
+6.f.1/3
+ including the "correct" matching identifier for Turkish.
+ Upper case conversion (used in '[Wide_]Wide_Image) introduces
+ additional problems.
+
+6.g/3
+ An implementation targeting the Turkish market is allowed (in
+ fact, expected) to provide a nonstandard mode where case
+ folding is appropriate for Turkish.
+
+6.j/2
+ Lithuanian and Azeri are two other languages that present
+ similar idiosyncrasies.
+
+ NOTES
+
+6.1/2
+ 2 {AI95-00285-01AI95-00285-01} Identifiers differing only in the
+ use of corresponding upper and lower case letters are considered
+ the same.
+
+ _Examples_
+
+7
+Examples of identifiers:
+
+8/2
+ {AI95-00433-01AI95-00433-01} Count X Get_Symbol Ethelyn Marion
+ Snobol_4 X1 Page_Count Store_Next_Item
+ [Unicode 928][Unicode 955][Unicode 940][Unicode 964][Unicode 969][Unicode 957] -- Plato
+ [Unicode 1063][Unicode 1072][Unicode 1081][Unicode 1082][Unicode 1086][Unicode 1074][Unicode 1089][Unicode 1082][Unicode 1080][Unicode 1081] -- Tchaikovsky
+ [Unicode 952] [Unicode 966] -- Angles
+
+ _Wording Changes from Ada 83_
+
+8.a
+ We no longer include reserved words as identifiers. This is
+ not a language change. In Ada 83, identifier included
+ reserved words. However, this complicated several other rules
+ (for example, regarding implementation-defined attributes and
+ pragmas, etc.). We now explicitly allow certain reserved
+ words for attribute designators, to make up for the loss.
+
+8.b
+ Ramification: Because syntax rules are relevant to overload
+ resolution, it means that if it looks like a reserved word, it
+ is not an identifier. As a side effect, implementations
+ cannot use reserved words as implementation-defined attributes
+ or pragma names.
+
+ _Extensions to Ada 95_
+
+8.c/2
+ {AI95-00285-01AI95-00285-01} An identifier can use any letter
+ defined by ISO-10646:2003, along with several other
+ categories. This should ease programming in languages other
+ than English.
+
+ _Incompatibilities With Ada 2005_
+
+8.d/3
+ {AI05-0091-1AI05-0091-1} Correction: other_format characters
+ were removed from identifiers as the Unicode recommendations
+ have changed. This change can only affect programs written
+ for the original Ada 2005, so there should be few such
+ programs.
+
+8.e/3
+ {AI05-0227-1AI05-0227-1} Correction: We now specify simple
+ case folding rather than full case folding. That potentially
+ could change identifier equivalence, although it is more
+ likely that identifiers that are considered the same in
+ original Ada 2005 will now be considered different. This
+ change was made because the original Ada 2005 definition was
+ incompatible (and even inconsistent in unusual cases) with the
+ Ada 95 identifier equivalence rules. As such, the Ada 2005
+ rules were rarely fully implemented, and in any case, only Ada
+ 2005 identifiers containing wide characters could be affected.
+
+\1f
+File: aarm2012.info, Node: 2.4, Next: 2.5, Prev: 2.3, Up: 2
+
+2.4 Numeric Literals
+====================
+
+1
+There are two kinds of numeric_literals, real literals and integer
+literals. A real literal is a numeric_literal that includes a point; an
+integer literal is a numeric_literal without a point.
+
+ _Syntax_
+
+2
+ numeric_literal ::= decimal_literal | based_literal
+
+ NOTES
+
+3
+ 3 The type of an integer literal is universal_integer. The type
+ of a real literal is universal_real.
+
+* Menu:
+
+* 2.4.1 :: Decimal Literals
+* 2.4.2 :: Based Literals
+
+\1f
+File: aarm2012.info, Node: 2.4.1, Next: 2.4.2, Up: 2.4
+
+2.4.1 Decimal Literals
+----------------------
+
+1
+A decimal_literal is a numeric_literal in the conventional decimal
+notation (that is, the base is ten).
+
+ _Syntax_
+
+2
+ decimal_literal ::= numeral [.numeral] [exponent]
+
+3
+ numeral ::= digit {[underline] digit}
+
+4
+ exponent ::= E [+] numeral | E - numeral
+
+4.1/2
+ {AI95-00285-01AI95-00285-01} digit ::=
+ 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
+
+5
+ An exponent for an integer literal shall not have a minus sign.
+
+5.a
+ Ramification: Although this rule is in this subclause, it
+ applies also to the next subclause.
+
+ _Static Semantics_
+
+6
+An underline character in a numeric_literal does not affect its meaning.
+The letter E of an exponent can be written either in lower case or in
+upper case, with the same meaning.
+
+6.a
+ Ramification: Although these rules are in this subclause, they
+ apply also to the next subclause.
+
+7
+An exponent indicates the power of ten by which the value of the
+decimal_literal without the exponent is to be multiplied to obtain the
+value of the decimal_literal with the exponent.
+
+ _Examples_
+
+8
+Examples of decimal literals:
+
+9
+ 12 0 1E6 123_456 -- integer literals
+
+ 12.0 0.0 0.456 3.14159_26 -- real literals
+
+ _Wording Changes from Ada 83_
+
+9.a
+ We have changed the syntactic category name integer to be
+ numeral. We got this idea from ACID. It avoids the confusion
+ between this and integers. (Other places don't offer similar
+ confusions. For example, a string_literal is different from a
+ string.)
+
+\1f
+File: aarm2012.info, Node: 2.4.2, Prev: 2.4.1, Up: 2.4
+
+2.4.2 Based Literals
+--------------------
+
+1
+[ A based_literal is a numeric_literal expressed in a form that
+specifies the base explicitly.]
+
+ _Syntax_
+
+2
+ based_literal ::=
+ base # based_numeral [.based_numeral] # [exponent]
+
+3
+ base ::= numeral
+
+4
+ based_numeral ::=
+ extended_digit {[underline] extended_digit}
+
+5
+ extended_digit ::= digit | A | B | C | D | E | F
+
+ _Legality Rules_
+
+6
+The base (the numeric value of the decimal numeral preceding the first
+#) shall be at least two and at most sixteen. The extended_digits A
+through F represent the digits ten through fifteen, respectively. The
+value of each extended_digit of a based_literal shall be less than the
+base.
+
+ _Static Semantics_
+
+7
+The conventional meaning of based notation is assumed. An exponent
+indicates the power of the base by which the value of the based_literal
+without the exponent is to be multiplied to obtain the value of the
+based_literal with the exponent. The base and the exponent, if any, are
+in decimal notation.
+
+8
+The extended_digits A through F can be written either in lower case or
+in upper case, with the same meaning.
+
+ _Examples_
+
+9
+Examples of based literals:
+
+10
+ 2#1111_1111# 16#FF# 016#0ff# -- integer literals of value 255
+ 16#E#E1 2#1110_0000# -- integer literals of value 224
+ 16#F.FF#E+2 2#1.1111_1111_1110#E11 -- real literals of value 4095.0
+
+ _Wording Changes from Ada 83_
+
+10.a
+ The rule about which letters are allowed is now encoded in
+ BNF, as suggested by Mike Woodger. This is clearly more
+ readable.
+
+\1f
+File: aarm2012.info, Node: 2.5, Next: 2.6, Prev: 2.4, Up: 2
+
+2.5 Character Literals
+======================
+
+1
+[A character_literal is formed by enclosing a graphic character between
+two apostrophe characters.]
+
+ _Syntax_
+
+2
+ character_literal ::= 'graphic_character'
+
+ NOTES
+
+3
+ 4 A character_literal is an enumeration literal of a character
+ type. See *note 3.5.2::.
+
+ _Examples_
+
+4
+Examples of character literals:
+
+5/2
+ {AI95-00433-01AI95-00433-01} 'A' '*' ''' ' '
+ 'L' '[Unicode 1051]' '[Unicode 923]' -- Various els.
+ '[Unicode 8734]' '[Unicode 1488]' -- Big numbers - infinity and aleph.
+
+ _Wording Changes from Ada 83_
+
+5.a/3
+ {AI05-0299-1AI05-0299-1} The definitions of the values of
+ literals are in Clauses 3 and 4, rather than here, since it
+ requires knowledge of types.
+
+\1f
+File: aarm2012.info, Node: 2.6, Next: 2.7, Prev: 2.5, Up: 2
+
+2.6 String Literals
+===================
+
+1
+[A string_literal is formed by a sequence of graphic characters
+(possibly none) enclosed between two quotation marks used as string
+brackets. They are used to represent operator_symbols (see *note
+6.1::), values of a string type (see *note 4.2::), and array
+subaggregates (see *note 4.3.3::). ]
+
+ _Syntax_
+
+2
+ string_literal ::= "{string_element}"
+
+3
+ string_element ::= "" | non_quotation_mark_graphic_character
+
+4
+ A string_element is either a pair of quotation marks (""), or a
+ single graphic_character other than a quotation mark.
+
+ _Static Semantics_
+
+5
+The sequence of characters of a string_literal is formed from the
+sequence of string_elements between the bracketing quotation marks, in
+the given order, with a string_element that is "" becoming a single
+quotation mark in the sequence of characters, and any other
+string_element being reproduced in the sequence.
+
+6
+A null string literal is a string_literal with no string_elements
+between the quotation marks.
+
+ NOTES
+
+7
+ 5 An end of line cannot appear in a string_literal.
+
+7.1/2
+ 6 {AI95-00285-01AI95-00285-01} No transformation is performed on
+ the sequence of characters of a string_literal.
+
+ _Examples_
+
+8
+Examples of string literals:
+
+9/2
+ {AI95-00433-01AI95-00433-01} "Message of the day:"
+
+ "" -- a null string literal
+ " " "A" """" -- three string literals of length 1
+
+ "Characters such as $, %, and } are allowed in string literals"
+ "Archimedes said ""[Unicode 917][Unicode 973][Unicode 961][Unicode 951][Unicode 954][Unicode 945]"""
+ "Volume of cylinder (PIr²h) = "
+
+ _Wording Changes from Ada 83_
+
+9.a
+ The wording has been changed to be strictly lexical. No
+ mention is made of string or character values, since
+ string_literals are also used to represent operator_symbols,
+ which don't have a defined value.
+
+9.b
+ The syntax is described differently.
+
+ _Wording Changes from Ada 95_
+
+9.c/2
+ {AI95-00285-01AI95-00285-01} We explicitly say that the
+ characters of a string_literal should be used as is. In
+ particular, no normalization or folding should be performed on
+ a string_literal.
+
+\1f
+File: aarm2012.info, Node: 2.7, Next: 2.8, Prev: 2.6, Up: 2
+
+2.7 Comments
+============
+
+1
+A comment starts with two adjacent hyphens and extends up to the end of
+the line.
+
+ _Syntax_
+
+2
+ comment ::= --{non_end_of_line_character}
+
+3
+ A comment may appear on any line of a program.
+
+ _Static Semantics_
+
+4
+The presence or absence of comments has no influence on whether a
+program is legal or illegal. Furthermore, comments do not influence the
+meaning of a program; their sole purpose is the enlightenment of the
+human reader.
+
+ _Examples_
+
+5
+Examples of comments:
+
+6
+ -- the last sentence above echoes the Algol 68 report
+
+ end; -- processing of Line is complete
+
+ -- a long comment may be split onto
+ -- two or more consecutive lines
+
+ ---------------- the first two hyphens start the comment
+
+\1f
+File: aarm2012.info, Node: 2.8, Next: 2.9, Prev: 2.7, Up: 2
+
+2.8 Pragmas
+===========
+
+1
+A pragma is a compiler directive. There are language-defined pragmas
+that give instructions for optimization, listing control, etc. An
+implementation may support additional (implementation-defined) pragmas.
+
+ _Language Design Principles_
+
+1.a/3
+ {AI05-0100-1AI05-0100-1} {AI05-0163-1AI05-0163-1} In general,
+ if all pragmas are treated as unrecognized pragmas, the
+ program should remain both syntactically and semantically
+ legal. There are a few exceptions to this general principle
+ (for example, pragma Import can eliminate the need for a
+ completion), but the principle remains, and is strictly true
+ at the syntactic level. Certainly any implementation-defined
+ pragmas should obey this principle both syntactically and
+ semantically, so that if the pragmas are not recognized by
+ some other implementation, the program will remain legal.
+
+ _Syntax_
+
+2
+ pragma ::=
+ pragma identifier [(pragma_argument_association {,
+ pragma_argument_association})];
+
+3/3
+ {AI05-0290-1AI05-0290-1} pragma_argument_association ::=
+ [pragma_argument_identifier =>] name
+ | [pragma_argument_identifier =>] expression
+ | pragma_argument_aspect_mark => name
+ | pragma_argument_aspect_mark => expression
+
+4/3
+ {AI05-0290-1AI05-0290-1} In a pragma, any
+ pragma_argument_associations without a pragma_argument_identifier
+ or pragma_argument_aspect_mark shall precede any associations with
+ a pragma_argument_identifier or pragma_argument_aspect_mark.
+
+5
+ Pragmas are only allowed at the following places in a program:
+
+6
+ * After a semicolon delimiter, but not within a formal_part or
+ discriminant_part.
+
+7/3
+ * {AI05-0100-1AI05-0100-1} {AI05-0163-1AI05-0163-1} At any place
+ where the syntax rules allow a construct defined by a
+ syntactic category whose name ends with "declaration", "item",
+ "statement", "clause", or "alternative", or one of the
+ syntactic categories variant or exception_handler; but not in
+ place of such a construct if the construct is required, or is
+ part of a list that is required to have at least one such
+ construct.
+
+7.1/3
+ * {AI05-0163-1AI05-0163-1} In place of a statement in a
+ sequence_of_statements.
+
+7.2/3
+ * {AI05-0100-1AI05-0100-1} At any place where a compilation_unit
+ is allowed.
+
+8
+ Additional syntax rules and placement restrictions exist for
+ specific pragmas.
+
+8.a
+ Discussion: The above rule is written in text, rather than in
+ BNF; the syntactic category pragma is not used in any BNF
+ syntax rule.
+
+8.b
+ Ramification: A pragma is allowed where a
+ generic_formal_parameter_declaration is allowed.
+
+9
+The name of a pragma is the identifier following the reserved word
+pragma. The name or expression of a pragma_argument_association is a
+pragma argument.
+
+9.a/2
+ To be honest: {AI95-00284-02AI95-00284-02} For compatibility
+ with Ada 83, the name of a pragma may also be "interface",
+ which is not an identifier (because it is a reserved word).
+ See *note J.12::.
+
+10/3
+{AI05-0272-1AI05-0272-1} An identifier specific to a pragma is an
+identifier or reserved word that is used in a pragma argument with
+special meaning for that pragma.
+
+10.a
+ To be honest: Whenever the syntax rules for a given pragma
+ allow "identifier" as an argument of the pragma, that
+ identifier is an identifier specific to that pragma.
+
+10.b/3
+ {AI05-0272-1AI05-0272-1} In a few cases, a reserved word is
+ allowed as "an identifier specific to a pragma". Even in
+ these cases, the syntax still is written as identifier (the
+ reserved word(s) are not shown). For example, the restriction
+ No_Use_Of_Attribute (see *note 13.12.1::) allows the reserved
+ words which can be attribute designators, but the syntax for a
+ restriction does not include these reserved words.
+
+ _Static Semantics_
+
+11
+If an implementation does not recognize the name of a pragma, then it
+has no effect on the semantics of the program. Inside such a pragma,
+the only rules that apply are the Syntax Rules.
+
+11.a
+ To be honest: This rule takes precedence over any other rules
+ that imply otherwise.
+
+11.b
+ Ramification: Note well: this rule applies only to pragmas
+ whose name is not recognized. If anything else is wrong with
+ a pragma (at compile time), the pragma is illegal. This is
+ true whether the pragma is language defined or implementation
+ defined.
+
+11.c
+ For example, an expression in an unrecognized pragma does not
+ cause freezing, even though the rules in *note 13.14::, "*note
+ 13.14:: Freezing Rules" say it does; the above rule overrules
+ those other rules. On the other hand, an expression in a
+ recognized pragma causes freezing, even if this makes
+ something illegal.
+
+11.d
+ For another example, an expression that would be ambiguous is
+ not illegal if it is inside an unrecognized pragma.
+
+11.e
+ Note, however, that implementations have to recognize pragma
+ Inline(Foo) and freeze things accordingly, even if they choose
+ to never do inlining.
+
+11.f
+ Obviously, the contradiction needs to be resolved one way or
+ the other. The reasons for resolving it this way are: The
+ implementation is simple -- the compiler can just ignore the
+ pragma altogether. The interpretation of constructs appearing
+ inside implementation-defined pragmas is implementation
+ defined. For example: "pragma Mumble(X);". If the current
+ implementation has never heard of Mumble, then it doesn't know
+ whether X is a name, an expression, or an identifier specific
+ to the pragma Mumble.
+
+11.g
+ To be honest: The syntax of individual pragmas overrides the
+ general syntax for pragma.
+
+11.h
+ Ramification: Thus, an identifier specific to a pragma is not
+ a name, syntactically; if it were, the visibility rules would
+ be invoked, which is not what we want.
+
+11.i/3
+ {AI05-0229-1AI05-0229-1} This also implies that named
+ associations do not allow one to give the arguments in an
+ arbitrary order -- the order given in the syntax rule for each
+ individual pragma must be obeyed. However, it is generally
+ possible to leave out earlier arguments when later ones are
+ given; for example, this is allowed by the syntax rule for
+ pragma Import (see *note J.15.5::, "*note J.15.5:: Interfacing
+ Pragmas"). As for subprogram calls, positional notation
+ precedes named notation.
+
+11.j
+ Note that Ada 83 had no pragmas for which the order of named
+ associations mattered, since there was never more than one
+ argument that allowed named associations.
+
+11.k
+ To be honest: The interpretation of the arguments of
+ implementation-defined pragmas is implementation defined.
+ However, the syntax rules have to be obeyed.
+
+ _Dynamic Semantics_
+
+12
+Any pragma that appears at the place of an executable construct is
+executed. Unless otherwise specified for a particular pragma, this
+execution consists of the evaluation of each evaluable pragma argument
+in an arbitrary order.
+
+12.a
+ Ramification: For a pragma that appears at the place of an
+ elaborable construct, execution is elaboration.
+
+12.b
+ An identifier specific to a pragma is neither a name nor an
+ expression -- such identifiers are not evaluated (unless an
+ implementation defines them to be evaluated in the case of an
+ implementation-defined pragma).
+
+12.c
+ The "unless otherwise specified" part allows us (and
+ implementations) to make exceptions, so a pragma can contain
+ an expression that is not evaluated. Note that pragmas in
+ type_definitions may contain expressions that depend on
+ discriminants.
+
+12.d
+ When we wish to define a pragma with some run-time effect, we
+ usually make sure that it appears in an executable context;
+ otherwise, special rules are needed to define the run-time
+ effect and when it happens.
+
+ _Implementation Requirements_
+
+13
+The implementation shall give a warning message for an unrecognized
+pragma name.
+
+13.a
+ Ramification: An implementation is also allowed to have modes
+ in which a warning message is suppressed, or in which the
+ presence of an unrecognized pragma is a compile-time error.
+
+ _Implementation Permissions_
+
+14
+An implementation may provide implementation-defined pragmas; the name
+of an implementation-defined pragma shall differ from those of the
+language-defined pragmas.
+
+14.a
+ Implementation defined: Implementation-defined pragmas.
+
+14.b
+ Ramification: The semantics of implementation-defined pragmas,
+ and any associated rules (such as restrictions on their
+ placement or arguments), are, of course, implementation
+ defined. Implementation-defined pragmas may have run-time
+ effects.
+
+15
+An implementation may ignore an unrecognized pragma even if it violates
+some of the Syntax Rules, if detecting the syntax error is too complex.
+
+15.a
+ Reason: Many compilers use extra post-parsing checks to
+ enforce the syntax rules, since the Ada syntax rules are not
+ LR(k) (for any k). (The grammar is ambiguous, in fact.) This
+ paragraph allows them to ignore an unrecognized pragma,
+ without having to perform such post-parsing checks.
+
+ _Implementation Advice_
+
+16/3
+{AI05-0163-1AI05-0163-1} Normally, implementation-defined pragmas should
+have no semantic effect for error-free programs; that is, if the
+implementation-defined pragmas in a working program are replaced with
+unrecognized pragmas, the program should still be legal, and should
+still have the same semantics.
+
+16.a.1/2
+ Implementation Advice: Implementation-defined pragmas should
+ have no semantic effect for error-free programs.
+
+16.a
+ Ramification: Note that "semantics" is not the same as
+ "effect;" as explained in *note 1.1.3::, the semantics defines
+ a set of possible effects.
+
+16.b
+ Note that adding a pragma to a program might cause an error
+ (either at compile time or at run time). On the other hand,
+ if the language-specified semantics for a feature are in part
+ implementation defined, it makes sense to support pragmas that
+ control the feature, and that have real semantics; thus, this
+ paragraph is merely a recommendation.
+
+17
+Normally, an implementation should not define pragmas that can make an
+illegal program legal, except as follows:
+
+18/3
+ * {AI05-0229-1AI05-0229-1} A pragma used to complete a declaration;
+
+18.a/3
+ Discussion: {AI05-0229-1AI05-0229-1} There are no
+ language-defined pragmas which can be completions; pragma
+ Import was defined this way in Ada 95 and Ada 2005, but in Ada
+ 2012 pragma Import just sets aspect Import which disallows
+ having any completion.
+
+19
+ * A pragma used to configure the environment by adding, removing, or
+ replacing library_items.
+
+19.a.1/2
+ Implementation Advice: Implementation-defined pragmas should
+ not make an illegal program legal, unless they complete a
+ declaration or configure the library_items in an environment.
+
+19.a
+ Ramification: For example, it is OK to support Interface,
+ System_Name, Storage_Unit, and Memory_Size pragmas for upward
+ compatibility reasons, even though all of these pragmas can
+ make an illegal program legal. (The latter three can affect
+ legality in a rather subtle way: They affect the value of
+ named numbers in System, and can therefore affect the legality
+ in cases where static expressions are required.)
+
+19.b
+ On the other hand, adding implementation-defined pragmas to a
+ legal program can make it illegal. For example, a common kind
+ of implementation-defined pragma is one that promises some
+ property that allows more efficient code to be generated. If
+ the promise is a lie, it is best if the user gets an error
+ message.
+
+ _Incompatibilities With Ada 83_
+
+19.c
+ In Ada 83, "bad" pragmas are ignored. In Ada 95, they are
+ illegal, except in the case where the name of the pragma
+ itself is not recognized by the implementation.
+
+ _Extensions to Ada 83_
+
+19.d
+ Implementation-defined pragmas may affect the legality of a
+ program.
+
+ _Wording Changes from Ada 83_
+
+19.e
+ Implementation-defined pragmas may affect the run-time
+ semantics of the program. This was always true in Ada 83
+ (since it was not explicitly forbidden by RM83), but it was
+ not clear, because there was no definition of "executing" or
+ "elaborating" a pragma.
+
+ _Extensions to Ada 2005_
+
+19.f/3
+ {AI05-0163-1AI05-0163-1} Correction: Allow pragmas in place of
+ a statement, even if there are no other statements in a
+ sequence_of_statements.
+
+19.g/3
+ {AI05-0272-1AI05-0272-1} Identifiers specific to a pragma can
+ be reserved words.
+
+19.h/3
+ {AI05-0290-1AI05-0290-1} Pragma arguments can be identified
+ with aspect_marks; this allows identifier'Class in this
+ context. As usual, this is only allowed if specifically
+ allowed by a particular pragma.
+
+ _Wording Changes from Ada 2005_
+
+19.i/3
+ {AI05-0100-1AI05-0100-1} Correction: Clarified where pragmas
+ are (and are not) allowed.
+
+ _Syntax_
+
+20
+ The forms of List, Page, and Optimize pragmas are as follows:
+
+21
+ pragma List(identifier);
+
+22
+ pragma Page;
+
+23
+ pragma Optimize(identifier);
+
+24
+ [Other pragmas are defined throughout this International Standard,
+ and are summarized in *note Annex L::.]
+
+24.a
+ Ramification: The language-defined pragmas are supported by
+ every implementation, although "supporting" some of them (for
+ example, Inline) requires nothing more than checking the
+ arguments, since they act only as advice to the
+ implementation.
+
+ _Static Semantics_
+
+25
+A pragma List takes one of the identifiers On or Off as the single
+argument. This pragma is allowed anywhere a pragma is allowed. It
+specifies that listing of the compilation is to be continued or
+suspended until a List pragma with the opposite argument is given within
+the same compilation. The pragma itself is always listed if the
+compiler is producing a listing.
+
+26
+A pragma Page is allowed anywhere a pragma is allowed. It specifies
+that the program text which follows the pragma should start on a new
+page (if the compiler is currently producing a listing).
+
+27
+A pragma Optimize takes one of the identifiers Time, Space, or Off as
+the single argument. This pragma is allowed anywhere a pragma is
+allowed, and it applies until the end of the immediately enclosing
+declarative region, or for a pragma at the place of a compilation_unit,
+to the end of the compilation. It gives advice to the implementation as
+to whether time or space is the primary optimization criterion, or that
+optional optimizations should be turned off. [It is implementation
+defined how this advice is followed.]
+
+27.a
+ Implementation defined: Effect of pragma Optimize.
+
+27.b
+ Discussion: For example, a compiler might use Time vs. Space
+ to control whether generic instantiations are implemented with
+ a macro-expansion model, versus a shared-generic-body model.
+
+27.c
+ We don't define what constitutes an "optimization" -- in fact,
+ it cannot be formally defined in the context of Ada. One
+ compiler might call something an optional optimization,
+ whereas another compiler might consider that same thing to be
+ a normal part of code generation. Thus, the programmer cannot
+ rely on this pragma having any particular portable effect on
+ the generated code. Some compilers might even ignore the
+ pragma altogether.
+
+ _Examples_
+
+28
+Examples of pragmas:
+
+29/3
+ {AI95-00433-01AI95-00433-01} {AI05-0229-1AI05-0229-1} pragma List(Off); -- turn off listing generation
+ pragma Optimize(Off); -- turn off optional optimizations
+ pragma Pure(Rational_Numbers); -- set categorization for package
+ pragma Assert(Exists(File_Name),
+ Message => "Nonexistent file"); -- assert file exists
+
+ _Extensions to Ada 83_
+
+29.a
+ The Optimize pragma now allows the identifier Off to request
+ that normal optimization be turned off.
+
+29.b
+ An Optimize pragma may appear anywhere pragmas are allowed.
+
+ _Wording Changes from Ada 83_
+
+29.c
+ We now describe the pragmas Page, List, and Optimize here, to
+ act as examples, and to remove the normative material from
+ *note Annex L::, "*note Annex L:: Language-Defined Pragmas",
+ so it can be entirely an informative annex.
+
+ _Wording Changes from Ada 95_
+
+29.d/2
+ {AI95-00433-01AI95-00433-01} Updated the example of named
+ pragma parameters, because the second parameter of pragma
+ Suppress is obsolescent.
+
+ _Wording Changes from Ada 2005_
+
+29.e/3
+ {AI05-0229-1AI05-0229-1} Updated the example of pragmas,
+ because both pragmas Inline and Import are obsolescent.
+
+\1f
+File: aarm2012.info, Node: 2.9, Prev: 2.8, Up: 2
+
+2.9 Reserved Words
+==================
+
+ _Syntax_
+
+1/1
+ This paragraph was deleted.
+
+2/3
+ {AI95-00284-02AI95-00284-02} {AI95-00395-01AI95-00395-01}
+ {AI05-0091-1AI05-0091-1} The following are the reserved words.
+ Within a program, some or all of the letters of a reserved word may
+ be in upper case.
+
+2.a
+ Discussion: Reserved words have special meaning in the syntax.
+ In addition, certain reserved words are used as attribute
+ names.
+
+2.b
+ The syntactic category identifier no longer allows reserved
+ words. We have added the few reserved words that are legal
+ explicitly to the syntax for attribute_reference. Allowing
+ identifier to include reserved words has been a source of
+ confusion for some users, and differs from the way they are
+ treated in the C and Pascal language definitions.
+
+abort else new return
+abs elsif not reverse
+abstract end null
+accept entry select
+access exception of separate
+aliased exit or some
+all others subtype
+and for out synchronized
+array function overriding
+at tagged
+ generic package task
+begin goto pragma terminate
+body private then
+ if procedure type
+case in protected
+constant interface until
+ is raise use
+declare range
+delay limited record when
+delta loop rem while
+digits renames with
+do mod requeue
+ xor
+
+ NOTES
+
+3
+ 7 The reserved words appear in lower case boldface in this
+ International Standard, except when used in the designator of an
+ attribute (see *note 4.1.4::). Lower case boldface is also used
+ for a reserved word in a string_literal used as an operator_symbol.
+ This is merely a convention -- programs may be written in whatever
+ typeface is desired and available.
+
+ _Incompatibilities With Ada 83_
+
+3.a
+ The following words are not reserved in Ada 83, but are
+ reserved in Ada 95: abstract, aliased, protected, requeue,
+ tagged, until.
+
+ _Wording Changes from Ada 83_
+
+3.b/3
+ {AI05-0299-1AI05-0299-1} The subclause entitled "Allowed
+ Replacements of Characters" has been moved to *note Annex J::,
+ "*note Annex J:: Obsolescent Features".
+
+ _Incompatibilities With Ada 95_
+
+3.c/2
+ {AI95-00284-02AI95-00284-02} The following words are not
+ reserved in Ada 95, but are reserved in Ada 2005: interface,
+ overriding, synchronized. A special allowance is made for
+ pragma Interface (see *note J.12::). Uses of these words as
+ identifiers will need to be changed, but we do not expect them
+ to be common.
+
+ _Wording Changes from Ada 95_
+
+3.d/2
+ {AI95-00395-01AI95-00395-01} The definition of upper case
+ equivalence has been modified to allow identifiers using all
+ of the characters of ISO 10646. This change has no effect on
+ the character sequences that are reserved words, but does make
+ some unusual sequences of characters illegal.
+
+ _Incompatibilities With Ada 2005_
+
+3.e/3
+ {AI05-0091-1AI05-0091-1} Correction: Removed other_format
+ characters from reserved words in order to be compatible with
+ the latest Unicode recommendations. This change can only
+ affect programs written for original Ada 2005, and there is
+ little reason to put other_format characters into reserved
+ words in the first place, so there should be very few such
+ programs.
+
+3.f/3
+ {AI05-0176-1AI05-0176-1} The following word is not reserved in
+ Ada 2005, but is reserved in Ada 2012: some. Uses of this
+ word as an identifier will need to be changed, but we do not
+ expect them to be common.
+
+\1f
+File: aarm2012.info, Node: 3, Next: 4, Prev: 2, Up: Top
+
+3 Declarations and Types
+************************
+
+1/3
+{AI05-0299-1AI05-0299-1} This clause describes the types in the language
+and the rules for declaring constants, variables, and named numbers.
+
+* Menu:
+
+* 3.1 :: Declarations
+* 3.2 :: Types and Subtypes
+* 3.3 :: Objects and Named Numbers
+* 3.4 :: Derived Types and Classes
+* 3.5 :: Scalar Types
+* 3.6 :: Array Types
+* 3.7 :: Discriminants
+* 3.8 :: Record Types
+* 3.9 :: Tagged Types and Type Extensions
+* 3.10 :: Access Types
+* 3.11 :: Declarative Parts
+
+\1f
+File: aarm2012.info, Node: 3.1, Next: 3.2, Up: 3
+
+3.1 Declarations
+================
+
+1
+The language defines several kinds of named entities that are declared
+by declarations. The entity's name is defined by the declaration,
+usually by a defining_identifier (*note 3.1: S0022.), but sometimes by a
+defining_character_literal (*note 3.5.1: S0040.) or
+defining_operator_symbol (*note 6.1: S0171.).
+
+2
+There are several forms of declaration. A basic_declaration is a form
+of declaration defined as follows.
+
+ _Syntax_
+
+3/3
+ {AI95-00348-01AI95-00348-01} {AI05-0177-1AI05-0177-1}
+ basic_declaration ::=
+ type_declaration | subtype_declaration
+ | object_declaration | number_declaration
+ | subprogram_declaration | abstract_subprogram_declaration
+ | null_procedure_declaration | expression_function_declaration
+ | package_declaration | renaming_declaration
+ | exception_declaration | generic_declaration
+ | generic_instantiation
+
+4
+ defining_identifier ::= identifier
+
+ _Static Semantics_
+
+5
+A declaration is a language construct that associates a name with (a
+view of) an entity. A declaration may appear explicitly in the program
+text (an explicit declaration), or may be supposed to occur at a given
+place in the text as a consequence of the semantics of another construct
+(an implicit declaration).
+
+5.a
+ Discussion: An implicit declaration generally declares a
+ predefined or inherited operation associated with the
+ definition of a type. This term is used primarily when
+ allowing explicit declarations to override implicit
+ declarations, as part of a type declaration.
+
+6/3
+{AI95-00318-02AI95-00318-02} {AI05-0255-1AI05-0255-1}
+{AI05-0277-1AI05-0277-1} Each of the following is defined to be a
+declaration: any basic_declaration (*note 3.1: S0021.); an
+enumeration_literal_specification (*note 3.5.1: S0039.); a
+discriminant_specification (*note 3.7: S0062.); a component_declaration
+(*note 3.8: S0070.); a loop_parameter_specification (*note 5.5: S0158.);
+an iterator_specification (*note 5.5.2: S0159.); a
+parameter_specification (*note 6.1: S0175.); a subprogram_body (*note
+6.3: S0177.); an extended_return_object_declaration (*note 6.5: S0185.);
+an entry_declaration (*note 9.5.2: S0218.); an entry_index_specification
+(*note 9.5.2: S0224.); a choice_parameter_specification (*note 11.2:
+S0267.); a generic_formal_parameter_declaration (*note 12.1: S0274.).
+
+6.a
+ Discussion: This list (when basic_declaration is expanded out)
+ contains all syntactic categories that end in "_declaration"
+ or "_specification", except for program unit _specifications.
+ Moreover, it contains subprogram_body. A subprogram_body is a
+ declaration, whether or not it completes a previous
+ declaration. This is a bit strange, subprogram_body is not
+ part of the syntax of basic_declaration or
+ library_unit_declaration. A renaming-as-body is considered a
+ declaration. An accept_statement is not considered a
+ declaration. Completions are sometimes declarations, and
+ sometimes not.
+
+7
+All declarations contain a definition for a view of an entity. A view
+consists of an identification of the entity (the entity of the view),
+plus view-specific characteristics that affect the use of the entity
+through that view (such as mode of access to an object, formal parameter
+names and defaults for a subprogram, or visibility to components of a
+type). In most cases, a declaration also contains the definition for
+the entity itself (a renaming_declaration is an example of a declaration
+that does not define a new entity, but instead defines a view of an
+existing entity (see *note 8.5::)).
+
+7.a/2
+ Glossary entry: A view of an entity reveals some or all of the
+ properties of the entity. A single entity may have multiple
+ views.
+
+7.b
+ Discussion: Most declarations define a view (of some entity)
+ whose view-specific characteristics are unchanging for the
+ life of the view. However, subtypes are somewhat unusual in
+ that they inherit characteristics from whatever view of their
+ type is currently visible. Hence, a subtype is not a view of
+ a type; it is more of an indirect reference. By contrast, a
+ private type provides a single, unchanging (partial) view of
+ its full type.
+
+7.1/3
+{AI05-0080-1AI05-0080-1} When it is clear from context, the term object
+is used in place of view of an object. Similarly, the terms type and
+subtype are used in place of view of a type and view of a subtype,
+respectively.
+
+7.c/3
+ Discussion: Rules interpreted at compile time generally refer
+ to views of entities, rather than the entities themselves.
+ This is necessary to preserve privacy; characteristics that
+ are not visible should not be used in compile-time rules.
+ Thus, Static Semantics and Legality Rules generally implicitly
+ have "view of". Legality Rules that need to look into the
+ private part are the exception to this interpretation.
+
+7.d/3
+ On the other hand, run-time rules can work either way, so
+ "view of" should not be assumed in Dynamic Semantics rules.
+
+8
+For each declaration, the language rules define a certain region of text
+called the scope of the declaration (see *note 8.2::). Most
+declarations associate an identifier with a declared entity. Within its
+scope, and only there, there are places where it is possible to use the
+identifier to refer to the declaration, the view it defines, and the
+associated entity; these places are defined by the visibility rules (see
+*note 8.3::). At such places the identifier is said to be a name of the
+entity (the direct_name or selector_name); the name is said to denote
+the declaration, the view, and the associated entity (see *note 8.6::).
+The declaration is said to declare the name, the view, and in most
+cases, the entity itself.
+
+9
+As an alternative to an identifier, an enumeration literal can be
+declared with a character_literal as its name (see *note 3.5.1::), and a
+function can be declared with an operator_symbol as its name (see *note
+6.1::).
+
+10
+The syntax rules use the terms defining_identifier,
+defining_character_literal (*note 3.5.1: S0040.), and
+defining_operator_symbol (*note 6.1: S0171.) for the defining occurrence
+of a name; these are collectively called defining names. The terms
+direct_name and selector_name are used for usage occurrences of
+identifiers, character_literals, and operator_symbols. These are
+collectively called usage names.
+
+10.a
+ To be honest: The terms identifier, character_literal, and
+ operator_symbol are used directly in contexts where the normal
+ visibility rules do not apply (such as the identifier that
+ appears after the end of a task_body). Analogous conventions
+ apply to the use of designator, which is the collective term
+ for identifier and operator_symbol.
+
+ _Dynamic Semantics_
+
+11
+The process by which a construct achieves its run-time effect is called
+execution. This process is also called elaboration for declarations and
+evaluation for expressions. One of the terms execution, elaboration, or
+evaluation is defined by this International Standard for each construct
+that has a run-time effect.
+
+11.a
+ Glossary entry: The process by which a construct achieves its
+ run-time effect is called execution. Execution of a
+ declaration is also called elaboration. Execution of an
+ expression is also called evaluation.
+
+11.b
+ To be honest: The term elaboration is also used for the
+ execution of certain constructs that are not declarations, and
+ the term evaluation is used for the execution of certain
+ constructs that are not expressions. For example,
+ subtype_indications are elaborated, and ranges are evaluated.
+
+11.c
+ For bodies, execution and elaboration are both explicitly
+ defined. When we refer specifically to the execution of a
+ body, we mean the explicit definition of execution for that
+ kind of body, not its elaboration.
+
+11.d
+ Discussion: Technically, "the execution of a declaration" and
+ "the elaboration of a declaration" are synonymous. We use the
+ term "elaboration" of a construct when we know the construct
+ is elaborable. When we are talking about more arbitrary
+ constructs, we use the term "execution". For example, we use
+ the term "erroneous execution", to refer to any erroneous
+ execution, including erroneous elaboration or evaluation.
+
+11.e
+ When we explicitly define evaluation or elaboration for a
+ construct, we are implicitly defining execution of that
+ construct.
+
+11.f
+ We also use the term "execution" for things like statements,
+ which are executable, but neither elaborable nor evaluable.
+ We considered using the term "execution" only for
+ nonelaborable, nonevaluable constructs, and defining the term
+ "action" to mean what we have defined "execution" to mean. We
+ rejected this idea because we thought three terms that mean
+ the same thing was enough -- four would be overkill. Thus,
+ the term "action" is used only informally in the standard
+ (except where it is defined as part of a larger term, such as
+ "protected action").
+
+11.f.1/2
+ Glossary entry: The process by which a declaration achieves
+ its run-time effect is called elaboration. Elaboration is one
+ of the forms of execution.
+
+11.f.2/2
+ Glossary entry: The process by which an expression achieves
+ its run-time effect is called evaluation. Evaluation is one
+ of the forms of execution.
+
+11.g
+ To be honest: A construct is elaborable if elaboration is
+ defined for it. A construct is evaluable if evaluation is
+ defined for it. A construct is executable if execution is
+ defined for it.
+
+11.h
+ Discussion: Don't confuse "elaborable" with "preelaborable"
+ (defined in *note 10.2.1::).
+
+11.i/2
+ {AI95-00114-01AI95-00114-01} Evaluation of an evaluable
+ construct produces a result that is either a value, a
+ denotation, or a range. The following are evaluable:
+ expression; name prefix; range; entry_index_specification; and
+ possibly discrete_range. The last one is curious -- RM83 uses
+ the term "evaluation of a discrete_range," but never defines
+ it. One might presume that the evaluation of a discrete_range
+ consists of the evaluation of the range or the
+ subtype_indication, depending on what it is. But
+ subtype_indications are not evaluated; they are elaborated.
+
+11.j
+ Intuitively, an executable construct is one that has a defined
+ run-time effect (which may be null). Since execution includes
+ elaboration and evaluation as special cases, all elaborable
+ and all evaluable constructs are also executable. Hence, most
+ constructs in Ada are executable. An important exception is
+ that the constructs inside a generic unit are not executable
+ directly, but rather are used as a template for (generally)
+ executable constructs in instances of the generic.
+
+ NOTES
+
+12
+ 1 At compile time, the declaration of an entity declares the
+ entity. At run time, the elaboration of the declaration creates
+ the entity.
+
+12.a
+ Ramification: Syntactic categories for declarations are named
+ either entity_declaration (if they include a trailing
+ semicolon) or entity_specification (if not).
+
+12.b
+ The various kinds of named entities that can be declared are
+ as follows: an object (including components and parameters), a
+ named number, a type (the name always refers to its first
+ subtype), a subtype, a subprogram (including enumeration
+ literals and operators), a single entry, an entry family, a
+ package, a protected or task unit (which corresponds to either
+ a type or a single object), an exception, a generic unit, a
+ label, and the name of a statement.
+
+12.c
+ Identifiers are also associated with names of pragmas,
+ arguments to pragmas, and with attributes, but these are not
+ user-definable.
+
+ _Wording Changes from Ada 83_
+
+12.d
+ The syntax rule for defining_identifier is new. It is used
+ for the defining occurrence of an identifier. Usage
+ occurrences use the direct_name or selector_name syntactic
+ categories. Each occurrence of an identifier (or
+ simple_name), character_literal, or operator_symbol in the Ada
+ 83 syntax rules is handled as follows in Ada 95:
+
+12.e
+ * It becomes a defining_identifier,
+ defining_character_literal, or defining_operator_symbol
+ (or some syntactic category composed of these), to
+ indicate a defining occurrence;
+
+12.f/3
+ * {AI05-0299-1AI05-0299-1} It becomes a direct_name, in
+ usage occurrences where the usage is required (in Clause
+ *note 8::) to be directly visible;
+
+12.g/3
+ * {AI05-0299-1AI05-0299-1} It becomes a selector_name, in
+ usage occurrences where the usage is required (in Clause
+ *note 8::) to be visible but not necessarily directly
+ visible;
+
+12.h
+ * It remains an identifier, character_literal, or
+ operator_symbol, in cases where the visibility rules do
+ not apply (such as the designator that appears after the
+ end of a subprogram_body).
+
+12.i
+ For declarations that come in "two parts" (program unit
+ declaration plus body, private or incomplete type plus full
+ type, deferred constant plus full constant), we consider both
+ to be defining occurrences. Thus, for example, the syntax for
+ package_body uses defining_identifier after the reserved word
+ body, as opposed to direct_name.
+
+12.j
+ The defining occurrence of a statement name is in its implicit
+ declaration, not where it appears in the program text.
+ Considering the statement name itself to be the defining
+ occurrence would complicate the visibility rules.
+
+12.k
+ The phrase "visible by selection" is not used in Ada 95. It
+ is subsumed by simply "visible" and the Name Resolution Rules
+ for selector_names.
+
+12.l/3
+ {AI05-0299-1AI05-0299-1} (Note that in Ada 95, a declaration
+ is visible at all places where one could have used a
+ selector_name, not just at places where a selector_name was
+ actually used. Thus, the places where a declaration is
+ directly visible are a subset of the places where it is
+ visible. See Clause *note 8:: for details.)
+
+12.m
+ We use the term "declaration" to cover _specifications that
+ declare (views of) objects, such as parameter_specifications.
+ In Ada 83, these are referred to as a "form of declaration,"
+ but it is not entirely clear that they are considered simply
+ "declarations."
+
+12.n/3
+ {AI05-0299-1AI05-0299-1} RM83 contains an incomplete
+ definition of "elaborated" in this subclause: it defines
+ "elaborated" for declarations, declarative_parts,
+ declarative_items and compilation_units, but "elaboration" is
+ defined elsewhere for various other constructs. To make
+ matters worse, Ada 95 has a different set of elaborable
+ constructs. Instead of correcting the list, it is more
+ maintainable to refer to the term "elaborable," which is
+ defined in a distributed manner.
+
+12.o
+ RM83 uses the term "has no other effect" to describe an
+ elaboration that doesn't do anything except change the state
+ from not-yet-elaborated to elaborated. This was a confusing
+ wording, because the answer to "other than what?" was to be
+ found many pages away. In Ada 95, we change this wording to
+ "has no effect" (for things that truly do nothing at run
+ time), and "has no effect other than to establish that
+ so-and-so can happen without failing the Elaboration_Check"
+ (for things where it matters).
+
+12.p
+ We make it clearer that the term "execution" covers
+ elaboration and evaluation as special cases. This was implied
+ in RM83. For example, "erroneous execution" can include any
+ execution, and RM83-9.4(3) has, "The task designated by any
+ other task object depends on the master whose execution
+ creates the task object;" the elaboration of the master's
+ declarative_part is doing the task creation.
+
+ _Wording Changes from Ada 95_
+
+12.q/2
+ {AI95-00318-02AI95-00318-02} Added extended_return_statement
+ to the list of declarations.
+
+12.r/2
+ {AI95-00348-01AI95-00348-01} Added null procedures (see *note
+ 6.7::) to the syntax.
+
+ _Wording Changes from Ada 2005_
+
+12.s/3
+ {AI05-0177-1AI05-0177-1} Added expression functions (see *note
+ 6.8::) to the syntax.
+
+\1f
+File: aarm2012.info, Node: 3.2, Next: 3.3, Prev: 3.1, Up: 3
+
+3.2 Types and Subtypes
+======================
+
+ _Static Semantics_
+
+1
+A type is characterized by a set of values, and a set of primitive
+operations which implement the fundamental aspects of its semantics. An
+object of a given type is a run-time entity that contains (has) a value
+of the type.
+
+1.a/2
+ Glossary entry: Each object has a type. A type has an
+ associated set of values, and a set of primitive operations
+ which implement the fundamental aspects of its semantics.
+ Types are grouped into categories. Most language-defined
+ categories of types are also classes of types.
+
+1.b/3
+ Glossary entry: A subtype is a type together with optional
+ constraints, null exclusions, and predicates, which constrain
+ the values of the subtype to satisfy certain conditions. The
+ values of a subtype are a subset of the values of its type.
+
+2/2
+{AI95-00442-01AI95-00442-01} Types are grouped into categories of types.
+There exist several language-defined categories of types (see NOTES
+below), reflecting the similarity of their values and primitive
+operations. [Most categories of types form classes of types.]
+Elementary types are those whose values are logically indivisible;
+composite types are those whose values are composed of component values.
+
+2.a/2
+ Proof: {AI95-00442-01AI95-00442-01} The formal definition of
+ category and class is found in *note 3.4::.
+
+2.b/2
+ Glossary entry: A class is a set of types that is closed under
+ derivation, which means that if a given type is in the class,
+ then all types derived from that type are also in the class.
+ The set of types of a class share common properties, such as
+ their primitive operations.
+
+2.b.1/2
+ Glossary entry: A category of types is a set of types with one
+ or more common properties, such as primitive operations. A
+ category of types that is closed under derivation is also
+ known as a class.
+
+2.c
+ Glossary entry: An elementary type does not have components.
+
+2.d/2
+ Glossary entry: A composite type may have components.
+
+2.e
+ Glossary entry: A scalar type is either a discrete type or a
+ real type.
+
+2.f
+ Glossary entry: An access type has values that designate
+ aliased objects. Access types correspond to "pointer types"
+ or "reference types" in some other languages.
+
+2.g
+ Glossary entry: A discrete type is either an integer type or
+ an enumeration type. Discrete types may be used, for example,
+ in case_statements and as array indices.
+
+2.h
+ Glossary entry: A real type has values that are approximations
+ of the real numbers. Floating point and fixed point types are
+ real types.
+
+2.i
+ Glossary entry: Integer types comprise the signed integer
+ types and the modular types. A signed integer type has a base
+ range that includes both positive and negative numbers, and
+ has operations that may raise an exception when the result is
+ outside the base range. A modular type has a base range whose
+ lower bound is zero, and has operations with "wraparound"
+ semantics. Modular types subsume what are called "unsigned
+ types" in some other languages.
+
+2.j
+ Glossary entry: An enumeration type is defined by an
+ enumeration of its values, which may be named by identifiers
+ or character literals.
+
+2.k
+ Glossary entry: A character type is an enumeration type whose
+ values include characters.
+
+2.l
+ Glossary entry: A record type is a composite type consisting
+ of zero or more named components, possibly of different types.
+
+2.m
+ Glossary entry: A record extension is a type that extends
+ another type by adding additional components.
+
+2.n
+ Glossary entry: An array type is a composite type whose
+ components are all of the same type. Components are selected
+ by indexing.
+
+2.o/2
+ Glossary entry: A task type is a composite type used to
+ represent active entities which execute concurrently and which
+ can communicate via queued task entries. The top-level task
+ of a partition is called the environment task.
+
+2.p/2
+ Glossary entry: A protected type is a composite type whose
+ components are accessible only through one of its protected
+ operations which synchronize concurrent access by multiple
+ tasks.
+
+2.q/2
+ Glossary entry: A private type gives a view of a type that
+ reveals only some of its properties. The remaining properties
+ are provided by the full view given elsewhere. Private types
+ can be used for defining abstractions that hide unnecessary
+ details from their clients.
+
+2.r/2
+ Glossary entry: A private extension is a type that extends
+ another type, with the additional properties hidden from its
+ clients.
+
+2.s/2
+ Glossary entry: An incomplete type gives a view of a type that
+ reveals only some of its properties. The remaining properties
+ are provided by the full view given elsewhere. Incomplete
+ types can be used for defining recursive data structures.
+
+3
+The elementary types are the scalar types (discrete and real) and the
+access types (whose values provide access to objects or subprograms).
+Discrete types are either integer types or are defined by enumeration of
+their values (enumeration types). Real types are either floating point
+types or fixed point types.
+
+4/2
+{AI95-00251-01AI95-00251-01} {AI95-00326-01AI95-00326-01} The composite
+types are the record types, record extensions, array types, interface
+types, task types, and protected types.
+
+4.a/2
+ This paragraph was deleted.{AI95-00442-01AI95-00442-01}
+
+4.1/2
+{AI95-00326-01AI95-00326-01} There can be multiple views of a type with
+varying sets of operations. [An incomplete type represents an
+incomplete view (see *note 3.10.1::) of a type with a very restricted
+usage, providing support for recursive data structures. A private type
+or private extension represents a partial view (see *note 7.3::) of a
+type, providing support for data abstraction. The full view (see *note
+3.2.1::) of a type represents its complete definition.] An incomplete
+or partial view is considered a composite type[, even if the full view
+is not].
+
+4.b/3
+ Proof: {AI05-0299-1AI05-0299-1} The real definitions of the
+ views are in the referenced subclauses.
+
+5/2
+{AI95-00326-01AI95-00326-01} Certain composite types (and views thereof)
+have special components called discriminants whose values affect the
+presence, constraints, or initialization of other components.
+Discriminants can be thought of as parameters of the type.
+
+6/2
+{AI95-00366-01AI95-00366-01} The term subcomponent is used in this
+International Standard in place of the term component to indicate either
+a component, or a component of another subcomponent. Where other
+subcomponents are excluded, the term component is used instead.
+Similarly, a part of an object or value is used to mean the whole object
+or value, or any set of its subcomponents. The terms component,
+subcomponent, and part are also applied to a type meaning the component,
+subcomponent, or part of objects and values of the type.
+
+6.a
+ Discussion: The definition of "part" here is designed to
+ simplify rules elsewhere. By design, the intuitive meaning of
+ "part" will convey the correct result to the casual reader,
+ while this formalistic definition will answer the concern of
+ the compiler-writer.
+
+6.b
+ We use the term "part" when talking about the parent part,
+ ancestor part, or extension part of a type extension. In
+ contexts such as these, the part might represent an empty set
+ of subcomponents (e.g. in a null record extension, or a
+ nonnull extension of a null record). We also use "part" when
+ specifying rules such as those that apply to an object with a
+ "controlled part" meaning that it applies if the object as a
+ whole is controlled, or any subcomponent is.
+
+7/2
+{AI95-00231-01AI95-00231-01} The set of possible values for an object of
+a given type can be subjected to a condition that is called a constraint
+(the case of a null constraint that specifies no restriction is also
+included)[; the rules for which values satisfy a given kind of
+constraint are given in *note 3.5:: for range_constraints, *note 3.6.1::
+for index_constraints, and *note 3.7.1:: for discriminant_constraints].
+The set of possible values for an object of an access type can also be
+subjected to a condition that excludes the null value (see *note
+3.10::).
+
+8/2
+{AI95-00231-01AI95-00231-01} {AI95-00415-01AI95-00415-01} A subtype of a
+given type is a combination of the type, a constraint on values of the
+type, and certain attributes specific to the subtype. The given type is
+called the type of the subtype. Similarly, the associated constraint is
+called the constraint of the subtype. The set of values of a subtype
+consists of the values of its type that satisfy its constraint and any
+exclusion of the null value. Such values belong to the subtype.
+
+8.a
+ Discussion: We make a strong distinction between a type and
+ its subtypes. In particular, a type is not a subtype of
+ itself. There is no constraint associated with a type (not
+ even a null one), and type-related attributes are distinct
+ from subtype-specific attributes.
+
+8.b
+ Discussion: We no longer use the term "base type." All types
+ were "base types" anyway in Ada 83, so the term was redundant,
+ and occasionally confusing. In the RM95 we say simply "the
+ type of the subtype" instead of "the base type of the
+ subtype."
+
+8.c
+ Ramification: The value subset for a subtype might be empty,
+ and need not be a proper subset.
+
+8.d/2
+ To be honest: {AI95-00442-01AI95-00442-01} Any name of a
+ category of types (such as "discrete", "real", or "limited")
+ is also used to qualify its subtypes, as well as its objects,
+ values, declarations, and definitions, such as an "integer
+ type declaration" or an "integer value." In addition, if a
+ term such as "parent subtype" or "index subtype" is defined,
+ then the corresponding term for the type of the subtype is
+ "parent type" or "index type."
+
+8.e
+ Discussion: We use these corresponding terms without
+ explicitly defining them, when the meaning is obvious.
+
+9
+A subtype is called an unconstrained subtype if its type has unknown
+discriminants, or if its type allows range, index, or discriminant
+constraints, but the subtype does not impose such a constraint;
+otherwise, the subtype is called a constrained subtype (since it has no
+unconstrained characteristics).
+
+9.a
+ Discussion: In an earlier version of Ada 9X, "constrained"
+ meant "has a nonnull constraint." However, we changed to this
+ definition since we kept having to special case composite
+ non-array/nondiscriminated types. It also corresponds better
+ to the (now obsolescent) attribute 'Constrained.
+
+9.b
+ For scalar types, "constrained" means "has a nonnull
+ constraint". For composite types, in implementation terms,
+ "constrained" means that the size of all objects of the
+ subtype is the same, assuming a typical implementation model.
+
+9.c
+ Class-wide subtypes are always unconstrained.
+
+ NOTES
+
+10/2
+ 2 {AI95-00442-01AI95-00442-01} Any set of types can be called a
+ "category" of types, and any set of types that is closed under
+ derivation (see *note 3.4::) can be called a "class" of types.
+ However, only certain categories and classes are used in the
+ description of the rules of the language -- generally those that
+ have their own particular set of primitive operations (see *note
+ 3.2.3::), or that correspond to a set of types that are matched by
+ a given kind of generic formal type (see *note 12.5::). The
+ following are examples of "interesting" language-defined classes:
+ elementary, scalar, discrete, enumeration, character, boolean,
+ integer, signed integer, modular, real, floating point, fixed
+ point, ordinary fixed point, decimal fixed point, numeric, access,
+ access-to-object, access-to-subprogram, composite, array, string,
+ (untagged) record, tagged, task, protected, nonlimited. Special
+ syntax is provided to define types in each of these classes. In
+ addition to these classes, the following are examples of
+ "interesting" language-defined categories: abstract, incomplete,
+ interface, limited, private, record.
+
+10.a
+ Discussion: A value is a run-time entity with a given type
+ which can be assigned to an object of an appropriate subtype
+ of the type. An operation is a program entity that operates
+ on zero or more operands to produce an effect, or yield a
+ result, or both.
+
+10.b/2
+ Ramification: {AI95-00442-01AI95-00442-01} Note that a type's
+ category (and class) depends on the place of the reference --
+ a private type is composite outside and possibly elementary
+ inside. It's really the view that is elementary or composite.
+ Note that although private types are composite, there are some
+ properties that depend on the corresponding full view -- for
+ example, parameter passing modes, and the constraint checks
+ that apply in various places.
+
+10.c/2
+ {AI95-00345-01AI95-00345-01} {AI95-00442-01AI95-00442-01}
+ Every property of types forms a category, but not every
+ property of types represents a class. For example, the set of
+ all abstract types does not form a class, because this set is
+ not closed under derivation. Similarly, the set of all
+ interface types does not form a class.
+
+10.d/2
+ {AI95-00442-01AI95-00442-01} The set of limited types does not
+ form a class (since nonlimited types can inherit from limited
+ interfaces), but the set of nonlimited types does. The set of
+ tagged record types and the set of tagged private types do not
+ form a class (because each of them can be extended to create a
+ type of the other category); that implies that the set of
+ record types and the set of private types also do not form a
+ class (even though untagged record types and untagged private
+ types do form a class). In all of these cases, we can talk
+ about the category of the type; for instance, we can talk
+ about the "category of limited types"..
+
+10.e/2
+ {AI95-00442-01AI95-00442-01} Normatively, the language-defined
+ classes are those that are defined to be inherited on
+ derivation by *note 3.4::; other properties either aren't
+ interesting or form categories, not classes.
+
+11/2
+ {AI95-00442-01AI95-00442-01} These language-defined categories are
+ organized like this:
+
+12/2
+ {AI95-00345-01AI95-00345-01} all types
+ elementary
+ scalar
+ discrete
+ enumeration
+ character
+ boolean
+ other enumeration
+ integer
+ signed integer
+ modular integer
+ real
+ floating point
+ fixed point
+ ordinary fixed point
+ decimal fixed point
+ access
+ access-to-object
+ access-to-subprogram
+ composite
+ untagged
+ array
+ string
+ other array
+ record
+ task
+ protected
+ tagged (including interfaces)
+ nonlimited tagged record
+ limited tagged
+ limited tagged record
+ synchronized tagged
+ tagged task
+ tagged protected
+
+13/2
+ {AI95-00345-01AI95-00345-01} {AI95-00442-01AI95-00442-01} There are
+ other categories, such as "numeric" and "discriminated", which
+ represent other categorization dimensions, but do not fit into the
+ above strictly hierarchical picture.
+
+13.a.1/2
+ Discussion: {AI95-00345-01AI95-00345-01}
+ {AI95-00442-01AI95-00442-01} Note that this is also true for
+ some categories mentioned in the chart. The category "task"
+ includes both untagged tasks and tagged tasks. Similarly for
+ "protected", "limited", and "nonlimited" (note that limited
+ and nonlimited are not shown for untagged composite types).
+
+ _Wording Changes from Ada 83_
+
+13.a/3
+ {AI05-0299-1AI05-0299-1} This subclause now precedes the
+ subclauses on objects and named numbers, to cut down on the
+ number of forward references.
+
+13.b
+ We have dropped the term "base type" in favor of simply "type"
+ (all types in Ada 83 were "base types" so it wasn't clear when
+ it was appropriate/necessary to say "base type"). Given a
+ subtype S of a type T, we call T the "type of the subtype S."
+
+ _Wording Changes from Ada 95_
+
+13.c/2
+ {AI95-00231-01AI95-00231-01} Added a mention of null
+ exclusions when we're talking about constraints (these are not
+ constraints, but they are similar).
+
+13.d/2
+ {AI95-00251-01AI95-00251-01} Defined an interface type to be a
+ composite type.
+
+13.e/2
+ {AI95-00326-01AI95-00326-01} Revised the wording so that it is
+ clear that an incomplete view is similar to a partial view in
+ terms of the language.
+
+13.f/2
+ {AI95-00366-01AI95-00366-01} Added a definition of component
+ of a type, subcomponent of a type, and part of a type. These
+ are commonly used in the standard, but they were not
+ previously defined.
+
+13.g/3
+ {AI95-00442-01AI95-00442-01} {AI05-0299-1AI05-0299-1} Reworded
+ most of this subclause to use category rather than class,
+ since so many interesting properties are not, strictly
+ speaking, classes. Moreover, there was no normative
+ description of exactly which properties formed classes, and
+ which did not. The real definition of class, along with a
+ list of properties, is now in *note 3.4::.
+
+* Menu:
+
+* 3.2.1 :: Type Declarations
+* 3.2.2 :: Subtype Declarations
+* 3.2.3 :: Classification of Operations
+* 3.2.4 :: Subtype Predicates
+
+\1f
+File: aarm2012.info, Node: 3.2.1, Next: 3.2.2, Up: 3.2
+
+3.2.1 Type Declarations
+-----------------------
+
+1
+A type_declaration declares a type and its first subtype.
+
+ _Syntax_
+
+2
+ type_declaration ::= full_type_declaration
+ | incomplete_type_declaration
+ | private_type_declaration
+ | private_extension_declaration
+
+3/3
+ {AI05-0183-1AI05-0183-1} full_type_declaration ::=
+ type defining_identifier [known_discriminant_part] is
+ type_definition
+ [aspect_specification];
+ | task_type_declaration
+ | protected_type_declaration
+
+4/2
+ {AI95-00251-01AI95-00251-01} type_definition ::=
+ enumeration_type_definition | integer_type_definition
+ | real_type_definition | array_type_definition
+ | record_type_definition | access_type_definition
+ | derived_type_definition | interface_type_definition
+
+ _Legality Rules_
+
+5
+A given type shall not have a subcomponent whose type is the given type
+itself.
+
+ _Static Semantics_
+
+6
+The defining_identifier (*note 3.1: S0022.) of a type_declaration (*note
+3.2.1: S0023.) denotes the first subtype of the type. The
+known_discriminant_part (*note 3.7: S0061.), if any, defines the
+discriminants of the type (see *note 3.7::, "*note 3.7::
+Discriminants"). The remainder of the type_declaration (*note 3.2.1:
+S0023.) defines the remaining characteristics of (the view of) the type.
+
+7/2
+{AI95-00230-01AI95-00230-01} A type defined by a type_declaration (*note
+3.2.1: S0023.) is a named type; such a type has one or more nameable
+subtypes. Certain other forms of declaration also include type
+definitions as part of the declaration for an object. The type defined
+by such a declaration is anonymous -- it has no nameable subtypes. For
+explanatory purposes, this International Standard sometimes refers to an
+anonymous type by a pseudo-name, written in italics, and uses such
+pseudo-names at places where the syntax normally requires an identifier.
+For a named type whose first subtype is T, this International Standard
+sometimes refers to the type of T as simply "the type T".
+
+7.a/2
+ Ramification: {AI95-00230-01AI95-00230-01} The only
+ user-defined types that can be anonymous in the above sense
+ are array, access, task, and protected types. An anonymous
+ array, task, or protected type can be defined as part of an
+ object_declaration. An anonymous access type can be defined
+ as part of numerous other constructs.
+
+8/2
+{AI95-00230-01AI95-00230-01} {AI95-00326-01AI95-00326-01} A named type
+that is declared by a full_type_declaration (*note 3.2.1: S0024.), or an
+anonymous type that is defined by an access_definition or as part of
+declaring an object of the type, is called a full type. The declaration
+of a full type also declares the full view of the type. The
+type_definition (*note 3.2.1: S0025.), task_definition (*note 9.1:
+S0207.), protected_definition (*note 9.4: S0212.), or access_definition
+(*note 3.10: S0084.) that defines a full type is called a full type
+definition. [Types declared by other forms of type_declaration (*note
+3.2.1: S0023.) are not separate types; they are partial or incomplete
+views of some full type.]
+
+8.a
+ To be honest: Class-wide, universal, and root numeric types
+ are full types.
+
+8.b/2
+ Reason: {AI95-00230-01AI95-00230-01} We need to mention
+ access_definition separately, as it may occur in renames,
+ which do not declare objects.
+
+9
+The definition of a type implicitly declares certain predefined
+operators that operate on the type, according to what classes the type
+belongs, as specified in *note 4.5::, "*note 4.5:: Operators and
+Expression Evaluation".
+
+9.a
+ Discussion: We no longer talk about the implicit declaration
+ of basic operations. These are treated like an if_statement
+ -- they don't need to be declared, but are still applicable to
+ only certain classes of types.
+
+10
+The predefined types [(for example the types Boolean, Wide_Character,
+Integer, root_integer, and universal_integer)] are the types that are
+defined in [a predefined library package called] Standard[; this package
+also includes the [(implicit)] declarations of their predefined
+operators]. [The package Standard is described in *note A.1::.]
+
+10.a
+ Ramification: We use the term "predefined" to refer to
+ entities declared in the visible part of Standard, to
+ implicitly declared operators of a type whose semantics are
+ defined by the language, to Standard itself, and to the
+ "predefined environment". We do not use this term to refer to
+ library packages other than Standard. For example Text_IO is
+ a language-defined package, not a predefined package, and
+ Text_IO.Put_Line is not a predefined operation.
+
+ _Dynamic Semantics_
+
+11
+The elaboration of a full_type_declaration consists of the elaboration
+of the full type definition. Each elaboration of a full type definition
+creates a distinct type and its first subtype.
+
+11.a
+ Reason: The creation is associated with the type definition,
+ rather than the type declaration, because there are types that
+ are created by full type definitions that are not immediately
+ contained within a type declaration (e.g. an array object
+ declaration, a singleton task declaration, etc.).
+
+11.b
+ Ramification: Any implicit declarations that occur immediately
+ following the full type definition are elaborated where they
+ (implicitly) occur.
+
+ _Examples_
+
+12
+Examples of type definitions:
+
+13
+ (White, Red, Yellow, Green, Blue, Brown, Black)
+ range 1 .. 72
+ array(1 .. 10) of Integer
+
+14
+Examples of type declarations:
+
+15
+ type Color is (White, Red, Yellow, Green, Blue, Brown, Black);
+ type Column is range 1 .. 72;
+ type Table is array(1 .. 10) of Integer;
+
+ NOTES
+
+16
+ 3 Each of the above examples declares a named type. The
+ identifier given denotes the first subtype of the type. Other
+ named subtypes of the type can be declared with
+ subtype_declarations (see *note 3.2.2::). Although names do not
+ directly denote types, a phrase like "the type Column" is sometimes
+ used in this International Standard to refer to the type of Column,
+ where Column denotes the first subtype of the type. For an example
+ of the definition of an anonymous type, see the declaration of the
+ array Color_Table in *note 3.3.1::; its type is anonymous -- it has
+ no nameable subtypes.
+
+ _Wording Changes from Ada 83_
+
+16.a
+ The syntactic category full_type_declaration now includes task
+ and protected type declarations.
+
+16.b/3
+ {AI05-0299-1AI05-0299-1} We have generalized the concept of
+ first-named subtype (now called simply "first subtype") to
+ cover all kinds of types, for uniformity of description
+ elsewhere. RM83 defined first-named subtype in Section 13.
+ We define first subtype here, because it is now a more
+ fundamental concept. We renamed the term, because in Ada 95
+ some first subtypes have no name.
+
+16.c/2
+ {AI95-00230-01AI95-00230-01} We no longer elaborate
+ discriminant_parts, because there is nothing to do, and it was
+ complex to say that you only wanted to elaborate it once for a
+ private or incomplete type. This is also consistent with the
+ fact that subprogram specifications are not elaborated
+ (neither in Ada 83 nor in Ada 95). Note, however, that an
+ access_definition appearing in a discriminant_part is
+ elaborated at the full_type_declaration (for a nonlimited
+ type) or when an object with such a discriminant is created
+ (for a limited type).
+
+ _Wording Changes from Ada 95_
+
+16.d/2
+ {AI95-00230-01AI95-00230-01} Added wording so that anonymous
+ access types are always full types, even if they appear in
+ renames.
+
+16.e/2
+ {AI95-00251-01AI95-00251-01} Added interface types (see *note
+ 3.9.4::) to the syntax.
+
+16.f/2
+ {AI95-00326-01AI95-00326-01} Added a definition of full view,
+ so that all types have a well-defined full view.
+
+ _Extensions to Ada 2005_
+
+16.g/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a full_type_declaration. This is described in
+ *note 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 3.2.2, Next: 3.2.3, Prev: 3.2.1, Up: 3.2
+
+3.2.2 Subtype Declarations
+--------------------------
+
+1
+A subtype_declaration declares a subtype of some previously declared
+type, as defined by a subtype_indication.
+
+ _Syntax_
+
+2/3
+ {AI05-0183-1AI05-0183-1} subtype_declaration ::=
+ subtype defining_identifier is subtype_indication
+ [aspect_specification];
+
+3/2
+ {AI95-00231-01AI95-00231-01} subtype_indication ::= [
+ null_exclusion] subtype_mark [constraint]
+
+4
+ subtype_mark ::= subtype_name
+
+4.a
+ Ramification: Note that name includes attribute_reference;
+ thus, S'Base can be used as a subtype_mark.
+
+4.b
+ Reason: We considered changing subtype_mark to subtype_name.
+ However, existing users are used to the word "mark," so we're
+ keeping it.
+
+5
+ constraint ::= scalar_constraint | composite_constraint
+
+6
+ scalar_constraint ::=
+ range_constraint | digits_constraint | delta_constraint
+
+7
+ composite_constraint ::=
+ index_constraint | discriminant_constraint
+
+ _Name Resolution Rules_
+
+8
+A subtype_mark shall resolve to denote a subtype. The type determined
+by a subtype_mark is the type of the subtype denoted by the
+subtype_mark.
+
+8.a/3
+ Ramification: {AI05-0005-1AI05-0005-1} Types are never
+ directly named; all subtype_marks denote subtypes -- possibly
+ an unconstrained (base) subtype, but never the type. When we
+ use the term anonymous type we really mean a type with no
+ nameable subtypes.
+
+ _Dynamic Semantics_
+
+9
+The elaboration of a subtype_declaration consists of the elaboration of
+the subtype_indication. The elaboration of a subtype_indication creates
+a new subtype. If the subtype_indication does not include a constraint,
+the new subtype has the same (possibly null) constraint as that denoted
+by the subtype_mark. The elaboration of a subtype_indication that
+includes a constraint proceeds as follows:
+
+10
+ * The constraint is first elaborated.
+
+11
+ * A check is then made that the constraint is compatible with the
+ subtype denoted by the subtype_mark.
+
+11.a
+ Ramification: The checks associated with constraint
+ compatibility are all Range_Checks. Discriminant_Checks and
+ Index_Checks are associated only with checks that a value
+ satisfies a constraint.
+
+12
+The condition imposed by a constraint is the condition obtained after
+elaboration of the constraint. The rules defining compatibility are
+given for each form of constraint in the appropriate subclause. These
+rules are such that if a constraint is compatible with a subtype, then
+the condition imposed by the constraint cannot contradict any condition
+already imposed by the subtype on its values. The exception
+Constraint_Error is raised if any check of compatibility fails.
+
+12.a
+ To be honest: The condition imposed by a constraint is named
+ after it -- a range_constraint imposes a range constraint,
+ etc.
+
+12.b
+ Ramification: A range_constraint causes freezing of its type.
+ Other constraints do not.
+
+ NOTES
+
+13
+ 4 A scalar_constraint may be applied to a subtype of an
+ appropriate scalar type (see *note 3.5::, *note 3.5.9::, and *note
+ J.3::), even if the subtype is already constrained. On the other
+ hand, a composite_constraint may be applied to a composite subtype
+ (or an access-to-composite subtype) only if the composite subtype
+ is unconstrained (see *note 3.6.1:: and *note 3.7.1::).
+
+ _Examples_
+
+14
+Examples of subtype declarations:
+
+15/2
+ {AI95-00433-01AI95-00433-01} subtype Rainbow is Color range Red .. Blue; -- see *note 3.2.1::
+ subtype Red_Blue is Rainbow;
+ subtype Int is Integer;
+ subtype Small_Int is Integer range -10 .. 10;
+ subtype Up_To_K is Column range 1 .. K; -- see *note 3.2.1::
+ subtype Square is Matrix(1 .. 10, 1 .. 10); -- see *note 3.6::
+ subtype Male is Person(Sex => M); -- see *note 3.10.1::
+ subtype Binop_Ref is not null Binop_Ptr; -- see *note 3.10::
+
+ _Incompatibilities With Ada 83_
+
+15.a
+ In Ada 95, all range_constraints cause freezing of their type.
+ Hence, a type-related representation item for a scalar type
+ has to precede any range_constraints whose type is the scalar
+ type.
+
+ _Wording Changes from Ada 83_
+
+15.b
+ Subtype_marks allow only subtype names now, since types are
+ never directly named. There is no need for RM83-3.3.2(3),
+ which says a subtype_mark can denote both the type and the
+ subtype; in Ada 95, you denote an unconstrained (base) subtype
+ if you want, but never the type.
+
+15.c
+ The syntactic category type_mark is now called subtype_mark,
+ since it always denotes a subtype.
+
+ _Extensions to Ada 95_
+
+15.d/2
+ {AI95-00231-01AI95-00231-01} An optional null_exclusion can be
+ used in a subtype_indication. This is described in *note
+ 3.10::.
+
+ _Extensions to Ada 2005_
+
+15.e/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a subtype_declaration. This is described in *note
+ 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 3.2.3, Next: 3.2.4, Prev: 3.2.2, Up: 3.2
+
+3.2.3 Classification of Operations
+----------------------------------
+
+ _Static Semantics_
+
+1/2
+{AI95-00416-01AI95-00416-01} An operation operates on a type T if it
+yields a value of type T, if it has an operand whose expected type (see
+*note 8.6::) is T, or if it has an access parameter or access result
+type (see *note 6.1::) designating T. A predefined operator, or other
+language-defined operation such as assignment or a membership test, that
+operates on a type, is called a predefined operation of the type. The
+primitive operations of a type are the predefined operations of the
+type, plus any user-defined primitive subprograms.
+
+1.a
+ Glossary entry: The primitive operations of a type are the
+ operations (such as subprograms) declared together with the
+ type declaration. They are inherited by other types in the
+ same class of types. For a tagged type, the primitive
+ subprograms are dispatching subprograms, providing run-time
+ polymorphism. A dispatching subprogram may be called with
+ statically tagged operands, in which case the subprogram body
+ invoked is determined at compile time. Alternatively, a
+ dispatching subprogram may be called using a dispatching call,
+ in which case the subprogram body invoked is determined at run
+ time.
+
+1.b
+ To be honest: Protected subprograms are not considered to be
+ "primitive subprograms," even though they are subprograms, and
+ they are inherited by derived types.
+
+1.c
+ Discussion: We use the term "primitive subprogram" in most of
+ the rest of the manual. The term "primitive operation" is
+ used mostly in conceptual discussions.
+
+2
+The primitive subprograms of a specific type are defined as follows:
+
+3
+ * The predefined operators of the type (see *note 4.5::);
+
+4
+ * For a derived type, the inherited (see *note 3.4::) user-defined
+ subprograms;
+
+5
+ * For an enumeration type, the enumeration literals (which are
+ considered parameterless functions -- see *note 3.5.1::);
+
+6
+ * For a specific type declared immediately within a
+ package_specification, any subprograms (in addition to the
+ enumeration literals) that are explicitly declared immediately
+ within the same package_specification and that operate on the type;
+
+6.1/3
+ * {AI05-0128-1AI05-0128-1} For a specific type with an explicitly
+ declared primitive "=" operator whose result type is Boolean, the
+ corresponding "/=" operator (see *note 6.6::);
+
+7/2
+ * {AI95-00200-01AI95-00200-01} For a nonformal type, any subprograms
+ not covered above [that are explicitly declared immediately within
+ the same declarative region as the type] and that override (see
+ *note 8.3::) other implicitly declared primitive subprograms of the
+ type.
+
+7.a
+ Discussion: In Ada 83, only subprograms declared in the
+ visible part were "primitive" (i.e. derivable). In Ada 95,
+ mostly because of child library units, we include all
+ operations declared in the private part as well, and all
+ operations that override implicit declarations.
+
+7.b
+ Ramification: It is possible for a subprogram to be primitive
+ for more than one type, though it is illegal for a subprogram
+ to be primitive for more than one tagged type. See *note
+ 3.9::.
+
+7.c
+ Discussion: The order of the implicit declarations when there
+ are both predefined operators and inherited subprograms is
+ described in *note 3.4::, "*note 3.4:: Derived Types and
+ Classes".
+
+7.d/2
+ Ramification: {AI95-00200-01AI95-00200-01} Subprograms
+ declared in a generic package specification are never
+ primitive for a formal type, even if they happen to override
+ an operation of the formal type. This includes formal
+ subprograms, which are never primitive operations (that's true
+ even for an abstract formal subprogram).
+
+8
+A primitive subprogram whose designator is an operator_symbol is called
+a primitive operator.
+
+ _Incompatibilities With Ada 83_
+
+8.a
+ The attribute S'Base is no longer defined for nonscalar
+ subtypes. Since this was only permitted as the prefix of
+ another attribute, and there are no interesting nonscalar
+ attributes defined for an unconstrained composite or access
+ subtype, this should not affect any existing programs.
+
+ _Extensions to Ada 83_
+
+8.b
+ The primitive subprograms (derivable subprograms) include
+ subprograms declared in the private part of a package
+ specification as well, and those that override implicitly
+ declared subprograms, even if declared in a body.
+
+ _Wording Changes from Ada 83_
+
+8.c
+ We have dropped the confusing term operation of a type in
+ favor of the more useful primitive operation of a type and the
+ phrase operates on a type.
+
+8.d
+ The description of S'Base has been moved to *note 3.5::,
+ "*note 3.5:: Scalar Types" because it is now defined only for
+ scalar types.
+
+ _Wording Changes from Ada 95_
+
+8.e/2
+ {AI95-00200-01AI95-00200-01} Clarified that a formal
+ subprogram that happens to override a primitive operation of a
+ formal type is not a primitive operation (and thus not a
+ dispatching operation) of the formal type.
+
+8.f/2
+ {AI95-00416-01AI95-00416-01} Added wording to include access
+ result types in the kinds of operations that operate on a type
+ T.
+
+ _Wording Changes from Ada 2005_
+
+8.g/3
+ {AI05-0128-1AI05-0128-1} Correction: The implicitly declared
+ "/=" for a primitive "=" operator is also primitive; this
+ makes it eligible to be made visible by a use type clause.
+
+\1f
+File: aarm2012.info, Node: 3.2.4, Prev: 3.2.3, Up: 3.2
+
+3.2.4 Subtype Predicates
+------------------------
+
+1/3
+{AI05-0153-3AI05-0153-3} {AI05-0269-1AI05-0269-1}
+{AI05-0299-1AI05-0299-1} The language-defined predicate aspects
+Static_Predicate and Dynamic_Predicate may be used to define properties
+of subtypes. A predicate specification is an aspect_specification for
+one of the two predicate aspects. General rules for aspects and
+aspect_specifications are found in Clause *note 13:: (*note 13.1:: and
+*note 13.1.1:: respectively).
+
+1.a/3
+ Aspect Description for Static_Predicate: Condition that must
+ hold true for objects of a given subtype; the subtype may be
+ static.
+
+1.b/3
+ Aspect Description for Dynamic_Predicate: Condition that must
+ hold true for objects of a given subtype; the subtype is not
+ static.
+
+ _Name Resolution Rules_
+
+2/3
+{AI05-0153-3AI05-0153-3} The expected type for a predicate aspect
+expression is any boolean type.
+
+ _Static Semantics_
+
+3/3
+{AI05-0153-3AI05-0153-3} A predicate specification may be given on a
+type_declaration or a subtype_declaration, and applies to the declared
+subtype. In addition, predicate specifications apply to certain other
+subtypes:
+
+4/3
+ * For a (first) subtype defined by a derived type declaration, the
+ predicates of the parent subtype and the progenitor subtypes apply.
+
+5/3
+ * For a subtype created by a subtype_indication, the predicate of the
+ subtype denoted by the subtype_mark applies.
+
+6/3
+{AI05-0153-3AI05-0153-3} The predicate of a subtype consists of all
+predicate specifications that apply, and-ed together; if no predicate
+specifications apply, the predicate is True [(in particular, the
+predicate of a base subtype is True)].
+
+7/3
+{AI05-0290-1AI05-0290-1} Predicate checks are defined to be enabled or
+disabled for a given subtype as follows:
+
+8/3
+ * If a subtype is declared by a type_declaration or
+ subtype_declaration that includes a predicate specification, then:
+
+9/3
+ * if performing checks is required by the Static_Predicate
+ assertion policy (see *note 11.4.2::) and the declaration
+ includes a Static_Predicate specification, then predicate
+ checks are enabled for the subtype;
+
+10/3
+ * if performing checks is required by the Dynamic_Predicate
+ assertion policy (see *note 11.4.2::) and the declaration
+ includes a Dynamic_Predicate specification, then predicate
+ checks are enabled for the subtype;
+
+11/3
+ * otherwise, predicate checks are disabled for the subtype[,
+ regardless of whether predicate checking is enabled for any
+ other subtypes mentioned in the declaration];
+
+12/3
+ * If a subtype is defined by a derived type declaration that does not
+ include a predicate specification, then predicate checks are
+ enabled for the subtype if and only if predicate checks are enabled
+ for at least one of the parent subtype and the progenitor subtypes;
+
+13/3
+ * If a subtype is created by a subtype_indication other than in one
+ of the previous cases, then predicate checks are enabled for the
+ subtype if and only if predicate checks are enabled for the subtype
+ denoted by the subtype_mark;
+
+14/3
+ * Otherwise, predicate checks are disabled for the given subtype.
+
+14.a/3
+ Discussion: In this case, no predicate specifications can
+ apply to the subtype and so it doesn't typically matter
+ whether predicate checks are enabled. This rule does make a
+ difference, however, when determining whether predicate checks
+ are enabled for another type when this type is one of multiple
+ progenitors. See the "derived type declaration" wording
+ above.
+
+14.b/3
+ Even when predicate checks are disabled, a predicate cam
+ affect various Legality Rules, the results of membership
+ tests, the items in a for loop, and the result of the Valid
+ attribute.
+
+ _Legality Rules_
+
+15/3
+{AI05-0153-3AI05-0153-3} {AI05-0269-1AI05-0269-1} The expression of a
+Static_Predicate specification shall be predicate-static; that is, one
+of the following:
+
+16/3
+ * a static expression;
+
+17/3
+ * a membership test whose simple_expression is the current instance,
+ and whose membership_choice_list meets the requirements for a
+ static membership test (see *note 4.9::);
+
+18/3
+ * a case_expression whose selecting_expression is the current
+ instance, and whose dependent_expressions are static expressions;
+
+19/3
+ * a call to a predefined equality or ordering operator, where one
+ operand is the current instance, and the other is a static
+ expression;
+
+20/3
+ * {AI05-0262-1AI05-0262-1} a call to a predefined boolean logical
+ operator, where each operand is predicate-static;
+
+21/3
+ * {AI05-0269-1AI05-0269-1} a short-circuit control form where both
+ operands are predicate-static; or
+
+22/3
+ * a parenthesized predicate-static expression.
+
+23/3
+{AI05-0262-1AI05-0262-1} A predicate shall not be specified for an
+incomplete subtype.
+
+23.a/3
+ Reason: The expression of such a predicate could not depend on
+ the properties of the value of the type (since it doesn't have
+ any), so it is useless and we don't want to require the added
+ complexity needed to support it.
+
+24/3
+{AI05-0287-1AI05-0287-1} If a predicate applies to a subtype, then that
+predicate shall not mention any other subtype to which the same
+predicate applies.
+
+24.a/3
+ Reason: This is intended to prevent recursive predicates,
+ which cause definitional problems for static predicates.
+ Inside of the predicate, the subtype name refers to the
+ current instance of the subtype, which is an object, so a
+ direct use of the subtype name cannot be recursive. But other
+ subtypes naming the same type might:
+
+24.b/3
+ type Really_Ugly is private;
+ private
+ subtype Ugly is Really_Ugly;
+ type Really_Ugly is new Integer
+ with Static_Predicate => Really_Ugly not in Ugly; -- Illegal!
+
+25/3
+{AI05-0153-3AI05-0153-3} An index subtype, discrete_range of an
+index_constraint or slice, or a discrete_subtype_definition of a
+constrained_array_definition, entry_declaration, or
+entry_index_specification shall not denote a subtype to which predicate
+specifications apply.
+
+26/3
+{AI05-0153-3AI05-0153-3} The prefix of an attribute_reference whose
+attribute_designator is First, Last, or Range shall not denote a scalar
+subtype to which predicate specifications apply.
+
+26.a/3
+ Reason: {AI05-0297-1AI05-0297-1} This is to prevent confusion
+ about whether the First value is the lowest value of the
+ subtype (which does not depend on the predicate) or the lowest
+ value of the subtype which meets the predicate. (For a
+ dynamic predicate, determining this latter value is expensive
+ as it would usually require a loop.) For a static subtype
+ that has a static predicate, the First_Valid and Last_Valid
+ attributes (see *note 3.5.5::) can be used instead.
+
+27/3
+{AI05-0153-3AI05-0153-3} {AI05-0262-1AI05-0262-1}
+{AI05-0287-1AI05-0287-1} The discrete_subtype_definition of a
+loop_parameter_specification shall not denote a nonstatic subtype to
+which predicate specifications apply or any subtype to which
+Dynamic_Predicate specifications apply.
+
+28/3
+{AI05-0153-3AI05-0153-3} {AI05-0262-1AI05-0262-1} The discrete_choice of
+a named_array_aggregate shall not denote a nonstatic subtype to which
+predicate specifications apply.
+
+28.a/3
+ Reason: {AI05-0262-1AI05-0262-1} This rule prevents
+ noncontiguous dynamically bounded array aggregates, which
+ could be expensive to check for. (Array aggregates have rules
+ to prevent problems with static subtypes.) We define this
+ rule here so that the runtime generic body check applies.
+
+29/3
+{AI05-0262-1AI05-0262-1} In addition to the places where Legality Rules
+normally apply (see *note 12.3::), these rules apply also in the private
+part of an instance of a generic unit.
+
+ _Dynamic Semantics_
+
+30/3
+{AI05-0153-3AI05-0153-3} {AI05-0290-1AI05-0290-1} If predicate checks
+are enabled for a given subtype, then:
+
+31/3
+ [On every subtype conversion, the predicate of the target
+ subtype is evaluated, and a check is performed that the
+ predicate is True. This includes all parameter passing,
+ except for certain parameters passed by reference, which are
+ covered by the following rule: ] After normal completion and
+ leaving of a subprogram, for each in out or out parameter that
+ is passed by reference, the predicate of the subtype of the
+ actual is evaluated, and a check is performed that the
+ predicate is True. For an object created by an
+ object_declaration with no explicit initialization expression,
+ or by an uninitialized allocator, if any subcomponents have
+ default_expressions, the predicate of the nominal subtype of
+ the created object is evaluated, and a check is performed that
+ the predicate is True. Assertions.Assertion_Error is raised
+ if any of these checks fail.
+
+31.a/3
+ Ramification: Predicates are not evaluated at the point of the
+ (sub)type declaration.
+
+31.b/3
+ Implementation Note: Static_Predicate checks can be removed
+ even in the presence of potentially invalid values, just as
+ constraint checks can be removed.
+
+32/3
+{AI05-0262-1AI05-0262-1} A value satisfies a predicate if the predicate
+is True for that value.
+
+33/3
+{AI05-0153-3AI05-0153-3} {AI05-0276-1AI05-0276-1} If any of the above
+Legality Rules is violated in an instance of a generic unit,
+Program_Error is raised at the point of the violation.
+
+33.a/3
+ Discussion: This is the usual way around the contract model;
+ this applies even in instance bodies. Note that errors in
+ instance specifications will be detected at compile-time by
+ the "re-check" of the specification, only errors in the body
+ should raise Program_Error.
+
+ NOTES
+
+34/3
+ 5 {AI05-0153-3AI05-0153-3} A predicate specification does not
+ cause a subtype to be considered constrained.
+
+35/3
+ 6 {AI05-0153-3AI05-0153-3} A Static_Predicate, like a constraint,
+ always remains True for all objects of the subtype, except in the
+ case of uninitialized variables and other invalid values. A
+ Dynamic_Predicate, on the other hand, is checked as specified
+ above, but can become False at other times. For example, the
+ predicate of a record subtype is not checked when a subcomponent is
+ modified.
+
+ _Extensions to Ada 2005_
+
+35.a/3
+ {AI05-0153-3AI05-0153-3} {AI05-0262-1AI05-0262-1}
+ {AI05-0276-1AI05-0276-1} {AI05-0290-1AI05-0290-1} Predicate
+ aspects are new in Ada 2012.
+
+\1f
+File: aarm2012.info, Node: 3.3, Next: 3.4, Prev: 3.2, Up: 3
+
+3.3 Objects and Named Numbers
+=============================
+
+1
+[Objects are created at run time and contain a value of a given type.
+An object can be created and initialized as part of elaborating a
+declaration, evaluating an allocator, aggregate, or function_call, or
+passing a parameter by copy. Prior to reclaiming the storage for an
+object, it is finalized if necessary (see *note 7.6.1::).]
+
+ _Static Semantics_
+
+2
+All of the following are objects:
+
+2.a
+ Glossary entry: An object is either a constant or a variable.
+ An object contains a value. An object is created by an
+ object_declaration or by an allocator. A formal parameter is
+ (a view of) an object. A subcomponent of an object is an
+ object.
+
+3
+ * the entity declared by an object_declaration;
+
+4
+ * a formal parameter of a subprogram, entry, or generic subprogram;
+
+5
+ * a generic formal object;
+
+6
+ * a loop parameter;
+
+7
+ * a choice parameter of an exception_handler;
+
+8
+ * an entry index of an entry_body;
+
+9
+ * the result of dereferencing an access-to-object value (see *note
+ 4.1::);
+
+10/3
+ * {AI95-00416-01AI95-00416-01} {AI05-0015-1AI05-0015-1} the return
+ object of a function;
+
+11
+ * the result of evaluating an aggregate;
+
+11.1/3
+ * {AI05-0003-1AI05-0003-1} a qualified_expression whose operand
+ denotes an object;
+
+12
+ * a component, slice, or view conversion of another object.
+
+13/3
+{AI05-0054-2AI05-0054-2} An object is either a constant object or a
+variable object. Similarly, a view of an object is either a constant or
+a variable. All views of a constant elementary object are constant.
+All views of a constant composite object are constant, except for parts
+that are of controlled or immutably limited types; variable views of
+those parts and their subcomponents may exist. In this sense, objects
+of controlled and immutably limited types are inherently mutable. A
+constant view of an object cannot be used to modify its value. The
+terms constant and variable by themselves refer to constant and variable
+views of objects.
+
+14
+The value of an object is read when the value of any part of the object
+is evaluated, or when the value of an enclosing object is evaluated.
+The value of a variable is updated when an assignment is performed to
+any part of the variable, or when an assignment is performed to an
+enclosing object.
+
+14.a
+ Ramification: Reading and updating are intended to include
+ read/write references of any kind, even if they are not
+ associated with the evaluation of a particular construct.
+ Consider, for example, the expression "X.all(F)", where X is
+ an access-to-array object, and F is a function. The
+ implementation is allowed to first evaluate "X.all" and then
+ F. Finally, a read is performed to get the value of the F'th
+ component of the array. Note that the array is not
+ necessarily read as part of the evaluation of "X.all". This
+ is important, because if F were to free X using
+ Unchecked_Deallocation, we want the execution of the final
+ read to be erroneous.
+
+15
+Whether a view of an object is constant or variable is determined by the
+definition of the view. The following (and no others) represent
+constants:
+
+16
+ * an object declared by an object_declaration with the reserved word
+ constant;
+
+16.a/2
+ To be honest: {AI95-00385-01AI95-00385-01} We mean the word
+ constant as defined by the grammar for object_declaration, not
+ some random word constant. Thus,
+
+16.b/2
+ X : access constant T;
+
+16.c/2
+ is not a constant.
+
+17
+ * a formal parameter or generic formal object of mode in;
+
+18
+ * a discriminant;
+
+18.1/3
+ * {AI05-0262-1AI05-0262-1} a loop parameter unless specified to be a
+ variable for a generalized loop (see *note 5.5.2::);
+
+19/3
+ * {AI05-0262-1AI05-0262-1} a choice parameter or entry index;
+
+20
+ * the dereference of an access-to-constant value;
+
+20.1/3
+ * {AI05-0015-1AI05-0015-1} the return object declared by an
+ extended_return_statement with the reserved word constant;
+
+21/3
+ * {AI05-0015-1AI05-0015-1} the object denoted by a function_call or
+ an aggregate;
+
+21.1/3
+ * {AI05-0003-1AI05-0003-1} the result of evaluating a
+ qualified_expression;
+
+21.2/3
+ * {AI05-0120-1AI05-0120-1} within the body of a protected function
+ (or a function declared immediately within a protected_body), the
+ current instance of the enclosing protected unit;
+
+22
+ * a selected_component, indexed_component, slice, or view conversion
+ of a constant.
+
+23/3
+{AI05-0264-1AI05-0264-1} At the place where a view of an object is
+defined, a nominal subtype is associated with the view. The object's
+actual subtype (that is, its subtype) can be more restrictive than the
+nominal subtype of the view; it always is if the nominal subtype is an
+indefinite subtype. A subtype is an indefinite subtype if it is an
+unconstrained array subtype, or if it has unknown discriminants or
+unconstrained discriminants without defaults (see *note 3.7::);
+otherwise, the subtype is a definite subtype [(all elementary subtypes
+are definite subtypes)]. [A class-wide subtype is defined to have
+unknown discriminants, and is therefore an indefinite subtype. An
+indefinite subtype does not by itself provide enough information to
+create an object; an additional constraint or explicit initialization
+expression is necessary (see *note 3.3.1::). A component cannot have an
+indefinite nominal subtype.]
+
+23.1/3
+{AI05-0008-1AI05-0008-1} A view of a composite object is known to be
+constrained if:
+
+23.2/3
+ * its nominal subtype is constrained, and is not an untagged partial
+ view; or
+
+23.3/3
+ * its nominal subtype is indefinite; or
+
+23.4/3
+ * {AI05-0008-1AI05-0008-1} {AI05-0093-1AI05-0093-1} its type is
+ immutably limited (see *note 7.5::); or
+
+23.5/3
+ * it is part of a stand-alone constant (including a generic formal
+ object of mode in); or
+
+23.6/3
+ * it is part of a formal parameter of mode in; or
+
+23.7/3
+ * it is part of the object denoted by a function_call or aggregate;
+ or
+
+23.8/3
+ * it is part of a constant return object of an
+ extended_return_statement; or
+
+23.9/3
+ * {AI05-0008-1AI05-0008-1} {AI05-0041-1AI05-0041-1} it is a
+ dereference of a pool-specific access type, and there is no
+ ancestor of its type that has a constrained partial view.
+
+23.a/3
+ Discussion: We do not include dereferences of general access
+ types because they might denote stand-alone aliased
+ unconstrained variables. That's true even for
+ access-to-constant types (the denoted object does not have to
+ be a constant).
+
+23.b/3
+ {AI05-0005-1AI05-0005-1} {AI05-0008-1AI05-0008-1} There are
+ other cases that could have been included in this definition
+ (view conversions, the current instance of a type, objects of
+ a formal discriminated private type), but these are not
+ relevant to the places this term is used, so they were not
+ included. If this term is used in additional places, the
+ definition should be checked to see if any of these additional
+ cases are relevant and appropriate wording added if necessary.
+
+23.10/3
+{AI05-0008-1AI05-0008-1} {AI05-0041-1AI05-0041-1} For the purposes of
+determining within a generic body whether an object is known to be
+constrained:
+
+23.11/3
+ * if a subtype is a descendant of an untagged generic formal private
+ or derived type, and the subtype is not an unconstrained array
+ subtype, it is not considered indefinite and is considered to have
+ a constrained partial view;
+
+23.12/3
+ * if a subtype is a descendant of a formal access type, it is not
+ considered pool-specific.
+
+24
+A named number provides a name for a numeric value known at compile
+time. It is declared by a number_declaration.
+
+ NOTES
+
+25
+ 7 A constant cannot be the target of an assignment operation, nor
+ be passed as an in out or out parameter, between its initialization
+ and finalization, if any.
+
+25.1/3
+ 8 {AI05-0054-2AI05-0054-2} The value of a constant object cannot
+ be changed after its initialization, except in some cases where the
+ object has a controlled or immutably limited part (see *note 7.5::,
+ *note 7.6::, and *note 13.9.1::).
+
+26/3
+ 9 {AI05-0264-1AI05-0264-1} The nominal and actual subtypes of an
+ elementary object are always the same. For a discriminated or
+ array object, if the nominal subtype is constrained, then so is the
+ actual subtype.
+
+ _Extensions to Ada 83_
+
+26.a
+ There are additional kinds of objects (choice parameters and
+ entry indices of entry bodies).
+
+26.b
+ The result of a function and of evaluating an aggregate are
+ considered (constant) objects. This is necessary to explain
+ the action of finalization on such things. Because a
+ function_call is also syntactically a name (see *note 4.1::),
+ the result of a function_call can be renamed, thereby allowing
+ repeated use of the result without calling the function again.
+
+ _Wording Changes from Ada 83_
+
+26.c/3
+ {AI05-0299-1AI05-0299-1} This subclause now follows the
+ subclauses on types and subtypes, to cut down on the number of
+ forward references.
+
+26.d
+ The term nominal subtype is new. It is used to distinguish
+ what is known at compile time about an object's constraint,
+ versus what its "true" run-time constraint is.
+
+26.e
+ The terms definite and indefinite (which apply to subtypes)
+ are new. They are used to aid in the description of generic
+ formal type matching, and to specify when an explicit initial
+ value is required in an object_declaration.
+
+26.f
+ We have moved the syntax for object_declaration and
+ number_declaration down into their respective subclauses, to
+ keep the syntax close to the description of the associated
+ semantics.
+
+26.g
+ We talk about variables and constants here, since the
+ discussion is not specific to object_declarations, and it
+ seems better to have the list of the kinds of constants
+ juxtaposed with the kinds of objects.
+
+26.h
+ We no longer talk about indirect updating due to parameter
+ passing. Parameter passing is handled in 6.2 and 6.4.1 in a
+ way that there is no need to mention it here in the definition
+ of read and update. Reading and updating now includes the
+ case of evaluating or assigning to an enclosing object.
+
+ _Wording Changes from Ada 95_
+
+26.i/2
+ {AI95-00416-01AI95-00416-01} Clarified that the return object
+ is the object created by a function call.
+
+ _Extensions to Ada 2005_
+
+26.j/3
+ {AI05-0015-1AI05-0015-1} Added wording to allow return objects
+ to be declared as constants, and corrected the definition of
+ return objects as objects.
+
+ _Wording Changes from Ada 2005_
+
+26.k/3
+ {AI05-0008-1AI05-0008-1} {AI05-0041-1AI05-0041-1}
+ {AI05-0093-1AI05-0093-1} Correction: Added a definition of
+ known to be constrained, for use in other rules.
+
+26.l/3
+ {AI05-0054-2AI05-0054-2} Correction: We now recognize the fact
+ that not all declared constant objects are immutable; for
+ those that a variable view can be constructed, they can be
+ changed via that view.
+
+26.m/3
+ {AI05-0120-1AI05-0120-1} Correction: Added the current
+ instance of a protected object to the list of constant views;
+ since the list claims to include all possibilities, it had
+ better include that one.
+
+26.n/3
+ {AI05-0003-1AI05-0003-1} The result of a qualified_expression
+ is defined to be a constant view and is defined to be an
+ object if the operand of the qualified_expression is an
+ object. These definitions, combined with some grammar
+ changes, allow qualified_expressions to be used in more
+ places. See *note 4.1:: for details.
+
+* Menu:
+
+* 3.3.1 :: Object Declarations
+* 3.3.2 :: Number Declarations
+
+\1f
+File: aarm2012.info, Node: 3.3.1, Next: 3.3.2, Up: 3.3
+
+3.3.1 Object Declarations
+-------------------------
+
+1/3
+{AI05-0262-1AI05-0262-1} An object_declaration declares a stand-alone
+object with a given nominal subtype and, optionally, an explicit initial
+value given by an initialization expression. For an array, access,
+task, or protected object, the object_declaration may include the
+definition of the (anonymous) type of the object.
+
+ _Syntax_
+
+2/3
+ {AI95-00385-01AI95-00385-01} {AI95-00406-01AI95-00406-01}
+ {AI05-0183-1AI05-0183-1} object_declaration ::=
+ defining_identifier_list : [aliased] [constant]
+ subtype_indication [:= expression]
+ [aspect_specification];
+ | defining_identifier_list : [aliased] [constant]
+ access_definition [:= expression]
+ [aspect_specification];
+ | defining_identifier_list : [aliased] [constant]
+ array_type_definition [:= expression]
+ [aspect_specification];
+ | single_task_declaration
+ | single_protected_declaration
+
+3
+ defining_identifier_list ::=
+ defining_identifier {, defining_identifier}
+
+ _Name Resolution Rules_
+
+4
+For an object_declaration with an expression following the compound
+delimiter :=, the type expected for the expression is that of the
+object. This expression is called the initialization expression.
+
+ _Legality Rules_
+
+5/2
+{AI95-00287-01AI95-00287-01} An object_declaration without the reserved
+word constant declares a variable object. If it has a
+subtype_indication or an array_type_definition that defines an
+indefinite subtype, then there shall be an initialization expression.
+
+ _Static Semantics_
+
+6/3
+{AI05-0264-1AI05-0264-1} {AI05-0299-1AI05-0299-1} An object_declaration
+with the reserved word constant declares a constant object. If it has
+an initialization expression, then it is called a full constant
+declaration. Otherwise, it is called a deferred constant declaration.
+The rules for deferred constant declarations are given in subclause
+*note 7.4::. The rules for full constant declarations are given in this
+subclause.
+
+7
+Any declaration that includes a defining_identifier_list with more than
+one defining_identifier is equivalent to a series of declarations each
+containing one defining_identifier from the list, with the rest of the
+text of the declaration copied for each declaration in the series, in
+the same order as the list. The remainder of this International
+Standard relies on this equivalence; explanations are given for
+declarations with a single defining_identifier.
+
+8/2
+{AI95-00385-01AI95-00385-01} The subtype_indication, access_definition,
+or full type definition of an object_declaration defines the nominal
+subtype of the object. The object_declaration declares an object of the
+type of the nominal subtype.
+
+8.a/2
+ Discussion: {AI95-00385-01AI95-00385-01} The phrase "full type
+ definition" here includes the case of an anonymous array,
+ access, task, or protected type.
+
+8.1/2
+{AI95-00373-01AI95-00373-01} A component of an object is said to require
+late initialization if it has an access discriminant value constrained
+by a per-object expression, or if it has an initialization expression
+that includes a name denoting the current instance of the type or
+denoting an access discriminant.
+
+8.b/2
+ Reason: Such components can depend on the values of other
+ components of the object. We want to initialize them as late
+ and as reproducibly as possible.
+
+ _Dynamic Semantics_
+
+9/2
+{AI95-00363-01AI95-00363-01} If a composite object declared by an
+object_declaration has an unconstrained nominal subtype, then if this
+subtype is indefinite or the object is constant the actual subtype of
+this object is constrained. The constraint is determined by the bounds
+or discriminants (if any) of its initial value; the object is said to be
+constrained by its initial value. When not constrained by its initial
+value, the actual and nominal subtypes of the object are the same. If
+its actual subtype is constrained, the object is called a constrained
+object.
+
+10
+For an object_declaration without an initialization expression, any
+initial values for the object or its subcomponents are determined by the
+implicit initial values defined for its nominal subtype, as follows:
+
+11
+ * The implicit initial value for an access subtype is the null value
+ of the access type.
+
+11.1/3
+ * {AI05-0228-1AI05-0228-1} The implicit initial value for a scalar
+ subtype that has the Default_Value aspect specified is the value of
+ that aspect converted to the nominal subtype (which might raise
+ Constraint_Error -- see *note 4.6::, "*note 4.6:: Type
+ Conversions");
+
+11.a.1/3
+ Ramification: This is a Dynamic Semantics rule, so the
+ visibility of the aspect_specification is not relevant -- if
+ the full type for a private type has the Default_Value aspect
+ specified, partial views of the type also have this implicit
+ initial value.
+
+12
+ * The implicit initial (and only) value for each discriminant of a
+ constrained discriminated subtype is defined by the subtype.
+
+13/3
+ * {AI05-0228-1AI05-0228-1} For a (definite) composite subtype, the
+ implicit initial value of each component with a default_expression
+ is obtained by evaluation of this expression and conversion to the
+ component's nominal subtype (which might raise Constraint_Error),
+ unless the component is a discriminant of a constrained subtype
+ (the previous case), or is in an excluded variant (see *note
+ 3.8.1::). For each component that does not have a
+ default_expression, if the composite subtype has the
+ Default_Component_Value aspect specified, the implicit initial
+ value is the value of that aspect converted to the component's
+ nominal subtype; otherwise, any implicit initial values are those
+ determined by the component's nominal subtype.
+
+14
+ * For a protected or task subtype, there is an implicit component (an
+ entry queue) corresponding to each entry, with its implicit initial
+ value being an empty queue.
+
+14.a
+ Implementation Note: The implementation may add implicit
+ components for its own use, which might have implicit initial
+ values. For a task subtype, such components might represent
+ the state of the associated thread of control. For a type
+ with dynamic-sized components, such implicit components might
+ be used to hold the offset to some explicit component.
+
+15
+The elaboration of an object_declaration proceeds in the following
+sequence of steps:
+
+16/2
+ 1. {AI95-00385-01AI95-00385-01} The subtype_indication (*note
+ 3.2.2: S0027.), access_definition (*note 3.10: S0084.),
+ array_type_definition (*note 3.6: S0051.), single_task_declaration
+ (*note 9.1: S0206.), or single_protected_declaration (*note 9.4:
+ S0211.) is first elaborated. This creates the nominal subtype (and
+ the anonymous type in the last four cases).
+
+17
+ 2. If the object_declaration includes an initialization
+ expression, the (explicit) initial value is obtained by evaluating
+ the expression and converting it to the nominal subtype (which
+ might raise Constraint_Error -- see *note 4.6::).
+
+18/2
+ 3. {8652/00028652/0002} {AI95-00171-01AI95-00171-01}
+ {AI95-00373-01AI95-00373-01} The object is created, and, if there
+ is not an initialization expression, the object is initialized by
+ default. When an object is initialized by default, any per-object
+ constraints (see *note 3.8::) are elaborated and any implicit
+ initial values for the object or for its subcomponents are obtained
+ as determined by the nominal subtype. Any initial values (whether
+ explicit or implicit) are assigned to the object or to the
+ corresponding subcomponents. As described in *note 5.2:: and *note
+ 7.6::, Initialize and Adjust procedures can be called.
+
+18.a
+ Discussion: For a per-object constraint that contains some
+ per-object expressions and some non-per-object expressions,
+ the values used for the constraint consist of the values of
+ the non-per-object expressions evaluated at the point of the
+ type_declaration, and the values of the per-object expressions
+ evaluated at the point of the creation of the object.
+
+18.b
+ The elaboration of per-object constraints was presumably
+ performed as part of the dependent compatibility check in Ada
+ 83. If the object is of a limited type with an access
+ discriminant, the access_definition is elaborated at this time
+ (see *note 3.7::).
+
+18.c
+ Reason: The reason we say that evaluating an explicit
+ initialization expression happens before creating the object
+ is that in some cases it is impossible to know the size of the
+ object being created until its initial value is known, as in
+ "X: String := Func_Call(...);". The implementation can create
+ the object early in the common case where the size can be
+ known early, since this optimization is semantically neutral.
+
+19/2
+ This paragraph was deleted.{AI95-00373-01AI95-00373-01}
+
+19.a
+ Ramification: Since the initial values have already been
+ converted to the appropriate nominal subtype, the only
+ Constraint_Errors that might occur as part of these
+ assignments are for values outside their base range that are
+ used to initialize unconstrained numeric subcomponents. See
+ *note 3.5::.
+
+20/2
+{AI95-00373-01AI95-00373-01} For the third step above, evaluations and
+assignments are performed in an arbitrary order subject to the following
+restrictions:
+
+20.1/2
+ * {AI95-00373-01AI95-00373-01} Assignment to any part of the object
+ is preceded by the evaluation of the value that is to be assigned.
+
+20.a.1/2
+ Reason: Duh. But we ought to say it. Note that, like any
+ rule in the International Standard, it doesn't prevent an
+ "as-if" optimization; as long as the semantics as observed
+ from the program are correct, the compiler can generate any
+ code it wants.
+
+20.2/2
+ * {AI95-00373-01AI95-00373-01} The evaluation of a default_expression
+ that includes the name of a discriminant is preceded by the
+ assignment to that discriminant.
+
+20.a.2/2
+ Reason: Duh again. But we have to say this, too. It's odd
+ that Ada 95 only required the default expressions to be
+ evaluated before the discriminant is used; it says nothing
+ about discriminant values that come from subtype_indications.
+
+20.3/2
+ * {AI95-00373-01AI95-00373-01} The evaluation of the
+ default_expression for any component that depends on a discriminant
+ is preceded by the assignment to that discriminant.
+
+20.a
+ Reason: For example:
+
+20.b
+ type R(D : Integer := F) is
+ record
+ S : String(1..D) := (others => G);
+ end record;
+
+20.c
+ X : R;
+
+20.d
+ For the elaboration of the declaration of X, it is important
+ that F be evaluated before the aggregate.
+
+20.4/3
+ * {AI95-00373-01AI95-00373-01} {AI05-0092-1AI05-0092-1} The
+ assignments to any components, including implicit components, not
+ requiring late initialization precede the initial value evaluations
+ for any components requiring late initialization; if two components
+ both require late initialization, then assignments to parts of the
+ component occurring earlier in the order of the component
+ declarations precede the initial value evaluations of the component
+ occurring later.
+
+20.e/2
+ Reason: Components that require late initialization can refer
+ to the entire object during their initialization. We want
+ them to be initialized as late as possible to reduce the
+ chance that their initialization depends on uninitialized
+ components. For instance:
+
+20.f/2
+ type T (D : Natural) is
+ limited record
+ C1 : T1 (T'Access);
+ C2 : Natural := F (D);
+ C3 : String (1 .. D) := (others => ' ');
+ end record;
+
+20.g/2
+ Component C1 requires late initialization. The initialization
+ could depend on the values of any component of T, including D,
+ C2, or C3. Therefore, we want to it to be initialized last.
+ Note that C2 and C3 do not require late initialization; they
+ only have to be initialized after D.
+
+20.h/2
+ It is possible for there to be more than one component that
+ requires late initialization. In this case, the language
+ can't prevent problems, because all of the components can't be
+ the last one initialized. In this case, we specify the order
+ of initialization for components requiring late
+ initialization; by doing so, programmers can arrange their
+ code to avoid accessing uninitialized components, and such
+ arrangements are portable. Note that if the program accesses
+ an uninitialized component, *note 13.9.1:: defines the
+ execution to be erroneous.
+
+21/3
+{AI05-0228-1AI05-0228-1} [There is no implicit initial value defined for
+a scalar subtype unless the Default_Value aspect has been specified for
+the type.] In the absence of an explicit initialization or the
+specification of the Default_Value aspect, a newly created scalar object
+might have a value that does not belong to its subtype (see *note
+13.9.1:: and *note H.1::).
+
+21.a
+ To be honest: It could even be represented by a bit pattern
+ that doesn't actually represent any value of the type at all,
+ such as an invalid internal code for an enumeration type, or a
+ NaN for a floating point type. It is a generally a bounded
+ error to reference scalar objects with such "invalid
+ representations", as explained in *note 13.9.1::, "*note
+ 13.9.1:: Data Validity".
+
+21.b
+ Ramification: There is no requirement that two objects of the
+ same scalar subtype have the same implicit initial "value" (or
+ representation). It might even be the case that two
+ elaborations of the same object_declaration produce two
+ different initial values. However, any particular
+ uninitialized object is default-initialized to a single value
+ (or invalid representation). Thus, multiple reads of such an
+ uninitialized object will produce the same value each time (if
+ the implementation chooses not to detect the error).
+
+ NOTES
+
+22
+ 10 Implicit initial values are not defined for an indefinite
+ subtype, because if an object's nominal subtype is indefinite, an
+ explicit initial value is required.
+
+23/3
+ 11 {AI05-0092-1AI05-0092-1} {AI05-0255-1AI05-0255-1} As indicated
+ above, a stand-alone object is an object declared by an
+ object_declaration. Similar definitions apply to "stand-alone
+ constant" and "stand-alone variable." A subcomponent of an object
+ is not a stand-alone object, nor is an object that is created by an
+ allocator. An object declared by a loop_parameter_specification,
+ iterator_specification, parameter_specification,
+ entry_index_specification, choice_parameter_specification,
+ extended_return_statement, or a formal_object_declaration of mode
+ in out is not considered a stand-alone object.
+
+24
+ 12 The type of a stand-alone object cannot be abstract (see *note
+ 3.9.3::).
+
+ _Examples_
+
+25
+Example of a multiple object declaration:
+
+26
+ -- the multiple object declaration
+
+27/2
+ {AI95-00433-01AI95-00433-01} John, Paul : not null Person_Name := new Person(Sex => M); -- see *note 3.10.1::
+
+28
+ -- is equivalent to the two single object declarations in the order given
+
+29/2
+ {AI95-00433-01AI95-00433-01} John : not null Person_Name := new Person(Sex => M);
+ Paul : not null Person_Name := new Person(Sex => M);
+
+30
+Examples of variable declarations:
+
+31/2
+ {AI95-00433-01AI95-00433-01} Count, Sum : Integer;
+ Size : Integer range 0 .. 10_000 := 0;
+ Sorted : Boolean := False;
+ Color_Table : array(1 .. Max) of Color;
+ Option : Bit_Vector(1 .. 10) := (others => True);
+ Hello : aliased String := "Hi, world.";
+ [Unicode 952], [Unicode 966] : Float range -PI .. +PI;
+
+32
+Examples of constant declarations:
+
+33/2
+ {AI95-00433-01AI95-00433-01} Limit : constant Integer := 10_000;
+ Low_Limit : constant Integer := Limit/10;
+ Tolerance : constant Real := Dispersion(1.15);
+ Hello_Msg : constant access String := Hello'Access; -- see *note 3.10.2::
+
+ _Extensions to Ada 83_
+
+33.a
+ The syntax rule for object_declaration is modified to allow
+ the aliased reserved word.
+
+33.b
+ A variable declared by an object_declaration can be
+ constrained by its initial value; that is, a variable of a
+ nominally unconstrained array subtype, or discriminated type
+ without defaults, can be declared so long as it has an
+ explicit initial value. In Ada 83, this was permitted for
+ constants, and for variables created by allocators, but not
+ for variables declared by object_declarations. This is
+ particularly important for tagged class-wide types, since
+ there is no way to constrain them explicitly, and so an
+ initial value is the only way to provide a constraint. It is
+ also important for generic formal private types with unknown
+ discriminants.
+
+33.c
+ We now allow an unconstrained_array_definition in an
+ object_declaration. This allows an object of an anonymous
+ array type to have its bounds determined by its initial value.
+ This is for uniformity: If one can write "X: constant
+ array(Integer range 1..10) of Integer := ...;" then it makes
+ sense to also allow "X: constant array(Integer range <>) of
+ Integer := ...;". (Note that if anonymous array types are
+ ever sensible, a common situation is for a table implemented
+ as an array. Tables are often constant, and for constants,
+ there's usually no point in forcing the user to count the
+ number of elements in the value.)
+
+ _Wording Changes from Ada 83_
+
+33.d
+ We have moved the syntax for object_declarations into this
+ subclause.
+
+33.e
+ Deferred constants no longer have a separate syntax rule, but
+ rather are incorporated in object_declaration as constants
+ declared without an initialization expression.
+
+ _Inconsistencies With Ada 95_
+
+33.f/2
+ {AI95-00363-01AI95-00363-01} Unconstrained aliased objects of
+ types with discriminants with defaults are no longer
+ constrained by their initial values. This means that a
+ program that raised Constraint_Error from an attempt to change
+ the discriminants will no longer do so. The change only
+ affects programs that depended on the raising of
+ Constraint_Error in this case, so the inconsistency is
+ unlikely to occur outside of the ACATS. This change may
+ however cause compilers to implement these objects
+ differently, possibly taking additional memory or time. This
+ is unlikely to be worse than the differences caused by any
+ major compiler upgrade.
+
+ _Extensions to Ada 95_
+
+33.g/2
+ {AI95-00287-01AI95-00287-01} A constant may have a limited
+ type; the initialization expression has to be built-in-place
+ (see *note 7.5::).
+
+33.h/2
+ {AI95-00385-01AI95-00385-01} {AI95-00406-01AI95-00406-01} A
+ stand-alone object may have an anonymous access type.
+
+ _Wording Changes from Ada 95_
+
+33.i/2
+ {8652/00028652/0002} {AI95-00171-01AI95-00171-01} Corrigendum:
+ Corrected wording to say that per-object constraints are
+ elaborated (not evaluated).
+
+33.j/2
+ {AI95-00373-01AI95-00373-01} The rules for evaluating default
+ initialization have been tightened. In particular, components
+ whose default initialization can refer to the rest of the
+ object are required to be initialized last.
+
+33.k/2
+ {AI95-00433-01AI95-00433-01} Added examples of various new
+ constructs.
+
+ _Extensions to Ada 2005_
+
+33.l/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in an object_declaration. This is described in *note
+ 13.1.1::.
+
+ _Wording Changes from Ada 2005_
+
+33.m/3
+ {AI05-0228-1AI05-0228-1} Implicit initial values can now be
+ given for scalar types and for scalar array components, using
+ the Default_Value (see *note 3.5::) and
+ Default_Component_Value (see *note 3.6::) aspects; the
+ extension is documented there.
+
+\1f
+File: aarm2012.info, Node: 3.3.2, Prev: 3.3.1, Up: 3.3
+
+3.3.2 Number Declarations
+-------------------------
+
+1
+A number_declaration declares a named number.
+
+1.a/3
+ Discussion: {AI05-0299-1AI05-0299-1} If a value or other
+ property of a construct is required to be static that means it
+ is required to be determined prior to execution. A static
+ expression is an expression whose value is computed at compile
+ time and is usable in contexts where the actual value might
+ affect the legality of the construct. This is fully defined
+ in subclause *note 4.9::.
+
+ _Syntax_
+
+2
+ number_declaration ::=
+ defining_identifier_list : constant := static_expression;
+
+ _Name Resolution Rules_
+
+3
+The static_expression given for a number_declaration is expected to be
+of any numeric type.
+
+ _Legality Rules_
+
+4/3
+{AI05-0299-1AI05-0299-1} The static_expression given for a number
+declaration shall be a static expression, as defined by subclause *note
+4.9::.
+
+ _Static Semantics_
+
+5
+The named number denotes a value of type universal_integer if the type
+of the static_expression is an integer type. The named number denotes a
+value of type universal_real if the type of the static_expression is a
+real type.
+
+6
+The value denoted by the named number is the value of the
+static_expression, converted to the corresponding universal type.
+
+ _Dynamic Semantics_
+
+7
+The elaboration of a number_declaration has no effect.
+
+7.a
+ Proof: Since the static_expression was evaluated at compile
+ time.
+
+ _Examples_
+
+8
+Examples of number declarations:
+
+9
+ Two_Pi : constant := 2.0*Ada.Numerics.Pi; -- a real number (see *note A.5::)
+
+10/2
+ {AI95-00433-01AI95-00433-01} Max : constant := 500; -- an integer number
+ Max_Line_Size : constant := Max/6; -- the integer 83
+ Power_16 : constant := 2**16; -- the integer 65_536
+ One, Un, Eins : constant := 1; -- three different names for 1
+
+ _Extensions to Ada 83_
+
+10.a
+ We now allow a static expression of any numeric type to
+ initialize a named number. For integer types, it was possible
+ in Ada 83 to use 'Pos to define a named number, but there was
+ no way to use a static expression of some nonuniversal real
+ type to define a named number. This change is upward
+ compatible because of the preference rule for the operators of
+ the root numeric types.
+
+ _Wording Changes from Ada 83_
+
+10.b
+ We have moved the syntax rule into this subclause.
+
+10.c
+ AI83-00263 describes the elaboration of a number declaration
+ in words similar to that of an object_declaration. However,
+ since there is no expression to be evaluated and no object to
+ be created, it seems simpler to say that the elaboration has
+ no effect.
+
+\1f
+File: aarm2012.info, Node: 3.4, Next: 3.5, Prev: 3.3, Up: 3
+
+3.4 Derived Types and Classes
+=============================
+
+1/2
+{AI95-00401-01AI95-00401-01} {AI95-00419-01AI95-00419-01} A
+derived_type_definition defines a derived type (and its first subtype)
+whose characteristics are derived from those of a parent type, and
+possibly from progenitor types.
+
+1.a/2
+ Glossary entry: A derived type is a type defined in terms of
+ one or more other types given in a derived type definition.
+ The first of those types is the parent type of the derived
+ type and any others are progenitor types. Each class
+ containing the parent type or a progenitor type also contains
+ the derived type. The derived type inherits properties such
+ as components and primitive operations from the parent and
+ progenitors. A type together with the types derived from it
+ (directly or indirectly) form a derivation class.
+
+1.1/2
+{AI95-00442-01AI95-00442-01} A class of types is a set of types that is
+closed under derivation; that is, if the parent or a progenitor type of
+a derived type belongs to a class, then so does the derived type. By
+saying that a particular group of types forms a class, we are saying
+that all derivatives of a type in the set inherit the characteristics
+that define that set. The more general term category of types is used
+for a set of types whose defining characteristics are not necessarily
+inherited by derivatives; for example, limited, abstract, and interface
+are all categories of types, but not classes of types.
+
+1.b/2
+ Ramification: A class of types is also a category of types.
+
+ _Syntax_
+
+2/2
+ {AI95-00251-01AI95-00251-01} {AI95-00419-01AI95-00419-01}
+ derived_type_definition ::=
+ [abstract] [limited] new parent_subtype_indication [[and
+ interface_list] record_extension_part]
+
+ _Legality Rules_
+
+3/2
+{AI95-00251-01AI95-00251-01} {AI95-00401-01AI95-00401-01}
+{AI95-00419-01AI95-00419-01} The parent_subtype_indication defines the
+parent subtype; its type is the parent type. The interface_list defines
+the progenitor types (see *note 3.9.4::). A derived type has one parent
+type and zero or more progenitor types.
+
+3.a/2
+ Glossary entry: The parent of a derived type is the first type
+ given in the definition of the derived type. The parent can
+ be almost any kind of type, including an interface type.
+
+4
+A type shall be completely defined (see *note 3.11.1::) prior to being
+specified as the parent type in a derived_type_definition -- [the
+full_type_declarations for the parent type and any of its subcomponents
+have to precede the derived_type_definition.]
+
+4.a
+ Discussion: This restriction does not apply to the ancestor
+ type of a private extension -- see *note 7.3::; such a type
+ need not be completely defined prior to the
+ private_extension_declaration. However, the restriction does
+ apply to record extensions, so the ancestor type will have to
+ be completely defined prior to the full_type_declaration
+ corresponding to the private_extension_declaration.
+
+4.b
+ Reason: We originally hoped we could relax this restriction.
+ However, we found it too complex to specify the rules for a
+ type derived from an incompletely defined limited type that
+ subsequently became nonlimited.
+
+5/2
+{AI95-00401-01AI95-00401-01} If there is a record_extension_part, the
+derived type is called a record extension of the parent type. A
+record_extension_part shall be provided if and only if the parent type
+is a tagged type. [An interface_list shall be provided only if the
+parent type is a tagged type.]
+
+5.a.1/2
+ Proof: {AI95-00401-01AI95-00401-01} The syntax only allows an
+ interface_list to appear with a record_extension_part, and a
+ record_extension_part can only be provided if the parent type
+ is a tagged type. We give the last sentence anyway for
+ completeness.
+
+5.a
+ Implementation Note: We allow a record extension to inherit
+ discriminants; an early version of Ada 9X did not. If the
+ parent subtype is unconstrained, it can be implemented as
+ though its discriminants were repeated in a new
+ known_discriminant_part and then used to constrain the old
+ ones one-for-one. However, in an extension aggregate, the
+ discriminants in this case do not appear in the component
+ association list.
+
+5.b/2
+ Ramification: {AI95-00114-01AI95-00114-01} This rule needs to
+ be rechecked in the visible part of an instance of a generic
+ unit because of the "only if" part of the rule. For example:
+
+5.c/2
+ generic
+ type T is private;
+ package P is
+ type Der is new T;
+ end P;
+
+5.d/2
+ package I is new P (Some_Tagged_Type); -- illegal
+
+5.e/2
+ {AI95-00114-01AI95-00114-01} The instantiation is illegal
+ because a tagged type is being extended in the visible part
+ without a record_extension_part. Note that this is legal in
+ the private part or body of an instance, both to avoid a
+ contract model violation, and because no code that can see
+ that the type is actually tagged can also see the derived type
+ declaration.
+
+5.f/2
+ No recheck is needed for derived types with a
+ record_extension_part, as that has to be derived from
+ something that is known to be tagged (otherwise the template
+ is illegal).
+
+5.1/3
+{AI95-00419-01AI95-00419-01} {AI05-0096-1AI05-0096-1} If the reserved
+word limited appears in a derived_type_definition, the parent type shall
+be a limited type. If the parent type is a tagged formal type, then in
+addition to the places where Legality Rules normally apply (see *note
+12.3::), this rule applies also in the private part of an instance of a
+generic unit.
+
+5.g/2
+ Reason: We allow limited because we don't inherit limitedness
+ from interfaces, so we must have a way to derive a limited
+ type from interfaces. The word limited has to be legal when
+ the parent could be an interface, and that includes generic
+ formal abstract types. Since we have to allow it in this
+ case, we might as well allow it everywhere as documentation,
+ to make it explicit that the type is limited.
+
+5.h/2
+ However, we do not want to allow limited when the parent is
+ nonlimited: limitedness cannot change in a derivation tree.
+
+5.i/3
+ If the parent type is an untagged limited formal type with an
+ actual type that is nonlimited, we allow derivation as a
+ limited type in the private part or body as no place could
+ have visibility on the resulting type where it was known to be
+ nonlimited (outside of the instance). (See the previous
+ paragraph's annotations for an explanation of this.) However,
+ if the parent type is a tagged limited formal type with an
+ actual type that is nonlimited, it would be possible to pass a
+ value of the limited type extension to a class-wide type of
+ the parent, which would be nonlimited. That's too weird to
+ allow (even though all of the extension components would have
+ to be nonlimited because the rules of *note 3.9.1:: are
+ rechecked), so we have a special rule to prevent that in the
+ private part (type extension from a formal type is illegal in
+ a generic package body).
+
+ _Static Semantics_
+
+6
+The first subtype of the derived type is unconstrained if a
+known_discriminant_part is provided in the declaration of the derived
+type, or if the parent subtype is unconstrained. Otherwise, the
+constraint of the first subtype corresponds to that of the parent
+subtype in the following sense: it is the same as that of the parent
+subtype except that for a range constraint (implicit or explicit), the
+value of each bound of its range is replaced by the corresponding value
+of the derived type.
+
+6.a
+ Discussion: A digits_constraint in a subtype_indication for a
+ decimal fixed point subtype always imposes a range constraint,
+ implicitly if there is no explicit one given. See *note
+ 3.5.9::, "*note 3.5.9:: Fixed Point Types".
+
+6.1/2
+{AI95-00231-01AI95-00231-01} The first subtype of the derived type
+excludes null (see *note 3.10::) if and only if the parent subtype
+excludes null.
+
+7/3
+{AI05-0110-1AI05-0110-1} The characteristics and implicitly declared
+primitive subprograms of the derived type are defined as follows:
+
+7.a/3
+ Ramification: {AI05-0110-1AI05-0110-1} The characteristics of
+ a type do not include its primitive subprograms (primitive
+ subprograms include predefined operators). The rules
+ governing availability/visibility and inheritance of
+ characteristics are separate from those for primitive
+ subprograms.
+
+8/2
+ * {AI95-00251-01AI95-00251-01} {AI95-00401-01AI95-00401-01}
+ {AI95-00442-01AI95-00442-01} [If the parent type or a progenitor
+ type belongs to a class of types, then the derived type also
+ belongs to that class.] The following sets of types, as well as
+ any higher-level sets composed from them, are classes in this
+ sense[, and hence the characteristics defining these classes are
+ inherited by derived types from their parent or progenitor types]:
+ signed integer, modular integer, ordinary fixed, decimal fixed,
+ floating point, enumeration, boolean, character,
+ access-to-constant, general access-to-variable, pool-specific
+ access-to-variable, access-to-subprogram, array, string, non-array
+ composite, nonlimited, untagged record, tagged, task, protected,
+ and synchronized tagged.
+
+8.a
+ Discussion: This is inherent in our notion of a "class" of
+ types. It is not mentioned in the initial definition of
+ "class" since at that point type derivation has not been
+ defined. In any case, this rule ensures that every class of
+ types is closed under derivation.
+
+9
+ * If the parent type is an elementary type or an array type, then the
+ set of possible values of the derived type is a copy of the set of
+ possible values of the parent type. For a scalar type, the base
+ range of the derived type is the same as that of the parent type.
+
+9.a
+ Discussion: The base range of a type defined by an
+ integer_type_definition or a real_type_definition is
+ determined by the _definition, and is not necessarily the same
+ as that of the corresponding root numeric type from which the
+ newly defined type is implicitly derived. Treating numerics
+ types as implicitly derived from one of the two root numeric
+ types is simply to link them into a type hierarchy; such an
+ implicit derivation does not follow all the rules given here
+ for an explicit derived_type_definition.
+
+10
+ * If the parent type is a composite type other than an array type,
+ then the components, protected subprograms, and entries that are
+ declared for the derived type are as follows:
+
+11
+ * The discriminants specified by a new
+ known_discriminant_part, if there is one; otherwise, each
+ discriminant of the parent type (implicitly declared in
+ the same order with the same specifications) -- in the
+ latter case, the discriminants are said to be inherited,
+ or if unknown in the parent, are also unknown in the
+ derived type;
+
+12
+ * Each nondiscriminant component, entry, and protected
+ subprogram of the parent type, implicitly declared in the
+ same order with the same declarations; these components,
+ entries, and protected subprograms are said to be
+ inherited;
+
+12.a
+ Ramification: The profiles of entries and protected
+ subprograms do not change upon type derivation, although the
+ type of the "implicit" parameter identified by the prefix of
+ the name in a call does.
+
+12.b
+ To be honest: Any name in the parent type_declaration that
+ denotes the current instance of the type is replaced with a
+ name denoting the current instance of the derived type,
+ converted to the parent type.
+
+13
+ * Each component declared in a record_extension_part, if
+ any.
+
+14
+ Declarations of components, protected subprograms, and entries,
+ whether implicit or explicit, occur immediately within the
+ declarative region of the type, in the order indicated above,
+ following the parent subtype_indication.
+
+14.a
+ Discussion: The order of declarations within the region
+ matters for record_aggregates and extension_aggregates.
+
+14.b
+ Ramification: In most cases, these things are implicitly
+ declared immediately following the parent subtype_indication.
+ However, *note 7.3.1::, "*note 7.3.1:: Private Operations"
+ defines some cases in which they are implicitly declared
+ later, and some cases in which the are not declared at all.
+
+14.c
+ Discussion: The place of the implicit declarations of
+ inherited components matters for visibility -- they are not
+ visible in the known_discriminant_part nor in the parent
+ subtype_indication, but are usually visible within the
+ record_extension_part, if any (although there are restrictions
+ on their use). Note that a discriminant specified in a new
+ known_discriminant_part is not considered "inherited" even if
+ it has the same name and subtype as a discriminant of the
+ parent type.
+
+15/2
+ * This paragraph was deleted.{AI95-00419-01AI95-00419-01}
+
+16
+ * [For each predefined operator of the parent type, there is a
+ corresponding predefined operator of the derived type.]
+
+16.a
+ Proof: This is a ramification of the fact that each class that
+ includes the parent type also includes the derived type, and
+ the fact that the set of predefined operators that is defined
+ for a type, as described in *note 4.5::, is determined by the
+ classes to which it belongs.
+
+16.b
+ Reason: Predefined operators are handled separately because
+ they follow a slightly different rule than user-defined
+ primitive subprograms. In particular the systematic
+ replacement described below does not apply fully to the
+ relational operators for Boolean and the exponentiation
+ operator for Integer. The relational operators for a type
+ derived from Boolean still return Standard.Boolean. The
+ exponentiation operator for a type derived from Integer still
+ expects Standard.Integer for the right operand. In addition,
+ predefined operators "reemerge" when a type is the actual type
+ corresponding to a generic formal type, so they need to be
+ well defined even if hidden by user-defined primitive
+ subprograms.
+
+17/2
+ * {AI95-00401-01AI95-00401-01} For each user-defined primitive
+ subprogram (other than a user-defined equality operator -- see
+ below) of the parent type or of a progenitor type that already
+ exists at the place of the derived_type_definition, there exists a
+ corresponding inherited primitive subprogram of the derived type
+ with the same defining name. Primitive user-defined equality
+ operators of the parent type and any progenitor types are also
+ inherited by the derived type, except when the derived type is a
+ nonlimited record extension, and the inherited operator would have
+ a profile that is type conformant with the profile of the
+ corresponding predefined equality operator; in this case, the
+ user-defined equality operator is not inherited, but is rather
+ incorporated into the implementation of the predefined equality
+ operator of the record extension (see *note 4.5.2::).
+
+17.a
+ Ramification: We say "...already exists..." rather than "is
+ visible" or "has been declared" because there are certain
+ operations that are declared later, but still exist at the
+ place of the derived_type_definition, and there are operations
+ that are never declared, but still exist. These cases are
+ explained in *note 7.3.1::.
+
+17.b
+ Note that nonprivate extensions can appear only after the last
+ primitive subprogram of the parent -- the freezing rules
+ ensure this.
+
+17.c
+ Reason: A special case is made for the equality operators on
+ nonlimited record extensions because their predefined equality
+ operators are already defined in terms of the primitive
+ equality operator of their parent type (and of the tagged
+ components of the extension part). Inheriting the parent's
+ equality operator as is would be undesirable, because it would
+ ignore any components of the extension part. On the other
+ hand, if the parent type is limited, then any user-defined
+ equality operator is inherited as is, since there is no
+ predefined equality operator to take its place.
+
+17.d/2
+ Ramification: {AI95-00114-01AI95-00114-01} Because
+ user-defined equality operators are not inherited by
+ nonlimited record extensions, the formal parameter names of =
+ and /= revert to Left and Right, even if different formal
+ parameter names were used in the user-defined equality
+ operators of the parent type.
+
+17.e/2
+ Discussion: {AI95-00401-01AI95-00401-01} This rule only
+ describes what operations are inherited; the rules that
+ describe what happens when there are conflicting inherited
+ subprograms are found in *note 8.3::.
+
+18/3
+ {AI95-00401-01AI95-00401-01} {AI05-0164-1AI05-0164-1}
+ {AI05-0240-1AI05-0240-1} The profile of an inherited subprogram
+ (including an inherited enumeration literal) is obtained from the
+ profile of the corresponding (user-defined) primitive subprogram of
+ the parent or progenitor type, after systematic replacement of each
+ subtype of its profile (see *note 6.1::) that is of the parent or
+ progenitor type, other than those subtypes found in the designated
+ profile of an access_definition, with a corresponding subtype of
+ the derived type. For a given subtype of the parent or progenitor
+ type, the corresponding subtype of the derived type is defined as
+ follows:
+
+19
+ * If the declaration of the derived type has neither a
+ known_discriminant_part nor a record_extension_part, then
+ the corresponding subtype has a constraint that
+ corresponds (as defined above for the first subtype of
+ the derived type) to that of the given subtype.
+
+20
+ * If the derived type is a record extension, then the
+ corresponding subtype is the first subtype of the derived
+ type.
+
+21
+ * If the derived type has a new known_discriminant_part but
+ is not a record extension, then the corresponding subtype
+ is constrained to those values that when converted to the
+ parent type belong to the given subtype (see *note
+ 4.6::).
+
+21.a
+ Reason: An inherited subprogram of an untagged type has an
+ Intrinsic calling convention, which precludes the use of the
+ Access attribute. We preclude 'Access because correctly
+ performing all required constraint checks on an indirect call
+ to such an inherited subprogram was felt to impose an
+ undesirable implementation burden.
+
+21.b/3
+ {AI05-0164-1AI05-0164-1} Note that the exception to
+ substitution of the parent or progenitor type applies only in
+ the profiles of anonymous access-to-subprogram types. The
+ exception is necessary to avoid calling an
+ access-to-subprogram with types and/or constraints different
+ than expected by the actual routine.
+
+22/2
+ {AI95-00401-01AI95-00401-01} The same formal parameters have
+ default_expressions in the profile of the inherited subprogram.
+ [Any type mismatch due to the systematic replacement of the parent
+ or progenitor type by the derived type is handled as part of the
+ normal type conversion associated with parameter passing -- see
+ *note 6.4.1::.]
+
+22.a/2
+ Reason: {AI95-00401-01AI95-00401-01} We don't introduce the
+ type conversion explicitly here since conversions to record
+ extensions or on access parameters are not generally legal.
+ Furthermore, any type conversion would just be "undone" since
+ the subprogram of the parent or progenitor is ultimately being
+ called anyway. (Null procedures can be inherited from a
+ progenitor without being overridden, so it is possible to call
+ subprograms of an interface.)
+
+23/2
+{AI95-00401-01AI95-00401-01} If a primitive subprogram of the parent or
+progenitor type is visible at the place of the derived_type_definition,
+then the corresponding inherited subprogram is implicitly declared
+immediately after the derived_type_definition. Otherwise, the inherited
+subprogram is implicitly declared later or not at all, as explained in
+*note 7.3.1::.
+
+24
+A derived type can also be defined by a private_extension_declaration
+(*note 7.3: S0194.) (see *note 7.3::) or a
+formal_derived_type_definition (*note 12.5.1: S0285.) (see *note
+12.5.1::). Such a derived type is a partial view of the corresponding
+full or actual type.
+
+25
+All numeric types are derived types, in that they are implicitly derived
+from a corresponding root numeric type (see *note 3.5.4:: and *note
+3.5.6::).
+
+ _Dynamic Semantics_
+
+26
+The elaboration of a derived_type_definition creates the derived type
+and its first subtype, and consists of the elaboration of the
+subtype_indication (*note 3.2.2: S0027.) and the record_extension_part
+(*note 3.9.1: S0075.), if any. If the subtype_indication (*note 3.2.2:
+S0027.) depends on a discriminant, then only those expressions that do
+not depend on a discriminant are evaluated.
+
+26.a/2
+ Discussion: {AI95-00251-01AI95-00251-01} We don't mention the
+ interface_list, because it does not need elaboration (see
+ *note 3.9.4::). This is consistent with the handling of
+ discriminant_parts, which aren't elaborated either.
+
+27/2
+{AI95-00391-01AI95-00391-01} {AI95-00401-01AI95-00401-01} For the
+execution of a call on an inherited subprogram, a call on the
+corresponding primitive subprogram of the parent or progenitor type is
+performed; the normal conversion of each actual parameter to the subtype
+of the corresponding formal parameter (see *note 6.4.1::) performs any
+necessary type conversion as well. If the result type of the inherited
+subprogram is the derived type, the result of calling the subprogram of
+the parent or progenitor is converted to the derived type, or in the
+case of a null extension, extended to the derived type using the
+equivalent of an extension_aggregate with the original result as the
+ancestor_part and null record as the record_component_association_list.
+
+27.a/2
+ Discussion: {AI95-00391-01AI95-00391-01} If an inherited
+ function returns the derived type, and the type is a nonnull
+ record extension, then the inherited function shall be
+ overridden, unless the type is abstract (in which case the
+ function is abstract, and (unless overridden) cannot be called
+ except via a dispatching call). See *note 3.9.3::.
+
+ NOTES
+
+28
+ 13 Classes are closed under derivation -- any class that contains
+ a type also contains its derivatives. Operations available for a
+ given class of types are available for the derived types in that
+ class.
+
+29
+ 14 Evaluating an inherited enumeration literal is equivalent to
+ evaluating the corresponding enumeration literal of the parent
+ type, and then converting the result to the derived type. This
+ follows from their equivalence to parameterless functions.
+
+30
+ 15 A generic subprogram is not a subprogram, and hence cannot be a
+ primitive subprogram and cannot be inherited by a derived type. On
+ the other hand, an instance of a generic subprogram can be a
+ primitive subprogram, and hence can be inherited.
+
+31
+ 16 If the parent type is an access type, then the parent and the
+ derived type share the same storage pool; there is a null access
+ value for the derived type and it is the implicit initial value for
+ the type. See *note 3.10::.
+
+32
+ 17 If the parent type is a boolean type, the predefined relational
+ operators of the derived type deliver a result of the predefined
+ type Boolean (see *note 4.5.2::). If the parent type is an integer
+ type, the right operand of the predefined exponentiation operator
+ is of the predefined type Integer (see *note 4.5.6::).
+
+33
+ 18 Any discriminants of the parent type are either all inherited,
+ or completely replaced with a new set of discriminants.
+
+34
+ 19 For an inherited subprogram, the subtype of a formal parameter
+ of the derived type need not have any value in common with the
+ first subtype of the derived type.
+
+34.a
+ Proof: This happens when the parent subtype is constrained to
+ a range that does not overlap with the range of a subtype of
+ the parent type that appears in the profile of some primitive
+ subprogram of the parent type. For example:
+
+34.b
+ type T1 is range 1..100;
+ subtype S1 is T1 range 1..10;
+ procedure P(X : in S1); -- P is a primitive subprogram
+ type T2 is new T1 range 11..20;
+ -- implicitly declared:
+ -- procedure P(X : in T2'Base range 1..10);
+ -- X cannot be in T2'First .. T2'Last
+
+35
+ 20 If the reserved word abstract is given in the declaration of a
+ type, the type is abstract (see *note 3.9.3::).
+
+35.1/2
+ 21 {AI95-00251-01AI95-00251-01} {AI95-00401-01AI95-00401-01} An
+ interface type that has a progenitor type "is derived from" that
+ type. A derived_type_definition, however, never defines an
+ interface type.
+
+35.2/2
+ 22 {AI95-00345-01AI95-00345-01} It is illegal for the parent type
+ of a derived_type_definition to be a synchronized tagged type.
+
+35.a/3
+ Proof: {AI05-0299-1AI05-0299-1} *note 3.9.1:: prohibits record
+ extensions whose parent type is a synchronized tagged type,
+ and this subclause requires tagged types to have a record
+ extension. Thus there are no legal derivations. Note that a
+ synchronized interface can be used as a progenitor in an
+ interface_type_definition as well as in task and protected
+ types, but we do not allow concrete extensions of any
+ synchronized tagged type.
+
+ _Examples_
+
+36
+Examples of derived type declarations:
+
+37
+ type Local_Coordinate is new Coordinate; -- two different types
+ type Midweek is new Day range Tue .. Thu; -- see *note 3.5.1::
+ type Counter is new Positive; -- same range as Positive
+
+38
+ type Special_Key is new Key_Manager.Key; -- see *note 7.3.1::
+ -- the inherited subprograms have the following specifications:
+ -- procedure Get_Key(K : out Special_Key);
+ -- function "<"(X,Y : Special_Key) return Boolean;
+
+ _Inconsistencies With Ada 83_
+
+38.a
+ When deriving from a (nonprivate, nonderived) type in the same
+ visible part in which it is defined, if a predefined operator
+ had been overridden prior to the derivation, the derived type
+ will inherit the user-defined operator rather than the
+ predefined operator. The work-around (if the new behavior is
+ not the desired behavior) is to move the definition of the
+ derived type prior to the overriding of any predefined
+ operators.
+
+ _Incompatibilities With Ada 83_
+
+38.b
+ When deriving from a (nonprivate, nonderived) type in the same
+ visible part in which it is defined, a primitive subprogram of
+ the parent type declared before the derived type will be
+ inherited by the derived type. This can cause upward
+ incompatibilities in cases like this:
+
+38.c
+ package P is
+ type T is (A, B, C, D);
+ function F( X : T := A ) return Integer;
+ type NT is new T;
+ -- inherits F as
+ -- function F( X : NT := A ) return Integer;
+ -- in Ada 95 only
+ ...
+ end P;
+ ...
+ use P; -- Only one declaration of F from P is use-visible in
+ -- Ada 83; two declarations of F are use-visible in
+ -- Ada 95.
+ begin
+ ...
+ if F > 1 then ... -- legal in Ada 83, ambiguous in Ada 95
+
+ _Extensions to Ada 83_
+
+38.d
+ The syntax for a derived_type_definition is amended to include
+ an optional record_extension_part (see *note 3.9.1::).
+
+38.e
+ A derived type may override the discriminants of the parent by
+ giving a new discriminant_part.
+
+38.f
+ The parent type in a derived_type_definition may be a derived
+ type defined in the same visible part.
+
+38.g
+ When deriving from a type in the same visible part in which it
+ is defined, the primitive subprograms declared prior to the
+ derivation are inherited as primitive subprograms of the
+ derived type. See *note 3.2.3::.
+
+ _Wording Changes from Ada 83_
+
+38.h
+ We now talk about the classes to which a type belongs, rather
+ than a single class.
+
+ _Extensions to Ada 95_
+
+38.i/2
+ {AI05-0190-1AI05-0190-1} {AI95-00251-01AI95-00251-01}
+ {AI95-00401-01AI95-00401-01} A derived type may inherit from
+ multiple (interface) progenitors, as well as the parent type
+ -- see *note 3.9.4::, "*note 3.9.4:: Interface Types".
+
+38.j/2
+ {AI95-00419-01AI95-00419-01} A derived type may specify that
+ it is a limited type. This is required for interface
+ ancestors (from which limitedness is not inherited), but it is
+ generally useful as documentation of limitedness.
+
+ _Wording Changes from Ada 95_
+
+38.k/2
+ {AI95-00391-01AI95-00391-01} Defined the result of functions
+ for null extensions (which we no longer require to be
+ overridden - see *note 3.9.3::).
+
+38.l/2
+ {AI95-00442-01AI95-00442-01} Defined the term "category of
+ types" and used it in wording elsewhere; also specified the
+ language-defined categories that form classes of types (this
+ was never normatively specified in Ada 95).
+
+ _Incompatibilities With Ada 2005_
+
+38.m/3
+ {AI05-0096-1AI05-0096-1} Correction: Added a (re)check that
+ limited type extensions never are derived from nonlimited
+ types in generic private parts. This is disallowed as it
+ would make it possible to pass a limited object to a
+ nonlimited class-wide type, which could then be copied. This
+ is only possible using Ada 2005 syntax, so examples in
+ existing programs should be rare.
+
+ _Wording Changes from Ada 2005_
+
+38.n/3
+ {AI05-0110-1AI05-0110-1} Correction: Added wording to clarify
+ that the characteristics of derived types are formally defined
+ here. (This is the only place in the Standard that actually
+ spells out what sorts of things are actually characteristics,
+ which is rather important.)
+
+38.o/3
+ {AI05-0164-1AI05-0164-1} Correction: Added wording to ensure
+ that anonymous access-to-subprogram types don't get modified
+ on derivation.
+
+* Menu:
+
+* 3.4.1 :: Derivation Classes
+
+\1f
+File: aarm2012.info, Node: 3.4.1, Up: 3.4
+
+3.4.1 Derivation Classes
+------------------------
+
+1
+In addition to the various language-defined classes of types, types can
+be grouped into derivation classes.
+
+ _Static Semantics_
+
+2/2
+{AI95-00251-01AI95-00251-01} {AI95-00401-01AI95-00401-01} A derived type
+is derived from its parent type directly; it is derived indirectly from
+any type from which its parent type is derived. A derived type,
+interface type, type extension, task type, protected type, or formal
+derived type is also derived from every ancestor of each of its
+progenitor types, if any. The derivation class of types for a type T
+(also called the class rooted at T) is the set consisting of T (the root
+type of the class) and all types derived from T (directly or indirectly)
+plus any associated universal or class-wide types (defined below).
+
+2.a
+ Discussion: Note that the definition of "derived from" is a
+ recursive definition. We don't define a root type for all
+ interesting language-defined classes, though presumably we
+ could.
+
+2.b
+ To be honest: By the class-wide type "associated" with a type
+ T, we mean the type T'Class. Similarly, the universal type
+ associated with root_integer, root_real, and root_fixed are
+ universal_integer, universal_real, and universal_fixed,
+ respectively.
+
+3/2
+{AI95-00230-01AI95-00230-01} Every type is either a specific type, a
+class-wide type, or a universal type. A specific type is one defined by
+a type_declaration, a formal_type_declaration, or a full type definition
+embedded in another construct. Class-wide and universal types are
+implicitly defined, to act as representatives for an entire class of
+types, as follows:
+
+3.a
+ To be honest: The root types root_integer, root_real, and
+ root_fixed are also specific types. They are declared in the
+ specification of package Standard.
+
+4
+Class-wide types
+ Class-wide types are defined for [(and belong to)] each
+ derivation class rooted at a tagged type (see *note
+ 3.9::). Given a subtype S of a tagged type T, S'Class is
+ the subtype_mark for a corresponding subtype of the
+ tagged class-wide type T'Class. Such types are called
+ "class-wide" because when a formal parameter is defined
+ to be of a class-wide type T'Class, an actual parameter
+ of any type in the derivation class rooted at T is
+ acceptable (see *note 8.6::).
+
+5
+ The set of values for a class-wide type T'Class is the
+ discriminated union of the set of values of each specific
+ type in the derivation class rooted at T (the tag acts as
+ the implicit discriminant -- see *note 3.9::).
+ Class-wide types have no primitive subprograms of their
+ own. However, as explained in *note 3.9.2::, operands of
+ a class-wide type T'Class can be used as part of a
+ dispatching call on a primitive subprogram of the type T.
+ The only components [(including discriminants)] of
+ T'Class that are visible are those of T. If S is a first
+ subtype, then S'Class is a first subtype.
+
+5.a
+ Reason: We want S'Class to be a first subtype when S is, so
+ that an attribute_definition_clause (*note 13.3: S0309.) like
+ "for S'Class'Output use ...;" will be legal.
+
+6/2
+{AI95-00230-01AI95-00230-01} Universal types
+ Universal types are defined for [(and belong to)] the
+ integer, real, fixed point, and access classes, and are
+ referred to in this standard as respectively,
+ universal_integer, universal_real, universal_fixed, and
+ universal_access. These are analogous to class-wide
+ types for these language-defined elementary classes. As
+ with class-wide types, if a formal parameter is of a
+ universal type, then an actual parameter of any type in
+ the corresponding class is acceptable. In addition, a
+ value of a universal type (including an integer or real
+ numeric_literal, or the literal null) is "universal" in
+ that it is acceptable where some particular type in the
+ class is expected (see *note 8.6::).
+
+7
+ The set of values of a universal type is the
+ undiscriminated union of the set of values possible for
+ any definable type in the associated class. Like
+ class-wide types, universal types have no primitive
+ subprograms of their own. However, their "universality"
+ allows them to be used as operands with the primitive
+ subprograms of any type in the corresponding class.
+
+7.a
+ Discussion: A class-wide type is only class-wide in one
+ direction, from specific to class-wide, whereas a universal
+ type is class-wide (universal) in both directions, from
+ specific to universal and back.
+
+7.b/2
+ {AI95-00230-01AI95-00230-01} We considered defining class-wide
+ or perhaps universal types for all derivation classes, not
+ just tagged classes and these four elementary classes.
+ However, this was felt to overly weaken the strong-typing
+ model in some situations. Tagged types preserve strong type
+ distinctions thanks to the run-time tag. Class-wide or
+ universal types for untagged types would weaken the
+ compile-time type distinctions without providing a
+ compensating run-time-checkable distinction.
+
+7.c
+ We considered defining standard names for the universal
+ numeric types so they could be used in formal parameter
+ specifications. However, this was felt to impose an undue
+ implementation burden for some implementations.
+
+7.d
+ To be honest: Formally, the set of values of a universal type
+ is actually a copy of the undiscriminated union of the values
+ of the types in its class. This is because we want each value
+ to have exactly one type, with explicit or implicit conversion
+ needed to go between types. An alternative, consistent model
+ would be to associate a class, rather than a particular type,
+ with a value, even though any given expression would have a
+ particular type. In that case, implicit type conversions
+ would not generally need to change the value, although an
+ associated subtype conversion might need to.
+
+8
+The integer and real numeric classes each have a specific root type in
+addition to their universal type, named respectively root_integer and
+root_real.
+
+9
+A class-wide or universal type is said to cover all of the types in its
+class. A specific type covers only itself.
+
+10/2
+{AI95-00230-01AI95-00230-01} {AI95-00251-01AI95-00251-01} A specific
+type T2 is defined to be a descendant of a type T1 if T2 is the same as
+T1, or if T2 is derived (directly or indirectly) from T1. A class-wide
+type T2'Class is defined to be a descendant of type T1 if T2 is a
+descendant of T1. Similarly, the numeric universal types are defined to
+be descendants of the root types of their classes. If a type T2 is a
+descendant of a type T1, then T1 is called an ancestor of T2. An
+ultimate ancestor of a type is an ancestor of that type that is not
+itself a descendant of any other type. Every untagged type has a unique
+ultimate ancestor.
+
+10.a
+ Ramification: A specific type is a descendant of itself.
+ Class-wide types are considered descendants of the
+ corresponding specific type, and do not have any descendants
+ of their own.
+
+10.b
+ A specific type is an ancestor of itself. The root of a
+ derivation class is an ancestor of all types in the class,
+ including any class-wide types in the class.
+
+10.c
+ Discussion: The terms root, parent, ancestor, and ultimate
+ ancestor are all related. For example:
+
+10.d/2
+ * {AI95-00251-01AI95-00251-01} Each type has at most one
+ parent, and one or more ancestor types; each untagged
+ type has exactly one ultimate ancestor. In Ada 83, the
+ term "parent type" was sometimes used more generally to
+ include any ancestor type (e.g. RM83-9.4(14)). In Ada
+ 95, we restrict parent to mean the immediate ancestor.
+
+10.e
+ * A class of types has at most one root type; a derivation
+ class has exactly one root type.
+
+10.f
+ * The root of a class is an ancestor of all of the types in
+ the class (including itself).
+
+10.g
+ * The type root_integer is the root of the integer class,
+ and is the ultimate ancestor of all integer types. A
+ similar statement applies to root_real.
+
+10.h/2
+ Glossary entry: An ancestor of a type is the type itself or,
+ in the case of a type derived from other types, its parent
+ type or one of its progenitor types or one of their ancestors.
+ Note that ancestor and descendant are inverse relationships.
+
+10.i/2
+ Glossary entry: A type is a descendant of itself, its parent
+ and progenitor types, and their ancestors. Note that
+ descendant and ancestor are inverse relationships.
+
+11
+An inherited component [(including an inherited discriminant)] of a
+derived type is inherited from a given ancestor of the type if the
+corresponding component was inherited by each derived type in the chain
+of derivations going back to the given ancestor.
+
+ NOTES
+
+12
+ 23 Because operands of a universal type are acceptable to the
+ predefined operators of any type in their class, ambiguity can
+ result. For universal_integer and universal_real, this potential
+ ambiguity is resolved by giving a preference (see *note 8.6::) to
+ the predefined operators of the corresponding root types
+ (root_integer and root_real, respectively). Hence, in an
+ apparently ambiguous expression like
+
+13
+ 1 + 4 < 7
+
+14
+ where each of the literals is of type universal_integer, the
+ predefined operators of root_integer will be preferred over those
+ of other specific integer types, thereby resolving the ambiguity.
+
+14.a
+ Ramification: Except for this preference, a root numeric type
+ is essentially like any other specific type in the associated
+ numeric class. In particular, the result of a predefined
+ operator of a root numeric type is not "universal" (implicitly
+ convertible) even if both operands were.
+
+ _Wording Changes from Ada 95_
+
+14.b/2
+ {AI95-00230-01AI95-00230-01} Updated the wording to define the
+ universal_access type. This was defined to make null for
+ anonymous access types sensible.
+
+14.c/2
+ {AI95-00251-01AI95-00251-01} {AI95-00401-01AI95-00401-01} The
+ definitions of ancestors and descendants were updated to allow
+ multiple ancestors (necessary to support interfaces).
+
+\1f
+File: aarm2012.info, Node: 3.5, Next: 3.6, Prev: 3.4, Up: 3
+
+3.5 Scalar Types
+================
+
+1
+Scalar types comprise enumeration types, integer types, and real types.
+Enumeration types and integer types are called discrete types; each
+value of a discrete type has a position number which is an integer
+value. Integer types and real types are called numeric types. [All
+scalar types are ordered, that is, all relational operators are
+predefined for their values.]
+
+ _Syntax_
+
+2
+ range_constraint ::= range range
+
+3
+ range ::= range_attribute_reference
+ | simple_expression .. simple_expression
+
+3.a
+ Discussion: These need to be simple_expressions rather than
+ more general expressions because ranges appear in membership
+ tests and other contexts where expression .. expression would
+ be ambiguous.
+
+4
+A range has a lower bound and an upper bound and specifies a subset of
+the values of some scalar type (the type of the range). A range with
+lower bound L and upper bound R is described by "L .. R". If R is less
+than L, then the range is a null range, and specifies an empty set of
+values. Otherwise, the range specifies the values of the type from the
+lower bound to the upper bound, inclusive. A value belongs to a range
+if it is of the type of the range, and is in the subset of values
+specified by the range. A value satisfies a range constraint if it
+belongs to the associated range. One range is included in another if
+all values that belong to the first range also belong to the second.
+
+ _Name Resolution Rules_
+
+5
+For a subtype_indication containing a range_constraint, either directly
+or as part of some other scalar_constraint, the type of the range shall
+resolve to that of the type determined by the subtype_mark of the
+subtype_indication. For a range of a given type, the simple_expressions
+of the range (likewise, the simple_expressions of the equivalent range
+for a range_attribute_reference) are expected to be of the type of the
+range.
+
+5.a
+ Discussion: In Ada 95, constraints only appear within
+ subtype_indications; things that look like constraints that
+ appear in type declarations are called something else like
+ real_range_specifications.
+
+5.b/3
+ {AI05-0299-1AI05-0299-1} We say "the expected type is ..." or
+ "the type is expected to be ..." depending on which reads
+ better. They are fundamentally equivalent, and both feed into
+ the type resolution rules of subclause *note 8.6::.
+
+5.c
+ In some cases, it doesn't work to use expected types. For
+ example, in the above rule, we say that the "type of the range
+ shall resolve to ..." rather than "the expected type for the
+ range is ...". We then use "expected type" for the bounds.
+ If we used "expected" at both points, there would be an
+ ambiguity, since one could apply the rules of *note 8.6::
+ either on determining the type of the range, or on determining
+ the types of the individual bounds. It is clearly important
+ to allow one bound to be of a universal type, and the other of
+ a specific type, so we need to use "expected type" for the
+ bounds. Hence, we used "shall resolve to" for the type of the
+ range as a whole. There are other situations where "expected
+ type" is not quite right, and we use "shall resolve to"
+ instead.
+
+ _Static Semantics_
+
+6
+The base range of a scalar type is the range of finite values of the
+type that can be represented in every unconstrained object of the type;
+it is also the range supported at a minimum for intermediate values
+during the evaluation of expressions involving predefined operators of
+the type.
+
+6.a
+ Implementation Note: Note that in some machine architectures
+ intermediates in an expression (particularly if static), and
+ register-resident variables might accommodate a wider range.
+ The base range does not include the values of this wider range
+ that are not assignable without overflow to memory-resident
+ objects.
+
+6.b
+ Ramification: The base range of an enumeration type is the
+ range of values of the enumeration type.
+
+6.c
+ Reason: If the representation supports infinities, the base
+ range is nevertheless restricted to include only the
+ representable finite values, so that 'Base'First and
+ 'Base'Last are always guaranteed to be finite.
+
+6.d
+ To be honest: By a "value that can be assigned without
+ overflow" we don't mean to restrict ourselves to values that
+ can be represented exactly. Values between machine
+ representable values can be assigned, but on subsequent
+ reading, a slightly different value might be retrieved, as
+ (partially) determined by the number of digits of precision of
+ the type.
+
+7
+[A constrained scalar subtype is one to which a range constraint
+applies.] The range of a constrained scalar subtype is the range
+associated with the range constraint of the subtype. The range of an
+unconstrained scalar subtype is the base range of its type.
+
+ _Dynamic Semantics_
+
+8
+A range is compatible with a scalar subtype if and only if it is either
+a null range or each bound of the range belongs to the range of the
+subtype. A range_constraint is compatible with a scalar subtype if and
+only if its range is compatible with the subtype.
+
+8.a
+ Ramification: Only range_constraints (explicit or implicit)
+ impose conditions on the values of a scalar subtype. The
+ other scalar_constraints, digits_constraints and
+ delta_constraints impose conditions on the subtype denoted by
+ the subtype_mark in a subtype_indication, but don't impose a
+ condition on the values of the subtype being defined.
+ Therefore, a scalar subtype is not called constrained if all
+ that applies to it is a digits_constraint. Decimal subtypes
+ are subtle, because a digits_constraint without a
+ range_constraint nevertheless includes an implicit
+ range_constraint.
+
+9
+The elaboration of a range_constraint consists of the evaluation of the
+range. The evaluation of a range determines a lower bound and an upper
+bound. If simple_expressions are given to specify bounds, the
+evaluation of the range evaluates these simple_expressions in an
+arbitrary order, and converts them to the type of the range. If a
+range_attribute_reference is given, the evaluation of the range consists
+of the evaluation of the range_attribute_reference.
+
+10
+Attributes
+
+11
+For every scalar subtype S, the following attributes are defined:
+
+12
+S'First
+ S'First denotes the lower bound of the range of S. The
+ value of this attribute is of the type of S.
+
+12.a
+ Ramification: Evaluating S'First never raises
+ Constraint_Error.
+
+13
+S'Last
+ S'Last denotes the upper bound of the range of S. The
+ value of this attribute is of the type of S.
+
+13.a
+ Ramification: Evaluating S'Last never raises Constraint_Error.
+
+14
+S'Range
+ S'Range is equivalent to the range S'First .. S'Last.
+
+15
+S'Base
+ S'Base denotes an unconstrained subtype of the type of S.
+ This unconstrained subtype is called the base subtype of
+ the type.
+
+16
+S'Min
+ S'Min denotes a function with the following
+ specification:
+
+17
+ function S'Min(Left, Right : S'Base)
+ return S'Base
+
+18
+ The function returns the lesser of the values of the two
+ parameters.
+
+18.a
+ Discussion: The formal parameter names are italicized because
+ they cannot be used in calls -- see *note 6.4::. Such a
+ specification cannot be written by the user because an
+ attribute_reference is not permitted as the designator of a
+ user-defined function, nor can its formal parameters be
+ anonymous.
+
+19
+S'Max
+ S'Max denotes a function with the following
+ specification:
+
+20
+ function S'Max(Left, Right : S'Base)
+ return S'Base
+
+21
+ The function returns the greater of the values of the two
+ parameters.
+
+22
+S'Succ
+ S'Succ denotes a function with the following
+ specification:
+
+23
+ function S'Succ(Arg : S'Base)
+ return S'Base
+
+24
+ For an enumeration type, the function returns the value
+ whose position number is one more than that of the value
+ of Arg; Constraint_Error is raised if there is no such
+ value of the type. For an integer type, the function
+ returns the result of adding one to the value of Arg.
+ For a fixed point type, the function returns the result
+ of adding small to the value of Arg. For a floating
+ point type, the function returns the machine number (as
+ defined in *note 3.5.7::) immediately above the value of
+ Arg; Constraint_Error is raised if there is no such
+ machine number.
+
+24.a
+ Ramification: S'Succ for a modular integer subtype wraps
+ around if the value of Arg is S'Base'Last. S'Succ for a
+ signed integer subtype might raise Constraint_Error if the
+ value of Arg is S'Base'Last, or it might return the
+ out-of-base-range value S'Base'Last+1, as is permitted for all
+ predefined numeric operations.
+
+25
+S'Pred
+ S'Pred denotes a function with the following
+ specification:
+
+26
+ function S'Pred(Arg : S'Base)
+ return S'Base
+
+27
+ For an enumeration type, the function returns the value
+ whose position number is one less than that of the value
+ of Arg; Constraint_Error is raised if there is no such
+ value of the type. For an integer type, the function
+ returns the result of subtracting one from the value of
+ Arg. For a fixed point type, the function returns the
+ result of subtracting small from the value of Arg. For a
+ floating point type, the function returns the machine
+ number (as defined in *note 3.5.7::) immediately below
+ the value of Arg; Constraint_Error is raised if there is
+ no such machine number.
+
+27.a
+ Ramification: S'Pred for a modular integer subtype wraps
+ around if the value of Arg is S'Base'First. S'Pred for a
+ signed integer subtype might raise Constraint_Error if the
+ value of Arg is S'Base'First, or it might return the
+ out-of-base-range value S'Base'First-1, as is permitted for
+ all predefined numeric operations.
+
+27.1/2
+S'Wide_Wide_Image
+ {AI95-00285-01AI95-00285-01} S'Wide_Wide_Image denotes a
+ function with the following specification:
+
+27.2/2
+ function S'Wide_Wide_Image(Arg : S'Base)
+ return Wide_Wide_String
+
+27.3/2
+ The function returns an image of the value of Arg, that
+ is, a sequence of characters representing the value in
+ display form. The lower bound of the result is one.
+
+27.4/2
+ The image of an integer value is the corresponding
+ decimal literal, without underlines, leading zeros,
+ exponent, or trailing spaces, but with a single leading
+ character that is either a minus sign or a space.
+
+27.b/2
+ Implementation Note: If the machine supports negative zeros
+ for signed integer types, it is not specified whether " 0" or
+ "-0" should be returned for negative zero. We don't have
+ enough experience with such machines to know what is
+ appropriate, and what other languages do. In any case, the
+ implementation should be consistent.
+
+27.5/2
+ The image of an enumeration value is either the
+ corresponding identifier in upper case or the
+ corresponding character literal (including the two
+ apostrophes); neither leading nor trailing spaces are
+ included. For a nongraphic character (a value of a
+ character type that has no enumeration literal associated
+ with it), the result is a corresponding language-defined
+ name in upper case (for example, the image of the
+ nongraphic character identified as nul is "NUL" -- the
+ quotes are not part of the image).
+
+27.c/2
+ Implementation Note: For an enumeration type T that has
+ "holes" (caused by an enumeration_representation_clause (*note
+ 13.4: S0310.)), T'Wide_Image should raise Program_Error if the
+ value is one of the holes (which is a bounded error anyway,
+ since holes can be generated only via uninitialized variables
+ and similar things).
+
+27.6/2
+ The image of a floating point value is a decimal real
+ literal best approximating the value (rounded away from
+ zero if halfway between) with a single leading character
+ that is either a minus sign or a space, a single digit
+ (that is nonzero unless the value is zero), a decimal
+ point, S'Digits-1 (see *note 3.5.8::) digits after the
+ decimal point (but one if S'Digits is one), an upper case
+ E, the sign of the exponent (either + or -), and two or
+ more digits (with leading zeros if necessary)
+ representing the exponent. If S'Signed_Zeros is True,
+ then the leading character is a minus sign for a
+ negatively signed zero.
+
+27.d/2
+ To be honest: Leading zeros are present in the exponent only
+ if necessary to make the exponent at least two digits.
+
+27.e/2
+ Reason: This image is intended to conform to that produced by
+ Text_IO.Float_IO.Put in its default format.
+
+27.f/2
+ Implementation Note: The rounding direction is specified here
+ to ensure portability of output results.
+
+27.7/2
+ The image of a fixed point value is a decimal real
+ literal best approximating the value (rounded away from
+ zero if halfway between) with a single leading character
+ that is either a minus sign or a space, one or more
+ digits before the decimal point (with no redundant
+ leading zeros), a decimal point, and S'Aft (see *note
+ 3.5.10::) digits after the decimal point.
+
+27.g/2
+ Reason: This image is intended to conform to that produced by
+ Text_IO.Fixed_IO.Put.
+
+27.h/2
+ Implementation Note: The rounding direction is specified here
+ to ensure portability of output results.
+
+27.i/2
+ Implementation Note: For a machine that supports negative
+ zeros, it is not specified whether " 0.000" or "-0.000" is
+ returned. See corresponding comment above about integer types
+ with signed zeros.
+
+28
+S'Wide_Image
+ S'Wide_Image denotes a function with the following
+ specification:
+
+29
+ function S'Wide_Image(Arg : S'Base)
+ return Wide_String
+
+30/3
+ {AI95-00285-01AI95-00285-01} {AI05-0262-1AI05-0262-1}
+ {AI05-0264-1AI05-0264-1} The function returns an image of
+ the value of Arg as a Wide_String. The lower bound of
+ the result is one. The image has the same sequence of
+ graphic characters as defined for S'Wide_Wide_Image if
+ all the graphic characters are defined in Wide_Character;
+ otherwise, the sequence of characters is implementation
+ defined (but no shorter than that of S'Wide_Wide_Image
+ for the same value of Arg).
+
+30.a/2
+ Implementation defined: The sequence of characters of the
+ value returned by S'Wide_Image when some of the graphic
+ characters of S'Wide_Wide_Image are not defined in
+ Wide_Character.
+
+ Paragraphs 31 through 34 were moved to Wide_Wide_Image.
+
+35
+S'Image
+ S'Image denotes a function with the following
+ specification:
+
+36
+ function S'Image(Arg : S'Base)
+ return String
+
+37/3
+ {AI95-00285-01AI95-00285-01} {AI05-0264-1AI05-0264-1} The
+ function returns an image of the value of Arg as a
+ String. The lower bound of the result is one. The image
+ has the same sequence of graphic characters as that
+ defined for S'Wide_Wide_Image if all the graphic
+ characters are defined in Character; otherwise, the
+ sequence of characters is implementation defined (but no
+ shorter than that of S'Wide_Wide_Image for the same value
+ of Arg).
+
+37.a/2
+ Implementation defined: The sequence of characters of the
+ value returned by S'Image when some of the graphic characters
+ of S'Wide_Wide_Image are not defined in Character.
+
+37.1/2
+S'Wide_Wide_Width
+ {AI95-00285-01AI95-00285-01} S'Wide_Wide_Width denotes
+ the maximum length of a Wide_Wide_String returned by
+ S'Wide_Wide_Image over all values of the subtype S. It
+ denotes zero for a subtype that has a null range. Its
+ type is universal_integer.
+
+38
+S'Wide_Width
+ S'Wide_Width denotes the maximum length of a Wide_String
+ returned by S'Wide_Image over all values of the subtype
+ S. It denotes zero for a subtype that has a null range.
+ Its type is universal_integer.
+
+39
+S'Width
+ S'Width denotes the maximum length of a String returned
+ by S'Image over all values of the subtype S. It denotes
+ zero for a subtype that has a null range. Its type is
+ universal_integer.
+
+39.1/2
+S'Wide_Wide_Value
+ {AI95-00285-01AI95-00285-01} S'Wide_Wide_Value denotes a
+ function with the following specification:
+
+39.2/2
+ function S'Wide_Wide_Value(Arg : Wide_Wide_String)
+ return S'Base
+
+39.3/2
+ This function returns a value given an image of the value
+ as a Wide_Wide_String, ignoring any leading or trailing
+ spaces.
+
+39.4/3
+ {AI05-0264-1AI05-0264-1} For the evaluation of a call on
+ S'Wide_Wide_Value for an enumeration subtype S, if the
+ sequence of characters of the parameter (ignoring leading
+ and trailing spaces) has the syntax of an enumeration
+ literal and if it corresponds to a literal of the type of
+ S (or corresponds to the result of S'Wide_Wide_Image for
+ a nongraphic character of the type), the result is the
+ corresponding enumeration value; otherwise,
+ Constraint_Error is raised.
+
+39.a.1/2
+ Discussion: It's not crystal clear that Range_Check is
+ appropriate here, but it doesn't seem worthwhile to invent a
+ whole new check name just for this weird case, so we decided
+ to lump it in with Range_Check.
+
+39.a.2/2
+ To be honest: {8652/00968652/0096}
+ {AI95-00053-01AI95-00053-01} A sequence of characters
+ corresponds to the result of S'Wide_Wide_Image if it is the
+ same ignoring case. Thus, the case of an image of a
+ nongraphic character does not matter. For example,
+ Character'Wide_Wide_Value("nul") does not raise
+ Constraint_Error, even though Character'Wide_Wide_Image
+ returns "NUL" for the nul character.
+
+39.5/3
+ {AI05-0264-1AI05-0264-1} For the evaluation of a call on
+ S'Wide_Wide_Value for an integer subtype S, if the
+ sequence of characters of the parameter (ignoring leading
+ and trailing spaces) has the syntax of an integer
+ literal, with an optional leading sign character (plus or
+ minus for a signed type; only plus for a modular type),
+ and the corresponding numeric value belongs to the base
+ range of the type of S, then that value is the result;
+ otherwise, Constraint_Error is raised.
+
+39.a.3/2
+ Discussion: We considered allowing 'Value to return a
+ representable but out-of-range value without a
+ Constraint_Error. However, we currently require (see *note
+ 4.9::) in an assignment_statement like "X :=
+ <numeric_literal>;" that the value of the numeric-literal be
+ in X's base range (at compile time), so it seems unfriendly
+ and confusing to have a different range allowed for 'Value.
+ Furthermore, for modular types, without the requirement for
+ being in the base range, 'Value would have to handle
+ arbitrarily long literals (since overflow never occurs for
+ modular types).
+
+39.6/2
+ For the evaluation of a call on S'Wide_Wide_Value for a
+ real subtype S, if the sequence of characters of the
+ parameter (ignoring leading and trailing spaces) has the
+ syntax of one of the following:
+
+39.7/2
+ * numeric_literal
+
+39.8/2
+ * numeral.[exponent]
+
+39.9/2
+ * .numeral[exponent]
+
+39.10/2
+ * base#based_numeral.#[exponent]
+
+39.11/2
+ * base#.based_numeral#[exponent]
+
+39.12/3
+ {AI05-0264-1AI05-0264-1} with an optional leading sign
+ character (plus or minus), and if the corresponding
+ numeric value belongs to the base range of the type of S,
+ then that value is the result; otherwise,
+ Constraint_Error is raised. The sign of a zero value is
+ preserved (positive if none has been specified) if
+ S'Signed_Zeros is True.
+
+40
+S'Wide_Value
+ S'Wide_Value denotes a function with the following
+ specification:
+
+41
+ function S'Wide_Value(Arg : Wide_String)
+ return S'Base
+
+42
+ This function returns a value given an image of the value
+ as a Wide_String, ignoring any leading or trailing
+ spaces.
+
+43/3
+ {AI95-00285-01AI95-00285-01} {AI05-0264-1AI05-0264-1} For
+ the evaluation of a call on S'Wide_Value for an
+ enumeration subtype S, if the sequence of characters of
+ the parameter (ignoring leading and trailing spaces) has
+ the syntax of an enumeration literal and if it
+ corresponds to a literal of the type of S (or corresponds
+ to the result of S'Wide_Image for a value of the type),
+ the result is the corresponding enumeration value;
+ otherwise, Constraint_Error is raised. For a numeric
+ subtype S, the evaluation of a call on S'Wide_Value with
+ Arg of type Wide_String is equivalent to a call on
+ S'Wide_Wide_Value for a corresponding Arg of type
+ Wide_Wide_String.
+
+43.a/2
+ This paragraph was deleted.
+
+43.a.1/2
+ This paragraph was deleted.{8652/00968652/0096}
+ {AI95-00053-01AI95-00053-01}
+
+43.b/2
+ Reason: S'Wide_Value is subtly different from
+ S'Wide_Wide_Value for enumeration subtypes since S'Wide_Image
+ might produce a different sequence of characters than
+ S'Wide_Wide_Image if the enumeration literal uses characters
+ outside of the predefined type Wide_Character. That is why we
+ don't just define S'Wide_Value in terms of S'Wide_Wide_Value
+ for enumeration subtypes. S'Wide_Value and S'Wide_Wide_Value
+ for numeric subtypes yield the same result given the same
+ sequence of characters.
+
+ Paragraphs 44 through 51 were moved to Wide_Wide_Value.
+
+52
+S'Value
+ S'Value denotes a function with the following
+ specification:
+
+53
+ function S'Value(Arg : String)
+ return S'Base
+
+54
+ This function returns a value given an image of the value
+ as a String, ignoring any leading or trailing spaces.
+
+55/3
+ {AI95-00285-01AI95-00285-01} {AI05-0264-1AI05-0264-1} For
+ the evaluation of a call on S'Value for an enumeration
+ subtype S, if the sequence of characters of the parameter
+ (ignoring leading and trailing spaces) has the syntax of
+ an enumeration literal and if it corresponds to a literal
+ of the type of S (or corresponds to the result of S'Image
+ for a value of the type), the result is the corresponding
+ enumeration value; otherwise, Constraint_Error is raised.
+ For a numeric subtype S, the evaluation of a call on
+ S'Value with Arg of type String is equivalent to a call
+ on S'Wide_Wide_Value for a corresponding Arg of type
+ Wide_Wide_String.
+
+55.a/2
+ Reason: {AI95-00285-01AI95-00285-01} S'Value is subtly
+ different from S'Wide_Wide_Value for enumeration subtypes; see
+ the discussion under S'Wide_Value.
+
+ _Implementation Permissions_
+
+56/2
+{AI95-00285-01AI95-00285-01} An implementation may extend the
+Wide_Wide_Value, [Wide_Value, Value, Wide_Wide_Image, Wide_Image, and
+Image] attributes of a floating point type to support special values
+such as infinities and NaNs.
+
+56.a/2
+ Proof: {AI95-00285-01AI95-00285-01} The permission is really
+ only necessary for Wide_Wide_Value, because Value and
+ Wide_Value are defined in terms of Wide_Wide_Value, and
+ because the behavior of Wide_Wide_Image, Wide_Image, and Image
+ is already unspecified for things like infinities and NaNs.
+
+56.b
+ Reason: This is to allow implementations to define full
+ support for IEEE arithmetic. See also the similar permission
+ for Get in *note A.10.9::.
+
+56.1/3
+{AI05-0182-1AI05-0182-1} {AI05-0262-1AI05-0262-1}
+{AI05-0269-1AI05-0269-1} An implementation may extend the
+Wide_Wide_Value, Wide_Value, and Value attributes of a character type to
+accept strings of the form "Hex_hhhhhhhh" (ignoring case) for any
+character (not just the ones for which Wide_Wide_Image would produce
+that form -- see *note 3.5.2::), as well as three-character strings of
+the form "'X'", where X is any character, including nongraphic
+characters.
+
+ _Static Semantics_
+
+56.2/3
+{AI05-0228-1AI05-0228-1} For a scalar type, the following
+language-defined representation aspect may be specified with an
+aspect_specification (see *note 13.1.1::):
+
+56.3/3
+Default_Value
+ This aspect shall be specified by a static expression,
+ and that expression shall be explicit, even if the aspect
+ has a boolean type. Default_Value shall be specified
+ only on a full_type_declaration.
+
+56.c/3
+ Reason: The part about requiring an explicit expression is to
+ disallow omitting the value for this aspect, which would
+ otherwise be allowed by the rules of *note 13.1.1::.
+
+56.d/3
+ This is a representation aspect in order to disallow
+ specifying it on a derived type that has inherited primitive
+ subprograms; that is necessary as the sizes of out parameters
+ could be different whether or not a Default_Value is specified
+ (see *note 6.4.1::).
+
+56.e/3
+ Aspect Description for Default_Value: Default value for a
+ scalar subtype.
+
+56.4/3
+{AI05-0228-1AI05-0228-1} If a derived type with no primitive subprograms
+inherits a boolean Default_Value aspect, the aspect may be specified to
+have any value for the derived type.
+
+56.f/3
+ Reason: This overrides the *note 13.1.1:: rule that says that
+ a boolean aspect with a value True cannot be changed.
+
+ _Name Resolution Rules_
+
+56.5/3
+{AI05-0228-1AI05-0228-1} The expected type for the expression specified
+for the Default_Value aspect is the type defined by the
+full_type_declaration on which it appears.
+
+ NOTES
+
+57
+ 24 The evaluation of S'First or S'Last never raises an exception.
+ If a scalar subtype S has a nonnull range, S'First and S'Last
+ belong to this range. These values can, for example, always be
+ assigned to a variable of subtype S.
+
+57.a
+ Discussion: This paragraph addresses an issue that came up
+ with Ada 83, where for fixed point types, the end points of
+ the range specified in the type definition were not
+ necessarily within the base range of the type. However, it
+ was later clarified (and we reconfirm it in *note 3.5.9::,
+ "*note 3.5.9:: Fixed Point Types") that the First and Last
+ attributes reflect the true bounds chosen for the type, not
+ the bounds specified in the type definition (which might be
+ outside the ultimately chosen base range).
+
+58
+ 25 For a subtype of a scalar type, the result delivered by the
+ attributes Succ, Pred, and Value might not belong to the subtype;
+ similarly, the actual parameters of the attributes Succ, Pred, and
+ Image need not belong to the subtype.
+
+59
+ 26 For any value V (including any nongraphic character) of an
+ enumeration subtype S, S'Value(S'Image(V)) equals V, as do
+ S'Wide_Value(S'Wide_Image(V)) and
+ S'Wide_Wide_Value(S'Wide_Wide_Image(V)). None of these expressions
+ ever raise Constraint_Error.
+
+ _Examples_
+
+60
+Examples of ranges:
+
+61
+ -10 .. 10
+ X .. X + 1
+ 0.0 .. 2.0*Pi
+ Red .. Green -- see *note 3.5.1::
+ 1 .. 0 -- a null range
+ Table'Range -- a range attribute reference (see *note 3.6::)
+
+62
+Examples of range constraints:
+
+63
+ range -999.0 .. +999.0
+ range S'First+1 .. S'Last-1
+
+ _Incompatibilities With Ada 83_
+
+63.a/1
+ S'Base is no longer defined for nonscalar types. One
+ conceivable existing use of S'Base for nonscalar types is
+ S'Base'Size where S is a generic formal private type.
+ However, that is not generally useful because the actual
+ subtype corresponding to S might be a constrained array or
+ discriminated type, which would mean that S'Base'Size might
+ very well overflow (for example, S'Base'Size where S is a
+ constrained subtype of String will generally be 8 *
+ (Integer'Last + 1)). For derived discriminated types that are
+ packed, S'Base'Size might not even be well defined if the
+ first subtype is constrained, thereby allowing some amount of
+ normally required "dope" to have been squeezed out in the
+ packing. Hence our conclusion is that S'Base'Size is not
+ generally useful in a generic, and does not justify keeping
+ the attribute Base for nonscalar types just so it can be used
+ as a prefix.
+
+ _Extensions to Ada 83_
+
+63.b
+ The attribute S'Base for a scalar subtype is now permitted
+ anywhere a subtype_mark is permitted. S'Base'First ..
+ S'Base'Last is the base range of the type. Using an
+ attribute_definition_clause (*note 13.3: S0309.), one cannot
+ specify any subtype-specific attributes for the subtype
+ denoted by S'Base (the base subtype).
+
+63.c
+ The attribute S'Range is now allowed for scalar subtypes.
+
+63.d
+ The attributes S'Min and S'Max are now defined, and made
+ available for all scalar types.
+
+63.e
+ The attributes S'Succ, S'Pred, S'Image, S'Value, and S'Width
+ are now defined for real types as well as discrete types.
+
+63.f
+ Wide_String versions of S'Image and S'Value are defined.
+ These are called S'Wide_Image and S'Wide_Value to avoid
+ introducing ambiguities involving uses of these attributes
+ with string literals.
+
+ _Wording Changes from Ada 83_
+
+63.g
+ We now use the syntactic category range_attribute_reference
+ since it is now syntactically distinguished from other
+ attribute references.
+
+63.h
+ The definition of S'Base has been moved here from 3.3.3 since
+ it now applies only to scalar types.
+
+63.i
+ More explicit rules are provided for nongraphic characters.
+
+ _Extensions to Ada 95_
+
+63.j/2
+ {AI95-00285-01AI95-00285-01} The attributes Wide_Wide_Image,
+ Wide_Wide_Value, and Wide_Wide_Width are new. Note that
+ Wide_Image and Wide_Value are now defined in terms of
+ Wide_Wide_Image and Wide_Wide_Value, but the image of types
+ other than characters have not changed.
+
+ _Wording Changes from Ada 95_
+
+63.k/2
+ {AI95-00285-01AI95-00285-01} The Wide_Image and Wide_Value
+ attributes are now defined in terms of Wide_Wide_Image and
+ Wide_Wide_Value, but the images of numeric types have not
+ changed.
+
+ _Inconsistencies With Ada 2005_
+
+63.l/3
+ {AI05-0181-1AI05-0181-1} Correction: Soft hyphen (code point
+ 173) is nongraphic in ISO/IEC 10646:2011 (and also in the 2003
+ version of that standard). Thus, we have given it the
+ language-defined name soft_hyphen. This changes the result of
+ Character'Image (and all of the related types and Image
+ attributes) for this character, and changes the behavior of
+ Character'Value (and all of the related types and Value
+ attributes) for this character, and (in unusual
+ circumstances), changes the result for Character'Width (and
+ all of the related types and Width attributes). The vast
+ majority of programs won't see any difference, as they are
+ already prepared to handle nongraphic characters.
+
+63.m/3
+ {AI05-0182-1AI05-0182-1} Correction: Added an Implementation
+ Permissions to let Wide_Wide_Value, Wide_Value, and Value
+ accept strings in the form of literals containing nongraphic
+ characters and "Hex_hhhhhhhh" for Latin-1 and graphic
+ characters. These were required to raise Constraint_Error in
+ Ada 2005. Since these attributes aren't very useful,
+ implementations were inconsistent as to whether these were
+ accepted, and since code that would care why the attribute
+ failed seems unlikely, this should not be a problem in
+ practice.
+
+ _Extensions to Ada 2005_
+
+63.n/3
+ {AI05-0228-1AI05-0228-1} The new aspect Default_Value allows
+ defining implicit initial values (see *note 3.3.1::) for
+ scalar types.
+
+* Menu:
+
+* 3.5.1 :: Enumeration Types
+* 3.5.2 :: Character Types
+* 3.5.3 :: Boolean Types
+* 3.5.4 :: Integer Types
+* 3.5.5 :: Operations of Discrete Types
+* 3.5.6 :: Real Types
+* 3.5.7 :: Floating Point Types
+* 3.5.8 :: Operations of Floating Point Types
+* 3.5.9 :: Fixed Point Types
+* 3.5.10 :: Operations of Fixed Point Types
+
+\1f
+File: aarm2012.info, Node: 3.5.1, Next: 3.5.2, Up: 3.5
+
+3.5.1 Enumeration Types
+-----------------------
+
+1
+[ An enumeration_type_definition defines an enumeration type.]
+
+ _Syntax_
+
+2
+ enumeration_type_definition ::=
+ (enumeration_literal_specification {,
+ enumeration_literal_specification})
+
+3
+ enumeration_literal_specification ::= defining_identifier |
+ defining_character_literal
+
+4
+ defining_character_literal ::= character_literal
+
+ _Legality Rules_
+
+5/3
+{AI05-0227-1AI05-0227-1} {AI05-0299-1AI05-0299-1} The
+defining_identifiers in upper case [and the defining_character_literals]
+listed in an enumeration_type_definition shall be distinct.
+
+5.a/3
+ Proof: {AI05-0227-1AI05-0227-1} For character literals, this
+ is a ramification of the normal disallowance of homographs
+ explicitly declared immediately in the same declarative
+ region.
+
+5.b/3
+ Reason: {AI05-0227-1AI05-0227-1} To ease implementation of the
+ attribute Wide_Wide_Value, we require that all enumeration
+ literals have distinct images.
+
+ _Static Semantics_
+
+6/3
+{AI05-0006-1AI05-0006-1} Each enumeration_literal_specification is the
+explicit declaration of the corresponding enumeration literal: it
+declares a parameterless function, whose defining name is the
+defining_identifier (*note 3.1: S0022.) or defining_character_literal
+(*note 3.5.1: S0040.), and whose result subtype is the base subtype of
+the enumeration type.
+
+6.a
+ Reason: This rule defines the profile of the enumeration
+ literal, which is used in the various types of conformance.
+
+6.b
+ Ramification: The parameterless function associated with an
+ enumeration literal is fully defined by the
+ enumeration_type_definition; a body is not permitted for it,
+ and it never fails the Elaboration_Check when called.
+
+6.c/3
+ Discussion: {AI05-0006-1AI05-0006-1} The result subtype is
+ primarily a concern when an enumeration literal is used as the
+ expression of a case statement, due to the full coverage
+ requirement based on the nominal subtype.
+
+7
+Each enumeration literal corresponds to a distinct value of the
+enumeration type, and to a distinct position number. The position
+number of the value of the first listed enumeration literal is zero; the
+position number of the value of each subsequent enumeration literal is
+one more than that of its predecessor in the list.
+
+8
+[The predefined order relations between values of the enumeration type
+follow the order of corresponding position numbers.]
+
+9
+[ If the same defining_identifier or defining_character_literal is
+specified in more than one enumeration_type_definition (*note 3.5.1:
+S0038.), the corresponding enumeration literals are said to be
+overloaded. At any place where an overloaded enumeration literal occurs
+in the text of a program, the type of the enumeration literal has to be
+determinable from the context (see *note 8.6::).]
+
+ _Dynamic Semantics_
+
+10
+The elaboration of an enumeration_type_definition creates the
+enumeration type and its first subtype, which is constrained to the base
+range of the type.
+
+10.a
+ Ramification: The first subtype of a discrete type is always
+ constrained, except in the case of a derived type whose parent
+ subtype is Whatever'Base.
+
+11
+When called, the parameterless function associated with an enumeration
+literal returns the corresponding value of the enumeration type.
+
+ NOTES
+
+12
+ 27 If an enumeration literal occurs in a context that does not
+ otherwise suffice to determine the type of the literal, then
+ qualification by the name of the enumeration type is one way to
+ resolve the ambiguity (see *note 4.7::).
+
+ _Examples_
+
+13
+Examples of enumeration types and subtypes:
+
+14
+ type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun);
+ type Suit is (Clubs, Diamonds, Hearts, Spades);
+ type Gender is (M, F);
+ type Level is (Low, Medium, Urgent);
+ type Color is (White, Red, Yellow, Green, Blue, Brown, Black);
+ type Light is (Red, Amber, Green); -- Red and Green are overloaded
+
+15
+ type Hexa is ('A', 'B', 'C', 'D', 'E', 'F');
+ type Mixed is ('A', 'B', '*', B, None, '?', '%');
+
+16
+ subtype Weekday is Day range Mon .. Fri;
+ subtype Major is Suit range Hearts .. Spades;
+ subtype Rainbow is Color range Red .. Blue; -- the Color Red, not the Light
+
+ _Wording Changes from Ada 83_
+
+16.a
+ The syntax rule for defining_character_literal is new. It is
+ used for the defining occurrence of a character_literal,
+ analogously to defining_identifier. Usage occurrences use the
+ name or selector_name syntactic categories.
+
+16.b
+ We emphasize the fact that an enumeration literal denotes a
+ function, which is called to produce a value.
+
+ _Incompatibilities With Ada 2005_
+
+16.c/3
+ {AI05-0227-1AI05-0227-1} Correction: Required that all
+ enumeration literals in a type have distinct images; this
+ might not be the case since upper case conversion can map
+ distinct characters to the same upper case character. This
+ can only happen for identifiers using Unicode characters first
+ allowed by Ada 2005; moreover, the original definition of Ada
+ 2005 was confused and appeared to require inconsistent results
+ from the Image attribute, so implementations that allowed
+ problematic cases are rare; the problematic cases are very
+ rare; so it is expected that this change would only affect
+ test programs.
+
+ _Wording Changes from Ada 2005_
+
+16.d/3
+ {AI05-0006-1AI05-0006-1} Correction: Defined the result
+ subtype of an enumeration literal to close a minor language
+ hole.
+
+\1f
+File: aarm2012.info, Node: 3.5.2, Next: 3.5.3, Prev: 3.5.1, Up: 3.5
+
+3.5.2 Character Types
+---------------------
+
+ _Static Semantics_
+
+1
+An enumeration type is said to be a character type if at least one of
+its enumeration literals is a character_literal.
+
+2/3
+{AI95-00285-01AI95-00285-01} {AI05-0181-1AI05-0181-1}
+{AI05-0262-1AI05-0262-1} {AI05-0266-1AI05-0266-1} The predefined type
+Character is a character type whose values correspond to the 256 code
+points of Row 00 (also known as Latin-1) of the ISO/IEC 10646:2011 Basic
+Multilingual Plane (BMP). Each of the graphic characters of Row 00 of
+the BMP has a corresponding character_literal in Character. Each of the
+nongraphic characters of Row 00 has a corresponding language-defined
+name, which is not usable as an enumeration literal, but which is usable
+with the attributes Image, Wide_Image, Wide_Wide_Image, Value,
+Wide_Value, and Wide_Wide_Value; these names are given in the definition
+of type Character in *note A.1::, "*note A.1:: The Package Standard",
+but are set in italics.
+
+2.a/3
+ Discussion: {AI05-0262-1AI05-0262-1} Code point is defined in
+ ISO/IEC 10646:2011.
+
+3/3
+{AI95-00285-01AI95-00285-01} {AI05-0262-1AI05-0262-1} The predefined
+type Wide_Character is a character type whose values correspond to the
+65536 code points of the ISO/IEC 10646:2011 Basic Multilingual Plane
+(BMP). Each of the graphic characters of the BMP has a corresponding
+character_literal in Wide_Character. The first 256 values of
+Wide_Character have the same character_literal or language-defined name
+as defined for Character. Each of the graphic_characters has a
+corresponding character_literal.
+
+4/3
+{AI95-00285-01AI95-00285-01} {AI05-0262-1AI05-0262-1} The predefined
+type Wide_Wide_Character is a character type whose values correspond to
+the 2147483648 code points of the ISO/IEC 10646:2011 character set.
+Each of the graphic_characters has a corresponding character_literal in
+Wide_Wide_Character. The first 65536 values of Wide_Wide_Character have
+the same character_literal or language-defined name as defined for
+Wide_Character.
+
+5/3
+{AI95-00285-01AI95-00285-01} {AI05-0262-1AI05-0262-1} The characters
+whose code point is larger than 16#FF# and which are not
+graphic_characters have language-defined names which are formed by
+appending to the string "Hex_" the representation of their code point in
+hexadecimal as eight extended digits. As with other language-defined
+names, these names are usable only with the attributes (Wide_)Wide_Image
+and (Wide_)Wide_Value; they are not usable as enumeration literals.
+
+5.a/2
+ Reason: {AI95-00285-01AI95-00285-01} The language-defined
+ names are not usable as enumeration literals to avoid
+ "polluting" the name space. Since Wide_Character and
+ Wide_Wide_Character are defined in Standard, if the
+ language-defined names were usable as enumeration literals,
+ they would hide other nonoverloadable declarations with the
+ same names in use-d packages.]}
+
+Paragraphs 6 and 7 were deleted.
+
+ NOTES
+
+8
+ 28 The language-defined library package Characters.Latin_1 (see
+ *note A.3.3::) includes the declaration of constants denoting
+ control characters, lower case characters, and special characters
+ of the predefined type Character.
+
+8.a
+ To be honest: The package ASCII does the same, but only for
+ the first 128 characters of Character. Hence, it is an
+ obsolescent package, and we no longer mention it here.
+
+9/3
+ 29 {AI05-0299-1AI05-0299-1} A conventional character set such as
+ EBCDIC can be declared as a character type; the internal codes of
+ the characters can be specified by an
+ enumeration_representation_clause as explained in subclause *note
+ 13.4::.
+
+ _Examples_
+
+10
+Example of a character type:
+
+11
+ type Roman_Digit is ('I', 'V', 'X', 'L', 'C', 'D', 'M');
+
+ _Inconsistencies With Ada 83_
+
+11.a
+ The declaration of Wide_Character in package Standard hides
+ use-visible declarations with the same defining identifier.
+ In the unlikely event that an Ada 83 program had depended on
+ such a use-visible declaration, and the program remains legal
+ after the substitution of Standard.Wide_Character, the meaning
+ of the program will be different.
+
+ _Incompatibilities With Ada 83_
+
+11.b
+ The presence of Wide_Character in package Standard means that
+ an expression such as
+
+11.c
+ 'a' = 'b'
+
+11.d
+ is ambiguous in Ada 95, whereas in Ada 83 both literals could
+ be resolved to be of type Character.
+
+11.e
+ The change in visibility rules (see *note 4.2::) for character
+ literals means that additional qualification might be
+ necessary to resolve expressions involving overloaded
+ subprograms and character literals.
+
+ _Extensions to Ada 83_
+
+11.f
+ The type Character has been extended to have 256 positions,
+ and the type Wide_Character has been added. Note that this
+ change was already approved by the ARG for Ada 83 conforming
+ compilers.
+
+11.g
+ The rules for referencing character literals are changed (see
+ *note 4.2::), so that the declaration of the character type
+ need not be directly visible to use its literals, similar to
+ null and string literals. Context is used to resolve their
+ type.
+
+ _Inconsistencies With Ada 95_
+
+11.h/2
+ {AI95-00285-01AI95-00285-01} Ada 95 defined most characters in
+ Wide_Character to be graphic characters, while Ada 2005 uses
+ the categorizations from ISO-10646:2003. It also provides
+ language-defined names for all nongraphic characters. That
+ means that in Ada 2005, Wide_Character'Wide_Value will raise
+ Constraint_Error for a string representing a character_literal
+ of a nongraphic character, while Ada 95 would have accepted
+ it. Similarly, the result of Wide_Character'Wide_Image will
+ change for such nongraphic characters.
+
+11.i/3
+ {AI95-00395-01AI95-00395-01} {AI05-0005-1AI05-0005-1}
+ {AI05-0262-1AI05-0262-1} The language-defined names FFFE and
+ FFFF were replaced by a consistent set of language-defined
+ names for all nongraphic characters with code points greater
+ than 16#FF#. That means that in Ada 2005,
+ Wide_Character'Wide_Value("FFFE") will raise Constraint_Error
+ while Ada 95 would have accepted it. Similarly, the result of
+ Wide_Character'Wide_Image will change for the position numbers
+ 16#FFFE# and 16#FFFF#. It is very unlikely that this will
+ matter in practice, as these names do not represent usable
+ characters.
+
+11.j/2
+ {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+ Because of the previously mentioned changes to the
+ Wide_Character'Wide_Image of various character values, the
+ value of attribute Wide_Width will change for some subtypes of
+ Wide_Character. However, the new language-defined names were
+ chosen so that the value of Wide_Character'Wide_Width itself
+ does not change.
+
+11.k/2
+ {AI95-00285-01AI95-00285-01} The declaration of
+ Wide_Wide_Character in package Standard hides use-visible
+ declarations with the same defining identifier. In the (very)
+ unlikely event that an Ada 95 program had depended on such a
+ use-visible declaration, and the program remains legal after
+ the substitution of Standard.Wide_Wide_Character, the meaning
+ of the program will be different.
+
+ _Extensions to Ada 95_
+
+11.l/2
+ {AI95-00285-01AI95-00285-01} The type Wide_Wide_Character is
+ new.
+
+ _Wording Changes from Ada 95_
+
+11.m/2
+ {AI95-00285-01AI95-00285-01} Characters are now defined in
+ terms of the entire ISO/IEC 10646:2003 character set.
+
+11.n/3
+ {AI95-00285-01AI95-00285-01} {AI05-0248-1AI05-0248-1} We
+ dropped the Implementation Advice for nonstandard
+ interpretation of character sets; an implementation can do
+ what it wants in a nonstandard mode, so there isn't much point
+ to any advice.
+
+ _Wording Changes from Ada 2005_
+
+11.o/3
+ {AI05-0181-1AI05-0181-1} Correction: Removed the position
+ numbers of nongraphic characters from the text, as it is wrong
+ and thus misleading.
+
+11.p/3
+ {AI05-0262-1AI05-0262-1} Changed "code position" to "code
+ point" consistently throughout the standard, as ISO/IEC
+ 10646:2011 prefers "code point" and we are referring to the
+ definition in that Standard. This change also reduces
+ confusion between "code point" and "position number"; while
+ these have the same values for the predefined character types,
+ there is no required relationship for other character types.
+
+\1f
+File: aarm2012.info, Node: 3.5.3, Next: 3.5.4, Prev: 3.5.2, Up: 3.5
+
+3.5.3 Boolean Types
+-------------------
+
+ _Static Semantics_
+
+1
+There is a predefined enumeration type named Boolean, [declared in the
+visible part of package Standard]. It has the two enumeration literals
+False and True ordered with the relation False < True. Any descendant
+of the predefined type Boolean is called a boolean type.
+
+1.a
+ Implementation Note: An implementation is not required to
+ support enumeration representation clauses on boolean types
+ that impose an unacceptable implementation burden. See *note
+ 13.4::, "*note 13.4:: Enumeration Representation Clauses".
+ However, it is generally straightforward to support
+ representations where False is zero and True is 2**n - 1 for
+ some n.
+
+\1f
+File: aarm2012.info, Node: 3.5.4, Next: 3.5.5, Prev: 3.5.3, Up: 3.5
+
+3.5.4 Integer Types
+-------------------
+
+1
+An integer_type_definition defines an integer type; it defines either a
+signed integer type, or a modular integer type. The base range of a
+signed integer type includes at least the values of the specified range.
+A modular type is an integer type with all arithmetic modulo a specified
+positive modulus; such a type corresponds to an unsigned type with
+wrap-around semantics.
+
+ _Syntax_
+
+2
+ integer_type_definition ::= signed_integer_type_definition |
+ modular_type_definition
+
+3
+ signed_integer_type_definition ::= range static_
+ simple_expression .. static_simple_expression
+
+3.a
+ Discussion: We don't call this a range_constraint, because it
+ is rather different -- not only is it required to be static,
+ but the associated overload resolution rules are different
+ than for normal range constraints. A similar comment applies
+ to real_range_specification. This used to be
+ integer_range_specification but when we added support for
+ modular types, it seemed overkill to have three levels of
+ syntax rules, and just calling these
+ signed_integer_range_specification and
+ modular_range_specification loses the fact that they are
+ defining different classes of types, which is important for
+ the generic type matching rules.
+
+4
+ modular_type_definition ::= mod static_expression
+
+ _Name Resolution Rules_
+
+5
+Each simple_expression in a signed_integer_type_definition is expected
+to be of any integer type; they need not be of the same type. The
+expression in a modular_type_definition is likewise expected to be of
+any integer type.
+
+ _Legality Rules_
+
+6
+The simple_expressions of a signed_integer_type_definition shall be
+static, and their values shall be in the range System.Min_Int ..
+System.Max_Int.
+
+7
+The expression of a modular_type_definition shall be static, and its
+value (the modulus) shall be positive, and shall be no greater than
+System.Max_Binary_Modulus if a power of 2, or no greater than
+System.Max_Nonbinary_Modulus if not.
+
+7.a
+ Reason: For a 2's-complement machine, supporting nonbinary
+ moduli greater than System.Max_Int can be quite difficult,
+ whereas essentially any binary moduli are straightforward to
+ support, up to 2*System.Max_Int+2, so this justifies having
+ two separate limits.
+
+ _Static Semantics_
+
+8
+The set of values for a signed integer type is the (infinite) set of
+mathematical integers[, though only values of the base range of the type
+are fully supported for run-time operations]. The set of values for a
+modular integer type are the values from 0 to one less than the modulus,
+inclusive.
+
+9
+A signed_integer_type_definition defines an integer type whose base
+range includes at least the values of the simple_expressions and is
+symmetric about zero, excepting possibly an extra negative value. A
+signed_integer_type_definition also defines a constrained first subtype
+of the type, with a range whose bounds are given by the values of the
+simple_expressions, converted to the type being defined.
+
+9.a/2
+ Implementation Note: {AI95-00114-01AI95-00114-01} The base
+ range of a signed integer type might be much larger than is
+ necessary to satisfy the above requirements.
+
+9.a.1/1
+ To be honest: The conversion mentioned above is not an
+ implicit subtype conversion (which is something that happens
+ at overload resolution, see *note 4.6::), although it happens
+ implicitly. Therefore, the freezing rules are not invoked on
+ the type (which is important so that representation items can
+ be given for the type).
+
+10
+A modular_type_definition defines a modular type whose base range is
+from zero to one less than the given modulus. A modular_type_definition
+also defines a constrained first subtype of the type with a range that
+is the same as the base range of the type.
+
+11
+There is a predefined signed integer subtype named Integer[, declared in
+the visible part of package Standard]. It is constrained to the base
+range of its type.
+
+11.a
+ Reason: Integer is a constrained subtype, rather than an
+ unconstrained subtype. This means that on assignment to an
+ object of subtype Integer, a range check is required. On the
+ other hand, an object of subtype Integer'Base is
+ unconstrained, and no range check (only overflow check) is
+ required on assignment. For example, if the object is held in
+ an extended-length register, its value might be outside of
+ Integer'First .. Integer'Last. All parameter and result
+ subtypes of the predefined integer operators are of such
+ unconstrained subtypes, allowing extended-length registers to
+ be used as operands or for the result. In an earlier version
+ of Ada 95, Integer was unconstrained. However, the fact that
+ certain Constraint_Errors might be omitted or appear elsewhere
+ was felt to be an undesirable upward inconsistency in this
+ case. Note that for Float, the opposite conclusion was
+ reached, partly because of the high cost of performing range
+ checks when not actually necessary. Objects of subtype Float
+ are unconstrained, and no range checks, only overflow checks,
+ are performed for them.
+
+12
+Integer has two predefined subtypes, [declared in the visible part of
+package Standard:]
+
+13
+ subtype Natural is Integer range 0 .. Integer'Last;
+ subtype Positive is Integer range 1 .. Integer'Last;
+
+14
+A type defined by an integer_type_definition is implicitly derived from
+root_integer, an anonymous predefined (specific) integer type, whose
+base range is System.Min_Int .. System.Max_Int. However, the base
+range of the new type is not inherited from root_integer, but is instead
+determined by the range or modulus specified by the
+integer_type_definition. [Integer literals are all of the type
+universal_integer, the universal type (see *note 3.4.1::) for the class
+rooted at root_integer, allowing their use with the operations of any
+integer type.]
+
+14.a
+ Discussion: This implicit derivation is not considered exactly
+ equivalent to explicit derivation via a
+ derived_type_definition. In particular, integer types defined
+ via a derived_type_definition inherit their base range from
+ their parent type. A type defined by an
+ integer_type_definition does not necessarily inherit its base
+ range from root_integer. It is not specified whether the
+ implicit derivation from root_integer is direct or indirect,
+ not that it really matters. All we want is for all integer
+ types to be descendants of root_integer.
+
+14.a.1/1
+ {8652/00998652/0099} {AI95-00152-01AI95-00152-01} Note that
+ this derivation does not imply any inheritance of subprograms.
+ Subprograms are inherited only for types derived by a
+ derived_type_definition (*note 3.4: S0035.) (see *note 3.4::),
+ or a private_extension_declaration (*note 7.3: S0194.) (see
+ *note 7.3::, *note 7.3.1::, and *note 12.5.1::).
+
+14.b
+ Implementation Note: It is the intent that even nonstandard
+ integer types (see below) will be descendants of root_integer,
+ even though they might have a base range that exceeds that of
+ root_integer. This causes no problem for static calculations,
+ which are performed without range restrictions (see *note
+ 4.9::). However for run-time calculations, it is possible
+ that Constraint_Error might be raised when using an operator
+ of root_integer on the result of 'Val applied to a value of a
+ nonstandard integer type.
+
+15
+The position number of an integer value is equal to the value.
+
+16/2
+{AI95-00340-01AI95-00340-01} For every modular subtype S, the following
+attributes are defined:
+
+16.1/2
+S'Mod
+ {AI95-00340-01AI95-00340-01} S'Mod denotes a function
+ with the following specification:
+
+16.2/2
+ function S'Mod (Arg : universal_integer)
+ return S'Base
+
+16.3/2
+ This function returns Arg mod S'Modulus, as a value of
+ the type of S.
+
+17
+S'Modulus
+ S'Modulus yields the modulus of the type of S, as a value
+ of the type universal_integer.
+
+ _Dynamic Semantics_
+
+18
+The elaboration of an integer_type_definition creates the integer type
+and its first subtype.
+
+19
+For a modular type, if the result of the execution of a predefined
+operator (see *note 4.5::) is outside the base range of the type, the
+result is reduced modulo the modulus of the type to a value that is
+within the base range of the type.
+
+20
+For a signed integer type, the exception Constraint_Error is raised by
+the execution of an operation that cannot deliver the correct result
+because it is outside the base range of the type. [ For any integer
+type, Constraint_Error is raised by the operators "/", "rem", and "mod"
+if the right operand is zero.]
+
+ _Implementation Requirements_
+
+21
+In an implementation, the range of Integer shall include the range
+-2**15+1 .. +2**15-1.
+
+22
+If Long_Integer is predefined for an implementation, then its range
+shall include the range -2**31+1 .. +2**31-1.
+
+23
+System.Max_Binary_Modulus shall be at least 2**16.
+
+ _Implementation Permissions_
+
+24
+For the execution of a predefined operation of a signed integer type,
+the implementation need not raise Constraint_Error if the result is
+outside the base range of the type, so long as the correct result is
+produced.
+
+24.a
+ Discussion: Constraint_Error is never raised for operations on
+ modular types, except for divide-by-zero (and
+ rem/mod-by-zero).
+
+25
+An implementation may provide additional predefined signed integer
+types[, declared in the visible part of Standard], whose first subtypes
+have names of the form Short_Integer, Long_Integer, Short_Short_Integer,
+Long_Long_Integer, etc. Different predefined integer types are allowed
+to have the same base range. However, the range of Integer should be no
+wider than that of Long_Integer. Similarly, the range of Short_Integer
+(if provided) should be no wider than Integer. Corresponding
+recommendations apply to any other predefined integer types. There need
+not be a named integer type corresponding to each distinct base range
+supported by an implementation. The range of each first subtype should
+be the base range of its type.
+
+25.a
+ Implementation defined: The predefined integer types declared
+ in Standard.
+
+26
+An implementation may provide nonstandard integer types, descendants of
+root_integer that are declared outside of the specification of package
+Standard, which need not have all the standard characteristics of a type
+defined by an integer_type_definition. For example, a nonstandard
+integer type might have an asymmetric base range or it might not be
+allowed as an array or loop index (a very long integer). Any type
+descended from a nonstandard integer type is also nonstandard. An
+implementation may place arbitrary restrictions on the use of such
+types; it is implementation defined whether operators that are
+predefined for "any integer type" are defined for a particular
+nonstandard integer type. [In any case, such types are not permitted as
+explicit_generic_actual_parameters for formal scalar types -- see *note
+12.5.2::.]
+
+26.a
+ Implementation defined: Any nonstandard integer types and the
+ operators defined for them.
+
+27
+For a one's complement machine, the high bound of the base range of a
+modular type whose modulus is one less than a power of 2 may be equal to
+the modulus, rather than one less than the modulus. It is
+implementation defined for which powers of 2, if any, this permission is
+exercised.
+
+27.1/1
+{8652/00038652/0003} {AI95-00095-01AI95-00095-01} For a one's complement
+machine, implementations may support nonbinary modulus values greater
+than System.Max_Nonbinary_Modulus. It is implementation defined which
+specific values greater than System.Max_Nonbinary_Modulus, if any, are
+supported.
+
+27.a.1/1
+ Reason: On a one's complement machine, the natural full word
+ type would have a modulus of 2**Word_Size-1. However, we
+ would want to allow the all-ones bit pattern (which represents
+ negative zero as a number) in logical operations. These
+ permissions are intended to allow that and the natural modulus
+ value without burdening implementations with supporting
+ expensive modulus values.
+
+ _Implementation Advice_
+
+28
+An implementation should support Long_Integer in addition to Integer if
+the target machine supports 32-bit (or longer) arithmetic. No other
+named integer subtypes are recommended for package Standard. Instead,
+appropriate named integer subtypes should be provided in the library
+package Interfaces (see *note B.2::).
+
+28.a.1/2
+ Implementation Advice: Long_Integer should be declared in
+ Standard if the target supports 32-bit arithmetic. No other
+ named integer subtypes should be declared in Standard.
+
+28.a
+ Implementation Note: To promote portability, implementations
+ should explicitly declare the integer (sub)types Integer and
+ Long_Integer in Standard, and leave other predefined integer
+ types anonymous. For implementations that already support
+ Byte_Integer, etc., upward compatibility argues for keeping
+ such declarations in Standard during the transition period,
+ but perhaps generating a warning on use. A separate package
+ Interfaces in the predefined environment is available for
+ pre-declaring types such as Integer_8, Integer_16, etc. See
+ *note B.2::. In any case, if the user declares a subtype
+ (first or not) whose range fits in, for example, a byte, the
+ implementation can store variables of the subtype in a single
+ byte, even if the base range of the type is wider.
+
+29
+An implementation for a two's complement machine should support modular
+types with a binary modulus up to System.Max_Int*2+2. An implementation
+should support a nonbinary modulus up to Integer'Last.
+
+29.a.1/2
+ Implementation Advice: For a two's complement target, modular
+ types with a binary modulus up to System.Max_Int*2+2 should be
+ supported. A nonbinary modulus up to Integer'Last should be
+ supported.
+
+29.a
+ Reason: Modular types provide bit-wise "and", "or", "xor", and
+ "not" operations. It is important for systems programming
+ that these be available for all integer types of the target
+ hardware.
+
+29.b
+ Ramification: Note that on a one's complement machine, the
+ largest supported modular type would normally have a nonbinary
+ modulus. On a two's complement machine, the largest supported
+ modular type would normally have a binary modulus.
+
+29.c
+ Implementation Note: Supporting a nonbinary modulus greater
+ than Integer'Last can impose an undesirable implementation
+ burden on some machines.
+
+ NOTES
+
+30
+ 30 Integer literals are of the anonymous predefined integer type
+ universal_integer. Other integer types have no literals. However,
+ the overload resolution rules (see *note 8.6::, "*note 8.6:: The
+ Context of Overload Resolution") allow expressions of the type
+ universal_integer whenever an integer type is expected.
+
+31
+ 31 The same arithmetic operators are predefined for all signed
+ integer types defined by a signed_integer_type_definition (see
+ *note 4.5::, "*note 4.5:: Operators and Expression Evaluation").
+ For modular types, these same operators are predefined, plus
+ bit-wise logical operators (and, or, xor, and not). In addition,
+ for the unsigned types declared in the language-defined package
+ Interfaces (see *note B.2::), functions are defined that provide
+ bit-wise shifting and rotating.
+
+32
+ 32 Modular types match a generic_formal_parameter_declaration of
+ the form "type T is mod <>;"; signed integer types match "type T is
+ range <>;" (see *note 12.5.2::).
+
+ _Examples_
+
+33
+Examples of integer types and subtypes:
+
+34
+ type Page_Num is range 1 .. 2_000;
+ type Line_Size is range 1 .. Max_Line_Size;
+
+35
+ subtype Small_Int is Integer range -10 .. 10;
+ subtype Column_Ptr is Line_Size range 1 .. 10;
+ subtype Buffer_Size is Integer range 0 .. Max;
+
+36
+ type Byte is mod 256; -- an unsigned byte
+ type Hash_Index is mod 97; -- modulus is prime
+
+ _Extensions to Ada 83_
+
+36.a
+ An implementation is allowed to support any number of distinct
+ base ranges for integer types, even if fewer integer types are
+ explicitly declared in Standard.
+
+36.b
+ Modular (unsigned, wrap-around) types are new.
+
+ _Wording Changes from Ada 83_
+
+36.c
+ Ada 83's integer types are now called "signed" integer types,
+ to contrast them with "modular" integer types.
+
+36.d
+ Standard.Integer, Standard.Long_Integer, etc., denote
+ constrained subtypes of predefined integer types, consistent
+ with the Ada 95 model that only subtypes have names.
+
+36.e
+ We now impose minimum requirements on the base range of
+ Integer and Long_Integer.
+
+36.f
+ We no longer explain integer type definition in terms of an
+ equivalence to a normal type derivation, except to say that
+ all integer types are by definition implicitly derived from
+ root_integer. This is for various reasons.
+
+36.g
+ First of all, the equivalence with a type derivation and a
+ subtype declaration was not perfect, and was the source of
+ various AIs (for example, is the conversion of the bounds
+ static? Is a numeric type a derived type with respect to
+ other rules of the language?)
+
+36.h
+ Secondly, we don't want to require that every integer size
+ supported shall have a corresponding named type in Standard.
+ Adding named types to Standard creates nonportabilities.
+
+36.i
+ Thirdly, we don't want the set of types that match a formal
+ derived type "type T is new Integer;" to depend on the
+ particular underlying integer representation chosen to
+ implement a given user-defined integer type. Hence, we would
+ have needed anonymous integer types as parent types for the
+ implicit derivation anyway. We have simply chosen to identify
+ only one anonymous integer type -- root_integer, and stated
+ that every integer type is derived from it.
+
+36.j
+ Finally, the "fiction" that there were distinct preexisting
+ predefined types for every supported representation breaks
+ down for fixed point with arbitrary smalls, and was never
+ exploited for enumeration types, array types, etc. Hence,
+ there seems little benefit to pushing an explicit equivalence
+ between integer type definition and normal type derivation.
+
+ _Extensions to Ada 95_
+
+36.k/2
+ {AI95-00340-01AI95-00340-01} The Mod attribute is new. It
+ eases mixing of signed and unsigned values in an expression,
+ which can be difficult as there may be no type which can
+ contain all of the values of both of the types involved.
+
+ _Wording Changes from Ada 95_
+
+36.l/2
+ {8652/00038652/0003} {AI95-00095-01AI95-00095-01} Corrigendum:
+ Added additional permissions for modular types on one's
+ complement machines.
+
+\1f
+File: aarm2012.info, Node: 3.5.5, Next: 3.5.6, Prev: 3.5.4, Up: 3.5
+
+3.5.5 Operations of Discrete Types
+----------------------------------
+
+ _Static Semantics_
+
+1
+For every discrete subtype S, the following attributes are defined:
+
+2
+S'Pos
+ S'Pos denotes a function with the following
+ specification:
+
+3
+ function S'Pos(Arg : S'Base)
+ return universal_integer
+
+4
+ This function returns the position number of the value of
+ Arg, as a value of type universal_integer.
+
+5
+S'Val
+ S'Val denotes a function with the following
+ specification:
+
+6
+ function S'Val(Arg : universal_integer)
+ return S'Base
+
+7
+ This function returns a value of the type of S whose
+ position number equals the value of Arg. For the
+ evaluation of a call on S'Val, if there is no value in
+ the base range of its type with the given position
+ number, Constraint_Error is raised.
+
+7.a
+ Ramification: By the overload resolution rules, a formal
+ parameter of type universal_integer allows an actual parameter
+ of any integer type.
+
+7.b
+ Reason: We considered allowing S'Val for a signed integer
+ subtype S to return an out-of-range value, but since checks
+ were required for enumeration and modular types anyway, the
+ allowance didn't seem worth the complexity of the rule.
+
+7.1/3
+{AI05-0297-1AI05-0297-1} For every static discrete subtype S for which
+there exists at least one value belonging to S that satisfies any
+predicate of S, the following attributes are defined:
+
+7.2/3
+S'First_Valid
+ {AI05-0297-1AI05-0297-1} S'First_Valid denotes the
+ smallest value that belongs to S and satisfies the
+ predicate of S. The value of this attribute is of the
+ type of S.
+
+7.3/3
+S'Last_Valid
+ {AI05-0297-1AI05-0297-1} S'Last_Valid denotes the largest
+ value that belongs to S and satisfies the predicate of S.
+ The value of this attribute is of the type of S.
+
+7.4/3
+{AI05-0297-1AI05-0297-1} [First_Valid and Last_Valid
+attribute_references are always static expressions. Any explicit
+predicate of S can only have been specified by a Static_Predicate
+aspect.]
+
+7.c/3
+ Proof: An attribute_reference is static if the prefix is a
+ static subtype (see *note 4.9::), (true by definition) and any
+ arguments are static (there are none). Similarly, a dynamic
+ predicate always makes a subtype nonstatic. QED.
+
+7.d/3
+ Reason: We require there to be at least one value so that
+ these are always values of the subtype. (This sidesteps the
+ question of what to return for a subtype with no values.)
+
+7.e/3
+ Discussion: These attributes are intended primarily for use in
+ the case where the Static_Predicate aspect of S has been
+ specified; First and Last are equivalent if these are allowed
+ and there is no predicate.
+
+ _Implementation Advice_
+
+8
+For the evaluation of a call on S'Pos for an enumeration subtype, if the
+value of the operand does not correspond to the internal code for any
+enumeration literal of its type [(perhaps due to an uninitialized
+variable)], then the implementation should raise Program_Error. This is
+particularly important for enumeration types with noncontiguous internal
+codes specified by an enumeration_representation_clause (*note 13.4:
+S0310.).
+
+8.a.1/2
+ Implementation Advice: Program_Error should be raised for the
+ evaluation of S'Pos for an enumeration type, if the value of
+ the operand does not correspond to the internal code for any
+ enumeration literal of the type.
+
+8.a
+ Reason: We say Program_Error here, rather than
+ Constraint_Error, because the main reason for such values is
+ uninitialized variables, and the normal way to indicate such a
+ use (if detected) is to raise Program_Error. (Other reasons
+ would involve the misuse of low-level features such as
+ Unchecked_Conversion.)
+
+ NOTES
+
+9
+ 33 Indexing and loop iteration use values of discrete types.
+
+10/3
+ 34 {AI05-0299-1AI05-0299-1} The predefined operations of a
+ discrete type include the assignment operation, qualification, the
+ membership tests, and the relational operators; for a boolean type
+ they include the short-circuit control forms and the logical
+ operators; for an integer type they include type conversion to and
+ from other numeric types, as well as the binary and unary adding
+ operators - and +, the multiplying operators, the unary operator
+ abs, and the exponentiation operator. The assignment operation is
+ described in *note 5.2::. The other predefined operations are
+ described in Clause *note 4::.
+
+11
+ 35 As for all types, objects of a discrete type have Size and
+ Address attributes (see *note 13.3::).
+
+12
+ 36 For a subtype of a discrete type, the result delivered by the
+ attribute Val might not belong to the subtype; similarly, the
+ actual parameter of the attribute Pos need not belong to the
+ subtype. The following relations are satisfied (in the absence of
+ an exception) by these attributes:
+
+13
+ S'Val(S'Pos(X)) = X
+ S'Pos(S'Val(N)) = N
+
+ _Examples_
+
+14
+Examples of attributes of discrete subtypes:
+
+15
+ -- For the types and subtypes declared in subclause *note 3.5.1:: the following hold:
+
+16
+ -- Color'First = White, Color'Last = Black
+ -- Rainbow'First = Red, Rainbow'Last = Blue
+
+17
+ -- Color'Succ(Blue) = Rainbow'Succ(Blue) = Brown
+ -- Color'Pos(Blue) = Rainbow'Pos(Blue) = 4
+ -- Color'Val(0) = Rainbow'Val(0) = White
+
+ _Extensions to Ada 83_
+
+17.a
+ The attributes S'Succ, S'Pred, S'Width, S'Image, and S'Value
+ have been generalized to apply to real types as well (see
+ *note 3.5::, "*note 3.5:: Scalar Types").
+
+ _Extensions to Ada 2005_
+
+17.b/3
+ {AI05-0297-1AI05-0297-1} The attributes S'First_Valid and
+ S'Last_Valid are new.
+
+\1f
+File: aarm2012.info, Node: 3.5.6, Next: 3.5.7, Prev: 3.5.5, Up: 3.5
+
+3.5.6 Real Types
+----------------
+
+1
+Real types provide approximations to the real numbers, with relative
+bounds on errors for floating point types, and with absolute bounds for
+fixed point types.
+
+ _Syntax_
+
+2
+ real_type_definition ::=
+ floating_point_definition | fixed_point_definition
+
+ _Static Semantics_
+
+3
+A type defined by a real_type_definition is implicitly derived from
+root_real, an anonymous predefined (specific) real type. [Hence, all
+real types, whether floating point or fixed point, are in the derivation
+class rooted at root_real.]
+
+3.a
+ Ramification: It is not specified whether the derivation from
+ root_real is direct or indirect, not that it really matters.
+ All we want is for all real types to be descendants of
+ root_real.
+
+3.a.1/1
+ {8652/00998652/0099} {AI95-00152-01AI95-00152-01} Note that
+ this derivation does not imply any inheritance of subprograms.
+ Subprograms are inherited only for types derived by a
+ derived_type_definition (*note 3.4: S0035.) (see *note 3.4::),
+ or a private_extension_declaration (*note 7.3: S0194.) (see
+ *note 7.3::, *note 7.3.1::, and *note 12.5.1::).
+
+4
+[ Real literals are all of the type universal_real, the universal type
+(see *note 3.4.1::) for the class rooted at root_real, allowing their
+use with the operations of any real type. Certain multiplying operators
+have a result type of universal_fixed (see *note 4.5.5::), the universal
+type for the class of fixed point types, allowing the result of the
+multiplication or division to be used where any specific fixed point
+type is expected.]
+
+ _Dynamic Semantics_
+
+5
+The elaboration of a real_type_definition consists of the elaboration of
+the floating_point_definition or the fixed_point_definition.
+
+ _Implementation Requirements_
+
+6
+An implementation shall perform the run-time evaluation of a use of a
+predefined operator of root_real with an accuracy at least as great as
+that of any floating point type definable by a
+floating_point_definition.
+
+6.a
+ Ramification: Static calculations using the operators of
+ root_real are exact, as for all static calculations. See
+ *note 4.9::.
+
+6.b
+ Implementation Note: The Digits attribute of the type used to
+ represent root_real at run time is at least as great as that
+ of any other floating point type defined by a
+ floating_point_definition, and its safe range includes that of
+ any such floating point type with the same Digits attribute.
+ On some machines, there might be real types with less accuracy
+ but a wider range, and hence run-time calculations with
+ root_real might not be able to accommodate all values that can
+ be represented at run time in such floating point or fixed
+ point types.
+
+ _Implementation Permissions_
+
+7/2
+{AI95-00114-01AI95-00114-01} [For the execution of a predefined
+operation of a real type, the implementation need not raise
+Constraint_Error if the result is outside the base range of the type, so
+long as the correct result is produced, or the Machine_Overflows
+attribute of the type is False (see *note G.2::).]
+
+8
+An implementation may provide nonstandard real types, descendants of
+root_real that are declared outside of the specification of package
+Standard, which need not have all the standard characteristics of a type
+defined by a real_type_definition. For example, a nonstandard real type
+might have an asymmetric or unsigned base range, or its predefined
+operations might wrap around or "saturate" rather than overflow (modular
+or saturating arithmetic), or it might not conform to the accuracy model
+(see *note G.2::). Any type descended from a nonstandard real type is
+also nonstandard. An implementation may place arbitrary restrictions on
+the use of such types; it is implementation defined whether operators
+that are predefined for "any real type" are defined for a particular
+nonstandard real type. [In any case, such types are not permitted as
+explicit_generic_actual_parameters for formal scalar types -- see *note
+12.5.2::.]
+
+8.a
+ Implementation defined: Any nonstandard real types and the
+ operators defined for them.
+
+ NOTES
+
+9
+ 37 As stated, real literals are of the anonymous predefined real
+ type universal_real. Other real types have no literals. However,
+ the overload resolution rules (see *note 8.6::) allow expressions
+ of the type universal_real whenever a real type is expected.
+
+ _Wording Changes from Ada 83_
+
+9.a
+ The syntax rule for real_type_definition is modified to use
+ the new syntactic categories floating_point_definition and
+ fixed_point_definition, instead of floating_point_constraint
+ and fixed_point_constraint, because the semantics of a type
+ definition are significantly different than the semantics of a
+ constraint.
+
+9.b
+ All discussion of model numbers, safe ranges, and machine
+ numbers is moved to *note 3.5.7::, *note 3.5.8::, and *note
+ G.2::. Values of a fixed point type are now described as
+ being multiples of the small of the fixed point type, and we
+ have no need for model numbers, safe ranges, etc. for fixed
+ point types.
+
+\1f
+File: aarm2012.info, Node: 3.5.7, Next: 3.5.8, Prev: 3.5.6, Up: 3.5
+
+3.5.7 Floating Point Types
+--------------------------
+
+1
+For floating point types, the error bound is specified as a relative
+precision by giving the required minimum number of significant decimal
+digits.
+
+ _Syntax_
+
+2
+ floating_point_definition ::=
+ digits static_expression [real_range_specification]
+
+3
+ real_range_specification ::=
+ range static_simple_expression .. static_simple_expression
+
+ _Name Resolution Rules_
+
+4
+The requested decimal precision, which is the minimum number of
+significant decimal digits required for the floating point type, is
+specified by the value of the expression given after the reserved word
+digits. This expression is expected to be of any integer type.
+
+5
+Each simple_expression of a real_range_specification is expected to be
+of any real type[; the types need not be the same].
+
+ _Legality Rules_
+
+6
+The requested decimal precision shall be specified by a static
+expression whose value is positive and no greater than
+System.Max_Base_Digits. Each simple_expression of a
+real_range_specification shall also be static. If the
+real_range_specification is omitted, the requested decimal precision
+shall be no greater than System.Max_Digits.
+
+6.a
+ Reason: We have added Max_Base_Digits to package System. It
+ corresponds to the requested decimal precision of root_real.
+ System.Max_Digits corresponds to the maximum value for Digits
+ that may be specified in the absence of a
+ real_range_specification, for upward compatibility. These
+ might not be the same if root_real has a base range that does
+ not include ± 10.0**(4*Max_Base_Digits).
+
+7
+A floating_point_definition is illegal if the implementation does not
+support a floating point type that satisfies the requested decimal
+precision and range.
+
+7.a
+ Implementation defined: What combinations of requested decimal
+ precision and range are supported for floating point types.
+
+ _Static Semantics_
+
+8
+The set of values for a floating point type is the (infinite) set of
+rational numbers. The machine numbers of a floating point type are the
+values of the type that can be represented exactly in every
+unconstrained variable of the type. The base range (see *note 3.5::) of
+a floating point type is symmetric around zero, except that it can
+include some extra negative values in some implementations.
+
+8.a
+ Implementation Note: For example, if a 2's complement
+ representation is used for the mantissa rather than a
+ sign-mantissa or 1's complement representation, then there is
+ usually one extra negative machine number.
+
+8.b
+ To be honest: If the Signed_Zeros attribute is True, then
+ minus zero could in a sense be considered a value of the type.
+ However, for most purposes, minus zero behaves the same as
+ plus zero.
+
+9
+The base decimal precision of a floating point type is the number of
+decimal digits of precision representable in objects of the type. The
+safe range of a floating point type is that part of its base range for
+which the accuracy corresponding to the base decimal precision is
+preserved by all predefined operations.
+
+9.a
+ Implementation Note: In most cases, the safe range and base
+ range are the same. However, for some hardware, values near
+ the boundaries of the base range might result in excessive
+ inaccuracies or spurious overflows when used with certain
+ predefined operations. For such hardware, the safe range
+ would omit such values.
+
+10
+A floating_point_definition defines a floating point type whose base
+decimal precision is no less than the requested decimal precision. If a
+real_range_specification is given, the safe range of the floating point
+type (and hence, also its base range) includes at least the values of
+the simple expressions given in the real_range_specification. If a
+real_range_specification is not given, the safe (and base) range of the
+type includes at least the values of the range -10.0**(4*D) ..
++10.0**(4*D) where D is the requested decimal precision. [The safe
+range might include other values as well. The attributes Safe_First and
+Safe_Last give the actual bounds of the safe range.]
+
+11
+A floating_point_definition also defines a first subtype of the type.
+If a real_range_specification is given, then the subtype is constrained
+to a range whose bounds are given by a conversion of the values of the
+simple_expressions of the real_range_specification to the type being
+defined. Otherwise, the subtype is unconstrained.
+
+11.a.1/1
+ To be honest: The conversion mentioned above is not an
+ implicit subtype conversion (which is something that happens
+ at overload resolution, see *note 4.6::), although it happens
+ implicitly. Therefore, the freezing rules are not invoked on
+ the type (which is important so that representation items can
+ be given for the type).
+
+12
+There is a predefined, unconstrained, floating point subtype named
+Float[, declared in the visible part of package Standard].
+
+ _Dynamic Semantics_
+
+13
+[The elaboration of a floating_point_definition creates the floating
+point type and its first subtype.]
+
+ _Implementation Requirements_
+
+14
+In an implementation that supports floating point types with 6 or more
+digits of precision, the requested decimal precision for Float shall be
+at least 6.
+
+15
+If Long_Float is predefined for an implementation, then its requested
+decimal precision shall be at least 11.
+
+ _Implementation Permissions_
+
+16
+An implementation is allowed to provide additional predefined floating
+point types[, declared in the visible part of Standard], whose
+(unconstrained) first subtypes have names of the form Short_Float,
+Long_Float, Short_Short_Float, Long_Long_Float, etc. Different
+predefined floating point types are allowed to have the same base
+decimal precision. However, the precision of Float should be no greater
+than that of Long_Float. Similarly, the precision of Short_Float (if
+provided) should be no greater than Float. Corresponding
+recommendations apply to any other predefined floating point types.
+There need not be a named floating point type corresponding to each
+distinct base decimal precision supported by an implementation.
+
+16.a
+ Implementation defined: The predefined floating point types
+ declared in Standard.
+
+ _Implementation Advice_
+
+17
+An implementation should support Long_Float in addition to Float if the
+target machine supports 11 or more digits of precision. No other named
+floating point subtypes are recommended for package Standard. Instead,
+appropriate named floating point subtypes should be provided in the
+library package Interfaces (see *note B.2::).
+
+17.a.1/2
+ Implementation Advice: Long_Float should be declared in
+ Standard if the target supports 11 or more digits of
+ precision. No other named float subtypes should be declared
+ in Standard.
+
+17.a
+ Implementation Note: To promote portability, implementations
+ should explicitly declare the floating point (sub)types Float
+ and Long_Float in Standard, and leave other predefined float
+ types anonymous. For implementations that already support
+ Short_Float, etc., upward compatibility argues for keeping
+ such declarations in Standard during the transition period,
+ but perhaps generating a warning on use. A separate package
+ Interfaces in the predefined environment is available for
+ pre-declaring types such as Float_32, IEEE_Float_64, etc. See
+ *note B.2::.
+
+ NOTES
+
+18
+ 38 If a floating point subtype is unconstrained, then assignments
+ to variables of the subtype involve only Overflow_Checks, never
+ Range_Checks.
+
+ _Examples_
+
+19
+Examples of floating point types and subtypes:
+
+20
+ type Coefficient is digits 10 range -1.0 .. 1.0;
+
+21
+ type Real is digits 8;
+ type Mass is digits 7 range 0.0 .. 1.0E35;
+
+22
+ subtype Probability is Real range 0.0 .. 1.0; -- a subtype with a smaller range
+
+ _Inconsistencies With Ada 83_
+
+22.a
+ No Range_Checks, only Overflow_Checks, are performed on
+ variables (or parameters) of an unconstrained floating point
+ subtype. This is upward compatible for programs that do not
+ raise Constraint_Error. For those that do raise
+ Constraint_Error, it is possible that the exception will be
+ raised at a later point, or not at all, if extended range
+ floating point registers are used to hold the value of the
+ variable (or parameter).
+
+22.b
+ Reason: This change was felt to be justified by the
+ possibility of improved performance on machines with
+ extended-range floating point registers. An implementation
+ need not take advantage of this relaxation in the range
+ checking; it can hide completely the use of extended range
+ registers if desired, presumably at some run-time expense.
+
+ _Wording Changes from Ada 83_
+
+22.c
+ The syntax rules for floating_point_constraint and
+ floating_accuracy_definition are removed. The syntax rules
+ for floating_point_definition and real_range_specification are
+ new.
+
+22.d
+ A syntax rule for digits_constraint is given in *note 3.5.9::,
+ "*note 3.5.9:: Fixed Point Types". In *note J.3:: we indicate
+ that a digits_constraint may be applied to a floating point
+ subtype_mark as well (to be compatible with Ada 83's
+ floating_point_constraint).
+
+22.e
+ Discussion of model numbers is postponed to *note 3.5.8:: and
+ *note G.2::. The concept of safe numbers has been replaced by
+ the concept of the safe range of values. The bounds of the
+ safe range are given by T'Safe_First .. T'Safe_Last, rather
+ than -T'Safe_Large .. T'Safe_Large, since on some machines
+ the safe range is not perfectly symmetric. The concept of
+ machine numbers is new, and is relevant to the definition of
+ Succ and Pred for floating point numbers.
+
+\1f
+File: aarm2012.info, Node: 3.5.8, Next: 3.5.9, Prev: 3.5.7, Up: 3.5
+
+3.5.8 Operations of Floating Point Types
+----------------------------------------
+
+ _Static Semantics_
+
+1
+The following attribute is defined for every floating point subtype S:
+
+2/1
+S'Digits
+ {8652/00048652/0004} {AI95-00203-01AI95-00203-01}
+ S'Digits denotes the requested decimal precision for the
+ subtype S. The value of this attribute is of the type
+ universal_integer. The requested decimal precision of
+ the base subtype of a floating point type T is defined to
+ be the largest value of d for which
+ ceiling(d * log(10) / log(T'Machine_Radix)) + g <=
+ T'Model_Mantissa
+ where g is 0 if Machine_Radix is a positive power of 10
+ and 1 otherwise.
+
+ NOTES
+
+3
+ 39 The predefined operations of a floating point type include the
+ assignment operation, qualification, the membership tests, and
+ explicit conversion to and from other numeric types. They also
+ include the relational operators and the following predefined
+ arithmetic operators: the binary and unary adding operators - and
+ +, certain multiplying operators, the unary operator abs, and the
+ exponentiation operator.
+
+4
+ 40 As for all types, objects of a floating point type have Size
+ and Address attributes (see *note 13.3::). Other attributes of
+ floating point types are defined in *note A.5.3::.
+
+ _Wording Changes from Ada 95_
+
+4.a/2
+ {8652/00048652/0004} {AI95-00203-01AI95-00203-01} Corrigendum:
+ Corrected the formula for Digits when the Machine_Radix is 10.
+
+\1f
+File: aarm2012.info, Node: 3.5.9, Next: 3.5.10, Prev: 3.5.8, Up: 3.5
+
+3.5.9 Fixed Point Types
+-----------------------
+
+1
+A fixed point type is either an ordinary fixed point type, or a decimal
+fixed point type. The error bound of a fixed point type is specified as
+an absolute value, called the delta of the fixed point type.
+
+ _Syntax_
+
+2
+ fixed_point_definition ::= ordinary_fixed_point_definition |
+ decimal_fixed_point_definition
+
+3
+ ordinary_fixed_point_definition ::=
+ delta static_expression real_range_specification
+
+4
+ decimal_fixed_point_definition ::=
+ delta static_expression digits static_expression [
+ real_range_specification]
+
+5
+ digits_constraint ::=
+ digits static_expression [range_constraint]
+
+ _Name Resolution Rules_
+
+6
+For a type defined by a fixed_point_definition, the delta of the type is
+specified by the value of the expression given after the reserved word
+delta; this expression is expected to be of any real type. For a type
+defined by a decimal_fixed_point_definition (a decimal fixed point
+type), the number of significant decimal digits for its first subtype
+(the digits of the first subtype) is specified by the expression given
+after the reserved word digits; this expression is expected to be of any
+integer type.
+
+ _Legality Rules_
+
+7
+In a fixed_point_definition or digits_constraint, the expressions given
+after the reserved words delta and digits shall be static; their values
+shall be positive.
+
+8/2
+{AI95-00100-01AI95-00100-01} The set of values of a fixed point type
+comprise the integral multiples of a number called the small of the
+type. The machine numbers of a fixed point type are the values of the
+type that can be represented exactly in every unconstrained variable of
+the type. For a type defined by an ordinary_fixed_point_definition (an
+ordinary fixed point type), the small may be specified by an
+attribute_definition_clause (*note 13.3: S0309.) (see *note 13.3::); if
+so specified, it shall be no greater than the delta of the type. If not
+specified, the small of an ordinary fixed point type is an
+implementation-defined power of two less than or equal to the delta.
+
+8.a
+ Implementation defined: The small of an ordinary fixed point
+ type.
+
+9
+For a decimal fixed point type, the small equals the delta; the delta
+shall be a power of 10. If a real_range_specification is given, both
+bounds of the range shall be in the range -(10**digits-1)*delta ..
++(10**digits-1)*delta.
+
+10
+A fixed_point_definition is illegal if the implementation does not
+support a fixed point type with the given small and specified range or
+digits.
+
+10.a
+ Implementation defined: What combinations of small, range, and
+ digits are supported for fixed point types.
+
+11
+For a subtype_indication with a digits_constraint, the subtype_mark
+shall denote a decimal fixed point subtype.
+
+11.a
+ To be honest: Or, as an obsolescent feature, a floating point
+ subtype is permitted -- see *note J.3::.
+
+ _Static Semantics_
+
+12
+The base range (see *note 3.5::) of a fixed point type is symmetric
+around zero, except possibly for an extra negative value in some
+implementations.
+
+13
+An ordinary_fixed_point_definition defines an ordinary fixed point type
+whose base range includes at least all multiples of small that are
+between the bounds specified in the real_range_specification. The base
+range of the type does not necessarily include the specified bounds
+themselves. An ordinary_fixed_point_definition (*note 3.5.9: S0048.)
+also defines a constrained first subtype of the type, with each bound of
+its range given by the closer to zero of:
+
+14
+ * the value of the conversion to the fixed point type of the
+ corresponding expression of the real_range_specification;
+
+14.a.1/1
+ To be honest: The conversion mentioned above is not an
+ implicit subtype conversion (which is something that happens
+ at overload resolution, see *note 4.6::), although it happens
+ implicitly. Therefore, the freezing rules are not invoked on
+ the type (which is important so that representation items can
+ be given for the type).
+
+15
+ * the corresponding bound of the base range.
+
+16
+A decimal_fixed_point_definition defines a decimal fixed point type
+whose base range includes at least the range -(10**digits-1)*delta ..
++(10**digits-1)*delta. A decimal_fixed_point_definition also defines a
+constrained first subtype of the type. If a real_range_specification is
+given, the bounds of the first subtype are given by a conversion of the
+values of the expressions of the real_range_specification. Otherwise,
+the range of the first subtype is -(10**digits-1)*delta ..
++(10**digits-1)*delta.
+
+16.a.1/1
+ To be honest: The conversion mentioned above is not an
+ implicit subtype conversion (which is something that happens
+ at overload resolution, see *note 4.6::), although it happens
+ implicitly. Therefore, the freezing rules are not invoked on
+ the type (which is important so that representation items can
+ be given for the type).
+
+ _Dynamic Semantics_
+
+17
+The elaboration of a fixed_point_definition creates the fixed point type
+and its first subtype.
+
+18
+For a digits_constraint on a decimal fixed point subtype with a given
+delta, if it does not have a range_constraint, then it specifies an
+implicit range -(10**D-1)*delta .. +(10**D-1)*delta, where D is the
+value of the expression. A digits_constraint is compatible with a
+decimal fixed point subtype if the value of the expression is no greater
+than the digits of the subtype, and if it specifies (explicitly or
+implicitly) a range that is compatible with the subtype.
+
+18.a
+ Discussion: Except for the requirement that the digits
+ specified be no greater than the digits of the subtype being
+ constrained, a digits_constraint is essentially equivalent to
+ a range_constraint.
+
+18.b
+ Consider the following example:
+
+18.c
+ type D is delta 0.01 digits 7 range -0.00 .. 9999.99;
+
+18.d/1
+ The compatibility rule implies that the digits_constraint
+ "digits 6" specifies an implicit range of "-9999.99 ..
+ 9999.99". Thus, "digits 6" is not compatible with the
+ constraint of D, but "digits 6 range 0.00 .. 9999.99" is
+ compatible.
+
+18.e/2
+ {AI95-00114-01AI95-00114-01} A value of a scalar type belongs
+ to a constrained subtype of the type if it belongs to the
+ range of the subtype. Attributes like Digits and Delta have
+ no effect on this fundamental rule. So the obsolescent forms
+ of digits_constraints and delta_constraints that are called
+ "accuracy constraints" in RM83 don't really represent
+ constraints on the values of the subtype, but rather primarily
+ affect compatibility of the "constraint" with the subtype
+ being "constrained." In this sense, they might better be
+ called "subtype assertions" rather than "constraints."
+
+18.f
+ Note that the digits_constraint on a decimal fixed point
+ subtype is a combination of an assertion about the digits of
+ the subtype being further constrained, and a constraint on the
+ range of the subtype being defined, either explicit or
+ implicit.
+
+19
+The elaboration of a digits_constraint consists of the elaboration of
+the range_constraint, if any. If a range_constraint is given, a check
+is made that the bounds of the range are both in the range
+-(10**D-1)*delta .. +(10**D-1)*delta, where D is the value of the
+(static) expression given after the reserved word digits. If this check
+fails, Constraint_Error is raised.
+
+ _Implementation Requirements_
+
+20
+The implementation shall support at least 24 bits of precision
+(including the sign bit) for fixed point types.
+
+20.a
+ Reason: This is sufficient to represent Standard.Duration with
+ a small no more than 50 milliseconds.
+
+ _Implementation Permissions_
+
+21
+Implementations are permitted to support only smalls that are a power of
+two. In particular, all decimal fixed point type declarations can be
+disallowed. Note however that conformance with the Information Systems
+Annex requires support for decimal smalls, and decimal fixed point type
+declarations with digits up to at least 18.
+
+21.a
+ Implementation Note: The accuracy requirements for
+ multiplication, division, and conversion (see *note G.2.1::,
+ "*note G.2.1:: Model of Floating Point Arithmetic") are such
+ that support for arbitrary smalls should be practical without
+ undue implementation effort. Therefore, implementations
+ should support fixed point types with arbitrary values for
+ small (within reason). One reasonable limitation would be to
+ limit support to fixed point types that can be converted to
+ the most precise floating point type without loss of precision
+ (so that Fixed_IO is implementable in terms of Float_IO).
+
+ NOTES
+
+22
+ 41 The base range of an ordinary fixed point type need not include
+ the specified bounds themselves so that the range specification can
+ be given in a natural way, such as:
+
+23
+ type Fraction is delta 2.0**(-15) range -1.0 .. 1.0;
+
+
+24
+ With 2's complement hardware, such a type could have a signed
+ 16-bit representation, using 1 bit for the sign and 15 bits for
+ fraction, resulting in a base range of -1.0 .. 1.0-2.0**(-15).
+
+ _Examples_
+
+25
+Examples of fixed point types and subtypes:
+
+26
+ type Volt is delta 0.125 range 0.0 .. 255.0;
+
+27
+ -- A pure fraction which requires all the available
+ -- space in a word can be declared as the type Fraction:
+ type Fraction is delta System.Fine_Delta range -1.0 .. 1.0;
+ -- Fraction'Last = 1.0 - System.Fine_Delta
+
+28
+ type Money is delta 0.01 digits 15; -- decimal fixed point
+ subtype Salary is Money digits 10;
+ -- Money'Last = 10.0**13 - 0.01, Salary'Last = 10.0**8 - 0.01
+
+ _Inconsistencies With Ada 83_
+
+28.a
+ In Ada 95, S'Small always equals S'Base'Small, so if an
+ implementation chooses a small for a fixed point type smaller
+ than required by the delta, the value of S'Small in Ada 95
+ might not be the same as it was in Ada 83.
+
+ _Extensions to Ada 83_
+
+28.b/3
+ {AI05-0005-1AI05-0005-1} Decimal fixed point types are new,
+ though their capabilities are essentially similar to that
+ available in Ada 83 with a fixed point type whose small equals
+ its delta and both are a power of 10. However, in the
+ Information Systems Annex, additional requirements are placed
+ on the support of decimal fixed point types (e.g. a minimum
+ of 18 digits of precision).
+
+ _Wording Changes from Ada 83_
+
+28.c
+ The syntax rules for fixed_point_constraint and
+ fixed_accuracy_definition are removed. The syntax rule for
+ fixed_point_definition is new. A syntax rule for
+ delta_constraint is included in the Obsolescent features (to
+ be compatible with Ada 83's fixed_point_constraint).
+
+ _Wording Changes from Ada 95_
+
+28.d/2
+ {AI95-00100-01AI95-00100-01} Added wording to define the
+ machine numbers of fixed point types; this is needed by the
+ static evaluation rules.
+
+\1f
+File: aarm2012.info, Node: 3.5.10, Prev: 3.5.9, Up: 3.5
+
+3.5.10 Operations of Fixed Point Types
+--------------------------------------
+
+ _Static Semantics_
+
+1
+The following attributes are defined for every fixed point subtype S:
+
+2/1
+S'Small
+ {8652/00058652/0005} {AI95-00054-01AI95-00054-01} S'Small
+ denotes the small of the type of S. The value of this
+ attribute is of the type universal_real. Small may be
+ specified for nonderived ordinary fixed point types via
+ an attribute_definition_clause (*note 13.3: S0309.) (see
+ *note 13.3::); the expression of such a clause shall be
+ static.
+
+2.a/3
+ Aspect Description for Small: Scale factor for a fixed point
+ type.
+
+3
+S'Delta
+ S'Delta denotes the delta of the fixed point subtype S.
+ The value of this attribute is of the type
+ universal_real.
+
+3.a
+ Reason: The delta is associated with the subtype as opposed to
+ the type, because of the possibility of an (obsolescent)
+ delta_constraint.
+
+4
+S'Fore
+ S'Fore yields the minimum number of characters needed
+ before the decimal point for the decimal representation
+ of any value of the subtype S, assuming that the
+ representation does not include an exponent, but includes
+ a one-character prefix that is either a minus sign or a
+ space. (This minimum number does not include superfluous
+ zeros or underlines, and is at least 2.) The value of
+ this attribute is of the type universal_integer.
+
+5
+S'Aft
+ S'Aft yields the number of decimal digits needed after
+ the decimal point to accommodate the delta of the subtype
+ S, unless the delta of the subtype S is greater than 0.1,
+ in which case the attribute yields the value one.
+ [(S'Aft is the smallest positive integer N for which
+ (10**N)*S'Delta is greater than or equal to one.)] The
+ value of this attribute is of the type universal_integer.
+
+6
+The following additional attributes are defined for every decimal fixed
+point subtype S:
+
+7
+S'Digits
+ S'Digits denotes the digits of the decimal fixed point
+ subtype S, which corresponds to the number of decimal
+ digits that are representable in objects of the subtype.
+ The value of this attribute is of the type
+ universal_integer. Its value is determined as follows:
+
+8
+ * For a first subtype or a subtype defined by a
+ subtype_indication with a digits_constraint, the
+ digits is the value of the expression given after
+ the reserved word digits;
+
+9
+ * For a subtype defined by a subtype_indication
+ without a digits_constraint, the digits of the
+ subtype is the same as that of the subtype denoted
+ by the subtype_mark in the subtype_indication.
+
+9.a
+ Implementation Note: Although a decimal subtype can be both
+ range-constrained and digits-constrained, the digits
+ constraint is intended to control the Size attribute of the
+ subtype. For decimal types, Size can be important because
+ input/output of decimal types is so common.
+
+10
+ * The digits of a base subtype is the largest integer
+ D such that the range -(10**D-1)*delta ..
+ +(10**D-1)*delta is included in the base range of
+ the type.
+
+11
+S'Scale
+ S'Scale denotes the scale of the subtype S, defined as
+ the value N such that S'Delta = 10.0**(-N). [The scale
+ indicates the position of the point relative to the
+ rightmost significant digits of values of subtype S.] The
+ value of this attribute is of the type universal_integer.
+
+11.a
+ Ramification: S'Scale is negative if S'Delta is greater than
+ one. By contrast, S'Aft is always positive.
+
+12
+S'Round
+ S'Round denotes a function with the following
+ specification:
+
+13
+ function S'Round(X : universal_real)
+ return S'Base
+
+14
+ The function returns the value obtained by rounding X
+ (away from 0, if X is midway between two values of the
+ type of S).
+
+ NOTES
+
+15
+ 42 All subtypes of a fixed point type will have the same value for
+ the Delta attribute, in the absence of delta_constraints (see *note
+ J.3::).
+
+16
+ 43 S'Scale is not always the same as S'Aft for a decimal subtype;
+ for example, if S'Delta = 1.0 then S'Aft is 1 while S'Scale is 0.
+
+17
+ 44 The predefined operations of a fixed point type include the
+ assignment operation, qualification, the membership tests, and
+ explicit conversion to and from other numeric types. They also
+ include the relational operators and the following predefined
+ arithmetic operators: the binary and unary adding operators - and
+ +, multiplying operators, and the unary operator abs.
+
+18
+ 45 As for all types, objects of a fixed point type have Size and
+ Address attributes (see *note 13.3::). Other attributes of fixed
+ point types are defined in *note A.5.4::.
+
+ _Wording Changes from Ada 95_
+
+18.a/2
+ {8652/00058652/0005} {AI95-00054-01AI95-00054-01} Corrigendum:
+ Clarified that small may be specified only for ordinary fixed
+ point types.
+
+\1f
+File: aarm2012.info, Node: 3.6, Next: 3.7, Prev: 3.5, Up: 3
+
+3.6 Array Types
+===============
+
+1
+An array object is a composite object consisting of components which all
+have the same subtype. The name for a component of an array uses one or
+more index values belonging to specified discrete types. The value of
+an array object is a composite value consisting of the values of the
+components.
+
+ _Syntax_
+
+2
+ array_type_definition ::=
+ unconstrained_array_definition | constrained_array_definition
+
+3
+ unconstrained_array_definition ::=
+ array(index_subtype_definition {, index_subtype_definition}) of
+ component_definition
+
+4
+ index_subtype_definition ::= subtype_mark range <>
+
+5
+ constrained_array_definition ::=
+ array (discrete_subtype_definition {,
+ discrete_subtype_definition}) of component_definition
+
+6
+ discrete_subtype_definition ::= discrete_subtype_indication | range
+
+7/2
+ {AI95-00230-01AI95-00230-01} {AI95-00406-01AI95-00406-01}
+ component_definition ::=
+ [aliased] subtype_indication
+ | [aliased] access_definition
+
+ _Name Resolution Rules_
+
+8
+For a discrete_subtype_definition that is a range, the range shall
+resolve to be of some specific discrete type[; which discrete type shall
+be determined without using any context other than the bounds of the
+range itself (plus the preference for root_integer -- see *note 8.6::).]
+
+ _Legality Rules_
+
+9
+Each index_subtype_definition or discrete_subtype_definition in an
+array_type_definition defines an index subtype; its type (the index
+type) shall be discrete.
+
+9.a
+ Discussion: An index is a discrete quantity used to select
+ along a given dimension of an array. A component is selected
+ by specifying corresponding values for each of the indices.
+
+10
+The subtype defined by the subtype_indication of a component_definition
+(the component subtype) shall be a definite subtype.
+
+10.a
+ Ramification: This applies to all uses of
+ component_definition, including in record_type_definitions and
+ protected_definitions.
+
+11/2
+This paragraph was deleted.{AI95-00363-01AI95-00363-01}
+
+ _Static Semantics_
+
+12
+An array is characterized by the number of indices (the dimensionality
+of the array), the type and position of each index, the lower and upper
+bounds for each index, and the subtype of the components. The order of
+the indices is significant.
+
+13
+A one-dimensional array has a distinct component for each possible index
+value. A multidimensional array has a distinct component for each
+possible sequence of index values that can be formed by selecting one
+value for each index position (in the given order). The possible values
+for a given index are all the values between the lower and upper bounds,
+inclusive; this range of values is called the index range. The bounds
+of an array are the bounds of its index ranges. The length of a
+dimension of an array is the number of values of the index range of the
+dimension (zero for a null range). The length of a one-dimensional
+array is the length of its only dimension.
+
+14
+An array_type_definition defines an array type and its first subtype.
+For each object of this array type, the number of indices, the type and
+position of each index, and the subtype of the components are as in the
+type definition[; the values of the lower and upper bounds for each
+index belong to the corresponding index subtype of its type, except for
+null arrays (see *note 3.6.1::)].
+
+15
+An unconstrained_array_definition defines an array type with an
+unconstrained first subtype. Each index_subtype_definition (*note 3.6:
+S0053.) defines the corresponding index subtype to be the subtype
+denoted by the subtype_mark (*note 3.2.2: S0028.). [ The compound
+delimiter <> (called a box) of an index_subtype_definition stands for an
+undefined range (different objects of the type need not have the same
+bounds).]
+
+16
+A constrained_array_definition defines an array type with a constrained
+first subtype. Each discrete_subtype_definition (*note 3.6: S0055.)
+defines the corresponding index subtype, as well as the corresponding
+index range for the constrained first subtype. The constraint of the
+first subtype consists of the bounds of the index ranges.
+
+16.a/3
+ Discussion: {AI05-0005-1AI05-0005-1} Although there is no
+ nameable unconstrained array subtype in this case, the
+ predefined slicing and concatenation operations can operate on
+ and yield values that do not necessarily belong to the first
+ array subtype. This is also true for Ada 83.
+
+17
+The discrete subtype defined by a discrete_subtype_definition (*note
+3.6: S0055.) is either that defined by the subtype_indication (*note
+3.2.2: S0027.), or a subtype determined by the range as follows:
+
+18
+ * If the type of the range resolves to root_integer, then the
+ discrete_subtype_definition defines a subtype of the predefined
+ type Integer with bounds given by a conversion to Integer of the
+ bounds of the range;
+
+18.a
+ Reason: This ensures that indexing over the discrete subtype
+ can be performed with regular Integers, rather than only
+ universal_integers.
+
+18.b
+ Discussion: We considered doing this by simply creating a
+ "preference" for Integer when resolving the range. However,
+ this can introduce Beaujolais effects when the
+ simple_expressions involve calls on functions visible due to
+ use clauses.
+
+19
+ * Otherwise, the discrete_subtype_definition defines a subtype of the
+ type of the range, with the bounds given by the range.
+
+20
+The component_definition of an array_type_definition defines the nominal
+subtype of the components. If the reserved word aliased appears in the
+component_definition, then each component of the array is aliased (see
+*note 3.10::).
+
+ _Dynamic Semantics_
+
+21
+The elaboration of an array_type_definition creates the array type and
+its first subtype, and consists of the elaboration of any
+discrete_subtype_definition (*note 3.6: S0055.)s and the
+component_definition (*note 3.6: S0056.).
+
+22/2
+{8652/00028652/0002} {AI95-00171-01AI95-00171-01}
+{AI95-00230-01AI95-00230-01} The elaboration of a
+discrete_subtype_definition that does not contain any per-object
+expressions creates the discrete subtype, and consists of the
+elaboration of the subtype_indication (*note 3.2.2: S0027.) or the
+evaluation of the range. The elaboration of a
+discrete_subtype_definition that contains one or more per-object
+expressions is defined in *note 3.8::. The elaboration of a
+component_definition (*note 3.6: S0056.) in an array_type_definition
+(*note 3.6: S0051.) consists of the elaboration of the
+subtype_indication (*note 3.2.2: S0027.) or access_definition. The
+elaboration of any discrete_subtype_definition (*note 3.6: S0055.)s and
+the elaboration of the component_definition (*note 3.6: S0056.) are
+performed in an arbitrary order.
+
+ _Static Semantics_
+
+22.1/3
+{AI05-0228-1AI05-0228-1} For an array type with a scalar component type,
+the following language-defined representation aspect may be specified
+with an aspect_specification (see *note 13.1.1::):
+
+22.2/3
+Default_Component_Value
+ This aspect shall be specified by a static expression,
+ and that expression shall be explicit, even if the aspect
+ has a boolean type. Default_Component_Value shall be
+ specified only on a full_type_declaration.
+
+22.a/3
+ Reason: The part about requiring an explicit expression is to
+ disallow omitting the value for this aspect, which would
+ otherwise be allowed by the rules of *note 13.1.1::.
+
+22.b/3
+ This is a representation attribute in order to disallow
+ specifying it on a derived type that has inherited primitive
+ subprograms; that is necessary as the sizes of out parameters
+ could be different whether or not a Default_Value is specified
+ (see *note 6.4.1::).
+
+22.c/3
+ Aspect Description for Default_Component_Value: Default value
+ for the components of an array-of-scalar subtype.
+
+22.3/3
+{AI05-0228-1AI05-0228-1} If a derived type with no primitive subprograms
+inherits a boolean Default_Component_Value aspect, the aspect may be
+specified to have any value for the derived type.
+
+22.d/3
+ Reason: This overrides the *note 13.1.1:: rule that says that
+ a boolean aspect with a value True cannot be changed.
+
+ _Name Resolution Rules_
+
+22.4/3
+{AI05-0228-1AI05-0228-1} The expected type for the expression specified
+for the Default_Component_Value aspect is the component type of the
+array type defined by the full_type_declaration on which it appears.
+
+ NOTES
+
+23
+ 46 All components of an array have the same subtype. In
+ particular, for an array of components that are one-dimensional
+ arrays, this means that all components have the same bounds and
+ hence the same length.
+
+24
+ 47 Each elaboration of an array_type_definition creates a distinct
+ array type. A consequence of this is that each object whose
+ object_declaration contains an array_type_definition is of its own
+ unique type.
+
+ _Examples_
+
+25
+Examples of type declarations with unconstrained array definitions:
+
+26
+ type Vector is array(Integer range <>) of Real;
+ type Matrix is array(Integer range <>, Integer range <>) of Real;
+ type Bit_Vector is array(Integer range <>) of Boolean;
+ type Roman is array(Positive range <>) of Roman_Digit; -- see *note 3.5.2::
+
+27
+Examples of type declarations with constrained array definitions:
+
+28
+ type Table is array(1 .. 10) of Integer;
+ type Schedule is array(Day) of Boolean;
+ type Line is array(1 .. Max_Line_Size) of Character;
+
+29
+Examples of object declarations with array type definitions:
+
+30/2
+ {AI95-00433-01AI95-00433-01} Grid : array(1 .. 80, 1 .. 100) of Boolean;
+ Mix : array(Color range Red .. Green) of Boolean;
+ Msg_Table : constant array(Error_Code) of access constant String :=
+ (Too_Big => new String'("Result too big"), Too_Small => ...);
+ Page : array(Positive range <>) of Line := -- an array of arrays
+ (1 | 50 => Line'(1 | Line'Last => '+', others => '-'), -- see *note 4.3.3::
+ 2 .. 49 => Line'(1 | Line'Last => '|', others => ' '));
+ -- Page is constrained by its initial value to (1..50)
+
+ _Extensions to Ada 83_
+
+30.a
+ The syntax rule for component_definition is modified to allow
+ the reserved word aliased.
+
+30.b
+ The syntax rules for unconstrained_array_definition and
+ constrained_array_definition are modified to use
+ component_definition (instead of
+ component_subtype_indication). The effect of this change is
+ to allow the reserved word aliased before the component
+ subtype_indication.
+
+30.c
+ A range in a discrete_subtype_definition may use arbitrary
+ universal expressions for each bound (e.g. -1 .. 3+5),
+ rather than strictly "implicitly convertible" operands. The
+ subtype defined will still be a subtype of Integer.
+
+ _Wording Changes from Ada 83_
+
+30.d
+ We introduce a new syntactic category,
+ discrete_subtype_definition, as distinct from discrete_range.
+ These two constructs have the same syntax, but their semantics
+ are quite different (one defines a subtype, with a preference
+ for Integer subtypes, while the other just selects a subrange
+ of an existing subtype). We use this new syntactic category
+ in for loops and entry families.
+
+30.e
+ The syntax for index_constraint and discrete_range have been
+ moved to their own subclause, since they are no longer used
+ here.
+
+30.f
+ The syntax rule for component_definition (formerly
+ component_subtype_definition) is moved here from RM83-3.7.
+
+ _Extensions to Ada 95_
+
+30.g/2
+ {AI95-00230-01AI95-00230-01} {AI95-00406-01AI95-00406-01}
+ Array components can have an anonymous access type.
+
+30.h/2
+ {AI95-00363-01AI95-00363-01} The prohibition against
+ unconstrained discriminated aliased components has been
+ lifted. It has been replaced by a prohibition against the
+ actual troublemakers: general access discriminant constraints
+ (see *note 3.7.1::).
+
+ _Wording Changes from Ada 95_
+
+30.i/2
+ {8652/00028652/0002} {AI95-00171-01AI95-00171-01} Corrigendum:
+ Added wording to allow the elaboration of per-object
+ constraints for constrained arrays.
+
+ _Extensions to Ada 2005_
+
+30.j/3
+ {AI05-0228-1AI05-0228-1} The new aspect
+ Default_Component_Value allows defining implicit initial
+ values (see *note 3.3.1::) for arrays of scalar types.
+
+* Menu:
+
+* 3.6.1 :: Index Constraints and Discrete Ranges
+* 3.6.2 :: Operations of Array Types
+* 3.6.3 :: String Types
+
+\1f
+File: aarm2012.info, Node: 3.6.1, Next: 3.6.2, Up: 3.6
+
+3.6.1 Index Constraints and Discrete Ranges
+-------------------------------------------
+
+1
+An index_constraint determines the range of possible values for every
+index of an array subtype, and thereby the corresponding array bounds.
+
+ _Syntax_
+
+2
+ index_constraint ::= (discrete_range {, discrete_range})
+
+3
+ discrete_range ::= discrete_subtype_indication | range
+
+ _Name Resolution Rules_
+
+4
+The type of a discrete_range is the type of the subtype defined by the
+subtype_indication, or the type of the range. For an index_constraint,
+each discrete_range shall resolve to be of the type of the corresponding
+index.
+
+4.a
+ Discussion: In Ada 95, index_constraints only appear in a
+ subtype_indication; they no longer appear in
+ constrained_array_definitions.
+
+ _Legality Rules_
+
+5
+An index_constraint shall appear only in a subtype_indication whose
+subtype_mark denotes either an unconstrained array subtype, or an
+unconstrained access subtype whose designated subtype is an
+unconstrained array subtype; in either case, the index_constraint shall
+provide a discrete_range for each index of the array type.
+
+ _Static Semantics_
+
+6
+A discrete_range defines a range whose bounds are given by the range, or
+by the range of the subtype defined by the subtype_indication.
+
+ _Dynamic Semantics_
+
+7
+An index_constraint is compatible with an unconstrained array subtype if
+and only if the index range defined by each discrete_range is compatible
+(see *note 3.5::) with the corresponding index subtype. If any of the
+discrete_ranges defines a null range, any array thus constrained is a
+null array, having no components. An array value satisfies an
+index_constraint if at each index position the array value and the
+index_constraint have the same index bounds.
+
+7.a
+ Ramification: There is no need to define compatibility with a
+ constrained array subtype, because one is not allowed to
+ constrain it again.
+
+8
+The elaboration of an index_constraint consists of the evaluation of the
+discrete_range(s), in an arbitrary order. The evaluation of a
+discrete_range consists of the elaboration of the subtype_indication or
+the evaluation of the range.
+
+ NOTES
+
+9
+ 48 The elaboration of a subtype_indication consisting of a
+ subtype_mark followed by an index_constraint checks the
+ compatibility of the index_constraint with the subtype_mark (see
+ *note 3.2.2::).
+
+10
+ 49 Even if an array value does not satisfy the index constraint of
+ an array subtype, Constraint_Error is not raised on conversion to
+ the array subtype, so long as the length of each dimension of the
+ array value and the array subtype match. See *note 4.6::.
+
+ _Examples_
+
+11
+Examples of array declarations including an index constraint:
+
+12
+ Board : Matrix(1 .. 8, 1 .. 8); -- see *note 3.6::
+ Rectangle : Matrix(1 .. 20, 1 .. 30);
+ Inverse : Matrix(1 .. N, 1 .. N); -- N need not be static
+
+13
+ Filter : Bit_Vector(0 .. 31);
+
+14
+Example of array declaration with a constrained array subtype:
+
+15
+ My_Schedule : Schedule; -- all arrays of type Schedule have the same bounds
+
+16
+Example of record type with a component that is an array:
+
+17
+ type Var_Line(Length : Natural) is
+ record
+ Image : String(1 .. Length);
+ end record;
+
+18
+ Null_Line : Var_Line(0); -- Null_Line.Image is a null array
+
+ _Extensions to Ada 83_
+
+18.a
+ We allow the declaration of a variable with a nominally
+ unconstrained array subtype, so long as it has an
+ initialization expression to determine its bounds.
+
+ _Wording Changes from Ada 83_
+
+18.b
+ We have moved the syntax for index_constraint and
+ discrete_range here since they are no longer used in
+ constrained_array_definitions. We therefore also no longer
+ have to describe the (special) semantics of index_constraints
+ and discrete_ranges that appear in
+ constrained_array_definitions.
+
+18.c
+ The rules given in RM83-3.6.1(5,7-10), which define the bounds
+ of an array object, are redundant with rules given elsewhere,
+ and so are not repeated here. RM83-3.6.1(6), which requires
+ that the (nominal) subtype of an array variable be
+ constrained, no longer applies, so long as the variable is
+ explicitly initialized.
+
+\1f
+File: aarm2012.info, Node: 3.6.2, Next: 3.6.3, Prev: 3.6.1, Up: 3.6
+
+3.6.2 Operations of Array Types
+-------------------------------
+
+ _Legality Rules_
+
+1
+[The argument N used in the attribute_designators for the N-th dimension
+of an array shall be a static expression of some integer type.] The
+value of N shall be positive (nonzero) and no greater than the
+dimensionality of the array.
+
+ _Static Semantics_
+
+2/1
+{8652/00068652/0006} {AI95-00030-01AI95-00030-01} The following
+attributes are defined for a prefix A that is of an array type [(after
+any implicit dereference)], or denotes a constrained array subtype:
+
+2.a
+ Ramification: These attributes are not defined if A is a
+ subtype-mark for an access-to-array subtype. They are defined
+ (by implicit dereference) for access-to-array values.
+
+3
+A'First
+ A'First denotes the lower bound of the first index range;
+ its type is the corresponding index type.
+
+4
+A'First(N)
+ A'First(N) denotes the lower bound of the N-th index
+ range; its type is the corresponding index type.
+
+5
+A'Last
+ A'Last denotes the upper bound of the first index range;
+ its type is the corresponding index type.
+
+6
+A'Last(N)
+ A'Last(N) denotes the upper bound of the N-th index
+ range; its type is the corresponding index type.
+
+7
+A'Range
+ A'Range is equivalent to the range A'First .. A'Last,
+ except that the prefix A is only evaluated once.
+
+8
+A'Range(N)
+ A'Range(N) is equivalent to the range A'First(N) ..
+ A'Last(N), except that the prefix A is only evaluated
+ once.
+
+9
+A'Length
+ A'Length denotes the number of values of the first index
+ range (zero for a null range); its type is
+ universal_integer.
+
+10
+A'Length(N)
+ A'Length(N) denotes the number of values of the N-th
+ index range (zero for a null range); its type is
+ universal_integer.
+
+ _Implementation Advice_
+
+11/3
+{AI05-0229-1AI05-0229-1} An implementation should normally represent
+multidimensional arrays in row-major order, consistent with the notation
+used for multidimensional array aggregates (see *note 4.3.3::).
+However, if convention Fortran is specified for a multidimensional array
+type, then column-major order should be used instead (see *note B.5::,
+"*note B.5:: Interfacing with Fortran").
+
+11.a/2
+ Implementation Advice: Multidimensional arrays should be
+ represented in row-major order, unless the array has
+ convention Fortran.
+
+ NOTES
+
+12
+ 50 The attribute_references A'First and A'First(1) denote the same
+ value. A similar relation exists for the attribute_references
+ A'Last, A'Range, and A'Length. The following relation is satisfied
+ (except for a null array) by the above attributes if the index type
+ is an integer type:
+
+13
+ A'Length(N) = A'Last(N) - A'First(N) + 1
+
+14
+ 51 An array type is limited if its component type is limited (see
+ *note 7.5::).
+
+15
+ 52 The predefined operations of an array type include the
+ membership tests, qualification, and explicit conversion. If the
+ array type is not limited, they also include assignment and the
+ predefined equality operators. For a one-dimensional array type,
+ they include the predefined concatenation operators (if nonlimited)
+ and, if the component type is discrete, the predefined relational
+ operators; if the component type is boolean, the predefined logical
+ operators are also included.
+
+16/2
+ 53 {AI95-00287-01AI95-00287-01} A component of an array can be
+ named with an indexed_component. A value of an array type can be
+ specified with an array_aggregate. For a one-dimensional array
+ type, a slice of the array can be named; also, string literals are
+ defined if the component type is a character type.
+
+ _Examples_
+
+17
+Examples (using arrays declared in the examples of subclause *note
+3.6.1::):
+
+18
+ -- Filter'First = 0 Filter'Last = 31 Filter'Length = 32
+ -- Rectangle'Last(1) = 20 Rectangle'Last(2) = 30
+
+\1f
+File: aarm2012.info, Node: 3.6.3, Prev: 3.6.2, Up: 3.6
+
+3.6.3 String Types
+------------------
+
+ _Static Semantics_
+
+1
+A one-dimensional array type whose component type is a character type is
+called a string type.
+
+2/2
+{AI95-00285-01AI95-00285-01} [There are three predefined string types,
+String, Wide_String, and Wide_Wide_String, each indexed by values of the
+predefined subtype Positive; these are declared in the visible part of
+package Standard:]
+
+3
+ [subtype Positive is Integer range 1 .. Integer'Last;
+
+4/2
+ {AI95-00285-01AI95-00285-01} type String is array(Positive range <>) of Character;
+ type Wide_String is array(Positive range <>) of Wide_Character;
+ type Wide_Wide_String is array(Positive range <>) of Wide_Wide_Character;
+ ]
+
+ NOTES
+
+5
+ 54 String literals (see *note 2.6:: and *note 4.2::) are defined
+ for all string types. The concatenation operator & is predefined
+ for string types, as for all nonlimited one-dimensional array
+ types. The ordering operators <, <=, >, and >= are predefined for
+ string types, as for all one-dimensional discrete array types;
+ these ordering operators correspond to lexicographic order (see
+ *note 4.5.2::).
+
+ _Examples_
+
+6
+Examples of string objects:
+
+7
+ Stars : String(1 .. 120) := (1 .. 120 => '*' );
+ Question : constant String := "How many characters?";
+ -- Question'First = 1, Question'Last = 20
+ -- Question'Length = 20 (the number of characters)
+
+8
+ Ask_Twice : String := Question & Question; -- constrained to (1..40)
+ Ninety_Six : constant Roman := "XCVI"; -- see *note 3.5.2:: and *note 3.6::
+
+ _Inconsistencies With Ada 83_
+
+8.a
+ The declaration of Wide_String in Standard hides a use-visible
+ declaration with the same defining_identifier. In rare cases,
+ this might result in an inconsistency between Ada 83 and Ada
+ 95.
+
+ _Incompatibilities With Ada 83_
+
+8.b
+ Because both String and Wide_String are always directly
+ visible, an expression like
+
+8.c
+ "a" < "bc"
+
+8.d
+ is now ambiguous, whereas in Ada 83 both string literals could
+ be resolved to type String.
+
+ _Extensions to Ada 83_
+
+8.e
+ The type Wide_String is new (though it was approved by ARG for
+ Ada 83 compilers as well).
+
+ _Wording Changes from Ada 83_
+
+8.f
+ We define the term string type as a natural analogy to the
+ term character type.
+
+ _Inconsistencies With Ada 95_
+
+8.g/2
+ {AI95-00285-01AI95-00285-01} The declaration of
+ Wide_Wide_String in Standard hides a use-visible declaration
+ with the same defining_identifier. In the (very) unlikely
+ event that an Ada 95 program had depended on such a
+ use-visible declaration, and the program remains legal after
+ the substitution of Standard.Wide_Wide_String, the meaning of
+ the program will be different.
+
+ _Extensions to Ada 95_
+
+8.h/2
+ {AI95-00285-01AI95-00285-01} The type Wide_Wide_String is new.
+
+\1f
+File: aarm2012.info, Node: 3.7, Next: 3.8, Prev: 3.6, Up: 3
+
+3.7 Discriminants
+=================
+
+1/2
+{AI95-00251-01AI95-00251-01} {AI95-00326-01AI95-00326-01} [ A composite
+type (other than an array or interface type) can have discriminants,
+which parameterize the type. A known_discriminant_part specifies the
+discriminants of a composite type. A discriminant of an object is a
+component of the object, and is either of a discrete type or an access
+type. An unknown_discriminant_part in the declaration of a view of a
+type specifies that the discriminants of the type are unknown for the
+given view; all subtypes of such a view are indefinite subtypes.]
+
+1.a/2
+ Glossary entry: A discriminant is a parameter for a composite
+ type. It can control, for example, the bounds of a component
+ of the type if the component is an array. A discriminant for
+ a task type can be used to pass data to a task of the type
+ upon creation.
+
+1.b/2
+ Discussion: {AI95-00114-01AI95-00114-01} A view of a type, and
+ all subtypes of the view, have unknown discriminants when the
+ number or names of the discriminants, if any, are unknown at
+ the point of the type declaration for the view. A
+ discriminant_part of (<>) is used to indicate unknown
+ discriminants.
+
+ _Language Design Principles_
+
+1.c/2
+ {AI95-00402-01AI95-00402-01} When an access discriminant is
+ initialized at the time of object creation with an allocator
+ of an anonymous type, the allocated object and the object with
+ the discriminant are tied together for their lifetime. They
+ should be allocated out of the same storage pool, and then at
+ the end of the lifetime of the enclosing object, finalized and
+ reclaimed together. In this case, the allocated object is
+ called a coextension (see *note 3.10.2::).
+
+1.d/2
+ Discussion: The above principle when applied to a nonlimited
+ type implies that such an object may be copied only to a
+ shorter-lived object, because attempting to assign it to a
+ longer-lived object would fail because the access
+ discriminants would not match. In a copy, the lifetime
+ connection between the enclosing object and the allocated
+ object does not exist. The allocated object is tied in the
+ above sense only to the original object. Other copies have
+ only secondary references to it.
+
+1.e/2
+ Note that when an allocator appears as a constraint on an
+ access discriminant in a subtype_indication that is elaborated
+ independently from object creation, no such connection exists.
+ For example, if a named constrained subtype is declared via
+ "subtype Constr is Rec(Acc_Discrim => new T);" or if such an
+ allocator appears in the subtype_indication for a component,
+ the allocator is evaluated when the subtype_indication is
+ elaborated, and hence its lifetime is typically longer than
+ the objects or components that will later be subject to the
+ constraint. In these cases, the allocated object should not
+ be reclaimed until the subtype_indication goes out of scope.
+
+ _Syntax_
+
+2
+ discriminant_part ::= unknown_discriminant_part |
+ known_discriminant_part
+
+3
+ unknown_discriminant_part ::= (<>)
+
+4
+ known_discriminant_part ::=
+ (discriminant_specification {; discriminant_specification})
+
+5/2
+ {AI95-00231-01AI95-00231-01} discriminant_specification ::=
+ defining_identifier_list : [null_exclusion] subtype_mark [:=
+ default_expression]
+ | defining_identifier_list : access_definition [:=
+ default_expression]
+
+6
+ default_expression ::= expression
+
+ _Name Resolution Rules_
+
+7
+The expected type for the default_expression of a
+discriminant_specification is that of the corresponding discriminant.
+
+ _Legality Rules_
+
+8/2
+{8652/00078652/0007} {AI95-00098-01AI95-00098-01}
+{AI95-00251-01AI95-00251-01} A discriminant_part is only permitted in a
+declaration for a composite type that is not an array or interface type
+[(this includes generic formal types)]. A type declared with a
+known_discriminant_part is called a discriminated type, as is a type
+that inherits (known) discriminants.
+
+8.a
+ Implementation Note: Discriminants on array types were
+ considered, but were omitted to ease (existing)
+ implementations.
+
+8.b
+ Discussion: Note that the above definition for "discriminated
+ type" does not include types declared with an
+ unknown_discriminant_part. This seems consistent with Ada 83,
+ where such types (in a generic formal part) would not be
+ considered discriminated types. Furthermore, the full type
+ for a type with unknown discriminants need not even be
+ composite, much less have any discriminants.
+
+8.b.1/1
+ {8652/00078652/0007} {AI95-00098-01AI95-00098-01} On the other
+ hand, unknown_discriminant_parts cannot be applied to type
+ declarations that cannot have a known_discriminant_part.
+ There is no point in having unknown discriminants on a type
+ that can never have discriminants (for instance, a formal
+ modular type), even when these are allowed syntactically.
+
+9/2
+{AI95-00231-01AI95-00231-01} {AI95-00254-01AI95-00254-01} The subtype of
+a discriminant may be defined by an optional null_exclusion and a
+subtype_mark, in which case the subtype_mark shall denote a discrete or
+access subtype, or it may be defined by an access_definition. A
+discriminant that is defined by an access_definition is called an access
+discriminant and is of an anonymous access type.
+
+9.a/2
+ This paragraph was deleted.{AI95-00230-01AI95-00230-01}
+
+9.b
+ Reason: Note that discriminants of a named access type are not
+ considered "access discriminants." Similarly, "access
+ parameter" only refers to a formal parameter defined by an
+ access_definition.
+
+9.1/3
+{AI95-00402-01AI95-00402-01} {AI05-0214-1AI05-0214-1}
+Default_expressions shall be provided either for all or for none of the
+discriminants of a known_discriminant_part (*note 3.7: S0061.). No
+default_expression (*note 3.7: S0063.)s are permitted in a
+known_discriminant_part (*note 3.7: S0061.) in a declaration of a
+nonlimited tagged type [or a generic formal type].
+
+9.c/2
+ Reason: The all-or-none rule is related to the rule that a
+ discriminant constraint shall specify values for all
+ discriminants. One could imagine a different rule that
+ allowed a constraint to specify only some of the
+ discriminants, with the others provided by default. Having
+ defaults for discriminants has a special significance -- it
+ allows objects of the type to be unconstrained, with the
+ discriminants alterable as part of assigning to the object.
+
+9.d/3
+ {AI05-0214-1AI05-0214-1} Defaults for discriminants of tagged
+ types are disallowed so that every object of a nonlimited
+ tagged type is constrained, either by an explicit constraint,
+ or by its initial discriminant values. This substantially
+ simplifies the semantic rules and the implementation of
+ inherited dispatching operations. We don't need this rule for
+ limited tagged types, as the discriminants of such objects
+ cannot be changed after the object is created in any case --
+ no full-object assignment is supported, and that is required
+ to change discriminant values. For generic formal types, the
+ restriction simplifies the type matching rules. If one simply
+ wants a "default" value for the discriminants, a constrained
+ subtype can be declared for future use.
+
+10/3
+{AI95-00230-01AI95-00230-01} {AI95-00402-01AI95-00402-01}
+{AI95-00419-01AI95-00419-01} {AI05-0063-1AI05-0063-1} A
+discriminant_specification for an access discriminant may have a
+default_expression only in the declaration for an immutably limited type
+(see *note 7.5::). In addition to the places where Legality Rules
+normally apply (see *note 12.3::), this rule applies also in the private
+part of an instance of a generic unit.
+
+10.a/3
+ Discussion: This rule implies that a type can have a default
+ for an access discriminant if the type is limited, but not if
+ the only reason it's limited is because of a limited
+ component. Compare the definition of limited type and
+ immutably limited type in *note 7.5::.
+
+10.b/3
+ Ramification: A (nonformal) limited private type can always
+ have a default for an access discriminant, because having the
+ default itself makes the type immutably limited. Such a
+ private type must necessarily have a full type with the same
+ access discriminant with a default, and thus the full type
+ will always be immutably limited (if legal).
+
+10.c/2
+ Reason: {AI95-00230-01AI95-00230-01} We considered the
+ following rules for access discriminants:
+
+10.d
+ * If a type has an access discriminant, this automatically
+ makes it limited, just like having a limited component
+ automatically makes a type limited. This was rejected
+ because it decreases program readability, and because it
+ seemed error prone (two bugs in a previous version of the
+ RM9X were attributable to this rule).
+
+10.e/2
+ * A type with an access discriminant shall be limited.
+ This is equivalent to the rule we actually chose for Ada
+ 95, except that it allows a type to have an access
+ discriminant if it is limited just because of a limited
+ component. For example, any record containing a task
+ would be allowed to have an access discriminant, whereas
+ the actual rule requires "limited record". This rule was
+ also rejected due to readability concerns, and because
+ would interact badly with the rules for limited types
+ that "become nonlimited".
+
+10.e.1/3
+ * {AI05-0063-1AI05-0063-1} A type may have an access
+ discriminant if it is an immutably limited type. This
+ was the rule chosen for Ada 95.
+
+10.f/2
+ * Any type may have an access discriminant. For nonlimited
+ type, there is no special accessibility for access
+ discriminants; they're the same as any other anonymous
+ access component. For a limited type, they have the
+ special accessibility of Ada 95. However, this doesn't
+ work because a limited partial view can have a nonlimited
+ full view -- giving the two views different
+ accessibility.
+
+10.f.1/3
+ * {AI05-0063-1AI05-0063-1} Any type may have an access
+ discriminant, as above. However, special accessibility
+ rules only apply to types that are immutably limited
+ (task, protected, and explicitly limited records).
+ However, this breaks privacy; worse, Legality Rules
+ depend on the definition of accessibility.
+
+10.f.2/3
+ * {AI05-0063-1AI05-0063-1} Any type may have an access
+ discriminant, as above. Limited types have special
+ accessibility, while nonlimited types have normal
+ accessibility. However, a limited partial view with an
+ access discriminant can only be completed by an immutably
+ limited type. That prevents accessibility from changing.
+ A runtime accessibility check is required on generic
+ formal types with access discriminants. However,
+ changing between limited and nonlimited types would have
+ far-reaching consequences for access discriminants --
+ which is uncomfortable.
+
+10.g/2
+ * Any type may have an access discriminant. All types have
+ special accessibility. This was considered early during
+ the Ada 9X process, but was dropped for "unpleasant
+ complexities", which unfortunately aren't recorded. It
+ does seem that an accessibility check would be needed on
+ assignment of such a type, to avoid copying an object
+ with a discriminant pointing to a local object into a
+ more global object (and thus creating a dangling
+ pointer).
+
+10.h/2
+ * Any type may have an access discriminant, but access
+ discriminants cannot have defaults. All types have
+ special accessibility. This gets rid of the problems on
+ assignment (you couldn't change such a discriminant), but
+ it would be horribly incompatible with Ada 95.
+
+10.h.1/3
+ * {AI05-0063-1AI05-0063-1} Any type may have an access
+ discriminant, but access discriminants may have defaults
+ only if they are of an immutably limited type. This is
+ the rule chosen for Ada 2005, as it is not incompatible,
+ and it doesn't require weird accessibility checks.
+
+11/2
+This paragraph was deleted.{AI95-00402-01AI95-00402-01}
+
+12
+For a type defined by a derived_type_definition, if a
+known_discriminant_part is provided in its declaration, then:
+
+13
+ * The parent subtype shall be constrained;
+
+14
+ * If the parent type is not a tagged type, then each discriminant of
+ the derived type shall be used in the constraint defining the
+ parent subtype;
+
+14.a
+ Implementation Note: This ensures that the new discriminant
+ can share storage with an existing discriminant.
+
+15
+ * If a discriminant is used in the constraint defining the parent
+ subtype, the subtype of the discriminant shall be statically
+ compatible (see *note 4.9.1::) with the subtype of the
+ corresponding parent discriminant.
+
+15.a
+ Reason: This ensures that on conversion (or extension via an
+ extension aggregate) to a distantly related type, if the
+ discriminants satisfy the target type's requirements they
+ satisfy all the intermediate types' requirements as well.
+
+15.b
+ Ramification: There is no requirement that the new
+ discriminant have the same (or any) default_expression as the
+ parent's discriminant.
+
+16/3
+This paragraph was deleted.{AI05-0102-1AI05-0102-1}
+
+16.a/3
+ This paragraph was deleted.
+
+ _Static Semantics_
+
+17
+A discriminant_specification declares a discriminant; the subtype_mark
+denotes its subtype unless it is an access discriminant, in which case
+the discriminant's subtype is the anonymous access-to-variable subtype
+defined by the access_definition.
+
+18
+[For a type defined by a derived_type_definition, each discriminant of
+the parent type is either inherited, constrained to equal some new
+discriminant of the derived type, or constrained to the value of an
+expression.] When inherited or constrained to equal some new
+discriminant, the parent discriminant and the discriminant of the
+derived type are said to correspond. Two discriminants also correspond
+if there is some common discriminant to which they both correspond. A
+discriminant corresponds to itself as well. If a discriminant of a
+parent type is constrained to a specific value by a
+derived_type_definition, then that discriminant is said to be specified
+by that derived_type_definition.
+
+18.a
+ Ramification: The correspondence relationship is transitive,
+ symmetric, and reflexive. That is, if A corresponds to B, and
+ B corresponds to C, then A, B, and C each corresponds to A, B,
+ and C in all combinations.
+
+19
+A constraint that appears within the definition of a discriminated type
+depends on a discriminant of the type if it names the discriminant as a
+bound or discriminant value. A component_definition depends on a
+discriminant if its constraint depends on the discriminant, or on a
+discriminant that corresponds to it.
+
+19.a
+ Ramification: A constraint in a task_body is not considered to
+ depend on a discriminant of the task type, even if it names
+ it. It is only the constraints in the type definition itself
+ that are considered dependents. Similarly for protected
+ types.
+
+20
+A component depends on a discriminant if:
+
+21
+ * Its component_definition depends on the discriminant; or
+
+21.a
+ Ramification: A component does not depend on a discriminant
+ just because its default_expression refers to the
+ discriminant.
+
+22
+ * It is declared in a variant_part that is governed by the
+ discriminant; or
+
+23
+ * It is a component inherited as part of a derived_type_definition,
+ and the constraint of the parent_subtype_indication depends on the
+ discriminant; or
+
+23.a
+ Reason: When the parent subtype depends on a discriminant, the
+ parent part of the derived type is treated like a
+ discriminant-dependent component.
+
+23.b
+ Ramification: Because of this rule, we don't really need to
+ worry about "corresponding" discriminants, since all the
+ inherited components will be discriminant-dependent if there
+ is a new known_discriminant_part whose discriminants are used
+ to constrain the old discriminants.
+
+24
+ * It is a subcomponent of a component that depends on the
+ discriminant.
+
+24.a
+ Reason: The concept of discriminant-dependent (sub)components
+ is primarily used in various rules that disallow renaming or
+ 'Access, or specify that certain discriminant-changing
+ assignments are erroneous. The goal is to allow
+ implementations to move around or change the size of
+ discriminant-dependent subcomponents upon a
+ discriminant-changing assignment to an enclosing object. The
+ above definition specifies that all subcomponents of a
+ discriminant-dependent component or parent part are themselves
+ discriminant-dependent, even though their presence or size
+ does not in fact depend on a discriminant. This is because it
+ is likely that they will move in a discriminant-changing
+ assignment if they are a component of one of several
+ discriminant-dependent parts of the same record.
+
+25
+Each value of a discriminated type includes a value for each component
+of the type that does not depend on a discriminant[; this includes the
+discriminants themselves]. The values of discriminants determine which
+other component values are present in the value of the discriminated
+type.
+
+25.a
+ To be honest: Which values are present might depend on
+ discriminants of some ancestor type that are constrained in an
+ intervening derived_type_definition. That's why we say
+ "values of discriminants" instead of "values of the
+ discriminants" -- a subtle point.
+
+26
+A type declared with a known_discriminant_part is said to have known
+discriminants; its first subtype is unconstrained. A type declared with
+an unknown_discriminant_part is said to have unknown discriminants. A
+type declared without a discriminant_part has no discriminants, unless
+it is a derived type; if derived, such a type has the same sort of
+discriminants (known, unknown, or none) as its parent (or ancestor)
+type. A tagged class-wide type also has unknown discriminants. [Any
+subtype of a type with unknown discriminants is an unconstrained and
+indefinite subtype (see *note 3.2:: and *note 3.3::).]
+
+26.a/2
+ Discussion: {AI95-00114-01AI95-00114-01} An
+ unknown_discriminant_part "(<>)" is only permitted in the
+ declaration of a (generic or nongeneric) private type, private
+ extension, incomplete type, or formal derived type. Hence,
+ only such types, descendants thereof, and class-wide types can
+ have unknown discriminants. An unknown_discriminant_part is
+ used to indicate that the corresponding actual or full type
+ might have discriminants without defaults, or be an
+ unconstrained array subtype. Tagged class-wide types are also
+ considered to have unknown discriminants because discriminants
+ can be added by type extensions, so the total number of
+ discriminants of any given value of a tagged class-wide type
+ is not known at compile time.
+
+26.b/2
+ {AI95-00287-01AI95-00287-01} A subtype with unknown
+ discriminants is indefinite, and hence an object of such a
+ subtype needs explicit initialization. A limited private type
+ with unknown discriminants is "extremely" limited; objects of
+ such a type can be initialized only by subprograms (either
+ procedures with a parameter of the type, or a function
+ returning the type) declared in the package. Subprograms
+ declared elsewhere can operate on and even return the type,
+ but they can only initialize the object by calling
+ (ultimately) a subprogram in the package declaring the type.
+ Such a type is useful for keeping complete control over object
+ creation within the package declaring the type.
+
+26.c
+ A partial view of a type might have unknown discriminants,
+ while the full view of the same type might have known,
+ unknown, or no discriminants.
+
+ _Dynamic Semantics_
+
+27/2
+{AI95-00230-01AI95-00230-01} {AI95-00416-01AI95-00416-01} For an access
+discriminant, its access_definition is elaborated when the value of the
+access discriminant is defined: by evaluation of its default_expression,
+by elaboration of a discriminant_constraint, or by an assignment that
+initializes the enclosing object.
+
+27.a/2
+ Ramification: {AI95-00231-01AI95-00231-01}
+ {AI95-00416-01AI95-00416-01} The conversion of the expression
+ defining the access discriminant to the anonymous access type
+ raises Program_Error for an object created by an allocator of
+ an access type T, if the initial value is an access parameter
+ that designates a view whose accessibility level is deeper
+ than that of T.
+
+ NOTES
+
+28
+ 55 If a discriminated type has default_expressions for its
+ discriminants, then unconstrained variables of the type are
+ permitted, and the values of the discriminants can be changed by an
+ assignment to such a variable. If defaults are not provided for
+ the discriminants, then all variables of the type are constrained,
+ either by explicit constraint or by their initial value; the values
+ of the discriminants of such a variable cannot be changed after
+ initialization.
+
+28.a
+ Discussion: This connection between discriminant defaults and
+ unconstrained variables can be a source of confusion. For Ada
+ 95, we considered various ways to break the connection between
+ defaults and unconstrainedness, but ultimately gave up for
+ lack of a sufficiently simple and intuitive alternative.
+
+28.b
+ An unconstrained discriminated subtype with defaults is called
+ a mutable subtype, and a variable of such a subtype is called
+ a mutable variable, because the discriminants of such a
+ variable can change. There are no mutable arrays (that is,
+ the bounds of an array object can never change), because there
+ is no way in the language to define default values for the
+ bounds. Similarly, there are no mutable class-wide subtypes,
+ because there is no way to define the default tag, and
+ defaults for discriminants are not allowed in the tagged case.
+ Mutable tags would also require a way for the maximum possible
+ size of such a class-wide subtype to be known. (In some
+ implementations, all mutable variables are allocated with the
+ maximum possible size. This approach is appropriate for
+ real-time applications where implicit use of the heap is
+ inappropriate.)
+
+29
+ 56 The default_expression for a discriminant of a type is
+ evaluated when an object of an unconstrained subtype of the type is
+ created.
+
+30
+ 57 Assignment to a discriminant of an object (after its
+ initialization) is not allowed, since the name of a discriminant is
+ a constant; neither assignment_statements nor assignments inherent
+ in passing as an in out or out parameter are allowed. Note however
+ that the value of a discriminant can be changed by assigning to the
+ enclosing object, presuming it is an unconstrained variable.
+
+30.a/2
+ Discussion: {AI95-00114-01AI95-00114-01} An
+ unknown_discriminant_part is permitted only in the declaration
+ of a private type (including generic formal private), private
+ extension, incomplete type, or generic formal derived type.
+ These are the things that will have a corresponding completion
+ or generic actual, which will either define the discriminants,
+ or say there are none. The (<>) indicates that the
+ actual/full subtype might be an indefinite subtype. An
+ unknown_discriminant_part is not permitted in a normal
+ untagged derived type declaration, because there is no
+ separate full type declaration for such a type. Note that
+ (<>) allows unconstrained array bounds; those are somewhat
+ like undefaulted discriminants.
+
+30.b
+ For a derived type, either the discriminants are inherited as
+ is, or completely respecified in a new discriminant_part. In
+ this latter case, each discriminant of the parent type shall
+ be constrained, either to a specific value, or to equal one of
+ the new discriminants. Constraining a parent type's
+ discriminant to equal one of the new discriminants is like a
+ renaming of the discriminant, except that the subtype of the
+ new discriminant can be more restrictive than that of the
+ parent's one. In any case, the new discriminant can share
+ storage with the parent's discriminant.
+
+31
+ 58 A discriminant that is of a named access type is not called an
+ access discriminant; that term is used only for discriminants
+ defined by an access_definition.
+
+ _Examples_
+
+32
+Examples of discriminated types:
+
+33
+ type Buffer(Size : Buffer_Size := 100) is -- see *note 3.5.4::
+ record
+ Pos : Buffer_Size := 0;
+ Value : String(1 .. Size);
+ end record;
+
+34
+ type Matrix_Rec(Rows, Columns : Integer) is
+ record
+ Mat : Matrix(1 .. Rows, 1 .. Columns); -- see *note 3.6::
+ end record;
+
+35
+ type Square(Side : Integer) is new
+ Matrix_Rec(Rows => Side, Columns => Side);
+
+36
+ type Double_Square(Number : Integer) is
+ record
+ Left : Square(Number);
+ Right : Square(Number);
+ end record;
+
+37/3
+ {AI95-00433-01AI95-00433-01} {AI05-0229-1AI05-0229-1} task type Worker(Prio : System.Priority; Buf : access Buffer)
+ with Priority => Prio is -- see *note D.1::
+ -- discriminants used to parameterize the task type (see *note 9.1::)
+ entry Fill;
+ entry Drain;
+ end Worker;
+
+ _Extensions to Ada 83_
+
+37.a
+ The syntax for a discriminant_specification is modified to
+ allow an access discriminant, with a type specified by an
+ access_definition (see *note 3.10::).
+
+37.b/2
+ {AI95-00251-01AI95-00251-01} Discriminants are allowed on all
+ composite types other than array and interface types.
+
+37.c
+ Discriminants may be of an access type.
+
+ _Wording Changes from Ada 83_
+
+37.d
+ Discriminant_parts are not elaborated, though an
+ access_definition is elaborated when the discriminant is
+ initialized.
+
+ _Extensions to Ada 95_
+
+37.e/2
+ {AI95-00230-01AI95-00230-01} {AI95-00402-01AI95-00402-01}
+ {AI95-00416-01AI95-00416-01} Access discriminants (anonymous
+ access types used as a discriminant) can be used on any type
+ allowing discriminants. Defaults aren't allowed on
+ discriminants of nonlimited types, however, so that
+ accessibility problems don't happen on assignment.
+
+37.f/2
+ {AI95-00231-01AI95-00231-01} null_exclusion can be used in the
+ declaration of a discriminant.
+
+ _Wording Changes from Ada 95_
+
+37.g/2
+ {8652/00078652/0007} {AI95-00098-01AI95-00098-01} Corrigendum:
+ The wording was clarified so that types that cannot have
+ discriminants cannot have an unknown_discriminant_part.
+
+37.h/2
+ {AI95-00251-01AI95-00251-01} Added wording to prevent
+ interfaces from having discriminants. We don't want
+ interfaces to have any components.
+
+37.i/2
+ {AI95-00254-01AI95-00254-01} Removed wording which implied or
+ required an access discriminant to have an access-to-object
+ type (anonymous access types can now be access-to-subprogram
+ types as well).
+
+37.j/3
+ {AI95-00326-01AI95-00326-01} {AI05-0299-1AI05-0299-1} Fixed
+ the wording of the introduction to this subclause to reflect
+ that both incomplete and partial views can have unknown
+ discriminants. That was always true, but for some reason this
+ wording specified partial views.
+
+37.k/2
+ {AI95-00419-01AI95-00419-01} Changed the wording to use the
+ new term "explicitly limited record", which makes the intent
+ much clearer (and eliminates confusion with derived types that
+ happen to contain the reserved word limited).
+
+ _Incompatibilities With Ada 2005_
+
+37.l/3
+ {AI05-0063-1AI05-0063-1} Correction: Changed the rules for
+ when access discriminants can have defaults to depend on the
+ new definition for immutably limited types; this will help
+ ensure that unusual corner cases are properly handled. Note
+ that the Ada 2005 rule was unintentionally incompatible with
+ the Ada 95 rule (as enforced by the ACATS); this change brings
+ it back into alignment with actual practice. So there should
+ be no practical incompatibility.
+
+ _Extensions to Ada 2005_
+
+37.m/3
+ {AI05-0214-1AI05-0214-1} A limited tagged type may now have
+ defaults for its discriminants.
+
+ _Wording Changes from Ada 2005_
+
+37.n/3
+ {AI05-0102-1AI05-0102-1} Correction: Moved implicit conversion
+ Legality Rule to *note 8.6::.
+
+* Menu:
+
+* 3.7.1 :: Discriminant Constraints
+* 3.7.2 :: Operations of Discriminated Types
+
+\1f
+File: aarm2012.info, Node: 3.7.1, Next: 3.7.2, Up: 3.7
+
+3.7.1 Discriminant Constraints
+------------------------------
+
+1
+A discriminant_constraint specifies the values of the discriminants for
+a given discriminated type.
+
+ _Language Design Principles_
+
+1.a/3
+ {AI05-0299-1AI05-0299-1} The rules in this subclause are
+ intentionally parallel to those given in *note 4.3.1::, "*note
+ 4.3.1:: Record Aggregates".
+
+ _Syntax_
+
+2
+ discriminant_constraint ::=
+ (discriminant_association {, discriminant_association})
+
+3
+ discriminant_association ::=
+ [discriminant_selector_name {| discriminant_selector_name} =>]
+ expression
+
+4
+ A discriminant_association is said to be named if it has one or
+ more discriminant_selector_names; it is otherwise said to be
+ positional. In a discriminant_constraint, any positional
+ associations shall precede any named associations.
+
+ _Name Resolution Rules_
+
+5
+Each selector_name of a named discriminant_association (*note 3.7.1:
+S0065.) shall resolve to denote a discriminant of the subtype being
+constrained; the discriminants so named are the associated discriminants
+of the named association. For a positional association, the associated
+discriminant is the one whose discriminant_specification (*note 3.7:
+S0062.) occurred in the corresponding position in the
+known_discriminant_part (*note 3.7: S0061.) that defined the
+discriminants of the subtype being constrained.
+
+6
+The expected type for the expression in a discriminant_association is
+that of the associated discriminant(s).
+
+ _Legality Rules_
+
+7/3
+{8652/00088652/0008} {AI95-00168-01AI95-00168-01}
+{AI95-00363-01AI95-00363-01} {AI05-0041-1AI05-0041-1} A
+discriminant_constraint is only allowed in a subtype_indication whose
+subtype_mark denotes either an unconstrained discriminated subtype, or
+an unconstrained access subtype whose designated subtype is an
+unconstrained discriminated subtype. However, in the case of an access
+subtype, a discriminant_constraint (*note 3.7.1: S0064.) is legal only
+if any dereference of a value of the access type is known to be
+constrained (see *note 3.3::). In addition to the places where Legality
+Rules normally apply (see *note 12.3::), these rules apply also in the
+private part of an instance of a generic unit.
+
+7.a.1/2
+ This paragraph was deleted.{8652/00088652/0008}
+ {AI95-00168-01AI95-00168-01} {AI95-00363-01AI95-00363-01}
+
+7.a/2
+ Reason: {AI95-00363-01AI95-00363-01} The second rule is
+ necessary to prevent objects from changing so that they no
+ longer match their constraint. In Ada 95, we attempted to
+ prevent this by banning every case where an aliased object
+ could be unconstrained or be changed by an enclosing
+ assignment. New ways to cause this problem were being
+ discovered frequently, meaning that new rules had to be
+ dreamed up to cover them. Meanwhile, aliased objects and
+ components were getting more and more limited. In Ada 2005,
+ we sweep away all of that cruft and replace it by a simple
+ rule "thou shalt not create an access subtype that can point
+ to an item whose discriminants can be changed by assignment".
+
+7.b/3
+ Discussion: {AI05-0041-1AI05-0041-1} The second rule will only
+ use the indefinite or dereference bullets in the definition of
+ "known to be constrained". The rule is worded in terms of
+ "known to be constrained" in order to capture the special
+ rules that apply in generic bodies (rather than repeating them
+ and getting them subtly wrong).
+
+8
+A named discriminant_association with more than one selector_name is
+allowed only if the named discriminants are all of the same type. A
+discriminant_constraint shall provide exactly one value for each
+discriminant of the subtype being constrained.
+
+9/3
+This paragraph was deleted.{AI05-0102-1AI05-0102-1}
+
+9.a/3
+ Ramification: In addition, *note 8.6:: requires that the
+ expression associated with an access discriminant is
+ convertible (see *note 4.6::) to the anonymous access type.
+ This implies both convertibility of designated types, and
+ static accessibility. This implies that if an object of type
+ T with an access discriminant is created by an allocator for
+ an access type A, then it requires that the type of the
+ expression associated with the access discriminant have an
+ accessibility level that is not statically deeper than that of
+ A. This is to avoid dangling references.
+
+ _Dynamic Semantics_
+
+10
+A discriminant_constraint is compatible with an unconstrained
+discriminated subtype if each discriminant value belongs to the subtype
+of the corresponding discriminant.
+
+10.a
+ Ramification: The "dependent compatibility check" has been
+ eliminated in Ada 95. Any checking on subcomponents is
+ performed when (and if) an object is created.
+
+10.b
+ Discussion: There is no need to define compatibility with a
+ constrained discriminated subtype, because one is not allowed
+ to constrain it again.
+
+11
+A composite value satisfies a discriminant constraint if and only if
+each discriminant of the composite value has the value imposed by the
+discriminant constraint.
+
+12
+For the elaboration of a discriminant_constraint, the expressions in the
+discriminant_associations are evaluated in an arbitrary order and
+converted to the type of the associated discriminant (which might raise
+Constraint_Error -- see *note 4.6::); the expression of a named
+association is evaluated (and converted) once for each associated
+discriminant. The result of each evaluation and conversion is the value
+imposed by the constraint for the associated discriminant.
+
+12.a
+ Reason: We convert to the type, not the subtype, so that the
+ definition of compatibility of discriminant constraints is not
+ vacuous.
+
+ NOTES
+
+13
+ 59 The rules of the language ensure that a discriminant of an
+ object always has a value, either from explicit or implicit
+ initialization.
+
+13.a
+ Discussion: Although it is illegal to constrain a class-wide
+ tagged subtype, it is possible to have a partially constrained
+ class-wide subtype: If the subtype S is defined by T(A => B),
+ then S'Class is partially constrained in the sense that
+ objects of subtype S'Class have to have discriminants
+ corresponding to A equal to B, but there can be other
+ discriminants defined in extensions that are not constrained
+ to any particular value.
+
+ _Examples_
+
+14/3
+{AI05-0299-1AI05-0299-1} Examples (using types declared above in
+subclause *note 3.7::):
+
+15
+ Large : Buffer(200); -- constrained, always 200 characters
+ -- (explicit discriminant value)
+ Message : Buffer; -- unconstrained, initially 100 characters
+ -- (default discriminant value)
+ Basis : Square(5); -- constrained, always 5 by 5
+ Illegal : Square; -- illegal, a Square has to be constrained
+
+ _Inconsistencies With Ada 83_
+
+15.a
+ Dependent compatibility checks are no longer performed on
+ subtype declaration. Instead they are deferred until object
+ creation (see *note 3.3.1::). This is upward compatible for a
+ program that does not raise Constraint_Error.
+
+ _Wording Changes from Ada 83_
+
+15.b
+ Everything in RM83-3.7.2(7-12), which specifies the initial
+ values for discriminants, is now redundant with 3.3.1, 6.4.1,
+ 8.5.1, and 12.4. Therefore, we don't repeat it here. Since
+ the material is largely intuitive, but nevertheless
+ complicated to state formally, it doesn't seem worth putting
+ it in a "NOTE."
+
+ _Incompatibilities With Ada 95_
+
+15.c/2
+ {8652/00088652/0008} {AI95-00168-01AI95-00168-01}
+ {AI95-00363-01AI95-00363-01} The Corrigendum added a
+ restriction on discriminant_constraints for general access
+ subtypes. Such constraints are prohibited if the designated
+ type can be treated as constrained somewhere in the program.
+ Ada 2005 goes further and prohibits such
+ discriminant_constraints if the designated type has (or might
+ have, in the case of a formal type) defaults for its
+ discriminants. The use of general access subtypes is rare,
+ and this eliminates a boatload of problems that required many
+ restrictions on the use of aliased objects and components (now
+ lifted). Similarly, Ada 2005 prohibits
+ discriminant_constraints on any access type whose designated
+ type has a partial view that is constrained. Such a type will
+ not be constrained in the heap to avoid privacy problems.
+ Again, the use of such subtypes is rare (they can only happen
+ within the package and its child units).
+
+ _Wording Changes from Ada 2005_
+
+15.d/3
+ {AI05-0041-1AI05-0041-1} Correction: Revised the rules on
+ access subtypes having discriminant constraints to depend on
+ the "known to be constrained" rules. This centralizes the
+ rules so that future fixes need to be made in only one place,
+ as well as fixing bugs in obscure cases.
+
+15.e/3
+ {AI05-0102-1AI05-0102-1} Correction: Moved implicit conversion
+ Legality Rule to *note 8.6::.
+
+\1f
+File: aarm2012.info, Node: 3.7.2, Prev: 3.7.1, Up: 3.7
+
+3.7.2 Operations of Discriminated Types
+---------------------------------------
+
+1
+[If a discriminated type has default_expressions for its discriminants,
+then unconstrained variables of the type are permitted, and the
+discriminants of such a variable can be changed by assignment to the
+variable. For a formal parameter of such a type, an attribute is
+provided to determine whether the corresponding actual parameter is
+constrained or unconstrained.]
+
+ _Static Semantics_
+
+2
+For a prefix A that is of a discriminated type [(after any implicit
+dereference)], the following attribute is defined:
+
+3/3
+A'Constrained
+ {AI05-0214-1AI05-0214-1} Yields the value True if A
+ denotes a constant, a value, a tagged object, or a
+ constrained variable, and False otherwise.
+
+3.a/3
+ Implementation Note: {AI05-0214-1AI05-0214-1} This attribute
+ is primarily used on parameters, to determine whether the
+ discriminants can be changed as part of an assignment. The
+ Constrained attribute is statically True for in parameters.
+ For in out and out parameters of a discriminated type, the
+ value of this attribute needs to be passed as an implicit
+ parameter, in general. However, if the type is tagged or does
+ not have defaults for its discriminants, the attribute is
+ statically True, so no implicit parameter is needed.
+ Parameters of a limited untagged type with defaulted
+ discriminants need this implicit parameter, unless there are
+ no nonlimited views, because they might be passed to a
+ subprogram whose body has visibility on a nonlimited view of
+ the type, and hence might be able to assign to the object and
+ change its discriminants.
+
+3.b/3
+ Reason: {AI05-0214-1AI05-0214-1} All tagged objects are known
+ to be constrained (as nonlimited tagged types cannot have
+ discriminant defaults, and limited tagged objects are
+ immutably limited), and are always considered constrained by
+ this attribute to avoid distributed overhead for parameters of
+ limited classwide types, as limited tagged objects may
+ technically be unconstrained if they use defaulted
+ discriminants. Such objects still cannot have their
+ discriminants changed, as assignment is not supported for
+ them, so there is no use for this attribute that would justify
+ the overhead of passing it with all classwide parameters.
+
+3.c/3
+ Discussion: {AI05-0005-1AI05-0005-1} {AI05-0214-1AI05-0214-1}
+ If the type of A is a type derived from an untagged partial
+ view of a tagged type such that it is not a tagged type, then
+ A is not considered a tagged object, and A'Constrained can
+ return either True or False depending on the nature of the
+ object.
+
+ _Erroneous Execution_
+
+4
+The execution of a construct is erroneous if the construct has a
+constituent that is a name denoting a subcomponent that depends on
+discriminants, and the value of any of these discriminants is changed by
+this execution between evaluating the name and the last use (within this
+execution) of the subcomponent denoted by the name.
+
+4.a
+ Ramification: This rule applies to assignment_statements,
+ calls (except when the discriminant-dependent subcomponent is
+ an in parameter passed by copy), indexed_components, and
+ slices. Ada 83 only covered the first two cases. AI83-00585
+ pointed out the situation with the last two cases. The cases
+ of object_renaming_declarations and generic formal in out
+ objects are handled differently, by disallowing the situation
+ at compile time.
+
+ _Extensions to Ada 83_
+
+4.b/1
+ For consistency with other attributes, we are allowing the
+ prefix of Constrained to be a value as well as an object of a
+ discriminated type, and also an implicit dereference. These
+ extensions are not important capabilities, but there seems no
+ reason to make this attribute different from other similar
+ attributes. We are curious what most Ada 83 compilers do with
+ F(1).X'Constrained.
+
+4.c
+ We now handle in a general way the cases of erroneousness
+ identified by AI83-00585, where the prefix of an
+ indexed_component or slice is discriminant-dependent, and the
+ evaluation of the index or discrete range changes the value of
+ a discriminant.
+
+ _Wording Changes from Ada 83_
+
+4.d
+ We have moved all discussion of erroneous use of names that
+ denote discriminant-dependent subcomponents to this subclause.
+ In Ada 83, it used to appear separately under
+ assignment_statements and subprogram calls.
+
+ _Wording Changes from Ada 2005_
+
+4.e/3
+ {AI05-0214-1AI05-0214-1} A'Constrained is now defined to
+ return True for any A that is a tagged object. This doesn't
+ change the result for any A allowed by previous versions of
+ Ada; the change is necessary to avoid unnecessary overhead for
+ limited tagged parameters.
+
+\1f
+File: aarm2012.info, Node: 3.8, Next: 3.9, Prev: 3.7, Up: 3
+
+3.8 Record Types
+================
+
+1
+A record object is a composite object consisting of named components.
+The value of a record object is a composite value consisting of the
+values of the components.
+
+ _Syntax_
+
+2
+ record_type_definition ::= [[abstract] tagged] [limited]
+ record_definition
+
+3
+ record_definition ::=
+ record
+ component_list
+ end record
+ | null record
+
+4
+ component_list ::=
+ component_item {component_item}
+ | {component_item} variant_part
+ | null;
+
+5/1
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} component_item
+ ::= component_declaration | aspect_clause
+
+6/3
+ {AI05-0183-1AI05-0183-1} component_declaration ::=
+ defining_identifier_list : component_definition [:=
+ default_expression]
+ [aspect_specification];
+
+ _Name Resolution Rules_
+
+7
+The expected type for the default_expression, if any, in a
+component_declaration is the type of the component.
+
+ _Legality Rules_
+
+8/2
+This paragraph was deleted.{AI95-00287-01AI95-00287-01}
+
+9/2
+{AI95-00366-01AI95-00366-01} Each component_declaration declares a
+component of the record type. Besides components declared by
+component_declarations, the components of a record type include any
+components declared by discriminant_specifications of the record type
+declaration. [The identifiers of all components of a record type shall
+be distinct.]
+
+9.a/3
+ Proof: {AI05-0299-1AI05-0299-1} The identifiers of all
+ components of a record type have to be distinct because they
+ are all declared immediately within the same declarative
+ region. See Clause *note 8::.
+
+10
+Within a type_declaration, a name that denotes a component, protected
+subprogram, or entry of the type is allowed only in the following cases:
+
+11/3
+ * {AI05-0004-1AI05-0004-1} {AI05-0295-1AI05-0295-1} A name that
+ denotes any component, protected subprogram, or entry is allowed
+ within an aspect_specification, an operational item, or a
+ representation item that occurs within the declaration of the
+ composite type.
+
+12/3
+ * {AI05-0264-1AI05-0264-1} A name that denotes a noninherited
+ discriminant is allowed within the declaration of the type, but not
+ within the discriminant_part. If the discriminant is used to
+ define the constraint of a component, the bounds of an entry
+ family, or the constraint of the parent subtype in a
+ derived_type_definition, then its name shall appear alone as a
+ direct_name (not as part of a larger expression or expanded name).
+ A discriminant shall not be used to define the constraint of a
+ scalar component.
+
+12.a
+ Reason: The penultimate restriction simplifies implementation,
+ and allows the outer discriminant and the inner discriminant
+ or bound to possibly share storage.
+
+12.b
+ Ramification: Other rules prevent such a discriminant from
+ being an inherited one.
+
+12.c
+ Reason: The last restriction is inherited from Ada 83. The
+ restriction is not really necessary from a language design
+ point of view, but we did not remove it, in order to avoid
+ unnecessary changes to existing compilers.
+
+12.d
+ Discussion: Note that a discriminant can be used to define the
+ constraint for a component that is of an access-to-composite
+ type.
+
+12.e/2
+ Reason: {AI95-00373-01AI95-00373-01} The above rules, and a
+ similar one in *note 6.1:: for formal parameters, are intended
+ to allow initializations of components or parameters to occur
+ in a (nearly) arbitrary order -- whatever order is most
+ efficient (subject to the restrictions of *note 3.3.1::),
+ since one default_expression cannot depend on the value of
+ another one. They also prevent circularities.
+
+12.f/3
+ Ramification: {AI05-0295-1AI05-0295-1} Inherited discriminants
+ are not allowed to be denoted, except within
+ aspect_specifications and representation items. However, the
+ discriminant_selector_name of the parent subtype_indication is
+ allowed to denote a discriminant of the parent.
+
+13
+If the name of the current instance of a type (see *note 8.6::) is used
+to define the constraint of a component, then it shall appear as a
+direct_name that is the prefix of an attribute_reference whose result is
+of an access type, and the attribute_reference shall appear alone.
+
+13.a
+ Reason: This rule allows T'Access or T'Unchecked_Access, but
+ disallows, for example, a range constraint (1..T'Size).
+ Allowing things like (1..T'Size) would mean that a per-object
+ constraint could affect the size of the object, which would be
+ bad.
+
+ _Static Semantics_
+
+13.1/3
+{AI95-00318-02AI95-00318-02} {AI05-0004-1AI05-0004-1} If a
+record_type_definition includes the reserved word limited, the type is
+called an explicitly limited record type.
+
+14
+The component_definition of a component_declaration defines the
+(nominal) subtype of the component. If the reserved word aliased
+appears in the component_definition, then the component is aliased (see
+*note 3.10::).
+
+15
+If the component_list of a record type is defined by the reserved word
+null and there are no discriminants, then the record type has no
+components and all records of the type are null records. A
+record_definition of null record is equivalent to record null; end
+record.
+
+15.a
+ Ramification: This short-hand is available both for declaring
+ a record type and a record extension -- see *note 3.9.1::.
+
+ _Dynamic Semantics_
+
+16
+The elaboration of a record_type_definition creates the record type and
+its first subtype, and consists of the elaboration of the
+record_definition. The elaboration of a record_definition consists of
+the elaboration of its component_list, if any.
+
+17
+The elaboration of a component_list consists of the elaboration of the
+component_items and variant_part, if any, in the order in which they
+appear. The elaboration of a component_declaration consists of the
+elaboration of the component_definition.
+
+17.a
+ Discussion: If the defining_identifier_list has more than one
+ defining_identifier, we presume here that the transformation
+ explained in *note 3.3.1:: has already taken place.
+ Alternatively, we could say that the component_definition is
+ elaborated once for each defining_identifier in the list.
+
+18/2
+{8652/00028652/0002} {AI95-00171-01AI95-00171-01}
+{AI95-00230-01AI95-00230-01} Within the definition of a composite type,
+if a component_definition or discrete_subtype_definition (see *note
+9.5.2::) includes a name that denotes a discriminant of the type, or
+that is an attribute_reference whose prefix denotes the current instance
+of the type, the expression containing the name is called a per-object
+expression, and the constraint or range being defined is called a
+per-object constraint. For the elaboration of a component_definition of
+a component_declaration or the discrete_subtype_definition (*note 3.6:
+S0055.) of an entry_declaration (*note 9.5.2: S0218.) for an entry
+family (see *note 9.5.2::), if the component subtype is defined by an
+access_definition or if the constraint or range of the
+subtype_indication or discrete_subtype_definition (*note 3.6: S0055.) is
+not a per-object constraint, then the access_definition,
+subtype_indication, or discrete_subtype_definition (*note 3.6: S0055.)
+is elaborated. On the other hand, if the constraint or range is a
+per-object constraint, then the elaboration consists of the evaluation
+of any included expression that is not part of a per-object expression.
+Each such expression is evaluated once unless it is part of a named
+association in a discriminant constraint, in which case it is evaluated
+once for each associated discriminant.
+
+18.1/1
+{8652/00028652/0002} {AI95-00171-01AI95-00171-01} When a per-object
+constraint is elaborated [(as part of creating an object)], each
+per-object expression of the constraint is evaluated. For other
+expressions, the values determined during the elaboration of the
+component_definition (*note 3.6: S0056.) or entry_declaration (*note
+9.5.2: S0218.) are used. Any checks associated with the enclosing
+subtype_indication or discrete_subtype_definition are performed[,
+including the subtype compatibility check (see *note 3.2.2::),] and the
+associated subtype is created.
+
+18.a
+ Discussion: The evaluation of other expressions that appear in
+ component_definitions and discrete_subtype_definitions is
+ performed when the type definition is elaborated. The
+ evaluation of expressions that appear as default_expressions
+ is postponed until an object is created. Expressions in
+ representation items that appear within a composite type
+ definition are evaluated according to the rules of the
+ particular representation item.
+
+ NOTES
+
+19
+ 60 A component_declaration with several identifiers is equivalent
+ to a sequence of single component_declarations, as explained in
+ *note 3.3.1::.
+
+20
+ 61 The default_expression of a record component is only evaluated
+ upon the creation of a default-initialized object of the record
+ type (presuming the object has the component, if it is in a
+ variant_part -- see *note 3.3.1::).
+
+21
+ 62 The subtype defined by a component_definition (see *note 3.6::)
+ has to be a definite subtype.
+
+22
+ 63 If a record type does not have a variant_part, then the same
+ components are present in all values of the type.
+
+23
+ 64 A record type is limited if it has the reserved word limited in
+ its definition, or if any of its components are limited (see *note
+ 7.5::).
+
+24
+ 65 The predefined operations of a record type include membership
+ tests, qualification, and explicit conversion. If the record type
+ is nonlimited, they also include assignment and the predefined
+ equality operators.
+
+25/2
+ 66 {AI95-00287-01AI95-00287-01} A component of a record can be
+ named with a selected_component. A value of a record can be
+ specified with a record_aggregate.
+
+ _Examples_
+
+26
+Examples of record type declarations:
+
+27
+ type Date is
+ record
+ Day : Integer range 1 .. 31;
+ Month : Month_Name;
+ Year : Integer range 0 .. 4000;
+ end record;
+
+28
+ type Complex is
+ record
+ Re : Real := 0.0;
+ Im : Real := 0.0;
+ end record;
+
+29
+Examples of record variables:
+
+30
+ Tomorrow, Yesterday : Date;
+ A, B, C : Complex;
+
+31
+ -- both components of A, B, and C are implicitly initialized to zero
+
+ _Extensions to Ada 83_
+
+31.a
+ The syntax rule for component_declaration is modified to use
+ component_definition (instead of
+ component_subtype_definition). The effect of this change is
+ to allow the reserved word aliased before the
+ component_subtype_definition.
+
+31.b
+ A short-hand is provided for defining a null record type (and
+ a null record extension), as these will be more common for
+ abstract root types (and derived types without additional
+ components).
+
+31.c
+ The syntax rule for record_type_definition is modified to
+ allow the reserved words tagged and limited. Tagging is new.
+ Limitedness is now orthogonal to privateness. In Ada 83 the
+ syntax implied that limited private was sort of more private
+ than private. However, limitedness really has nothing to do
+ with privateness; limitedness simply indicates the lack of
+ assignment capabilities, and makes perfect sense for
+ nonprivate types such as record types.
+
+ _Wording Changes from Ada 83_
+
+31.d/1
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} The syntax
+ rules now allow aspect_clauses to appear in a
+ record_definition. This is not a language extension, because
+ Legality Rules prevent all language-defined representation
+ clauses from appearing there. However, an
+ implementation-defined attribute_definition_clause could
+ appear there. The reason for this change is to allow the
+ rules for aspect_clauses and representation pragmas to be as
+ similar as possible.
+
+ _Extensions to Ada 95_
+
+31.e/2
+ {AI95-00287-01AI95-00287-01} Record components can have an
+ anonymous access type.
+
+31.f/2
+ {AI95-00287-01AI95-00287-01} Limited components can be
+ initialized, so long as the expression is one that allows
+ building the object in place (such as an aggregate or
+ function_call).
+
+ _Wording Changes from Ada 95_
+
+31.g/2
+ {8652/00028652/0002} {AI95-00171-01AI95-00171-01} Corrigendum:
+ Improved the description of the elaboration of per-object
+ constraints.
+
+31.h/2
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} Corrigendum:
+ Changed representation clauses to aspect clauses to reflect
+ that they are used for more than just representation.
+
+31.i/2
+ {AI95-00318-02AI95-00318-02} Defined explicitly limited record
+ type to use in other rules.
+
+ _Extensions to Ada 2005_
+
+31.j/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a component_declaration. This is described in
+ *note 13.1.1::.
+
+* Menu:
+
+* 3.8.1 :: Variant Parts and Discrete Choices
+
+\1f
+File: aarm2012.info, Node: 3.8.1, Up: 3.8
+
+3.8.1 Variant Parts and Discrete Choices
+----------------------------------------
+
+1
+A record type with a variant_part specifies alternative lists of
+components. Each variant defines the components for the value or values
+of the discriminant covered by its discrete_choice_list.
+
+1.a
+ Discussion: Discrete_choice_lists and discrete_choices are
+ said to cover values as defined below; which
+ discrete_choice_list covers a value determines which of
+ various alternatives is chosen. These are used in
+ variant_parts, array_aggregates, and case_statements.
+
+ _Language Design Principles_
+
+1.b
+ The definition of "cover" in this subclause and the rules
+ about discrete choices are designed so that they are also
+ appropriate for array aggregates and case statements.
+
+1.c
+ The rules of this subclause intentionally parallel those for
+ case statements.
+
+ _Syntax_
+
+2
+ variant_part ::=
+ case discriminant_direct_name is
+ variant
+ {variant}
+ end case;
+
+3
+ variant ::=
+ when discrete_choice_list =>
+ component_list
+
+4
+ discrete_choice_list ::= discrete_choice {| discrete_choice}
+
+5/3
+ {AI05-0153-3AI05-0153-3} {AI05-0158-1AI05-0158-1} discrete_choice
+ ::= choice_expression | discrete_subtype_indication |
+ range | others
+
+ _Name Resolution Rules_
+
+6
+The discriminant_direct_name shall resolve to denote a discriminant
+(called the discriminant of the variant_part) specified in the
+known_discriminant_part of the full_type_declaration that contains the
+variant_part. The expected type for each discrete_choice in a variant
+is the type of the discriminant of the variant_part.
+
+6.a
+ Ramification: A full_type_declaration with a variant_part has
+ to have a (new) known_discriminant_part; the discriminant of
+ the variant_part cannot be an inherited discriminant.
+
+ _Legality Rules_
+
+7
+The discriminant of the variant_part shall be of a discrete type.
+
+7.a
+ Ramification: It shall not be of an access type, named or
+ anonymous.
+
+8/3
+{AI05-0153-3AI05-0153-3} The choice_expressions, subtype_indications,
+and ranges given as discrete_choices in a variant_part shall be static.
+The discrete_choice others shall appear alone in a discrete_choice_list,
+and such a discrete_choice_list, if it appears, shall be the last one in
+the enclosing construct.
+
+9
+A discrete_choice is defined to cover a value in the following cases:
+
+10/3
+ * {AI05-0262-1AI05-0262-1} A discrete_choice that is a
+ choice_expression covers a value if the value equals the value of
+ the choice_expression converted to the expected type.
+
+10.1/3
+ * {AI05-0153-3AI05-0153-3} {AI05-0262-1AI05-0262-1} A discrete_choice
+ that is a subtype_indication covers all values (possibly none) that
+ belong to the subtype and that satisfy the static predicate of the
+ subtype (see *note 3.2.4::).
+
+10.a/3
+ Ramification: {AI05-0262-1AI05-0262-1} A dynamic predicate is
+ never allowed in this case (for variants, case_statements, and
+ case_expressions, a subtype with a dynamic predicate isn't
+ static and thus isn't allowed in a discrete_choice, and for a
+ choice in an array_aggregate, a dynamic predicate is
+ explicitly disallowed -- see *note 3.2.4::).
+
+11/3
+ * {AI05-0153-3AI05-0153-3} A discrete_choice that is a range covers
+ all values (possibly none) that belong to the range.
+
+12
+ * The discrete_choice others covers all values of its expected type
+ that are not covered by previous discrete_choice_lists of the same
+ construct.
+
+12.a
+ Ramification: For case_statements, this includes values
+ outside the range of the static subtype (if any) to be covered
+ by the choices. It even includes values outside the base
+ range of the case expression's type, since values of numeric
+ types (and undefined values of any scalar type?) can be
+ outside their base range.
+
+13
+A discrete_choice_list covers a value if one of its discrete_choices
+covers the value.
+
+14
+The possible values of the discriminant of a variant_part shall be
+covered as follows:
+
+15/3
+ * {AI05-0153-3AI05-0153-3} {AI05-0188-1AI05-0188-1}
+ {AI05-0262-1AI05-0262-1} If the discriminant is of a static
+ constrained scalar subtype then, except within an instance of a
+ generic unit, each non-others discrete_choice (*note 3.8.1: S0074.)
+ shall cover only values in that subtype that satisfy its predicate,
+ and each value of that subtype that satisfies its predicate shall
+ be covered by some discrete_choice (*note 3.8.1: S0074.) [(either
+ explicitly or by others)];
+
+15.a/3
+ Reason: {AI05-0188-1AI05-0188-1} The exemption for a
+ discriminated type declared in an instance allows the
+ following example:
+
+15.b/3
+ generic
+ type T is new Integer;
+ package G is
+ type Rec (Discrim : T) is record
+ case Discrim is
+ when -10 .. -1 =>
+ Foo : Float;
+ when others =>
+ null;
+ end case;
+ end record;
+ end G;
+
+15.c/3
+ package I is new G (Natural); -- Legal
+
+16/3
+ * {AI05-0264-1AI05-0264-1} If the type of the discriminant is a
+ descendant of a generic formal scalar type, then the variant_part
+ shall have an others discrete_choice;
+
+16.a
+ Reason: The base range is not known statically in this case.
+
+17
+ * Otherwise, each value of the base range of the type of the
+ discriminant shall be covered [(either explicitly or by others)].
+
+18
+Two distinct discrete_choices of a variant_part shall not cover the same
+value.
+
+ _Static Semantics_
+
+19
+If the component_list of a variant is specified by null, the variant has
+no components.
+
+20
+The discriminant of a variant_part is said to govern the variant_part
+and its variants. In addition, the discriminant of a derived type
+governs a variant_part and its variants if it corresponds (see *note
+3.7::) to the discriminant of the variant_part.
+
+ _Dynamic Semantics_
+
+21
+A record value contains the values of the components of a particular
+variant only if the value of the discriminant governing the variant is
+covered by the discrete_choice_list of the variant. This rule applies
+in turn to any further variant that is, itself, included in the
+component_list of the given variant.
+
+21.1/3
+{AI05-0290-1AI05-0290-1} When an object of a discriminated type T is
+initialized by default, Constraint_Error is raised if no
+discrete_choice_list of any variant of a variant_part of T covers the
+value of the discriminant that governs the variant_part. When a
+variant_part appears in the component_list of another variant V, this
+test is only applied if the value of the discriminant governing V is
+covered by the discrete_choice_list of V.
+
+21.a/3
+ Implementation Note: This is not a "check"; it cannot be
+ suppressed. However, in most cases it is not necessary to
+ generate any code to raise this exception. A test is needed
+ (and can fail) in the case where the discriminant subtype has
+ a Static_Predicate specified, it also has predicate checking
+ disabled, and the discriminant governs a variant_part which
+ lacks a when others choice.
+
+21.b/3
+ The test also could fail for a static discriminant subtype
+ with range checking suppressed and the discriminant governs a
+ variant_part which lacks a when others choice. But execution
+ is erroneous if a range check that would have failed is
+ suppressed (see *note 11.5::), so an implementation does not
+ have to generate code to check this case. (An unchecked
+ failed predicate does not cause erroneous execution, so the
+ test is required in that case.)
+
+21.c/3
+ Like the checks associated with a per-object constraint, this
+ test is not made during the elaboration of a
+ subtype_indication.
+
+22
+The elaboration of a variant_part consists of the elaboration of the
+component_list of each variant in the order in which they appear.
+
+ _Examples_
+
+23
+Example of record type with a variant part:
+
+24
+ type Device is (Printer, Disk, Drum);
+ type State is (Open, Closed);
+
+25
+ type Peripheral(Unit : Device := Disk) is
+ record
+ Status : State;
+ case Unit is
+ when Printer =>
+ Line_Count : Integer range 1 .. Page_Size;
+ when others =>
+ Cylinder : Cylinder_Index;
+ Track : Track_Number;
+ end case;
+ end record;
+
+26
+Examples of record subtypes:
+
+27
+ subtype Drum_Unit is Peripheral(Drum);
+ subtype Disk_Unit is Peripheral(Disk);
+
+28
+Examples of constrained record variables:
+
+29
+ Writer : Peripheral(Unit => Printer);
+ Archive : Disk_Unit;
+
+ _Extensions to Ada 83_
+
+29.a
+ In Ada 83, the discriminant of a variant_part is not allowed
+ to be of a generic formal type. This restriction is removed
+ in Ada 95; an others discrete_choice is required in this case.
+
+ _Wording Changes from Ada 83_
+
+29.b
+ The syntactic category choice is removed. The syntax rules
+ for variant, array_aggregate, and case_statement now use
+ discrete_choice_list or discrete_choice instead. The syntax
+ rule for record_aggregate now defines its own syntax for named
+ associations.
+
+29.c/3
+ {AI05-0299-1AI05-0299-1} We have added the term Discrete
+ Choice to the title since this is where they are talked about.
+ This is analogous to the name of the subclause "Index
+ Constraints and Discrete Ranges" in the subclause on Array
+ Types.
+
+29.d
+ The rule requiring that the discriminant denote a discriminant
+ of the type being defined seems to have been left implicit in
+ RM83.
+
+ _Incompatibilities With Ada 2005_
+
+29.e/3
+ {AI05-0158-1AI05-0158-1} Membership tests are no longer
+ allowed as a discrete_choice, in order that those tests can be
+ expanded to allow multiple tests in a single expression
+ without ambiguity. Since a membership test has a boolean
+ type, they are very unlikely to be used as a discrete_choice.
+
+ _Extensions to Ada 2005_
+
+29.f/3
+ {AI05-0153-3AI05-0153-3} Subtypes with static predicates can
+ be used in discrete_choices, and the coverage rules are
+ modified to respect the predicates.
+
+29.g/3
+ {AI05-0188-1AI05-0188-1} Variants in generic specifications
+ are no longer rejected if the subtype of the actual type does
+ not include all of the case choices. This probably isn't
+ useful, but it is consistent with the treatment of
+ case_expressions.
+
+ _Wording Changes from Ada 2005_
+
+29.h/3
+ {AI05-0290-1AI05-0290-1} Added a test that some variant covers
+ the value of a discriminant that governs a variant_part. This
+ is similar to the test that some case limb covers the value of
+ the Selecting_expression of a case_statement. This test
+ cannot change the behavior of any nonerroneous Ada 2005
+ program, so it is not an inconsistency.
+
+\1f
+File: aarm2012.info, Node: 3.9, Next: 3.10, Prev: 3.8, Up: 3
+
+3.9 Tagged Types and Type Extensions
+====================================
+
+1
+[ Tagged types and type extensions support object-oriented programming,
+based on inheritance with extension and run-time polymorphism via
+dispatching operations. ]
+
+ _Language Design Principles_
+
+1.a/2
+ {AI95-00251-01AI95-00251-01} The intended implementation model
+ is for the static portion of a tag to be represented as a
+ pointer to a statically allocated and link-time initialized
+ type descriptor. The type descriptor contains the address of
+ the code for each primitive operation of the type. It
+ probably also contains other information, such as might make
+ membership tests convenient and efficient. Tags for nested
+ type extensions must also have a dynamic part that identifies
+ the particular elaboration of the type.
+
+1.b
+ The primitive operations of a tagged type are known at its
+ first freezing point; the type descriptor is laid out at that
+ point. It contains linker symbols for each primitive
+ operation; the linker fills in the actual addresses.
+
+1.b.1/2
+ {AI95-00251-01AI95-00251-01} Primitive operations of type
+ extensions that are declared at a level deeper than the level
+ of the ultimate ancestor from which they are derived can be
+ represented by wrappers that use the dynamic part of the tag
+ to call the actual primitive operation. The dynamic part
+ would generally be some way to represent the static link or
+ display necessary for making a nested call. One
+ implementation strategy would be to store that information in
+ the extension part of such nested type extensions, and use the
+ dynamic part of the tag to point at it. (That way, the
+ "dynamic" part of the tag could be static, at the cost of
+ indirect access.)
+
+1.b.2/2
+ {AI95-00251-01AI95-00251-01} If the tagged type is descended
+ from any interface types, it also will need to include
+ "subtags" (one for each interface) that describe the mapping
+ of the primitive operations of the interface to the primitives
+ of the type. These subtags could directly reference the
+ primitive operations (for faster performance), or simply
+ provide the tag "slot" numbers for the primitive operations
+ (for easier derivation). In either case, the subtags would be
+ used for calls that dispatch through a class-wide type of the
+ interface.
+
+1.c
+ Other implementation models are possible.
+
+1.d
+ The rules ensure that "dangling dispatching" is impossible;
+ that is, when a dispatching call is made, there is always a
+ body to execute. This is different from some other
+ object-oriented languages, such as Smalltalk, where it is
+ possible to get a run-time error from a missing method.
+
+1.e/2
+ {AI95-00251-01AI95-00251-01} Dispatching calls should be
+ efficient, and should have a bounded worst-case execution
+ time. This is important in a language intended for real-time
+ applications. In the intended implementation model, a
+ dispatching call involves calling indirect through the
+ appropriate slot in the dispatch table. No complicated
+ "method lookup" is involved although a call which is
+ dispatching on an interface may require a lookup of the
+ appropriate interface subtag.
+
+1.f
+ The programmer should have the choice at each call site of a
+ dispatching operation whether to do a dispatching call or a
+ statically determined call (i.e. whether the body executed
+ should be determined at run time or at compile time).
+
+1.g
+ The same body should be executed for a call where the tag is
+ statically determined to be T'Tag as for a dispatching call
+ where the tag is found at run time to be T'Tag. This allows
+ one to test a given tagged type with statically determined
+ calls, with some confidence that run-time dispatching will
+ produce the same behavior.
+
+1.h
+ All views of a type should share the same type descriptor and
+ the same tag.
+
+1.i
+ The visibility rules determine what is legal at compile time;
+ they have nothing to do with what bodies can be executed at
+ run time. Thus, it is possible to dispatch to a subprogram
+ whose declaration is not visible at the call site. In fact,
+ this is one of the primary facts that gives object-oriented
+ programming its power. The subprogram that ends up being
+ dispatched to by a given call might even be designed long
+ after the call site has been coded and compiled.
+
+1.j
+ Given that Ada has overloading, determining whether a given
+ subprogram overrides another is based both on the names and
+ the type profiles of the operations.
+
+1.k/2
+ {AI95-00401-01AI95-00401-01} When a type extension is
+ declared, if there is any place within its immediate scope
+ where a certain subprogram of the parent or progenitor is
+ visible, then a matching subprogram should override. If there
+ is no such place, then a matching subprogram should be totally
+ unrelated, and occupy a different slot in the type descriptor.
+ This is important to preserve the privacy of private parts;
+ when an operation declared in a private part is inherited, the
+ inherited version can be overridden only in that private part,
+ in the package body, and in any children of the package.
+
+1.l
+ If an implementation shares code for instances of generic
+ bodies, it should be allowed to share type descriptors of
+ tagged types declared in the generic body, so long as they are
+ not extensions of types declared in the specification of the
+ generic unit.
+
+ _Static Semantics_
+
+2/2
+{AI95-00345-01AI95-00345-01} A record type or private type that has the
+reserved word tagged in its declaration is called a tagged type. In
+addition, an interface type is a tagged type, as is a task or protected
+type derived from an interface (see *note 3.9.4::). [When deriving from
+a tagged type, as for any derived type, additional primitive subprograms
+may be defined, and inherited primitive subprograms may be overridden.]
+The derived type is called an extension of its ancestor types, or simply
+a type extension.
+
+2.1/2
+{AI95-00345-01AI95-00345-01} Every type extension is also a tagged type,
+and is a record extension or a private extension of some other tagged
+type, or a noninterface synchronized tagged type (see *note 3.9.4::). A
+record extension is defined by a derived_type_definition with a
+record_extension_part (see *note 3.9.1::)[, which may include the
+definition of additional components]. A private extension, which is a
+partial view of a record extension or of a synchronized tagged type, can
+be declared in the visible part of a package (see *note 7.3::) or in a
+generic formal part (see *note 12.5.1::).
+
+2.a
+ Glossary entry: The objects of a tagged type have a run-time
+ type tag, which indicates the specific type with which the
+ object was originally created. An operand of a class-wide
+ tagged type can be used in a dispatching call; the tag
+ indicates which subprogram body to invoke. Nondispatching
+ calls, in which the subprogram body to invoke is determined at
+ compile time, are also allowed. Tagged types may be extended
+ with additional components.
+
+2.b/2
+ Ramification: {AI95-00218-03AI95-00218-03} If a tagged type is
+ declared other than in a package_specification, it is
+ impossible to add new primitive subprograms for that type,
+ although it can inherit primitive subprograms, and those can
+ be overridden. If the user incorrectly thinks a certain
+ subprogram is primitive when it is not, and tries to call it
+ with a dispatching call, an error message will be given at the
+ call site. Similarly, by using an overriding_indicator (see
+ *note 6.1::), the user can declare that a subprogram is
+ intended to be overriding, and get an error message when they
+ made a mistake. The use of overriding_indicators is highly
+ recommended in new code that does not need to be compatible
+ with Ada 95.
+
+3
+An object of a tagged type has an associated (run-time) tag that
+identifies the specific tagged type used to create the object
+originally. [ The tag of an operand of a class-wide tagged type T'Class
+controls which subprogram body is to be executed when a primitive
+subprogram of type T is applied to the operand (see *note 3.9.2::);
+using a tag to control which body to execute is called dispatching.]
+
+4/2
+{AI95-00344-01AI95-00344-01} The tag of a specific tagged type
+identifies the full_type_declaration of the type, and for a type
+extension, is sufficient to uniquely identify the type among all
+descendants of the same ancestor. If a declaration for a tagged type
+occurs within a generic_package_declaration, then the corresponding type
+declarations in distinct instances of the generic package are associated
+with distinct tags. For a tagged type that is local to a generic
+package body and with all of its ancestors (if any) also local to the
+generic body, the language does not specify whether repeated
+instantiations of the generic body result in distinct tags.
+
+4.a/2
+ This paragraph was deleted.{AI95-00344-01AI95-00344-01}
+
+4.a.1/2
+ Implementation Note: {AI95-00344-01AI95-00344-01} In most
+ cases, a tag need only identify a particular tagged type
+ declaration, and can therefore be a simple link-time-known
+ address. However, for tag checks (see *note 3.9.2::) it is
+ essential that each descendant (that currently exists) of a
+ given type have a unique tag. Hence, for types declared in
+ shared generic bodies where an ancestor comes from outside the
+ generic, or for types declared at a deeper level than an
+ ancestor, the tag needs to be augmented with some kind of
+ dynamic descriptor (which may be a static link, global
+ display, instance descriptor pointer, or combination). This
+ implies that type Tag may need to be two words, the second of
+ which is normally null, but in these identified special cases
+ needs to include a static link or equivalent. Within an
+ object of one of these types with a two-word tag, the two
+ parts of the tag would typically be separated, one part as the
+ first word of the object, the second placed in the first
+ extension part that corresponds to a type declared more nested
+ than its parent or declared in a shared generic body when the
+ parent is declared outside. Alternatively, by using an extra
+ level of indirection, the type Tag could remain a single-word.
+
+4.b/2
+ {AI95-00344-01AI95-00344-01} For types that are not type
+ extensions (even for ones declared in nested scopes), we do
+ not require that repeated elaborations of the same
+ full_type_declaration correspond to distinct tags. This was
+ done so that Ada 2005 implementations of tagged types could
+ maintain representation compatibility with Ada 95
+ implementations. Only type extensions that were not allowed
+ in Ada 95 require additional information with the tag.
+
+4.c/2
+ To be honest: {AI95-00344-01AI95-00344-01} The wording "is
+ sufficient to uniquely identify the type among all descendants
+ of the same ancestor" only applies to types that currently
+ exist. It is not necessary to distinguish between descendants
+ that currently exist, and descendants of the same type that no
+ longer exist. For instance, the address of the stack frame of
+ the subprogram that created the tag is sufficient to meet the
+ requirements of this rule, even though it is possible, after
+ the subprogram returns, that a later call of the subprogram
+ could have the same stack frame and thus have an identical
+ tag.
+
+5
+The following language-defined library package exists:
+
+6/2
+ {AI95-00362-01AI95-00362-01} package Ada.Tags is
+ pragma Preelaborate(Tags);
+ type Tag is private;
+ pragma Preelaborable_Initialization(Tag);
+
+6.1/2
+ {AI95-00260-02AI95-00260-02} No_Tag : constant Tag;
+
+7/2
+ {AI95-00400-01AI95-00400-01} function Expanded_Name(T : Tag) return String;
+ function Wide_Expanded_Name(T : Tag) return Wide_String;
+ function Wide_Wide_Expanded_Name(T : Tag) return Wide_Wide_String;
+ function External_Tag(T : Tag) return String;
+ function Internal_Tag(External : String) return Tag;
+
+7.1/2
+ {AI95-00344-01AI95-00344-01} function Descendant_Tag(External : String; Ancestor : Tag) return Tag;
+ function Is_Descendant_At_Same_Level(Descendant, Ancestor : Tag)
+ return Boolean;
+
+7.2/2
+ {AI95-00260-02AI95-00260-02} function Parent_Tag (T : Tag) return Tag;
+
+7.3/2
+ {AI95-00405-01AI95-00405-01} type Tag_Array is array (Positive range <>) of Tag;
+
+7.4/2
+ {AI95-00405-01AI95-00405-01} function Interface_Ancestor_Tags (T : Tag) return Tag_Array;
+
+7.5/3
+ {AI05-0173-1AI05-0173-1} function Is_Abstract (T : Tag) return Boolean;
+
+8
+ Tag_Error : exception;
+
+9
+ private
+ ... -- not specified by the language
+ end Ada.Tags;
+
+9.a
+ Reason: Tag is a nonlimited, definite subtype, because it
+ needs the equality operators, so that tag checking makes
+ sense. Also, equality, assignment, and object declaration are
+ all useful capabilities for this subtype.
+
+9.b
+ For an object X and a type T, "X'Tag = T'Tag" is not needed,
+ because a membership test can be used. However, comparing the
+ tags of two objects cannot be done via membership. This is
+ one reason to allow equality for type Tag.
+
+9.1/2
+{AI95-00260-02AI95-00260-02} No_Tag is the default initial value of type
+Tag.
+
+9.c/2
+ Reason: {AI95-00260-02AI95-00260-02} This is similar to the
+ requirement that all access values be initialized to null.
+
+10/2
+{AI95-00400-01AI95-00400-01} The function Wide_Wide_Expanded_Name
+returns the full expanded name of the first subtype of the specific type
+identified by the tag, in upper case, starting with a root library unit.
+The result is implementation defined if the type is declared within an
+unnamed block_statement.
+
+10.a
+ To be honest: This name, as well as each prefix of it, does
+ not denote a renaming_declaration.
+
+10.b/2
+ Implementation defined: The result of
+ Tags.Wide_Wide_Expanded_Name for types declared within an
+ unnamed block_statement.
+
+10.1/2
+{AI95-00400-01AI95-00400-01} The function Expanded_Name (respectively,
+Wide_Expanded_Name) returns the same sequence of graphic characters as
+that defined for Wide_Wide_Expanded_Name, if all the graphic characters
+are defined in Character (respectively, Wide_Character); otherwise, the
+sequence of characters is implementation defined, but no shorter than
+that returned by Wide_Wide_Expanded_Name for the same value of the
+argument.
+
+10.c/2
+ Implementation defined: The sequence of characters of the
+ value returned by Tags.Expanded_Name (respectively,
+ Tags.Wide_Expanded_Name) when some of the graphic characters
+ of Tags.Wide_Wide_Expanded_Name are not defined in Character
+ (respectively, Wide_Character).
+
+11
+The function External_Tag returns a string to be used in an external
+representation for the given tag. The call External_Tag(S'Tag) is
+equivalent to the attribute_reference S'External_Tag (see *note 13.3::).
+
+11.a
+ Reason: It might seem redundant to provide both the function
+ External_Tag and the attribute External_Tag. The function is
+ needed because the attribute can't be applied to values of
+ type Tag. The attribute is needed so that it can be specified
+ via an attribute_definition_clause.
+
+11.1/2
+{AI95-00417-01AI95-00417-01} The string returned by the functions
+Expanded_Name, Wide_Expanded_Name, Wide_Wide_Expanded_Name, and
+External_Tag has lower bound 1.
+
+12/2
+{AI95-00279-01AI95-00279-01} The function Internal_Tag returns a tag
+that corresponds to the given external tag, or raises Tag_Error if the
+given string is not the external tag for any specific type of the
+partition. Tag_Error is also raised if the specific type identified is
+a library-level type whose tag has not yet been created (see *note
+13.14::).
+
+12.a/3
+ Reason: {AI95-00279-01AI95-00279-01} {AI05-0005-1AI05-0005-1}
+ The check for uncreated library-level types prevents a
+ reference to the type before execution reaches the freezing
+ point of the type. This is important so that T'Class'Input or
+ an instance of Tags.Generic_Dispatching_Constructor do not try
+ to create an object of a type that hasn't been frozen (which
+ might not have yet elaborated its constraints). We don't
+ require this behavior for non-library-level types as the tag
+ can be created multiple times and possibly multiple copies can
+ exist at the same time, making the check complex.
+
+12.1/3
+{AI95-00344-01AI95-00344-01} {AI05-0113-1AI05-0113-1} The function
+Descendant_Tag returns the (internal) tag for the type that corresponds
+to the given external tag and is both a descendant of the type
+identified by the Ancestor tag and has the same accessibility level as
+the identified ancestor. Tag_Error is raised if External is not the
+external tag for such a type. Tag_Error is also raised if the specific
+type identified is a library-level type whose tag has not yet been
+created, or if the given external tag identifies more than one type that
+has the appropriate Ancestor and accessibility level.
+
+12.b/2
+ Reason: Descendant_Tag is used by T'Class'Input to identify
+ the type identified by an external tag. Because there can be
+ multiple elaborations of a given type declaration,
+ Internal_Tag does not have enough information to choose a
+ unique such type. Descendant_Tag does not return the tag for
+ types declared at deeper accessibility levels than the
+ ancestor because there could be ambiguity in the presence of
+ recursion or multiple tasks. Descendant_Tag can be used in
+ constructing a user-defined replacement for T'Class'Input.
+
+12.b.1/3
+ {AI05-0113-1AI05-0113-1} Rules for specifying external tags
+ will usually prevent an external tag from identifying more
+ than one type. However, an external tag can identify multiple
+ types if a generic body contains a derivation of a tagged type
+ declared outside of the generic, and there are multiple
+ instances at the same accessibility level as the type. (The
+ Standard allows default external tags to not be unique in this
+ case.)
+
+12.2/2
+{AI95-00344-01AI95-00344-01} The function Is_Descendant_At_Same_Level
+returns True if the Descendant tag identifies a type that is both a
+descendant of the type identified by Ancestor and at the same
+accessibility level. If not, it returns False.
+
+12.c/2
+ Reason: Is_Descendant_At_Same_Level (or something similar to
+ it) is used by T'Class'Output to determine whether the item
+ being written is at the same accessibility level as T. It may
+ be used to determine prior to using T'Class'Output whether
+ Tag_Error will be raised, and also can be used in constructing
+ a user-defined replacement for T'Class'Output.
+
+12.3/3
+{AI05-0115-1AI05-0115-1} For the purposes of the dynamic semantics of
+functions Descendant_Tag and Is_Descendant_At_Same_Level, a tagged type
+T2 is a descendant of a type T1 if it is the same as T1, or if its
+parent type or one of its progenitor types is a descendant of type T1 by
+this rule[, even if at the point of the declaration of T2, one of the
+derivations in the chain is not visible].
+
+12.c.1/3
+ Discussion: In other contexts, "descendant" is dependent on
+ visibility, and the particular view a derived type has of its
+ parent type. See *note 7.3.1::.
+
+12.4/3
+{AI95-00260-02AI95-00260-02} The function Parent_Tag returns the tag of
+the parent type of the type whose tag is T. If the type does not have a
+parent type (that is, it was not declared by a
+derived_type_declaration), then No_Tag is returned.
+
+12.d/2
+ Ramification: The parent type is always the parent of the full
+ type; a private extension appears to define a parent type, but
+ it does not (only the various forms of derivation do that).
+ As this is a run-time operation, ignoring privateness is OK.
+
+12.5/3
+{AI95-00405-01AI95-00405-01} The function Interface_Ancestor_Tags
+returns an array containing the tag of each interface ancestor type of
+the type whose tag is T, other than T itself. The lower bound of the
+returned array is 1, and the order of the returned tags is unspecified.
+Each tag appears in the result exactly once.[ If the type whose tag is T
+has no interface ancestors, a null array is returned.]
+
+12.e/2
+ Ramification: The result of Interface_Ancestor_Tags includes
+ the tag of the parent type, if the parent is an interface.
+
+12.f/2
+ Indirect interface ancestors are included in the result of
+ Interface_Ancestor_Tags. That's because where an interface
+ appears in the derivation tree has no effect on the semantics
+ of the type; the only interesting property is whether the type
+ has an interface as an ancestor.
+
+12.6/3
+{AI05-0173-1AI05-0173-1} The function Is_Abstract returns True if the
+type whose tag is T is abstract, and False otherwise.
+
+13
+For every subtype S of a tagged type T (specific or class-wide), the
+following attributes are defined:
+
+14
+S'Class
+ S'Class denotes a subtype of the class-wide type (called
+ T'Class in this International Standard) for the class
+ rooted at T (or if S already denotes a class-wide
+ subtype, then S'Class is the same as S).
+
+15
+ S'Class is unconstrained. However, if S is constrained,
+ then the values of S'Class are only those that when
+ converted to the type T belong to S.
+
+15.a
+ Ramification: This attribute is defined for both specific and
+ class-wide subtypes. The definition is such that
+ S'Class'Class is the same as S'Class.
+
+15.b
+ Note that if S is constrained, S'Class is only partially
+ constrained, since there might be additional discriminants
+ added in descendants of T which are not constrained.
+
+15.c/2
+ Reason: {AI95-00326-01AI95-00326-01} The Class attribute is
+ not defined for untagged subtypes (except for incomplete types
+ and private types whose full view is tagged -- see *note
+ J.11:: and *note 7.3.1::) so as to preclude implicit
+ conversion in the absence of run-time type information. If it
+ were defined for untagged subtypes, it would correspond to the
+ concept of universal types provided for the predefined numeric
+ classes.
+
+16
+S'Tag
+ S'Tag denotes the tag of the type T (or if T is
+ class-wide, the tag of the root type of the corresponding
+ class). The value of this attribute is of type Tag.
+
+16.a
+ Reason: S'Class'Tag equals S'Tag, to avoid generic contract
+ model problems when S'Class is the actual type associated with
+ a generic formal derived type.
+
+17
+Given a prefix X that is of a class-wide tagged type [(after any
+implicit dereference)], the following attribute is defined:
+
+18
+X'Tag
+ X'Tag denotes the tag of X. The value of this attribute
+ is of type Tag.
+
+18.a
+ Reason: X'Tag is not defined if X is of a specific type. This
+ is primarily to avoid confusion that might result about
+ whether the Tag attribute should reflect the tag of the type
+ of X, or the tag of X. No such confusion is possible if X is
+ of a class-wide type.
+
+18.1/2
+{AI95-00260-02AI95-00260-02} {AI95-00441-01AI95-00441-01} The following
+language-defined generic function exists:
+
+18.2/3
+ {AI05-0229-1AI05-0229-1} generic
+ type T (<>) is abstract tagged limited private;
+ type Parameters (<>) is limited private;
+ with function Constructor (Params : not null access Parameters)
+ return T is abstract;
+ function Ada.Tags.Generic_Dispatching_Constructor
+ (The_Tag : Tag;
+ Params : not null access Parameters) return T'Class
+ with Convention => Intrinsic;
+ pragma Preelaborate(Generic_Dispatching_Constructor);
+
+18.3/2
+{AI95-00260-02AI95-00260-02} Tags.Generic_Dispatching_Constructor
+provides a mechanism to create an object of an appropriate type from
+just a tag value. The function Constructor is expected to create the
+object given a reference to an object of type Parameters.
+
+18.b/2
+ Discussion: This specification is designed to make it easy to
+ create dispatching constructors for streams; in particular,
+ this can be used to construct overridings for T'Class'Input.
+
+18.c/2
+ Note that any tagged type will match T (see *note 12.5.1::).
+
+ _Dynamic Semantics_
+
+19
+The tag associated with an object of a tagged type is determined as
+follows:
+
+20
+ * The tag of a stand-alone object, a component, or an aggregate of a
+ specific tagged type T identifies T.
+
+20.a
+ Discussion: The tag of a formal parameter of type T is not
+ necessarily the tag of T, if, for example, the actual was a
+ type conversion.
+
+21
+ * The tag of an object created by an allocator for an access type
+ with a specific designated tagged type T, identifies T.
+
+21.a
+ Discussion: The tag of an object designated by a value of such
+ an access type might not be T, if, for example, the access
+ value is the result of a type conversion.
+
+22
+ * The tag of an object of a class-wide tagged type is that of its
+ initialization expression.
+
+22.a
+ Ramification: The tag of an object (even a class-wide one)
+ cannot be changed after it is initialized, since a
+ "class-wide" assignment_statement raises Constraint_Error if
+ the tags don't match, and a "specific" assignment_statement
+ does not affect the tag.
+
+23
+ * The tag of the result returned by a function whose result type is a
+ specific tagged type T identifies T.
+
+23.a/2
+ Implementation Note: {AI95-00318-02AI95-00318-02} For a
+ limited tagged type, the return object is "built in place" in
+ the ultimate result object with the appropriate tag. For a
+ nonlimited type, a new anonymous object with the appropriate
+ tag is created as part of the function return. See *note
+ 6.5::, "*note 6.5:: Return Statements".
+
+24/2
+ * {AI95-00318-02AI95-00318-02} The tag of the result returned by a
+ function with a class-wide result type is that of the return
+ object.
+
+25
+The tag is preserved by type conversion and by parameter passing. The
+tag of a value is the tag of the associated object (see *note 6.2::).
+
+25.1/3
+{AI95-00260-02AI95-00260-02} {AI95-00344-01AI95-00344-01}
+{AI95-00405-01AI95-00405-01} {AI05-0092-1AI05-0092-1}
+{AI05-0262-1AI05-0262-1} Tag_Error is raised by a call of
+Descendant_Tag, Expanded_Name, External_Tag, Interface_Ancestor_Tags,
+Is_Abstract, Is_Descendant_At_Same_Level, Parent_Tag,
+Wide_Expanded_Name, or Wide_Wide_Expanded_Name if any tag passed is
+No_Tag.
+
+25.2/2
+{AI95-00260-02AI95-00260-02} An instance of
+Tags.Generic_Dispatching_Constructor raises Tag_Error if The_Tag does
+not represent a concrete descendant of T or if the innermost master (see
+*note 7.6.1::) of this descendant is not also a master of the instance.
+Otherwise, it dispatches to the primitive function denoted by the formal
+Constructor for the type identified by The_Tag, passing Params, and
+returns the result. Any exception raised by the function is propagated.
+
+25.a/2
+ Ramification: The tag check checks both that The_Tag is in
+ T'Class, and that it is not abstract. These checks are
+ similar to the ones required by streams for T'Class'Input (see
+ *note 13.13.2::). In addition, there is a check that the tag
+ identifies a type declared on the current dynamic call chain,
+ and not a more nested type or a type declared by another task.
+ This check is not necessary for streams, because the stream
+ attributes are declared at the same dynamic level as the type
+ used.
+
+ _Erroneous Execution_
+
+25.3/2
+{AI95-00260-02AI95-00260-02} If an internal tag provided to an instance
+of Tags.Generic_Dispatching_Constructor or to any subprogram declared in
+package Tags identifies either a type that is not library-level and
+whose tag has not been created (see *note 13.14::), or a type that does
+not exist in the partition at the time of the call, then execution is
+erroneous.
+
+25.b/2
+ Ramification: One reason that a type might not exist in the
+ partition is that the tag refers to a type whose declaration
+ was elaborated as part of an execution of a subprogram_body
+ which has been left (see *note 7.6.1::).
+
+25.c/2
+ We exclude tags of library-level types from the current
+ execution of the partition, because misuse of such tags should
+ always be detected. T'Tag freezes the type (and thus creates
+ the tag), and Internal_Tag and Descendant_Tag cannot return
+ the tag of a library-level type that has not been created.
+ All ancestors of a tagged type must be frozen no later than
+ the (full) declaration of a type that uses them, so Parent_Tag
+ and Interface_Ancestor_Tags cannot return a tag that has not
+ been created. Finally, library-level types never cease to
+ exist while the partition is executing. Thus, if the tag
+ comes from a library-level type, there cannot be erroneous
+ execution (the use of Descendant_Tag rather than Internal_Tag
+ can help ensure that the tag is of a library-level type).
+ This is also similar to the rules for T'Class'Input (see *note
+ 13.13.2::).
+
+25.d/2
+ Discussion: {AI95-00344-01AI95-00344-01} Ada 95 allowed
+ Tag_Error in this case, or expected the functions to work.
+ This worked because most implementations used tags constructed
+ at link-time, and each elaboration of the same
+ type_declaration produced the same tag. However, Ada 2005
+ requires at least part of the tags to be dynamically
+ constructed for a type derived from a type at a shallower
+ level. For dynamically constructed tags, detecting the error
+ can be expensive and unreliable. To see this, consider a
+ program containing two tasks. Task A creates a nested tagged
+ type, passes the tag to task B (which saves it), and then
+ terminates. The nested tag (if dynamic) probably will need to
+ refer in some way to the stack frame for task A. If task B
+ later tries to use the tag created by task A, the tag's
+ reference to the stack frame of A probably is a dangling
+ pointer. Avoiding this would require some sort of protected
+ tag manager, which would be a bottleneck in a program's
+ performance. Moreover, we'd still have a race condition; if
+ task A terminated after the tag check, but before the tag was
+ used, we'd still have a problem. That means that all of these
+ operations would have to be serialized. That could be a
+ significant performance drain, whether or not nested tagged
+ types are ever used. Therefore, we allow execution to become
+ erroneous as we do for other dangling pointers. If the
+ implementation can detect the error, we recommend that
+ Tag_Error be raised.
+
+ _Implementation Permissions_
+
+26/2
+{AI95-00260-02AI95-00260-02} {AI95-00279-01AI95-00279-01} The
+implementation of Internal_Tag and Descendant_Tag may raise Tag_Error if
+no specific type corresponding to the string External passed as a
+parameter exists in the partition at the time the function is called, or
+if there is no such type whose innermost master is a master of the point
+of the function call.
+
+26.a/2
+ Reason: {AI95-00260-02AI95-00260-02}
+ {AI95-00279-01AI95-00279-01} {AI95-00344-01AI95-00344-01}
+ Locking would be required to ensure that the mapping of
+ strings to tags never returned tags of types which no longer
+ exist, because types can cease to exist (because they belong
+ to another task, as described above) during the execution of
+ these operations. Moreover, even if these functions did use
+ locking, that would not prevent the type from ceasing to exist
+ at the instant that the function returned. Thus, we do not
+ require the overhead of locking; hence the word "may" in this
+ rule.
+
+ _Implementation Advice_
+
+26.1/3
+{AI95-00260-02AI95-00260-02} {AI05-0113-1AI05-0113-1} Internal_Tag
+should return the tag of a type, if one exists, whose innermost master
+is a master of the point of the function call.
+
+26.b/3
+ Implementation Advice: Tags.Internal_Tag should return the tag
+ of a type, if one exists, whose innermost master is a master
+ of the point of the function call..
+
+26.c/2
+ Reason: {AI95-00260-02AI95-00260-02}
+ {AI95-00344-01AI95-00344-01} It's not helpful if Internal_Tag
+ returns the tag of some type in another task when one is
+ available in the task that made the call. We don't require
+ this behavior (because it requires the same implementation
+ techniques we decided not to insist on previously), but
+ encourage it.
+
+26.d/3
+ Discussion: {AI05-0113-1AI05-0113-1} There is no Advice for
+ the result of Internal_Tag if no such type exists. In most
+ cases, the Implementation Permission can be used to raise
+ Tag_Error, but some other tag can be returned as well.
+
+ NOTES
+
+27
+ 67 A type declared with the reserved word tagged should normally
+ be declared in a package_specification, so that new primitive
+ subprograms can be declared for it.
+
+28
+ 68 Once an object has been created, its tag never changes.
+
+29
+ 69 Class-wide types are defined to have unknown discriminants (see
+ *note 3.7::). This means that objects of a class-wide type have to
+ be explicitly initialized (whether created by an object_declaration
+ or an allocator), and that aggregates have to be explicitly
+ qualified with a specific type when their expected type is
+ class-wide.
+
+30/2
+ 70 {AI95-00260-02AI95-00260-02} {AI95-00326-01AI95-00326-01} The
+ capability provided by Tags.Generic_Dispatching_Constructor is
+ sometimes known as a factory.
+
+ _Examples_
+
+31
+Examples of tagged record types:
+
+32
+ type Point is tagged
+ record
+ X, Y : Real := 0.0;
+ end record;
+
+33
+ type Expression is tagged null record;
+ -- Components will be added by each extension
+
+ _Extensions to Ada 83_
+
+33.a
+ Tagged types are a new concept.
+
+ _Inconsistencies With Ada 95_
+
+33.b/2
+ {AI95-00279-01AI95-00279-01} Amendment Correction: Added
+ wording specifying that Internal_Tag must raise Tag_Error if
+ the tag of a library-level type has not yet been created. Ada
+ 95 gave an Implementation Permission to do this; we require it
+ to avoid erroneous execution when streaming in an object of a
+ library-level type that has not yet been elaborated. This is
+ technically inconsistent; a program that used Internal_Tag
+ outside of streaming and used a compiler that didn't take
+ advantage of the Implementation Permission would not have
+ raised Tag_Error, and may have returned a useful tag. (If the
+ tag was used in streaming, the program would have been
+ erroneous.) Since such a program would not have been portable
+ to a compiler that did take advantage of the Implementation
+ Permission, this is not a significant inconsistency.
+
+33.c/2
+ {AI95-00417-01AI95-00417-01} We now define the lower bound of
+ the string returned from [[Wide_]Wide_]Expanded_Name and
+ External_Name. This makes working with the returned string
+ easier, and is consistent with many other string-returning
+ functions in Ada. This is technically an inconsistency; if a
+ program depended on some other lower bound for the string
+ returned from one of these functions, it could fail when
+ compiled with Ada 2005. Such code is not portable even
+ between Ada 95 implementations, so it should be very rare.
+
+ _Incompatibilities With Ada 95_
+
+33.d/3
+ {AI95-00260-02AI95-00260-02} {AI95-00344-01AI95-00344-01}
+ {AI95-00400-01AI95-00400-01} {AI95-00405-01AI95-00405-01}
+ {AI05-0005-1AI05-0005-1} Constant No_Tag, and functions
+ Parent_Tag, Interface_Ancestor_Tags, Descendant_Tag,
+ Is_Descendant_At_Same_Level, Wide_Expanded_Name, and
+ Wide_Wide_Expanded_Name are added to Ada.Tags. If Ada.Tags is
+ referenced in a use_clause, and an entity E with the same
+ defining_identifier as a new entity in Ada.Tags is defined in
+ a package that is also referenced in a use_clause, the entity
+ E may no longer be use-visible, resulting in errors. This
+ should be rare and is easily fixed if it does occur.
+
+ _Extensions to Ada 95_
+
+33.e/2
+ {AI95-00362-01AI95-00362-01} Ada.Tags is now defined to be
+ preelaborated.
+
+33.f/2
+ {AI95-00260-02AI95-00260-02} Generic function
+ Tags.Generic_Dispatching_Constructor is new.
+
+ _Wording Changes from Ada 95_
+
+33.g/2
+ {AI95-00318-02AI95-00318-02} We talk about return objects
+ rather than return expressions, as functions can return using
+ an extended_return_statement.
+
+33.h/2
+ {AI95-00344-01AI95-00344-01} Added wording to define that tags
+ for all descendants of a tagged type must be distinct. This
+ is needed to ensure that more nested type extensions will work
+ properly. The wording does not require implementation changes
+ for types that were allowed in Ada 95.
+
+ _Inconsistencies With Ada 2005_
+
+33.i/3
+ {AI05-0113-1AI05-0113-1} Correction: Added wording specifying
+ that Dependent_Tag must raise Tag_Error if there is more than
+ one type which matches the requirements. If an implementation
+ had returned a random tag of the matching types, a program may
+ have worked properly. However, such a program would not be
+ portable (another implementation may return a different tag)
+ and the conditions that would cause the problem are unlikely
+ (most likely, a tagged type extension declared in a generic
+ body with multiple instances in the same scope).
+
+ _Incompatibilities With Ada 2005_
+
+33.j/3
+ {AI05-0173-1AI05-0173-1} Function Is_Abstract is added to
+ Ada.Tags. If Ada.Tags is referenced in a use_clause, and an
+ entity E with the defining_identifier Is_Abstract is defined
+ in a package that is also referenced in a use_clause, the
+ entity E may no longer be use-visible, resulting in errors.
+ This should be rare and is easily fixed if it does occur.
+
+ _Wording Changes from Ada 2005_
+
+33.k/3
+ {AI05-0115-1AI05-0115-1} Correction: We explicitly define the
+ meaning of "descendant" at runtime, so that it does not depend
+ on visibility as does the usual meaning.
+
+* Menu:
+
+* 3.9.1 :: Type Extensions
+* 3.9.2 :: Dispatching Operations of Tagged Types
+* 3.9.3 :: Abstract Types and Subprograms
+* 3.9.4 :: Interface Types
+
+\1f
+File: aarm2012.info, Node: 3.9.1, Next: 3.9.2, Up: 3.9
+
+3.9.1 Type Extensions
+---------------------
+
+1/2
+{AI95-00345-01AI95-00345-01} [ Every type extension is a tagged type,
+and is a record extension or a private extension of some other tagged
+type, or a noninterface synchronized tagged type.]
+
+ _Language Design Principles_
+
+1.a
+ We want to make sure that we can extend a generic formal
+ tagged type, without knowing its discriminants.
+
+1.b
+ We don't want to allow components in an extension aggregate to
+ depend on discriminants inherited from the parent value, since
+ such dependence requires staticness in aggregates, at least
+ for variants.
+
+ _Syntax_
+
+2
+ record_extension_part ::= with record_definition
+
+ _Legality Rules_
+
+3/2
+{AI95-00344-01AI95-00344-01} {AI95-00345-01AI95-00345-01}
+{AI95-00419-01AI95-00419-01} The parent type of a record extension shall
+not be a class-wide type nor shall it be a synchronized tagged type (see
+*note 3.9.4::). If the parent type or any progenitor is nonlimited,
+then each of the components of the record_extension_part shall be
+nonlimited. In addition to the places where Legality Rules normally
+apply (see *note 12.3::), these rules apply also in the private part of
+an instance of a generic unit.
+
+3.a
+ Reason: If the parent is a limited formal type, then the
+ actual might be nonlimited.
+
+3.b/2
+ {AI95-00344-01AI95-00344-01} Ada 95 required the record
+ extensions to be the same level as the parent type. Now we
+ use accessibility checks on class-wide allocators and return
+ statements to prevent objects from living longer than their
+ type.
+
+3.c/2
+ {AI95-00345-01AI95-00345-01} Synchronized tagged types cannot
+ be extended. We have this limitation so that all of the data
+ of a task or protected type is defined within the type. Data
+ defined outside of the type wouldn't be subject to the mutual
+ exclusion properties of a protected type, and couldn't be used
+ by a task, and thus doesn't seem to be worth the potential
+ impact on implementations.
+
+4/2
+{AI95-00344-01AI95-00344-01} Within the body of a generic unit, or the
+body of any of its descendant library units, a tagged type shall not be
+declared as a descendant of a formal type declared within the formal
+part of the generic unit.
+
+4.a
+ Reason: This paragraph ensures that a dispatching call will
+ never attempt to execute an inaccessible subprogram body.
+
+4.a.1/2
+ {AI95-00344-01AI95-00344-01} The convoluted wording ("formal
+ type declared within the formal part") is necessary to include
+ tagged types that are formal parameters of formal packages of
+ the generic unit, as well as formal tagged and tagged formal
+ derived types of the generic unit.
+
+4.b/2
+ {AI95-00344-01AI95-00344-01} This rule is necessary in order
+ to preserve the contract model.
+
+4.c/2
+ {AI05-0005-1AI05-0005-1} {AI95-00344-01AI95-00344-01} If an
+ ancestor is a formal of the generic unit , we have a problem
+ because it might have an unknown number of subprograms that
+ require overriding, as in the following example:
+
+4.d/2
+ package P is
+ type T is tagged null record;
+ function F return T; -- Inherited versions will require overriding.
+ end P;
+
+4.e
+ generic
+ type TT is tagged private;
+ package Gp is
+ type NT is abstract new TT with null record;
+ procedure Q(X : in NT) is abstract;
+ end Gp;
+
+4.f/2
+ package body Gp is
+ type NT2 is new NT with null record; -- Illegal!
+ procedure Q(X : in NT2) is begin null; end Q;
+ -- Is this legal or not? Can't decide because
+ -- we don't know whether TT had any functions that require
+ -- overriding on extension.
+ end Gp;
+
+4.g
+ package I is new Gp(TT => P.T);
+
+4.h/2
+ I.NT is an abstract type with two abstract subprograms: F
+ (inherited as abstract) and Q (explicitly declared as
+ abstract). But the generic body doesn't know about F, so we
+ don't know that it needs to be overridden to make a
+ nonabstract extension of NT.Hence, we have to disallow this
+ case.
+
+4.h.1/2
+ Similarly, since the actual type for a formal tagged limited
+ private type can be a nonlimited type, we would have a problem
+ if a type extension of a limited private formal type could be
+ declared in a generic body. Such an extension could have a
+ task component, for example, and an object of that type could
+ be passed to a dispatching operation of a nonlimited ancestor
+ type. That operation could try to copy the object with the
+ task component. That would be bad. So we disallow this as
+ well.
+
+4.i
+ If TT were declared as abstract, then we could have the same
+ problem with abstract procedures.
+
+4.j
+ We considered disallowing all tagged types in a generic body,
+ for simplicity. We decided not to go that far, in order to
+ avoid unnecessary restrictions.
+
+4.k
+ We also considered trying make the accessibility level part of
+ the contract; i.e. invent some way of saying (in the
+ generic_declaration) "all instances of this generic unit will
+ have the same accessibility level as the generic_declaration."
+ Unfortunately, that doesn't solve the part of the problem
+ having to do with abstract types.
+
+4.l/2
+ This paragraph was deleted.
+
+4.m/2
+ Ramification: {AI95-00344AI95-00344} This rule applies to
+ types with ancestors (directly or indirectly) of formal
+ interface types (see *note 12.5.5::), formal tagged private
+ types (see *note 12.5.1::), and formal derived private types
+ whose ancestor type is tagged (see *note 12.5.1::).
+
+ _Static Semantics_
+
+4.1/2
+{AI95-00391-01AI95-00391-01} A record extension is a null extension if
+its declaration has no known_discriminant_part and its
+record_extension_part includes no component_declarations.
+
+ _Dynamic Semantics_
+
+5
+The elaboration of a record_extension_part consists of the elaboration
+of the record_definition.
+
+ NOTES
+
+6
+ 71 The term "type extension" refers to a type as a whole. The
+ term "extension part" refers to the piece of text that defines the
+ additional components (if any) the type extension has relative to
+ its specified ancestor type.
+
+6.a
+ Discussion: We considered other terminology, such as "extended
+ type." However, the terms "private extended type" and "record
+ extended type" did not convey the proper meaning. Hence, we
+ have chosen to uniformly use the term "extension" as the type
+ resulting from extending a type, with "private extension"
+ being one produced by privately extending the type, and
+ "record extension" being one produced by extending the type
+ with an additional record-like set of components. Note also
+ that the term "type extension" refers to the result of
+ extending a type in the language Oberon as well (though there
+ the term "extended type" is also used, interchangeably,
+ perhaps because Oberon doesn't have the concept of a "private
+ extension").
+
+7/2
+ 72 {AI95-00344-01AI95-00344-01} When an extension is declared
+ immediately within a body, primitive subprograms are inherited and
+ are overridable, but new primitive subprograms cannot be added.
+
+8
+ 73 A name that denotes a component (including a discriminant) of
+ the parent type is not allowed within the record_extension_part.
+ Similarly, a name that denotes a component defined within the
+ record_extension_part is not allowed within the
+ record_extension_part. It is permissible to use a name that
+ denotes a discriminant of the record extension, providing there is
+ a new known_discriminant_part in the enclosing type declaration.
+ (The full rule is given in *note 3.8::.)
+
+8.a
+ Reason: The restriction against depending on discriminants of
+ the parent is to simplify the definition of extension
+ aggregates. The restriction against using parent components
+ in other ways is methodological; it presumably simplifies
+ implementation as well.
+
+9
+ 74 Each visible component of a record extension has to have a
+ unique name, whether the component is (visibly) inherited from the
+ parent type or declared in the record_extension_part (see *note
+ 8.3::).
+
+ _Examples_
+
+10
+Examples of record extensions (of types defined above in *note 3.9::):
+
+11
+ type Painted_Point is new Point with
+ record
+ Paint : Color := White;
+ end record;
+ -- Components X and Y are inherited
+
+12
+ Origin : constant Painted_Point := (X | Y => 0.0, Paint => Black);
+
+13
+ type Literal is new Expression with
+ record -- a leaf in an Expression tree
+ Value : Real;
+ end record;
+
+14
+ type Expr_Ptr is access all Expression'Class;
+ -- see *note 3.10::
+
+15
+ type Binary_Operation is new Expression with
+ record -- an internal node in an Expression tree
+ Left, Right : Expr_Ptr;
+ end record;
+
+16
+ type Addition is new Binary_Operation with null record;
+ type Subtraction is new Binary_Operation with null record;
+ -- No additional components needed for these extensions
+
+17
+ Tree : Expr_Ptr := -- A tree representation of "5.0 + (13.0-7.0)"
+ new Addition'(
+ Left => new Literal'(Value => 5.0),
+ Right => new Subtraction'(
+ Left => new Literal'(Value => 13.0),
+ Right => new Literal'(Value => 7.0)));
+
+ _Extensions to Ada 83_
+
+17.a
+ Type extension is a new concept.
+
+ _Extensions to Ada 95_
+
+17.b/2
+ {AI95-00344-01AI95-00344-01} Type extensions now can be
+ declared in more nested scopes than their parent types.
+ Additional accessibility checks on allocators and return
+ statements prevent objects from outliving their type.
+
+ _Wording Changes from Ada 95_
+
+17.c/2
+ {AI95-00345-01AI95-00345-01} Added wording to prevent
+ extending synchronized tagged types.
+
+17.d/2
+ {AI95-00391-01AI95-00391-01} Defined null extension for use
+ elsewhere.
+
+\1f
+File: aarm2012.info, Node: 3.9.2, Next: 3.9.3, Prev: 3.9.1, Up: 3.9
+
+3.9.2 Dispatching Operations of Tagged Types
+--------------------------------------------
+
+1/2
+{AI95-00260-02AI95-00260-02} {AI95-00335-01AI95-00335-01} The primitive
+subprograms of a tagged type, the subprograms declared by
+formal_abstract_subprogram_declaration (*note 12.6: S0297.)s, and the
+stream attributes of a specific tagged type that are available (see
+*note 13.13.2::) at the end of the declaration list where the type is
+declared are called dispatching operations. [A dispatching operation
+can be called using a statically determined controlling tag, in which
+case the body to be executed is determined at compile time.
+Alternatively, the controlling tag can be dynamically determined, in
+which case the call dispatches to a body that is determined at run
+time;] such a call is termed a dispatching call. [As explained below,
+the properties of the operands and the context of a particular call on a
+dispatching operation determine how the controlling tag is determined,
+and hence whether or not the call is a dispatching call. Run-time
+polymorphism is achieved when a dispatching operation is called by a
+dispatching call.]
+
+1.a.1/2
+ Reason: {AI95-00335-01AI95-00335-01} For the stream attributes
+ of a type declared immediately within a package_specification
+ that has a partial view, the declaration list to consider is
+ the visible part of the package. Stream attributes that are
+ not available in the same declaration list are not dispatching
+ as there is no guarantee that descendants of the type have
+ available attributes (there is such a guarantee for visibly
+ available attributes). If we allowed dispatching for any
+ available attribute, then for attributes defined in the
+ private part we could end up executing a nonexistent body.
+
+ _Language Design Principles_
+
+1.a
+ The controlling tag determination rules are analogous to the
+ overload resolution rules, except they deal with run-time type
+ identification (tags) rather than compile-time type
+ resolution. As with overload resolution, controlling tag
+ determination may depend on operands or result context.
+
+ _Static Semantics_
+
+2/3
+{AI95-00260-02AI95-00260-02} {AI95-00416-01AI95-00416-01}
+{AI05-0076-1AI05-0076-1} A call on a dispatching operation is a call
+whose name or prefix denotes the declaration of a dispatching operation.
+A controlling operand in a call on a dispatching operation of a tagged
+type T is one whose corresponding formal parameter is of type T or is of
+an anonymous access type with designated type T; the corresponding
+formal parameter is called a controlling formal parameter. If the
+controlling formal parameter is an access parameter, the controlling
+operand is the object designated by the actual parameter, rather than
+the actual parameter itself. If the call is to a (primitive) function
+with result type T (a function with a controlling result), then the call
+has a controlling result -- the context of the call can control the
+dispatching. Similarly, if the call is to a function with an access
+result type designating T (a function with a controlling access result),
+then the call has a controlling access result, and the context can
+similarly control dispatching.
+
+2.a
+ Ramification: This definition implies that a call through the
+ dereference of an access-to-subprogram value is never
+ considered a call on a dispatching operation. Note also that
+ if the prefix denotes a renaming_declaration, the place where
+ the renaming occurs determines whether it is primitive; the
+ thing being renamed is irrelevant.
+
+3
+A name or expression of a tagged type is either statically tagged,
+dynamically tagged, or tag indeterminate, according to whether, when
+used as a controlling operand, the tag that controls dispatching is
+determined statically by the operand's (specific) type, dynamically by
+its tag at run time, or from context. A qualified_expression or
+parenthesized expression is statically, dynamically, or indeterminately
+tagged according to its operand. For other kinds of names and
+expressions, this is determined as follows:
+
+4/2
+ * {AI95-00416-01AI95-00416-01} The name or expression is statically
+ tagged if it is of a specific tagged type and, if it is a call with
+ a controlling result or controlling access result, it has at least
+ one statically tagged controlling operand;
+
+4.a
+ Discussion: It is illegal to have both statically tagged and
+ dynamically tagged controlling operands in the same call --
+ see below.
+
+5/2
+ * {AI95-00416-01AI95-00416-01} The name or expression is dynamically
+ tagged if it is of a class-wide type, or it is a call with a
+ controlling result or controlling access result and at least one
+ dynamically tagged controlling operand;
+
+6/2
+ * {AI95-00416-01AI95-00416-01} The name or expression is tag
+ indeterminate if it is a call with a controlling result or
+ controlling access result, all of whose controlling operands (if
+ any) are tag indeterminate.
+
+7/1
+{8652/00108652/0010} {AI95-00127-01AI95-00127-01} [A type_conversion is
+statically or dynamically tagged according to whether the type
+determined by the subtype_mark is specific or class-wide, respectively.]
+For an object that is designated by an expression whose expected type is
+an anonymous access-to-specific tagged type, the object is dynamically
+tagged if the expression, ignoring enclosing parentheses, is of the form
+X'Access, where X is of a class-wide type, or is of the form new
+T'(...), where T denotes a class-wide subtype. Otherwise, the object is
+statically or dynamically tagged according to whether the designated
+type of the type of the expression is specific or class-wide,
+respectively.
+
+7.a
+ Ramification: A type_conversion is never tag indeterminate,
+ even if its operand is. A designated object is never tag
+ indeterminate.
+
+7.a.1/1
+ {8652/00108652/0010} {AI95-00127-01AI95-00127-01} Allocators
+ and access attributes of class-wide types can be used as the
+ controlling parameters of dispatching calls.
+
+ _Legality Rules_
+
+8
+A call on a dispatching operation shall not have both dynamically tagged
+and statically tagged controlling operands.
+
+8.a
+ Reason: This restriction is intended to minimize confusion
+ between whether the dynamically tagged operands are implicitly
+ converted to, or tag checked against the specific type of the
+ statically tagged operand(s).
+
+9/1
+{8652/00108652/0010} {AI95-00127-01AI95-00127-01} If the expected type
+for an expression or name is some specific tagged type, then the
+expression or name shall not be dynamically tagged unless it is a
+controlling operand in a call on a dispatching operation. Similarly, if
+the expected type for an expression is an anonymous access-to-specific
+tagged type, then the object designated by the expression shall not be
+dynamically tagged unless it is a controlling operand in a call on a
+dispatching operation.
+
+9.a
+ Reason: This prevents implicit "truncation" of a
+ dynamically-tagged value to the specific type of the target
+ object/formal. An explicit conversion is required to request
+ this truncation.
+
+9.b/2
+ Ramification: {AI95-00252-01AI95-00252-01} This rule applies
+ to all expressions or names with a specific expected type, not
+ just those that are actual parameters to a dispatching call.
+ This rule does not apply to a membership test whose expression
+ is class-wide, since any type that covers the tested type is
+ explicitly allowed. See *note 4.5.2::. This rule also
+ doesn't apply to a selected_component whose selector_name is a
+ subprogram, since the rules explicitly say that the prefix may
+ be class-wide (see *note 4.1.3::).
+
+10/2
+{8652/00118652/0011} {AI95-00117-01AI95-00117-01}
+{AI95-00430-01AI95-00430-01} In the declaration of a dispatching
+operation of a tagged type, everywhere a subtype of the tagged type
+appears as a subtype of the profile (see *note 6.1::), it shall
+statically match the first subtype of the tagged type. If the
+dispatching operation overrides an inherited subprogram, it shall be
+subtype conformant with the inherited subprogram. The convention of an
+inherited dispatching operation is the convention of the corresponding
+primitive operation of the parent or progenitor type. The default
+convention of a dispatching operation that overrides an inherited
+primitive operation is the convention of the inherited operation; if the
+operation overrides multiple inherited operations, then they shall all
+have the same convention. An explicitly declared dispatching operation
+shall not be of convention Intrinsic.
+
+10.a
+ Reason: These rules ensure that constraint checks can be
+ performed by the caller in a dispatching call, and parameter
+ passing conventions match up properly. A special rule on
+ aggregates prevents values of a tagged type from being created
+ that are outside of its first subtype.
+
+11/2
+{AI95-00416-01AI95-00416-01} The default_expression for a controlling
+formal parameter of a dispatching operation shall be tag indeterminate.
+
+11.a/2
+ Reason: {AI95-00416-01AI95-00416-01} This rule ensures that
+ the default_expression always produces the "correct" tag when
+ called with or without dispatching, or when inherited by a
+ descendant. If it were statically tagged, the default would
+ be useless for a dispatching call; if it were dynamically
+ tagged, the default would be useless for a nondispatching
+ call.
+
+11.1/2
+{AI95-00404-01AI95-00404-01} If a dispatching operation is defined by a
+subprogram_renaming_declaration or the instantiation of a generic
+subprogram, any access parameter of the renamed subprogram or the
+generic subprogram that corresponds to a controlling access parameter of
+the dispatching operation, shall have a subtype that excludes null.
+
+12
+A given subprogram shall not be a dispatching operation of two or more
+distinct tagged types.
+
+12.a
+ Reason: This restriction minimizes confusion since multiple
+ dispatching is not provided. The normal solution is to
+ replace all but one of the tagged types with their class-wide
+ types.
+
+12.a.1/1
+ Ramification: {8652/00988652/0098}
+ {AI95-00183-01AI95-00183-01} This restriction applies even if
+ the partial view (see *note 7.3::) of one or both of the types
+ is untagged. This follows from the definition of dispatching
+ operation: the operation is a dispatching operation anywhere
+ the full views of the (tagged) types are visible.
+
+13
+The explicit declaration of a primitive subprogram of a tagged type
+shall occur before the type is frozen (see *note 13.14::). [For
+example, new dispatching operations cannot be added after objects or
+values of the type exist, nor after deriving a record extension from it,
+nor after a body.]
+
+13.a/2
+ Reason: {AI95-00344-01AI95-00344-01} This rule is needed
+ because (1) we don't want people dispatching to things that
+ haven't been declared yet, and (2) we want to allow the static
+ part of tagged type descriptors to be static (allocated
+ statically, and initialized to link-time-known symbols).
+ Suppose T2 inherits primitive P from T1, and then overrides P.
+ Suppose P is called before the declaration of the overriding
+ P. What should it dispatch to? If the answer is the new P,
+ we've violated the first principle above. If the answer is
+ the old P, we've violated the second principle. (A call to
+ the new one necessarily raises Program_Error, but that's
+ beside the point.)
+
+13.b
+ Note that a call upon a dispatching operation of type T will
+ freeze T.
+
+13.c
+ We considered applying this rule to all derived types, for
+ uniformity. However, that would be upward incompatible, so we
+ rejected the idea. As in Ada 83, for an untagged type, the
+ above call upon P will call the old P (which is arguably
+ confusing).
+
+13.d/2
+ Implementation Note: {AI95-00326-01AI95-00326-01} Because of
+ this rule, the type descriptor can be created (presumably
+ containing linker symbols pointing at the not-yet-compiled
+ bodies) at the first freezing point of the type. It also
+ prevents, for a (nonincomplete) tagged type declared in a
+ package_specification, overriding in the body or by a child
+ subprogram.
+
+13.e/2
+ Ramification: {AI95-00251-01AI95-00251-01} A consequence is
+ that for a tagged type declaration in a declarative_part, only
+ the last (overriding) primitive subprogram can be declared by
+ a subprogram_body. (Other overridings must be provided by
+ subprogram_declarations.)
+
+13.f/3
+ To be honest: {AI05-0222-1AI05-0222-1} This rule applies only
+ to "original" declarations and not to the completion of a
+ primitive subprogram, even though a completion is technically
+ an explicit declaration, and it may declare a primitive
+ subprogram.
+
+ _Dynamic Semantics_
+
+14
+For the execution of a call on a dispatching operation of a type T, the
+controlling tag value determines which subprogram body is executed. The
+controlling tag value is defined as follows:
+
+15
+ * If one or more controlling operands are statically tagged, then the
+ controlling tag value is statically determined to be the tag of T.
+
+16
+ * If one or more controlling operands are dynamically tagged, then
+ the controlling tag value is not statically determined, but is
+ rather determined by the tags of the controlling operands. If
+ there is more than one dynamically tagged controlling operand, a
+ check is made that they all have the same tag. If this check
+ fails, Constraint_Error is raised unless the call is a
+ function_call whose name denotes the declaration of an equality
+ operator (predefined or user defined) that returns Boolean, in
+ which case the result of the call is defined to indicate
+ inequality, and no subprogram_body is executed. This check is
+ performed prior to evaluating any tag-indeterminate controlling
+ operands.
+
+16.a
+ Reason: Tag mismatch is considered an error (except for "="
+ and "/=") since the corresponding primitive subprograms in
+ each specific type expect all controlling operands to be of
+ the same type. For tag mismatch with an equality operator,
+ rather than raising an exception, "=" returns False and "/="
+ returns True. No equality operator is actually invoked, since
+ there is no common tag value to control the dispatch.
+ Equality is a special case to be consistent with the existing
+ Ada 83 principle that equality comparisons, even between
+ objects with different constraints, never raise
+ Constraint_Error.
+
+17/2
+ * {AI95-00196-01AI95-00196-01} If all of the controlling operands (if
+ any) are tag-indeterminate, then:
+
+18/2
+ * {AI95-00239-01AI95-00239-01} {AI95-00416-01AI95-00416-01}
+ If the call has a controlling result or controlling
+ access result and is itself, or designates, a (possibly
+ parenthesized or qualified) controlling operand of an
+ enclosing call on a dispatching operation of a descendant
+ of type T, then its controlling tag value is determined
+ by the controlling tag value of this enclosing call;
+
+18.a/2
+ Discussion: {AI95-00239-01AI95-00239-01} For code that a user
+ can write explicitly, the only contexts that can control
+ dispatching of a function with a controlling result of type T
+ are those that involve controlling operands of the same type
+ T: if the two types differ there is an illegality and the
+ dynamic semantics are irrelevant.
+
+18.b/2
+ In the case of an inherited subprogram however, if a default
+ expression is a function call, it may be of type T while the
+ parameter is of a type derived from T. To cover this case, we
+ talk about "a descendant of T" above. This is safe, because
+ if the type of the parameter is descended from the type of the
+ function result, it is guaranteed to inherit or override the
+ function, and this ensures that there will be an appropriate
+ body to dispatch to. Note that abstract functions are not an
+ issue here because the call to the function is a dispatching
+ call, so it is guaranteed to always land on a concrete body.
+
+18.1/2
+ * {AI95-00196-01AI95-00196-01} {AI95-00416-01AI95-00416-01}
+ If the call has a controlling result or controlling
+ access result and (possibly parenthesized, qualified, or
+ dereferenced) is the expression of an
+ assignment_statement whose target is of a class-wide
+ type, then its controlling tag value is determined by the
+ target;
+
+19
+ * Otherwise, the controlling tag value is statically
+ determined to be the tag of type T.
+
+19.a
+ Ramification: This includes the cases of a tag-indeterminate
+ procedure call, and a tag-indeterminate function_call that is
+ used to initialize a class-wide formal parameter or class-wide
+ object.
+
+20/3
+{AI95-00345-01AI95-00345-01} {AI05-0126-1AI05-0126-1} For the execution
+of a call on a dispatching operation, the action performed is determined
+by the properties of the corresponding dispatching operation of the
+specific type identified by the controlling tag value:
+
+20.1/3
+ * {AI05-0126-1AI05-0126-1} if the corresponding operation is
+ explicitly declared for this type, [even if the declaration occurs
+ in a private part], then the action comprises an invocation of the
+ explicit body for the operation;
+
+20.2/3
+ * {AI95-00345-01AI95-00345-01} {AI05-0126-1AI05-0126-1} if the
+ corresponding operation is implicitly declared for this type and is
+ implemented by an entry or protected subprogram (see *note 9.1::
+ and *note 9.4::), then the action comprises a call on this entry or
+ protected subprogram, with the target object being given by the
+ first actual parameter of the call, and the actual parameters of
+ the entry or protected subprogram being given by the remaining
+ actual parameters of the call, if any;
+
+20.3/3
+ * {AI05-0197-1AI05-0197-1} if the corresponding operation is a
+ predefined operator then the action comprises an invocation of that
+ operator;
+
+20.4/3
+ * {AI95-00345-01AI95-00345-01} {AI05-0126-1AI05-0126-1}
+ {AI05-0197-1AI05-0197-1} {AI05-0250-1AI05-0250-1}
+ {AI05-0254-1AI05-0254-1} otherwise, the action is the same as the
+ action for the corresponding operation of the parent type or
+ progenitor type from which the operation was inherited except that
+ additional invariant checks (see *note 7.3.2::) and class-wide
+ postcondition checks (see *note 6.1.1::) may apply. If there is
+ more than one such corresponding operation, the action is that for
+ the operation that is not a null procedure, if any; otherwise, the
+ action is that of an arbitrary one of the operations.
+
+20.a/3
+ This paragraph was deleted.{AI05-0126-1AI05-0126-1}
+
+20.a.1/3
+ Ramification: {AI05-0005-1AI05-0005-1}
+ {AI05-0126-1AI05-0126-1} "Corresponding dispatching operation"
+ refers to the inheritance relationship between subprograms.
+ Primitive operations are always inherited for a type T, but
+ they might not be declared if the primitive operation is never
+ visible within the immediate scope of the type T. If no
+ corresponding operation is declared, the last bullet is used
+ and the corresponding operation of the parent type is executed
+ (an explicit body that happens to have the same name and
+ profile is not called in that case).
+
+20.a.2/3
+ {AI05-0005-1AI05-0005-1} {AI05-0126-1AI05-0126-1} We have to
+ talk about progenitors in the last bullet in case the
+ corresponding operation is a null procedure inherited from an
+ interface. In that case, the parent type might not even have
+ the operation in question.
+
+20.a.3/3
+ {AI05-0197-1AI05-0197-1} For the last bullet, if there are
+ multiple corresponding operations for the parent and
+ progenitors, all but one of them have to be a null procedure.
+ (If the progenitors declared abstract routines, there would
+ have to be an explicit overriding of the operation, and then
+ the first bullet would apply.) We call the nonnull routine if
+ one exists.
+
+20.a.4/3
+ {AI05-0126-1AI05-0126-1} Any explicit declaration for an
+ inherited corresponding operation has to be an overriding
+ routine. These rules mean that a dispatching call executes
+ the overriding routine (if any) for the specific type.
+
+20.b/3
+ Reason: {AI05-0005-1AI05-0005-1} The wording of the above
+ rules is intended to ensure that the same body is executed for
+ a given tag, whether that tag is determined statically or
+ dynamically. For a type declared in a package, it doesn't
+ matter whether a given subprogram is overridden in the visible
+ part or the private part, and it doesn't matter whether the
+ call is inside or outside the package. For example:
+
+20.c
+ package P1 is
+ type T1 is tagged null record;
+ procedure Op_A(Arg : in T1);
+ procedure Op_B(Arg : in T1);
+ end P1;
+
+20.d
+ with P1; use P1;
+ package P2 is
+ type T2 is new T1 with null record;
+ procedure Op_A(Param : in T2);
+ private
+ procedure Op_B(Param : in T2);
+ end P2;
+
+20.e/1
+ with P1; with P2;
+ procedure Main is
+ X : P2.T2;
+ Y : P1.T1'Class := X;
+ begin
+ P2.Op_A(Param => X); -- Nondispatching call to a dispatching operation.
+ P1.Op_A(Arg => Y); -- Dispatching call.
+ P2.Op_B(Arg => X); -- Nondispatching call to a dispatching operation.
+ P1.Op_B(Arg => Y); -- Dispatching call.
+ end Main;
+
+20.f
+ The two calls to Op_A both execute the body of Op_A that has
+ to occur in the body of package P2. Similarly, the two calls
+ to Op_B both execute the body of Op_B that has to occur in the
+ body of package P2, even though Op_B is overridden in the
+ private part of P2. Note, however, that the formal parameter
+ names are different for P2.Op_A versus P2.Op_B. The overriding
+ declaration for P2.Op_B is not visible in Main, so the name in
+ the call actually denotes the implicit declaration of Op_B
+ inherited from T1.
+
+20.g
+ If a call occurs in the program text before an overriding,
+ which can happen only if the call is part of a default
+ expression, the overriding will still take effect for that
+ call.
+
+20.h
+ Implementation Note: Even when a tag is not statically
+ determined, a compiler might still be able to figure it out
+ and thereby avoid the overhead of run-time dispatching.
+
+ NOTES
+
+21
+ 75 The body to be executed for a call on a dispatching operation
+ is determined by the tag; it does not matter whether that tag is
+ determined statically or dynamically, and it does not matter
+ whether the subprogram's declaration is visible at the place of the
+ call.
+
+22/2
+ 76 {AI95-00260-02AI95-00260-02} This subclause covers calls on
+ dispatching subprograms of a tagged type. Rules for tagged type
+ membership tests are described in *note 4.5.2::. Controlling tag
+ determination for an assignment_statement is described in *note
+ 5.2::.
+
+23
+ 77 A dispatching call can dispatch to a body whose declaration is
+ not visible at the place of the call.
+
+24
+ 78 A call through an access-to-subprogram value is never a
+ dispatching call, even if the access value designates a dispatching
+ operation. Similarly a call whose prefix denotes a
+ subprogram_renaming_declaration cannot be a dispatching call unless
+ the renaming itself is the declaration of a primitive subprogram.
+
+ _Extensions to Ada 83_
+
+24.a
+ The concept of dispatching operations is new.
+
+ _Incompatibilities With Ada 95_
+
+24.b/2
+ {AI95-00404-01AI95-00404-01} If a dispatching operation is
+ defined by a subprogram_renaming_declaration, and it has a
+ controlling access parameter, Ada 2005 requires the subtype of
+ the parameter to exclude null. The same applies to
+ instantiations. This is required so that all calls to the
+ subprogram operate the same way (controlling access parameters
+ have to exclude null so that dispatching calls will work).
+ Since Ada 95 didn't have the notion of access subtypes that
+ exclude null, and all access parameters excluded null, it had
+ no such rules. These rules will require the addition of an
+ explicit not null on nondispatching operations that are later
+ renamed to be dispatching, or on a generic that is used to
+ define a dispatching operation.
+
+ _Extensions to Ada 95_
+
+24.c/2
+ {AI95-00416-01AI95-00416-01} Functions that have an access
+ result type can be dispatching in the same way as a function
+ that returns a tagged object directly.
+
+ _Wording Changes from Ada 95_
+
+24.d/3
+ {8652/00108652/0010} {AI95-00127-01AI95-00127-01}
+ {AI05-0299-1AI05-0299-1} Corrigendum: Allocators and access
+ attributes of objects of class-wide types can be used as the
+ controlling parameter in a dispatching calls. This was an
+ oversight in the definition of Ada 95. (See *note 3.10.2::
+ and *note 4.8::).
+
+24.e/2
+ {8652/00118652/0011} {AI95-00117-01AI95-00117-01}
+ {AI95-00430-01AI95-00430-01} Corrigendum: Corrected the
+ conventions of dispatching operations. This is extended in
+ Ada 2005 to cover operations inherited from progenitors, and
+ to ensure that the conventions of all inherited operations are
+ the same.
+
+24.f/2
+ {AI95-00196-01AI95-00196-01} Clarified the wording to ensure
+ that functions with no controlling operands are
+ tag-indeterminate, and to describe that the controlling tag
+ can come from the target of an assignment_statement.
+
+24.g/2
+ {AI95-00239-01AI95-00239-01} Fixed the wording to cover
+ default expressions inherited by derived subprograms. A
+ literal reading of the old wording would have implied that
+ operations would be called with objects of the wrong type.
+
+24.h/2
+ {AI95-00260-02AI95-00260-02} An abstract formal subprogram is
+ a dispatching operation, even though it is not a primitive
+ operation. See *note 12.6::, "*note 12.6:: Formal
+ Subprograms".
+
+24.i/2
+ {AI95-00345-01AI95-00345-01} Dispatching calls include
+ operations implemented by entries and protected operations, so
+ we have to update the wording to reflect that.
+
+24.j/2
+ {AI95-00335-01AI95-00335-01} A stream attribute of a tagged
+ type is usually a dispatching operation, even though it is not
+ a primitive operation. If they weren't dispatching,
+ T'Class'Input and T'Class'Output wouldn't work.
+
+ _Wording Changes from Ada 2005_
+
+24.k/3
+ {AI05-0076-1AI05-0076-1} Correction: Defined "function with a
+ controlling result", as it is used in *note 3.9.3::.
+
+24.l/3
+ {AI05-0126-1AI05-0126-1} {AI05-0197-1AI05-0197-1} Correction:
+ Corrected holes in the definition of dynamic dispatching: the
+ behavior for operations that are never declared and/or
+ inherited from a progenitor were not specified.
+
+\1f
+File: aarm2012.info, Node: 3.9.3, Next: 3.9.4, Prev: 3.9.2, Up: 3.9
+
+3.9.3 Abstract Types and Subprograms
+------------------------------------
+
+1/2
+{AI95-00345-01AI95-00345-01} [ An abstract type is a tagged type
+intended for use as an ancestor of other types, but which is not allowed
+to have objects of its own. An abstract subprogram is a subprogram that
+has no body, but is intended to be overridden at some point when
+inherited. Because objects of an abstract type cannot be created, a
+dispatching call to an abstract subprogram always dispatches to some
+overriding body.]
+
+1.a.1/2
+ Glossary entry: An abstract type is a tagged type intended for
+ use as an ancestor of other types, but which is not allowed to
+ have objects of its own.
+
+ _Language Design Principles_
+
+1.a/3
+ {AI05-0299-1AI05-0299-1} An abstract subprogram has no body,
+ so the rules in this subclause are designed to ensure (at
+ compile time) that the body will never be invoked. We do so
+ primarily by disallowing the creation of values of the
+ abstract type. Therefore, since type conversion and parameter
+ passing don't change the tag, we know we will never get a
+ class-wide value with a tag identifying an abstract type.
+ This means that we only have to disallow nondispatching calls
+ on abstract subprograms (dispatching calls will never reach
+ them).
+
+ _Syntax_
+
+1.1/3
+ {AI95-00218-03AI95-00218-03} {AI95-00348-01AI95-00348-01}
+ {AI05-0183-1AI05-0183-1} abstract_subprogram_declaration ::=
+ [overriding_indicator]
+ subprogram_specification is abstract
+ [aspect_specification];
+
+ _Static Semantics_
+
+1.2/2
+{AI95-00345-01AI95-00345-01} Interface types (see *note 3.9.4::) are
+abstract types. In addition, a tagged type that has the reserved word
+abstract in its declaration is an abstract type. The class-wide type
+(see *note 3.4.1::) rooted at an abstract type is not itself an abstract
+type.
+
+ _Legality Rules_
+
+2/2
+{AI95-00345-01AI95-00345-01} Only a tagged type shall have the reserved
+word abstract in its declaration.
+
+2.a
+ Ramification: Untagged types are never abstract, even though
+ they can have primitive abstract subprograms. Such
+ subprograms cannot be called, unless they also happen to be
+ dispatching operations of some tagged type, and then only via
+ a dispatching call.
+
+2.b
+ Class-wide types are never abstract. If T is abstract, then
+ it is illegal to declare a stand-alone object of type T, but
+ it is OK to declare a stand-alone object of type T'Class; the
+ latter will get a tag from its initial value, and this tag
+ will necessarily be different from T'Tag.
+
+3/2
+{AI95-00260-02AI95-00260-02} {AI95-00348-01AI95-00348-01} A subprogram
+declared by an abstract_subprogram_declaration (*note 3.9.3: S0076.) or
+a formal_abstract_subprogram_declaration (*note 12.6: S0297.) (see *note
+12.6::) is an abstract subprogram. If it is a primitive subprogram of a
+tagged type, then the tagged type shall be abstract.
+
+3.a
+ Ramification: Note that for a private type, this applies to
+ both views. The following is illegal:
+
+3.b
+ package P is
+ type T is abstract tagged private;
+ function Foo (X : T) return Boolean is abstract; -- Illegal!
+ private
+ type T is tagged null record; -- Illegal!
+ X : T;
+ Y : Boolean := Foo (T'Class (X));
+ end P;
+
+3.c
+ The full view of T is not abstract, but has an abstract
+ operation Foo, which is illegal. The two lines marked "--
+ Illegal!" are illegal when taken together.
+
+3.d/2
+ Reason: {AI95-00310-01AI95-00310-01} We considered disallowing
+ untagged types from having abstract primitive subprograms.
+ However, we rejected that plan, because it introduced some
+ silly anomalies, and because such subprograms are harmless.
+ For example:
+
+3.e/1
+ package P is
+ type Field_Size is range 0..100;
+ type T is abstract tagged null record;
+ procedure Print(X : in T; F : in Field_Size := 0) is abstract;
+ . . .
+ package Q is
+ type My_Field_Size is new Field_Size;
+ -- implicit declaration of Print(X : T; F : My_Field_Size := 0) is abstract;
+ end Q;
+
+3.f
+ It seemed silly to make the derivative of My_Field_Size
+ illegal, just because there was an implicitly declared
+ abstract subprogram that was not primitive on some tagged
+ type. Other rules could be formulated to solve this problem,
+ but the current ones seem like the simplest.
+
+3.g/2
+ {AI95-00310-01AI95-00310-01} In Ada 2005, abstract primitive
+ subprograms of an untagged type may be used to "undefine" an
+ operation.
+
+3.h/2
+ Ramification: {AI95-00260-02AI95-00260-02} Note that the
+ second sentence does not apply to abstract formal subprograms,
+ as they are never primitive operations of a type.
+
+4/3
+{AI95-00251-01AI95-00251-01} {AI95-00334-01AI95-00334-01}
+{AI95-00391-01AI95-00391-01} {AI05-0097-1AI05-0097-1}
+{AI05-0198-1AI05-0198-1} If a type has an implicitly declared primitive
+subprogram that is inherited or is a predefined operator, and the
+corresponding primitive subprogram of the parent or ancestor type is
+abstract or is a function with a controlling access result, or if a type
+other than a nonabstract null extension inherits a function with a
+controlling result, then:
+
+4.a/3
+ Ramification: {AI05-0068-1AI05-0068-1} These rules apply to
+ each view of the type individually. That is necessary to
+ preserve privacy. For instance, in the following example:
+
+4.b/3
+ package P is
+ type I is interface;
+ procedure Op (X : I) is abstract;
+ end P;
+
+4.c/3
+ with P;
+ package Q is
+ type T is abstract new P.I with private;
+ -- Op inherited here.
+ private
+ type T is abstract new P.I with null record;
+ procedure Op (X : T) is null;
+ end Q;
+
+4.d/3
+ with Q;
+ package R is
+ type T2 is new Q.T with null record;
+ -- Illegal. Op inherited here, but requires overriding.
+ end R;
+
+4.e/3
+ If this did not depend on the view, this would be legal. But
+ in that case, the fact that Op is overridden in the private
+ part would be visible; package R would have to be illegal if
+ no overriding was in the private part.
+
+4.f/3
+ Note that this means that whether an inherited subprogram is
+ abstract or concrete depends on where it inherited. In the
+ case of Q, Q.Op in the visible part is abstract, while Q.Op in
+ the private part is concrete. That is, R is illegal since it
+ is an unrelated unit (and thus it cannot see the private
+ part), but if R had been a private child of Q, it would have
+ been legal.
+
+5/2
+ * {AI95-00251-01AI95-00251-01} {AI95-00334-01AI95-00334-01} If the
+ type is abstract or untagged, the implicitly declared subprogram is
+ abstract.
+
+5.a
+ Ramification: Note that it is possible to override a concrete
+ subprogram with an abstract one.
+
+6/2
+ * {AI95-00391-01AI95-00391-01} Otherwise, the subprogram shall be
+ overridden with a nonabstract subprogram or, in the case of a
+ private extension inheriting a function with a controlling result,
+ have a full type that is a null extension[; for a type declared in
+ the visible part of a package, the overriding may be either in the
+ visible or the private part]. Such a subprogram is said to require
+ overriding. However, if the type is a generic formal type, the
+ subprogram need not be overridden for the formal type itself; [a
+ nonabstract version will necessarily be provided by the actual
+ type.]
+
+6.a/2
+ Reason: {AI95-00228-01AI95-00228-01}
+ {AI95-00391-01AI95-00391-01} A function that returns the
+ parent type requires overriding for a type extension (or
+ becomes abstract for an abstract type) because conversion from
+ a parent type to a type extension is not defined, and function
+ return semantics is defined in terms of conversion (other than
+ for a null extension; see below). (Note that parameters of
+ mode in out or out do not have this problem, because the tag
+ of the actual is not changed.)
+
+6.b
+ Note that the overriding required above can be in the private
+ part, which allows the following:
+
+6.c
+ package Pack1 is
+ type Ancestor is abstract ...;
+ procedure Do_Something(X : in Ancestor) is abstract;
+ end Pack1;
+
+6.d
+ with Pack1; use Pack1;
+ package Pack2 is
+ type T1 is new Ancestor with record ...;
+ -- A concrete type.
+ procedure Do_Something(X : in T1); -- Have to override.
+ end Pack2;
+
+6.e
+ with Pack1; use Pack1;
+ with Pack2; use Pack2;
+ package Pack3 is
+ type T2 is new Ancestor with private;
+ -- A concrete type.
+ private
+ type T2 is new T1 with -- Parent different from ancestor.
+ record ... end record;
+ -- Here, we inherit Pack2.Do_Something.
+ end Pack3;
+
+
+6.f/2
+ {AI95-00228-01AI95-00228-01} T2 inherits an abstract
+ Do_Something, but T2 is not abstract, so Do_Something has to
+ be overridden. However, it is OK to override it in the
+ private part. In this case, we override it by inheriting a
+ concrete version from a different type. Nondispatching calls
+ to Pack3.Do_Something are allowed both inside and outside
+ package Pack3, as the client "knows" that the subprogram was
+ necessarily overridden somewhere.
+
+6.g/2
+ {AI95-00391-01AI95-00391-01} For a null extension, the result
+ of a function with a controlling result is defined in terms of
+ an extension_aggregate with a null record extension part (see
+ *note 3.4::). This means that these restrictions on functions
+ with a controlling result do not have to apply to null
+ extensions.
+
+6.h/2
+ {AI95-00391-01AI95-00391-01} However, functions with
+ controlling access results still require overriding. Changing
+ the tag in place might clobber a preexisting object, and
+ allocating new memory would possibly change the pool of the
+ object, leading to storage leaks. Moreover, copying the
+ object isn't possible for limited types. We don't need to
+ restrict functions that have an access return type of an
+ untagged type, as derived types with primitive subprograms
+ have to have the same representation as their parent type.
+
+7
+A call on an abstract subprogram shall be a dispatching call;
+[nondispatching calls to an abstract subprogram are not allowed.]
+
+7.a/2
+ Ramification: {AI95-00310-01AI95-00310-01} If an abstract
+ subprogram is not a dispatching operation of some tagged type,
+ then it cannot be called at all. In Ada 2005, such
+ subprograms are not even considered by name resolution (see
+ *note 6.4::).
+
+8/3
+{AI05-0073-1AI05-0073-1} {AI05-0203-1AI05-0203-1} The type of an
+aggregate, or of an object created by an object_declaration or an
+allocator, or a generic formal object of mode in, shall not be abstract.
+The type of the target of an assignment operation (see *note 5.2::)
+shall not be abstract. The type of a component shall not be abstract.
+If the result type of a function is abstract, then the function shall be
+abstract. If a function has an access result type designating an
+abstract type, then the function shall be abstract. The type denoted by
+a return_subtype_indication (see *note 6.5::) shall not be abstract. A
+generic function shall not have an abstract result type or an access
+result type designating an abstract type.
+
+8.a
+ Reason: This ensures that values of an abstract type cannot be
+ created, which ensures that a dispatching call to an abstract
+ subprogram will not try to execute the nonexistent body.
+
+8.b
+ Generic formal objects of mode in are like constants;
+ therefore they should be forbidden for abstract types.
+ Generic formal objects of mode in out are like renamings;
+ therefore, abstract types are OK for them, though probably not
+ terribly useful.
+
+8.c/3
+ {AI05-0073-1AI05-0073-1} Generic functions returning a formal
+ abstract type are illegal because any instance would have to
+ be instantiated with a nonabstract type in order to avoid
+ violating the function rule (generic functions cannot be
+ declared abstract). But that would be an implied contract; it
+ would be better for the contract to be explicit by the formal
+ type not being declared abstract. Moreover, the implied
+ contract does not add any capability.
+
+9
+If a partial view is not abstract, the corresponding full view shall not
+be abstract. If a generic formal type is abstract, then for each
+primitive subprogram of the formal that is not abstract, the
+corresponding primitive subprogram of the actual shall not be abstract.
+
+9.a
+ Discussion: By contrast, we allow the actual type to be
+ nonabstract even if the formal type is declared abstract.
+ Hence, the most general formal tagged type possible is "type
+ T(<>) is abstract tagged limited private;".
+
+9.b
+ For an abstract private extension declared in the visible part
+ of a package, it is only possible for the full type to be
+ nonabstract if the private extension has no abstract
+ dispatching operations.
+
+9.c/2
+ To be honest: {AI95-00294-01AI95-00294-01} In the sentence
+ about primitive subprograms above, there is some ambiguity as
+ to what is meant by "corresponding" in the case where an
+ inherited operation is overridden. This is best explained by
+ an example, where the implicit declarations are shown as
+ comments:
+
+9.d/2
+ package P1 is
+ type T1 is abstract tagged null record;
+ procedure P (X : T1); -- (1)
+ end P1;
+
+9.e/2
+ package P2 is
+ type T2 is abstract new P1.T1 with null record;
+ -- procedure P (X : T2); -- (2)
+ procedure P (X : T2) is abstract; -- (3)
+ end P2;
+
+9.f/2
+ generic
+ type D is abstract new P1.T1 with private;
+ -- procedure P (X : D); -- (4)
+ procedure G (X : D);
+
+9.g/2
+ procedure I is new G (P2.T2); -- Illegal.
+
+9.h/2
+ Type T2 inherits a nonabstract procedure P (2) from the
+ primitive procedure P (1) of T1. P (2) is overridden by the
+ explicitly declared abstract procedure P (3). Type D inherits
+ a nonabstract procedure P (4) from P (1). In instantiation I,
+ the operation corresponding to P (4) is the one which is not
+ overridden, that is, P (3): the overridden operation P (2)
+ does not "reemerge". Therefore, the instantiation is illegal.
+
+10/3
+{AI05-0073-1AI05-0073-1} For an abstract type declared in a visible
+part, an abstract primitive subprogram shall not be declared in the
+private part, unless it is overriding an abstract subprogram implicitly
+declared in the visible part. For a tagged type declared in a visible
+part, a primitive function with a controlling result or a controlling
+access result shall not be declared in the private part, unless it is
+overriding a function implicitly declared in the visible part.
+
+10.a
+ Reason: The "visible part" could be that of a package or a
+ generic package. This rule is needed because a nonabstract
+ type extension declared outside the package would not know
+ about any abstract primitive subprograms or primitive
+ functions with controlling results declared in the private
+ part, and wouldn't know that they need to be overridden with
+ nonabstract subprograms. The rule applies to a tagged record
+ type or record extension declared in a visible part, just as
+ to a tagged private type or private extension. The rule
+ applies to explicitly and implicitly declared abstract
+ subprograms:
+
+10.b
+ package Pack is
+ type T is abstract new T1 with private;
+ private
+ type T is abstract new T2 with record ... end record;
+ ...
+ end Pack;
+
+10.c
+ The above example would be illegal if T1 has a nonabstract
+ primitive procedure P, but T2 overrides P with an abstract
+ one; the private part should override P with a nonabstract
+ version. On the other hand, if the P were abstract for both
+ T1 and T2, the example would be legal as is.
+
+11/2
+{AI95-00260-02AI95-00260-02} A generic actual subprogram shall not be an
+abstract subprogram unless the generic formal subprogram is declared by
+a formal_abstract_subprogram_declaration. The prefix of an
+attribute_reference for the Access, Unchecked_Access, or Address
+attributes shall not denote an abstract subprogram.
+
+11.a
+ Ramification: An abstract_subprogram_declaration is not
+ syntactically a subprogram_declaration. Nonetheless, an
+ abstract subprogram is a subprogram, and an
+ abstract_subprogram_declaration is a declaration of a
+ subprogram.
+
+11.b/2
+ {AI95-00260-02AI95-00260-02} The part about generic actual
+ subprograms includes those given by default. Of course, an
+ abstract formal subprogram's actual subprogram can be
+ abstract.
+
+ _Dynamic Semantics_
+
+11.1/2
+{AI95-00348-01AI95-00348-01} The elaboration of an
+abstract_subprogram_declaration has no effect.
+
+ NOTES
+
+12
+ 79 Abstractness is not inherited; to declare an abstract type, the
+ reserved word abstract has to be used in the declaration of the
+ type extension.
+
+12.a
+ Ramification: A derived type can be abstract even if its
+ parent is not. Similarly, an inherited concrete subprogram
+ can be overridden with an abstract subprogram.
+
+13
+ 80 A class-wide type is never abstract. Even if a class is rooted
+ at an abstract type, the class-wide type for the class is not
+ abstract, and an object of the class-wide type can be created; the
+ tag of such an object will identify some nonabstract type in the
+ class.
+
+ _Examples_
+
+14
+Example of an abstract type representing a set of natural numbers:
+
+15
+ package Sets is
+ subtype Element_Type is Natural;
+ type Set is abstract tagged null record;
+ function Empty return Set is abstract;
+ function Union(Left, Right : Set) return Set is abstract;
+ function Intersection(Left, Right : Set) return Set is abstract;
+ function Unit_Set(Element : Element_Type) return Set is abstract;
+ procedure Take(Element : out Element_Type;
+ From : in out Set) is abstract;
+ end Sets;
+
+ NOTES
+
+16
+ 81 Notes on the example: Given the above abstract type, one could
+ then derive various (nonabstract) extensions of the type,
+ representing alternative implementations of a set. One might use a
+ bit vector, but impose an upper bound on the largest element
+ representable, while another might use a hash table, trading off
+ space for flexibility.
+
+16.a
+ Discussion: One way to export a type from a package with some
+ components visible and some components private is as follows:
+
+16.b
+ package P is
+ type Public_Part is abstract tagged
+ record
+ ...
+ end record;
+ type T is new Public_Part with private;
+ ...
+ private
+ type T is new Public_Part with
+ record
+ ...
+ end record;
+ end P;
+
+16.c
+ The fact that Public_Part is abstract tells clients they have
+ to create objects of type T instead of Public_Part. Note that
+ the public part has to come first; it would be illegal to
+ declare a private type Private_Part, and then a record
+ extension T of it, unless T were in the private part after the
+ full declaration of Private_Part, but then clients of the
+ package would not have visibility to T.
+
+ _Extensions to Ada 95_
+
+16.d/2
+ {AI95-00391-01AI95-00391-01} It is not necessary to override
+ functions with a controlling result for a null extension.
+ This makes it easier to derive a tagged type to complete a
+ private type.
+
+ _Wording Changes from Ada 95_
+
+16.e/2
+ {AI95-00251-01AI95-00251-01} {AI95-00345-01AI95-00345-01}
+ Updated the wording to reflect the addition of interface types
+ (see *note 3.9.4::).
+
+16.f/2
+ {AI95-00260-02AI95-00260-02} Updated the wording to reflect
+ the addition of abstract formal subprograms (see *note
+ 12.6::).
+
+16.g/2
+ {AI95-00334-01AI95-00334-01} The wording of
+ shall-be-overridden was clarified so that it clearly applies
+ to abstract predefined equality.
+
+16.h/2
+ {AI95-00348-01AI95-00348-01} Moved the syntax and elaboration
+ rule for abstract_subprogram_declaration here, so the syntax
+ and most of the semantics are together (which is consistent
+ with null procedures).
+
+16.i/2
+ {AI95-00391-01AI95-00391-01} We define the term require
+ overriding to make other wording easier to understand.
+
+ _Incompatibilities With Ada 2005_
+
+16.j/3
+ {AI05-0073-1AI05-0073-1} Correction: Added rules to eliminate
+ holes with controlling access results and generic functions
+ that return abstract types. While these changes are
+ technically incompatible, it is unlikely that they could be
+ used in a program without violating some other rule of the use
+ of abstract types.
+
+16.k/3
+ {AI05-0097-1AI05-0097-1} Correction: Corrected a minor glitch
+ having to do with abstract null extensions. The Ada 2005 rule
+ allowed such extensions to inherit concrete operations in some
+ rare cases. It is unlikely that these cases exist in user
+ code.
+
+ _Extensions to Ada 2005_
+
+16.l/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in an abstract_subprogram_declaration. This is
+ described in *note 13.1.1::.
+
+ _Wording Changes from Ada 2005_
+
+16.m/3
+ {AI05-0198-1AI05-0198-1} Correction: Clarified that the
+ predefined operator corresponding to an inherited abstract
+ operator is also abstract. The Ada 2005 rules caused the
+ predefined operator and the inherited operator to override
+ each other, which is weird. But the effect is the same either
+ way (the operator is not considered for resolution).
+
+16.n/3
+ {AI05-0203-1AI05-0203-1} Correction: Added wording to disallow
+ abstract return objects. These were illegal in Ada 2005 by
+ other rules; the extension to support class-wide type better
+ opened a hole which has now been plugged.
+
+\1f
+File: aarm2012.info, Node: 3.9.4, Prev: 3.9.3, Up: 3.9
+
+3.9.4 Interface Types
+---------------------
+
+1/2
+{AI95-00251-01AI95-00251-01} {AI95-00345-01AI95-00345-01} [An interface
+type is an abstract tagged type that provides a restricted form of
+multiple inheritance. A tagged type, task type, or protected type may
+have one or more interface types as ancestors.]
+
+1.a/2
+ Glossary entry: An interface type is a form of abstract tagged
+ type which has no components or concrete operations except
+ possibly null procedures. Interface types are used for
+ composing other interfaces and tagged types and thereby
+ provide multiple inheritance. Only an interface type can be
+ used as a progenitor of another type.
+
+ _Language Design Principles_
+
+1.b/2
+ {AI95-00251-01AI95-00251-01} {AI95-00345-01AI95-00345-01} The
+ rules are designed so that an interface can be used as either
+ a parent type or a progenitor type without changing the
+ meaning. That's important so that the order that interfaces
+ are specified in a derived_type_definition is not significant.
+ In particular, we want:
+
+1.c/2
+ type Con1 is new Int1 and Int2 with null record;
+ type Con2 is new Int2 and Int1 with null record;
+
+1.d/2
+ to mean exactly the same thing.
+
+ _Syntax_
+
+2/2
+ {AI95-00251-01AI95-00251-01} {AI95-00345-01AI95-00345-01}
+ interface_type_definition ::=
+ [limited | task | protected | synchronized] interface [and
+ interface_list]
+
+3/2
+ {AI95-00251-01AI95-00251-01} {AI95-00419-01AI95-00419-01}
+ interface_list ::= interface_subtype_mark {and interface_
+ subtype_mark}
+
+ _Static Semantics_
+
+4/2
+{AI95-00251-01AI95-00251-01} An interface type (also called an
+interface) is a specific abstract tagged type that is defined by an
+interface_type_definition.
+
+5/2
+{AI95-00345-01AI95-00345-01} An interface with the reserved word
+limited, task, protected, or synchronized in its definition is termed,
+respectively, a limited interface, a task interface, a protected
+interface, or a synchronized interface. In addition, all task and
+protected interfaces are synchronized interfaces, and all synchronized
+interfaces are limited interfaces.
+
+5.a/2
+ Glossary entry: A synchronized entity is one that will work
+ safely with multiple tasks at one time. A synchronized
+ interface can be an ancestor of a task or a protected type.
+ Such a task or protected type is called a synchronized tagged
+ type.
+
+6/2
+{AI95-00345-01AI95-00345-01} {AI95-00443-01AI95-00443-01} [A task or
+protected type derived from an interface is a tagged type.] Such a
+tagged type is called a synchronized tagged type, as are synchronized
+interfaces and private extensions whose declaration includes the
+reserved word synchronized.
+
+6.a/2
+ Proof: The full definition of tagged types given in *note
+ 3.9:: includes task and protected types derived from
+ interfaces.
+
+6.b/2
+ Ramification: The class-wide type associated with a tagged
+ task type (including a task interface type) is a task type,
+ because "task" is one of the language-defined classes of types
+ (see *note 3.2::). However, the class-wide type associated
+ with an interface is not an interface type, as "interface" is
+ not one of the language-defined classes (as it is not closed
+ under derivation). In this sense, "interface" is similar to
+ "abstract". The class-wide type associated with an interface
+ is a concrete (nonabstract) indefinite tagged composite type.
+
+6.c/2
+ "Private extension" includes generic formal private
+ extensions, as explained in *note 12.5.1::.
+
+7/2
+{AI95-00345-01AI95-00345-01} A task interface is an [abstract] task
+type. A protected interface is an [abstract] protected type.
+
+7.a/2
+ Proof: The "abstract" follows from the definition of an
+ interface type.
+
+7.b/2
+ Reason: This ensures that task operations (like abort and the
+ Terminated attribute) can be applied to a task interface type
+ and the associated class-wide type. While there are no
+ protected type operations, we apply the same rule to protected
+ interfaces for consistency.
+
+8/2
+{AI95-00251-01AI95-00251-01} [An interface type has no components.]
+
+8.a/2
+ Proof: This follows from the syntax and the fact that
+ discriminants are not allowed for interface types.
+
+9/2
+{AI95-00419-01AI95-00419-01} An interface_subtype_mark in an
+interface_list names a progenitor subtype; its type is the progenitor
+type. An interface type inherits user-defined primitive subprograms
+from each progenitor type in the same way that a derived type inherits
+user-defined primitive subprograms from its progenitor types (see *note
+3.4::).
+
+9.a.1/2
+ Glossary entry: A progenitor of a derived type is one of the
+ types given in the definition of the derived type other than
+ the first. A progenitor is always an interface type.
+ Interfaces, tasks, and protected types may also have
+ progenitors.
+
+ _Legality Rules_
+
+10/2
+{AI95-00251-01AI95-00251-01} All user-defined primitive subprograms of
+an interface type shall be abstract subprograms or null procedures.
+
+11/2
+{AI95-00251-01AI95-00251-01} The type of a subtype named in an
+interface_list shall be an interface type.
+
+12/2
+{AI95-00251-01AI95-00251-01} {AI95-00345-01AI95-00345-01} A type derived
+from a nonlimited interface shall be nonlimited.
+
+13/2
+{AI95-00345-01AI95-00345-01} An interface derived from a task interface
+shall include the reserved word task in its definition; any other type
+derived from a task interface shall be a private extension or a task
+type declared by a task declaration (see *note 9.1::).
+
+14/2
+{AI95-00345-01AI95-00345-01} An interface derived from a protected
+interface shall include the reserved word protected in its definition;
+any other type derived from a protected interface shall be a private
+extension or a protected type declared by a protected declaration (see
+*note 9.4::).
+
+15/2
+{AI95-00345-01AI95-00345-01} An interface derived from a synchronized
+interface shall include one of the reserved words task, protected, or
+synchronized in its definition; any other type derived from a
+synchronized interface shall be a private extension, a task type
+declared by a task declaration, or a protected type declared by a
+protected declaration.
+
+15.a/2
+ Reason: We require that an interface descendant of a task,
+ protected, or synchronized interface repeat the explicit kind
+ of interface it will be, rather than simply inheriting it, so
+ that a reader is always aware of whether the interface
+ provides synchronization and whether it may be implemented
+ only by a task or protected type. The only place where
+ inheritance of the kind of interface might be useful would be
+ in a generic if you didn't know the kind of the actual
+ interface. However, the value of that is low because you
+ cannot implement an interface properly if you don't know
+ whether it is a task, protected, or synchronized interface.
+ Hence, we require the kind of the actual interface to match
+ the kind of the formal interface (see *note 12.5.5::).
+
+16/2
+{AI95-00345-01AI95-00345-01} No type shall be derived from both a task
+interface and a protected interface.
+
+16.a
+ Reason: This prevents a single private extension from
+ inheriting from both a task and a protected interface. For a
+ private type, there can be no legal completion. For a generic
+ formal derived type, there can be no possible matching type
+ (so no instantiation could be legal). This rule provides
+ early detection of the errors.
+
+17/2
+{AI95-00251-01AI95-00251-01} In addition to the places where Legality
+Rules normally apply (see *note 12.3::), these rules apply also in the
+private part of an instance of a generic unit.
+
+17.a/3
+ Ramification: {AI05-0299-1AI05-0299-1} This paragraph is
+ intended to apply to all of the Legality Rules in this
+ subclause. We cannot allow interface types which do not obey
+ these rules, anywhere. Luckily, deriving from a formal type
+ (which might be an interface) is not allowed for any tagged
+ types in a generic body. So checking in the private part of a
+ generic covers all of the cases.
+
+ _Dynamic Semantics_
+
+18/3
+{AI95-00251-01AI95-00251-01} {AI05-0070-1AI05-0070-1} The elaboration of
+an interface_type_definition creates the interface type and its first
+subtype.
+
+18.a/3
+ Discussion: There is no other effect. An interface_list is
+ made up of subtype_marks, which do not need to be elaborated,
+ so the interface_list does not either. This is consistent
+ with the handling of discriminant_parts.
+
+ NOTES
+
+19/2
+ 82 {AI95-00411-01AI95-00411-01} Nonlimited interface types have
+ predefined nonabstract equality operators. These may be overridden
+ with user-defined abstract equality operators. Such operators will
+ then require an explicit overriding for any nonabstract descendant
+ of the interface.
+
+ _Examples_
+
+20/2
+{AI95-00433-01AI95-00433-01} Example of a limited interface and a
+synchronized interface extending it:
+
+21/2
+ type Queue is limited interface;
+ procedure Append(Q : in out Queue; Person : in Person_Name) is abstract;
+ procedure Remove_First(Q : in out Queue;
+ Person : out Person_Name) is abstract;
+ function Cur_Count(Q : in Queue) return Natural is abstract;
+ function Max_Count(Q : in Queue) return Natural is abstract;
+ -- See *note 3.10.1:: for Person_Name.
+
+22/3
+ {AI05-0004-1AI05-0004-1} Queue_Error : exception;
+ -- Append raises Queue_Error if Cur_Count(Q) = Max_Count(Q)
+ -- Remove_First raises Queue_Error if Cur_Count(Q) = 0
+
+23/2
+ type Synchronized_Queue is synchronized interface and Queue; -- see *note 9.11::
+ procedure Append_Wait(Q : in out Synchronized_Queue;
+ Person : in Person_Name) is abstract;
+ procedure Remove_First_Wait(Q : in out Synchronized_Queue;
+ Person : out Person_Name) is abstract;
+
+24/2
+ ...
+
+25/2
+ procedure Transfer(From : in out Queue'Class;
+ To : in out Queue'Class;
+ Number : in Natural := 1) is
+ Person : Person_Name;
+ begin
+ for I in 1..Number loop
+ Remove_First(From, Person);
+ Append(To, Person);
+ end loop;
+ end Transfer;
+
+26/2
+This defines a Queue interface defining a queue of people. (A similar
+design could be created to define any kind of queue simply by replacing
+Person_Name by an appropriate type.) The Queue interface has four
+dispatching operations, Append, Remove_First, Cur_Count, and Max_Count.
+The body of a class-wide operation, Transfer is also shown. Every
+nonabstract extension of Queue must provide implementations for at least
+its four dispatching operations, as they are abstract. Any object of a
+type derived from Queue may be passed to Transfer as either the From or
+the To operand. The two operands need not be of the same type in any
+given call.
+
+27/2
+The Synchronized_Queue interface inherits the four dispatching
+operations from Queue and adds two additional dispatching operations,
+which wait if necessary rather than raising the Queue_Error exception.
+This synchronized interface may only be implemented by a task or
+protected type, and as such ensures safe concurrent access.
+
+28/2
+{AI95-00433-01AI95-00433-01} Example use of the interface:
+
+29/3
+ {AI05-0004-1AI05-0004-1} type Fast_Food_Queue is new Queue with record ...;
+ procedure Append(Q : in out Fast_Food_Queue; Person : in Person_Name);
+ procedure Remove_First(Q : in out Fast_Food_Queue; Person : out Person_Name);
+ function Cur_Count(Q : in Fast_Food_Queue) return Natural;
+ function Max_Count(Q : in Fast_Food_Queue) return Natural;
+
+30/2
+ ...
+
+31/2
+ Cashier, Counter : Fast_Food_Queue;
+
+32/2
+ ...
+ -- Add George (see *note 3.10.1::) to the cashier's queue:
+ Append (Cashier, George);
+ -- After payment, move George to the sandwich counter queue:
+ Transfer (Cashier, Counter);
+ ...
+
+33/2
+An interface such as Queue can be used directly as the parent of a new
+type (as shown here), or can be used as a progenitor when a type is
+derived. In either case, the primitive operations of the interface are
+inherited. For Queue, the implementation of the four inherited routines
+must be provided. Inside the call of Transfer, calls will dispatch to
+the implementations of Append and Remove_First for type Fast_Food_Queue.
+
+34/2
+{AI95-00433-01AI95-00433-01} Example of a task interface:
+
+35/2
+ type Serial_Device is task interface; -- see *note 9.1::
+ procedure Read (Dev : in Serial_Device; C : out Character) is abstract;
+ procedure Write(Dev : in Serial_Device; C : in Character) is abstract;
+
+36/2
+The Serial_Device interface has two dispatching operations which are
+intended to be implemented by task entries (see 9.1).
+
+ _Extensions to Ada 95_
+
+36.a/2
+ {AI95-00251-01AI95-00251-01} {AI95-00345-01AI95-00345-01}
+ Interface types are new. They provide multiple inheritance of
+ interfaces, similar to the facility provided in Java and other
+ recent language designs.
+
+ _Wording Changes from Ada 2005_
+
+36.b/3
+ {AI05-0070-1AI05-0070-1} Correction: Corrected the definition
+ of elaboration for an interface_type_definition to match that
+ of other type definitions.
+
+\1f
+File: aarm2012.info, Node: 3.10, Next: 3.11, Prev: 3.9, Up: 3
+
+3.10 Access Types
+=================
+
+1
+A value of an access type (an access value) provides indirect access to
+the object or subprogram it designates. Depending on its type, an
+access value can designate either subprograms, objects created by
+allocators (see *note 4.8::), or more generally aliased objects of an
+appropriate type.
+
+1.a
+ Discussion: A name denotes an entity; an access value
+ designates an entity. The "dereference" of an access value X,
+ written "X.all", is a name that denotes the entity designated
+ by X.
+
+ _Language Design Principles_
+
+1.b/3
+ {AI05-0299-1AI05-0299-1} Access values should always be well
+ defined (barring uses of certain unchecked features of Clause
+ *note 13::). In particular, uninitialized access variables
+ should be prevented by compile-time rules.
+
+ _Syntax_
+
+2/2
+ {AI95-00231-01AI95-00231-01} access_type_definition ::=
+ [null_exclusion] access_to_object_definition
+ | [null_exclusion] access_to_subprogram_definition
+
+3
+ access_to_object_definition ::=
+ access [general_access_modifier] subtype_indication
+
+4
+ general_access_modifier ::= all | constant
+
+5
+ access_to_subprogram_definition ::=
+ access [protected] procedure parameter_profile
+ | access [protected] function parameter_and_result_profile
+
+5.1/2
+ {AI95-00231-01AI95-00231-01} null_exclusion ::= not null
+
+6/2
+ {AI95-00231-01AI95-00231-01} {AI95-00254-01AI95-00254-01}
+ {AI95-00404-01AI95-00404-01} access_definition ::=
+ [null_exclusion] access [constant] subtype_mark
+ | [null_exclusion] access [protected] procedure parameter_profile
+ | [null_exclusion] access [protected] function
+ parameter_and_result_profile
+
+ _Static Semantics_
+
+7/1
+{8652/00128652/0012} {AI95-00062-01AI95-00062-01} There are two kinds of
+access types, access-to-object types, whose values designate objects,
+and access-to-subprogram types, whose values designate subprograms.
+Associated with an access-to-object type is a storage pool; several
+access types may share the same storage pool. All descendants of an
+access type share the same storage pool. A storage pool is an area of
+storage used to hold dynamically allocated objects (called pool
+elements) created by allocators[; storage pools are described further in
+*note 13.11::, "*note 13.11:: Storage Management"].
+
+8
+Access-to-object types are further subdivided into pool-specific access
+types, whose values can designate only the elements of their associated
+storage pool, and general access types, whose values can designate the
+elements of any storage pool, as well as aliased objects created by
+declarations rather than allocators, and aliased subcomponents of other
+objects.
+
+8.a
+ Implementation Note: The value of an access type will
+ typically be a machine address. However, a value of a
+ pool-specific access type can be represented as an offset (or
+ index) relative to its storage pool, since it can point only
+ to the elements of that pool.
+
+9/3
+{AI95-00225-01AI95-00225-01} {AI95-00363-01AI95-00363-01}
+{AI05-0053-1AI05-0053-1} {AI05-0142-4AI05-0142-4}
+{AI05-0277-1AI05-0277-1} A view of an object is defined to be aliased if
+it is defined by an object_declaration (*note 3.3.1: S0032.),
+component_definition (*note 3.6: S0056.), parameter_specification (*note
+6.1: S0175.), or extended_return_object_declaration with the reserved
+word aliased, or by a renaming of an aliased view. In addition, the
+dereference of an access-to-object value denotes an aliased view, as
+does a view conversion (see *note 4.6::) of an aliased view. The
+current instance of an immutably limited type (see *note 7.5::) is
+defined to be aliased. Finally, a formal parameter or generic formal
+object of a tagged type is defined to be aliased. [Aliased views are
+the ones that can be designated by an access value.]
+
+9.a
+ Glossary entry: An aliased view of an object is one that can
+ be designated by an access value. Objects allocated by
+ allocators are aliased. Objects can also be explicitly
+ declared as aliased with the reserved word aliased. The
+ Access attribute can be used to create an access value
+ designating an aliased object.
+
+9.b
+ Ramification: The current instance of a nonlimited type is not
+ aliased.
+
+9.c
+ The object created by an allocator is aliased, but not its
+ subcomponents, except of course for those that themselves have
+ aliased in their component_definition.
+
+9.d
+ The renaming of an aliased object is aliased.
+
+9.e
+ Slices are never aliased. See *note 4.1.2:: for more
+ discussion.
+
+9.f/2
+ Reason: {AI95-00225-01AI95-00225-01} The current instance of a
+ limited type is defined to be aliased so that an access
+ discriminant of a component can be initialized with T'Access
+ inside the definition of T. Note that we don't want this to
+ apply to a type that could become nonlimited later within its
+ immediate scope, so we require the full definition to be
+ limited.
+
+9.g
+ A formal parameter of a tagged type is defined to be aliased
+ so that a (tagged) parameter X may be passed to an access
+ parameter P by using P => X'Access. Access parameters are
+ most important for tagged types because of
+ dispatching-on-access-parameters (see *note 3.9.2::). By
+ restricting this to formal parameters, we minimize problems
+ associated with allowing components that are not declared
+ aliased to be pointed-to from within the same record.
+
+9.h
+ A view conversion of an aliased view is aliased so that the
+ type of an access parameter can be changed without first
+ converting to a named access type. For example:
+
+9.i
+ type T1 is tagged ...;
+ procedure P(X : access T1);
+
+9.j
+ type T2 is new T1 with ...;
+ procedure P(X : access T2) is
+ begin
+ P(T1(X.all)'Access); -- hand off to T1's P
+ . . . -- now do extra T2-specific processing
+ end P;
+
+9.k/2
+ This paragraph was deleted.{AI95-00363-01AI95-00363-01}
+
+9.l/2
+ We considered making more kinds of objects aliased by default.
+ In particular, any object of a by-reference type will pretty
+ much have to be allocated at an addressable location, so it
+ can be passed by reference without using bit-field pointers.
+ Therefore, one might wish to allow the Access and
+ Unchecked_Access attributes for such objects. However,
+ private parts are transparent to the definition of
+ "by-reference type", so if we made all objects of a
+ by-reference type aliased, we would be violating the privacy
+ of private parts. Instead, we would have to define a concept
+ of "visibly by-reference" and base the rule on that. This
+ seemed to complicate the rules more than it was worth,
+ especially since there is no way to declare an untagged
+ limited private type to be by-reference, since the full type
+ might by nonlimited.
+
+9.m
+ Discussion: Note that we do not use the term "aliased" to
+ refer to formal parameters that are referenced through
+ multiple access paths (see *note 6.2::).
+
+10
+An access_to_object_definition defines an access-to-object type and its
+first subtype; the subtype_indication (*note 3.2.2: S0027.) defines the
+designated subtype of the access type. If a general_access_modifier
+(*note 3.10: S0081.) appears, then the access type is a general access
+type. If the modifier is the reserved word constant, then the type is
+an access-to-constant type[; a designated object cannot be updated
+through a value of such a type]. If the modifier is the reserved word
+all, then the type is an access-to-variable type[; a designated object
+can be both read and updated through a value of such a type]. If no
+general_access_modifier (*note 3.10: S0081.) appears in the
+access_to_object_definition (*note 3.10: S0080.), the access type is a
+pool-specific access-to-variable type.
+
+10.a
+ To be honest: The type of the designated subtype is called the
+ designated type.
+
+10.b
+ Reason: The modifier all was picked to suggest that values of
+ a general access type could point into "all" storage pools, as
+ well as to objects declared aliased, and that "all" access
+ (both read and update) to the designated object was provided.
+ We couldn't think of any use for pool-specific
+ access-to-constant types, so any access type defined with the
+ modifier constant is considered a general access type, and can
+ point into any storage pool or at other (appropriate) aliased
+ objects.
+
+10.c
+ Implementation Note: The predefined generic
+ Unchecked_Deallocation can be instantiated for any named
+ access-to-variable type. There is no (language-defined)
+ support for deallocating objects designated by a value of an
+ access-to-constant type. Because of this, an allocator for an
+ access-to-constant type can allocate out of a storage pool
+ with no support for deallocation. Frequently, the allocation
+ can be done at link-time, if the size and initial value are
+ known then.
+
+10.d
+ Discussion: For the purpose of generic formal type matching,
+ the relevant subclasses of access types are
+ access-to-subprogram types, access-to-constant types, and
+ (named) access-to-variable types, with its subclass (named)
+ general access-to-variable types. Pool-specific
+ access-to-variable types are not a separately matchable
+ subclass of types, since they don't have any "extra"
+ operations relative to all (named) access-to-variable types.
+
+11
+An access_to_subprogram_definition defines an access-to-subprogram type
+and its first subtype; the parameter_profile or
+parameter_and_result_profile defines the designated profile of the
+access type. There is a calling convention associated with the
+designated profile[; only subprograms with this calling convention can
+be designated by values of the access type.] By default, the calling
+convention is "protected" if the reserved word protected appears, and
+"Ada" otherwise. [See *note Annex B:: for how to override this
+default.]
+
+11.a
+ Ramification: The calling convention protected is in italics
+ to emphasize that it cannot be specified explicitly by the
+ user. This is a consequence of it being a reserved word.
+
+11.b/2
+ Implementation Note: {AI95-00254-01AI95-00254-01} For a named
+ access-to-subprogram type, the representation of an access
+ value might include implementation-defined information needed
+ to support up-level references -- for example, a static link.
+ The accessibility rules (see *note 3.10.2::) ensure that in a
+ "global-display-based" implementation model (as opposed to a
+ static-link-based model), a named
+ access-to-(unprotected)-subprogram value need consist only of
+ the address of the subprogram. The global display is
+ guaranteed to be properly set up any time the designated
+ subprogram is called. Even in a static-link-based model, the
+ only time a static link is definitely required is for an
+ access-to-subprogram type declared in a scope nested at least
+ two levels deep within subprogram or task bodies, since values
+ of such a type might designate subprograms nested a smaller
+ number of levels. For the normal case of a named
+ access-to-subprogram type declared at the outermost (library)
+ level, a code address by itself should be sufficient to
+ represent the access value in many implementations.
+
+11.c
+ For access-to-protected-subprogram, the access values will
+ necessarily include both an address (or other identification)
+ of the code of the subprogram, as well as the address of the
+ associated protected object. This could be thought of as a
+ static link, but it will be needed even for
+ global-display-based implementation models. It corresponds to
+ the value of the "implicit parameter" that is passed into
+ every call of a protected operation, to identify the current
+ instance of the protected type on which they are to operate.
+
+11.d
+ Any Elaboration_Check is performed when a call is made through
+ an access value, rather than when the access value is first
+ "created" via a 'Access. For implementation models that
+ normally put that check at the call-site, an access value will
+ have to point to a separate entry point that does the check.
+ Alternatively, the access value could point to a "subprogram
+ descriptor" that consisted of two words (or perhaps more), the
+ first being the address of the code, the second being the
+ elaboration bit. Or perhaps more efficiently, just the
+ address of the code, but using the trick that the descriptor
+ is initialized to point to a Raise-Program-Error routine
+ initially, and then set to point to the "real" code when the
+ body is elaborated.
+
+11.e
+ For implementations that share code between generic
+ instantiations, the extra level of indirection suggested above
+ to support Elaboration_Checks could also be used to provide a
+ pointer to the per-instance data area normally required when
+ calling shared code. The trick would be to put a pointer to
+ the per-instance data area into the subprogram descriptor, and
+ then make sure that the address of the subprogram descriptor
+ is loaded into a "known" register whenever an indirect call is
+ performed. Once inside the shared code, the address of the
+ per-instance data area can be retrieved out of the subprogram
+ descriptor, by indexing off the "known" register.
+
+11.f/2
+ This paragraph was deleted.{AI95-00344-01AI95-00344-01}
+
+11.g/2
+ {AI95-00254-01AI95-00254-01} Note that access parameters of an
+ anonymous access-to-subprogram type are permitted. Such
+ parameters represent full "downward" closures, meaning that in
+ an implementation that uses a per-task (global) display, the
+ display will have to be passed as a hidden parameter, and
+ reconstructed at the point of call.
+
+12/3
+{AI95-00230-01AI95-00230-01} {AI95-00231-01AI95-00231-01}
+{AI95-00254-01AI95-00254-01} {AI05-0264-1AI05-0264-1} An
+access_definition defines an anonymous general access type or an
+anonymous access-to-subprogram type. For a general access type, the
+subtype_mark denotes its designated subtype; if the
+general_access_modifier (*note 3.10: S0081.) constant appears, the type
+is an access-to-constant type; otherwise, it is an access-to-variable
+type. For an access-to-subprogram type, the parameter_profile (*note
+6.1: S0172.) or parameter_and_result_profile (*note 6.1: S0173.) denotes
+its designated profile.
+
+13/2
+{AI95-00230-01AI95-00230-01} {AI95-00231-01AI95-00231-01} For each
+access type, there is a null access value designating no entity at all,
+which can be obtained by (implicitly) converting the literal null to the
+access type. [The null value of an access type is the default initial
+value of the type.] Nonnull values of an access-to-object type are
+obtained by evaluating an allocator[, which returns an access value
+designating a newly created object (see *note 3.10.2::)], or in the case
+of a general access-to-object type, evaluating an attribute_reference
+for the Access or Unchecked_Access attribute of an aliased view of an
+object. Nonnull values of an access-to-subprogram type are obtained by
+evaluating an attribute_reference for the Access attribute of a
+nonintrinsic subprogram.
+
+13.a/2
+ This paragraph was deleted.{AI95-00231-01AI95-00231-01}
+
+13.b/2
+ This paragraph was deleted.{AI95-00231-01AI95-00231-01}
+
+13.1/2
+{AI95-00231-01AI95-00231-01} A null_exclusion in a construct specifies
+that the null value does not belong to the access subtype defined by the
+construct, that is, the access subtype excludes null. In addition, the
+anonymous access subtype defined by the access_definition for a
+controlling access parameter (see *note 3.9.2::) excludes null.
+Finally, for a subtype_indication without a null_exclusion, the subtype
+denoted by the subtype_indication excludes null if and only if the
+subtype denoted by the subtype_mark in the subtype_indication excludes
+null.
+
+13.c/2
+ Reason: {AI95-00231-01AI95-00231-01} An access_definition used
+ in a controlling parameter excludes null because it is
+ necessary to read the tag to dispatch, and null has no tag.
+ We would have preferred to require not null to be specified
+ for such parameters, but that would have been too incompatible
+ with Ada 95 code to require.
+
+13.d/2
+ {AI95-00416-01AI95-00416-01} Note that we considered imposing
+ a similar implicit null exclusion for controlling access
+ results, but chose not to do that, because there is no Ada 95
+ compatibility issue, and there is no automatic null check
+ inherent in the use of a controlling access result. If a null
+ check is necessary, it is because there is a dereference of
+ the result, or because the value is passed to a parameter
+ whose subtype excludes null. If there is no dereference of
+ the result, a null return value is perfectly acceptable, and
+ can be a useful indication of a particular status of the call.
+
+14/3
+{8652/00138652/0013} {AI95-00012-01AI95-00012-01}
+{AI05-0264-1AI05-0264-1} [All subtypes of an access-to-subprogram type
+are constrained.] The first subtype of a type defined by an
+access_definition or an access_to_object_definition is unconstrained if
+the designated subtype is an unconstrained array or discriminated
+subtype; otherwise, it is constrained.
+
+14.a
+ Proof: The Legality Rules on range_constraints (see *note
+ 3.5::) do not permit the subtype_mark of the
+ subtype_indication to denote an access-to-scalar type, only a
+ scalar type. The Legality Rules on index_constraints (see
+ *note 3.6.1::) and discriminant_constraints (see *note
+ 3.7.1::) both permit access-to-composite types in a
+ subtype_indication with such _constraints. Note that an
+ access-to-access-to-composite is never permitted in a
+ subtype_indication with a constraint.
+
+14.b/2
+ Reason: {AI95-00363-01AI95-00363-01} Only
+ composite_constraints are permitted for an access type, and
+ only on access-to-composite types. A constraint on an
+ access-to-scalar or access-to-access type might be violated
+ due to assignments via other access paths that were not so
+ constrained. By contrast, if the designated subtype is an
+ array or discriminated type without defaults, the constraint
+ could not be violated by unconstrained assignments, since
+ array objects are always constrained, and discriminated
+ objects are also constrained when the type does not have
+ defaults for its discriminants. Constraints are not allowed
+ on general access-to-unconstrained discriminated types if the
+ type has defaults for its discriminants; constraints on
+ pool-specific access types are usually allowed because
+ allocated objects are usually constrained by their initial
+ value.
+
+ _Legality Rules_
+
+14.1/2
+{AI95-00231-01AI95-00231-01} If a subtype_indication (*note 3.2.2:
+S0027.), discriminant_specification (*note 3.7: S0062.),
+parameter_specification (*note 6.1: S0175.),
+parameter_and_result_profile (*note 6.1: S0173.),
+object_renaming_declaration (*note 8.5.1: S0200.), or
+formal_object_declaration (*note 12.4: S0279.) has a null_exclusion
+(*note 3.10: S0083.), the subtype_mark (*note 3.2.2: S0028.) in that
+construct shall denote an access subtype that does not exclude null.
+
+14.c/2
+ To be honest: {AI95-00231-01AI95-00231-01} This means
+ "directly allowed in"; we are not talking about a
+ null_exclusion that occurs in an access_definition in one of
+ these constructs (for an access_definition, the subtype_mark
+ in such an access_definition is not restricted).
+
+14.d/2
+ Reason: {AI95-00231-01AI95-00231-01} This is similar to doubly
+ constraining a composite subtype, which we also don't allow.
+
+ _Dynamic Semantics_
+
+15/2
+{AI95-00231-01AI95-00231-01} A composite_constraint is compatible with
+an unconstrained access subtype if it is compatible with the designated
+subtype. A null_exclusion is compatible with any access subtype that
+does not exclude null. An access value satisfies a composite_constraint
+of an access subtype if it equals the null value of its type or if it
+designates an object whose value satisfies the constraint. An access
+value satisfies an exclusion of the null value if it does not equal the
+null value of its type.
+
+16
+The elaboration of an access_type_definition creates the access type and
+its first subtype. For an access-to-object type, this elaboration
+includes the elaboration of the subtype_indication, which creates the
+designated subtype.
+
+17/2
+{AI95-00230-01AI95-00230-01} {AI95-00254-01AI95-00254-01} The
+elaboration of an access_definition creates an anonymous access type.
+
+ NOTES
+
+18
+ 83 Access values are called "pointers" or "references" in some
+ other languages.
+
+19
+ 84 Each access-to-object type has an associated storage pool;
+ several access types can share the same pool. An object can be
+ created in the storage pool of an access type by an allocator (see
+ *note 4.8::) for the access type. A storage pool (roughly)
+ corresponds to what some other languages call a "heap." See *note
+ 13.11:: for a discussion of pools.
+
+20
+ 85 Only index_constraints and discriminant_constraints can be
+ applied to access types (see *note 3.6.1:: and *note 3.7.1::).
+
+ _Examples_
+
+21
+Examples of access-to-object types:
+
+22/2
+ {AI95-00433-01AI95-00433-01} type Peripheral_Ref is not null access Peripheral; -- see *note 3.8.1::
+ type Binop_Ptr is access all Binary_Operation'Class;
+ -- general access-to-class-wide, see *note 3.9.1::
+
+23
+Example of an access subtype:
+
+24
+ subtype Drum_Ref is Peripheral_Ref(Drum); -- see *note 3.8.1::
+
+25
+Example of an access-to-subprogram type:
+
+26
+ type Message_Procedure is access procedure (M : in String := "Error!");
+ procedure Default_Message_Procedure(M : in String);
+ Give_Message : Message_Procedure := Default_Message_Procedure'Access;
+ ...
+ procedure Other_Procedure(M : in String);
+ ...
+ Give_Message := Other_Procedure'Access;
+ ...
+ Give_Message("File not found."); -- call with parameter (.all is optional)
+ Give_Message.all; -- call with no parameters
+
+ _Extensions to Ada 83_
+
+26.a
+ The syntax for access_type_definition is changed to support
+ general access types (including access-to-constants) and
+ access-to-subprograms. The syntax rules for
+ general_access_modifier and access_definition are new.
+
+ _Wording Changes from Ada 83_
+
+26.b/3
+ {AI05-0190-1AI05-0190-1} We use the term "storage pool" to
+ talk about the data area from which allocation takes place.
+ The term "collection" is only used for finalization.
+ ("Collection" and "storage pool" are not the same thing
+ because multiple unrelated access types can share the same
+ storage pool; see *note 13.11:: for more discussion.)
+
+ _Inconsistencies With Ada 95_
+
+26.c/2
+ {AI95-00231-01AI95-00231-01} Access discriminants and
+ noncontrolling access parameters no longer exclude null. A
+ program which passed null to such an access discriminant or
+ access parameter and expected it to raise Constraint_Error may
+ fail when compiled with Ada 2005. One hopes that there no
+ such programs outside of the ACATS. (Of course, a program
+ which actually wants to pass null will work, which is far more
+ likely.)
+
+26.d/2
+ {AI95-00363-01AI95-00363-01} Most unconstrained aliased
+ objects with defaulted discriminants are no longer constrained
+ by their initial values. This means that a program that
+ raised Constraint_Error from an attempt to change the
+ discriminants will no longer do so. The change only affects
+ programs that depended on the raising of Constraint_Error in
+ this case, so the inconsistency is unlikely to occur outside
+ of the ACATS. This change may however cause compilers to
+ implement these objects differently, possibly taking
+ additional memory or time. This is unlikely to be worse than
+ the differences caused by any major compiler upgrade.
+
+ _Incompatibilities With Ada 95_
+
+26.e/2
+ {AI95-00225-01AI95-00225-01} Amendment Correction: The rule
+ defining when a current instance of a limited type is
+ considered to be aliased has been tightened to apply only to
+ types that cannot become nonlimited. A program that attempts
+ to take 'Access of the current instance of a limited type that
+ can become nonlimited will be illegal in Ada 2005. While
+ original Ada 95 allowed the current instance of any limited
+ type to be treated as aliased, this was inconsistently
+ implemented in compilers, and was likely to not work as
+ expected for types that are ultimately nonlimited.
+
+ _Extensions to Ada 95_
+
+26.f/2
+ {AI95-00231-01AI95-00231-01} The null_exclusion is new. It
+ can be used in both anonymous and named access type
+ definitions. It is most useful to declare that parameters
+ cannot be null, thus eliminating the need for checks on use.
+
+26.g/2
+ {AI95-00231-01AI95-00231-01} {AI95-00254-01AI95-00254-01}
+ {AI95-00404-01AI95-00404-01} The kinds of anonymous access
+ types allowed were increased by adding anonymous
+ access-to-constant and anonymous access-to-subprogram types.
+ Anonymous access-to-subprogram types used as parameters allow
+ passing of subprograms at any level.
+
+ _Wording Changes from Ada 95_
+
+26.h/2
+ {8652/00128652/0012} {AI95-00062-01AI95-00062-01} Corrigendum:
+ Added accidentally-omitted wording that says that a derived
+ access type shares its storage pool with its parent type.
+ This was clearly intended, both because of a note in *note
+ 3.4::, and because anything else would have been incompatible
+ with Ada 83.
+
+26.i/2
+ {8652/00138652/0013} {AI95-00012-01AI95-00012-01} Corrigendum:
+ Fixed typographical errors in the description of when access
+ types are constrained.
+
+26.j/2
+ {AI95-00230-01AI95-00230-01} The wording was fixed to allow
+ allocators and the literal null for anonymous access types.
+ The former was clearly intended by Ada 95; see the
+ Implementation Advice in *note 13.11::.
+
+26.k/2
+ {AI95-00363-01AI95-00363-01} The rules about aliased objects
+ being constrained by their initial values now apply only to
+ allocated objects, and thus have been moved to *note 4.8::,
+ "*note 4.8:: Allocators".
+
+ _Wording Changes from Ada 2005_
+
+26.l/3
+ {AI05-0053-1AI05-0053-1} {AI05-0277-1AI05-0277-1} Correction:
+ The rule about a current instance being aliased now is worded
+ in terms of immutably limited types. Wording was also added
+ to make extended return object declarations that have the
+ keyword aliased be considered aliased. This latter was a
+ significant oversight in Ada 2005 -- technically, the keyword
+ aliased had no effect. But of course implementations followed
+ the intent, not the letter of the Standard.
+
+26.m/3
+ {AI05-0142-4AI05-0142-4} Explicitly aliased parameters (see
+ *note 6.1::) are defined to be aliased.
+
+* Menu:
+
+* 3.10.1 :: Incomplete Type Declarations
+* 3.10.2 :: Operations of Access Types
+
+\1f
+File: aarm2012.info, Node: 3.10.1, Next: 3.10.2, Up: 3.10
+
+3.10.1 Incomplete Type Declarations
+-----------------------------------
+
+1
+There are no particular limitations on the designated type of an access
+type. In particular, the type of a component of the designated type can
+be another access type, or even the same access type. This permits
+mutually dependent and recursive access types. An
+incomplete_type_declaration can be used to introduce a type to be used
+as a designated type, while deferring its full definition to a
+subsequent full_type_declaration.
+
+ _Syntax_
+
+2/2
+ {AI95-00326-01AI95-00326-01} incomplete_type_declaration ::= type
+ defining_identifier [discriminant_part] [is tagged];
+
+ _Static Semantics_
+
+2.1/2
+{AI95-00326-01AI95-00326-01} An incomplete_type_declaration declares an
+incomplete view of a type and its first subtype; the first subtype is
+unconstrained if a discriminant_part appears. If the
+incomplete_type_declaration (*note 3.10.1: S0085.) includes the reserved
+word tagged, it declares a tagged incomplete view. [An incomplete view
+of a type is a limited view of the type (see *note 7.5::).]
+
+2.2/2
+{AI95-00326-01AI95-00326-01} Given an access type A whose designated
+type T is an incomplete view, a dereference of a value of type A also
+has this incomplete view except when:
+
+2.a/3
+ Discussion: {AI05-0208-1AI05-0208-1} Whether the designated
+ type is an incomplete view (and thus whether this set of rules
+ applies) is determined by the view of the type at the
+ declaration of the access type; it does not change during the
+ life of the type.
+
+2.3/2
+ * it occurs within the immediate scope of the completion of T, or
+
+2.4/3
+ * {AI05-0208-1AI05-0208-1} it occurs within the scope of a
+ nonlimited_with_clause that mentions a library package in whose
+ visible part the completion of T is declared, or
+
+2.5/3
+ * {AI05-0208-1AI05-0208-1} it occurs within the scope of the
+ completion of T and T is an incomplete view declared by an
+ incomplete_type_declaration.
+
+2.6/3
+{AI05-0162-1AI05-0162-1} In these cases, the dereference has the view of
+T visible at the point of the dereference.
+
+2.b/2
+ Discussion: We need the "in whose visible part" rule so that
+ the second rule doesn't trigger in the body of a package with
+ a with of a child unit:
+
+2.c/2
+ package P is
+ private
+ type T;
+ type PtrT is access T;
+ end P;
+
+2.d/2
+ private package P.C is
+ Ptr : PtrT;
+ end P.C;
+
+2.e/3
+ {AI05-0005-1AI05-0005-1} with P.C;
+ package body P is
+ -- Ptr.all'Size is not legal here, but we are within the scope
+ -- of a nonlimited_with_clause for P.
+ type T is ...
+ -- Ptr.all'Size is legal here.
+ end P;
+
+2.7/3
+{AI95-00412-01AI95-00412-01} {AI05-0162-1AI05-0162-1}
+{AI05-0208-1AI05-0208-1} Similarly, if a subtype_mark denotes a
+subtype_declaration defining a subtype of an incomplete view T, the
+subtype_mark denotes an incomplete view except under the same three
+circumstances given above, in which case it denotes the view of T
+visible at the point of the subtype_mark.
+
+ _Legality Rules_
+
+3/3
+{AI05-0162-1AI05-0162-1} An incomplete_type_declaration (*note 3.10.1:
+S0085.) requires a completion, which shall be a type_declaration (*note
+3.2.1: S0023.) other than an incomplete_type_declaration (*note 3.10.1:
+S0085.). [If the incomplete_type_declaration (*note 3.10.1: S0085.)
+occurs immediately within either the visible part of a
+package_specification (*note 7.1: S0191.) or a declarative_part (*note
+3.11: S0086.), then the type_declaration (*note 3.2.1: S0023.) shall
+occur later and immediately within this visible part or declarative_part
+(*note 3.11: S0086.). If the incomplete_type_declaration (*note 3.10.1:
+S0085.) occurs immediately within the private part of a given
+package_specification (*note 7.1: S0191.), then the type_declaration
+(*note 3.2.1: S0023.) shall occur later and immediately within either
+the private part itself, or the declarative_part (*note 3.11: S0086.) of
+the corresponding package_body (*note 7.2: S0192.).]
+
+3.a
+ Proof: This is implied by the next AARM-only rule, plus the
+ rules in *note 3.11.1::, "*note 3.11.1:: Completions of
+ Declarations" which require a completion to appear later and
+ immediately within the same declarative region.
+
+3.b
+ To be honest: If the incomplete_type_declaration occurs
+ immediately within the visible part of a
+ package_specification, then the completing type_declaration
+ (*note 3.2.1: S0023.) shall occur immediately within this
+ visible part.
+
+3.c
+ To be honest: If the implementation supports it, an
+ incomplete_type_declaration can be imported (using aspect
+ Import, see *note B.1::), in which case no explicit completion
+ is allowed.
+
+4/3
+{AI95-00326-01AI95-00326-01} {AI05-0162-1AI05-0162-1} If an
+incomplete_type_declaration (*note 3.10.1: S0085.) includes the reserved
+word tagged, then a type_declaration (*note 3.2.1: S0023.) that
+completes it shall declare a tagged type. If an
+incomplete_type_declaration (*note 3.10.1: S0085.) has a
+known_discriminant_part (*note 3.7: S0061.), then a type_declaration
+(*note 3.2.1: S0023.) that completes it shall have a fully conforming
+(explicit) known_discriminant_part (*note 3.7: S0061.) (see *note
+6.3.1::). [If an incomplete_type_declaration (*note 3.10.1: S0085.) has
+no discriminant_part (or an unknown_discriminant_part (*note 3.7:
+S0060.)), then a corresponding type_declaration (*note 3.2.1: S0023.) is
+nevertheless allowed to have discriminants, either explicitly, or
+inherited via derivation.]
+
+5/2
+{AI95-00326-01AI95-00326-01} A name that denotes an incomplete view of a
+type may be used as follows:
+
+6/3
+ * {AI05-0098-1AI05-0098-1} as the subtype_mark in the
+ subtype_indication of an access_to_object_definition (*note 3.10:
+ S0080.); [the only form of constraint allowed in this
+ subtype_indication is a discriminant_constraint [(a null_exclusion
+ is not allowed)];]
+
+6.a
+ Implementation Note: We now allow discriminant_constraints
+ even if the full type is deferred to the package body.
+ However, there is no particular implementation burden because
+ we have dropped the concept of the dependent compatibility
+ check. In other words, we have effectively repealed
+ AI83-00007.
+
+7/2
+ * {AI95-00326-01AI95-00326-01} {AI95-00412-01AI95-00412-01} as the
+ subtype_mark in the subtype_indication of a subtype_declaration;
+ the subtype_indication (*note 3.2.2: S0027.) shall not have a
+ null_exclusion (*note 3.10: S0083.) or a constraint;
+
+8/3
+ * {AI95-00326-01AI95-00326-01} {AI05-0151-1AI05-0151-1} as the
+ subtype_mark in an access_definition for an access-to-object type;
+
+8.a/2
+ To be honest: This does not mean any random subtype_mark in a
+ construct that makes up an access_definition, such as a
+ formal_part, just the one given directly in the syntax of
+ access_definition.
+
+8.1/3
+ * {AI05-0151-1AI05-0151-1} as the subtype_mark defining the subtype
+ of a parameter or result in a profile occurring within a
+ basic_declaration;
+
+8.b/3
+ Ramification: But not in the profile for a body or entry.
+
+8.2/3
+ * {AI05-0213-1AI05-0213-1} as a generic actual parameter whose
+ corresponding generic formal parameter is a formal incomplete type
+ (see *note 12.5.1::).
+
+8.3/2
+{AI95-00326-01AI95-00326-01} If such a name denotes a tagged incomplete
+view, it may also be used:
+
+8.4/3
+ * {AI95-00326-01AI95-00326-01} {AI05-0151-1AI05-0151-1} as the
+ subtype_mark defining the subtype of a parameter in the profile for
+ a subprogram_body, entry_body, or accept_statement;
+
+9/2
+ * {AI95-00326-01AI95-00326-01} as the prefix of an
+ attribute_reference whose attribute_designator (*note 4.1.4:
+ S0101.) is Class; such an attribute_reference (*note 4.1.4: S0100.)
+ is restricted to the uses allowed here; it denotes a tagged
+ incomplete view.
+
+9.a/2
+ This paragraph was deleted.{AI95-00326-01AI95-00326-01}
+
+9.1/3
+This paragraph was deleted.{AI95-00326-01AI95-00326-01}
+{AI05-0151-1AI05-0151-1}
+
+9.2/3
+ * This paragraph was deleted.{AI95-00326-01AI95-00326-01}
+ {AI05-0098-1AI05-0098-1} {AI05-0151-1AI05-0151-1}
+
+9.b/3
+ This paragraph was deleted.
+
+9.3/2
+{AI95-00326-01AI95-00326-01} If any of the above uses occurs as part of
+the declaration of a primitive subprogram of the incomplete view, and
+the declaration occurs immediately within the private part of a package,
+then the completion of the incomplete view shall also occur immediately
+within the private part; it shall not be deferred to the package body.
+
+9.c/2
+ Reason: This fixes a hole in Ada 95 where a dispatching
+ operation with an access parameter could be declared in a
+ private part and a dispatching call on it could occur in a
+ child even though there is no visibility on the full type,
+ requiring access to the controlling tag without access to the
+ representation of the type.
+
+9.4/2
+{AI95-00326-01AI95-00326-01} No other uses of a name that denotes an
+incomplete view of a type are allowed.
+
+10/3
+{AI95-00326-01AI95-00326-01} {AI05-0151-1AI05-0151-1} A prefix that
+denotes an object shall not be of an incomplete view. An actual
+parameter in a call shall not be of an untagged incomplete view. The
+result object of a function call shall not be of an incomplete view. A
+prefix shall not denote a subprogram having a formal parameter of an
+untagged incomplete view, nor a return type that is an incomplete view.
+
+10.a/2
+ Reason: We used to disallow all dereferences of an incomplete
+ type. Now we only disallow such dereferences when used as a
+ prefix. Dereferences used in other contexts do not pose a
+ problem since normal type matching will preclude their use
+ except when the full type is "nearby" as context (for example,
+ as the expected type).
+
+10.b/2
+ This also disallows prefixes that are directly of an
+ incomplete view. For instance, a parameter P can be declared
+ of a tagged incomplete type, but we don't want to allow
+ P'Size, P'Alignment, or the like, as representation values
+ aren't known for an incomplete view.
+
+10.c/2
+ We say "denotes an object" so that prefixes that directly name
+ an incomplete view are not covered; the previous rules cover
+ such cases, and we certainly don't want to ban Incomp'Class.
+
+10.d/3
+ {AI05-0151-1AI05-0151-1} As subprogram profiles now may
+ include any kind of incomplete type, we also disallow passing
+ objects of untagged incomplete types in subprogram calls (as
+ the parameter passing method is not known as it is for tagged
+ types) and disallow returning any sort of incomplete objects
+ (since we don't know how big they are).
+
+Paragraph 11 was deleted.
+
+ _Dynamic Semantics_
+
+12
+The elaboration of an incomplete_type_declaration has no effect.
+
+12.a
+ Reason: An incomplete type has no real existence, so it
+ doesn't need to be "created" in the usual sense we do for
+ other types. It is roughly equivalent to a "forward;"
+ declaration in Pascal. Private types are different, because
+ they have a different set of characteristics from their full
+ type.
+
+ NOTES
+
+13
+ 86 Within a declarative_part, an incomplete_type_declaration and a
+ corresponding full_type_declaration cannot be separated by an
+ intervening body. This is because a type has to be completely
+ defined before it is frozen, and a body freezes all types declared
+ prior to it in the same declarative_part (see *note 13.14::).
+
+13.1/3
+ 87 {AI05-0151-1AI05-0151-1} {AI05-0269-1AI05-0269-1} A name that
+ denotes an object of an incomplete view is defined to be of a
+ limited type. Hence, the target of an assignment statement cannot
+ be of an incomplete view.
+
+ _Examples_
+
+14
+Example of a recursive type:
+
+15
+ type Cell; -- incomplete type declaration
+ type Link is access Cell;
+
+16
+ type Cell is
+ record
+ Value : Integer;
+ Succ : Link;
+ Pred : Link;
+ end record;
+
+17
+ Head : Link := new Cell'(0, null, null);
+ Next : Link := Head.Succ;
+
+18
+Examples of mutually dependent access types:
+
+19/2
+ {AI95-00433-01AI95-00433-01} type Person(<>); -- incomplete type declaration
+ type Car is tagged; -- incomplete type declaration
+
+20/2
+ {AI95-00433-01AI95-00433-01} type Person_Name is access Person;
+ type Car_Name is access all Car'Class;
+
+21/2
+ {AI95-00433-01AI95-00433-01} type Car is tagged
+ record
+ Number : Integer;
+ Owner : Person_Name;
+ end record;
+
+22
+ type Person(Sex : Gender) is
+ record
+ Name : String(1 .. 20);
+ Birth : Date;
+ Age : Integer range 0 .. 130;
+ Vehicle : Car_Name;
+ case Sex is
+ when M => Wife : Person_Name(Sex => F);
+ when F => Husband : Person_Name(Sex => M);
+ end case;
+ end record;
+
+23
+ My_Car, Your_Car, Next_Car : Car_Name := new Car; -- see *note 4.8::
+ George : Person_Name := new Person(M);
+ ...
+ George.Vehicle := Your_Car;
+
+ _Extensions to Ada 83_
+
+23.a
+ The full_type_declaration that completes an
+ incomplete_type_declaration may have a known_discriminant_part
+ even if the incomplete_type_declaration does not.
+
+23.b/1
+ A discriminant_constraint may be applied to an incomplete
+ type, even if its completion is deferred to the package body,
+ because there is no "dependent compatibility check" required
+ any more. Of course, the constraint can be specified only if
+ a known_discriminant_part was given in the
+ incomplete_type_declaration. As mentioned in the previous
+ paragraph, that is no longer required even when the full type
+ has discriminants.
+
+ _Wording Changes from Ada 83_
+
+23.c
+ Dereferences producing incomplete types were not explicitly
+ disallowed in RM83, though AI83-00039 indicated that it was
+ not strictly necessary since troublesome cases would result in
+ Constraint_Error at run time, since the access value would
+ necessarily be null. However, this introduces an undesirable
+ implementation burden, as illustrated by Example 4 of
+ AI83-00039:
+
+23.d
+ package Pack is
+ type Pri is private;
+ private
+ type Sep;
+ type Pri is access Sep;
+ X : Pri;
+ end Pack;
+
+23.e
+ package body Pack is -- Could be separately compiled!
+ type Sep is ...;
+ X := new Sep;
+ end Pack;
+
+23.f
+ pragma Elaborate(Pack);
+ private package Pack.Child is
+ I : Integer := X.all'Size; -- Legal, by AI-00039.
+ end Pack.Child;
+
+23.g
+ Generating code for the above example could be a serious
+ implementation burden, since it would require all aliased
+ objects to store size dope, and for that dope to be in the
+ same format for all kinds of types (or some other equivalently
+ inefficient implementation). On the contrary, most
+ implementations allocate dope differently (or not at all) for
+ different designated subtypes.
+
+ _Incompatibilities With Ada 95_
+
+23.h/2
+ {AI95-00326-01AI95-00326-01} It is now illegal to use an
+ incomplete view (type) as the parameter or result of an
+ access-to-subprogram type unless the incomplete view is
+ completed in the same declaration list as the use. This was
+ allowed in Ada 95 for incomplete types where the completion
+ was deferred to the body. By disallowing this rare use of
+ incomplete views, we can allow the use of incomplete views in
+ many more places, which is especially valuable for limited
+ views.
+
+23.i/2
+ {AI95-00326-01AI95-00326-01} It is now illegal to use an
+ incomplete view (type) in a primitive subprogram of the type
+ unless the incomplete view is completed in the package
+ specification. This was allowed in Ada 95 for incomplete
+ types where the completion was deferred to the body (the use
+ would have to be in an access parameter). This
+ incompatibility was caused by the fix for the hole noted in
+ Legality Rules above.
+
+ _Extensions to Ada 95_
+
+23.j/2
+ {AI95-00326-01AI95-00326-01} Tagged incomplete types are new.
+ They are allowed in parameter declarations as well as the
+ usual places, as tagged types are always by-reference types
+ (and thus there can be no code generation issue).
+
+23.k/2
+ {AI95-00412-01AI95-00412-01} A subtype_declaration can be used
+ to give a new name to an incomplete view of a type. This is
+ valuable to give shorter names to entities imported with a
+ limited_with_clause.
+
+ _Wording Changes from Ada 95_
+
+23.l/2
+ {AI95-00326-01AI95-00326-01} The description of incomplete
+ types as incomplete views is new. Ada 95 defined these as
+ separate types, but neglected to give any rules for matching
+ them with other types. Luckily, implementers did the right
+ thing anyway. This change also makes it easier to describe
+ the meaning of a limited view.
+
+ _Extensions to Ada 2005_
+
+23.m/3
+ {AI05-0098-1AI05-0098-1} Correction: Fixed the definition so
+ that an anonymous access-to-subprogram type can use an
+ incomplete view in the same way that a named
+ access-to-subprogram type can.
+
+23.n/3
+ {AI05-0151-1AI05-0151-1} Incomplete types now can be used in
+ subprogram declarations. The type has to be complete before
+ any calls or the body is declared. This reduces the places
+ where access types are required for types imported from
+ limited views of packages.
+
+23.o/3
+ {AI05-0162-1AI05-0162-1} Incomplete types now can be completed
+ by private types and private extensions. Since this can
+ already happen for limited views, there is no remaining reason
+ to disallow it for explicitly declared incomplete types.
+
+ _Wording Changes from Ada 2005_
+
+23.p/3
+ {AI05-0208-1AI05-0208-1} Correction: Changed the rules of uses
+ of dereferences of incomplete views such that it does not
+ introduce an unintentional incompatibility with Ada 83 and Ada
+ 95.
+
+23.q/3
+ {AI05-0213-1AI05-0213-1} Incomplete types now can be used as
+ actuals to formal incomplete types (see *note 12.5.1::).
+
+\1f
+File: aarm2012.info, Node: 3.10.2, Prev: 3.10.1, Up: 3.10
+
+3.10.2 Operations of Access Types
+---------------------------------
+
+1/3
+{AI05-0299-1AI05-0299-1} [The attribute Access is used to create access
+values designating aliased objects and nonintrinsic subprograms. The
+"accessibility" rules prevent dangling references (in the absence of
+uses of certain unchecked features -- see Clause *note 13::).]
+
+ _Language Design Principles_
+
+1.a
+ It should be possible for an access value to designate an
+ object declared by an object declaration, or a subcomponent
+ thereof. In implementation terms, this means pointing at
+ stack-allocated and statically allocated data structures.
+ However, dangling references should be prevented, primarily
+ via compile-time rules, so long as features like
+ Unchecked_Access and Unchecked_Deallocation are not used.
+
+1.b
+ In order to create such access values, we require that the
+ access type be a general access type, that the designated
+ object be aliased, and that the accessibility rules be obeyed.
+
+ _Name Resolution Rules_
+
+2/2
+{AI95-00235-01AI95-00235-01} For an attribute_reference with
+attribute_designator Access (or Unchecked_Access -- see *note 13.10::),
+the expected type shall be a single access type A such that:
+
+2.1/2
+ * {AI95-00235-01AI95-00235-01} A is an access-to-object type with
+ designated type D and the type of the prefix is D'Class or is
+ covered by D, or
+
+2.2/2
+ * {AI95-00235-01AI95-00235-01} A is an access-to-subprogram type
+ whose designated profile is type conformant with that of the
+ prefix.
+
+2.3/2
+{AI95-00235-01AI95-00235-01} [The prefix of such an attribute_reference
+is never interpreted as an implicit_dereference or a parameterless
+function_call (see *note 4.1.4::).] The designated type or profile of
+the expected type of the attribute_reference is the expected type or
+profile for the prefix.
+
+2.a
+ Discussion: Saying that the expected type shall be a "single
+ access type" is our "new" way of saying that the type has to
+ be determinable from context using only the fact that it is an
+ access type. See *note 4.2:: and *note 8.6::. Specifying the
+ expected profile only implies type conformance. The more
+ stringent subtype conformance is required by a Legality Rule.
+ This is the only Resolution Rule that applies to the name in a
+ prefix of an attribute_reference. In all other cases, the
+ name has to be resolved without using context. See *note
+ 4.1.4::.
+
+2.b/2
+ {AI95-00235-01AI95-00235-01} Saying "single access type" is a
+ bit of a fudge. Both the context and the prefix may provide
+ both multiple types; "single" only means that a single,
+ specific interpretation must remain after resolution. We say
+ "single" here to trigger the Legality Rules of *note 8.6::.
+ The resolution of an access attribute is similar to that of an
+ assignment_statement. For example:
+
+2.c/2
+ type Int_Ptr is access all Integer;
+ type Char_Ptr is access all Character;
+ type Float_Ptr is access all Float;
+
+2.d/2
+ function Zap (Val : Int_Ptr) return Float; -- (1)
+ function Zap (Val : Float_Ptr) return Float; -- (2)
+ function Zop return Int_Ptr; -- (3)
+ function Zop return Char_Ptr; -- (4)
+
+2.e/2
+ Result : Float := Zap (Zop.all'Access); -- Resolves to Zap (1) and Zop (3).
+
+ _Static Semantics_
+
+3/2
+{AI95-00162-01AI95-00162-01} [The accessibility rules, which prevent
+dangling references, are written in terms of accessibility levels, which
+reflect the run-time nesting of masters. As explained in *note 7.6.1::,
+a master is the execution of a certain construct, such as a
+subprogram_body. An accessibility level is deeper than another if it is
+more deeply nested at run time. For example, an object declared local
+to a called subprogram has a deeper accessibility level than an object
+declared local to the calling subprogram. The accessibility rules for
+access types require that the accessibility level of an object
+designated by an access value be no deeper than that of the access type.
+This ensures that the object will live at least as long as the access
+type, which in turn ensures that the access value cannot later designate
+an object that no longer exists. The Unchecked_Access attribute may be
+used to circumvent the accessibility rules.]
+
+3.a/3
+ Discussion: {AI05-0005-1AI05-0005-1} The Unchecked_Access
+ attribute acts as if the object was declared at library-level;
+ this applies even when it is used as the value of anonymous
+ access type. See *note 13.10::.
+
+3.b/3
+ Subclause *note 3.10.2::, home of the accessibility rules, is
+ informally known as the "Heart of Darkness" amongst the
+ maintainers of Ada. Woe unto all who enter here (well, at
+ least unto anyone that needs to understand any of these
+ rules).
+
+4
+[A given accessibility level is said to be statically deeper than
+another if the given level is known at compile time (as defined below)
+to be deeper than the other for all possible executions. In most cases,
+accessibility is enforced at compile time by Legality Rules. Run-time
+accessibility checks are also used, since the Legality Rules do not
+cover certain cases involving access parameters and generic packages.]
+
+5
+Each master, and each entity and view created by it, has an
+accessibility level:
+
+6
+ * The accessibility level of a given master is deeper than that of
+ each dynamically enclosing master, and deeper than that of each
+ master upon which the task executing the given master directly
+ depends (see *note 9.3::).
+
+7/3
+ * {AI95-00162-01AI95-00162-01} {AI95-00416-01AI95-00416-01}
+ {AI05-0235-1AI05-0235-1} An entity or view defined by a declaration
+ and created as part of its elaboration has the same accessibility
+ level as the innermost master of the declaration except in the
+ cases of renaming and derived access types described below. Other
+ than for an explicitly aliased parameter, a formal parameter of a
+ callable entity has the same accessibility level as the master
+ representing the invocation of the entity.
+
+7.a/2
+ Reason: {AI95-00416-01AI95-00416-01} This rule defines the
+ "normal" accessibility of entities. In the absence of special
+ rules below, we intend for this rule to apply.
+
+7.b/2
+ Discussion: {AI95-00416-01AI95-00416-01} This rule defines the
+ accessibility of all named access types, as well as the
+ accessibility level of all anonymous access types other than
+ those for access parameters and access discriminants. Special
+ rules exist for the accessibility level of such anonymous
+ types. Components, stand-alone objects, and function results
+ whose (anonymous) type is defined by an access_definition have
+ accessibility levels corresponding to named access types
+ defined at the same point.
+
+7.c/2
+ Ramification: {AI95-00230-01AI95-00230-01} Because
+ accessibility level is determined by where the
+ access_definition is elaborated, for a type extension, the
+ anonymous access types of components (other than access
+ discriminants) inherited from the parent have the same
+ accessibility as they did in the parent; those in the
+ extension part have the accessibility determined by the scope
+ where the type extension is declared. Similarly, the types of
+ the nondiscriminant access components of a derived untagged
+ type have the same accessibility as they did in the parent.
+
+7.d/3
+ To be honest: {AI05-0235-1AI05-0235-1} We use "invocation of"
+ in the parameter case as a master is formally an execution of
+ something. But we mean this to be interpreted statically (for
+ instance, as the body of the subprogram) for the purposes of
+ computing "statically deeper than" (see below).
+
+7.e/3
+ Ramification: {AI05-0235-1AI05-0235-1} Note that accessibility
+ can differ depending on the view of an object (for both static
+ and dynamic accessibility). For instance, the accessibility
+ level of a formal parameter may be different than the
+ accessibility level of the corresponding actual parameter.
+ This occurs in other cases as well.
+
+7.f/3
+ Reason: {AI05-0235-1AI05-0235-1} We define the (dynamic)
+ accessibility of formal parameters in order that it does not
+ depend on the parameter passing model (by-reference or
+ by-copy) as that is implementation defined. Otherwise, there
+ would be a portability issue.
+
+8
+ * The accessibility level of a view of an object or subprogram
+ defined by a renaming_declaration is the same as that of the
+ renamed view.
+
+9/2
+ * {AI95-00416-01AI95-00416-01} The accessibility level of a view
+ conversion, qualified_expression, or parenthesized expression, is
+ the same as that of the operand.
+
+9.1/3
+ * {AI05-0188-1AI05-0188-1} The accessibility level of a
+ conditional_expression is the accessibility level of the evaluated
+ dependent_expression.
+
+10/3
+ * {AI95-00318-02AI95-00318-02} {AI95-00416-01AI95-00416-01}
+ {AI05-0234-1AI05-0234-1} The accessibility level of an aggregate
+ that is used (in its entirety) to directly initialize part of an
+ object is that of the object being initialized. In other contexts,
+ the accessibility level of an aggregate is that of the innermost
+ master that evaluates the aggregate.
+
+10.1/3
+ * {AI05-0234-1AI05-0234-1} The accessibility level of the result of a
+ function call is that of the master of the function call, which is
+ determined by the point of call as follows:
+
+10.2/3
+ * If the result is used (in its entirety) to directly
+ initialize part of an object, the master is that of the
+ object being initialized. In the case where the
+ initialized object is a coextension (see below) that
+ becomes a coextension of another object, the master is
+ that of the eventual object to which the coextension will
+ be transferred.
+
+10.a/2
+ To be honest: {AI95-00416-01AI95-00416-01} The first sentence
+ is talking about a static use of the entire return object -- a
+ slice that happens to be the entire return object doesn't
+ count. On the other hand, this is intended to allow
+ parentheses and qualified_expressions.
+
+10.b/3
+ Ramification: {AI95-00416-01AI95-00416-01}
+ {AI05-0234-1AI05-0234-1} If the function is used as a prefix,
+ this bullet does not apply. Similarly, an
+ assignment_statement is not an initialization of an object, so
+ this bullet does not apply.
+
+10.3/3
+ * If the result is of an anonymous access type and is the
+ operand of an explicit conversion, the master is that of
+ the target type of the conversion;
+
+10.4/3
+ * If the result is of an anonymous access type and defines
+ an access discriminant, the master is the same as that
+ for an object created by an anonymous allocator that
+ defines an access discriminant (even if the access result
+ is of an access-to-subprogram type).
+
+10.5/3
+ * If the call itself defines the result of a function to
+ which one of the above rules applies, these rules are
+ applied recursively;
+
+10.6/3
+ * In other cases, the master of the call is that of the
+ innermost master that evaluates the function call.
+
+10.c/2
+ Ramification: {AI95-00318-02AI95-00318-02}
+ {AI95-00416-01AI95-00416-01} The "innermost master which
+ evaluated the function call" does not include the function
+ call itself (which might be a master).
+
+10.d/2
+ {AI95-00318-02AI95-00318-02} {AI95-00416-01AI95-00416-01} We
+ really mean the innermost master here, which could be a very
+ short lifetime. Consider a function call used as a parameter
+ of a procedure call. In this case the innermost master which
+ evaluated the function call is the procedure call.
+
+10.d.1/3
+ Ramification: {AI05-0234-1AI05-0234-1} These rules do not
+ mention whether the result object is built-in-place (see *note
+ 7.6::). In particular, in the case where building in place is
+ optional, the choice whether or not to build-in-place has no
+ effect on masters, lifetimes, or accessibility.
+
+10.d.2/3
+ Implementation Note: {AI05-0234-1AI05-0234-1} There are
+ several cases where the implementation may have to pass in the
+ accessibility level of the result object on a call, to support
+ later rules where the accessibility level comes from the
+ master of the call:
+
+10.d.3/3
+ * when the function result may have a part with access
+ discriminants;
+
+10.d.4/3
+ * when the function result type is an anonymous access
+ type;
+
+10.d.5/3
+ * when the function result is built-in-place;
+
+10.d.6/3
+ * when the function has an explicitly aliased parameter.
+
+10.d.7/3
+ In particular, this implies passing a level parameter when the
+ result type is class-wide, since descendants may add access
+ discriminants. For most implementations this will mean that
+ functions with controlling results will also need a level
+ parameter.
+
+10.7/3
+ {AI05-0284-1AI05-0284-1} In the case of a call to a function whose
+ result type is an anonymous access type, the accessibility level of
+ the type of the result of the function call is also determined by
+ the point of call as described above.
+
+10.8/3
+ * {AI95-00416-01AI95-00416-01} Within a return statement, the
+ accessibility level of the return object is that of the execution
+ of the return statement. If the return statement completes
+ normally by returning from the function, then prior to leaving the
+ function, the accessibility level of the return object changes to
+ be a level determined by the point of call, as does the level of
+ any coextensions (see below) of the return object.
+
+10.e/2
+ Reason: We define the accessibility level of the return object
+ during the return statement to be that of the return statement
+ itself so that the object may be designated by objects local
+ to the return statement, but not by objects outside the return
+ statement. In addition, the intent is that the return object
+ gets finalized if the return statement ends without actually
+ returning (for example, due to propagating an exception, or a
+ goto). For a normal return, of course, no finalization is
+ done before returning.
+
+11
+ * The accessibility level of a derived access type is the same as
+ that of its ultimate ancestor.
+
+11.1/2
+ * {AI95-00230-01AI95-00230-01} The accessibility level of the
+ anonymous access type defined by an access_definition of an
+ object_renaming_declaration is the same as that of the renamed
+ view.
+
+12/2
+ * {AI95-00230-01AI95-00230-01} {AI95-00416-01AI95-00416-01} The
+ accessibility level of the anonymous access type of an access
+ discriminant in the subtype_indication or qualified_expression of
+ an allocator, or in the expression or return_subtype_indication
+ (*note 6.5: S0187.) of a return statement is determined as follows:
+
+12.1/2
+ * If the value of the access discriminant is determined by
+ a discriminant_association in a subtype_indication, the
+ accessibility level of the object or subprogram
+ designated by the associated value (or library level if
+ the value is null);
+
+12.a/2
+ Discussion: This deals with the following cases, when they
+ occur in the context of an allocator or return statement:
+
+12.b/2
+ * An extension_aggregate where the ancestor_part is a
+ subtype_mark denoting a constrained subtype;
+
+12.c/2
+ * An uninitialized allocator where the
+ subtype_indication defines a constrained subtype;
+
+12.d/2
+ * A discriminant of an object with a constrained
+ nominal subtype, including constrained components,
+ the result of calling a function with a constrained
+ result subtype, the dereference of an
+ access-to-constrained subtype, etc.
+
+12.e/3
+ Ramification: {AI05-0281-1AI05-0281-1} The subtype_indication
+ mentioned in this bullet is not necessarily the one given in
+ the allocator or return statement that is determining the
+ accessibility level; the constrained subtype might have been
+ defined in an earlier declaration (as a named subtype).
+
+12.f/3
+ {AI05-0005-1AI05-0005-1} If the value for this rule and the
+ next one is derived from an Unchecked_Access attribute, the
+ accessibility is library-level no matter what the
+ accessibility level of the object is (see *note 13.10::).
+
+12.2/3
+ * {AI05-0234-1AI05-0234-1} If the value of the access
+ discriminant is determined by a default_expression in the
+ declaration of the discriminant, the level of the object
+ or subprogram designated by the associated value (or
+ library level if null);
+
+12.f.1/3
+ Discussion: This covers the case of an unconstrained
+ subcomponent of a limited type with defaulted access
+ discriminants.
+
+12.3/3
+ * {AI05-0004-1AI05-0004-1} If the value of the access
+ discriminant is determined by a
+ record_component_association in an aggregate, the
+ accessibility level of the object or subprogram
+ designated by the associated value (or library level if
+ the value is null);
+
+12.g/2
+ Discussion: In this bullet, the aggregate has to occur in the
+ context of an allocator or return statement, while the
+ subtype_indication of the previous bullet can occur anywhere
+ (it doesn't have to be directly given in the allocator or
+ return statement).
+
+12.4/3
+ * In other cases, where the value of the access
+ discriminant is determined by an object with an
+ unconstrained nominal subtype, the accessibility level of
+ the object.
+
+12.h/2
+ Discussion: {AI95-00416-01AI95-00416-01} In other words, if
+ you know the value of the discriminant for an allocator or
+ return statement from a discriminant constraint or an
+ aggregate component association, then that determines the
+ accessibility level; if you don't know it, then it is based on
+ the object itself.
+
+12.5/3
+ * {AI95-00416-01AI95-00416-01} The accessibility level of the
+ anonymous access type of an access discriminant in any other
+ context is that of the enclosing object.
+
+13/3
+ * {AI95-00162-01AI95-00162-01} {AI95-00254-01AI95-00254-01}
+ {AI05-0270-1AI05-0270-1} The accessibility level of the anonymous
+ access type of an access parameter specifying an access-to-object
+ type is the same as that of the view designated by the actual (or
+ library-level if the actual is null).
+
+13.a/3
+ Ramification: {AI05-0005-1AI05-0005-1} If the value of the
+ actual is derived from an Unchecked_Access attribute, the
+ accessibility is always library-level (see *note 13.10::).
+
+13.1/2
+ * {AI95-00254-01AI95-00254-01} The accessibility level of the
+ anonymous access type of an access parameter specifying an
+ access-to-subprogram type is deeper than that of any master; all
+ such anonymous access types have this same level.
+
+13.b/2
+ Reason: These represent "downward closures" and thus require
+ passing of static links or global display information (along
+ with generic sharing information if the implementation does
+ sharing) along with the address of the subprogram. We must
+ prevent conversions of these to types with "normal"
+ accessibility, as those typically don't include the extra
+ information needed to make a call.
+
+13.2/3
+ * {AI05-0148-1AI05-0148-1} {AI05-0240-1AI05-0240-1} The accessibility
+ level of the type of a stand-alone object of an anonymous
+ access-to-object type is the same as the accessibility level of the
+ type of the access value most recently assigned to the object[;
+ accessibility checks ensure that this is never deeper than that of
+ the declaration of the stand-alone object].
+
+13.3/3
+ * {AI05-0142-4AI05-0142-4} {AI05-0240-1AI05-0240-1} The accessibility
+ level of an explicitly aliased (see *note 6.1::) formal parameter
+ in a function body is determined by the point of call; it is the
+ same level that the return object ultimately will have.
+
+14/3
+ * {AI95-00416-01AI95-00416-01} {AI05-0051-1AI05-0051-1}
+ {AI05-0253-1AI05-0253-1} The accessibility level of an object
+ created by an allocator is the same as that of the access type,
+ except for an allocator of an anonymous access type (an anonymous
+ allocator) in certain contexts, as follows: For an anonymous
+ allocator that defines the result of a function with an access
+ result, the accessibility level is determined as though the
+ allocator were in place of the call of the function; in the special
+ case of a call that is the operand of a type conversion, the level
+ is that of the target access type of the conversion. For an
+ anonymous allocator defining the value of an access parameter, the
+ accessibility level is that of the innermost master of the call.
+ For an anonymous allocator whose type is that of a stand-alone
+ object of an anonymous access-to-object type, the accessibility
+ level is that of the declaration of the stand-alone object. For
+ one defining an access discriminant, the accessibility level is
+ determined as follows:
+
+14.1/3
+ * {AI95-00416-01AI95-00416-01} {AI05-0024-1AI05-0024-1} for
+ an allocator used to define the discriminant of an
+ object, the level of the object;
+
+14.2/3
+ * {AI95-00416-01AI95-00416-01} {AI05-0024-1AI05-0024-1} for
+ an allocator used to define the constraint in a
+ subtype_indication in any other context, the level of the
+ master that elaborates the subtype_indication.
+
+14.3/3
+ * This paragraph was deleted.{AI95-00416-01AI95-00416-01}
+ {AI05-0024-1AI05-0024-1}
+
+14.4/3
+ {AI95-00416-01AI95-00416-01} {AI05-0024-1AI05-0024-1}
+ {AI05-0066-1AI05-0066-1} In the first case, the allocated object is
+ said to be a coextension of the object whose discriminant
+ designates it, as well as of any object of which the discriminated
+ object is itself a coextension or subcomponent. If the allocated
+ object is a coextension of an anonymous object representing the
+ result of an aggregate or function call that is used (in its
+ entirety) to directly initialize a part of an object, after the
+ result is assigned, the coextension becomes a coextension of the
+ object being initialized and is no longer considered a coextension
+ of the anonymous object. All coextensions of an object [(which
+ have not thus been transfered by such an initialization)] are
+ finalized when the object is finalized (see *note 7.6.1::).
+
+14.a.1/2
+ Ramification: The rules of access discriminants are such that
+ when the space for an object with a coextension is reclaimed,
+ the space for the coextensions can be reclaimed. Hence, there
+ is implementation advice (see 13.11) that an object and its
+ coextensions all be allocated from the same storage pool (or
+ stack frame, in the case of a declared object).
+
+14.5/3
+ * {AI05-0051-1AI05-0051-1} Within a return statement, the
+ accessibility level of the anonymous access type of an access
+ result is that of the master of the call.
+
+15/3
+ * {AI05-0014-1AI05-0014-1} The accessibility level of a view of an
+ object or subprogram designated by an access value is the same as
+ that of the access type.
+
+15.a/3
+ Discussion: {AI05-0005-1AI05-0005-1} {AI05-0014-1AI05-0014-1}
+ This rule applies even when no dereference exists, for example
+ when an access value is passed as an access parameter. This
+ rule ensures that implementations are not required to include
+ dynamic accessibility values with all access values.
+
+16
+ * The accessibility level of a component, protected subprogram, or
+ entry of (a view of) a composite object is the same as that of (the
+ view of) the composite object.
+
+16.1/3
+{AI95-00416-01AI95-00416-01} {AI05-0262-1AI05-0262-1} In the above
+rules, the operand of a view conversion, parenthesized expression or
+qualified_expression is considered to be used in a context if the view
+conversion, parenthesized expression or qualified_expression itself is
+used in that context. Similarly, a dependent_expression of a
+conditional_expression is considered to be used in a context if the
+conditional_expression itself is used in that context.
+
+17
+One accessibility level is defined to be statically deeper than another
+in the following cases:
+
+18
+ * For a master that is statically nested within another master, the
+ accessibility level of the inner master is statically deeper than
+ that of the outer master.
+
+18.a
+ To be honest: Strictly speaking, this should talk about the
+ constructs (such as subprogram_bodies) being statically nested
+ within one another; the masters are really the executions of
+ those constructs.
+
+18.b
+ To be honest: If a given accessibility level is statically
+ deeper than another, then each level defined to be the same as
+ the given level is statically deeper than each level defined
+ to be the same as the other level.
+
+18.1/2
+ * {AI95-00254-01AI95-00254-01} The accessibility level of the
+ anonymous access type of an access parameter specifying an
+ access-to-subprogram type is statically deeper than that of any
+ master; all such anonymous access types have this same level.
+
+18.c/2
+ Ramification: This rule means that it is illegal to convert an
+ access parameter specifying an access to subprogram to a named
+ access to subprogram type, but it is allowed to pass such an
+ access parameter to another access parameter (the implicit
+ conversion's accessibility will succeed).
+
+19/3
+ * {AI95-00254-01AI95-00254-01} {AI05-0082-1AI05-0082-1} The
+ statically deeper relationship does not apply to the accessibility
+ level of the anonymous type of an access parameter specifying an
+ access-to-object type nor does it apply to a descendant of a
+ generic formal type; that is, such an accessibility level is not
+ considered to be statically deeper, nor statically shallower, than
+ any other.
+
+19.1/3
+ * {AI05-0148-1AI05-0148-1} The statically deeper relationship does
+ not apply to the accessibility level of the type of a stand-alone
+ object of an anonymous access-to-object type; that is, such an
+ accessibility level is not considered to be statically deeper, nor
+ statically shallower, than any other.
+
+19.a/3
+ Ramification: In these cases, we use dynamic accessibility
+ checks.
+
+19.2/3
+ * {AI05-0142-4AI05-0142-4} {AI05-0235-1AI05-0235-1} Inside a return
+ statement that applies to a function F, when determining whether
+ the accessibility level of an explicitly aliased parameter of F is
+ statically deeper than the level of the return object of F, the
+ level of the return object is considered to be the same as that of
+ the level of the explicitly aliased parameter; for statically
+ comparing with the level of other entities, an explicitly aliased
+ parameter of F is considered to have the accessibility level of the
+ body of F.
+
+19.3/3
+ * {AI05-0051-1AI05-0051-1} {AI05-0234-1AI05-0234-1}
+ {AI05-0235-1AI05-0235-1} For determining whether a level is
+ statically deeper than the level of the anonymous access type of an
+ access result of a function, when within a return statement that
+ applies to the function, the level of the master of the call is
+ presumed to be the same as that of the level of the master that
+ elaborated the function body.
+
+19.b/3
+ To be honest: {AI05-0235-1AI05-0235-1} This rule has no effect
+ if the previous bullet also applies (that is, the "a level" is
+ of an explicitly aliased parameter).
+
+20
+ * [For determining whether one level is statically deeper than
+ another when within a generic package body, the generic package is
+ presumed to be instantiated at the same level as where it was
+ declared; run-time checks are needed in the case of more deeply
+ nested instantiations.]
+
+20.a/3
+ Proof: {AI05-0082-1AI05-0082-1} A generic package does not
+ introduce a new master, so it has the static level of its
+ declaration; the rest follows from the other "statically
+ deeper" rules.
+
+21
+ * For determining whether one level is statically deeper than another
+ when within the declarative region of a type_declaration, the
+ current instance of the type is presumed to be an object created at
+ a deeper level than that of the type.
+
+21.a
+ Ramification: In other words, the rules are checked at compile
+ time of the type_declaration, in an assume-the-worst manner.
+
+22
+The accessibility level of all library units is called the library
+level; a library-level declaration or entity is one whose accessibility
+level is the library level.
+
+22.a
+ Ramification: Library_unit_declarations are library level.
+ Nested declarations are library level if they are nested only
+ within packages (possibly more than one), and not within
+ subprograms, tasks, etc.
+
+22.b/2
+ To be honest: The definition of the accessibility level of the
+ anonymous type of an access parameter specifying an
+ access-to-object type cheats a bit, since it refers to the
+ view designated by the actual, but access values designate
+ objects, not views of objects. What we really mean is the
+ view that "would be" denoted by an expression "X.all", where X
+ is the actual, even though such an expression is a figment of
+ our imagination. The definition is intended to be equivalent
+ to the following more verbose version: The accessibility level
+ of the anonymous type of an access parameter is as follows:
+
+22.c
+ * if the actual is an expression of a named access type --
+ the accessibility level of that type;
+
+22.d
+ * if the actual is an allocator -- the accessibility level
+ of the execution of the called subprogram;
+
+22.e/1
+ * if the actual is a reference to the Access attribute --
+ the accessibility level of the view denoted by the
+ prefix;
+
+22.f
+ * if the actual is a reference to the Unchecked_Access
+ attribute -- library accessibility level;
+
+22.g
+ * if the actual is an access parameter -- the accessibility
+ level of its type.
+
+22.h
+ Note that the allocator case is explicitly mentioned in the
+ RM95, because otherwise the definition would be circular: the
+ level of the anonymous type is that of the view designated by
+ the actual, which is that of the access type.
+
+22.i
+ Discussion: A deeper accessibility level implies a shorter
+ maximum lifetime. Hence, when a rule requires X to have a
+ level that is "not deeper than" Y's level, this requires that
+ X has a lifetime at least as long as Y. (We say "maximum
+ lifetime" here, because the accessibility level really
+ represents an upper bound on the lifetime; an object created
+ by an allocator can have its lifetime prematurely ended by an
+ instance of Unchecked_Deallocation.)
+
+22.j
+ Package elaborations are not masters, and are therefore
+ invisible to the accessibility rules: an object declared
+ immediately within a package has the same accessibility level
+ as an object declared immediately within the declarative
+ region containing the package. This is true even in the body
+ of a package; it jibes with the fact that objects declared in
+ a package_body live as long as objects declared outside the
+ package, even though the body objects are not visible outside
+ the package.
+
+22.k
+ Note that the level of the view denoted by X.all can be
+ different from the level of the object denoted by X.all. The
+ former is determined by the type of X; the latter is
+ determined either by the type of the allocator, or by the
+ master in which the object was declared. The former is used
+ in several Legality Rules and run-time checks; the latter is
+ used to define when X.all gets finalized. The level of a view
+ reflects what we can conservatively "know" about the object of
+ that view; for example, due to type_conversions, an access
+ value might designate an object that was allocated by an
+ allocator for a different access type.
+
+22.l
+ Similarly, the level of the view denoted by X.all.Comp can be
+ different from the level of the object denoted by X.all.Comp.
+
+22.m
+ If Y is statically deeper than X, this implies that Y will be
+ (dynamically) deeper than X in all possible executions.
+
+22.n
+ Most accessibility checking is done at compile time; the rules
+ are stated in terms of "statically deeper than". The
+ exceptions are:
+
+22.o/2
+ * Checks involving access parameters of an access-to-object
+ type. The fact that "statically deeper than" is not
+ defined for the anonymous access type of an access
+ parameter implies that any rule saying "shall not be
+ statically deeper than" does not apply to such a type,
+ nor to anything defined to have "the same" level as such
+ a type.
+
+22.o.1/3
+ * {AI05-0082-1AI05-0082-1} Checks involving generic formal
+ types and their descendants. This is because the actual
+ type can be more or less deeply nested than the generic
+ unit. Note that this only applies to the generic unit
+ itself, and not to the instance. Any static checks
+ needed in the instance will be performed. Any other
+ checks (such as those in the generic body) will require a
+ run-time check of some sort (although implementations
+ that macro-expand generics can determine the result of
+ the check when the generic is expanded).
+
+22.p/3
+ * {AI05-0082-1AI05-0082-1} Checks involving other entities
+ and views within generic packages. This is because an
+ instantiation can be at a level that is more deeply
+ nested than the generic package itself. In
+ implementations that use a macro-expansion model of
+ generics, these violations can be detected at
+ macro-expansion time. For implementations that share
+ generics, run-time code is needed to detect the error.
+
+22.q/2
+ * {AI95-00318-02AI95-00318-02} {AI95-00344-01AI95-00344-01}
+ {AI95-00416-01AI95-00416-01} Checks during function
+ return and allocators, for nested type extensions and
+ access discriminants.
+
+22.r/3
+ {AI05-0005-1AI05-0005-1} Note that run-time checks are not
+ required for access discriminants (except during function
+ returns and allocators), because their accessibility is
+ determined statically by the accessibility level of the
+ enclosing object.
+
+22.s/2
+ The accessibility level of the result object of a function
+ reflects the time when that object will be finalized; we don't
+ allow pointers to the object to survive beyond that time.
+
+22.t
+ We sometimes use the terms "accessible" and "inaccessible" to
+ mean that something has an accessibility level that is not
+ deeper, or deeper, respectively, than something else.
+
+22.u/2
+ Implementation Note: {AI95-00318-02AI95-00318-02}
+ {AI95-00344-01AI95-00344-01} {AI95-00416-01AI95-00416-01} If
+ an accessibility Legality Rule is satisfied, then the
+ corresponding run-time check (if any) cannot fail (and a
+ reasonable implementation will not generate any checking code)
+ unless one of the cases requiring run-time checks mentioned
+ previously is involved.
+
+22.v
+ Accessibility levels are defined in terms of the relations
+ "the same as" and "deeper than". To make the discussion more
+ concrete, we can assign actual numbers to each level. Here,
+ we assume that library-level accessibility is level 0, and
+ each level defined as "deeper than" is one level deeper.
+ Thus, a subprogram directly called from the environment task
+ (such as the main subprogram) would be at level 1, and so on.
+
+22.w/2
+ Accessibility is not enforced at compile time for access
+ parameters of an access-to-object type. The "obvious"
+ implementation of the run-time checks would be inefficient,
+ and would involve distributed overhead; therefore, an
+ efficient method is given below. The "obvious" implementation
+ would be to pass the level of the caller at each subprogram
+ call, task creation, etc. This level would be incremented by
+ 1 for each dynamically nested master. An Accessibility_Check
+ would be implemented as a simple comparison -- checking that X
+ is not deeper than Y would involve checking that X <= Y.
+
+22.x
+ A more efficient method is based on passing static nesting
+ levels (within constructs that correspond at run time to
+ masters -- packages don't count). Whenever an access
+ parameter is passed, an implicit extra parameter is passed
+ with it. The extra parameter represents (in an indirect way)
+ the accessibility level of the anonymous access type, and,
+ therefore, the level of the view denoted by a dereference of
+ the access parameter. This is analogous to the implicit
+ "Constrained" bit associated with certain formal parameters of
+ an unconstrained but definite composite subtype. In this
+ method, we avoid distributed overhead: it is not necessary to
+ pass any extra information to subprograms that have no access
+ parameters. For anything other than an access parameter and
+ its anonymous type, the static nesting level is known at
+ compile time, and is defined analogously to the RM95
+ definition of accessibility level (e.g. derived access types
+ get their nesting level from their parent). Checking "not
+ deeper than" is a "<=" test on the levels.
+
+22.y/2
+ For each access parameter of an access-to-object type, the
+ static depth passed depends on the actual, as follows:
+
+22.z
+ * If the actual is an expression of a named access type,
+ pass the static nesting level of that type.
+
+22.aa
+ * If the actual is an allocator, pass the static nesting
+ level of the caller, plus one.
+
+22.bb/1
+ * If the actual is a reference to the Access attribute,
+ pass the level of the view denoted by the prefix.
+
+22.cc
+ * If the actual is a reference to the Unchecked_Access
+ attribute, pass 0 (the library accessibility level).
+
+22.dd/2
+ * If the actual is an access parameter of an
+ access-to-object type, usually just pass along the level
+ passed in. However, if the static nesting level of the
+ formal (access) parameter is greater than the static
+ nesting level of the actual (access) parameter, the level
+ to be passed is the minimum of the static nesting level
+ of the access parameter and the actual level passed in.
+
+22.ee/2
+ For the Accessibility_Check associated with a type_conversion
+ of an access parameter of an access-to-object type of a given
+ subprogram to a named access type, if the target type is
+ statically nested within the subprogram, do nothing; the check
+ can't fail in this case. Otherwise, check that the value
+ passed in is <= the static nesting depth of the target type.
+ The other Accessibility_Checks are handled in a similar
+ manner.
+
+22.ff
+ This method, using statically known values most of the time,
+ is efficient, and, more importantly, avoids distributed
+ overhead.
+
+22.ff.1/3
+ {AI05-0148-1AI05-0148-1} The implementation of accessibility
+ checks for stand-alone objects of anonymous access-to-object
+ types can be similar to that for anonymous access-to-object
+ parameters. A static level suffices; it can be calculated
+ using rules similar to those previously described for access
+ parameters.
+
+22.ff.2/3
+ {AI05-0148-1AI05-0148-1} One important difference between the
+ stand-alone access variables and access parameters is that one
+ can assign a local access parameter to a more global
+ stand-alone access variable. Similarly, one can assign a more
+ global access parameter to a more local stand-alone access
+ variable.
+
+22.ff.3/3
+ {AI05-0148-1AI05-0148-1} For these cases, it is important to
+ note that the "correct" static accessibility level for an
+ access parameter assigned to a stand-alone access object is
+ the minimum of the passed in level and the static
+ accessibility level of the stand-alone object itself. This is
+ true since the static accessibility level passed in might be
+ deeper than that of the stand-alone object, but the dynamic
+ accessibility of the passed in object clearly must be
+ shallower than the stand-alone object (whatever is passed in
+ must live at least as long as the subprogram call). We do not
+ need to keep a more local static level as accesses to objects
+ statically deeper than the stand-alone object cannot be stored
+ into the stand-alone object.
+
+22.gg
+ Discussion: Examples of accessibility:
+
+22.hh/3
+ {AI05-0005-1AI05-0005-1} package body Lib_Unit is
+ type T is tagged ...;
+ type A0 is access all T;
+ Global: A0 := ...;
+ procedure P(X: in out T) is
+ Y: aliased T;
+ type A1 is access all T;
+ Ptr0: A0 := Global; -- OK.
+ Ptr1: A1 := X'Access; -- OK.
+ begin
+ Ptr1 := Y'Access; -- OK;
+ Ptr0 := A0(Ptr1); -- Illegal type conversion!
+ Ptr0 := X'Access; -- Illegal reference to Access attribute!
+ Ptr0 := Y'Access; -- Illegal reference to Access attribute!
+ Global := Ptr0; -- OK.
+ end P;
+ end Lib_Unit;
+
+22.ii/3
+ {AI05-0005-1AI05-0005-1} The above illegal statements are
+ illegal because the accessibility levels of X and Y are
+ statically deeper than the accessibility level of A0. In
+ every possible execution of any program including this library
+ unit, if P is called, the accessibility level of X will be
+ (dynamically) deeper than that of A0. Note that the
+ accessibility levels of X and Y are the same.
+
+22.jj/2
+ Here's an example involving access parameters of an
+ access-to-object type:
+
+22.kk
+ procedure Main is
+ type Level_1_Type is access all Integer;
+
+22.ll
+ procedure P(X: access Integer) is
+ type Nested_Type is access all Integer;
+ begin
+ ... Nested_Type(X) ... -- (1)
+ ... Level_1_Type(X) ... -- (2)
+ end P;
+
+22.mm
+ procedure Q(X: access Integer) is
+ procedure Nested(X: access Integer) is
+ begin
+ P(X);
+ end Nested;
+ begin
+ Nested(X);
+ end Q;
+
+22.nn
+ procedure R is
+ Level_2: aliased Integer;
+ begin
+ Q(Level_2'Access); -- (3)
+ end R;
+
+22.oo
+ Level_1: aliased Integer;
+ begin
+ Q(Level_1'Access); -- (4)
+ R;
+ end Main;
+
+22.pp
+ The run-time Accessibility_Check at (1) can never fail, and no
+ code should be generated to check it. The check at (2) will
+ fail when called from (3), but not when called from (4).
+
+22.qq
+ Within a type_declaration, the rules are checked in an
+ assume-the-worst manner. For example:
+
+22.rr/3
+ {AI05-0298-1AI05-0298-1} package P is
+ type Int_Ptr is access all Integer;
+ type Rec(D: access Integer) is limited private;
+ private
+ type Rec_Ptr is access all Rec;
+ function F(X: Rec_Ptr) return Boolean;
+ function G(X: access Rec) return Boolean;
+ type Rec(D: access Integer) is
+ limited record
+ C1: Int_Ptr := Int_Ptr(D); -- Illegal!
+ C2: Rec_Ptr := Rec'Access; -- Illegal!
+ C3: Boolean := F(Rec'Access); -- Illegal!
+ C4: Boolean := G(Rec'Access);
+ end record;
+ end P;
+
+22.ss
+ C1, C2, and C3 are all illegal, because one might declare an
+ object of type Rec at a more deeply nested place than the
+ declaration of the type. C4 is legal, but the accessibility
+ level of the object will be passed to function G, and
+ constraint checks within G will prevent it from doing any evil
+ deeds.
+
+22.tt
+ Note that we cannot defer the checks on C1, C2, and C3 until
+ compile-time of the object creation, because that would cause
+ violation of the privacy of private parts. Furthermore, the
+ problems might occur within a task or protected body, which
+ the compiler can't see while compiling an object creation.
+
+23
+The following attribute is defined for a prefix X that denotes an
+aliased view of an object:
+
+24/1
+X'Access
+ {8652/00108652/0010} {AI95-00127-01AI95-00127-01}
+ X'Access yields an access value that designates the
+ object denoted by X. The type of X'Access is an
+ access-to-object type, as determined by the expected
+ type. The expected type shall be a general access type.
+ X shall denote an aliased view of an object[, including
+ possibly the current instance (see *note 8.6::) of a
+ limited type within its definition, or a formal parameter
+ or generic formal object of a tagged type]. The view
+ denoted by the prefix X shall satisfy the following
+ additional requirements, presuming the expected type for
+ X'Access is the general access type A with designated
+ type D:
+
+25
+ * If A is an access-to-variable type, then the view
+ shall be a variable; [on the other hand, if A is an
+ access-to-constant type, the view may be either a
+ constant or a variable.]
+
+25.a
+ Discussion: The current instance of a limited type is
+ considered a variable.
+
+26/3
+ * {AI95-00363-01AI95-00363-01}
+ {AI05-0008-1AI05-0008-1} {AI05-0041-1AI05-0041-1}
+ The view shall not be a subcomponent that depends on
+ discriminants of an object unless the object is
+ known to be constrained.
+
+26.a
+ Discussion: This restriction is intended to be similar to the
+ restriction on renaming discriminant-dependent subcomponents.
+
+26.b
+ Reason: This prevents references to subcomponents that might
+ disappear or move or change constraints after creating the
+ reference.
+
+26.c
+ Implementation Note: There was some thought to making this
+ restriction more stringent, roughly: "X shall not denote a
+ subcomponent of a variable with discriminant-dependent
+ subcomponents, if the nominal subtype of the variable is an
+ unconstrained definite subtype." This was because in some
+ implementations, it is not just the discriminant-dependent
+ subcomponents that might move as the result of an assignment
+ that changed the discriminants of the enclosing object.
+ However, it was decided not to make this change because a
+ reasonable implementation strategy was identified to avoid
+ such problems, as follows:
+
+26.d
+ * Place non-discriminant-dependent components with any
+ aliased parts at offsets preceding any
+ discriminant-dependent components in a discriminated
+ record type with defaulted discriminants.
+
+26.e
+ * Preallocate the maximum space for unconstrained
+ discriminated variables with aliased subcomponents,
+ rather than allocating the initial size and moving them
+ to a larger (heap-resident) place if they grow as the
+ result of an assignment.
+
+26.f
+ Note that for objects of a by-reference type, it is not an
+ error for a programmer to take advantage of the fact that such
+ objects are passed by reference. Therefore, the above
+ approach is also necessary for discriminated record types with
+ components of a by-reference type.
+
+26.g
+ To make the above strategy work, it is important that a
+ component of a derived type is defined to be
+ discriminant-dependent if it is inherited and the parent
+ subtype constraint is defined in terms of a discriminant of
+ the derived type (see *note 3.7::).
+
+27/2
+ * {8652/00108652/0010} {AI95-00127-01AI95-00127-01}
+ {AI95-00363-01AI95-00363-01} If A is a named access
+ type and D is a tagged type, then the type of the
+ view shall be covered by D; if A is anonymous and D
+ is tagged, then the type of the view shall be either
+ D'Class or a type covered by D; if D is untagged,
+ then the type of the view shall be D, and either:
+
+27.1/2
+ * {AI95-00363-01AI95-00363-01} the
+ designated subtype of A shall statically
+ match the nominal subtype of the view; or
+
+27.2/3
+ * {AI95-00363-01AI95-00363-01}
+ {AI05-0041-1AI05-0041-1} D shall be
+ discriminated in its full view and
+ unconstrained in any partial view, and the
+ designated subtype of A shall be
+ unconstrained. For the purposes of
+ determining within a generic body whether
+ D is unconstrained in any partial view, a
+ discriminated subtype is considered to
+ have a constrained partial view if it is a
+ descendant of an untagged generic formal
+ private or derived type.
+
+27.a
+ Implementation Note: This ensures that the dope for an aliased
+ array object can always be stored contiguous with it, but need
+ not be if its nominal subtype is constrained.
+
+27.a.1/1
+ Ramification: {8652/00108652/0010}
+ {AI95-00127-01AI95-00127-01} An access attribute can be used
+ as the controlling operand in a dispatching call; see *note
+ 3.9.2::.
+
+27.a.2/2
+ {AI95-00363-01AI95-00363-01} This does not require that types
+ have a partial view in order to allow an access attribute of
+ an unconstrained discriminated object, only that any partial
+ view that does exist is unconstrained.
+
+28/3
+ * {AI05-0041-1AI05-0041-1} The accessibility level of
+ the view shall not be statically deeper than that of
+ the access type A.
+
+28.a
+ Ramification: In an instance body, a run-time check applies.
+
+28.b/2
+ {AI95-00230-01AI95-00230-01} If A is an anonymous
+ access-to-object type of an access parameter, then the view
+ can never have a deeper accessibility level than A. The same
+ is true for an anonymous access-to-object type of an access
+ discriminant, except when X'Access is used to initialize an
+ access discriminant of an object created by an allocator. The
+ latter case is illegal if the accessibility level of X is
+ statically deeper than that of the access type of the
+ allocator; a run-time check is needed in the case where the
+ initial value comes from an access parameter. Other anonymous
+ access-to-object types have "normal" accessibility checks.
+
+28.1/3
+ {AI05-0041-1AI05-0041-1} In addition to the places where
+ Legality Rules normally apply (see *note 12.3::), these
+ requirements apply also in the private part of an
+ instance of a generic unit.
+
+29
+ A check is made that the accessibility level of X is not
+ deeper than that of the access type A. If this check
+ fails, Program_Error is raised.
+
+29.a/2
+ Ramification: The check is needed for access parameters of an
+ access-to-object type and in instance bodies.
+
+29.a.1/3
+ {AI05-0024-1AI05-0024-1} Because there are no access
+ parameters permitted for task entries, the accessibility
+ levels are always comparable. We would have to switch to the
+ terminology used in *note 4.8:: and *note 6.5:: based on
+ inclusion within masters if we relax this restriction. That
+ might introduce unacceptable distributed overhead.
+
+29.b/3
+ Implementation Note: {AI05-0148-1AI05-0148-1} This check
+ requires that some indication of lifetime is passed as an
+ implicit parameter along with access parameters of an
+ access-to-object type. A similar indication is required for
+ stand-alone objects of anonymous access-to-object types.No
+ such requirement applies to other anonymous access types,
+ since the checks associated with them are all compile-time
+ checks.
+
+30
+ If the nominal subtype of X does not statically match the
+ designated subtype of A, a view conversion of X to the
+ designated subtype is evaluated (which might raise
+ Constraint_Error -- see *note 4.6::) and the value of
+ X'Access designates that view.
+
+31
+The following attribute is defined for a prefix P that denotes a
+subprogram:
+
+32/3
+P'Access
+ {AI95-00229-01AI95-00229-01} {AI95-00254-01AI95-00254-01}
+ {AI05-0239-1AI05-0239-1} P'Access yields an access value
+ that designates the subprogram denoted by P. The type of
+ P'Access is an access-to-subprogram type (S), as
+ determined by the expected type. The accessibility level
+ of P shall not be statically deeper than that of S. In
+ addition to the places where Legality Rules normally
+ apply (see *note 12.3::), this rule applies also in the
+ private part of an instance of a generic unit. The
+ profile of P shall be subtype conformant with the
+ designated profile of S, and shall not be Intrinsic. If
+ the subprogram denoted by P is declared within a generic
+ unit, and the expression P'Access occurs within the body
+ of that generic unit or within the body of a generic unit
+ declared within the declarative region of the generic
+ unit, then the ultimate ancestor of S shall be either a
+ nonformal type declared within the generic unit or an
+ anonymous access type of an access parameter.
+
+32.a/2
+ Discussion: {AI95-00229-01AI95-00229-01} The part about
+ generic bodies is worded in terms of the denoted subprogram,
+ not the denoted view; this implies that renaming is invisible
+ to this part of the rule. "Declared within the declarative
+ region of the generic" is referring to child and nested
+ generic units.This rule is partly to prevent contract model
+ problems with respect to the accessibility rules, and partly
+ to ease shared-generic-body implementations, in which a
+ subprogram declared in an instance needs to have a different
+ calling convention from other subprograms with the same
+ profile.
+
+32.b
+ Overload resolution ensures only that the profile is type
+ conformant. This rule specifies that subtype conformance is
+ required (which also requires matching calling conventions).
+ P cannot denote an entry because access-to-subprogram types
+ never have the entry calling convention. P cannot denote an
+ enumeration literal or an attribute function because these
+ have intrinsic calling conventions.
+
+ _Legality Rules_
+
+32.1/3
+{AI05-0188-1AI05-0188-1} An expression is said to have distributed
+accessibility if it is
+
+32.2/3
+ * a conditional_expression (see *note 4.5.7::); or
+
+32.3/3
+ * a view conversion, qualified_expression, or parenthesized
+ expression whose operand has distributed accessibility.
+
+32.4/3
+{AI05-0188-1AI05-0188-1} The statically deeper relationship does not
+apply to the accessibility level of an expression having distributed
+accessibility; that is, such an accessibility level is not considered to
+be statically deeper, nor statically shallower, than any other.
+
+32.5/3
+{AI05-0188-1AI05-0188-1} Any static accessibility requirement that is
+imposed on an expression that has distributed accessibility (or on its
+type) is instead imposed on the dependent_expressions of the underlying
+conditional_expression. This rule is applied recursively if a
+dependent_expression also has distributed accessibility.
+
+32.c/3
+ Discussion: This means that any Legality Rule requiring that
+ the accessibility level of an expression (or that of the type
+ of an expression) shall or shall not be statically deeper than
+ some other level also applies, in the case where the
+ expression has distributed accessibility, to each
+ dependent_expression of the underlying conditional_expression.
+
+ NOTES
+
+33
+ 88 The Unchecked_Access attribute yields the same result as the
+ Access attribute for objects, but has fewer restrictions (see *note
+ 13.10::). There are other predefined operations that yield access
+ values: an allocator can be used to create an object, and return an
+ access value that designates it (see *note 4.8::); evaluating the
+ literal null yields a null access value that designates no entity
+ at all (see *note 4.2::).
+
+34/2
+ 89 {AI95-00230-01AI95-00230-01} The predefined operations of an
+ access type also include the assignment operation, qualification,
+ and membership tests. Explicit conversion is allowed between
+ general access types with matching designated subtypes; explicit
+ conversion is allowed between access-to-subprogram types with
+ subtype conformant profiles (see *note 4.6::). Named access types
+ have predefined equality operators; anonymous access types do not,
+ but they can use the predefined equality operators for
+ universal_access (see *note 4.5.2::).
+
+34.a/2
+ Reason: {AI95-00230-01AI95-00230-01} Anonymous access types
+ can use the universal access equality operators declared in
+ Standard, while named access types cannot for compatibility
+ reasons. By not having equality operators for anonymous
+ access types, we eliminate the need to specify exactly where
+ the predefined operators for anonymous access types would be
+ defined, as well as the need for an implementer to insert an
+ implicit declaration for "=", etc. at the appropriate place
+ in their symbol table. Note that ":=", 'Access, and ".all"
+ are defined.
+
+35
+ 90 The object or subprogram designated by an access value can be
+ named with a dereference, either an explicit_dereference (*note
+ 4.1: S0094.) or an implicit_dereference. See *note 4.1::.
+
+36
+ 91 A call through the dereference of an access-to-subprogram value
+ is never a dispatching call.
+
+36.a
+ Proof: See *note 3.9.2::.
+
+37/2
+ 92 {AI95-00254-01AI95-00254-01} The Access attribute for
+ subprograms and parameters of an anonymous access-to-subprogram
+ type may together be used to implement "downward closures" -- that
+ is, to pass a more-nested subprogram as a parameter to a
+ less-nested subprogram, as might be appropriate for an iterator
+ abstraction or numerical integration. Downward closures can also
+ be implemented using generic formal subprograms (see *note 12.6::).
+ Note that Unchecked_Access is not allowed for subprograms.
+
+38
+ 93 Note that using an access-to-class-wide tagged type with a
+ dispatching operation is a potentially more structured alternative
+ to using an access-to-subprogram type.
+
+39
+ 94 An implementation may consider two access-to-subprogram values
+ to be unequal, even though they designate the same subprogram.
+ This might be because one points directly to the subprogram, while
+ the other points to a special prologue that performs an
+ Elaboration_Check and then jumps to the subprogram. See *note
+ 4.5.2::.
+
+39.a
+ Ramification: If equality of access-to-subprogram values is
+ important to the logic of a program, a reference to the Access
+ attribute of a subprogram should be evaluated only once and
+ stored in a global constant for subsequent use and equality
+ comparison.
+
+ _Examples_
+
+40
+Example of use of the Access attribute:
+
+41
+ Martha : Person_Name := new Person(F); -- see *note 3.10.1::
+ Cars : array (1..2) of aliased Car;
+ ...
+ Martha.Vehicle := Cars(1)'Access;
+ George.Vehicle := Cars(2)'Access;
+
+ _Extensions to Ada 83_
+
+41.a
+ We no longer make things like 'Last and ".component" (basic)
+ operations of an access type that need to be "declared"
+ somewhere. Instead, implicit dereference in a prefix takes
+ care of them all. This means that there should never be a
+ case when X.all'Last is legal while X'Last is not. See
+ AI83-00154.
+
+ _Incompatibilities With Ada 95_
+
+41.b/2
+ {AI95-00363-01AI95-00363-01} Aliased variables are not
+ necessarily constrained in Ada 2005 (see *note 3.6::).
+ Therefore, a subcomponent of an aliased variable may disappear
+ or change shape, and taking 'Access of such a subcomponent
+ thus is illegal, while the same operation would have been
+ legal in Ada 95. Note that most allocated objects are still
+ constrained by their initial value (see *note 4.8::), and thus
+ legality of 'Access didn't change for them. For example:
+
+41.c/2
+ type T1 (D1 : Boolean := False) is
+ record
+ case D1 is
+ when False =>
+ C1 : aliased Integer;
+ when True =>
+ null;
+ end case;
+ end record;
+ type Acc_Int is access all Integer;
+
+41.d/2
+ A_T : aliased T1;
+ Ptr : Acc_Int := A_T.C1'Access; -- Illegal in Ada 2005, legal in Ada 95
+ A_T := (D1 => True); -- Raised Constraint_Error in Ada 95, but does not
+ -- in Ada 2005, so Ptr would become invalid when this
+ -- is assigned (thus Ptr is illegal).
+
+41.e/2
+ {AI95-00363-01AI95-00363-01} If a discriminated full type has
+ a partial view (private type) that is constrained, we do not
+ allow 'Access on objects to create a value of an object of an
+ access-to-unconstrained type. Ada 95 allowed this attribute
+ and various access subtypes, requiring that the heap object be
+ constrained and thus making details of the implementation of
+ the private type visible to the client of the private type.
+ See *note 4.8:: for more on this topic.
+
+41.f/2
+ {AI95-00229-01AI95-00229-01} {AI95-00254-01AI95-00254-01}
+ Amendment Correction: Taking 'Access of a subprogram declared
+ in a generic unit in the body of that generic is no longer
+ allowed. Such references can easily be used to create
+ dangling pointers, as Legality Rules are not rechecked in
+ instance bodies. At the same time, the rules were loosened a
+ bit where that is harmless, and also to allow any routine to
+ be passed to an access parameter of an access-to-subprogram
+ type. The now illegal uses of 'Access can almost always be
+ moved to the private part of the generic unit, where they are
+ still legal (and rechecked upon instantiation for possibly
+ dangling pointers).
+
+ _Extensions to Ada 95_
+
+41.g/2
+ {8652/00108652/0010} {AI95-00127-01AI95-00127-01} Corrigendum:
+ Access attributes of objects of class-wide types can be used
+ as the controlling parameter in a dispatching calls (see *note
+ 3.9.2::). This was an oversight in Ada 95.
+
+41.h/2
+ {AI95-00235-01AI95-00235-01} Amendment Correction: The type of
+ the prefix can now be used in resolving Access attributes.
+ This allows more uses of the Access attribute to resolve. For
+ example:
+
+41.i/2
+ type Int_Ptr is access all Integer;
+ type Float_Ptr is access all Float;
+
+41.j/2
+ function Zap (Val : Int_Ptr) return Float;
+ function Zap (Val : Float_Ptr) return Float;
+
+41.k/2
+ Value : aliased Integer := 10;
+
+41.l/2
+ Result1 : Float := Zap (Value'access); -- Ambiguous in Ada 95; resolves in Ada 2005.
+ Result2 : Float := Zap (Int_Ptr'(Value'access)); -- Resolves in Ada 95 and Ada 2005.
+
+41.m/2
+ This change is upward compatible; any expression that does not
+ resolve by the new rules would have failed a Legality Rule.
+
+ _Wording Changes from Ada 95_
+
+41.n/2
+ {AI95-00162-01AI95-00162-01} Adjusted the wording to reflect
+ the fact that expressions and function calls are masters.
+
+41.o/2
+ {AI95-00230-01AI95-00230-01} {AI95-00254-01AI95-00254-01}
+ {AI95-00318-02AI95-00318-02} {AI95-00385-01AI95-00385-01}
+ {AI95-00416-01AI95-00416-01} Defined the accessibility of the
+ various new kinds and uses of anonymous access types.
+
+ _Incompatibilities With Ada 2005_
+
+41.p/3
+ {AI05-0008-1AI05-0008-1} Correction: Simplified the
+ description of when a discriminant-dependent component is
+ allowed as the prefix of 'Access to when the object is known
+ to be constrained. This fixes a confusion as to whether a
+ subcomponent of an object that is not certain to be
+ constrained can be used as a prefix of 'Access. The fix
+ introduces an incompatibility, as the rule did not apply in
+ Ada 95 if the prefix was a constant; but it now applies no
+ matter what kind of object is involved. The incompatibility
+ is not too bad, since most kinds of constants are known to be
+ constrained.
+
+41.q/3
+ {AI05-0041-1AI05-0041-1} Correction: Corrected the checks for
+ the constrainedness of the prefix of the Access attribute so
+ that assume-the-worst is used in generic bodies. This may
+ make some programs illegal, but those programs were at risk
+ having objects disappear while valid access values still
+ pointed at them.
+
+ _Extensions to Ada 2005_
+
+41.r/3
+ {AI05-0082-1AI05-0082-1} Correction: Eliminated the static
+ accessibility definition for generic formal types, as the
+ actual can be more or less nested than the generic itself.
+ This allows programs that were illegal for Ada 95 and for Ada
+ 2005.
+
+41.s/3
+ {AI05-0148-1AI05-0148-1} {AI05-0253-1AI05-0253-1} Eliminate
+ the static accessibility definition for stand-alone objects of
+ anonymous access-to-object types. This allows such objects to
+ be used as temporaries without causing accessibility problems.
+
+ _Wording Changes from Ada 2005_
+
+41.t/3
+ {AI05-0014-1AI05-0014-1} Correction: Corrected the rules so
+ that the accessibility of the object designated by an access
+ object is that of the access type, even when no dereference is
+ given. The accessibility was not specified in the past. This
+ correction applies to both Ada 95 and Ada 2005.
+
+41.u/3
+ {AI05-0024-1AI05-0024-1} Correction: Corrected accessibility
+ rules for access discriminants so that no cases are omitted.
+
+41.v/3
+ {AI05-0051-1AI05-0051-1} {AI05-0234-1AI05-0234-1}
+ {AI05-0235-1AI05-0235-1} {AI05-0284-1AI05-0284-1} Correction:
+ Corrected accessibility rules for anonymous access return
+ types and access discriminants in return statements.
+
+41.w/3
+ {AI05-0066-1AI05-0066-1} Correction: Changed coextension rules
+ so that coextensions that belong to an anonymous object are
+ transfered to the ultimate object.
+
+41.x/3
+ {AI05-0142-4AI05-0142-4} {AI05-0188-1AI05-0188-1}
+ {AI05-0235-1AI05-0235-1} Defined the accessibility of
+ explicitly aliased parameters (see *note 6.1::) and
+ conditional_expressions (see *note 4.5.7::).
+
+41.y/3
+ {AI05-0234-1AI05-0234-1} Correction: Defined the term "master
+ of the call" to simplify other wording, especially that for
+ the accessibility checks associated with return statements and
+ explicitly aliased parameters.
+
+41.z/3
+ {AI05-0270-1AI05-0270-1} Correction: Defined the (omitted)
+ accessibility level of null values when those are passed as
+ the actual of an access-to-object parameter.
+
+\1f
+File: aarm2012.info, Node: 3.11, Prev: 3.10, Up: 3
+
+3.11 Declarative Parts
+======================
+
+1
+[A declarative_part contains declarative_items (possibly none).]
+
+ _Syntax_
+
+2
+ declarative_part ::= {declarative_item}
+
+3
+ declarative_item ::=
+ basic_declarative_item | body
+
+4/1
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+ basic_declarative_item ::=
+ basic_declaration | aspect_clause | use_clause
+
+5
+ body ::= proper_body | body_stub
+
+6
+ proper_body ::=
+ subprogram_body | package_body | task_body | protected_body
+
+ _Static Semantics_
+
+6.1/2
+{AI95-00420-01AI95-00420-01} The list of declarative_items of a
+declarative_part is called the declaration list of the declarative_part.
+
+ _Dynamic Semantics_
+
+7
+The elaboration of a declarative_part consists of the elaboration of the
+declarative_items, if any, in the order in which they are given in the
+declarative_part.
+
+8
+An elaborable construct is in the elaborated state after the normal
+completion of its elaboration. Prior to that, it is not yet elaborated.
+
+8.a
+ Ramification: The elaborated state is only important for
+ bodies; certain uses of a body raise an exception if the body
+ is not yet elaborated.
+
+8.b
+ Note that "prior" implies before the start of elaboration, as
+ well as during elaboration.
+
+8.c
+ The use of the term "normal completion" implies that if the
+ elaboration propagates an exception or is aborted, the
+ declaration is not elaborated. RM83 missed the aborted case.
+
+9
+For a construct that attempts to use a body, a check (Elaboration_Check)
+is performed, as follows:
+
+10/1
+ * {8652/00148652/0014} {AI95-00064-01AI95-00064-01} For a call to a
+ (non-protected) subprogram that has an explicit body, a check is
+ made that the body is already elaborated. This check and the
+ evaluations of any actual parameters of the call are done in an
+ arbitrary order.
+
+10.a
+ Discussion: AI83-00180 specifies that there is no elaboration
+ check for a subprogram defined by a pragma Interface (or
+ equivalently, pragma Import). AI83-00430 specifies that there
+ is no elaboration check for an enumeration literal.
+ AI83-00406 specifies that the evaluation of parameters and the
+ elaboration check occur in an arbitrary order. AI83-00406
+ applies to generic instantiation as well (see below).
+
+10.a.1/3
+ {8652/00148652/0014} {AI95-00064-01AI95-00064-01}
+ {AI05-0177-1AI05-0177-1} A subprogram can be completed by a
+ renaming-as-body, a null_procedure_declaration, or an
+ expression_function_declaration, and we need to make an
+ elaboration check on such a body, so we use "body" rather than
+ subprogram_body above.
+
+11/3
+ * {AI05-0229-1AI05-0229-1} For a call to a protected operation of a
+ protected type (that has a body -- no check is performed if the
+ protected type is imported -- see *note B.1::), a check is made
+ that the protected_body is already elaborated. This check and the
+ evaluations of any actual parameters of the call are done in an
+ arbitrary order.
+
+11.a
+ Discussion: A protected type has only one elaboration "bit,"
+ rather than one for each operation, because one call may
+ result in evaluating the barriers of other entries, and
+ because there are no elaborable declarations between the
+ bodies of the operations. In fact, the elaboration of a
+ protected_body does not elaborate the enclosed bodies, since
+ they are not considered independently elaborable.
+
+11.b
+ Note that there is no elaboration check when calling a task
+ entry. Task entry calls are permitted even before the
+ associated task_body has been seen. Such calls are simply
+ queued until the task is activated and reaches a corresponding
+ accept_statement. We considered a similar rule for protected
+ entries -- simply queuing all calls until the protected_body
+ was seen, but felt it was not worth the possible
+ implementation overhead, particularly given that there might
+ be multiple instances of the protected type.
+
+12
+ * For the activation of a task, a check is made by the activator that
+ the task_body is already elaborated. If two or more tasks are
+ being activated together (see *note 9.2::), as the result of the
+ elaboration of a declarative_part or the initialization for the
+ object created by an allocator, this check is done for all of them
+ before activating any of them.
+
+12.a
+ Reason: As specified by AI83-00149, the check is done by the
+ activator, rather than by the task itself. If it were done by
+ the task itself, it would be turned into a Tasking_Error in
+ the activator, and the other tasks would still be activated.
+
+13
+ * For the instantiation of a generic unit that has a body, a check is
+ made that this body is already elaborated. This check and the
+ evaluation of any explicit_generic_actual_parameters of the
+ instantiation are done in an arbitrary order.
+
+14
+The exception Program_Error is raised if any of these checks fails.
+
+ _Extensions to Ada 83_
+
+14.a/2
+ {AI95-00114-01AI95-00114-01} The syntax for declarative_part
+ is modified to remove the ordering restrictions of Ada 83;
+ that is, the distinction between basic_declarative_items and
+ later_declarative_items within declarative_parts is removed.
+ This means that things like use_clauses and
+ object_declarations can be freely intermixed with things like
+ bodies.
+
+14.b
+ The syntax rule for proper_body now allows a protected_body,
+ and the rules for elaboration checks now cover calls on
+ protected operations.
+
+ _Wording Changes from Ada 83_
+
+14.c
+ The syntax rule for later_declarative_item is removed; the
+ syntax rule for declarative_item is new.
+
+14.d
+ RM83 defines "elaborated" and "not yet elaborated" for
+ declarative_items here, and for other things in *note 3.1::,
+ "*note 3.1:: Declarations". That's no longer necessary, since
+ these terms are fully defined in *note 3.1::.
+
+14.e
+ In RM83, all uses of declarative_part are optional (except for
+ the one in block_statement with a declare) which is sort of
+ strange, since a declarative_part can be empty, according to
+ the syntax. That is, declarative_parts are sort of "doubly
+ optional". In Ada 95, these declarative_parts are always
+ required (but can still be empty). To simplify description,
+ we go further and say (see *note 5.6::, "*note 5.6:: Block
+ Statements") that a block_statement without an explicit
+ declarative_part is equivalent to one with an empty one.
+
+ _Wording Changes from Ada 95_
+
+14.f/2
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} Corrigendum:
+ Changed representation clauses to aspect clauses to reflect
+ that they are used for more than just representation.
+
+14.g/2
+ {8652/00148652/0014} {AI95-00064-01AI95-00064-01} Corrigendum:
+ Clarified that the elaboration check applies to all kinds of
+ subprogram bodies.
+
+14.h/2
+ {AI95-00420-01AI95-00420-01} Defined "declaration list" to
+ avoid confusion for various rules. Other kinds of declaration
+ list are defined elsewhere.
+
+* Menu:
+
+* 3.11.1 :: Completions of Declarations
+
+\1f
+File: aarm2012.info, Node: 3.11.1, Up: 3.11
+
+3.11.1 Completions of Declarations
+----------------------------------
+
+1/3
+{8652/00148652/0014} {AI95-00064-01AI95-00064-01}
+{AI05-0177-1AI05-0177-1} Declarations sometimes come in two parts. A
+declaration that requires a second part is said to require completion.
+The second part is called the completion of the declaration (and of the
+entity declared), and is either another declaration, a body, or a
+pragma. A body is a body, an entry_body, a null_procedure_declaration
+or an expression_function_declaration that completes another
+declaration, or a renaming-as-body (see *note 8.5.4::).
+
+1.a
+ Discussion: Throughout the RM95, there are rules about
+ completions that define the following:
+
+1.b
+ * Which declarations require a corresponding completion.
+
+1.c
+ * Which constructs can only serve as the completion of a
+ declaration.
+
+1.d
+ * Where the completion of a declaration is allowed to be.
+
+1.e
+ * What kinds of completions are allowed to correspond to
+ each kind of declaration that allows one.
+
+1.f
+ Don't confuse this compile-time concept with the run-time
+ concept of completion defined in *note 7.6.1::.
+
+1.g
+ Note that the declaration of a private type (if limited) can
+ be completed with the declaration of a task type, which is
+ then completed with a body. Thus, a declaration can actually
+ come in three parts.
+
+1.h/3
+ {AI95-00217-06AI95-00217-06} {AI05-0162-1AI05-0162-1} An
+ incomplete type (whether declared in the limited view of a
+ package or not) may be completed by a private type
+ declaration, so we can in fact have four parts.
+
+1.i/3
+ {AI05-0229-1AI05-0229-1} In Ada 2012, there are no
+ language-defined pragmas that act as completions. Pragma
+ Import (which is obsolescent) has the effect of setting aspect
+ Import to True; such an aspect makes giving a completion
+ illegal. The wording that allows pragmas as completions was
+ left as it is harmless and appears in many places in this
+ Standard.
+
+ _Name Resolution Rules_
+
+2
+A construct that can be a completion is interpreted as the completion of
+a prior declaration only if:
+
+3
+ * The declaration and the completion occur immediately within the
+ same declarative region;
+
+4
+ * The defining name or defining_program_unit_name in the completion
+ is the same as in the declaration, or in the case of a pragma, the
+ pragma applies to the declaration;
+
+5
+ * If the declaration is overloadable, then the completion either has
+ a type-conformant profile, or is a pragma.
+
+ _Legality Rules_
+
+6/3
+{AI05-0229-1AI05-0229-1} An implicit declaration shall not have a
+completion. For any explicit declaration that is specified to require
+completion, there shall be a corresponding explicit completion, unless
+the declared entity is imported (see *note B.1::).
+
+6.a.1/2
+ To be honest: {AI95-00217-06AI95-00217-06} The implicit
+ declarations occurring in a limited view do have a completion
+ (the explicit declaration occurring in the full view) but
+ that's a special case, since the implicit declarations are
+ actually built from the explicit ones. So they do not require
+ a completion, they have one by fiat.
+
+6.a/3
+ Discussion: {AI05-0299-1AI05-0299-1} The implicit declarations
+ of predefined operators are not allowed to have a completion.
+ Enumeration literals, although they are subprograms, are not
+ allowed to have a corresponding subprogram_body. That's
+ because the completion rules are described in terms of
+ constructs (subprogram_declarations) and not entities
+ (subprograms). When a completion is required, it has to be
+ explicit; the implicit null package_body that Clause *note 7::
+ talks about cannot serve as the completion of a
+ package_declaration if a completion is required.
+
+7
+At most one completion is allowed for a given declaration. Additional
+requirements on completions appear where each kind of completion is
+defined.
+
+7.a
+ Ramification: A subunit is not a completion; the stub is.
+
+7.b
+ If the completion of a declaration is also a declaration, then
+ that declaration might have a completion, too. For example, a
+ limited private type can be completed with a task type, which
+ can then be completed with a task body. This is not a
+ violation of the "at most one completion" rule.
+
+8
+A type is completely defined at a place that is after its full type
+definition (if it has one) and after all of its subcomponent types are
+completely defined. A type shall be completely defined before it is
+frozen (see *note 13.14:: and *note 7.3::).
+
+8.a
+ Reason: Index types are always completely defined -- no need
+ to mention them. There is no way for a completely defined
+ type to depend on the value of a (still) deferred constant.
+
+ NOTES
+
+9/3
+ 95 {AI05-0229-1AI05-0229-1} Completions are in principle allowed
+ for any kind of explicit declaration. However, for some kinds of
+ declaration, the only allowed completion is an
+ implementation-defined pragma, and implementations are not required
+ to have any such pragmas.
+
+9.a/3
+ This paragraph was deleted.{AI05-0229-1AI05-0229-1}
+
+10
+ 96 There are rules that prevent premature uses of declarations
+ that have a corresponding completion. The Elaboration_Checks of
+ *note 3.11:: prevent such uses at run time for subprograms,
+ protected operations, tasks, and generic units. The rules of *note
+ 13.14::, "*note 13.14:: Freezing Rules" prevent, at compile time,
+ premature uses of other entities such as private types and deferred
+ constants.
+
+ _Wording Changes from Ada 83_
+
+10.a
+ This subclause is new. It is intended to cover all kinds of
+ completions of declarations, be they a body for a spec, a full
+ type for an incomplete or private type, a full constant
+ declaration for a deferred constant declaration, or a pragma
+ Import for any kind of entity.
+
+ _Wording Changes from Ada 95_
+
+10.b/2
+ {8652/00148652/0014} {AI95-00064-01AI95-00064-01} Corrigendum:
+ Added a definition of body, which is different than body or
+ body.
+
+ _Wording Changes from Ada 2005_
+
+10.c/3
+ {AI95-0177-1AI95-0177-1} Added null procedures and expression
+ functions that are completions to the definition of body.
+
+\1f
+File: aarm2012.info, Node: 4, Next: 5, Prev: 3, Up: Top
+
+4 Names and Expressions
+***********************
+
+1/3
+{AI05-0299-1AI05-0299-1} [The rules applicable to the different forms of
+name and expression, and to their evaluation, are given in this clause.]
+
+* Menu:
+
+* 4.1 :: Names
+* 4.2 :: Literals
+* 4.3 :: Aggregates
+* 4.4 :: Expressions
+* 4.5 :: Operators and Expression Evaluation
+* 4.6 :: Type Conversions
+* 4.7 :: Qualified Expressions
+* 4.8 :: Allocators
+* 4.9 :: Static Expressions and Static Subtypes
+
+\1f
+File: aarm2012.info, Node: 4.1, Next: 4.2, Up: 4
+
+4.1 Names
+=========
+
+1
+[Names can denote declared entities, whether declared explicitly or
+implicitly (see *note 3.1::). Names can also denote objects or
+subprograms designated by access values; the results of type_conversions
+or function_calls; subcomponents and slices of objects and values;
+protected subprograms, single entries, entry families, and entries in
+families of entries. Finally, names can denote attributes of any of the
+foregoing.]
+
+ _Syntax_
+
+2/3
+ {AI05-0003-1AI05-0003-1} {AI05-0139-2AI05-0139-2} name ::=
+ direct_name | explicit_dereference
+ | indexed_component | slice
+ | selected_component | attribute_reference
+ | type_conversion | function_call
+ | character_literal | qualified_expression
+ | generalized_reference | generalized_indexing
+
+3
+ direct_name ::= identifier | operator_symbol
+
+3.a/2
+ Discussion: {AI95-00114-01AI95-00114-01} character_literal is
+ no longer a direct_name. character_literals are usable even
+ when the corresponding enumeration type declaration is not
+ visible. See *note 4.2::.
+
+4
+ prefix ::= name | implicit_dereference
+
+5
+ explicit_dereference ::= name.all
+
+6
+ implicit_dereference ::= name
+
+7/3
+{AI05-0004-1AI05-0004-1} [Certain forms of name (indexed_components,
+selected_components, slices, and attribute_references) include a prefix
+that is either itself a name that denotes some related entity, or an
+implicit_dereference of an access value that designates some related
+entity.]
+
+ _Name Resolution Rules_
+
+8
+The name in a dereference (either an implicit_dereference or an
+explicit_dereference) is expected to be of any access type.
+
+ _Static Semantics_
+
+9/3
+{AI05-0008-1AI05-0008-1} If the type of the name in a dereference is
+some access-to-object type T, then the dereference denotes a view of an
+object, the nominal subtype of the view being the designated subtype of
+T. If the designated subtype has unconstrained discriminants, the
+(actual) subtype of the view is constrained by the values of the
+discriminants of the designated object, except when there is a partial
+view of the type of the designated subtype that does not have
+discriminants, in which case the dereference is not constrained by its
+discriminant values.
+
+9.a
+ Ramification: If the value of the name is the result of an
+ access type conversion, the dereference denotes a view created
+ as part of the conversion. The nominal subtype of the view is
+ not necessarily the same as that used to create the designated
+ object. See *note 4.6::.
+
+9.b
+ To be honest: We sometimes refer to the nominal subtype of a
+ particular kind of name rather than the nominal subtype of the
+ view denoted by the name (presuming the name denotes a view of
+ an object). These two uses of nominal subtype are intended to
+ mean the same thing.
+
+9.c/3
+ Reason: {AI05-0008-1AI05-0008-1} The last sentence was not
+ present in Ada 95; it is necessary in Ada 2005 because general
+ access types can designate unconstrained objects, which was
+ not possible in Ada 95. Thus, the rules that had this effect
+ in Ada 95 (the object being constrained by its initial value)
+ don't work in Ada 2005 and we have to say this explicitly.
+
+9.d/3
+ {AI05-0008-1AI05-0008-1} The "except" part of the last
+ sentence prevents privacy "breaking", so that if a private
+ type has discriminants only in the full view, they don't
+ interfere with freely interassigning values between objects of
+ the type, even when the objects live in the heap.
+
+9.e/3
+ Implementation Note: {AI05-0008-1AI05-0008-1} Since we don't
+ depend on whether the designated object is constrained, it is
+ not necessary to include a constrained bit in every object
+ that could be designated by a general access type.
+
+10
+If the type of the name in a dereference is some access-to-subprogram
+type S, then the dereference denotes a view of a subprogram, the profile
+of the view being the designated profile of S.
+
+10.a
+ Ramification: This means that the formal parameter names and
+ default expressions to be used in a call whose name or prefix
+ is a dereference are those of the designated profile, which
+ need not be the same as those of the subprogram designated by
+ the access value, since 'Access requires only subtype
+ conformance, not full conformance.
+
+ _Dynamic Semantics_
+
+11/2
+{AI95-00415-01AI95-00415-01} The evaluation of a name determines the
+entity denoted by the name. This evaluation has no other effect for a
+name that is a direct_name or a character_literal.
+
+12
+[The evaluation of a name that has a prefix includes the evaluation of
+the prefix.] The evaluation of a prefix consists of the evaluation of
+the name or the implicit_dereference. The prefix denotes the entity
+denoted by the name or the implicit_dereference.
+
+13
+The evaluation of a dereference consists of the evaluation of the name
+and the determination of the object or subprogram that is designated by
+the value of the name. A check is made that the value of the name is
+not the null access value. Constraint_Error is raised if this check
+fails. The dereference denotes the object or subprogram designated by
+the value of the name.
+
+ _Examples_
+
+14
+Examples of direct names:
+
+15
+ Pi -- the direct name of a number (see *note 3.3.2::)
+ Limit -- the direct name of a constant (see *note 3.3.1::)
+ Count -- the direct name of a scalar variable (see *note 3.3.1::)
+ Board -- the direct name of an array variable (see *note 3.6.1::)
+ Matrix -- the direct name of a type (see *note 3.6::)
+ Random -- the direct name of a function (see *note 6.1::)
+ Error -- the direct name of an exception (see *note 11.1::)
+
+16
+Examples of dereferences:
+
+17
+ Next_Car.all -- explicit dereference denoting the object designated by
+ -- the access variable Next_Car (see *note 3.10.1::)
+ Next_Car.Owner -- selected component with implicit dereference;
+ -- same as Next_Car.all.Owner
+
+ _Extensions to Ada 83_
+
+17.a
+ Type conversions and function calls are now considered names
+ that denote the result of the operation. In the case of a
+ type conversion used as an actual parameter or that is of a
+ tagged type, the type conversion is considered a variable if
+ the operand is a variable. This simplifies the description of
+ "parameters of the form of a type conversion" as well as
+ better supporting an important OOP paradigm that requires the
+ combination of a conversion from a class-wide type to some
+ specific type followed immediately by component selection.
+ Function calls are considered names so that a type conversion
+ of a function call and the function call itself are treated
+ equivalently in the grammar. A function call is considered
+ the name of a constant, and can be used anywhere such a name
+ is permitted. See *note 6.5::.
+
+17.b/1
+ Type conversions of a tagged type are permitted anywhere their
+ operand is permitted. That is, if the operand is a variable,
+ then the type conversion can appear on the left-hand side of
+ an assignment_statement. If the operand is an object, then
+ the type conversion can appear in an object renaming or as a
+ prefix. See *note 4.6::.
+
+ _Wording Changes from Ada 83_
+
+17.c/2
+ {AI95-00114-01AI95-00114-01} Everything of the general
+ syntactic form name(...) is now syntactically a name. In any
+ realistic parser, this would be a necessity since
+ distinguishing among the various name(...) constructs
+ inevitably requires name resolution. In cases where the
+ construct yields a value rather than an object, the name
+ denotes a value rather than an object. Names already denote
+ values in Ada 83 with named numbers, components of the result
+ of a function call, etc. This is partly just a wording
+ change, and partly an extension of functionality (see
+ Extensions heading above).
+
+17.d
+ The syntax rule for direct_name is new. It is used in places
+ where direct visibility is required. It's kind of like Ada
+ 83's simple_name, but simple_name applied to both direct
+ visibility and visibility by selection, and furthermore, it
+ didn't work right for operator_symbols. The syntax rule for
+ simple_name is removed, since its use is covered by a
+ combination of direct_name and selector_name. The syntactic
+ categories direct_name and selector_name are similar; it's
+ mainly the visibility rules that distinguish the two. The
+ introduction of direct_name requires the insertion of one new
+ explicit textual rule: to forbid statement_identifiers from
+ being operator_symbols. This is the only case where the
+ explicit rule is needed, because this is the only case where
+ the declaration of the entity is implicit. For example, there
+ is no need to syntactically forbid (say) "X: "Rem";", because
+ it is impossible to declare a type whose name is an
+ operator_symbol in the first place.
+
+17.e
+ The syntax rules for explicit_dereference and
+ implicit_dereference are new; this makes other rules simpler,
+ since dereferencing an access value has substantially
+ different semantics from selected_components. We also use
+ name instead of prefix in the explicit_dereference rule since
+ that seems clearer. Note that these rules rely on the fact
+ that function calls are now names, so we don't need to use
+ prefix to allow functions calls in front of .all.
+
+17.f
+ Discussion: Actually, it would be reasonable to allow any
+ primary in front of .all, since only the value is needed, but
+ that would be a bit radical.
+
+17.g
+ We no longer use the term appropriate for a type since we now
+ describe the semantics of a prefix in terms of implicit
+ dereference.
+
+ _Extensions to Ada 2005_
+
+17.h/3
+ {AI05-0003-1AI05-0003-1} A qualified_expression is now a name
+ denoting a constant view; this allows them to be used as a
+ prefix and to be renamed as an object. They are often used to
+ remove ambiguity from function calls, and there may be no
+ other way to do that. Interestingly, a type_conversion of a
+ qualified_expression is already legal in these contexts, so
+ this change mainly reduces clutter by eliminating an otherwise
+ unneeded type_conversion from some expressions.
+
+ _Wording Changes from Ada 2005_
+
+17.i/3
+ {AI05-0008-1AI05-0008-1} Correction: Added a missing rule so
+ that most dereferences are assumed constrained (without
+ determining whether the designated object is). This is just
+ confirming the Ada 95 rules; Ada 2005 failed to ensure that
+ this property was unchanged.
+
+17.j/3
+ {AI05-0139-2AI05-0139-2} {AI05-0299-1AI05-0299-1} Added
+ generalized_reference and generalized_indexing as types of
+ name; these are documented as extensions in the appropriate
+ subclauses.
+
+* Menu:
+
+* 4.1.1 :: Indexed Components
+* 4.1.2 :: Slices
+* 4.1.3 :: Selected Components
+* 4.1.4 :: Attributes
+* 4.1.5 :: User-Defined References
+* 4.1.6 :: User-Defined Indexing
+
+\1f
+File: aarm2012.info, Node: 4.1.1, Next: 4.1.2, Up: 4.1
+
+4.1.1 Indexed Components
+------------------------
+
+1
+[An indexed_component denotes either a component of an array or an entry
+in a family of entries. ]
+
+ _Syntax_
+
+2
+ indexed_component ::= prefix(expression {, expression})
+
+ _Name Resolution Rules_
+
+3
+The prefix of an indexed_component with a given number of expressions
+shall resolve to denote an array (after any implicit dereference) with
+the corresponding number of index positions, or shall resolve to denote
+an entry family of a task or protected object (in which case there shall
+be only one expression).
+
+4
+The expected type for each expression is the corresponding index type.
+
+ _Static Semantics_
+
+5
+When the prefix denotes an array, the indexed_component denotes the
+component of the array with the specified index value(s). The nominal
+subtype of the indexed_component is the component subtype of the array
+type.
+
+6
+When the prefix denotes an entry family, the indexed_component denotes
+the individual entry of the entry family with the specified index value.
+
+ _Dynamic Semantics_
+
+7
+For the evaluation of an indexed_component, the prefix and the
+expressions are evaluated in an arbitrary order. The value of each
+expression is converted to the corresponding index type. A check is
+made that each index value belongs to the corresponding index range of
+the array or entry family denoted by the prefix. Constraint_Error is
+raised if this check fails.
+
+ _Examples_
+
+8
+Examples of indexed components:
+
+9
+ My_Schedule(Sat) -- a component of a one-dimensional array (see *note 3.6.1::)
+ Page(10) -- a component of a one-dimensional array (see *note 3.6::)
+ Board(M, J + 1) -- a component of a two-dimensional array (see *note 3.6.1::)
+ Page(10)(20) -- a component of a component (see *note 3.6::)
+ Request(Medium) -- an entry in a family of entries (see *note 9.1::)
+ Next_Frame(L)(M, N) -- a component of a function call (see *note 6.1::)
+
+ NOTES
+
+10
+ 1 Notes on the examples: Distinct notations are used for
+ components of multidimensional arrays (such as Board) and arrays of
+ arrays (such as Page). The components of an array of arrays are
+ arrays and can therefore be indexed. Thus Page(10)(20) denotes the
+ 20th component of Page(10). In the last example Next_Frame(L) is a
+ function call returning an access value that designates a
+ two-dimensional array.
+
+\1f
+File: aarm2012.info, Node: 4.1.2, Next: 4.1.3, Prev: 4.1.1, Up: 4.1
+
+4.1.2 Slices
+------------
+
+1
+[ A slice denotes a one-dimensional array formed by a sequence of
+consecutive components of a one-dimensional array. A slice of a
+variable is a variable; a slice of a constant is a constant;] a slice of
+a value is a value.
+
+ _Syntax_
+
+2
+ slice ::= prefix(discrete_range)
+
+ _Name Resolution Rules_
+
+3
+The prefix of a slice shall resolve to denote a one-dimensional array
+(after any implicit dereference).
+
+4
+The expected type for the discrete_range of a slice is the index type of
+the array type.
+
+ _Static Semantics_
+
+5
+A slice denotes a one-dimensional array formed by the sequence of
+consecutive components of the array denoted by the prefix, corresponding
+to the range of values of the index given by the discrete_range.
+
+6
+The type of the slice is that of the prefix. Its bounds are those
+defined by the discrete_range.
+
+ _Dynamic Semantics_
+
+7
+For the evaluation of a slice, the prefix and the discrete_range are
+evaluated in an arbitrary order. If the slice is not a null slice (a
+slice where the discrete_range is a null range), then a check is made
+that the bounds of the discrete_range belong to the index range of the
+array denoted by the prefix. Constraint_Error is raised if this check
+fails.
+
+ NOTES
+
+8
+ 2 A slice is not permitted as the prefix of an Access
+ attribute_reference, even if the components or the array as a whole
+ are aliased. See *note 3.10.2::.
+
+8.a
+ Proof: Slices are not aliased, by *note 3.10::, "*note 3.10::
+ Access Types".
+
+8.b
+ Reason: This is to ease implementation of
+ general-access-to-array. If slices were aliased,
+ implementations would need to store array dope with the access
+ values, which is not always desirable given
+ access-to-incomplete types completed in a package body.
+
+9
+ 3 For a one-dimensional array A, the slice A(N .. N) denotes an
+ array that has only one component; its type is the type of A. On
+ the other hand, A(N) denotes a component of the array A and has the
+ corresponding component type.
+
+ _Examples_
+
+10
+Examples of slices:
+
+11
+ Stars(1 .. 15) -- a slice of 15 characters (see *note 3.6.3::)
+ Page(10 .. 10 + Size) -- a slice of 1 + Size components (see *note 3.6::)
+ Page(L)(A .. B) -- a slice of the array Page(L) (see *note 3.6::)
+ Stars(1 .. 0) -- a null slice (see *note 3.6.3::)
+ My_Schedule(Weekday) -- bounds given by subtype (see *note 3.6.1:: and *note 3.5.1::)
+ Stars(5 .. 15)(K) -- same as Stars(K) (see *note 3.6.3::)
+ -- provided that K is in 5 .. 15
+
+\1f
+File: aarm2012.info, Node: 4.1.3, Next: 4.1.4, Prev: 4.1.2, Up: 4.1
+
+4.1.3 Selected Components
+-------------------------
+
+1
+[Selected_components are used to denote components (including
+discriminants), entries, entry families, and protected subprograms; they
+are also used as expanded names as described below. ]
+
+ _Syntax_
+
+2
+ selected_component ::= prefix . selector_name
+
+3
+ selector_name ::= identifier | character_literal | operator_symbol
+
+ _Name Resolution Rules_
+
+4
+A selected_component is called an expanded name if, according to the
+visibility rules, at least one possible interpretation of its prefix
+denotes a package or an enclosing named construct (directly, not through
+a subprogram_renaming_declaration or generic_renaming_declaration).
+
+4.a
+ Discussion: See AI83-00187.
+
+5
+A selected_component that is not an expanded name shall resolve to
+denote one of the following:
+
+5.a
+ Ramification: If the prefix of a selected_component denotes an
+ enclosing named construct, then the selected_component is
+ interpreted only as an expanded name, even if the named
+ construct is a function that could be called without
+ parameters.
+
+6
+ * A component [(including a discriminant)]:
+
+7
+ The prefix shall resolve to denote an object or value of some
+ non-array composite type (after any implicit dereference). The
+ selector_name shall resolve to denote a discriminant_specification
+ of the type, or, unless the type is a protected type, a
+ component_declaration of the type. The selected_component denotes
+ the corresponding component of the object or value.
+
+7.a/3
+ Reason: {AI05-0005-1AI05-0005-1} The components of a protected
+ object cannot be named except by an expanded name, even from
+ within the corresponding protected body. The protected body
+ cannot reference the private components of some arbitrary
+ object of the protected type; the protected body may reference
+ components of the current instance only (by an expanded name
+ or a direct_name).
+
+7.b
+ Ramification: Only the discriminants and components visible at
+ the place of the selected_component can be selected, since a
+ selector_name can only denote declarations that are visible
+ (see *note 8.3::).
+
+8
+ * A single entry, an entry family, or a protected subprogram:
+
+9
+ The prefix shall resolve to denote an object or value of some task
+ or protected type (after any implicit dereference). The
+ selector_name shall resolve to denote an entry_declaration or
+ subprogram_declaration occurring (implicitly or explicitly) within
+ the visible part of that type. The selected_component denotes the
+ corresponding entry, entry family, or protected subprogram.
+
+9.a
+ Reason: This explicitly says "visible part" because even
+ though the body has visibility on the private part, it cannot
+ call the private operations of some arbitrary object of the
+ task or protected type, only those of the current instance
+ (and expanded name notation has to be used for that).
+
+9.1/2
+ * {AI95-00252-01AI95-00252-01} {AI95-00407-01AI95-00407-01} A view of
+ a subprogram whose first formal parameter is of a tagged type or is
+ an access parameter whose designated type is tagged:
+
+9.2/3
+ {AI95-00252-01AI95-00252-01} {AI95-00407-01AI95-00407-01}
+ {AI05-0090-1AI05-0090-1} The prefix (after any implicit
+ dereference) shall resolve to denote an object or value of a
+ specific tagged type T or class-wide type T'Class. The
+ selector_name shall resolve to denote a view of a subprogram
+ declared immediately within the declarative region in which an
+ ancestor of the type T is declared. The first formal parameter of
+ the subprogram shall be of type T, or a class-wide type that covers
+ T, or an access parameter designating one of these types. The
+ designator of the subprogram shall not be the same as that of a
+ component of the tagged type visible at the point of the
+ selected_component. The subprogram shall not be an implicitly
+ declared primitive operation of type T that overrides an inherited
+ subprogram implemented by an entry or protected subprogram visible
+ at the point of the selected_component. The selected_component
+ denotes a view of this subprogram that omits the first formal
+ parameter. This view is called a prefixed view of the subprogram,
+ and the prefix of the selected_component (after any implicit
+ dereference) is called the prefix of the prefixed view.
+
+9.b/3
+ Discussion: {AI05-0090-1AI05-0090-1} The part of the rule that
+ excludes a primitive overriding subprogram as a selector
+ applies only to the wrapper subprogram that is implicitly
+ declared to override a subprogram inherited from a
+ synchronized interface that is implemented by an operation of
+ a task or protected type (see *note 9.1:: and *note 9.4::).
+ We don't want calls that use a prefixed view to be ambiguous
+ between the wrapper subprogram and the implementing entry or
+ protected operation. Note that it is illegal to declare an
+ explicit primitive that has a prefixed view that is
+ homographic with one of the type's operations, so in normal
+ cases it isn't possible to have an ambiguity in a prefix call.
+ However, a class-wide operation of an ancestor type that is
+ declared in the same declaration list with the ancestor type
+ is also considered, and that can still make a call ambiguous.
+
+10
+An expanded name shall resolve to denote a declaration that occurs
+immediately within a named declarative region, as follows:
+
+11
+ * The prefix shall resolve to denote either a package [(including the
+ current instance of a generic package, or a rename of a package)],
+ or an enclosing named construct.
+
+12
+ * The selector_name shall resolve to denote a declaration that occurs
+ immediately within the declarative region of the package or
+ enclosing construct [(the declaration shall be visible at the place
+ of the expanded name -- see *note 8.3::)]. The expanded name
+ denotes that declaration.
+
+12.a
+ Ramification: Hence, a library unit or subunit can use an
+ expanded name to refer to the declarations within the private
+ part of its parent unit, as well as to other children that
+ have been mentioned in with_clauses.
+
+13
+ * If the prefix does not denote a package, then it shall be a
+ direct_name or an expanded name, and it shall resolve to denote a
+ program unit (other than a package), the current instance of a
+ type, a block_statement, a loop_statement, or an accept_statement
+ (*note 9.5.2: S0219.) (in the case of an accept_statement (*note
+ 9.5.2: S0219.) or entry_body (*note 9.5.2: S0221.), no family index
+ is allowed); the expanded name shall occur within the declarative
+ region of this construct. Further, if this construct is a callable
+ construct and the prefix denotes more than one such enclosing
+ callable construct, then the expanded name is ambiguous,
+ independently of the selector_name.
+
+ _Legality Rules_
+
+13.1/2
+{AI95-00252-01AI95-00252-01} {AI95-00407-01AI95-00407-01} For a
+subprogram whose first parameter is an access parameter, the prefix of
+any prefixed view shall denote an aliased view of an object.
+
+13.2/2
+{AI95-00407-01AI95-00407-01} For a subprogram whose first parameter is
+of mode in out or out, or of an anonymous access-to-variable type, the
+prefix of any prefixed view shall denote a variable.
+
+13.a/2
+ Reason: We want calls through a prefixed view and through a
+ normal view to have the same legality. Thus, the implicit
+ 'Access in this new notation needs the same legality check
+ that an explicit 'Access would have. Similarly, we need to
+ prohibit the object from being constant if the first parameter
+ of the subprogram is in out, because that is (obviously)
+ prohibited for passing a normal parameter.
+
+ _Dynamic Semantics_
+
+14
+The evaluation of a selected_component includes the evaluation of the
+prefix.
+
+15
+For a selected_component that denotes a component of a variant, a check
+is made that the values of the discriminants are such that the value or
+object denoted by the prefix has this component. The exception
+Constraint_Error is raised if this check fails.
+
+ _Examples_
+
+16
+Examples of selected components:
+
+17/2
+ {AI95-00252-01AI95-00252-01} {AI95-00407-01AI95-00407-01} Tomorrow.Month -- a record component (see *note 3.8::)
+ Next_Car.Owner -- a record component (see *note 3.10.1::)
+ Next_Car.Owner.Age -- a record component (see *note 3.10.1::)
+ -- the previous two lines involve implicit dereferences
+ Writer.Unit -- a record component (a discriminant) (see *note 3.8.1::)
+ Min_Cell(H).Value -- a record component of the result (see *note 6.1::)
+ -- of the function call Min_Cell(H)
+ Cashier.Append -- a prefixed view of a procedure (see *note 3.9.4::)
+ Control.Seize -- an entry of a protected object (see *note 9.4::)
+ Pool(K).Write -- an entry of the task Pool(K) (see *note 9.4::)
+
+18
+Examples of expanded names:
+
+19
+ Key_Manager."<" -- an operator of the visible part of a package (see *note 7.3.1::)
+ Dot_Product.Sum -- a variable declared in a function body (see *note 6.1::)
+ Buffer.Pool -- a variable declared in a protected unit (see *note 9.11::)
+ Buffer.Read -- an entry of a protected unit (see *note 9.11::)
+ Swap.Temp -- a variable declared in a block statement (see *note 5.6::)
+ Standard.Boolean -- the name of a predefined type (see *note A.1::)
+
+ _Extensions to Ada 83_
+
+19.a
+ We now allow an expanded name to use a prefix that denotes a
+ rename of a package, even if the selector is for an entity
+ local to the body or private part of the package, so long as
+ the entity is visible at the place of the reference. This
+ eliminates a preexisting anomaly where references in a package
+ body may refer to declarations of its visible part but not
+ those of its private part or body when the prefix is a rename
+ of the package.
+
+ _Wording Changes from Ada 83_
+
+19.b
+ The syntax rule for selector_name is new. It is used in
+ places where visibility, but not necessarily direct
+ visibility, is required. See *note 4.1::, "*note 4.1:: Names"
+ for more information.
+
+19.c
+ The description of dereferencing an access type has been moved
+ to *note 4.1::, "*note 4.1:: Names"; name.all is no longer
+ considered a selected_component.
+
+19.d
+ The rules have been restated to be consistent with our new
+ terminology, to accommodate class-wide types, etc.
+
+ _Extensions to Ada 95_
+
+19.e/2
+ {AI95-00252-01AI95-00252-01} The prefixed view notation for
+ tagged objects is new. This provides a similar notation to
+ that used in other popular languages, and also reduces the
+ need for use_clauses. This is sometimes known as
+ "distinguished receiver notation".
+
+19.f/2
+ Given the following definitions for a tagged type T:
+
+19.g/2
+ procedure Do_Something (Obj : in out T; Count : in Natural);
+ procedure Do_Something_Else (Obj : access T; Flag : in Boolean);
+ My_Object : aliased T;
+
+19.h/2
+ the following calls are equivalent:
+
+19.i/2
+ Do_Something (My_Object, Count => 10);
+ My_Object.Do_Something (Count => 10);
+
+19.j/2
+ as are the following calls:
+
+19.k/2
+ Do_Something_Else (My_Object'Access, Flag => True);
+ My_Object.Do_Something_Else (Flag => True);
+
+ _Wording Changes from Ada 2005_
+
+19.l/3
+ {AI05-0090-1AI05-0090-1} Correction: Corrected the definition
+ of a prefixed view to ignore the implicit subprograms declared
+ for "implemented by" entries and protected subprograms.
+
+\1f
+File: aarm2012.info, Node: 4.1.4, Next: 4.1.5, Prev: 4.1.3, Up: 4.1
+
+4.1.4 Attributes
+----------------
+
+1
+[An attribute is a characteristic of an entity that can be queried via
+an attribute_reference (*note 4.1.4: S0100.) or a
+range_attribute_reference (*note 4.1.4: S0102.).]
+
+ _Syntax_
+
+2
+ attribute_reference ::= prefix'attribute_designator
+
+3/2
+ {AI05-0004-1AI05-0004-1} attribute_designator ::=
+ identifier[(static_expression)]
+ | Access | Delta | Digits | Mod
+
+4
+ range_attribute_reference ::= prefix'range_attribute_designator
+
+5
+ range_attribute_designator ::= Range[(static_expression)]
+
+ _Name Resolution Rules_
+
+6
+In an attribute_reference, if the attribute_designator is for an
+attribute defined for (at least some) objects of an access type, then
+the prefix is never interpreted as an implicit_dereference; otherwise
+(and for all range_attribute_references), if the type of the name within
+the prefix is of an access type, the prefix is interpreted as an
+implicit_dereference. Similarly, if the attribute_designator is for an
+attribute defined for (at least some) functions, then the prefix is
+never interpreted as a parameterless function_call; otherwise (and for
+all range_attribute_references), if the prefix consists of a name that
+denotes a function, it is interpreted as a parameterless function_call.
+
+6.a
+ Discussion: The first part of this rule is essentially a
+ "preference" against implicit dereference, so that it is
+ possible to ask for, say, 'Size of an access object, without
+ automatically getting the size of the object designated by the
+ access object. This rule applies to 'Access,
+ 'Unchecked_Access, 'Size, and 'Address, and any other
+ attributes that are defined for at least some access objects.
+
+6.b
+ The second part of this rule implies that, for a parameterless
+ function F, F'Address is the address of F, whereas F'Size is
+ the size of the anonymous constant returned by F.
+
+6.c/1
+ We normally talk in terms of expected type or profile for name
+ resolution rules, but we don't do this for attributes because
+ certain attributes are legal independent of the type or the
+ profile of the prefix.
+
+6.d/2
+ {AI95-00114-01AI95-00114-01} Other than the rules given above,
+ the Name Resolution Rules for the prefix of each attribute are
+ defined as Name Resolution Rules for that attribute. If no
+ such rules are defined, then no context at all should be used
+ when resolving the prefix. In particular, any knowledge about
+ the kind of entities required must not be used for resolution
+ unless that is required by Name Resolution Rules. This
+ matters in obscure cases; for instance, given the following
+ declarations:
+
+6.e/2
+ function Get_It return Integer is ... -- (1)
+ function Get_It return Some_Record_Type is ... -- (2)
+
+6.f/2
+ the following attribute_reference cannot be resolved and is
+ illegal:
+
+6.g/2
+ if Get_It'Valid then
+
+6.h/3
+ {AI05-0005-1AI05-0005-1} even though the Valid attribute is
+ only defined for objects of scalar types, and thus cannot be
+ applied to the result of function (2). That information
+ cannot be used to resolve the prefix. The same would be true
+ if (2) had been a procedure; even though the procedure does
+ not denote an object, the attribute_reference is still
+ illegal.
+
+7
+The expression, if any, in an attribute_designator or
+range_attribute_designator is expected to be of any integer type.
+
+ _Legality Rules_
+
+8
+The expression, if any, in an attribute_designator or
+range_attribute_designator shall be static.
+
+ _Static Semantics_
+
+9/3
+{AI05-0006-1AI05-0006-1} An attribute_reference denotes a value, an
+object, a subprogram, or some other kind of program entity. For an
+attribute_reference that denotes a value or an object, if its type is
+scalar, then its nominal subtype is the base subtype of the type; if its
+type is tagged, its nominal subtype is the first subtype of the type;
+otherwise, its nominal subtype is a subtype of the type without any
+constraint or null_exclusion. Similarly, unless explicitly specified
+otherwise, for an attribute_reference that denotes a function, when its
+result type is scalar, its result subtype is the base subtype of the
+type, when its result type is tagged, the result subtype is the first
+subtype of the type, and when the result type is some other type, the
+result subtype is a subtype of the type without any constraint or
+null_exclusion.
+
+9.a
+ Ramification: The attributes defined by the language are
+ summarized in *note K.2::. Implementations can define
+ additional attributes.
+
+9.b/3
+ Discussion: {AI05-0006-1AI05-0006-1} The nominal subtype is
+ primarily a concern when an attribute_reference, or a call on
+ an attribute_reference, is used as the expression of a case
+ statement, due to the full coverage requirement based on the
+ nominal subtype. For nondiscrete cases, we define the nominal
+ subtype mainly for completeness. Implementations may specify
+ otherwise for implementation-defined attribute functions.
+
+9.c/3
+ The rule is written to match the meaning of the italicized T
+ in the definition of attributes such as Input; see *note
+ 4.5.1::.
+
+9.d/3
+ To be honest: {AI05-0006-1AI05-0006-1} We don't worry about
+ the fact that "base subtype" is not explicitly defined for the
+ universal types. Since it is not possible to constrain a
+ universal numeric type, all subtypes are unconstrained, and
+ hence can be considered base subtypes. The wording above
+ could be altered to bypass this issue, but it doesn't seem
+ necessary, since universal integer is handled specially in the
+ rules for case expression full coverage, and we don't allow
+ user-defined functions for attribute functions whose result
+ type is universal.
+
+10
+[A range_attribute_reference X'Range(N) is equivalent to the range
+X'First(N) .. X'Last(N), except that the prefix is only evaluated once.
+Similarly, X'Range is equivalent to X'First .. X'Last, except that the
+prefix is only evaluated once.]
+
+ _Dynamic Semantics_
+
+11
+The evaluation of an attribute_reference (or range_attribute_reference)
+consists of the evaluation of the prefix.
+
+ _Implementation Permissions_
+
+12/1
+{8652/00158652/0015} {AI95-00093-01AI95-00093-01} An implementation may
+provide implementation-defined attributes; the identifier for an
+implementation-defined attribute shall differ from those of the
+language-defined attributes unless supplied for compatibility with a
+previous edition of this International Standard.
+
+12.a
+ Implementation defined: Implementation-defined attributes.
+
+12.b
+ Ramification: They cannot be reserved words because reserved
+ words are not legal identifiers.
+
+12.c
+ The semantics of implementation-defined attributes, and any
+ associated rules, are, of course, implementation defined. For
+ example, the implementation defines whether a given
+ implementation-defined attribute can be used in a static
+ expression.
+
+12.c.1/1
+ {8652/00158652/0015} {AI95-00093-01AI95-00093-01}
+ Implementations are allowed to support the Small attribute for
+ floating types, as this was defined in Ada 83, even though the
+ name would conflict with a language-defined attribute.
+
+ NOTES
+
+13
+ 4 Attributes are defined throughout this International Standard,
+ and are summarized in *note K.2::.
+
+14/2
+ 5 {AI95-00235AI95-00235} In general, the name in a prefix of an
+ attribute_reference (or a range_attribute_reference) has to be
+ resolved without using any context. However, in the case of the
+ Access attribute, the expected type for the attribute_reference has
+ to be a single access type, and the resolution of the name can use
+ the fact that the type of the object or the profile of the callable
+ entity denoted by the prefix has to match the designated type or be
+ type conformant with the designated profile of the access type.
+
+14.a/2
+ Proof: {AI95-00235AI95-00235} In the general case, there is no
+ "expected type" for the prefix of an attribute_reference. In
+ the special case of 'Access, there is an "expected type" or
+ "expected profile" for the prefix.
+
+14.b
+ Reason: 'Access is a special case, because without it, it
+ would be very difficult to take 'Access of an overloaded
+ subprogram.
+
+ _Examples_
+
+15
+Examples of attributes:
+
+16
+ Color'First -- minimum value of the enumeration type Color (see *note 3.5.1::)
+ Rainbow'Base'First -- same as Color'First (see *note 3.5.1::)
+ Real'Digits -- precision of the type Real (see *note 3.5.7::)
+ Board'Last(2) -- upper bound of the second dimension of Board (see *note 3.6.1::)
+ Board'Range(1) -- index range of the first dimension of Board (see *note 3.6.1::)
+ Pool(K)'Terminated -- True if task Pool(K) is terminated (see *note 9.1::)
+ Date'Size -- number of bits for records of type Date (see *note 3.8::)
+ Message'Address -- address of the record variable Message (see *note 3.7.1::)
+
+ _Extensions to Ada 83_
+
+16.a
+ We now uniformly treat X'Range as X'First..X'Last, allowing
+ its use with scalar subtypes.
+
+16.b
+ We allow any integer type in the static_expression of an
+ attribute designator, not just a value of universal_integer.
+ The preference rules ensure upward compatibility.
+
+ _Wording Changes from Ada 83_
+
+16.c
+ We use the syntactic category attribute_reference rather than
+ simply "attribute" to avoid confusing the name of something
+ with the thing itself.
+
+16.d
+ The syntax rule for attribute_reference now uses identifier
+ instead of simple_name, because attribute identifiers are not
+ required to follow the normal visibility rules.
+
+16.e
+ We now separate attribute_reference from
+ range_attribute_reference, and enumerate the reserved words
+ that are legal attribute or range attribute designators. We
+ do this because identifier no longer includes reserved words.
+
+16.f
+ The Ada 95 name resolution rules are a bit more explicit than
+ in Ada 83. The Ada 83 rule said that the "meaning of the
+ prefix of an attribute must be determinable independently of
+ the attribute designator and independently of the fact that it
+ is the prefix of an attribute." That isn't quite right since
+ the meaning even in Ada 83 embodies whether or not the prefix
+ is interpreted as a parameterless function call, and in Ada
+ 95, it also embodies whether or not the prefix is interpreted
+ as an implicit_dereference. So the attribute designator does
+ make a difference -- just not much.
+
+16.g
+ Note however that if the attribute designator is Access, it
+ makes a big difference in the interpretation of the prefix
+ (see *note 3.10.2::).
+
+ _Wording Changes from Ada 95_
+
+16.h/2
+ {8652/00158652/0015} {AI95-00093-01AI95-00093-01} Corrigendum:
+ The wording was changed to allow implementations to continue
+ to implement the Ada 83 Small attribute. This was always
+ intended to be allowed.
+
+16.i/2
+ {AI95-00235-01AI95-00235-01} The note about resolving prefixes
+ of attributes was updated to reflect that the prefix of an
+ Access attribute now has an expected type (see *note
+ 3.10.2::).
+
+ _Wording Changes from Ada 2005_
+
+16.j/3
+ {AI05-0006-1AI05-0006-1} Correction: Defined the nominal
+ subtype of an attribute_reference to close a minor language
+ hole.
+
+\1f
+File: aarm2012.info, Node: 4.1.5, Next: 4.1.6, Prev: 4.1.4, Up: 4.1
+
+4.1.5 User-Defined References
+-----------------------------
+
+ _Static Semantics_
+
+1/3
+{AI05-0139-2AI05-0139-2} Given a discriminated type T, the following
+type-related operational aspect may be specified:
+
+2/3
+Implicit_Dereference
+ This aspect is specified by a name that denotes an access
+ discriminant declared for the type T.
+
+2.a/3
+ Aspect Description for Implicit_Dereference: Mechanism for
+ user-defined implicit .all.
+
+3/3
+{AI05-0139-2AI05-0139-2} A (view of a) type with a specified
+Implicit_Dereference aspect is a reference type. A reference object is
+an object of a reference type. The discriminant named by the
+Implicit_Dereference aspect is the reference discriminant of the
+reference type or reference object. [A generalized_reference is a name
+that identifies a reference object, and denotes the object or subprogram
+designated by the reference discriminant of the reference object.]
+
+3.a.1/3
+ Glossary entry: A reference type is one that has user-defined
+ behavior for ".all", defined by the Implicit_Dereference
+ aspect.
+
+ _Syntax_
+
+4/3
+ {AI05-0139-2AI05-0139-2} generalized_reference ::=
+ reference_object_name
+
+ _Name Resolution Rules_
+
+5/3
+{AI05-0139-2AI05-0139-2} {AI05-0269-1AI05-0269-1} The expected type for
+the reference_object_name in a generalized_reference is any reference
+type.
+
+ _Static Semantics_
+
+6/3
+{AI05-0139-2AI05-0139-2} A generalized_reference denotes a view
+equivalent to that of a dereference of the reference discriminant of the
+reference object.
+
+7/3
+{AI05-0139-2AI05-0139-2} Given a reference type T, the
+Implicit_Dereference aspect is inherited by descendants of type T if not
+overridden. If a descendant type constrains the value of the reference
+discriminant of T by a new discriminant, that new discriminant is the
+reference discriminant of the descendant. [If the descendant type
+constrains the value of the reference discriminant of T by an expression
+other than the name of a new discriminant, a generalized_reference that
+identifies an object of the descendant type denotes the object or
+subprogram designated by the value of this constraining expression.]
+
+ _Dynamic Semantics_
+
+8/3
+{AI05-0139-2AI05-0139-2} The evaluation of a generalized_reference
+consists of the evaluation of the reference_object_name and a
+determination of the object or subprogram designated by the reference
+discriminant of the named reference object. A check is made that the
+value of the reference discriminant is not the null access value.
+Constraint_Error is raised if this check fails. The
+generalized_reference denotes the object or subprogram designated by the
+value of the reference discriminant of the named reference object.
+
+ _Examples_
+
+9/3
+ {AI05-0268-1AI05-0268-1} type Barrel is tagged ... -- holds objects of type Element
+
+10/3
+ {AI05-0139-2AI05-0139-2} {AI05-0299-2AI05-0299-2} type Ref_Element(Data : access Element) is limited private
+ with Implicit_Dereference => Data;
+ -- This Ref_Element type is a "reference" type.
+ -- "Data" is its reference discriminant.
+
+11/3
+ {AI05-0139-2AI05-0139-2} {AI05-0268-1AI05-0268-1} function Find (B : aliased in out Barrel; Key : String) return Ref_Element;
+ -- Return a reference to an element of a barrel.
+
+12/3
+ {AI05-0268-1AI05-0268-1} {AI05-0299-2AI05-0299-2} B: aliased Barrel;
+
+13/3
+ {AI05-0139-2AI05-0139-2} ...
+
+14/3
+ {AI05-0139-2AI05-0139-2} {AI05-0268-1AI05-0268-1} Find (B, "grape") := Element'(...); -- Assign through a reference.
+
+15/3
+ {AI05-0139-2AI05-0139-2} {AI05-0268-1AI05-0268-1} -- This is equivalent to:
+ Find (B, "grape").Data.all := Element'(...);
+
+ _Extensions to Ada 2005_
+
+15.a/3
+ {AI05-0139-2AI05-0139-2} The aspect Implicit_Dereference and
+ the generalized_reference are new.
+
+\1f
+File: aarm2012.info, Node: 4.1.6, Prev: 4.1.5, Up: 4.1
+
+4.1.6 User-Defined Indexing
+---------------------------
+
+ _Static Semantics_
+
+1/3
+{AI05-0139-2AI05-0139-2} Given a tagged type T, the following
+type-related, operational aspects may be specified:
+
+2/3
+Constant_Indexing
+ This aspect shall be specified by a name that denotes one
+ or more functions declared immediately within the same
+ declaration list in which T is declared. All such
+ functions shall have at least two parameters, the first
+ of which is of type T or T'Class, or is an
+ access-to-constant parameter with designated type T or
+ T'Class.
+
+2.a/3
+ Aspect Description for Constant_Indexing: Defines function(s)
+ to implement user-defined indexed_components.
+
+3/3
+Variable_Indexing
+ This aspect shall be specified by a name that denotes one
+ or more functions declared immediately within the same
+ declaration list in which T is declared. All such
+ functions shall have at least two parameters, the first
+ of which is of type T or T'Class, or is an access
+ parameter with designated type T or T'Class. All such
+ functions shall have a return type that is a reference
+ type (see *note 4.1.5::), whose reference discriminant is
+ of an access-to-variable type.
+
+3.a/3
+ Reason: We require these functions to return a reference type
+ so that the object returned from the function can act like a
+ variable. We need no similar rule for Constant_Indexing,
+ since all functions return constant objects.
+
+3.b/3
+ Aspect Description for Variable_Indexing: Defines function(s)
+ to implement user-defined indexed_components.
+
+4/3
+These aspects are inherited by descendants of T (including the
+class-wide type T'Class). [The aspects shall not be overridden, but the
+functions they denote may be.]
+
+4.a/3
+ Ramification: Indexing can be provided for multiple index
+ types by overloading routines with different parameter
+ profiles. For instance, the map containers provide indexing
+ on both cursors and keys by providing pairs of overloaded
+ routines to the Constant_Indexing and Variable_Indexing
+ aspects.
+
+5/3
+{AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1} An indexable container
+type is (a view of) a tagged type with at least one of the aspects
+Constant_Indexing or Variable_Indexing specified. An indexable
+container object is an object of an indexable container type. [A
+generalized_indexing is a name that denotes the result of calling a
+function named by a Constant_Indexing or Variable_Indexing aspect.]
+
+5.a.1/3
+ Glossary entry: An indexable container type is one that has
+ user-defined behavior for indexing, via the Constant_Indexing
+ or Variable_Indexing aspects.
+
+ _Legality Rules_
+
+6/3
+{AI05-0139-2AI05-0139-2} The Constant_Indexing or Variable_Indexing
+aspect shall not be specified:
+
+7/3
+ * on a derived type if the parent type has the corresponding aspect
+ specified or inherited; or
+
+8/3
+ * on a full_type_declaration if the type has a tagged partial view.
+
+9/3
+In addition to the places where Legality Rules normally apply (see *note
+12.3::), these rules apply also in the private part of an instance of a
+generic unit.
+
+9.a/3
+ Ramification: In order to enforce these rules without breaking
+ privacy, we cannot allow a tagged private type to have hidden
+ indexing aspects. There is no problem if the private type is
+ not tagged (as the indexing aspects cannot be specified on
+ descendants in that case).
+
+9.b/3
+ We don't need an assume-the-worst rule as deriving from formal
+ tagged type is not allowed in generic bodies.
+
+ _Syntax_
+
+10/3
+ {AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1}
+ generalized_indexing ::= indexable_container_object_prefix
+ actual_parameter_part
+
+ _Name Resolution Rules_
+
+11/3
+{AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1} The expected type for
+the indexable_container_object_prefix of a generalized_indexing is any
+indexable container type.
+
+12/3
+{AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1} If the
+Constant_Indexing aspect is specified for the type of the
+indexable_container_object_prefix of a generalized_indexing, then the
+generalized_indexing is interpreted as a constant indexing under the
+following circumstances:
+
+13/3
+ * when the Variable_Indexing aspect is not specified for the type of
+ the indexable_container_object_prefix;
+
+14/3
+ * when the indexable_container_object_prefix denotes a constant;
+
+15/3
+ * when the generalized_indexing is used within a primary where a name
+ denoting a constant is permitted.
+
+15.a/3
+ Ramification: This means it is not interpreted as a constant
+ indexing for the variable_name in the LHS of an assignment
+ (not inside a primary), nor for the name used for an out or in
+ out parameter (not allowed to be a constant), nor for the name
+ in an object renaming (not inside a primary), unless there is
+ no Variable_Indexing aspect defined.
+
+16/3
+Otherwise, the generalized_indexing is interpreted as a variable
+indexing.
+
+17/3
+When a generalized_indexing is interpreted as a constant (or variable)
+indexing, it is equivalent to a call on a prefixed view of one of the
+functions named by the Constant_Indexing (or Variable_Indexing) aspect
+of the type of the indexable_container_object_prefix with the given
+actual_parameter_part, and with the indexable_container_object_prefix as
+the prefix of the prefixed view.
+
+17.a/3
+ Ramification: In other words, the generalized_indexing is
+ equivalent to:
+
+17.b/3
+ indexable_container_object_prefix.Indexing actual_parameter_part
+
+17.c/3
+ where Indexing is the name specified for the Constant_Indexing
+ or Variable_Indexing aspect.
+
+ _Examples_
+
+18/3
+ {AI05-0268-1AI05-0268-1} {AI05-0292-1AI05-0292-1} type Indexed_Barrel is tagged ...
+ with Variable_Indexing => Find;
+ -- Indexed_Barrel is an indexable container type,
+ -- Find is the generalized indexing operation.
+
+19/3
+ {AI05-0268-1AI05-0268-1} function Find (B : aliased in out Indexed_Barrel; Key : String) return Ref_Element;
+ -- Return a reference to an element of a barrel (see *note 4.1.5::).
+
+20/3
+ {AI05-0268-1AI05-0268-1} IB: aliased Indexed_Barrel;
+
+21/3
+ {AI05-0268-1AI05-0268-1} -- All of the following calls are then equivalent:
+ Find (IB,"pear").Data.all := Element'(...); -- Traditional call
+ IB.Find ("pear").Data.all := Element'(...); -- Call of prefixed view
+ IB.Find ("pear") := Element'(...); -- Implicit dereference (see *note 4.1.5::)
+ IB ("pear") := Element'(...); -- Implicit indexing and dereference
+ IB ("pear").Data.all := Element'(...); -- Implicit indexing only
+
+ _Extensions to Ada 2005_
+
+21.a/3
+ {AI05-0139-2AI05-0139-2} Aspects Constant_Indexing and
+ Variable_Indexing, and the generalized_indexing syntax are
+ new.
+
+\1f
+File: aarm2012.info, Node: 4.2, Next: 4.3, Prev: 4.1, Up: 4
+
+4.2 Literals
+============
+
+1
+[ A literal represents a value literally, that is, by means of notation
+suited to its kind.] A literal is either a numeric_literal, a
+character_literal, the literal null, or a string_literal.
+
+1.a
+ Discussion: An enumeration literal that is an identifier
+ rather than a character_literal is not considered a literal in
+ the above sense, because it involves no special notation
+ "suited to its kind." It might more properly be called an
+ enumeration_identifier, except for historical reasons.
+
+ _Name Resolution Rules_
+
+2/2
+This paragraph was deleted.{AI95-00230-01AI95-00230-01}
+
+3
+For a name that consists of a character_literal, either its expected
+type shall be a single character type, in which case it is interpreted
+as a parameterless function_call that yields the corresponding value of
+the character type, or its expected profile shall correspond to a
+parameterless function with a character result type, in which case it is
+interpreted as the name of the corresponding parameterless function
+declared as part of the character type's definition (see *note 3.5.1::).
+In either case, the character_literal denotes the
+enumeration_literal_specification.
+
+3.a
+ Discussion: See *note 4.1.3:: for the resolution rules for a
+ selector_name that is a character_literal.
+
+4
+The expected type for a primary that is a string_literal shall be a
+single string type.
+
+ _Legality Rules_
+
+5
+A character_literal that is a name shall correspond to a
+defining_character_literal of the expected type, or of the result type
+of the expected profile.
+
+6
+For each character of a string_literal with a given expected string
+type, there shall be a corresponding defining_character_literal of the
+component type of the expected string type.
+
+7/2
+This paragraph was deleted.{AI95-00230-01AI95-00230-01}
+{AI95-00231-01AI95-00231-01}
+
+ _Static Semantics_
+
+8/2
+{AI95-00230-01AI95-00230-01} An integer literal is of type
+universal_integer. A real literal is of type universal_real. The
+literal null is of type universal_access.
+
+ _Dynamic Semantics_
+
+9
+The evaluation of a numeric literal, or the literal null, yields the
+represented value.
+
+10
+The evaluation of a string_literal that is a primary yields an array
+value containing the value of each character of the sequence of
+characters of the string_literal, as defined in *note 2.6::. The bounds
+of this array value are determined according to the rules for
+positional_array_aggregates (see *note 4.3.3::), except that for a null
+string literal, the upper bound is the predecessor of the lower bound.
+
+11
+For the evaluation of a string_literal of type T, a check is made that
+the value of each character of the string_literal belongs to the
+component subtype of T. For the evaluation of a null string literal, a
+check is made that its lower bound is greater than the lower bound of
+the base range of the index type. The exception Constraint_Error is
+raised if either of these checks fails.
+
+11.a
+ Ramification: The checks on the characters need not involve
+ more than two checks altogether, since one need only check the
+ characters of the string with the lowest and highest position
+ numbers against the range of the component subtype.
+
+ NOTES
+
+12
+ 6 Enumeration literals that are identifiers rather than
+ character_literals follow the normal rules for identifiers when
+ used in a name (see *note 4.1:: and *note 4.1.3::).
+ Character_literals used as selector_names follow the normal rules
+ for expanded names (see *note 4.1.3::).
+
+ _Examples_
+
+13
+Examples of literals:
+
+14
+ 3.14159_26536 -- a real literal
+ 1_345 -- an integer literal
+ 'A' -- a character literal
+ "Some Text" -- a string literal
+
+ _Incompatibilities With Ada 83_
+
+14.a
+ Because character_literals are now treated like other
+ literals, in that they are resolved using context rather than
+ depending on direct visibility, additional qualification might
+ be necessary when passing a character_literal to an overloaded
+ subprogram.
+
+ _Extensions to Ada 83_
+
+14.b
+ Character_literals are now treated analogously to null and
+ string_literals, in that they are resolved using context,
+ rather than their content; the declaration of the
+ corresponding defining_character_literal need not be directly
+ visible.
+
+ _Wording Changes from Ada 83_
+
+14.c
+ Name Resolution rules for enumeration literals that are not
+ character_literals are not included anymore, since they are
+ neither syntactically nor semantically "literals" but are
+ rather names of parameterless functions.
+
+ _Extensions to Ada 95_
+
+14.d/2
+ {AI95-00230-01AI95-00230-01} {AI95-00231-01AI95-00231-01} Null
+ now has type universal_access, which is similar to other
+ literals. Null can be used with anonymous access types.
+
+\1f
+File: aarm2012.info, Node: 4.3, Next: 4.4, Prev: 4.2, Up: 4
+
+4.3 Aggregates
+==============
+
+1
+[ An aggregate combines component values into a composite value of an
+array type, record type, or record extension.]
+
+ _Syntax_
+
+2
+ aggregate ::= record_aggregate | extension_aggregate |
+ array_aggregate
+
+ _Name Resolution Rules_
+
+3/2
+{AI95-00287-01AI95-00287-01} The expected type for an aggregate shall be
+a single array type, record type, or record extension.
+
+3.a
+ Discussion: See *note 8.6::, "*note 8.6:: The Context of
+ Overload Resolution" for the meaning of "shall be a single ...
+ type."
+
+3.b/3
+ Ramification: {AI05-0005-1AI05-0005-1} There are additional
+ rules for each kind of aggregate. These aggregate rules are
+ additive; a legal expression needs to satisfy all of the
+ applicable rules. That means the rule given here must be
+ satisfied even when it is syntactically possible to tell which
+ specific kind of aggregate is being used.
+
+ _Legality Rules_
+
+4
+An aggregate shall not be of a class-wide type.
+
+4.a
+ Ramification: When the expected type in some context is
+ class-wide, an aggregate has to be explicitly qualified by the
+ specific type of value to be created, so that the expected
+ type for the aggregate itself is specific.
+
+4.b
+ Discussion: We used to disallow aggregates of a type with
+ unknown discriminants. However, that was unnecessarily
+ restrictive in the case of an extension aggregate, and
+ irrelevant to a record aggregate (since a type that is legal
+ for a record aggregate could not possibly have unknown
+ discriminants) and to an array aggregate (the only specific
+ types that can have unknown discriminants are private types,
+ private extensions, and types derived from them).
+
+ _Dynamic Semantics_
+
+5
+For the evaluation of an aggregate, an anonymous object is created and
+values for the components or ancestor part are obtained (as described in
+the subsequent subclause for each kind of the aggregate) and assigned
+into the corresponding components or ancestor part of the anonymous
+object. Obtaining the values and the assignments occur in an arbitrary
+order. The value of the aggregate is the value of this object.
+
+5.a
+ Discussion: The ancestor part is the set of components
+ inherited from the ancestor type. The syntactic category
+ ancestor_part is the expression or subtype_mark that specifies
+ how the ancestor part of the anonymous object should be
+ initialized.
+
+5.b
+ Ramification: The assignment operations do the necessary value
+ adjustment, as described in *note 7.6::. Note that the value
+ as a whole is not adjusted -- just the subcomponents (and
+ ancestor part, if any). *note 7.6:: also describes when this
+ anonymous object is finalized.
+
+5.c
+ If the ancestor_part is a subtype_mark the Initialize
+ procedure for the ancestor type is applied to the ancestor
+ part after default-initializing it, unless the procedure is
+ abstract, as described in *note 7.6::. The Adjust procedure
+ for the ancestor type is not called in this case, since there
+ is no assignment to the ancestor part as a whole.
+
+6
+If an aggregate is of a tagged type, a check is made that its value
+belongs to the first subtype of the type. Constraint_Error is raised if
+this check fails.
+
+6.a
+ Ramification: This check ensures that no values of a tagged
+ type are ever outside the first subtype, as required for
+ inherited dispatching operations to work properly (see *note
+ 3.4::). This check will always succeed if the first subtype
+ is unconstrained. This check is not extended to untagged
+ types to preserve upward compatibility.
+
+ _Extensions to Ada 83_
+
+6.b
+ We now allow extension_aggregates.
+
+ _Wording Changes from Ada 83_
+
+6.c
+ We have adopted new wording for expressing the rule that the
+ type of an aggregate shall be determinable from the outside,
+ though using the fact that it is nonlimited record (extension)
+ or array.
+
+6.d
+ An aggregate now creates an anonymous object. This is
+ necessary so that controlled types will work (see *note
+ 7.6::).
+
+ _Incompatibilities With Ada 95_
+
+6.e/2
+ {AI95-00287-01AI95-00287-01} In Ada 95, a limited type is not
+ considered when resolving an aggregate. Since Ada 2005 now
+ allows limited aggregates, we can have incompatibilities. For
+ example:
+
+6.f/2
+ type Lim is limited
+ record
+ Comp: Integer;
+ end record;
+
+6.g/2
+ type Not_Lim is
+ record
+ Comp: Integer;
+ end record;
+
+6.h/2
+ procedure P(X: Lim);
+ procedure P(X: Not_Lim);
+
+6.i/2
+ P((Comp => 123)); -- Illegal in Ada 2005, legal in Ada 95
+
+6.j/2
+ The call to P is ambiguous in Ada 2005, while it would not be
+ ambiguous in Ada 95 as the aggregate could not have a limited
+ type. Qualifying the aggregate will eliminate any ambiguity.
+ This construction would be rather confusing to a maintenance
+ programmer, so it should be avoided, and thus we expect it to
+ be rare.
+
+ _Extensions to Ada 95_
+
+6.k/2
+ {AI95-00287-01AI95-00287-01} Aggregates can be of a limited
+ type.
+
+* Menu:
+
+* 4.3.1 :: Record Aggregates
+* 4.3.2 :: Extension Aggregates
+* 4.3.3 :: Array Aggregates
+
+\1f
+File: aarm2012.info, Node: 4.3.1, Next: 4.3.2, Up: 4.3
+
+4.3.1 Record Aggregates
+-----------------------
+
+1
+[In a record_aggregate, a value is specified for each component of the
+record or record extension value, using either a named or a positional
+association.]
+
+ _Syntax_
+
+2
+ record_aggregate ::= (record_component_association_list)
+
+3
+ record_component_association_list ::=
+ record_component_association {, record_component_association}
+ | null record
+
+4/2
+ {AI95-00287-01AI95-00287-01} record_component_association ::=
+ [component_choice_list =>] expression
+ | component_choice_list => <>
+
+5
+ component_choice_list ::=
+ component_selector_name {| component_selector_name}
+ | others
+
+6
+ A record_component_association (*note 4.3.1: S0109.) is a named
+ component association if it has a component_choice_list; otherwise,
+ it is a positional component association. Any positional component
+ associations shall precede any named component associations. If
+ there is a named association with a component_choice_list of
+ others, it shall come last.
+
+6.a
+ Discussion: These rules were implied by the BNF in an early
+ version of the RM9X, but it made the grammar harder to read,
+ and was inconsistent with how we handle discriminant
+ constraints. Note that for array aggregates we still express
+ some of the rules in the grammar, but array aggregates are
+ significantly different because an array aggregate is either
+ all positional (with a possible others at the end), or all
+ named.
+
+7
+ In the record_component_association_list (*note 4.3.1: S0108.) for
+ a record_aggregate (*note 4.3.1: S0107.), if there is only one
+ association, it shall be a named association.
+
+7.a/3
+ Reason: {AI05-0264-1AI05-0264-1} Otherwise, the construct
+ would be interpreted as a parenthesized expression. This is
+ considered a syntax rule, since it is relevant to overload
+ resolution. We choose not to express it with BNF so we can
+ share the definition of record_component_association_list in
+ both record_aggregate and extension_aggregate.
+
+7.b
+ Ramification: The record_component_association_list of an
+ extension_aggregate does not have such a restriction.
+
+ _Name Resolution Rules_
+
+8/2
+{AI95-00287-01AI95-00287-01} The expected type for a record_aggregate
+shall be a single record type or record extension.
+
+8.a
+ Ramification: This rule is used to resolve whether an
+ aggregate is an array_aggregate or a record_aggregate. The
+ presence of a with is used to resolve between a
+ record_aggregate and an extension_aggregate.
+
+9
+For the record_component_association_list (*note 4.3.1: S0108.) of a
+record_aggregate (*note 4.3.1: S0107.), all components of the composite
+value defined by the aggregate are needed[; for the association list of
+an extension_aggregate, only those components not determined by the
+ancestor expression or subtype are needed (see *note 4.3.2::).] Each
+selector_name (*note 4.1.3: S0099.) in a record_component_association
+(*note 4.3.1: S0109.) shall denote a needed component [(including
+possibly a discriminant)].
+
+9.a
+ Ramification: For the association list of a record_aggregate,
+ "needed components" includes every component of the composite
+ value, but does not include those in unchosen variants (see
+ AI83-309). If there are variants, then the value specified
+ for the discriminant that governs them determines which
+ variant is chosen, and hence which components are needed.
+
+9.b
+ If an extension defines a new known_discriminant_part, then
+ all of its discriminants are needed in the component
+ association list of an extension aggregate for that type, even
+ if the discriminants have the same names and types as
+ discriminants of the type of the ancestor expression. This is
+ necessary to ensure that the positions in the
+ record_component_association_list (*note 4.3.1: S0108.) are
+ well defined, and that discriminants that govern variant_parts
+ can be given by static expressions.
+
+10
+The expected type for the expression of a record_component_association
+(*note 4.3.1: S0109.) is the type of the associated component(s); the
+associated component(s) are as follows:
+
+11
+ * For a positional association, the component [(including possibly a
+ discriminant)] in the corresponding relative position (in the
+ declarative region of the type), counting only the needed
+ components;
+
+11.a
+ Ramification: This means that for an association list of an
+ extension_aggregate, only noninherited components are counted
+ to determine the position.
+
+11.b/3
+ {AI05-0005-1AI05-0005-1} For a derived type (including type
+ extensions), the order of declaration is defined in *note
+ 3.4::, "*note 3.4:: Derived Types and Classes". In
+ particular, all discriminants come first, regardless of
+ whether they are defined for the parent type or are newly
+ added to the derived type.
+
+12
+ * For a named association with one or more component_selector_names,
+ the named component(s);
+
+13
+ * For a named association with the reserved word others, all needed
+ components that are not associated with some previous association.
+
+ _Legality Rules_
+
+14
+If the type of a record_aggregate is a record extension, then it shall
+be a descendant of a record type, through one or more record extensions
+(and no private extensions).
+
+15/3
+{AI05-0016-1AI05-0016-1} The reserved words null record may appear only
+if there are no components needed in a given
+record_component_association_list (*note 4.3.1: S0108.).
+
+15.a
+ Ramification: For example, "(null record)" is a
+ record_aggregate for a null record type. Similarly, "(T'(A)
+ with null record)" is an extension_aggregate for a type
+ defined as a null record extension of T.
+
+15.b/3
+ {AI05-0016-1AI05-0016-1} If no components are needed and null
+ record is not used, the record_component_association (*note
+ 4.3.1: S0109.) must necessarily be others => <>, as that is
+ the only record_component_association (*note 4.3.1: S0109.)
+ that does not require an associated component.
+
+16/3
+{AI95-00287-01AI95-00287-01} {AI05-0199-1AI05-0199-1} Each
+record_component_association other than an others choice with a <> shall
+have at least one associated component, and each needed component shall
+be associated with exactly one record_component_association (*note
+4.3.1: S0109.). If a record_component_association (*note 4.3.1: S0109.)
+with an expression has two or more associated components, all of them
+shall be of the same type, or all of them shall be of anonymous access
+types whose subtypes statically match.
+
+16.a/2
+ Ramification: {AI95-00287-01AI95-00287-01} These rules apply
+ to an association with an others choice with an expression.
+ An others choice with a <> can match zero components or
+ several components with different types.
+
+16.b/2
+ Reason: {AI95-00287-01AI95-00287-01} Without these rules,
+ there would be no way to know what was the expected type for
+ the expression of the association. Note that some of the
+ rules do not apply to <> associations, as we do not need to
+ resolve anything. We allow others => <> to match no
+ components as this is similar to array aggregates. That means
+ that (others => <>) always represents a default-initialized
+ record or array value.
+
+16.c
+ Discussion: AI83-00244 also requires that the expression shall
+ be legal for each associated component. This is because even
+ though two components have the same type, they might have
+ different subtypes. Therefore, the legality of the
+ expression, particularly if it is an array aggregate, might
+ differ depending on the associated component's subtype.
+ However, we have relaxed the rules on array aggregates
+ slightly for Ada 95, so the staticness of an applicable index
+ constraint has no effect on the legality of the array
+ aggregate to which it applies. See *note 4.3.3::. This was
+ the only case (that we know of) where a subtype provided by
+ context affected the legality of an expression.
+
+16.d
+ Ramification: The rule that requires at least one associated
+ component for each record_component_association implies that
+ there can be no extra associations for components that don't
+ exist in the composite value, or that are already determined
+ by the ancestor expression or subtype of an
+ extension_aggregate.
+
+16.e
+ The second part of the first sentence ensures that no needed
+ components are left out, nor specified twice.
+
+17/3
+{AI05-0220-1AI05-0220-1} The value of a discriminant that governs a
+variant_part P shall be given by a static expression, unless P is nested
+within a variant V that is not selected by the discriminant value
+governing the variant_part enclosing V.
+
+17.a
+ Ramification: This expression might either be given within the
+ aggregate itself, or in a constraint on the parent subtype in
+ a derived_type_definition for some ancestor of the type of the
+ aggregate.
+
+17.1/2
+{AI95-00287-01AI95-00287-01} A record_component_association for a
+discriminant without a default_expression shall have an expression
+rather than <>.
+
+17.b/2
+ Reason: A discriminant must always have a defined value, but
+ <> means uninitialized for a discrete type unless the
+ component has a default value.
+
+ _Dynamic Semantics_
+
+18
+The evaluation of a record_aggregate consists of the evaluation of the
+record_component_association_list (*note 4.3.1: S0108.).
+
+19
+For the evaluation of a record_component_association_list (*note 4.3.1:
+S0108.), any per-object constraints (see *note 3.8::) for components
+specified in the association list are elaborated and any expressions are
+evaluated and converted to the subtype of the associated component. Any
+constraint elaborations and expression evaluations (and conversions)
+occur in an arbitrary order, except that the expression for a
+discriminant is evaluated (and converted) prior to the elaboration of
+any per-object constraint that depends on it, which in turn occurs prior
+to the evaluation and conversion of the expression for the component
+with the per-object constraint.
+
+19.a
+ Ramification: The conversion in the first rule might raise
+ Constraint_Error.
+
+19.b
+ Discussion: This check in the first rule presumably happened
+ as part of the dependent compatibility check in Ada 83.
+
+19.1/2
+{AI95-00287-01AI95-00287-01} For a record_component_association with an
+expression, the expression defines the value for the associated
+component(s). For a record_component_association with <>, if the
+component_declaration has a default_expression, that default_expression
+defines the value for the associated component(s); otherwise, the
+associated component(s) are initialized by default as for a stand-alone
+object of the component subtype (see *note 3.3.1::).
+
+20
+The expression of a record_component_association is evaluated (and
+converted) once for each associated component.
+
+20.a/3
+ Ramification: {AI05-0005-1AI05-0005-1} We don't need similar
+ language for <>, as we're considering the value of <> for each
+ individual component. Each component has its own default
+ expression or its own default initialization (they can be
+ different for each component; the components even could have
+ different types), and each one has to be evaluated. So there
+ is no need to repeat that.
+
+ NOTES
+
+21
+ 7 For a record_aggregate with positional associations, expressions
+ specifying discriminant values appear first since the
+ known_discriminant_part is given first in the declaration of the
+ type; they have to be in the same order as in the
+ known_discriminant_part.
+
+ _Examples_
+
+22
+Example of a record aggregate with positional associations:
+
+23
+ (4, July, 1776) -- see *note 3.8::
+
+24
+Examples of record aggregates with named associations:
+
+25
+ (Day => 4, Month => July, Year => 1776)
+ (Month => July, Day => 4, Year => 1776)
+
+26
+ (Disk, Closed, Track => 5, Cylinder => 12) -- see *note 3.8.1::
+ (Unit => Disk, Status => Closed, Cylinder => 9, Track => 1)
+
+27/2
+{AI95-00287-01AI95-00287-01} Examples of component associations with
+several choices:
+
+28
+ (Value => 0, Succ|Pred => new Cell'(0, null, null)) -- see *note 3.10.1::
+
+29
+ -- The allocator is evaluated twice: Succ and Pred designate different cells
+
+29.1/2
+ (Value => 0, Succ|Pred => <>) -- see *note 3.10.1::
+
+29.2/2
+ -- Succ and Pred will be set to null
+
+30
+Examples of record aggregates for tagged types (see *note 3.9:: and
+*note 3.9.1::):
+
+31
+ Expression'(null record)
+ Literal'(Value => 0.0)
+ Painted_Point'(0.0, Pi/2.0, Paint => Red)
+
+ _Extensions to Ada 83_
+
+31.a
+ Null record aggregates may now be specified, via "(null
+ record)". However, this syntax is more useful for null record
+ extensions in extension aggregates.
+
+ _Wording Changes from Ada 83_
+
+31.b
+ Various AIs have been incorporated (AI83-00189, AI83-00244,
+ and AI83-00309). In particular, Ada 83 did not explicitly
+ disallow extra values in a record aggregate. Now we do.
+
+ _Extensions to Ada 95_
+
+31.c/2
+ {AI95-00287-01AI95-00287-01} <> can be used in place of an
+ expression in a record_aggregate, default initializing the
+ component.
+
+ _Wording Changes from Ada 95_
+
+31.d/2
+ {AI95-00287-01AI95-00287-01} Limited record_aggregates are
+ allowed (since all kinds of aggregates can now be limited, see
+ *note 4.3::).
+
+ _Incompatibilities With Ada 2005_
+
+31.e/3
+ {AI05-0220-1AI05-0220-1} Correction: Corrected wording so that
+ the rule for discriminants governing variant_parts was not
+ effectively circular. The change makes a few aggregates where
+ a nonstatic discriminant governs an empty variant_part
+ illegal. However, most Ada implementations already enforce
+ some version of the new rule and already reject these
+ aggregates. So it is unlikely that any incompatibility will
+ be noticed in practice.
+
+ _Extensions to Ada 2005_
+
+31.f/3
+ {AI05-0016-1AI05-0016-1} Correction: Fixed the wording so that
+ others => <> can be used in place of null record. This is
+ needed to avoid a generic contract issue for generic bodies:
+ we do not want to have to assume the worst to disallow others
+ => <> if the record type might be a null record.
+
+31.g/3
+ {AI05-0199-1AI05-0199-1} Correction: We now allow multiple
+ components with anonymous access types to be specified with a
+ single component association. This is to be consistent with
+ the capabilities of a named access type.
+
+\1f
+File: aarm2012.info, Node: 4.3.2, Next: 4.3.3, Prev: 4.3.1, Up: 4.3
+
+4.3.2 Extension Aggregates
+--------------------------
+
+1
+[An extension_aggregate specifies a value for a type that is a record
+extension by specifying a value or subtype for an ancestor of the type,
+followed by associations for any components not determined by the
+ancestor_part.]
+
+ _Language Design Principles_
+
+1.a
+ The model underlying this syntax is that a record extension
+ can also be viewed as a regular record type with an ancestor
+ "prefix." The record_component_association_list (*note 4.3.1:
+ S0108.) corresponds to exactly what would be needed if there
+ were no ancestor/prefix type. The ancestor_part determines
+ the value of the ancestor/prefix.
+
+ _Syntax_
+
+2
+ extension_aggregate ::=
+ (ancestor_part with record_component_association_list)
+
+3
+ ancestor_part ::= expression | subtype_mark
+
+ _Name Resolution Rules_
+
+4/2
+{AI95-00287-01AI95-00287-01} The expected type for an
+extension_aggregate shall be a single type that is a record extension.
+If the ancestor_part is an expression, it is expected to be of any
+tagged type.
+
+4.a
+ Reason: We could have made the expected type T'Class where T
+ is the ultimate ancestor of the type of the aggregate, or we
+ could have made it even more specific than that. However, if
+ the overload resolution rules get too complicated, the
+ implementation gets more difficult and it becomes harder to
+ produce good error messages.
+
+4.b/3
+ Ramification: {AI05-0005-1AI05-0005-1} This rule is additive
+ with the rule given in *note 4.3::. That means the *note
+ 4.3:: rule must be satisfied even though it is always
+ syntactically possible to tell that something is an extension
+ aggregate rather than another kind of aggregate.
+ Specifically, that means that an extension aggregate is
+ ambiguous if the context is overloaded on array and/or
+ untagged record types, even though those are never legal
+ contexts for an extension aggregate. Thus, this rule acts
+ more like a Legality Rules than a Name Resolution Rules.
+
+ _Legality Rules_
+
+5/3
+{AI95-00306-01AI95-00306-01} {AI05-0115-1AI05-0115-1} If the
+ancestor_part is a subtype_mark, it shall denote a specific tagged
+subtype. If the ancestor_part is an expression, it shall not be
+dynamically tagged. The type of the extension_aggregate shall be a
+descendant of the type of the ancestor_part (the ancestor type), through
+one or more record extensions (and no private extensions). If the
+ancestor_part is a subtype_mark, the view of the ancestor type from
+which the type is descended (see *note 7.3.1::) shall not have unknown
+discriminants.
+
+5.a/2
+ Reason: {AI95-00306-01AI95-00306-01} The expression cannot be
+ dynamically tagged to prevent implicit "truncation" of a
+ dynamically-tagged value to the specific ancestor type. This
+ is similar to the rules in *note 3.9.2::.
+
+5.1/3
+{AI05-0067-1AI05-0067-1} {AI05-0244-1AI05-0244-1} If the type of the
+ancestor_part is limited and at least one component is needed in the
+record_component_association_list, then the ancestor_part shall not be:
+
+5.2/3
+ * a call to a function with an unconstrained result subtype; nor
+
+5.3/3
+ * a parenthesized or qualified expression whose operand would violate
+ this rule; nor
+
+5.4/3
+ * a conditional_expression having at least one dependent_expression
+ that would violate this rule.
+
+5.b/3
+ Reason: {AI05-0067-1AI05-0067-1} {AI05-0244-1AI05-0244-1} This
+ restriction simplifies implementation, because it ensures that
+ either the caller or the callee knows the size to allocate for
+ the aggregate. Without this restriction, information from
+ both caller and callee would have to be combined to determine
+ the appropriate size.
+
+5.c/3
+ {AI05-0067-1AI05-0067-1} The (F(...) with null record) case
+ is exempt from this rule, because such extension aggregates
+ are created internally for inherited functions returning
+ null-extension types -- we can't very well make those illegal.
+ Moreover, we don't need the rule for null extensions, as the
+ result can simply use the space returned by the function call.
+
+ _Static Semantics_
+
+6
+For the record_component_association_list (*note 4.3.1: S0108.) of an
+extension_aggregate (*note 4.3.2: S0111.), the only components needed
+are those of the composite value defined by the aggregate that are not
+inherited from the type of the ancestor_part (*note 4.3.2: S0112.), plus
+any inherited discriminants if the ancestor_part (*note 4.3.2: S0112.)
+is a subtype_mark (*note 3.2.2: S0028.) that denotes an unconstrained
+subtype.
+
+ _Dynamic Semantics_
+
+7
+For the evaluation of an extension_aggregate, the
+record_component_association_list (*note 4.3.1: S0108.) is evaluated.
+If the ancestor_part is an expression, it is also evaluated; if the
+ancestor_part is a subtype_mark, the components of the value of the
+aggregate not given by the record_component_association_list (*note
+4.3.1: S0108.) are initialized by default as for an object of the
+ancestor type. Any implicit initializations or evaluations are
+performed in an arbitrary order, except that the expression for a
+discriminant is evaluated prior to any other evaluation or
+initialization that depends on it.
+
+8/3
+{AI05-0282-1AI05-0282-1} If the type of the ancestor_part has
+discriminants and the ancestor_part is not a subtype_mark that denotes
+an unconstrained subtype, then a check is made that each discriminant
+determined by the ancestor_part has the value specified for a
+corresponding discriminant, if any, either in the
+record_component_association_list (*note 4.3.1: S0108.), or in the
+derived_type_definition for some ancestor of the type of the
+extension_aggregate. Constraint_Error is raised if this check fails.
+
+8.a
+ Ramification: Corresponding and specified discriminants are
+ defined in *note 3.7::. The rules requiring static
+ compatibility between new discriminants of a derived type and
+ the parent discriminant(s) they constrain ensure that at most
+ one check is required per discriminant of the ancestor
+ expression.
+
+8.b/3
+ {AI05-0282-1AI05-0282-1} The check needs to be made any time
+ that the ancestor is constrained; the source of the
+ discriminants or the constraints is irrelevant.
+
+ NOTES
+
+9
+ 8 If all components of the value of the extension_aggregate are
+ determined by the ancestor_part, then the
+ record_component_association_list (*note 4.3.1: S0108.) is required
+ to be simply null record.
+
+10
+ 9 If the ancestor_part is a subtype_mark, then its type can be
+ abstract. If its type is controlled, then as the last step of
+ evaluating the aggregate, the Initialize procedure of the ancestor
+ type is called, unless the Initialize procedure is abstract (see
+ *note 7.6::).
+
+ _Examples_
+
+11
+Examples of extension aggregates (for types defined in *note 3.9.1::):
+
+12
+ Painted_Point'(Point with Red)
+ (Point'(P) with Paint => Black)
+
+13
+ (Expression with Left => 1.2, Right => 3.4)
+ Addition'(Binop with null record)
+ -- presuming Binop is of type Binary_Operation
+
+ _Extensions to Ada 83_
+
+13.a
+ The extension aggregate syntax is new.
+
+ _Incompatibilities With Ada 95_
+
+13.b/2
+ {AI95-00306-01AI95-00306-01} Amendment Correction: Eliminated
+ implicit "truncation" of a dynamically tagged value when it is
+ used as an ancestor expression. If an aggregate includes such
+ an expression, it is illegal in Ada 2005. Such aggregates are
+ thought to be rare; the problem can be fixed with a type
+ conversion to the appropriate specific type if it occurs.
+
+ _Wording Changes from Ada 95_
+
+13.c/2
+ {AI95-00287-01AI95-00287-01} Limited extension_aggregates are
+ allowed (since all kinds of aggregates can now be limited, see
+ *note 4.3::).
+
+ _Inconsistencies With Ada 2005_
+
+13.d/3
+ {AI05-0282-1AI05-0282-1} Correction: An extension_aggregate
+ with an ancestor_part whose discriminants are constrained and
+ inherited might now raise Constraint_Error if the aggregate's
+ type is constrained, while it was OK in Ada 2005. In almost
+ all cases, this will make no difference as the constraint will
+ be checked by the immediately following use of the aggregate,
+ but it is possible to compare such an aggregate for equality;
+ in this case, no exception would be raised by Ada 2005, while
+ Ada 2012 will raise Constraint_Error. This should be very
+ rare, and having the possibility means that the representation
+ of the aggregate type has to be able to support unconstrained
+ values of the type, even if the first subtype is constrained
+ and no such objects can be created any other way.
+
+ _Incompatibilities With Ada 2005_
+
+13.e/3
+ {AI05-0067-1AI05-0067-1} Correction: A limited unconstrained
+ ancestor expression that is a function call is now illegal
+ unless the extension part is null. Such aggregates were first
+ introduced in Ada 2005 and are very complex to implement as
+ they must be built-in-place with an unknown size; as such, it
+ is unlikely that they are implemented correctly in existing
+ compilers and thus not often used in existing code.
+
+13.f/3
+ {AI05-0115-1AI05-0115-1} Correction: An ancestor_part that is
+ a subtype with unknown discriminants is now explicitly
+ illegal. Such a subtype should not be used to declare an
+ object, and the ancestor_part acts like an object. The Ada 95
+ rules did not disallow such cases, so it is possible that code
+ exists that uses such an ancestor, but this should be rare.
+
+\1f
+File: aarm2012.info, Node: 4.3.3, Prev: 4.3.2, Up: 4.3
+
+4.3.3 Array Aggregates
+----------------------
+
+1
+[In an array_aggregate, a value is specified for each component of an
+array, either positionally or by its index.] For a
+positional_array_aggregate, the components are given in increasing-index
+order, with a final others, if any, representing any remaining
+components. For a named_array_aggregate, the components are identified
+by the values covered by the discrete_choices.
+
+ _Language Design Principles_
+
+1.a/1
+ The rules in this subclause are based on terms and rules for
+ discrete_choice_lists defined in *note 3.8.1::, "*note 3.8.1::
+ Variant Parts and Discrete Choices". For example, the
+ requirements that others come last and stand alone are found
+ there.
+
+ _Syntax_
+
+2
+ array_aggregate ::=
+ positional_array_aggregate | named_array_aggregate
+
+3/2
+ {AI95-00287-01AI95-00287-01} positional_array_aggregate ::=
+ (expression, expression {, expression})
+ | (expression {, expression}, others => expression)
+ | (expression {, expression}, others => <>)
+
+4
+ named_array_aggregate ::=
+ (array_component_association {, array_component_association})
+
+5/2
+ {AI95-00287-01AI95-00287-01} array_component_association ::=
+ discrete_choice_list => expression
+ | discrete_choice_list => <>
+
+6
+An n-dimensional array_aggregate is one that is written as n levels of
+nested array_aggregates (or at the bottom level, equivalent
+string_literals). For the multidimensional case (n >= 2) the
+array_aggregates (or equivalent string_literals) at the n-1 lower levels
+are called subaggregates of the enclosing n-dimensional array_aggregate.
+The expressions of the bottom level subaggregates (or of the
+array_aggregate itself if one-dimensional) are called the array
+component expressions of the enclosing n-dimensional array_aggregate.
+
+6.a
+ Ramification: Subaggregates do not have a type. They
+ correspond to part of an array. For example, with a matrix, a
+ subaggregate would correspond to a single row of the matrix.
+ The definition of "n-dimensional" array_aggregate applies to
+ subaggregates as well as aggregates that have a type.
+
+6.b
+ To be honest: An others choice is the reserved word others as
+ it appears in a positional_array_aggregate or as the
+ discrete_choice of the discrete_choice_list in an
+ array_component_association.
+
+ _Name Resolution Rules_
+
+7/2
+{AI95-00287-01AI95-00287-01} The expected type for an array_aggregate
+(that is not a subaggregate) shall be a single array type. The
+component type of this array type is the expected type for each array
+component expression of the array_aggregate.
+
+7.a/2
+ Ramification: {AI95-00287-01AI95-00287-01} We already require
+ a single array or record type or record extension for an
+ aggregate. The above rule requiring a single array type (and
+ similar ones for record and extension aggregates) resolves
+ which kind of aggregate you have.
+
+8
+The expected type for each discrete_choice in any discrete_choice_list
+of a named_array_aggregate is the type of the corresponding index; the
+corresponding index for an array_aggregate that is not a subaggregate is
+the first index of its type; for an (n-m)-dimensional subaggregate
+within an array_aggregate of an n-dimensional type, the corresponding
+index is the index in position m+1.
+
+ _Legality Rules_
+
+9
+An array_aggregate of an n-dimensional array type shall be written as an
+n-dimensional array_aggregate.
+
+9.a
+ Ramification: In an m-dimensional array_aggregate [(including
+ a subaggregate)], where m >= 2, each of the expressions has to
+ be an (m-1)-dimensional subaggregate.
+
+10
+An others choice is allowed for an array_aggregate only if an applicable
+index constraint applies to the array_aggregate. [An applicable index
+constraint is a constraint provided by certain contexts where an
+array_aggregate is permitted that can be used to determine the bounds of
+the array value specified by the aggregate.] Each of the following
+contexts (and none other) defines an applicable index constraint:
+
+11/2
+ * {AI95-00318-02AI95-00318-02} For an explicit_actual_parameter, an
+ explicit_generic_actual_parameter, the expression of a return
+ statement, the initialization expression in an object_declaration
+ (*note 3.3.1: S0032.), or a default_expression (*note 3.7: S0063.)
+ [(for a parameter or a component)], when the nominal subtype of the
+ corresponding formal parameter, generic formal parameter, function
+ return object, object, or component is a constrained array subtype,
+ the applicable index constraint is the constraint of the subtype;
+
+12
+ * For the expression of an assignment_statement where the name
+ denotes an array variable, the applicable index constraint is the
+ constraint of the array variable;
+
+12.a
+ Reason: This case is broken out because the constraint comes
+ from the actual subtype of the variable (which is always
+ constrained) rather than its nominal subtype (which might be
+ unconstrained).
+
+13
+ * For the operand of a qualified_expression whose subtype_mark
+ denotes a constrained array subtype, the applicable index
+ constraint is the constraint of the subtype;
+
+14
+ * For a component expression in an aggregate, if the component's
+ nominal subtype is a constrained array subtype, the applicable
+ index constraint is the constraint of the subtype;
+
+14.a
+ Discussion: Here, the array_aggregate with others is being
+ used within a larger aggregate.
+
+15/3
+ * {AI05-0147-1AI05-0147-1} For a parenthesized expression, the
+ applicable index constraint is that, if any, defined for the
+ expression;
+
+15.a
+ Discussion: RM83 omitted this case, presumably as an
+ oversight. We want to minimize situations where an expression
+ becomes illegal if parenthesized.
+
+15.1/3
+ * {AI05-0147-1AI05-0147-1} For a conditional_expression, the
+ applicable index constraint for each dependent_expression is that,
+ if any, defined for the conditional_expression.
+
+16
+The applicable index constraint applies to an array_aggregate that
+appears in such a context, as well as to any subaggregates thereof. In
+the case of an explicit_actual_parameter (or default_expression) for a
+call on a generic formal subprogram, no applicable index constraint is
+defined.
+
+16.a
+ Reason: This avoids generic contract model problems, because
+ only mode conformance is required when matching actual
+ subprograms with generic formal subprograms.
+
+17/3
+{AI05-0153-3AI05-0153-3} The discrete_choice_list of an
+array_component_association is allowed to have a discrete_choice that is
+a nonstatic choice_expression or that is a subtype_indication or range
+that defines a nonstatic or null range, only if it is the single
+discrete_choice of its discrete_choice_list, and there is only one
+array_component_association in the array_aggregate.
+
+17.a
+ Discussion: We now allow a nonstatic others choice even if
+ there are other array component expressions as well.
+
+18/3
+{AI05-0262-1AI05-0262-1} In a named_array_aggregate where all
+discrete_choices are static, no two discrete_choices are allowed to
+cover the same value (see *note 3.8.1::); if there is no others choice,
+the discrete_choices taken together shall exactly cover a contiguous
+sequence of values of the corresponding index type.
+
+18.a
+ Ramification: This implies that each component must be
+ specified exactly once. See AI83-309.
+
+18.b/3
+ Reason: {AI05-0262-1AI05-0262-1} This has to apply even if
+ there is only one static discrete_choice; a single choice has
+ to represent a contiguous range (a subtype_mark with a static
+ predicate might represent a discontiguous set of values). If
+ the (single) choice is a dynamic subtype, we don't need to
+ make this check as no predicates are allowed (see *note
+ 3.2.4::) and thus the range has to be contiguous.
+
+19
+A bottom level subaggregate of a multidimensional array_aggregate of a
+given array type is allowed to be a string_literal only if the component
+type of the array type is a character type; each character of such a
+string_literal shall correspond to a defining_character_literal of the
+component type.
+
+ _Static Semantics_
+
+20
+A subaggregate that is a string_literal is equivalent to one that is a
+positional_array_aggregate of the same length, with each expression
+being the character_literal for the corresponding character of the
+string_literal.
+
+ _Dynamic Semantics_
+
+21
+The evaluation of an array_aggregate of a given array type proceeds in
+two steps:
+
+22
+ 1. Any discrete_choices of this aggregate and of its subaggregates
+ are evaluated in an arbitrary order, and converted to the
+ corresponding index type;
+
+23
+ 2. The array component expressions of the aggregate are evaluated
+ in an arbitrary order and their values are converted to the
+ component subtype of the array type; an array component expression
+ is evaluated once for each associated component.
+
+23.a
+ Ramification: Subaggregates are not separately evaluated. The
+ conversion of the value of the component expressions to the
+ component subtype might raise Constraint_Error.
+
+23.b/3
+ {AI05-0005-1AI05-0005-1} We don't need to say that <> is
+ evaluated once for each component, as <> means that each
+ component is initialized by default. That means that the
+ actions defined for default initialization are applied to each
+ component individually. Initializing one component by default
+ and copying that to the others would be an incorrect
+ implementation in general (although it might be OK if the
+ default initialization is known to be constant).
+
+23.1/2
+{AI95-00287-01AI95-00287-01} Each expression in an
+array_component_association defines the value for the associated
+component(s). For an array_component_association with <>, the
+associated component(s) are initialized by default as for a stand-alone
+object of the component subtype (see *note 3.3.1::).
+
+24
+The bounds of the index range of an array_aggregate [(including a
+subaggregate)] are determined as follows:
+
+25
+ * For an array_aggregate with an others choice, the bounds are those
+ of the corresponding index range from the applicable index
+ constraint;
+
+26
+ * For a positional_array_aggregate [(or equivalent string_literal)]
+ without an others choice, the lower bound is that of the
+ corresponding index range in the applicable index constraint, if
+ defined, or that of the corresponding index subtype, if not; in
+ either case, the upper bound is determined from the lower bound and
+ the number of expressions [(or the length of the string_literal)];
+
+27
+ * For a named_array_aggregate without an others choice, the bounds
+ are determined by the smallest and largest index values covered by
+ any discrete_choice_list.
+
+27.a
+ Reason: We don't need to say that each index value has to be
+ covered exactly once, since that is a ramification of the
+ general rule on aggregates that each component's value has to
+ be specified exactly once.
+
+28
+For an array_aggregate, a check is made that the index range defined by
+its bounds is compatible with the corresponding index subtype.
+
+28.a
+ Discussion: In RM83, this was phrased more explicitly, but
+ once we define "compatibility" between a range and a subtype,
+ it seems to make sense to take advantage of that definition.
+
+28.b
+ Ramification: The definition of compatibility handles the
+ special case of a null range, which is always compatible with
+ a subtype. See AI83-00313.
+
+29/3
+{AI05-0037-1AI05-0037-1} For an array_aggregate with an others choice, a
+check is made that no expression or <> is specified for an index value
+outside the bounds determined by the applicable index constraint.
+
+29.a
+ Discussion: RM83 omitted this case, apparently through an
+ oversight. AI83-00309 defines this as a dynamic check, even
+ though other Ada 83 rules ensured that this check could be
+ performed statically. We now allow an others choice to be
+ dynamic, even if it is not the only choice, so this check now
+ needs to be dynamic, in some cases. Also, within a generic
+ unit, this would be a nonstatic check in some cases.
+
+30
+For a multidimensional array_aggregate, a check is made that all
+subaggregates that correspond to the same index have the same bounds.
+
+30.a
+ Ramification: No array bounds "sliding" is performed on
+ subaggregates.
+
+30.b
+ Reason: If sliding were performed, it would not be obvious
+ which subaggregate would determine the bounds of the
+ corresponding index.
+
+31
+The exception Constraint_Error is raised if any of the above checks
+fail.
+
+ NOTES
+
+32/3
+ 10 {AI05-0004-1AI05-0004-1} In an array_aggregate, positional
+ notation may only be used with two or more expressions; a single
+ expression in parentheses is interpreted as a parenthesized
+ expression. A named_array_aggregate, such as (1 => X), may be used
+ to specify an array with a single component.
+
+ _Examples_
+
+33
+Examples of array aggregates with positional associations:
+
+34
+ (7, 9, 5, 1, 3, 2, 4, 8, 6, 0)
+ Table'(5, 8, 4, 1, others => 0) -- see *note 3.6::
+
+35
+Examples of array aggregates with named associations:
+
+36
+ (1 .. 5 => (1 .. 8 => 0.0)) -- two-dimensional
+ (1 .. N => new Cell) -- N new cells, in particular for N = 0
+
+37
+ Table'(2 | 4 | 10 => 1, others => 0)
+ Schedule'(Mon .. Fri => True, others => False) -- see *note 3.6::
+ Schedule'(Wed | Sun => False, others => True)
+ Vector'(1 => 2.5) -- single-component vector
+
+38
+Examples of two-dimensional array aggregates:
+
+39
+ -- Three aggregates for the same value of subtype Matrix(1..2,1..3) (see *note 3.6::):
+
+40
+ ((1.1, 1.2, 1.3), (2.1, 2.2, 2.3))
+ (1 => (1.1, 1.2, 1.3), 2 => (2.1, 2.2, 2.3))
+ (1 => (1 => 1.1, 2 => 1.2, 3 => 1.3), 2 => (1 => 2.1, 2 => 2.2, 3 => 2.3))
+
+41
+Examples of aggregates as initial values:
+
+42
+ A : Table := (7, 9, 5, 1, 3, 2, 4, 8, 6, 0); -- A(1)=7, A(10)=0
+ B : Table := (2 | 4 | 10 => 1, others => 0); -- B(1)=0, B(10)=1
+ C : constant Matrix := (1 .. 5 => (1 .. 8 => 0.0)); -- C'Last(1)=5, C'Last(2)=8
+
+43
+ D : Bit_Vector(M .. N) := (M .. N => True); -- see *note 3.6::
+ E : Bit_Vector(M .. N) := (others => True);
+ F : String(1 .. 1) := (1 => 'F'); -- a one component aggregate: same as "F"
+
+44/2
+{AI95-00433-01AI95-00433-01} Example of an array aggregate with
+defaulted others choice and with an applicable index constraint provided
+by an enclosing record aggregate:
+
+45/2
+ Buffer'(Size => 50, Pos => 1, Value => String'('x', others => <>)) -- see *note 3.7::
+
+ _Incompatibilities With Ada 83_
+
+45.a.1/1
+ In Ada 95, no applicable index constraint is defined for a
+ parameter in a call to a generic formal subprogram; thus, some
+ aggregates that are legal in Ada 83 are illegal in Ada 95.
+ For example:
+
+45.a.2/1
+ subtype S3 is String (1 .. 3);
+ ...
+ generic
+ with function F (The_S3 : in S3) return Integer;
+ package Gp is
+ I : constant Integer := F ((1 => '!', others => '?'));
+ -- The aggregate is legal in Ada 83, illegal in Ada 95.
+ end Gp;
+
+45.a.3/1
+ This change eliminates generic contract model problems.
+
+ _Extensions to Ada 83_
+
+45.a
+ We now allow "named with others" aggregates in all contexts
+ where there is an applicable index constraint, effectively
+ eliminating what was RM83-4.3.2(6). Sliding never occurs on
+ an aggregate with others, because its bounds come from the
+ applicable index constraint, and therefore already match the
+ bounds of the target.
+
+45.b
+ The legality of an others choice is no longer affected by the
+ staticness of the applicable index constraint. This
+ substantially simplifies several rules, while being slightly
+ more flexible for the user. It obviates the rulings of
+ AI83-00244 and AI83-00310, while taking advantage of the
+ dynamic nature of the "extra values" check required by
+ AI83-00309.
+
+45.c
+ Named array aggregates are permitted even if the index type is
+ descended from a formal scalar type. See *note 4.9:: and
+ AI83-00190.
+
+ _Wording Changes from Ada 83_
+
+45.d
+ We now separate named and positional array aggregate syntax,
+ since, unlike other aggregates, named and positional
+ associations cannot be mixed in array aggregates (except that
+ an others choice is allowed in a positional array aggregate).
+
+45.e
+ We have also reorganized the presentation to handle
+ multidimensional and one-dimensional aggregates more
+ uniformly, and to incorporate the rulings of AI83-00019,
+ AI83-00309, etc.
+
+ _Extensions to Ada 95_
+
+45.f/2
+ {AI95-00287-01AI95-00287-01} <> can be used in place of an
+ expression in an array_aggregate, default-initializing the
+ component.
+
+ _Wording Changes from Ada 95_
+
+45.g/2
+ {AI95-00287-01AI95-00287-01} Limited array_aggregates are
+ allowed (since all kinds of aggregates can now be limited, see
+ *note 4.3::).
+
+45.h/2
+ {AI95-00318-02AI95-00318-02} Fixed aggregates to use the
+ subtype of the return object of a function, rather than the
+ result subtype, because they can be different for an
+ extended_return_statement, and we want to use the subtype
+ that's explicitly in the code at the point of the expression.
+
+ _Inconsistencies With Ada 2005_
+
+45.i/3
+ {AI05-0037-1AI05-0037-1} Correction: Fixed so the check for
+ components outside of the array applies to both expressions
+ and <>s. As <> was a new feature in Ada 2005, there should be
+ little existing code that depends on a <> component that is
+ specified outside of the array (and that is nonsense anyway,
+ that a compiler is likely to detect even without an explicit
+ language rule disallowing it).
+
+ _Wording Changes from Ada 2005_
+
+45.j/3
+ {AI05-0147-1AI05-0147-1} Added a definition of the applicable
+ index constraint for conditional_expressions (which are new).
+
+\1f
+File: aarm2012.info, Node: 4.4, Next: 4.5, Prev: 4.3, Up: 4
+
+4.4 Expressions
+===============
+
+1/3
+{AI05-0147-1AI05-0147-1} {AI05-0158-1AI05-0158-1}
+{AI05-0176-1AI05-0176-1} An expression is a formula that defines the
+computation or retrieval of a value. In this International Standard,
+the term "expression" refers to a construct of the syntactic category
+expression or of any of the following categories: choice_expression,
+choice_relation, relation, simple_expression, term, factor, primary,
+conditional_expression, quantified_expression.
+
+ _Syntax_
+
+2
+ expression ::=
+ relation {and relation} | relation {and then relation}
+ | relation {or relation} | relation {or else relation}
+ | relation {xor relation}
+
+2.1/3
+ {AI05-0158-1AI05-0158-1} choice_expression ::=
+ choice_relation {and choice_relation}
+ | choice_relation {or choice_relation}
+ | choice_relation {xor choice_relation}
+ | choice_relation {and then choice_relation}
+ | choice_relation {or else choice_relation}
+
+2.2/3
+ {AI05-0158-1AI05-0158-1} choice_relation ::=
+ simple_expression [relational_operator simple_expression]
+
+3/3
+ {AI05-0158-1AI05-0158-1} relation ::=
+ simple_expression [relational_operator simple_expression]
+ | simple_expression [not] in membership_choice_list
+
+3.1/3
+ {AI05-0158-1AI05-0158-1} membership_choice_list ::=
+ membership_choice {| membership_choice}
+
+3.2/3
+ {AI05-0158-1AI05-0158-1} membership_choice ::= choice_expression |
+ range | subtype_mark
+
+4
+ simple_expression ::= [unary_adding_operator] term {
+ binary_adding_operator term}
+
+5
+ term ::= factor {multiplying_operator factor}
+
+6
+ factor ::= primary [** primary] | abs primary | not primary
+
+7/3
+ {AI05-0003-1AI05-0003-1} {AI05-0147-1AI05-0147-1}
+ {AI05-0176-1AI05-0176-1} primary ::=
+ numeric_literal | null | string_literal | aggregate
+ | name | allocator | (expression)
+ | (conditional_expression) | (quantified_expression)
+
+ _Name Resolution Rules_
+
+8
+A name used as a primary shall resolve to denote an object or a value.
+
+8.a
+ Discussion: This replaces RM83-4.4(3). We don't need to
+ mention named numbers explicitly, because the name of a named
+ number denotes a value. We don't need to mention attributes
+ explicitly, because attributes now denote (rather than yield)
+ values in general. Also, the new wording allows attributes
+ that denote objects, which should always have been allowed (in
+ case the implementation chose to have such a thing).
+
+8.b
+ Reason: It might seem odd that this is an overload resolution
+ rule, but it is relevant during overload resolution. For
+ example, it helps ensure that a primary that consists of only
+ the identifier of a parameterless function is interpreted as a
+ function_call rather than directly as a direct_name.
+
+ _Static Semantics_
+
+9
+Each expression has a type; it specifies the computation or retrieval of
+a value of that type.
+
+ _Dynamic Semantics_
+
+10
+The value of a primary that is a name denoting an object is the value of
+the object.
+
+ _Implementation Permissions_
+
+11
+For the evaluation of a primary that is a name denoting an object of an
+unconstrained numeric subtype, if the value of the object is outside the
+base range of its type, the implementation may either raise
+Constraint_Error or return the value of the object.
+
+11.a/3
+ Ramification: {AI05-0299-1AI05-0299-1} This means that if
+ extra-range intermediates are used to hold the value of an
+ object of an unconstrained numeric subtype, a Constraint_Error
+ can be raised on a read of the object, rather than only on an
+ assignment to it. Similarly, it means that computing the
+ value of an object of such a subtype can be deferred until the
+ first read of the object (presuming no side effects other than
+ failing an Overflow_Check are possible). This permission is
+ over and above that provided by subclause *note 11.6::, since
+ this allows the Constraint_Error to move to a different
+ handler.
+
+11.b
+ Reason: This permission is intended to allow extra-range
+ registers to be used efficiently to hold parameters and local
+ variables, even if they might need to be transferred into
+ smaller registers for performing certain predefined
+ operations.
+
+11.c
+ Discussion: There is no need to mention other kinds of
+ primarys, since any Constraint_Error to be raised can be
+ "charged" to the evaluation of the particular kind of primary.
+
+ _Examples_
+
+12
+Examples of primaries:
+
+13
+ 4.0 -- real literal
+ Pi -- named number
+ (1 .. 10 => 0) -- array aggregate
+ Sum -- variable
+ Integer'Last -- attribute
+ Sine(X) -- function call
+ Color'(Blue) -- qualified expression
+ Real(M*N) -- conversion
+ (Line_Count + 10) -- parenthesized expression
+
+14
+Examples of expressions:
+
+15/2
+ {AI95-00433-01AI95-00433-01} Volume -- primary
+ not Destroyed -- factor
+ 2*Line_Count -- term
+ -4.0 -- simple expression
+ -4.0 + A -- simple expression
+ B**2 - 4.0*A*C -- simple expression
+ R*Sin([Unicode 952])*Cos([Unicode 966]) -- simple expression
+ Password(1 .. 3) = "Bwv" -- relation
+ Count in Small_Int -- relation
+ Count not in Small_Int -- relation
+ Index = 0 or Item_Hit -- expression
+ (Cold and Sunny) or Warm -- expression (parentheses are required)
+ A**(B**C) -- expression (parentheses are required)
+
+ _Extensions to Ada 83_
+
+15.a
+ In Ada 83, out parameters and their nondiscriminant
+ subcomponents are not allowed as primaries. These
+ restrictions are eliminated in Ada 95.
+
+15.b
+ In various contexts throughout the language where Ada 83
+ syntax rules had simple_expression, the corresponding Ada 95
+ syntax rule has expression instead. This reflects the
+ inclusion of modular integer types, which makes the logical
+ operators "and", "or", and "xor" more useful in expressions of
+ an integer type. Requiring parentheses to use these operators
+ in such contexts seemed unnecessary and potentially confusing.
+ Note that the bounds of a range still have to be specified by
+ simple_expressions, since otherwise expressions involving
+ membership tests might be ambiguous. Essentially, the
+ operation ".." is of higher precedence than the logical
+ operators, and hence uses of logical operators still have to
+ be parenthesized when used in a bound of a range.
+
+ _Wording Changes from Ada 2005_
+
+15.c/3
+ {AI05-0003-1AI05-0003-1} Moved qualified_expression from
+ primary to name (see *note 4.1::). This allows the use of
+ qualified_expressions in more places.
+
+15.d/3
+ {AI05-0147-1AI05-0147-1} {AI05-0176-1AI05-0176-1} Added
+ conditional_expression and quantified_expression to primary.
+
+15.e/3
+ {AI05-0158-1AI05-0158-1} Expanded membership test syntax (see
+ *note 4.5.2::).
+
+\1f
+File: aarm2012.info, Node: 4.5, Next: 4.6, Prev: 4.4, Up: 4
+
+4.5 Operators and Expression Evaluation
+=======================================
+
+1
+[ The language defines the following six categories of operators (given
+in order of increasing precedence). The corresponding operator_symbols,
+and only those, can be used as designators in declarations of functions
+for user-defined operators. See *note 6.6::, "*note 6.6:: Overloading
+of Operators".]
+
+ _Syntax_
+
+2
+ logical_operator ::= and | or | xor
+
+3
+ relational_operator ::= = | /= | < | <= | > | >=
+
+4
+ binary_adding_operator ::= + | - | &
+
+5
+ unary_adding_operator ::= + | -
+
+6
+ multiplying_operator ::= * | / | mod | rem
+
+7
+ highest_precedence_operator ::= ** | abs | not
+
+7.a
+ Discussion: Some of the above syntactic categories are not
+ used in other syntax rules. They are just used for
+ classification. The others are used for both classification
+ and parsing.
+
+ _Static Semantics_
+
+8
+For a sequence of operators of the same precedence level, the operators
+are associated with their operands in textual order from left to right.
+Parentheses can be used to impose specific associations.
+
+8.a
+ Discussion: The left-associativity is not directly inherent in
+ the grammar of *note 4.4::, though in *note 1.1.4:: the
+ definition of the metasymbols {} implies left associativity.
+ So this could be seen as redundant, depending on how literally
+ one interprets the definition of the {} metasymbols.
+
+8.b
+ See the Implementation Permissions below regarding flexibility
+ in reassociating operators of the same precedence.
+
+9
+For each form of type definition, certain of the above operators are
+predefined; that is, they are implicitly declared immediately after the
+type definition. For each such implicit operator declaration, the
+parameters are called Left and Right for binary operators; the single
+parameter is called Right for unary operators. [An expression of the
+form X op Y, where op is a binary operator, is equivalent to a
+function_call of the form "op"(X, Y). An expression of the form op Y,
+where op is a unary operator, is equivalent to a function_call of the
+form "op"(Y). The predefined operators and their effects are described
+in subclauses *note 4.5.1:: through *note 4.5.6::.]
+
+ _Dynamic Semantics_
+
+10
+[ The predefined operations on integer types either yield the
+mathematically correct result or raise the exception Constraint_Error.
+For implementations that support the Numerics Annex, the predefined
+operations on real types yield results whose accuracy is defined in
+*note Annex G::, or raise the exception Constraint_Error. ]
+
+10.a
+ To be honest: Predefined operations on real types can
+ "silently" give wrong results when the Machine_Overflows
+ attribute is false, and the computation overflows.
+
+ _Implementation Requirements_
+
+11
+The implementation of a predefined operator that delivers a result of an
+integer or fixed point type may raise Constraint_Error only if the
+result is outside the base range of the result type.
+
+12
+The implementation of a predefined operator that delivers a result of a
+floating point type may raise Constraint_Error only if the result is
+outside the safe range of the result type.
+
+12.a
+ To be honest: An exception is made for exponentiation by a
+ negative exponent in *note 4.5.6::.
+
+ _Implementation Permissions_
+
+13
+For a sequence of predefined operators of the same precedence level (and
+in the absence of parentheses imposing a specific association), an
+implementation may impose any association of the operators with operands
+so long as the result produced is an allowed result for the
+left-to-right association, but ignoring the potential for failure of
+language-defined checks in either the left-to-right or chosen order of
+association.
+
+13.a
+ Discussion: Note that the permission to reassociate the
+ operands in any way subject to producing a result allowed for
+ the left-to-right association is not much help for most
+ floating point operators, since reassociation may introduce
+ significantly different round-off errors, delivering a result
+ that is outside the model interval for the left-to-right
+ association. Similar problems arise for division with integer
+ or fixed point operands.
+
+13.b
+ Note that this permission does not apply to user-defined
+ operators.
+
+ NOTES
+
+14
+ 11 The two operands of an expression of the form X op Y, where op
+ is a binary operator, are evaluated in an arbitrary order, as for
+ any function_call (see *note 6.4::).
+
+ _Examples_
+
+15
+Examples of precedence:
+
+16
+ not Sunny or Warm -- same as (not Sunny) or Warm
+ X > 4.0 and Y > 0.0 -- same as (X > 4.0) and (Y > 0.0)
+
+17
+ -4.0*A**2 -- same as -(4.0 * (A**2))
+ abs(1 + A) + B -- same as (abs (1 + A)) + B
+ Y**(-3) -- parentheses are necessary
+ A / B * C -- same as (A/B)*C
+ A + (B + C) -- evaluate B + C before adding it to A
+
+ _Wording Changes from Ada 83_
+
+17.a
+ We don't give a detailed definition of precedence, since it is
+ all implicit in the syntax rules anyway.
+
+17.b
+ The permission to reassociate is moved here from RM83-11.6(5),
+ so it is closer to the rules defining operator association.
+
+* Menu:
+
+* 4.5.1 :: Logical Operators and Short-circuit Control Forms
+* 4.5.2 :: Relational Operators and Membership Tests
+* 4.5.3 :: Binary Adding Operators
+* 4.5.4 :: Unary Adding Operators
+* 4.5.5 :: Multiplying Operators
+* 4.5.6 :: Highest Precedence Operators
+* 4.5.7 :: Conditional Expressions
+* 4.5.8 :: Quantified Expressions
+
+\1f
+File: aarm2012.info, Node: 4.5.1, Next: 4.5.2, Up: 4.5
+
+4.5.1 Logical Operators and Short-circuit Control Forms
+-------------------------------------------------------
+
+ _Name Resolution Rules_
+
+1
+An expression consisting of two relations connected by and then or or
+else (a short-circuit control form) shall resolve to be of some boolean
+type; the expected type for both relations is that same boolean type.
+
+1.a
+ Reason: This rule is written this way so that overload
+ resolution treats the two operands symmetrically; the
+ resolution of overloading present in either one can benefit
+ from the resolution of the other. Furthermore, the type
+ expected by context can help.
+
+ _Static Semantics_
+
+2
+The following logical operators are predefined for every boolean type T,
+for every modular type T, and for every one-dimensional array type T
+whose component type is a boolean type:
+
+3
+ function "and"(Left, Right : T) return T
+ function "or" (Left, Right : T) return T
+ function "xor"(Left, Right : T) return T
+
+3.a/2
+ This paragraph was deleted.{AI95-00145-01AI95-00145-01}
+
+3.b/2
+ Ramification: {AI95-00145-01AI95-00145-01} For these
+ operators, we are talking about the type without any
+ (interesting) subtype, and not some subtype with a constraint
+ or exclusion. Since it's possible that there is no name for
+ the "uninteresting" subtype, we denote the type with an
+ italicized T. This applies to the italicized T in many other
+ predefined operators and attributes as well.
+
+3.c/2
+ {AI95-00145-01AI95-00145-01} In many cases, there is a subtype
+ with the correct properties available. The italicized T
+ means:
+
+3.d/2
+ * T'Base, for scalars;
+
+3.e/2
+ * the first subtype of T, for tagged types;
+
+3.f/2
+ * a subtype of the type T without any constraint or null
+ exclusion, in other cases.
+
+3.g/2
+ Note that "without a constraint" is not the same as
+ unconstrained. For instance, a record type with no
+ discriminant part is considered constrained; no subtype of it
+ has a constraint, but the subtype is still constrained.
+
+3.h/2
+ Thus, the last case often is the same as the first subtype of
+ T, but that isn't the case for constrained array types (where
+ the correct subtype is unconstrained) and for access types
+ with a null_exclusion (where the correct subtype does not
+ exclude null).
+
+3.i/2
+ This italicized T is used for defining operators and
+ attributes of the language. The meaning is intended to be as
+ described here.
+
+4
+For boolean types, the predefined logical operators and, or, and xor
+perform the conventional operations of conjunction, inclusive
+disjunction, and exclusive disjunction, respectively.
+
+5
+For modular types, the predefined logical operators are defined on a
+bit-by-bit basis, using the binary representation of the value of the
+operands to yield a binary representation for the result, where zero
+represents False and one represents True. If this result is outside the
+base range of the type, a final subtraction by the modulus is performed
+to bring the result into the base range of the type.
+
+6
+The logical operators on arrays are performed on a
+component-by-component basis on matching components (as for equality --
+see *note 4.5.2::), using the predefined logical operator for the
+component type. The bounds of the resulting array are those of the left
+operand.
+
+ _Dynamic Semantics_
+
+7
+The short-circuit control forms and then and or else deliver the same
+result as the corresponding predefined and and or operators for boolean
+types, except that the left operand is always evaluated first, and the
+right operand is not evaluated if the value of the left operand
+determines the result.
+
+8
+For the logical operators on arrays, a check is made that for each
+component of the left operand there is a matching component of the right
+operand, and vice versa. Also, a check is made that each component of
+the result belongs to the component subtype. The exception
+Constraint_Error is raised if either of the above checks fails.
+
+8.a
+ Discussion: The check against the component subtype is per
+ AI83-00535.
+
+ NOTES
+
+9
+ 12 The conventional meaning of the logical operators is given by
+ the following truth table:
+
+10
+ A B (A and B) (A or B) (A xor B)
+
+ True True True True False
+ True False False True True
+ False True False True True
+ False False False False False
+
+ _Examples_
+
+11
+Examples of logical operators:
+
+12
+ Sunny or Warm
+ Filter(1 .. 10) and Filter(15 .. 24) -- see *note 3.6.1::
+
+13
+Examples of short-circuit control forms:
+
+14
+ Next_Car.Owner /= null and then Next_Car.Owner.Age > 25 -- see *note 3.10.1::
+ N = 0 or else A(N) = Hit_Value
+
+\1f
+File: aarm2012.info, Node: 4.5.2, Next: 4.5.3, Prev: 4.5.1, Up: 4.5
+
+4.5.2 Relational Operators and Membership Tests
+-----------------------------------------------
+
+1
+[ The equality operators = (equals) and /= (not equals) are predefined
+for nonlimited types. The other relational_operators are the ordering
+operators < (less than), <= (less than or equal), > (greater than), and
+>= (greater than or equal). The ordering operators are predefined for
+scalar types, and for discrete array types, that is, one-dimensional
+array types whose components are of a discrete type.
+
+1.a
+ Ramification: The equality operators are not defined for every
+ nonlimited type -- see below for the exact rule.
+
+2/3
+{AI05-0262-1AI05-0262-1} {AI05-0269-1AI05-0269-1} A membership test,
+using in or not in, determines whether or not a value belongs to any
+given subtype or range, is equal to any given value, has a tag that
+identifies a type that is covered by a given type, or is convertible to
+and has an accessibility level appropriate for a given access type.
+Membership tests are allowed for all types.]
+
+ _Name Resolution Rules_
+
+3/3
+{AI95-00251-01AI95-00251-01} {AI05-0158-1AI05-0158-1} The tested type of
+a membership test is determined by the membership_choices of the
+membership_choice_list. Either all membership_choices of the
+membership_choice_list shall resolve to the same type, which is the
+tested type; or each membership_choice shall be of an elementary type,
+and the tested type shall be covered by each of these elementary types.
+
+3.1/3
+{AI05-0158-1AI05-0158-1} If the tested type is tagged, then the
+simple_expression shall resolve to be of a type that is convertible (see
+*note 4.6::) to the tested type; if untagged, the expected type for the
+simple_expression is the tested type. The expected type of a
+choice_expression in a membership_choice, and of a simple_expression of
+a range in a membership_choice, is the tested type of the membership
+operation.
+
+3.a/2
+ Reason: {AI95-00230-01AI95-00230-01} The part of the rule for
+ untagged types is stated in a way that ensures that operands
+ like a string literal are still legal as operands of a
+ membership test.
+
+3.b/2
+ {AI95-00251-01AI95-00251-01} The significance of "is
+ convertible to" is that we allow the simple_expression to be
+ of any class-wide type that could be converted to the tested
+ type, not just the one rooted at the tested type. This
+ includes any class-wide type that covers the tested type,
+ along with class-wide interfaces in some cases.
+
+3.c/3
+ {AI05-0158-1AI05-0158-1} The special rule for determining the
+ tested type for elementary types is to allow numeric literals
+ in membership_choice_lists. Without the rule, A in B | 1
+ would be illegal as B and 1 would have different types (the
+ literal having type universal integer).
+
+ _Legality Rules_
+
+4
+For a membership test, if the simple_expression is of a tagged
+class-wide type, then the tested type shall be (visibly) tagged.
+
+4.a
+ Ramification: Untagged types covered by the tagged class-wide
+ type are not permitted. Such types can exist if they are
+ descendants of a private type whose full type is tagged. This
+ rule is intended to avoid confusion since such derivatives
+ don't have their "own" tag, and hence are indistinguishable
+ from one another at run time once converted to a covering
+ class-wide type.
+
+4.1/3
+{AI05-0158-1AI05-0158-1} If a membership test includes one or more
+choice_expressions and the tested type of the membership test is
+limited, then the tested type of the membership test shall have a
+visible primitive equality operator.
+
+4.b/3
+ Reason: {AI05-0158-1AI05-0158-1} A visible equality operator
+ is required in order to avoid breaking privacy; that is, we
+ don't want to depend on a hidden equality operator.
+
+ _Static Semantics_
+
+5
+The result type of a membership test is the predefined type Boolean.
+
+6
+The equality operators are predefined for every specific type T that is
+not limited, and not an anonymous access type, with the following
+specifications:
+
+7
+ function "=" (Left, Right : T) return Boolean
+ function "/="(Left, Right : T) return Boolean
+
+7.1/2
+{AI95-00230-01AI95-00230-01} The following additional equality operators
+for the universal_access type are declared in package Standard for use
+with anonymous access types:
+
+7.2/2
+ function "=" (Left, Right : universal_access) return Boolean
+ function "/="(Left, Right : universal_access) return Boolean
+
+8
+The ordering operators are predefined for every specific scalar type T,
+and for every discrete array type T, with the following specifications:
+
+9
+ function "<" (Left, Right : T) return Boolean
+ function "<="(Left, Right : T) return Boolean
+ function ">" (Left, Right : T) return Boolean
+ function ">="(Left, Right : T) return Boolean
+
+ _Name Resolution Rules_
+
+9.1/2
+{AI95-00230-01AI95-00230-01} {AI95-00420-01AI95-00420-01} At least one
+of the operands of an equality operator for universal_access shall be of
+a specific anonymous access type. Unless the predefined equality
+operator is identified using an expanded name with prefix denoting the
+package Standard, neither operand shall be of an access-to-object type
+whose designated type is D or D'Class, where D has a user-defined
+primitive equality operator such that:
+
+9.2/2
+ * its result type is Boolean;
+
+9.3/3
+ * {AI05-0020-1AI05-0020-1} it is declared immediately within the same
+ declaration list as D or any partial or incomplete view of D; and
+
+9.4/2
+ * at least one of its operands is an access parameter with designated
+ type D.
+
+9.a/2
+ Reason: The first sentence prevents compatibility problems by
+ ensuring that these operators are not used for named access
+ types. Also, universal access types do not count for the
+ purposes of this rule. Otherwise, equality expressions like
+ (X = null) would be ambiguous for normal access types.
+
+9.b/2
+ The rest of the rule makes it possible to call (including a
+ dispatching call) user-defined "=" operators for anonymous
+ access-to-object types (they'd be hidden otherwise), and to
+ write user-defined "=" operations for anonymous access types
+ (by making it possible to see the universal operator using the
+ Standard prefix).
+
+9.c/2
+ Ramification: We don't need a similar rule for anonymous
+ access-to-subprogram types because they can't be primitive for
+ any type. Note that any nonprimitive user-defined equality
+ operators still are hidden by the universal operators; they'll
+ have to be called with a package prefix, but they are likely
+ to be very uncommon.
+
+ _Legality Rules_
+
+9.5/2
+{AI95-00230-01AI95-00230-01} At least one of the operands of the
+equality operators for universal_access shall be of type
+universal_access, or both shall be of access-to-object types, or both
+shall be of access-to-subprogram types. Further:
+
+9.6/2
+ * When both are of access-to-object types, the designated types shall
+ be the same or one shall cover the other, and if the designated
+ types are elementary or array types, then the designated subtypes
+ shall statically match;
+
+9.7/2
+ * When both are of access-to-subprogram types, the designated
+ profiles shall be subtype conformant.
+
+9.d/2
+ Reason: We don't want to allow completely arbitrary
+ comparisons, as we don't want to insist that all access types
+ are represented in ways that are convertible to one another.
+ For instance, a compiler could use completely separate address
+ spaces or incompatible representations. Instead, we allow
+ compares if there exists an access parameter to which both
+ operands could be converted. Since the user could write such
+ an subprogram, and any reasonable meaning for "=" would allow
+ using it in such a subprogram, this doesn't impose any further
+ restrictions on Ada implementations.
+
+9.8/3
+{AI05-0123-1AI05-0123-1} If the profile of an explicitly declared
+primitive equality operator of an untagged record type is type
+conformant with that of the corresponding predefined equality operator,
+the declaration shall occur before the type is frozen. In addition, if
+the untagged record type has a nonlimited partial view, then the
+declaration shall occur in the visible part of the enclosing package.
+In addition to the places where Legality Rules normally apply (see *note
+12.3::), this rule applies also in the private part of an instance of a
+generic unit.
+
+ _Dynamic Semantics_
+
+10
+For discrete types, the predefined relational operators are defined in
+terms of corresponding mathematical operations on the position numbers
+of the values of the operands.
+
+11
+For real types, the predefined relational operators are defined in terms
+of the corresponding mathematical operations on the values of the
+operands, subject to the accuracy of the type.
+
+11.a
+ Ramification: For floating point types, the results of
+ comparing nearly equal values depends on the accuracy of the
+ implementation (see *note G.2.1::, "*note G.2.1:: Model of
+ Floating Point Arithmetic" for implementations that support
+ the Numerics Annex).
+
+11.b
+ Implementation Note: On a machine with signed zeros, if the
+ generated code generates both plus zero and minus zero, plus
+ and minus zero must be equal by the predefined equality
+ operators.
+
+12
+Two access-to-object values are equal if they designate the same object,
+or if both are equal to the null value of the access type.
+
+13
+Two access-to-subprogram values are equal if they are the result of the
+same evaluation of an Access attribute_reference, or if both are equal
+to the null value of the access type. Two access-to-subprogram values
+are unequal if they designate different subprograms. [It is unspecified
+whether two access values that designate the same subprogram but are the
+result of distinct evaluations of Access attribute_references are equal
+or unequal.]
+
+13.a
+ Reason: This allows each Access attribute_reference for a
+ subprogram to designate a distinct "wrapper" subprogram if
+ necessary to support an indirect call.
+
+14/3
+{AI05-0123-1AI05-0123-1} For a type extension, predefined equality is
+defined in terms of the primitive [(possibly user-defined)] equals
+operator for the parent type and for any components that have a record
+type in the extension part, and predefined equality for any other
+components not inherited from the parent type.
+
+14.a
+ Ramification: Two values of a type extension are not equal if
+ there is a variant_part in the extension part and the two
+ values have different variants present. This is a
+ ramification of the requirement that a discriminant governing
+ such a variant_part has to be a "new" discriminant, and so has
+ to be equal in the two values for the values to be equal.
+ Note that variant_parts in the parent part need not match if
+ the primitive equals operator for the parent type considers
+ them equal.
+
+14.b/2
+ {AI95-00349-01AI95-00349-01} The full type extension's
+ operation is used for a private extension. This follows as
+ only full types have parent types; the type specified in a
+ private extension is an ancestor, but not necessarily the
+ parent type. For instance, in:
+
+14.c/2
+ with Pak1;
+ package Pak2 is
+ type Typ3 is new Pak1.Typ1 with private;
+ private
+ type Typ3 is new Pak1.Typ2 with null record;
+ end Pak2;
+
+
+14.d/2
+ the parent type is Pak1.Typ2, not Pak1.Typ1, and the equality
+ operator of Pak1.Typ2 is used to create predefined equality
+ for Typ3.
+
+14.1/3
+{AI05-0123-1AI05-0123-1} For a derived type whose parent is an untagged
+record type, predefined equality is defined in terms of the primitive
+(possibly user-defined) equals operator of the parent type.
+
+14.e/3
+ Reason: This prevents predefined equality from reemerging in
+ generic units for untagged record types. For other uses the
+ primitive equality is inherited and the inherited routine is
+ primitive.
+
+15/3
+{AI05-0123-1AI05-0123-1} For a private type, if its full type is a
+record type, predefined equality is defined in terms of the primitive
+equals operator of the full type; otherwise, predefined equality for the
+private type is that of its full type.
+
+16
+For other composite types, the predefined equality operators [(and
+certain other predefined operations on composite types -- see *note
+4.5.1:: and *note 4.6::)] are defined in terms of the corresponding
+operation on matching components, defined as follows:
+
+17
+ * For two composite objects or values of the same non-array type,
+ matching components are those that correspond to the same
+ component_declaration or discriminant_specification;
+
+18
+ * For two one-dimensional arrays of the same type, matching
+ components are those (if any) whose index values match in the
+ following sense: the lower bounds of the index ranges are defined
+ to match, and the successors of matching indices are defined to
+ match;
+
+19
+ * For two multidimensional arrays of the same type, matching
+ components are those whose index values match in successive index
+ positions.
+
+20
+The analogous definitions apply if the types of the two objects or
+values are convertible, rather than being the same.
+
+20.a
+ Discussion: Ada 83 seems to omit this part of the definition,
+ though it is used in array type conversions. See *note 4.6::.
+
+21
+Given the above definition of matching components, the result of the
+predefined equals operator for composite types (other than for those
+composite types covered earlier) is defined as follows:
+
+22
+ * If there are no components, the result is defined to be True;
+
+23
+ * If there are unmatched components, the result is defined to be
+ False;
+
+24/3
+ * {AI05-0123-1AI05-0123-1} Otherwise, the result is defined in terms
+ of the primitive equals operator for any matching components that
+ are records, and the predefined equals for any other matching
+ components.
+
+24.a/3
+ Reason: {AI05-0123-1AI05-0123-1} This asymmetry between
+ components with and without a record type is necessary to
+ preserve most upward compatibility and corresponds with the
+ corresponding situation with generics, where the predefined
+ operations "reemerge" in a generic for non-record types, but
+ do not for record types. Also, only tagged types support
+ user-defined assignment (see *note 7.6::), so only tagged
+ types can fully handle levels of indirection in the
+ implementation of the type. For untagged types, one reason
+ for a user-defined equals operator might be to allow values
+ with different bounds or discriminants to compare equal in
+ certain cases. When such values are matching components, the
+ bounds or discriminants will necessarily match anyway if the
+ discriminants of the enclosing values match.
+
+24.b
+ Ramification: Two null arrays of the same type are always
+ equal; two null records of the same type are always equal.
+
+24.c/3
+ {AI05-0123-1AI05-0123-1} Note that if a composite object has a
+ component of a floating point type, and the floating point
+ type has both a plus and minus zero, which are considered
+ equal by the predefined equality, then a block compare cannot
+ be used for the predefined composite equality. Of course,
+ with user-defined equals operators for components that are
+ records, a block compare breaks down anyway, so this is not
+ the only special case that requires component-by-component
+ comparisons. On a one's complement machine, a similar
+ situation might occur for integer types, since one's
+ complement machines typically have both a plus and minus
+ (integer) zero.
+
+24.d/2
+ To be honest: {AI95-00230-01AI95-00230-01} For a component
+ with an anonymous access type, "predefined equality" is that
+ defined for the universal_access type (anonymous access types
+ have no equality operators of their own).
+
+24.e/3
+ {AI05-0123-1AI05-0123-1} For a component with a record type T,
+ "the primitive equals operator" is the one with two parameters
+ of T which returns Boolean. We're not talking about some
+ random other primitive function named "=".
+
+24.1/3
+{AI05-0123-1AI05-0123-1} If the primitive equals operator for an
+untagged record type is abstract, then Program_Error is raised at the
+point of any (implicit) call to that abstract subprogram.
+
+24.f/3
+ Reason: An explicit call to an abstract subprogram is illegal.
+ This rule is needed in order to define the effect of an
+ implicit call such as a call that is part of the predefined
+ equality operation for an enclosing composite type that has a
+ component of an untagged record type that has an abstract
+ primitive equals operator. For tagged types, an abstract
+ primitive equals operator is only allowed for an abstract
+ type, and abstract types cannot be components, so this case
+ does not occur.
+
+24.2/1
+{8652/00168652/0016} {AI95-00123-01AI95-00123-01} For any composite
+type, the order in which "=" is called for components is unspecified.
+Furthermore, if the result can be determined before calling "=" on some
+components, it is unspecified whether "=" is called on those components.
+
+25
+The predefined "/=" operator gives the complementary result to the
+predefined "=" operator.
+
+25.a
+ Ramification: Furthermore, if the user defines an "=" operator
+ that returns Boolean, then a "/=" operator is implicitly
+ declared in terms of the user-defined "=" operator so as to
+ give the complementary result. See *note 6.6::.
+
+26/3
+{AI05-0264-1AI05-0264-1} For a discrete array type, the predefined
+ordering operators correspond to lexicographic order using the
+predefined order relation of the component type: A null array is
+lexicographically less than any array having at least one component. In
+the case of nonnull arrays, the left operand is lexicographically less
+than the right operand if the first component of the left operand is
+less than that of the right; otherwise, the left operand is
+lexicographically less than the right operand only if their first
+components are equal and the tail of the left operand is
+lexicographically less than that of the right (the tail consists of the
+remaining components beyond the first and can be null).
+
+26.1/3
+{AI05-0269-1AI05-0269-1} An individual membership test is the membership
+test of a single membership_choice.
+
+27/3
+{AI05-0158-1AI05-0158-1} For the evaluation of a membership test using
+in whose membership_choice_list has a single membership_choice, the
+simple_expression and the membership_choice are evaluated in an
+arbitrary order; the result is the result of the individual membership
+test for the membership_choice.
+
+27.1/3
+{AI05-0158-1AI05-0158-1} For the evaluation of a membership test using
+in whose membership_choice_list has more than one membership_choice, the
+simple_expression of the membership test is evaluated first and the
+result of the operation is equivalent to that of a sequence consisting
+of an individual membership test on each membership_choice combined with
+the short-circuit control form or else.
+
+27.a.1/3
+ Ramification: {AI05-0158-1AI05-0158-1} This equivalence
+ includes the evaluation of the membership_choices; evaluation
+ stops as soon as an individual choice evaluates to True.
+
+28/3
+{AI05-0158-1AI05-0158-1} {AI05-0269-1AI05-0269-1} An individual
+membership test yields the result True if:
+
+28.1/3
+ * {AI05-0158-1AI05-0158-1} {AI05-0264-1AI05-0264-1} The
+ membership_choice is a choice_expression, and the simple_expression
+ is equal to the value of the membership_choice. If the tested type
+ is a record type or a limited type, the test uses the primitive
+ equality for the type; otherwise, the test uses predefined
+ equality.
+
+28.2/3
+ * {AI05-0153-3AI05-0153-3} {AI05-0158-1AI05-0158-1} The
+ membership_choice is a range and the value of the simple_expression
+ belongs to the given range.
+
+29/3
+ * {AI05-0153-3AI05-0153-3} {AI05-0158-1AI05-0158-1} The
+ membership_choice is a subtype_mark, the tested type is scalar, the
+ value of the simple_expression belongs to the range of the named
+ subtype, and the predicate of the named subtype evaluates to True.
+
+29.a/3
+ Ramification: {AI05-0153-3AI05-0153-3} The scalar membership
+ test only does a range check and a predicate check. It does
+ not perform any other check, such as whether a value falls in
+ a "hole" of a "holey" enumeration type. The Pos attribute
+ function can be used for that purpose.
+
+29.b
+ Even though Standard.Float is an unconstrained subtype, the
+ test "X in Float" will still return False (presuming the
+ evaluation of X does not raise Constraint_Error) when X is
+ outside Float'Range.
+
+30/3
+ * {AI95-00231-01AI95-00231-01} {AI05-0153-3AI05-0153-3}
+ {AI05-0158-1AI05-0158-1} The membership_choice is a subtype_mark,
+ the tested type is not scalar, the value of the simple_expression
+ satisfies any constraints of the named subtype, the predicate of
+ the named subtype evaluates to True, and:
+
+30.1/2
+ * {AI95-00231-01AI95-00231-01} if the type of the
+ simple_expression is class-wide, the value has a tag that
+ identifies a type covered by the tested type;
+
+30.a
+ Ramification: Note that the tag is not checked if the
+ simple_expression is of a specific type.
+
+30.2/3
+ * {AI95-00231-01AI95-00231-01} {AI05-0149-1AI05-0149-1} if
+ the tested type is an access type and the named subtype
+ excludes null, the value of the simple_expression is not
+ null;
+
+30.3/3
+ * {AI05-0149-1AI05-0149-1} if the tested type is a general
+ access-to-object type, the type of the simple_expression
+ is convertible to the tested type and its accessibility
+ level is no deeper than that of the tested type; further,
+ if the designated type of the tested type is tagged and
+ the simple_expression is nonnull, the tag of the object
+ designated by the value of the simple_expression is
+ covered by the designated type of the tested type.
+
+31/3
+{AI05-0264-1AI05-0264-1} Otherwise, the test yields the result False.
+
+32
+A membership test using not in gives the complementary result to the
+corresponding membership test using in.
+
+32.a/3
+ To be honest: {AI05-0158-1AI05-0158-1} X not in A | B | C is
+ intended to be exactly equivalent to not (X in A | B | C),
+ including the order of evaluation of the simple_expression and
+ membership_choices.
+
+ _Implementation Requirements_
+
+32.1/1
+{8652/00168652/0016} {AI95-00123-01AI95-00123-01} For all nonlimited
+types declared in language-defined packages, the "=" and "/=" operators
+of the type shall behave as if they were the predefined equality
+operators for the purposes of the equality of composite types and
+generic formal types.
+
+32.a.1/3
+ Ramification: {AI95-00123-01AI95-00123-01}
+ {AI05-0123-1AI05-0123-1} If any language-defined types are
+ implemented with a user-defined "=" operator, then either the
+ full type must be a record type, or the compiler must use
+ "magic" to implement equality for this type. A normal
+ user-defined "=" operator for a non-record type does not meet
+ this requirement.
+
+ NOTES
+
+33/2
+ This paragraph was deleted.{AI95-00230-01AI95-00230-01}
+
+34
+ 13 If a composite type has components that depend on
+ discriminants, two values of this type have matching components if
+ and only if their discriminants are equal. Two nonnull arrays have
+ matching components if and only if the length of each dimension is
+ the same for both.
+
+ _Examples_
+
+35
+Examples of expressions involving relational operators and membership
+tests:
+
+36
+ X /= Y
+
+37
+ "" < "A" and "A" < "Aa" -- True
+ "Aa" < "B" and "A" < "A " -- True
+
+38/3
+ {AI05-0264-1AI05-0264-1} My_Car = null -- True if My_Car has been set to null (see *note 3.10.1::)
+ My_Car = Your_Car -- True if we both share the same car
+ My_Car.all = Your_Car.all -- True if the two cars are identical
+
+39/3
+ {AI05-0158-1AI05-0158-1} N not in 1 .. 10 -- range membership test
+ Today in Mon .. Fri -- range membership test
+ Today in Weekday -- subtype membership test (see *note 3.5.1::)
+ Card in Clubs | Spades -- list membership test (see *note 3.5.1::)
+ Archive in Disk_Unit -- subtype membership test (see *note 3.8.1::)
+ Tree.all in Addition'Class -- class membership test (see *note 3.9.1::)
+
+ _Extensions to Ada 83_
+
+39.a
+ Membership tests can be used to test the tag of a class-wide
+ value.
+
+39.b
+ Predefined equality for a composite type is defined in terms
+ of the primitive equals operator for tagged components or the
+ parent part.
+
+ _Wording Changes from Ada 83_
+
+39.c
+ The term "membership test" refers to the relation "X in S"
+ rather to simply the reserved word in or not in.
+
+39.d
+ We use the term "equality operator" to refer to both the =
+ (equals) and /= (not equals) operators. Ada 83 referred to =
+ as the equality operator, and /= as the inequality operator.
+ The new wording is more consistent with the ISO 10646 name for
+ "=" (equals sign) and provides a category similar to "ordering
+ operator" to refer to both = and /=.
+
+39.e
+ We have changed the term "catenate" to "concatenate".
+
+ _Extensions to Ada 95_
+
+39.f/2
+ {AI95-00230-01AI95-00230-01} {AI95-00420-01AI95-00420-01} The
+ universal_access equality operators are new. They provide
+ equality operations (most importantly, testing against null)
+ for anonymous access types.
+
+ _Wording Changes from Ada 95_
+
+39.g/2
+ {8652/00168652/0016} {AI95-00123-01AI95-00123-01} Corrigendum:
+ Wording was added to clarify that the order of calls (and
+ whether the calls are made at all) on "=" for components is
+ unspecified. Also clarified that "=" must compose properly
+ for language-defined types.
+
+39.h/2
+ {AI95-00251-01AI95-00251-01} Memberships were adjusted to
+ allow interfaces which don't cover the tested type, in order
+ to be consistent with type conversions.
+
+ _Inconsistencies With Ada 2005_
+
+39.i/3
+ {AI05-0123-1AI05-0123-1} User-defined untagged record equality
+ is now defined to compose and be used in generics. Any code
+ which assumes that the predefined equality reemerges in
+ generics and in predefined equals for composite types could
+ fail. However, it is much more likely that this change will
+ fix bugs, as the behavior that would be expected (the
+ user-defined "=" is used) will be true in more cases.
+
+39.j/3
+ {AI05-0123-1AI05-0123-1} If a composite type contains a
+ component of an untagged record type with an abstract equality
+ operation, calling "=" on the composite type will raise
+ Program_Error, while in the past a result will be returned
+ using the predefined equality. This is quite possible in ASIS
+ programs; it will detect a bug in such programs but of course
+ the programs will need to be fixed before they will work.
+
+ _Incompatibilities With Ada 2005_
+
+39.k/3
+ {AI05-0123-1AI05-0123-1} Late and hidden overriding of
+ equality for untagged record types is now prohibited. This is
+ necessary to make composition of equality predictable. It
+ should always be possible to move the overriding to an earlier
+ spot where it will be legal.
+
+ _Extensions to Ada 2005_
+
+39.l/3
+ {AI05-0149-1AI05-0149-1} Membership tests for valid
+ accessibility levels and tag coverage by the designated type
+ for general access types are new.
+
+39.m/3
+ {AI05-0153-3AI05-0153-3} Membership tests now include a
+ predicate check.
+
+39.n/3
+ {AI05-0158-1AI05-0158-1} Membership tests now allow multiple
+ choices.
+
+ _Wording Changes from Ada 2005_
+
+39.o/3
+ {AI05-0020-1AI05-0020-1} Correction: Wording was added to
+ clarify that universal_access "=" does not apply if an
+ appropriate operator is declared for a partial or incomplete
+ view of the designated type. Otherwise, adding a partial or
+ incomplete view could make some "=" operators ambiguous.
+
+\1f
+File: aarm2012.info, Node: 4.5.3, Next: 4.5.4, Prev: 4.5.2, Up: 4.5
+
+4.5.3 Binary Adding Operators
+-----------------------------
+
+ _Static Semantics_
+
+1
+The binary adding operators + (addition) and - (subtraction) are
+predefined for every specific numeric type T with their conventional
+meaning. They have the following specifications:
+
+2
+ function "+"(Left, Right : T) return T
+ function "-"(Left, Right : T) return T
+
+3
+The concatenation operators & are predefined for every nonlimited,
+one-dimensional array type T with component type C. They have the
+following specifications:
+
+4
+ function "&"(Left : T; Right : T) return T
+ function "&"(Left : T; Right : C) return T
+ function "&"(Left : C; Right : T) return T
+ function "&"(Left : C; Right : C) return T
+
+ _Dynamic Semantics_
+
+5
+For the evaluation of a concatenation with result type T, if both
+operands are of type T, the result of the concatenation is a
+one-dimensional array whose length is the sum of the lengths of its
+operands, and whose components comprise the components of the left
+operand followed by the components of the right operand. If the left
+operand is a null array, the result of the concatenation is the right
+operand. Otherwise, the lower bound of the result is determined as
+follows:
+
+6
+ * If the ultimate ancestor of the array type was defined by a
+ constrained_array_definition, then the lower bound of the result is
+ that of the index subtype;
+
+6.a
+ Reason: This rule avoids Constraint_Error when using
+ concatenation on an array type whose first subtype is
+ constrained.
+
+7
+ * If the ultimate ancestor of the array type was defined by an
+ unconstrained_array_definition, then the lower bound of the result
+ is that of the left operand.
+
+8
+[The upper bound is determined by the lower bound and the length.] A
+check is made that the upper bound of the result of the concatenation
+belongs to the range of the index subtype, unless the result is a null
+array. Constraint_Error is raised if this check fails.
+
+9
+If either operand is of the component type C, the result of the
+concatenation is given by the above rules, using in place of such an
+operand an array having this operand as its only component (converted to
+the component subtype) and having the lower bound of the index subtype
+of the array type as its lower bound.
+
+9.a
+ Ramification: The conversion might raise Constraint_Error.
+ The conversion provides "sliding" for the component in the
+ case of an array-of-arrays, consistent with the normal Ada 95
+ rules that allow sliding during parameter passing.
+
+10
+The result of a concatenation is defined in terms of an assignment to an
+anonymous object, as for any function call (see *note 6.5::).
+
+10.a
+ Ramification: This implies that value adjustment is performed
+ as appropriate -- see *note 7.6::. We don't bother saying
+ this for other predefined operators, even though they are all
+ function calls, because this is the only one where it matters.
+ It is the only one that can return a value having controlled
+ parts.
+
+ NOTES
+
+11
+ 14 As for all predefined operators on modular types, the binary
+ adding operators + and - on modular types include a final reduction
+ modulo the modulus if the result is outside the base range of the
+ type.
+
+11.a
+ Implementation Note: A full "modulus" operation need not be
+ performed after addition or subtraction of modular types. For
+ binary moduli, a simple mask is sufficient. For nonbinary
+ moduli, a check after addition to see if the value is greater
+ than the high bound of the base range can be followed by a
+ conditional subtraction of the modulus. Conversely, a check
+ after subtraction to see if a "borrow" was performed can be
+ followed by a conditional addition of the modulus.
+
+ _Examples_
+
+12
+Examples of expressions involving binary adding operators:
+
+13
+ Z + 0.1 -- Z has to be of a real type
+
+14
+ "A" & "BCD" -- concatenation of two string literals
+ 'A' & "BCD" -- concatenation of a character literal and a string literal
+ 'A' & 'A' -- concatenation of two character literals
+
+ _Inconsistencies With Ada 83_
+
+14.a
+ The lower bound of the result of concatenation, for a type
+ whose first subtype is constrained, is now that of the index
+ subtype. This is inconsistent with Ada 83, but generally only
+ for Ada 83 programs that raise Constraint_Error. For example,
+ the concatenation operator in
+
+14.b
+ X : array(1..10) of Integer;
+ begin
+ X := X(6..10) & X(1..5);
+
+14.c
+ would raise Constraint_Error in Ada 83 (because the bounds of
+ the result of the concatenation would be 6..15, which is
+ outside of 1..10), but would succeed and swap the halves of X
+ (as expected) in Ada 95.
+
+ _Extensions to Ada 83_
+
+14.d
+ Concatenation is now useful for array types whose first
+ subtype is constrained. When the result type of a
+ concatenation is such an array type, Constraint_Error is
+ avoided by effectively first sliding the left operand (if
+ nonnull) so that its lower bound is that of the index subtype.
+
+\1f
+File: aarm2012.info, Node: 4.5.4, Next: 4.5.5, Prev: 4.5.3, Up: 4.5
+
+4.5.4 Unary Adding Operators
+----------------------------
+
+ _Static Semantics_
+
+1
+The unary adding operators + (identity) and - (negation) are predefined
+for every specific numeric type T with their conventional meaning. They
+have the following specifications:
+
+2
+ function "+"(Right : T) return T
+ function "-"(Right : T) return T
+
+ NOTES
+
+3
+ 15 For modular integer types, the unary adding operator -, when
+ given a nonzero operand, returns the result of subtracting the
+ value of the operand from the modulus; for a zero operand, the
+ result is zero.
+
+\1f
+File: aarm2012.info, Node: 4.5.5, Next: 4.5.6, Prev: 4.5.4, Up: 4.5
+
+4.5.5 Multiplying Operators
+---------------------------
+
+ _Static Semantics_
+
+1
+The multiplying operators * (multiplication), / (division), mod
+(modulus), and rem (remainder) are predefined for every specific integer
+type T:
+
+2
+ function "*" (Left, Right : T) return T
+ function "/" (Left, Right : T) return T
+ function "mod"(Left, Right : T) return T
+ function "rem"(Left, Right : T) return T
+
+3
+Signed integer multiplication has its conventional meaning.
+
+4
+Signed integer division and remainder are defined by the relation:
+
+5
+ A = (A/B)*B + (A rem B)
+
+6
+where (A rem B) has the sign of A and an absolute value less than the
+absolute value of B. Signed integer division satisfies the identity:
+
+7
+ (-A)/B = -(A/B) = A/(-B)
+
+8/3
+{AI05-0260-1AI05-0260-1} The signed integer modulus operator is defined
+such that the result of A mod B is either zero, or has the sign of B and
+an absolute value less than the absolute value of B; in addition, for
+some signed integer value N, this result satisfies the relation:
+
+9
+ A = B*N + (A mod B)
+
+10
+The multiplying operators on modular types are defined in terms of the
+corresponding signed integer operators[, followed by a reduction modulo
+the modulus if the result is outside the base range of the type] [(which
+is only possible for the "*" operator)].
+
+10.a
+ Ramification: The above identity satisfied by signed integer
+ division is not satisfied by modular division because of the
+ difference in effect of negation.
+
+11
+Multiplication and division operators are predefined for every specific
+floating point type T:
+
+12
+ function "*"(Left, Right : T) return T
+ function "/"(Left, Right : T) return T
+
+13
+The following multiplication and division operators, with an operand of
+the predefined type Integer, are predefined for every specific fixed
+point type T:
+
+14
+ function "*"(Left : T; Right : Integer) return T
+ function "*"(Left : Integer; Right : T) return T
+ function "/"(Left : T; Right : Integer) return T
+
+15
+[All of the above multiplying operators are usable with an operand of an
+appropriate universal numeric type.] The following additional
+multiplying operators for root_real are predefined[, and are usable when
+both operands are of an appropriate universal or root numeric type, and
+the result is allowed to be of type root_real, as in a
+number_declaration]:
+
+15.a
+ Ramification: These operators are analogous to the multiplying
+ operators involving fixed or floating point types where
+ root_real substitutes for the fixed or floating point type,
+ and root_integer substitutes for Integer. Only values of the
+ corresponding universal numeric types are implicitly
+ convertible to these root numeric types, so these operators
+ are really restricted to use with operands of a universal
+ type, or the specified root numeric types.
+
+16
+ function "*"(Left, Right : root_real) return root_real
+ function "/"(Left, Right : root_real) return root_real
+
+17
+ function "*"(Left : root_real; Right : root_integer) return root_real
+ function "*"(Left : root_integer; Right : root_real) return root_real
+ function "/"(Left : root_real; Right : root_integer) return root_real
+
+18
+Multiplication and division between any two fixed point types are
+provided by the following two predefined operators:
+
+18.a
+ Ramification: Universal_fixed is the universal type for the
+ class of fixed point types, meaning that these operators take
+ operands of any fixed point types (not necessarily the same)
+ and return a result that is implicitly (or explicitly)
+ convertible to any fixed point type.
+
+19
+ function "*"(Left, Right : universal_fixed) return universal_fixed
+ function "/"(Left, Right : universal_fixed) return universal_fixed
+
+ _Name Resolution Rules_
+
+19.1/2
+{AI95-00364-01AI95-00364-01} {AI95-00420-01AI95-00420-01} The above two
+fixed-fixed multiplying operators shall not be used in a context where
+the expected type for the result is itself universal_fixed [-- the
+context has to identify some other numeric type to which the result is
+to be converted, either explicitly or implicitly]. Unless the
+predefined universal operator is identified using an expanded name with
+prefix denoting the package Standard, an explicit conversion is required
+on the result when using the above fixed-fixed multiplication operator
+if either operand is of a type having a user-defined primitive
+multiplication operator such that:
+
+19.2/3
+ * {AI05-0020-1AI05-0020-1} {AI05-0209-1AI05-0209-1} it is declared
+ immediately within the same declaration list as the type or any
+ partial or incomplete view thereof; and
+
+19.3/2
+ * both of its formal parameters are of a fixed-point type.
+
+19.4/2
+{AI95-00364-01AI95-00364-01} {AI95-00420-01AI95-00420-01} A
+corresponding requirement applies to the universal fixed-fixed division
+operator.
+
+19.a/2
+ Discussion: The small of universal_fixed is infinitesimal; no
+ loss of precision is permitted. However, fixed-fixed division
+ is impractical to implement when an exact result is required,
+ and multiplication will sometimes result in unanticipated
+ overflows in such circumstances, so we require an explicit
+ conversion to be inserted in expressions like A * B * C if A,
+ B, and C are each of some fixed point type.
+
+19.b/2
+ On the other hand, X := A * B; is permitted by this rule, even
+ if X, A, and B are all of different fixed point types, since
+ the expected type for the result of the multiplication is the
+ type of X, which is necessarily not universal_fixed.
+
+19.c/2
+ {AI95-00364-01AI95-00364-01} {AI95-00420-01AI95-00420-01} We
+ have made these into Name Resolution rules to ensure that
+ user-defined primitive fixed-fixed operators are not made
+ unusable due to the presence of these universal fixed-fixed
+ operators. But we do allow these operators to be used if
+ prefixed by package Standard, so that they can be used in the
+ definitions of user-defined operators.
+
+Paragraph 20 was deleted.
+
+ _Dynamic Semantics_
+
+21
+The multiplication and division operators for real types have their
+conventional meaning. [For floating point types, the accuracy of the
+result is determined by the precision of the result type. For decimal
+fixed point types, the result is truncated toward zero if the
+mathematical result is between two multiples of the small of the
+specific result type (possibly determined by context); for ordinary
+fixed point types, if the mathematical result is between two multiples
+of the small, it is unspecified which of the two is the result. ]
+
+22
+The exception Constraint_Error is raised by integer division, rem, and
+mod if the right operand is zero. [Similarly, for a real type T with
+T'Machine_Overflows True, division by zero raises Constraint_Error.]
+
+ NOTES
+
+23
+ 16 For positive A and B, A/B is the quotient and A rem B is the
+ remainder when A is divided by B. The following relations are
+ satisfied by the rem operator:
+
+24
+ A rem (-B) = A rem B
+ (-A) rem B = -(A rem B)
+
+25
+ 17 For any signed integer K, the following identity holds:
+
+26
+ A mod B = (A + K*B) mod B
+
+27
+ The relations between signed integer division, remainder, and
+ modulus are illustrated by the following table:
+
+28
+ A B A/B A rem B A mod B A B A/B A rem B A mod B
+
+29
+ 10 5 2 0 0 -10 5 -2 0 0
+ 11 5 2 1 1 -11 5 -2 -1 4
+ 12 5 2 2 2 -12 5 -2 -2 3
+ 13 5 2 3 3 -13 5 -2 -3 2
+ 14 5 2 4 4 -14 5 -2 -4 1
+
+30
+ A B A/B A rem B A mod B A B A/B A rem B A mod B
+
+ 10 -5 -2 0 0 -10 -5 2 0 0
+ 11 -5 -2 1 -4 -11 -5 2 -1 -1
+ 12 -5 -2 2 -3 -12 -5 2 -2 -2
+ 13 -5 -2 3 -2 -13 -5 2 -3 -3
+ 14 -5 -2 4 -1 -14 -5 2 -4 -4
+
+ _Examples_
+
+31
+Examples of expressions involving multiplying operators:
+
+32
+ I : Integer := 1;
+ J : Integer := 2;
+ K : Integer := 3;
+
+33
+ X : Real := 1.0; -- see *note 3.5.7::
+ Y : Real := 2.0;
+
+34
+ F : Fraction := 0.25; -- see *note 3.5.9::
+ G : Fraction := 0.5;
+
+35
+ Expression Value Result Type
+
+ I*J 2 same as I and J, that is, Integer
+ K/J 1 same as K and J, that is, Integer
+ K mod J 1 same as K and J, that is, Integer
+
+ X/Y 0.5 same as X and Y, that is, Real
+ F/2 0.125 same as F, that is, Fraction
+
+ 3*F 0.75 same as F, that is, Fraction
+ 0.75*G 0.375 universal_fixed, implicitly convertible
+ to any fixed point type
+ Fraction(F*G) 0.125 Fraction, as stated by the conversion
+ Real(J)*Y 4.0 Real, the type of both operands after
+ conversion of J
+
+ _Incompatibilities With Ada 83_
+
+35.a.1/2
+ {AI95-00364-01AI95-00364-01} {AI95-00420-01AI95-00420-01} The
+ universal fixed-fixed multiplying operators are now directly
+ available (see below). Any attempt to use user-defined
+ fixed-fixed multiplying operators will be ambiguous with the
+ universal ones. The only way to use the user-defined
+ operators is to fully qualify them in a prefix call. This
+ problem was not documented during the design of Ada 95, and
+ has been mitigated by Ada 2005.
+
+ _Extensions to Ada 83_
+
+35.a
+ Explicit conversion of the result of multiplying or dividing
+ two fixed point numbers is no longer required, provided the
+ context uniquely determines some specific fixed point result
+ type. This is to improve support for decimal fixed point,
+ where requiring explicit conversion on every fixed-fixed
+ multiply or divide was felt to be inappropriate.
+
+35.b
+ The type universal_fixed is covered by universal_real, so real
+ literals and fixed point operands may be multiplied or divided
+ directly, without any explicit conversions required.
+
+ _Wording Changes from Ada 83_
+
+35.c
+ We have used the normal syntax for function definition rather
+ than a tabular format.
+
+ _Incompatibilities With Ada 95_
+
+35.d/2
+ {AI95-00364-01AI95-00364-01} We have changed the resolution
+ rules for the universal fixed-fixed multiplying operators to
+ remove the incompatibility with Ada 83 discussed above. The
+ solution is to hide the universal operators in some
+ circumstances. As a result, some legal Ada 95 programs will
+ require the insertion of an explicit conversion around a
+ fixed-fixed multiply operator. This change is likely to catch
+ as many bugs as it causes, since it is unlikely that the user
+ wanted to use predefined operators when they had defined
+ user-defined versions.
+
+ _Wording Changes from Ada 2005_
+
+35.e/3
+ {AI05-0020-1AI05-0020-1} {AI05-0209-1AI05-0209-1} Correction:
+ Wording was added to clarify that universal_fixed "*" and "/"
+ does not apply if an appropriate operator is declared for a
+ partial (or incomplete) view of the designated type.
+ Otherwise, adding a partial (or incomplete) view could make
+ some "*" and "/" operators ambiguous.
+
+35.f/3
+ {AI05-0260-1AI05-0260-1} Correction: The wording for the mod
+ operator was corrected so that a result of 0 does not have to
+ have "the sign of B" (which is impossible if B is negative).
+
+\1f
+File: aarm2012.info, Node: 4.5.6, Next: 4.5.7, Prev: 4.5.5, Up: 4.5
+
+4.5.6 Highest Precedence Operators
+----------------------------------
+
+ _Static Semantics_
+
+1
+The highest precedence unary operator abs (absolute value) is predefined
+for every specific numeric type T, with the following specification:
+
+2
+ function "abs"(Right : T) return T
+
+3
+The highest precedence unary operator not (logical negation) is
+predefined for every boolean type T, every modular type T, and for every
+one-dimensional array type T whose components are of a boolean type,
+with the following specification:
+
+4
+ function "not"(Right : T) return T
+
+5
+The result of the operator not for a modular type is defined as the
+difference between the high bound of the base range of the type and the
+value of the operand. [For a binary modulus, this corresponds to a
+bit-wise complement of the binary representation of the value of the
+operand.]
+
+6
+The operator not that applies to a one-dimensional array of boolean
+components yields a one-dimensional boolean array with the same bounds;
+each component of the result is obtained by logical negation of the
+corresponding component of the operand (that is, the component that has
+the same index value). A check is made that each component of the
+result belongs to the component subtype; the exception Constraint_Error
+is raised if this check fails.
+
+6.a
+ Discussion: The check against the component subtype is per
+ AI83-00535.
+
+7
+The highest precedence exponentiation operator ** is predefined for
+every specific integer type T with the following specification:
+
+8
+ function "**"(Left : T; Right : Natural) return T
+
+9
+Exponentiation is also predefined for every specific floating point type
+as well as root_real, with the following specification (where T is
+root_real or the floating point type):
+
+10
+ function "**"(Left : T; Right : Integer'Base) return T
+
+11/3
+{AI05-0088-1AI05-0088-1} The right operand of an exponentiation is the
+exponent. The value of X**N with the value of the exponent N positive
+is the same as the value of X*X*...X (with N-1 multiplications) except
+that the multiplications are associated in an arbitrary order. With N
+equal to zero, the result is one. With the value of N negative [(only
+defined for a floating point operand)], the result is the reciprocal of
+the result using the absolute value of N as the exponent.
+
+11.a
+ Ramification: The language does not specify the order of
+ association of the multiplications inherent in an
+ exponentiation. For a floating point type, the accuracy of
+ the result might depend on the particular association order
+ chosen.
+
+ _Implementation Permissions_
+
+12
+The implementation of exponentiation for the case of a negative exponent
+is allowed to raise Constraint_Error if the intermediate result of the
+repeated multiplications is outside the safe range of the type, even
+though the final result (after taking the reciprocal) would not be.
+(The best machine approximation to the final result in this case would
+generally be 0.0.)
+
+ NOTES
+
+13
+ 18 As implied by the specification given above for exponentiation
+ of an integer type, a check is made that the exponent is not
+ negative. Constraint_Error is raised if this check fails.
+
+ _Inconsistencies With Ada 83_
+
+13.a.1/1
+ {8652/01008652/0100} {AI95-00018-01AI95-00018-01} The
+ definition of "**" allows arbitrary association of the
+ multiplications which make up the result. Ada 83 required
+ left-to-right associations (confirmed by AI83-00137). Thus it
+ is possible that "**" would provide a slightly different (and
+ more potentially accurate) answer in Ada 95 than in the same
+ Ada 83 program.
+
+ _Wording Changes from Ada 83_
+
+13.a
+ We now show the specification for "**" for integer types with
+ a parameter subtype of Natural rather than Integer for the
+ exponent. This reflects the fact that Constraint_Error is
+ raised if a negative value is provided for the exponent.
+
+ _Wording Changes from Ada 2005_
+
+13.b/3
+ {AI05-0088-1AI05-0088-1} Correction: The equivalence
+ definition for "**" was corrected so that it does not imply
+ that the operands are evaluated multiple times.
+
+\1f
+File: aarm2012.info, Node: 4.5.7, Next: 4.5.8, Prev: 4.5.6, Up: 4.5
+
+4.5.7 Conditional Expressions
+-----------------------------
+
+1/3
+{AI05-0147-1AI05-0147-1} {AI05-0188-1AI05-0188-1}
+{AI05-0262-1AI05-0262-1} A conditional_expression selects for evaluation
+at most one of the enclosed dependent_expressions, depending on a
+decision among the alternatives. One kind of conditional_expression is
+the if_expression, which selects for evaluation a dependent_expression
+depending on the value of one or more corresponding conditions. The
+other kind of conditional_expression is the case_expression, which
+selects for evaluation one of a number of alternative
+dependent_expressions; the chosen alternative is determined by the value
+of a selecting_expression.
+
+ _Language Design Principles_
+
+1.a/3
+ {AI05-0188-1AI05-0188-1} As previously noted, there are two
+ kinds of conditional_expression, if_expressions and
+ case_expressions. Whenever possible, we have written the
+ rules in terms of conditional_expressions to avoid
+ duplication.
+
+1.b/3
+ {AI05-0147-1AI05-0147-1} The rules for conditional_expressions
+ have been designed as much as possible to work similarly to a
+ parenthesized expression. The intent is that as much as
+ possible, wherever a parenthesized expression would be
+ allowed, a conditional_expression would be allowed, and it
+ should work the same way.
+
+ _Syntax_
+
+2/3
+ {AI05-0188-1AI05-0188-1} conditional_expression ::= if_expression |
+ case_expression
+
+3/3
+ {AI05-0147-1AI05-0147-1} {AI05-0188-1AI05-0188-1} if_expression ::=
+
+ if condition then dependent_expression
+ {elsif condition then dependent_expression}
+ [else dependent_expression]
+
+4/3
+ {AI05-0147-1AI05-0147-1} condition ::= boolean_expression
+
+5/3
+ {AI05-0188-1AI05-0188-1} case_expression ::=
+ case selecting_expression is
+ case_expression_alternative {,
+ case_expression_alternative}
+
+6/3
+ {AI05-0188-1AI05-0188-1} case_expression_alternative ::=
+ when discrete_choice_list =>
+ dependent_expression
+
+7/3
+ {AI05-0147-1AI05-0147-1} Wherever the Syntax Rules allow an
+ expression, a conditional_expression may be used in place of the
+ expression, so long as it is immediately surrounded by parentheses.
+
+7.a/3
+ Discussion: {AI05-0147-1AI05-0147-1} The syntactic category
+ conditional_expression appears only as a primary that is
+ parenthesized. The above rule allows it to additionally be
+ used in other contexts where it would be directly surrounded
+ by parentheses.
+
+7.b/3
+ The grammar makes the following directly legal:
+
+7.c/3
+ A := (if X then Y else Z); -- parentheses required
+ A := B + (if X then Y else Z) + C; -- parentheses required
+
+7.d/3
+ The following procedure calls are syntactically legal; the
+ first uses the above rule to eliminate the redundant
+ parentheses found in the second:
+
+7.e/3
+ P(if X then Y else Z);
+ P((if X then Y else Z)); -- redundant parentheses
+
+7.f/3
+ P((if X then Y else Z), Some_Other_Param);
+ P(Some_Other_Param, (if X then Y else Z));
+ P(Formal => (if X then Y else Z));
+
+7.g/3
+ whereas the following are illegal:
+
+7.h/3
+ P(if X then Y else Z, Some_Other_Param);
+ P(Some_Other_Param, if X then Y else Z);
+ P(Formal => if X then Y else Z);
+
+7.i/3
+ because in these latter cases, the conditional_expression is
+ not immediately surrounded by parentheses (which means on both
+ sides!).
+
+7.j/3
+ The English-language rule applies in all places that could
+ surround an expression with parentheses, including pragma
+ arguments, type conversion and qualified expression operands,
+ and array index expressions.
+
+7.k/3
+ This English-language rule could have been implemented instead
+ by adding a nonterminal expression_within_parentheses, which
+ would consist of expressions and conditional_expressions.
+ Then, that could be used in all of the syntax which could
+ consist of parens directly around an expression. We did not
+ do that because of the large amount of change required. A
+ complete grammar is given in AI05-0147-1AI05-0147-1.
+
+7.l/3
+ Implementation Note: {AI05-0147-1AI05-0147-1} Implementers are
+ cautioned to consider error detection when implementing the
+ syntax for conditional_expressions. An if_expression and an
+ if_statement are very similar syntactically, (as are a
+ case_expression and a case_statement) and simple mistakes can
+ appear to change one into the other, potentially causing
+ errors to be moved far away from their actual location. The
+ absence of end if to terminate an if_expression (and end case
+ for a case_expression) also may make error handling harder.
+
+ _Name Resolution Rules_
+
+8/3
+{AI05-0147-1AI05-0147-1} If a conditional_expression is expected to be
+of a type T, then each dependent_expression of the
+conditional_expression is expected to be of type T. Similarly, if a
+conditional_expression is expected to be of some class of types, then
+each dependent_expression of the conditional_expression is subject to
+the same expectation. If a conditional_expression shall resolve to be
+of a type T, then each dependent_expression shall resolve to be of type
+T.
+
+9/3
+{AI05-0147-1AI05-0147-1} The possible types of a conditional_expression
+are further determined as follows:
+
+10/3
+ * If the conditional_expression is the operand of a type conversion,
+ the type of the conditional_expression is the target type of the
+ conversion; otherwise,
+
+10.a/3
+ Reason: This rule distributes an enclosing type conversion to
+ the dependent_expressions. This means that
+
+10.b/3
+ T(if C then A else B)
+
+10.c/3
+ has the same semantics as
+
+10.d/3
+ (if C then T(A) else T(B))
+
+11/3
+ * If all of the dependent_expressions are of the same type, the type
+ of the conditional_expression is that type; otherwise,
+
+12/3
+ * If a dependent_expression is of an elementary type, the type of the
+ conditional_expression shall be covered by that type; otherwise,
+
+12.a/3
+ Reason: This rule supports the use of numeric literals and
+ universal expressions within a conditional_expression.
+
+13/3
+ * If the conditional_expression is expected to be of type T or shall
+ resolve to type T, then the conditional_expression is of type T.
+
+13.a/3
+ Ramification: If the type of the conditional_expression cannot
+ be determined by one of these rules, then Name Resolution has
+ failed for that expression, even if the dependent_expressions
+ would resolve individually.
+
+14/3
+{AI05-0147-1AI05-0147-1} A condition is expected to be of any boolean
+type.
+
+15/3
+{AI05-0188-1AI05-0188-1} The expected type for the selecting_expression
+and the discrete_choices are as for case statements (see *note 5.4::).
+
+ _Legality Rules_
+
+16/3
+{AI05-0147-1AI05-0147-1} {AI05-0188-1AI05-0188-1} All of the
+dependent_expressions shall be convertible (see *note 4.6::) to the type
+of the conditional_expression.
+
+17/3
+{AI05-0147-1AI05-0147-1} {AI05-0188-1AI05-0188-1}
+{AI05-0269-1AI05-0269-1} If the expected type of a
+conditional_expression is a specific tagged type, all of the
+dependent_expressions of the conditional_expression shall be dynamically
+tagged, or none shall be dynamically tagged. In this case, the
+conditional_expression is dynamically tagged if all of the
+dependent_expressions are dynamically tagged, is tag-indeterminate if
+all of the dependent_expressions are tag-indeterminate, and is
+statically tagged otherwise.
+
+18/3
+{AI05-0147-1AI05-0147-1} {AI05-0262-1AI05-0262-1} If there is no else
+dependent_expression, the if_expression shall be of a boolean type.
+
+19/3
+{AI05-0188-1AI05-0188-1} {AI05-0269-1AI05-0269-1} All Legality Rules
+that apply to the discrete_choices of a case_statement (see *note 5.4::)
+also apply to the discrete_choices of a case_expression except within an
+instance of a generic unit.
+
+19.a/3
+ Reason: The exemption for a case expression that occurs in an
+ instance allows the following example:
+
+19.b/3
+ generic
+ with function Int_Func return Integer;
+ package G is
+ X : Float := (case Int_Func is
+ when Integer'First .. -1 => -1.0,
+ when 0 => 0.0,
+ when Positive => 1.0);
+ end G;
+
+19.c/3
+ function Nat_Func return Natural is (123);
+
+19.d/3
+ package I is new G (Int_Func => Nat_Func); -- Legal
+
+19.e/3
+ Note that the Legality Rules still apply in the generic unit
+ itself; they are just not enforced in an instance of the unit.
+
+ _Dynamic Semantics_
+
+20/3
+{AI05-0147-1AI05-0147-1} {AI05-0188-1AI05-0188-1} For the evaluation of
+an if_expression, the condition specified after if, and any conditions
+specified after elsif, are evaluated in succession (treating a final
+else as elsif True then), until one evaluates to True or all conditions
+are evaluated and yield False. If a condition evaluates to True, the
+associated dependent_expression is evaluated, converted to the type of
+the if_expression, and the resulting value is the value of the
+if_expression. Otherwise (when there is no else clause), the value of
+the if_expression is True.
+
+20.a/3
+ Ramification: Else is required unless the if_expression has a
+ boolean type, so the last sentence can only apply to
+ if_expressions with a boolean type.
+
+21/3
+{AI05-0188-1AI05-0188-1} For the evaluation of a case_expression, the
+selecting_expression is first evaluated. If the value of the
+selecting_expression is covered by the discrete_choice_list of some
+case_expression_alternative, then the dependent_expression of the
+case_expression_alternative is evaluated, converted to the type of the
+case_expression, and the resulting value is the value of the
+case_expression. Otherwise (the value is not covered by any
+discrete_choice_list, perhaps due to being outside the base range),
+Constraint_Error is raised.
+
+ _Extensions to Ada 2005_
+
+21.a/3
+ {AI05-0147-1AI05-0147-1} If expressions and case expressions
+ are new.
+
+\1f
+File: aarm2012.info, Node: 4.5.8, Prev: 4.5.7, Up: 4.5
+
+4.5.8 Quantified Expressions
+----------------------------
+
+ _Syntax_
+
+1/3
+ {AI05-0176-1AI05-0176-1} quantified_expression ::= for quantifier
+ loop_parameter_specification => predicate
+ | for quantifier iterator_specification => predicate
+
+2/3
+ quantifier ::= all | some
+
+3/3
+ predicate ::= boolean_expression
+
+4/3
+ {AI05-0176-1AI05-0176-1} Wherever the Syntax Rules allow an
+ expression, a quantified_expression may be used in place of the
+ expression, so long as it is immediately surrounded by parentheses.
+
+4.a/3
+ Discussion: The syntactic category quantified_expression
+ appears only as a primary that is parenthesized. The above
+ rule allows it to additionally be used in other contexts where
+ it would be directly surrounded by parentheses. This is the
+ same rule that is used for conditional_expressions; see *note
+ 4.5.7:: for a detailed discussion of the meaning and effects
+ of this rule.
+
+ _Name Resolution Rules_
+
+5/3
+{AI05-0176-1AI05-0176-1} The expected type of a quantified_expression is
+any Boolean type. The predicate in a quantified_expression is expected
+to be of the same type.
+
+ _Dynamic Semantics_
+
+6/3
+{AI05-0176-1AI05-0176-1} For the evaluation of a quantified_expression,
+the loop_parameter_specification or iterator_specification is first
+elaborated. The evaluation of a quantified_expression then evaluates
+the predicate for each value of the loop parameter. These values are
+examined in the order specified by the loop_parameter_specification (see
+*note 5.5::) or iterator_specification (see *note 5.5.2::).
+
+7/3
+{AI05-0176-1AI05-0176-1} The value of the quantified_expression is
+determined as follows:
+
+8/3
+ * If the quantifier is all, the expression is True if the evaluation
+ of the predicate yields True for each value of the loop parameter.
+ It is False otherwise. Evaluation of the quantified_expression
+ stops when all values of the domain have been examined, or when the
+ predicate yields False for a given value. Any exception raised by
+ evaluation of the predicate is propagated.
+
+8.a/3
+ Ramification: The expression is True if the domain contains no
+ values.
+
+9/3
+ * If the quantifier is some, the expression is True if the evaluation
+ of the predicate yields True for some value of the loop parameter.
+ It is False otherwise. Evaluation of the quantified_expression
+ stops when all values of the domain have been examined, or when the
+ predicate yields True for a given value. Any exception raised by
+ evaluation of the predicate is propagated.
+
+9.a/3
+ Ramification: The expression is False if the domain contains
+ no values.
+
+ _Examples_
+
+10/3
+{AI05-0176-1AI05-0176-1} The postcondition for a sorting routine on an
+array A with an index subtype T can be written:
+
+11/3
+ Post => (A'Length < 2 or else
+ (for all I in A'First .. T'Pred(A'Last) => A (I) <= A (T'Succ (I))))
+
+12/3
+{AI05-0176-1AI05-0176-1} The assertion that a positive number is
+composite (as opposed to prime) can be written:
+
+13/3
+ pragma Assert (for some X in 2 .. N / 2 => N mod X = 0);
+
+ _Extensions to Ada 2005_
+
+13.a/3
+ {AI05-0176-1AI05-0176-1} Quantified expressions are new.
+
+\1f
+File: aarm2012.info, Node: 4.6, Next: 4.7, Prev: 4.5, Up: 4
+
+4.6 Type Conversions
+====================
+
+1/3
+{AI05-0299-1AI05-0299-1} [Explicit type conversions, both value
+conversions and view conversions, are allowed between closely related
+types as defined below. This subclause also defines rules for value and
+view conversions to a particular subtype of a type, both explicit ones
+and those implicit in other constructs. ]
+
+ _Syntax_
+
+2
+ type_conversion ::=
+ subtype_mark(expression)
+ | subtype_mark(name)
+
+3
+The target subtype of a type_conversion is the subtype denoted by the
+subtype_mark. The operand of a type_conversion is the expression or
+name within the parentheses; its type is the operand type.
+
+4/3
+{AI05-0299-1AI05-0299-1} One type is convertible to a second type if a
+type_conversion with the first type as operand type and the second type
+as target type is legal according to the rules of this subclause. Two
+types are convertible if each is convertible to the other.
+
+4.a
+ Ramification: Note that "convertible" is defined in terms of
+ legality of the conversion. Whether the conversion would
+ raise an exception at run time is irrelevant to this
+ definition.
+
+5/2
+{8652/00178652/0017} {AI95-00184-01AI95-00184-01}
+{AI95-00330-01AI95-00330-01} A type_conversion whose operand is the name
+of an object is called a view conversion if both its target type and
+operand type are tagged, or if it appears in a call as an actual
+parameter of mode out or in out; other type_conversions are called value
+conversions.
+
+5.a
+ Ramification: A view conversion to a tagged type can appear in
+ any context that requires an object name, including in an
+ object renaming, the prefix of a selected_component, and if
+ the operand is a variable, on the left side of an
+ assignment_statement. View conversions to other types only
+ occur as actual parameters. Allowing view conversions of
+ untagged types in all contexts seemed to incur an undue
+ implementation burden.
+
+5.b/2
+ {AI95-00330-01AI95-00330-01} A type conversion appearing as an
+ in out parameter in a generic instantiation is not a view
+ conversion; the second part of the rule only applies to
+ subprogram calls, not instantiations.
+
+ _Name Resolution Rules_
+
+6
+The operand of a type_conversion is expected to be of any type.
+
+6.a
+ Discussion: This replaces the "must be determinable" wording
+ of Ada 83. This is equivalent to (but hopefully more
+ intuitive than) saying that the operand of a type_conversion
+ is a "complete context."
+
+7
+The operand of a view conversion is interpreted only as a name; the
+operand of a value conversion is interpreted as an expression.
+
+7.a
+ Reason: This formally resolves the syntactic ambiguity between
+ the two forms of type_conversion, not that it really matters.
+
+ _Legality Rules_
+
+8/2
+{AI95-00251-01AI95-00251-01} In a view conversion for an untagged type,
+the target type shall be convertible (back) to the operand type.
+
+8.a/2
+ Reason: Untagged view conversions appear only as [in] out
+ parameters. Hence, the reverse conversion must be legal as
+ well. The forward conversion must be legal even for an out
+ parameter, because (for example) actual parameters of an
+ access type are always copied in anyway.
+
+Paragraphs 9 through 20 were reorganized and moved below.
+
+8.b/2
+ Discussion: {AI95-00251-01AI95-00251-01} The entire Legality
+ Rules section has been reorganized to eliminate an
+ unintentional incompatibility with Ada 83. In rare cases, a
+ type conversion between two types related by derivation is not
+ allowed by Ada 95, while it is allowed in Ada 83. The
+ reorganization fixes this. Much of the wording of the
+ legality section is unchanged, but it is reordered and
+ reformatted. Because of the limitations of our tools, we had
+ to delete and replace nearly the entire section. The text of
+ Ada 95 paragraphs 8 through 12, 14, 15, 17, 19, 20, and 24 are
+ unchanged (just moved); these are now 24.1 through 24.5,
+ 24.12, 24.13, 24.17, 24.19, 24.20, and 8.
+
+21/3
+{AI95-00251-01AI95-00251-01} {AI05-0115-1AI05-0115-1} If there is a type
+(other than a root numeric type) that is an ancestor of both the target
+type and the operand type, or both types are class-wide types, then at
+least one of the following rules shall apply:
+
+21.1/2
+ * {AI95-00251-01AI95-00251-01} The target type shall be untagged; or
+
+22
+ * The operand type shall be covered by or descended from the target
+ type; or
+
+22.a
+ Ramification: This is a conversion toward the root, which is
+ always safe.
+
+23/2
+ * {AI95-00251-01AI95-00251-01} The operand type shall be a class-wide
+ type that covers the target type; or
+
+23.a
+ Ramification: This is a conversion of a class-wide type toward
+ the leaves, which requires a tag check. See Dynamic
+ Semantics.
+
+23.b/2
+ {AI95-00251-01AI95-00251-01} These two rules imply that a
+ conversion from an ancestor type to a type extension is not
+ permitted, as this would require specifying the values for
+ additional components, in general, and changing the tag. An
+ extension_aggregate has to be used instead, constructing a new
+ value, rather than converting an existing value. However, a
+ conversion from the class-wide type rooted at an ancestor type
+ is permitted; such a conversion just verifies that the
+ operand's tag is a descendant of the target.
+
+23.1/2
+ * {AI95-00251-01AI95-00251-01} The operand and target types shall
+ both be class-wide types and the specific type associated with at
+ least one of them shall be an interface type.
+
+23.c/2
+ Ramification: We allow converting any class-wide type T'Class
+ to or from a class-wide interface type even if the specific
+ type T does not have an appropriate interface ancestor,
+ because some extension of T might have the needed ancestor.
+ This is similar to a conversion of a class-wide type toward
+ the leaves of the tree, and we need to be consistent. Of
+ course, there is a run-time check that the actual object has
+ the needed interface.
+
+24/3
+{AI95-00251-01AI95-00251-01} {AI05-0115-1AI05-0115-1} If there is no
+type (other than a root numeric type) that is the ancestor of both the
+target type and the operand type, and they are not both class-wide
+types, one of the following rules shall apply:
+
+24.1/2
+ * {AI95-00251-01AI95-00251-01} If the target type is a numeric type,
+ then the operand type shall be a numeric type.
+
+24.2/2
+ * {AI95-00251-01AI95-00251-01} If the target type is an array type,
+ then the operand type shall be an array type. Further:
+
+24.3/2
+ * {AI95-00251-01AI95-00251-01} The types shall have the
+ same dimensionality;
+
+24.4/2
+ * {AI95-00251-01AI95-00251-01} Corresponding index types
+ shall be convertible;
+
+24.5/2
+ * {AI95-00251-01AI95-00251-01} The component subtypes shall
+ statically match;
+
+24.6/2
+ * {AI95-00392-01AI95-00392-01} If the component types are
+ anonymous access types, then the accessibility level of
+ the operand type shall not be statically deeper than that
+ of the target type;
+
+24.b/2
+ Reason: For unrelated array types, the component types could
+ have different accessibility, and we had better not allow a
+ conversion of a local type into a global type, in case the
+ local type points at local objects. We don't need a check for
+ other types of components; such components necessarily are for
+ related types, and either have the same accessibility or (for
+ access discriminants) cannot be changed so the discriminant
+ check will prevent problems.
+
+24.7/2
+ * {AI95-00246-01AI95-00246-01} Neither the target type nor
+ the operand type shall be limited;
+
+24.c/2
+ Reason: We cannot allow conversions between unrelated limited
+ types, as they may have different representations, and (since
+ the types are limited), a copy cannot be made to reconcile the
+ representations.
+
+24.8/2
+ * {AI95-00251-01AI95-00251-01} {AI95-00363-01AI95-00363-01}
+ If the target type of a view conversion has aliased
+ components, then so shall the operand type; and
+
+24.d/2
+ Reason: {AI95-00363-01AI95-00363-01} We cannot allow a view
+ conversion from an object with unaliased components to an
+ object with aliased components, because that would effectively
+ allow pointers to unaliased components. This rule was missing
+ from Ada 95.
+
+24.9/2
+ * {AI95-00246-01AI95-00246-01} {AI95-00251-01AI95-00251-01}
+ The operand type of a view conversion shall not have a
+ tagged, private, or volatile subcomponent.
+
+24.e/2
+ Reason: {AI95-00246-01AI95-00246-01} We cannot allow view
+ conversions between unrelated might-be-by-reference types, as
+ they may have different representations, and a copy cannot be
+ made to reconcile the representations.
+
+24.f/2
+ Ramification: These rules only apply to unrelated array
+ conversions; different (weaker) rules apply to conversions
+ between related types.
+
+24.10/2
+ * {AI95-00230-01AI95-00230-01} If the target type is
+ universal_access, then the operand type shall be an access type.
+
+24.g/2
+ Discussion: Such a conversion cannot be written explicitly, of
+ course, but it can be implicit (see below).
+
+24.11/2
+ * {AI95-00230-01AI95-00230-01} {AI95-00251-01AI95-00251-01} If the
+ target type is a general access-to-object type, then the operand
+ type shall be universal_access or an access-to-object type.
+ Further, if the operand type is not universal_access:
+
+24.h/2
+ Discussion: The Legality Rules and Dynamic Semantics are
+ worded so that a type_conversion T(X) (where T is an access
+ type) is (almost) equivalent to the attribute_reference
+ X.all'Access, where the result is of type T. The only
+ difference is that the type_conversion accepts a null value,
+ whereas the attribute_reference would raise Constraint_Error.
+
+24.12/2
+ * {AI95-00251-01AI95-00251-01} If the target type is an
+ access-to-variable type, then the operand type shall be
+ an access-to-variable type;
+
+24.i/2
+ Ramification: If the target type is an access-to-constant
+ type, then the operand type can be access-to-constant or
+ access-to-variable.
+
+24.13/2
+ * {AI95-00251-01AI95-00251-01} If the target designated
+ type is tagged, then the operand designated type shall be
+ convertible to the target designated type;
+
+24.14/2
+ * {AI95-00251-01AI95-00251-01} {AI95-00363-01AI95-00363-01}
+ If the target designated type is not tagged, then the
+ designated types shall be the same, and either:
+
+24.15/2
+ * {AI95-00363-01AI95-00363-01} the designated subtypes
+ shall statically match; or
+
+24.16/2
+ * {AI95-00363-01AI95-00363-01}
+ {AI95-00384-01AI95-00384-01} the designated type
+ shall be discriminated in its full view and
+ unconstrained in any partial view, and one of the
+ designated subtypes shall be unconstrained;
+
+24.j/2
+ Ramification: {AI95-00363-01AI95-00363-01} This does not
+ require that types have a partial view in order to allow the
+ conversion, simply that any partial view that does exist is
+ unconstrained.
+
+24.k/2
+ {AI95-00384-01AI95-00384-01} This allows conversions both ways
+ (either subtype can be unconstrained); while Ada 95 only
+ allowed the conversion if the target subtype is unconstrained.
+ We generally want type conversions to be symmetric; which type
+ is the target shouldn't matter for legality.
+
+24.l/2
+ Reason: {AI95-00363-01AI95-00363-01} If the visible partial
+ view is constrained, we do not allow conversion between
+ unconstrained and constrained subtypes. This means that
+ whether the full type had discriminants is not visible to
+ clients of the partial view.
+
+24.m/2
+ Reason: These rules are designed to ensure that aliased array
+ objects only need "dope" if their nominal subtype is
+ unconstrained, but they can always have dope if required by
+ the run-time model (since no sliding is permitted as part of
+ access type conversion). By contrast, aliased discriminated
+ objects will always need their discriminants stored with them,
+ even if nominally constrained. (Here, we are assuming an
+ implementation that represents an access value as a single
+ pointer.)
+
+24.17/3
+ * {AI95-00251-01AI95-00251-01} {AI05-0148-1AI05-0148-1}
+ {AI05-0248-1AI05-0248-1} The accessibility level of the
+ operand type shall not be statically deeper than that of
+ the target type, unless the target type is an anonymous
+ access type of a stand-alone object. If the target type
+ is that of such a stand-alone object, the accessibility
+ level of the operand type shall not be statically deeper
+ than that of the declaration of the stand-alone object.
+ In addition to the places where Legality Rules normally
+ apply (see *note 12.3::), this rule applies also in the
+ private part of an instance of a generic unit.
+
+24.n/3
+ Ramification: {AI05-0148-1AI05-0148-1} The access parameter
+ case is handled by a run-time check. Run-time checks are also
+ done in instance bodies, and for stand-alone objects of
+ anonymous access types.
+
+24.n.1/3
+ Reason: We prohibit storing accesses to objects deeper than a
+ stand-alone object of an anonymous access-to-object (even
+ while we allow storing all other accesses) in order to prevent
+ dangling accesses.
+
+24.18/2
+ * {AI95-00230-01AI95-00230-01} If the target type is a pool-specific
+ access-to-object type, then the operand type shall be
+ universal_access.
+
+24.o/2
+ Reason: This allows null to be converted to pool-specific
+ types. Without it, null could be converted to general access
+ types but not pool-specific ones, which would be too
+ inconsistent. Remember that these rules only apply to
+ unrelated types, so we don't have to talk about conversions to
+ derived or other related types.
+
+24.19/2
+ * {AI95-00230-01AI95-00230-01} {AI95-00251-01AI95-00251-01} If the
+ target type is an access-to-subprogram type, then the operand type
+ shall be universal_access or an access-to-subprogram type.
+ Further, if the operand type is not universal_access:
+
+24.20/3
+ * {AI95-00251-01AI95-00251-01} {AI05-0239-1AI05-0239-1} The
+ designated profiles shall be subtype conformant.
+
+24.21/2
+ * {AI95-00251-01AI95-00251-01} The accessibility level of
+ the operand type shall not be statically deeper than that
+ of the target type. In addition to the places where
+ Legality Rules normally apply (see *note 12.3::), this
+ rule applies also in the private part of an instance of a
+ generic unit. If the operand type is declared within a
+ generic body, the target type shall be declared within
+ the generic body.
+
+24.p/2
+ Reason: The reason it is illegal to convert from an
+ access-to-subprogram type declared in a generic body to one
+ declared outside that body is that in an implementation that
+ shares generic bodies, procedures declared inside the generic
+ need to have a different calling convention -- they need an
+ extra parameter pointing to the data declared in the current
+ instance. For procedures declared in the spec, that's OK,
+ because the compiler can know about them at compile time of
+ the instantiation.
+
+ _Static Semantics_
+
+25
+A type_conversion that is a value conversion denotes the value that is
+the result of converting the value of the operand to the target subtype.
+
+26/3
+{AI05-0264-1AI05-0264-1} A type_conversion that is a view conversion
+denotes a view of the object denoted by the operand. This view is a
+variable of the target type if the operand denotes a variable;
+otherwise, it is a constant of the target type.
+
+27
+The nominal subtype of a type_conversion is its target subtype.
+
+ _Dynamic Semantics_
+
+28
+For the evaluation of a type_conversion that is a value conversion, the
+operand is evaluated, and then the value of the operand is converted to
+a corresponding value of the target type, if any. If there is no value
+of the target type that corresponds to the operand value,
+Constraint_Error is raised[; this can only happen on conversion to a
+modular type, and only when the operand value is outside the base range
+of the modular type.] Additional rules follow:
+
+29
+ * Numeric Type Conversion
+
+30
+ * If the target and the operand types are both integer
+ types, then the result is the value of the target type
+ that corresponds to the same mathematical integer as the
+ operand.
+
+31
+ * If the target type is a decimal fixed point type, then
+ the result is truncated (toward 0) if the value of the
+ operand is not a multiple of the small of the target
+ type.
+
+32
+ * If the target type is some other real type, then the
+ result is within the accuracy of the target type (see
+ *note G.2::, "*note G.2:: Numeric Performance
+ Requirements", for implementations that support the
+ Numerics Annex).
+
+32.a
+ Discussion: An integer type might have more bits of precision
+ than a real type, so on conversion (of a large integer), some
+ precision might be lost.
+
+33
+ * If the target type is an integer type and the operand
+ type is real, the result is rounded to the nearest
+ integer (away from zero if exactly halfway between two
+ integers).
+
+33.a/2
+ Discussion: {AI95-00267-01AI95-00267-01} This was
+ implementation defined in Ada 83. There seems no reason to
+ preserve the nonportability in Ada 95. Round-away-from-zero
+ is the conventional definition of rounding, and standard
+ Fortran and COBOL both specify rounding away from zero, so for
+ interoperability, it seems important to pick this. This is
+ also the most easily "undone" by hand. Round-to-nearest-even
+ is an alternative, but that is quite complicated if not
+ supported by the hardware. In any case, this operation is not
+ usually part of an inner loop, so predictability and
+ portability are judged most important. A floating point
+ attribute function Unbiased_Rounding is provided (see *note
+ A.5.3::) for those applications that require
+ round-to-nearest-even, and a floating point attribute function
+ Machine_Rounding (also see *note A.5.3::) is provided for
+ those applications that require the highest possible
+ performance. "Deterministic" rounding is required for static
+ conversions to integer as well. See *note 4.9::.
+
+34
+ * Enumeration Type Conversion
+
+35
+ * The result is the value of the target type with the same
+ position number as that of the operand value.
+
+36
+ * Array Type Conversion
+
+37
+ * If the target subtype is a constrained array subtype,
+ then a check is made that the length of each dimension of
+ the value of the operand equals the length of the
+ corresponding dimension of the target subtype. The
+ bounds of the result are those of the target subtype.
+
+38
+ * If the target subtype is an unconstrained array subtype,
+ then the bounds of the result are obtained by converting
+ each bound of the value of the operand to the
+ corresponding index type of the target type. For each
+ nonnull index range, a check is made that the bounds of
+ the range belong to the corresponding index subtype.
+
+38.a
+ Discussion: Only nonnull index ranges are checked, per
+ AI83-00313.
+
+39
+ * In either array case, the value of each component of the
+ result is that of the matching component of the operand
+ value (see *note 4.5.2::).
+
+39.a
+ Ramification: This applies whether or not the component is
+ initialized.
+
+39.1/2
+ * {AI95-00392-01AI95-00392-01} If the component types of
+ the array types are anonymous access types, then a check
+ is made that the accessibility level of the operand type
+ is not deeper than that of the target type.
+
+39.b/2
+ Reason: This check is needed for operands that are access
+ parameters and in instance bodies. Other cases are handled by
+ the legality rule given previously.
+
+40
+ * Composite (Non-Array) Type Conversion
+
+41
+ * The value of each nondiscriminant component of the result
+ is that of the matching component of the operand value.
+
+41.a
+ Ramification: This applies whether or not the component is
+ initialized.
+
+42
+ * [The tag of the result is that of the operand.] If the
+ operand type is class-wide, a check is made that the tag
+ of the operand identifies a (specific) type that is
+ covered by or descended from the target type.
+
+42.a
+ Ramification: This check is certain to succeed if the operand
+ type is itself covered by or descended from the target type.
+
+42.b
+ Proof: The fact that a type_conversion preserves the tag is
+ stated officially in *note 3.9::, "*note 3.9:: Tagged Types
+ and Type Extensions"
+
+43
+ * For each discriminant of the target type that corresponds
+ to a discriminant of the operand type, its value is that
+ of the corresponding discriminant of the operand value;
+ if it corresponds to more than one discriminant of the
+ operand type, a check is made that all these
+ discriminants are equal in the operand value.
+
+44
+ * For each discriminant of the target type that corresponds
+ to a discriminant that is specified by the
+ derived_type_definition for some ancestor of the operand
+ type (or if class-wide, some ancestor of the specific
+ type identified by the tag of the operand), its value in
+ the result is that specified by the
+ derived_type_definition.
+
+44.a
+ Ramification: It is a ramification of the rules for the
+ discriminants of derived types that each discriminant of the
+ result is covered either by this paragraph or the previous
+ one. See *note 3.7::.
+
+45
+ * For each discriminant of the operand type that
+ corresponds to a discriminant that is specified by the
+ derived_type_definition for some ancestor of the target
+ type, a check is made that in the operand value it equals
+ the value specified for it.
+
+46
+ * For each discriminant of the result, a check is made that
+ its value belongs to its subtype.
+
+47
+ * Access Type Conversion
+
+48/3
+ * {AI05-0148-1AI05-0148-1} {AI05-0248-1AI05-0248-1} For an
+ access-to-object type, a check is made that the
+ accessibility level of the operand type is not deeper
+ than that of the target type, unless the target type is
+ an anonymous access type of a stand-alone object. If the
+ target type is that of such a stand-alone object, a check
+ is made that the accessibility level of the operand type
+ is not deeper than that of the declaration of the
+ stand-alone object[; then if the check succeeds, the
+ accessibility level of the target type becomes that of
+ the operand type].
+
+48.a/3
+ Ramification: {AI05-0148-1AI05-0148-1} This check is needed
+ for operands that are access parameters, for stand-alone
+ anonymous access objects, and in instance bodies.
+
+48.b
+ Note that this check can never fail for the implicit
+ conversion to the anonymous type of an access parameter that
+ is done when calling a subprogram with an access parameter.
+
+49/2
+ * {AI95-00230-01AI95-00230-01} {AI95-00231-01AI95-00231-01}
+ If the operand value is null, the result of the
+ conversion is the null value of the target type.
+
+49.a/2
+ Ramification: A conversion to an anonymous access type happens
+ implicitly as part of initializing or assigning to an
+ anonymous access object.
+
+50
+ * If the operand value is not null, then the result
+ designates the same object (or subprogram) as is
+ designated by the operand value, but viewed as being of
+ the target designated subtype (or profile); any checks
+ associated with evaluating a conversion to the target
+ designated subtype are performed.
+
+50.a
+ Ramification: The checks are certain to succeed if the target
+ and operand designated subtypes statically match.
+
+51/3
+{AI95-00231-01AI95-00231-01} {AI05-0153-3AI05-0153-3}
+{AI05-0290-1AI05-0290-1} After conversion of the value to the target
+type, if the target subtype is constrained, a check is performed that
+the value satisfies this constraint. If the target subtype excludes
+null, then a check is made that the value is not null. If predicate
+checks are enabled for the target subtype (see *note 3.2.4::), a check
+is performed that the predicate of the target subtype is satisfied for
+the value.
+
+51.a/2
+ Ramification: {AI95-00231-01AI95-00231-01} The first check
+ above is a Range_Check for scalar subtypes, a
+ Discriminant_Check or Index_Check for access subtypes, and a
+ Discriminant_Check for discriminated subtypes. The
+ Length_Check for an array conversion is performed as part of
+ the conversion to the target type. The check for exclusion of
+ null is an Access_Check.
+
+52
+For the evaluation of a view conversion, the operand name is evaluated,
+and a new view of the object denoted by the operand is created, whose
+type is the target type; if the target type is composite, checks are
+performed as above for a value conversion.
+
+53
+The properties of this new view are as follows:
+
+54/1
+ * {8652/00178652/0017} {AI95-00184-01AI95-00184-01} If the target
+ type is composite, the bounds or discriminants (if any) of the view
+ are as defined above for a value conversion; each nondiscriminant
+ component of the view denotes the matching component of the operand
+ object; the subtype of the view is constrained if either the target
+ subtype or the operand object is constrained, or if the target
+ subtype is indefinite, or if the operand type is a descendant of
+ the target type and has discriminants that were not inherited from
+ the target type;
+
+55
+ * If the target type is tagged, then an assignment to the view
+ assigns to the corresponding part of the object denoted by the
+ operand; otherwise, an assignment to the view assigns to the
+ object, after converting the assigned value to the subtype of the
+ object (which might raise Constraint_Error);
+
+56
+ * Reading the value of the view yields the result of converting the
+ value of the operand object to the target subtype (which might
+ raise Constraint_Error), except if the object is of an access type
+ and the view conversion is passed as an out parameter; in this
+ latter case, the value of the operand object is used to initialize
+ the formal parameter without checking against any constraint of the
+ target subtype (see *note 6.4.1::).
+
+56.a
+ Reason: This ensures that even an out parameter of an access
+ type is initialized reasonably.
+
+57/3
+{AI05-0290-1AI05-0290-1} If an Accessibility_Check fails, Program_Error
+is raised. If a predicate check fails, Assertions.Assertion_Error is
+raised. Any other check associated with a conversion raises
+Constraint_Error if it fails.
+
+58
+Conversion to a type is the same as conversion to an unconstrained
+subtype of the type.
+
+58.a
+ Reason: This definition is needed because the semantics of
+ various constructs involves converting to a type, whereas an
+ explicit type_conversion actually converts to a subtype. For
+ example, the evaluation of a range is defined to convert the
+ values of the expressions to the type of the range.
+
+58.b
+ Ramification: A conversion to a scalar type, or, equivalently,
+ to an unconstrained scalar subtype, can raise Constraint_Error
+ if the value is outside the base range of the type.
+
+ NOTES
+
+59
+ 19 In addition to explicit type_conversions, type conversions are
+ performed implicitly in situations where the expected type and the
+ actual type of a construct differ, as is permitted by the type
+ resolution rules (see *note 8.6::). For example, an integer
+ literal is of the type universal_integer, and is implicitly
+ converted when assigned to a target of some specific integer type.
+ Similarly, an actual parameter of a specific tagged type is
+ implicitly converted when the corresponding formal parameter is of
+ a class-wide type.
+
+60
+ Even when the expected and actual types are the same, implicit
+ subtype conversions are performed to adjust the array bounds (if
+ any) of an operand to match the desired target subtype, or to raise
+ Constraint_Error if the (possibly adjusted) value does not satisfy
+ the constraints of the target subtype.
+
+61/2
+ 20 {AI95-00230-01AI95-00230-01} A ramification of the overload
+ resolution rules is that the operand of an (explicit)
+ type_conversion cannot be an allocator, an aggregate, a
+ string_literal, a character_literal, or an attribute_reference for
+ an Access or Unchecked_Access attribute. Similarly, such an
+ expression enclosed by parentheses is not allowed. A
+ qualified_expression (see *note 4.7::) can be used instead of such
+ a type_conversion.
+
+62
+ 21 The constraint of the target subtype has no effect for a
+ type_conversion of an elementary type passed as an out parameter.
+ Hence, it is recommended that the first subtype be specified as the
+ target to minimize confusion (a similar recommendation applies to
+ renaming and generic formal in out objects).
+
+ _Examples_
+
+63
+Examples of numeric type conversion:
+
+64
+ Real(2*J) -- value is converted to floating point
+ Integer(1.6) -- value is 2
+ Integer(-0.4) -- value is 0
+
+65
+Example of conversion between derived types:
+
+66
+ type A_Form is new B_Form;
+
+67
+ X : A_Form;
+ Y : B_Form;
+
+68
+ X := A_Form(Y);
+ Y := B_Form(X); -- the reverse conversion
+
+69
+Examples of conversions between array types:
+
+70
+ type Sequence is array (Integer range <>) of Integer;
+ subtype Dozen is Sequence(1 .. 12);
+ Ledger : array(1 .. 100) of Integer;
+
+71
+ Sequence(Ledger) -- bounds are those of Ledger
+ Sequence(Ledger(31 .. 42)) -- bounds are 31 and 42
+ Dozen(Ledger(31 .. 42)) -- bounds are those of Dozen
+
+ _Incompatibilities With Ada 83_
+
+71.a
+ A character_literal is not allowed as the operand of a
+ type_conversion, since there are now two character types in
+ package Standard.
+
+71.b
+ The component subtypes have to statically match in an array
+ conversion, rather than being checked for matching constraints
+ at run time.
+
+71.c
+ Because sliding of array bounds is now provided for operations
+ where it was not in Ada 83, programs that used to raise
+ Constraint_Error might now continue executing and produce a
+ reasonable result. This is likely to fix more bugs than it
+ creates.
+
+ _Extensions to Ada 83_
+
+71.d
+ A type_conversion is considered the name of an object in
+ certain circumstances (such a type_conversion is called a view
+ conversion). In particular, as in Ada 83, a type_conversion
+ can appear as an in out or out actual parameter. In addition,
+ if the target type is tagged and the operand is the name of an
+ object, then so is the type_conversion, and it can be used as
+ the prefix to a selected_component, in an
+ object_renaming_declaration, etc.
+
+71.e
+ We no longer require type-mark conformance between a parameter
+ of the form of a type conversion, and the corresponding formal
+ parameter. This had caused some problems for inherited
+ subprograms (since there isn't really a type-mark for
+ converted formals), as well as for renamings, formal
+ subprograms, etc. See AI83-00245, AI83-00318, AI83-00547.
+
+71.f
+ We now specify "deterministic" rounding from real to integer
+ types when the value of the operand is exactly between two
+ integers (rounding is away from zero in this case).
+
+71.g
+ "Sliding" of array bounds (which is part of conversion to an
+ array subtype) is performed in more cases in Ada 95 than in
+ Ada 83. Sliding is not performed on the operand of a
+ membership test, nor on the operand of a qualified_expression.
+ It wouldn't make sense on a membership test, and we wish to
+ retain a connection between subtype membership and subtype
+ qualification. In general, a subtype membership test returns
+ True if and only if a corresponding subtype qualification
+ succeeds without raising an exception. Other operations that
+ take arrays perform sliding.
+
+ _Wording Changes from Ada 83_
+
+71.h
+ We no longer explicitly list the kinds of things that are not
+ allowed as the operand of a type_conversion, except in a NOTE.
+
+71.i/3
+ {AI05-0299-1AI05-0299-1} The rules in this subclause subsume
+ the rules for "parameters of the form of a type conversion,"
+ and have been generalized to cover the use of a type
+ conversion as a name.
+
+ _Incompatibilities With Ada 95_
+
+71.j/2
+ {AI95-00246-01AI95-00246-01} Amendment Correction: Conversions
+ between unrelated array types that are limited or (for view
+ conversions) might be by-reference types are now illegal. The
+ representations of two such arrays may differ, making the
+ conversions impossible. We make the check here, because
+ legality should not be based on representation properties.
+ Such conversions are likely to be rare, anyway. There is a
+ potential that this change would make a working program
+ illegal (if the types have the same representation).
+
+71.k/2
+ {AI95-00363-01AI95-00363-01} If a discriminated full type has
+ a partial view (private type) that is constrained, we do not
+ allow conversion between access-to-unconstrained and
+ access-to-constrained subtypes designating the type. Ada 95
+ allowed this conversion and the declaration of various access
+ subtypes, requiring that the designated object be constrained
+ and thus making details of the implementation of the private
+ type visible to the client of the private type. See *note
+ 4.8:: for more on this topic.
+
+ _Extensions to Ada 95_
+
+71.l/2
+ {AI95-00230-01AI95-00230-01} Conversion rules for
+ universal_access were defined. These allow the use of
+ anonymous access values in equality tests (see *note 4.5.2::),
+ and also allow the use of null in type conversions and other
+ contexts that do not provide a single expected type.
+
+71.m/2
+ {AI95-00384-01AI95-00384-01} A type conversion from an
+ access-to-discriminated and unconstrained object to an
+ access-to-discriminated and constrained one is allowed. Ada
+ 95 only allowed the reverse conversion, which was weird and
+ asymmetric. Of course, a constraint check will be performed
+ for this conversion.
+
+ _Wording Changes from Ada 95_
+
+71.n/2
+ {8652/00178652/0017} {AI95-00184-01AI95-00184-01} Corrigendum:
+ Wording was added to ensure that view conversions are
+ constrained, and that a tagged view conversion has a tagged
+ object. Both rules are needed to avoid having a way to change
+ the discriminants of a constrained object.
+
+71.o/2
+ {8652/00088652/0008} {AI95-00168-01AI95-00168-01} Corrigendum:
+ Wording was added to ensure that the aliased status of array
+ components cannot change in a view conversion. This rule was
+ needed to avoid having a way to change the discriminants of an
+ aliased object. This rule was repealed later, as Ada 2005
+ allows changing the discriminants of an aliased object.
+
+71.p/2
+ {AI95-00231-01AI95-00231-01} Wording was added to check
+ subtypes that exclude null (see *note 3.10::).
+
+71.q/2
+ {AI95-00251-01AI95-00251-01} The organization of the legality
+ rules was changed, both to make it clearer, and to eliminate
+ an unintentional incompatibility with Ada 83. The old
+ organization prevented type conversions between some types
+ that were related by derivation (which Ada 83 always allowed).
+
+71.r/3
+ {AI95-00330-01AI95-00330-01} {AI05-0005-1AI05-0005-1}
+ Clarified that an untagged type conversion appearing as a
+ generic actual parameter for a generic in out formal parameter
+ is not a view conversion (and thus is illegal). This confirms
+ the ACATS tests, so all implementations already follow this
+ interpretation.
+
+71.s/2
+ {AI95-00363-01AI95-00363-01} Rules added by the Corrigendum to
+ eliminate problems with discriminants of aliased components
+ changing were removed, as we now generally allow discriminants
+ of aliased components to be changed.
+
+71.t/2
+ {AI95-00392-01AI95-00392-01} Accessibility checks on
+ conversions involving types with anonymous access components
+ were added. These components have the level of the type, and
+ conversions can be between types at different levels, which
+ could cause dangling access values in the absence of such
+ checks.
+
+ _Inconsistencies With Ada 2005_
+
+71.u/3
+ {AI05-0148-1AI05-0148-1} A stand-alone object of an anonymous
+ access-to-object type now has dynamic accessibility.
+ Normally, this will make programs legal that were illegal in
+ Ada 2005. However, it is possible that a program that
+ previously raised Program_Error now will not. It is very
+ unlikely that an existing program intentionally depends on the
+ exception being raised; the change is more likely to fix bugs
+ than introduce them.
+
+ _Wording Changes from Ada 2005_
+
+71.v/3
+ {AI05-0115-1AI05-0115-1} Correction: Clarified that a root
+ numeric type is not considered a common ancestor for a
+ conversion.
+
+71.w/3
+ {AI05-0153-3AI05-0153-3} {AI05-0290-1AI05-0290-1} Added rules
+ so that predicate aspects (see *note 3.2.4::) are enforced on
+ subtype conversion.
+
+\1f
+File: aarm2012.info, Node: 4.7, Next: 4.8, Prev: 4.6, Up: 4
+
+4.7 Qualified Expressions
+=========================
+
+1
+[A qualified_expression is used to state explicitly the type, and to
+verify the subtype, of an operand that is either an expression or an
+aggregate. ]
+
+ _Syntax_
+
+2
+ qualified_expression ::=
+ subtype_mark'(expression) | subtype_mark'aggregate
+
+ _Name Resolution Rules_
+
+3
+The operand (the expression or aggregate) shall resolve to be of the
+type determined by the subtype_mark (*note 3.2.2: S0028.), or a
+universal type that covers it.
+
+ _Static Semantics_
+
+3.1/3
+{AI05-0003-1AI05-0003-1} [If the operand of a qualified_expression
+denotes an object, the qualified_expression denotes a constant view of
+that object.] The nominal subtype of a qualified_expression is the
+subtype denoted by the subtype_mark.
+
+3.a/3
+ Proof: {AI05-0003-1AI05-0003-1} This is stated in *note 3.3::.
+
+ _Dynamic Semantics_
+
+4
+The evaluation of a qualified_expression evaluates the operand (and if
+of a universal type, converts it to the type determined by the
+subtype_mark) and checks that its value belongs to the subtype denoted
+by the subtype_mark. The exception Constraint_Error is raised if this
+check fails.
+
+4.a
+ Ramification: This is one of the few contexts in Ada 95 where
+ implicit subtype conversion is not performed prior to a
+ constraint check, and hence no "sliding" of array bounds is
+ provided.
+
+4.b
+ Reason: Implicit subtype conversion is not provided because a
+ qualified_expression with a constrained target subtype is
+ essentially an assertion about the subtype of the operand,
+ rather than a request for conversion. An explicit
+ type_conversion can be used rather than a qualified_expression
+ if subtype conversion is desired.
+
+ NOTES
+
+5
+ 22 When a given context does not uniquely identify an expected
+ type, a qualified_expression can be used to do so. In particular,
+ if an overloaded name or aggregate is passed to an overloaded
+ subprogram, it might be necessary to qualify the operand to resolve
+ its type.
+
+ _Examples_
+
+6
+Examples of disambiguating expressions using qualification:
+
+7
+ type Mask is (Fix, Dec, Exp, Signif);
+ type Code is (Fix, Cla, Dec, Tnz, Sub);
+
+8
+ Print (Mask'(Dec)); -- Dec is of type Mask
+ Print (Code'(Dec)); -- Dec is of type Code
+
+9
+ for J in Code'(Fix) .. Code'(Dec) loop ... -- qualification needed for either Fix or Dec
+ for J in Code range Fix .. Dec loop ... -- qualification unnecessary
+ for J in Code'(Fix) .. Dec loop ... -- qualification unnecessary for Dec
+
+10
+ Dozen'(1 | 3 | 5 | 7 => 2, others => 0) -- see *note 4.6::
+
+ _Wording Changes from Ada 2005_
+
+10.a/3
+ {AI05-0003-1AI05-0003-1} Added a definition of the nominal
+ subtype of a qualified_expression.
+
+\1f
+File: aarm2012.info, Node: 4.8, Next: 4.9, Prev: 4.7, Up: 4
+
+4.8 Allocators
+==============
+
+1
+[The evaluation of an allocator creates an object and yields an access
+value that designates the object. ]
+
+ _Syntax_
+
+2/3
+ {AI05-0111-3AI05-0111-3} allocator ::=
+ new [subpool_specification] subtype_indication
+ | new [subpool_specification] qualified_expression
+
+2.1/3
+ {AI05-0111-3AI05-0111-3} subpool_specification ::= (subpool_handle_
+ name)
+
+2.2/3
+ {AI05-0104-1AI05-0104-1} For an allocator with a
+ subtype_indication, the subtype_indication shall not specify a
+ null_exclusion.
+
+2.a/3
+ Reason: Such an uninitialized allocator would necessarily
+ raise Constraint_Error, as the default value is null. Also
+ note that the syntax does not allow a null_exclusion in an
+ initialized allocator, so it makes sense to make the
+ uninitialized case illegal as well.
+
+ _Name Resolution Rules_
+
+3/3
+{8652/00108652/0010} {AI95-00127-01AI95-00127-01}
+{AI05-0111-3AI05-0111-3} {AI05-0269-1AI05-0269-1} The expected type for
+an allocator shall be a single access-to-object type with designated
+type D such that either D covers the type determined by the subtype_mark
+of the subtype_indication (*note 3.2.2: S0027.) or qualified_expression
+(*note 4.7: S0142.), or the expected type is anonymous and the
+determined type is D'Class. A subpool_handle_name is expected to be of
+any type descended from Subpool_Handle, which is the type used to
+identify a subpool, declared in package System.Storage_Pools.Subpools
+(see *note 13.11.4::).
+
+3.a
+ Discussion: See *note 8.6::, "*note 8.6:: The Context of
+ Overload Resolution" for the meaning of "shall be a single ...
+ type whose ..."
+
+3.a.1/1
+ Ramification: {8652/00108652/0010}
+ {AI95-00127-01AI95-00127-01} An allocator is allowed as a
+ controlling parameter of a dispatching call (see *note
+ 3.9.2::).
+
+ _Legality Rules_
+
+4
+An initialized allocator is an allocator with a qualified_expression.
+An uninitialized allocator is one with a subtype_indication. In the
+subtype_indication of an uninitialized allocator, a constraint is
+permitted only if the subtype_mark denotes an [unconstrained] composite
+subtype; if there is no constraint, then the subtype_mark shall denote a
+definite subtype.
+
+4.a
+ Ramification: For example, ... new S'Class ... (with no
+ initialization expression) is illegal, but ... new
+ S'Class'(X) ... is legal, and takes its tag and constraints
+ from the initial value X. (Note that the former case cannot
+ have a constraint.)
+
+5/2
+{AI95-00287-01AI95-00287-01} If the type of the allocator is an
+access-to-constant type, the allocator shall be an initialized
+allocator.
+
+5.a/2
+ This paragraph was deleted.{AI95-00287-01AI95-00287-01}
+
+5.1/3
+{AI05-0111-3AI05-0111-3} If a subpool_specification is given, the type
+of the storage pool of the access type shall be a descendant of
+Root_Storage_Pool_With_Subpools.
+
+5.2/3
+{AI95-00344-01AI95-00344-01} If the designated type of the type of the
+allocator is class-wide, the accessibility level of the type determined
+by the subtype_indication or qualified_expression shall not be
+statically deeper than that of the type of the allocator.
+
+5.b/2
+ Reason: This prevents the allocated object from outliving its
+ type.
+
+5.3/3
+{AI95-00416-01AI95-00416-01} {AI05-0051-1AI05-0051-1} If the subtype
+determined by the subtype_indication or qualified_expression of the
+allocator has one or more access discriminants, then the accessibility
+level of the anonymous access type of each access discriminant shall not
+be statically deeper than that of the type of the allocator (see *note
+3.10.2::).
+
+5.c/2
+ Reason: This prevents the allocated object from outliving its
+ discriminants.
+
+5.4/3
+{AI95-00366-01AI95-00366-01} {AI05-0052-1AI05-0052-1}
+{AI05-0157-1AI05-0157-1} An allocator shall not be of an access type for
+which the Storage_Size has been specified by a static expression with
+value zero or is defined by the language to be zero.
+
+5.d/2
+ Reason: An allocator for an access type that has Storage_Size
+ specified to be zero is required to raise Storage_Error
+ anyway. It's better to detect the error at compile-time, as
+ the allocator might be executed infrequently. This also
+ simplifies the rules for Pure units, where we do not want to
+ allow any allocators for library-level access types, as they
+ would represent state.
+
+5.e/3
+ {AI05-0157-1AI05-0157-1} We don't need a special rule to cover
+ generic formals (unlike many other similar Legality Rules).
+ There are only two cases of interest. For formal access
+ types, the Storage_Size property is not known in the generic,
+ and surely isn't static, so this Legality Rule can never
+ apply. For a formal derived type, this Legality Rule can only
+ be triggered by a parent type having one of the appropriate
+ properties. But Storage_Size can never be specified for a
+ derived access type, so it always has the same value for all
+ child types; additionally, a type derived from a remote access
+ type (which has Storage_Size defined to be zero) is also a
+ remote access type. That means that any actual that would
+ match the formal derived type necessarily has the same
+ Storage_Size properties, so it is harmless (and preferable) to
+ check them in the body - they are always known in that case.
+ For other formal types,allocators are not allowed, so we don't
+ need to consider them. So we don't need an assume-the-best
+ rule here.
+
+5.5/3
+{AI05-0052-1AI05-0052-1} If the designated type of the type of the
+allocator is limited, then the allocator shall not be used to define the
+value of an access discriminant, unless the discriminated type is
+immutably limited (see *note 7.5::).
+
+5.f/3
+ Reason: Because coextensions work very much like parts, we
+ don't want users creating limited coextensions for nonlimited
+ types. This would be similar to extending a nonlimited type
+ with a limited component. We check this on the allocator.
+ Note that there is an asymmetry in what types are considered
+ limited; this is required to preserve privacy. We have to
+ assume that the designated type might be limited as soon as we
+ see a limited partial view, but we want to ensure that the
+ containing object is of a type that is always limited.
+
+5.6/3
+{AI05-0052-1AI05-0052-1} In addition to the places where Legality Rules
+normally apply (see *note 12.3::), these rules apply also in the private
+part of an instance of a generic unit.
+
+5.g/3
+ Discussion: This applies to all of the Legality Rules of this
+ subclause.
+
+ _Static Semantics_
+
+6/3
+{AI95-00363-01AI95-00363-01} {AI05-0041-1AI05-0041-1} If the designated
+type of the type of the allocator is elementary, then the subtype of the
+created object is the designated subtype. If the designated type is
+composite, then the subtype of the created object is the designated
+subtype when the designated subtype is constrained or there is an
+ancestor of the designated type that has a constrained partial view;
+otherwise, the created object is constrained by its initial value [(even
+if the designated subtype is unconstrained with defaults)].
+
+6.a
+ Discussion: See AI83-00331.
+
+6.b/2
+ Reason: {AI95-00363-01AI95-00363-01} All objects created by an
+ allocator are aliased, and most aliased composite objects need
+ to be constrained so that access subtypes work reasonably.
+ Problematic access subtypes are prohibited for types with a
+ constrained partial view.
+
+6.c/2
+ Discussion: {AI95-00363-01AI95-00363-01} If there is a
+ constrained partial view of the type, this allows the objects
+ to be unconstrained. This eliminates privacy breaking (we
+ don't want the objects to act differently simply because
+ they're allocated). Such a created object is effectively
+ constrained by its initial value if the access type is an
+ access-to-constant type, or the designated type is limited (in
+ all views), but we don't need to state that here. It is
+ implicit in other rules. Note, however, that a value of an
+ access-to-constant type can designate a variable object via
+ 'Access or conversion, and the variable object might be
+ assigned by some other access path, and that assignment might
+ alter the discriminants.
+
+ _Dynamic Semantics_
+
+7/2
+{AI95-00373-01AI95-00373-01} For the evaluation of an initialized
+allocator, the evaluation of the qualified_expression is performed
+first. An object of the designated type is created and the value of the
+qualified_expression is converted to the designated subtype and assigned
+to the object.
+
+7.a
+ Ramification: The conversion might raise Constraint_Error.
+
+8
+For the evaluation of an uninitialized allocator, the elaboration of the
+subtype_indication is performed first. Then:
+
+9/2
+ * {AI95-00373-01AI95-00373-01} If the designated type is elementary,
+ an object of the designated subtype is created and any implicit
+ initial value is assigned;
+
+10/2
+ * {8652/00028652/0002} {AI95-00171-01AI95-00171-01}
+ {AI95-00373-01AI95-00373-01} If the designated type is composite,
+ an object of the designated type is created with tag, if any,
+ determined by the subtype_mark of the subtype_indication. This
+ object is then initialized by default (see *note 3.3.1::) using the
+ subtype_indication to determine its nominal subtype. A check is
+ made that the value of the object belongs to the designated
+ subtype. Constraint_Error is raised if this check fails. This
+ check and the initialization of the object are performed in an
+ arbitrary order.
+
+10.a
+ Discussion: AI83-00150.
+
+10.1/3
+{AI95-00344-01AI95-00344-01} {AI95-00416-01AI95-00416-01}
+{AI05-0024-1AI05-0024-1} {AI05-0051-1AI05-0051-1}
+{AI05-0234-1AI05-0234-1} For any allocator, if the designated type of
+the type of the allocator is class-wide, then a check is made that the
+master of the type determined by the subtype_indication, or by the tag
+of the value of the qualified_expression, includes the elaboration of
+the type of the allocator. If any part of the subtype determined by the
+subtype_indication or qualified_expression of the allocator (or by the
+tag of the value if the type of the qualified_expression is class-wide)
+has one or more access discriminants, then a check is made that the
+accessibility level of the anonymous access type of each access
+discriminant is not deeper than that of the type of the allocator.
+Program_Error is raised if either such check fails.
+
+10.b/3
+ Reason: {AI95-00344-01AI95-00344-01} {AI05-0024-1AI05-0024-1}
+ The master check on class-wide types prevents the allocated
+ object from outliving its type. We need the run-time check in
+ instance bodies, or when the type of the qualified_expression
+ is class-wide (other cases are statically detected).
+
+10.b.1/3
+ {AI05-0024-1AI05-0024-1} We can't use the normal accessibility
+ level "deeper than" check here because we may have
+ "incomparable" levels if the appropriate master and the type
+ declaration belong to two different tasks. This can happen
+ when checking the master of the tag for an allocator
+ initialized by a parameter passed in to an accept statement,
+ if the type of the allocator is an access type declared in the
+ enclosing task body. For example:
+
+10.b.2/3
+ task body TT is
+ type Acc_TC is access T'Class;
+ P : Acc_TC;
+ begin
+ accept E(X : T'Class) do
+ P := new T'Class'(X);
+ -- Master check on tag of X.
+ -- Can't use "accessibility levels" since they might be incomparable.
+ -- Must revert to checking that the master of the type identified by
+ -- X'tag includes the elaboration of Acc_TC, so it is sure to outlive it.
+ end E;
+
+10.c/2
+ {AI95-00416-01AI95-00416-01} The accessibility check on access
+ discriminants prevents the allocated object from outliving its
+ discriminants.
+
+10.2/2
+{AI95-00280-01AI95-00280-01} If the object to be created by an allocator
+has a controlled or protected part, and the finalization of the
+collection of the type of the allocator (see *note 7.6.1::) has started,
+Program_Error is raised.
+
+10.d/2
+ Reason: If the object has a controlled or protected part, its
+ finalization is likely to be nontrivial. If the allocation
+ was allowed, we could not know whether the finalization would
+ actually be performed. That would be dangerous to otherwise
+ safe abstractions, so we mandate a check here. On the other
+ hand, if the finalization of the object will be trivial, we do
+ not require (but allow) the check, as no real harm could come
+ from late allocation.
+
+10.e/2
+ Discussion: This check can only fail if an allocator is
+ evaluated in code reached from a Finalize routine for a type
+ declared in the same master. That's highly unlikely; Finalize
+ routines are much more likely to be deallocating objects than
+ allocating them.
+
+10.3/2
+{AI95-00280-01AI95-00280-01} If the object to be created by an allocator
+contains any tasks, and the master of the type of the allocator is
+completed, and all of the dependent tasks of the master are terminated
+(see *note 9.3::), then Program_Error is raised.
+
+10.f/2
+ Reason: A task created after waiting for tasks has finished
+ could depend on freed data structures, and certainly would
+ never be awaited.
+
+10.4/3
+{AI05-0111-3AI05-0111-3} If the allocator includes a
+subpool_handle_name, Constraint_Error is raised if the subpool handle is
+null. Program_Error is raised if the subpool does not belong (see *note
+13.11.4::) to the storage pool of the access type of the allocator.
+
+10.g/3
+ Implementation Note: This can be implemented by comparing the
+ result of Pool_of_Subpool to a reference to the storage pool
+ object. Pool_of_Subpool's parameter is not null, so the check
+ for null falls out naturally.
+
+10.h/3
+ Reason: This detects cases where the subpool belongs to
+ another pool, or to no pool at all. This includes detecting
+ dangling subpool handles so long as the subpool object (the
+ object designated by the handle) still exists. (If the
+ subpool object has been deallocated, execution is erroneous;
+ it is likely that this check will still detect the problem,
+ but there cannot be a guarantee.)
+
+11
+[If the created object contains any tasks, they are activated (see *note
+9.2::).] Finally, an access value that designates the created object is
+returned.
+
+ _Bounded (Run-Time) Errors_
+
+11.1/2
+{AI95-00280-01AI95-00280-01} It is a bounded error if the finalization
+of the collection of the type (see *note 7.6.1::) of the allocator has
+started. If the error is detected, Program_Error is raised. Otherwise,
+the allocation proceeds normally.
+
+11.a/2
+ Discussion: This check is required in some cases; see above.
+
+ NOTES
+
+12
+ 23 Allocators cannot create objects of an abstract type. See
+ *note 3.9.3::.
+
+13
+ 24 If any part of the created object is controlled, the
+ initialization includes calls on corresponding Initialize or Adjust
+ procedures. See *note 7.6::.
+
+14
+ 25 As explained in *note 13.11::, "*note 13.11:: Storage
+ Management", the storage for an object allocated by an allocator
+ comes from a storage pool (possibly user defined). The exception
+ Storage_Error is raised by an allocator if there is not enough
+ storage. Instances of Unchecked_Deallocation may be used to
+ explicitly reclaim storage.
+
+15/3
+ 26 {AI05-0229-1AI05-0229-1} Implementations are permitted, but not
+ required, to provide garbage collection.
+
+15.a
+ Ramification: Note that in an allocator, the exception
+ Constraint_Error can be raised by the evaluation of the
+ qualified_expression, by the elaboration of the
+ subtype_indication, or by the initialization.
+
+15.b
+ Discussion: By default, the implementation provides the
+ storage pool. The user may exercise more control over storage
+ management by associating a user-defined pool with an access
+ type.
+
+ _Examples_
+
+16
+Examples of allocators:
+
+17
+ new Cell'(0, null, null) -- initialized explicitly, see *note 3.10.1::
+ new Cell'(Value => 0, Succ => null, Pred => null) -- initialized explicitly
+ new Cell -- not initialized
+
+18
+ new Matrix(1 .. 10, 1 .. 20) -- the bounds only are given
+ new Matrix'(1 .. 10 => (1 .. 20 => 0.0)) -- initialized explicitly
+
+19
+ new Buffer(100) -- the discriminant only is given
+ new Buffer'(Size => 80, Pos => 0, Value => (1 .. 80 => 'A')) -- initialized explicitly
+
+20
+ Expr_Ptr'(new Literal) -- allocator for access-to-class-wide type, see *note 3.9.1::
+ Expr_Ptr'(new Literal'(Expression with 3.5)) -- initialized explicitly
+
+ _Incompatibilities With Ada 83_
+
+20.a/1
+ The subtype_indication of an uninitialized allocator may not
+ have an explicit constraint if the designated type is an
+ access type. In Ada 83, this was permitted even though the
+ constraint had no effect on the subtype of the created object.
+
+ _Extensions to Ada 83_
+
+20.b
+ Allocators creating objects of type T are now overloaded on
+ access types designating T'Class and all class-wide types that
+ cover T.
+
+20.c
+ Implicit array subtype conversion (sliding) is now performed
+ as part of an initialized allocator.
+
+ _Wording Changes from Ada 83_
+
+20.d
+ We have used a new organization, inspired by the ACID
+ document, that makes it clearer what is the subtype of the
+ created object, and what subtype conversions take place.
+
+20.e
+ Discussion of storage management issues, such as garbage
+ collection and the raising of Storage_Error, has been moved to
+ *note 13.11::, "*note 13.11:: Storage Management".
+
+ _Inconsistencies With Ada 95_
+
+20.f/2
+ {AI95-00363-01AI95-00363-01} If the designated type has a
+ constrained partial view, the allocated object can be
+ unconstrained. This might cause the object to take up a
+ different amount of memory, and might cause the operations to
+ work where they previously would have raised Constraint_Error.
+ It's unlikely that the latter would actually matter in a real
+ program (Constraint_Error usually indicates a bug that would
+ be fixed, not left in a program.) The former might cause
+ Storage_Error to be raised at a different time than in an Ada
+ 95 program.
+
+ _Incompatibilities With Ada 95_
+
+20.g/2
+ {AI95-00366-01AI95-00366-01} An allocator for an access type
+ that has Storage_Size specified to be zero is now illegal.
+ Ada 95 allowed the allocator, but it had to raise
+ Storage_Error if executed. The primary impact of this change
+ should be to detect bugs.
+
+ _Extensions to Ada 95_
+
+20.h/2
+ {8652/00108652/0010} {AI95-00127-01AI95-00127-01} Corrigendum:
+ An allocator can be a controlling parameter of a dispatching
+ call. This was an oversight in Ada 95.
+
+20.i/2
+ {AI95-00287-01AI95-00287-01} Initialized allocators are
+ allowed when the designated type is limited.
+
+ _Wording Changes from Ada 95_
+
+20.j/2
+ {8652/00028652/0002} {AI95-00171-01AI95-00171-01} Corrigendum:
+ Clarified the elaboration of per-object constraints for an
+ uninitialized allocator.
+
+20.k/2
+ {AI95-00280-01AI95-00280-01} Program_Error is now raised if
+ the allocator occurs after the finalization of the collection
+ or the waiting for tasks. This is not listed as an
+ incompatibility as the Ada 95 behavior was unspecified, and
+ Ada 95 implementations tend to generate programs that crash in
+ this case.
+
+20.l/2
+ {AI95-00344-01AI95-00344-01} Added accessibility checks to
+ class-wide allocators. These checks could not fail in Ada 95
+ (as all of the designated types had to be declared at the same
+ level, so the access type would necessarily have been at the
+ same level or more nested than the type of allocated object).
+
+20.m/2
+ {AI95-00373-01AI95-00373-01} Revised the description of
+ evaluation of uninitialized allocators to use "initialized by
+ default" so that the ordering requirements are the same for
+ all kinds of objects that are default-initialized.
+
+20.n/2
+ {AI95-00416-01AI95-00416-01} Added accessibility checks to
+ access discriminants of allocators. These checks could not
+ fail in Ada 95 as the discriminants always have the
+ accessibility of the object.
+
+ _Incompatibilities With Ada 2005_
+
+20.o/3
+ {AI05-0052-1AI05-0052-1} Correction: Added a rule to prevent
+ limited coextensions of nonlimited types. Allowing this would
+ have far-reaching implementation costs. Because of those
+ costs, it seems unlikely that any implementation ever
+ supported it properly and thus it is unlikely that any
+ existing code depends on this capability.
+
+20.p/3
+ {AI05-0104-1AI05-0104-1} Correction: Added a rule to make
+ null_exclusions illegal for uninitialized allocators, as such
+ an allocator would always raise Constraint_Error. Programs
+ that depend on the unconditional raising of a predefined
+ exception should be very rare.
+
+ _Extensions to Ada 2005_
+
+20.q/3
+ {AI05-0111-3AI05-0111-3} Subpool handles (see *note 13.11.4::)
+ can be specified in an allocator.
+
+ _Wording Changes from Ada 2005_
+
+20.r/3
+ {AI05-0024-1AI05-0024-1} Correction: Corrected the master
+ check for tags since the masters may be for different tasks
+ and thus incomparable.
+
+20.s/3
+ {AI05-0041-1AI05-0041-1} Correction: Corrected the rules for
+ when a designated object is constrained by its initial value
+ so that types derived from a partial view are handled
+ properly.
+
+20.t/3
+ {AI05-0051-1AI05-0051-1} {AI05-0234-1AI05-0234-1} Correction:
+ Corrected the accessibility check for access discriminants so
+ that it does not depend on the designated type (which might
+ not have discriminants when the allocated type does).
+
+\1f
+File: aarm2012.info, Node: 4.9, Prev: 4.8, Up: 4
+
+4.9 Static Expressions and Static Subtypes
+==========================================
+
+1
+Certain expressions of a scalar or string type are defined to be static.
+Similarly, certain discrete ranges are defined to be static, and certain
+scalar and string subtypes are defined to be static subtypes. [ Static
+means determinable at compile time, using the declared properties or
+values of the program entities.]
+
+1.a
+ Discussion: As opposed to more elaborate data flow analysis,
+ etc.
+
+ _Language Design Principles_
+
+1.b
+ For an expression to be static, it has to be calculable at
+ compile time.
+
+1.c
+ Only scalar and string expressions are static.
+
+1.d
+ To be static, an expression cannot have any nonscalar,
+ nonstring subexpressions (though it can have nonscalar
+ constituent names). A static scalar expression cannot have
+ any nonscalar subexpressions. There is one exception -- a
+ membership test for a string subtype can be static, and the
+ result is scalar, even though a subexpression is nonscalar.
+
+1.e
+ The rules for evaluating static expressions are designed to
+ maximize portability of static calculations.
+
+2
+A static expression is [a scalar or string expression that is] one of
+the following:
+
+3
+ * a numeric_literal;
+
+3.a
+ Ramification: A numeric_literal is always a static expression,
+ even if its expected type is not that of a static subtype.
+ However, if its value is explicitly converted to, or qualified
+ by, a nonstatic subtype, the resulting expression is
+ nonstatic.
+
+4
+ * a string_literal of a static string subtype;
+
+4.a
+ Ramification: That is, the constrained subtype defined by the
+ index range of the string is static. Note that elementary
+ values don't generally have subtypes, while composite values
+ do (since the bounds or discriminants are inherent in the
+ value).
+
+5
+ * a name that denotes the declaration of a named number or a static
+ constant;
+
+5.a
+ Ramification: Note that enumeration literals are covered by
+ the function_call case.
+
+6
+ * a function_call whose function_name or function_prefix statically
+ denotes a static function, and whose actual parameters, if any
+ (whether given explicitly or by default), are all static
+ expressions;
+
+6.a
+ Ramification: This includes uses of operators that are
+ equivalent to function_calls.
+
+7
+ * an attribute_reference that denotes a scalar value, and whose
+ prefix denotes a static scalar subtype;
+
+7.a
+ Ramification: Note that this does not include the case of an
+ attribute that is a function; a reference to such an attribute
+ is not even an expression. See above for function calls.
+
+7.b
+ An implementation may define the staticness and other
+ properties of implementation-defined attributes.
+
+8
+ * an attribute_reference whose prefix statically denotes a statically
+ constrained array object or array subtype, and whose
+ attribute_designator is First, Last, or Length, with an optional
+ dimension;
+
+9
+ * a type_conversion whose subtype_mark denotes a static scalar
+ subtype, and whose operand is a static expression;
+
+10
+ * a qualified_expression whose subtype_mark denotes a static [(scalar
+ or string)] subtype, and whose operand is a static expression;
+
+10.a
+ Ramification: This rules out the subtype_mark'aggregate case.
+
+10.b
+ Reason: Adding qualification to an expression shouldn't make
+ it nonstatic, even for strings.
+
+11/3
+ * {AI05-0158-1AI05-0158-1} {AI05-0269-1AI05-0269-1} a membership test
+ whose simple_expression is a static expression, and whose
+ membership_choice_list consists only of membership_choices that are
+ either static choice_expressions, static ranges, or subtype_marks
+ that denote a static [(scalar or string)] subtype;
+
+11.a
+ Reason: Clearly, we should allow membership tests in exactly
+ the same cases where we allow qualified_expressions.
+
+12
+ * a short-circuit control form both of whose relations are static
+ expressions;
+
+12.1/3
+ * {AI05-0147-1AI05-0147-1} {AI05-0188-1AI05-0188-1} a
+ conditional_expression all of whose conditions,
+ selecting_expressions, and dependent_expressions are static
+ expressions;
+
+13
+ * a static expression enclosed in parentheses.
+
+13.a
+ Discussion: Informally, we talk about a static value. When we
+ do, we mean a value specified by a static expression.
+
+13.b
+ Ramification: The language requires a static expression in a
+ number_declaration, a numeric type definition, a
+ discrete_choice (sometimes), certain representation items, an
+ attribute_designator, and when specifying the value of a
+ discriminant governing a variant_part in a record_aggregate or
+ extension_aggregate.
+
+14
+A name statically denotes an entity if it denotes the entity and:
+
+15
+ * It is a direct_name, expanded name, or character_literal, and it
+ denotes a declaration other than a renaming_declaration; or
+
+16
+ * It is an attribute_reference whose prefix statically denotes some
+ entity; or
+
+17
+ * It denotes a renaming_declaration with a name that statically
+ denotes the renamed entity.
+
+17.a
+ Ramification: Selected_components that are not expanded names
+ and indexed_components do not statically denote things.
+
+18
+A static function is one of the following:
+
+18.a
+ Ramification: These are the functions whose calls can be
+ static expressions.
+
+19
+ * a predefined operator whose parameter and result types are all
+ scalar types none of which are descendants of formal scalar types;
+
+20
+ * a predefined concatenation operator whose result type is a string
+ type;
+
+21
+ * an enumeration literal;
+
+22
+ * a language-defined attribute that is a function, if the prefix
+ denotes a static scalar subtype, and if the parameter and result
+ types are scalar.
+
+23
+In any case, a generic formal subprogram is not a static function.
+
+24
+A static constant is a constant view declared by a full constant
+declaration or an object_renaming_declaration (*note 8.5.1: S0200.) with
+a static nominal subtype, having a value defined by a static scalar
+expression or by a static string expression whose value has a length not
+exceeding the maximum length of a string_literal (*note 2.6: S0016.) in
+the implementation.
+
+24.a
+ Ramification: A deferred constant is not static; the view
+ introduced by the corresponding full constant declaration can
+ be static.
+
+24.b/3
+ Reason: {AI05-0229-1AI05-0229-1} The reason for restricting
+ the length of static string constants is so that compilers
+ don't have to store giant strings in their symbol tables.
+ Since most string constants will be initialized from
+ string_literals, the length limit seems pretty natural. The
+ reason for avoiding nonstring types is also to save symbol
+ table space. We're trying to keep it cheap and simple (from
+ the implementer's viewpoint), while still allowing, for
+ example, the aspect_definition for a Link_Name aspect to
+ contain a concatenation.
+
+24.c
+ The length we're talking about is the maximum number of
+ characters in the value represented by a string_literal, not
+ the number of characters in the source representation; the
+ quotes don't count.
+
+25
+A static range is a range whose bounds are static expressions, [or a
+range_attribute_reference (*note 4.1.4: S0102.) that is equivalent to
+such a range.] A static discrete_range (*note 3.6.1: S0058.) is one
+that is a static range or is a subtype_indication (*note 3.2.2: S0027.)
+that defines a static scalar subtype. The base range of a scalar type
+is a static range, unless the type is a descendant of a formal scalar
+type.
+
+26/3
+{AI95-00263-01AI95-00263-01} {AI05-0153-3AI05-0153-3} A static subtype
+is either a static scalar subtype or a static string subtype. A static
+scalar subtype is an unconstrained scalar subtype whose type is not a
+descendant of a formal type, or a constrained scalar subtype formed by
+imposing a compatible static constraint on a static scalar subtype. A
+static string subtype is an unconstrained string subtype whose index
+subtype and component subtype are static, or a constrained string
+subtype formed by imposing a compatible static constraint on a static
+string subtype. In any case, the subtype of a generic formal object of
+mode in out, and the result subtype of a generic formal function, are
+not static. Also, a subtype is not static if any Dynamic_Predicate
+specifications apply to it.
+
+26.a
+ Ramification: String subtypes are the only composite subtypes
+ that can be static.
+
+26.b
+ Reason: The part about generic formal objects of mode in out
+ is necessary because the subtype of the formal is not required
+ to have anything to do with the subtype of the actual. For
+ example:
+
+26.c
+ subtype Int10 is Integer range 1..10;
+
+26.d
+ generic
+ F : in out Int10;
+ procedure G;
+
+26.e
+ procedure G is
+ begin
+ case F is
+ when 1..10 => null;
+ -- Illegal!
+ end case;
+ end G;
+
+26.f
+ X : Integer range 1..20;
+ procedure I is new G(F => X); -- OK.
+
+26.g
+ The case_statement is illegal, because the subtype of F is not
+ static, so the choices have to cover all values of Integer,
+ not just those in the range 1..10. A similar issue arises for
+ generic formal functions, now that function calls are object
+ names.
+
+27
+The different kinds of static constraint are defined as follows:
+
+28
+ * A null constraint is always static;
+
+29
+ * A scalar constraint is static if it has no range_constraint, or one
+ with a static range;
+
+30
+ * An index constraint is static if each discrete_range is static, and
+ each index subtype of the corresponding array type is static;
+
+31
+ * A discriminant constraint is static if each expression of the
+ constraint is static, and the subtype of each discriminant is
+ static.
+
+31.1/2
+{AI95-00311-01AI95-00311-01} In any case, the constraint of the first
+subtype of a scalar formal type is neither static nor null.
+
+32
+A subtype is statically constrained if it is constrained, and its
+constraint is static. An object is statically constrained if its
+nominal subtype is statically constrained, or if it is a static string
+constant.
+
+ _Legality Rules_
+
+32.1/3
+{AI05-0147-1AI05-0147-1} An expression is statically unevaluated if it
+is part of:
+
+32.2/3
+ * {AI05-0147-1AI05-0147-1} the right operand of a static
+ short-circuit control form whose value is determined by its left
+ operand; or
+
+32.3/3
+ * {AI05-0147-1AI05-0147-1} {AI05-0188-1AI05-0188-1} a
+ dependent_expression of an if_expression whose associated condition
+ is static and equals False; or
+
+32.4/3
+ * {AI05-0147-1AI05-0147-1} {AI05-0188-1AI05-0188-1} a condition or
+ dependent_expression of an if_expression where the condition
+ corresponding to at least one preceding dependent_expression of the
+ if_expression is static and equals True; or
+
+32.a/3
+ Reason: We need this bullet so that only a single
+ dependent_expression is evaluated in a static if_expression if
+ there is more than one condition that evaluates to True. The
+ part about conditions makes
+
+32.b/3
+ (if N = 0 then Min elsif 10_000/N > Min then 10_000/N else Min)
+
+32.c/3
+ legal if N and Min are static and N = 0.
+
+32.d/3
+ Discussion: {AI05-0147-1AI05-0147-1} {AI05-0188-1AI05-0188-1}
+ We need the "of the if_expression" here so there is no
+ confusion for nested if_expressions; this rule only applies to
+ the conditions and dependent_expressions of a single
+ if_expression. Similar reasoning applies to the "of a
+ case_expression" of the last bullet.
+
+32.5/3
+ * {AI05-0188-1AI05-0188-1} {AI05-0269-1AI05-0269-1} a
+ dependent_expression of a case_expression whose
+ selecting_expression is static and whose value is not covered by
+ the corresponding discrete_choice_list; or
+
+32.6/3
+ * {AI05-0158-1AI05-0158-1} a choice_expression (or a
+ simple_expression of a range that occurs as a membership_choice of
+ a membership_choice_list) of a static membership test that is
+ preceded in the enclosing membership_choice_list by another item
+ whose individual membership test (see *note 4.5.2::) statically
+ yields True.
+
+33/3
+{AI05-0147-1AI05-0147-1} A static expression is evaluated at compile
+time except when it is statically unevaluated. The compile-time
+evaluation of a static expression is performed exactly, without
+performing Overflow_Checks. For a static expression that is evaluated:
+
+34/3
+ * {AI05-0262-1AI05-0262-1} The expression is illegal if its
+ evaluation fails a language-defined check other than
+ Overflow_Check. For the purposes of this evaluation, the assertion
+ policy is assumed to be Check.
+
+34.a/3
+ Reason: {AI05-0262-1AI05-0262-1} Assertion policies can
+ control whether checks are made, but we don't want assertion
+ policies to affect legality. For Ada 2012, subtype predicates
+ are the only checks controlled by the assertion policy that
+ can appear in static expressions.
+
+35/2
+ * {AI95-00269-01AI95-00269-01} If the expression is not part of a
+ larger static expression and the expression is expected to be of a
+ single specific type, then its value shall be within the base range
+ of its expected type. Otherwise, the value may be arbitrarily
+ large or small.
+
+35.a/2
+ Ramification: {AI95-00269-01AI95-00269-01} If the expression
+ is expected to be of a universal type, or of "any integer
+ type", there are no limits on the value of the expression.
+
+36/2
+ * {AI95-00269-01AI95-00269-01} If the expression is of type
+ universal_real and its expected type is a decimal fixed point type,
+ then its value shall be a multiple of the small of the decimal
+ type. This restriction does not apply if the expected type is a
+ descendant of a formal scalar type (or a corresponding actual type
+ in an instance).
+
+36.a
+ Ramification: This means that a numeric_literal for a decimal
+ type cannot have "extra" significant digits.
+
+36.b/2
+ Reason: {AI95-00269-01AI95-00269-01} The small is not known
+ for a generic formal type, so we have to exclude formal types
+ from this check.
+
+37/2
+{AI95-00269-01AI95-00269-01} In addition to the places where Legality
+Rules normally apply (see *note 12.3::), the above restrictions also
+apply in the private part of an instance of a generic unit.
+
+37.a
+ Discussion: Values outside the base range are not permitted
+ when crossing from the "static" domain to the "dynamic"
+ domain. This rule is designed to enhance portability of
+ programs containing static expressions. Note that this rule
+ applies to the exact value, not the value after any rounding
+ or truncation. (See below for the rounding and truncation
+ requirements.)
+
+37.b
+ Short-circuit control forms are a special case:
+
+37.c
+ N: constant := 0.0;
+ X: constant Boolean := (N = 0.0) or else (1.0/N > 0.5); -- Static.
+
+37.d
+ The declaration of X is legal, since the divide-by-zero part
+ of the expression is not evaluated. X is a static constant
+ equal to True.
+
+ _Implementation Requirements_
+
+38/2
+{AI95-00268-01AI95-00268-01} {AI95-00269-01AI95-00269-01} For a real
+static expression that is not part of a larger static expression, and
+whose expected type is not a descendant of a formal type, the
+implementation shall round or truncate the value (according to the
+Machine_Rounds attribute of the expected type) to the nearest machine
+number of the expected type; if the value is exactly half-way between
+two machine numbers, the rounding performed is implementation-defined.
+If the expected type is a descendant of a formal type, or if the static
+expression appears in the body of an instance of a generic unit and the
+corresponding expression is nonstatic in the corresponding generic body,
+then no special rounding or truncating is required -- normal accuracy
+rules apply (see *note Annex G::).
+
+38.a.1/2
+ Implementation defined: Rounding of real static expressions
+ which are exactly half-way between two machine numbers.
+
+38.a/2
+ Reason: {AI95-00268-01AI95-00268-01} Discarding extended
+ precision enhances portability by ensuring that the value of a
+ static constant of a real type is always a machine number of
+ the type.
+
+38.b
+ When the expected type is a descendant of a formal floating
+ point type, extended precision (beyond that of the machine
+ numbers) can be retained when evaluating a static expression,
+ to ease code sharing for generic instantiations. For similar
+ reasons, normal (nondeterministic) rounding or truncating
+ rules apply for descendants of a formal fixed point type.
+
+38.b.1/2
+ {AI95-00269-01AI95-00269-01} There is no requirement for exact
+ evaluation or special rounding in an instance body (unless the
+ expression is static in the generic body). This eliminates a
+ potential contract issue where the exact value of a static
+ expression depends on the actual parameters (which could then
+ affect the legality of other code).
+
+38.c
+ Implementation Note: Note that the implementation of static
+ expressions has to keep track of plus and minus zero for a
+ type whose Signed_Zeros attribute is True.
+
+38.d/2
+ {AI95-00100-01AI95-00100-01} Note that the only machine
+ numbers of a fixed point type are the multiples of the small,
+ so a static conversion to a fixed-point type, or division by
+ an integer, must do truncation to a multiple of small. It is
+ not correct for the implementation to do all static
+ calculations in infinite precision.
+
+ _Implementation Advice_
+
+38.1/2
+{AI95-00268-01AI95-00268-01} For a real static expression that is not
+part of a larger static expression, and whose expected type is not a
+descendant of a formal type, the rounding should be the same as the
+default rounding for the target system.
+
+38.e/2
+ Implementation Advice: A real static expression with a
+ nonformal type that is not part of a larger static expression
+ should be rounded the same as the target system.
+
+ NOTES
+
+39
+ 27 An expression can be static even if it occurs in a context
+ where staticness is not required.
+
+39.a
+ Ramification: For example:
+
+39.b
+ X : Float := Float'(1.0E+400) + 1.0 - Float'(1.0E+400);
+
+39.c
+ The expression is static, which means that the value of X must
+ be exactly 1.0, independent of the accuracy or range of the
+ run-time floating point implementation.
+
+39.d
+ The following kinds of expressions are never static:
+ explicit_dereference, indexed_component, slice, null,
+ aggregate, allocator.
+
+40
+ 28 A static (or run-time) type_conversion from a real type to an
+ integer type performs rounding. If the operand value is exactly
+ half-way between two integers, the rounding is performed away from
+ zero.
+
+40.a
+ Reason: We specify this for portability. The reason for not
+ choosing round-to-nearest-even, for example, is that this
+ method is easier to undo.
+
+40.b
+ Ramification: The attribute Truncation (see *note A.5.3::) can
+ be used to perform a (static) truncation prior to conversion,
+ to prevent rounding.
+
+40.c
+ Implementation Note: The value of the literal
+ 0E999999999999999999999999999999999999999999999 is zero. The
+ implementation must take care to evaluate such literals
+ properly.
+
+ _Examples_
+
+41
+Examples of static expressions:
+
+42
+ 1 + 1 -- 2
+ abs(-10)*3 -- 30
+
+43
+ Kilo : constant := 1000;
+ Mega : constant := Kilo*Kilo; -- 1_000_000
+ Long : constant := Float'Digits*2;
+
+44
+ Half_Pi : constant := Pi/2; -- see *note 3.3.2::
+ Deg_To_Rad : constant := Half_Pi/90;
+ Rad_To_Deg : constant := 1.0/Deg_To_Rad; -- equivalent to 1.0/((3.14159_26536/2)/90)
+
+ _Extensions to Ada 83_
+
+44.a
+ The rules for static expressions and static subtypes are
+ generalized to allow more kinds of compile-time-known
+ expressions to be used where compile-time-known values are
+ required, as follows:
+
+44.b
+ * Membership tests and short-circuit control forms may
+ appear in a static expression.
+
+44.c
+ * The bounds and length of statically constrained array
+ objects or subtypes are static.
+
+44.d
+ * The Range attribute of a statically constrained array
+ subtype or object gives a static range.
+
+44.e
+ * A type_conversion is static if the subtype_mark denotes a
+ static scalar subtype and the operand is a static
+ expression.
+
+44.f
+ * All numeric literals are now static, even if the expected
+ type is a formal scalar type. This is useful in
+ case_statements and variant_parts, which both now allow a
+ value of a formal scalar type to control the selection,
+ to ease conversion of a package into a generic package.
+ Similarly, named array aggregates are also permitted for
+ array types with an index type that is a formal scalar
+ type.
+
+44.g
+ The rules for the evaluation of static expressions are revised
+ to require exact evaluation at compile time, and force a
+ machine number result when crossing from the static realm to
+ the dynamic realm, to enhance portability and predictability.
+ Exact evaluation is not required for descendants of a formal
+ scalar type, to simplify generic code sharing and to avoid
+ generic contract model problems.
+
+44.h
+ Static expressions are legal even if an intermediate in the
+ expression goes outside the base range of the type.
+ Therefore, the following will succeed in Ada 95, whereas it
+ might raise an exception in Ada 83:
+
+44.i
+ type Short_Int is range -32_768 .. 32_767;
+ I : Short_Int := -32_768;
+
+44.j
+ This might raise an exception in Ada 83 because "32_768" is
+ out of range, even though "-32_768" is not. In Ada 95, this
+ will always succeed.
+
+44.k
+ Certain expressions involving string operations (in particular
+ concatenation and membership tests) are considered static in
+ Ada 95.
+
+44.l
+ The reason for this change is to simplify the rule requiring
+ compile-time-known string expressions as the link name in an
+ interfacing pragma, and to simplify the preelaborability
+ rules.
+
+ _Incompatibilities With Ada 83_
+
+44.m
+ An Ada 83 program that uses an out-of-range static value is
+ illegal in Ada 95, unless the expression is part of a larger
+ static expression, or the expression is not evaluated due to
+ being on the right-hand side of a short-circuit control form.
+
+ _Wording Changes from Ada 83_
+
+44.n/3
+ {AI05-0299-1AI05-0299-1} This subclause (and *note 4.5.5::,
+ "*note 4.5.5:: Multiplying Operators") subsumes the RM83
+ section on Universal Expressions.
+
+44.o
+ The existence of static string expressions necessitated
+ changing the definition of static subtype to include string
+ subtypes. Most occurrences of "static subtype" have been
+ changed to "static scalar subtype", in order to preserve the
+ effect of the Ada 83 rules. This has the added benefit of
+ clarifying the difference between "static subtype" and
+ "statically constrained subtype", which has been a source of
+ confusion. In cases where we allow static string subtypes, we
+ explicitly use phrases like "static string subtype" or "static
+ (scalar or string) subtype", in order to clarify the meaning
+ for those who have gotten used to the Ada 83 terminology.
+
+44.p
+ In Ada 83, an expression was considered nonstatic if it raised
+ an exception. Thus, for example:
+
+44.q
+ Bad: constant := 1/0; -- Illegal!
+
+44.r
+ was illegal because 1/0 was not static. In Ada 95, the above
+ example is still illegal, but for a different reason: 1/0 is
+ static, but there's a separate rule forbidding the exception
+ raising.
+
+ _Inconsistencies With Ada 95_
+
+44.s/2
+ {AI95-00268-01AI95-00268-01} Amendment Correction: Rounding of
+ static real expressions is implementation-defined in Ada 2005,
+ while it was specified as away from zero in (original) Ada 95.
+ This could make subtle differences in programs. However, the
+ original Ada 95 rule required rounding that (probably)
+ differed from the target processor, thus creating anomalies
+ where the value of a static expression was required to be
+ different than the same expression evaluated at run-time.
+
+ _Wording Changes from Ada 95_
+
+44.t/2
+ {AI95-00263-01AI95-00263-01} {AI95-00268-01AI95-00268-01} The
+ Ada 95 wording that defined static subtypes unintentionally
+ failed to exclude formal derived types that happen to be
+ scalar (these aren't formal scalar types); and had a
+ parenthetical remark excluding formal string types - but that
+ was neither necessary nor parenthetical (it didn't follow from
+ other wording). This issue also applies to the rounding rules
+ for real static expressions.
+
+44.u/2
+ {AI95-00269-01AI95-00269-01} Ada 95 didn't clearly define the
+ bounds of a value of a static expression for universal types
+ and for "any integer/float/fixed type". We also make it clear
+ that we do not intend exact evaluation of static expressions
+ in an instance body if the expressions aren't static in the
+ generic body.
+
+44.v/2
+ {AI95-00311-01AI95-00311-01} We clarify that the first subtype
+ of a scalar formal type has a nonstatic, nonnull constraint.
+
+ _Wording Changes from Ada 2005_
+
+44.w/3
+ {AI05-0147-1AI05-0147-1} {AI05-0188-1AI05-0188-1} Added
+ wording to define staticness and the lack of evaluation for
+ if_expressions and case_expressions. These are new and
+ defined elsewhere.
+
+44.x/3
+ {AI05-0153-3AI05-0153-3} Added wording to prevent subtypes
+ that have dynamic predicates (see *note 3.2.4::) from being
+ static.
+
+44.y/3
+ {AI05-0158-1AI05-0158-1} Revised wording for membership tests
+ to allow for the new possibilities allowed by the
+ membership_choice_list.
+
+* Menu:
+
+* 4.9.1 :: Statically Matching Constraints and Subtypes
+
+\1f
+File: aarm2012.info, Node: 4.9.1, Up: 4.9
+
+4.9.1 Statically Matching Constraints and Subtypes
+--------------------------------------------------
+
+ _Static Semantics_
+
+1/2
+{AI95-00311-01AI95-00311-01} A constraint statically matches another
+constraint if:
+
+1.1/2
+ * both are null constraints;
+
+1.2/2
+ * both are static and have equal corresponding bounds or discriminant
+ values;
+
+1.3/2
+ * both are nonstatic and result from the same elaboration of a
+ constraint of a subtype_indication (*note 3.2.2: S0027.) or the
+ same evaluation of a range of a discrete_subtype_definition (*note
+ 3.6: S0055.); or
+
+1.4/2
+ * {AI95-00311-01AI95-00311-01} both are nonstatic and come from the
+ same formal_type_declaration.
+
+2/3
+{AI95-00231-01AI95-00231-01} {AI95-00254-01AI95-00254-01}
+{AI05-0153-3AI05-0153-3} A subtype statically matches another subtype of
+the same type if they have statically matching constraints, all
+predicate specifications that apply to them come from the same
+declarations, and, for access subtypes, either both or neither exclude
+null. Two anonymous access-to-object subtypes statically match if their
+designated subtypes statically match, and either both or neither exclude
+null, and either both or neither are access-to-constant. Two anonymous
+access-to-subprogram subtypes statically match if their designated
+profiles are subtype conformant, and either both or neither exclude
+null.
+
+2.a
+ Ramification: Statically matching constraints and subtypes are
+ the basis for subtype conformance of profiles (see *note
+ 6.3.1::).
+
+2.b/2
+ Reason: Even though anonymous access types always represent
+ different types, they can statically match. That's important
+ so that they can be used widely. For instance, if this wasn't
+ true, access parameters and access discriminants could never
+ conform, so they couldn't be used in separate specifications.
+
+3
+Two ranges of the same type statically match if both result from the
+same evaluation of a range, or if both are static and have equal
+corresponding bounds.
+
+3.a
+ Ramification: The notion of static matching of ranges is used
+ in *note 12.5.3::, "*note 12.5.3:: Formal Array Types"; the
+ index ranges of formal and actual constrained array subtypes
+ have to statically match.
+
+4/3
+{AI05-0086-1AI05-0086-1} {AI05-0153-3AI05-0153-3} A constraint is
+statically compatible with a scalar subtype if it statically matches the
+constraint of the subtype, or if both are static and the constraint is
+compatible with the subtype. A constraint is statically compatible with
+an access or composite subtype if it statically matches the constraint
+of the subtype, or if the subtype is unconstrained.
+
+4.a
+ Discussion: Static compatibility is required when constraining
+ a parent subtype with a discriminant from a new
+ discriminant_part. See *note 3.7::. Static compatibility is
+ also used in matching generic formal derived types.
+
+4.b
+ Note that statically compatible with a subtype does not imply
+ compatible with a type. It is OK since the terms are used in
+ different contexts.
+
+5/3
+{AI05-0153-3AI05-0153-3} Two statically matching subtypes are statically
+compatible with each other. In addition, a subtype S1 is statically
+compatible with a subtype S2 if:
+
+6/3
+ * the constraint of S1 is statically compatible with S2, and
+
+7/3
+ * {AI05-0086-1AI05-0086-1} if S2 excludes null, so does S1, and
+
+8/3
+ * either:
+
+9/3
+ * all predicate specifications that apply to S2 apply also
+ to S1, or
+
+10/3
+ * both subtypes are static, every value that satisfies the
+ predicate of S1 also satisfies the predicate of S2, and
+ it is not the case that both types each have at least one
+ applicable predicate specification, predicate checks are
+ enabled (see *note 11.4.2::) for S2, and predicate checks
+ are not enabled for S1.
+
+ _Wording Changes from Ada 83_
+
+10.a
+ This subclause is new to Ada 95.
+
+ _Wording Changes from Ada 95_
+
+10.b/2
+ {AI95-00231-01AI95-00231-01} {AI95-00254-01AI95-00254-01}
+ Added static matching rules for null exclusions and anonymous
+ access-to-subprogram types; both of these are new.
+
+10.c/2
+ {AI95-00311-01AI95-00311-01} We clarify that the constraint of
+ the first subtype of a scalar formal type statically matches
+ itself.
+
+ _Incompatibilities With Ada 2005_
+
+10.d/3
+ {AI05-0086-1AI05-0086-1} Correction: Updated the statically
+ compatible rules to take null exclusions into account. This
+ is technically incompatible, as it could cause a legal Ada
+ 2005 program to be rejected; however, such a program violates
+ the intent of the rules (for instance, *note 3.7::(15)) and
+ this probably will simply detect bugs.
+
+ _Wording Changes from Ada 2005_
+
+10.e/3
+ {AI05-0153-3AI05-0153-3} {AI05-0290-1AI05-0290-1} Modified
+ static matching and static compatibility to take predicate
+ aspects (see *note 3.2.4::) into account.
+
+\1f
+File: aarm2012.info, Node: 5, Next: 6, Prev: 4, Up: Top
+
+5 Statements
+************
+
+1
+[A statement defines an action to be performed upon its execution.]
+
+2/3
+{AI95-00318-02AI95-00318-02} {AI05-0299-1AI05-0299-1} [This clause
+describes the general rules applicable to all statements. Some
+statements are discussed in later clauses: Procedure_call_statement
+(*note 6.4: S0178.)s and return statements are described in *note 6::,
+"*note 6:: Subprograms". Entry_call_statement (*note 9.5.3: S0225.)s,
+requeue_statement (*note 9.5.4: S0226.)s, delay_statement (*note 9.6:
+S0227.)s, accept_statement (*note 9.5.2: S0219.)s, select_statement
+(*note 9.7: S0230.)s, and abort_statement (*note 9.8: S0245.)s are
+described in *note 9::, "*note 9:: Tasks and Synchronization".
+Raise_statement (*note 11.3: S0269.)s are described in *note 11::,
+"*note 11:: Exceptions", and code_statement (*note 13.8: S0317.)s in
+*note 13::. The remaining forms of statements are presented in this
+clause.]
+
+ _Wording Changes from Ada 83_
+
+2.a/2
+ {AI95-00318-02AI95-00318-02} The description of return
+ statements has been moved to *note 6.5::, "*note 6.5:: Return
+ Statements", so that it is closer to the description of
+ subprograms.
+
+* Menu:
+
+* 5.1 :: Simple and Compound Statements - Sequences of Statements
+* 5.2 :: Assignment Statements
+* 5.3 :: If Statements
+* 5.4 :: Case Statements
+* 5.5 :: Loop Statements
+* 5.6 :: Block Statements
+* 5.7 :: Exit Statements
+* 5.8 :: Goto Statements
+
+\1f
+File: aarm2012.info, Node: 5.1, Next: 5.2, Up: 5
+
+5.1 Simple and Compound Statements - Sequences of Statements
+============================================================
+
+1
+[A statement is either simple or compound. A simple_statement encloses
+no other statement. A compound_statement can enclose simple_statements
+and other compound_statements.]
+
+ _Syntax_
+
+2/3
+ {AI05-0179-1AI05-0179-1} sequence_of_statements ::= statement {
+ statement} {label}
+
+3
+ statement ::=
+ {label} simple_statement | {label} compound_statement
+
+4/2
+ {AI95-00318-02AI95-00318-02} simple_statement ::= null_statement
+ | assignment_statement | exit_statement
+ | goto_statement | procedure_call_statement
+ | simple_return_statement | entry_call_statement
+ | requeue_statement | delay_statement
+ | abort_statement | raise_statement
+ | code_statement
+
+5/2
+ {AI95-00318-02AI95-00318-02} compound_statement ::=
+ if_statement | case_statement
+ | loop_statement | block_statement
+ | extended_return_statement
+ | accept_statement | select_statement
+
+6
+ null_statement ::= null;
+
+7
+ label ::= <<label_statement_identifier>>
+
+8
+ statement_identifier ::= direct_name
+
+9
+ The direct_name of a statement_identifier shall be an identifier
+ (not an operator_symbol).
+
+ _Name Resolution Rules_
+
+10
+The direct_name of a statement_identifier shall resolve to denote its
+corresponding implicit declaration (see below).
+
+ _Legality Rules_
+
+11
+Distinct identifiers shall be used for all statement_identifiers that
+appear in the same body, including inner block_statements but excluding
+inner program units.
+
+ _Static Semantics_
+
+12
+For each statement_identifier, there is an implicit declaration (with
+the specified identifier) at the end of the declarative_part of the
+innermost block_statement or body that encloses the
+statement_identifier. The implicit declarations occur in the same order
+as the statement_identifiers occur in the source text. If a usage name
+denotes such an implicit declaration, the entity it denotes is the
+label, loop_statement, or block_statement with the given
+statement_identifier.
+
+12.a
+ Reason: We talk in terms of individual statement_identifiers
+ here rather than in terms of the corresponding statements,
+ since a given statement may have multiple
+ statement_identifiers.
+
+12.b
+ A block_statement that has no explicit declarative_part has an
+ implicit empty declarative_part, so this rule can safely refer
+ to the declarative_part of a block_statement.
+
+12.c
+ The scope of a declaration starts at the place of the
+ declaration itself (see *note 8.2::). In the case of a label,
+ loop, or block name, it follows from this rule that the scope
+ of the implicit declaration starts before the first explicit
+ occurrence of the corresponding name, since this occurrence is
+ either in a statement label, a loop_statement, a
+ block_statement, or a goto_statement. An implicit declaration
+ in a block_statement may hide a declaration given in an outer
+ program unit or block_statement (according to the usual rules
+ of hiding explained in *note 8.3::).
+
+12.d
+ The syntax rule for label uses statement_identifier which is a
+ direct_name (not a defining_identifier), because labels are
+ implicitly declared. The same applies to loop and block
+ names. In other words, the label itself is not the defining
+ occurrence; the implicit declaration is.
+
+12.e
+ We cannot consider the label to be a defining occurrence. An
+ example that can tell the difference is this:
+
+12.f
+ declare
+ -- Label Foo is implicitly declared here.
+ begin
+ for Foo in ... loop
+ ...
+ <<Foo>> -- Illegal.
+ ...
+ end loop;
+ end;
+
+
+12.g/3
+ {AI05-0299-1AI05-0299-1} The label in this example is hidden
+ from itself by the loop parameter with the same name; the
+ example is illegal. We considered creating a new syntactic
+ category name, separate from direct_name and selector_name,
+ for use in the case of statement labels. However, that would
+ confuse the rules in Clause 8, so we didn't do it.
+
+12.1/3
+{AI05-0179-1AI05-0179-1} If one or more labels end a
+sequence_of_statements, an implicit null_statement follows the labels
+before any following constructs.
+
+12.g.1/3
+ Reason: The semantics of a goto_statement is defined in terms
+ of the statement having (following) that label. Thus we
+ ensure that every label has a following statement, which might
+ be implicit.
+
+ _Dynamic Semantics_
+
+13
+The execution of a null_statement has no effect.
+
+14/2
+{AI95-00318-02AI95-00318-02} A transfer of control is the run-time
+action of an exit_statement, return statement, goto_statement, or
+requeue_statement, selection of a terminate_alternative, raising of an
+exception, or an abort, which causes the next action performed to be one
+other than what would normally be expected from the other rules of the
+language. [As explained in *note 7.6.1::, a transfer of control can
+cause the execution of constructs to be completed and then left, which
+may trigger finalization.]
+
+15
+The execution of a sequence_of_statements consists of the execution of
+the individual statements in succession until the sequence_ is
+completed.
+
+15.a
+ Ramification: It could be completed by reaching the end of it,
+ or by a transfer of control.
+
+ NOTES
+
+16
+ 1 A statement_identifier that appears immediately within the
+ declarative region of a named loop_statement or an accept_statement
+ is nevertheless implicitly declared immediately within the
+ declarative region of the innermost enclosing body or
+ block_statement; in other words, the expanded name for a named
+ statement is not affected by whether the statement occurs inside or
+ outside a named loop or an accept_statement -- only nesting within
+ block_statements is relevant to the form of its expanded name.
+
+16.a
+ Discussion: Each comment in the following example gives the
+ expanded name associated with an entity declared in the task
+ body:
+
+16.b
+ task body Compute is
+ Sum : Integer := 0; -- Compute.Sum
+ begin
+ Outer: -- Compute.Outer
+ for I in 1..10 loop -- Compute.Outer.I
+ Blk: -- Compute.Blk
+ declare
+ Sum : Integer := 0; -- Compute.Blk.Sum
+ begin
+ accept Ent(I : out Integer; J : in Integer) do
+ -- Compute.Ent.I, Compute.Ent.J
+ Compute.Ent.I := Compute.Outer.I;
+ Inner: -- Compute.Blk.Inner
+ for J in 1..10 loop
+ -- Compute.Blk.Inner.J
+ Sum := Sum + Compute.Blk.Inner.J * Compute.Ent.J;
+ end loop Inner;
+ end Ent;
+ Compute.Sum := Compute.Sum + Compute.Blk.Sum;
+ end Blk;
+ end loop Outer;
+ Record_Result(Sum);
+ end Compute;
+
+ _Examples_
+
+17
+Examples of labeled statements:
+
+18
+ <<Here>> <<Ici>> <<Aqui>> <<Hier>> null;
+
+19
+ <<After>> X := 1;
+
+ _Extensions to Ada 83_
+
+19.a
+ The requeue_statement is new.
+
+ _Wording Changes from Ada 83_
+
+19.b
+ We define the syntactic category statement_identifier to
+ simplify the description. It is used for labels, loop names,
+ and block names. We define the entity associated with the
+ implicit declarations of statement names.
+
+19.c
+ Completion includes completion caused by a transfer of
+ control, although RM83-5.1(6) did not take this view.
+
+ _Extensions to Ada 95_
+
+19.d/2
+ {AI95-00318-02AI95-00318-02} The extended_return_statement is
+ new (simple_return_statement is merely renamed).
+
+ _Extensions to Ada 2005_
+
+19.e/3
+ {AI95-0179-1AI95-0179-1} A label can end a
+ sequence_of_statements, eliminating the requirement for having
+ an explicit null; statement after an ending label (a common
+ use).
+
+\1f
+File: aarm2012.info, Node: 5.2, Next: 5.3, Prev: 5.1, Up: 5
+
+5.2 Assignment Statements
+=========================
+
+1
+[An assignment_statement replaces the current value of a variable with
+the result of evaluating an expression.]
+
+ _Syntax_
+
+2
+ assignment_statement ::=
+ variable_name := expression;
+
+3
+The execution of an assignment_statement includes the evaluation of the
+expression and the assignment of the value of the expression into the
+target. [An assignment operation (as opposed to an assignment_statement
+(*note 5.2: S0152.)) is performed in other contexts as well, including
+object initialization and by-copy parameter passing.] The target of an
+assignment operation is the view of the object to which a value is being
+assigned; the target of an assignment_statement (*note 5.2: S0152.) is
+the variable denoted by the variable_name.
+
+3.a
+ Discussion: Don't confuse this notion of the "target" of an
+ assignment with the notion of the "target object" of an entry
+ call or requeue.
+
+3.b
+ Don't confuse the term "assignment operation" with the
+ assignment_statement. The assignment operation is just one
+ part of the execution of an assignment_statement. The
+ assignment operation is also a part of the execution of
+ various other constructs; see *note 7.6.1::, "*note 7.6.1::
+ Completion and Finalization" for a complete list. Note that
+ when we say, "such-and-such is assigned to so-and-so", we mean
+ that the assignment operation is being applied, and that
+ so-and-so is the target of the assignment operation.
+
+ _Name Resolution Rules_
+
+4/2
+{AI95-00287-01AI95-00287-01} The variable_name of an
+assignment_statement is expected to be of any type. The expected type
+for the expression is the type of the target.
+
+4.a
+ Implementation Note: An assignment_statement as a whole is a
+ "complete context," so if the variable_name of an
+ assignment_statement is overloaded, the expression can be used
+ to help disambiguate it. For example:
+
+4.b
+ type P1 is access R1;
+ type P2 is access R2;
+
+4.c
+ function F return P1;
+ function F return P2;
+
+4.d
+ X : R1;
+ begin
+ F.all := X; -- Right hand side helps resolve left hand side
+
+ _Legality Rules_
+
+5/2
+{AI95-00287-01AI95-00287-01} The target [denoted by the variable_name]
+shall be a variable of a nonlimited type.
+
+6
+If the target is of a tagged class-wide type T'Class, then the
+expression shall either be dynamically tagged, or of type T and
+tag-indeterminate (see *note 3.9.2::).
+
+6.a
+ Reason: This is consistent with the general rule that a single
+ dispatching operation shall not have both dynamically tagged
+ and statically tagged operands. Note that for an object
+ initialization (as opposed to the assignment_statement), a
+ statically tagged initialization expression is permitted,
+ since there is no chance for confusion (or Tag_Check failure).
+ Also, in an object initialization, tag-indeterminate
+ expressions of any type covered by T'Class would be allowed,
+ but with an assignment_statement, that might not work if the
+ tag of the target was for a type that didn't have one of the
+ dispatching operations in the tag-indeterminate expression.
+
+ _Dynamic Semantics_
+
+7
+For the execution of an assignment_statement, the variable_name and the
+expression are first evaluated in an arbitrary order.
+
+7.a
+ Ramification: Other rules of the language may require that the
+ bounds of the variable be determined prior to evaluating the
+ expression, but that does not necessarily require evaluation
+ of the variable_name, as pointed out by the ACID.
+
+8
+When the type of the target is class-wide:
+
+9
+ * If the expression is tag-indeterminate (see *note 3.9.2::), then
+ the controlling tag value for the expression is the tag of the
+ target;
+
+9.a
+ Ramification: See *note 3.9.2::, "*note 3.9.2:: Dispatching
+ Operations of Tagged Types".
+
+10
+ * Otherwise [(the expression is dynamically tagged)], a check is made
+ that the tag of the value of the expression is the same as that of
+ the target; if this check fails, Constraint_Error is raised.
+
+11
+The value of the expression is converted to the subtype of the target.
+[The conversion might raise an exception (see *note 4.6::).]
+
+11.a
+ Ramification: *note 4.6::, "*note 4.6:: Type Conversions"
+ defines what actions and checks are associated with subtype
+ conversion. For non-array subtypes, it is just a constraint
+ check presuming the types match. For array subtypes, it
+ checks the lengths and slides if the target is constrained.
+ "Sliding" means the array doesn't have to have the same
+ bounds, so long as it is the same length.
+
+12
+In cases involving controlled types, the target is finalized, and an
+anonymous object might be used as an intermediate in the assignment, as
+described in *note 7.6.1::, "*note 7.6.1:: Completion and Finalization".
+In any case, the converted value of the expression is then assigned to
+the target, which consists of the following two steps:
+
+12.a
+ To be honest: *note 7.6.1:: actually says that finalization
+ happens always, but unless controlled types are involved, this
+ finalization during an assignment_statement does nothing.
+
+13
+ * The value of the target becomes the converted value.
+
+14/3
+ * {AI05-0299-1AI05-0299-1} If any part of the target is controlled,
+ its value is adjusted as explained in subclause *note 7.6::.
+
+14.a
+ Ramification: If any parts of the object are controlled, abort
+ is deferred during the assignment operation itself, but not
+ during the rest of the execution of an assignment_statement.
+
+ NOTES
+
+15
+ 2 The tag of an object never changes; in particular, an
+ assignment_statement does not change the tag of the target.
+
+16/2
+ This paragraph was deleted.{AI95-00363-01AI95-00363-01}
+
+16.a
+ Ramification: The implicit subtype conversion described above
+ for assignment_statements is performed only for the value of
+ the right-hand side expression as a whole; it is not performed
+ for subcomponents of the value.
+
+16.b
+ The determination of the type of the variable of an
+ assignment_statement may require consideration of the
+ expression if the variable name can be interpreted as the name
+ of a variable designated by the access value returned by a
+ function call, and similarly, as a component or slice of such
+ a variable (see *note 8.6::, "*note 8.6:: The Context of
+ Overload Resolution").
+
+ _Examples_
+
+17
+Examples of assignment statements:
+
+18
+ Value := Max_Value - 1;
+ Shade := Blue;
+
+19
+ Next_Frame(F)(M, N) := 2.5; -- see *note 4.1.1::
+ U := Dot_Product(V, W); -- see *note 6.3::
+
+20
+ Writer := (Status => Open, Unit => Printer, Line_Count => 60); -- see *note 3.8.1::
+ Next_Car.all := (72074, null); -- see *note 3.10.1::
+
+21
+Examples involving scalar subtype conversions:
+
+22
+ I, J : Integer range 1 .. 10 := 5;
+ K : Integer range 1 .. 20 := 15;
+ ...
+
+23
+ I := J; -- identical ranges
+ K := J; -- compatible ranges
+ J := K; -- will raise Constraint_Error if K > 10
+
+24
+Examples involving array subtype conversions:
+
+25
+ A : String(1 .. 31);
+ B : String(3 .. 33);
+ ...
+
+26
+ A := B; -- same number of components
+
+27
+ A(1 .. 9) := "tar sauce";
+ A(4 .. 12) := A(1 .. 9); -- A(1 .. 12) = "tartar sauce"
+
+ NOTES
+
+28
+ 3 Notes on the examples: Assignment_statements are allowed even in
+ the case of overlapping slices of the same array, because the
+ variable_name and expression are both evaluated before copying the
+ value into the variable. In the above example, an implementation
+ yielding A(1 .. 12) = "tartartartar" would be incorrect.
+
+ _Extensions to Ada 83_
+
+28.a
+ We now allow user-defined finalization and value adjustment
+ actions as part of assignment_statements (see *note 7.6::,
+ "*note 7.6:: Assignment and Finalization").
+
+ _Wording Changes from Ada 83_
+
+28.b
+ The special case of array assignment is subsumed by the
+ concept of a subtype conversion, which is applied for all
+ kinds of types, not just arrays. For arrays it provides
+ "sliding". For numeric types it provides conversion of a
+ value of a universal type to the specific type of the target.
+ For other types, it generally has no run-time effect, other
+ than a constraint check.
+
+28.c
+ We now cover in a general way in *note 3.7.2:: the erroneous
+ execution possible due to changing the value of a discriminant
+ when the variable in an assignment_statement is a subcomponent
+ that depends on discriminants.
+
+ _Incompatibilities With Ada 95_
+
+28.d/2
+ {AI95-00287-01AI95-00287-01} The change of the limited check
+ from a resolution rule to a legality rule is not quite upward
+ compatible. For example
+
+28.e/2
+ type AccNonLim is access NonLim;
+ function Foo (Arg : in Integer) return AccNonLim;
+ type AccLim is access Lim;
+ function Foo (Arg : in Integer) return AccLim;
+ Foo(2).all := Foo(1).all;
+
+28.f/2
+ where NonLim is a nonlimited type and Lim is a limited type.
+ The assignment is legal in Ada 95 (only the first Foo would be
+ considered), and is ambiguous in Ada 2005. We made the change
+ because we want limited types to be as similar to nonlimited
+ types as possible. Limited expressions are now allowed in all
+ other contexts (with a similar incompatibility), and it would
+ be odd if assignments had different resolution rules (which
+ would eliminate ambiguities in some cases). Moreover,
+ examples like this one are rare, as they depend on assigning
+ into overloaded function calls.
+
+\1f
+File: aarm2012.info, Node: 5.3, Next: 5.4, Prev: 5.2, Up: 5
+
+5.3 If Statements
+=================
+
+1
+[An if_statement selects for execution at most one of the enclosed
+sequences_of_statements, depending on the (truth) value of one or more
+corresponding conditions.]
+
+ _Syntax_
+
+2
+ if_statement ::=
+ if condition then
+ sequence_of_statements
+ {elsif condition then
+ sequence_of_statements}
+ [else
+ sequence_of_statements]
+ end if;
+
+Paragraphs 3 and 4 were deleted.
+
+ _Dynamic Semantics_
+
+5/3
+{AI05-0264-1AI05-0264-1} For the execution of an if_statement, the
+condition specified after if, and any conditions specified after elsif,
+are evaluated in succession (treating a final else as elsif True then),
+until one evaluates to True or all conditions are evaluated and yield
+False. If a condition evaluates to True, then the corresponding
+sequence_of_statements is executed; otherwise, none of them is executed.
+
+5.a
+ Ramification: The part about all evaluating to False can't
+ happen if there is an else, since that is herein considered
+ equivalent to elsif True then.
+
+ _Examples_
+
+6
+Examples of if statements:
+
+7
+ if Month = December and Day = 31 then
+ Month := January;
+ Day := 1;
+ Year := Year + 1;
+ end if;
+
+8
+ if Line_Too_Short then
+ raise Layout_Error;
+ elsif Line_Full then
+ New_Line;
+ Put(Item);
+ else
+ Put(Item);
+ end if;
+
+9
+ if My_Car.Owner.Vehicle /= My_Car then -- see *note 3.10.1::
+ Report ("Incorrect data");
+ end if;
+
+ _Wording Changes from Ada 2005_
+
+9.a/3
+ {AI05-0147-1AI05-0147-1} Moved definition of condition to
+ *note 4.5.7:: in order to eliminate a forward reference.
+
+\1f
+File: aarm2012.info, Node: 5.4, Next: 5.5, Prev: 5.3, Up: 5
+
+5.4 Case Statements
+===================
+
+1
+[A case_statement selects for execution one of a number of alternative
+sequences_of_statements; the chosen alternative is defined by the value
+of an expression.]
+
+ _Syntax_
+
+2/3
+ {AI05-0188-1AI05-0188-1} case_statement ::=
+ case selecting_expression is
+ case_statement_alternative
+ {case_statement_alternative}
+ end case;
+
+3
+ case_statement_alternative ::=
+ when discrete_choice_list =>
+ sequence_of_statements
+
+ _Name Resolution Rules_
+
+4/3
+{AI05-0188-1AI05-0188-1} The selecting_expression is expected to be of
+any discrete type. The expected type for each discrete_choice is the
+type of the selecting_expression.
+
+ _Legality Rules_
+
+5/3
+{AI05-0153-3AI05-0153-3} The choice_expressions, subtype_indications,
+and ranges given as discrete_choices of a case_statement shall be
+static. [A discrete_choice others, if present, shall appear alone and
+in the last discrete_choice_list.]
+
+6/3
+{AI05-0188-1AI05-0188-1} {AI05-0240-1AI05-0240-1} The possible values of
+the selecting_expression shall be covered (see *note 3.8.1::) as
+follows:
+
+6.a/3
+ Discussion: {AI05-0240-1AI05-0240-1} The meaning of "covered"
+ here and in the following rules is that of the term "cover a
+ value" that is defined in *note 3.8.1::.
+
+7/3
+ * {AI05-0003-1AI05-0003-1} {AI05-0153-3AI05-0153-3}
+ {AI05-0188-1AI05-0188-1} {AI05-0262-1AI05-0262-1} If the
+ selecting_expression is a name [(including a type_conversion,
+ qualified_expression, or function_call)] having a static and
+ constrained nominal subtype, then each non-others discrete_choice
+ shall cover only values in that subtype that satisfy its predicate
+ (see *note 3.2.4::), and each value of that subtype that satisfies
+ its predicate shall be covered by some discrete_choice [(either
+ explicitly or by others)].
+
+7.a
+ Ramification: Although not official names of objects, a value
+ conversion still has a defined nominal subtype, namely its
+ target subtype. See *note 4.6::.
+
+8/3
+ * {AI05-0188-1AI05-0188-1} If the type of the selecting_expression is
+ root_integer, universal_integer, or a descendant of a formal scalar
+ type, then the case_statement shall have an others discrete_choice.
+
+8.a
+ Reason: This is because the base range is implementation
+ defined for root_integer and universal_integer, and not known
+ statically in the case of a formal scalar type.
+
+9/3
+ * {AI05-0188-1AI05-0188-1} Otherwise, each value of the base range of
+ the type of the selecting_expression shall be covered [(either
+ explicitly or by others)].
+
+10
+Two distinct discrete_choices of a case_statement shall not cover the
+same value.
+
+10.a/3
+ Ramification: {AI05-0188-1AI05-0188-1} The goal of these
+ coverage rules is that any possible value of the
+ selecting_expression of a case_statement should be covered by
+ exactly one discrete_choice of the case_statement, and that
+ this should be checked at compile time. The goal is achieved
+ in most cases, but there are two minor loopholes:
+
+10.b
+ * If the expression reads an object with an invalid
+ representation (e.g. an uninitialized object), then the
+ value can be outside the covered range. This can happen
+ for static constrained subtypes, as well as nonstatic or
+ unconstrained subtypes. It cannot, however, happen if
+ the case_statement has the discrete_choice others,
+ because others covers all values, even those outside the
+ subtype.
+
+10.c/3
+ * {AI95-00114-01AI95-00114-01} {AI05-0188-1AI05-0188-1} If
+ the compiler chooses to represent the value of an
+ expression of an unconstrained subtype in a way that
+ includes values outside the bounds of the subtype, then
+ those values can be outside the covered range. For
+ example, if X: Integer := Integer'Last;, and the case
+ selecting_expression is X+1, then the implementation
+ might choose to produce the correct value, which is
+ outside the bounds of Integer. (It might raise
+ Constraint_Error instead.) This case can only happen for
+ nongeneric subtypes that are either unconstrained or
+ nonstatic (or both). It can only happen if there is no
+ others discrete_choice.
+
+10.d
+ In the uninitialized variable case, the value might be
+ anything; hence, any alternative can be chosen, or
+ Constraint_Error can be raised. (We intend to prevent,
+ however, jumping to random memory locations and the like.) In
+ the out-of-range case, the behavior is more sensible: if there
+ is an others, then the implementation may choose to raise
+ Constraint_Error on the evaluation of the expression (as
+ usual), or it may choose to correctly evaluate the expression
+ and therefore choose the others alternative. Otherwise (no
+ others), Constraint_Error is raised either way -- on the
+ expression evaluation, or for the case_statement itself.
+
+10.e
+ For an enumeration type with a discontiguous set of internal
+ codes (see *note 13.4::), the only way to get values in
+ between the proper values is via an object with an invalid
+ representation; there is no "out-of-range" situation that can
+ produce them.
+
+ _Dynamic Semantics_
+
+11/3
+{AI05-0188-1AI05-0188-1} For the execution of a case_statement the
+selecting_expression is first evaluated.
+
+12/3
+{AI05-0188-1AI05-0188-1} If the value of the selecting_expression is
+covered by the discrete_choice_list (*note 3.8.1: S0073.) of some
+case_statement_alternative (*note 5.4: S0155.), then the
+sequence_of_statements (*note 5.1: S0145.) of the _alternative is
+executed.
+
+13
+Otherwise (the value is not covered by any discrete_choice_list, perhaps
+due to being outside the base range), Constraint_Error is raised.
+
+13.a
+ Ramification: In this case, the value is outside the base
+ range of its type, or is an invalid representation.
+
+ NOTES
+
+14
+ 4 The execution of a case_statement chooses one and only one
+ alternative. Qualification of the expression of a case_statement
+ by a static subtype can often be used to limit the number of
+ choices that need be given explicitly.
+
+ _Examples_
+
+15
+Examples of case statements:
+
+16
+ case Sensor is
+ when Elevation => Record_Elevation(Sensor_Value);
+ when Azimuth => Record_Azimuth (Sensor_Value);
+ when Distance => Record_Distance (Sensor_Value);
+ when others => null;
+ end case;
+
+17
+ case Today is
+ when Mon => Compute_Initial_Balance;
+ when Fri => Compute_Closing_Balance;
+ when Tue .. Thu => Generate_Report(Today);
+ when Sat .. Sun => null;
+ end case;
+
+18
+ case Bin_Number(Count) is
+ when 1 => Update_Bin(1);
+ when 2 => Update_Bin(2);
+ when 3 | 4 =>
+ Empty_Bin(1);
+ Empty_Bin(2);
+ when others => raise Error;
+ end case;
+
+ _Incompatibilities With Ada 83_
+
+18.a.1/1
+ In Ada 95, function_calls and type_conversions are names,
+ whereas in Ada 83, they were expressions. Therefore, if the
+ expression of a case_statement is a function_call or
+ type_conversion, and the result subtype is static, it is
+ illegal to specify a choice outside the bounds of the subtype.
+ For this case in Ada 83 choices only are required to be in the
+ base range of the type.
+
+18.a.2/1
+ In addition, the rule about which choices must be covered is
+ unchanged in Ada 95. Therefore, for a case_statement whose
+ expression is a function_call or type_conversion, Ada 83
+ required covering all choices in the base range, while Ada 95
+ only requires covering choices in the bounds of the subtype.
+ If the case_statement does not include an others
+ discrete_choice, then a legal Ada 83 case_statement will be
+ illegal in Ada 95 if the bounds of the subtype are different
+ than the bounds of the base type.
+
+ _Extensions to Ada 83_
+
+18.a
+ In Ada 83, the expression in a case_statement is not allowed
+ to be of a generic formal type. This restriction is removed
+ in Ada 95; an others discrete_choice is required instead.
+
+18.b
+ In Ada 95, a function call is the name of an object; this was
+ not true in Ada 83 (see *note 4.1::, "*note 4.1:: Names").
+ This change makes the following case_statement legal:
+
+18.c
+ subtype S is Integer range 1..2;
+ function F return S;
+ case F is
+ when 1 => ...;
+ when 2 => ...;
+ -- No others needed.
+ end case;
+
+18.d/3
+ {AI05-0005-1AI05-0005-1} Note that the result subtype given in
+ a function renaming_declaration is ignored; for a
+ case_statement whose expression calls a such a function, the
+ full coverage rules are checked using the result subtype of
+ the original function. Note that predefined operators such as
+ "+" have an unconstrained result subtype (see *note 4.5.1::).
+ Note that generic formal functions do not have static result
+ subtypes. Note that the result subtype of an inherited
+ subprogram need not correspond to any nameable subtype; there
+ is still a perfectly good result subtype, though.
+
+ _Wording Changes from Ada 83_
+
+18.e
+ Ada 83 forgot to say what happens for "legally" out-of-bounds
+ values.
+
+18.f
+ We take advantage of rules and terms (e.g. cover a value)
+ defined for discrete_choices and discrete_choice_lists in
+ *note 3.8.1::, "*note 3.8.1:: Variant Parts and Discrete
+ Choices".
+
+18.g
+ In the Name Resolution Rule for the case expression, we no
+ longer need RM83-5.4(3)'s "which must be determinable
+ independently of the context in which the expression occurs,
+ but using the fact that the expression must be of a discrete
+ type," because the expression is now a complete context. See
+ *note 8.6::, "*note 8.6:: The Context of Overload Resolution".
+
+18.h
+ Since type_conversions are now defined as names, their
+ coverage rule is now covered under the general rule for names,
+ rather than being separated out along with
+ qualified_expressions.
+
+ _Wording Changes from Ada 2005_
+
+18.i/3
+ {AI05-0003-1AI05-0003-1} Rewording to reflect that a
+ qualified_expression is now a name.
+
+18.j/3
+ {AI05-0153-3AI05-0153-3} Revised for changes to
+ discrete_choices made to allow static predicates (see *note
+ 3.2.4::) as case choices (see *note 3.8.1::).
+
+18.k/3
+ {AI05-0188-1AI05-0188-1} Added the selecting_ prefix to make
+ this wording consistent with case_expression, and to clarify
+ which expression is being talked about in the wording.
+
+\1f
+File: aarm2012.info, Node: 5.5, Next: 5.6, Prev: 5.4, Up: 5
+
+5.5 Loop Statements
+===================
+
+1
+[A loop_statement includes a sequence_of_statements that is to be
+executed repeatedly, zero or more times.]
+
+ _Syntax_
+
+2
+ loop_statement ::=
+ [loop_statement_identifier:]
+ [iteration_scheme] loop
+ sequence_of_statements
+ end loop [loop_identifier];
+
+3/3
+ {AI05-0139-2AI05-0139-2} iteration_scheme ::= while condition
+ | for loop_parameter_specification
+ | for iterator_specification
+
+4
+ loop_parameter_specification ::=
+ defining_identifier in [reverse] discrete_subtype_definition
+
+5
+ If a loop_statement has a loop_statement_identifier, then the
+ identifier shall be repeated after the end loop; otherwise, there
+ shall not be an identifier after the end loop.
+
+ _Static Semantics_
+
+6
+A loop_parameter_specification declares a loop parameter, which is an
+object whose subtype is that defined by the discrete_subtype_definition.
+
+ _Dynamic Semantics_
+
+7
+For the execution of a loop_statement, the sequence_of_statements is
+executed repeatedly, zero or more times, until the loop_statement is
+complete. The loop_statement is complete when a transfer of control
+occurs that transfers control out of the loop, or, in the case of an
+iteration_scheme, as specified below.
+
+8
+For the execution of a loop_statement with a while iteration_scheme, the
+condition is evaluated before each execution of the
+sequence_of_statements (*note 5.1: S0145.); if the value of the
+condition is True, the sequence_of_statements (*note 5.1: S0145.) is
+executed; if False, the execution of the loop_statement (*note 5.5:
+S0156.) is complete.
+
+9/3
+{AI05-0139-2AI05-0139-2} {AI05-0262-1AI05-0262-1} For the execution of a
+loop_statement with the iteration_scheme being for
+loop_parameter_specification (*note 5.5: S0158.), the
+loop_parameter_specification (*note 5.5: S0158.) is first elaborated.
+This elaboration creates the loop parameter and elaborates the
+discrete_subtype_definition (*note 3.6: S0055.). If the
+discrete_subtype_definition (*note 3.6: S0055.) defines a subtype with a
+null range, the execution of the loop_statement is complete. Otherwise,
+the sequence_of_statements (*note 5.1: S0145.) is executed once for each
+value of the discrete subtype defined by the discrete_subtype_definition
+(*note 3.6: S0055.) that satisfies the predicate of the subtype (or
+until the loop is left as a consequence of a transfer of control).
+Prior to each such iteration, the corresponding value of the discrete
+subtype is assigned to the loop parameter. These values are assigned in
+increasing order unless the reserved word reverse is present, in which
+case the values are assigned in decreasing order.
+
+9.a
+ Ramification: The order of creating the loop parameter and
+ evaluating the discrete_subtype_definition doesn't matter,
+ since the creation of the loop parameter has no side effects
+ (other than possibly raising Storage_Error, but anything can
+ do that).
+
+9.b/3
+ {AI05-0262-1AI05-0262-1} The predicate (if any) necessarily
+ has to be a static predicate as a dynamic predicate is
+ explicitly disallowed -- see *note 3.2.4::.
+
+9.c/3
+ Reason: {AI05-0262-1AI05-0262-1} If there is a predicate, the
+ loop still visits the values in the order of the underlying
+ base type; the order of the values in the predicate is
+ irrelevant. This is the case so that the following loops have
+ the same sequence of calls and parameters on procedure Call
+ for any subtype S:
+
+9.d
+ for I in S loop
+ Call (I);
+ end loop;
+
+9.e
+ for I in S'Base loop
+ if I in S then
+ Call (I);
+ end if;
+ end loop;
+
+9.1/3
+{AI05-0262-1AI05-0262-1} [For details about the execution of a
+loop_statement with the iteration_scheme being for
+iterator_specification, see *note 5.5.2::.]
+
+ NOTES
+
+10
+ 5 A loop parameter is a constant; it cannot be updated within the
+ sequence_of_statements of the loop (see *note 3.3::).
+
+11
+ 6 An object_declaration should not be given for a loop parameter,
+ since the loop parameter is automatically declared by the
+ loop_parameter_specification. The scope of a loop parameter
+ extends from the loop_parameter_specification to the end of the
+ loop_statement, and the visibility rules are such that a loop
+ parameter is only visible within the sequence_of_statements of the
+ loop.
+
+11.a
+ Implementation Note: An implementation could give a warning if
+ a variable is hidden by a loop_parameter_specification.
+
+12
+ 7 The discrete_subtype_definition of a for loop is elaborated just
+ once. Use of the reserved word reverse does not alter the discrete
+ subtype defined, so that the following iteration_schemes are not
+ equivalent; the first has a null range.
+
+13
+ for J in reverse 1 .. 0
+ for J in 0 .. 1
+
+13.a
+ Ramification: If a loop_parameter_specification has a static
+ discrete range, the subtype of the loop parameter is static.
+
+ _Examples_
+
+14
+Example of a loop statement without an iteration scheme:
+
+15
+ loop
+ Get(Current_Character);
+ exit when Current_Character = '*';
+ end loop;
+
+16
+Example of a loop statement with a while iteration scheme:
+
+17
+ while Bid(N).Price < Cut_Off.Price loop
+ Record_Bid(Bid(N).Price);
+ N := N + 1;
+ end loop;
+
+18
+Example of a loop statement with a for iteration scheme:
+
+19
+ for J in Buffer'Range loop -- works even with a null range
+ if Buffer(J) /= Space then
+ Put(Buffer(J));
+ end if;
+ end loop;
+
+20
+Example of a loop statement with a name:
+
+21
+ Summation:
+ while Next /= Head loop -- see *note 3.10.1::
+ Sum := Sum + Next.Value;
+ Next := Next.Succ;
+ end loop Summation;
+
+ _Wording Changes from Ada 83_
+
+21.a
+ The constant-ness of loop parameters is specified in *note
+ 3.3::, "*note 3.3:: Objects and Named Numbers".
+
+ _Wording Changes from Ada 2005_
+
+21.b/3
+ {AI05-0139-2AI05-0139-2} {AI05-0262-1AI05-0262-1}
+ {AI05-0299-1AI05-0299-1} Generalized iterator_specifications
+ are allowed in for loops; these are documented as an extension
+ in the appropriate subclause.
+
+* Menu:
+
+* 5.5.1 :: User-Defined Iterator Types
+* 5.5.2 :: Generalized Loop Iteration
+
+\1f
+File: aarm2012.info, Node: 5.5.1, Next: 5.5.2, Up: 5.5
+
+5.5.1 User-Defined Iterator Types
+---------------------------------
+
+ _Static Semantics_
+
+1/3
+{AI05-0139-2AI05-0139-2} The following language-defined generic library
+package exists:
+
+2/3
+ generic
+ type Cursor;
+ with function Has_Element (Position : Cursor) return Boolean;
+ package Ada.Iterator_Interfaces is
+ pragma Pure (Iterator_Interfaces);
+
+3/3
+ type Forward_Iterator is limited interface;
+ function First (Object : Forward_Iterator) return Cursor is abstract;
+ function Next (Object : Forward_Iterator; Position : Cursor)
+ return Cursor is abstract;
+
+4/3
+ type Reversible_Iterator is limited interface and Forward_Iterator;
+ function Last (Object : Reversible_Iterator) return Cursor is abstract;
+ function Previous (Object : Reversible_Iterator; Position : Cursor)
+ return Cursor is abstract;
+
+5/3
+ end Ada.Iterator_Interfaces;
+
+6/3
+{AI05-0139-2AI05-0139-2} An iterator type is a type descended from the
+Forward_Iterator interface from some instance of
+Ada.Iterator_Interfaces. A reversible iterator type is a type descended
+from the Reversible_Iterator interface from some instance of
+Ada.Iterator_Interfaces. An iterator object is an object of an iterator
+type. A reversible iterator object is an object of a reversible
+iterator type. The formal subtype Cursor from the associated instance
+of Ada.Iterator_Interfaces is the iteration cursor subtype for the
+iterator type.
+
+7/3
+{AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1} The following
+type-related operational aspects may be specified for an indexable
+container type T (see *note 4.1.6::):
+
+8/3
+Default_Iterator
+ This aspect is specified by a name that denotes exactly
+ one function declared immediately within the same
+ declaration list in which T is declared, whose first
+ parameter is of type T or T'Class or an access parameter
+ whose designated type is type T or T'Class, whose other
+ parameters, if any, have default expressions, and whose
+ result type is an iterator type. This function is the
+ default iterator function for T. Its result subtype is
+ the default iterator subtype for T. The iteration cursor
+ subtype for the default iterator subtype is the default
+ cursor subtype for T.
+
+8.a/3
+ Aspect Description for Default_Iterator: Default iterator to
+ be used in for loops.
+
+9/3
+Iterator_Element
+ This aspect is specified by a name that denotes a
+ subtype. This is the default element subtype for T.
+
+9.a/3
+ Aspect Description for Iterator_Element: Element type to be
+ used for user-defined iterators.
+
+10/3
+These aspects are inherited by descendants of type T (including
+T'Class).
+
+11/3
+{AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1} An iterable container
+type is an indexable container type with specified Default_Iterator and
+Iterator_Element aspects. A reversible iterable container type is an
+iterable container type with the default iterator type being a
+reversible iterator type. An iterable container object is an object of
+an iterable container type. A reversible iterable container object is
+an object of a reversible iterable container type.
+
+11.a.1/3
+ Glossary entry: An iterable container type is one that has
+ user-defined behavior for iteration, via the Default_Iterator
+ and Iterator_Element aspects.
+
+ _Legality Rules_
+
+12/3
+{AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1} The Constant_Indexing
+aspect (if any) of an iterable container type T shall denote exactly one
+function with the following properties:
+
+13/3
+ * the result type of the function is covered by the default element
+ type of T or is a reference type (see *note 4.1.5::) with an access
+ discriminant designating a type covered by the default element type
+ of T;
+
+14/3
+ * the type of the second parameter of the function covers the default
+ cursor type for T;
+
+15/3
+ * if there are more than two parameters, the additional parameters
+ all have default expressions.
+
+16/3
+This function (if any) is the default constant indexing function for T.
+
+16.a/3
+ Ramification: This does not mean that Constant_Indexing has to
+ designate only one subprogram, only that there is only one
+ routine that meets all of these properties. There can be
+ other routines designated by Constant_Indexing, but they
+ cannot have the profile described above. For instance, map
+ containers have a version of Constant_Indexing that takes a
+ key instead of a cursor; this is allowed.
+
+17/3
+{AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1} The Variable_Indexing
+aspect (if any) of an iterable container type T shall denote exactly one
+function with the following properties:
+
+18/3
+ * the result type of the function is a reference type (see *note
+ 4.1.5::) with an access discriminant designating a type covered by
+ the default element type of T;
+
+19/3
+ * the type of the second parameter of the function covers the default
+ cursor type for T;
+
+20/3
+ * if there are more than two parameters, the additional parameters
+ all have default expressions.
+
+21/3
+This function (if any) is the default variable indexing function for T.
+
+ _Extensions to Ada 2005_
+
+21.a/3
+ {AI05-0139-2AI05-0139-2} User-defined iterator types are new
+ in Ada 2012.
+
+\1f
+File: aarm2012.info, Node: 5.5.2, Prev: 5.5.1, Up: 5.5
+
+5.5.2 Generalized Loop Iteration
+--------------------------------
+
+1/3
+{AI05-0139-2AI05-0139-2} Generalized forms of loop iteration are
+provided by an iterator_specification.
+
+ _Syntax_
+
+2/3
+ {AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1}
+ iterator_specification ::=
+ defining_identifier in [reverse] iterator_name
+ | defining_identifier [:
+ subtype_indication] of [reverse] iterable_name
+
+ _Name Resolution Rules_
+
+3/3
+{AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1} For the first form of
+iterator_specification, called a generalized iterator, the expected type
+for the iterator_name is any iterator type. For the second form of
+iterator_specification, the expected type for the iterable_name is any
+array or iterable container type. If the iterable_name denotes an array
+object, the iterator_specification is called an array component
+iterator; otherwise it is called a container element iterator.
+
+3.a.1/3
+ Glossary entry: An iterator is a construct that is used to
+ loop over the elements of an array or container. Iterators
+ may be user defined, and may perform arbitrary computations to
+ access elements from a container.
+
+ _Legality Rules_
+
+4/3
+{AI05-0139-2AI05-0139-2} If the reserved word reverse appears, the
+iterator_specification is a reverse iterator; otherwise it is a forward
+iterator. In a reverse generalized iterator, the iterator_name shall be
+of a reversible iterator type. In a reverse container element iterator,
+the default iterator type for the type of the iterable_name shall be a
+reversible iterator type.
+
+5/3
+{AI05-0139-2AI05-0139-2} The type of the subtype_indication, if any, of
+an array component iterator shall cover the component type of the type
+of the iterable_name. The type of the subtype_indication, if any, of a
+container element iterator shall cover the default element type for the
+type of the iterable_name.
+
+6/3
+{AI05-0139-2AI05-0139-2} In a container element iterator whose
+iterable_name has type T, if the iterable_name denotes a constant or the
+Variable_Indexing aspect is not specified for T, then the
+Constant_Indexing aspect shall be specified for T.
+
+ _Static Semantics_
+
+7/3
+{AI05-0139-2AI05-0139-2} {AI05-0269-1AI05-0269-1}
+{AI05-0292-1AI05-0292-1} An iterator_specification declares a loop
+parameter. In a generalized iterator, the nominal subtype of the loop
+parameter is the iteration cursor subtype. In an array component
+iterator or a container element iterator, if a subtype_indication is
+present, it determines the nominal subtype of the loop parameter. In an
+array component iterator, if a subtype_indication is not present, the
+nominal subtype of the loop parameter is the component subtype of the
+type of the iterable_name. In a container element iterator, if a
+subtype_indication is not present, the nominal subtype of the loop
+parameter is the default element subtype for the type of the
+iterable_name.
+
+8/3
+{AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1} In a generalized
+iterator, the loop parameter is a constant. In an array component
+iterator, the loop parameter is a constant if the iterable_name denotes
+a constant; otherwise it denotes a variable. In a container element
+iterator, the loop parameter is a constant if the iterable_name denotes
+a constant, or if the Variable_Indexing aspect is not specified for the
+type of the iterable_name; otherwise it is a variable.
+
+ _Dynamic Semantics_
+
+9/3
+{AI05-0139-2AI05-0139-2} For the execution of a loop_statement with an
+iterator_specification, the iterator_specification is first elaborated.
+This elaboration elaborates the subtype_indication, if any.
+
+10/3
+{AI05-0139-2AI05-0139-2} For a generalized iterator, the loop parameter
+is created, the iterator_name is evaluated, and the denoted iterator
+object becomes the loop iterator. In a forward generalized iterator,
+the operation First of the iterator type is called on the loop iterator,
+to produce the initial value for the loop parameter. If the result of
+calling Has_Element on the initial value is False, then the execution of
+the loop_statement is complete. Otherwise, the sequence_of_statements
+is executed and then the Next operation of the iterator type is called
+with the loop iterator and the current value of the loop parameter to
+produce the next value to be assigned to the loop parameter. This
+repeats until the result of calling Has_Element on the loop parameter is
+False, or the loop is left as a consequence of a transfer of control.
+For a reverse generalized iterator, the operations Last and Previous are
+called rather than First and Next.
+
+11/3
+{AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1} For an array component
+iterator, the iterable_name is evaluated and the denoted array object
+becomes the array for the loop. If the array for the loop is a null
+array, then the execution of the loop_statement is complete. Otherwise,
+the sequence_of_statements is executed with the loop parameter denoting
+each component of the array for the loop, using a canonical order of
+components, which is last dimension varying fastest (unless the array
+has convention Fortran, in which case it is first dimension varying
+fastest). For a forward array component iterator, the iteration starts
+with the component whose index values are each the first in their index
+range, and continues in the canonical order. For a reverse array
+component iterator, the iteration starts with the component whose index
+values are each the last in their index range, and continues in the
+reverse of the canonical order. The loop iteration proceeds until the
+sequence_of_statements has been executed for each component of the array
+for the loop, or until the loop is left as a consequence of a transfer
+of control.
+
+12/3
+{AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1} For a container
+element iterator, the iterable_name is evaluated and the denoted
+iterable container object becomes the iterable container object for the
+loop. The default iterator function for the type of the iterable
+container object for the loop is called on the iterable container object
+and the result is the loop iterator. An object of the default cursor
+subtype is created (the loop cursor).
+
+13/3
+{AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1} For a forward
+container element iterator, the operation First of the iterator type is
+called on the loop iterator, to produce the initial value for the loop
+cursor. If the result of calling Has_Element on the initial value is
+False, then the execution of the loop_statement is complete. Otherwise,
+the sequence_of_statements is executed with the loop parameter denoting
+an indexing (see *note 4.1.6::) into the iterable container object for
+the loop, with the only parameter to the indexing being the current
+value of the loop cursor; then the Next operation of the iterator type
+is called with the loop iterator and the loop cursor to produce the next
+value to be assigned to the loop cursor. This repeats until the result
+of calling Has_Element on the loop cursor is False, or until the loop is
+left as a consequence of a transfer of control. For a reverse container
+element iterator, the operations Last and Previous are called rather
+than First and Next. If the loop parameter is a constant (see above),
+then the indexing uses the default constant indexing function for the
+type of the iterable container object for the loop; otherwise it uses
+the default variable indexing function.
+
+ _Examples_
+
+14/3
+ {AI05-0269-1AI05-0269-1} -- Array component iterator example:
+ for Element of Board loop -- See *note 3.6.1::.
+ Element := Element * 2.0; -- Double each element of Board, a two-dimensional array.
+ end loop;
+
+15/3
+{AI05-0268-1AI05-0268-1} For examples of use of generalized iterators,
+see *note A.18.32:: and the corresponding container packages in *note
+A.18.2:: and *note A.18.3::.
+
+ _Extensions to Ada 2005_
+
+15.a/3
+ {AI05-0139-2AI05-0139-2} Generalized forms of loop iteration
+ are new.
+
+\1f
+File: aarm2012.info, Node: 5.6, Next: 5.7, Prev: 5.5, Up: 5
+
+5.6 Block Statements
+====================
+
+1
+[A block_statement encloses a handled_sequence_of_statements optionally
+preceded by a declarative_part.]
+
+ _Syntax_
+
+2
+ block_statement ::=
+ [block_statement_identifier:]
+ [declare
+ declarative_part]
+ begin
+ handled_sequence_of_statements
+ end [block_identifier];
+
+3
+ If a block_statement has a block_statement_identifier, then the
+ identifier shall be repeated after the end; otherwise, there shall
+ not be an identifier after the end.
+
+ _Static Semantics_
+
+4
+A block_statement that has no explicit declarative_part has an implicit
+empty declarative_part.
+
+4.a
+ Ramification: Thus, other rules can always refer to the
+ declarative_part of a block_statement.
+
+ _Dynamic Semantics_
+
+5
+The execution of a block_statement consists of the elaboration of its
+declarative_part followed by the execution of its
+handled_sequence_of_statements.
+
+ _Examples_
+
+6
+Example of a block statement with a local variable:
+
+7
+ Swap:
+ declare
+ Temp : Integer;
+ begin
+ Temp := V; V := U; U := Temp;
+ end Swap;
+
+7.a
+ Ramification: If task objects are declared within a
+ block_statement whose execution is completed, the
+ block_statement is not left until all its dependent tasks are
+ terminated (see *note 7.6::). This rule applies to completion
+ caused by a transfer of control.
+
+7.b
+ Within a block_statement, the block name can be used in
+ expanded names denoting local entities such as Swap.Temp in
+ the above example (see *note 4.1.3::).
+
+ _Wording Changes from Ada 83_
+
+7.c
+ The syntax rule for block_statement now uses the syntactic
+ category handled_sequence_of_statements.
+
+\1f
+File: aarm2012.info, Node: 5.7, Next: 5.8, Prev: 5.6, Up: 5
+
+5.7 Exit Statements
+===================
+
+1
+[An exit_statement is used to complete the execution of an enclosing
+loop_statement; the completion is conditional if the exit_statement
+includes a condition.]
+
+ _Syntax_
+
+2
+ exit_statement ::=
+ exit [loop_name] [when condition];
+
+ _Name Resolution Rules_
+
+3
+The loop_name, if any, in an exit_statement shall resolve to denote a
+loop_statement.
+
+ _Legality Rules_
+
+4
+Each exit_statement (*note 5.7: S0161.) applies to a loop_statement
+(*note 5.5: S0156.); this is the loop_statement (*note 5.5: S0156.)
+being exited. An exit_statement (*note 5.7: S0161.) with a name is only
+allowed within the loop_statement (*note 5.5: S0156.) denoted by the
+name, and applies to that loop_statement (*note 5.5: S0156.). An
+exit_statement (*note 5.7: S0161.) without a name is only allowed within
+a loop_statement (*note 5.5: S0156.), and applies to the innermost
+enclosing one. An exit_statement (*note 5.7: S0161.) that applies to a
+given loop_statement (*note 5.5: S0156.) shall not appear within a body
+or accept_statement (*note 9.5.2: S0219.), if this construct is itself
+enclosed by the given loop_statement.
+
+ _Dynamic Semantics_
+
+5
+For the execution of an exit_statement, the condition, if present, is
+first evaluated. If the value of the condition is True, or if there is
+no condition, a transfer of control is done to complete the
+loop_statement (*note 5.5: S0156.). If the value of the condition is
+False, no transfer of control takes place.
+
+ NOTES
+
+6
+ 8 Several nested loops can be exited by an exit_statement that
+ names the outer loop.
+
+ _Examples_
+
+7
+Examples of loops with exit statements:
+
+8
+ for N in 1 .. Max_Num_Items loop
+ Get_New_Item(New_Item);
+ Merge_Item(New_Item, Storage_File);
+ exit when New_Item = Terminal_Item;
+ end loop;
+
+9
+ Main_Cycle:
+ loop
+ -- initial statements
+ exit Main_Cycle when Found;
+ -- final statements
+ end loop Main_Cycle;
+
+\1f
+File: aarm2012.info, Node: 5.8, Prev: 5.7, Up: 5
+
+5.8 Goto Statements
+===================
+
+1
+[A goto_statement specifies an explicit transfer of control from this
+statement to a target statement with a given label.]
+
+ _Syntax_
+
+2
+ goto_statement ::= goto label_name;
+
+ _Name Resolution Rules_
+
+3
+The label_name shall resolve to denote a label; the statement with that
+label is the target statement.
+
+ _Legality Rules_
+
+4
+The innermost sequence_of_statements that encloses the target statement
+shall also enclose the goto_statement. Furthermore, if a goto_statement
+is enclosed by an accept_statement or a body, then the target statement
+shall not be outside this enclosing construct.
+
+4.a
+ Ramification: The goto_statement can be a statement of an
+ inner sequence_.
+
+4.b
+ It follows from the second rule that if the target statement
+ is enclosed by such a construct, then the goto_statement
+ cannot be outside.
+
+ _Dynamic Semantics_
+
+5
+The execution of a goto_statement transfers control to the target
+statement, completing the execution of any compound_statement that
+encloses the goto_statement but does not enclose the target.
+
+ NOTES
+
+6
+ 9 The above rules allow transfer of control to a statement of an
+ enclosing sequence_of_statements but not the reverse. Similarly,
+ they prohibit transfers of control such as between alternatives of
+ a case_statement, if_statement, or select_statement; between
+ exception_handlers; or from an exception_handler of a
+ handled_sequence_of_statements back to its sequence_of_statements.
+
+ _Examples_
+
+7
+Example of a loop containing a goto statement:
+
+8
+ <<Sort>>
+ for I in 1 .. N-1 loop
+ if A(I) > A(I+1) then
+ Exchange(A(I), A(I+1));
+ goto Sort;
+ end if;
+ end loop;
+
+\1f
+File: aarm2012.info, Node: 6, Next: 7, Prev: 5, Up: Top
+
+6 Subprograms
+*************
+
+1
+A subprogram is a program unit or intrinsic operation whose execution is
+invoked by a subprogram call. There are two forms of subprogram:
+procedures and functions. A procedure call is a statement; a function
+call is an expression and returns a value. The definition of a
+subprogram can be given in two parts: a subprogram declaration defining
+its interface, and a subprogram_body defining its execution. [Operators
+and enumeration literals are functions.]
+
+1.a
+ To be honest: A function call is an expression, but more
+ specifically it is a name.
+
+1.b/2
+ Glossary entry: A subprogram is a section of a program that
+ can be executed in various contexts. It is invoked by a
+ subprogram call that may qualify the effect of the subprogram
+ through the passing of parameters. There are two forms of
+ subprograms: functions, which return values, and procedures,
+ which do not.
+
+1.c/2
+ Glossary entry: A function is a form of subprogram that
+ returns a result and can be called as part of an expression.
+
+1.d/2
+ Glossary entry: A procedure is a form of subprogram that does
+ not return a result and can only be called by a statement.
+
+2/3
+{AI05-0299-1AI05-0299-1} A callable entity is a subprogram or entry (see
+Section 9). A callable entity is invoked by a call; that is, a
+subprogram call or entry call. A callable construct is a construct that
+defines the action of a call upon a callable entity: a subprogram_body,
+entry_body, or accept_statement.
+
+2.a
+ Ramification: Note that "callable entity" includes predefined
+ operators, enumeration literals, and abstract subprograms.
+ "Call" includes calls of these things. They do not have
+ callable constructs, since they don't have completions.
+
+* Menu:
+
+* 6.1 :: Subprogram Declarations
+* 6.2 :: Formal Parameter Modes
+* 6.3 :: Subprogram Bodies
+* 6.4 :: Subprogram Calls
+* 6.5 :: Return Statements
+* 6.6 :: Overloading of Operators
+* 6.7 :: Null Procedures
+* 6.8 :: Expression Functions
+
+\1f
+File: aarm2012.info, Node: 6.1, Next: 6.2, Up: 6
+
+6.1 Subprogram Declarations
+===========================
+
+1
+[A subprogram_declaration declares a procedure or function.]
+
+ _Syntax_
+
+2/3
+ {AI95-00218-03AI95-00218-03} {AI05-0183-1AI05-0183-1}
+ subprogram_declaration ::=
+ [overriding_indicator]
+ subprogram_specification
+ [aspect_specification];
+
+3/2
+ This paragraph was deleted.{AI95-00348-01AI95-00348-01}
+
+4/2
+ {AI95-00348-01AI95-00348-01} subprogram_specification ::=
+ procedure_specification
+ | function_specification
+
+4.1/2
+ {AI95-00348-01AI95-00348-01} procedure_specification ::= procedure
+ defining_program_unit_name parameter_profile
+
+4.2/2
+ {AI95-00348-01AI95-00348-01} function_specification ::= function
+ defining_designator parameter_and_result_profile
+
+5
+ designator ::= [parent_unit_name . ]identifier | operator_symbol
+
+6
+ defining_designator ::= defining_program_unit_name |
+ defining_operator_symbol
+
+7
+ defining_program_unit_name ::= [parent_unit_name . ]
+ defining_identifier
+
+8
+ [The optional parent_unit_name is only allowed for library units
+ (see *note 10.1.1::).]
+
+9
+ operator_symbol ::= string_literal
+
+10/3
+ {AI95-00395-01AI95-00395-01} {AI05-0299-1AI05-0299-1} The sequence
+ of characters in an operator_symbol shall form a reserved word, a
+ delimiter, or compound delimiter that corresponds to an operator
+ belonging to one of the six categories of operators defined in
+ subclause *note 4.5::.
+
+10.a/3
+ Reason: {AI95-00395-01AI95-00395-01} {AI05-0090-1AI05-0090-1}
+ The "sequence of characters" of the string literal of the
+ operator is a technical term (see *note 2.6::), and does not
+ include the surrounding quote characters. As defined in *note
+ 2.2::, lexical elements are "formed" from a sequence of
+ characters. Spaces are not allowed, and upper and lower case
+ is not significant.
+
+11
+ defining_operator_symbol ::= operator_symbol
+
+12
+ parameter_profile ::= [formal_part]
+
+13/2
+ {AI95-00231-01AI95-00231-01} {AI95-00318-02AI95-00318-02}
+ parameter_and_result_profile ::=
+ [formal_part] return [null_exclusion] subtype_mark
+ | [formal_part] return access_definition
+
+14
+ formal_part ::=
+ (parameter_specification {; parameter_specification})
+
+15/3
+ {AI95-00231-01AI95-00231-01} {AI05-0142-4AI05-0142-4}
+ parameter_specification ::=
+ defining_identifier_list : [aliased] mode [null_exclusion]
+ subtype_mark [:= default_expression]
+ | defining_identifier_list : access_definition [:=
+ default_expression]
+
+16
+ mode ::= [in] | in out | out
+
+ _Name Resolution Rules_
+
+17
+A formal parameter is an object [directly visible within a
+subprogram_body] that represents the actual parameter passed to the
+subprogram in a call; it is declared by a parameter_specification. For
+a formal parameter, the expected type for its default_expression, if
+any, is that of the formal parameter.
+
+ _Legality Rules_
+
+18/3
+{AI05-0143-1AI05-0143-1} The parameter mode of a formal parameter
+conveys the direction of information transfer with the actual parameter:
+in, in out, or out. Mode in is the default, and is the mode of a
+parameter defined by an access_definition.
+
+18.a/3
+ This paragraph was deleted.{AI05-0143-1AI05-0143-1}
+
+19
+A default_expression is only allowed in a parameter_specification for a
+formal parameter of mode in.
+
+20/3
+{AI95-00348-01AI95-00348-01} {AI05-0177-1AI05-0177-1}
+{AI05-0229-1AI05-0229-1} A subprogram_declaration or a
+generic_subprogram_declaration requires a completion [unless the Import
+aspect (see *note B.1::) is True for the declaration; the completion
+shall be a body or a renaming_declaration (see *note 8.5::)]. [A
+completion is not allowed for an abstract_subprogram_declaration (see
+*note 3.9.3::), a null_procedure_declaration (see *note 6.7::), or an
+expression_function_declaration (see *note 6.8::).]
+
+20.a/3
+ Ramification: {AI95-00348-01AI95-00348-01}
+ {AI05-0177-1AI05-0177-1} Abstract subprograms , null
+ procedures, and expression functions are not declared by
+ subprogram_declarations, and so do not require completion
+ (although the latter two can be completions). Protected
+ subprograms are declared by subprogram_declarations, and so
+ require completion. Note that an abstract subprogram is a
+ subprogram, a null procedure is a subprogram, an expression
+ function is a subprogram, and a protected subprogram is a
+ subprogram, but a generic subprogram is not a subprogram.
+
+20.b/3
+ Proof: {AI05-0229-1AI05-0229-1} When the Import aspect is True
+ for any entity, no completion is allowed (see *note B.1::).
+
+21
+A name that denotes a formal parameter is not allowed within the
+formal_part in which it is declared, nor within the formal_part of a
+corresponding body or accept_statement.
+
+21.a
+ Ramification: By contrast,
+ generic_formal_parameter_declarations are visible to
+ subsequent declarations in the same generic_formal_part.
+
+ _Static Semantics_
+
+22
+The profile of (a view of) a callable entity is either a
+parameter_profile or parameter_and_result_profile[; it embodies
+information about the interface to that entity -- for example, the
+profile includes information about parameters passed to the callable
+entity. All callable entities have a profile -- enumeration literals,
+other subprograms, and entries. An access-to-subprogram type has a
+designated profile.] Associated with a profile is a calling convention.
+A subprogram_declaration declares a procedure or a function, as
+indicated by the initial reserved word, with name and profile as given
+by its specification.
+
+23/2
+{AI95-00231-01AI95-00231-01} {AI95-00318-02AI95-00318-02} The nominal
+subtype of a formal parameter is the subtype determined by the optional
+null_exclusion and the subtype_mark, or defined by the
+access_definition, in the parameter_specification. The nominal subtype
+of a function result is the subtype determined by the optional
+null_exclusion and the subtype_mark, or defined by the
+access_definition, in the parameter_and_result_profile.
+
+23.1/3
+{AI05-0142-4AI05-0142-4} An explicitly aliased parameter is a formal
+parameter whose parameter_specification includes the reserved word
+aliased.
+
+24/2
+{AI95-00231-01AI95-00231-01} {AI95-00254-01AI95-00254-01}
+{AI95-00318-02AI95-00318-02} An access parameter is a formal in
+parameter specified by an access_definition. An access result type is a
+function result type specified by an access_definition. An access
+parameter or result type is of an anonymous access type (see *note
+3.10::). [Access parameters of an access-to-object type allow
+dispatching calls to be controlled by access values. Access parameters
+of an access-to-subprogram type permit calls to subprograms passed as
+parameters irrespective of their accessibility level.]
+
+24.a/2
+ Discussion: {AI95-00318-02AI95-00318-02} Access result types
+ have normal accessibility and thus don't have any special
+ properties worth noting here.
+
+25
+The subtypes of a profile are:
+
+26
+ * For any non-access parameters, the nominal subtype of the
+ parameter.
+
+27/2
+ * {AI95-00254-01AI95-00254-01} For any access parameters of an
+ access-to-object type, the designated subtype of the parameter
+ type.
+
+27.1/3
+ * {AI95-00254-01AI95-00254-01} {AI05-0164-1AI05-0164-1} For any
+ access parameters of an access-to-subprogram type, the subtypes of
+ the designated profile of the parameter type.
+
+28/2
+ * {AI95-00231-01AI95-00231-01} {AI95-00318-02AI95-00318-02} For any
+ non-access result, the nominal subtype of the function result.
+
+28.1/2
+ * {AI95-00318-02AI95-00318-02} For any access result type of an
+ access-to-object type, the designated subtype of the result type.
+
+28.2/3
+ * {AI95-00318-02AI95-00318-02} {AI05-0164-1AI05-0164-1} For any
+ access result type of an access-to-subprogram type, the subtypes of
+ the designated profile of the result type.
+
+29
+[ The types of a profile are the types of those subtypes.]
+
+30/3
+{AI95-00348-01AI95-00348-01} {AI05-0177-1AI05-0177-1} [A subprogram
+declared by an abstract_subprogram_declaration is abstract; a subprogram
+declared by a subprogram_declaration is not. See *note 3.9.3::, "*note
+3.9.3:: Abstract Types and Subprograms". Similarly, a procedure
+declared by a null_procedure_declaration is a null procedure; a
+procedure declared by a subprogram_declaration is not. See *note 6.7::,
+"*note 6.7:: Null Procedures". Finally, a function declared by an
+expression_function_declaration is an expression function; a function
+declared by a subprogram_declaration is not. See *note 6.8::, "*note
+6.8:: Expression Functions".]
+
+30.1/2
+{AI95-00218-03AI95-00218-03} [An overriding_indicator is used to
+indicate whether overriding is intended. See *note 8.3.1::, "*note
+8.3.1:: Overriding Indicators".]
+
+ _Dynamic Semantics_
+
+31/2
+{AI95-00348-01AI95-00348-01} The elaboration of a subprogram_declaration
+has no effect.
+
+ NOTES
+
+32
+ 1 A parameter_specification with several identifiers is equivalent
+ to a sequence of single parameter_specifications, as explained in
+ *note 3.3::.
+
+33
+ 2 Abstract subprograms do not have bodies, and cannot be used in a
+ nondispatching call (see *note 3.9.3::, "*note 3.9.3:: Abstract
+ Types and Subprograms").
+
+34
+ 3 The evaluation of default_expressions is caused by certain
+ calls, as described in *note 6.4.1::. They are not evaluated
+ during the elaboration of the subprogram declaration.
+
+35
+ 4 Subprograms can be called recursively and can be called
+ concurrently from multiple tasks.
+
+ _Examples_
+
+36
+Examples of subprogram declarations:
+
+37
+ procedure Traverse_Tree;
+ procedure Increment(X : in out Integer);
+ procedure Right_Indent(Margin : out Line_Size); -- see *note 3.5.4::
+ procedure Switch(From, To : in out Link); -- see *note 3.10.1::
+
+38
+ function Random return Probability; -- see *note 3.5.7::
+
+39
+ function Min_Cell(X : Link) return Cell; -- see *note 3.10.1::
+ function Next_Frame(K : Positive) return Frame; -- see *note 3.10::
+ function Dot_Product(Left, Right : Vector) return Real; -- see *note 3.6::
+
+40
+ function "*"(Left, Right : Matrix) return Matrix; -- see *note 3.6::
+
+41
+Examples of in parameters with default expressions:
+
+42
+ procedure Print_Header(Pages : in Natural;
+ Header : in Line := (1 .. Line'Last => ' '); -- see *note 3.6::
+ Center : in Boolean := True);
+
+ _Extensions to Ada 83_
+
+42.a
+ The syntax for abstract_subprogram_declaration is added. The
+ syntax for parameter_specification is revised to allow for
+ access parameters (see *note 3.10::)
+
+42.b/3
+ {AI05-0299-1AI05-0299-1} Program units that are library units
+ may have a parent_unit_name to indicate the parent of a child
+ (see *note 10.1.1::).
+
+ _Wording Changes from Ada 83_
+
+42.c
+ We have incorporated the rules from RM83-6.5, "Function
+ Subprograms" here and in *note 6.3::, "*note 6.3:: Subprogram
+ Bodies"
+
+42.d
+ We have incorporated the definitions of RM83-6.6, "Parameter
+ and Result Type Profile - Overloading of Subprograms" here.
+
+42.e
+ The syntax rule for defining_operator_symbol is new. It is
+ used for the defining occurrence of an operator_symbol,
+ analogously to defining_identifier. Usage occurrences use the
+ direct_name or selector_name syntactic categories. The syntax
+ rules for defining_designator and defining_program_unit_name
+ are new.
+
+ _Extensions to Ada 95_
+
+42.f/2
+ {AI95-00218-03AI95-00218-03} Subprograms now allow
+ overriding_indicators for better error checking of overriding.
+
+42.g/2
+ {AI95-00231-01AI95-00231-01} An optional null_exclusion can be
+ used in a formal parameter declaration. Similarly, an
+ optional null_exclusion can be used in a function result.
+
+42.h/2
+ {AI95-00318-02AI95-00318-02} The return type of a function can
+ be an anonymous access type.
+
+ _Wording Changes from Ada 95_
+
+42.i/2
+ {AI95-00254-01AI95-00254-01} A description of the purpose of
+ anonymous access-to-subprogram parameters and the definition
+ of the profile of subprograms containing them was added.
+
+42.j/2
+ {AI95-00348-01AI95-00348-01} Split the production for
+ subprogram_specification in order to make the declaration of
+ null procedures (see *note 6.7::) easier.
+
+42.k/2
+ {AI95-00348-01AI95-00348-01} Moved the Syntax and Dynamic
+ Semantics for abstract_subprogram_declaration to *note
+ 3.9.3::, so that the syntax and semantics are together. This
+ also keeps abstract and null subprograms similar.
+
+42.l/2
+ {AI95-00395-01AI95-00395-01} Revised to allow other_format
+ characters in operator_symbols in the same way as the
+ underlying constructs.
+
+ _Extensions to Ada 2005_
+
+42.m/3
+ {AI05-0142-4AI05-0142-4} Parameters can now be explicitly
+ aliased, allowing parts of function results to designate
+ parameters and forcing by-reference parameter passing.
+
+42.n/3
+ {AI05-0143-1AI05-0143-1} The parameters of a function can now
+ have any mode.
+
+42.o/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a subprogram_declaration. This is described in
+ *note 13.1.1::.
+
+ _Wording Changes from Ada 2005_
+
+42.p/3
+ {AI05-0177-1AI05-0177-1} Added expression functions (see *note
+ 6.8::) to the wording.
+
+* Menu:
+
+* 6.1.1 :: Preconditions and Postconditions
+
+\1f
+File: aarm2012.info, Node: 6.1.1, Up: 6.1
+
+6.1.1 Preconditions and Postconditions
+--------------------------------------
+
+1/3
+{AI05-0145-2AI05-0145-2} {AI05-0247-1AI05-0247-1} For a subprogram or
+entry, the following language-defined aspects may be specified with an
+aspect_specification (see *note 13.1.1::):
+
+2/3
+Pre
+ This aspect specifies a specific precondition for a
+ callable entity; it shall be specified by an expression,
+ called a specific precondition expression. If not
+ specified for an entity, the specific precondition
+ expression for the entity is the enumeration literal
+ True.
+
+2.a/3
+ To be honest: In this and the following rules, we are talking
+ about the enumeration literal True declared in package
+ Standard (see *note A.1::), and not some other value or
+ identifier True. That matters as some rules depend on full
+ conformance of these expressions, which depends on the
+ specific declarations involved.
+
+2.b/3
+ Aspect Description for Pre: Precondition; a condition that
+ must hold true before a call.
+
+3/3
+{AI05-0254-1AI05-0254-1} {AI05-0262-1AI05-0262-1} Pre'Class
+ This aspect specifies a class-wide precondition for an
+ operation of a tagged type and its descendants; it shall
+ be specified by an expression, called a class-wide
+ precondition expression. If not specified for an entity,
+ then if no other class-wide precondition applies to the
+ entity, the class-wide precondition expression for the
+ entity is the enumeration literal True.
+
+3.a/3
+ Ramification: {AI05-0254-1AI05-0254-1} If other class-wide
+ preconditions apply to the entity and no class-wide
+ precondition is specified, no class-wide precondition is
+ defined for the entity; of course, the class-wide
+ preconditions (of ancestors) that apply are still going to be
+ checked. We need subprograms that don't have ancestors and
+ don't specify a class-wide precondition to have a class-wide
+ precondition of True, so that adding such a precondition to a
+ descendant has no effect (necessary as a dispatching call
+ through the root routine would not check any precondition).
+
+3.b/3
+ Aspect Description for Pre'Class: Precondition inherited on
+ type derivation.
+
+4/3
+Post
+ This aspect specifies a specific postcondition for a
+ callable entity; it shall be specified by an expression,
+ called a specific postcondition expression. If not
+ specified for an entity, the specific postcondition
+ expression for the entity is the enumeration literal
+ True.
+
+4.a/3
+ Aspect Description for Post: Postcondition; a condition that
+ must hold true after a call.
+
+5/3
+{AI05-0262-1AI05-0262-1} Post'Class
+ This aspect specifies a class-wide postcondition for an
+ operation of a tagged type and its descendants; it shall
+ be specified by an expression, called a class-wide
+ postcondition expression. If not specified for an
+ entity, the class-wide postcondition expression for the
+ entity is the enumeration literal True.
+
+5.a/3
+ Aspect Description for Post'Class: Postcondition inherited on
+ type derivation.
+
+ _Name Resolution Rules_
+
+6/3
+{AI05-0145-2AI05-0145-2} The expected type for a precondition or
+postcondition expression is any boolean type.
+
+7/3
+{AI05-0145-2AI05-0145-2} {AI05-0262-1AI05-0262-1} Within the expression
+for a Pre'Class or Post'Class aspect for a primitive subprogram of a
+tagged type T, a name that denotes a formal parameter of type T is
+interpreted as having type T'Class. Similarly, a name that denotes a
+formal access parameter of type access-to-T is interpreted as having
+type access-to-T'Class. [This ensures that the expression is
+well-defined for a primitive subprogram of a type descended from T.]
+
+8/3
+{AI05-0145-2AI05-0145-2} {AI05-0264-1AI05-0264-1} For an
+attribute_reference with attribute_designator Old, if the attribute
+reference has an expected type or shall resolve to a given type, the
+same applies to the prefix; otherwise, the prefix shall be resolved
+independently of context.
+
+ _Legality Rules_
+
+9/3
+{AI05-0145-2AI05-0145-2} {AI05-0230-1AI05-0230-1} The Pre or Post aspect
+shall not be specified for an abstract subprogram or a null procedure.
+[Only the Pre'Class and Post'Class aspects may be specified for such a
+subprogram.]
+
+9.a/3
+ Discussion: {AI05-0183-1AI05-0183-1} Pre'Class and Post'Class
+ can only be specified on primitive routines of tagged types,
+ by a blanket rule found in *note 13.1.1::.
+
+10/3
+{AI05-0247-1AI05-0247-1} {AI05-0254-1AI05-0254-1} If a type T has an
+implicitly declared subprogram P inherited from a parent type T1 and a
+homograph (see *note 8.3::) of P from a progenitor type T2, and
+
+11/3
+ * the corresponding primitive subprogram P1 of type T1 is neither
+ null nor abstract; and
+
+12/3
+ * the class-wide precondition expression True does not apply to P1
+ (implicitly or explicitly); and
+
+13/3
+ * there is a class-wide precondition expression that applies to the
+ corresponding primitive subprogram P2 of T2 that does not fully
+ conform to any class-wide precondition expression that applies to
+ P1,
+
+14/3
+{AI05-0247-1AI05-0247-1} {AI05-0254-1AI05-0254-1} then:
+
+15/3
+ * If the type T is abstract, the implicitly declared subprogram P is
+ abstract.
+
+16/3
+ * Otherwise, the subprogram P requires overriding and shall be
+ overridden with a nonabstract subprogram.
+
+16.a/3
+ Discussion: We use the term "requires overriding" here so that
+ this rule is taken into account when calculating visibility in
+ *note 8.3::; otherwise we would have a mess when this routine
+ is overridden.
+
+16.b/3
+ Reason: Such an inherited subprogram would necessarily violate
+ the Liskov Substitutability Principle (LSP) if called via a
+ dispatching call from an ancestor other than the one that
+ provides the called body. In such a case, the class-wide
+ precondition of the actual body is stronger than the
+ class-wide precondition of the ancestor. If we did not
+ enforce that precondition for the body, the body could be
+ called when the precondition it knows about is False -- such
+ "counterfeiting" of preconditions has to be avoided. But
+ enforcing the precondition violates LSP. We do not want the
+ language to be implicitly creating bodies that violate LSP;
+ the programmer can still write an explicit body that calls the
+ appropriate parent subprogram. In that case, the violation of
+ LSP is explicitly in the code and obvious to code reviewers
+ (both human and automated).
+
+16.c/3
+ We have to say that the subprogram is abstract for an abstract
+ type in this case, so that the next concrete type has to
+ override it for the reasons above. Otherwise, inserting an
+ extra level of abstract types would eliminate the requirement
+ to override (as there is only one declared operation for the
+ concrete type), and that would be bad for the reasons given
+ above.
+
+16.d/3
+ Ramification: This requires the set of class-wide
+ preconditions that apply to the interface routine to be
+ strictly stronger than those that apply to the concrete
+ routine. Since full conformance requires each name to denote
+ the same declaration, it is unlikely that independently
+ declared preconditions would conform. This rule does allow
+ "diamond inheritance" of preconditions, and of course no
+ preconditions at all match.
+
+16.e/3
+ We considered adopting a rule that would allow examples where
+ the expressions would conform after all inheritance has been
+ applied, but this is complex and is not likely to be common in
+ practice. Since the penalty here is just that an explicit
+ overriding is required, the complexity is too much.
+
+17/3
+{AI05-0247-1AI05-0247-1} If a renaming of a subprogram or entry S1
+overrides an inherited subprogram S2, then the overriding is illegal
+unless each class-wide precondition expression that applies to S1 fully
+conforms to some class-wide precondition expression that applies to S2
+and each class-wide precondition expression that applies to S2 fully
+conforms to some class-wide precondition expression that applies to S1.
+
+17.a/3
+ Reason: Such an overriding subprogram would violate LSP, as
+ the precondition of S1 would usually be different (and thus
+ stronger) than the one known to a dispatching call through an
+ ancestor routine of S2. This is always OK if the
+ preconditions match, so we always allow that.
+
+17.b/3
+ Ramification: This only applies to primitives of tagged types;
+ other routines cannot have class-wide preconditions.
+
+ _Static Semantics_
+
+18/3
+{AI05-0145-2AI05-0145-2} If a Pre'Class or Post'Class aspect is
+specified for a primitive subprogram of a tagged type T, then the
+associated expression also applies to the corresponding primitive
+subprogram of each descendant of T.
+
+19/3
+{AI05-0145-2AI05-0145-2} {AI05-0262-1AI05-0262-1}
+{AI05-0290-1AI05-0290-1} If performing checks is required by the Pre,
+Pre'Class, Post, or Post'Class assertion policies (see *note 11.4.2::)
+in effect at the point of a corresponding aspect specification
+applicable to a given subprogram or entry, then the respective
+precondition or postcondition expressions are considered enabled.
+
+19.a/3
+ Ramification: {AI05-0290-1AI05-0290-1} If a class-wide
+ precondition or postcondition expression is enabled, it
+ remains enabled when inherited by an overriding subprogram,
+ even if the policy in effect is Ignore for the inheriting
+ subprogram.
+
+20/3
+{AI05-0273-1AI05-0273-1} An expression is potentially unevaluated if it
+occurs within:
+
+21/3
+ * any part of an if_expression other than the first condition;
+
+22/3
+ * a dependent_expression of a case_expression;
+
+23/3
+ * the right operand of a short-circuit control form; or
+
+24/3
+ * a membership_choice other than the first of a membership operation.
+
+25/3
+{AI05-0145-2AI05-0145-2} For a prefix X that denotes an object of a
+nonlimited type, the following attribute is defined:
+
+26/3
+X'Old
+ {AI05-0145-2AI05-0145-2} {AI05-0262-1AI05-0262-1}
+ {AI05-0273-1AI05-0273-1} For each X'Old in a
+ postcondition expression that is enabled, a constant is
+ implicitly declared at the beginning of the subprogram or
+ entry. The constant is of the type of X and is
+ initialized to the result of evaluating X (as an
+ expression) at the point of the constant declaration.
+ The value of X'Old in the postcondition expression is the
+ value of this constant; the type of X'Old is the type of
+ X. These implicit constant declarations occur in an
+ arbitrary order.
+
+27/3
+ {AI05-0145-2AI05-0145-2} {AI05-0262-1AI05-0262-1}
+ {AI05-0273-1AI05-0273-1} Reference to this attribute is
+ only allowed within a postcondition expression. The
+ prefix of an Old attribute_reference shall not contain a
+ Result attribute_reference, nor an Old
+ attribute_reference, nor a use of an entity declared
+ within the postcondition expression but not within prefix
+ itself (for example, the loop parameter of an enclosing
+ quantified_expression). The prefix of an Old
+ attribute_reference that is potentially unevaluated shall
+ statically denote an entity.
+
+27.a/3
+ Discussion: The prefix X can be any nonlimited object that
+ obeys the syntax for prefix other than the few exceptions
+ given above (discussed below). Useful cases are: the name of
+ a formal parameter of mode [in] out, the name of a global
+ variable updated by the subprogram, a function call passing
+ those as parameters, a subcomponent of those things, etc.
+
+27.b/3
+ A qualified expression can be used to make an arbitrary
+ expression into a valid prefix, so T'(X + Y)'Old is legal,
+ even though (X + Y)'Old is not. The value being saved here is
+ the sum of X and Y (a function result is an object). Of
+ course, in this case "+"(X, Y)'Old is also legal, but the
+ qualified expression is arguably more readable.
+
+27.c/3
+ Note that F(X)'Old and F(X'Old) are not necessarily equal.
+ The former calls F(X) and saves that value for later use
+ during the postcondition. The latter saves the value of X,
+ and during the postcondition, passes that saved value to F. In
+ most cases, the former is what one wants (but it is not always
+ legal, see below).
+
+27.d/3
+ If X has controlled parts, adjustment and finalization are
+ implied by the implicit constant declaration.
+
+27.e/3
+ If postconditions are disabled, we want the compiler to avoid
+ any overhead associated with saving 'Old values.
+
+27.f/3
+ 'Old makes no sense for limited types, because its
+ implementation involves copying. It might make semantic sense
+ to allow build-in-place, but it's not worth the trouble.
+
+27.g/3
+ Reason: {AI05-0273-1AI05-0273-1} Since the prefix is evaluated
+ unconditionally when the subprogram is called, we cannot allow
+ it to include values that do not exist at that time (like
+ 'Result and loop parameters of quantified_expressions). We
+ also do not allow it to include 'Old references, as those
+ would be redundant (the entire prefix is evaluated when the
+ subprogram is called), and allowing them would require some
+ sort of order to the implicit constant declarations (because
+ in A(I'Old)'Old, we surely would want the value of I'Old
+ evaluated before the A(I'Old) is evaluated).
+
+27.h/3
+ {AI05-0273-1AI05-0273-1} In addition, we only allow simple
+ names as the prefix of the Old attribute if the
+ attribute_reference might not be evaluated when the
+ postcondition expression is evaluated. This is necessary
+ because the Old prefixes have to be unconditionally evaluated
+ when the subprogram is called; the compiler cannot in general
+ know whether they will be needed in the postcondition
+ expression. To see the problem, consider:
+
+27.i/3
+ Table : array (1..10) of Integer := ...
+ procedure Bar (I : in out Natural)
+ with Post => I > 0 and then Table(I)'Old = 1; -- Illegal
+
+27.j/3
+ In this example, the compiler cannot know the value of I when
+ the subprogram returns (since the subprogram execution can
+ change it), and thus it does not know whether Table(I)'Old
+ will be needed then. Thus it has to always create an implicit
+ constant and evaluate Table(I) when Bar is called (because not
+ having the value when it is needed is not acceptable). But if
+ I = 0 when the subprogram is called, that evaluation will
+ raise Constraint_Error, and that will happen even if I is
+ unchanged by the subprogram and the value of Table(I)'Old is
+ not ultimately needed. It's easy to see how a similar problem
+ could occur for a dereference of an access type. This would
+ be mystifying (since the point of the short circuit is to
+ eliminate this possibility, but it cannot do so). Therefore,
+ we require the prefix of any Old attribute in such a context
+ to statically denote an object, which eliminates anything that
+ could change at during execution.
+
+27.k/3
+ It is easy to work around most errors that occur because of
+ this rule. Just move the 'Old to the outer object, before any
+ indexing, dereferences, or components. (That does not work
+ for function calls, however, nor does it work for array
+ indexing if the index can change during the execution of the
+ subprogram.)
+
+28/3
+{AI05-0145-2AI05-0145-2} For a prefix F that denotes a function
+declaration, the following attribute is defined:
+
+29/3
+F'Result
+ {AI05-0145-2AI05-0145-2} {AI05-0262-1AI05-0262-1} Within
+ a postcondition expression for function F, denotes the
+ result object of the function. The type of this
+ attribute is that of the function result except within a
+ Post'Class postcondition expression for a function with a
+ controlling result or with a controlling access result.
+ For a controlling result, the type of the attribute is
+ T'Class, where T is the function result type. For a
+ controlling access result, the type of the attribute is
+ an anonymous access type whose designated type is
+ T'Class, where T is the designated type of the function
+ result type.
+
+30/3
+ {AI05-0262-1AI05-0262-1} Use of this attribute is allowed
+ only within a postcondition expression for F.
+
+ _Dynamic Semantics_
+
+31/3
+{AI05-0145-2AI05-0145-2} {AI05-0247-1AI05-0247-1}
+{AI05-0290-1AI05-0290-1} Upon a call of the subprogram or entry, after
+evaluating any actual parameters, precondition checks are performed as
+follows:
+
+32/3
+ * The specific precondition check begins with the evaluation of the
+ specific precondition expression that applies to the subprogram or
+ entry, if it is enabled; if the expression evaluates to False,
+ Assertions.Assertion_Error is raised; if the expression is not
+ enabled, the check succeeds.
+
+33/3
+ * The class-wide precondition check begins with the evaluation of any
+ enabled class-wide precondition expressions that apply to the
+ subprogram or entry. If and only if all the class-wide
+ precondition expressions evaluate to False,
+ Assertions.Assertion_Error is raised.
+
+33.a/3
+ Ramification: The class-wide precondition expressions of the
+ entity itself as well as those of any parent or progenitor
+ operations are evaluated, as these expressions apply to the
+ corresponding operations of all descendants.
+
+33.b/3
+ Class-wide precondition checks are performed for all
+ appropriate calls, but only enabled precondition expressions
+ are evaluated. Thus, the check would be trivial if no
+ precondition expressions are enabled.
+
+34/3
+{AI05-0145-2AI05-0145-2} {AI05-0247-1AI05-0247-1}
+{AI05-0254-1AI05-0254-1} {AI05-0269-1AI05-0269-1} The precondition
+checks are performed in an arbitrary order, and if any of the class-wide
+precondition expressions evaluate to True, it is not specified whether
+the other class-wide precondition expressions are evaluated. The
+precondition checks and any check for elaboration of the subprogram body
+are performed in an arbitrary order. It is not specified whether in a
+call on a protected operation, the checks are performed before or after
+starting the protected action. For an entry call, the checks are
+performed prior to checking whether the entry is open.
+
+34.a/3
+ Reason: We need to explicitly allow short-circuiting of the
+ evaluation of the class-wide precondition check if any
+ expression fails, as it consists of multiple expressions; we
+ don't need a similar permission for the specific precondition
+ check as it consists only of a single expression. Nothing is
+ evaluated for the call after a check fails, as the failed
+ check propagates an exception.
+
+35/3
+{AI05-0145-2AI05-0145-2} {AI05-0247-1AI05-0247-1}
+{AI05-0254-1AI05-0254-1} {AI05-0262-1AI05-0262-1}
+{AI05-0290-1AI05-0290-1} Upon successful return from a call of the
+subprogram or entry, prior to copying back any by-copy in out or out
+parameters, the postcondition check is performed. This consists of the
+evaluation of any enabled specific and class-wide postcondition
+expressions that apply to the subprogram or entry. If any of the
+postcondition expressions evaluate to False, then
+Assertions.Assertion_Error is raised. The postcondition expressions are
+evaluated in an arbitrary order, and if any postcondition expression
+evaluates to False, it is not specified whether any other postcondition
+expressions are evaluated. The postcondition check, and any constraint
+or predicate checks associated with in out or out parameters are
+performed in an arbitrary order.
+
+35.a/3
+ Ramification: The class-wide postcondition expressions of the
+ entity itself as well as those of any parent or progenitor
+ operations are evaluated, as these apply to all descendants;
+ in contrast, only the specific postcondition of the entity
+ applies. Postconditions can always be evaluated inside the
+ invoked body.
+
+36/3
+{AI05-0145-2AI05-0145-2} {AI05-0262-1AI05-0262-1} If a precondition or
+postcondition check fails, the exception is raised at the point of the
+call[; the exception cannot be handled inside the called subprogram or
+entry]. Similarly, any exception raised by the evaluation of a
+precondition or postcondition expression is raised at the point of call.
+
+37/3
+{AI05-0145-2AI05-0145-2} {AI05-0247-1AI05-0247-1}
+{AI05-0254-1AI05-0254-1} {AI05-0262-1AI05-0262-1} For any subprogram or
+entry call (including dispatching calls), the checks that are performed
+to verify specific precondition expressions and specific and class-wide
+postcondition expressions are determined by those for the subprogram or
+entry actually invoked. Note that the class-wide postcondition
+expressions verified by the postcondition check that is part of a call
+on a primitive subprogram of type T includes all class-wide
+postcondition expressions originating in any progenitor of T[, even if
+the primitive subprogram called is inherited from a type T1 and some of
+the postcondition expressions do not apply to the corresponding
+primitive subprogram of T1].
+
+37.a/3
+ Ramification: This applies to access-to-subprogram calls,
+ dispatching calls, and to statically bound calls. We need
+ this rule to cover statically bound calls as well, as specific
+ pre- and postconditions are not inherited, but the subprogram
+ might be.
+
+37.b/3
+ For concrete subprograms, we require the original specific
+ postcondition to be evaluated as well as the inherited
+ class-wide postconditions in order that the semantics of an
+ explicitly defined wrapper that does nothing but call the
+ original subprogram is the same as that of an inherited
+ subprogram.
+
+37.c/3
+ Note that this rule does not apply to class-wide
+ preconditions; they have their own rules mentioned below.
+
+38/3
+{AI05-0145-2AI05-0145-2} {AI05-0247-1AI05-0247-1}
+{AI05-0254-1AI05-0254-1} The class-wide precondition check for a call to
+a subprogram or entry consists solely of checking the class-wide
+precondition expressions that apply to the denoted callable entity (not
+necessarily the one that is invoked).
+
+38.a/3
+ Ramification: For a dispatching call, we are talking about the
+ Pre'Class(es) that apply to the subprogram that the
+ dispatching call is resolving to, not the Pre'Class(es) for
+ the subprogram that is ultimately dispatched to. The
+ class-wide precondition of the resolved call is necessarily
+ the same or stronger than that of the invoked call. For a
+ statically bound call, these are the same; for an
+ access-to-subprogram, (which has no class-wide preconditions
+ of its own), we check the class-wide preconditions of the
+ invoked routine.
+
+38.b/3
+ Implementation Note: These rules imply that logically,
+ class-wide preconditions of routines must be checked at the
+ point of call (other than for access-to-subprogram calls,
+ which must be checked in the body, probably using a wrapper).
+ Specific preconditions that might be called with a dispatching
+ call or via an access-to-subprogram value must be checked
+ inside of the subprogram body. In contrast, the postcondition
+ checks always need to be checked inside the body of the
+ routine. Of course, an implementation can evaluate all of
+ these at the point of call for statically bound calls if the
+ implementation uses wrappers for dispatching bodies and for
+ 'Access values.
+
+38.c/3
+ There is no requirement for an implementation to generate
+ special code for routines that are imported from outside of
+ the Ada program. That's because there is a requirement on the
+ programmer that the use of interfacing aspects do not violate
+ Ada semantics (see B.1). That includes making pre- and
+ postcondition checks. For instance, if the implementation
+ expects routines to make their own postcondition checks in the
+ body before returning, C code can be assumed to do this (even
+ though that is highly unlikely). That's even though the
+ formal definition of those checks is that they are evaluated
+ at the call site. Note that pre- and postconditions can be
+ very useful for verification tools (even if they aren't
+ checked), because they tell the tool about the expectations on
+ the foreign code that it most likely cannot analyze.
+
+39/3
+{AI05-0145-2AI05-0145-2} {AI05-0247-1AI05-0247-1}
+{AI05-0254-1AI05-0254-1} For a call via an access-to-subprogram value,
+all precondition and postcondition checks performed are determined by
+the subprogram or entry denoted by the prefix of the Access attribute
+reference that produced the value.
+
+ NOTES
+
+40/3
+ 5 {AI05-0145-2AI05-0145-2} {AI05-0262-1AI05-0262-1} A precondition
+ is checked just before the call. If another task can change any
+ value that the precondition expression depends on, the precondition
+ need not hold within the subprogram or entry body.
+
+ _Extensions to Ada 2005_
+
+40.a/3
+ {AI05-0145-2AI05-0145-2} {AI05-0230-1AI05-0230-1}
+ {AI05-0247-1AI05-0247-1} {AI05-0254-1AI05-0254-1}
+ {AI05-0262-1AI05-0262-1} {AI05-0273-1AI05-0273-1}
+ {AI05-0274-1AI05-0274-1} Pre and Post aspects are new.
+
+\1f
+File: aarm2012.info, Node: 6.2, Next: 6.3, Prev: 6.1, Up: 6
+
+6.2 Formal Parameter Modes
+==========================
+
+1
+[A parameter_specification declares a formal parameter of mode in, in
+out, or out.]
+
+ _Static Semantics_
+
+2
+A parameter is passed either by copy or by reference. [When a parameter
+is passed by copy, the formal parameter denotes a separate object from
+the actual parameter, and any information transfer between the two
+occurs only before and after executing the subprogram. When a parameter
+is passed by reference, the formal parameter denotes (a view of) the
+object denoted by the actual parameter; reads and updates of the formal
+parameter directly reference the actual parameter object.]
+
+3/3
+{AI05-0142-4AI05-0142-4} {AI05-0262-1AI05-0262-1} A type is a by-copy
+type if it is an elementary type, or if it is a descendant of a private
+type whose full type is a by-copy type. A parameter of a by-copy type
+is passed by copy, unless the formal parameter is explicitly aliased.
+
+4
+A type is a by-reference type if it is a descendant of one of the
+following:
+
+5
+ * a tagged type;
+
+6
+ * a task or protected type;
+
+7/3
+ * {AI05-0096-1AI05-0096-1} an explicitly limited record type;
+
+7.a/3
+ This paragraph was deleted.{AI05-0096-1AI05-0096-1}
+
+8
+ * a composite type with a subcomponent of a by-reference type;
+
+9
+ * a private type whose full type is a by-reference type.
+
+10/3
+{AI05-0142-4AI05-0142-4} {AI05-0188-1AI05-0188-1} A parameter of a
+by-reference type is passed by reference, as is an explicitly aliased
+parameter of any type. Each value of a by-reference type has an
+associated object. For a parenthesized expression,
+qualified_expression, or type_conversion, this object is the one
+associated with the operand. For a conditional_expression, this object
+is the one associated with the evaluated dependent_expression.
+
+10.a
+ Ramification: By-reference parameter passing makes sense only
+ if there is an object to reference; hence, we define such an
+ object for each case.
+
+10.b
+ Since tagged types are by-reference types, this implies that
+ every value of a tagged type has an associated object. This
+ simplifies things, because we can define the tag to be a
+ property of the object, and not of the value of the object,
+ which makes it clearer that object tags never change.
+
+10.c
+ We considered simplifying things even more by making every
+ value (and therefore every expression) have an associated
+ object. After all, there is little semantic difference
+ between a constant object and a value. However, this would
+ cause problems for untagged types. In particular, we would
+ have to do a constraint check on every read of a type
+ conversion (or a renaming thereof) in certain cases.
+
+10.d/2
+ {AI95-00318-02AI95-00318-02} We do not want this definition to
+ depend on the view of the type; privateness is essentially
+ ignored for this definition. Otherwise, things would be
+ confusing (does the rule apply at the call site, at the site
+ of the declaration of the subprogram, at the site of the
+ return statement?), and requiring different calls to use
+ different mechanisms would be an implementation burden.
+
+10.e
+ *note C.6::, "*note C.6:: Shared Variable Control" says that a
+ composite type with an atomic or volatile subcomponent is a
+ by-reference type, among other things.
+
+10.f
+ Every value of a limited by-reference type is the value of one
+ and only one limited object. The associated object of a value
+ of a limited by-reference type is the object whose value it
+ represents. Two values of a limited by-reference type are the
+ same if and only if they represent the value of the same
+ object.
+
+10.g
+ We say "by-reference" above because these statements are not
+ always true for limited private types whose underlying type is
+ nonlimited (unfortunately).
+
+11/3
+{AI05-0240-1AI05-0240-1} For other parameters, it is unspecified whether
+the parameter is passed by copy or by reference.
+
+11.a/3
+ Discussion: {AI05-0005-1AI05-0005-1} There is no need to
+ incorporate the discussion of AI83-00178, which requires
+ pass-by-copy for certain kinds of actual parameters, while
+ allowing pass-by-reference for others. This is because we
+ explicitly indicate that a function creates an anonymous
+ constant object for its result (see *note 6.5::). We also
+ provide a special dispensation for instances of
+ Unchecked_Conversion to return by reference (see *note
+ 13.9::).
+
+ _Bounded (Run-Time) Errors_
+
+12/3
+{AI05-0240-1AI05-0240-1} If one name denotes a part of a formal
+parameter, and a second name denotes a part of a distinct formal
+parameter or an object that is not part of a formal parameter, then the
+two names are considered distinct access paths. If an object is of a
+type for which the parameter passing mechanism is not specified and is
+not an explicitly aliased parameter, then it is a bounded error to
+assign to the object via one access path, and then read the value of the
+object via a distinct access path, unless the first access path denotes
+a part of a formal parameter that no longer exists at the point of the
+second access [(due to leaving the corresponding callable construct).]
+The possible consequences are that Program_Error is raised, or the newly
+assigned value is read, or some old value of the object is read.
+
+12.a
+ Discussion: For example, if we call "P(X => Global_Variable, Y
+ => Global_Variable)", then within P, the names "X", "Y", and
+ "Global_Variable" are all distinct access paths. If
+ Global_Variable's type is neither pass-by-copy nor
+ pass-by-reference, then it is a bounded error to assign to
+ Global_Variable and then read X or Y, since the language does
+ not specify whether the old or the new value would be read.
+ On the other hand, if Global_Variable's type is pass-by-copy,
+ then the old value would always be read, and there is no
+ error. Similarly, if Global_Variable's type is defined by the
+ language to be pass-by-reference, then the new value would
+ always be read, and again there is no error.
+
+12.b
+ Reason: We are saying assign here, not update, because
+ updating any subcomponent is considered to update the
+ enclosing object.
+
+12.c
+ The "still exists" part is so that a read after the subprogram
+ returns is OK.
+
+12.d
+ If the parameter is of a by-copy type, then there is no issue
+ here -- the formal is not a view of the actual. If the
+ parameter is of a by-reference type, then the programmer may
+ depend on updates through one access path being visible
+ through some other access path, just as if the parameter were
+ of an access type.
+
+12.e
+ Implementation Note: The implementation can keep a copy in a
+ register of a parameter whose parameter-passing mechanism is
+ not specified. If a different access path is used to update
+ the object (creating a bounded error situation), then the
+ implementation can still use the value of the register, even
+ though the in-memory version of the object has been changed.
+ However, to keep the error properly bounded, if the
+ implementation chooses to read the in-memory version, it has
+ to be consistent -- it cannot then assume that something it
+ has proven about the register is true of the memory location.
+ For example, suppose the formal parameter is L, the value of
+ L(6) is now in a register, and L(6) is used in an
+ indexed_component as in "A(L(6)) := 99;", where A has bounds
+ 1..3. If the implementation can prove that the value for L(6)
+ in the register is in the range 1..3, then it need not perform
+ the constraint check if it uses the register value. However,
+ if the memory value of L(6) has been changed to 4, and the
+ implementation uses that memory value, then it had better not
+ alter memory outside of A.
+
+12.f
+ Note that the rule allows the implementation to pass a
+ parameter by reference and then keep just part of it in a
+ register, or, equivalently, to pass part of the parameter by
+ reference and another part by copy.
+
+12.g
+ Reason: We do not want to go so far as to say that the mere
+ presence of aliasing is wrong. We wish to be able to write
+ the following sorts of things in standard Ada:
+
+12.h
+ procedure Move ( Source : in String;
+ Target : out String;
+ Drop : in Truncation := Error;
+ Justify : in Alignment := Left;
+ Pad : in Character := Space);
+ -- Copies elements from Source to Target (safely if they overlap)
+
+12.i
+ This is from the standard string handling package. It would
+ be embarrassing if this couldn't be written in Ada!
+
+12.j
+ The "then" before "read" in the rule implies that the
+ implementation can move a read to an earlier place in the
+ code, but not to a later place after a potentially aliased
+ assignment. Thus, if the subprogram reads one of its
+ parameters into a local variable, and then updates another
+ potentially aliased one, the local copy is safe -- it is known
+ to have the old value. For example, the above-mentioned Move
+ subprogram can be implemented by copying Source into a local
+ variable before assigning into Target.
+
+12.k
+ For an assignment_statement assigning one array parameter to
+ another, the implementation has to check which direction to
+ copy at run time, in general, in case the actual parameters
+ are overlapping slices. For example:
+
+12.l
+ procedure Copy(X : in out String; Y: String) is
+ begin
+ X := Y;
+ end Copy;
+
+12.m
+ It would be wrong for the compiler to assume that X and Y do
+ not overlap (unless, of course, it can prove otherwise).
+
+ NOTES
+
+13
+ 6 A formal parameter of mode in is a constant view (see *note
+ 3.3::); it cannot be updated within the subprogram_body.
+
+ _Extensions to Ada 83_
+
+13.a
+ The value of an out parameter may be read. An out parameter
+ is treated like a declared variable without an explicit
+ initial expression.
+
+ _Wording Changes from Ada 83_
+
+13.b
+ Discussion of copy-in for parts of out parameters is now
+ covered in *note 6.4.1::, "*note 6.4.1:: Parameter
+ Associations".
+
+13.c
+ The concept of a by-reference type is new to Ada 95.
+
+13.d
+ We now cover in a general way in *note 3.7.2:: the rule
+ regarding erroneous execution when a discriminant is changed
+ and one of the parameters depends on the discriminant.
+
+ _Wording Changes from Ada 2005_
+
+13.e/3
+ {AI05-0096-1AI05-0096-1} Correction: Corrected so that limited
+ derived types are by-reference only if their parent is.
+
+13.f/3
+ {AI05-0142-4AI05-0142-4} Defined that explicitly aliased
+ parameters (see *note 6.1::) are always passed by reference.
+
+\1f
+File: aarm2012.info, Node: 6.3, Next: 6.4, Prev: 6.2, Up: 6
+
+6.3 Subprogram Bodies
+=====================
+
+1
+[A subprogram_body specifies the execution of a subprogram.]
+
+ _Syntax_
+
+2/3
+ {AI95-00218-03AI95-00218-03} {AI05-0183-1AI05-0183-1}
+ subprogram_body ::=
+ [overriding_indicator]
+ subprogram_specification
+ [aspect_specification] is
+ declarative_part
+ begin
+ handled_sequence_of_statements
+ end [designator];
+
+3
+ If a designator appears at the end of a subprogram_body, it shall
+ repeat the defining_designator of the subprogram_specification.
+
+ _Legality Rules_
+
+4
+[In contrast to other bodies,] a subprogram_body need not be the
+completion of a previous declaration[, in which case the body declares
+the subprogram]. If the body is a completion, it shall be the
+completion of a subprogram_declaration or
+generic_subprogram_declaration. The profile of a subprogram_body that
+completes a declaration shall conform fully to that of the declaration.
+
+ _Static Semantics_
+
+5
+A subprogram_body is considered a declaration. It can either complete a
+previous declaration, or itself be the initial declaration of the
+subprogram.
+
+ _Dynamic Semantics_
+
+6
+The elaboration of a nongeneric subprogram_body has no other effect than
+to establish that the subprogram can from then on be called without
+failing the Elaboration_Check.
+
+6.a
+ Ramification: See *note 12.2:: for elaboration of a generic
+ body. Note that protected subprogram_bodies never get
+ elaborated; the elaboration of the containing protected_body
+ allows them to be called without failing the
+ Elaboration_Check.
+
+7
+[The execution of a subprogram_body is invoked by a subprogram call.]
+For this execution the declarative_part is elaborated, and the
+handled_sequence_of_statements is then executed.
+
+ _Examples_
+
+8
+Example of procedure body:
+
+9
+ procedure Push(E : in Element_Type; S : in out Stack) is
+ begin
+ if S.Index = S.Size then
+ raise Stack_Overflow;
+ else
+ S.Index := S.Index + 1;
+ S.Space(S.Index) := E;
+ end if;
+ end Push;
+
+10
+Example of a function body:
+
+11
+ function Dot_Product(Left, Right : Vector) return Real is
+ Sum : Real := 0.0;
+ begin
+ Check(Left'First = Right'First and Left'Last = Right'Last);
+ for J in Left'Range loop
+ Sum := Sum + Left(J)*Right(J);
+ end loop;
+ return Sum;
+ end Dot_Product;
+
+ _Extensions to Ada 83_
+
+11.a
+ A renaming_declaration may be used instead of a
+ subprogram_body.
+
+ _Wording Changes from Ada 83_
+
+11.b
+ The syntax rule for subprogram_body now uses the syntactic
+ category handled_sequence_of_statements.
+
+11.c
+ The declarative_part of a subprogram_body is now required;
+ that doesn't make any real difference, because a
+ declarative_part can be empty.
+
+11.d
+ We have incorporated some rules from RM83-6.5 here.
+
+11.e
+ RM83 forgot to restrict the definition of elaboration of a
+ subprogram_body to nongenerics.
+
+ _Wording Changes from Ada 95_
+
+11.f/2
+ {AI95-00218-03AI95-00218-03} Overriding_indicator is added to
+ subprogram_body.
+
+ _Extensions to Ada 2005_
+
+11.g/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a subprogram_body. This is described in *note
+ 13.1.1::.
+
+* Menu:
+
+* 6.3.1 :: Conformance Rules
+* 6.3.2 :: Inline Expansion of Subprograms
+
+\1f
+File: aarm2012.info, Node: 6.3.1, Next: 6.3.2, Up: 6.3
+
+6.3.1 Conformance Rules
+-----------------------
+
+1
+[When subprogram profiles are given in more than one place, they are
+required to conform in one of four ways: type conformance, mode
+conformance, subtype conformance, or full conformance.]
+
+ _Static Semantics_
+
+2/1
+{8652/00118652/0011} {AI95-00117-01AI95-00117-01} [As explained in *note
+B.1::, "*note B.1:: Interfacing Aspects", a convention can be specified
+for an entity.] Unless this International Standard states otherwise,
+the default convention of an entity is Ada. [For a callable entity or
+access-to-subprogram type, the convention is called the calling
+convention.] The following conventions are defined by the language:
+
+3/3
+ * {AI05-0229-1AI05-0229-1} The default calling convention for any
+ subprogram not listed below is Ada. [The Convention aspect may be
+ specified to override the default calling convention (see *note
+ B.1::)].
+
+3.a
+ Ramification: See also the rule about renamings-as-body in
+ *note 8.5.4::.
+
+4
+ * The Intrinsic calling convention represents subprograms that are
+ "built in" to the compiler. The default calling convention is
+ Intrinsic for the following:
+
+5
+ * an enumeration literal;
+
+6
+ * a "/=" operator declared implicitly due to the
+ declaration of "=" (see *note 6.6::);
+
+7
+ * any other implicitly declared subprogram unless it is a
+ dispatching operation of a tagged type;
+
+8
+ * an inherited subprogram of a generic formal tagged type
+ with unknown discriminants;
+
+8.a.1/1
+ Reason: Consider:
+
+8.a.2/1
+ package P is
+ type Root is tagged null record;
+ procedure Proc(X: Root);
+ end P;
+
+8.a.3/1
+ generic
+ type Formal(<>) is new Root with private;
+ package G is
+ ...
+ end G;
+
+8.a.4/1
+ package body G is
+ ...
+ X: Formal := ...;
+ ...
+ Proc(X); -- This is a dispatching call in Instance, because
+ -- the actual type for Formal is class-wide.
+ ...
+ -- Proc'Access would be illegal here, because it is of
+ -- convention Intrinsic, by the above rule.
+ end G;
+
+8.a.5/1
+ type Actual is new Root with ...;
+ procedure Proc(X: Actual);
+ package Instance is new G(Formal => Actual'Class);
+ -- It is legal to pass in a class-wide actual, because Formal
+ -- has unknown discriminants.
+
+8.a.6/1
+ Within Instance, all calls to Proc will be dispatching calls,
+ so Proc doesn't really exist in machine code, so we wish to
+ avoid taking 'Access of it. This rule applies to those cases
+ where the actual type might be class-wide, and makes these
+ Intrinsic, thus forbidding 'Access.
+
+9
+ * an attribute that is a subprogram;
+
+10/2
+ * {AI95-00252-01AI95-00252-01} a subprogram declared
+ immediately within a protected_body;
+
+10.1/2
+ * {AI95-00252-01AI95-00252-01} {AI95-00407-01AI95-00407-01}
+ any prefixed view of a subprogram (see *note 4.1.3::).
+
+10.a/2
+ Reason: The profile of a prefixed view is different than the
+ "real" profile of the subprogram (it doesn't have the first
+ parameter), so we don't want to be able to take 'Access of it,
+ as that would require generating a wrapper of some sort.
+
+11
+ [The Access attribute is not allowed for Intrinsic subprograms.]
+
+11.a
+ Ramification: The Intrinsic calling convention really
+ represents any number of calling conventions at the machine
+ code level; the compiler might have a different instruction
+ sequence for each intrinsic. That's why the Access attribute
+ is disallowed. We do not wish to require the implementation
+ to generate an out of line body for an intrinsic.
+
+11.b/3
+ {AI05-0229-1AI05-0229-1} Whenever we wish to disallow the
+ Access attribute in order to ease implementation, we make the
+ subprogram Intrinsic. Several language-defined subprograms
+ have "with Convention => Intrinsic;". An implementation might
+ actually implement this as "with Import => True, Convention =>
+ Intrinsic;", if there is really no body, and the
+ implementation of the subprogram is built into the code
+ generator.
+
+11.c
+ Subprograms declared in protected_bodies will generally have a
+ special calling convention so as to pass along the
+ identification of the current instance of the protected type.
+ The convention is not protected since such local subprograms
+ need not contain any "locking" logic since they are not
+ callable via "external" calls; this rule prevents an access
+ value designating such a subprogram from being passed outside
+ the protected unit.
+
+11.d
+ The "implicitly declared subprogram" above refers to
+ predefined operators (other than the "=" of a tagged type) and
+ the inherited subprograms of untagged types.
+
+12
+ * The default calling convention is protected for a protected
+ subprogram, and for an access-to-subprogram type with the reserved
+ word protected in its definition.
+
+13
+ * The default calling convention is entry for an entry.
+
+13.1/3
+ * {AI95-00254-01AI95-00254-01} {AI95-00409-01AI95-00409-01}
+ {AI05-0264-1AI05-0264-1} The calling convention for an anonymous
+ access-to-subprogram parameter or anonymous access-to-subprogram
+ result is protected if the reserved word protected appears in its
+ definition; otherwise, it is the convention of the subprogram that
+ contains the parameter.
+
+13.a/2
+ Ramification: The calling convention for other anonymous
+ access-to-subprogram types is Ada.
+
+13.2/1
+ * {8652/00118652/0011} {AI95-00117-01AI95-00117-01} [If not specified
+ above as Intrinsic, the calling convention for any inherited or
+ overriding dispatching operation of a tagged type is that of the
+ corresponding subprogram of the parent type.] The default calling
+ convention for a new dispatching operation of a tagged type is the
+ convention of the type.
+
+13.a.1/1
+ Reason: The first rule is officially stated in *note 3.9.2::.
+ The second is intended to make interfacing to foreign OOP
+ languages easier, by making the default be that the type and
+ operations all have the same convention.
+
+14/3
+{AI05-0229-1AI05-0229-1} Of these four conventions, only Ada and
+Intrinsic are allowed as a convention_identifier in the specification of
+a Convention aspect.
+
+14.a/3
+ Discussion: {AI05-0229-1AI05-0229-1} The names of the
+ protected and entry calling conventions cannot be used in the
+ specification of Convention. Note that protected and entry
+ are reserved words.
+
+15/2
+{AI95-00409-01AI95-00409-01} Two profiles are type conformant if they
+have the same number of parameters, and both have a result if either
+does, and corresponding parameter and result types are the same, or, for
+access parameters or access results, corresponding designated types are
+the same, or corresponding designated profiles are type conformant.
+
+15.a/2
+ Discussion: {AI95-00409-01AI95-00409-01} For anonymous
+ access-to-object parameters, the designated types have to be
+ the same for type conformance, not the access types, since in
+ general each access parameter has its own anonymous access
+ type, created when the subprogram is called. Of course,
+ corresponding parameters have to be either both access
+ parameters or both not access parameters.
+
+15.b/2
+ {AI95-00409-01AI95-00409-01} Similarly, for anonymous
+ access-to-subprogram parameters, the designated profiles of
+ the types, not the types themselves, have to be conformant.
+
+16/3
+{AI95-00318-02AI95-00318-02} {AI95-00409-01AI95-00409-01}
+{AI05-0142-4AI05-0142-4} Two profiles are mode conformant if:
+
+16.1/3
+ * {AI05-0142-4AI05-0142-4} {AI05-0262-1AI05-0262-1} they are type
+ conformant; and
+
+16.2/3
+ * {AI05-0142-4AI05-0142-4} corresponding parameters have identical
+ modes and both or neither are explicitly aliased parameters; and
+
+16.3/3
+ * {AI05-0207-1AI05-0207-1} for corresponding access parameters and
+ any access result type, the designated subtypes statically match
+ and either both or neither are access-to-constant, or the
+ designated profiles are subtype conformant.
+
+17/3
+{AI05-0239-1AI05-0239-1} Two profiles are subtype conformant if they are
+mode conformant, corresponding subtypes of the profile statically match,
+and the associated calling conventions are the same. The profile of a
+generic formal subprogram is not subtype conformant with any other
+profile.
+
+17.a
+ Ramification:
+
+18/3
+{AI05-0134-1AI05-0134-1} {AI05-0262-1AI05-0262-1} Two profiles are fully
+conformant if they are subtype conformant, if they have
+access-to-subprogram results whose designated profiles are fully
+conformant, and for corresponding parameters:
+
+18.1/3
+ * {AI05-0262-1AI05-0262-1} they have the same names; and
+
+18.2/3
+ * {AI05-0046-1AI05-0046-1} both or neither have null_exclusions; and
+
+18.3/3
+ * neither have default_expressions, or they both have
+ default_expressions that are fully conformant with one another; and
+
+18.4/3
+ * {AI05-0134-1AI05-0134-1} for access-to-subprogram parameters, the
+ designated profiles are fully conformant.
+
+18.a
+ Ramification: Full conformance requires subtype conformance,
+ which requires the same calling conventions. However, the
+ calling convention of the declaration and body of a subprogram
+ or entry are always the same by definition.
+
+18.b/3
+ Reason: {AI05-0046-1AI05-0046-1} The part about
+ null_exclusions is necessary to prevent controlling parameters
+ from having different exclusions, as such a parameter is
+ defined to exclude null whether or not an exclusion is given.
+
+18.c/3
+ {AI05-0134-1AI05-0134-1} The parts about access-to-subprogram
+ parameters and results is necessary to prevent such types from
+ having different default_expressions in the specification and
+ body of a subprogram. If that was allowed, it would be
+ undefined which default_expression was used in a call of an
+ access-to-subprogram parameter.
+
+19
+Two expressions are fully conformant if, [after replacing each use of an
+operator with the equivalent function_call:]
+
+20
+ * each constituent construct of one corresponds to an instance of the
+ same syntactic category in the other, except that an expanded name
+ may correspond to a direct_name (or character_literal) or to a
+ different expanded name in the other; and
+
+21
+ * each direct_name, character_literal, and selector_name that is not
+ part of the prefix of an expanded name in one denotes the same
+ declaration as the corresponding direct_name, character_literal, or
+ selector_name in the other; and
+
+21.a
+ Ramification: Note that it doesn't say "respectively" because
+ a direct_name can correspond to a selector_name, and
+ vice-versa, by the previous bullet. This rule allows the
+ prefix of an expanded name to be removed, or replaced with a
+ different prefix that denotes a renaming of the same entity.
+ However, it does not allow a direct_name or selector_name to
+ be replaced with one denoting a distinct renaming (except for
+ direct_names and selector_names in prefixes of expanded
+ names). Note that calls using operator notation are
+ equivalent to calls using prefix notation.
+
+21.b
+ Given the following declarations:
+
+21.c
+ package A is
+ function F(X : Integer := 1) return Boolean;
+ end A;
+
+21.c.1/3
+ {AI05-0005-1AI05-0005-1} with A;
+ package B is
+ package A_View renames A;
+ function F_View(X : Integer := 9999) return Boolean renames A.F;
+ end B;
+
+21.d
+ with A, B; use A, B;
+ procedure Main is ...
+
+21.e
+ Within Main, the expressions "F", "A.F", "B.A_View.F", and
+ "A_View.F" are all fully conformant with one another.
+ However, "F" and "F_View" are not fully conformant. If they
+ were, it would be bad news, since the two denoted views have
+ different default_expressions.
+
+21.1/3
+ * {8652/00188652/0018} {AI95-00175-01AI95-00175-01}
+ {AI05-0092-1AI05-0092-1} each attribute_designator in one is the
+ same as the corresponding attribute_designator in the other; and
+
+22
+ * each primary that is a literal in one has the same value as the
+ corresponding literal in the other.
+
+22.a
+ Ramification: The literals may be written differently.
+
+22.b
+ Ramification: Note that the above definition makes full
+ conformance a transitive relation.
+
+23
+Two known_discriminant_parts are fully conformant if they have the same
+number of discriminants, and discriminants in the same positions have
+the same names, statically matching subtypes, and default_expressions
+that are fully conformant with one another.
+
+24
+Two discrete_subtype_definitions are fully conformant if they are both
+subtype_indications or are both ranges, the subtype_marks (if any)
+denote the same subtype, and the corresponding simple_expressions of the
+ranges (if any) fully conform.
+
+24.a
+ Ramification: In the subtype_indication case, any ranges have
+ to be corresponding; that is, two subtype_indications cannot
+ conform unless both or neither has a range.
+
+24.b
+ Discussion: This definition is used in *note 9.5.2::, "*note
+ 9.5.2:: Entries and Accept Statements" for the conformance
+ required between the discrete_subtype_definitions of an
+ entry_declaration for a family of entries and the
+ corresponding entry_index_specification of the entry_body.
+
+24.1/2
+{AI95-00345-01AI95-00345-01} {AI95-00397-01AI95-00397-01} The prefixed
+view profile of a subprogram is the profile obtained by omitting the
+first parameter of that subprogram. There is no prefixed view profile
+for a parameterless subprogram. For the purposes of defining subtype
+and mode conformance, the convention of a prefixed view profile is
+considered to match that of either an entry or a protected operation.
+
+24.c/2
+ Discussion: This definition is used to define how primitive
+ subprograms of interfaces match operations in task and
+ protected type definitions (see *note 9.1:: and *note 9.4::).
+
+24.d/2
+ Reason: The weird rule about conventions is pretty much
+ required for synchronized interfaces to make any sense. There
+ will be wrappers all over the place for interfaces anyway. Of
+ course, this doesn't imply that entries have the same
+ convention as protected operations.
+
+ _Implementation Permissions_
+
+25
+An implementation may declare an operator declared in a language-defined
+library unit to be intrinsic.
+
+ _Extensions to Ada 83_
+
+25.a
+ The rules for full conformance are relaxed -- they are now
+ based on the structure of constructs, rather than the sequence
+ of lexical elements. This implies, for example, that "(X, Y:
+ T)" conforms fully with "(X: T; Y: T)", and "(X: T)" conforms
+ fully with "(X: in T)".
+
+ _Wording Changes from Ada 95_
+
+25.b/2
+ {8652/00118652/0011} {AI95-00117-01AI95-00117-01} Corrigendum:
+ Clarified that the default convention is Ada. Also clarified
+ that the convention of a primitive operation of a tagged type
+ is the same as that of the type.
+
+25.c/2
+ {8652/00188652/0018} {AI95-00175-01AI95-00175-01} Corrigendum:
+ Added wording to ensure that two attributes conform only if
+ they have the same attribute_designator.
+
+25.d/2
+ {AI95-00252-01AI95-00252-01} {AI95-00254-01AI95-00254-01}
+ {AI95-00407-01AI95-00407-01} Defined the calling convention
+ for anonymous access-to-subprogram types and for prefixed
+ views of subprograms (see *note 4.1.3::).
+
+25.e/2
+ {AI95-00318-02AI95-00318-02} Defined the conformance of access
+ result types (see *note 6.1::).
+
+25.f/2
+ {AI95-00345-01AI95-00345-01} {AI95-00397-01AI95-00397-01}
+ Defined the prefixed view profile of subprograms for later
+ use.
+
+25.g/2
+ {AI95-00409-01AI95-00409-01} Defined the conformance of
+ anonymous access-to-subprogram parameters.
+
+ _Incompatibilities With Ada 2005_
+
+25.h/3
+ {AI05-0046-1AI05-0046-1} Correction: Now require
+ null_exclusions to match for full conformance. While this is
+ technically incompatible with Ada 2005 as defined by Amendment
+ 1, it is a new Ada 2005 feature and it is unlikely that users
+ have been intentionally taking advantage of the ability to
+ write mismatching exclusions. In any case, it is easy to fix:
+ add a null_exclusion where needed for conformance.
+
+25.i/3
+ {AI05-0134-1AI05-0134-1} Correction: Now require full
+ conformance of anonymous access-to-subprogram parameters and
+ results for full conformance. This is necessary so that there
+ is no confusion about the default expression that is used for
+ a call. While this is technically incompatible with Ada 2005
+ as defined by Amendment 1, it is a new Ada 2005 feature and it
+ is unlikely that users have been intentionally taking
+ advantage and writing different default expressions. In any
+ case, it is easy to fix: change any default expressions that
+ don't conform so that they do conform.
+
+25.j/3
+ {AI05-0207-1AI05-0207-1} Correction: Now include the presence
+ or absence of constant in access parameters to be considered
+ when checking mode conformance. This is necessary to prevent
+ modification of constants. While this is technically
+ incompatible with Ada 2005 as defined by Amendment 1, it is a
+ new Ada 2005 feature and it is unlikely that users have been
+ intentionally taking advantage and writing mismatching access
+ types.
+
+ _Wording Changes from Ada 2005_
+
+25.k/3
+ {AI05-0142-4AI05-0142-4} Explicitly aliased parameters are
+ included as part of mode conformance (since it affects the
+ parameter passing mechanism).
+
+\1f
+File: aarm2012.info, Node: 6.3.2, Prev: 6.3.1, Up: 6.3
+
+6.3.2 Inline Expansion of Subprograms
+-------------------------------------
+
+1
+[Subprograms may be expanded in line at the call site.]
+
+Paragraphs 2 through 4 were moved to *note Annex J::, "*note Annex J::
+Obsolescent Features".
+
+ _Static Semantics_
+
+5/3
+{AI05-0229-1AI05-0229-1} For a callable entity or a generic subprogram,
+the following language-defined representation aspect may be specified:
+
+5.1/3
+Inline
+ The type of aspect Inline is Boolean. When aspect Inline
+ is True for a callable entity, inline expansion is
+ desired for all calls to that entity. When aspect Inline
+ is True for a generic subprogram, inline expansion is
+ desired for all calls to all instances of that generic
+ subprogram.
+
+5.2/3
+ If directly specified, the aspect_definition shall be a
+ static expression. [This aspect is never inherited;] if
+ not directly specified, the aspect is False.
+
+5.a/3
+ Aspect Description for Inline: For efficiency, Inline calls
+ are requested for a subprogram.
+
+5.b/3
+ This paragraph was deleted.{AI05-0229-1AI05-0229-1}
+
+5.c/3
+ This paragraph was deleted.
+
+5.d/3
+ This paragraph was deleted.
+
+5.e/3
+ Ramification: {AI05-0229-1AI05-0229-1} The meaning of a
+ subprogram can be changed by inline expansion as requested by
+ aspect Inline only in the presence of failing checks (see
+ *note 11.6::).
+
+ _Implementation Permissions_
+
+6/3
+{AI05-0229-1AI05-0229-1} For each call, an implementation is free to
+follow or to ignore the recommendation determined by the Inline aspect.
+
+6.a
+ Ramification: Note, in particular, that the recommendation
+ cannot always be followed for a recursive call, and is often
+ infeasible for entries. Note also that the implementation can
+ inline calls even when no such desire was expressed via the
+ Inline aspect, so long as the semantics of the program remains
+ unchanged.
+
+ _Incompatibilities With Ada 83_
+
+7.a/3
+ This paragraph was deleted.{AI95-00309-01AI95-00309-01}
+ {AI05-0229-1AI05-0229-1}
+
+ _Extensions to Ada 83_
+
+7.b/3
+ This paragraph was deleted.{AI05-0229-1AI05-0229-1}
+
+ _Extensions to Ada 95_
+
+7.c/3
+ This paragraph was deleted.{AI95-00309-01AI95-00309-01}
+ {AI05-0229-1AI05-0229-1}
+
+ _Extensions to Ada 2005_
+
+7.d/3
+ {AI05-0229-1AI05-0229-1} Aspect Inline is new; pragma Inline
+ is now obsolescent.
+
+\1f
+File: aarm2012.info, Node: 6.4, Next: 6.5, Prev: 6.3, Up: 6
+
+6.4 Subprogram Calls
+====================
+
+1
+A subprogram call is either a procedure_call_statement or a
+function_call; [it invokes the execution of the subprogram_body. The
+call specifies the association of the actual parameters, if any, with
+formal parameters of the subprogram.]
+
+ _Syntax_
+
+2
+ procedure_call_statement ::=
+ procedure_name;
+ | procedure_prefix actual_parameter_part;
+
+3
+ function_call ::=
+ function_name
+ | function_prefix actual_parameter_part
+
+3.a/3
+ To be honest: {AI05-0005-1AI05-0005-1} For the purpose of
+ non-syntax rules, infix operator calls are considered
+ function_calls. See *note 6.6::.
+
+4
+ actual_parameter_part ::=
+ (parameter_association {, parameter_association})
+
+5
+ parameter_association ::=
+ [formal_parameter_selector_name =>] explicit_actual_parameter
+
+6
+ explicit_actual_parameter ::= expression | variable_name
+
+7
+ A parameter_association is named or positional according to whether
+ or not the formal_parameter_selector_name (*note 4.1.3: S0099.) is
+ specified. Any positional associations shall precede any named
+ associations. Named associations are not allowed if the prefix in
+ a subprogram call is an attribute_reference (*note 4.1.4: S0100.).
+
+7.a
+ Ramification: This means that the formal parameter names used
+ in describing predefined attributes are to aid presentation of
+ their semantics, but are not intended for use in actual calls.
+
+ _Name Resolution Rules_
+
+8/2
+{AI95-00310-01AI95-00310-01} The name or prefix given in a
+procedure_call_statement shall resolve to denote a callable entity that
+is a procedure, or an entry renamed as (viewed as) a procedure. The
+name or prefix given in a function_call shall resolve to denote a
+callable entity that is a function. The name or prefix shall not
+resolve to denote an abstract subprogram unless it is also a dispatching
+subprogram. [When there is an actual_parameter_part (*note 6.4:
+S0180.), the prefix can be an implicit_dereference (*note 4.1: S0095.)
+of an access-to-subprogram value.]
+
+8.a.1/2
+ Discussion: {AI95-00310-01AI95-00310-01} This rule is talking
+ about dispatching operations (which is a static concept) and
+ not about dispatching calls (which is a dynamic concept).
+
+8.a
+ Ramification: The function can be an operator, enumeration
+ literal, attribute that is a function, etc.
+
+9
+A subprogram call shall contain at most one association for each formal
+parameter. Each formal parameter without an association shall have a
+default_expression (in the profile of the view denoted by the name or
+prefix). [This rule is an overloading rule (see *note 8.6::).]
+
+9.a/3
+ Proof: {AI05-0240-1AI05-0240-1} All Name Resolution Rules are
+ overloading rules, see *note 8.6::.
+
+ _Dynamic Semantics_
+
+10/2
+{AI95-00345-01AI95-00345-01} For the execution of a subprogram call, the
+name or prefix of the call is evaluated, and each parameter_association
+(*note 6.4: S0181.) is evaluated (see *note 6.4.1::). If a
+default_expression (*note 3.7: S0063.) is used, an implicit
+parameter_association (*note 6.4: S0181.) is assumed for this rule.
+These evaluations are done in an arbitrary order. The subprogram_body
+(*note 6.3: S0177.) is then executed, or a call on an entry or protected
+subprogram is performed (see *note 3.9.2::). Finally, if the subprogram
+completes normally, then after it is left, any necessary assigning back
+of formal to actual parameters occurs (see *note 6.4.1::).
+
+10.a
+ Discussion: The implicit association for a default is only for
+ this run-time rule. At compile time, the visibility rules are
+ applied to the default at the place where it occurs, not at
+ the place of a call.
+
+10.b
+ To be honest: If the subprogram is inherited, see *note 3.4::,
+ "*note 3.4:: Derived Types and Classes".
+
+10.c
+ If the subprogram is protected, see *note 9.5.1::, "*note
+ 9.5.1:: Protected Subprograms and Protected Actions".
+
+10.d
+ If the subprogram is really a renaming of an entry, see *note
+ 9.5.3::, "*note 9.5.3:: Entry Calls".
+
+10.d.1/2
+ {AI95-00345-01AI95-00345-01} If the subprogram is implemented
+ by an entry or protected subprogram, it will be treated as a
+ dispatching call to the corresponding entry (see *note
+ 9.5.3::, "*note 9.5.3:: Entry Calls") or protected subprogram
+ (see *note 9.5.1::, "*note 9.5.1:: Protected Subprograms and
+ Protected Actions").
+
+10.e/2
+ {AI95-00348-01AI95-00348-01} Normally, the subprogram_body
+ that is executed by the above rule is the one for the
+ subprogram being called. For an enumeration literal,
+ implicitly declared (but noninherited) subprogram, null
+ procedure, or an attribute that is a subprogram, an implicit
+ body is assumed. For a dispatching call, *note 3.9.2::,
+ "*note 3.9.2:: Dispatching Operations of Tagged Types" defines
+ which subprogram_body is executed.
+
+10.1/2
+{AI95-00407-01AI95-00407-01} If the name or prefix of a subprogram call
+denotes a prefixed view (see *note 4.1.3::), the subprogram call is
+equivalent to a call on the underlying subprogram, with the first actual
+parameter being provided by the prefix of the prefixed view (or the
+Access attribute of this prefix if the first formal parameter is an
+access parameter), and the remaining actual parameters given by the
+actual_parameter_part, if any.
+
+11/2
+{AI95-00318-02AI95-00318-02} The exception Program_Error is raised at
+the point of a function_call if the function completes normally without
+executing a return statement.
+
+11.a
+ Discussion: We are committing to raising the exception at the
+ point of call, for uniformity -- see AI83-00152. This happens
+ after the function is left, of course.
+
+11.b
+ Note that there is no name for suppressing this check, since
+ the check imposes no time overhead and minimal space overhead
+ (since it can usually be statically eliminated as dead code).
+
+12/2
+{AI95-00231-01AI95-00231-01} A function_call denotes a constant, as
+defined in *note 6.5::; the nominal subtype of the constant is given by
+the nominal subtype of the function result.
+
+ _Examples_
+
+13
+Examples of procedure calls:
+
+14
+ Traverse_Tree; -- see *note 6.1::
+ Print_Header(128, Title, True); -- see *note 6.1::
+
+15
+ Switch(From => X, To => Next); -- see *note 6.1::
+ Print_Header(128, Header => Title, Center => True); -- see *note 6.1::
+ Print_Header(Header => Title, Center => True, Pages => 128); -- see *note 6.1::
+
+16
+Examples of function calls:
+
+17
+ Dot_Product(U, V) -- see *note 6.1:: and *note 6.3::
+ Clock -- see *note 9.6::
+ F.all -- presuming F is of an access-to-subprogram type -- see *note 3.10::
+
+18
+Examples of procedures with default expressions:
+
+19
+ procedure Activate(Process : in Process_Name;
+ After : in Process_Name := No_Process;
+ Wait : in Duration := 0.0;
+ Prior : in Boolean := False);
+
+20/3
+ {AI05-0299-1AI05-0299-1} procedure Pair(Left, Right : in Person_Name := new Person(M)); -- see *note 3.10.1::
+
+21
+Examples of their calls:
+
+22
+ Activate(X);
+ Activate(X, After => Y);
+ Activate(X, Wait => 60.0, Prior => True);
+ Activate(X, Y, 10.0, False);
+
+23/3
+ {AI05-0299-1AI05-0299-1} Pair;
+ Pair(Left => new Person(F), Right => new Person(M));
+
+ NOTES
+
+24
+ 7 If a default_expression is used for two or more parameters in a
+ multiple parameter_specification (*note 6.1: S0175.), the
+ default_expression (*note 3.7: S0063.) is evaluated once for each
+ omitted parameter. Hence in the above examples, the two calls of
+ Pair are equivalent.
+
+ _Examples_
+
+25
+Examples of overloaded subprograms:
+
+26
+ procedure Put(X : in Integer);
+ procedure Put(X : in String);
+
+27
+ procedure Set(Tint : in Color);
+ procedure Set(Signal : in Light);
+
+28
+Examples of their calls:
+
+29
+ Put(28);
+ Put("no possible ambiguity here");
+
+30
+ Set(Tint => Red);
+ Set(Signal => Red);
+ Set(Color'(Red));
+
+31
+ -- Set(Red) would be ambiguous since Red may
+ -- denote a value either of type Color or of type Light
+
+ _Wording Changes from Ada 83_
+
+31.a
+ We have gotten rid of parameters "of the form of a type
+ conversion" (see RM83-6.4.1(3)). The new view semantics of
+ type_conversions allows us to use normal type_conversions
+ instead.
+
+31.b
+ We have moved wording about run-time semantics of parameter
+ associations to *note 6.4.1::.
+
+31.c
+ We have moved wording about raising Program_Error for a
+ function that falls off the end to here from RM83-6.5.
+
+ _Extensions to Ada 95_
+
+31.d/2
+ {AI95-00310-01AI95-00310-01} Nondispatching abstract
+ operations are no longer considered when resolving a
+ subprogram call. That makes it possible to use abstract to
+ "undefine" a predefined operation for an untagged type.
+ That's especially helpful when defining custom arithmetic
+ packages.
+
+ _Wording Changes from Ada 95_
+
+31.e/2
+ {AI95-00231-01AI95-00231-01} Changed the definition of the
+ nominal subtype of a function_call to use the nominal subtype
+ wording of *note 6.1::, to take into account null_exclusions
+ and access result types.
+
+31.f/2
+ {AI95-00345-01AI95-00345-01} Added wording to clarify that the
+ meaning of a call on a subprogram "implemented by" an entry or
+ protected operation is defined by *note 3.9.2::.
+
+31.g/2
+ {AI95-00407-01AI95-00407-01} Defined the meaning of a call on
+ a prefixed view of a subprogram (see *note 4.1.3::).
+
+* Menu:
+
+* 6.4.1 :: Parameter Associations
+
+\1f
+File: aarm2012.info, Node: 6.4.1, Up: 6.4
+
+6.4.1 Parameter Associations
+----------------------------
+
+1
+[ A parameter association defines the association between an actual
+parameter and a formal parameter.]
+
+ _Language Design Principles_
+
+1.a
+ The parameter passing rules for out parameters are designed to
+ ensure that the parts of a type that have implicit initial
+ values (see *note 3.3.1::) don't become "de-initialized" by
+ being passed as an out parameter.
+
+1.b/3
+ {AI05-0142-4AI05-0142-4} For explicitly aliased parameters of
+ functions, we will ensure at the call site that a part of the
+ parameter can be returned as part of the function result
+ without creating a dangling pointer. We do this with
+ accessibility checks at the call site that all actual objects
+ of explicitly aliased parameters live at least as long as the
+ function result; then we can allow them to be returned as
+ access discriminants or anonymous access results, as those
+ have the master of the function result.
+
+ _Name Resolution Rules_
+
+2/3
+{AI05-0118-1AI05-0118-1} The formal_parameter_selector_name of a named
+parameter_association (*note 6.4: S0181.) shall resolve to denote a
+parameter_specification (*note 6.1: S0175.) of the view being called;
+this is the formal parameter of the association. The formal parameter
+for a positional parameter_association (*note 6.4: S0181.) is the
+parameter with the corresponding position in the formal part of the view
+being called.
+
+2.a/3
+ To be honest: {AI05-0118-1AI05-0118-1} For positional
+ parameters, the "corresponding position" is calculated after
+ any transformation of prefixed views.
+
+3
+The actual parameter is either the explicit_actual_parameter given in a
+parameter_association for a given formal parameter, or the corresponding
+default_expression if no parameter_association is given for the formal
+parameter. The expected type for an actual parameter is the type of the
+corresponding formal parameter.
+
+3.a
+ To be honest: The corresponding default_expression is the one
+ of the corresponding formal parameter in the profile of the
+ view denoted by the name or prefix of the call.
+
+4
+If the mode is in, the actual is interpreted as an expression;
+otherwise, the actual is interpreted only as a name, if possible.
+
+4.a
+ Ramification: This formally resolves the ambiguity present in
+ the syntax rule for explicit_actual_parameter. Note that we
+ don't actually require that the actual be a name if the mode
+ is not in; we do that below.
+
+ _Legality Rules_
+
+5
+If the mode is in out or out, the actual shall be a name that denotes a
+variable.
+
+5.a
+ Discussion: We no longer need "or a type_conversion whose
+ argument is the name of a variable," because a type_conversion
+ is now a name, and a type_conversion of a variable is a
+ variable.
+
+5.b
+ Reason: The requirement that the actual be a (variable) name
+ is not an overload resolution rule, since we don't want the
+ difference between expression and name to be used to resolve
+ overloading. For example:
+
+5.c
+ procedure Print(X : in Integer; Y : in Boolean := True);
+ procedure Print(Z : in out Integer);
+ . . .
+ Print(3); -- Ambiguous!
+
+
+5.d
+ The above call to Print is ambiguous even though the call is
+ not compatible with the second Print which requires an actual
+ that is a (variable) name ("3" is an expression, not a name).
+ This requirement is a legality rule, so overload resolution
+ fails before it is considered, meaning that the call is
+ ambiguous.
+
+6/3
+{AI05-0102-1AI05-0102-1} {AI05-0142-4AI05-0142-4} If the formal
+parameter is an explicitly aliased parameter, the type of the actual
+parameter shall be tagged or the actual parameter shall be an aliased
+view of an object. Further, if the formal parameter subtype F is
+untagged:
+
+6.1/3
+ * the subtype F shall statically match the nominal subtype of the
+ actual object; or
+
+6.2/3
+ * the subtype F shall be unconstrained, discriminated in its full
+ view, and unconstrained in any partial view.
+
+6.a/3
+ Ramification: Tagged objects (and tagged aggregates for in
+ parameters) do not need to be aliased. This matches the
+ behavior of unaliased formal parameters of tagged types, which
+ allow 'Access to be taken of the formal parameter regardless
+ of the form of the actual parameter.
+
+6.b/3
+ Reason: We need the subtype check on untagged actual
+ parameters so that the requirements of 'Access are not lost.
+ 'Access makes its checks against the nominal subtype of its
+ prefix, and parameter passing can change that subtype. But we
+ don't want this parameter passing to change the objects that
+ would be allowed as the prefix of 'Access. This is
+ particularly important for arrays, where we don't want to
+ require any additional implementation burden.
+
+6.3/3
+{AI05-0142-4AI05-0142-4} {AI05-0234-1AI05-0234-1} In a function call,
+the accessibility level of the actual object for each explicitly aliased
+parameter shall not be statically deeper than the accessibility level of
+the master of the call (see *note 3.10.2::).
+
+6.c/3
+ Discussion: Since explicitly aliased parameters are either
+ tagged or required to be objects, there is always an object
+ (possibly anonymous) to talk about. This is discussing the
+ static accessibility level of the actual object; it does not
+ depend on any runtime information (for instance when the
+ actual object is a formal parameter of another subprogram, it
+ does not depend on the actual parameter of that other
+ subprogram).
+
+6.d/3
+ Ramification: This accessibility check (and its dynamic cousin
+ as well) can only fail if the function call is used to
+ directly initialize a built-in-place object with a master
+ different than that enclosing the call. The only place all of
+ those conditions exist is in the initializer of an allocator;
+ in all other cases this check will always pass.
+
+6.4/3
+{AI05-0144-2AI05-0144-2} Two names are known to denote the same object
+if:
+
+6.5/3
+ * both names statically denote the same stand-alone object or
+ parameter; or
+
+6.6/3
+ * both names are selected_components, their prefixes are known to
+ denote the same object, and their selector_names denote the same
+ component; or
+
+6.7/3
+ * both names are dereferences (implicit or explicit) and the
+ dereferenced names are known to denote the same object; or
+
+6.8/3
+ * both names are indexed_components, their prefixes are known to
+ denote the same object, and each of the pairs of corresponding
+ index values are either both static expressions with the same
+ static value or both names that are known to denote the same
+ object; or
+
+6.9/3
+ * both names are slices, their prefixes are known to denote the same
+ object, and the two slices have statically matching index
+ constraints; or
+
+6.10/3
+ * one of the two names statically denotes a renaming declaration
+ whose renamed object_name is known to denote the same object as the
+ other, the prefix of any dereference within the renamed object_name
+ is not a variable, and any expression within the renamed
+ object_name contains no references to variables nor calls on
+ nonstatic functions.
+
+6.e/3
+ Reason: This exposes known renamings of slices, indexing, and
+ so on to this definition. In particular, if we have
+
+6.f/3
+ C : Character renames S(1);
+
+6.g/3
+ then C and S(1) are known to denote the same object.
+
+6.h/3
+ We need the requirement that no variables occur in the
+ prefixes of dereferences and in (index) expressions of the
+ renamed object in order to avoid problems from later changes
+ to those parts of renamed names. Consider:
+
+6.i/3
+ type Ref is access Some_Type;
+ Ptr : Ref := new Some_Type'(...);
+ X : Some_Type renames Ptr.all;
+ begin
+ Ptr := new Some_Type'(...);
+ P (Func_With_Out_Params (Ptr.all), X);
+
+6.j/3
+ X and Ptr.all should not be known to denote the same object,
+ since they denote different allocated objects (and this is not
+ an unreasonable thing to do).
+
+6.k/3
+ To be honest: The exclusion of variables from renamed
+ object_names is not enough to prevent altering the value of
+ the name or expression by another access path. For instance,
+ both in parameters passed by reference and access-to-constant
+ values can designate variables. For the intended use of
+ "known to be the same object", this is OK; the modification
+ via another access path is very tricky and it is OK to reject
+ code that would be buggy except for the tricky code. Assuming
+ Element is an elementary type, consider the following example:
+
+6.l/3
+ Global : Tagged_Type;
+
+6.m/3
+ procedure Foo (Param : in Tagged_Type := Global) is
+ X : Element renames Some_Global_Array (Param.C);
+ begin
+ Global.C := Global.C + 1;
+ Swap (X, Some_Global_Array (Param.C));
+
+6.n/3
+ The rules will flag the call of procedure Swap as illegal,
+ since X and Some_Global_Array (Parameter.C) are known to
+ denote the same object (even though they will actually
+ represent different objects if Param = Global). But this is
+ only incorrect if the parameter actually is Global and not
+ some other value; the error could exist for some calls. So
+ this flagging seems harmless.
+
+6.o/3
+ Similar examples can be constructed using stand-alone
+ composite constants with controlled or immutably limited
+ components, and (as previously noted) with dereferences of
+ access-to-constant values. Even when these examples flag a
+ call incorrectly, that call depends on very tricky code
+ (modifying the value of a constant); the code is likely to
+ confuse future maintainers as well and thus we do not mind
+ rejecting it.
+
+6.p/3
+ Discussion: Whether or not names or prefixes are known to
+ denote the same object is determined statically. If the name
+ contains some dynamic portion other than a dereference,
+ indexed_component, or slice, it is not "known to denote the
+ same object".
+
+6.q/3
+ These rules make no attempt to handle slices of objects that
+ are known to be the same when the slices have dynamic bounds
+ (other than the trivial case of bounds being defined by the
+ same subtype), even when the bounds could be proven to be the
+ same, as it is just too complex to get right and these rules
+ are intended to be conservative.
+
+6.r/3
+ Ramification: "Known to denote the same object" is intended to
+ be an equivalence relationship, that is, it is reflexive,
+ symmetric, and transitive. We believe this follows from the
+ rules. For instance, given the following declarations:
+
+6.s/3
+ S : String(1..10);
+ ONE : constant Natural := 1;
+ R : Character renames S(1);
+
+6.t/3
+ the names R and S(1) are known to denote the same object by
+ the sixth bullet, and S(1) and S(ONE) are known to denote the
+ same object by the fourth bullet, so using the sixth bullet on
+ R and S(ONE), we simply have to test S(1) vs. S(ONE), which
+ we already know denote the same object.
+
+6.11/3
+{AI05-0144-2AI05-0144-2} Two names are known to refer to the same object
+if
+
+6.12/3
+ * The two names are known to denote the same object; or
+
+6.13/3
+ * One of the names is a selected_component, indexed_component, or
+ slice and its prefix is known to refer to the same object as the
+ other name; or
+
+6.14/3
+ * One of the two names statically denotes a renaming declaration
+ whose renamed object_name is known to refer to the same object as
+ the other name.
+
+6.u/3
+ Reason: This ensures that names Prefix.Comp and Prefix are
+ known to refer to the same object for the purposes of the
+ rules below. This intentionally does not include
+ dereferences; we only want to worry about accesses to the same
+ object, and a dereference changes the object in question.
+ (There is nothing shared between an access value and the
+ object it designates.)
+
+6.15/3
+{AI05-0144-2AI05-0144-2} If a call C has two or more parameters of mode
+in out or out that are of an elementary type, then the call is legal
+only if:
+
+6.16/3
+ * For each name N that is passed as a parameter of mode in out or out
+ to the call C, there is no other name among the other parameters of
+ mode in out or out to C that is known to denote the same object.
+
+6.v/3
+ To be honest: This means visibly an elementary type; it does
+ not include partial views of elementary types (partial views
+ are always composite). That's necessary to avoid having
+ Legality Rules depend on the contents of the private part.
+
+6.17/3
+{AI05-0144-2AI05-0144-2} If a construct C has two or more direct
+constituents that are names or expressions whose evaluation may occur in
+an arbitrary order, at least one of which contains a function call with
+an in out or out parameter, then the construct is legal only if:
+
+6.w/3
+ Ramification: All of the places where the language allows an
+ arbitrary order can be found by looking in the index under
+ "arbitrary order, allowed". Note that this listing includes
+ places that don't involve names or expressions (such as checks
+ or finalization).
+
+6.18/3
+ * For each name N that is passed as a parameter of mode in out or out
+ to some inner function call C2 (not including the construct C
+ itself), there is no other name anywhere within a direct
+ constituent of the construct C other than the one containing C2,
+ that is known to refer to the same object.
+
+6.x/3
+ Ramification: This requirement cannot fail for a procedure or
+ entry call alone; there must be at least one function with an
+ in out or out parameter called as part of a parameter
+ expression of the call in order for it to fail.
+
+6.y/3
+ Reason: These rules prevent obvious cases of dependence on the
+ order of evaluation of names or expressions. Such dependence
+ is usually a bug, and in any case, is not portable to another
+ implementation (or even another optimization setting).
+
+6.z/3
+ In the case that the top-level construct C is a call, these
+ rules do not require checks for most in out parameters, as the
+ rules about evaluation of calls prevent problems. Similarly,
+ we do not need checks for short circuit operations or other
+ operations with a defined order of evaluation. The rules
+ about arbitrary order (see *note 1.1.4::) allow evaluating
+ parameters and writing parameters back in an arbitrary order,
+ but not interleaving of evaluating parameters of one call with
+ writing parameters back from another -- that would not
+ correspond to any allowed sequential order.
+
+6.19/3
+{AI05-0144-2AI05-0144-2} For the purposes of checking this rule:
+
+6.20/3
+ * For an array aggregate, an expression associated with a
+ discrete_choice_list that has two or more discrete choices, or that
+ has a nonstatic range, is considered as two or more separate
+ occurrences of the expression;
+
+6.21/3
+ * For a record aggregate:
+
+6.22/3
+ * The expression of a record_component_association is
+ considered to occur once for each associated component;
+ and
+
+6.23/3
+ * The default_expression for each
+ record_component_association with <> for which the
+ associated component has a default_expression is
+ considered part of the aggregate;
+
+6.24/3
+ * For a call, any default_expression evaluated as part of the call is
+ considered part of the call.
+
+6.aa/3
+ Ramification: We do not check expressions that are evaluated
+ only because of a component initialized by default in an
+ aggregate (via <>).
+
+ _Dynamic Semantics_
+
+7
+For the evaluation of a parameter_association:
+
+8
+ * The actual parameter is first evaluated.
+
+9
+ * For an access parameter, the access_definition is elaborated, which
+ creates the anonymous access type.
+
+10
+ * For a parameter [(of any mode)] that is passed by reference (see
+ *note 6.2::), a view conversion of the actual parameter to the
+ nominal subtype of the formal parameter is evaluated, and the
+ formal parameter denotes that conversion.
+
+10.a
+ Discussion: We are always allowing sliding, even for [in] out
+ by-reference parameters.
+
+11
+ * For an in or in out parameter that is passed by copy (see *note
+ 6.2::), the formal parameter object is created, and the value of
+ the actual parameter is converted to the nominal subtype of the
+ formal parameter and assigned to the formal.
+
+11.a
+ Ramification: The conversion mentioned here is a value
+ conversion.
+
+12
+ * For an out parameter that is passed by copy, the formal parameter
+ object is created, and:
+
+13/3
+ * {AI05-0153-3AI05-0153-3} {AI05-0196-1AI05-0196-1} For an
+ access type, the formal parameter is initialized from the
+ value of the actual, without checking that the value satisfies
+ any constraint, any predicate, or any exclusion of the null
+ value;
+
+13.a
+ Reason: This preserves the Language Design Principle that an
+ object of an access type is always initialized with a
+ "reasonable" value.
+
+13.1/3
+ * {AI05-0153-3AI05-0153-3} {AI05-0228-1AI05-0228-1} For a scalar
+ type that has the Default_Value aspect specified, the formal
+ parameter is initialized from the value of the actual, without
+ checking that the value satisfies any constraint or any
+ predicate;
+
+13.b/3
+ Reason: This preserves the Language Design Principle that all
+ objects of a type with an implicit initial value are
+ initialized. This is important so that a programmer can
+ guarantee that all objects of a scalar type have a valid value
+ with a carefully chosen Default_Value.
+
+13.c/3
+ Implementation Note: This rule means that out parameters of a
+ subtype T with a specified Default_Value need to be large
+ enough to support any possible value of the base type of T. In
+ contrast, a type that does not have a Default_Value only need
+ support the size of the subtype (since no values are passed
+ in).
+
+14
+ * For a composite type with discriminants or that has implicit
+ initial values for any subcomponents (see *note 3.3.1::), the
+ behavior is as for an in out parameter passed by copy.
+
+14.a
+ Reason: This ensures that no part of an object of such a type
+ can become "de-initialized" by being part of an out parameter.
+
+14.b
+ Ramification: This includes an array type whose component type
+ is an access type, and a record type with a component that has
+ a default_expression, among other things.
+
+15
+ * For any other type, the formal parameter is uninitialized. If
+ composite, a view conversion of the actual parameter to the
+ nominal subtype of the formal is evaluated [(which might raise
+ Constraint_Error)], and the actual subtype of the formal is
+ that of the view conversion. If elementary, the actual
+ subtype of the formal is given by its nominal subtype.
+
+15.a/3
+ Ramification: {AI05-0228-1AI05-0228-1} This case covers scalar
+ types that do not have Default_Value specified, and composite
+ types whose subcomponent's subtypes do not have any implicit
+ initial values. The view conversion for composite types
+ ensures that if the lengths don't match between an actual and
+ a formal array parameter, the Constraint_Error is raised
+ before the call, rather than after.
+
+15.1/3
+ * {AI05-0142-4AI05-0142-4} {AI05-0234-1AI05-0234-1} In a function
+ call, for each explicitly aliased parameter, a check is made that
+ the accessibility level of the master of the actual object is not
+ deeper than that of the master of the call (see *note 3.10.2::).
+
+15.a.1/3
+ Ramification: If the actual object to a call C is a formal
+ parameter of some function call F, no dynamic check against
+ the master of the actual parameter of F is necessary. Any
+ case which could fail the dynamic check is already statically
+ illegal (either at the call site of F, or at the call site C).
+ This is important, as it would require nasty distributed
+ overhead to accurately know the dynamic accessibility of a
+ formal parameter (all tagged and explicitly aliased parameters
+ would have to carry accessibility levels).
+
+16
+A formal parameter of mode in out or out with discriminants is
+constrained if either its nominal subtype or the actual parameter is
+constrained.
+
+17
+After normal completion and leaving of a subprogram, for each in out or
+out parameter that is passed by copy, the value of the formal parameter
+is converted to the subtype of the variable given as the actual
+parameter and assigned to it. These conversions and assignments occur
+in an arbitrary order.
+
+17.a
+ Ramification: The conversions mentioned above during parameter
+ passing might raise Constraint_Error -- (see *note 4.6::).
+
+17.b
+ Ramification: If any conversion or assignment as part of
+ parameter passing propagates an exception, the exception is
+ raised at the place of the subprogram call; that is, it cannot
+ be handled inside the subprogram_body.
+
+17.c
+ Proof: Since these checks happen before or after executing the
+ subprogram_body, the execution of the subprogram_body does not
+ dynamically enclose them, so it can't handle the exceptions.
+
+17.d
+ Discussion: The variable we're talking about is the one
+ denoted by the variable_name given as the
+ explicit_actual_parameter. If this variable_name is a
+ type_conversion, then the rules in *note 4.6:: for assigning
+ to a view conversion apply. That is, if X is of subtype S1,
+ and the actual is S2(X), the above-mentioned conversion will
+ convert to S2, and the one mentioned in *note 4.6:: will
+ convert to S1.
+
+ _Erroneous Execution_
+
+18/3
+{AI05-0008-1AI05-0008-1} If the nominal subtype of a formal parameter
+with discriminants is constrained or indefinite, and the parameter is
+passed by reference, then the execution of the call is erroneous if the
+value of any discriminant of the actual is changed while the formal
+parameter exists (that is, before leaving the corresponding callable
+construct).
+
+ _Extensions to Ada 83_
+
+18.a
+ In Ada 95, a program can rely on the fact that passing an
+ object as an out parameter does not "de-initialize" any parts
+ of the object whose subtypes have implicit initial values.
+ (This generalizes the RM83 rule that required copy-in for
+ parts that were discriminants or of an access type.)
+
+ _Wording Changes from Ada 83_
+
+18.b/3
+ {AI05-0299-1AI05-0299-1} We have eliminated the subclause on
+ Default Parameters, as it is subsumed by earlier subclauses.
+
+ _Inconsistencies With Ada 2005_
+
+18.c/3
+ {AI05-0196-1AI05-0196-1} Correction: Clarified that out
+ parameters of an access type are not checked for null
+ exclusions when they are passed in (which is similar to the
+ behavior for constraints). This was unspecified in Ada 2005,
+ so a program which depends on the behavior of an
+ implementation which does check the exclusion may malfunction.
+ But a program depending on an exception being raised is
+ unlikely.
+
+ _Incompatibilities With Ada 2005_
+
+18.d/3
+ {AI05-0144-2AI05-0144-2} Additional rules have been added to
+ make illegal passing the same elementary object to more than
+ one in out or out parameters of the same call. In this case,
+ the result in the object could depend on the compiler version,
+ optimization settings, and potentially the phase of the moon,
+ so this check will mostly reject programs that are nonportable
+ and could fail with any change. Even when the result is
+ expected to be the same in both parameters, the code is
+ unnecessarily tricky. Programs which fail this new check
+ should be rare and are easily fixed by adding a temporary
+ object.
+
+ _Wording Changes from Ada 2005_
+
+18.e/3
+ {AI05-0008-1AI05-0008-1} Correction: A missing rule was added
+ to cover cases that were missed in Ada 95 and Ada 2005;
+ specifically, that an in parameter passed by reference might
+ have its discriminants changed via another path. Such cases
+ are erroneous as requiring compilers to detect such errors
+ would be expensive, and requiring such cases to work would be
+ a major change of the user model (in parameters with
+ discriminants could no longer be assumed constant). This is
+ not an inconsistency, as compilers are not required to change
+ any current behavior.
+
+18.f/3
+ {AI05-0102-1AI05-0102-1} Correction: Moved implicit conversion
+ Legality Rule to *note 8.6::.
+
+18.g/3
+ {AI05-0118-1AI05-0118-1} Correction: Added a definition for
+ positional parameters, as this is missing from Ada 95 and
+ later.
+
+18.h/3
+ {AI05-0142-4AI05-0142-4} Rules have been added defining the
+ legality and dynamic checks needed for explicitly aliased
+ parameters (see *note 6.1::).
+
+18.i/3
+ {AI05-0144-2AI05-0144-2} Additional rules have been added such
+ that passing an object to an in out or out parameter of a
+ function is illegal if it is used elsewhere in a construct
+ which allows evaluation in an arbitrary order. Such calls are
+ not portable (since the results may depend on the evaluation
+ order), and the results could even vary because of
+ optimization settings and the like. Thus they've been banned.
+
+\1f
+File: aarm2012.info, Node: 6.5, Next: 6.6, Prev: 6.4, Up: 6
+
+6.5 Return Statements
+=====================
+
+1/2
+{AI95-00318-02AI95-00318-02} A simple_return_statement (*note 6.5:
+S0183.) or extended_return_statement (*note 6.5: S0186.) (collectively
+called a return statement) is used to complete the execution of the
+innermost enclosing subprogram_body (*note 6.3: S0177.), entry_body
+(*note 9.5.2: S0221.), or accept_statement (*note 9.5.2: S0219.).
+
+ _Syntax_
+
+2/2
+ {AI95-00318-02AI95-00318-02} simple_return_statement ::= return [
+ expression];
+
+2.1/3
+ {AI05-0277-1AI05-0277-1} extended_return_object_declaration ::=
+ defining_identifier : [aliased][constant]
+ return_subtype_indication [:= expression]
+
+2.2/3
+ {AI95-00318-02AI95-00318-02} {AI05-0015-1AI05-0015-1}
+ {AI05-0053-1AI05-0053-1} {AI05-0277-1AI05-0277-1}
+ {AI05-0299-1AI05-0299-1} extended_return_statement ::=
+ return extended_return_object_declaration [do
+ handled_sequence_of_statements
+ end return];
+
+2.3/2
+ {AI95-00318-02AI95-00318-02} return_subtype_indication ::=
+ subtype_indication | access_definition
+
+ _Name Resolution Rules_
+
+3/2
+{AI95-00318-02AI95-00318-02} The result subtype of a function is the
+subtype denoted by the subtype_mark, or defined by the
+access_definition, after the reserved word return in the profile of the
+function. The expected type for the expression, if any, of a
+simple_return_statement (*note 6.5: S0183.) is the result type of the
+corresponding function. The expected type for the expression of an
+extended_return_statement is that of the return_subtype_indication
+(*note 6.5: S0187.).
+
+3.a
+ To be honest: The same applies to generic functions.
+
+ _Legality Rules_
+
+4/2
+{AI95-00318-02AI95-00318-02} A return statement shall be within a
+callable construct, and it applies to the innermost callable construct
+or extended_return_statement that contains it. A return statement shall
+not be within a body that is within the construct to which the return
+statement applies.
+
+5/3
+{AI95-00318-02AI95-00318-02} {AI05-0015-1AI05-0015-1} A function body
+shall contain at least one return statement that applies to the function
+body, unless the function contains code_statements. A
+simple_return_statement (*note 6.5: S0183.) shall include an expression
+if and only if it applies to a function body. An
+extended_return_statement shall apply to a function body. An
+extended_return_statement with the reserved word constant shall include
+an expression.
+
+5.a/2
+ Reason: {AI95-00318-02AI95-00318-02} The requirement that a
+ function body has to have at least one return statement is a
+ "helpful" restriction. There has been some interest in
+ lifting this restriction, or allowing a raise statement to
+ substitute for the return statement. However, there was
+ enough interest in leaving it as is that we decided not to
+ change it.
+
+5.b/2
+ Ramification: {AI95-00318-02AI95-00318-02} A return statement
+ can apply to an extended_return_statement, so a
+ simple_return_statement (*note 6.5: S0183.) without an
+ expression can be given in one. However, neither
+ simple_return_statement (*note 6.5: S0183.) with an expression
+ nor an extended_return_statement can be given inside an
+ extended_return_statement, as they must apply (directly) to a
+ function body.
+
+5.1/2
+{AI95-00318-02AI95-00318-02} For an extended_return_statement (*note
+6.5: S0186.) that applies to a function body:
+
+5.2/3
+ * {AI95-00318-02AI95-00318-02} {AI05-0032-1AI05-0032-1}
+ {AI05-0103-1AI05-0103-1} If the result subtype of the function is
+ defined by a subtype_mark, the return_subtype_indication (*note
+ 6.5: S0187.) shall be a subtype_indication. The type of the
+ subtype_indication shall be covered by the result type of the
+ function. The subtype defined by the subtype_indication shall be
+ statically compatible with the result subtype of the function; if
+ the result type of the function is elementary, the two subtypes
+ shall statically match. If the result subtype of the function is
+ indefinite, then the subtype defined by the subtype_indication
+ shall be a definite subtype, or there shall be an expression.
+
+5.3/2
+ * {AI95-00318-02AI95-00318-02} If the result subtype of the function
+ is defined by an access_definition, the return_subtype_indication
+ (*note 6.5: S0187.) shall be an access_definition. The subtype
+ defined by the access_definition shall statically match the result
+ subtype of the function. The accessibility level of this anonymous
+ access subtype is that of the result subtype.
+
+5.4/3
+ * {AI05-0032-1AI05-0032-1} If the result subtype of the function is
+ class-wide, the accessibility level of the type of the subtype
+ defined by the return_subtype_indication shall not be statically
+ deeper than that of the master that elaborated the function body.
+
+5.b.1/3
+ Reason: In this case, the return_subtype_indication could be a
+ specific type initialized by default; in that case there is no
+ expression to check.
+
+5.5/3
+{AI95-00318-02AI95-00318-02} {AI05-0032-1AI05-0032-1} For any return
+statement that applies to a function body:
+
+5.6/3
+ * {AI95-00318-02AI95-00318-02} {AI05-0188-1AI05-0188-1} [If the
+ result subtype of the function is limited, then the expression of
+ the return statement (if any) shall meet the restrictions described
+ in *note 7.5::.]
+
+5.c/3
+ This paragraph was deleted.{AI05-0188-1AI05-0188-1}
+
+5.7/3
+ * {AI95-00416-01AI95-00416-01} {AI05-0032-1AI05-0032-1}
+ {AI05-0051-1AI05-0051-1} If the result subtype of the function is
+ class-wide, the accessibility level of the type of the expression
+ (if any) of the return statement shall not be statically deeper
+ than that of the master that elaborated the function body.
+
+5.d/3
+ Discussion: {AI05-0032-1AI05-0032-1} {AI05-0051-1AI05-0051-1}
+ If the result type is class wide, then there must be an
+ expression of the return statement unless this is an
+ extended_return_statement whose return_subtype_indication is a
+ specific type. We have a separate rule to cover that case.
+ Note that if an extended_return_statement has an expression,
+ then both this rule and the next one must be satisfied.
+
+5.8/3
+ * {AI05-0051-1AI05-0051-1} If the subtype determined by the
+ expression of the simple_return_statement or by the
+ return_subtype_indication has one or more access discriminants, the
+ accessibility level of the anonymous access type of each access
+ discriminant shall not be statically deeper than that of the master
+ that elaborated the function body.
+
+5.d.1/3
+ Discussion: We use the type used by the return statement
+ rather than from the function return type since we want to
+ check whenever the return object has access discriminants,
+ even if the function return type doesn't have any (mostly for
+ a class-wide type).
+
+5.9/3
+{AI05-0277-1AI05-0277-1} If the keyword aliased is present in an
+extended_return_object_declaration, the type of the extended return
+object shall be immutably limited.
+
+ _Static Semantics_
+
+5.10/3
+{AI95-00318-02AI95-00318-02} {AI05-0015-1AI05-0015-1}
+{AI05-0144-2AI05-0144-2} Within an extended_return_statement, the return
+object is declared with the given defining_identifier, with the nominal
+subtype defined by the return_subtype_indication (*note 6.5: S0187.).
+An extended_return_statement with the reserved word constant is a full
+constant declaration that declares the return object to be a constant
+object.
+
+ _Dynamic Semantics_
+
+5.11/3
+{AI95-00318-02AI95-00318-02} {AI95-00416-01AI95-00416-01}
+{AI05-0032-1AI05-0032-1} For the execution of an
+extended_return_statement, the subtype_indication or access_definition
+is elaborated. This creates the nominal subtype of the return object.
+If there is an expression, it is evaluated and converted to the nominal
+subtype (which might raise Constraint_Error -- see *note 4.6::); the
+return object is created and the converted value is assigned to the
+return object. Otherwise, the return object is created and initialized
+by default as for a stand-alone object of its nominal subtype (see *note
+3.3.1::). If the nominal subtype is indefinite, the return object is
+constrained by its initial value. A check is made that the value of the
+return object belongs to the function result subtype. Constraint_Error
+is raised if this check fails.
+
+5.e/2
+ Ramification: If the result type is controlled or has a
+ controlled part, appropriate calls on Initialize or Adjust are
+ performed prior to executing the
+ handled_sequence_of_statements, except when the initial
+ expression is an aggregate (which requires build-in-place with
+ no call on Adjust).
+
+5.f/3
+ {AI05-0005-1AI05-0005-1} If the return statement is left
+ without resulting in a return (for example, due to an
+ exception propagated from the expression or the
+ handled_sequence_of_statements, or a goto out of the
+ handled_sequence_of_statements), if the return object has been
+ created, it is finalized prior to leaving the return
+ statement. If it has not been created when the return
+ statement is left, it is not created or finalized.
+
+5.g/3
+ {AI05-0032-1AI05-0032-1} Other rules ensure that the check
+ required by this rule cannot fail unless the function has a
+ class-wide result subtype where the associated specific
+ subtype is constrained. In other cases, either the subtypes
+ have to match or the function's subtype is unconstrained and
+ needs no checking.
+
+6/2
+{AI95-00318-02AI95-00318-02} For the execution of a
+simple_return_statement (*note 6.5: S0183.), the expression (if any) is
+first evaluated, converted to the result subtype, and then is assigned
+to the anonymous return object.
+
+6.a
+ Ramification: The conversion might raise Constraint_Error --
+ (see *note 4.6::).
+
+7/2
+{AI95-00318-02AI95-00318-02} {AI95-00416-01AI95-00416-01} [If the return
+object has any parts that are tasks, the activation of those tasks does
+not occur until after the function returns (see *note 9.2::).]
+
+7.a/2
+ Proof: This is specified by the rules in *note 9.2::.
+
+7.b/2
+ Reason: Only the caller can know when task activations should
+ take place, as it depends on the context of the call. If the
+ function is being used to initialize the component of some
+ larger object, then that entire object must be initialized
+ before any task activations. Even after the outer object is
+ fully initialized, task activations are still postponed until
+ the begin at the end of the declarative part if the function
+ is being used to initialize part of a declared object.
+
+8/3
+{AI95-00318-02AI95-00318-02} {AI95-00344-01AI95-00344-01}
+{AI05-0024-1AI05-0024-1} {AI05-0032-1AI05-0032-1} If the result type of
+a function is a specific tagged type, the tag of the return object is
+that of the result type. If the result type is class-wide, the tag of
+the return object is that of the type of the subtype_indication if it is
+specific, or otherwise that of the value of the expression. A check is
+made that the master of the type identified by the tag of the result
+includes the elaboration of the master that elaborated the function
+body. If this check fails, Program_Error is raised.
+
+8.a/2
+ Ramification: {AI95-00318-02AI95-00318-02} The first sentence
+ is true even if the tag of the expression is different, which
+ could happen if the expression were a view conversion or a
+ dereference of an access value. Note that for a limited type,
+ because of the restriction to aggregates and function calls
+ (and no conversions), the tag will already match.
+
+8.b/2
+ Reason: {AI95-00318-02AI95-00318-02} The first rule ensures
+ that a function whose result type is a specific tagged type
+ always returns an object whose tag is that of the result type.
+ This is important for dispatching on controlling result, and
+ allows the caller to allocate the appropriate amount of space
+ to hold the value being returned (assuming there are no
+ discriminants).
+
+8.c/3
+ The master check prevents the returned object from outliving
+ its type. Note that this check cannot fail for a specific
+ tagged type, as the tag represents the function's type, which
+ necessarily must be declared outside of the function.
+
+8.d/3
+ We can't use the normal accessibility level "deeper than"
+ check here because we may have "incomparable" levels if the
+ masters belong to two different tasks. This can happen when
+ an accept statement calls a function declared in the enclosing
+ task body, and the function returns an object passed to it
+ from the accept statement, and this object was itself a
+ parameter to the accept statement.
+
+8.1/3
+{AI05-0073-1AI05-0073-1} If the result subtype of the function is
+defined by an access_definition designating a specific tagged type T, a
+check is made that the result value is null or the tag of the object
+designated by the result value identifies T. Constraint_Error is raised
+if this check fails.
+
+8.e/3
+ Reason: This check is needed so that dispatching on
+ controlling access results works for tag-indeterminate
+ functions. If it was not made, it would be possible for such
+ functions to return an access to a descendant type, meaning
+ the function could return an object with a tag different than
+ the one assumed by the dispatching rules.
+
+Paragraphs 9 through 20 were deleted.
+
+21/3
+{AI95-00318-02AI95-00318-02} {AI95-00402-01AI95-00402-01}
+{AI95-00416-01AI95-00416-01} {AI05-0051-1AI05-0051-1} If any part of the
+specific type of the return object of a function (or coextension
+thereof) has one or more access discriminants whose value is not
+constrained by the result subtype of the function, a check is made that
+the accessibility level of the anonymous access type of each access
+discriminant, as determined by the expression or the
+return_subtype_indication (*note 6.5: S0187.) of the return statement,
+is not deeper than the level of the master of the call (see *note
+3.10.2::). If this check fails, Program_Error is raised.
+
+21.a/2
+ This paragraph was deleted.
+
+21.b/2
+ Reason: The check prevents the returned object (for a
+ nonlimited type) from outliving the object designated by one
+ of its discriminants. The check is made on the values of the
+ discriminants, which may come from the
+ return_subtype_indication (*note 6.5: S0187.) (if
+ constrained), or the expression, but it is never necessary to
+ check both.
+
+21.c/3
+ Implementation Note: {AI05-0234-1AI05-0234-1} The reason for
+ saying "any part of the specific type" is to simplify
+ implementation. In the case of class-wide result objects,
+ this allows the testing of a simple flag in the tagged type
+ descriptor that indicates whether the specific type has any
+ parts with access discriminants. By basing the test on the
+ type of the object rather than the object itself, we avoid
+ concerns about whether subcomponents in variant parts and of
+ arrays (which might be empty) are present.
+
+21.d/3
+ Discussion: {AI05-0234-1AI05-0234-1} For a function with a
+ class-wide result type, the access values that need to be
+ checked are determined by the tag of the return object. In
+ order to implement this accessibility check in the case where
+ the tag of the result is not known statically at the point of
+ the return statement, an implementation may need to somehow
+ associate with the tag of a specific tagged type an indication
+ of whether the type has unconstrained access discriminants
+ (explicit or inherited) or has any subcomponents with such
+ discriminants. If an implementation is already maintaining a
+ statically initialized descriptor of some kind for each
+ specific tagged type, then an additional Boolean could be
+ added to this descriptor.
+
+21.e/3
+ {AI05-0005-1AI05-0005-1} {AI05-0234-1AI05-0234-1} Note that
+ the flag should only be queried in the case where the result
+ object might have access discriminants that might have
+ subtypes with "bad" accessibility levels (as determined by the
+ rules of *note 3.10.2:: for determining the accessibility
+ level of the type of an access discriminant in the expression
+ or return_subtype_indication of a return statement).
+
+21.f/3
+ Thus, in a case like
+
+21.g/3
+ type Global is access T'Class;
+ function F (Ptr : Global) return T'Class is
+ begin
+ return Ptr.all;
+ end F;
+
+21.h/3
+ there is no need for a run-time accessibility check. While an
+ object of T'Class "might have" access discriminants, the
+ accessibility of those potential discriminants cannot be bad.
+ The setting of the bit doesn't matter and there is no need to
+ query it.
+
+21.i/3
+ On the other hand, given
+
+21.j/3
+ function F return T'Class is
+ Local : T'Class := ... ;
+ begin
+ return Local;
+ end F;
+
+21.k/3
+ In this case, a check would typically be required.
+
+21.l/3
+ The need for including subcomponents in this check is
+ illustrated by the following example:
+
+21.m/3
+ X : aliased Integer;
+
+21.n/3
+ type Component_Type (Discrim : access Integer := X'Access)
+ is limited null record;
+
+21.o/3
+ type Undiscriminated is record
+ Fld : Component_Type;
+ end record;
+
+21.p/3
+ function F return Undiscriminated is
+ Local : aliased Integer;
+ begin
+ return X : Undiscriminated := (Fld => (Discrim => Local'Access)) do
+ Foo;
+ end return;
+ -- raises Program_Error after calling Foo.
+ end F;
+
+21.q/3
+ Ramification: {AI05-0234-1AI05-0234-1} In the case where the
+ tag of the result is not known statically at the point of the
+ return statement and the run-time accessibility check is
+ needed, discriminant values and array bounds play no role in
+ performing this check. That is, array components are assumed
+ to have nonzero length and components declared within variant
+ parts are assumed to be present. Thus, the check may be
+ implemented simply by testing the aforementioned descriptor
+ bit and conditionally raising Program_Error.
+
+22/3
+{AI95-00318-02AI95-00318-02} {AI05-0058-1AI05-0058-1} For the execution
+of an extended_return_statement (*note 6.5: S0186.), the
+handled_sequence_of_statements (*note 11.2: S0265.) is executed. Within
+this handled_sequence_of_statements (*note 11.2: S0265.), the execution
+of a simple_return_statement (*note 6.5: S0183.) that applies to the
+extended_return_statement (*note 6.5: S0186.) causes a transfer of
+control that completes the extended_return_statement (*note 6.5:
+S0186.). Upon completion of a return statement that applies to a
+callable construct by the normal completion of a simple_return_statement
+(*note 6.5: S0183.) or by reaching the end return of an
+extended_return_statement (*note 6.5: S0186.), a transfer of control is
+performed which completes the execution of the callable construct, and
+returns to the caller.
+
+22.a/3
+ Ramification: {AI05-0058-1AI05-0058-1} A transfer of control
+ that completes an extended_return_statement (such as an exit
+ or goto) does not cause a return to the caller unless it is
+ caused by simple_return_statement (that is, triggers the
+ second sentence of this paragraph). The return to the caller
+ occurs for the simple_return_statement that applies to an
+ extended_return_statement because the last sentence says "the
+ normal completion of a simple_return_statement", which
+ includes the one nested in the extended_return_statement.
+
+23/2
+{AI95-00318-02AI95-00318-02} In the case of a function, the
+function_call denotes a constant view of the return object.
+
+ _Implementation Permissions_
+
+24/3
+{AI95-00416-01AI95-00416-01} {AI05-0050-1AI05-0050-1} For a function
+call used to initialize a composite object with a constrained nominal
+subtype or used to initialize a return object that is built in place
+into such an object:
+
+24.1/3
+ * {AI05-0050-1AI05-0050-1} If the result subtype of the function is
+ constrained, and conversion of an object of this subtype to the
+ subtype of the object being initialized would raise
+ Constraint_Error, then Constraint_Error may be raised before
+ calling the function.
+
+24.2/3
+ * {AI05-0050-1AI05-0050-1} If the result subtype of the function is
+ unconstrained, and a return statement is executed such that the
+ return object is known to be constrained, and conversion of the
+ return object to the subtype of the object being initialized would
+ raise Constraint_Error, then Constraint_Error may be raised at the
+ point of the call (after abandoning the execution of the function
+ body).
+
+24.a/3
+ Reason: {AI95-00416-01AI95-00416-01} {AI05-0050-1AI05-0050-1}
+ Without such a permission, it would be very difficult to
+ implement "built-in-place" semantics. The intention is that
+ the exception is raised at the same point that it would have
+ been raised without the permission; it should not change
+ handlers if the implementation switches between return-by-copy
+ and built-in-place. This means that the exception is not
+ handleable within the function, because in the return-by-copy
+ case, the constraint check to verify that the result satisfies
+ the constraints of the object being initialized happens after
+ the function returns. This implies further that upon
+ detecting such a situation, the implementation may need to
+ simulate a goto to a point outside any local exception
+ handlers prior to raising the exception.
+
+24.b/3
+ Ramification: {AI95-00416-01AI95-00416-01}
+ {AI05-0050-1AI05-0050-1} These permissions do not apply in the
+ case of an extended return object with mutable discriminants.
+ That's necessary because in that case a return object can be
+ created with the "wrong" discriminants and then changed to the
+ "right" discriminants later (but before returning). We don't
+ want this case raising an exception when the canonical
+ semantics will not do so.
+
+24.c/3
+ {AI05-0050-1AI05-0050-1} It's still possible to write a
+ program that will raise an exception using this permission
+ that would not in the canonical semantics. That could happen
+ if a return statement with the "wrong" discriminants or bounds
+ is abandoned (via an exception, or for an
+ extended_return_statement, via an exit or goto statement), and
+ then a return statement with the "right" discriminants or
+ bounds is executed. The only solution for this problem is to
+ not have the permission at all, but this is too unusual of a
+ case to worry about the effects of the permission, especially
+ given the implementation difficulties for built-in-place
+ objects that this permission is intended to ease.
+
+24.d/3
+ {AI05-0050-1AI05-0050-1} Note that the mutable-discriminant
+ case only happens when built-in-place initialization is
+ optional. This means that any difficulties associated with
+ implementing built-in-place initialization without these
+ permissions can be sidestepped by not building in place.
+
+ _Examples_
+
+25
+Examples of return statements:
+
+26/2
+ {AI95-00318-02AI95-00318-02} return; -- in a procedure body, entry_body,
+ -- accept_statement, or extended_return_statement
+
+27
+ return Key_Value(Last_Index); -- in a function body
+
+28/2
+ {AI95-00318-02AI95-00318-02} return Node : Cell do -- in a function body, see *note 3.10.1:: for Cell
+ Node.Value := Result;
+ Node.Succ := Next_Node;
+ end return;
+
+ _Incompatibilities With Ada 83_
+
+28.a/2
+ {AI95-00318-02AI95-00318-02} In Ada 95, if the result type of
+ a function has a part that is a task, then an attempt to
+ return a local variable will raise Program_Error. This is
+ illegal in Ada 2005, see below. In Ada 83, if a function
+ returns a local variable containing a task, execution is
+ erroneous according to AI83-00867. However, there are other
+ situations where functions that return tasks (or that return a
+ variant record only one of whose variants includes a task) are
+ correct in Ada 83 but will raise Program_Error according to
+ the new rules.
+
+28.b
+ The rule change was made because there will be more types
+ (protected types, limited controlled types) in Ada 95 for
+ which it will be meaningless to return a local variable, and
+ making all of these erroneous is unacceptable. The current
+ rule was felt to be the simplest that kept upward
+ incompatibilities to situations involving returning tasks,
+ which are quite rare.
+
+ _Wording Changes from Ada 83_
+
+28.c/3
+ {AI05-0299-1AI05-0299-1} This subclause has been moved here
+ from chapter 5, since it has mainly to do with subprograms.
+
+28.d
+ A function now creates an anonymous object. This is necessary
+ so that controlled types will work.
+
+28.e/2
+ {AI95-00318-02AI95-00318-02} We have clarified that a return
+ statement applies to a callable construct, not to a callable
+ entity.
+
+28.f/2
+ {AI95-00318-02AI95-00318-02} There is no need to mention
+ generics in the rules about where a return statement can
+ appear and what it applies to; the phrase "body of a
+ subprogram or generic subprogram" is syntactic, and refers
+ exactly to "subprogram_body".
+
+ _Inconsistencies With Ada 95_
+
+28.f.1/3
+ {AI95-0416-1AI95-0416-1} {AI05-0005-1AI05-0005-1}
+ {AI05-0050-1AI05-0050-1} Added an Implementation Permission
+ allowing early raising of Constraint_Error if the result
+ cannot fit in the ultimate object. This gives implementations
+ more flexibility to do built-in-place returns, and is
+ essential for limited types (which cannot be built in a
+ temporary). However, it allows raising Constraint_Error in
+ some cases where it would not be raised if the permission was
+ not used. See Inconsistencies With Ada 2005 for additional
+ changes. This case is potentially inconsistent with Ada 95,
+ but a compiler does not have to take advantage of these
+ permissions for any Ada 95 code, so there should be little
+ practical impact.
+
+ _Incompatibilities With Ada 95_
+
+28.g/2
+ {AI95-00318-02AI95-00318-02} The entire business about
+ return-by-reference types has been dropped. Instead, the
+ expression of a return statement of a limited type can only be
+ an aggregate or function_call (see *note 7.5::). This means
+ that returning a global object or type_conversion, legal in
+ Ada 95, is now illegal. Such functions can be converted to
+ use anonymous access return types by adding access in the
+ function definition and return statement, adding .all in uses,
+ and adding aliased in the object declarations. This has the
+ advantage of making the reference return semantics much
+ clearer to the casual reader.
+
+28.h/2
+ We changed these rules so that functions, combined with the
+ new rules for limited types (*note 7.5::), can be used as
+ build-in-place constructors for limited types. This reduces
+ the differences between limited and nonlimited types, which
+ will make limited types useful in more circumstances.
+
+ _Extensions to Ada 95_
+
+28.i/2
+ {AI95-00318-02AI95-00318-02} The extended_return_statement is
+ new. This provides a name for the object being returned,
+ which reduces the copying needed to return complex objects
+ (including no copying at all for limited objects). It also
+ allows component-by-component construction of the return
+ object.
+
+ _Wording Changes from Ada 95_
+
+28.j/2
+ {AI95-00318-02AI95-00318-02} The wording was updated to
+ support anonymous access return subtypes.
+
+28.k/2
+ {AI95-00318-02AI95-00318-02} The term "return expression" was
+ dropped because reviewers found it confusing when applied to
+ the default expression of an extended_return_statement.
+
+28.l/2
+ {AI95-00344-01AI95-00344-01} {AI95-00416-01AI95-00416-01}
+ Added accessibility checks to class-wide return statements.
+ These checks could not fail in Ada 95 (as all of the types had
+ to be declared at the same level, so the tagged type would
+ necessarily have been at the same level as the type of the
+ object).
+
+28.m/2
+ {AI95-00402-01AI95-00402-01} {AI95-00416-01AI95-00416-01}
+ Added accessibility checks to return statements for types with
+ access discriminants. Since such types have to be limited in
+ Ada 95, the expression of a return statement would have been
+ illegal in order for this check to fail.
+
+ _Inconsistencies With Ada 2005_
+
+28.n/3
+ {AI05-0050-1AI05-0050-1} Correction: The Implementation
+ Permission allowing early raising of Constraint_Error was
+ modified to remove the most common of these cases from the
+ permission (returning an object with mutable discriminants,
+ where the return object is created with one set of
+ discriminants and then changed to another). (The permission
+ was also widened to allow the early check for constrained
+ functions when that constraint is wrong.) However, there
+ still is an unlikely case where the permission would allow an
+ exception to be raised when none would be raised by the
+ canonical semantics (when a return statement is abandoned).
+ These changes can only remove the raising of an exception (or
+ change the place where it is raised) compared to Ada 2005, so
+ programs that depend on the previous behavior should be very
+ rare.
+
+28.o/3
+ {AI05-0051-1AI05-0051-1} {AI05-0234-1AI05-0234-1} Correction:
+ Accessibility checks for access discriminants now depend on
+ the master of the call rather than the point of declaration of
+ the function. This will result in cases that used to raise
+ Program_Error now running without raising any exception. This
+ is technically inconsistent with Ada 2005 (as defined by
+ Amendment 1), but it is unlikely that any real code depends on
+ the raising of this exception.
+
+28.p/3
+ {AI05-0073-1AI05-0073-1} Correction: Added a tag check for
+ functions returning anonymous access-to-tagged types, so that
+ dispatching of tag-indeterminate function works as expected.
+ This is technically inconsistent with Ada 2005 (as defined by
+ Amendment 1), but as the feature in question was newly added
+ to Ada 2005, there should be little code that depends on the
+ behavior that now raises an exception.
+
+ _Incompatibilities With Ada 2005_
+
+28.q/3
+ {AI05-0053-1AI05-0053-1} {AI05-0277-1AI05-0277-1} Correction:
+ The aliased keyword can now only appear on extended return
+ objects with an immutably limited type. Other types would
+ provide a way to get an aliased view of an object that is not
+ necessarily aliased, which would be very bad. This is
+ incompatible, but since the feature was added in Ada 2005, the
+ keyword had no defined meaning in Ada 2005 (a significant
+ oversight), and most sensible uses involve immutably limited
+ types, it is unlikely that it appears meaningfully in existing
+ programs.
+
+28.r/3
+ {AI05-0103-1AI05-0103-1} Correction: Added wording to require
+ static matching for unconstrained access types in extended
+ return statements. This disallows adding or omitting null
+ exclusions, and adding access constraints, in the declaration
+ of the return object. While this is incompatible, the
+ incompatible cases in question are either useless (access
+ constraints - the constraint can be given on an allocator if
+ necessary, and still must be given there even if given on the
+ return object) or wrong (null exclusions - null could be
+ returned from a function declared to be null excluding), so we
+ expect them to be extremely rare in practice.
+
+ _Extensions to Ada 2005_
+
+28.s/3
+ {AI05-0015-1AI05-0015-1} {AI05-0144-2AI05-0144-2} The return
+ object of an extended_return_statement can be declared
+ constant; this works similarly to a constant object
+ declaration.
+
+28.t/3
+ {AI05-0032-1AI05-0032-1} Added wording to allow the
+ return_subtype_indication to have a specific type if the
+ return subtype of the function is class-wide. Specifying the
+ (specific) type of the return object is awkward without this
+ change, and this is consistent with the way allocators work.
+
+ _Wording Changes from Ada 2005_
+
+28.u/3
+ {AI05-0024-1AI05-0024-1} Correction: Corrected the master
+ check for tags since the masters may be for different tasks
+ and thus incomparable.
+
+28.v/3
+ {AI05-0058-1AI05-0058-1} Correction: Corrected the wording
+ defining returns for extended_return_statements, since leaving
+ by an exit or goto is considered "normal" completion of the
+ statement.
+
+28.w/3
+ {AI05-0205-1AI05-0205-1} {AI05-0277-1AI05-0277-1} Correction:
+ Added the extended_return_object_declaration to make other
+ rules easier to write and eliminate the problem described in
+ AI05-0205-1.
+
+* Menu:
+
+* 6.5.1 :: Nonreturning Procedures
+
+\1f
+File: aarm2012.info, Node: 6.5.1, Up: 6.5
+
+6.5.1 Nonreturning Procedures
+-----------------------------
+
+1/3
+{AI95-00329-01AI95-00329-01} {AI95-00414-01AI95-00414-01}
+{AI05-0229-1AI05-0229-1} Specifying aspect No_Return to have the value
+True indicates that a procedure cannot return normally[; it may
+propagate an exception or loop forever].
+
+1.a/3
+ Discussion: Aspect No_Deposit will have to wait for Ada 2020.
+ :-)
+
+Paragraphs 2 and 3 were moved to *note Annex J::, "*note Annex J::
+Obsolescent Features".
+
+ _Static Semantics_
+
+3.1/3
+{AI05-0229-1AI05-0229-1} For a procedure or generic procedure, the
+following language-defined representation aspect may be specified:
+
+3.2/3
+No_Return
+ The type of aspect No_Return is Boolean. When aspect
+ No_Return is True for an entity, the entity is said to be
+ nonreturning.
+
+3.3/3
+ If directly specified, the aspect_definition shall be a
+ static expression. [This aspect is never inherited;] if
+ not directly specified, the aspect is False.
+
+3.a/3
+ Aspect Description for No_Return: A procedure will not return
+ normally.
+
+3.4/3
+{AI05-0229-1AI05-0229-1} If a generic procedure is nonreturning, then so
+are its instances. If a procedure declared within a generic unit is
+nonreturning, then so are the corresponding copies of that procedure in
+instances.
+
+ _Legality Rules_
+
+4/3
+{AI95-00329-01AI95-00329-01} {AI95-00414-01AI95-00414-01}
+{AI05-0229-1AI05-0229-1} Aspect No_Return shall not be specified for a
+null procedure nor an instance of a generic unit.
+
+4.a/2
+ Reason: A null procedure cannot have the appropriate
+ nonreturning semantics, as it does not raise an exception or
+ loop forever.
+
+4.b/3
+ Ramification: {AI05-0229-1AI05-0229-1} The procedure can be
+ abstract. If a nonreturning procedure is renamed (anywhere)
+ calls through the new name still have the nonreturning
+ semantics.
+
+5/2
+{AI95-00329-01AI95-00329-01} {AI95-00414-01AI95-00414-01} A return
+statement shall not apply to a nonreturning procedure or generic
+procedure.
+
+6/2
+{AI95-00414-01AI95-00414-01} A procedure shall be nonreturning if it
+overrides a dispatching nonreturning procedure. In addition to the
+places where Legality Rules normally apply (see *note 12.3::), this rule
+applies also in the private part of an instance of a generic unit.
+
+6.a/2
+ Reason: This ensures that dispatching calls to nonreturning
+ procedures will, in fact, not return.
+
+7/2
+{AI95-00414-01AI95-00414-01} If a renaming-as-body completes a
+nonreturning procedure declaration, then the renamed procedure shall be
+nonreturning.
+
+7.a/2
+ Reason: This ensures that no extra code is needed to implement
+ the renames (that is, no wrapper is needed) as the body has
+ the same property.
+
+Paragraph 8 was deleted.
+
+ _Dynamic Semantics_
+
+9/2
+{AI95-00329-01AI95-00329-01} {AI95-00414-01AI95-00414-01} If the body of
+a nonreturning procedure completes normally, Program_Error is raised at
+the point of the call.
+
+9.a/2
+ Discussion: Note that there is no name for suppressing this
+ check, since the check represents a bug, imposes no time
+ overhead, and minimal space overhead (since it can usually be
+ statically eliminated as dead code).
+
+9.b/2
+ Implementation Note: If a nonreturning procedure tries to
+ return, we raise Program_Error. This is stated as happening
+ at the call site, because we do not wish to allow the
+ procedure to handle the exception (and then, perhaps, try to
+ return again!). However, the expected run-time model is that
+ the compiler will generate raise Program_Error at the end of
+ the procedure body (but not handleable by the procedure
+ itself), as opposed to doing it at the call site. (This is
+ just like the typical run-time model for functions that fall
+ off the end without returning a value). The reason is
+ indirect calls: in P.all(...);, the compiler cannot know
+ whether P designates a nonreturning procedure or a normal one.
+ Putting the raise Program_Error in the procedure's generated
+ code solves this problem neatly.
+
+9.c/2
+ Similarly, if one passes a nonreturning procedure to a generic
+ formal parameter, the compiler cannot know this at call sites
+ (in shared code implementations); the raise-in-body solution
+ deals with this neatly.
+
+ _Examples_
+
+10/3
+ {AI95-00433-01AI95-00433-01} {AI05-0229-1AI05-0229-1} procedure Fail(Msg : String) -- raises Fatal_Error exception
+ with No_Return;
+ -- Inform compiler and reader that procedure never returns normally
+
+ _Extensions to Ada 95_
+
+10.a/2
+ {AI95-00329-01AI95-00329-01} {AI95-00414-01AI95-00414-01}
+ Pragma No_Return is new.
+
+ _Extensions to Ada 2005_
+
+10.b/3
+ {AI05-0229-1AI05-0229-1} Aspect No_Return is new; pragma
+ No_Return is now obsolescent.
+
+\1f
+File: aarm2012.info, Node: 6.6, Next: 6.7, Prev: 6.5, Up: 6
+
+6.6 Overloading of Operators
+============================
+
+1
+An operator is a function whose designator is an operator_symbol.
+[Operators, like other functions, may be overloaded.]
+
+ _Name Resolution Rules_
+
+2
+Each use of a unary or binary operator is equivalent to a function_call
+with function_prefix being the corresponding operator_symbol, and with
+(respectively) one or two positional actual parameters being the
+operand(s) of the operator (in order).
+
+2.a/3
+ To be honest: {AI05-0299-1AI05-0299-1} We also use the term
+ operator (in Clause 4 and in *note 6.1::) to refer to one of
+ the syntactic categories defined in *note 4.5::, "*note 4.5::
+ Operators and Expression Evaluation" whose names end with
+ "_operator:" logical_operator (*note 4.5: S0127.),
+ relational_operator (*note 4.5: S0128.),
+ binary_adding_operator (*note 4.5: S0129.),
+ unary_adding_operator (*note 4.5: S0130.),
+ multiplying_operator (*note 4.5: S0131.), and
+ highest_precedence_operator (*note 4.5: S0132.).
+
+2.b/3
+ Discussion: {AI05-0005-1AI05-0005-1} This equivalence extends
+ to uses of function_call in most other language rules.
+ However, as often happens, the equivalence is not perfect, as
+ operator calls are not a name, while a function_call is a
+ name. Thus, operator calls cannot be used in contexts that
+ require a name (such as a rename of an object). A direct fix
+ for this problem would be very disruptive, and thus we have
+ not done that. However, qualifying an operator call can be
+ used as a workaround in contexts that require a name.
+
+ _Legality Rules_
+
+3/3
+{AI05-0143-1AI05-0143-1} The subprogram_specification of a unary or
+binary operator shall have one or two parameters, respectively. The
+parameters shall be of mode in. A generic function instantiation whose
+designator is an operator_symbol is only allowed if the specification of
+the generic function has the corresponding number of parameters, and
+they are all of mode in.
+
+4
+Default_expressions are not allowed for the parameters of an operator
+(whether the operator is declared with an explicit
+subprogram_specification or by a generic_instantiation).
+
+5
+An explicit declaration of "/=" shall not have a result type of the
+predefined type Boolean.
+
+ _Static Semantics_
+
+6/3
+{AI05-0128-1AI05-0128-1} An explicit declaration of "=" whose result
+type is Boolean implicitly declares an operator "/=" that gives the
+complementary result.
+
+6.a/3
+ Discussion: {AI05-0128-1AI05-0128-1} A "/=" defined by this
+ rule is considered user-defined, which means that it will be
+ inherited by a derived type. "User-defined" means "not
+ language-defined" for the purposes of inheritance, that is
+ anything other than predefined operators.
+
+ NOTES
+
+7
+ 8 The operators "+" and "-" are both unary and binary operators,
+ and hence may be overloaded with both one- and two-parameter
+ functions.
+
+ _Examples_
+
+8
+Examples of user-defined operators:
+
+9
+ function "+" (Left, Right : Matrix) return Matrix;
+ function "+" (Left, Right : Vector) return Vector;
+
+ -- assuming that A, B, and C are of the type Vector
+ -- the following two statements are equivalent:
+
+ A := B + C;
+ A := "+"(B, C);
+
+ _Extensions to Ada 83_
+
+9.a
+ Explicit declarations of "=" are now permitted for any
+ combination of parameter and result types.
+
+9.b
+ Explicit declarations of "/=" are now permitted, so long as
+ the result type is not Boolean.
+
+ _Wording Changes from Ada 2005_
+
+9.c/3
+ {AI05-0128-1AI05-0128-1} Correction: Corrected the wording so
+ that only explicit declarations of "=" cause an implicit
+ declaration of "/="; otherwise, we could get multiple implicit
+ definitions of "/=" without an obvious way to chose between
+ them.
+
+9.d/3
+ {AI05-0143-1AI05-0143-1} Added wording so that operators only
+ allow parameters of mode in. This was made necessary by the
+ elimination elsewhere of the restriction that function
+ parameters be only of mode in.
+
+\1f
+File: aarm2012.info, Node: 6.7, Next: 6.8, Prev: 6.6, Up: 6
+
+6.7 Null Procedures
+===================
+
+1/2
+{AI95-00348-01AI95-00348-01} A null_procedure_declaration provides a
+shorthand to declare a procedure with an empty body.
+
+ _Syntax_
+
+2/3
+ {AI95-00348-01AI95-00348-01} {AI05-0183-1AI05-0183-1}
+ null_procedure_declaration ::=
+ [overriding_indicator]
+ procedure_specification is null
+ [aspect_specification];
+
+ _Legality Rules_
+
+2.1/3
+{AI05-0177-1AI05-0177-1} If a null_procedure_declaration is a
+completion, it shall be the completion of a subprogram_declaration or
+generic_subprogram_declaration. The profile of a
+null_procedure_declaration that completes a declaration shall conform
+fully to that of the declaration.
+
+ _Static Semantics_
+
+3/3
+{AI95-00348-01AI95-00348-01} {AI05-0177-1AI05-0177-1}
+{AI05-0264-1AI05-0264-1} A null_procedure_declaration declares a null
+procedure. A completion is not allowed for a
+null_procedure_declaration; however, a null_procedure_declaration can
+complete a previous declaration.
+
+3.a/2
+ Reason: There are no null functions because the return value
+ has to be constructed somehow; a function that always raises
+ Program_Error doesn't seem very useful or worth the
+ complication.
+
+ _Dynamic Semantics_
+
+4/2
+{AI95-00348-01AI95-00348-01} The execution of a null procedure is
+invoked by a subprogram call. For the execution of a subprogram call on
+a null procedure, the execution of the subprogram_body has no effect.
+
+4.a/2
+ Ramification: Thus, a null procedure is equivalent to the body
+
+4.b/2
+ begin
+ null;
+ end;
+
+4.c/2
+ with the exception that a null procedure can be used in place
+ of a procedure specification.
+
+5/3
+{AI95-00348-01AI95-00348-01} {AI05-0177-1AI05-0177-1} The elaboration of
+a null_procedure_declaration has no other effect than to establish that
+the null procedure can be called without failing the Elaboration_Check.
+
+ _Examples_
+
+6/2
+ {AI95-00433-01AI95-00433-01} procedure Simplify(Expr : in out Expression) is null; -- see *note 3.9::
+ -- By default, Simplify does nothing, but it may be overridden in extensions of Expression
+
+ _Extensions to Ada 95_
+
+6.a/2
+ {AI95-00348-01AI95-00348-01} Null procedures are new.
+
+ _Extensions to Ada 2005_
+
+6.b/3
+ {AI05-0177-1AI05-0177-1} A null_procedure_declaration can now
+ be a completion.
+
+6.c/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a null_procedure_declaration. This is described in
+ *note 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 6.8, Prev: 6.7, Up: 6
+
+6.8 Expression Functions
+========================
+
+1/3
+{AI05-0177-1AI05-0177-1} An expression_function_declaration provides a
+shorthand to declare a function whose body consists of a single return
+statement.
+
+ _Syntax_
+
+2/3
+ {AI95-0177-1AI95-0177-1} expression_function_declaration ::=
+ [overriding_indicator]
+ function_specification is
+ (expression)
+ [aspect_specification];
+
+ _Name Resolution Rules_
+
+3/3
+{AI05-0177-1AI05-0177-1} The expected type for the expression of an
+expression_function_declaration (*note 6.8: S0189.) is the result type
+(see *note 6.5::) of the function.
+
+ _Legality Rules_
+
+4/3
+{AI05-0177-1AI05-0177-1} If an expression_function_declaration (*note
+6.8: S0189.) is a completion, it shall be the completion of a
+subprogram_declaration or generic_subprogram_declaration. The profile
+of an expression_function_declaration (*note 6.8: S0189.) that completes
+a declaration shall conform fully to that of the declaration.
+
+5/3
+{AI05-0177-1AI05-0177-1} If the result subtype has one or more
+unconstrained access discriminants, the accessibility level of the
+anonymous access type of each access discriminant, as determined by the
+expression of the expression function, shall not be statically deeper
+than that of the master that elaborated the
+expression_function_declaration (*note 6.8: S0189.).
+
+5.a/3
+ Ramification: This can only fail if the discriminant is an
+ access to a part of a non-aliased parameter, as there can be
+ no local declarations here.
+
+5.b/3
+ Discussion: We don't need to repeat any of the other Legality
+ Rules for return statements since none of them can fail here:
+ the implicit return statement has to apply to this function
+ (and isn't nested in something), there clearly is a return
+ statement in this function, and the static classwide
+ accessibility check cannot fail as a tagged type cannot be
+ declared locally in an expression function.
+
+ _Static Semantics_
+
+6/3
+{AI05-0177-1AI05-0177-1} {AI05-0264-1AI05-0264-1} An
+expression_function_declaration (*note 6.8: S0189.) declares an
+expression function. A completion is not allowed for an
+expression_function_declaration (*note 6.8: S0189.); however, an
+expression_function_declaration (*note 6.8: S0189.) can complete a
+previous declaration.
+
+ _Dynamic Semantics_
+
+7/3
+{AI05-0177-1AI05-0177-1} {AI05-0262-1AI05-0262-1} The execution of an
+expression function is invoked by a subprogram call. For the execution
+of a subprogram call on an expression function, the execution of the
+subprogram_body executes an implicit function body containing only a
+simple_return_statement whose expression is that of the expression
+function.
+
+7.a/3
+ Discussion: The last sentence effectively means that all of
+ the dynamic wording in *note 6.5:: applies as needed, and we
+ don't have to repeat it here.
+
+8/3
+{AI05-0177-1AI05-0177-1} The elaboration of an
+expression_function_declaration (*note 6.8: S0189.) has no other effect
+than to establish that the expression function can be called without
+failing the Elaboration_Check.
+
+ _Examples_
+
+9/3
+ {AI05-0177-1AI05-0177-1} function Is_Origin (P : in Point) return Boolean is -- see *note 3.9::
+ (P.X = 0.0 and P.Y = 0.0);
+
+ _Extensions to Ada 2005_
+
+9.a/3
+ {AI05-0177-1AI05-0177-1} Expression functions are new in Ada
+ 2012.
+
+\1f
+File: aarm2012.info, Node: 7, Next: 8, Prev: 6, Up: Top
+
+7 Packages
+**********
+
+1
+[Packages are program units that allow the specification of groups of
+logically related entities. Typically, a package contains the
+declaration of a type (often a private type or private extension) along
+with the declarations of primitive subprograms of the type, which can be
+called from outside the package, while their inner workings remain
+hidden from outside users. ]
+
+* Menu:
+
+* 7.1 :: Package Specifications and Declarations
+* 7.2 :: Package Bodies
+* 7.3 :: Private Types and Private Extensions
+* 7.4 :: Deferred Constants
+* 7.5 :: Limited Types
+* 7.6 :: Assignment and Finalization
+
+\1f
+File: aarm2012.info, Node: 7.1, Next: 7.2, Up: 7
+
+7.1 Package Specifications and Declarations
+===========================================
+
+1
+[A package is generally provided in two parts: a package_specification
+and a package_body. Every package has a package_specification, but not
+all packages have a package_body.]
+
+ _Syntax_
+
+2
+ package_declaration ::= package_specification;
+
+3/3
+ {AI05-0183-1AI05-0183-1} package_specification ::=
+ package defining_program_unit_name
+ [aspect_specification] is
+ {basic_declarative_item}
+ [private
+ {basic_declarative_item}]
+ end [[parent_unit_name.]identifier]
+
+4
+ If an identifier or parent_unit_name.identifier appears at the end
+ of a package_specification, then this sequence of lexical elements
+ shall repeat the defining_program_unit_name.
+
+ _Legality Rules_
+
+5/2
+{AI95-00434-01AI95-00434-01} A package_declaration or
+generic_package_declaration requires a completion [(a body)] if it
+contains any basic_declarative_item that requires a completion, but
+whose completion is not in its package_specification.
+
+5.a/3
+ To be honest: {AI05-0229-1AI05-0229-1} If an implementation
+ supports it, the body of a package or generic package may be
+ imported (using aspect Import, see *note B.1::), in which case
+ no explicit body is allowed.
+
+ _Static Semantics_
+
+6/2
+{AI95-00420-01AI95-00420-01} {AI95-00434-01AI95-00434-01} The first list
+of basic_declarative_items of a package_specification of a package other
+than a generic formal package is called the visible part of the package.
+[ The optional list of basic_declarative_items after the reserved word
+private (of any package_specification) is called the private part of the
+package. If the reserved word private does not appear, the package has
+an implicit empty private part.] Each list of basic_declarative_items
+of a package_specification forms a declaration list of the package.
+
+6.a
+ Ramification: This definition of visible part does not apply
+ to generic formal packages -- *note 12.7:: defines the visible
+ part of a generic formal package.
+
+6.b
+ The implicit empty private part is important because certain
+ implicit declarations occur there if the package is a child
+ package, and it defines types in its visible part that are
+ derived from, or contain as components, private types declared
+ within the parent package. These implicit declarations are
+ visible in children of the child package. See *note 10.1.1::.
+
+7
+[An entity declared in the private part of a package is visible only
+within the declarative region of the package itself (including any child
+units -- see *note 10.1.1::). In contrast, expanded names denoting
+entities declared in the visible part can be used even outside the
+package; furthermore, direct visibility of such entities can be achieved
+by means of use_clauses (see *note 4.1.3:: and *note 8.4::).]
+
+ _Dynamic Semantics_
+
+8
+The elaboration of a package_declaration consists of the elaboration of
+its basic_declarative_items in the given order.
+
+ NOTES
+
+9
+ 1 The visible part of a package contains all the information that
+ another program unit is able to know about the package.
+
+10
+ 2 If a declaration occurs immediately within the specification of
+ a package, and the declaration has a corresponding completion that
+ is a body, then that body has to occur immediately within the body
+ of the package.
+
+10.a
+ Proof: This follows from the fact that the declaration and
+ completion are required to occur immediately within the same
+ declarative region, and the fact that bodies are disallowed
+ (by the Syntax Rules) in package_specifications. This does
+ not apply to instances of generic units, whose bodies can
+ occur in package_specifications.
+
+ _Examples_
+
+11
+Example of a package declaration:
+
+12
+ package Rational_Numbers is
+
+13
+ type Rational is
+ record
+ Numerator : Integer;
+ Denominator : Positive;
+ end record;
+
+14
+ function "="(X,Y : Rational) return Boolean;
+
+15
+ function "/" (X,Y : Integer) return Rational; -- to construct a rational number
+
+16
+ function "+" (X,Y : Rational) return Rational;
+ function "-" (X,Y : Rational) return Rational;
+ function "*" (X,Y : Rational) return Rational;
+ function "/" (X,Y : Rational) return Rational;
+ end Rational_Numbers;
+
+17
+There are also many examples of package declarations in the predefined
+language environment (see *note Annex A::).
+
+ _Incompatibilities With Ada 83_
+
+17.a
+ In Ada 83, a library package is allowed to have a body even if
+ it doesn't need one. In Ada 95, a library package body is
+ either required or forbidden -- never optional. The
+ workaround is to add pragma Elaborate_Body, or something else
+ requiring a body, to each library package that has a body that
+ isn't otherwise required.
+
+ _Wording Changes from Ada 83_
+
+17.b/3
+ {AI05-0299-1AI05-0299-1} We have moved the syntax into this
+ subclause and the next subclause from RM83-7.1, "Package
+ Structure", which we have removed.
+
+17.c
+ RM83 was unclear on the rules about when a package requires a
+ body. For example, RM83-7.1(4) and RM83-7.1(8) clearly forgot
+ about the case of an incomplete type declared in a
+ package_declaration but completed in the body. In addition,
+ RM83 forgot to make this rule apply to a generic package. We
+ have corrected these rules. Finally, since we now allow a
+ pragma Import for any explicit declaration, the completion
+ rules need to take this into account as well.
+
+ _Wording Changes from Ada 95_
+
+17.d/2
+ {AI95-00420-01AI95-00420-01} Defined "declaration list" to
+ avoid ambiguity in other rules as to whether packages are
+ included.
+
+ _Extensions to Ada 2005_
+
+17.e/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a package_specification. This is described in
+ *note 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 7.2, Next: 7.3, Prev: 7.1, Up: 7
+
+7.2 Package Bodies
+==================
+
+1
+[In contrast to the entities declared in the visible part of a package,
+the entities declared in the package_body are visible only within the
+package_body itself. As a consequence, a package with a package_body
+can be used for the construction of a group of related subprograms in
+which the logical operations available to clients are clearly isolated
+from the internal entities.]
+
+ _Syntax_
+
+2/3
+ {AI05-0267-1AI05-0267-1} package_body ::=
+ package body defining_program_unit_name
+ [aspect_specification] is
+ declarative_part
+ [begin
+ handled_sequence_of_statements]
+ end [[parent_unit_name.]identifier];
+
+3
+ If an identifier or parent_unit_name.identifier appears at the end
+ of a package_body, then this sequence of lexical elements shall
+ repeat the defining_program_unit_name.
+
+ _Legality Rules_
+
+4
+A package_body shall be the completion of a previous package_declaration
+(*note 7.1: S0190.) or generic_package_declaration (*note 12.1: S0272.).
+A library package_declaration (*note 7.1: S0190.) or library
+generic_package_declaration (*note 12.1: S0272.) shall not have a body
+unless it requires a body[; pragma Elaborate_Body can be used to require
+a library_unit_declaration (*note 10.1.1: S0249.) to have a body (see
+*note 10.2.1::) if it would not otherwise require one].
+
+4.a
+ Ramification: The first part of the rule forbids a
+ package_body from standing alone -- it has to belong to some
+ previous package_declaration or generic_package_declaration.
+
+4.b
+ A nonlibrary package_declaration or nonlibrary
+ generic_package_declaration that does not require a completion
+ may have a corresponding body anyway.
+
+ _Static Semantics_
+
+5/3
+{AI05-0299-1AI05-0299-1} In any package_body without statements there is
+an implicit null_statement (*note 5.1: S0149.). For any
+package_declaration (*note 7.1: S0190.) without an explicit completion,
+there is an implicit package_body (*note 7.2: S0192.) containing a
+single null_statement. For a noninstance, nonlibrary package, this body
+occurs at the end of the declarative_part (*note 3.11: S0086.) of the
+innermost enclosing program unit or block_statement (*note 5.6: S0160.);
+if there are several such packages, the order of the implicit
+package_bodies is unspecified. [(For an instance, the implicit
+package_body (*note 7.2: S0192.) occurs at the place of the
+instantiation (see *note 12.3::). For a library package, the place is
+partially determined by the elaboration dependences (see Clause *note
+10::).)]
+
+5.a
+ Discussion: Thus, for example, we can refer to something
+ happening just after the begin of a package_body, and we can
+ refer to the handled_sequence_of_statements of a package_body,
+ without worrying about all the optional pieces. The place of
+ the implicit body makes a difference for tasks activated by
+ the package. See also RM83-9.3(5).
+
+5.b
+ The implicit body would be illegal if explicit in the case of
+ a library package that does not require (and therefore does
+ not allow) a body. This is a bit strange, but not harmful.
+
+ _Dynamic Semantics_
+
+6
+For the elaboration of a nongeneric package_body, its declarative_part
+(*note 3.11: S0086.) is first elaborated, and its
+handled_sequence_of_statements (*note 11.2: S0265.) is then executed.
+
+ NOTES
+
+7
+ 3 A variable declared in the body of a package is only visible
+ within this body and, consequently, its value can only be changed
+ within the package_body. In the absence of local tasks, the value
+ of such a variable remains unchanged between calls issued from
+ outside the package to subprograms declared in the visible part.
+ The properties of such a variable are similar to those of a
+ "static" variable of C.
+
+8
+ 4 The elaboration of the body of a subprogram explicitly declared
+ in the visible part of a package is caused by the elaboration of
+ the body of the package. Hence a call of such a subprogram by an
+ outside program unit raises the exception Program_Error if the call
+ takes place before the elaboration of the package_body (see *note
+ 3.11::).
+
+ _Examples_
+
+9
+Example of a package body (see *note 7.1::):
+
+10
+ package body Rational_Numbers is
+
+11
+ procedure Same_Denominator (X,Y : in out Rational) is
+ begin
+ -- reduces X and Y to the same denominator:
+ ...
+ end Same_Denominator;
+
+12
+ function "="(X,Y : Rational) return Boolean is
+ U : Rational := X;
+ V : Rational := Y;
+ begin
+ Same_Denominator (U,V);
+ return U.Numerator = V.Numerator;
+ end "=";
+
+13
+ function "/" (X,Y : Integer) return Rational is
+ begin
+ if Y > 0 then
+ return (Numerator => X, Denominator => Y);
+ else
+ return (Numerator => -X, Denominator => -Y);
+ end if;
+ end "/";
+
+14
+ function "+" (X,Y : Rational) return Rational is ... end "+";
+ function "-" (X,Y : Rational) return Rational is ... end "-";
+ function "*" (X,Y : Rational) return Rational is ... end "*";
+ function "/" (X,Y : Rational) return Rational is ... end "/";
+
+15
+ end Rational_Numbers;
+
+ _Wording Changes from Ada 83_
+
+15.a
+ The syntax rule for package_body now uses the syntactic
+ category handled_sequence_of_statements.
+
+15.b
+ The declarative_part of a package_body is now required; that
+ doesn't make any real difference, since a declarative_part can
+ be empty.
+
+15.c
+ RM83 seems to have forgotten to say that a package_body can't
+ stand alone, without a previous declaration. We state that
+ rule here.
+
+15.d
+ RM83 forgot to restrict the definition of elaboration of
+ package_bodies to nongeneric ones. We have corrected that
+ omission.
+
+15.e
+ The rule about implicit bodies (from RM83-9.3(5)) is moved
+ here, since it is more generally applicable.
+
+ _Extensions to Ada 2005_
+
+15.f/3
+ {AI05-0267-1AI05-0267-1} An optional aspect_specification can
+ be used in a package_body. This is described in *note
+ 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 7.3, Next: 7.4, Prev: 7.2, Up: 7
+
+7.3 Private Types and Private Extensions
+========================================
+
+1
+[The declaration (in the visible part of a package) of a type as a
+private type or private extension serves to separate the characteristics
+that can be used directly by outside program units (that is, the logical
+properties) from other characteristics whose direct use is confined to
+the package (the details of the definition of the type itself). See
+*note 3.9.1:: for an overview of type extensions. ]
+
+ _Language Design Principles_
+
+1.a
+ A private (untagged) type can be thought of as a record type
+ with the type of its single (hidden) component being the full
+ view.
+
+1.b
+ A private tagged type can be thought of as a private extension
+ of an anonymous parent with no components. The only
+ dispatching operation of the parent is equality (although the
+ Size attribute, and, if nonlimited, assignment are allowed,
+ and those will presumably be implemented in terms of
+ dispatching).
+
+ _Syntax_
+
+2/3
+ {AI05-0183-1AI05-0183-1} private_type_declaration ::=
+ type defining_identifier [
+ discriminant_part] is [[abstract] tagged] [limited] private
+ [aspect_specification];
+
+3/3
+ {AI95-00251-01AI95-00251-01} {AI95-00419-01AI95-00419-01}
+ {AI95-00443-01AI95-00443-01} {AI05-0183-1AI05-0183-1}
+ private_extension_declaration ::=
+ type defining_identifier [discriminant_part] is
+ [abstract] [limited | synchronized] new ancestor_
+ subtype_indication
+ [and interface_list] with private
+ [aspect_specification];
+
+ _Legality Rules_
+
+4
+A private_type_declaration or private_extension_declaration declares a
+partial view of the type; such a declaration is allowed only as a
+declarative_item of the visible part of a package, and it requires a
+completion, which shall be a full_type_declaration that occurs as a
+declarative_item of the private part of the package. [ The view of the
+type declared by the full_type_declaration is called the full view.] A
+generic formal private type or a generic formal private extension is
+also a partial view.
+
+4.a
+ To be honest: A private type can also be imported (using
+ aspect Import, see *note B.1::), in which case no completion
+ is allowed, if supported by an implementation.
+
+4.b
+ Reason: We originally used the term "private view," but this
+ was easily confused with the view provided from the private
+ part, namely the full view.
+
+4.c/2
+ Proof: {AI95-00326-01AI95-00326-01} Full view is now defined
+ in *note 3.2.1::, "*note 3.2.1:: Type Declarations", as all
+ types now have them.
+
+5
+[A type shall be completely defined before it is frozen (see *note
+3.11.1:: and *note 13.14::). Thus, neither the declaration of a
+variable of a partial view of a type, nor the creation by an allocator
+of an object of the partial view are allowed before the full declaration
+of the type. Similarly, before the full declaration, the name of the
+partial view cannot be used in a generic_instantiation or in a
+representation item.]
+
+5.a
+ Proof: This rule is stated officially in *note 3.11.1::,
+ "*note 3.11.1:: Completions of Declarations".
+
+6/2
+{AI95-00419-01AI95-00419-01} {AI95-00443-01AI95-00443-01} [A private
+type is limited if its declaration includes the reserved word limited; a
+private extension is limited if its ancestor type is a limited type that
+is not an interface type, or if the reserved word limited or
+synchronized appears in its definition.] If the partial view is
+nonlimited, then the full view shall be nonlimited. If a tagged partial
+view is limited, then the full view shall be limited. [On the other
+hand, if an untagged partial view is limited, the full view may be
+limited or nonlimited.]
+
+7
+If the partial view is tagged, then the full view shall be tagged. [On
+the other hand, if the partial view is untagged, then the full view may
+be tagged or untagged.] In the case where the partial view is untagged
+and the full view is tagged, no derivatives of the partial view are
+allowed within the immediate scope of the partial view; [derivatives of
+the full view are allowed.]
+
+7.a
+ Ramification: Note that deriving from a partial view within
+ its immediate scope can only occur in a package that is a
+ child of the one where the partial view is declared. The rule
+ implies that in the visible part of a public child package, it
+ is impossible to derive from an untagged private type declared
+ in the visible part of the parent package in the case where
+ the full view of the parent type turns out to be tagged. We
+ considered a model in which the derived type was implicitly
+ redeclared at the earliest place within its immediate scope
+ where characteristics needed to be added. However, we
+ rejected that model, because (1) it would imply that (for an
+ untagged type) subprograms explicitly declared after the
+ derived type could be inherited, and (2) to make this model
+ work for composite types as well, several implicit
+ redeclarations would be needed, since new characteristics can
+ become visible one by one; that seemed like too much
+ mechanism.
+
+7.b
+ Discussion: The rule for tagged partial views is redundant for
+ partial views that are private extensions, since all
+ extensions of a given ancestor tagged type are tagged, and
+ limited if the ancestor is limited. We phrase this rule
+ partially redundantly to keep its structure parallel with the
+ other rules.
+
+7.c
+ To be honest: This rule is checked in a generic unit, rather
+ than using the "assume the best" or "assume the worst" method.
+
+7.d/2
+ Reason: {AI95-00230-01AI95-00230-01} Tagged limited private
+ types have certain capabilities that are incompatible with
+ having assignment for the full view of the type. In
+ particular, tagged limited private types can be extended with
+ components of a limited type, which works only because
+ assignment is not allowed. Consider the following example:
+
+7.e
+ package P1 is
+ type T1 is tagged limited private;
+ procedure Foo(X : in T1'Class);
+ private
+ type T1 is tagged null record; -- Illegal!
+ -- This should say "tagged limited null record".
+ end P1;
+
+7.f/1
+ package body P1 is
+ type A is access T1'Class;
+ Global : A;
+ procedure Foo(X : in T1'Class) is
+ begin
+ Global := new T1'Class'(X);
+ -- This would be illegal if the full view of
+ -- T1 were limited, like it's supposed to be.
+ end Foo;
+ end P1;
+
+7.g/2
+ {AI95-00230-01AI95-00230-01} with P1;
+ package P2 is
+ type T2(D : access Integer)
+ is new P1.T1 with
+ record
+ My_Task : Some_Task_Type; -- Trouble!
+ end record;
+ end P2;
+
+7.h/1
+ with P1;
+ with P2;
+ procedure Main is
+ Local : aliased Integer;
+ Y : P2.T2(D => Local'Access);
+ begin
+ P1.Foo(Y);
+ end Main;
+
+
+7.i/2
+ {AI95-00230-01AI95-00230-01} If the above example were legal,
+ we would have succeeded in doing an assignment of a task
+ object, which is supposed to be a no-no.
+
+7.j
+ This rule is not needed for private extensions, because they
+ inherit their limitedness from their ancestor, and there is a
+ separate rule forbidding limited components of the
+ corresponding record extension if the parent is nonlimited.
+
+7.k
+ Ramification: A type derived from an untagged private type is
+ untagged, even if the full view of the parent is tagged, and
+ even at places that can see the parent:
+
+7.l
+ package P is
+ type Parent is private;
+ private
+ type Parent is tagged
+ record
+ X: Integer;
+ end record;
+ end P;
+
+7.m/1
+ with P;
+ package Q is
+ type T is new P.Parent;
+ end Q;
+
+7.n
+ with Q; use Q;
+ package body P is
+ ... T'Class ... -- Illegal!
+ Object: T;
+ ... Object.X ... -- Illegal!
+ ... Parent(Object).X ... -- OK.
+ end P;
+
+7.o
+ The declaration of T declares an untagged view. This view is
+ always untagged, so T'Class is illegal, it would be illegal to
+ extend T, and so forth. The component name X is never visible
+ for this view, although the component is still there -- one
+ can get one's hands on it via a type_conversion.
+
+7.1/2
+{AI95-00396-01AI95-00396-01} If a full type has a partial view that is
+tagged, then:
+
+7.2/2
+ * the partial view shall be a synchronized tagged type (see *note
+ 3.9.4::) if and only if the full type is a synchronized tagged
+ type;
+
+7.o.1/2
+ Reason: Since we do not allow record extensions of
+ synchronized tagged types, this property has to be visible in
+ the partial view to avoid privacy breaking. Generic formals
+ do not need a similar rule as any extensions are rechecked for
+ legality in the specification, and extensions of tagged
+ formals are always illegal in a generic body.
+
+7.3/2
+ * the partial view shall be a descendant of an interface type (see
+ 3.9.4) if and only if the full type is a descendant of the
+ interface type.
+
+7.p/2
+ Reason: Consider the following example:
+
+7.q/2
+ package P is
+ package Pkg is
+ type Ifc is interface;
+ procedure Foo (X : Ifc) is abstract;
+ end Pkg;
+
+7.r/2
+ type Parent_1 is tagged null record;
+
+7.s/2
+ type T1 is new Parent_1 with private;
+ private
+ type Parent_2 is new Parent_1 and Pkg.Ifc with null record;
+ procedure Foo (X : Parent_2); -- Foo #1
+
+7.t/2
+ type T1 is new Parent_2 with null record; -- Illegal.
+ end P;
+
+7.u/2
+ with P;
+ package P_Client is
+ type T2 is new P.T1 and P.Pkg.Ifc with null record;
+ procedure Foo (X : T2); -- Foo #2
+ X : T2;
+ end P_Client;
+
+7.v/2
+ with P_Client;
+ package body P is
+ ...
+
+7.w/2
+ procedure Bar (X : T1'Class) is
+ begin
+ Pkg.Foo (X); -- should call Foo #1 or an override thereof
+ end;
+
+7.x/2
+ begin
+ Pkg.Foo (Pkg.Ifc'Class (P_Client.X)); -- should call Foo #2
+ Bar (T1'Class (P_Client.X));
+ end P;
+
+7.y/2
+ This example is illegal because the completion of T1 is
+ descended from an interface that the partial view is not
+ descended from. If it were legal, T2 would implement Ifc
+ twice, once in the visible part of P, and once in the visible
+ part of P_Client. We would need to decide how Foo #1 and Foo
+ #2 relate to each other. There are two options: either Foo #2
+ overrides Foo #1, or it doesn't.
+
+7.z/2
+ If Foo #2 overrides Foo #1, we have a problem because the
+ client redefines a behavior that it doesn't know about, and we
+ try to avoid this at all costs, as it would lead to a
+ breakdown of whatever abstraction was implemented. If the
+ abstraction didn't expose that it implements Ifc, there must
+ be a reason, and it should be able to depend on the fact that
+ no overriding takes place in clients. Also, during
+ maintenance, things may change and the full view might
+ implement a different set of interfaces. Furthermore, the
+ situation is even worse if the full type implements another
+ interface Ifc2 that happens to have a conforming Foo
+ (otherwise unrelated, except for its name and profile).
+
+7.aa/2
+ If Foo #2 doesn't override Foo #1, there is some similarity
+ with the case of normal tagged private types, where a client
+ can declare an operation that happens to conform to some
+ private operation, and that's OK, it gets a different slot in
+ the type descriptor. The problem here is that T2 would
+ implement Ifc in two different ways, and through conversions
+ to Ifc'Class we could end up with visibility on both of these
+ two different implementations. This is the "diamond
+ inheritance" problem of C++ all over again, and we would need
+ some kind of a preference rule to pick one implementation. We
+ don't want to go there (if we did, we might as well provide
+ full-fledged multiple inheritance).
+
+7.bb/2
+ Note that there wouldn't be any difficulty to implement the
+ first option, so the restriction is essentially
+ methodological. The second option might be harder to
+ implement, depending on the language rules that we would
+ choose.
+
+7.cc/3
+ Ramification: {AI05-0005-1AI05-0005-1} This rule also prevents
+ completing a private type with an interface. An interface,
+ like all types, is a descendant of itself, and thus this rule
+ is triggered. One reason this is necessary is that a client
+ of a private extension should be able to inherit limitedness
+ without having to look in the private part to see if the type
+ is an interface (remember that limitedness of interfaces is
+ never inherited, while it is inherited from other types).
+
+8
+The ancestor subtype of a private_extension_declaration is the subtype
+defined by the ancestor_subtype_indication (*note 3.2.2: S0027.); the
+ancestor type shall be a specific tagged type. The full view of a
+private extension shall be derived (directly or indirectly) from the
+ancestor type. In addition to the places where Legality Rules normally
+apply (see *note 12.3::), the requirement that the ancestor be specific
+applies also in the private part of an instance of a generic unit.
+
+8.a
+ Reason: This rule allows the full view to be defined through
+ several intermediate derivations, possibly from a series of
+ types produced by generic_instantiations.
+
+8.1/2
+{AI95-00419-01AI95-00419-01} {AI95-00443-01AI95-00443-01} If the
+reserved word limited appears in a private_extension_declaration, the
+ancestor type shall be a limited type. If the reserved word
+synchronized appears in a private_extension_declaration, the ancestor
+type shall be a limited interface.
+
+9
+If the declaration of a partial view includes a known_discriminant_part,
+then the full_type_declaration shall have a fully conforming
+[(explicit)] known_discriminant_part [(see *note 6.3.1::, "*note 6.3.1::
+Conformance Rules")]. [The ancestor subtype may be unconstrained; the
+parent subtype of the full view is required to be constrained (see *note
+3.7::).]
+
+9.a
+ Discussion: If the ancestor subtype has discriminants, then it
+ is usually best to make it unconstrained.
+
+9.b
+ Ramification: If the partial view has a
+ known_discriminant_part, then the full view has to be a
+ composite, non-array type, since only such types may have
+ known discriminants. Also, the full view cannot inherit the
+ discriminants in this case; the known_discriminant_part has to
+ be explicit.
+
+9.c
+ That is, the following is illegal:
+
+9.d
+ package P is
+ type T(D : Integer) is private;
+ private
+ type T is new Some_Other_Type; -- Illegal!
+ end P;
+
+
+9.e
+ even if Some_Other_Type has an integer discriminant called D.
+
+9.f
+ It is a ramification of this and other rules that in order for
+ a tagged type to privately inherit unconstrained
+ discriminants, the private type declaration has to have an
+ unknown_discriminant_part.
+
+10
+If a private extension inherits known discriminants from the ancestor
+subtype, then the full view shall also inherit its discriminants from
+the ancestor subtype, and the parent subtype of the full view shall be
+constrained if and only if the ancestor subtype is constrained.
+
+10.a
+ Reason: The first part ensures that the full view has the same
+ discriminants as the partial view. The second part ensures
+ that if the partial view is unconstrained, then the full view
+ is also unconstrained; otherwise, a client might constrain the
+ partial view in a way that conflicts with the constraint on
+ the full view.
+
+10.1/3
+{AI95-00419-01AI95-00419-01} {AI05-0004-1AI05-0004-1} If the
+full_type_declaration for a private extension includes a
+derived_type_definition, then the reserved word limited shall appear in
+the full_type_declaration if and only if it also appears in the
+private_extension_declaration.
+
+10.b/3
+ Reason: {AI05-0004-1AI05-0004-1} The word limited is optional
+ (unless the ancestor is an interface), but it should be used
+ consistently. Otherwise things would be too confusing for the
+ reader. Of course, we only require that if the full type
+ includes a derived_type_definition, as we want to allow task
+ and protected types to complete extensions of synchronized
+ interfaces.
+
+11
+[If a partial view has unknown discriminants, then the
+full_type_declaration may define a definite or an indefinite subtype,
+with or without discriminants.]
+
+12
+If a partial view has neither known nor unknown discriminants, then the
+full_type_declaration shall define a definite subtype.
+
+13
+If the ancestor subtype of a private extension has constrained
+discriminants, then the parent subtype of the full view shall impose a
+statically matching constraint on those discriminants.
+
+13.a
+ Ramification: If the parent type of the full view is not the
+ ancestor type, but is rather some descendant thereof, the
+ constraint on the discriminants of the parent type might come
+ from the declaration of some intermediate type in the
+ derivation chain between the ancestor type and the parent
+ type.
+
+13.b
+ Reason: This prevents the following:
+
+13.c
+ package P is
+ type T2 is new T1(Discrim => 3) with private;
+ private
+ type T2 is new T1(Discrim => 999) -- Illegal!
+ with record ...;
+ end P;
+
+13.d
+ The constraints in this example do not statically match.
+
+13.e
+ If the constraint on the parent subtype of the full view
+ depends on discriminants of the full view, then the ancestor
+ subtype has to be unconstrained:
+
+13.f
+ type One_Discrim(A: Integer) is tagged ...;
+ ...
+ package P is
+ type Two_Discrims(B: Boolean; C: Integer) is new One_Discrim with private;
+ private
+ type Two_Discrims(B: Boolean; C: Integer) is new One_Discrim(A => C) with
+ record
+ ...
+ end record;
+ end P;
+
+13.g
+ The above example would be illegal if the private extension
+ said "is new One_Discrim(A => C);", because then the
+ constraints would not statically match. (Constraints that
+ depend on discriminants are not static.)
+
+ _Static Semantics_
+
+14
+A private_type_declaration declares a private type and its first
+subtype. Similarly, a private_extension_declaration (*note 7.3: S0194.)
+declares a private extension and its first subtype.
+
+14.a
+ Discussion: A package-private type is one declared by a
+ private_type_declaration; that is, a private type other than a
+ generic formal private type. Similarly, a package-private
+ extension is one declared by a private_extension_declaration.
+ These terms are not used in the RM95 version of this document.
+
+15/3
+{AI05-0269-1AI05-0269-1} A declaration of a partial view and the
+corresponding full_type_declaration define two views of a single type.
+The declaration of a partial view together with the visible part define
+the operations that are available to outside program units; the
+declaration of the full view together with the private part define other
+operations whose direct use is possible only within the declarative
+region of the package itself. Moreover, within the scope of the
+declaration of the full view, the characteristics (see *note 3.4::) of
+the type are determined by the full view; in particular, within its
+scope, the full view determines the classes that include the type, which
+components, entries, and protected subprograms are visible, what
+attributes and other predefined operations are allowed, and whether the
+first subtype is static. See *note 7.3.1::.
+
+16/3
+{AI95-00401-01AI95-00401-01} {AI05-0110-1AI05-0110-1} For a private
+extension, the characteristics (including components, but excluding
+discriminants if there is a new discriminant_part specified), predefined
+operators, and inherited user-defined primitive subprograms are
+determined by its ancestor type and its progenitor types (if any), in
+the same way that those of a record extension are determined by those of
+its parent type and its progenitor types (see *note 3.4:: and *note
+7.3.1::).
+
+16.a/3
+ To be honest: {AI05-0110-1AI05-0110-1} If an operation of the
+ ancestor or parent type is abstract, then the abstractness of
+ the inherited operation is different for nonabstract record
+ extensions than for nonabstract private extensions (see *note
+ 3.9.3::).
+
+ _Dynamic Semantics_
+
+17
+The elaboration of a private_type_declaration creates a partial view of
+a type. The elaboration of a private_extension_declaration elaborates
+the ancestor_subtype_indication, and creates a partial view of a type.
+
+ NOTES
+
+18
+ 5 The partial view of a type as declared by a
+ private_type_declaration is defined to be a composite view (in
+ *note 3.2::). The full view of the type might or might not be
+ composite. A private extension is also composite, as is its full
+ view.
+
+19/2
+ 6 {AI95-00318-02AI95-00318-02} Declaring a private type with an
+ unknown_discriminant_part is a way of preventing clients from
+ creating uninitialized objects of the type; they are then forced to
+ initialize each object by calling some operation declared in the
+ visible part of the package.
+
+19.a
+ Discussion: Packages with private types are analogous to
+ generic packages with formal private types, as follows: The
+ declaration of a package-private type is like the declaration
+ of a formal private type. The visible part of the package is
+ like the generic formal part; these both specify a contract
+ (that is, a set of operations and other things available for
+ the private type). The private part of the package is like an
+ instantiation of the generic; they both give a
+ full_type_declaration that specifies implementation details of
+ the private type. The clients of the package are like the
+ body of the generic; usage of the private type in these places
+ is restricted to the operations defined by the contract.
+
+19.b
+ In other words, being inside the package is like being outside
+ the generic, and being outside the package is like being
+ inside the generic; a generic is like an "inside-out" package.
+
+19.c
+ This analogy also works for private extensions in the same
+ inside-out way.
+
+19.d
+ Many of the legality rules are defined with this analogy in
+ mind. See, for example, the rules relating to operations of
+ [formal] derived types.
+
+19.e
+ The completion rules for a private type are intentionally
+ quite similar to the matching rules for a generic formal
+ private type.
+
+19.f
+ This analogy breaks down in one respect: a generic actual
+ subtype is a subtype, whereas the full view for a private type
+ is always a new type. (We considered allowing the completion
+ of a private_type_declaration to be a subtype_declaration, but
+ the semantics just won't work.) This difference is behind the
+ fact that a generic actual type can be class-wide, whereas the
+ completion of a private type always declares a specific type.
+
+20/2
+ 7 {AI95-00401AI95-00401} The ancestor type specified in a
+ private_extension_declaration and the parent type specified in the
+ corresponding declaration of a record extension given in the
+ private part need not be the same. If the ancestor type is not an
+ interface type, the parent type of the full view can be any
+ descendant of the ancestor type. In this case, for a primitive
+ subprogram that is inherited from the ancestor type and not
+ overridden, the formal parameter names and default expressions (if
+ any) come from the corresponding primitive subprogram of the
+ specified ancestor type, while the body comes from the
+ corresponding primitive subprogram of the parent type of the full
+ view. See *note 3.9.2::.
+
+20.1/2
+ 8 {AI95-00401AI95-00401} If the ancestor type specified in a
+ private_extension_declaration is an interface type, the parent type
+ can be any type so long as the full view is a descendant of the
+ ancestor type. The progenitor types specified in a
+ private_extension_declaration and the progenitor types specified in
+ the corresponding declaration of a record extension given in the
+ private part need not be the same -- the only requirement is that
+ the private extension and the record extension be descended from
+ the same set of interfaces.
+
+ _Examples_
+
+21
+Examples of private type declarations:
+
+22
+ type Key is private;
+ type File_Name is limited private;
+
+23
+Example of a private extension declaration:
+
+24
+ type List is new Ada.Finalization.Controlled with private;
+
+ _Extensions to Ada 83_
+
+24.a
+ The syntax for a private_type_declaration is augmented to
+ allow the reserved word tagged.
+
+24.b
+ In Ada 83, a private type without discriminants cannot be
+ completed with a type with discriminants. Ada 95 allows the
+ full view to have discriminants, so long as they have defaults
+ (that is, so long as the first subtype is definite). This
+ change is made for uniformity with generics, and because the
+ rule as stated is simpler and easier to remember than the Ada
+ 83 rule. In the original version of Ada 83, the same
+ restriction applied to generic formal private types. However,
+ the restriction was removed by the ARG for generics. In order
+ to maintain the "generic contract/private type contract
+ analogy" discussed above, we have to apply the same rule to
+ package-private types. Note that a private untagged type
+ without discriminants can be completed with a tagged type with
+ discriminants only if the full view is constrained, because
+ discriminants of tagged types cannot have defaults.
+
+ _Wording Changes from Ada 83_
+
+24.c
+ RM83-7.4.1(4), "Within the specification of the package that
+ declares a private type and before the end of the
+ corresponding full type declaration, a restriction
+ applies....", is subsumed (and corrected) by the rule that a
+ type shall be completely defined before it is frozen, and the
+ rule that the parent type of a derived type declaration shall
+ be completely defined, unless the derived type is a private
+ extension.
+
+ _Extensions to Ada 95_
+
+24.d/2
+ {AI95-00251-01AI95-00251-01} {AI95-00396-01AI95-00396-01}
+ {AI95-00401-01AI95-00401-01} Added interface_list to private
+ extensions to support interfaces and multiple inheritance (see
+ *note 3.9.4::).
+
+24.e/2
+ {AI95-00419-01AI95-00419-01} A private extension may specify
+ that it is a limited type. This is required for interface
+ ancestors (from which limitedness is not inherited), but it is
+ generally useful as documentation of limitedness.
+
+24.f/2
+ {AI95-00443-01AI95-00443-01} A private extension may specify
+ that it is a synchronized type. This is required in order so
+ that a regular limited interface can be used as the ancestor
+ of a synchronized type (we do not allow hiding of
+ synchronization).
+
+ _Extensions to Ada 2005_
+
+24.g/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a private_type_declaration and a
+ private_extension_declaration. This is described in *note
+ 13.1.1::.
+
+ _Wording Changes from Ada 2005_
+
+24.h/3
+ {AI05-0110-1AI05-0110-1} Correction: The description of how a
+ private extension inherits characteristics was made consistent
+ with the way formal derived types inherit characteristics (see
+ *note 12.5.1::).
+
+* Menu:
+
+* 7.3.1 :: Private Operations
+* 7.3.2 :: Type Invariants
+
+\1f
+File: aarm2012.info, Node: 7.3.1, Next: 7.3.2, Up: 7.3
+
+7.3.1 Private Operations
+------------------------
+
+1
+[For a type declared in the visible part of a package or generic
+package, certain operations on the type do not become visible until
+later in the package -- either in the private part or the body. Such
+private operations are available only inside the declarative region of
+the package or generic package.]
+
+ _Static Semantics_
+
+2
+The predefined operators that exist for a given type are determined by
+the classes to which the type belongs. For example, an integer type has
+a predefined "+" operator. In most cases, the predefined operators of a
+type are declared immediately after the definition of the type; the
+exceptions are explained below. Inherited subprograms are also
+implicitly declared immediately after the definition of the type, except
+as stated below.
+
+3/3
+{8652/00198652/0019} {AI95-00033-01AI95-00033-01}
+{AI05-0029-1AI05-0029-1} For a composite type, the characteristics (see
+*note 7.3::) of the type are determined in part by the characteristics
+of its component types. At the place where the composite type is
+declared, the only characteristics of component types used are those
+characteristics visible at that place. If later immediately within the
+declarative region in which the composite type is declared additional
+characteristics become visible for a component type, then any
+corresponding characteristics become visible for the composite type.
+Any additional predefined operators are implicitly declared at that
+place. If there is no such place, then additional predefined operators
+are not declared at all, but they still exist.
+
+3.a/3
+ Reason: {AI05-0029-1AI05-0029-1} We say that the predefined
+ operators exist because they can emerge in some unusual
+ generic instantiations. See *note 12.5::.
+
+3.b/3
+ Discussion: {AI05-0029-1AI05-0029-1} The predefined operators
+ for the underlying class of a type always exist, even if there
+ is no visibility on that underlying class. This rule is
+ simply about where (if ever) those operators are declared (and
+ thus become usable). The "additional predefined operators"
+ defined by this rule are any that are not declared at the
+ point of the original type declaration. For instance, a type
+ derived from a private type whose full type is type String
+ always will have a ">" operator, but where that operator is
+ declared (and thus whether it is visible) will depend on the
+ visibility of the full type of the parent type.
+
+4/1
+{8652/00198652/0019} {AI95-00033-01AI95-00033-01} The corresponding rule
+applies to a type defined by a derived_type_definition, if there is a
+place immediately within the declarative region in which the type is
+declared where additional characteristics of its parent type become
+visible.
+
+5/1
+{8652/00198652/0019} {AI95-00033-01AI95-00033-01} [For example, an array
+type whose component type is limited private becomes nonlimited if the
+full view of the component type is nonlimited and visible at some later
+place immediately within the declarative region in which the array type
+is declared. In such a case, the predefined "=" operator is implicitly
+declared at that place, and assignment is allowed after that place.]
+
+5.1/3
+{AI05-0115-1AI05-0115-1} {AI05-0269-1AI05-0269-1} A type is a descendant
+of the full view of some ancestor of its parent type only if the current
+view it has of its parent is a descendant of the full view of that
+ancestor. More generally, at any given place, a type is descended from
+the same view of an ancestor as that from which the current view of its
+parent is descended. This view determines what characteristics are
+inherited from the ancestor[, and, for example, whether the type is
+considered to be a descendant of a record type, or a descendant only
+through record extensions of a more distant ancestor].
+
+5.2/3
+{AI05-0115-1AI05-0115-1} [It is possible for there to be places where a
+derived type is visibly a descendant of an ancestor type, but not a
+descendant of even a partial view of the ancestor type, because the
+parent of the derived type is not visibly a descendant of the ancestor.
+In this case, the derived type inherits no characteristics from that
+ancestor, but nevertheless is within the derivation class of the
+ancestor for the purposes of type conversion, the "covers" relationship,
+and matching against a formal derived type. In this case the derived
+type is considered to be a descendant of an incomplete view of the
+ancestor.]
+
+5.a.1/3
+ Discussion: Here is an example of this situation:
+
+5.a.2/3
+ package P is
+ type T is private;
+ C : constant T;
+ private
+ type T is new Integer;
+ C : constant T := 42;
+ end P;
+
+5.a.3/3
+ with P;
+ package Q is
+ type T2 is new P.T;
+ end Q;
+
+5.a.4/3
+ with Q;
+ package P.Child is
+ type T3 is new Q.T2;
+ private
+ Int : Integer := 52;
+ V : T3 := T3(P.C); -- Legal: conversion allowed
+ W : T3 := T3(Int); -- Legal: conversion allowed
+ X : T3 := T3(42); -- Error: T3 is not a numeric type
+ Y : T3 := X + 1; -- Error: no visible "+" operator
+ Z : T3 := T3(Integer(W) + 1); -- Legal: convert to Integer first
+ end P.Child;
+
+6/3
+{8652/00198652/0019} {AI95-00033-01AI95-00033-01}
+{AI05-0029-1AI05-0029-1} Inherited primitive subprograms follow a
+different rule. For a derived_type_definition, each inherited primitive
+subprogram is implicitly declared at the earliest place, if any,
+immediately within the declarative region in which the type_declaration
+occurs, but after the type_declaration, where the corresponding
+declaration from the parent is visible. If there is no such place, then
+the inherited subprogram is not declared at all, but it still exists.
+[For a tagged type, it is possible to dispatch to an inherited
+subprogram that is not declared at all.]
+
+7
+For a private_extension_declaration, each inherited subprogram is
+declared immediately after the private_extension_declaration if the
+corresponding declaration from the ancestor is visible at that place.
+Otherwise, the inherited subprogram is not declared for the private
+extension, [though it might be for the full type].
+
+7.a/1
+ Reason: There is no need for the "earliest place immediately
+ within the declarative region" business here, because a
+ private_extension_declaration will be completed with a
+ full_type_declaration, so we can hang the necessary private
+ implicit declarations on the full_type_declaration.
+
+7.b
+ Discussion: The above rules matter only when the component
+ type (or parent type) is declared in the visible part of a
+ package, and the composite type (or derived type) is declared
+ within the declarative region of that package (possibly in a
+ nested package or a child package).
+
+7.c
+ Consider:
+
+7.d
+ package Parent is
+ type Root is tagged null record;
+ procedure Op1(X : Root);
+
+7.e
+ type My_Int is range 1..10;
+ private
+ procedure Op2(X : Root);
+
+7.f
+ type Another_Int is new My_Int;
+ procedure Int_Op(X : My_Int);
+ end Parent;
+
+7.g
+ with Parent; use Parent;
+ package Unrelated is
+ type T2 is new Root with null record;
+ procedure Op2(X : T2);
+ end Unrelated;
+
+7.h
+ package Parent.Child is
+ type T3 is new Root with null record;
+ -- Op1(T3) implicitly declared here.
+
+7.i
+ package Nested is
+ type T4 is new Root with null record;
+ private
+ ...
+ end Nested;
+ private
+ -- Op2(T3) implicitly declared here.
+ ...
+ end Parent.Child;
+
+7.j
+ with Unrelated; use Unrelated;
+ package body Parent.Child is
+ package body Nested is
+ -- Op2(T4) implicitly declared here.
+ end Nested;
+
+7.k
+ type T5 is new T2 with null record;
+ end Parent.Child;
+
+7.l
+ Another_Int does not inherit Int_Op, because Int_Op does not
+ "exist" at the place where Another_Int is declared.
+
+7.m/1
+ Type T2 inherits Op1 and Op2 from Root. However, the
+ inherited Op2 is never declared, because Parent.Op2 is never
+ visible immediately within the declarative region of T2. T2
+ explicitly declares its own Op2, but this is unrelated to the
+ inherited one -- it does not override the inherited one, and
+ occupies a different slot in the type descriptor.
+
+7.n
+ T3 inherits both Op1 and Op2. Op1 is implicitly declared
+ immediately after the type declaration, whereas Op2 is
+ declared at the beginning of the private part. Note that if
+ Child were a private child of Parent, then Op1 and Op2 would
+ both be implicitly declared immediately after the type
+ declaration.
+
+7.o/1
+ T4 is similar to T3, except that the earliest place
+ immediately within the declarative region containing T4 where
+ Root's Op2 is visible is in the body of Nested.
+
+7.p
+ If T3 or T4 were to declare a type-conformant Op2, this would
+ override the one inherited from Root. This is different from
+ the situation with T2.
+
+7.q
+ T5 inherits Op1 and two Op2's from T2. Op1 is implicitly
+ declared immediately after the declaration of T5, as is the
+ Op2 that came from Unrelated.Op2. However, the Op2 that
+ originally came from Parent.Op2 is never implicitly declared
+ for T5, since T2's version of that Op2 is never visible
+ (anywhere -- it never got declared either).
+
+7.r
+ For all of these rules, implicit private parts and bodies are
+ assumed as needed.
+
+7.s
+ It is possible for characteristics of a type to be revealed in
+ more than one place:
+
+7.t
+ package P is
+ type Comp1 is private;
+ private
+ type Comp1 is new Boolean;
+ end P;
+
+7.u
+ package P.Q is
+ package R is
+ type Comp2 is limited private;
+ type A is array(Integer range <>) of Comp2;
+ private
+ type Comp2 is new Comp1;
+ -- A becomes nonlimited here.
+ -- "="(A, A) return Boolean is implicitly declared here.
+ ...
+ end R;
+ private
+ -- Now we find out what Comp1 really is, which reveals
+ -- more information about Comp2, but we're not within
+ -- the immediate scope of Comp2, so we don't do anything
+ -- about it yet.
+ end P.Q;
+
+7.v
+ package body P.Q is
+ package body R is
+ -- Things like "xor"(A,A) return A are implicitly
+ -- declared here.
+ end R;
+ end P.Q;
+
+7.v.1/1
+ {8652/00198652/0019} {AI95-00033-01AI95-00033-01} We say
+ immediately within the declarative region in order that types
+ do not gain operations within a nested scope. Consider:
+
+7.v.2/1
+ package Outer is
+ package Inner is
+ type Inner_Type is private;
+ private
+ type Inner_Type is new Boolean;
+ end Inner;
+ type Outer_Type is array(Natural range <>) of Inner.Inner_Type;
+ end Outer;
+
+7.v.3/1
+ package body Outer is
+ package body Inner is
+ -- At this point, we can see that Inner_Type is a Boolean type.
+ -- But we don't want Outer_Type to gain an "and" operator here.
+ end Inner;
+ end Outer;
+
+8
+[The Class attribute is defined for tagged subtypes in *note 3.9::. In
+addition,] for every subtype S of an untagged private type whose full
+view is tagged, the following attribute is defined:
+
+9
+S'Class
+ Denotes the class-wide subtype corresponding to the full
+ view of S. This attribute is allowed only from the
+ beginning of the private part in which the full view is
+ declared, until the declaration of the full view. [After
+ the full view, the Class attribute of the full view can
+ be used.]
+
+ NOTES
+
+10
+ 9 Because a partial view and a full view are two different views
+ of one and the same type, outside of the defining package the
+ characteristics of the type are those defined by the visible part.
+ Within these outside program units the type is just a private type
+ or private extension, and any language rule that applies only to
+ another class of types does not apply. The fact that the full
+ declaration might implement a private type with a type of a
+ particular class (for example, as an array type) is relevant only
+ within the declarative region of the package itself including any
+ child units.
+
+11
+ The consequences of this actual implementation are, however, valid
+ everywhere. For example: any default initialization of components
+ takes place; the attribute Size provides the size of the full view;
+ finalization is still done for controlled components of the full
+ view; task dependence rules still apply to components that are task
+ objects.
+
+12/2
+ 10 {AI95-00287-01AI95-00287-01} Partial views provide
+ initialization, membership tests, selected components for the
+ selection of discriminants and inherited components, qualification,
+ and explicit conversion. Nonlimited partial views also allow use
+ of assignment_statements.
+
+13
+ 11 For a subtype S of a partial view, S'Size is defined (see *note
+ 13.3::). For an object A of a partial view, the attributes A'Size
+ and A'Address are defined (see *note 13.3::). The Position,
+ First_Bit, and Last_Bit attributes are also defined for
+ discriminants and inherited components.
+
+ _Examples_
+
+14
+Example of a type with private operations:
+
+15
+ package Key_Manager is
+ type Key is private;
+ Null_Key : constant Key; -- a deferred constant declaration (see *note 7.4::)
+ procedure Get_Key(K : out Key);
+ function "<" (X, Y : Key) return Boolean;
+ private
+ type Key is new Natural;
+ Null_Key : constant Key := Key'First;
+ end Key_Manager;
+
+16
+ package body Key_Manager is
+ Last_Key : Key := Null_Key;
+ procedure Get_Key(K : out Key) is
+ begin
+ Last_Key := Last_Key + 1;
+ K := Last_Key;
+ end Get_Key;
+
+17
+ function "<" (X, Y : Key) return Boolean is
+ begin
+ return Natural(X) < Natural(Y);
+ end "<";
+ end Key_Manager;
+
+ NOTES
+
+18
+ 12 Notes on the example: Outside of the package Key_Manager, the
+ operations available for objects of type Key include assignment,
+ the comparison for equality or inequality, the procedure Get_Key
+ and the operator "<"; they do not include other relational
+ operators such as ">=", or arithmetic operators.
+
+19
+ The explicitly declared operator "<" hides the predefined operator
+ "<" implicitly declared by the full_type_declaration. Within the
+ body of the function, an explicit conversion of X and Y to the
+ subtype Natural is necessary to invoke the "<" operator of the
+ parent type. Alternatively, the result of the function could be
+ written as not (X >= Y), since the operator ">=" is not redefined.
+
+20
+ The value of the variable Last_Key, declared in the package body,
+ remains unchanged between calls of the procedure Get_Key. (See
+ also the NOTES of *note 7.2::.)
+
+ _Wording Changes from Ada 83_
+
+20.a
+ The phrase in RM83-7.4.2(7), "...after the full type
+ declaration", doesn't work in the presence of child units, so
+ we define that rule in terms of visibility.
+
+20.b
+ The definition of the Constrained attribute for private types
+ has been moved to "Obsolescent Features." (The Constrained
+ attribute of an object has not been moved there.)
+
+ _Wording Changes from Ada 95_
+
+20.c/2
+ {8652/00188652/0018} {AI95-00033-01AI95-00033-01} Corrigendum:
+ Clarified when additional operations are declared.
+
+20.d/2
+ {AI95-00287-01AI95-00287-01} Revised the note on operations of
+ partial views to reflect that limited types do have an
+ assignment operation, but not assignment_statements.
+
+ _Wording Changes from Ada 2005_
+
+20.e/3
+ {AI05-0029-1AI05-0029-1} Correction: Revised the wording to
+ say that predefined operations still exist even if they are
+ never declared, because it is possible to reference them in a
+ generic unit.
+
+20.f/3
+ {AI05-0115-1AI05-0115-1} Correction: Clarified that the
+ characteristics of a descendant of a private type depend on
+ the visibility of the full view of the direct ancestor. This
+ has to be the case (so that privacy is not violated), but it
+ wasn't spelled out in earlier versions of Ada.
+
+\1f
+File: aarm2012.info, Node: 7.3.2, Prev: 7.3.1, Up: 7.3
+
+7.3.2 Type Invariants
+---------------------
+
+1/3
+{AI05-0146-1AI05-0146-1} For a private type or private extension, the
+following language-defined aspects may be specified with an
+aspect_specification (see *note 13.1.1::):
+
+2/3
+{AI05-0146-1AI05-0146-1} {AI05-0250-1AI05-0250-1} Type_Invariant
+ This aspect shall be specified by an expression, called
+ an invariant expression. Type_Invariant may be specified
+ on a private_type_declaration (*note 7.3: S0193.), on a
+ private_extension_declaration (*note 7.3: S0194.), or on
+ a full_type_declaration (*note 3.2.1: S0024.) that
+ declares the completion of a private type or private
+ extension.
+
+2.a/3
+ Aspect Description for Type_Invariant: A condition that must
+ hold true for all objects of a type.
+
+3/3
+{AI05-0146-1AI05-0146-1} Type_Invariant'Class
+ This aspect shall be specified by an expression, called
+ an invariant expression. Type_Invariant'Class may be
+ specified on a private_type_declaration (*note 7.3:
+ S0193.) or a private_extension_declaration (*note 7.3:
+ S0194.).
+
+3.a/3
+ Reason: {AI05-0254-1AI05-0254-1} A class-wide type invariant
+ cannot be hidden in the private part, as the creator of an
+ extension needs to know about it in order to conform to it in
+ any new or overriding operations. On the other hand, a
+ specific type invariant is not inherited, so that no operation
+ outside of the original package needs to conform to it; thus
+ there is no need for it to be visible.
+
+3.b/3
+ Aspect Description for Type_Invariant'Class: A condition that
+ must hold true for all objects in a class of types.
+
+ _Name Resolution Rules_
+
+4/3
+{AI05-0146-1AI05-0146-1} The expected type for an invariant expression
+is any boolean type.
+
+5/3
+{AI05-0146-1AI05-0146-1} [Within an invariant expression, the identifier
+of the first subtype of the associated type denotes the current instance
+of the type.] Within an invariant expression associated with type T,
+the type of the current instance is T for the Type_Invariant aspect and
+T'Class for the Type_Invariant'Class aspect.
+
+5.a/3
+ Proof: The first sentence is given formally in *note 13.1.1::.
+
+ _Legality Rules_
+
+6/3
+{AI05-0146-1AI05-0146-1} [The Type_Invariant'Class aspect shall not be
+specified for an untagged type.] The Type_Invariant aspect shall not be
+specified for an abstract type.
+
+6.a/3
+ Proof: The first sentence is given formally in *note 13.1.1::.
+
+ _Static Semantics_
+
+7/3
+{AI05-0250-1AI05-0250-1} [If the Type_Invariant aspect is specified for
+a type T, then the invariant expression applies to T.]
+
+8/3
+{AI05-0146-1AI05-0146-1} [If the Type_Invariant'Class aspect is
+specified for a tagged type T, then the invariant expression applies to
+all descendants of T.]
+
+8.a/3
+ Proof: "Applies" is formally defined in *note 13.1.1::.
+
+ _Dynamic Semantics_
+
+9/3
+{AI05-0146-1AI05-0146-1} {AI05-0247-1AI05-0247-1}
+{AI05-0290-1AI05-0290-1} If one or more invariant expressions apply to a
+type T, then an invariant check is performed at the following places, on
+the specified object(s):
+
+10/3
+ * After successful default initialization of an object of type T, the
+ check is performed on the new object;
+
+11/3
+ * After successful conversion to type T, the check is performed on
+ the result of the conversion;
+
+12/3
+ * {AI05-0146-1AI05-0146-1} {AI05-0269-1AI05-0269-1} For a view
+ conversion, outside the immediate scope of T, that converts from a
+ descendant of T (including T itself) to an ancestor of type T
+ (other than T itself), a check is performed on the part of the
+ object that is of type T:
+
+13/3
+ * after assigning to the view conversion; and
+
+14/3
+ * after successful return from a call that passes the view
+ conversion as an in out or out parameter.
+
+14.a/3
+ Ramification: For a single view conversion that converts
+ between distantly related types, this rule could be triggered
+ for multiple types and thus multiple invariant checks may be
+ needed.
+
+14.b/3
+ Implementation Note: {AI05-0299-1AI05-0299-1} For calls to
+ inherited subprograms (including dispatching calls), the
+ implied view conversions mean that a wrapper is probably
+ needed. (See the Note at the bottom of this subclause for
+ more on the model of checks for inherited subprograms.)
+
+14.c/3
+ For view conversions involving class-wide types, the exact
+ checks needed may not be known at compile-time. One way to
+ deal with this is to have an implicit dispatching operation
+ that is given the object to check and the tag of the target of
+ the conversion, and which first checks if the passed tag is
+ not for itself, and if not, checks the its invariant on the
+ object and then calls the operation of its parent type. If
+ the tag is for itself, the operation is complete.
+
+15/3
+ * After a successful call on the Read or Input stream attribute of
+ the type T, the check is performed on the object initialized by the
+ stream attribute;
+
+16/3
+ * {AI05-0146-1AI05-0146-1} {AI05-0269-1AI05-0269-1} An invariant is
+ checked upon successful return from a call on any subprogram or
+ entry that:
+
+17/3
+ * {AI05-0146-1AI05-0146-1} {AI05-0269-1AI05-0269-1} is declared
+ within the immediate scope of type T (or by an instance of a
+ generic unit, and the generic is declared within the immediate
+ scope of type T), and
+
+18/3
+ * is visible outside the immediate scope of type T or overrides
+ an operation that is visible outside the immediate scope of T,
+ and
+
+19/3
+ * {AI05-0289-1AI05-0289-1} has a result with a part of type T,
+ or one or more parameters with a part of type T, or an access
+ to variable parameter whose designated type has a part of type
+ T.
+
+20/3
+ {AI05-0146-1AI05-0146-1} {AI05-0269-1AI05-0269-1} The check is
+ performed on each such part of type T.
+
+21/3
+{AI05-0290-1AI05-0290-1} If performing checks is required by the
+Invariant or Invariant'Class assertion policies (see *note 11.4.2::) in
+effect at the point of corresponding aspect specification applicable to
+a given type, then the respective invariant expression is considered
+enabled.
+
+21.a/3
+ Ramification: If a class-wide invariant expression is enabled
+ for a type, it remains enabled when inherited by descendants
+ of that type, even if the policy in effect is Ignore for the
+ inheriting type.
+
+22/3
+{AI05-0146-1AI05-0146-1} {AI05-0250-1AI05-0250-1}
+{AI05-0289-1AI05-0289-1} {AI05-0290-1AI05-0290-1} The invariant check
+consists of the evaluation of each enabled invariant expression that
+applies to T, on each of the objects specified above. If any of these
+evaluate to False, Assertions.Assertion_Error is raised at the point of
+the object initialization, conversion, or call. If a given call
+requires more than one evaluation of an invariant expression, either for
+multiple objects of a single type or for multiple types with invariants,
+the evaluations are performed in an arbitrary order, and if one of them
+evaluates to False, it is not specified whether the others are
+evaluated. Any invariant check is performed prior to copying back any
+by-copy in out or out parameters. Invariant checks, any postcondition
+check, and any constraint or predicate checks associated with in out or
+out parameters are performed in an arbitrary order.
+
+23/3
+{AI05-0146-1AI05-0146-1} {AI05-0247-1AI05-0247-1}
+{AI05-0250-1AI05-0250-1} The invariant checks performed on a call are
+determined by the subprogram or entry actually invoked, whether
+directly, as part of a dispatching call, or as part of a call through an
+access-to-subprogram value.
+
+23.a/3
+ Ramification: Invariant checks on subprogram return are not
+ performed on objects that are accessible only through access
+ values. It is also possible to call through an
+ access-to-subprogram value and reach a subprogram body that
+ has visibility on the full declaration of a type, from outside
+ the immediate scope of the type. No invariant checks will be
+ performed if the designated subprogram is not itself
+ externally visible. These cases represent "holes" in the
+ protection provided by invariant checks; but note that these
+ holes cannot be caused by clients of the type T with the
+ invariant without help for the designer of the package
+ containing T.
+
+23.b/3
+ Implementation Note: The implementation might want to produce
+ a warning if a private extension has an ancestor type that is
+ a visible extension, and an invariant expression depends on
+ the value of one of the components from a visible extension
+ part.
+
+ NOTES
+
+24/3
+ 13 {AI05-0250-1AI05-0250-1} {AI05-0269-1AI05-0269-1} For a call of
+ a primitive subprogram of type NT that is inherited from type T,
+ the specified checks of the specific invariants of both the types
+ NT and T are performed. For a call of a primitive subprogram of
+ type NT that is overridden for type NT, the specified checks of the
+ specific invariants of only type NT are performed.
+
+24.a/3
+ Proof: This follows from the definition of a call on an
+ inherited subprogram as view conversions of the parameters of
+ the type and a call to the original subprogram (see *note
+ 3.4::), along with the normal invariant checking rules. In
+ particular, the call to the original subprogram takes care of
+ any checks needed on type T, and the checks required on view
+ conversions take care of any checks needed on type NT,
+ specifically on in out and out parameters. We require this in
+ order that the semantics of an explicitly defined wrapper that
+ does nothing but call the original subprogram is the same as
+ that of an inherited subprogram.
+
+ _Extensions to Ada 2005_
+
+24.b/3
+ {AI05-0146-1AI05-0146-1} {AI05-0247-1AI05-0247-1}
+ {AI05-0250-1AI05-0250-1} {AI05-0289-1AI05-0289-1}
+ Type_Invariant aspects are new.
+
+\1f
+File: aarm2012.info, Node: 7.4, Next: 7.5, Prev: 7.3, Up: 7
+
+7.4 Deferred Constants
+======================
+
+1
+[Deferred constant declarations may be used to declare constants in the
+visible part of a package, but with the value of the constant given in
+the private part. They may also be used to declare constants imported
+from other languages (see *note Annex B::).]
+
+ _Legality Rules_
+
+2/3
+{AI05-0229-1AI05-0229-1} {AI05-0269-1AI05-0269-1} [ A deferred constant
+declaration is an object_declaration with the reserved word constant but
+no initialization expression.] The constant declared by a deferred
+constant declaration is called a deferred constant. [Unless the Import
+aspect (see *note B.1::) is True for a deferred constant declaration,
+the ] deferred constant declaration requires a completion, which shall
+be a full constant declaration (called the full declaration of the
+deferred constant).
+
+2.a
+ Proof: The first sentence is redundant, as it is stated
+ officially in *note 3.3.1::.
+
+2.b/3
+ {AI05-0229-1AI05-0229-1} {AI05-0269-1AI05-0269-1} The first
+ part of the last sentence is redundant, as no imported entity
+ may have a completion, as stated in *note B.1::.
+
+3
+A deferred constant declaration that is completed by a full constant
+declaration shall occur immediately within the visible part of a
+package_specification. For this case, the following additional rules
+apply to the corresponding full declaration:
+
+4
+ * The full declaration shall occur immediately within the private
+ part of the same package;
+
+5/2
+ * {AI95-00385-01AI95-00385-01} The deferred and full constants shall
+ have the same type, or shall have statically matching anonymous
+ access subtypes;
+
+5.a/2
+ Ramification: {AI95-00385-01AI95-00385-01} This implies that
+ both the deferred declaration and the full declaration have to
+ have a subtype_indication or access_definition rather than an
+ array_type_definition, because each array_type_definition
+ would define a new type.
+
+6/3
+ * {AI95-00385-01AI95-00385-01} {AI05-0062-1AI05-0062-1}
+ {AI05-0262-1AI05-0262-1} If the deferred constant declaration
+ includes a subtype_indication S that defines a constrained subtype,
+ then the constraint defined by the subtype_indication in the full
+ declaration shall match the constraint defined by S statically.[ On
+ the other hand, if the subtype of the deferred constant is
+ unconstrained, then the full declaration is still allowed to impose
+ a constraint. The constant itself will be constrained, like all
+ constants;]
+
+7/2
+ * {AI95-00231-01AI95-00231-01} If the deferred constant declaration
+ includes the reserved word aliased, then the full declaration shall
+ also;
+
+7.a
+ Ramification: On the other hand, the full constant can be
+ aliased even if the deferred constant is not.
+
+7.1/2
+ * {AI95-00231-01AI95-00231-01} If the subtype of the deferred
+ constant declaration excludes null, the subtype of the full
+ declaration shall also exclude null.
+
+7.a.1/2
+ Ramification: On the other hand, the full constant can exclude
+ null even if the deferred constant does not. But that can
+ only happen for a subtype_indication, as anonymous access
+ types are required to statically match (which includes any
+ null_exclusion).
+
+8/3
+{AI05-0229-1AI05-0229-1} [A deferred constant declaration for which the
+Import aspect is True need not appear in the visible part of a
+package_specification, and has no full constant declaration.]
+
+9/2
+{AI95-00256-01AI95-00256-01} The completion of a deferred constant
+declaration shall occur before the constant is frozen (see *note
+13.14::).
+
+ _Dynamic Semantics_
+
+10/3
+{AI05-0004-1AI05-0004-1} The elaboration of a deferred constant
+declaration elaborates the subtype_indication, access_definition, or
+(only allowed in the case of an imported constant) the
+array_type_definition.
+
+10.a/3
+ Ramification: {AI05-0004-1AI05-0004-1} For nonimported
+ constants, these elaborations cannot require any code or
+ checks for a legal program, because the given
+ subtype_indication has to be indefinite or statically match
+ that of the full constant, meaning that either it is a
+ subtype_mark or it has static constraints. If the deferred
+ constant instead has an access_definition, the designated
+ subtype must be a subtype_mark. We still say that these are
+ elaborated, however, because part of elaboration is creating
+ the type, which is clearly needed for access_definitions. (A
+ deferred constant and its full constant have different types
+ when they are specified by an access_definition, although
+ there is no visible effect of these types being different as
+ neither can be named.)
+
+ NOTES
+
+11
+ 14 The full constant declaration for a deferred constant that is
+ of a given private type or private extension is not allowed before
+ the corresponding full_type_declaration. This is a consequence of
+ the freezing rules for types (see *note 13.14::).
+
+11.a
+ Ramification: Multiple or single declarations are allowed for
+ the deferred and the full declarations, provided that the
+ equivalent single declarations would be allowed.
+
+11.b
+ Deferred constant declarations are useful for declaring
+ constants of private views, and types with components of
+ private views. They are also useful for declaring
+ access-to-constant objects that designate variables declared
+ in the private part of a package.
+
+ _Examples_
+
+12
+Examples of deferred constant declarations:
+
+13
+ Null_Key : constant Key; -- see *note 7.3.1::
+
+14/3
+ {AI05-0229-1AI05-0229-1} CPU_Identifier : constant String(1..8)
+ with Import => True, Convention => Assembler, Link_Name => "CPU_ID";
+ -- see *note B.1::
+
+ _Extensions to Ada 83_
+
+14.a
+ In Ada 83, a deferred constant is required to be of a private
+ type declared in the same visible part. This restriction is
+ removed for Ada 95; deferred constants can be of any type.
+
+14.b
+ In Ada 83, a deferred constant declaration was not permitted
+ to include a constraint, nor the reserved word aliased.
+
+14.c
+ In Ada 83, the rules required conformance of type marks; here
+ we require static matching of subtypes if the deferred
+ constant is constrained.
+
+14.d
+ A deferred constant declaration can be completed with a pragma
+ Import. Such a deferred constant declaration need not be
+ within a package_specification.
+
+14.e
+ The rules for too-early uses of deferred constants are
+ modified in Ada 95 to allow more cases, and catch all errors
+ at compile time. This change is necessary in order to allow
+ deferred constants of a tagged type without violating the
+ principle that for a dispatching call, there is always an
+ implementation to dispatch to. It has the beneficial side
+ effect of catching some Ada-83-erroneous programs at compile
+ time. The new rule fits in well with the new freezing-point
+ rules. Furthermore, we are trying to convert undefined-value
+ problems into bounded errors, and we were having trouble for
+ the case of deferred constants. Furthermore, uninitialized
+ deferred constants cause trouble for the shared variable /
+ tasking rules, since they are really variable, even though
+ they purport to be constant. In Ada 95, they cannot be
+ touched until they become constant.
+
+14.f
+ Note that we do not consider this change to be an upward
+ incompatibility, because it merely changes an erroneous
+ execution in Ada 83 into a compile-time error.
+
+14.g
+ The Ada 83 semantics are unclear in the case where the full
+ view turns out to be an access type. It is a goal of the
+ language design to prevent uninitialized access objects. One
+ wonders if the implementation is required to initialize the
+ deferred constant to null, and then initialize it (again!) to
+ its real value. In Ada 95, the problem goes away.
+
+ _Wording Changes from Ada 83_
+
+14.h/3
+ {AI05-0299-1AI05-0299-1} Since deferred constants can now be
+ of a nonprivate type, we have made this a stand-alone
+ subclause, rather than a subclause of *note 7.3::, "*note
+ 7.3:: Private Types and Private Extensions".
+
+14.i
+ Deferred constant declarations used to have their own syntax,
+ but now they are simply a special case of object_declarations.
+
+ _Extensions to Ada 95_
+
+14.j/2
+ {AI95-00385-01AI95-00385-01} Deferred constants were enhanced
+ to allow the use of anonymous access types in them.
+
+ _Wording Changes from Ada 95_
+
+14.k/2
+ {AI95-00231-01AI95-00231-01} Added matching rules for subtypes
+ that exclude null.
+
+ _Wording Changes from Ada 2005_
+
+14.l/3
+ {AI05-0062-1AI05-0062-1} Correction: Corrected rules so that
+ the intent that a full constant may have a null exclusion even
+ if the deferred constant does not is actually met.
+
+\1f
+File: aarm2012.info, Node: 7.5, Next: 7.6, Prev: 7.4, Up: 7
+
+7.5 Limited Types
+=================
+
+1/2
+{AI95-00287-01AI95-00287-01} [A limited type is (a view of) a type for
+which copying (such as for an assignment_statement) is not allowed. A
+nonlimited type is a (view of a) type for which copying is allowed.]
+
+1.a
+ Discussion: The concept of the value of a limited type is
+ difficult to define, since the abstract value of a limited
+ type often extends beyond its physical representation. In
+ some sense, values of a limited type cannot be divorced from
+ their object. The value is the object.
+
+1.b/2
+ {AI95-00318-02AI95-00318-02} In Ada 83, in the two places
+ where limited types were defined by the language, namely tasks
+ and files, an implicit level of indirection was implied by the
+ semantics to avoid the separation of the value from an
+ associated object. In Ada 95, most limited types are passed
+ by reference, and even return-ed by reference. In Ada 2005,
+ most limited types are built-in-place upon return, rather than
+ returned by reference. Thus the object "identity" is part of
+ the logical value of most limited types.
+
+1.c/2
+ To be honest: {AI95-00287-01AI95-00287-01}
+ {AI95-00419-01AI95-00419-01} For a limited partial view whose
+ full view is nonlimited, copying is possible on parameter
+ passing and function return. To prevent any copying
+ whatsoever, one should make both the partial and full views
+ limited.
+
+1.d/2
+ Glossary entry: A limited type is a type for which copying
+ (such as in an assignment_statement) is not allowed. A
+ nonlimited type is a type for which copying is allowed.
+
+ _Legality Rules_
+
+2/2
+{AI95-00419-01AI95-00419-01} If a tagged record type has any limited
+components, then the reserved word limited shall appear in its
+record_type_definition. [If the reserved word limited appears in the
+definition of a derived_type_definition, its parent type and any
+progenitor interfaces shall be limited.]
+
+2.a.1/2
+ Proof: {AI95-00419-01AI95-00419-01} The rule about the parent
+ type being required to be limited can be found in *note 3.4::.
+ Rules about progenitor interfaces can be found in *note
+ 3.9.4::, specifically, a nonlimited interface can appear only
+ on a nonlimited type. We repeat these rules here to gather
+ these scattered rules in one obvious place.
+
+2.a
+ Reason: This prevents tagged limited types from becoming
+ nonlimited. Otherwise, the following could happen:
+
+2.b
+ package P is
+ type T is limited private;
+ type R is tagged
+ record -- Illegal!
+ -- This should say "limited record".
+ X : T;
+ end record;
+ private
+ type T is new Integer; -- R becomes nonlimited here.
+ end P;
+
+2.c/2
+ package Q is
+ type R2 is new R with
+ record
+ Y : Some_Task_Type;
+ end record;
+ end Q;
+
+2.d/2
+ {AI95-00230-01AI95-00230-01} If the above were legal, then
+ assignment would be defined for R'Class in the body of P,
+ which is bad news, given the task.
+
+2.1/3
+{AI95-00287-01AI95-00287-01} {AI95-00318-02AI95-00318-02}
+{AI05-0147-1AI05-0147-1} In the following contexts, an expression of a
+limited type is not permitted unless it is an aggregate, a
+function_call, a parenthesized expression or qualified_expression whose
+operand is permitted by this rule, or a conditional_expression all of
+whose dependent_expressions are permitted by this rule:
+
+2.2/2
+ * the initialization expression of an object_declaration (see *note
+ 3.3.1::)
+
+2.3/2
+ * the default_expression of a component_declaration (see *note 3.8::)
+
+2.4/2
+ * the expression of a record_component_association (see *note
+ 4.3.1::)
+
+2.5/2
+ * the expression for an ancestor_part of an extension_aggregate (see
+ *note 4.3.2::)
+
+2.6/2
+ * an expression of a positional_array_aggregate or the expression of
+ an array_component_association (see *note 4.3.3::)
+
+2.7/2
+ * the qualified_expression of an initialized allocator (see *note
+ 4.8::)
+
+2.8/2
+ * the expression of a return statement (see *note 6.5::)
+
+2.9/3
+ * {AI05-0177-1AI05-0177-1} the expression of an
+ expression_function_declaration (see *note 6.8::)
+
+2.10/3
+ * the default_expression or actual parameter for a formal object of
+ mode in (see *note 12.4::)
+
+2.e/2
+ Discussion: All of these contexts normally require copying; by
+ restricting the uses as above, we can require the new object
+ to be built-in-place.
+
+ _Static Semantics_
+
+3/3
+{AI95-00419-01AI95-00419-01} {AI05-0178-1AI05-0178-1} A view of a type
+is limited if it is one of the following:
+
+4/2
+ * {AI95-00411-01AI95-00411-01} {AI95-00419-01AI95-00419-01} a type
+ with the reserved word limited, synchronized, task, or protected in
+ its definition;
+
+4.a
+ Ramification: Note that there is always a "definition,"
+ conceptually, even if there is no syntactic category called
+ "..._definition".
+
+4.b/2
+ {AI95-00419-01AI95-00419-01} This includes interfaces of the
+ above kinds, derived types with the reserved word limited, as
+ well as task and protected types.
+
+5/3
+ * {AI95-00419-01AI95-00419-01} {AI05-0087-1AI05-0087-1} a class-wide
+ type whose specific type is limited;
+
+6/2
+ * {AI95-00419-01AI95-00419-01} a composite type with a limited
+ component;
+
+6.1/3
+ * {AI05-0178-1AI05-0178-1} an incomplete view;
+
+6.2/2
+ * {AI95-00419-01AI95-00419-01} a derived type whose parent is limited
+ and is not an interface.
+
+6.a/2
+ Ramification: {AI95-00419-01AI95-00419-01} Limitedness is not
+ inherited from interfaces; it must be explicitly specified
+ when the parent is an interface.
+
+6.b/2
+ To be honest: {AI95-00419-01AI95-00419-01} A derived type can
+ become nonlimited if limited does not appear and the
+ derivation takes place in the visible part of a child package,
+ and the parent type is nonlimited as viewed from the private
+ part or body of the child package.
+
+6.c/2
+ Reason: {AI95-00419-01AI95-00419-01} We considered a rule
+ where limitedness was always inherited from the parent for
+ derived types, but in the case of a type whose parent is an
+ interface, this meant that the first interface is treated
+ differently than other interfaces. It also would have forced
+ users to declare dummy nonlimited interfaces just to get the
+ limitedness right. We also considered a syntax like not
+ limited to specify nonlimitedness when the parent was limited,
+ but that was unsavory. The rule given is more uniform and
+ simpler to understand.
+
+6.d/2
+ {AI95-00419-01AI95-00419-01} The rules for interfaces are
+ asymmetrical, but the language is not: if the parent interface
+ is limited, the presence of the word limited determines the
+ limitedness, and nonlimited progenitors are illegal by the
+ rules in *note 3.9.4:: if limited is present. If the parent
+ interface is nonlimited, the word limited is illegal by the
+ rules in *note 3.4::. The net effect is that the order of the
+ interfaces doesn't matter.
+
+7
+Otherwise, the type is nonlimited.
+
+8
+[There are no predefined equality operators for a limited type.]
+
+8.1/3
+{AI05-0052-1AI05-0052-1} A type is immutably limited if it is one of the
+following:
+
+8.2/3
+ * An explicitly limited record type;
+
+8.3/3
+ * {AI05-0217-1AI05-0217-1} A record extension with the reserved word
+ limited;
+
+8.4/3
+ * A nonformal limited private type that is tagged or has at least one
+ access discriminant with a default_expression;
+
+8.a/3
+ Reason: The full type in both of these cases must necessarily
+ be immutably limited. We need to include private types as
+ much as possible so that we aren't unintentionally
+ discouraging the use of private types.
+
+8.5/3
+ * A task type, a protected type, or a synchronized interface;
+
+8.6/3
+ * A type derived from an immutably limited type.
+
+8.b/3
+ Discussion: An immutably limited type is a type that cannot
+ become nonlimited subsequently in a private part or in a child
+ unit. If a view of the type makes it immutably limited, then
+ no copying (assignment) operations are ever available for
+ objects of the type. This allows other properties; for
+ instance, it is safe for such objects to have access
+ discriminants that have defaults or designate other limited
+ objects.
+
+8.c/3
+ Ramification: A nonsynchronized limited interface type is not
+ immutably limited; a type derived from it can be nonlimited.
+
+8.7/3
+{AI05-0052-1AI05-0052-1} A descendant of a generic formal limited
+private type is presumed to be immutably limited except within the body
+of a generic unit or a body declared within the declarative region of a
+generic unit, if the formal type is declared within the formal part of
+the generic unit.
+
+8.d/3
+ Ramification: In an instance, a type is descended from the
+ actual type corresponding to the formal, and all rules are
+ rechecked in the specification. Bodies are excepted so that
+ we assume the worst there; the complex wording is required to
+ handle children of generics and unrelated bodies properly.
+
+ NOTES
+
+9/3
+ 15 {AI95-00287-01AI95-00287-01} {AI95-00318-02AI95-00318-02}
+ {AI05-0067-1AI05-0067-1} While it is allowed to write
+ initializations of limited objects, such initializations never copy
+ a limited object. The source of such an assignment operation must
+ be an aggregate or function_call, and such aggregates and
+ function_calls must be built directly in the target object (see
+ *note 7.6::).
+
+9.a/2
+ To be honest: This isn't quite true if the type can become
+ nonlimited (see below); function_calls only are required to be
+ build-in-place for "really" limited types.
+
+ Paragraphs 10 through 15 were deleted.
+
+16
+ 16 As illustrated in *note 7.3.1::, an untagged limited type can
+ become nonlimited under certain circumstances.
+
+16.a
+ Ramification: Limited private types do not become nonlimited;
+ instead, their full view can be nonlimited, which has a
+ similar effect.
+
+16.b
+ It is important to remember that a single nonprivate type can
+ be both limited and nonlimited in different parts of its
+ scope. In other words, "limited" is a property that depends
+ on where you are in the scope of the type. We don't call this
+ a "view property" because there is no particular declaration
+ to declare the nonlimited view.
+
+16.c
+ Tagged types never become nonlimited.
+
+ _Examples_
+
+17
+Example of a package with a limited type:
+
+18
+ package IO_Package is
+ type File_Name is limited private;
+
+19
+ procedure Open (F : in out File_Name);
+ procedure Close(F : in out File_Name);
+ procedure Read (F : in File_Name; Item : out Integer);
+ procedure Write(F : in File_Name; Item : in Integer);
+ private
+ type File_Name is
+ limited record
+ Internal_Name : Integer := 0;
+ end record;
+ end IO_Package;
+
+20
+ package body IO_Package is
+ Limit : constant := 200;
+ type File_Descriptor is record ... end record;
+ Directory : array (1 .. Limit) of File_Descriptor;
+ ...
+ procedure Open (F : in out File_Name) is ... end;
+ procedure Close(F : in out File_Name) is ... end;
+ procedure Read (F : in File_Name; Item : out Integer) is ... end;
+ procedure Write(F : in File_Name; Item : in Integer) is ... end;
+ begin
+ ...
+ end IO_Package;
+
+ NOTES
+
+21
+ 17 Notes on the example: In the example above, an outside
+ subprogram making use of IO_Package may obtain a file name by
+ calling Open and later use it in calls to Read and Write. Thus,
+ outside the package, a file name obtained from Open acts as a kind
+ of password; its internal properties (such as containing a numeric
+ value) are not known and no other operations (such as addition or
+ comparison of internal names) can be performed on a file name.
+ Most importantly, clients of the package cannot make copies of
+ objects of type File_Name.
+
+22
+ This example is characteristic of any case where complete control
+ over the operations of a type is desired. Such packages serve a
+ dual purpose. They prevent a user from making use of the internal
+ structure of the type. They also implement the notion of an
+ encapsulated data type where the only operations on the type are
+ those given in the package specification.
+
+23/2
+ {AI95-00318-02AI95-00318-02} The fact that the full view of
+ File_Name is explicitly declared limited means that parameter
+ passing will always be by reference and function results will
+ always be built directly in the result object (see *note 6.2:: and
+ *note 6.5::).
+
+ _Extensions to Ada 83_
+
+23.a
+ The restrictions in RM83-7.4.4(4), which disallowed out
+ parameters of limited types in certain cases, are removed.
+
+ _Wording Changes from Ada 83_
+
+23.b/3
+ {AI05-0299-1AI05-0299-1} Since limitedness and privateness are
+ orthogonal in Ada 95 (and to some extent in Ada 83), this is
+ now its own subclause rather than being a subclause of *note
+ 7.3::, "*note 7.3:: Private Types and Private Extensions".
+
+ _Extensions to Ada 95_
+
+23.c/2
+ {AI95-00287-01AI95-00287-01} {AI95-00318-02AI95-00318-02}
+ Limited types now have an assignment operation, but its use is
+ restricted such that all uses are build-in-place. This is
+ accomplished by restricting uses to aggregates and
+ function_calls. Aggregates were not allowed to have a limited
+ type in Ada 95, which causes a compatibility issue discussed
+ in *note 4.3::, "*note 4.3:: Aggregates". Compatibility
+ issues with return statements for limited function_calls are
+ discussed in *note 6.5::, "*note 6.5:: Return Statements".
+
+ _Wording Changes from Ada 95_
+
+23.d/2
+ {AI95-00411-01AI95-00411-01} {AI95-00419-01AI95-00419-01}
+ Rewrote the definition of limited to ensure that interfaces
+ are covered, but that limitedness is not inherited from
+ interfaces. Derived types that explicitly include limited are
+ now also covered.
+
+ _Wording Changes from Ada 2005_
+
+23.e/3
+ {AI05-0052-1AI05-0052-1} {AI05-0217-1AI05-0217-1} Correction:
+ Added a definition for immutably limited types, so that the
+ fairly complex definition does not need to be repeated in
+ rules elsewhere in the Standard.
+
+23.f/3
+ {AI05-0067-1AI05-0067-1} {AI05-0299-1AI05-0299-1} Correction:
+ The built-in-place rules are consolidated in *note 7.6::, and
+ thus they are removed from this subclause.
+
+23.g/3
+ {AI05-0087-1AI05-0087-1} Correction: Fixed an oversight:
+ class-wide types were never defined to be limited, even if
+ their associated specific type is. It is thought that this
+ oversight was never implemented incorrectly by any compiler,
+ thus we have not classified it as an incompatibility.
+
+23.h/3
+ {AI05-0147-1AI05-0147-1} Allowed conditional_expressions in
+ limited constructor contexts -- we want to treat these as
+ closely to parentheses as possible.
+
+23.i/3
+ {AI05-0178-1AI05-0178-1} Added wording so that expression
+ functions can return limited entities.
+
+23.j/3
+ {AI05-0178-1AI05-0178-1} Correction: Added incomplete views to
+ the list of reasons for a view of a type to be limited. This
+ is not a change as the definition already was in *note
+ 3.10.1::. But it is much better to have all of the reasons
+ for limitedness together.
+
+\1f
+File: aarm2012.info, Node: 7.6, Prev: 7.5, Up: 7
+
+7.6 Assignment and Finalization
+===============================
+
+1
+[ Three kinds of actions are fundamental to the manipulation of objects:
+initialization, finalization, and assignment. Every object is
+initialized, either explicitly or by default, after being created (for
+example, by an object_declaration or allocator). Every object is
+finalized before being destroyed (for example, by leaving a
+subprogram_body containing an object_declaration, or by a call to an
+instance of Unchecked_Deallocation). An assignment operation is used as
+part of assignment_statements, explicit initialization, parameter
+passing, and other operations.
+
+2
+Default definitions for these three fundamental operations are provided
+by the language, but a controlled type gives the user additional control
+over parts of these operations. In particular, the user can define, for
+a controlled type, an Initialize procedure which is invoked immediately
+after the normal default initialization of a controlled object, a
+Finalize procedure which is invoked immediately before finalization of
+any of the components of a controlled object, and an Adjust procedure
+which is invoked as the last step of an assignment to a (nonlimited)
+controlled object.]
+
+2.a
+ Glossary entry: A controlled type supports user-defined
+ assignment and finalization. Objects are always finalized
+ before being destroyed.
+
+2.b/2
+ Ramification: {AI95-00114-01AI95-00114-01}
+ {AI95-00287-01AI95-00287-01} Here's the basic idea of
+ initialization, value adjustment, and finalization, whether or
+ not user defined: When an object is created, if it is
+ explicitly assigned an initial value, the object is either
+ built-in-place from an aggregate or function call (in which
+ case neither Adjust nor Initialize is applied), or the
+ assignment copies and adjusts the initial value. Otherwise,
+ Initialize is applied to it (except in the case of an
+ aggregate as a whole). An assignment_statement finalizes the
+ target before copying in and adjusting the new value.
+ Whenever an object goes away, it is finalized. Calls on
+ Initialize and Adjust happen bottom-up; that is, components
+ first, followed by the containing object. Calls on Finalize
+ happen top-down; that is, first the containing object, and
+ then its components. These ordering rules ensure that any
+ components will be in a well-defined state when Initialize,
+ Adjust, or Finalize is applied to the containing object.
+
+ _Static Semantics_
+
+3
+The following language-defined library package exists:
+
+4/3
+ {8652/00208652/0020} {AI95-00126-01AI95-00126-01} {AI05-0212-1AI05-0212-1} package Ada.Finalization is
+ pragma Pure(Finalization);
+
+5/2
+ {AI95-00161-01AI95-00161-01} type Controlled is abstract tagged private;
+ pragma Preelaborable_Initialization(Controlled);
+
+6/2
+ {AI95-00348-01AI95-00348-01} procedure Initialize (Object : in out Controlled) is null;
+ procedure Adjust (Object : in out Controlled) is null;
+ procedure Finalize (Object : in out Controlled) is null;
+
+7/2
+ {AI95-00161-01AI95-00161-01} type Limited_Controlled is abstract tagged limited private;
+ pragma Preelaborable_Initialization(Limited_Controlled);
+
+8/2
+ {AI95-00348-01AI95-00348-01} procedure Initialize (Object : in out Limited_Controlled) is null;
+ procedure Finalize (Object : in out Limited_Controlled) is null;
+ private
+ ... -- not specified by the language
+ end Ada.Finalization;
+
+9/2
+{AI95-00348-01AI95-00348-01} A controlled type is a descendant of
+Controlled or Limited_Controlled. The predefined "=" operator of type
+Controlled always returns True, [since this operator is incorporated
+into the implementation of the predefined equality operator of types
+derived from Controlled, as explained in *note 4.5.2::.] The type
+Limited_Controlled is like Controlled, except that it is limited and it
+lacks the primitive subprogram Adjust.
+
+9.a
+ Discussion: We say "nonlimited controlled type" (rather than
+ just "controlled type";) when we want to talk about
+ descendants of Controlled only.
+
+9.b
+ Reason: We considered making Adjust and Finalize abstract.
+ However, a reasonable coding convention is e.g. for Finalize
+ to always call the parent's Finalize after doing whatever work
+ is needed for the extension part. (Unlike CLOS, we have no
+ way to do that automatically in Ada 95.) For this to work,
+ Finalize cannot be abstract. In a generic unit, for a generic
+ formal abstract derived type whose ancestor is Controlled or
+ Limited_Controlled, calling the ancestor's Finalize would be
+ illegal if it were abstract, even though the actual type might
+ have a concrete version.
+
+9.c
+ Types Controlled and Limited_Controlled are abstract, even
+ though they have no abstract primitive subprograms. It is not
+ clear that they need to be abstract, but there seems to be no
+ harm in it, and it might make an implementation's life easier
+ to know that there are no objects of these types -- in case
+ the implementation wishes to make them "magic" in some way.
+
+9.d/2
+ {AI95-00251-01AI95-00251-01} For Ada 2005, we considered
+ making these types interfaces. That would have the advantage
+ of allowing them to be added to existing trees. But that was
+ rejected both because it would cause massive disruptions to
+ existing implementations, and because it would be very
+ incompatible due to the "no hidden interfaces" rule. The
+ latter rule would prevent a tagged private type from being
+ completed with a derivation from Controlled or
+ Limited_Controlled -- a very common idiom.
+
+9.1/2
+{AI95-00360-01AI95-00360-01} A type is said to need finalization if:
+
+9.2/2
+ * it is a controlled type, a task type or a protected type; or
+
+9.3/3
+ * {AI05-0092-1AI05-0092-1} it has a component whose type needs
+ finalization; or
+
+9.4/3
+ * {AI05-0013-1AI05-0013-1} it is a class-wide type; or
+
+9.5/3
+ * {AI05-0026-1AI05-0026-1} it is a partial view whose full view needs
+ finalization; or
+
+9.6/2
+ * it is one of a number of language-defined types that are explicitly
+ defined to need finalization.
+
+9.e/2
+ Ramification: The fact that a type needs finalization does not
+ require it to be implemented with a controlled type. It just
+ has to be recognized by the No_Nested_Finalization
+ restriction.
+
+9.f/2
+ This property is defined for the type, not for a particular
+ view. That's necessary as restrictions look in private parts
+ to enforce their restrictions; the point is to eliminate all
+ controlled parts, not just ones that are visible.
+
+ _Dynamic Semantics_
+
+10/2
+{AI95-00373-01AI95-00373-01} During the elaboration or evaluation of a
+construct that causes an object to be initialized by default, for every
+controlled subcomponent of the object that is not assigned an initial
+value (as defined in *note 3.3.1::), Initialize is called on that
+subcomponent. Similarly, if the object that is initialized by default
+as a whole is controlled, Initialize is called on the object.
+
+11/2
+{8652/00218652/0021} {AI95-00182-01AI95-00182-01}
+{AI95-00373-01AI95-00373-01} For an extension_aggregate whose
+ancestor_part is a subtype_mark denoting a controlled subtype, the
+Initialize procedure of the ancestor type is called, unless that
+Initialize procedure is abstract.
+
+11.a
+ Discussion: Example:
+
+11.b
+ type T1 is new Controlled with
+ record
+ ... -- some components might have defaults
+ end record;
+
+11.c
+ type T2 is new Controlled with
+ record
+ X : T1; -- no default
+ Y : T1 := ...; -- default
+ end record;
+
+11.d
+ A : T2;
+ B : T2 := ...;
+
+11.e
+ As part of the elaboration of A's declaration, A.Y is assigned
+ a value; therefore Initialize is not applied to A.Y. Instead,
+ Adjust is applied to A.Y as part of the assignment operation.
+ Initialize is applied to A.X and to A, since those objects are
+ not assigned an initial value. The assignment to A.Y is not
+ considered an assignment to A.
+
+11.f
+ For the elaboration of B's declaration, Initialize is not
+ called at all. Instead the assignment adjusts B's value; that
+ is, it applies Adjust to B.X, B.Y, and B.
+
+11.f.1/2
+ {8652/00218652/0021} {AI95-00182-01AI95-00182-01}
+ {AI95-00373-01AI95-00373-01} The ancestor_part of an
+ extension_aggregate, <> in aggregates, and the return object
+ of an extended_return_statement are handled similarly.
+
+12
+Initialize and other initialization operations are done in an arbitrary
+order, except as follows. Initialize is applied to an object after
+initialization of its subcomponents, if any [(including both implicit
+initialization and Initialize calls)]. If an object has a component
+with an access discriminant constrained by a per-object expression,
+Initialize is applied to this component after any components that do not
+have such discriminants. For an object with several components with
+such a discriminant, Initialize is applied to them in order of their
+component_declarations. For an allocator, any task activations follow
+all calls on Initialize.
+
+12.a
+ Reason: The fact that Initialize is done for subcomponents
+ first allows Initialize for a composite object to refer to its
+ subcomponents knowing they have been properly initialized.
+
+12.b
+ The fact that Initialize is done for components with access
+ discriminants after other components allows the Initialize
+ operation for a component with a self-referential access
+ discriminant to assume that other components of the enclosing
+ object have already been properly initialized. For multiple
+ such components, it allows some predictability.
+
+13
+When a target object with any controlled parts is assigned a value,
+[either when created or in a subsequent assignment_statement,] the
+assignment operation proceeds as follows:
+
+14
+ * The value of the target becomes the assigned value.
+
+15
+ * The value of the target is adjusted.
+
+15.a
+ Ramification: If any parts of the object are controlled, abort
+ is deferred during the assignment operation.
+
+16/3
+{AI05-0067-1AI05-0067-1} To adjust the value of a composite object, the
+values of the components of the object are first adjusted in an
+arbitrary order, and then, if the object is nonlimited controlled,
+Adjust is called. Adjusting the value of an elementary object has no
+effect[, nor does adjusting the value of a composite object with no
+controlled parts.]
+
+16.a/3
+ Ramification: {AI05-0067-1AI05-0067-1} Adjustment is never
+ actually performed for values of an immutably limited type,
+ since all assignment operations for such types are required to
+ be built-in-place. Even so, we still define adjustment for
+ all types in order that the canonical semantics is
+ well-defined.
+
+16.b/3
+ Reason: {AI05-0005-1AI05-0005-1} The verbiage in the
+ Initialize rule about access discriminants constrained by
+ per-object expressions is not necessary here, since such types
+ are either limited or do not have defaults, so the
+ discriminant can only be changed by an assignment to an outer
+ object. Such an assignment could happen only before any
+ adjustments or (if part of an outer Adjust) only after any
+ inner (component) adjustments have completed.
+
+17
+For an assignment_statement, [ after the name and expression have been
+evaluated, and any conversion (including constraint checking) has been
+done,] an anonymous object is created, and the value is assigned into
+it; [that is, the assignment operation is applied]. [(Assignment
+includes value adjustment.)] The target of the assignment_statement is
+then finalized. The value of the anonymous object is then assigned into
+the target of the assignment_statement. Finally, the anonymous object
+is finalized. [As explained below, the implementation may eliminate the
+intermediate anonymous object, so this description subsumes the one
+given in *note 5.2::, "*note 5.2:: Assignment Statements".]
+
+17.a
+ Reason: An alternative design for user-defined assignment
+ might involve an Assign operation instead of Adjust:
+
+17.b
+ procedure Assign(Target : in out Controlled; Source : in out Controlled);
+
+17.c
+ Or perhaps even a syntax like this:
+
+17.d
+ procedure ":="(Target : in out Controlled; Source : in out Controlled);
+
+17.e
+ Assign (or ":=") would have the responsibility of doing the
+ copy, as well as whatever else is necessary. This would have
+ the advantage that the Assign operation knows about both the
+ target and the source at the same time -- it would be possible
+ to do things like reuse storage belonging to the target, for
+ example, which Adjust cannot do. However, this sort of design
+ would not work in the case of unconstrained discriminated
+ variables, because there is no way to change the discriminants
+ individually. For example:
+
+17.f
+ type Mutable(D : Integer := 0) is
+ record
+ X : Array_Of_Controlled_Things(1..D);
+ case D is
+ when 17 => Y : Controlled_Thing;
+ when others => null;
+ end D;
+ end record;
+
+17.g
+ An assignment to an unconstrained variable of type Mutable can
+ cause some of the components of X, and the component Y, to
+ appear and/or disappear. There is no way to write the Assign
+ operation to handle this sort of case.
+
+17.h
+ Forbidding such cases is not an option -- it would cause
+ generic contract model violations.
+
+17.1/3
+{AI05-0067-1AI05-0067-1} When a function call or aggregate is used to
+initialize an object, the result of the function call or aggregate is an
+anonymous object, which is assigned into the newly-created object. For
+such an assignment, the anonymous object might be built in place, in
+which case the assignment does not involve any copying. Under certain
+circumstances, the anonymous object is required to be built in place.
+In particular:
+
+17.i/3
+ Discussion: {AI05-0067-1AI05-0067-1} We say assignment to
+ built-in-place objects does not involve copying, which matches
+ the intended implementation (see below). Of course, the
+ implementation can do any copying it likes, if it can make
+ such copying semantically invisible (by patching up access
+ values to point to the copy, and so forth).
+
+17.2/3
+ * If the full type of any part of the object is immutably limited,
+ the anonymous object is built in place.
+
+17.j/3
+ Reason: {AI05-0067-1AI05-0067-1} We talk about the full types
+ being immutably limited, as this is independent of the view of
+ a type (in the same way that it is for determining the
+ technique of parameter passing). That is, privacy is ignored
+ for this purpose.
+
+17.k/3
+ {AI05-0005-1AI05-0005-1} {AI05-0067-1AI05-0067-1} For function
+ calls, we only require building in place for immutably limited
+ types. These are the types that would have been
+ return-by-reference types in Ada 95. We limited the
+ requirement because we want to minimize disruption to Ada 95
+ implementations and users.
+
+17.l/3
+ To be honest: {AI05-0232-1AI05-0232-1} This is a dynamic
+ property and is determined by the specific type of the parts
+ of the actual object. In particular, if a part has a
+ class-wide type, the tag of the object might need to be
+ examined in order to determine if build-in-place is required.
+ However, we expect that most Ada implementations will
+ determine this property at compile-time using some
+ assume-the-worst algorithm in order to chose the appropriate
+ method to implement a given call or aggregate. In addition,
+ there is no attribute or other method for a program to
+ determine if a particular object has this property (or not),
+ so there is no value to a more careful description of this
+ rule.
+
+17.3/3
+ * In the case of an aggregate, if the full type of any part of the
+ newly-created object is controlled, the anonymous object is built
+ in place.
+
+17.m/3
+ Reason: {AI05-0067-1AI05-0067-1} This is necessary to prevent
+ elaboration problems with deferred constants of controlled
+ types. Consider:
+
+17.m.1/3
+ package P is
+ type Dyn_String is private;
+ Null_String : constant Dyn_String;
+ ...
+ private
+ type Dyn_String is new Ada.Finalization.Controlled with ...
+ procedure Finalize(X : in out Dyn_String);
+ procedure Adjust(X : in out Dyn_String);
+
+ Null_String : constant Dyn_String :=
+ (Ada.Finalization.Controlled with ...);
+ ...
+ end P;
+
+17.m.2/3
+ When Null_String is elaborated, the bodies of Finalize and
+ Adjust clearly have not been elaborated. Without this rule,
+ this declaration would necessarily raise Program_Error (unless
+ the permissions given below are used by the implementation).
+
+17.n/3
+ Ramification: An aggregate with a controlled part used in the
+ return expression of a simple_return_statement (*note 6.5:
+ S0183.) has to be built in place in the anonymous return
+ object, as this is similar to an object declaration. (This is
+ a change from Ada 95, but it is not an inconsistency as it
+ only serves to restrict implementation choices.) But this
+ only covers the aggregate; a separate anonymous return object
+ can still be used unless it too is required to be built in
+ place.
+
+17.o/3
+ Similarly, an aggregate that has a controlled part but is not
+ itself controlled and that is used to initialize an object
+ also has to be built in place. This is also a change from Ada
+ 95, but it is not an inconsistency as it only serves to
+ restrict implementation choices. This avoids problems if a
+ type like Dyn_String (in the example above) is used as a
+ component in a type used as a deferred constant in package P.
+
+17.4/3
+ * In other cases, it is unspecified whether the anonymous object is
+ built in place.
+
+17.p/3
+ Reason: This is left unspecified so the implementation can use
+ any appropriate criteria for determining when to build in
+ place. That includes making the decision on a call-by-call
+ basis. Reasonable programs will not care what decision is
+ made here anyway.
+
+17.5/3
+{AI05-0067-1AI05-0067-1} Notwithstanding what this International
+Standard says elsewhere, if an object is built in place:
+
+17.6/3
+ * Upon successful completion of the return statement or aggregate,
+ the anonymous object mutates into the newly-created object; that
+ is, the anonymous object ceases to exist, and the newly-created
+ object appears in its place.
+
+17.7/3
+ * Finalization is not performed on the anonymous object.
+
+17.8/3
+ * Adjustment is not performed on the newly-created object.
+
+17.9/3
+ * All access values that designate parts of the anonymous object now
+ designate the corresponding parts of the newly-created object.
+
+17.10/3
+ * All renamings of parts of the anonymous object now denote views of
+ the corresponding parts of the newly-created object.
+
+17.11/3
+ * Coextensions of the anonymous object become coextensions of the
+ newly-created object.
+
+17.q/3
+ To be honest: This "mutating" does not necessarily happen
+ atomically with respect to abort and other tasks. For
+ example, if a function call is used as the parent part of an
+ extension_aggregate, then the tag of the anonymous object (the
+ function result) will be different from the tag of the
+ newly-created object (the parent part of the
+ extension_aggregate). In implementation terms, this involves
+ modifying the tag field. If the current task is aborted
+ during this modification, the object might become abnormal.
+ Likewise, if some other task accesses the tag field during
+ this modification, it constitutes improper use of shared
+ variables, and is erroneous.
+
+17.r/3
+ Implementation Note: The intended implementation is that the
+ anonymous object is allocated at the same address as the
+ newly-created object. Thus, no run-time action is required to
+ cause all the access values and renamings to point to the
+ right place. They just point to the newly-created object,
+ which is what the return object has magically "mutated into".
+
+17.s/3
+ There is no requirement that 'Address of the return object is
+ equal to 'Address of the newly-created object, but that will
+ be true in the intended implementation.
+
+17.t/3
+ For a function call, if the size of the newly-created object
+ is known at the call site, the object is allocated there, and
+ the address is implicitly passed to the function; the return
+ object is created at that address. Otherwise, a storage pool
+ is implicitly passed to the function; the size is determined
+ at the point of the return statement, and passed to the
+ Allocate procedure. The address returned by the storage pool
+ is returned from the function, and the newly-created object
+ uses that same address. If the return statement is left
+ without returning (via an exception or a goto, for example),
+ then Deallocate is called. The storage pool might be a dummy
+ pool that represents "allocate on the stack".
+
+17.u/3
+ The Tag of the newly-created object may be different from that
+ of the result object. Likewise, the master and accessibility
+ level may be different.
+
+17.v/3
+ An alternative implementation model might allow objects to
+ move around to different addresses. In this case, access
+ values and renamings would need to be modified at run time.
+ It seems that this model requires the full power of tracing
+ garbage collection.
+
+ _Implementation Permissions_
+
+18/3
+{AI05-0067-1AI05-0067-1} An implementation is allowed to relax the above
+rules for assignment_statements in the following ways:
+
+18.a/3
+ This paragraph was deleted.{AI05-0067-1AI05-0067-1}
+
+18.b/3
+ Ramification: {AI05-0067-1AI05-0067-1} The relaxations apply
+ only to nonlimited types, as assignment_statements are not
+ allowed for limited types. This is important so that the
+ programmer can count on a stricter semantics for limited
+ controlled types.
+
+19/3
+ * {AI05-0067-1AI05-0067-1} If an object is assigned the value of that
+ same object, the implementation need not do anything.
+
+19.a
+ Ramification: In other words, even if an object is controlled
+ and a combination of Finalize and Adjust on the object might
+ have a net side effect, they need not be performed.
+
+20/3
+ * {AI05-0067-1AI05-0067-1} For assignment of a noncontrolled type,
+ the implementation may finalize and assign each component of the
+ variable separately (rather than finalizing the entire variable and
+ assigning the entire new value) unless a discriminant of the
+ variable is changed by the assignment.
+
+20.a
+ Reason: For example, in a slice assignment, an anonymous
+ object is not necessary if the slice is copied
+ component-by-component in the right direction, since array
+ types are not controlled (although their components may be).
+ Note that the direction, and even the fact that it's a slice
+ assignment, can in general be determined only at run time.
+
+20.b/3
+ Ramification: {AI05-0005-1AI05-0005-1} This potentially breaks
+ a single assignment operation into many, and thus abort
+ deferral (see *note 9.8::) needs to last only across an
+ individual component assignment when the component has a
+ controlled part. It is only important that the copy step is
+ not separated (by an abort) from the adjust step, so aborts
+ between component assignments is not harmful.
+
+21/3
+ * {AI95-00147-01AI95-00147-01} {AI05-0067-1AI05-0067-1} The
+ implementation need not create an anonymous object if the value
+ being assigned is the result of evaluating a name denoting an
+ object (the source object) whose storage cannot overlap with the
+ target. If the source object might overlap with the target object,
+ then the implementation can avoid the need for an intermediary
+ anonymous object by exercising one of the above permissions and
+ perform the assignment one component at a time (for an overlapping
+ array assignment), or not at all (for an assignment where the
+ target and the source of the assignment are the same object).
+
+21.a/3
+ Ramification: {AI05-0005-1AI05-0005-1} If the anonymous object
+ is eliminated by this permission, there is no anonymous object
+ to be finalized and thus the Finalize call on it is
+ eliminated.
+
+21.b/3
+ {AI95-00147-01AI95-00147-01} {AI05-0005-1AI05-0005-1} Note
+ that if the anonymous object is eliminated but the new value
+ is not built in place in the target object, that Adjust must
+ be called directly on the target object as the last step of
+ the assignment, since some of the subcomponents may be
+ self-referential or otherwise position-dependent. This Adjust
+ can be eliminated only by using one of the following
+ permissions.
+
+22/2
+{AI95-00147-01AI95-00147-01} Furthermore, an implementation is permitted
+to omit implicit Initialize, Adjust, and Finalize calls and associated
+assignment operations on an object of a nonlimited controlled type
+provided that:
+
+23/2
+ * any omitted Initialize call is not a call on a user-defined
+ Initialize procedure, and
+
+23.a/2
+ To be honest: This does not apply to any calls to a
+ user-defined Initialize routine that happen to occur in an
+ Adjust or Finalize routine. It is intended that it is never
+ necessary to look inside of an Adjust or Finalize routine to
+ determine if the call can be omitted.
+
+23.b/2
+ Reason: We don't want to eliminate objects for which the
+ Initialize might have side effects (such as locking a
+ resource).
+
+24/2
+ * any usage of the value of the object after the implicit Initialize
+ or Adjust call and before any subsequent Finalize call on the
+ object does not change the external effect of the program, and
+
+25/2
+ * after the omission of such calls and operations, any execution of
+ the program that executes an Initialize or Adjust call on an object
+ or initializes an object by an aggregate will also later execute a
+ Finalize call on the object and will always do so prior to
+ assigning a new value to the object, and
+
+26/2
+ * the assignment operations associated with omitted Adjust calls are
+ also omitted.
+
+27/2
+This permission applies to Adjust and Finalize calls even if the
+implicit calls have additional external effects.
+
+27.a/2
+ Reason: The goal of the above permissions is to allow typical
+ dead assignment and dead variable removal algorithms to work
+ for nonlimited controlled types. We require that "pairs" of
+ Initialize/Adjust/Finalize operations are removed. (These
+ aren't always pairs, which is why we talk about "any execution
+ of the program".)
+
+ _Extensions to Ada 83_
+
+27.b
+ Controlled types and user-defined finalization are new to Ada
+ 95. (Ada 83 had finalization semantics only for masters of
+ tasks.)
+
+ _Extensions to Ada 95_
+
+27.c/2
+ {AI95-00161-01AI95-00161-01} Amendment Correction: Types
+ Controlled and Limited_Controlled now have
+ Preelaborable_Initialization, so that objects of types derived
+ from these types can be used in preelaborated packages.
+
+ _Wording Changes from Ada 95_
+
+27.d/2
+ {8652/00208652/0020} {AI95-00126-01AI95-00126-01} Corrigendum:
+ Clarified that Ada.Finalization is a remote types package.
+
+27.e/2
+ {8652/00218652/0021} {AI95-00182-01AI95-00182-01} Corrigendum:
+ Added wording to clarify that the default initialization
+ (whatever it is) of an ancestor part is used.
+
+27.f/2
+ {8652/00228652/0022} {AI95-00083-01AI95-00083-01} Corrigendum:
+ Clarified that Adjust is never called on an aggregate used for
+ the initialization of an object or subaggregate, or passed as
+ a parameter.
+
+27.g/2
+ {AI95-00147-01AI95-00147-01} Additional optimizations are
+ allowed for nonlimited controlled types. These allow
+ traditional dead variable elimination to be applied to such
+ types.
+
+27.h/2
+ {AI95-00318-02AI95-00318-02} Corrected the build-in-place
+ requirement for controlled aggregates to be consistent with
+ the requirements for limited types.
+
+27.i/2
+ {AI95-00348-01AI95-00348-01} The operations of types
+ Controlled and Limited_Controlled are now declared as null
+ procedures (see *note 6.7::) to make the semantics clear (and
+ to provide a good example of what null procedures can be used
+ for).
+
+27.j/2
+ {AI95-00360-01AI95-00360-01} Types that need finalization are
+ defined; this is used by the No_Nested_Finalization
+ restriction (see *note D.7::, "*note D.7:: Tasking
+ Restrictions").
+
+27.k/2
+ {AI95-00373-01AI95-00373-01} Generalized the description of
+ objects that have Initialize called for them to say that it is
+ done for all objects that are initialized by default. This is
+ needed so that all of the new cases are covered.
+
+ _Extensions to Ada 2005_
+
+27.l/3
+ {AI05-0212-1AI05-0212-1} Package Ada.Finalization now has Pure
+ categorization, so it can be mentioned for any package. Note
+ that this does not change the preelaborability of objects
+ descended from Controlled and Limited_Controlled.
+
+ _Wording Changes from Ada 2005_
+
+27.m/3
+ {AI05-0013-1AI05-0013-1} Correction: Eliminated coextensions
+ from the "needs finalization" rules, as this cannot be
+ determined in general in the compilation unit that declares
+ the type. (The designated type of the coextension may have
+ been imported as a limited view.) Uses of "needs
+ finalization" need to ensure that coextensions are handled by
+ other means (such as in No_Nested_Finalization - see *note
+ D.7::) or that coextensions cannot happen.
+
+27.n/3
+ {AI05-0013-1AI05-0013-1} Correction: Corrected the "needs
+ finalization" rules to include class-wide types, as a future
+ extension can include a part that needs finalization.
+
+27.o/3
+ {AI05-0026-1AI05-0026-1} Correction: Corrected the "needs
+ finalization" rules to clearly say that they ignore privacy.
+
+27.p/3
+ {AI05-0067-1AI05-0067-1} Correction: Changed "built in place"
+ to Dynamic Semantics and centralized the rules here. This
+ eliminates the fiction that built in place is just a
+ combination of a permission and a requirement; it clearly has
+ noticeable semantic effects. This wording change is not
+ intended to change the semantics of any correct Ada program.
+
+* Menu:
+
+* 7.6.1 :: Completion and Finalization
+
+\1f
+File: aarm2012.info, Node: 7.6.1, Up: 7.6
+
+7.6.1 Completion and Finalization
+---------------------------------
+
+1
+[This subclause defines completion and leaving of the execution of
+constructs and entities. A master is the execution of a construct that
+includes finalization of local objects after it is complete (and after
+waiting for any local tasks -- see *note 9.3::), but before leaving.
+Other constructs and entities are left immediately upon completion. ]
+
+ _Dynamic Semantics_
+
+2/2
+{AI95-00318-02AI95-00318-02} The execution of a construct or entity is
+complete when the end of that execution has been reached, or when a
+transfer of control (see *note 5.1::) causes it to be abandoned.
+Completion due to reaching the end of execution, or due to the transfer
+of control of an exit_statement, return statement, goto_statement, or
+requeue_statement or of the selection of a terminate_alternative is
+normal completion. Completion is abnormal otherwise [-- when control is
+transferred out of a construct due to abort or the raising of an
+exception].
+
+2.a
+ Discussion: Don't confuse the run-time concept of completion
+ with the compile-time concept of completion defined in *note
+ 3.11.1::.
+
+3/2
+{AI95-00162-01AI95-00162-01} {AI95-00416-01AI95-00416-01} After
+execution of a construct or entity is complete, it is left, meaning that
+execution continues with the next action, as defined for the execution
+that is taking place. Leaving an execution happens immediately after
+its completion, except in the case of a master: the execution of a body
+other than a package_body; the execution of a statement; or the
+evaluation of an expression, function_call, or range that is not part of
+an enclosing expression, function_call, range, or simple_statement
+(*note 5.1: S0147.) other than a simple_return_statement (*note 6.5:
+S0183.). A master is finalized after it is complete, and before it is
+left.
+
+3.a/2
+ Reason: {AI95-00162-01AI95-00162-01}
+ {AI95-00416-01AI95-00416-01} Expressions and statements are
+ masters so that objects created by subprogram calls (in
+ aggregates, allocators for anonymous access-to-object types,
+ and so on) are finalized and have their tasks awaited before
+ the expressions or statements are left. Note that expressions
+ like the condition of an if_statement are masters, because
+ they are not enclosed by a simple_statement. Similarly, a
+ function_call which is renamed is a master, as it is not in a
+ simple_statement (*note 5.1: S0147.).
+
+3.b/2
+ {AI95-00416-01AI95-00416-01} We have to include function_calls
+ in the contexts that do not cause masters to occur so that
+ expressions contained in a function_call (that is not part of
+ an expression or simple_statement) do not individually become
+ masters. We certainly do not want the parameter expressions
+ of a function_call to be separate masters, as they would then
+ be finalized before the function is called.
+
+3.c/2
+ Ramification: {AI95-00416-01AI95-00416-01} The fact that a
+ function_call is a master does not change the accessibility of
+ the return object denoted by the function_call; that depends
+ on the use of the function_call. The function_call is the
+ master of any short-lived entities (such as aggregates used as
+ parameters of types with task or controlled parts).
+
+4
+For the finalization of a master, dependent tasks are first awaited, as
+explained in *note 9.3::. Then each object whose accessibility level is
+the same as that of the master is finalized if the object was
+successfully initialized and still exists. [These actions are performed
+whether the master is left by reaching the last statement or via a
+transfer of control.] When a transfer of control causes completion of
+an execution, each included master is finalized in order, from innermost
+outward.
+
+4.a
+ Ramification: As explained in *note 3.10.2::, the set of
+ objects with the same accessibility level as that of the
+ master includes objects declared immediately within the
+ master, objects declared in nested packages, objects created
+ by allocators (if the ultimate ancestor access type is
+ declared in one of those places) and subcomponents of all of
+ these things. If an object was already finalized by
+ Unchecked_Deallocation, then it is not finalized again when
+ the master is left.
+
+4.b
+ Note that any object whose accessibility level is deeper than
+ that of the master would no longer exist; those objects would
+ have been finalized by some inner master. Thus, after leaving
+ a master, the only objects yet to be finalized are those whose
+ accessibility level is less deep than that of the master.
+
+4.c
+ To be honest: Subcomponents of objects due to be finalized are
+ not finalized by the finalization of the master; they are
+ finalized by the finalization of the containing object.
+
+4.d
+ Reason: We need to finalize subcomponents of objects even if
+ the containing object is not going to get finalized because it
+ was not fully initialized. But if the containing object is
+ finalized, we don't want to require repeated finalization of
+ the subcomponents, as might normally be implied by the
+ recursion in finalization of a master and the recursion in
+ finalization of an object.
+
+4.e
+ To be honest: Formally, completion and leaving refer to
+ executions of constructs or entities. However, the standard
+ sometimes (informally) refers to the constructs or entities
+ whose executions are being completed. Thus, for example, "the
+ subprogram call or task is complete" really means "the
+ execution of the subprogram call or task is complete."
+
+5
+For the finalization of an object:
+
+6/3
+ * {AI05-0099-1AI05-0099-1} If the full type of the object is an
+ elementary type, finalization has no effect;
+
+6.a/3
+ Reason: {AI05-0099-1AI05-0099-1} We say "full type" in this
+ and the following bullets as privacy is ignored for the
+ purpose of determining the finalization actions of an object;
+ that is as expected for Dynamic Semantics rules.
+
+7/3
+ * {AI05-0099-1AI05-0099-1} If the full type of the object is a tagged
+ type, and the tag of the object identifies a controlled type, the
+ Finalize procedure of that controlled type is called;
+
+8/3
+ * {AI05-0099-1AI05-0099-1} If the full type of the object is a
+ protected type, or if the full type of the object is a tagged type
+ and the tag of the object identifies a protected type, the actions
+ defined in *note 9.4:: are performed;
+
+9/3
+ * {AI95-00416-01AI95-00416-01} {AI05-0099-1AI05-0099-1} If the full
+ type of the object is a composite type, then after performing the
+ above actions, if any, every component of the object is finalized
+ in an arbitrary order, except as follows: if the object has a
+ component with an access discriminant constrained by a per-object
+ expression, this component is finalized before any components that
+ do not have such discriminants; for an object with several
+ components with such a discriminant, they are finalized in the
+ reverse of the order of their component_declarations;
+
+9.a
+ Reason: This allows the finalization of a component with an
+ access discriminant to refer to other components of the
+ enclosing object prior to their being finalized.
+
+9.b/3
+ To be honest: {AI05-0099-1AI05-0099-1} The components
+ discussed here are all of the components that the object
+ actually has, not just those components that are statically
+ identified by the type of the object. These can be different
+ if the object has a classwide type.
+
+9.1/2
+ * {AI95-00416-01AI95-00416-01} If the object has coextensions (see
+ *note 3.10.2::), each coextension is finalized after the object
+ whose access discriminant designates it.
+
+9.c/3
+ Ramification: {AI05-0066-1AI05-0066-1} In the case of an
+ aggregate or function call that is used (in its entirety) to
+ directly initialize a part of an object, the coextensions of
+ the result of evaluating the aggregate or function call are
+ transfered to become coextensions of the object being
+ initialized and are not finalized until the object being
+ initialized is ultimately finalized, even if an anonymous
+ object is created as part of the operation.
+
+10
+Immediately before an instance of Unchecked_Deallocation reclaims the
+storage of an object, the object is finalized. [If an instance of
+Unchecked_Deallocation is never applied to an object created by an
+allocator, the object will still exist when the corresponding master
+completes, and it will be finalized then.]
+
+11/3
+{AI95-00280-01AI95-00280-01} {AI05-0051-1AI05-0051-1}
+{AI05-0190-1AI05-0190-1} The finalization of a master performs
+finalization of objects created by declarations in the master in the
+reverse order of their creation. After the finalization of a master is
+complete, the objects finalized as part of its finalization cease to
+exist, as do any types and subtypes defined and created within the
+master.
+
+11.a/3
+ This paragraph was deleted.{AI05-0190-1AI05-0190-1}
+
+11.b/3
+ This paragraph was deleted.{AI05-0190-1AI05-0190-1}
+
+11.c/3
+ This paragraph was deleted.{AI05-0190-1AI05-0190-1}
+
+11.d/3
+ This paragraph was deleted.{AI05-0190-1AI05-0190-1}
+
+11.e
+ Ramification: Note that a deferred constant declaration does
+ not create the constant; the full constant declaration creates
+ it. Therefore, the order of finalization depends on where the
+ full constant declaration occurs, not the deferred constant
+ declaration.
+
+11.f
+ An imported object is not created by its declaration. It is
+ neither initialized nor finalized.
+
+11.g
+ Implementation Note: An implementation has to ensure that the
+ storage for an object is not reclaimed when references to the
+ object are still possible (unless, of course, the user
+ explicitly requests reclamation via an instance of
+ Unchecked_Deallocation). This implies, in general, that
+ objects cannot be deallocated one by one as they are
+ finalized; a subsequent finalization might reference an object
+ that has been finalized, and that object had better be in its
+ (well-defined) finalized state.
+
+11.1/3
+{AI05-0190-1AI05-0190-1} Each nonderived access type T has an associated
+collection, which is the set of objects created by allocators of T, or
+of types derived from T. Unchecked_Deallocation removes an object from
+its collection. Finalization of a collection consists of finalization
+of each object in the collection, in an arbitrary order. The collection
+of an access type is an object implicitly declared at the following
+place:
+
+11.h/3
+ Ramification: {AI05-0190-1AI05-0190-1} The place of the
+ implicit declaration determines when allocated objects are
+ finalized. For multiple collections declared at the same
+ place, we do not define the order of their implicit
+ declarations.
+
+11.i/3
+ {AI05-0190-1AI05-0190-1} Finalization of allocated objects is
+ done according to the (ultimate ancestor) allocator type, not
+ according to the storage pool in which they are allocated.
+ Pool finalization might reclaim storage (see *note 13.11::,
+ "*note 13.11:: Storage Management"), but has nothing
+ (directly) to do with finalization of the pool elements.
+
+11.j/3
+ {AI05-0190-1AI05-0190-1} Note that finalization is done only
+ for objects that still exist; if an instance of
+ Unchecked_Deallocation has already gotten rid of a given pool
+ element, that pool element will not be finalized when the
+ master is left.
+
+11.k/3
+ Reason: {AI05-0190-1AI05-0190-1} Note that we talk about the
+ type of the allocator here. There may be access values of a
+ (general) access type pointing at objects created by
+ allocators for some other type; these are not (necessarily)
+ finalized at this point.
+
+11.2/3
+ * For a named access type, the first freezing point (see *note
+ 13.14::) of the type.
+
+11.l/3
+ Reason: {AI05-0190-1AI05-0190-1} The freezing point of the
+ ultimate ancestor access type is chosen because before that
+ point, pool elements cannot be created, and after that point,
+ access values designating (parts of) the pool elements can be
+ created. This is also the point after which the pool object
+ cannot have been declared. We don't want to finalize the pool
+ elements until after anything finalizing objects that contain
+ access values designating them. Nor do we want to finalize
+ pool elements after finalizing the pool object itself.
+
+11.3/3
+ * For the type of an access parameter, the call that contains the
+ allocator.
+
+11.4/3
+ * For the type of an access result, within the master of the call
+ (see *note 3.10.2::).
+
+11.m/3
+ To be honest: {AI05-0005-1AI05-0005-1}
+ {AI05-0190-1AI05-0190-1} We mean at a place within the master
+ consistent with the execution of the call within the master.
+ We don't say that normatively, as it is difficult to explain
+ that when the master of the call need not be the master that
+ immediately includes the call (such as when an anonymous
+ result is converted to a named access type).
+
+11.5/3
+ * For any other anonymous access type, the first freezing point of
+ the innermost enclosing declaration.
+
+12/2
+{AI95-00256-01AI95-00256-01} The target of an assignment_statement is
+finalized before copying in the new value, as explained in *note 7.6::.
+
+13/3
+{8652/00218652/0021} {AI95-00182-01AI95-00182-01}
+{AI95-00162-01AI95-00162-01} {AI05-0066-1AI05-0066-1}
+{AI05-0142-4AI05-0142-4} {AI05-0269-1AI05-0269-1} The master of an
+object is the master enclosing its creation whose accessibility level
+(see *note 3.10.2::) is equal to that of the object, except in the case
+of an anonymous object representing the result of an aggregate or
+function call. If such an anonymous object is part of the result of
+evaluating the actual parameter expression for an explicitly aliased
+parameter of a function call, the master of the object is the innermost
+master enclosing the evaluation of the aggregate or function call,
+excluding the aggregate or function call itself. Otherwise, the master
+of such an anonymous object is the innermost master enclosing the
+evaluation of the aggregate or function call, which may be the aggregate
+or function call itself.
+
+13.a/2
+ This paragraph was deleted.{AI95-00162-01AI95-00162-01}
+
+13.b/2
+ This paragraph was deleted.
+
+13.c/2
+ This paragraph was deleted.
+
+13.d/2
+ Reason: {AI95-00162-01AI95-00162-01} This effectively imports
+ all of the special rules for the accessibility level of
+ renames, allocators, and so on, and applies them to determine
+ where objects created in them are finalized. For instance,
+ the master of a rename of a subprogram is that of the renamed
+ subprogram.
+
+13.e/3
+ {AI05-0066-1AI05-0066-1} In *note 3.10.2:: we assign an
+ accessibility level to the result of an aggregate or function
+ call that is used to directly initialize a part of an object
+ based on the object being initialized. This is important to
+ ensure that any access discriminants denote objects that live
+ at least as long as the object being initialized. However, if
+ the result of the aggregate or function call is not built
+ directly in the target object, but instead is built in an
+ anonymous object that is then assigned to the target, the
+ anonymous object needs to be finalized after the assignment
+ rather than persisting until the target object is finalized
+ (but not its coextensions). (Note than an implementation is
+ never required to create such an anonymous object, and in some
+ cases is required to not have such a separate object, but
+ rather to build the result directly in the target.)
+
+13.f/3
+ {AI05-0142-4AI05-0142-4} The special case for explicitly
+ aliased parameters of functions is needed for the same reason,
+ as access discriminants of the returned object may designate
+ one of these parameters. In that case, we want to lengthen
+ the lifetime of the anonymous objects as long as the possible
+ lifetime of the result.
+
+13.g/3
+ {AI05-0142-4AI05-0142-4} We don't do a similar change for
+ other kinds of calls, because the extended lifetime of the
+ parameters adds no value, but could constitute a storage leak.
+ For instance, such an anonymous object created by a procedure
+ call in the elaboration part of a package body would have to
+ live until the end of the program, even though it could not be
+ used after the procedure returns (other than via
+ Unchecked_Access).
+
+13.h/3
+ Ramification: {AI05-0142-4AI05-0142-4} Note that the lifetime
+ of the master given to anonymous objects in explicitly aliased
+ parameters of functions is not necessarily as long as the
+ lifetime of the master of the object being initialized (if the
+ function call is used to initialize an allocator, for
+ instance). In that case, the accessibility check on
+ explicitly aliased parameters will necessarily fail if any
+ such anonymous objects exist. This is necessary to avoid
+ requiring the objects to live as long as the access type or
+ having the implementation complexity of an implicit
+ coextension.
+
+13.1/3
+{8652/00238652/0023} {AI95-00169-01AI95-00169-01}
+{AI95-00162-01AI95-00162-01} {AI05-0066-1AI05-0066-1}
+{AI05-0262-1AI05-0262-1} In the case of an expression that is a master,
+finalization of any (anonymous) objects occurs after completing
+evaluation of the expression and all use of the objects, prior to
+starting the execution of any subsequent construct.
+
+ _Bounded (Run-Time) Errors_
+
+14/1
+{8652/00238652/0023} {AI95-00169-01AI95-00169-01} It is a bounded error
+for a call on Finalize or Adjust that occurs as part of object
+finalization or assignment to propagate an exception. The possible
+consequences depend on what action invoked the Finalize or Adjust
+operation:
+
+14.a
+ Ramification: It is not a bounded error for Initialize to
+ propagate an exception. If Initialize propagates an
+ exception, then no further calls on Initialize are performed,
+ and those components that have already been initialized
+ (either explicitly or by default) are finalized in the usual
+ way.
+
+14.a.1/1
+ {8652/00238652/0023} {AI95-00169-01AI95-00169-01} It also is
+ not a bounded error for an explicit call to Finalize or Adjust
+ to propagate an exception. We do not want implementations to
+ have to treat explicit calls to these routines specially.
+
+15
+ * For a Finalize invoked as part of an assignment_statement,
+ Program_Error is raised at that point.
+
+16/2
+ * {8652/00248652/0024} {AI95-00193-01AI95-00193-01}
+ {AI95-00256-01AI95-00256-01} For an Adjust invoked as part of
+ assignment operations other than those invoked as part of an
+ assignment_statement, other adjustments due to be performed might
+ or might not be performed, and then Program_Error is raised.
+ During its propagation, finalization might or might not be applied
+ to objects whose Adjust failed. For an Adjust invoked as part of
+ an assignment_statement, any other adjustments due to be performed
+ are performed, and then Program_Error is raised.
+
+16.a/2
+ Reason: {8652/00248652/0024} {AI95-00193-01AI95-00193-01}
+ {AI95-00256-01AI95-00256-01} In the case of assignments that
+ are part of initialization, there is no need to complete all
+ adjustments if one propagates an exception, as the object will
+ immediately be finalized. So long as a subcomponent is not
+ going to be finalized, it need not be adjusted, even if it is
+ initialized as part of an enclosing composite assignment
+ operation for which some adjustments are performed. However,
+ there is no harm in an implementation making additional Adjust
+ calls (as long as any additional components that are adjusted
+ are also finalized), so we allow the implementation
+ flexibility here. On the other hand, for an
+ assignment_statement, it is important that all adjustments be
+ performed, even if one fails, because all controlled
+ subcomponents are going to be finalized. Other kinds of
+ assignment are more like initialization than
+ assignment_statements, so we include them as well in the
+ permission.
+
+16.a.1/1
+ Ramification: {8652/00248652/0024}
+ {AI95-00193-01AI95-00193-01} Even if an Adjust invoked as part
+ of the initialization of a controlled object propagates an
+ exception, objects whose initialization (including any Adjust
+ or Initialize calls) successfully completed will be finalized.
+ The permission above only applies to objects whose Adjust
+ failed. Objects for which Adjust was never even invoked must
+ not be finalized.
+
+17
+ * For a Finalize invoked as part of a call on an instance of
+ Unchecked_Deallocation, any other finalizations due to be performed
+ are performed, and then Program_Error is raised.
+
+17.a.1/1
+ Discussion: {8652/01048652/0104} {AI95-00179-01AI95-00179-01}
+ The standard does not specify if storage is recovered in this
+ case. If storage is not recovered (and the object continues
+ to exist), Finalize may be called on the object again (when
+ the allocator's master is finalized).
+
+17.1/3
+ * This paragraph was deleted.{8652/00238652/0023}
+ {AI95-00169-01AI95-00169-01} {AI05-0064-1AI05-0064-1}
+
+17.2/1
+ * {8652/00238652/0023} {AI95-00169-01AI95-00169-01} For a Finalize
+ invoked due to reaching the end of the execution of a master, any
+ other finalizations associated with the master are performed, and
+ Program_Error is raised immediately after leaving the master.
+
+17.a/3
+ Discussion: {AI05-0064-1AI05-0064-1} This rule covers both
+ ordinary objects created by a declaration, and anonymous
+ objects created as part of evaluating an expression. All
+ contexts that create objects that need finalization are
+ defined to be masters.
+
+18/2
+ * {AI95-00318-02AI95-00318-02} For a Finalize invoked by the transfer
+ of control of an exit_statement, return statement, goto_statement,
+ or requeue_statement (*note 9.5.4: S0226.), Program_Error is raised
+ no earlier than after the finalization of the master being
+ finalized when the exception occurred, and no later than the point
+ where normal execution would have continued. Any other
+ finalizations due to be performed up to that point are performed
+ before raising Program_Error.
+
+18.a
+ Ramification: For example, upon leaving a block_statement due
+ to a goto_statement, the Program_Error would be raised at the
+ point of the target statement denoted by the label, or else in
+ some more dynamically nested place, but not so nested as to
+ allow an exception_handler that has visibility upon the
+ finalized object to handle it. For example,
+
+18.b
+ procedure Main is
+ begin
+ <<The_Label>>
+ Outer_Block_Statement : declare
+ X : Some_Controlled_Type;
+ begin
+ Inner_Block_Statement : declare
+ Y : Some_Controlled_Type;
+ Z : Some_Controlled_Type;
+ begin
+ goto The_Label;
+ exception
+ when Program_Error => ... -- Handler number 1.
+ end;
+ exception
+ when Program_Error => ... -- Handler number 2.
+ end;
+ exception
+ when Program_Error => ... -- Handler number 3.
+ end Main;
+
+18.c
+ The goto_statement will first cause Finalize(Y) to be called.
+ Suppose that Finalize(Y) propagates an exception.
+ Program_Error will be raised after leaving
+ Inner_Block_Statement, but before leaving Main. Thus, handler
+ number 1 cannot handle this Program_Error; it will be handled
+ either by handler number 2 or handler number 3. If it is
+ handled by handler number 2, then Finalize(Z) will be done
+ before executing the handler. If it is handled by handler
+ number 3, then Finalize(Z) and Finalize(X) will both be done
+ before executing the handler.
+
+19
+ * For a Finalize invoked by a transfer of control that is due to
+ raising an exception, any other finalizations due to be performed
+ for the same master are performed; Program_Error is raised
+ immediately after leaving the master.
+
+19.a
+ Ramification: If, in the above example, the goto_statement
+ were replaced by a raise_statement, then the Program_Error
+ would be handled by handler number 2, and Finalize(Z) would be
+ done before executing the handler.
+
+19.b
+ Reason: We considered treating this case in the same way as
+ the others, but that would render certain exception_handlers
+ useless. For example, suppose the only exception_handler is
+ one for others in the main subprogram. If some deeply nested
+ call raises an exception, causing some Finalize operation to
+ be called, which then raises an exception, then normal
+ execution "would have continued" at the beginning of the
+ exception_handler. Raising Program_Error at that point would
+ cause that handler's code to be skipped. One would need two
+ nested exception_handlers to be sure of catching such cases!
+
+19.c
+ On the other hand, the exception_handler for a given master
+ should not be allowed to handle exceptions raised during
+ finalization of that master.
+
+20
+ * For a Finalize invoked by a transfer of control due to an abort or
+ selection of a terminate alternative, the exception is ignored; any
+ other finalizations due to be performed are performed.
+
+20.a
+ Ramification: This case includes an asynchronous transfer of
+ control.
+
+20.b
+ To be honest: This violates the general principle that it is
+ always possible for a bounded error to raise Program_Error
+ (see *note 1.1.5::, "*note 1.1.5:: Classification of Errors").
+
+ _Implementation Permissions_
+
+20.1/3
+{AI05-0107-1AI05-0107-1} If the execution of an allocator propagates an
+exception, any parts of the allocated object that were successfully
+initialized may be finalized as part of the finalization of the
+innermost master enclosing the allocator.
+
+20.c/3
+ Reason: This allows deallocating the memory for the allocated
+ object at the innermost master, preventing a storage leak.
+ Otherwise, the object would have to stay around until the
+ finalization of the collection that it belongs to, which could
+ be the entire life of the program if the associated access
+ type is library level.
+
+20.2/3
+{AI05-0111-3AI05-0111-3} {AI05-0262-1AI05-0262-1} The implementation may
+finalize objects created by allocators for an access type whose storage
+pool supports subpools (see *note 13.11.4::) as if the objects were
+created (in an arbitrary order) at the point where the storage pool was
+elaborated instead of at the first freezing point of the access type.
+
+20.d/3
+ Ramification: This allows the finalization of such objects to
+ occur later than they otherwise would, but still as part of
+ the finalization of the same master. Accessibility rules in
+ *note 13.11.4:: ensure that it is the same master (usually
+ that of the environment task).
+
+20.e/3
+ Implementation Note: This permission is intended to allow the
+ allocated objects to "belong" to the subpool objects and to
+ allow those objects to be finalized at the time that the
+ storage pool is finalized (if they are not finalized earlier).
+ This is expected to ease implementation, as the objects will
+ only need to belong to the subpool and not also to the
+ collection.
+
+ NOTES
+
+21/3
+ 18 {AI05-0299-1AI05-0299-1} The rules of Clause 10 imply that
+ immediately prior to partition termination, Finalize operations are
+ applied to library-level controlled objects (including those
+ created by allocators of library-level access types, except those
+ already finalized). This occurs after waiting for library-level
+ tasks to terminate.
+
+21.a
+ Discussion: We considered defining a pragma that would apply
+ to a controlled type that would suppress Finalize operations
+ for library-level objects of the type upon partition
+ termination. This would be useful for types whose
+ finalization actions consist of simply reclaiming global heap
+ storage, when this is already provided automatically by the
+ environment upon program termination.
+
+22
+ 19 A constant is only constant between its initialization and
+ finalization. Both initialization and finalization are allowed to
+ change the value of a constant.
+
+23
+ 20 Abort is deferred during certain operations related to
+ controlled types, as explained in *note 9.8::. Those rules prevent
+ an abort from causing a controlled object to be left in an
+ ill-defined state.
+
+24
+ 21 The Finalize procedure is called upon finalization of a
+ controlled object, even if Finalize was called earlier, either
+ explicitly or as part of an assignment; hence, if a controlled type
+ is visibly controlled (implying that its Finalize primitive is
+ directly callable), or is nonlimited (implying that assignment is
+ allowed), its Finalize procedure should be designed to have no ill
+ effect if it is applied a second time to the same object.
+
+24.a
+ Discussion: Or equivalently, a Finalize procedure should be
+ "idempotent"; applying it twice to the same object should be
+ equivalent to applying it once.
+
+24.b
+ Reason: A user-written Finalize procedure should be idempotent
+ since it can be called explicitly by a client (at least if the
+ type is "visibly" controlled). Also, Finalize is used
+ implicitly as part of the assignment_statement if the type is
+ nonlimited, and an abort is permitted to disrupt an
+ assignment_statement between finalizing the left-hand side and
+ assigning the new value to it (an abort is not permitted to
+ disrupt an assignment operation between copying in the new
+ value and adjusting it).
+
+24.c/2
+ Discussion: {AI95-00287-01AI95-00287-01} Either Initialize or
+ Adjust, but not both, is applied to (almost) every controlled
+ object when it is created: Initialize is done when no initial
+ value is assigned to the object, whereas Adjust is done as
+ part of assigning the initial value. The one exception is the
+ object initialized by an aggregate (both the anonymous object
+ created for an aggregate, or an object initialized by an
+ aggregate that is built-in-place); Initialize is not applied
+ to the aggregate as a whole, nor is the value of the aggregate
+ or object adjusted.
+
+24.d
+ All of the following use the assignment operation, and thus
+ perform value adjustment:
+
+24.e
+ * the assignment_statement (see *note 5.2::);
+
+24.f
+ * explicit initialization of a stand-alone object (see
+ *note 3.3.1::) or of a pool element (see *note 4.8::);
+
+24.g
+ * default initialization of a component of a stand-alone
+ object or pool element (in this case, the value of each
+ component is assigned, and therefore adjusted, but the
+ value of the object as a whole is not adjusted);
+
+24.h/2
+ * {AI95-00318-02AI95-00318-02} function return, when the
+ result is not built-in-place (adjustment of the result
+ happens before finalization of the function);
+
+24.i
+ * predefined operators (although the only one that matters
+ is concatenation; see *note 4.5.3::);
+
+24.j
+ * generic formal objects of mode in (see *note 12.4::);
+ these are defined in terms of constant declarations; and
+
+24.k/2
+ * {AI95-00287-01AI95-00287-01} aggregates (see *note
+ 4.3::), when the result is not built-in-place (in this
+ case, the value of each component, and the parent part,
+ for an extension_aggregate, is assigned, and therefore
+ adjusted, but the value of the aggregate as a whole is
+ not adjusted; neither is Initialize called);
+
+24.l
+ The following also use the assignment operation, but
+ adjustment never does anything interesting in these cases:
+
+24.m
+ * By-copy parameter passing uses the assignment operation
+ (see *note 6.4.1::), but controlled objects are always
+ passed by reference, so the assignment operation never
+ does anything interesting in this case. If we were to
+ allow by-copy parameter passing for controlled objects,
+ we would need to make sure that the actual is finalized
+ before doing the copy back for [in] out parameters. The
+ finalization of the parameter itself needs to happen
+ after the copy back (if any), similar to the finalization
+ of an anonymous function return object or aggregate
+ object.
+
+24.n
+ * For loops use the assignment operation (see *note 5.5::),
+ but since the type of the loop parameter is never
+ controlled, nothing interesting happens there, either.
+
+24.n.1/2
+ * {AI95-00318-02AI95-00318-02} Objects initialized by
+ function results and aggregates that are built-in-place.
+ In this case, the assignment operation is never executed,
+ and no adjustment takes place. While built-in-place is
+ always allowed, it is required for some types -- see
+ *note 7.5:: and *note 7.6:: -- and that's important since
+ limited types have no Adjust to call.
+
+24.o/2
+ This paragraph was deleted.{AI95-00287-01AI95-00287-01}
+
+24.p
+ Finalization of the parts of a protected object are not done
+ as protected actions. It is possible (in pathological cases)
+ to create tasks during finalization that access these parts in
+ parallel with the finalization itself. This is an erroneous
+ use of shared variables.
+
+24.q
+ Implementation Note: One implementation technique for
+ finalization is to chain the controlled objects together on a
+ per-task list. When leaving a master, the list can be walked
+ up to a marked place. The links needed to implement the list
+ can be declared (privately) in types Controlled and
+ Limited_Controlled, so they will be inherited by all
+ controlled types.
+
+24.r
+ Another implementation technique, which we refer to as the
+ "PC-map" approach essentially implies inserting exception
+ handlers at various places, and finalizing objects based on
+ where the exception was raised.
+
+24.s
+ The PC-map approach is for the compiler/linker to create a map
+ of code addresses; when an exception is raised, or abort
+ occurs, the map can be consulted to see where the task was
+ executing, and what finalization needs to be performed. This
+ approach was given in the Ada 83 Rationale as a possible
+ implementation strategy for exception handling -- the map is
+ consulted to determine which exception handler applies.
+
+24.t
+ If the PC-map approach is used, the implementation must take
+ care in the case of arrays. The generated code will generally
+ contain a loop to initialize an array. If an exception is
+ raised part way through the array, the components that have
+ been initialized must be finalized, and the others must not be
+ finalized.
+
+24.u
+ It is our intention that both of these implementation methods
+ should be possible.
+
+ _Wording Changes from Ada 83_
+
+24.v/3
+ {AI05-0299-1AI05-0299-1} Finalization depends on the concepts
+ of completion and leaving, and on the concept of a master.
+ Therefore, we have moved the definitions of these concepts
+ here, from where they used to be in Clause *note 9::. These
+ concepts also needed to be generalized somewhat. Task waiting
+ is closely related to user-defined finalization; the rules
+ here refer to the task-waiting rules of Clause *note 9::.
+
+ _Inconsistencies With Ada 95_
+
+24.v.1/3
+ {AI05-0066-1AI05-0066-1} Ada 2012 Correction: Changed the
+ definition of the master of an anonymous object used to
+ directly initialize an object, so it can be finalized
+ immediately rather than having to hang around as long as the
+ object. In this case, the Ada 2005 definition was
+ inconsistent with Ada 95, and Ada 2012 changes it back. It is
+ unlikely that many compilers implemented the rule as written
+ in Amendment 1, so an inconsistency is unlikely to arise in
+ practice.
+
+ _Wording Changes from Ada 95_
+
+24.w/2
+ {8652/00218652/0021} {AI95-00182-01AI95-00182-01} Corrigendum:
+ Fixed the wording to say that anonymous objects aren't
+ finalized until the object can't be used anymore.
+
+24.x/2
+ {8652/00238652/0023} {AI95-00169-01AI95-00169-01} Corrigendum:
+ Added wording to clarify what happens when Adjust or Finalize
+ raises an exception; some cases had been omitted.
+
+24.y/2
+ {8652/00248652/0024} {AI95-00193-01AI95-00193-01}
+ {AI95-00256-01AI95-00256-01} Corrigendum: Stated that if
+ Adjust raises an exception during initialization, nothing
+ further is required. This is corrected in Ada 2005 to include
+ all kinds of assignment other than assignment_statements.
+
+24.z/2
+ {AI95-00162-01AI95-00162-01} {AI95-00416-01AI95-00416-01}
+ Revised the definition of master to include expressions and
+ statements, in order to cleanly define what happens for tasks
+ and controlled objects created as part of a subprogram call.
+ Having done that, all of the special wording to cover those
+ cases is eliminated (at least until the Ada comments start
+ rolling in).
+
+24.aa/2
+ {AI95-00280-01AI95-00280-01} We define finalization of the
+ collection here, so as to be able to conveniently refer to it
+ in other rules (especially in *note 4.8::, "*note 4.8::
+ Allocators").
+
+24.bb/2
+ {AI95-00416-01AI95-00416-01} Clarified that a coextension is
+ finalized at the same time as the outer object. (This was
+ intended for Ada 95, but since the concept did not have a
+ name, it was overlooked.)
+
+ _Inconsistencies With Ada 2005_
+
+24.cc/3
+ {AI05-0051-1AI05-0051-1} {AI05-0190-1AI05-0190-1} Correction:
+ Better defined when objects allocated from anonymous access
+ types are finalized. This could be inconsistent if objects
+ are finalized in a different order than in an Ada 2005
+ implementation and that order caused different program
+ behavior; however programs that depend on the order of
+ finalization within a single master are already fragile and
+ hopefully are rare.
+
+ _Wording Changes from Ada 2005_
+
+24.dd/3
+ {AI05-0064-1AI05-0064-1} Correction: Removed a redundant rule,
+ which is now covered by the additional places where masters
+ are defined.
+
+24.ee/3
+ {AI05-0099-1AI05-0099-1} Correction: Clarified the
+ finalization rules so that there is no doubt that privacy is
+ ignored, and to ensure that objects of classwide interface
+ types are finalized based on their specific concrete type.
+
+24.ff/3
+ {AI05-0107-1AI05-0107-1} Correction: Allowed premature
+ finalization of parts of failed allocators. This could be an
+ inconsistency, but the previous behavior is still allowed and
+ there is no requirement that implementations take advantage of
+ the permission.
+
+24.gg/3
+ {AI05-0111-3AI05-0111-3} Added a permission to finalize object
+ allocated from a subpool later than usual.
+
+24.hh/3
+ {AI05-0142-4AI05-0142-4} Added text to specially define the
+ master of anonymous objects which are passed as explicitly
+ aliased parameters (see *note 6.1::) of functions. The model
+ for these parameters is explained in detail in *note 6.4.1::.
+
+\1f
+File: aarm2012.info, Node: 8, Next: 9, Prev: 7, Up: Top
+
+8 Visibility Rules
+******************
+
+1/3
+{AI05-0299-1AI05-0299-1} [The rules defining the scope of declarations
+and the rules defining which identifiers, character_literals, and
+operator_symbols are visible at (or from) various places in the text of
+the program are described in this clause. The formulation of these
+rules uses the notion of a declarative region.
+
+2/3
+{AI05-0299-1AI05-0299-1} As explained in Clause *note 3::, a declaration
+declares a view of an entity and associates a defining name with that
+view. The view comprises an identification of the viewed entity, and
+possibly additional properties. A usage name denotes a declaration. It
+also denotes the view declared by that declaration, and denotes the
+entity of that view. Thus, two different usage names might denote two
+different views of the same entity; in this case they denote the same
+entity.]
+
+2.a
+ To be honest: In some cases, a usage name that denotes a
+ declaration does not denote the view declared by that
+ declaration, nor the entity of that view, but instead denotes
+ a view of the current instance of the entity, and denotes the
+ current instance of the entity. This sometimes happens when
+ the usage name occurs inside the declarative region of the
+ declaration.
+
+ _Wording Changes from Ada 83_
+
+2.b
+ We no longer define the term "basic operation;" thus we no
+ longer have to worry about the visibility of them. Since they
+ were essentially always visible in Ada 83, this change has no
+ effect. The reason for this change is that the definition in
+ Ada 83 was confusing, and not quite correct, and we found it
+ difficult to fix. For example, one wonders why an
+ if_statement was not a basic operation of type Boolean. For
+ another example, one wonders what it meant for a basic
+ operation to be "inherent in" something. Finally, this fixes
+ the problem addressed by AI83-00027/07.
+
+* Menu:
+
+* 8.1 :: Declarative Region
+* 8.2 :: Scope of Declarations
+* 8.3 :: Visibility
+* 8.4 :: Use Clauses
+* 8.5 :: Renaming Declarations
+* 8.6 :: The Context of Overload Resolution
+
+\1f
+File: aarm2012.info, Node: 8.1, Next: 8.2, Up: 8
+
+8.1 Declarative Region
+======================
+
+ _Static Semantics_
+
+1
+For each of the following constructs, there is a portion of the program
+text called its declarative region, [within which nested declarations
+can occur]:
+
+2
+ * any declaration, other than that of an enumeration type, that is
+ not a completion [of a previous declaration];
+
+3
+ * a block_statement;
+
+4
+ * a loop_statement;
+
+4.1/3
+ * {AI05-0255-1AI05-0255-1} a quantified_expression;
+
+4.2/3
+ * {AI95-00318-02AI95-00318-02} an extended_return_statement;
+
+5
+ * an accept_statement;
+
+6
+ * an exception_handler.
+
+7
+The declarative region includes the text of the construct together with
+additional text determined [(recursively)], as follows:
+
+8
+ * If a declaration is included, so is its completion, if any.
+
+9
+ * If the declaration of a library unit [(including Standard -- see
+ *note 10.1.1::)] is included, so are the declarations of any child
+ units [(and their completions, by the previous rule)]. The child
+ declarations occur after the declaration.
+
+10
+ * If a body_stub is included, so is the corresponding subunit.
+
+11
+ * If a type_declaration is included, then so is a corresponding
+ record_representation_clause, if any.
+
+11.a
+ Reason: This is so that the component_declarations can be
+ directly visible in the record_representation_clause.
+
+12
+The declarative region of a declaration is also called the declarative
+region of any view or entity declared by the declaration.
+
+12.a
+ Reason: The constructs that have declarative regions are the
+ constructs that can have declarations nested inside them.
+ Nested declarations are declared in that declarative region.
+ The one exception is for enumeration literals; although they
+ are nested inside an enumeration type declaration, they behave
+ as if they were declared at the same level as the type.
+
+12.b
+ To be honest: A declarative region does not include
+ parent_unit_names.
+
+12.c
+ Ramification: A declarative region does not include
+ context_clauses.
+
+13
+A declaration occurs immediately within a declarative region if this
+region is the innermost declarative region that encloses the declaration
+(the immediately enclosing declarative region), not counting the
+declarative region (if any) associated with the declaration itself.
+
+13.a
+ Discussion: Don't confuse the declarative region of a
+ declaration with the declarative region in which it
+ immediately occurs.
+
+14
+[ A declaration is local to a declarative region if the declaration
+occurs immediately within the declarative region.] [An entity is local
+to a declarative region if the entity is declared by a declaration that
+is local to the declarative region.]
+
+14.a
+ Ramification: "Occurs immediately within" and "local to" are
+ synonyms (when referring to declarations).
+
+14.b
+ Thus, "local to" applies to both declarations and entities,
+ whereas "occurs immediately within" only applies to
+ declarations. We use this term only informally; for cases
+ where precision is required, we use the term "occurs
+ immediately within", since it is less likely to cause
+ confusion.
+
+15
+A declaration is global to a declarative region if the declaration
+occurs immediately within another declarative region that encloses the
+declarative region. An entity is global to a declarative region if the
+entity is declared by a declaration that is global to the declarative
+region.
+
+ NOTES
+
+16
+ 1 The children of a parent library unit are inside the parent's
+ declarative region, even though they do not occur inside the
+ parent's declaration or body. This implies that one can use (for
+ example) "P.Q" to refer to a child of P whose defining name is Q,
+ and that after "use P;" Q can refer (directly) to that child.
+
+17
+ 2 As explained above and in *note 10.1.1::, "*note 10.1.1::
+ Compilation Units - Library Units", all library units are
+ descendants of Standard, and so are contained in the declarative
+ region of Standard. They are not inside the declaration or body of
+ Standard, but they are inside its declarative region.
+
+18
+ 3 For a declarative region that comes in multiple parts, the text
+ of the declarative region does not contain any text that might
+ appear between the parts. Thus, when a portion of a declarative
+ region is said to extend from one place to another in the
+ declarative region, the portion does not contain any text that
+ might appear between the parts of the declarative region.
+
+18.a
+ Discussion: It is necessary for the things that have a
+ declarative region to include anything that contains
+ declarations (except for enumeration type declarations). This
+ includes any declaration that has a profile (that is,
+ subprogram_declaration, subprogram_body, entry_declaration,
+ subprogram_renaming_declaration,
+ formal_subprogram_declaration, access-to-subprogram
+ type_declaration), anything that has a discriminant_part (that
+ is, various kinds of type_declaration), anything that has a
+ component_list (that is, record type_declaration and record
+ extension type_declaration), and finally the declarations of
+ task and protected units and packages.
+
+ _Wording Changes from Ada 83_
+
+18.b
+ It was necessary to extend Ada 83's definition of declarative
+ region to take the following Ada 95 features into account:
+
+18.c
+ * Child library units.
+
+18.d
+ * Derived types/type extensions -- we need a declarative
+ region for inherited components and also for new
+ components.
+
+18.e
+ * All the kinds of types that allow discriminants.
+
+18.f
+ * Protected units.
+
+18.g
+ * Entries that have bodies instead of accept statements.
+
+18.h
+ * The choice_parameter_specification of an
+ exception_handler.
+
+18.i
+ * The formal parameters of access-to-subprogram types.
+
+18.j
+ * Renamings-as-body.
+
+18.k
+ Discriminated and access-to-subprogram type declarations need
+ a declarative region. Enumeration type declarations cannot
+ have one, because you don't have to say "Color.Red" to refer
+ to the literal Red of Color. For other type declarations, it
+ doesn't really matter whether or not there is an associated
+ declarative region, so for simplicity, we give one to all
+ types except enumeration types.
+
+18.l
+ We now say that an accept_statement has its own declarative
+ region, rather than being part of the declarative region of
+ the entry_declaration, so that declarative regions are
+ properly nested regions of text, so that it makes sense to
+ talk about "inner declarative regions," and "...extends to the
+ end of a declarative region." Inside an accept_statement, the
+ name of one of the parameters denotes the
+ parameter_specification of the accept_statement, not that of
+ the entry_declaration. If the accept_statement is nested
+ within a block_statement, these parameter_specifications can
+ hide declarations of the block_statement. The semantics of
+ such cases was unclear in RM83.
+
+18.m
+ To be honest: Unfortunately, we have the same problem for the
+ entry name itself -- it should denote the accept_statement,
+ but accept_statements are not declarations. They should be,
+ and they should hide the entry from all visibility within
+ themselves.
+
+18.n
+ Note that we can't generalize this to entry_bodies, or other
+ bodies, because the declarative_part of a body is not supposed
+ to contain (explicit) homographs of things in the declaration.
+ It works for accept_statements only because an
+ accept_statement does not have a declarative_part.
+
+18.o
+ To avoid confusion, we use the term "local to" only informally
+ in Ada 95. Even RM83 used the term incorrectly (see, for
+ example, RM83-12.3(13)).
+
+18.p
+ In Ada 83, (root) library units were inside Standard; it was
+ not clear whether the declaration or body of Standard was
+ meant. In Ada 95, they are children of Standard, and so occur
+ immediately within Standard's declarative region, but not
+ within either the declaration or the body. (See RM83-8.6(2)
+ and RM83-10.1.1(5).)
+
+ _Wording Changes from Ada 95_
+
+18.q/2
+ {AI95-00318-02AI95-00318-02} Extended_return_statement (see
+ *note 6.5::) is added to the list of constructs that have a
+ declarative region.
+
+\1f
+File: aarm2012.info, Node: 8.2, Next: 8.3, Prev: 8.1, Up: 8
+
+8.2 Scope of Declarations
+=========================
+
+1
+[For each declaration, the language rules define a certain portion of
+the program text called the scope of the declaration. The scope of a
+declaration is also called the scope of any view or entity declared by
+the declaration. Within the scope of an entity, and only there, there
+are places where it is legal to refer to the declared entity. These
+places are defined by the rules of visibility and overloading.]
+
+ _Static Semantics_
+
+2
+The immediate scope of a declaration is a portion of the declarative
+region immediately enclosing the declaration. The immediate scope
+starts at the beginning of the declaration, except in the case of an
+overloadable declaration, in which case the immediate scope starts just
+after the place where the profile of the callable entity is determined
+(which is at the end of the _specification for the callable entity, or
+at the end of the generic_instantiation if an instance). The immediate
+scope extends to the end of the declarative region, with the following
+exceptions:
+
+2.a
+ Reason: The reason for making overloadable declarations with
+ profiles special is to simplify compilation: until the
+ compiler has determined the profile, it doesn't know which
+ other declarations are homographs of this one, so it doesn't
+ know which ones this one should hide. Without this rule, two
+ passes over the _specification or generic_instantiation would
+ be required to resolve names that denote things with the same
+ name as this one.
+
+3
+ * The immediate scope of a library_item includes only its semantic
+ dependents.
+
+3.a/3
+ Reason: {AI05-0299-1AI05-0299-1} Clause 10 defines only a
+ partial ordering of library_items. Therefore, it is a good
+ idea to restrict the immediate scope (and the scope, defined
+ below) to semantic dependents.
+
+3.b
+ Consider also examples like this:
+
+3.c
+ package P is end P;
+
+3.d
+ package P.Q is
+ I : Integer := 0;
+ end P.Q;
+
+3.e/1
+ with P;
+ package R is
+ package X renames P;
+ J : Integer := X.Q.I; -- Illegal!
+ end R;
+
+3.f
+ The scope of P.Q does not contain R. Hence, neither P.Q nor
+ X.Q are visible within R. However, the name R.X.Q would be
+ visible in some other library unit where both R and P.Q are
+ visible (assuming R were made legal by removing the offending
+ declaration).
+
+3.g/2
+ Ramification: {AI95-00217-06AI95-00217-06} This rule applies
+ to limited views as well as "normal" library items. In that
+ case, the semantic dependents are the units that have a
+ limited_with_clause for the limited view.
+
+4
+ * The immediate scope of a declaration in the private part of a
+ library unit does not include the visible part of any public
+ descendant of that library unit.
+
+4.a
+ Ramification: In other words, a declaration in the private
+ part can be visible within the visible part, private part and
+ body of a private child unit. On the other hand, such a
+ declaration can be visible within only the private part and
+ body of a public child unit.
+
+4.b
+ Reason: The purpose of this rule is to prevent children from
+ giving private information to clients.
+
+4.c/2
+ Ramification: {AI95-00231-01AI95-00231-01} For a public child
+ subprogram, this means that the parent's private part is not
+ visible in the profile of the declaration and of the body.
+ This is true even for subprogram_bodies that are not
+ completions. For a public child generic unit, it means that
+ the parent's private part is not visible in the
+ generic_formal_part, as well as in the first list of
+ basic_declarative_items (for a generic package), or the
+ (syntactic) profile (for a generic subprogram).
+
+5
+[The visible part of (a view of) an entity is a portion of the text of
+its declaration containing declarations that are visible from outside.]
+The private part of (a view of) an entity that has a visible part
+contains all declarations within the declaration of (the view of) the
+entity, except those in the visible part; [these are not visible from
+outside. Visible and private parts are defined only for these kinds of
+entities: callable entities, other program units, and composite types.]
+
+6
+ * The visible part of a view of a callable entity is its profile.
+
+7
+ * The visible part of a composite type other than a task or protected
+ type consists of the declarations of all components declared
+ [(explicitly or implicitly)] within the type_declaration.
+
+8
+ * The visible part of a generic unit includes the
+ generic_formal_part. For a generic package, it also includes the
+ first list of basic_declarative_items of the package_specification.
+ For a generic subprogram, it also includes the profile.
+
+8.a
+ Reason: Although there is no way to reference anything but the
+ formals from outside a generic unit, they are still in the
+ visible part in the sense that the corresponding declarations
+ in an instance can be referenced (at least in some cases). In
+ other words, these declarations have an effect on the outside
+ world. The visible part of a generic unit needs to be defined
+ this way in order to properly support the rule that makes a
+ parent's private part invisible within a public child's
+ visible part.
+
+8.b
+ Ramification: The visible part of an instance of a generic
+ unit is as defined for packages and subprograms; it is not
+ defined in terms of the visible part of a generic unit.
+
+9
+ * [The visible part of a package, task unit, or protected unit
+ consists of declarations in the program unit's declaration other
+ than those following the reserved word private, if any; see *note
+ 7.1:: and *note 12.7:: for packages, *note 9.1:: for task units,
+ and *note 9.4:: for protected units.]
+
+10
+The scope of a declaration always contains the immediate scope of the
+declaration. In addition, for a given declaration that occurs
+immediately within the visible part of an outer declaration, or is a
+public child of an outer declaration, the scope of the given declaration
+extends to the end of the scope of the outer declaration, except that
+the scope of a library_item includes only its semantic dependents.
+
+10.a
+ Ramification: Note the recursion. If a declaration appears in
+ the visible part of a library unit, its scope extends to the
+ end of the scope of the library unit, but since that only
+ includes dependents of the declaration of the library unit,
+ the scope of the inner declaration also only includes those
+ dependents. If X renames library package P, which has a child
+ Q, a with_clause mentioning P.Q is necessary to be able to
+ refer to X.Q, even if P.Q is visible at the place where X is
+ declared.
+
+10.1/3
+{AI95-00408-01AI95-00408-01} {AI05-0183-1AI05-0183-1} The scope of an
+attribute_definition_clause is identical to the scope of a declaration
+that would occur at the point of the attribute_definition_clause. The
+scope of an aspect_specification is identical to the scope of the
+associated declaration.
+
+11
+The immediate scope of a declaration is also the immediate scope of the
+entity or view declared by the declaration. Similarly, the scope of a
+declaration is also the scope of the entity or view declared by the
+declaration.
+
+11.a
+ Ramification: The rule for immediate scope implies the
+ following:
+
+11.b
+ * If the declaration is that of a library unit, then the
+ immediate scope includes the declarative region of the
+ declaration itself, but not other places, unless they are
+ within the scope of a with_clause that mentions the
+ library unit.
+
+11.c
+ It is necessary to attach the semantics of with_clauses
+ to [immediate] scopes (as opposed to visibility), in
+ order for various rules to work properly. A library unit
+ should hide a homographic implicit declaration that
+ appears in its parent, but only within the scope of a
+ with_clause that mentions the library unit. Otherwise,
+ we would violate the "legality determinable via semantic
+ dependences" rule of *note 10::, "*note 10:: Program
+ Structure and Compilation Issues". The declaration of a
+ library unit should be allowed to be a homograph of an
+ explicit declaration in its parent's body, so long as
+ that body does not mention the library unit in a
+ with_clause.
+
+11.d
+ This means that one cannot denote the declaration of the
+ library unit, but one might still be able to denote the
+ library unit via another view.
+
+11.e
+ A with_clause does not make the declaration of a library
+ unit visible; the lack of a with_clause prevents it from
+ being visible. Even if a library unit is mentioned in a
+ with_clause, its declaration can still be hidden.
+
+11.f
+ * The completion of the declaration of a library unit
+ (assuming that's also a declaration) is not visible,
+ neither directly nor by selection, outside that
+ completion.
+
+11.g
+ * The immediate scope of a declaration immediately within
+ the body of a library unit does not include any child of
+ that library unit.
+
+11.h
+ This is needed to prevent children from looking inside
+ their parent's body. The children are in the declarative
+ region of the parent, and they might be after the
+ parent's body. Therefore, the scope of a declaration
+ that occurs immediately within the body might include
+ some children.
+
+ NOTES
+
+12/3
+ 4 {AI05-0299-1AI05-0299-1} There are notations for denoting
+ visible declarations that are not directly visible. For example,
+ parameter_specification (*note 6.1: S0175.)s are in the visible
+ part of a subprogram_declaration (*note 6.1: S0163.) so that they
+ can be used in named-notation calls appearing outside the called
+ subprogram. For another example, declarations of the visible part
+ of a package can be denoted by expanded names appearing outside the
+ package, and can be made directly visible by a use_clause.
+
+12.a/3
+ Ramification: {AI95-00114-01AI95-00114-01}
+ {AI05-0299-1AI05-0299-1} There are some obscure cases
+ involving generics in which there is no such notation. See
+ Clause *note 12::.
+
+ _Extensions to Ada 83_
+
+12.b
+ The fact that the immediate scope of an overloadable
+ declaration does not include its profile is new to Ada 95. It
+ replaces RM83-8.3(16), which said that within a subprogram
+ specification and within the formal part of an entry
+ declaration or accept statement, all declarations with the
+ same designator as the subprogram or entry were hidden from
+ all visibility. The RM83-8.3(16) rule seemed to be overkill,
+ and created both implementation difficulties and unnecessary
+ semantic complexity.
+
+ _Wording Changes from Ada 83_
+
+12.c
+ We no longer need to talk about the scope of notations,
+ identifiers, character_literals, and operator_symbols.
+
+12.d/3
+ {AI05-0299-1AI05-0299-1} The notion of "visible part" has been
+ extended in Ada 95. The syntax of task and protected units
+ now allows private parts, thus requiring us to be able to talk
+ about the visible part as well. It was necessary to extend
+ the concept to subprograms and to generic units, in order for
+ the visibility rules related to child library units to work
+ properly. It was necessary to define the concept separately
+ for generic formal packages, since their visible part is
+ slightly different from that of a normal package. Extending
+ the concept to composite types made the definition of scope
+ slightly simpler. We define visible part for some things
+ elsewhere, since it makes a big difference to the user for
+ those things. For composite types and subprograms, however,
+ the concept is used only in arcane visibility rules, so we
+ localize it to this subclause.
+
+12.e
+ In Ada 83, the semantics of with_clauses was described in
+ terms of visibility. It is now described in terms of
+ [immediate] scope.
+
+12.f
+ We have clarified that the following is illegal (where Q and R
+ are library units):
+
+12.g
+ package Q is
+ I : Integer := 0;
+ end Q;
+
+12.h
+ package R is
+ package X renames Standard;
+ X.Q.I := 17; -- Illegal!
+ end R;
+
+12.i
+ even though Q is declared in the declarative region of
+ Standard, because R does not mention Q in a with_clause.
+
+ _Wording Changes from Ada 95_
+
+12.j/2
+ {AI95-00408-01AI95-00408-01} The scope of an
+ attribute_definition_clause is defined so that it can be used
+ to define the visibility of such a clause, so that can be used
+ by the stream attribute availability rules (see *note
+ 13.13.2::).
+
+ _Wording Changes from Ada 2005_
+
+12.k/3
+ {AI05-0183-1AI05-0183-1} The scope of an aspect_specification
+ is defined for similar reasons that it was defined for
+ attribute_definition_clauses.
+
+\1f
+File: aarm2012.info, Node: 8.3, Next: 8.4, Prev: 8.2, Up: 8
+
+8.3 Visibility
+==============
+
+1
+[ The visibility rules, given below, determine which declarations are
+visible and directly visible at each place within a program. The
+visibility rules apply to both explicit and implicit declarations.]
+
+ _Static Semantics_
+
+2
+A declaration is defined to be directly visible at places where a name
+consisting of only an identifier or operator_symbol is sufficient to
+denote the declaration; that is, no selected_component notation or
+special context (such as preceding => in a named association) is
+necessary to denote the declaration. A declaration is defined to be
+visible wherever it is directly visible, as well as at other places
+where some name (such as a selected_component) can denote the
+declaration.
+
+3
+The syntactic category direct_name is used to indicate contexts where
+direct visibility is required. The syntactic category selector_name is
+used to indicate contexts where visibility, but not direct visibility,
+is required.
+
+4
+There are two kinds of direct visibility: immediate visibility and
+use-visibility. A declaration is immediately visible at a place if it
+is directly visible because the place is within its immediate scope. A
+declaration is use-visible if it is directly visible because of a
+use_clause (see *note 8.4::). Both conditions can apply.
+
+5
+A declaration can be hidden, either from direct visibility, or from all
+visibility, within certain parts of its scope. Where hidden from all
+visibility, it is not visible at all (neither using a direct_name nor a
+selector_name). Where hidden from direct visibility, only direct
+visibility is lost; visibility using a selector_name is still possible.
+
+6
+[ Two or more declarations are overloaded if they all have the same
+defining name and there is a place where they are all directly visible.]
+
+6.a
+ Ramification: Note that a name can have more than one possible
+ interpretation even if it denotes a nonoverloadable entity.
+ For example, if there are two functions F that return records,
+ both containing a component called C, then the name F.C has
+ two possible interpretations, even though component
+ declarations are not overloadable.
+
+7
+The declarations of callable entities [(including enumeration literals)]
+are overloadable[, meaning that overloading is allowed for them].
+
+7.a
+ Ramification: A generic_declaration is not overloadable within
+ its own generic_formal_part. This follows from the rules
+ about when a name denotes a current instance. See AI83-00286.
+ This implies that within a generic_formal_part, outer
+ declarations with the same defining name are hidden from
+ direct visibility. It also implies that if a generic formal
+ parameter has the same defining name as the generic itself,
+ the formal parameter hides the generic from direct visibility.
+
+8
+Two declarations are homographs if they have the same defining name,
+and, if both are overloadable, their profiles are type conformant. [An
+inner declaration hides any outer homograph from direct visibility.]
+
+8.a/2
+ Glossary entry: An overriding operation is one that replaces
+ an inherited primitive operation. Operations may be marked
+ explicitly as overriding or not overriding.
+
+9/1
+{8652/00258652/0025} {AI95-00044-01AI95-00044-01} [Two homographs are
+not generally allowed immediately within the same declarative region
+unless one overrides the other (see Legality Rules below).] The only
+declarations that are overridable are the implicit declarations for
+predefined operators and inherited primitive subprograms. A declaration
+overrides another homograph that occurs immediately within the same
+declarative region in the following cases:
+
+10/1
+ * {8652/00258652/0025} {AI95-00044-01AI95-00044-01} A declaration
+ that is not overridable overrides one that is overridable,
+ [regardless of which declaration occurs first];
+
+10.a/1
+ Ramification: {8652/00258652/0025}
+ {AI95-00044-01AI95-00044-01} And regardless of whether the
+ nonoverridable declaration is overloadable or not. For
+ example, statement_identifiers are covered by this rule.
+
+10.b
+ The "regardless of which declaration occurs first" is there
+ because the explicit declaration could be a primitive
+ subprogram of a partial view, and then the full view might
+ inherit a homograph. We are saying that the explicit one wins
+ (within its scope), even though the implicit one comes later.
+
+10.c
+ If the overriding declaration is also a subprogram, then it is
+ a primitive subprogram.
+
+10.d
+ As explained in *note 7.3.1::, "*note 7.3.1:: Private
+ Operations", some inherited primitive subprograms are never
+ declared. Such subprograms cannot be overridden, although
+ they can be reached by dispatching calls in the case of a
+ tagged type.
+
+11
+ * The implicit declaration of an inherited operator overrides that of
+ a predefined operator;
+
+11.a
+ Ramification: In a previous version of Ada 9X, we tried to
+ avoid the notion of predefined operators, and say that they
+ were inherited from some magical root type. However, this
+ seemed like too much mechanism. Therefore, a type can have a
+ predefined "+" as well as an inherited "+". The above rule
+ says the inherited one wins.
+
+11.b/2
+ {AI95-00114-01AI95-00114-01} The "regardless of which
+ declaration occurs first" applies here as well, in the case
+ where derived_type_definition in the visible part of a public
+ library unit derives from a private type declared in the
+ parent unit, and the full view of the parent type has
+ additional predefined operators, as explained in *note
+ 7.3.1::, "*note 7.3.1:: Private Operations". Those predefined
+ operators can be overridden by inherited subprograms
+ implicitly declared earlier.
+
+12
+ * An implicit declaration of an inherited subprogram overrides a
+ previous implicit declaration of an inherited subprogram.
+
+12.1/2
+ * {AI95-00251-01AI95-00251-01} If two or more homographs are
+ implicitly declared at the same place:
+
+12.2/2
+ * {AI95-00251-01AI95-00251-01} If at least one is a
+ subprogram that is neither a null procedure nor an
+ abstract subprogram, and does not require overriding (see
+ *note 3.9.3::), then they override those that are null
+ procedures, abstract subprograms, or require overriding.
+ If more than one such homograph remains that is not thus
+ overridden, then they are all hidden from all visibility.
+
+12.3/2
+ * {AI95-00251-01AI95-00251-01} Otherwise (all are null
+ procedures, abstract subprograms, or require overriding),
+ then any null procedure overrides all abstract
+ subprograms and all subprograms that require overriding;
+ if more than one such homograph remains that is not thus
+ overridden, then if they are all fully conformant with
+ one another, one is chosen arbitrarily; if not, they are
+ all hidden from all visibility.
+
+12.a/2
+ Discussion: In the case where the implementation arbitrarily
+ chooses one overrider from among a group of inherited
+ subprograms, users should not be able to determine which
+ member was chosen, as the set of inherited subprograms which
+ are chosen from must be fully conformant. This rule is needed
+ in order to allow
+
+12.b/2
+ package Outer is
+ package P1 is
+ type Ifc1 is interface;
+ procedure Null_Procedure (X : Ifc1) is null;
+ procedure Abstract_Subp (X : Ifc1) is abstract;
+ end P1;
+
+12.c/2
+ package P2 is
+ type Ifc2 is interface;
+ procedure Null_Procedure (X : Ifc2) is null;
+ procedure Abstract_Subp (X : Ifc2) is abstract;
+ end P2;
+
+12.d/2
+ type T is abstract new P1.Ifc1 and P2.Ifc2 with null record;
+ end Outer;
+
+12.e/2
+ without requiring that T explicitly override any of its
+ inherited operations.
+
+12.f/2
+ Full conformance is required here, as we cannot allow the
+ parameter names to differ. If they did differ, the routine
+ which was selected for overriding could be determined by using
+ named parameter notation in a call.
+
+12.g/2
+ When the subprograms do not conform, we chose not to adopt the
+ "use clause" rule which would make them all visible resulting
+ in likely ambiguity. If we had used such a rule, any
+ successful calls would be confusing; and the fact that there
+ are no Beaujolais-like effect to worry about means we can
+ consider other rules. The hidden-from-all-visibility
+ homographs are still inherited by further derivations, which
+ avoids order-of-declaration dependencies and other anomalies.
+
+12.h/2
+ We have to be careful to not include arbitrary selection if
+ the routines have real bodies. (This can happen in generics,
+ see the example in the incompatibilities section below.) We
+ don't want the ability to successfully call routines where the
+ body executed depends on the compiler or a phase of the moon.
+
+12.i/2
+ Note that if the type is concrete, abstract subprograms are
+ inherited as subprograms that require overriding. We include
+ functions that require overriding as well; these don't have
+ real bodies, so they can use the more liberal rules.
+
+13
+ * [For an implicit declaration of a primitive subprogram in a generic
+ unit, there is a copy of this declaration in an instance.]
+ However, a whole new set of primitive subprograms is implicitly
+ declared for each type declared within the visible part of the
+ instance. These new declarations occur immediately after the type
+ declaration, and override the copied ones. [The copied ones can be
+ called only from within the instance; the new ones can be called
+ only from outside the instance, although for tagged types, the body
+ of a new one can be executed by a call to an old one.]
+
+13.a
+ Discussion: In addition, this is also stated redundantly
+ (again), and is repeated, in *note 12.3::, "*note 12.3::
+ Generic Instantiation". The rationale for the rule is
+ explained there.
+
+13.b/3
+ To be honest: {AI05-0042-1AI05-0042-1} The implicit
+ subprograms declared when an operation of a progenitor is
+ implemented by an entry or subprogram also override the
+ appropriate implicitly declared inherited operations of the
+ progenitor.
+
+14
+A declaration is visible within its scope, except where hidden from all
+visibility, as follows:
+
+15
+ * An overridden declaration is hidden from all visibility within the
+ scope of the overriding declaration.
+
+15.a
+ Ramification: We have to talk about the scope of the
+ overriding declaration, not its visibility, because it hides
+ even when it is itself hidden.
+
+15.b
+ Note that the scope of an explicit subprogram_declaration does
+ not start until after its profile.
+
+16
+ * A declaration is hidden from all visibility until the end of the
+ declaration, except:
+
+17
+ * For a record type or record extension, the declaration is
+ hidden from all visibility only until the reserved word
+ record;
+
+18/3
+ * {AI95-00345-01AI95-00345-01} {AI05-0177-1AI05-0177-1} For
+ a package_declaration, generic_package_declaration (*note
+ 12.1: S0272.), subprogram_body (*note 6.3: S0177.), or
+ expression_function_declaration (*note 6.8: S0189.), the
+ declaration is hidden from all visibility only until the
+ reserved word is of the declaration;
+
+18.a
+ Ramification: We're talking about the is of the construct
+ itself, here, not some random is that might appear in a
+ generic_formal_part.
+
+18.1/2
+ * {AI95-00345-01AI95-00345-01} For a task declaration or
+ protected declaration, the declaration is hidden from all
+ visibility only until the reserved word with of the
+ declaration if there is one, or the reserved word is of
+ the declaration if there is no with.
+
+18.b/2
+ To be honest: If there is neither a with nor is, then the
+ exception does not apply and the name is hidden from all
+ visibility until the end of the declaration. This oddity was
+ inherited from Ada 95.
+
+18.c/2
+ Reason: We need the "with or is" rule so that the visibility
+ within an interface_list does not vary by construct. That
+ would make it harder to complete private extensions and would
+ complicate implementations.
+
+19
+ * If the completion of a declaration is a declaration, then within
+ the scope of the completion, the first declaration is hidden from
+ all visibility. Similarly, a discriminant_specification (*note
+ 3.7: S0062.) or parameter_specification (*note 6.1: S0175.) is
+ hidden within the scope of a corresponding
+ discriminant_specification (*note 3.7: S0062.) or
+ parameter_specification (*note 6.1: S0175.) of a corresponding
+ completion, or of a corresponding accept_statement (*note 9.5.2:
+ S0219.).
+
+19.a
+ Ramification: This rule means, for example, that within the
+ scope of a full_type_declaration that completes a
+ private_type_declaration, the name of the type will denote the
+ full_type_declaration, and therefore the full view of the
+ type. On the other hand, if the completion is not a
+ declaration, then it doesn't hide anything, and you can't
+ denote it.
+
+20/2
+ * {AI95-00217-06AI95-00217-06} {AI95-00412-01AI95-00412-01} The
+ declaration of a library unit (including a
+ library_unit_renaming_declaration) is hidden from all visibility at
+ places outside its declarative region that are not within the scope
+ of a nonlimited_with_clause that mentions it. The limited view of
+ a library package is hidden from all visibility at places that are
+ not within the scope of a limited_with_clause that mentions it; in
+ addition, the limited view is hidden from all visibility within the
+ declarative region of the package, as well as within the scope of
+ any nonlimited_with_clause that mentions the package. Where the
+ declaration of the limited view of a package is visible, any name
+ that denotes the package denotes the limited view, including those
+ provided by a package renaming.
+
+20.a/2
+ Discussion: {AI95-00217-06AI95-00217-06} This is the rule that
+ prevents with_clauses from being transitive; the [immediate]
+ scope includes indirect semantic dependents. This rule also
+ prevents the limited view of a package from being visible in
+ the same place as the full view of the package, which prevents
+ various ripple effects.
+
+20.1/2
+ * {AI95-00217-06AI95-00217-06} {AI95-00412-01AI95-00412-01} [For each
+ declaration or renaming of a generic unit as a child of some parent
+ generic package, there is a corresponding declaration nested
+ immediately within each instance of the parent.] Such a nested
+ declaration is hidden from all visibility except at places that are
+ within the scope of a with_clause that mentions the child.
+
+21
+A declaration with a defining_identifier or defining_operator_symbol is
+immediately visible [(and hence directly visible)] within its immediate
+scope except where hidden from direct visibility, as follows:
+
+22
+ * A declaration is hidden from direct visibility within the immediate
+ scope of a homograph of the declaration, if the homograph occurs
+ within an inner declarative region;
+
+23
+ * A declaration is also hidden from direct visibility where hidden
+ from all visibility.
+
+23.1/3
+{AI95-00195-01AI95-00195-01} {AI95-00408-01AI95-00408-01}
+{AI05-0183-1AI05-0183-1} An attribute_definition_clause or an
+aspect_specification is visible everywhere within its scope.
+
+ _Name Resolution Rules_
+
+24
+A direct_name shall resolve to denote a directly visible declaration
+whose defining name is the same as the direct_name. A selector_name
+shall resolve to denote a visible declaration whose defining name is the
+same as the selector_name.
+
+24.a
+ Discussion: "The same as" has the obvious meaning here, so for
+ +, the possible interpretations are declarations whose
+ defining name is "+" (an operator_symbol).
+
+25
+These rules on visibility and direct visibility do not apply in a
+context_clause, a parent_unit_name, or a pragma that appears at the
+place of a compilation_unit. For those contexts, see the rules in *note
+10.1.6::, "*note 10.1.6:: Environment-Level Visibility Rules".
+
+25.a
+ Ramification: Direct visibility is irrelevant for
+ character_literals. In terms of overload resolution
+ character_literals are similar to other literals, like null --
+ see *note 4.2::. For character_literals, there is no need to
+ worry about hiding, since there is no way to declare
+ homographs.
+
+ _Legality Rules_
+
+26/2
+{8652/00258652/0025} {8652/00268652/0026} {AI95-00044-01AI95-00044-01}
+{AI95-00150-01AI95-00150-01} {AI95-00377-01AI95-00377-01} A
+nonoverridable declaration is illegal if there is a homograph occurring
+immediately within the same declarative region that is visible at the
+place of the declaration, and is not hidden from all visibility by the
+nonoverridable declaration. In addition, a type extension is illegal if
+somewhere within its immediate scope it has two visible components with
+the same name. Similarly, the context_clause for a compilation unit is
+illegal if it mentions (in a with_clause) some library unit, and there
+is a homograph of the library unit that is visible at the place of the
+compilation unit, and the homograph and the mentioned library unit are
+both declared immediately within the same declarative region. These
+rules also apply to dispatching operations declared in the visible part
+of an instance of a generic unit. However, they do not apply to other
+overloadable declarations in an instance[; such declarations may have
+type conformant profiles in the instance, so long as the corresponding
+declarations in the generic were not type conformant].
+
+26.a
+ Discussion: Normally, these rules just mean you can't
+ explicitly declare two homographs immediately within the same
+ declarative region. The wording is designed to handle the
+ following special cases:
+
+26.b
+ * If the second declaration completes the first one, the
+ second declaration is legal.
+
+26.c
+ * If the body of a library unit contains an explicit
+ homograph of a child of that same library unit, this is
+ illegal only if the body mentions the child in its
+ context_clause, or if some subunit mentions the child.
+ Here's an example:
+
+26.d
+ package P is
+ end P;
+
+26.e
+ package P.Q is
+ end P.Q;
+
+26.f
+ package body P is
+ Q : Integer; -- OK; we cannot see package P.Q here.
+ procedure Sub is separate;
+ end P;
+
+26.g
+ with P.Q;
+ separate(P)
+ procedure Sub is -- Illegal.
+ begin
+ null;
+ end Sub;
+
+26.h
+ If package body P said "with P.Q;", then it would be
+ illegal to declare the homograph Q: Integer. But it does
+ not, so the body of P is OK. However, the subunit would
+ be able to see both P.Q's, and is therefore illegal.
+
+26.i
+ A previous version of Ada 9X allowed the subunit, and
+ said that references to P.Q would tend to be ambiguous.
+ However, that was a bad idea, because it requires
+ overload resolution to resolve references to directly
+ visible nonoverloadable homographs, which is something
+ compilers have never before been required to do.
+
+26.i.1/1
+ * {8652/00268652/0026} {8652/01028652/0102}
+ {AI95-00150-01AI95-00150-01} {AI95-00157-01AI95-00157-01}
+ If a type extension contains a component with the same
+ name as a component in an ancestor type, there must be no
+ place where both components are visible. For instance:
+
+26.i.2/1
+ package A is
+ type T is tagged private;
+ package B is
+ type NT is new T with record
+ I: Integer; -- Illegal because T.I is visible in the body.
+ end record; -- T.I is not visible here.
+ end B;
+ private
+ type T is tagged record
+ I: Integer; -- Illegal because T.I is visible in the body.
+ end record;
+ end A;
+
+26.i.3/2
+ {AI95-00114-01AI95-00114-01} package body A is
+ package body B is
+ -- T.I becomes visible here.
+ end B;
+ end A;
+
+26.i.4/1
+ package A.C is
+ type NT2 is new A.T with record
+ I: Integer; -- Illegal because T.I is visible in the private part.
+ end record; -- T.I is not visible here.
+ private
+ -- T.I is visible here.
+ end A.C;
+
+26.i.5/1
+ with A;
+ package D is
+ type NT3 is new A.T with record
+ I: Integer; -- Legal because T.I is never visible in this package.
+ end record;
+ end D;
+
+26.i.6/1
+ with D;
+ package A.E is
+ type NT4 is new D.NT3 with null record;
+ X : NT4;
+ I1 : Integer := X.I; -- D.NT3.I
+ I2 : Integer := D.NT3(X).I; -- D.NT3.I
+ I3 : Integer := A.T(X).I; -- A.T.I
+ end A.E;
+
+26.i.7/1
+ {8652/01028652/0102} {AI95-00157-01AI95-00157-01} D.NT3
+ can have a component I because the component I of the
+ parent type is never visible. The parent component
+ exists, of course, but is never declared for the type
+ D.NT3. In the child package A.E, the component I of A.T
+ is visible, but that does not change the fact that the
+ A.T.I component was never declared for type D.NT3. Thus,
+ A.E.NT4 does not (visibly) inherit the component I from
+ A.T, while it does inherit the component I from D.NT3.
+ Of course, both components exist, and can be accessed by
+ a type conversion as shown above. This behavior stems
+ from the fact that every characteristic of a type
+ (including components) must be declared somewhere in the
+ innermost declarative region containing the type -- if
+ the characteristic is never visible in that declarative
+ region, it is never declared. Therefore, such
+ characteristics do not suddenly become available even if
+ they are in fact visible in some other scope. See *note
+ 7.3.1:: for more on the rules.
+
+26.i.8/2
+ * {AI95-00377-01AI95-00377-01} It is illegal to mention
+ both an explicit child of an instance, and a child of the
+ generic from which the instance was instantiated. This
+ is easier to understand with an example:
+
+26.i.9/2
+ generic
+ package G1 is
+ end G1;
+
+26.i.10/2
+ generic
+ package G1.G2 is
+ end G1.G2;
+
+26.i.11/2
+ with G1;
+ package I1 is new G1;
+
+26.i.12/2
+ package I1.G2 renames ...
+
+26.i.13/2
+ with G1.G2;
+ with I1.G2; -- Illegal
+ package Bad is ...
+
+26.i.14/2
+ The context clause for Bad is illegal as I1 has an
+ implicit declaration of I1.G2 based on the generic child
+ G1.G2, as well as the mention of the explicit child
+ I1.G2. As in the previous cases, this is illegal only if
+ the context clause makes both children visible; the
+ explicit child can be mentioned as long as the generic
+ child is not (and vice-versa).
+
+26.j
+ Note that we need to be careful which things we make "hidden
+ from all visibility" versus which things we make simply
+ illegal for names to denote. The distinction is subtle. The
+ rules that disallow names denoting components within a type
+ declaration (see *note 3.7::) do not make the components
+ invisible at those places, so that the above rule makes
+ components with the same name illegal. The same is true for
+ the rule that disallows names denoting formal parameters
+ within a formal_part (see *note 6.1::).
+
+26.k
+ Discussion: The part about instances is from AI83-00012. The
+ reason it says "overloadable declarations" is because we don't
+ want it to apply to type extensions that appear in an
+ instance; components are not overloadable.
+
+ NOTES
+
+27
+ 5 Visibility for compilation units follows from the definition of
+ the environment in *note 10.1.4::, except that it is necessary to
+ apply a with_clause to obtain visibility to a
+ library_unit_declaration or library_unit_renaming_declaration.
+
+28
+ 6 In addition to the visibility rules given above, the meaning of
+ the occurrence of a direct_name or selector_name at a given place
+ in the text can depend on the overloading rules (see *note 8.6::).
+
+29
+ 7 Not all contexts where an identifier, character_literal, or
+ operator_symbol are allowed require visibility of a corresponding
+ declaration. Contexts where visibility is not required are
+ identified by using one of these three syntactic categories
+ directly in a syntax rule, rather than using direct_name or
+ selector_name.
+
+29.a
+ Ramification: An identifier, character_literal or
+ operator_symbol that occurs in one of the following contexts
+ is not required to denote a visible or directly visible
+ declaration:
+
+29.b
+ 1. A defining name.
+
+29.c
+ 2. The identifiers or operator_symbol that appear after
+ the reserved word end in a proper_body. Similarly for
+ "end loop", etc.
+
+29.d
+ 3. An attribute_designator.
+
+29.e
+ 4. A pragma identifier.
+
+29.f
+ 5. A pragma_argument_identifier.
+
+29.g
+ 6. An identifier specific to a pragma used in a pragma
+ argument.
+
+29.g.1/3
+ 7. {AI05-0183-1AI05-0183-1} An aspect_mark;
+
+29.g.2/3
+ 8. {AI05-0183-1AI05-0183-1} An identifier specific to an
+ aspect used in an aspect_definition.
+
+29.h
+ The visibility rules have nothing to do with the above cases;
+ the meanings of such things are defined elsewhere. Reserved
+ words are not identifiers; the visibility rules don't apply to
+ them either.
+
+29.i
+ Because of the way we have defined "declaration", it is
+ possible for a usage name to denote a subprogram_body, either
+ within that body, or (for a nonlibrary unit) after it (since
+ the body hides the corresponding declaration, if any). Other
+ bodies do not work that way. Completions of type_declarations
+ and deferred constant declarations do work that way.
+ Accept_statements are never denoted, although the
+ parameter_specifications in their profiles can be.
+
+29.j
+ The scope of a subprogram does not start until after its
+ profile. Thus, the following is legal:
+
+29.k
+ X : constant Integer := 17;
+ ...
+ package P is
+ procedure X(Y : in Integer := X);
+ end P;
+
+29.l
+ The body of the subprogram will probably be illegal, however,
+ since the constant X will be hidden by then.
+
+29.m
+ The rule is different for generic subprograms, since they are
+ not overloadable; the following is illegal:
+
+29.n
+ X : constant Integer := 17;
+ package P is
+ generic
+ Z : Integer := X; -- Illegal!
+ procedure X(Y : in Integer := X); -- Illegal!
+ end P;
+
+29.o
+ The constant X is hidden from direct visibility by the generic
+ declaration.
+
+ _Extensions to Ada 83_
+
+29.p
+ Declarations with the same defining name as that of a
+ subprogram or entry being defined are nevertheless visible
+ within the subprogram specification or entry declaration.
+
+ _Wording Changes from Ada 83_
+
+29.q
+ The term "visible by selection" is no longer defined. We use
+ the terms "directly visible" and "visible" (among other
+ things). There are only two regions of text that are of
+ interest, here: the region in which a declaration is visible,
+ and the region in which it is directly visible.
+
+29.r
+ Visibility is defined only for declarations.
+
+ _Incompatibilities With Ada 95_
+
+29.s/2
+ {AI95-00251-01AI95-00251-01} Added rules to handle the
+ inheritance and overriding of multiple homographs for a single
+ type declaration, in order to support multiple inheritance
+ from interfaces. The new rules are intended to be compatible
+ with the existing rules so that programs that do not use
+ interfaces do not change their legality. However, there is a
+ very rare case where this is not true:
+
+29.t/2
+ generic
+ type T1 is private;
+ type T2 is private;
+ package G is
+ type T is null record;
+ procedure P (X : T; Y : T1);
+ procedure P (X : T; Z : T2);
+ end G;]
+
+29.u/2
+ package I is new G (Integer, Integer); -- Exports homographs of P.
+
+29.v/2
+ type D is new I.T; -- Both Ps are inherited.
+
+29.w/2
+ Obj : D;
+
+29.x/2
+ P (Obj, Z => 10); -- Legal in Ada 95, illegal in Ada 2005.
+
+29.y/2
+ The call to P would resolve in Ada 95 by using the parameter
+ name, while the procedures P would be hidden from all
+ visibility in Ada 2005 and thus would not resolve. This case
+ doesn't seem worth making the rules any more complex than they
+ already are.
+
+29.z/2
+ {AI95-00377-01AI95-00377-01} Amendment Correction: A
+ with_clause is illegal if it would create a homograph of an
+ implicitly declared generic child (see *note 10.1.1::). An
+ Ada 95 compiler could have allowed this, but which unit of the
+ two units involved would be denoted wasn't specified, so any
+ successful use isn't portable. Removing one of the two
+ with_clauses involved will fix the problem.
+
+ _Wording Changes from Ada 95_
+
+29.aa/2
+ {8652/00258652/0025} {AI95-00044-01AI95-00044-01} Corrigendum:
+ Clarified the overriding rules so that "/=" and
+ statement_identifiers are covered.
+
+29.bb/2
+ {8652/00268652/0026} {AI95-00150-01AI95-00150-01} Corrigendum:
+ Clarified that is it never possible for two components with
+ the same name to be visible; any such program is illegal.
+
+29.cc/2
+ {AI95-00195-01AI95-00195-01} {AI95-00408-01AI95-00408-01} The
+ visibility of an attribute_definition_clause is defined so
+ that it can be used by the stream attribute availability rules
+ (see *note 13.13.2::).
+
+29.dd/2
+ {AI95-00217-06AI95-00217-06} The visibility of a limited view
+ of a library package is defined (see *note 10.1.1::).
+
+ _Wording Changes from Ada 2005_
+
+29.ee/3
+ {AI05-0177-1AI05-0177-1} Added wording so that the parameters
+ of an expression_function_declaration (*note 6.8: S0189.) are
+ visible in the expression of the function. (It would be
+ pretty useless without such a rule.)
+
+29.ff/3
+ {AI05-0183-1AI05-0183-1} The visibility of an
+ aspect_specification is defined so that it can be used in
+ various other rules.
+
+* Menu:
+
+* 8.3.1 :: Overriding Indicators
+
+\1f
+File: aarm2012.info, Node: 8.3.1, Up: 8.3
+
+8.3.1 Overriding Indicators
+---------------------------
+
+1/2
+{AI95-00218-03AI95-00218-03} An overriding_indicator is used to declare
+that an operation is intended to override (or not override) an inherited
+operation.
+
+ _Syntax_
+
+2/2
+ {AI95-00218-03AI95-00218-03} overriding_indicator ::=
+ [not] overriding
+
+ _Legality Rules_
+
+3/3
+{AI95-00218-03AI95-00218-03} {AI95-00348-01AI95-00348-01}
+{AI95-00397-01AI95-00397-01} {AI05-0177-1AI05-0177-1} If an
+abstract_subprogram_declaration (*note 3.9.3: S0076.),
+null_procedure_declaration (*note 6.7: S0188.),
+expression_function_declaration (*note 6.8: S0189.), subprogram_body,
+subprogram_body_stub (*note 10.1.3: S0259.),
+subprogram_renaming_declaration (*note 8.5.4: S0203.),
+generic_instantiation (*note 12.3: S0275.) of a subprogram, or
+subprogram_declaration (*note 6.1: S0163.) other than a protected
+subprogram has an overriding_indicator (*note 8.3.1: S0195.), then:
+
+4/2
+ * the operation shall be a primitive operation for some type;
+
+5/2
+ * if the overriding_indicator is overriding, then the operation shall
+ override a homograph at the place of the declaration or body;
+
+5.a/3
+ To be honest: {AI05-0005-1AI05-0005-1} This doesn't require
+ that the overriding happen at precisely the place of the
+ declaration or body; it only requires that the region in which
+ the overriding is known to have happened includes this place.
+ That is, the overriding can happen at or before the place of
+ the declaration or body.
+
+6/2
+ * if the overriding_indicator is not overriding, then the operation
+ shall not override any homograph (at any place).
+
+7/2
+In addition to the places where Legality Rules normally apply, these
+rules also apply in the private part of an instance of a generic unit.
+
+7.a/2
+ Discussion: The overriding and not overriding rules differ
+ slightly. For overriding, we want the indicator to reflect
+ the overriding state at the place of the declaration;
+ otherwise the indicator would be "lying". Whether a homograph
+ is implicitly declared after the declaration (see 7.3.1 to see
+ how this can happen) has no impact on this check. However,
+ not overriding is different; "lying" would happen if a
+ homograph declared later actually is overriding. So, we
+ require this check to take into account later overridings.
+ That can be implemented either by looking ahead, or by
+ rechecking when additional operations are declared.
+
+7.b/2
+ The "no lying" rules are needed to prevent a
+ subprogram_declaration and subprogram_body from having
+ contradictory overriding_indicators.
+
+ NOTES
+
+8/2
+ 8 {AI95-00397-01AI95-00397-01} Rules for overriding_indicators of
+ task and protected entries and of protected subprograms are found
+ in *note 9.5.2:: and *note 9.4::, respectively.
+
+ _Examples_
+
+9/2
+{AI95-00433-01AI95-00433-01} The use of overriding_indicators allows the
+detection of errors at compile-time that otherwise might not be detected
+at all. For instance, we might declare a security queue derived from
+the Queue interface of 3.9.4 as:
+
+10/2
+ type Security_Queue is new Queue with record ...;
+
+11/2
+ overriding
+ procedure Append(Q : in out Security_Queue; Person : in Person_Name);
+
+12/2
+ overriding
+ procedure Remove_First(Q : in out Security_Queue; Person : in Person_Name);
+
+13/2
+ overriding
+ function Cur_Count(Q : in Security_Queue) return Natural;
+
+14/2
+ overriding
+ function Max_Count(Q : in Security_Queue) return Natural;
+
+15/2
+ not overriding
+ procedure Arrest(Q : in out Security_Queue; Person : in Person_Name);
+
+16/2
+The first four subprogram declarations guarantee that these subprograms
+will override the four subprograms inherited from the Queue interface.
+A misspelling in one of these subprograms will be detected by the
+implementation. Conversely, the declaration of Arrest guarantees that
+this is a new operation.
+
+16.a/2
+ Discussion: In this case, the subprograms are abstract, so
+ misspellings will get detected anyway. But for other
+ subprograms (especially when deriving from concrete types),
+ the error might never be detected, and a body other than the
+ one the programmer intended might be executed without warning.
+ Thus our new motto: "Overriding indicators -- don't derive a
+ type without them!"
+
+ _Extensions to Ada 95_
+
+16.b/2
+ {AI95-00218-03AI95-00218-03} Overriding_indicators are new.
+ These let the programmer state her overriding intentions to
+ the compiler; if the compiler disagrees, an error will be
+ produced rather than a hard to find bug.
+
+ _Wording Changes from Ada 2005_
+
+16.c/3
+ {AI95-0177-1AI95-0177-1} Expression functions can have
+ overriding indicators.
+
+\1f
+File: aarm2012.info, Node: 8.4, Next: 8.5, Prev: 8.3, Up: 8
+
+8.4 Use Clauses
+===============
+
+1
+[A use_package_clause achieves direct visibility of declarations that
+appear in the visible part of a package; a use_type_clause achieves
+direct visibility of the primitive operators of a type.]
+
+ _Language Design Principles_
+
+1.a
+ If and only if the visibility rules allow P.A, "use P;" should
+ make A directly visible (barring name conflicts). This means,
+ for example, that child library units, and generic formals of
+ a formal package whose formal_package_actual_part is (<>),
+ should be made visible by a use_clause for the appropriate
+ package.
+
+1.b
+ The rules for use_clauses were carefully constructed to avoid
+ so-called Beaujolais effects, where the addition or removal of
+ a single use_clause, or a single declaration in a "use"d
+ package, would change the meaning of a program from one legal
+ interpretation to another.
+
+ _Syntax_
+
+2
+ use_clause ::= use_package_clause | use_type_clause
+
+3
+ use_package_clause ::= use package_name {, package_name};
+
+4/3
+ {AI05-0150-1AI05-0150-1} use_type_clause ::= use [all] type
+ subtype_mark {, subtype_mark};
+
+ _Legality Rules_
+
+5/2
+{AI95-00217-06AI95-00217-06} A package_name of a use_package_clause
+shall denote a nonlimited view of a package.
+
+5.a
+ Ramification: This includes formal packages.
+
+ _Static Semantics_
+
+6
+For each use_clause, there is a certain region of text called the scope
+of the use_clause. For a use_clause within a context_clause of a
+library_unit_declaration or library_unit_renaming_declaration, the scope
+is the entire declarative region of the declaration. For a use_clause
+within a context_clause of a body, the scope is the entire body [and any
+subunits (including multiply nested subunits). The scope does not
+include context_clauses themselves.]
+
+7
+For a use_clause immediately within a declarative region, the scope is
+the portion of the declarative region starting just after the use_clause
+and extending to the end of the declarative region. However, the scope
+of a use_clause in the private part of a library unit does not include
+the visible part of any public descendant of that library unit.
+
+7.a
+ Reason: The exception echoes the similar exception for
+ "immediate scope (of a declaration)" (see *note 8.2::). It
+ makes use_clauses work like this:
+
+7.b
+ package P is
+ type T is range 1..10;
+ end P;
+
+7.c
+ with P;
+ package Parent is
+ private
+ use P;
+ X : T;
+ end Parent;
+
+7.d
+ package Parent.Child is
+ Y : T; -- Illegal!
+ Z : P.T;
+ private
+ W : T;
+ end Parent.Child;
+
+7.e
+ The declaration of Y is illegal because the scope of the "use
+ P" does not include that place, so T is not directly visible
+ there. The declarations of X, Z, and W are legal.
+
+7.1/2
+{AI95-00217-06AI95-00217-06} A package is named in a use_package_clause
+if it is denoted by a package_name of that clause. A type is named in a
+use_type_clause if it is determined by a subtype_mark of that clause.
+
+8/3
+{AI95-00217-06AI95-00217-06} {AI05-0150-1AI05-0150-1} For each package
+named in a use_package_clause whose scope encloses a place, each
+declaration that occurs immediately within the declarative region of the
+package is potentially use-visible at this place if the declaration is
+visible at this place. For each type T or T'Class named in a
+use_type_clause whose scope encloses a place, the declaration of each
+primitive operator of type T is potentially use-visible at this place if
+its declaration is visible at this place. If a use_type_clause whose
+scope encloses a place includes the reserved word all, then the
+following entities are also potentially use-visible at this place if the
+declaration of the entity is visible at this place:
+
+8.1/3
+ * {AI05-0150-1AI05-0150-1} Each primitive subprogram of T including
+ each enumeration literal (if any);
+
+8.2/3
+ * {AI05-0150-1AI05-0150-1} Each subprogram that is declared
+ immediately within the declarative region in which an ancestor type
+ of T is declared and that operates on a class-wide type that covers
+ T.
+
+8.a/3
+ Ramification: {AI05-0150-1AI05-0150-1} Primitive subprograms
+ whose defining name is an identifier are not made potentially
+ visible by a use_type_clause unless reserved word all is
+ included. A use_type_clause without all is only for
+ operators.
+
+8.b
+ The semantics described here should be similar to the
+ semantics for expanded names given in *note 4.1.3::, "*note
+ 4.1.3:: Selected Components" so as to achieve the effect
+ requested by the "principle of equivalence of use_clauses and
+ selected_components." Thus, child library units and generic
+ formal parameters of a formal package are potentially
+ use-visible when their enclosing package is use'd.
+
+8.c
+ The "visible at that place" part implies that applying a
+ use_clause to a parent unit does not make all of its children
+ use-visible -- only those that have been made visible by a
+ with_clause. It also implies that we don't have to worry
+ about hiding in the definition of "directly visible" -- a
+ declaration cannot be use-visible unless it is visible.
+
+8.d
+ Note that "use type T'Class;" is equivalent to "use type T;",
+ which helps avoid breaking the generic contract model.
+
+8.3/3
+{AI05-0131-1AI05-0131-1} Certain implicit declarations may become
+potentially use-visible in certain contexts as described in *note
+12.6::.
+
+9
+A declaration is use-visible if it is potentially use-visible, except in
+these naming-conflict cases:
+
+10
+ * A potentially use-visible declaration is not use-visible if the
+ place considered is within the immediate scope of a homograph of
+ the declaration.
+
+11
+ * Potentially use-visible declarations that have the same identifier
+ are not use-visible unless each of them is an overloadable
+ declaration.
+
+11.a
+ Ramification: Overloadable declarations don't cancel each
+ other out, even if they are homographs, though if they are not
+ distinguishable by formal parameter names or the presence or
+ absence of default_expressions, any use will be ambiguous. We
+ only mention identifiers here, because declarations named by
+ operator_symbols are always overloadable, and hence never
+ cancel each other. Direct visibility is irrelevant for
+ character_literals.
+
+ _Dynamic Semantics_
+
+12
+The elaboration of a use_clause has no effect.
+
+ _Examples_
+
+13
+Example of a use clause in a context clause:
+
+14
+ with Ada.Calendar; use Ada;
+
+15
+Example of a use type clause:
+
+16
+ use type Rational_Numbers.Rational; -- see *note 7.1::
+ Two_Thirds: Rational_Numbers.Rational := 2/3;
+
+16.a
+ Ramification: In "use X, Y;", Y cannot refer to something made
+ visible by the "use" of X. Thus, it's not (quite) equivalent
+ to "use X; use Y;".
+
+16.b
+ If a given declaration is already immediately visible, then a
+ use_clause that makes it potentially use-visible has no
+ effect. Therefore, a use_type_clause for a type whose
+ declaration appears in a place other than the visible part of
+ a package has no effect; it cannot make a declaration
+ use-visible unless that declaration is already immediately
+ visible.
+
+16.c
+ "Use type S1;" and "use type S2;" are equivalent if S1 and S2
+ are both subtypes of the same type. In particular, "use type
+ S;" and "use type S'Base;" are equivalent.
+
+16.d
+ Reason: We considered adding a rule that prevented several
+ declarations of views of the same entity that all have the
+ same semantics from cancelling each other out. For example,
+ if a (possibly implicit) subprogram_declaration for "+" is
+ potentially use-visible, and a fully conformant renaming of it
+ is also potentially use-visible, then they (annoyingly) cancel
+ each other out; neither one is use-visible. The considered
+ rule would have made just one of them use-visible. We gave up
+ on this idea due to the complexity of the rule. It would have
+ had to account for both overloadable and nonoverloadable
+ renaming_declarations, the case where the rule should apply
+ only to some subset of the declarations with the same defining
+ name, and the case of subtype_declarations (since they are
+ claimed to be sufficient for renaming of subtypes).
+
+ _Extensions to Ada 83_
+
+16.e
+ The use_type_clause is new to Ada 95.
+
+ _Wording Changes from Ada 83_
+
+16.f
+ The phrase "omitting from this set any packages that enclose
+ this place" is no longer necessary to avoid making something
+ visible outside its scope, because we explicitly state that
+ the declaration has to be visible in order to be potentially
+ use-visible.
+
+ _Wording Changes from Ada 95_
+
+16.g/2
+ {AI95-00217-06AI95-00217-06} Limited views of packages are not
+ allowed in use clauses. Defined named in a use clause for use
+ in other limited view rules (see *note 10.1.2::).
+
+ _Extensions to Ada 2005_
+
+16.h/3
+ {AI05-0150-1AI05-0150-1} The use all type version of the
+ use_type_clause is new to Ada 2012. It works similarly to
+ prefixed views.
+
+ _Wording Changes from Ada 2005_
+
+16.i/3
+ {AI05-0131-1AI05-0131-1} Correction: Added wording to allow
+ other declarations to be potentially use-visible, to support
+ corrections to formal subprograms.
+
+\1f
+File: aarm2012.info, Node: 8.5, Next: 8.6, Prev: 8.4, Up: 8
+
+8.5 Renaming Declarations
+=========================
+
+1
+[A renaming_declaration declares another name for an entity, such as an
+object, exception, package, subprogram, entry, or generic unit.
+Alternatively, a subprogram_renaming_declaration can be the completion
+of a previous subprogram_declaration.]
+
+1.a.1/2
+ Glossary entry: A renaming_declaration is a declaration that
+ does not define a new entity, but instead defines a view of an
+ existing entity.
+
+ _Syntax_
+
+2
+ renaming_declaration ::=
+ object_renaming_declaration
+ | exception_renaming_declaration
+ | package_renaming_declaration
+ | subprogram_renaming_declaration
+ | generic_renaming_declaration
+
+ _Dynamic Semantics_
+
+3
+The elaboration of a renaming_declaration evaluates the name that
+follows the reserved word renames and thereby determines the view and
+entity denoted by this name (the renamed view and renamed entity). [A
+name that denotes the renaming_declaration denotes (a new view of) the
+renamed entity.]
+
+ NOTES
+
+4
+ 9 Renaming may be used to resolve name conflicts and to act as a
+ shorthand. Renaming with a different identifier or operator_symbol
+ does not hide the old name; the new name and the old name need not
+ be visible at the same places.
+
+5
+ 10 A task or protected object that is declared by an explicit
+ object_declaration can be renamed as an object. However, a single
+ task or protected object cannot be renamed since the corresponding
+ type is anonymous (meaning it has no nameable subtypes). For
+ similar reasons, an object of an anonymous array or access type
+ cannot be renamed.
+
+6
+ 11 A subtype defined without any additional constraint can be used
+ to achieve the effect of renaming another subtype (including a task
+ or protected subtype) as in
+
+7
+ subtype Mode is Ada.Text_IO.File_Mode;
+
+ _Wording Changes from Ada 83_
+
+7.a
+ The second sentence of RM83-8.5(3), "At any point where a
+ renaming declaration is visible, the identifier, or operator
+ symbol of this declaration denotes the renamed entity." is
+ incorrect. It doesn't say directly visible. Also, such an
+ identifier might resolve to something else.
+
+7.b
+ The verbiage about renamings being legal "only if exactly
+ one...", which appears in RM83-8.5(4) (for objects) and
+ RM83-8.5(7) (for subprograms) is removed, because it follows
+ from the normal rules about overload resolution. For language
+ lawyers, these facts are obvious; for programmers, they are
+ irrelevant, since failing these tests is highly unlikely.
+
+* Menu:
+
+* 8.5.1 :: Object Renaming Declarations
+* 8.5.2 :: Exception Renaming Declarations
+* 8.5.3 :: Package Renaming Declarations
+* 8.5.4 :: Subprogram Renaming Declarations
+* 8.5.5 :: Generic Renaming Declarations
+
+\1f
+File: aarm2012.info, Node: 8.5.1, Next: 8.5.2, Up: 8.5
+
+8.5.1 Object Renaming Declarations
+----------------------------------
+
+1
+[An object_renaming_declaration is used to rename an object.]
+
+ _Syntax_
+
+2/3
+ {AI95-00230-01AI95-00230-01} {AI95-00423-01AI95-00423-01}
+ {AI05-0183-1AI05-0183-1} object_renaming_declaration ::=
+ defining_identifier : [null_exclusion]
+ subtype_mark renames object_name
+ [aspect_specification];
+ | defining_identifier : access_definition renames object_name
+ [aspect_specification];
+
+ _Name Resolution Rules_
+
+3/2
+{AI95-00230-01AI95-00230-01} {AI95-00254-01AI95-00254-01}
+{AI95-00409-01AI95-00409-01} The type of the object_name shall resolve
+to the type determined by the subtype_mark, or in the case where the
+type is defined by an access_definition, to an anonymous access type.
+If the anonymous access type is an access-to-object type, the type of
+the object_name shall have the same designated type as that of the
+access_definition. If the anonymous access type is an
+access-to-subprogram type, the type of the object_name shall have a
+designated profile that is type conformant with that of the
+access_definition.
+
+3.a
+ Reason: A previous version of Ada 9X used the usual "expected
+ type" wording:
+ "The expected type for the object_name is that determined by
+ the subtype_mark."
+ We changed it so that this would be illegal:
+
+3.b
+ X: T;
+ Y: T'Class renames X; -- Illegal!
+
+3.c
+ When the above was legal, it was unclear whether Y was of type
+ T or T'Class. Note that we still allow this:
+
+3.d
+ Z: T'Class := ...;
+ W: T renames F(Z);
+
+3.e
+ where F is a function with a controlling parameter and result.
+ This is admittedly a bit odd.
+
+3.f
+ Note that the matching rule for generic formal parameters of
+ mode in out was changed to keep it consistent with the rule
+ for renaming. That makes the rule different for in vs. in
+ out.
+
+ _Legality Rules_
+
+4
+The renamed entity shall be an object.
+
+4.1/2
+{AI95-00231-01AI95-00231-01} {AI95-00409-01AI95-00409-01} In the case
+where the type is defined by an access_definition, the type of the
+renamed object and the type defined by the access_definition:
+
+4.2/2
+ * {AI95-00231-01AI95-00231-01} {AI95-00409-01AI95-00409-01} shall
+ both be access-to-object types with statically matching designated
+ subtypes and with both or neither being access-to-constant types;
+ or
+
+4.3/2
+ * {AI95-00409-01AI95-00409-01} shall both be access-to-subprogram
+ types with subtype conformant designated profiles.
+
+4.4/2
+{AI95-00423-01AI95-00423-01} For an object_renaming_declaration with a
+null_exclusion or an access_definition that has a null_exclusion:
+
+4.5/2
+ * if the object_name denotes a generic formal object of a generic
+ unit G, and the object_renaming_declaration occurs within the body
+ of G or within the body of a generic unit declared within the
+ declarative region of G, then the declaration of the formal object
+ of G shall have a null_exclusion;
+
+4.6/2
+ * otherwise, the subtype of the object_name shall exclude null. In
+ addition to the places where Legality Rules normally apply (see
+ *note 12.3::), this rule applies also in the private part of an
+ instance of a generic unit.
+
+4.a/2
+ Reason: This rule prevents "lying". Null must never be the
+ value of an object with an explicit null_exclusion. The first
+ bullet is an assume-the-worst rule which prevents trouble in
+ one obscure case:
+
+4.b/2
+ type Acc_I is access Integer;
+ subtype Acc_NN_I is not null Acc_I;
+ Obj : Acc_I := null;
+
+4.c/2
+ generic
+ B : in out Acc_NN_I;
+ package Gen is
+ ...
+ end Gen;
+
+4.d/2
+ package body Gen is
+ D : not null Acc_I renames B;
+ end Gen;
+
+4.e/2
+ package Inst is new Gen (B => Obj);
+
+4.f/2
+ Without the first bullet rule, D would be legal, and contain
+ the value null, because the rule about lying is satisfied for
+ generic matching (Obj matches B; B does not explicitly state
+ not null), Legality Rules are not rechecked in the body of any
+ instance, and the template passes the lying rule as well. The
+ rule is so complex because it has to apply to formals used in
+ bodies of child generics as well as in the bodies of generics.
+
+5/3
+{8652/00178652/0017} {AI95-00184-01AI95-00184-01}
+{AI95-00363-01AI95-00363-01} {AI05-0008-1AI05-0008-1} The renamed entity
+shall not be a subcomponent that depends on discriminants of an object
+whose nominal subtype is unconstrained unless the object is known to be
+constrained. A slice of an array shall not be renamed if this
+restriction disallows renaming of the array. In addition to the places
+where Legality Rules normally apply, these rules apply also in the
+private part of an instance of a generic unit.
+
+5.a
+ Reason: This prevents renaming of subcomponents that might
+ disappear, which might leave dangling references. Similar
+ restrictions exist for the Access attribute.
+
+5.a.1/3
+ {8652/00178652/0017} {AI95-00184-01AI95-00184-01}
+ {AI05-0008-1AI05-0008-1} The "recheck on instantiation"
+ requirement on generics is necessary to avoid renaming of
+ components which could disappear even when the nominal subtype
+ would prevent the problem:
+
+5.a.2/1
+ type T1 (D1 : Boolean) is
+ record
+ case D1 is
+ when False =>
+ C1 : Integer;
+ when True =>
+ null;
+ end case;
+ end record;
+
+5.a.3/1
+ generic
+ type F is new T1;
+ X : in out F;
+ package G is
+ C1_Ren : Integer renames X.C1;
+ end G;
+
+5.a.4/1
+ type T2 (D2 : Boolean := False) is new T1 (D1 => D2);
+
+ Y : T2;
+
+ package I is new G (T2, Y);
+
+ Y := (D1 => True); -- Oops! What happened to I.C1_Ren?
+
+5.a.5/3
+ {AI05-0008-1AI05-0008-1} In addition, the "known to be
+ constrained" rules include assume-the-worst rules for generic
+ bodies partially to prevent such problems.
+
+5.b
+ Implementation Note: Note that if an implementation chooses to
+ deallocate-then-reallocate on assignment_statement (*note 5.2:
+ S0152.)s assigning to unconstrained definite objects, then it
+ cannot represent renamings and access values as simple
+ addresses, because the above rule does not apply to all
+ components of such an object.
+
+5.c
+ Ramification: If it is a generic formal object, then the
+ assume-the-best or assume-the-worst rules are applied as
+ appropriate.
+
+ _Static Semantics_
+
+6/2
+{AI95-00230-01AI95-00230-01} {AI95-00409-01AI95-00409-01} An
+object_renaming_declaration declares a new view [of the renamed object]
+whose properties are identical to those of the renamed view. [Thus, the
+properties of the renamed object are not affected by the
+renaming_declaration. In particular, its value and whether or not it is
+a constant are unaffected; similarly, the null exclusion or constraints
+that apply to an object are not affected by renaming (any constraint
+implied by the subtype_mark or access_definition of the
+object_renaming_declaration is ignored).]
+
+6.a
+ Discussion: Because the constraints are ignored, it is a good
+ idea to use the nominal subtype of the renamed object when
+ writing an object_renaming_declaration.
+
+6.b/2
+ {AI95-00409-01AI95-00409-01} If no null_exclusion is given in
+ the renaming, the object may or may not exclude null. This is
+ similar to the way that constraints need not match, and
+ constant is not specified. The renaming defines a view of the
+ renamed entity, inheriting the original properties.
+
+ _Examples_
+
+7
+Example of renaming an object:
+
+8
+ declare
+ L : Person renames Leftmost_Person; -- see *note 3.10.1::
+ begin
+ L.Age := L.Age + 1;
+ end;
+
+ _Wording Changes from Ada 83_
+
+8.a
+ The phrase "subtype ... as defined in a corresponding object
+ declaration, component declaration, or component subtype
+ indication," from RM83-8.5(5), is incorrect in Ada 95;
+ therefore we removed it. It is incorrect in the case of an
+ object with an indefinite unconstrained nominal subtype.
+
+ _Incompatibilities With Ada 95_
+
+8.b/2
+ {AI95-00363-01AI95-00363-01} Aliased variables are not
+ necessarily constrained in Ada 2005 (see *note 3.6::).
+ Therefore, a subcomponent of an aliased variable may disappear
+ or change shape, and renaming such a subcomponent thus is
+ illegal, while the same operation would have been legal in Ada
+ 95. Note that most allocated objects are still constrained by
+ their initial value (see *note 4.8::), and thus have no change
+ in the legality of renaming for them. For example, using the
+ type T2 of the previous example:
+
+8.c/2
+ AT2 : aliased T2;
+ C1_Ren : Integer renames AT2.C1; -- Illegal in Ada 2005, legal in Ada 95
+ AT2 := (D1 => True); -- Raised Constraint_Error in Ada 95,
+ -- but does not in Ada 2005, so C1_Ren becomes
+ -- invalid when this is assigned.
+
+ _Extensions to Ada 95_
+
+8.d/2
+ {AI95-00230-01AI95-00230-01} {AI95-00231-01AI95-00231-01}
+ {AI95-00254-01AI95-00254-01} {AI95-00409-01AI95-00409-01} A
+ renaming can have an anonymous access type. In that case, the
+ accessibility of the renaming is that of the original object
+ (accessibility is not lost as it is for assignment to a
+ component or stand-alone object).
+
+8.e/2
+ {AI95-00231-01AI95-00231-01} {AI95-00423-01AI95-00423-01} A
+ renaming can have a null_exclusion; if so, the renamed object
+ must also exclude null, so that the null_exclusion does not
+ lie. On the other hand, if the renaming does not have a
+ null_exclusion. it excludes null if the renamed object does.
+
+ _Wording Changes from Ada 95_
+
+8.f/2
+ {8652/00178652/0017} {AI95-00184-01AI95-00184-01} Corrigendum:
+ Fixed to forbid renamings of depends-on-discriminant
+ components if the type might be definite.
+
+ _Incompatibilities With Ada 2005_
+
+8.g/3
+ {AI05-0008-1AI05-0008-1} Correction: Simplified the
+ description of when a discriminant-dependent component is
+ allowed to be renamed -- it's now simply when the object is
+ known to be constrained. This fixes a confusion as to whether
+ a subcomponent of an object that is not certain to be
+ constrained can be renamed. The fix introduces an
+ incompatibility, as the rule did not apply in Ada 95 if the
+ prefix was a constant; but it now applies no matter what kind
+ of object is involved. The incompatibility is not too bad,
+ since most kinds of constants are known to be constrained.
+
+ _Extensions to Ada 2005_
+
+8.h/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in an object_renaming_declaration. This is described
+ in *note 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 8.5.2, Next: 8.5.3, Prev: 8.5.1, Up: 8.5
+
+8.5.2 Exception Renaming Declarations
+-------------------------------------
+
+1
+[An exception_renaming_declaration is used to rename an exception.]
+
+ _Syntax_
+
+2/3
+ {AI05-0183-1AI05-0183-1} exception_renaming_declaration ::=
+ defining_identifier : exception renames exception_name
+ [aspect_specification];
+
+ _Legality Rules_
+
+3
+The renamed entity shall be an exception.
+
+ _Static Semantics_
+
+4
+An exception_renaming_declaration declares a new view [of the renamed
+exception].
+
+ _Examples_
+
+5
+Example of renaming an exception:
+
+6
+ EOF : exception renames Ada.IO_Exceptions.End_Error; -- see *note A.13::
+
+ _Extensions to Ada 2005_
+
+6.a/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in an exception_renaming_declaration. This is
+ described in *note 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 8.5.3, Next: 8.5.4, Prev: 8.5.2, Up: 8.5
+
+8.5.3 Package Renaming Declarations
+-----------------------------------
+
+1
+[A package_renaming_declaration is used to rename a package.]
+
+ _Syntax_
+
+2/3
+ {AI05-0183-1AI05-0183-1} package_renaming_declaration ::= package
+ defining_program_unit_name renames package_name
+ [aspect_specification];
+
+ _Legality Rules_
+
+3
+The renamed entity shall be a package.
+
+3.1/2
+{AI95-00217-06AI95-00217-06} {AI95-00412-01AI95-00412-01} If the
+package_name of a package_renaming_declaration denotes a limited view of
+a package P, then a name that denotes the package_renaming_declaration
+shall occur only within the immediate scope of the renaming or the scope
+of a with_clause that mentions the package P or, if P is a nested
+package, the innermost library package enclosing P.
+
+3.a.1/2
+ Discussion: The use of a renaming that designates a limited
+ view is restricted to locations where we know whether the view
+ is limited or nonlimited (based on a with_clause). We don't
+ want to make an implicit limited view, as those are not
+ transitive like a regular view. Implementations should be
+ able to see all limited views needed based on the
+ context_clause.
+
+ _Static Semantics_
+
+4
+A package_renaming_declaration declares a new view [of the renamed
+package].
+
+4.1/2
+{AI95-00412-01AI95-00412-01} [At places where the declaration of the
+limited view of the renamed package is visible, a name that denotes the
+package_renaming_declaration denotes a limited view of the package (see
+*note 10.1.1::).]
+
+4.a.1/2
+ Proof: This rule is found in *note 8.3::, "*note 8.3::
+ Visibility".
+
+ _Examples_
+
+5
+Example of renaming a package:
+
+6
+ package TM renames Table_Manager;
+
+ _Wording Changes from Ada 95_
+
+6.a/2
+ {AI95-00217-06AI95-00217-06} {AI95-00412-01AI95-00412-01} Uses
+ of renamed limited views of packages can only be used within
+ the scope of a with_clause for the renamed package.
+
+ _Extensions to Ada 2005_
+
+6.b/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a package_renaming_declaration. This is described
+ in *note 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 8.5.4, Next: 8.5.5, Prev: 8.5.3, Up: 8.5
+
+8.5.4 Subprogram Renaming Declarations
+--------------------------------------
+
+1/3
+{AI05-0299-1AI05-0299-1} A subprogram_renaming_declaration can serve as
+the completion of a subprogram_declaration; such a renaming_declaration
+is called a renaming-as-body. A subprogram_renaming_declaration that is
+not a completion is called a renaming-as-declaration[, and is used to
+rename a subprogram (possibly an enumeration literal) or an entry].
+
+1.a/3
+ Ramification: {AI05-0299-1AI05-0299-1} A renaming-as-body is a
+ declaration, as defined in Clause *note 3::.
+
+ _Syntax_
+
+2/3
+ {AI95-00218-03AI95-00218-03} {AI05-0183-1AI05-0183-1}
+ subprogram_renaming_declaration ::=
+ [overriding_indicator]
+ subprogram_specification renames callable_entity_name
+ [aspect_specification];
+
+ _Name Resolution Rules_
+
+3
+The expected profile for the callable_entity_name is the profile given
+in the subprogram_specification.
+
+ _Legality Rules_
+
+4/3
+{AI05-0239-1AI05-0239-1} The profile of a renaming-as-declaration shall
+be mode conformant, with that of the renamed callable entity.
+
+4.1/2
+{AI95-00423-01AI95-00423-01} For a parameter or result subtype of the
+subprogram_specification that has an explicit null_exclusion:
+
+4.2/2
+ * if the callable_entity_name denotes a generic formal subprogram of
+ a generic unit G, and the subprogram_renaming_declaration occurs
+ within the body of a generic unit G or within the body of a generic
+ unit declared within the declarative region of the generic unit G,
+ then the corresponding parameter or result subtype of the formal
+ subprogram of G shall have a null_exclusion;
+
+4.3/2
+ * otherwise, the subtype of the corresponding parameter or result
+ type of the renamed callable entity shall exclude null. In
+ addition to the places where Legality Rules normally apply (see
+ *note 12.3::), this rule applies also in the private part of an
+ instance of a generic unit.
+
+4.a/2
+ Reason: This rule prevents "lying". Null must never be the
+ value of a parameter or result with an explicit
+ null_exclusion. The first bullet is an assume-the-worst rule
+ which prevents trouble in generic bodies (including bodies of
+ child units) when the formal subtype excludes null implicitly.
+
+5/3
+{8652/00278652/0027} {8652/00288652/0028} {AI95-00135-01AI95-00135-01}
+{AI95-00145-01AI95-00145-01} {AI05-0239-1AI05-0239-1} The profile of a
+renaming-as-body shall conform fully to that of the declaration it
+completes. If the renaming-as-body completes that declaration before
+the subprogram it declares is frozen, the profile shall be mode
+conformant with that of the renamed callable entity and the subprogram
+it declares takes its convention from the renamed subprogram; otherwise,
+the profile shall be subtype conformant with that of the renamed
+callable entity and the convention of the renamed subprogram shall not
+be Intrinsic. A renaming-as-body is illegal if the declaration occurs
+before the subprogram whose declaration it completes is frozen, and the
+renaming renames the subprogram itself, through one or more subprogram
+renaming declarations, none of whose subprograms has been frozen.
+
+5.a/1
+ Reason: The otherwise part of the second sentence is to allow
+ an implementation of a renaming-as-body as a single jump
+ instruction to the target subprogram. Among other things,
+ this prevents a subprogram from being completed with a
+ renaming of an entry. (In most cases, the target of the jump
+ can be filled in at link time. In some cases, such as a
+ renaming of a name like "A(I).all", an indirect jump is
+ needed. Note that the name is evaluated at renaming time, not
+ at call time.)
+
+5.a.1/1
+ {8652/00288652/0028} {AI95-00145-01AI95-00145-01} The first
+ part of the second sentence is intended to allow
+ renaming-as-body of predefined operators before the
+ subprogram_declaration is frozen. For some types (such as
+ integer types), the parameter type for operators is the base
+ type, and it would be very strange for
+ function Equal (A, B : in T) return Boolean;
+ function Equal (A, B : in T) return Boolean renames "=";
+ to be illegal. (Note that predefined operators cannot be
+ renamed this way after the subprogram_declaration is frozen,
+ as they have convention Intrinsic.)
+
+5.b/1
+ The first sentence is the normal rule for completions of
+ subprogram_declarations.
+
+5.c
+ Ramification: An entry_declaration, unlike a
+ subprogram_declaration, cannot be completed with a
+ renaming_declaration (*note 8.5: S0199.). Nor can a
+ generic_subprogram_declaration (*note 12.1: S0271.).
+
+5.d
+ The syntax rules prevent a protected subprogram declaration
+ from being completed by a renaming. This is fortunate,
+ because it allows us to avoid worrying about whether the
+ implicit protected object parameter of a protected operation
+ is involved in the conformance rules.
+
+5.d.1/1
+ Reason: {8652/00278652/0027} {AI95-00135-01AI95-00135-01}
+ Circular renames before freezing is illegal, as the compiler
+ would not be able to determine the convention of the
+ subprogram. Other circular renames are handled below; see
+ Bounded (Run-Time) Errors.
+
+5.1/2
+{AI95-00228-01AI95-00228-01} The callable_entity_name of a renaming
+shall not denote a subprogram that requires overriding (see *note
+3.9.3::).
+
+5.d.2/2
+ Reason: {AI95-00228-01AI95-00228-01} Such a rename cannot be
+ of the inherited subprogram (which requires overriding because
+ it cannot be called), and thus cannot squirrel away a
+ subprogram (see below). That would be confusing, so we make
+ it illegal. The renaming is allowed after the overriding, as
+ then the name will denote the overriding subprogram, not the
+ inherited one.
+
+5.2/2
+{AI95-00228-01AI95-00228-01} The callable_entity_name of a
+renaming-as-body shall not denote an abstract subprogram.
+
+5.d.3/2
+ Reason: {AI95-00228-01AI95-00228-01} Such a subprogram has no
+ body, so it hardly can replace one in the program.
+
+6
+A name that denotes a formal parameter of the subprogram_specification
+is not allowed within the callable_entity_name.
+
+6.a
+ Reason: This is to prevent things like this:
+
+6.b
+ function F(X : Integer) return Integer renames Table(X).all;
+
+6.c
+ A similar rule in *note 6.1:: forbids things like this:
+
+6.d
+ function F(X : Integer; Y : Integer := X) return Integer;
+
+ _Static Semantics_
+
+7
+A renaming-as-declaration declares a new view of the renamed entity.
+The profile of this new view takes its subtypes, parameter modes, and
+calling convention from the original profile of the callable entity,
+while taking the formal parameter names and default_expressions from the
+profile given in the subprogram_renaming_declaration. The new view is a
+function or procedure, never an entry.
+
+7.a
+ To be honest: When renaming an entry as a procedure, the
+ compile-time rules apply as if the new view is a procedure,
+ but the run-time semantics of a call are that of an entry
+ call.
+
+7.b
+ Ramification: For example, it is illegal for the
+ entry_call_statement of a timed_entry_call to call the new
+ view. But what looks like a procedure call will do things
+ like barrier waiting.
+
+7.b.1/3
+ {8652/01058652/0105} {AI95-00211-01AI95-00211-01}
+ {AI95-00228-01AI95-00228-01} {AI05-0095-1AI05-0095-1} All
+ properties of the renamed entity are inherited by the new view
+ unless otherwise stated by this International Standard. In
+ particular, if the renamed entity is abstract, the new view
+ also is abstract. Similarly, if the renamed entity is not a
+ program unit, then neither is the renaming. (Implicitly
+ declared subprograms are not program units, see *note 10.1::).
+
+ _Dynamic Semantics_
+
+7.1/1
+{8652/00148652/0014} {AI95-00064-01AI95-00064-01} For a call to a
+subprogram whose body is given as a renaming-as-body, the execution of
+the renaming-as-body is equivalent to the execution of a subprogram_body
+that simply calls the renamed subprogram with its formal parameters as
+the actual parameters and, if it is a function, returns the value of the
+call.
+
+7.b.2/1
+ Ramification: This implies that the subprogram completed by
+ the renaming-as-body has its own elaboration check.
+
+8/3
+{AI05-0123-1AI05-0123-1} For a call on a renaming of a dispatching
+subprogram that is overridden, if the overriding occurred before the
+renaming, then the body executed is that of the overriding declaration,
+even if the overriding declaration is not visible at the place of the
+renaming; otherwise, the inherited or predefined subprogram is called.
+A corresponding rule applies to a call on a renaming of a predefined
+equality operator for an untagged record type.
+
+8.a
+ Discussion: Note that whether or not the renaming is itself
+ primitive has nothing to do with the renamed subprogram.
+
+8.b/3
+ {AI05-0123-1AI05-0123-1} Note that the above rule is only for
+ tagged types and equality of untagged record types.
+
+8.c
+ Consider the following example:
+
+8.d
+ package P is
+ type T is tagged null record;
+ function Predefined_Equal(X, Y : T) return Boolean renames "=";
+ private
+ function "="(X, Y : T) return Boolean; -- Override predefined "=".
+ end P;
+
+8.e
+ with P; use P;
+ package Q is
+ function User_Defined_Equal(X, Y : T) return Boolean renames P."=";
+ end Q;
+
+8.f
+ A call on Predefined_Equal will execute the predefined
+ equality operator of T, whereas a call on User_Defined_Equal
+ will execute the body of the overriding declaration in the
+ private part of P.
+
+8.g
+ Thus a renaming allows one to squirrel away a copy of an
+ inherited or predefined subprogram before later overriding it.
+
+ _Bounded (Run-Time) Errors_
+
+8.1/1
+{8652/00278652/0027} {AI95-00135-01AI95-00135-01} If a subprogram
+directly or indirectly renames itself, then it is a bounded error to
+call that subprogram. Possible consequences are that Program_Error or
+Storage_Error is raised, or that the call results in infinite recursion.
+
+8.g.1/1
+ Reason: {8652/00278652/0027} {AI95-00135-01AI95-00135-01} This
+ has to be a bounded error, as it is possible for a
+ renaming-as-body appearing in a package body to cause this
+ problem. Thus it is not possible in general to detect this
+ problem at compile time.
+
+ NOTES
+
+9
+ 12 A procedure can only be renamed as a procedure. A function
+ whose defining_designator is either an identifier or an
+ operator_symbol can be renamed with either an identifier or an
+ operator_symbol; for renaming as an operator, the subprogram
+ specification given in the renaming_declaration is subject to the
+ rules given in *note 6.6:: for operator declarations. Enumeration
+ literals can be renamed as functions; similarly,
+ attribute_references that denote functions (such as references to
+ Succ and Pred) can be renamed as functions. An entry can only be
+ renamed as a procedure; the new name is only allowed to appear in
+ contexts that allow a procedure name. An entry of a family can be
+ renamed, but an entry family cannot be renamed as a whole.
+
+10
+ 13 The operators of the root numeric types cannot be renamed
+ because the types in the profile are anonymous, so the
+ corresponding specifications cannot be written; the same holds for
+ certain attributes, such as Pos.
+
+11
+ 14 Calls with the new name of a renamed entry are
+ procedure_call_statements and are not allowed at places where the
+ syntax requires an entry_call_statement in conditional_ and
+ timed_entry_calls, nor in an asynchronous_select; similarly, the
+ Count attribute is not available for the new name.
+
+12
+ 15 The primitiveness of a renaming-as-declaration is determined by
+ its profile, and by where it occurs, as for any declaration of (a
+ view of) a subprogram; primitiveness is not determined by the
+ renamed view. In order to perform a dispatching call, the
+ subprogram name has to denote a primitive subprogram, not a
+ nonprimitive renaming of a primitive subprogram.
+
+12.a
+ Reason: A subprogram_renaming_declaration could more properly
+ be called renaming_as_subprogram_declaration, since you're
+ renaming something as a subprogram, but you're not necessarily
+ renaming a subprogram. But that's too much of a mouthful.
+ Or, alternatively, we could call it a
+ callable_entity_renaming_declaration, but that's even worse.
+ Not only is it a mouthful, it emphasizes the entity being
+ renamed, rather than the new view, which we think is a bad
+ idea. We'll live with the oddity.
+
+ _Examples_
+
+13
+Examples of subprogram renaming declarations:
+
+14
+ procedure My_Write(C : in Character) renames Pool(K).Write; -- see *note 4.1.3::
+
+15
+ function Real_Plus(Left, Right : Real ) return Real renames "+";
+ function Int_Plus (Left, Right : Integer) return Integer renames "+";
+
+16
+ function Rouge return Color renames Red; -- see *note 3.5.1::
+ function Rot return Color renames Red;
+ function Rosso return Color renames Rouge;
+
+17
+ function Next(X : Color) return Color renames Color'Succ; -- see *note 3.5.1::
+
+18
+Example of a subprogram renaming declaration with new parameter names:
+
+19
+ function "*" (X,Y : Vector) return Real renames Dot_Product; -- see *note 6.1::
+
+20
+Example of a subprogram renaming declaration with a new default
+expression:
+
+21
+ function Minimum(L : Link := Head) return Cell renames Min_Cell; -- see *note 6.1::
+
+ _Extensions to Ada 95_
+
+21.a/2
+ {8652/00288652/0028} {AI95-00145-01AI95-00145-01} Corrigendum:
+ Allowed a renaming-as-body to be just mode conformant with the
+ specification if the subprogram is not yet frozen.
+
+21.b/2
+ {AI95-00218-03AI95-00218-03} Overriding_indicator (see *note
+ 8.3.1::) is optionally added to subprogram renamings.
+
+ _Wording Changes from Ada 95_
+
+21.c/2
+ {8652/00148652/0014} {AI95-00064-01AI95-00064-01} Corrigendum:
+ Described the semantics of renaming-as-body, so that the
+ location of elaboration checks is clear.
+
+21.d/2
+ {8652/00278652/0027} {AI95-00135-01AI95-00135-01} Corrigendum:
+ Clarified that circular renaming-as-body is illegal (if it can
+ be detected in time) or a bounded error.
+
+21.e/2
+ {AI95-00228-01AI95-00228-01} Amendment Correction: Clarified
+ that renaming a shall-be-overridden subprogram is illegal, as
+ well as renaming-as-body an abstract subprogram.
+
+21.f/2
+ {AI95-00423-01AI95-00423-01} Added matching rules for
+ null_exclusions.
+
+ _Inconsistencies With Ada 2005_
+
+21.f.1/3
+ {AI05-0123-1AI05-0123-1} Renaming of user-defined untagged
+ record equality is now defined to call the overridden body so
+ long as the overriding occurred before the renames. This
+ could change the body called in unusual cases; the change is
+ necessary to preserve the principle that the body called for
+ an explicit call to "=" (via a renames in this case) is the
+ same as the one inherited for a derived type and used in
+ generics. Note that any renamings before the overriding will
+ be unchanged. Any differences caused by the change will be
+ rare and most likely will fix a bug.
+
+ _Extensions to Ada 2005_
+
+21.g/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a subprogram_renaming_declaration. This is
+ described in *note 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 8.5.5, Prev: 8.5.4, Up: 8.5
+
+8.5.5 Generic Renaming Declarations
+-----------------------------------
+
+1
+[A generic_renaming_declaration is used to rename a generic unit.]
+
+ _Syntax_
+
+2/3
+ {AI05-0183-1AI05-0183-1} generic_renaming_declaration ::=
+ generic package
+ defining_program_unit_name renames generic_package_name
+ [aspect_specification];
+ | generic procedure
+ defining_program_unit_name renames generic_procedure_name
+ [aspect_specification];
+ | generic function
+ defining_program_unit_name renames generic_function_name
+ [aspect_specification];
+
+ _Legality Rules_
+
+3
+The renamed entity shall be a generic unit of the corresponding kind.
+
+ _Static Semantics_
+
+4
+A generic_renaming_declaration declares a new view [of the renamed
+generic unit].
+
+ NOTES
+
+5
+ 16 Although the properties of the new view are the same as those
+ of the renamed view, the place where the
+ generic_renaming_declaration occurs may affect the legality of
+ subsequent renamings and instantiations that denote the
+ generic_renaming_declaration, in particular if the renamed generic
+ unit is a library unit (see *note 10.1.1::).
+
+ _Examples_
+
+6
+Example of renaming a generic unit:
+
+7
+ generic package Enum_IO renames Ada.Text_IO.Enumeration_IO; -- see *note A.10.10::
+
+ _Extensions to Ada 83_
+
+7.a
+ Renaming of generic units is new to Ada 95. It is
+ particularly important for renaming child library units that
+ are generic units. For example, it might be used to rename
+ Numerics.Generic_Elementary_Functions as simply
+ Generic_Elementary_Functions, to match the name for the
+ corresponding Ada-83-based package.
+
+ _Wording Changes from Ada 83_
+
+7.b
+ The information in RM83-8.6, "The Package Standard," has been
+ updated for the child unit feature, and moved to *note Annex
+ A::, except for the definition of "predefined type," which has
+ been moved to *note 3.2.1::.
+
+ _Extensions to Ada 2005_
+
+7.c/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a generic_renaming_declaration. This is described
+ in *note 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 8.6, Prev: 8.5, Up: 8
+
+8.6 The Context of Overload Resolution
+======================================
+
+1/3
+{AI05-0299-1AI05-0299-1} [ Because declarations can be overloaded, it is
+possible for an occurrence of a usage name to have more than one
+possible interpretation; in most cases, ambiguity is disallowed. This
+subclause describes how the possible interpretations resolve to the
+actual interpretation.
+
+2
+Certain rules of the language (the Name Resolution Rules) are considered
+"overloading rules". If a possible interpretation violates an
+overloading rule, it is assumed not to be the intended interpretation;
+some other possible interpretation is assumed to be the actual
+interpretation. On the other hand, violations of nonoverloading rules
+do not affect which interpretation is chosen; instead, they cause the
+construct to be illegal. To be legal, there usually has to be exactly
+one acceptable interpretation of a construct that is a "complete
+context", not counting any nested complete contexts.
+
+3
+The syntax rules of the language and the visibility rules given in *note
+8.3:: determine the possible interpretations. Most type checking rules
+(rules that require a particular type, or a particular class of types,
+for example) are overloading rules. Various rules for the matching of
+formal and actual parameters are overloading rules.]
+
+ _Language Design Principles_
+
+3.a
+ The type resolution rules are intended to minimize the need
+ for implicit declarations and preference rules associated with
+ implicit conversion and dispatching operations.
+
+ _Name Resolution Rules_
+
+4
+[Overload resolution is applied separately to each complete context, not
+counting inner complete contexts.] Each of the following constructs is
+a complete context:
+
+5
+ * A context_item.
+
+6
+ * A declarative_item or declaration.
+
+6.a
+ Ramification: A loop_parameter_specification is a declaration,
+ and hence a complete context.
+
+7
+ * A statement.
+
+8
+ * A pragma_argument_association.
+
+8.a
+ Reason: We would make it the whole pragma, except that certain
+ pragma arguments are allowed to be ambiguous, and ambiguity
+ applies to a complete context.
+
+9
+ * The expression of a case_statement.
+
+9.a
+ Ramification: This means that the expression is resolved
+ without looking at the choices.
+
+10
+An (overall) interpretation of a complete context embodies its meaning,
+and includes the following information about the constituents of the
+complete context, not including constituents of inner complete contexts:
+
+11
+ * for each constituent of the complete context, to which syntactic
+ categories it belongs, and by which syntax rules; and
+
+11.a
+ Ramification: Syntactic categories is plural here, because
+ there are lots of trivial productions -- an expression might
+ also be all of the following, in this order: identifier, name,
+ primary, factor, term, simple_expression, and relation.
+ Basically, we're trying to capture all the information in the
+ parse tree here, without using compiler-writer's jargon like
+ "parse tree".
+
+12
+ * for each usage name, which declaration it denotes (and, therefore,
+ which view and which entity it denotes); and
+
+12.a/2
+ Ramification: {AI95-00382-01AI95-00382-01} In most cases, a
+ usage name denotes the view declared by the denoted
+ declaration. However, in certain cases, a usage name that
+ denotes a declaration and appears inside the declarative
+ region of that same declaration, denotes the current instance
+ of the declaration. For example, within a task_body other
+ than in an access_definition, a usage name that denotes the
+ task_type_declaration denotes the object containing the
+ currently executing task, and not the task type declared by
+ the declaration.
+
+13
+ * for a complete context that is a declarative_item, whether or not
+ it is a completion of a declaration, and (if so) which declaration
+ it completes.
+
+13.a
+ Ramification: Unfortunately, we are not confident that the
+ above list is complete. We'll have to live with that.
+
+13.b
+ To be honest: For "possible" interpretations, the above
+ information is tentative.
+
+13.c
+ Discussion: A possible interpretation (an input to overload
+ resolution) contains information about what a usage name might
+ denote, but what it actually does denote requires overload
+ resolution to determine. Hence the term "tentative" is needed
+ for possible interpretations; otherwise, the definition would
+ be circular.
+
+14
+A possible interpretation is one that obeys the syntax rules and the
+visibility rules. An acceptable interpretation is a possible
+interpretation that obeys the overloading rules[, that is, those rules
+that specify an expected type or expected profile, or specify how a
+construct shall resolve or be interpreted.]
+
+14.a
+ To be honest: One rule that falls into this category, but does
+ not use the above-mentioned magic words, is the rule about
+ numbers of parameter associations in a call (see *note 6.4::).
+
+14.b
+ Ramification: The Name Resolution Rules are the ones that
+ appear under the Name Resolution Rules heading. Some Syntax
+ Rules are written in English, instead of BNF. No rule is a
+ Syntax Rule or Name Resolution Rule unless it appears under
+ the appropriate heading.
+
+15
+The interpretation of a constituent of a complete context is determined
+from the overall interpretation of the complete context as a whole.
+[Thus, for example, "interpreted as a function_call," means that the
+construct's interpretation says that it belongs to the syntactic
+category function_call.]
+
+16
+[Each occurrence of] a usage name denotes the declaration determined by
+its interpretation. It also denotes the view declared by its denoted
+declaration, except in the following cases:
+
+16.a
+ Ramification: As explained below, a pragma argument is allowed
+ to be ambiguous, so it can denote several declarations, and
+ all of the views declared by those declarations.
+
+17/3
+ * {AI95-00382-01AI95-00382-01} {AI05-0287-1AI05-0287-1} If a usage
+ name appears within the declarative region of a type_declaration
+ and denotes that same type_declaration, then it denotes the current
+ instance of the type (rather than the type itself); the current
+ instance of a type is the object or value of the type that is
+ associated with the execution that evaluates the usage name.
+ Similarly, if a usage name appears within the declarative region of
+ a subtype_declaration and denotes that same subtype_declaration,
+ then it denotes the current instance of the subtype. These rules
+ do not apply if the usage name appears within the subtype_mark of
+ an access_definition for an access-to-object type, or within the
+ subtype of a parameter or result of an access-to-subprogram type.
+
+17.a/2
+ Reason: {AI95-00382-01AI95-00382-01} This is needed, for
+ example, for references to the Access attribute from within
+ the type_declaration. Also, within a task_body or
+ protected_body, we need to be able to denote the current task
+ or protected object. (For a single_task_declaration or
+ single_protected_declaration, the rule about current instances
+ is not needed.) We exclude anonymous access types so that
+ they can be used to create self-referencing types in the
+ natural manner (otherwise such types would be illegal).
+
+17.b/2
+ Discussion: {AI95-00382-01AI95-00382-01} The phrase "within
+ the subtype_mark" in the "this rule does not apply" part is
+ intended to cover a case like access T'Class appearing within
+ the declarative region of T: here T denotes the type, not the
+ current instance.
+
+18
+ * If a usage name appears within the declarative region of a
+ generic_declaration (but not within its generic_formal_part) and it
+ denotes that same generic_declaration, then it denotes the current
+ instance of the generic unit (rather than the generic unit itself).
+ See also *note 12.3::.
+
+18.a
+ To be honest: The current instance of a generic unit is the
+ instance created by whichever generic_instantiation is of
+ interest at any given time.
+
+18.b
+ Ramification: Within a generic_formal_part, a name that
+ denotes the generic_declaration denotes the generic unit,
+ which implies that it is not overloadable.
+
+19
+A usage name that denotes a view also denotes the entity of that view.
+
+19.a
+ Ramification: Usually, a usage name denotes only one
+ declaration, and therefore one view and one entity.
+
+20/2
+{AI95-00231-01AI95-00231-01} The expected type for a given expression,
+name, or other construct determines, according to the type resolution
+rules given below, the types considered for the construct during
+overload resolution. [ The type resolution rules provide support for
+class-wide programming, universal literals, dispatching operations, and
+anonymous access types:]
+
+20.a
+ Ramification: Expected types are defined throughout the RM95.
+ The most important definition is that, for a subprogram, the
+ expected type for the actual parameter is the type of the
+ formal parameter.
+
+20.b
+ The type resolution rules are trivial unless either the actual
+ or expected type is universal, class-wide, or of an anonymous
+ access type.
+
+21
+ * If a construct is expected to be of any type in a class of types,
+ or of the universal or class-wide type for a class, then the type
+ of the construct shall resolve to a type in that class or to a
+ universal type that covers the class.
+
+21.a
+ Ramification: This matching rule handles (among other things)
+ cases like the Val attribute, which denotes a function that
+ takes a parameter of type universal_integer.
+
+21.b/1
+ The last part of the rule, "or to a universal type that covers
+ the class" implies that if the expected type for an expression
+ is universal_fixed, then an expression whose type is
+ universal_real (such as a real literal) is OK.
+
+22
+ * If the expected type for a construct is a specific type T, then the
+ type of the construct shall resolve either to T, or:
+
+22.a
+ Ramification: This rule is not intended to create a preference
+ for the specific type -- such a preference would cause
+ Beaujolais effects.
+
+23
+ * to T'Class; or
+
+23.a
+ Ramification: This will only be legal as part of a call on a
+ dispatching operation; see *note 3.9.2::, "*note 3.9.2::
+ Dispatching Operations of Tagged Types". Note that that rule
+ is not a Name Resolution Rule.
+
+24
+ * to a universal type that covers T; or
+
+25/2
+ * {AI95-00230-01AI95-00230-01} {AI95-00231-01AI95-00231-01}
+ {AI95-00254-01AI95-00254-01} {AI95-00409-01AI95-00409-01}
+ when T is a specific anonymous access-to-object type (see
+ *note 3.10::) with designated type D, to an
+ access-to-object type whose designated type is D'Class or
+ is covered by D; or
+
+25.a/2
+ This paragraph was deleted.{AI95-00409-01AI95-00409-01}
+
+25.b
+ Ramification: The case where the actual is access-to-D'Class
+ will only be legal as part of a call on a dispatching
+ operation; see *note 3.9.2::, "*note 3.9.2:: Dispatching
+ Operations of Tagged Types". Note that that rule is not a
+ Name Resolution Rule.
+
+25.1/3
+ * {AI05-0149-1AI05-0149-1} when T is a named general
+ access-to-object type (see *note 3.10::) with designated
+ type D, to an anonymous access-to-object type whose
+ designated type covers or is covered by D; or
+
+25.2/3
+ * {AI95-00254-01AI95-00254-01} {AI95-00409-01AI95-00409-01}
+ {AI05-0239-1AI05-0239-1} when T is an anonymous
+ access-to-subprogram type (see *note 3.10::), to an
+ access-to-subprogram type whose designated profile is
+ type conformant with that of T.
+
+26
+In certain contexts, [such as in a subprogram_renaming_declaration,] the
+Name Resolution Rules define an expected profile for a given name; in
+such cases, the name shall resolve to the name of a callable entity
+whose profile is type conformant with the expected profile.
+
+26.a/3
+ Ramification: {AI05-0239-1AI05-0239-1} The parameter and
+ result subtypes are not used in overload resolution. Only
+ type conformance of profiles is considered during overload
+ resolution. Legality rules generally require at least mode
+ conformance in addition, but those rules are not used in
+ overload resolution.
+
+ _Legality Rules_
+
+27/2
+{AI95-00332-01AI95-00332-01} When a construct is one that requires that
+its expected type be a single type in a given class, the type of the
+construct shall be determinable solely from the context in which the
+construct appears, excluding the construct itself, but using the
+requirement that it be in the given class. Furthermore, the context
+shall not be one that expects any type in some class that contains types
+of the given class; in particular, the construct shall not be the
+operand of a type_conversion.
+
+27.a/2
+ Ramification: {AI95-00230-01AI95-00230-01} For example, the
+ expected type for a string literal is required to be a single
+ string type. But the expected type for the operand of a
+ type_conversion is any type. Therefore, a string literal is
+ not allowed as the operand of a type_conversion. This is true
+ even if there is only one string type in scope (which is never
+ the case). The reason for these rules is so that the compiler
+ will not have to search "everywhere" to see if there is
+ exactly one type in a class in scope.
+
+27.b/2
+ Discussion: {AI95-00332-01AI95-00332-01} The first sentence is
+ carefully worded so that it only mentions "expected type" as
+ part of identifying the interesting case, but doesn't require
+ that the context actually provide such an expected type. This
+ allows such constructs to be used inside of constructs that
+ don't provide an expected type (like qualified expressions and
+ renames). Otherwise, such constructs wouldn't allow
+ aggregates, 'Access, and so on.
+
+27.1/3
+{AI05-0102-1AI05-0102-1} {AI05-0149-1AI05-0149-1}
+{AI05-0299-1AI05-0299-1} Other than for the simple_expression of a
+membership test, if the expected type for a name or expression is not
+the same as the actual type of the name or expression, the actual type
+shall be convertible to the expected type (see *note 4.6::); further, if
+the expected type is a named access-to-object type with designated type
+D1 and the actual type is an anonymous access-to-object type with
+designated type D2, then D1 shall cover D2, and the name or expression
+shall denote a view with an accessibility level for which the statically
+deeper relationship applies[; in particular it shall not denote an
+access parameter nor a stand-alone access object].
+
+27.c/3
+ Reason: This rule prevents an implicit conversion that would
+ be illegal if it was an explicit conversion. For instance,
+ this prevents assigning an access-to-constant value into a
+ stand-alone anonymous access-to-variable object. It also
+ covers convertibility of the designated type and accessibility
+ checks.
+
+27.d/3
+ The rule also minimizes cases of implicit conversions when the
+ tag check or the accessibility check might fail. We word it
+ this way because access discriminants should also be
+ disallowed if their enclosing object is designated by an
+ access parameter.
+
+27.e/3
+ Ramification: This rule does not apply to expressions that
+ don't have expected types (such as the operand of a qualified
+ expression or the expression of a renames). We don't need a
+ rule like this in those cases, as the type needs to be the
+ same; there is no implicit conversion.
+
+28
+A complete context shall have at least one acceptable interpretation; if
+there is exactly one, then that one is chosen.
+
+28.a
+ Ramification: This, and the rule below about ambiguity, are
+ the ones that suck in all the Syntax Rules and Name Resolution
+ Rules as compile-time rules. Note that this and the ambiguity
+ rule have to be Legality Rules.
+
+29
+There is a preference for the primitive operators (and ranges) of the
+root numeric types root_integer and root_real. In particular, if two
+acceptable interpretations of a constituent of a complete context differ
+only in that one is for a primitive operator (or range) of the type
+root_integer or root_real, and the other is not, the interpretation
+using the primitive operator (or range) of the root numeric type is
+preferred.
+
+29.a
+ Reason: The reason for this preference is so that expressions
+ involving literals and named numbers can be unambiguous. For
+ example, without the preference rule, the following would be
+ ambiguous:
+
+29.b/1
+ N : constant := 123;
+ if N > 100 then -- Preference for root_integer ">" operator.
+ ...
+ end if;
+
+29.1/3
+{AI05-0149-1AI05-0149-1} Similarly, there is a preference for the
+equality operators of the universal_access type (see *note 4.5.2::). If
+two acceptable interpretations of a constituent of a complete context
+differ only in that one is for an equality operator of the
+universal_access type, and the other is not, the interpretation using
+the equality operator of the universal_access type is preferred.
+
+29.c/3
+ Reason: This preference is necessary because of implicit
+ conversion from an anonymous access type to a named access
+ type, which would allow the equality operator of any named
+ access type to be used to compare anonymous access values (and
+ that way lies madness).
+
+30
+For a complete context, if there is exactly one overall acceptable
+interpretation where each constituent's interpretation is the same as or
+preferred (in the above sense) over those in all other overall
+acceptable interpretations, then that one overall acceptable
+interpretation is chosen. Otherwise, the complete context is ambiguous.
+
+31
+A complete context other than a pragma_argument_association shall not be
+ambiguous.
+
+32
+A complete context that is a pragma_argument_association is allowed to
+be ambiguous (unless otherwise specified for the particular pragma), but
+only if every acceptable interpretation of the pragma argument is as a
+name that statically denotes a callable entity. Such a name denotes all
+of the declarations determined by its interpretations, and all of the
+views declared by these declarations.
+
+32.a/3
+ Ramification: {AI95-00224-01AI95-00224-01}
+ {AI05-0229-1AI05-0229-1} This applies to Inline, Suppress,
+ Import, Export, and Convention pragmas. For example, it is OK
+ to say "pragma Export(C, Entity_Name => P.Q);", even if there
+ are two directly visible P's, and there are two Q's declared
+ in the visible part of each P. In this case, P.Q denotes four
+ different declarations. This rule also applies to certain
+ pragmas defined in the Specialized Needs Annexes. It almost
+ applies to Pure, Elaborate_Body, and Elaborate_All pragmas,
+ but those can't have overloading for other reasons. Note that
+ almost all of these pragmas are obsolescent (see *note J.10::
+ and *note J.15::), and a major reason is that this rule has
+ proven to be too broad in practice (it is common to want to
+ specify something on a single subprogram of an overloaded set,
+ that can't be done easily with this rule).
+ Aspect_specifications, which are given on individual
+ declarations, are preferred in Ada 2012.
+
+32.b
+ Note that if a pragma argument denotes a call to a callable
+ entity, rather than the entity itself, this exception does not
+ apply, and ambiguity is disallowed.
+
+32.c
+ Note that we need to carefully define which pragma-related
+ rules are Name Resolution Rules, so that, for example, a
+ pragma Inline does not pick up subprograms declared in
+ enclosing declarative regions, and therefore make itself
+ illegal.
+
+32.d
+ We say "statically denotes" in the above rule in order to
+ avoid having to worry about how many times the name is
+ evaluated, in case it denotes more than one callable entity.
+
+ NOTES
+
+33
+ 17 If a usage name has only one acceptable interpretation, then it
+ denotes the corresponding entity. However, this does not mean that
+ the usage name is necessarily legal since other requirements exist
+ which are not considered for overload resolution; for example, the
+ fact that an expression is static, whether an object is constant,
+ mode and subtype conformance rules, freezing rules, order of
+ elaboration, and so on.
+
+34
+ Similarly, subtypes are not considered for overload resolution (the
+ violation of a constraint does not make a program illegal but
+ raises an exception during program execution).
+
+ _Incompatibilities With Ada 83_
+
+34.a
+ The new preference rule for operators of root numeric types is
+ upward incompatible, but only in cases that involved
+ Beaujolais effects in Ada 83. Such cases are ambiguous in Ada
+ 95.
+
+ _Extensions to Ada 83_
+
+34.b
+ The rule that allows an expected type to match an actual
+ expression of a universal type, in combination with the new
+ preference rule for operators of root numeric types, subsumes
+ the Ada 83 "implicit conversion" rules for universal types.
+
+ _Wording Changes from Ada 83_
+
+34.c
+ In Ada 83, it is not clear what the "syntax rules" are.
+ AI83-00157 states that a certain textual rule is a syntax
+ rule, but it's still not clear how one tells in general which
+ textual rules are syntax rules. We have solved the problem by
+ stating exactly which rules are syntax rules -- the ones that
+ appear under the "Syntax" heading.
+
+34.d
+ RM83 has a long list of the "forms" of rules that are to be
+ used in overload resolution (in addition to the syntax rules).
+ It is not clear exactly which rules fall under each form. We
+ have solved the problem by explicitly marking all rules that
+ are used in overload resolution. Thus, the list of kinds of
+ rules is unnecessary. It is replaced with some introductory
+ (intentionally vague) text explaining the basic idea of what
+ sorts of rules are overloading rules.
+
+34.e/3
+ {AI05-0299-1AI05-0299-1} It is not clear from RM83 what
+ information is embodied in a "meaning" or an "interpretation."
+ "Meaning" and "interpretation" were intended to be synonymous;
+ we now use the latter only in defining the rules about
+ overload resolution. "Meaning" is used only informally. This
+ subclause attempts to clarify what is meant by
+ "interpretation."
+
+34.f
+ For example, RM83 does not make it clear that overload
+ resolution is required in order to match subprogram_bodies
+ with their corresponding declarations (and even to tell
+ whether a given subprogram_body is the completion of a
+ previous declaration). Clearly, the information needed to do
+ this is part of the "interpretation" of a subprogram_body.
+ The resolution of such things is defined in terms of the
+ "expected profile" concept. Ada 95 has some new cases where
+ expected profiles are needed -- the resolution of P'Access,
+ where P might denote a subprogram, is an example.
+
+34.g
+ RM83-8.7(2) might seem to imply that an interpretation
+ embodies information about what is denoted by each usage name,
+ but not information about which syntactic category each
+ construct belongs to. However, it seems necessary to include
+ such information, since the Ada grammar is highly ambiguous.
+ For example, X(Y) might be a function_call or an
+ indexed_component, and no context-free/syntactic information
+ can tell the difference. It seems like we should view X(Y) as
+ being, for example, "interpreted as a function_call" (if
+ that's what overload resolution decides it is). Note that
+ there are examples where the denotation of each usage name
+ does not imply the syntactic category. However, even if that
+ were not true, it seems that intuitively, the interpretation
+ includes that information. Here's an example:
+
+34.h
+ type T;
+ type A is access T;
+ type T is array(Integer range 1..10) of A;
+ I : Integer := 3;
+ function F(X : Integer := 7) return A;
+ Y : A := F(I); -- Ambiguous? (We hope so.)
+
+34.i/1
+ Consider the declaration of Y (a complete context). In the
+ above example, overload resolution can easily determine the
+ declaration, and therefore the entity, denoted by Y, A, F, and
+ I. However, given all of that information, we still don't know
+ whether F(I) is a function_call or an indexed_component whose
+ prefix is a function_call. (In the latter case, it is
+ equivalent to F(7).all(I).)
+
+34.j
+ It seems clear that the declaration of Y ought to be
+ considered ambiguous. We describe that by saying that there
+ are two interpretations, one as a function_call, and one as an
+ indexed_component. These interpretations are both acceptable
+ to the overloading rules. Therefore, the complete context is
+ ambiguous, and therefore illegal.
+
+34.k
+ It is the intent that the Ada 95 preference rule for root
+ numeric operators is more locally enforceable than that of
+ RM83-4.6(15). It should also eliminate interpretation shifts
+ due to the addition or removal of a use_clause (the so called
+ Beaujolais effect).
+
+34.l/2
+ {AI95-00114-01AI95-00114-01} RM83-8.7 seems to be missing some
+ complete contexts, such as pragma_argument_associations,
+ declarative_items that are not declarations or aspect_clauses,
+ and context_items. We have added these, and also replaced the
+ "must be determinable" wording of RM83-5.4(3) with the notion
+ that the expression of a case_statement is a complete context.
+
+34.m
+ Cases like the Val attribute are now handled using the normal
+ type resolution rules, instead of having special cases that
+ explicitly allow things like "any integer type."
+
+ _Incompatibilities With Ada 95_
+
+34.n/2
+ {AI95-00409-01AI95-00409-01} Ada 95 allowed name resolution to
+ distinguish between anonymous access-to-variable and
+ access-to-constant types. This is similar to distinguishing
+ between subprograms with in and in out parameters, which is
+ known to be bad. Thus, that part of the rule was dropped as
+ we now have anonymous access-to-constant types, making this
+ much more likely.
+
+34.o/2
+ type Cacc is access constant Integer;
+ procedure Proc (Acc : access Integer) ...
+ procedure Proc (Acc : Cacc) ...
+ List : Cacc := ...;
+ Proc (List); -- OK in Ada 95, ambiguous in Ada 2005.
+
+34.p/2
+ If there is any code like this (such code should be rare), it
+ will be ambiguous in Ada 2005.
+
+ _Extensions to Ada 95_
+
+34.q/2
+ {AI95-00230-01AI95-00230-01} {AI95-00231-01AI95-00231-01}
+ {AI95-00254-01AI95-00254-01} Generalized the anonymous access
+ resolution rules to support the new capabilities of anonymous
+ access types (that is, access-to-subprogram and
+ access-to-constant).
+
+34.r/2
+ {AI95-00382-01AI95-00382-01} We now allow the creation of
+ self-referencing types via anonymous access types. This is an
+ extension in unusual cases involving task and protected types.
+ For example:
+
+34.s/2
+ task type T;
+
+34.t/2
+ task body T is
+ procedure P (X : access T) is -- Illegal in Ada 95, legal in Ada 2005
+ ...
+ end P;
+ begin
+ ...
+ end T;
+
+ _Wording Changes from Ada 95_
+
+34.u/2
+ {AI95-00332-01AI95-00332-01} Corrected the "single expected
+ type" so that it works in contexts that don't have expected
+ types (like object renames and qualified expressions). This
+ fixes a hole in Ada 95 that appears to prohibit using
+ aggregates, 'Access, character literals, string literals, and
+ allocators in qualified expressions.
+
+ _Incompatibilities With Ada 2005_
+
+34.v/3
+ {AI05-0149-1AI05-0149-1} Implicit conversion is now allowed
+ from anonymous access-to-object types to general
+ access-to-object types. Such conversions can make calls
+ ambiguous. That can only happen when there are two visible
+ subprograms with the same name and have profiles that differ
+ only by a parameter that is of a named or anonymous access
+ type, and the actual argument is of an anonymous access type.
+ This should be rare, as many possible calls would be ambiguous
+ even in Ada 2005 (including allocators and any actual of a
+ named access type if the designated types are the same).
+
+ _Extensions to Ada 2005_
+
+34.w/3
+ {AI05-0149-1AI05-0149-1} Implicit conversion is allowed from
+ anonymous access-to-object types to general access-to-object
+ types if the designated type is convertible and runtime checks
+ are minimized. See also the incompatibilities section.
+
+ _Wording Changes from Ada 2005_
+
+34.x/3
+ {AI05-0102-1AI05-0102-1} Added a requirement here that
+ implicit conversions are convertible to the appropriate type.
+ This rule was scattered about the Standard, we moved a single
+ generalized version here.
+
+\1f
+File: aarm2012.info, Node: 9, Next: 10, Prev: 8, Up: Top
+
+9 Tasks and Synchronization
+***************************
+
+1/3
+{AI05-0299-1AI05-0299-1} The execution of an Ada program consists of the
+execution of one or more tasks. Each task represents a separate thread
+of control that proceeds independently and concurrently between the
+points where it interacts with other tasks. The various forms of task
+interaction are described in this clause, and include:
+
+1.a
+ To be honest: The execution of an Ada program consists of the
+ execution of one or more partitions (see *note 10.2::), each
+ of which in turn consists of the execution of an environment
+ task and zero or more subtasks.
+
+2
+ * the activation and termination of a task;
+
+3
+ * a call on a protected subprogram of a protected object, providing
+ exclusive read-write access, or concurrent read-only access to
+ shared data;
+
+4
+ * a call on an entry, either of another task, allowing for
+ synchronous communication with that task, or of a protected object,
+ allowing for asynchronous communication with one or more other
+ tasks using that same protected object;
+
+5
+ * a timed operation, including a simple delay statement, a timed
+ entry call or accept, or a timed asynchronous select statement (see
+ next item);
+
+6
+ * an asynchronous transfer of control as part of an asynchronous
+ select statement, where a task stops what it is doing and begins
+ execution at a different point in response to the completion of an
+ entry call or the expiration of a delay;
+
+7
+ * an abort statement, allowing one task to cause the termination of
+ another task.
+
+8
+In addition, tasks can communicate indirectly by reading and updating
+(unprotected) shared variables, presuming the access is properly
+synchronized through some other kind of task interaction.
+
+ _Static Semantics_
+
+9
+The properties of a task are defined by a corresponding task declaration
+and task_body, which together define a program unit called a task unit.
+
+ _Dynamic Semantics_
+
+10
+Over time, tasks proceed through various states. A task is initially
+inactive; upon activation, and prior to its termination it is either
+blocked (as part of some task interaction) or ready to run. While
+ready, a task competes for the available execution resources that it
+requires to run.
+
+10.a/3
+ Discussion: {AI05-0229-1AI05-0229-1} The means for selecting
+ which of the ready tasks to run, given the currently available
+ execution resources, is determined by the task dispatching
+ policy in effect, which is generally implementation defined,
+ but may be controlled by aspects, pragmas, and operations
+ defined in the Real-Time Annex (see *note D.2:: and *note
+ D.5::).
+
+ NOTES
+
+11
+ 1 Concurrent task execution may be implemented on multicomputers,
+ multiprocessors, or with interleaved execution on a single physical
+ processor. On the other hand, whenever an implementation can
+ determine that the required semantic effects can be achieved when
+ parts of the execution of a given task are performed by different
+ physical processors acting in parallel, it may choose to perform
+ them in this way.
+
+ _Wording Changes from Ada 83_
+
+11.a
+ The introduction has been rewritten.
+
+11.b
+ We use the term "concurrent" rather than "parallel" when
+ talking about logically independent execution of threads of
+ control. The term "parallel" is reserved for referring to the
+ situation where multiple physical processors run
+ simultaneously.
+
+* Menu:
+
+* 9.1 :: Task Units and Task Objects
+* 9.2 :: Task Execution - Task Activation
+* 9.3 :: Task Dependence - Termination of Tasks
+* 9.4 :: Protected Units and Protected Objects
+* 9.5 :: Intertask Communication
+* 9.6 :: Delay Statements, Duration, and Time
+* 9.7 :: Select Statements
+* 9.8 :: Abort of a Task - Abort of a Sequence of Statements
+* 9.9 :: Task and Entry Attributes
+* 9.10 :: Shared Variables
+* 9.11 :: Example of Tasking and Synchronization
+
+\1f
+File: aarm2012.info, Node: 9.1, Next: 9.2, Up: 9
+
+9.1 Task Units and Task Objects
+===============================
+
+1
+A task unit is declared by a task declaration, which has a corresponding
+task_body. A task declaration may be a task_type_declaration, in which
+case it declares a named task type; alternatively, it may be a
+single_task_declaration, in which case it defines an anonymous task
+type, as well as declaring a named task object of that type.
+
+ _Syntax_
+
+2/3
+ {AI95-00345-01AI95-00345-01} {AI05-0183-1AI05-0183-1}
+ task_type_declaration ::=
+ task type defining_identifier [known_discriminant_part]
+ [aspect_specification] [is
+ [new interface_list with]
+ task_definition];
+
+3/3
+ {AI95-00399-01AI95-00399-01} {AI05-0183-1AI05-0183-1}
+ single_task_declaration ::=
+ task defining_identifier
+ [aspect_specification][is
+ [new interface_list with]
+ task_definition];
+
+4
+ task_definition ::=
+ {task_item}
+ [ private
+ {task_item}]
+ end [task_identifier]
+
+5/1
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} task_item ::=
+ entry_declaration | aspect_clause
+
+6/3
+ {AI05-0267-1AI05-0267-1} task_body ::=
+ task body defining_identifier
+ [aspect_specification] is
+ declarative_part
+ begin
+ handled_sequence_of_statements
+ end [task_identifier];
+
+7
+ If a task_identifier appears at the end of a task_definition or
+ task_body, it shall repeat the defining_identifier.
+
+8.a/2
+ This paragraph was deleted.
+
+Paragraph 8 was deleted.
+
+ _Static Semantics_
+
+9
+A task_definition defines a task type and its first subtype. The first
+list of task_items of a task_definition (*note 9.1: S0207.), together
+with the known_discriminant_part (*note 3.7: S0061.), if any, is called
+the visible part of the task unit. [ The optional list of task_items
+after the reserved word private is called the private part of the task
+unit.]
+
+9.a/3
+ Proof: {AI05-0299-1AI05-0299-1} Private part is defined in
+ Clause *note 8::.
+
+9.1/1
+{8652/00298652/0029} {AI95-00116-01AI95-00116-01} For a task declaration
+without a task_definition, a task_definition without task_items is
+assumed.
+
+9.2/3
+{AI95-00345-01AI95-00345-01} {AI95-00397-01AI95-00397-01}
+{AI95-00399-01AI95-00399-01} {AI95-00419-01AI95-00419-01}
+{AI05-0042-1AI05-0042-1} For a task declaration with an interface_list,
+the task type inherits user-defined primitive subprograms from each
+progenitor type (see *note 3.9.4::), in the same way that a derived type
+inherits user-defined primitive subprograms from its progenitor types
+(see *note 3.4::). If the first parameter of a primitive inherited
+subprogram is of the task type or an access parameter designating the
+task type, and there is an entry_declaration for a single entry with the
+same identifier within the task declaration, whose profile is type
+conformant with the prefixed view profile of the inherited subprogram,
+the inherited subprogram is said to be implemented by the conforming
+task entry using an implicitly declared nonabstract subprogram which has
+the same profile as the inherited subprogram and which overrides it.
+
+9.b/2
+ Ramification: The inherited subprograms can only come from an
+ interface given as part of the task declaration.
+
+9.b.1/3
+ Reason: {AI05-0042-1AI05-0042-1} The part about the implicitly
+ declared subprogram is needed so that a subprogram implemented
+ by an entry is considered to be overridden for the purpose of
+ the other rules of the language. Without it, it would for
+ instance be illegal for an abstract subprogram to be
+ implemented by an entry, because the abstract subprogram would
+ not be overridden. The Legality Rules below ensure that there
+ is no conflict between the implicit overriding subprogram and
+ a user-defined overriding subprogram.
+
+ _Legality Rules_
+
+9.3/2
+{AI95-00345-01AI95-00345-01} A task declaration requires a completion[,
+which shall be a task_body,] and every task_body shall be the completion
+of some task declaration.
+
+9.c/3
+ To be honest: {AI05-0229-1AI05-0229-1} If the implementation
+ supports it, the task body can be imported (using aspect
+ Import, see *note B.1::), in which case no explicit task_body
+ is allowed.
+
+9.4/2
+{AI95-00345-01AI95-00345-01} {AI95-00399-01AI95-00399-01} [Each
+interface_subtype_mark of an interface_list appearing within a task
+declaration shall denote a limited interface type that is not a
+protected interface.]
+
+9.d/2
+ Proof: *note 3.9.4:: requires that an interface_list only name
+ interface types, and limits the descendants of the various
+ kinds of interface types. Only a limited, task, or
+ synchronized interface can have a task type descendant.
+ Nonlimited or protected interfaces are not allowed, as they
+ offer operations that a task does not have.
+
+9.5/3
+{AI95-00397-01AI95-00397-01} {AI05-0090-1AI05-0090-1} The prefixed view
+profile of an explicitly declared primitive subprogram of a tagged task
+type shall not be type conformant with any entry of the task type, if
+the subprogram has the same defining name as the entry and the first
+parameter of the subprogram is of the task type or is an access
+parameter designating the task type.
+
+9.e/2
+ Reason: This prevents the existence of two operations with the
+ same name and profile which could be called with a prefixed
+ view. If the operation was inherited, this would be illegal
+ by the following rules; this rule puts inherited and
+ noninherited routines on the same footing. Note that this
+ only applies to tagged task types (that is, those with an
+ interface in their declaration); we do that as there is no
+ problem with prefixed view calls of primitive operations for
+ "normal" task types, and having this rule apply to all tasks
+ would be incompatible with Ada 95.
+
+9.6/2
+{AI95-00345-01AI95-00345-01} {AI95-00399-01AI95-00399-01} For each
+primitive subprogram inherited by the type declared by a task
+declaration, at most one of the following shall apply:
+
+9.7/2
+ * {AI95-00345-01AI95-00345-01} the inherited subprogram is overridden
+ with a primitive subprogram of the task type, in which case the
+ overriding subprogram shall be subtype conformant with the
+ inherited subprogram and not abstract; or
+
+9.8/2
+ * {AI95-00345-01AI95-00345-01} {AI95-00397-01AI95-00397-01} the
+ inherited subprogram is implemented by a single entry of the task
+ type; in which case its prefixed view profile shall be subtype
+ conformant with that of the task entry.
+
+9.f/2
+ Ramification: An entry may implement two subprograms from the
+ ancestors, one whose first parameter is of type T and one
+ whose first parameter is of type access T. That doesn't cause
+ implementation problems because "implemented by" (unlike
+ "overridden') probably entails the creation of wrappers.
+
+9.9/2
+If neither applies, the inherited subprogram shall be a null procedure.
+In addition to the places where Legality Rules normally apply (see *note
+12.3::), these rules also apply in the private part of an instance of a
+generic unit.
+
+9.g/2
+ Reason: Each inherited subprogram can only have a single
+ implementation (either from overriding a subprogram or
+ implementing an entry), and must have an implementation unless
+ the subprogram is a null procedure.
+
+ _Dynamic Semantics_
+
+10
+[ The elaboration of a task declaration elaborates the task_definition.
+The elaboration of a single_task_declaration (*note 9.1: S0206.) also
+creates an object of an (anonymous) task type.]
+
+10.a
+ Proof: This is redundant with the general rules for the
+ elaboration of a full_type_declaration and an
+ object_declaration.
+
+11
+[The elaboration of a task_definition creates the task type and its
+first subtype;] it also includes the elaboration of the
+entry_declarations in the given order.
+
+12/1
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01} As part of the
+initialization of a task object, any aspect_clauses and any per-object
+constraints associated with entry_declaration (*note 9.5.2: S0218.)s of
+the corresponding task_definition (*note 9.1: S0207.) are elaborated in
+the given order.
+
+12.a/1
+ Reason: The only aspect_clauses defined for task entries are
+ ones that specify the Address of an entry, as part of defining
+ an interrupt entry. These clearly need to be elaborated
+ per-object, not per-type. Normally the address will be a
+ function of a discriminant, if such an Address clause is in a
+ task type rather than a single task declaration, though it
+ could rely on a parameterless function that allocates
+ sequential interrupt vectors.
+
+12.b
+ We do not mention representation pragmas, since each pragma
+ may have its own elaboration rules.
+
+13
+The elaboration of a task_body has no effect other than to establish
+that tasks of the type can from then on be activated without failing the
+Elaboration_Check.
+
+14
+[The execution of a task_body is invoked by the activation of a task of
+the corresponding type (see *note 9.2::).]
+
+15
+The content of a task object of a given task type includes:
+
+16
+ * The values of the discriminants of the task object, if any;
+
+17
+ * An entry queue for each entry of the task object;
+
+17.a
+ Ramification: "For each entry" implies one queue for each
+ single entry, plus one for each entry of each entry family.
+
+18
+ * A representation of the state of the associated task.
+
+ NOTES
+
+19/2
+ 2 {AI95-00382-01AI95-00382-01} Other than in an access_definition,
+ the name of a task unit within the declaration or body of the task
+ unit denotes the current instance of the unit (see *note 8.6::),
+ rather than the first subtype of the corresponding task type (and
+ thus the name cannot be used as a subtype_mark).
+
+19.a/2
+ Discussion: {AI95-00382-01AI95-00382-01} It can be used as a
+ subtype_mark in an anonymous access type. In addition, it is
+ possible to refer to some other subtype of the task type
+ within its body, presuming such a subtype has been declared
+ between the task_type_declaration and the task_body.
+
+20
+ 3 The notation of a selected_component can be used to denote a
+ discriminant of a task (see *note 4.1.3::). Within a task unit,
+ the name of a discriminant of the task type denotes the
+ corresponding discriminant of the current instance of the unit.
+
+21/2
+ 4 {AI95-00287-01AI95-00287-01} A task type is a limited type (see
+ *note 7.5::), and hence precludes use of assignment_statements and
+ predefined equality operators. If an application needs to store
+ and exchange task identities, it can do so by defining an access
+ type designating the corresponding task objects and by using access
+ values for identification purposes. Assignment is available for
+ such an access type as for any access type. Alternatively, if the
+ implementation supports the Systems Programming Annex, the Identity
+ attribute can be used for task identification (see *note C.7.1::).
+
+ _Examples_
+
+22
+Examples of declarations of task types:
+
+23
+ task type Server is
+ entry Next_Work_Item(WI : in Work_Item);
+ entry Shut_Down;
+ end Server;
+
+24/2
+ {AI95-00433-01AI95-00433-01} task type Keyboard_Driver(ID : Keyboard_ID := New_ID) is
+ new Serial_Device with -- see *note 3.9.4::
+ entry Read (C : out Character);
+ entry Write(C : in Character);
+ end Keyboard_Driver;
+
+25
+Examples of declarations of single tasks:
+
+26
+ task Controller is
+ entry Request(Level)(D : Item); -- a family of entries
+ end Controller;
+
+27
+ task Parser is
+ entry Next_Lexeme(L : in Lexical_Element);
+ entry Next_Action(A : out Parser_Action);
+ end;
+
+28
+ task User; -- has no entries
+
+29
+Examples of task objects:
+
+30
+ Agent : Server;
+ Teletype : Keyboard_Driver(TTY_ID);
+ Pool : array(1 .. 10) of Keyboard_Driver;
+
+31
+Example of access type designating task objects:
+
+32
+ type Keyboard is access Keyboard_Driver;
+ Terminal : Keyboard := new Keyboard_Driver(Term_ID);
+
+ _Extensions to Ada 83_
+
+32.a/1
+ The syntax rules for task declarations are modified to allow a
+ known_discriminant_part, and to allow a private part. They
+ are also modified to allow entry_declarations and
+ aspect_clauses to be mixed.
+
+ _Wording Changes from Ada 83_
+
+32.b
+ The syntax rules for tasks have been split up according to
+ task types and single tasks. In particular: The syntax rules
+ for task_declaration and task_specification are removed. The
+ syntax rules for task_type_declaration,
+ single_task_declaration, task_definition and task_item are
+ new.
+
+32.c
+ The syntax rule for task_body now uses the nonterminal
+ handled_sequence_of_statements.
+
+32.d
+ The declarative_part of a task_body is now required; that
+ doesn't make any real difference, because a declarative_part
+ can be empty.
+
+ _Extensions to Ada 95_
+
+32.e/2
+ {AI95-00345-01AI95-00345-01} {AI95-00397-01AI95-00397-01}
+ {AI95-00399-01AI95-00399-01} {AI95-00419-01AI95-00419-01} Task
+ types and single tasks can be derived from one or more
+ interfaces. Entries of the task type can implement the
+ primitive operations of an interface. Overriding_indicators
+ can be used to specify whether or not an entry implements a
+ primitive operation.
+
+ _Wording Changes from Ada 95_
+
+32.f/2
+ {8652/00298652/0029} {AI95-00116-01AI95-00116-01} Corrigendum:
+ Clarified that a task type has an implicit empty
+ task_definition if none is given.
+
+32.g/2
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} Corrigendum:
+ Changed representation clauses to aspect clauses to reflect
+ that they are used for more than just representation.
+
+32.h/2
+ {AI95-00287-01AI95-00287-01} Revised the note on operations of
+ task types to reflect that limited types do have an assignment
+ operation, but not copying (assignment_statements).
+
+32.i/2
+ {AI95-00382-01AI95-00382-01} Revised the note on use of the
+ name of a task type within itself to reflect the exception for
+ anonymous access types.
+
+ _Extensions to Ada 2005_
+
+32.j/3
+ {AI05-0183-1AI05-0183-1} {AI05-0267-1AI05-0267-1} An optional
+ aspect_specification can be used in a task_type_declaration, a
+ single_task_declaration, and a task_body. This is described
+ in *note 13.1.1::.
+
+ _Wording Changes from Ada 2005_
+
+32.k/3
+ {AI05-0042-1AI05-0042-1} Correction: Clarified that an
+ inherited procedure of a progenitor is overridden when it is
+ implemented by an entry.
+
+32.l/3
+ {AI05-0090-1AI05-0090-1} Correction: Added the missing
+ defining name in the no conflicting primitive operation rule.
+
+\1f
+File: aarm2012.info, Node: 9.2, Next: 9.3, Prev: 9.1, Up: 9
+
+9.2 Task Execution - Task Activation
+====================================
+
+ _Dynamic Semantics_
+
+1
+The execution of a task of a given task type consists of the execution
+of the corresponding task_body. The initial part of this execution is
+called the activation of the task; it consists of the elaboration of the
+declarative_part of the task_body. Should an exception be propagated by
+the elaboration of its declarative_part, the activation of the task is
+defined to have failed, and it becomes a completed task.
+
+2/2
+{AI95-00416-01AI95-00416-01} A task object (which represents one task)
+can be a part of a stand-alone object, of an object created by an
+allocator, or of an anonymous object of a limited type, or a coextension
+of one of these. All tasks that are part or coextensions of any of the
+stand-alone objects created by the elaboration of object_declaration
+(*note 3.3.1: S0032.)s (or generic_associations of formal objects of
+mode in) of a single declarative region are activated together. All
+tasks that are part or coextensions of a single object that is not a
+stand-alone object are activated together.
+
+2.a
+ Discussion: The initialization of an object_declaration or
+ allocator can indirectly include the creation of other objects
+ that contain tasks. For example, the default expression for a
+ subcomponent of an object created by an allocator might call a
+ function that evaluates a completely different allocator.
+ Tasks created by the two allocators are not activated
+ together.
+
+3/2
+{AI95-00416-01AI95-00416-01} For the tasks of a given declarative
+region, the activations are initiated within the context of the
+handled_sequence_of_statements (*note 11.2: S0265.) (and its associated
+exception_handler (*note 11.2: S0266.)s if any -- see *note 11.2::),
+just prior to executing the statements of the
+handled_sequence_of_statements. [For a package without an explicit body
+or an explicit handled_sequence_of_statements (*note 11.2: S0265.), an
+implicit body or an implicit null_statement (*note 5.1: S0149.) is
+assumed, as defined in *note 7.2::.]
+
+3.a
+ Ramification: If Tasking_Error is raised, it can be handled by
+ handlers of the handled_sequence_of_statements (*note 11.2:
+ S0265.).
+
+4/2
+{AI95-00416-01AI95-00416-01} For tasks that are part or coextensions of
+a single object that is not a stand-alone object, activations are
+initiated after completing any initialization of the outermost object
+enclosing these tasks, prior to performing any other operation on the
+outermost object. In particular, for tasks that are part or
+coextensions of the object created by the evaluation of an allocator,
+the activations are initiated as the last step of evaluating the
+allocator, prior to returning the new access value. For tasks that are
+part or coextensions of an object that is the result of a function call,
+the activations are not initiated until after the function returns.
+
+4.a/2
+ Discussion: {AI95-00416-01AI95-00416-01} The intent is that
+ "temporary" objects with task parts (or coextensions) are
+ treated similarly to an object created by an allocator. The
+ "whole" object is initialized, and then all of the task parts
+ (including the coextensions) are activated together. Each
+ such "whole" object has its own task activation sequence,
+ involving the activating task being suspended until all the
+ new tasks complete their activation.
+
+5
+The task that created the new tasks and initiated their activations (the
+activator) is blocked until all of these activations complete
+(successfully or not). Once all of these activations are complete, if
+the activation of any of the tasks has failed [(due to the propagation
+of an exception)], Tasking_Error is raised in the activator, at the
+place at which it initiated the activations. Otherwise, the activator
+proceeds with its execution normally. Any tasks that are aborted prior
+to completing their activation are ignored when determining whether to
+raise Tasking_Error.
+
+5.a
+ Ramification: Note that a task created by an allocator does
+ not necessarily depend on its activator; in such a case the
+ activator's termination can precede the termination of the
+ newly created task.
+
+5.b
+ Discussion: Tasking_Error is raised only once, even if two or
+ more of the tasks being activated fail their activation.
+
+5.c/2
+ To be honest: {AI95-00265-01AI95-00265-01} The pragma
+ Partition_Elaboration_Policy (see *note H.6::) can be used to
+ defer task activation to a later point, thus changing many of
+ these rules.
+
+6/3
+{AI05-0045-1AI05-0045-1} If the master that directly encloses the point
+where the activation of a task T would be initiated, completes before
+the activation of T is initiated, T becomes terminated and is never
+activated. Furthermore, if a return statement is left such that the
+return object is not returned to the caller, any task that was created
+as a part of the return object or one of its coextensions immediately
+becomes terminated and is never activated.
+
+6.a/3
+ Ramification: {AI05-0045-1AI05-0045-1} The first case can only
+ happen if the activation point of T is not reached due to an
+ exception being raised or a task or statement being aborted.
+ Note that this is exclusive; if the master completes normally
+ and starts finalization, we're already past the activation
+ point.
+
+6.b/3
+ {AI05-0045-1AI05-0045-1} The second case can happen with an
+ exception being raised in a return statement, by an exit or
+ goto from an extended_return_statement, or by a return
+ statement being aborted. Any tasks created for the return
+ object of such a return statement are never activated.
+
+ NOTES
+
+7
+ 5 An entry of a task can be called before the task has been
+ activated.
+
+8
+ 6 If several tasks are activated together, the execution of any of
+ these tasks need not await the end of the activation of the other
+ tasks.
+
+9
+ 7 A task can become completed during its activation either because
+ of an exception or because it is aborted (see *note 9.8::).
+
+ _Examples_
+
+10
+Example of task activation:
+
+11
+ procedure P is
+ A, B : Server; -- elaborate the task objects A, B
+ C : Server; -- elaborate the task object C
+ begin
+ -- the tasks A, B, C are activated together before the first statement
+ ...
+ end;
+
+ _Wording Changes from Ada 83_
+
+11.a
+ We have replaced the term suspended with blocked, since we
+ didn't want to consider a task blocked when it was simply
+ competing for execution resources. "Suspended" is sometimes
+ used more generally to refer to tasks that are not actually
+ running on some processor, due to the lack of resources.
+
+11.b/3
+ {AI05-0299-1AI05-0299-1} This subclause has been rewritten in
+ an attempt to improve presentation.
+
+ _Wording Changes from Ada 95_
+
+11.c/2
+ {AI95-00416-01AI95-00416-01} Adjusted the wording for
+ activating tasks to handle the case of anonymous function
+ return objects. This is critical; we don't want to be waiting
+ for the tasks in a return object when we exit the function
+ normally.
+
+ _Wording Changes from Ada 2005_
+
+11.d/3
+ {AI05-0045-1AI05-0045-1} Correction: Corrected the wording
+ that handles tasks that are never activated to ensure that no
+ lookahead is implied and to make it clear that tasks created
+ by return statements that never return are never activated.
+
+\1f
+File: aarm2012.info, Node: 9.3, Next: 9.4, Prev: 9.2, Up: 9
+
+9.3 Task Dependence - Termination of Tasks
+==========================================
+
+ _Dynamic Semantics_
+
+1
+Each task (other than an environment task -- see *note 10.2::) depends
+on one or more masters (see *note 7.6.1::), as follows:
+
+2
+ * If the task is created by the evaluation of an allocator for a
+ given access type, it depends on each master that includes the
+ elaboration of the declaration of the ultimate ancestor of the
+ given access type.
+
+3
+ * If the task is created by the elaboration of an object_declaration,
+ it depends on each master that includes this elaboration.
+
+3.1/2
+ * {AI95-00416-01AI95-00416-01} Otherwise, the task depends on the
+ master of the outermost object of which it is a part (as determined
+ by the accessibility level of that object -- see *note 3.10.2:: and
+ *note 7.6.1::), as well as on any master whose execution includes
+ that of the master of the outermost object.
+
+3.a/2
+ Ramification: {AI95-00416-01AI95-00416-01} The master of a
+ task created by a return statement changes when the
+ accessibility of the return object changes. Note that its
+ activation happens, if at all, only after the function returns
+ and all accessibility level changes have occurred.
+
+4
+Furthermore, if a task depends on a given master, it is defined to
+depend on the task that executes the master, and (recursively) on any
+master of that task.
+
+4.a
+ Discussion: Don't confuse these kinds of dependences with the
+ dependences among compilation units defined in *note 10.1.1::,
+ "*note 10.1.1:: Compilation Units - Library Units".
+
+5
+A task is said to be completed when the execution of its corresponding
+task_body is completed. A task is said to be terminated when any
+finalization of the task_body has been performed (see *note 7.6.1::).
+[The first step of finalizing a master (including a task_body) is to
+wait for the termination of any tasks dependent on the master.] The
+task executing the master is blocked until all the dependents have
+terminated. [Any remaining finalization is then performed and the
+master is left.]
+
+6/1
+Completion of a task (and the corresponding task_body) can occur when
+the task is blocked at a select_statement (*note 9.7: S0230.) with an
+open terminate_alternative (see *note 9.7.1::); the open
+terminate_alternative is selected if and only if the following
+conditions are satisfied:
+
+7/2
+ * {AI95-00415-01AI95-00415-01} The task depends on some completed
+ master; and
+
+8
+ * Each task that depends on the master considered is either already
+ terminated or similarly blocked at a select_statement with an open
+ terminate_alternative.
+
+9
+When both conditions are satisfied, the task considered becomes
+completed, together with all tasks that depend on the master considered
+that are not yet completed.
+
+9.a
+ Ramification: Any required finalization is performed after the
+ selection of terminate_alternatives. The tasks are not
+ callable during the finalization. In some ways it is as
+ though they were aborted.
+
+ NOTES
+
+10
+ 8 The full view of a limited private type can be a task type, or
+ can have subcomponents of a task type. Creation of an object of
+ such a type creates dependences according to the full type.
+
+11
+ 9 An object_renaming_declaration defines a new view of an existing
+ entity and hence creates no further dependence.
+
+12
+ 10 The rules given for the collective completion of a group of
+ tasks all blocked on select_statements with open
+ terminate_alternatives ensure that the collective completion can
+ occur only when there are no remaining active tasks that could call
+ one of the tasks being collectively completed.
+
+13
+ 11 If two or more tasks are blocked on select_statements with open
+ terminate_alternatives, and become completed collectively, their
+ finalization actions proceed concurrently.
+
+14
+ 12 The completion of a task can occur due to any of the following:
+
+15
+ * the raising of an exception during the elaboration of the
+ declarative_part of the corresponding task_body;
+
+16
+ * the completion of the handled_sequence_of_statements of the
+ corresponding task_body;
+
+17
+ * the selection of an open terminate_alternative of a
+ select_statement in the corresponding task_body;
+
+18
+ * the abort of the task.
+
+ _Examples_
+
+19
+Example of task dependence:
+
+20
+ declare
+ type Global is access Server; -- see *note 9.1::
+ A, B : Server;
+ G : Global;
+ begin
+ -- activation of A and B
+ declare
+ type Local is access Server;
+ X : Global := new Server; -- activation of X.all
+ L : Local := new Server; -- activation of L.all
+ C : Server;
+ begin
+ -- activation of C
+ G := X; -- both G and X designate the same task object
+ ...
+ end; -- await termination of C and L.all (but not X.all)
+ ...
+ end; -- await termination of A, B, and G.all
+
+ _Wording Changes from Ada 83_
+
+20.a
+ We have revised the wording to be consistent with the
+ definition of master now given in *note 7.6.1::, "*note
+ 7.6.1:: Completion and Finalization".
+
+20.b
+ Tasks that used to depend on library packages in Ada 83, now
+ depend on the (implicit) task_body of the environment task
+ (see *note 10.2::). Therefore, the environment task has to
+ wait for them before performing library level finalization and
+ terminating the partition. In Ada 83 the requirement to wait
+ for tasks that depended on library packages was not as clear.
+
+20.c
+ What was "collective termination" is now "collective
+ completion" resulting from selecting terminate_alternatives.
+ This is because finalization still occurs for such tasks, and
+ this happens after selecting the terminate_alternative, but
+ before termination.
+
+ _Wording Changes from Ada 95_
+
+20.d/2
+ {AI95-00416-01AI95-00416-01} Added missing wording that
+ explained the master of tasks that are neither object
+ declarations nor allocators, such as function returns.
+
+\1f
+File: aarm2012.info, Node: 9.4, Next: 9.5, Prev: 9.3, Up: 9
+
+9.4 Protected Units and Protected Objects
+=========================================
+
+1
+A protected object provides coordinated access to shared data, through
+calls on its visible protected operations, which can be protected
+subprograms or protected entries. A protected unit is declared by a
+protected declaration, which has a corresponding protected_body. A
+protected declaration may be a protected_type_declaration, in which case
+it declares a named protected type; alternatively, it may be a
+single_protected_declaration, in which case it defines an anonymous
+protected type, as well as declaring a named protected object of that
+type.
+
+ _Syntax_
+
+2/3
+ {AI95-00345-01AI95-00345-01} {AI05-0183-1AI05-0183-1}
+ protected_type_declaration ::=
+ protected type defining_identifier [known_discriminant_part]
+ [aspect_specification] is
+ [new interface_list with]
+ protected_definition;
+
+3/3
+ {AI95-00399-01AI95-00399-01} {AI05-0183-1AI05-0183-1}
+ single_protected_declaration ::=
+ protected defining_identifier
+ [aspect_specification] is
+ [new interface_list with]
+ protected_definition;
+
+4
+ protected_definition ::=
+ { protected_operation_declaration }
+ [ private
+ { protected_element_declaration } ]
+ end [protected_identifier]
+
+5/1
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+ protected_operation_declaration ::= subprogram_declaration
+ | entry_declaration
+ | aspect_clause
+
+6
+ protected_element_declaration ::= protected_operation_declaration
+ | component_declaration
+
+6.a
+ Reason: We allow the operations and components to be mixed
+ because that's how other things work (for example, package
+ declarations). We have relaxed the ordering rules for the
+ items inside declarative_parts and task_definitions as well.
+
+7/3
+ {AI05-0267-1AI05-0267-1} protected_body ::=
+ protected body defining_identifier
+ [aspect_specification] is
+ { protected_operation_item }
+ end [protected_identifier];
+
+8/1
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+ protected_operation_item ::= subprogram_declaration
+ | subprogram_body
+ | entry_body
+ | aspect_clause
+
+9
+ If a protected_identifier appears at the end of a
+ protected_definition or protected_body, it shall repeat the
+ defining_identifier.
+
+10.a/2
+ This paragraph was deleted.
+
+Paragraph 10 was deleted.
+
+ _Static Semantics_
+
+11/2
+{AI95-00345-01AI95-00345-01} {AI95-00401-01AI95-00401-01} A
+protected_definition defines a protected type and its first subtype.
+The list of protected_operation_declaration (*note 9.4: S0213.)s of a
+protected_definition (*note 9.4: S0212.), together with the
+known_discriminant_part (*note 3.7: S0061.), if any, is called the
+visible part of the protected unit. [ The optional list of
+protected_element_declaration (*note 9.4: S0214.)s after the reserved
+word private is called the private part of the protected unit.]
+
+11.a/3
+ Proof: {AI05-0299-1AI05-0299-1} Private part is defined in
+ Clause *note 8::.
+
+11.1/3
+{AI95-00345-01AI95-00345-01} {AI95-00397-01AI95-00397-01}
+{AI95-00399-01AI95-00399-01} {AI95-00419-01AI95-00419-01}
+{AI05-0042-1AI05-0042-1} For a protected declaration with an
+interface_list, the protected type inherits user-defined primitive
+subprograms from each progenitor type (see *note 3.9.4::), in the same
+way that a derived type inherits user-defined primitive subprograms from
+its progenitor types (see *note 3.4::). If the first parameter of a
+primitive inherited subprogram is of the protected type or an access
+parameter designating the protected type, and there is a
+protected_operation_declaration for a protected subprogram or single
+entry with the same identifier within the protected declaration, whose
+profile is type conformant with the prefixed view profile of the
+inherited subprogram, the inherited subprogram is said to be implemented
+by the conforming protected subprogram or entry using an implicitly
+declared nonabstract subprogram which has the same profile as the
+inherited subprogram and which overrides it.
+
+11.b/2
+ Ramification: The inherited subprograms can only come from an
+ interface given as part of the protected declaration.
+
+11.b.1/3
+ Reason: {AI05-0042-1AI05-0042-1} The part about the implicitly
+ declared subprogram is needed so that a subprogram implemented
+ by an entry or subprogram is considered to be overridden for
+ the purpose of the other rules of the language. Without it,
+ it would for instance be illegal for an abstract subprogram to
+ be implemented by an entry, because the abstract subprogram
+ would not be overridden. The Legality Rules below ensure that
+ there is no conflict between the implicit overriding
+ subprogram and a user-defined overriding subprogram.
+
+ _Legality Rules_
+
+11.2/2
+{AI95-00345-01AI95-00345-01} A protected declaration requires a
+completion[, which shall be a protected_body (*note 9.4: S0215.),] and
+every protected_body (*note 9.4: S0215.) shall be the completion of some
+protected declaration.
+
+11.c/3
+ To be honest: {AI05-0229-1AI05-0229-1} If the implementation
+ supports it, the protected body can be imported (using aspect
+ Import, see *note B.1::), in which case no explicit
+ protected_body is allowed.
+
+11.3/2
+{AI95-00345-01AI95-00345-01} {AI95-00399-01AI95-00399-01} [Each
+interface_subtype_mark of an interface_list appearing within a protected
+declaration shall denote a limited interface type that is not a task
+interface.]
+
+11.d/2
+ Proof: *note 3.9.4:: requires that an interface_list only name
+ interface types, and limits the descendants of the various
+ kinds of interface types. Only a limited, protected, or
+ synchronized interface can have a protected type descendant.
+ Nonlimited or task interfaces are not allowed, as they offer
+ operations that a protected type does not have.
+
+11.4/3
+{AI95-00397-01AI95-00397-01} {AI05-0042-1AI05-0042-1} The prefixed view
+profile of an explicitly declared primitive subprogram of a tagged
+protected type shall not be type conformant with any protected operation
+of the protected type, if the subprogram has the same defining name as
+the protected operation and the first parameter of the subprogram is of
+the protected type or is an access parameter designating the protected
+type.
+
+11.e/2
+ Reason: This prevents the existence of two operations with the
+ same name and profile which could be called with a prefixed
+ view. If the operation was inherited, this would be illegal
+ by the following rules; this rule puts inherited and
+ noninherited routines on the same footing. Note that this
+ only applies to tagged protected types (that is, those with an
+ interface in their declaration); we do that as there is no
+ problem with prefixed view calls of primitive operations for
+ "normal" protected types, and having this rule apply to all
+ protected types would be incompatible with Ada 95.
+
+11.5/2
+{AI95-00345-01AI95-00345-01} {AI95-00399-01AI95-00399-01} For each
+primitive subprogram inherited by the type declared by a protected
+declaration, at most one of the following shall apply:
+
+11.6/2
+ * {AI95-00345-01AI95-00345-01} the inherited subprogram is overridden
+ with a primitive subprogram of the protected type, in which case
+ the overriding subprogram shall be subtype conformant with the
+ inherited subprogram and not abstract; or
+
+11.7/2
+ * {AI95-00345-01AI95-00345-01} {AI95-00397-01AI95-00397-01} the
+ inherited subprogram is implemented by a protected subprogram or
+ single entry of the protected type, in which case its prefixed view
+ profile shall be subtype conformant with that of the protected
+ subprogram or entry.
+
+11.8/2
+If neither applies, the inherited subprogram shall be a null procedure.
+In addition to the places where Legality Rules normally apply (see *note
+12.3::), these rules also apply in the private part of an instance of a
+generic unit.
+
+11.f/2
+ Reason: Each inherited subprogram can only have a single
+ implementation (either from overriding a subprogram,
+ implementing a subprogram, or implementing an entry), and must
+ have an implementation unless the subprogram is a null
+ procedure.
+
+11.9/3
+{AI95-00345-01AI95-00345-01} {AI05-0291-1AI05-0291-1} If an inherited
+subprogram is implemented by a protected procedure or an entry, then the
+first parameter of the inherited subprogram shall be of mode out or in
+out, or an access-to-variable parameter. If an inherited subprogram is
+implemented by a protected function, then the first parameter of the
+inherited subprogram shall be of mode in, but not an access-to-variable
+parameter.
+
+11.g/3
+ Reason: For a protected procedure or entry, the protected
+ object can be read or written (see *note 9.5.1::). A
+ subprogram that is implemented by a protected procedure or
+ entry must have a profile which reflects that in order to
+ avoid confusion. Similarly, a protected function has a
+ parameter that is a constant, and the inherited routine should
+ reflect that.
+
+11.10/2
+{AI95-00397-01AI95-00397-01} If a protected subprogram declaration has
+an overriding_indicator, then at the point of the declaration:
+
+11.11/2
+ * if the overriding_indicator is overriding, then the subprogram
+ shall implement an inherited subprogram;
+
+11.12/2
+ * if the overriding_indicator is not overriding, then the subprogram
+ shall not implement any inherited subprogram.
+
+11.13/2
+In addition to the places where Legality Rules normally apply (see *note
+12.3::), these rules also apply in the private part of an instance of a
+generic unit.
+
+11.h/2
+ Discussion: These rules are subtly different than those for
+ subprograms (see *note 8.3.1::) because there cannot be "late"
+ inheritance of primitives from interfaces. Hidden (that is,
+ private) interfaces are prohibited explicitly (see *note
+ 7.3::), as are hidden primitive operations (as private
+ operations of public abstract types are prohibited -- see
+ *note 3.9.3::).
+
+ _Dynamic Semantics_
+
+12
+[The elaboration of a protected declaration elaborates the
+protected_definition. The elaboration of a single_protected_declaration
+(*note 9.4: S0211.) also creates an object of an (anonymous) protected
+type.]
+
+12.a
+ Proof: This is redundant with the general rules for the
+ elaboration of a full_type_declaration and an
+ object_declaration.
+
+13
+[The elaboration of a protected_definition creates the protected type
+and its first subtype;] it also includes the elaboration of the
+component_declarations and protected_operation_declarations in the given
+order.
+
+14
+[As part of the initialization of a protected object, any per-object
+constraints (see *note 3.8::) are elaborated.]
+
+14.a
+ Discussion: We do not mention pragmas since each pragma has
+ its own elaboration rules.
+
+15
+The elaboration of a protected_body has no other effect than to
+establish that protected operations of the type can from then on be
+called without failing the Elaboration_Check.
+
+16
+The content of an object of a given protected type includes:
+
+17
+ * The values of the components of the protected object, including
+ (implicitly) an entry queue for each entry declared for the
+ protected object;
+
+17.a
+ Ramification: "For each entry" implies one queue for each
+ single entry, plus one for each entry of each entry family.
+
+18
+ * A representation of the state of the execution resource associated
+ with the protected object (one such resource is associated with
+ each protected object).
+
+19
+[The execution resource associated with a protected object has to be
+acquired to read or update any components of the protected object; it
+can be acquired (as part of a protected action -- see *note 9.5.1::)
+either for concurrent read-only access, or for exclusive read-write
+access.]
+
+20
+As the first step of the finalization of a protected object, each call
+remaining on any entry queue of the object is removed from its queue and
+Program_Error is raised at the place of the corresponding
+entry_call_statement (*note 9.5.3: S0225.).
+
+20.a
+ Reason: This is analogous to the raising of Tasking_Error in
+ callers of a task that completes before accepting the calls.
+ This situation can only occur due to a requeue (ignoring
+ premature unchecked_deallocation), since any task that has
+ accessibility to a protected object is awaited before
+ finalizing the protected object. For example:
+
+20.b
+ procedure Main is
+ task T is
+ entry E;
+ end T;
+
+20.c
+ task body T is
+ protected PO is
+ entry Ee;
+ end PO;
+
+20.d
+ protected body PO is
+ entry Ee when False is
+ begin
+ null;
+ end Ee;
+ end PO;
+ begin
+ accept E do
+ requeue PO.Ee;
+ end E;
+ end T;
+ begin
+ T.E;
+ end Main;
+
+20.e/3
+ {AI05-0005-1AI05-0005-1} The environment task is queued on
+ PO.Ee when PO is finalized.
+
+20.f
+ In a real example, a server task might park callers on a local
+ protected object for some useful purpose, so we didn't want to
+ disallow this case.
+
+ _Bounded (Run-Time) Errors_
+
+20.1/2
+{AI95-00280-01AI95-00280-01} It is a bounded error to call an entry or
+subprogram of a protected object after that object is finalized. If the
+error is detected, Program_Error is raised. Otherwise, the call
+proceeds normally, which may leave a task queued forever.
+
+20.g/2
+ Reason: This is very similar to the finalization rule. It is
+ a bounded error so that an implementation can avoid the
+ overhead of the check if it can ensure that the call still
+ will operate properly. Such an implementation cannot need to
+ return resources (such as locks) to an executive that it needs
+ to execute calls.
+
+20.h/2
+ This case can happen (and has happened in production code)
+ when a protected object is accessed from the Finalize routine
+ of a type. For example:
+
+20.i/2
+ with Ada.Finalization.Controlled;
+ package Window_Manager is
+ ...
+ type Root_Window is new Ada.Finalization.Controlled with private;
+ type Any_Window is access all Root_Window;
+ ...
+ private
+ ...
+ procedure Finalize (Object : in out Root_Window);
+ ...
+ end Window_Manager;
+
+20.j/2
+ package body Window_Manager is
+ protected type Lock is
+ entry Get_Lock;
+ procedure Free_Lock;
+ ...
+ end Lock;
+
+20.k/2
+ Window_Lock : Lock;
+
+20.l/2
+ procedure Finalize (Object : in out Root_Window) is
+ begin
+ Window_Lock.Get_Lock;
+ ...
+ Window_Lock.Free_Lock;
+ end Finalize;
+ ...
+ A_Window : Any_Window := new Root_Window;
+ end Window_Manager;
+
+20.m/2
+ The environment task will call Window_Lock for the object
+ allocated for A_Window when the collection for Any_Window is
+ finalized, which will happen after the finalization of
+ Window_Lock (because finalization of the package body will
+ occur before that of the package specification).
+
+ NOTES
+
+21/2
+ 13 {AI95-00382-01AI95-00382-01} Within the declaration or body of
+ a protected unit other than in an access_definition, the name of
+ the protected unit denotes the current instance of the unit (see
+ *note 8.6::), rather than the first subtype of the corresponding
+ protected type (and thus the name cannot be used as a
+ subtype_mark).
+
+21.a/2
+ Discussion: {AI95-00382-01AI95-00382-01} It can be used as a
+ subtype_mark in an anonymous access type. In addition, it is
+ possible to refer to some other subtype of the protected type
+ within its body, presuming such a subtype has been declared
+ between the protected_type_declaration and the protected_body.
+
+22
+ 14 A selected_component can be used to denote a discriminant of a
+ protected object (see *note 4.1.3::). Within a protected unit, the
+ name of a discriminant of the protected type denotes the
+ corresponding discriminant of the current instance of the unit.
+
+23/2
+ 15 {AI95-00287-01AI95-00287-01} A protected type is a limited type
+ (see *note 7.5::), and hence precludes use of assignment_statements
+ and predefined equality operators.
+
+24
+ 16 The bodies of the protected operations given in the
+ protected_body define the actions that take place upon calls to the
+ protected operations.
+
+25
+ 17 The declarations in the private part are only visible within
+ the private part and the body of the protected unit.
+
+25.a
+ Reason: Component_declarations are disallowed in a
+ protected_body because, for efficiency, we wish to allow the
+ compiler to determine the size of protected objects (when not
+ dynamic); the compiler cannot necessarily see the body.
+ Furthermore, the semantics of initialization of such objects
+ would be problematic -- we do not wish to give protected
+ objects complex initialization semantics similar to task
+ activation.
+
+25.b
+ The same applies to entry_declarations, since an entry
+ involves an implicit component -- the entry queue.
+
+ _Examples_
+
+26
+Example of declaration of protected type and corresponding body:
+
+27
+ protected type Resource is
+ entry Seize;
+ procedure Release;
+ private
+ Busy : Boolean := False;
+ end Resource;
+
+28
+ protected body Resource is
+ entry Seize when not Busy is
+ begin
+ Busy := True;
+ end Seize;
+
+29
+ procedure Release is
+ begin
+ Busy := False;
+ end Release;
+ end Resource;
+
+30
+Example of a single protected declaration and corresponding body:
+
+31
+ protected Shared_Array is
+ -- Index, Item, and Item_Array are global types
+ function Component (N : in Index) return Item;
+ procedure Set_Component(N : in Index; E : in Item);
+ private
+ Table : Item_Array(Index) := (others => Null_Item);
+ end Shared_Array;
+
+32
+ protected body Shared_Array is
+ function Component(N : in Index) return Item is
+ begin
+ return Table(N);
+ end Component;
+
+33
+ procedure Set_Component(N : in Index; E : in Item) is
+ begin
+ Table(N) := E;
+ end Set_Component;
+ end Shared_Array;
+
+34
+Examples of protected objects:
+
+35
+ Control : Resource;
+ Flags : array(1 .. 100) of Resource;
+
+ _Extensions to Ada 83_
+
+35.a/3
+ {AI05-0299-1AI05-0299-1} This entire subclause is new;
+ protected units do not exist in Ada 83.
+
+ _Extensions to Ada 95_
+
+35.b/2
+ {AI95-00345-01AI95-00345-01} {AI95-00397-01AI95-00397-01}
+ {AI95-00399-01AI95-00399-01} {AI95-00401-01AI95-00401-01}
+ {AI95-00419-01AI95-00419-01} Protected types and single
+ protected objects can be derived from one or more interfaces.
+ Operations declared in the protected type can implement the
+ primitive operations of an interface. Overriding_indicators
+ can be used to specify whether or not a protected operation
+ implements a primitive operation.
+
+ _Wording Changes from Ada 95_
+
+35.c/2
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} Corrigendum:
+ Changed representation clauses to aspect clauses to reflect
+ that they are used for more than just representation.
+
+35.d/2
+ {AI95-00280-01AI95-00280-01} Described what happens when an
+ operation of a finalized protected object is called.
+
+35.e/2
+ {AI95-00287-01AI95-00287-01} Revised the note on operations of
+ protected types to reflect that limited types do have an
+ assignment operation, but not copying (assignment_statements).
+
+35.f/2
+ {AI95-00382-01AI95-00382-01} Revised the note on use of the
+ name of a protected type within itself to reflect the
+ exception for anonymous access types.
+
+ _Incompatibilities With Ada 2005_
+
+35.g/3
+ {AI05-0291-1AI05-0291-1} When an inherited subprogram is
+ implemented by a protected function, the first parameter has
+ to be an in parameter, but not an access-to-variable type.
+ Ada 2005 allowed access-to-variable parameters in this case;
+ the parameter will need to be changed to access-to-constant
+ with the addition of the constant keyword.
+
+ _Extensions to Ada 2005_
+
+35.h/3
+ {AI05-0183-1AI05-0183-1} {AI05-0267-1AI05-0267-1} An optional
+ aspect_specification can be used in a
+ protected_type_declaration, a single_protected_declaration,
+ and a protected_body. This is described in *note 13.1.1::.
+
+ _Wording Changes from Ada 2005_
+
+35.i/3
+ {AI05-0042-1AI05-0042-1} Correction: Clarified that an
+ inherited subprogram of a progenitor is overridden when it is
+ implemented by an entry or subprogram.
+
+35.j/3
+ {AI05-0090-1AI05-0090-1} Correction: Added the missing
+ defining name in the no conflicting primitive operation rule.
+
+\1f
+File: aarm2012.info, Node: 9.5, Next: 9.6, Prev: 9.4, Up: 9
+
+9.5 Intertask Communication
+===========================
+
+1
+The primary means for intertask communication is provided by calls on
+entries and protected subprograms. Calls on protected subprograms allow
+coordinated access to shared data objects. Entry calls allow for
+blocking the caller until a given condition is satisfied (namely, that
+the corresponding entry is open -- see *note 9.5.3::), and then
+communicating data or control information directly with another task or
+indirectly via a shared protected object.
+
+ _Static Semantics_
+
+2/3
+{AI05-0225-1AI05-0225-1} {AI05-0291-1AI05-0291-1} When a name or prefix
+denotes an entry, protected subprogram, or a prefixed view of a
+primitive subprogram of a limited interface whose first parameter is a
+controlling parameter, the name or prefix determines a target object, as
+follows:
+
+2.a/3
+ To be honest: {AI05-0291-1AI05-0291-1} This wording uses
+ "denotes" to mean "denotes a view of an entity" (when the term
+ is used in Legality Rules), and "denotes an entity" (when the
+ term is used in Dynamic Semantics rules). It does not mean
+ "view of a declaration", as that would not include renames (a
+ renames is not an entry or protected subprogram).
+
+3/3
+ * {AI05-0291-1AI05-0291-1} If it is a direct_name or expanded name
+ that denotes the declaration (or body) of the operation, then the
+ target object is implicitly specified to be the current instance of
+ the task or protected unit immediately enclosing the operation; a
+ call using such a name is defined to be an internal call;
+
+4/3
+ * {AI05-0291-1AI05-0291-1} If it is a selected_component that is not
+ an expanded name, then the target object is explicitly specified to
+ be the object denoted by the prefix of the name; a call using such
+ a name is defined to be an external call;
+
+4.a
+ Discussion: For example:
+
+4.b
+ protected type Pt is
+ procedure Op1;
+ procedure Op2;
+ end Pt;
+
+4.c
+ PO : Pt;
+ Other_Object : Some_Other_Protected_Type;
+
+4.d
+ protected body Pt is
+ procedure Op1 is begin ... end Op1;
+
+4.e
+ procedure Op2 is
+ begin
+ Op1; -- An internal call.
+ Pt.Op1; -- Another internal call.
+ PO.Op1; -- An external call. It the current instance is PO, then
+ -- this is a bounded error (see *note 9.5.1::).
+ Other_Object.Some_Op; -- An external call.
+ end Op2;
+ end Pt;
+
+5/3
+ * {AI05-0291-1AI05-0291-1} If the name or prefix is a dereference
+ (implicit or explicit) of an access-to-protected-subprogram value,
+ then the target object is determined by the prefix of the Access
+ attribute_reference that produced the access value originally; a
+ call using such a name is defined to be an external call;
+
+6
+ * If the name or prefix denotes a subprogram_renaming_declaration,
+ then the target object is as determined by the name of the renamed
+ entity.
+
+6.1/3
+{AI05-0291-1AI05-0291-1} A call on an entry or a protected subprogram
+either uses a name or prefix that determines a target object implicitly,
+as above, or is a call on (a non-prefixed view of) a primitive
+subprogram of a limited interface whose first parameter is a controlling
+parameter, in which case the target object is identified explicitly by
+the first parameter. This latter case is an external call.
+
+7
+A corresponding definition of target object applies to a
+requeue_statement (see *note 9.5.4::), with a corresponding distinction
+between an internal requeue and an external requeue.
+
+ _Legality Rules_
+
+7.1/3
+{AI95-00345-01AI95-00345-01} {AI05-0225-1AI05-0225-1}
+{AI05-0291-1AI05-0291-1} If a name or prefix determines a target object,
+and the name denotes a protected entry or procedure, then the target
+object shall be a variable, unless the prefix is for an
+attribute_reference to the Count attribute (see *note 9.9::).
+
+7.a/3
+ Reason: {AI05-0225-1AI05-0225-1} The point is to prevent any
+ calls to such a name whose target object is a constant view of
+ a protected object, directly, or via an access value, renames,
+ or generic formal subprogram. It is, however, legal to say
+ P'Count in a protected function body, even though the
+ protected object is a constant view there.
+
+7.b/3
+ Ramification: {AI05-0291-1AI05-0291-1} This rule does not
+ apply to calls that are not to a prefixed view. Specifically
+ a "normal" call to a primitive operation of a limited
+ interface is not covered by this rule. In that case, the
+ normal parameter passing mode checks will prevent passing a
+ constant protected object to an operation implemented by a
+ protected entry or procedure as the mode is required to be in
+ out or out.
+
+ _Dynamic Semantics_
+
+8
+Within the body of a protected operation, the current instance (see
+*note 8.6::) of the immediately enclosing protected unit is determined
+by the target object specified (implicitly or explicitly) in the call
+(or requeue) on the protected operation.
+
+8.a
+ To be honest: The current instance is defined in the same way
+ within the body of a subprogram declared immediately within a
+ protected_body.
+
+9
+Any call on a protected procedure or entry of a target protected object
+is defined to be an update to the object, as is a requeue on such an
+entry.
+
+9.a
+ Reason: Read/write access to the components of a protected
+ object is granted while inside the body of a protected
+ procedure or entry. Also, any protected entry call can change
+ the value of the Count attribute, which represents an update.
+ Any protected procedure call can result in servicing the
+ entries, which again might change the value of a Count
+ attribute.
+
+ _Syntax_
+
+10/3
+ {AI05-0030-2AI05-0030-2} {AI05-0215-1AI05-0215-1}
+ synchronization_kind ::=
+ By_Entry | By_Protected_Procedure | Optional
+
+ _Static Semantics_
+
+11/3
+{AI05-0215-1AI05-0215-1} For the declaration of a primitive procedure of
+a synchronized tagged type the following language-defined representation
+aspect may be specified with an aspect_specification (see *note
+13.1.1::):
+
+12/3
+Synchronization
+ If specified, the aspect definition shall be a
+ synchronization_kind.
+
+12.a/3
+ Aspect Description for Synchronization: Defines whether a
+ given primitive operation of a synchronized interface must be
+ implemented by an entry or protected procedure.
+
+13/3
+{AI05-0030-2AI05-0030-2} {AI05-0215-1AI05-0215-1} Inherited subprograms
+inherit the Synchronization aspect, if any, from the corresponding
+subprogram of the parent or progenitor type. If an overriding operation
+does not have a directly specified Synchronization aspect then the
+Synchronization aspect of the inherited operation is inherited by the
+overriding operation.
+
+ _Legality Rules_
+
+14/3
+{AI05-0030-2AI05-0030-2} {AI05-0215-1AI05-0215-1} The
+synchronization_kind By_Protected_Procedure shall not be applied to a
+primitive procedure of a task interface.
+
+15/3
+{AI05-0030-2AI05-0030-2} {AI05-0215-1AI05-0215-1} A procedure for which
+the specified synchronization_kind is By_Entry shall be implemented by
+an entry. A procedure for which the specified synchronization_kind is
+By_Protected_Procedure shall be implemented by a protected procedure. A
+procedure for which the specified synchronization_kind is Optional may
+be implemented by an entry or by a procedure (including a protected
+procedure).
+
+16/3
+{AI05-0030-2AI05-0030-2} {AI05-0215-1AI05-0215-1} If a primitive
+procedure overrides an inherited operation for which the Synchronization
+aspect has been specified to be By_Entry or By_Protected_Procedure, then
+any specification of the aspect Synchronization applied to the
+overriding operation shall have the same synchronization_kind.
+
+17/3
+{AI05-0030-2AI05-0030-2} In addition to the places where Legality Rules
+normally apply (see *note 12.3::), these rules also apply in the private
+part of an instance of a generic unit.
+
+ NOTES
+
+18/3
+ 18 {AI05-0030-2AI05-0030-2} {AI05-0215-1AI05-0215-1} The
+ synchronization_kind By_Protected_Procedure implies that the
+ operation will not block.
+
+ _Wording Changes from Ada 95_
+
+18.a/2
+ {AI95-00345-01AI95-00345-01} Added a Legality Rule to make it
+ crystal-clear that the protected object of an entry or
+ procedure call must be a variable. This rule was implied by
+ the Dynamic Semantics here, along with the Static Semantics of
+ *note 3.3::, but it is much better to explicitly say it.
+ While many implementations have gotten this wrong, this is not
+ an incompatibility -- allowing updates of protected constants
+ has always been wrong.
+
+ _Extensions to Ada 2005_
+
+18.b/3
+ {AI05-0030-2AI05-0030-2} {AI05-0215-1AI05-0215-1} Added the
+ Synchronization aspect to allow specifying that an interface
+ procedure is really an entry or a protected procedure.
+
+ _Wording Changes from Ada 2005_
+
+18.c/3
+ {AI05-0225-1AI05-0225-1} Correction: Clarified that the target
+ object of any name denoted a protected procedure or entry can
+ never be a constant (other than for the 'Count attribute).
+ This closes holes involving calls to access-to-protected,
+ renaming as a procedure, and generic formal subprograms.
+
+* Menu:
+
+* 9.5.1 :: Protected Subprograms and Protected Actions
+* 9.5.2 :: Entries and Accept Statements
+* 9.5.3 :: Entry Calls
+* 9.5.4 :: Requeue Statements
+
+\1f
+File: aarm2012.info, Node: 9.5.1, Next: 9.5.2, Up: 9.5
+
+9.5.1 Protected Subprograms and Protected Actions
+-------------------------------------------------
+
+1
+A protected subprogram is a subprogram declared immediately within a
+protected_definition. Protected procedures provide exclusive read-write
+access to the data of a protected object; protected functions provide
+concurrent read-only access to the data.
+
+1.a
+ Ramification: A subprogram declared immediately within a
+ protected_body is not a protected subprogram; it is an
+ intrinsic subprogram. See *note 6.3.1::, "*note 6.3.1::
+ Conformance Rules".
+
+ _Static Semantics_
+
+2
+[Within the body of a protected function (or a function declared
+immediately within a protected_body), the current instance of the
+enclosing protected unit is defined to be a constant (that is, its
+subcomponents may be read but not updated). Within the body of a
+protected procedure (or a procedure declared immediately within a
+protected_body), and within an entry_body, the current instance is
+defined to be a variable (updating is permitted).]
+
+2.a.1/3
+ Proof: {AI05-0120-1AI05-0120-1} All constant views are defined
+ in *note 3.3::, "*note 3.3:: Objects and Named Numbers",
+ anything not named there is a variable view.
+
+2.a
+ Ramification: The current instance is like an implicit
+ parameter, of mode in for a protected function, and of mode in
+ out for a protected procedure (or protected entry).
+
+ _Dynamic Semantics_
+
+3
+For the execution of a call on a protected subprogram, the evaluation of
+the name or prefix and of the parameter associations, and any assigning
+back of in out or out parameters, proceeds as for a normal subprogram
+call (see *note 6.4::). If the call is an internal call (see *note
+9.5::), the body of the subprogram is executed as for a normal
+subprogram call. If the call is an external call, then the body of the
+subprogram is executed as part of a new protected action on the target
+protected object; the protected action completes after the body of the
+subprogram is executed. [A protected action can also be started by an
+entry call (see *note 9.5.3::).]
+
+4
+A new protected action is not started on a protected object while
+another protected action on the same protected object is underway,
+unless both actions are the result of a call on a protected function.
+This rule is expressible in terms of the execution resource associated
+with the protected object:
+
+5
+ * Starting a protected action on a protected object corresponds to
+ acquiring the execution resource associated with the protected
+ object, either for concurrent read-only access if the protected
+ action is for a call on a protected function, or for exclusive
+ read-write access otherwise;
+
+6
+ * Completing the protected action corresponds to releasing the
+ associated execution resource.
+
+7
+[After performing an operation on a protected object other than a call
+on a protected function, but prior to completing the associated
+protected action, the entry queues (if any) of the protected object are
+serviced (see *note 9.5.3::).]
+
+ _Bounded (Run-Time) Errors_
+
+8
+During a protected action, it is a bounded error to invoke an operation
+that is potentially blocking. The following are defined to be
+potentially blocking operations:
+
+8.a
+ Reason: Some of these operations are not directly blocking.
+ However, they are still treated as bounded errors during a
+ protected action, because allowing them might impose an
+ undesirable implementation burden.
+
+9
+ * a select_statement;
+
+10
+ * an accept_statement;
+
+11
+ * an entry_call_statement;
+
+12
+ * a delay_statement;
+
+13
+ * an abort_statement;
+
+14
+ * task creation or activation;
+
+15
+ * an external call on a protected subprogram (or an external requeue)
+ with the same target object as that of the protected action;
+
+15.a
+ Reason: This is really a deadlocking call, rather than a
+ blocking call, but we include it in this list for simplicity.
+
+16
+ * a call on a subprogram whose body contains a potentially blocking
+ operation.
+
+16.a
+ Reason: This allows an implementation to check and raise
+ Program_Error as soon as a subprogram is called, rather than
+ waiting to find out whether it actually reaches the
+ potentially blocking operation. This in turn allows the
+ potentially blocking operation check to be performed prior to
+ run time in some environments.
+
+17
+If the bounded error is detected, Program_Error is raised. If not
+detected, the bounded error might result in deadlock or a (nested)
+protected action on the same target object.
+
+17.a/2
+ Discussion: {AI95-00305-01AI95-00305-01} By "nested protected
+ action", we mean that an additional protected action can be
+ started by another task on the same protected object. This
+ means that mutual exclusion may be broken in this bounded
+ error case. A way to ensure that this does not happen is to
+ use pragma Detect_Blocking (see *note H.5::).
+
+18
+Certain language-defined subprograms are potentially blocking. In
+particular, the subprograms of the language-defined input-output
+packages that manipulate files (implicitly or explicitly) are
+potentially blocking. Other potentially blocking subprograms are
+identified where they are defined. When not specified as potentially
+blocking, a language-defined subprogram is nonblocking.
+
+18.a/2
+ Discussion: {AI95-00178-01AI95-00178-01} Any subprogram in a
+ language-defined input-output package that has a file
+ parameter or result or operates on a default file is
+ considered to manipulate a file. An instance of a
+ language-defined input-output generic package provides
+ subprograms that are covered by this rule. The only
+ subprograms in language-defined input-output packages not
+ covered by this rule (and thus not potentially blocking) are
+ the Get and Put routines that take string parameters defined
+ in the packages nested in Text_IO.
+
+ NOTES
+
+19
+ 19 If two tasks both try to start a protected action on a
+ protected object, and at most one is calling a protected function,
+ then only one of the tasks can proceed. Although the other task
+ cannot proceed, it is not considered blocked, and it might be
+ consuming processing resources while it awaits its turn. There is
+ no language-defined ordering or queuing presumed for tasks
+ competing to start a protected action -- on a multiprocessor such
+ tasks might use busy-waiting; for monoprocessor considerations, see
+ *note D.3::, "*note D.3:: Priority Ceiling Locking".
+
+19.a
+ Discussion: The intended implementation on a multi-processor
+ is in terms of "spin locks" -- the waiting task will spin.
+
+20
+ 20 The body of a protected unit may contain declarations and
+ bodies for local subprograms. These are not visible outside the
+ protected unit.
+
+21
+ 21 The body of a protected function can contain internal calls on
+ other protected functions, but not protected procedures, because
+ the current instance is a constant. On the other hand, the body of
+ a protected procedure can contain internal calls on both protected
+ functions and procedures.
+
+22
+ 22 From within a protected action, an internal call on a protected
+ subprogram, or an external call on a protected subprogram with a
+ different target object is not considered a potentially blocking
+ operation.
+
+22.a
+ Reason: This is because a task is not considered blocked while
+ attempting to acquire the execution resource associated with a
+ protected object. The acquisition of such a resource is
+ rather considered part of the normal competition for execution
+ resources between the various tasks that are ready. External
+ calls that turn out to be on the same target object are
+ considered potentially blocking, since they can deadlock the
+ task indefinitely.
+
+22.1/2
+ 23 {AI95-00305-01AI95-00305-01} The pragma Detect_Blocking may be
+ used to ensure that all executions of potentially blocking
+ operations during a protected action raise Program_Error. See
+ *note H.5::.
+
+ _Examples_
+
+23
+Examples of protected subprogram calls (see *note 9.4::):
+
+24
+ Shared_Array.Set_Component(N, E);
+ E := Shared_Array.Component(M);
+ Control.Release;
+
+ _Wording Changes from Ada 95_
+
+24.a/2
+ {AI95-00305-01AI95-00305-01} Added a note pointing out the
+ existence of pragma Detect_Blocking. This pragma can be used
+ to ensure portable (somewhat pessimistic) behavior of
+ protected actions by converting the Bounded Error into a
+ required check.
+
+\1f
+File: aarm2012.info, Node: 9.5.2, Next: 9.5.3, Prev: 9.5.1, Up: 9.5
+
+9.5.2 Entries and Accept Statements
+-----------------------------------
+
+1
+Entry_declarations, with the corresponding entry_bodies or
+accept_statements, are used to define potentially queued operations on
+tasks and protected objects.
+
+ _Syntax_
+
+2/3
+ {AI95-00397-01AI95-00397-01} {AI05-0183-1AI05-0183-1}
+ entry_declaration ::=
+ [overriding_indicator]
+ entry defining_identifier [(discrete_subtype_definition)]
+ parameter_profile
+ [aspect_specification];
+
+3
+ accept_statement ::=
+ accept entry_direct_name [(entry_index)] parameter_profile [do
+ handled_sequence_of_statements
+ end [entry_identifier]];
+
+3.a
+ Reason: We cannot use defining_identifier for
+ accept_statements. Although an accept_statement is sort of
+ like a body, it can appear nested within a block_statement,
+ and therefore be hidden from its own entry by an outer
+ homograph.
+
+4
+ entry_index ::= expression
+
+5
+ entry_body ::=
+ entry defining_identifier entry_body_formal_part
+ entry_barrier is
+ declarative_part
+ begin
+ handled_sequence_of_statements
+ end [entry_identifier];
+
+5.a/2
+ Discussion: {AI95-00397-01AI95-00397-01} We don't allow an
+ overriding_indicator on an entry_body because entries always
+ implement procedures at the point of the type declaration;
+ there is no late implementation. And we don't want to have to
+ think about overriding_indicators on accept_statements.
+
+6
+ entry_body_formal_part ::= [(entry_index_specification)]
+ parameter_profile
+
+7
+ entry_barrier ::= when condition
+
+8
+ entry_index_specification ::= for defining_identifier in
+ discrete_subtype_definition
+
+9
+ If an entry_identifier appears at the end of an accept_statement,
+ it shall repeat the entry_direct_name (*note 4.1: S0092.). If an
+ entry_identifier appears at the end of an entry_body (*note 9.5.2:
+ S0221.), it shall repeat the defining_identifier (*note 3.1:
+ S0022.).
+
+10
+ [An entry_declaration is allowed only in a protected or task
+ declaration.]
+
+10.a
+ Proof: This follows from the BNF.
+
+10.1/2
+ {AI95-00397-01AI95-00397-01} An overriding_indicator is not allowed
+ in an entry_declaration that includes a
+ discrete_subtype_definition.
+
+10.a.1/2
+ Reason: An entry family can never implement something, so
+ allowing an indicator is felt by the majority of the ARG to be
+ redundant.
+
+ _Name Resolution Rules_
+
+11
+In an accept_statement, the expected profile for the entry_direct_name
+is that of the entry_declaration (*note 9.5.2: S0218.); the expected
+type for an entry_index is that of the subtype defined by the
+discrete_subtype_definition (*note 3.6: S0055.) of the corresponding
+entry_declaration (*note 9.5.2: S0218.).
+
+12
+Within the handled_sequence_of_statements of an accept_statement, if a
+selected_component (*note 4.1.3: S0098.) has a prefix that denotes the
+corresponding entry_declaration (*note 9.5.2: S0218.), then the entity
+denoted by the prefix is the accept_statement (*note 9.5.2: S0219.), and
+the selected_component (*note 4.1.3: S0098.) is interpreted as an
+expanded name (see *note 4.1.3::)[; the selector_name of the
+selected_component (*note 4.1.3: S0098.) has to be the identifier for
+some formal parameter of the accept_statement (*note 9.5.2: S0219.)].
+
+12.a
+ Proof: The only declarations that occur immediately within the
+ declarative region of an accept_statement are those for its
+ formal parameters.
+
+ _Legality Rules_
+
+13
+An entry_declaration in a task declaration shall not contain a
+specification for an access parameter (see *note 3.10::).
+
+13.a
+ Reason: Access parameters for task entries would require a
+ complex implementation. For example:
+
+13.b
+ task T is
+ entry E(Z : access Integer); -- Illegal!
+ end T;
+
+13.c
+ task body T is
+ begin
+ declare
+ type A is access all Integer;
+ X : A;
+ Int : aliased Integer;
+ task Inner;
+ task body Inner is
+ begin
+ T.E(Int'Access);
+ end Inner;
+ begin
+ accept E(Z : access Integer) do
+ X := A(Z); -- Accessibility_Check
+ end E;
+ end;
+ end T;
+
+13.d
+ Implementing the Accessibility_Check inside the
+ accept_statement for E is difficult, since one does not know
+ whether the entry caller is calling from inside the
+ immediately enclosing declare block or from outside it. This
+ means that the lexical nesting level associated with the
+ designated object is not sufficient to determine whether the
+ Accessibility_Check should pass or fail.
+
+13.e
+ Note that such problems do not arise with protected entries,
+ because entry_bodies are always nested immediately within the
+ protected_body; they cannot be further nested as can
+ accept_statements, nor can they be called from within the
+ protected_body (since no entry calls are permitted inside a
+ protected_body).
+
+13.1/2
+{AI95-00397-01AI95-00397-01} If an entry_declaration has an
+overriding_indicator, then at the point of the declaration:
+
+13.2/2
+ * if the overriding_indicator is overriding, then the entry shall
+ implement an inherited subprogram;
+
+13.3/2
+ * if the overriding_indicator is not overriding, then the entry shall
+ not implement any inherited subprogram.
+
+13.4/2
+In addition to the places where Legality Rules normally apply (see *note
+12.3::), these rules also apply in the private part of an instance of a
+generic unit.
+
+13.f/2
+ Discussion: These rules are subtly different than those for
+ subprograms (see *note 8.3.1::) because there cannot be "late"
+ inheritance of primitives from interfaces. Hidden (that is,
+ private) interfaces are prohibited explicitly (see *note
+ 7.3::), as are hidden primitive operations (as private
+ operations of public abstract types are prohibited -- see
+ *note 3.9.3::).
+
+14
+For an accept_statement, the innermost enclosing body shall be a
+task_body, and the entry_direct_name (*note 4.1: S0092.) shall denote an
+entry_declaration (*note 9.5.2: S0218.) in the corresponding task
+declaration; the profile of the accept_statement (*note 9.5.2: S0219.)
+shall conform fully to that of the corresponding entry_declaration
+(*note 9.5.2: S0218.). An accept_statement (*note 9.5.2: S0219.) shall
+have a parenthesized entry_index (*note 9.5.2: S0220.) if and only if
+the corresponding entry_declaration (*note 9.5.2: S0218.) has a
+discrete_subtype_definition (*note 3.6: S0055.).
+
+15
+An accept_statement shall not be within another accept_statement that
+corresponds to the same entry_declaration (*note 9.5.2: S0218.), nor
+within an asynchronous_select (*note 9.7.4: S0241.) inner to the
+enclosing task_body.
+
+15.a
+ Reason: Accept_statements are required to be immediately
+ within the enclosing task_body (as opposed to being in a
+ nested subprogram) to ensure that a nested task does not
+ attempt to accept the entry of its enclosing task. We
+ considered relaxing this restriction, either by making the
+ check a run-time check, or by allowing a nested task to accept
+ an entry of its enclosing task. However, neither change
+ seemed to provide sufficient benefit to justify the additional
+ implementation burden.
+
+15.b
+ Nested accept_statements for the same entry (or entry family)
+ are prohibited to ensure that there is no ambiguity in the
+ resolution of an expanded name for a formal parameter of the
+ entry. This could be relaxed by allowing the inner one to
+ hide the outer one from all visibility, but again the small
+ added benefit didn't seem to justify making the change for Ada
+ 95.
+
+15.c
+ Accept_statements are not permitted within asynchronous_select
+ statements to simplify the semantics and implementation: an
+ accept_statement in an abortable_part could result in
+ Tasking_Error being propagated from an entry call even though
+ the target task was still callable; implementations that use
+ multiple tasks implicitly to implement an asynchronous_select
+ might have trouble supporting "up-level" accepts.
+ Furthermore, if accept_statements were permitted in the
+ abortable_part, a task could call its own entry and then
+ accept it in the abortable_part, leading to rather unusual and
+ possibly difficult-to-specify semantics.
+
+16
+An entry_declaration of a protected unit requires a completion[, which
+shall be an entry_body,] and every entry_body (*note 9.5.2: S0221.)
+shall be the completion of an entry_declaration (*note 9.5.2: S0218.) of
+a protected unit. The profile of the entry_body (*note 9.5.2: S0221.)
+shall conform fully to that of the corresponding declaration.
+
+16.a
+ Ramification: An entry_declaration, unlike a
+ subprogram_declaration, cannot be completed with a
+ renaming_declaration (*note 8.5: S0199.).
+
+16.b/3
+ To be honest: {AI05-0229-1AI05-0229-1} If the implementation
+ supports it, the entry body can be imported (using aspect
+ Import, see *note B.1::), in which case no explicit entry_body
+ is allowed.
+
+16.c
+ Discussion: The above applies only to protected entries, which
+ are the only ones completed with entry_bodies. Task entries
+ have corresponding accept_statements instead of having
+ entry_bodies, and we do not consider an accept_statement to be
+ a "completion," because a task entry_declaration is allowed to
+ have zero, one, or more than one corresponding
+ accept_statements.
+
+17
+An entry_body_formal_part shall have an entry_index_specification (*note
+9.5.2: S0224.) if and only if the corresponding entry_declaration (*note
+9.5.2: S0218.) has a discrete_subtype_definition (*note 3.6: S0055.).
+In this case, the discrete_subtype_definition (*note 3.6: S0055.)s of
+the entry_declaration (*note 9.5.2: S0218.) and the
+entry_index_specification (*note 9.5.2: S0224.) shall fully conform to
+one another (see *note 6.3.1::).
+
+18
+A name that denotes a formal parameter of an entry_body is not allowed
+within the entry_barrier of the entry_body.
+
+ _Static Semantics_
+
+19
+The parameter modes defined for parameters in the parameter_profile of
+an entry_declaration are the same as for a subprogram_declaration and
+have the same meaning (see *note 6.2::).
+
+19.a
+ Discussion: Note that access parameters are not allowed for
+ task entries (see above).
+
+20
+An entry_declaration with a discrete_subtype_definition (see *note
+3.6::) declares a family of distinct entries having the same profile,
+with one such entry for each value of the entry index subtype defined by
+the discrete_subtype_definition (*note 3.6: S0055.). [A name for an
+entry of a family takes the form of an indexed_component, where the
+prefix denotes the entry_declaration for the family, and the index value
+identifies the entry within the family.] The term single entry is used
+to refer to any entry other than an entry of an entry family.
+
+21
+In the entry_body for an entry family, the entry_index_specification
+declares a named constant whose subtype is the entry index subtype
+defined by the corresponding entry_declaration; the value of the named
+entry index identifies which entry of the family was called.
+
+21.a
+ Ramification: The discrete_subtype_definition of the
+ entry_index_specification is not elaborated; the subtype of
+ the named constant declared is defined by the
+ discrete_subtype_definition of the corresponding
+ entry_declaration, which is elaborated, either when the type
+ is declared, or when the object is created, if its constraint
+ is per-object.
+
+ _Dynamic Semantics_
+
+22/1
+{8652/00028652/0002} {AI95-00171-01AI95-00171-01} The elaboration of an
+entry_declaration for an entry family consists of the elaboration of the
+discrete_subtype_definition (*note 3.6: S0055.), as described in *note
+3.8::. The elaboration of an entry_declaration (*note 9.5.2: S0218.)
+for a single entry has no effect.
+
+22.a/3
+ Discussion: {AI05-0299-1AI05-0299-1} The elaboration of the
+ declaration of a protected subprogram has no effect, as
+ specified in subclause *note 6.1::. The default
+ initialization of an object of a task or protected type is
+ covered in *note 3.3.1::.
+
+23
+[The actions to be performed when an entry is called are specified by
+the corresponding accept_statement (*note 9.5.2: S0219.)s (if any) for
+an entry of a task unit, and by the corresponding entry_body (*note
+9.5.2: S0221.) for an entry of a protected unit.]
+
+24
+For the execution of an accept_statement, the entry_index, if any, is
+first evaluated and converted to the entry index subtype; this index
+value identifies which entry of the family is to be accepted. Further
+execution of the accept_statement is then blocked until a caller of the
+corresponding entry is selected (see *note 9.5.3::), whereupon the
+handled_sequence_of_statements, if any, of the accept_statement is
+executed, with the formal parameters associated with the corresponding
+actual parameters of the selected entry call. Upon completion of the
+handled_sequence_of_statements, the accept_statement completes and is
+left. When an exception is propagated from the
+handled_sequence_of_statements of an accept_statement, the same
+exception is also raised by the execution of the corresponding
+entry_call_statement.
+
+24.a
+ Ramification: This is in addition to propagating it to the
+ construct containing the accept_statement. In other words,
+ for a rendezvous, the raising splits in two, and continues
+ concurrently in both tasks.
+
+24.b
+ The caller gets a new occurrence; this isn't considered
+ propagation.
+
+24.c
+ Note that we say "propagated from the
+ handled_sequence_of_statements of an accept_statement", not
+ "propagated from an accept_statement." The latter would be
+ wrong -- we don't want exceptions propagated by the
+ entry_index to be sent to the caller (there is none yet!).
+
+25
+The above interaction between a calling task and an accepting task is
+called a rendezvous. [After a rendezvous, the two tasks continue their
+execution independently.]
+
+26
+[An entry_body is executed when the condition of the entry_barrier
+evaluates to True and a caller of the corresponding single entry, or
+entry of the corresponding entry family, has been selected (see *note
+9.5.3::).] For the execution of the entry_body (*note 9.5.2: S0221.),
+the declarative_part (*note 3.11: S0086.) of the entry_body (*note
+9.5.2: S0221.) is elaborated, and the handled_sequence_of_statements
+(*note 11.2: S0265.) of the body is executed, as for the execution of a
+subprogram_body. The value of the named entry index, if any, is
+determined by the value of the entry index specified in the entry_name
+of the selected entry call (or intermediate requeue_statement (*note
+9.5.4: S0226.) -- see *note 9.5.4::).
+
+26.a
+ To be honest: If the entry had been renamed as a subprogram,
+ and the call was a procedure_call_statement using the name
+ declared by the renaming, the entry index (if any) comes from
+ the entry name specified in the
+ subprogram_renaming_declaration.
+
+ NOTES
+
+27
+ 24 A task entry has corresponding accept_statements (zero or
+ more), whereas a protected entry has a corresponding entry_body
+ (exactly one).
+
+28
+ 25 A consequence of the rule regarding the allowed placements of
+ accept_statements is that a task can execute accept_statements only
+ for its own entries.
+
+29/2
+ 26 {AI95-00318-02AI95-00318-02} A return statement (see *note
+ 6.5::) or a requeue_statement (see *note 9.5.4::) may be used to
+ complete the execution of an accept_statement or an entry_body.
+
+29.a
+ Ramification: An accept_statement need not have a
+ handled_sequence_of_statements even if the corresponding entry
+ has parameters. Equally, it can have a
+ handled_sequence_of_statements even if the corresponding entry
+ has no parameters.
+
+29.b
+ Ramification: A single entry overloads a subprogram, an
+ enumeration literal, or another single entry if they have the
+ same defining_identifier. Overloading is not allowed for
+ entry family names. A single entry or an entry of an entry
+ family can be renamed as a procedure as explained in *note
+ 8.5.4::.
+
+30
+ 27 The condition in the entry_barrier may reference anything
+ visible except the formal parameters of the entry. This includes
+ the entry index (if any), the components (including discriminants)
+ of the protected object, the Count attribute of an entry of that
+ protected object, and data global to the protected unit.
+
+31
+ The restriction against referencing the formal parameters within an
+ entry_barrier ensures that all calls of the same entry see the same
+ barrier value. If it is necessary to look at the parameters of an
+ entry call before deciding whether to handle it, the entry_barrier
+ can be "when True" and the caller can be requeued (on some private
+ entry) when its parameters indicate that it cannot be handled
+ immediately.
+
+ _Examples_
+
+32
+Examples of entry declarations:
+
+33
+ entry Read(V : out Item);
+ entry Seize;
+ entry Request(Level)(D : Item); -- a family of entries
+
+34
+Examples of accept statements:
+
+35
+ accept Shut_Down;
+
+36
+ accept Read(V : out Item) do
+ V := Local_Item;
+ end Read;
+
+37
+ accept Request(Low)(D : Item) do
+ ...
+ end Request;
+
+ _Extensions to Ada 83_
+
+37.a
+ The syntax rule for entry_body is new.
+
+37.b
+ Accept_statements can now have exception_handlers.
+
+ _Wording Changes from Ada 95_
+
+37.c/2
+ {8652/00028652/0002} {AI95-00171-01AI95-00171-01} Corrigendum:
+ Clarified the elaboration of per-object constraints.
+
+37.d/2
+ {AI95-00397-01AI95-00397-01} Overriding_indicators can be used
+ on entries; this is only useful when a task or protected type
+ inherits from an interface.
+
+ _Extensions to Ada 2005_
+
+37.e/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in an entry_declaration. This is described in *note
+ 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 9.5.3, Next: 9.5.4, Prev: 9.5.2, Up: 9.5
+
+9.5.3 Entry Calls
+-----------------
+
+1
+[An entry_call_statement (an entry call) can appear in various
+contexts.] A simple entry call is a stand-alone statement that
+represents an unconditional call on an entry of a target task or a
+protected object. [Entry calls can also appear as part of
+select_statements (see *note 9.7::).]
+
+ _Syntax_
+
+2
+ entry_call_statement ::= entry_name [actual_parameter_part];
+
+ _Name Resolution Rules_
+
+3
+The entry_name given in an entry_call_statement shall resolve to denote
+an entry. The rules for parameter associations are the same as for
+subprogram calls (see *note 6.4:: and *note 6.4.1::).
+
+ _Static Semantics_
+
+4
+[The entry_name of an entry_call_statement specifies (explicitly or
+implicitly) the target object of the call, the entry or entry family,
+and the entry index, if any (see *note 9.5::).]
+
+ _Dynamic Semantics_
+
+5
+Under certain circumstances (detailed below), an entry of a task or
+protected object is checked to see whether it is open or closed:
+
+6/3
+ * {AI05-0264-1AI05-0264-1} An entry of a task is open if the task is
+ blocked on an accept_statement that corresponds to the entry (see
+ *note 9.5.2::), or on a selective_accept (see *note 9.7.1::) with
+ an open accept_alternative that corresponds to the entry;
+ otherwise, it is closed.
+
+7/3
+ * {AI05-0264-1AI05-0264-1} An entry of a protected object is open if
+ the condition of the entry_barrier of the corresponding entry_body
+ evaluates to True; otherwise, it is closed. If the evaluation of
+ the condition propagates an exception, the exception Program_Error
+ is propagated to all current callers of all entries of the
+ protected object.
+
+7.a
+ Reason: An exception during barrier evaluation is considered
+ essentially a fatal error. All current entry callers are
+ notified with a Program_Error. In a fault-tolerant system, a
+ protected object might provide a Reset protected procedure, or
+ equivalent, to support attempts to restore such a "broken"
+ protected object to a reasonable state.
+
+7.b
+ Discussion: Note that the definition of when a task entry is
+ open is based on the state of the (accepting) task, whereas
+ the "openness" of a protected entry is defined only when it is
+ explicitly checked, since the barrier expression needs to be
+ evaluated. Implementation permissions are given (below) to
+ allow implementations to evaluate the barrier expression more
+ or less often than it is checked, but the basic semantic model
+ presumes it is evaluated at the times when it is checked.
+
+8
+For the execution of an entry_call_statement, evaluation of the name and
+of the parameter associations is as for a subprogram call (see *note
+6.4::). The entry call is then issued: For a call on an entry of a
+protected object, a new protected action is started on the object (see
+*note 9.5.1::). The named entry is checked to see if it is open; if
+open, the entry call is said to be selected immediately, and the
+execution of the call proceeds as follows:
+
+9
+ * For a call on an open entry of a task, the accepting task becomes
+ ready and continues the execution of the corresponding
+ accept_statement (see *note 9.5.2::).
+
+10
+ * For a call on an open entry of a protected object, the
+ corresponding entry_body is executed (see *note 9.5.2::) as part of
+ the protected action.
+
+11
+If the accept_statement or entry_body completes other than by a requeue
+(see *note 9.5.4::), return is made to the caller (after servicing the
+entry queues -- see below); any necessary assigning back of formal to
+actual parameters occurs, as for a subprogram call (see *note 6.4.1::);
+such assignments take place outside of any protected action.
+
+11.a
+ Ramification: The return to the caller will generally not
+ occur until the protected action completes, unless some other
+ thread of control is given the job of completing the protected
+ action and releasing the associated execution resource.
+
+12
+If the named entry is closed, the entry call is added to an entry queue
+(as part of the protected action, for a call on a protected entry), and
+the call remains queued until it is selected or cancelled; there is a
+separate (logical) entry queue for each entry of a given task or
+protected object [(including each entry of an entry family)].
+
+13
+When a queued call is selected, it is removed from its entry queue.
+Selecting a queued call from a particular entry queue is called
+servicing the entry queue. An entry with queued calls can be serviced
+under the following circumstances:
+
+14
+ * When the associated task reaches a corresponding accept_statement,
+ or a selective_accept with a corresponding open accept_alternative;
+
+15
+ * If after performing, as part of a protected action on the
+ associated protected object, an operation on the object other than
+ a call on a protected function, the entry is checked and found to
+ be open.
+
+16
+If there is at least one call on a queue corresponding to an open entry,
+then one such call is selected according to the entry queuing policy in
+effect (see below), and the corresponding accept_statement or entry_body
+is executed as above for an entry call that is selected immediately.
+
+17
+The entry queuing policy controls selection among queued calls both for
+task and protected entry queues. The default entry queuing policy is to
+select calls on a given entry queue in order of arrival. If calls from
+two or more queues are simultaneously eligible for selection, the
+default entry queuing policy does not specify which queue is serviced
+first. Other entry queuing policies can be specified by pragmas (see
+*note D.4::).
+
+18
+For a protected object, the above servicing of entry queues continues
+until there are no open entries with queued calls, at which point the
+protected action completes.
+
+18.a
+ Discussion: While servicing the entry queues of a protected
+ object, no new calls can be added to any entry queue of the
+ object, except due to an internal requeue (see *note 9.5.4::).
+ This is because the first step of a call on a protected entry
+ is to start a new protected action, which implies acquiring
+ (for exclusive read-write access) the execution resource
+ associated with the protected object, which cannot be done
+ while another protected action is already in progress.
+
+19
+For an entry call that is added to a queue, and that is not the
+triggering_statement of an asynchronous_select (*note 9.7.4: S0241.)
+(see *note 9.7.4::), the calling task is blocked until the call is
+cancelled, or the call is selected and a corresponding accept_statement
+or entry_body completes without requeuing. In addition, the calling
+task is blocked during a rendezvous.
+
+19.a
+ Ramification: For a call on a protected entry, the caller is
+ not blocked if the call is selected immediately, unless a
+ requeue causes the call to be queued.
+
+20
+An attempt can be made to cancel an entry call upon an abort (see *note
+9.8::) and as part of certain forms of select_statement (see *note
+9.7.2::, *note 9.7.3::, and *note 9.7.4::). The cancellation does not
+take place until a point (if any) when the call is on some entry queue,
+and not protected from cancellation as part of a requeue (see *note
+9.5.4::); at such a point, the call is removed from the entry queue and
+the call completes due to the cancellation. The cancellation of a call
+on an entry of a protected object is a protected action[, and as such
+cannot take place while any other protected action is occurring on the
+protected object. Like any protected action, it includes servicing of
+the entry queues (in case some entry barrier depends on a Count
+attribute).]
+
+20.a/2
+ Implementation Note: {AI95-00114-01AI95-00114-01} In the case
+ of an attempted cancellation due to abort, this removal might
+ have to be performed by the calling task itself if the ceiling
+ priority of the protected object is lower than the priority of
+ the task initiating the abort.
+
+21
+A call on an entry of a task that has already completed its execution
+raises the exception Tasking_Error at the point of the call; similarly,
+this exception is raised at the point of the call if the called task
+completes its execution or becomes abnormal before accepting the call or
+completing the rendezvous (see *note 9.8::). This applies equally to a
+simple entry call and to an entry call as part of a select_statement.
+
+ _Implementation Permissions_
+
+22
+An implementation may perform the sequence of steps of a protected
+action using any thread of control; it need not be that of the task that
+started the protected action. If an entry_body completes without
+requeuing, then the corresponding calling task may be made ready without
+waiting for the entire protected action to complete.
+
+22.a
+ Reason: These permissions are intended to allow flexibility
+ for implementations on multiprocessors. On a monoprocessor,
+ which thread of control executes the protected action is
+ essentially invisible, since the thread is not abortable in
+ any case, and the "current_task" function is not guaranteed to
+ work during a protected action (see *note C.7.1::).
+
+23
+When the entry of a protected object is checked to see whether it is
+open, the implementation need not reevaluate the condition of the
+corresponding entry_barrier if no variable or attribute referenced by
+the condition (directly or indirectly) has been altered by the execution
+(or cancellation) of a protected procedure or entry call on the object
+since the condition was last evaluated.
+
+23.a
+ Ramification: Changes to variables referenced by an entry
+ barrier that result from actions outside of a protected
+ procedure or entry call on the protected object need not be
+ "noticed." For example, if a global variable is referenced by
+ an entry barrier, it should not be altered (except as part of
+ a protected action on the object) any time after the barrier
+ is first evaluated. In other words, globals can be used to
+ "parameterize" a protected object, but they cannot reliably be
+ used to control it after the first use of the protected
+ object.
+
+23.b
+ Implementation Note: Note that even if a global variable is
+ volatile, the implementation need only reevaluate a barrier if
+ the global is updated during a protected action on the
+ protected object. This ensures that an entry-open bit-vector
+ implementation approach is possible, where the bit-vector is
+ computed at the end of a protected action, rather than upon
+ each entry call.
+
+24
+An implementation may evaluate the conditions of all entry_barriers of a
+given protected object any time any entry of the object is checked to
+see if it is open.
+
+24.a
+ Ramification: In other words, any side effects of evaluating
+ an entry barrier should be innocuous, since an entry barrier
+ might be evaluated more or less often than is implied by the
+ "official" dynamic semantics.
+
+24.b
+ Implementation Note: It is anticipated that when the number of
+ entries is known to be small, all barriers will be evaluated
+ any time one of them needs to be, to produce an "entry-open
+ bit-vector." The appropriate bit will be tested when the
+ entry is called, and only if the bit is false will a check be
+ made to see whether the bit-vector might need to be
+ recomputed. This should allow an implementation to maximize
+ the performance of a call on an open entry, which seems like
+ the most important case.
+
+24.c
+ In addition to the entry-open bit-vector, an "is-valid" bit is
+ needed per object, which indicates whether the current
+ bit-vector setting is valid. A "depends-on-Count-attribute"
+ bit is needed per type. The "is-valid" bit is set to false
+ (as are all the bits of the bit-vector) when the protected
+ object is first created, as well as any time an exception is
+ propagated from computing the bit-vector. Is-valid would also
+ be set false any time the Count is changed and
+ "depends-on-Count-attribute" is true for the type, or a
+ protected procedure or entry returns indicating it might have
+ updated a variable referenced in some barrier.
+
+24.d
+ A single procedure can be compiled to evaluate all of the
+ barriers, set the entry-open bit-vector accordingly, and set
+ the is-valid bit to true. It could have a "when others"
+ handler to set them all false, and call a routine to propagate
+ Program_Error to all queued callers.
+
+24.e
+ For protected types where the number of entries is not known
+ to be small, it makes more sense to evaluate a barrier only
+ when the corresponding entry is checked to see if it is open.
+ It isn't worth saving the state of the entry between checks,
+ because of the space that would be required. Furthermore, the
+ entry queues probably want to take up space only when there is
+ actually a caller on them, so rather than an array of all
+ entry queues, a linked list of nonempty entry queues make the
+ most sense in this case, with the first caller on each entry
+ queue acting as the queue header.
+
+25
+When an attempt is made to cancel an entry call, the implementation need
+not make the attempt using the thread of control of the task (or
+interrupt) that initiated the cancellation; in particular, it may use
+the thread of control of the caller itself to attempt the cancellation,
+even if this might allow the entry call to be selected in the interim.
+
+25.a
+ Reason: Because cancellation of a protected entry call is a
+ protected action (which helps make the Count attribute of a
+ protected entry meaningful), it might not be practical to
+ attempt the cancellation from the thread of control that
+ initiated the cancellation. For example, if the cancellation
+ is due to the expiration of a delay, it is unlikely that the
+ handler of the timer interrupt could perform the necessary
+ protected action itself (due to being on the interrupt level).
+ Similarly, if the cancellation is due to an abort, it is
+ possible that the task initiating the abort has a priority
+ higher than the ceiling priority of the protected object (for
+ implementations that support ceiling priorities). Similar
+ considerations could apply in a multiprocessor situation.
+
+ NOTES
+
+26
+ 28 If an exception is raised during the execution of an
+ entry_body, it is propagated to the corresponding caller (see *note
+ 11.4::).
+
+27
+ 29 For a call on a protected entry, the entry is checked to see if
+ it is open prior to queuing the call, and again thereafter if its
+ Count attribute (see *note 9.9::) is referenced in some entry
+ barrier.
+
+27.a
+ Ramification: Given this, extra care is required if a
+ reference to the Count attribute of an entry appears in the
+ entry's own barrier.
+
+27.b
+ Reason: An entry is checked to see if it is open prior to
+ queuing to maximize the performance of a call on an open
+ entry.
+
+28
+ 30 In addition to simple entry calls, the language permits timed,
+ conditional, and asynchronous entry calls (see *note 9.7.2::, *note
+ 9.7.3::, and see *note 9.7.4::).
+
+28.a
+ Ramification: A task can call its own entries, but the task
+ will deadlock if the call is a simple entry call.
+
+29
+ 31 The condition of an entry_barrier is allowed to be evaluated by
+ an implementation more often than strictly necessary, even if the
+ evaluation might have side effects. On the other hand, an
+ implementation need not reevaluate the condition if nothing it
+ references was updated by an intervening protected action on the
+ protected object, even if the condition references some global
+ variable that might have been updated by an action performed from
+ outside of a protected action.
+
+ _Examples_
+
+30
+Examples of entry calls:
+
+31
+ Agent.Shut_Down; -- see *note 9.1::
+ Parser.Next_Lexeme(E); -- see *note 9.1::
+ Pool(5).Read(Next_Char); -- see *note 9.1::
+ Controller.Request(Low)(Some_Item); -- see *note 9.1::
+ Flags(3).Seize; -- see *note 9.4::
+
+\1f
+File: aarm2012.info, Node: 9.5.4, Prev: 9.5.3, Up: 9.5
+
+9.5.4 Requeue Statements
+------------------------
+
+1
+[A requeue_statement can be used to complete an accept_statement or
+entry_body, while redirecting the corresponding entry call to a new (or
+the same) entry queue. Such a requeue can be performed with or without
+allowing an intermediate cancellation of the call, due to an abort or
+the expiration of a delay. ]
+
+ _Syntax_
+
+2/3
+ {AI05-0030-2AI05-0030-2} requeue_statement ::=
+ requeue procedure_or_entry_name [with abort];
+
+ _Name Resolution Rules_
+
+3/3
+{AI05-0030-2AI05-0030-2} {AI05-0215-1AI05-0215-1} The
+procedure_or_entry_name of a requeue_statement shall resolve to denote a
+procedure or an entry (the requeue target). The profile of the entry,
+or the profile or prefixed profile of the procedure, shall either have
+no parameters, or be type conformant (see *note 6.3.1::) with the
+profile of the innermost enclosing entry_body (*note 9.5.2: S0221.) or
+accept_statement (*note 9.5.2: S0219.).
+
+ _Legality Rules_
+
+4
+A requeue_statement shall be within a callable construct that is either
+an entry_body or an accept_statement, and this construct shall be the
+innermost enclosing body or callable construct.
+
+5/3
+{AI05-0030-2AI05-0030-2} {AI05-0215-1AI05-0215-1} If the requeue target
+has parameters, then its (prefixed) profile shall be subtype conformant
+with the profile of the innermost enclosing callable construct.
+
+5.1/3
+{AI05-0030-2AI05-0030-2} {AI05-0215-1AI05-0215-1} If the target is a
+procedure, the name shall denote a renaming of an entry, or shall denote
+a view or a prefixed view of a primitive subprogram of a synchronized
+interface, where the first parameter of the unprefixed view of the
+primitive subprogram shall be a controlling parameter, and the
+Synchronization aspect shall be specified with synchronization_kind
+By_Entry for the primitive subprogram.
+
+6/3
+{AI05-0030-2AI05-0030-2} In a requeue_statement of an accept_statement
+of some task unit, either the target object shall be a part of a formal
+parameter of the accept_statement, or the accessibility level of the
+target object shall not be equal to or statically deeper than any
+enclosing accept_statement of the task unit. In a requeue_statement
+(*note 9.5.4: S0226.) of an entry_body (*note 9.5.2: S0221.) of some
+protected unit, either the target object shall be a part of a formal
+parameter of the entry_body (*note 9.5.2: S0221.), or the accessibility
+level of the target object shall not be statically deeper than that of
+the entry_declaration for the entry_body.
+
+6.a
+ Ramification: In the entry_body case, the intent is that the
+ target object can be global, or can be a component of the
+ protected unit, but cannot be a local variable of the
+ entry_body.
+
+6.b
+ Reason: These restrictions ensure that the target object of
+ the requeue outlives the completion and finalization of the
+ enclosing callable construct. They also prevent requeuing
+ from a nested accept_statement on a parameter of an outer
+ accept_statement, which could create some strange
+ "long-distance" connections between an entry caller and its
+ server.
+
+6.c
+ Note that in the strange case where a task_body is nested
+ inside an accept_statement, it is permissible to requeue from
+ an accept_statement of the inner task_body on parameters of
+ the outer accept_statement. This is not a problem because all
+ calls on the inner task have to complete before returning from
+ the outer accept_statement, meaning no "dangling calls" will
+ be created.
+
+6.d
+ Implementation Note: By disallowing certain requeues, we
+ ensure that the normal terminate_alternative rules remain
+ sensible, and that explicit clearing of the entry queues of a
+ protected object during finalization is rarely necessary. In
+ particular, such clearing of the entry queues is necessary
+ only (ignoring premature Unchecked_Deallocation) for protected
+ objects declared in a task_body (or created by an allocator
+ for an access type declared in such a body) containing one or
+ more requeue_statements. Protected objects declared in
+ subprograms, or at the library level, will never need to have
+ their entry queues explicitly cleared during finalization.
+
+ _Dynamic Semantics_
+
+7/3
+{AI05-0030-2AI05-0030-2} The execution of a requeue_statement proceeds
+by first evaluating the procedure_or_entry_name[, including the prefix
+identifying the target task or protected object and the expression
+identifying the entry within an entry family, if any]. The entry_body
+or accept_statement enclosing the requeue_statement is then completed[,
+finalized, and left (see *note 7.6.1::)].
+
+8
+For the execution of a requeue on an entry of a target task, after
+leaving the enclosing callable construct, the named entry is checked to
+see if it is open and the requeued call is either selected immediately
+or queued, as for a normal entry call (see *note 9.5.3::).
+
+9
+For the execution of a requeue on an entry of a target protected object,
+after leaving the enclosing callable construct:
+
+10
+ * if the requeue is an internal requeue (that is, the requeue is back
+ on an entry of the same protected object -- see *note 9.5::), the
+ call is added to the queue of the named entry and the ongoing
+ protected action continues (see *note 9.5.1::);
+
+10.a
+ Ramification: Note that for an internal requeue, the call is
+ queued without checking whether the target entry is open.
+ This is because the entry queues will be serviced before the
+ current protected action completes anyway, and considering the
+ requeued call immediately might allow it to "jump" ahead of
+ existing callers on the same queue.
+
+11
+ * if the requeue is an external requeue (that is, the target
+ protected object is not implicitly the same as the current object
+ -- see *note 9.5::), a protected action is started on the target
+ object and proceeds as for a normal entry call (see *note 9.5.3::).
+
+12/3
+{AI05-0030-2AI05-0030-2} If the requeue target named in the
+requeue_statement has formal parameters, then during the execution of
+the accept_statement or entry_body corresponding to the new entry, the
+formal parameters denote the same objects as did the corresponding
+formal parameters of the callable construct completed by the requeue.
+[In any case, no parameters are specified in a requeue_statement; any
+parameter passing is implicit.]
+
+13
+If the requeue_statement includes the reserved words with abort (it is a
+requeue-with-abort), then:
+
+14
+ * if the original entry call has been aborted (see *note 9.8::), then
+ the requeue acts as an abort completion point for the call, and the
+ call is cancelled and no requeue is performed;
+
+15
+ * if the original entry call was timed (or conditional), then the
+ original expiration time is the expiration time for the requeued
+ call.
+
+16
+If the reserved words with abort do not appear, then the call remains
+protected against cancellation while queued as the result of the
+requeue_statement.
+
+16.a
+ Ramification: This protection against cancellation lasts only
+ until the call completes or a subsequent requeue-with-abort is
+ performed on the call.
+
+16.b
+ Reason: We chose to protect a requeue, by default, against
+ abort or cancellation. This seemed safer, since it is likely
+ that extra steps need to be taken to allow for possible
+ cancellation once the servicing of an entry call has begun.
+ This also means that in the absence of with abort the usual
+ Ada 83 behavior is preserved, namely that once an entry call
+ is accepted, it cannot be cancelled until it completes.
+
+ NOTES
+
+17
+ 32 A requeue is permitted from a single entry to an entry of an
+ entry family, or vice-versa. The entry index, if any, plays no
+ part in the subtype conformance check between the profiles of the
+ two entries; an entry index is part of the entry_name for an entry
+ of a family.
+
+ _Examples_
+
+18
+Examples of requeue statements:
+
+19
+ requeue Request(Medium) with abort;
+ -- requeue on a member of an entry family of the current task, see *note 9.1::
+
+20
+ requeue Flags(I).Seize;
+ -- requeue on an entry of an array component, see *note 9.4::
+
+ _Extensions to Ada 83_
+
+20.a
+ The requeue_statement is new.
+
+ _Extensions to Ada 2005_
+
+20.b/3
+ {AI05-0030-2AI05-0030-2} {AI05-0215-1AI05-0215-1} Added the
+ ability to requeue on operations of synchronized interfaces
+ that are declared to be an entry.
+
+\1f
+File: aarm2012.info, Node: 9.6, Next: 9.7, Prev: 9.5, Up: 9
+
+9.6 Delay Statements, Duration, and Time
+========================================
+
+1
+[ A delay_statement is used to block further execution until a specified
+expiration time is reached. The expiration time can be specified either
+as a particular point in time (in a delay_until_statement (*note 9.6:
+S0228.)), or in seconds from the current time (in a
+delay_relative_statement (*note 9.6: S0229.)). The language-defined
+package Calendar provides definitions for a type Time and associated
+operations, including a function Clock that returns the current time. ]
+
+ _Syntax_
+
+2
+ delay_statement ::= delay_until_statement |
+ delay_relative_statement
+
+3
+ delay_until_statement ::= delay until delay_expression;
+
+4
+ delay_relative_statement ::= delay delay_expression;
+
+ _Name Resolution Rules_
+
+5
+The expected type for the delay_expression in a delay_relative_statement
+is the predefined type Duration. The delay_expression in a
+delay_until_statement is expected to be of any nonlimited type.
+
+ _Legality Rules_
+
+6/3
+{AI05-0092-1AI05-0092-1} There can be multiple time bases, each with a
+corresponding clock, and a corresponding time type. The type of the
+delay_expression in a delay_until_statement shall be a time type --
+either the type Time defined in the language-defined package Calendar
+(see below), the type Time in the package Real_Time (see *note D.8::),
+or some other implementation-defined time type.
+
+6.a
+ Implementation defined: Any implementation-defined time types.
+
+ _Static Semantics_
+
+7
+[There is a predefined fixed point type named Duration, declared in the
+visible part of package Standard;] a value of type Duration is used to
+represent the length of an interval of time, expressed in seconds. [The
+type Duration is not specific to a particular time base, but can be used
+with any time base.]
+
+8/3
+{AI05-0092-1AI05-0092-1} A value of the type Time in package Calendar,
+or of some other time type, represents a time as reported by a
+corresponding clock.
+
+9
+The following language-defined library package exists:
+
+10
+
+ package Ada.Calendar is
+ type Time is private;
+
+11/2
+ {AI95-00351-01AI95-00351-01} subtype Year_Number is Integer range 1901 .. 2399;
+ subtype Month_Number is Integer range 1 .. 12;
+ subtype Day_Number is Integer range 1 .. 31;
+ subtype Day_Duration is Duration range 0.0 .. 86_400.0;
+
+11.a/2
+ Reason: {AI95-00351-01AI95-00351-01} A range of 500 years was
+ chosen, as that only requires one extra bit for the year as
+ compared to Ada 95. This was done to minimize disruptions
+ with existing implementations. (One implementor reports that
+ their time values represent nanoseconds, and this year range
+ requires 63.77 bits to represent.)
+
+12
+ function Clock return Time;
+
+13
+ function Year (Date : Time) return Year_Number;
+ function Month (Date : Time) return Month_Number;
+ function Day (Date : Time) return Day_Number;
+ function Seconds(Date : Time) return Day_Duration;
+
+14
+ procedure Split (Date : in Time;
+ Year : out Year_Number;
+ Month : out Month_Number;
+ Day : out Day_Number;
+ Seconds : out Day_Duration);
+
+15
+ function Time_Of(Year : Year_Number;
+ Month : Month_Number;
+ Day : Day_Number;
+ Seconds : Day_Duration := 0.0)
+ return Time;
+
+16
+ function "+" (Left : Time; Right : Duration) return Time;
+ function "+" (Left : Duration; Right : Time) return Time;
+ function "-" (Left : Time; Right : Duration) return Time;
+ function "-" (Left : Time; Right : Time) return Duration;
+
+17
+ function "<" (Left, Right : Time) return Boolean;
+ function "<="(Left, Right : Time) return Boolean;
+ function ">" (Left, Right : Time) return Boolean;
+ function ">="(Left, Right : Time) return Boolean;
+
+18
+ Time_Error : exception;
+
+19
+ private
+ ... -- not specified by the language
+ end Ada.Calendar;
+
+ _Dynamic Semantics_
+
+20
+For the execution of a delay_statement, the delay_expression is first
+evaluated. For a delay_until_statement, the expiration time for the
+delay is the value of the delay_expression, in the time base associated
+with the type of the expression. For a delay_relative_statement, the
+expiration time is defined as the current time, in the time base
+associated with relative delays, plus the value of the delay_expression
+converted to the type Duration, and then rounded up to the next clock
+tick. The time base associated with relative delays is as defined in
+*note D.9::, "*note D.9:: Delay Accuracy" or is implementation defined.
+
+20.a
+ Implementation defined: The time base associated with relative
+ delays.
+
+20.b
+ Ramification: Rounding up to the next clock tick means that
+ the reading of the delay-relative clock when the delay expires
+ should be no less than the current reading of the
+ delay-relative clock plus the specified duration.
+
+21
+The task executing a delay_statement is blocked until the expiration
+time is reached, at which point it becomes ready again. If the
+expiration time has already passed, the task is not blocked.
+
+21.a
+ Discussion: For a delay_relative_statement, this case
+ corresponds to when the value of the delay_expression is zero
+ or negative.
+
+21.b
+ Even though the task is not blocked, it might be put back on
+ the end of its ready queue. See *note D.2::, "*note D.2::
+ Priority Scheduling".
+
+22/3
+{AI05-0092-1AI05-0092-1} If an attempt is made to cancel the
+delay_statement [(as part of an asynchronous_select (*note 9.7.4:
+S0241.) or abort -- see *note 9.7.4:: and *note 9.8::)], the statement
+is cancelled if the expiration time has not yet passed, thereby
+completing the delay_statement.
+
+22.a
+ Reason: This is worded this way so that in an
+ asynchronous_select where the triggering_statement is a
+ delay_statement, an attempt to cancel the delay when the
+ abortable_part completes is ignored if the expiration time has
+ already passed, in which case the optional statements of the
+ triggering_alternative are executed.
+
+23
+The time base associated with the type Time of package Calendar is
+implementation defined. The function Clock of package Calendar returns
+a value representing the current time for this time base. [The
+implementation-defined value of the named number System.Tick (see *note
+13.7::) is an approximation of the length of the real-time interval
+during which the value of Calendar.Clock remains constant.]
+
+23.a
+ Implementation defined: The time base of the type
+ Calendar.Time.
+
+24/2
+{AI95-00351-01AI95-00351-01} The functions Year, Month, Day, and Seconds
+return the corresponding values for a given value of the type Time, as
+appropriate to an implementation-defined time zone; the procedure Split
+returns all four corresponding values. Conversely, the function Time_Of
+combines a year number, a month number, a day number, and a duration,
+into a value of type Time. The operators "+" and "-" for addition and
+subtraction of times and durations, and the relational operators for
+times, have the conventional meaning.
+
+24.a/2
+ Implementation defined: The time zone used for package
+ Calendar operations.
+
+24.b/3
+ Ramification: {AI05-0119-1AI05-0119-1} The behavior of these
+ values and subprograms if the time zone changes is also
+ implementation-defined. In particular, the changes associated
+ with summer time adjustments (like Daylight Savings Time in
+ the United States) should be treated as a change in the
+ implementation-defined time zone. The language does not
+ specify whether the time zone information is stored in values
+ of type Time; therefore the results of binary operators are
+ unspecified when the operands are the two values with
+ different effective time zones. In particular, the results of
+ "-" may differ from the "real" result by the difference in the
+ time zone adjustment. Similarly, the result of
+ UTC_Time_Offset (see 9.6.1) may or may not reflect a time zone
+ adjustment.
+
+25
+If Time_Of is called with a seconds value of 86_400.0, the value
+returned is equal to the value of Time_Of for the next day with a
+seconds value of 0.0. The value returned by the function Seconds or
+through the Seconds parameter of the procedure Split is always less than
+86_400.0.
+
+26/1
+{8652/00308652/0030} {AI95-00113-01AI95-00113-01} The exception
+Time_Error is raised by the function Time_Of if the actual parameters do
+not form a proper date. This exception is also raised by the operators
+"+" and "-" if the result is not representable in the type Time or
+Duration, as appropriate. This exception is also raised by the
+functions Year, Month, Day, and Seconds and the procedure Split if the
+year number of the given date is outside of the range of the subtype
+Year_Number.
+
+26.a/1
+ To be honest: {8652/01068652/0106}
+ {AI95-00160-01AI95-00160-01} By "proper date" above we mean
+ that the given year has a month with the given day. For
+ example, February 29th is a proper date only for a leap year.
+ We do not mean to include the Seconds in this notion; in
+ particular, we do not mean to require implementations to check
+ for the "missing hour" that occurs when Daylight Savings Time
+ starts in the spring.
+
+26.b/2
+ Reason: {8652/00308652/0030} {AI95-00113-01AI95-00113-01}
+ {AI95-00351-01AI95-00351-01} We allow Year and Split to raise
+ Time_Error because the arithmetic operators are allowed (but
+ not required) to produce times that are outside the range of
+ years from 1901 to 2399. This is similar to the way integer
+ operators may return values outside the base range of their
+ type so long as the value is mathematically correct. We allow
+ the functions Month, Day and Seconds to raise Time_Error so
+ that they can be implemented in terms of Split.
+
+ _Implementation Requirements_
+
+27
+The implementation of the type Duration shall allow representation of
+time intervals (both positive and negative) up to at least 86400 seconds
+(one day); Duration'Small shall not be greater than twenty milliseconds.
+The implementation of the type Time shall allow representation of all
+dates with year numbers in the range of Year_Number[; it may allow
+representation of other dates as well (both earlier and later).]
+
+ _Implementation Permissions_
+
+28/3
+{AI05-0092-1AI05-0092-1} An implementation may define additional time
+types.
+
+29
+An implementation may raise Time_Error if the value of a
+delay_expression in a delay_until_statement of a select_statement
+represents a time more than 90 days past the current time. The actual
+limit, if any, is implementation-defined.
+
+29.a
+ Implementation defined: Any limit on delay_until_statements of
+ select_statements.
+
+29.b
+ Implementation Note: This allows an implementation to
+ implement select_statement timeouts using a representation
+ that does not support the full range of a time type. In
+ particular 90 days of seconds can be represented in 23 bits,
+ allowing a signed 24-bit representation for the seconds part
+ of a timeout. There is no similar restriction allowed for
+ stand-alone delay_until_statements, as these can be
+ implemented internally using a loop if necessary to
+ accommodate a long delay.
+
+ _Implementation Advice_
+
+30
+Whenever possible in an implementation, the value of Duration'Small
+should be no greater than 100 microseconds.
+
+30.a
+ Implementation Note: This can be satisfied using a 32-bit 2's
+ complement representation with a small of 2.0**(-14) -- that
+ is, 61 microseconds -- and a range of ± 2.0**17 -- that is,
+ 131_072.0.
+
+30.b/2
+ Implementation Advice: The value of Duration'Small should be
+ no greater than 100 microseconds.
+
+31
+The time base for delay_relative_statements should be monotonic; it need
+not be the same time base as used for Calendar.Clock.
+
+31.a/2
+ Implementation Advice: The time base for
+ delay_relative_statements should be monotonic.
+
+ NOTES
+
+32
+ 33 A delay_relative_statement with a negative value of the
+ delay_expression is equivalent to one with a zero value.
+
+33
+ 34 A delay_statement may be executed by the environment task;
+ consequently delay_statements may be executed as part of the
+ elaboration of a library_item or the execution of the main
+ subprogram. Such statements delay the environment task (see *note
+ 10.2::).
+
+34
+ 35 A delay_statement is an abort completion point and a
+ potentially blocking operation, even if the task is not actually
+ blocked.
+
+35
+ 36 There is no necessary relationship between System.Tick (the
+ resolution of the clock of package Calendar) and Duration'Small
+ (the small of type Duration).
+
+35.a
+ Ramification: The inaccuracy of the delay_statement has no
+ relation to System.Tick. In particular, it is possible that
+ the clock used for the delay_statement is less accurate than
+ Calendar.Clock.
+
+35.b
+ We considered making Tick a run-time-determined quantity, to
+ allow for easier configurability. However, this would not be
+ upward compatible, and the desired configurability can be
+ achieved using functionality defined in *note Annex D::,
+ "*note Annex D:: Real-Time Systems".
+
+36
+ 37 Additional requirements associated with delay_statements are
+ given in *note D.9::, "*note D.9:: Delay Accuracy".
+
+ _Examples_
+
+37
+Example of a relative delay statement:
+
+38
+ delay 3.0; -- delay 3.0 seconds
+
+39
+Example of a periodic task:
+
+40
+ declare
+ use Ada.Calendar;
+ Next_Time : Time := Clock + Period;
+ -- Period is a global constant of type Duration
+ begin
+ loop -- repeated every Period seconds
+ delay until Next_Time;
+ ... -- perform some actions
+ Next_Time := Next_Time + Period;
+ end loop;
+ end;
+
+ _Inconsistencies With Ada 83_
+
+40.a
+ For programs that raise Time_Error on "+" or "-" in Ada 83,the
+ exception might be deferred until a call on Split or
+ Year_Number, or might not be raised at all (if the offending
+ time is never Split after being calculated). This should not
+ affect typical programs, since they deal only with times
+ corresponding to the relatively recent past or near future.
+
+ _Extensions to Ada 83_
+
+40.b
+ The syntax rule for delay_statement is modified to allow
+ delay_until_statements.
+
+40.c/2
+ {AI95-00351-01AI95-00351-01} The type Time may represent dates
+ with year numbers outside of Year_Number. Therefore, the
+ operations "+" and "-" need only raise Time_Error if the
+ result is not representable in Time (or Duration); also, Split
+ or Year will now raise Time_Error if the year number is
+ outside of Year_Number. This change is intended to simplify
+ the implementation of "+" and "-" (allowing them to depend on
+ overflow for detecting when to raise Time_Error) and to allow
+ local time zone information to be considered at the time of
+ Split rather than Clock (depending on the implementation
+ approach). For example, in a POSIX environment, it is natural
+ for the type Time to be based on GMT, and the results of
+ procedure Split (and the functions Year, Month, Day, and
+ Seconds) to depend on local time zone information. In other
+ environments, it is more natural for the type Time to be based
+ on the local time zone, with the results of Year, Month, Day,
+ and Seconds being pure functions of their input.
+
+40.d/2
+ This paragraph was deleted.{AI95-00351-01AI95-00351-01}
+
+ _Inconsistencies With Ada 95_
+
+40.e/2
+ {AI95-00351-01AI95-00351-01} The upper bound of Year_Number
+ has been changed to avoid a year 2100 problem. A program
+ which expects years past 2099 to raise Constraint_Error will
+ fail in Ada 2005. We don't expect there to be many programs
+ which are depending on an exception to be raised. A program
+ that uses Year_Number'Last as a magic number may also fail if
+ values of Time are stored outside of the program. Note that
+ the lower bound of Year_Number wasn't changed, because it is
+ not unusual to use that value in a constant to represent an
+ unknown time.
+
+ _Wording Changes from Ada 95_
+
+40.f/2
+ {8652/00028652/0002} {AI95-00171-01AI95-00171-01} Corrigendum:
+ Clarified that Month, Day, and Seconds can raise Time_Error.
+
+* Menu:
+
+* 9.6.1 :: Formatting, Time Zones, and other operations for Time
+
+\1f
+File: aarm2012.info, Node: 9.6.1, Up: 9.6
+
+9.6.1 Formatting, Time Zones, and other operations for Time
+-----------------------------------------------------------
+
+ _Static Semantics_
+
+1/2
+{AI95-00351-01AI95-00351-01} {AI95-00427-01AI95-00427-01} The following
+language-defined library packages exist:
+
+2/2
+ package Ada.Calendar.Time_Zones is
+
+3/2
+ -- Time zone manipulation:
+
+4/2
+ type Time_Offset is range -28*60 .. 28*60;
+
+4.a/2
+ Reason: We want to be able to specify the difference between
+ any two arbitrary time zones. You might think that 1440 (24
+ hours) would be enough, but there are places (like Tonga,
+ which is UTC+13hr) which are more than 12 hours than UTC.
+ Combined with summer time (known as daylight saving time in
+ some parts of the world) - which switches opposite in the
+ northern and souther hemispheres - and even greater
+ differences are possible. We know of cases of a 26 hours
+ difference, so we err on the safe side by selecting 28 hours
+ as the limit.
+
+5/2
+ Unknown_Zone_Error : exception;
+
+6/2
+ function UTC_Time_Offset (Date : Time := Clock) return Time_Offset;
+
+7/2
+ end Ada.Calendar.Time_Zones;
+
+8/2
+
+ package Ada.Calendar.Arithmetic is
+
+9/2
+ -- Arithmetic on days:
+
+10/2
+ type Day_Count is range
+ -366*(1+Year_Number'Last - Year_Number'First)
+ ..
+ 366*(1+Year_Number'Last - Year_Number'First);
+
+11/2
+ subtype Leap_Seconds_Count is Integer range -2047 .. 2047;
+
+11.a/2
+ Reason: The maximum number of leap seconds is likely to be
+ much less than this, but we don't want to reach the limit too
+ soon if the earth's behavior suddenly changes. We believe
+ that the maximum number is 1612, based on the current rules,
+ but that number is too weird to use here.
+
+12/2
+ procedure Difference (Left, Right : in Time;
+ Days : out Day_Count;
+ Seconds : out Duration;
+ Leap_Seconds : out Leap_Seconds_Count);
+
+13/2
+ function "+" (Left : Time; Right : Day_Count) return Time;
+ function "+" (Left : Day_Count; Right : Time) return Time;
+ function "-" (Left : Time; Right : Day_Count) return Time;
+ function "-" (Left, Right : Time) return Day_Count;
+
+14/2
+ end Ada.Calendar.Arithmetic;
+
+15/2
+
+ with Ada.Calendar.Time_Zones;
+ package Ada.Calendar.Formatting is
+
+16/2
+ -- Day of the week:
+
+17/2
+ type Day_Name is (Monday, Tuesday, Wednesday, Thursday,
+ Friday, Saturday, Sunday);
+
+18/2
+ function Day_of_Week (Date : Time) return Day_Name;
+
+19/2
+ -- Hours:Minutes:Seconds access:
+
+20/2
+ subtype Hour_Number is Natural range 0 .. 23;
+ subtype Minute_Number is Natural range 0 .. 59;
+ subtype Second_Number is Natural range 0 .. 59;
+ subtype Second_Duration is Day_Duration range 0.0 .. 1.0;
+
+21/2
+ function Year (Date : Time;
+ Time_Zone : Time_Zones.Time_Offset := 0)
+ return Year_Number;
+
+22/2
+ function Month (Date : Time;
+ Time_Zone : Time_Zones.Time_Offset := 0)
+ return Month_Number;
+
+23/2
+ function Day (Date : Time;
+ Time_Zone : Time_Zones.Time_Offset := 0)
+ return Day_Number;
+
+24/2
+ function Hour (Date : Time;
+ Time_Zone : Time_Zones.Time_Offset := 0)
+ return Hour_Number;
+
+25/2
+ function Minute (Date : Time;
+ Time_Zone : Time_Zones.Time_Offset := 0)
+ return Minute_Number;
+
+26/2
+ function Second (Date : Time)
+ return Second_Number;
+
+27/2
+ function Sub_Second (Date : Time)
+ return Second_Duration;
+
+28/2
+ function Seconds_Of (Hour : Hour_Number;
+ Minute : Minute_Number;
+ Second : Second_Number := 0;
+ Sub_Second : Second_Duration := 0.0)
+ return Day_Duration;
+
+29/2
+ procedure Split (Seconds : in Day_Duration;
+ Hour : out Hour_Number;
+ Minute : out Minute_Number;
+ Second : out Second_Number;
+ Sub_Second : out Second_Duration);
+
+30/2
+ function Time_Of (Year : Year_Number;
+ Month : Month_Number;
+ Day : Day_Number;
+ Hour : Hour_Number;
+ Minute : Minute_Number;
+ Second : Second_Number;
+ Sub_Second : Second_Duration := 0.0;
+ Leap_Second: Boolean := False;
+ Time_Zone : Time_Zones.Time_Offset := 0)
+ return Time;
+
+31/2
+ function Time_Of (Year : Year_Number;
+ Month : Month_Number;
+ Day : Day_Number;
+ Seconds : Day_Duration := 0.0;
+ Leap_Second: Boolean := False;
+ Time_Zone : Time_Zones.Time_Offset := 0)
+ return Time;
+
+32/2
+ procedure Split (Date : in Time;
+ Year : out Year_Number;
+ Month : out Month_Number;
+ Day : out Day_Number;
+ Hour : out Hour_Number;
+ Minute : out Minute_Number;
+ Second : out Second_Number;
+ Sub_Second : out Second_Duration;
+ Time_Zone : in Time_Zones.Time_Offset := 0);
+
+33/2
+ procedure Split (Date : in Time;
+ Year : out Year_Number;
+ Month : out Month_Number;
+ Day : out Day_Number;
+ Hour : out Hour_Number;
+ Minute : out Minute_Number;
+ Second : out Second_Number;
+ Sub_Second : out Second_Duration;
+ Leap_Second: out Boolean;
+ Time_Zone : in Time_Zones.Time_Offset := 0);
+
+34/2
+ procedure Split (Date : in Time;
+ Year : out Year_Number;
+ Month : out Month_Number;
+ Day : out Day_Number;
+ Seconds : out Day_Duration;
+ Leap_Second: out Boolean;
+ Time_Zone : in Time_Zones.Time_Offset := 0);
+
+35/2
+ -- Simple image and value:
+ function Image (Date : Time;
+ Include_Time_Fraction : Boolean := False;
+ Time_Zone : Time_Zones.Time_Offset := 0) return String;
+
+36/2
+ function Value (Date : String;
+ Time_Zone : Time_Zones.Time_Offset := 0) return Time;
+
+37/2
+ function Image (Elapsed_Time : Duration;
+ Include_Time_Fraction : Boolean := False) return String;
+
+38/2
+ function Value (Elapsed_Time : String) return Duration;
+
+39/2
+ end Ada.Calendar.Formatting;
+
+40/2
+{AI95-00351-01AI95-00351-01} Type Time_Offset represents the number of
+minutes difference between the implementation-defined time zone used by
+Calendar and another time zone.
+
+41/2
+ function UTC_Time_Offset (Date : Time := Clock) return Time_Offset;
+
+42/3
+ {AI95-00351-01AI95-00351-01} {AI05-0119-1AI05-0119-1}
+ {AI05-0269-1AI05-0269-1} Returns, as a number of minutes, the
+ result of subtracting the implementation-defined time zone of
+ Calendar from UTC time, at the time Date. If the time zone of
+ the Calendar implementation is unknown, then
+ Unknown_Zone_Error is raised.
+
+42.a.1/3
+ Ramification: {AI05-0119-1AI05-0119-1} In North America, the
+ result will be negative; in Europe, the result will be zero or
+ positive.
+
+42.a/2
+ Discussion: The Date parameter is needed to take into account
+ time differences caused by daylight-savings time and other
+ time changes. This parameter is measured in the time zone of
+ Calendar, if any, not necessarily the UTC time zone.
+
+42.b/2
+ Other time zones can be supported with a child package. We
+ don't define one because of the lack of agreement on the
+ definition of a time zone.
+
+42.c/2
+ The accuracy of this routine is not specified; the intent is
+ that the facilities of the underlying target operating system
+ are used to implement it.
+
+43/2
+ procedure Difference (Left, Right : in Time;
+ Days : out Day_Count;
+ Seconds : out Duration;
+ Leap_Seconds : out Leap_Seconds_Count);
+
+44/2
+ {AI95-00351-01AI95-00351-01} {AI95-00427-01AI95-00427-01}
+ Returns the difference between Left and Right. Days is the
+ number of days of difference, Seconds is the remainder seconds
+ of difference excluding leap seconds, and Leap_Seconds is the
+ number of leap seconds. If Left < Right, then Seconds <= 0.0,
+ Days <= 0, and Leap_Seconds <= 0. Otherwise, all values are
+ nonnegative. The absolute value of Seconds is always less
+ than 86_400.0. For the returned values, if Days = 0, then
+ Seconds + Duration(Leap_Seconds) = Calendar."-" (Left, Right).
+
+44.a/2
+ Discussion: Leap_Seconds, if any, are not included in Seconds.
+ However, Leap_Seconds should be included in calculations using
+ the operators defined in Calendar, as is specified for "-"
+ above.
+
+45/2
+ function "+" (Left : Time; Right : Day_Count) return Time;
+ function "+" (Left : Day_Count; Right : Time) return Time;
+
+46/2
+ {AI95-00351-01AI95-00351-01} Adds a number of days to a time
+ value. Time_Error is raised if the result is not
+ representable as a value of type Time.
+
+47/2
+ function "-" (Left : Time; Right : Day_Count) return Time;
+
+48/2
+ {AI95-00351-01AI95-00351-01} Subtracts a number of days from a
+ time value. Time_Error is raised if the result is not
+ representable as a value of type Time.
+
+49/2
+ function "-" (Left, Right : Time) return Day_Count;
+
+50/2
+ {AI95-00351-01AI95-00351-01} Subtracts two time values, and
+ returns the number of days between them. This is the same
+ value that Difference would return in Days.
+
+51/2
+ function Day_of_Week (Date : Time) return Day_Name;
+
+52/2
+ {AI95-00351-01AI95-00351-01} Returns the day of the week for
+ Time. This is based on the Year, Month, and Day values of
+ Time.
+
+53/2
+ function Year (Date : Time;
+ Time_Zone : Time_Zones.Time_Offset := 0)
+ return Year_Number;
+
+54/2
+ {AI95-00427-01AI95-00427-01} Returns the year for Date, as
+ appropriate for the specified time zone offset.
+
+55/2
+ function Month (Date : Time;
+ Time_Zone : Time_Zones.Time_Offset := 0)
+ return Month_Number;
+
+56/2
+ {AI95-00427-01AI95-00427-01} Returns the month for Date, as
+ appropriate for the specified time zone offset.
+
+57/2
+ function Day (Date : Time;
+ Time_Zone : Time_Zones.Time_Offset := 0)
+ return Day_Number;
+
+58/2
+ {AI95-00427-01AI95-00427-01} Returns the day number for Date,
+ as appropriate for the specified time zone offset.
+
+59/2
+ function Hour (Date : Time;
+ Time_Zone : Time_Zones.Time_Offset := 0)
+ return Hour_Number;
+
+60/2
+ {AI95-00351-01AI95-00351-01} Returns the hour for Date, as
+ appropriate for the specified time zone offset.
+
+61/2
+ function Minute (Date : Time;
+ Time_Zone : Time_Zones.Time_Offset := 0)
+ return Minute_Number;
+
+62/2
+ {AI95-00351-01AI95-00351-01} Returns the minute within the
+ hour for Date, as appropriate for the specified time zone
+ offset.
+
+63/2
+ function Second (Date : Time)
+ return Second_Number;
+
+64/2
+ {AI95-00351-01AI95-00351-01} {AI95-00427-01AI95-00427-01}
+ Returns the second within the hour and minute for Date.
+
+65/2
+ function Sub_Second (Date : Time)
+ return Second_Duration;
+
+66/2
+ {AI95-00351-01AI95-00351-01} {AI95-00427-01AI95-00427-01}
+ Returns the fraction of second for Date (this has the same
+ accuracy as Day_Duration). The value returned is always less
+ than 1.0.
+
+67/2
+ function Seconds_Of (Hour : Hour_Number;
+ Minute : Minute_Number;
+ Second : Second_Number := 0;
+ Sub_Second : Second_Duration := 0.0)
+ return Day_Duration;
+
+68/2
+ {AI95-00351-01AI95-00351-01} {AI95-00427-01AI95-00427-01}
+ Returns a Day_Duration value for the combination of the given
+ Hour, Minute, Second, and Sub_Second. This value can be used
+ in Calendar.Time_Of as well as the argument to Calendar."+"
+ and Calendar."-". If Seconds_Of is called with a Sub_Second
+ value of 1.0, the value returned is equal to the value of
+ Seconds_Of for the next second with a Sub_Second value of 0.0.
+
+69/2
+ procedure Split (Seconds : in Day_Duration;
+ Hour : out Hour_Number;
+ Minute : out Minute_Number;
+ Second : out Second_Number;
+ Sub_Second : out Second_Duration);
+
+70/3
+ {AI95-00351-01AI95-00351-01} {AI95-00427-01AI95-00427-01}
+ {AI05-0238-1AI05-0238-1} Splits Seconds into Hour, Minute,
+ Second and Sub_Second in such a way that the resulting values
+ all belong to their respective subtypes. The value returned
+ in the Sub_Second parameter is always less than 1.0. If
+ Seconds = 86400.0, Split propagates Time_Error.
+
+70.a/2
+ Ramification: There is only one way to do the split which
+ meets all of the requirements.
+
+70.b/3
+ Reason: {AI05-0238-1AI05-0238-1} If Seconds = 86400.0, one of
+ the returned values would have to be out of its defined range
+ (either Sub_Second = 1.0 or Hour = 24 with the other value
+ being 0). This doesn't seem worth breaking the invariants.
+
+71/2
+ function Time_Of (Year : Year_Number;
+ Month : Month_Number;
+ Day : Day_Number;
+ Hour : Hour_Number;
+ Minute : Minute_Number;
+ Second : Second_Number;
+ Sub_Second : Second_Duration := 0.0;
+ Leap_Second: Boolean := False;
+ Time_Zone : Time_Zones.Time_Offset := 0)
+ return Time;
+
+72/2
+ {AI95-00351-01AI95-00351-01} {AI95-00427-01AI95-00427-01} If
+ Leap_Second is False, returns a Time built from the date and
+ time values, relative to the specified time zone offset. If
+ Leap_Second is True, returns the Time that represents the time
+ within the leap second that is one second later than the time
+ specified by the other parameters. Time_Error is raised if
+ the parameters do not form a proper date or time. If Time_Of
+ is called with a Sub_Second value of 1.0, the value returned
+ is equal to the value of Time_Of for the next second with a
+ Sub_Second value of 0.0.
+
+72.a/2
+ Discussion: Time_Error should be raised if Leap_Second is
+ True, and the date and time values do not represent the second
+ before a leap second. A leap second always occurs at midnight
+ UTC, and is 23:59:60 UTC in ISO notation. So, if the time
+ zone is UTC and Leap_Second is True, if any of Hour /= 23,
+ Minute /= 59, or Second /= 59, then Time_Error should be
+ raised. However, we do not say that, because other time zones
+ will have different values where a leap second is allowed.
+
+73/2
+ function Time_Of (Year : Year_Number;
+ Month : Month_Number;
+ Day : Day_Number;
+ Seconds : Day_Duration := 0.0;
+ Leap_Second: Boolean := False;
+ Time_Zone : Time_Zones.Time_Offset := 0)
+ return Time;
+
+74/2
+ {AI95-00351-01AI95-00351-01} {AI95-00427-01AI95-00427-01} If
+ Leap_Second is False, returns a Time built from the date and
+ time values, relative to the specified time zone offset. If
+ Leap_Second is True, returns the Time that represents the time
+ within the leap second that is one second later than the time
+ specified by the other parameters. Time_Error is raised if
+ the parameters do not form a proper date or time. If Time_Of
+ is called with a Seconds value of 86_400.0, the value returned
+ is equal to the value of Time_Of for the next day with a
+ Seconds value of 0.0.
+
+75/2
+ procedure Split (Date : in Time;
+ Year : out Year_Number;
+ Month : out Month_Number;
+ Day : out Day_Number;
+ Hour : out Hour_Number;
+ Minute : out Minute_Number;
+ Second : out Second_Number;
+ Sub_Second : out Second_Duration;
+ Leap_Second: out Boolean;
+ Time_Zone : in Time_Zones.Time_Offset := 0);
+
+76/2
+ {AI95-00351-01AI95-00351-01} {AI95-00427-01AI95-00427-01} If
+ Date does not represent a time within a leap second, splits
+ Date into its constituent parts (Year, Month, Day, Hour,
+ Minute, Second, Sub_Second), relative to the specified time
+ zone offset, and sets Leap_Second to False. If Date
+ represents a time within a leap second, set the constituent
+ parts to values corresponding to a time one second earlier
+ than that given by Date, relative to the specified time zone
+ offset, and sets Leap_Seconds to True. The value returned in
+ the Sub_Second parameter is always less than 1.0.
+
+77/2
+ procedure Split (Date : in Time;
+ Year : out Year_Number;
+ Month : out Month_Number;
+ Day : out Day_Number;
+ Hour : out Hour_Number;
+ Minute : out Minute_Number;
+ Second : out Second_Number;
+ Sub_Second : out Second_Duration;
+ Time_Zone : in Time_Zones.Time_Offset := 0);
+
+78/2
+ {AI95-00351-01AI95-00351-01} {AI95-00427-01AI95-00427-01}
+ Splits Date into its constituent parts (Year, Month, Day,
+ Hour, Minute, Second, Sub_Second), relative to the specified
+ time zone offset. The value returned in the Sub_Second
+ parameter is always less than 1.0.
+
+79/2
+ procedure Split (Date : in Time;
+ Year : out Year_Number;
+ Month : out Month_Number;
+ Day : out Day_Number;
+ Seconds : out Day_Duration;
+ Leap_Second: out Boolean;
+ Time_Zone : in Time_Zones.Time_Offset := 0);
+
+80/2
+ {AI95-00351-01AI95-00351-01} {AI95-00427-01AI95-00427-01} If
+ Date does not represent a time within a leap second, splits
+ Date into its constituent parts (Year, Month, Day, Seconds),
+ relative to the specified time zone offset, and sets
+ Leap_Second to False. If Date represents a time within a leap
+ second, set the constituent parts to values corresponding to a
+ time one second earlier than that given by Date, relative to
+ the specified time zone offset, and sets Leap_Seconds to True.
+ The value returned in the Seconds parameter is always less
+ than 86_400.0.
+
+81/2
+ function Image (Date : Time;
+ Include_Time_Fraction : Boolean := False;
+ Time_Zone : Time_Zones.Time_Offset := 0) return String;
+
+82/2
+ {AI95-00351-01AI95-00351-01} Returns a string form of the Date
+ relative to the given Time_Zone. The format is
+ "Year-Month-Day Hour:Minute:Second", where the Year is a
+ 4-digit value, and all others are 2-digit values, of the
+ functions defined in Calendar and Calendar.Formatting,
+ including a leading zero, if needed. The separators between
+ the values are a minus, another minus, a colon, and a single
+ space between the Day and Hour. If Include_Time_Fraction is
+ True, the integer part of Sub_Seconds*100 is suffixed to the
+ string as a point followed by a 2-digit value.
+
+82.a/2
+ Discussion: The Image provides a string in ISO 8601 format,
+ the international standard time format. Alternative
+ representations allowed in ISO 8601 are not supported here.
+
+82.b/2
+ ISO 8601 allows 24:00:00 for midnight; and a seconds value of
+ 60 for leap seconds. These are not allowed here (the routines
+ mentioned above cannot produce those results).
+
+82.c/2
+ Ramification: The fractional part is truncated, not rounded.
+ It would be quite hard to define the result with proper
+ rounding, as it can change all of the values of the image.
+ Values can be rounded up by adding an appropriate constant
+ (0.5 if Include_Time_Fraction is False, 0.005 otherwise) to
+ the time before taking the image.
+
+83/2
+ function Value (Date : String;
+ Time_Zone : Time_Zones.Time_Offset := 0) return Time;
+
+84/2
+ {AI95-00351-01AI95-00351-01} Returns a Time value for the
+ image given as Date, relative to the given time zone.
+ Constraint_Error is raised if the string is not formatted as
+ described for Image, or the function cannot interpret the
+ given string as a Time value.
+
+84.a/3
+ Discussion: {AI05-0005-1AI05-0005-1} The intent is that the
+ implementation enforce the same range rules on the string as
+ the appropriate function Time_Of, except for the hour, so
+ "cannot interpret the given string as a Time value" happens
+ when one of the values is out of the required range. For
+ example, "2005-08-31 24:00:00" should raise Constraint_Error
+ (the hour is out of range).
+
+85/2
+ function Image (Elapsed_Time : Duration;
+ Include_Time_Fraction : Boolean := False) return String;
+
+86/2
+ {AI95-00351-01AI95-00351-01} Returns a string form of the
+ Elapsed_Time. The format is "Hour:Minute:Second", where all
+ values are 2-digit values, including a leading zero, if
+ needed. The separators between the values are colons. If
+ Include_Time_Fraction is True, the integer part of
+ Sub_Seconds*100 is suffixed to the string as a point followed
+ by a 2-digit value. If Elapsed_Time < 0.0, the result is
+ Image (abs Elapsed_Time, Include_Time_Fraction) prefixed with
+ a minus sign. If abs Elapsed_Time represents 100 hours or
+ more, the result is implementation-defined.
+
+86.a/2
+ Implementation defined: The result of Calendar.Formating.Image
+ if its argument represents more than 100 hours.
+
+86.b/2
+ Implementation Note: This cannot be implemented (directly) by
+ calling Calendar.Formatting.Split, since it may be out of the
+ range of Day_Duration, and thus the number of hours may be out
+ of the range of Hour_Number.
+
+86.c
+ If a Duration value can represent more then 100 hours, the
+ implementation will need to define a format for the return of
+ Image.
+
+87/2
+ function Value (Elapsed_Time : String) return Duration;
+
+88/2
+ {AI95-00351-01AI95-00351-01} Returns a Duration value for the
+ image given as Elapsed_Time. Constraint_Error is raised if
+ the string is not formatted as described for Image, or the
+ function cannot interpret the given string as a Duration
+ value.
+
+88.a/2
+ Discussion: The intent is that the implementation enforce the
+ same range rules on the string as the appropriate function
+ Time_Of, except for the hour, so "cannot interpret the given
+ string as a Time value" happens when one of the values is out
+ of the required range. For example, "10:23:60" should raise
+ Constraint_Error (the seconds value is out of range).
+
+ _Implementation Advice_
+
+89/2
+{AI95-00351-01AI95-00351-01} An implementation should support leap
+seconds if the target system supports them. If leap seconds are not
+supported, Difference should return zero for Leap_Seconds, Split should
+return False for Leap_Second, and Time_Of should raise Time_Error if
+Leap_Second is True.
+
+89.a/2
+ Implementation Advice: Leap seconds should be supported if the
+ target system supports them. Otherwise, operations in
+ Calendar.Formatting should return results consistent with no
+ leap seconds.
+
+89.b/2
+ Discussion: An implementation can always support leap seconds
+ when the target system does not; indeed, this isn't
+ particularly hard (all that is required is a table of when
+ leap seconds were inserted). As such, leap second support
+ isn't "impossible or impractical" in the sense of *note
+ 1.1.3::. However, for some purposes, it may be important to
+ follow the target system's lack of leap second support (if the
+ target is a GPS satellite, which does not use leap seconds,
+ leap second support would be a handicap to work around).
+ Thus, this Implementation Advice should be read as giving
+ permission to not support leap seconds on target systems that
+ don't support leap seconds. Implementers should use the needs
+ of their customers to determine whether or not support leap
+ seconds on such targets.
+
+ NOTES
+
+90/2
+ 38 {AI95-00351-01AI95-00351-01} The implementation-defined time
+ zone of package Calendar may, but need not, be the local time zone.
+ UTC_Time_Offset always returns the difference relative to the
+ implementation-defined time zone of package Calendar. If
+ UTC_Time_Offset does not raise Unknown_Zone_Error, UTC time can be
+ safely calculated (within the accuracy of the underlying
+ time-base).
+
+90.a/2
+ Discussion: {AI95-00351-01AI95-00351-01} The time in the time
+ zone known as Greenwich Mean Time (GMT) is generally very
+ close to UTC time; for most purposes they can be treated the
+ same. GMT is the time based on the rotation of the Earth; UTC
+ is the time based on atomic clocks, with leap seconds
+ periodically inserted to realign with GMT (because most human
+ activities depend on the rotation of the Earth). At any point
+ in time, there will be a sub-second difference between GMT and
+ UTC.
+
+91/2
+ 39 {AI95-00351-01AI95-00351-01} Calling Split on the results of
+ subtracting Duration(UTC_Time_Offset*60) from Clock provides the
+ components (hours, minutes, and so on) of the UTC time. In the
+ United States, for example, UTC_Time_Offset will generally be
+ negative.
+
+91.a/2
+ Discussion: This is an illustration to help specify the value
+ of UTC_Time_Offset. A user should pass UTC_Time_Offset as the
+ Time_Zone parameter of Split, rather than trying to make the
+ above calculation.
+
+ _Extensions to Ada 95_
+
+91.b/2
+ {AI95-00351-01AI95-00351-01} {AI95-00428-01AI95-00428-01}
+ Packages Calendar.Time_Zones, Calendar.Arithmetic, and
+ Calendar.Formatting are new.
+
+ _Inconsistencies With Ada 2005_
+
+91.c/3
+ {AI05-0238-1AI05-0238-1} Correction: Defined that Split for
+ Seconds raises Time_Error for a value of exactly 86400.0,
+ rather than breaking some invariant or raising some other
+ exception. Ada 2005 left this unspecified; a program that
+ depended on what some implementation does might break, but
+ such a program is not portable anyway.
+
+ _Wording Changes from Ada 2005_
+
+91.d/3
+ {AI05-0119-1AI05-0119-1} Correction: Clarified the sign of
+ UTC_Time_Offset.
+
+\1f
+File: aarm2012.info, Node: 9.7, Next: 9.8, Prev: 9.6, Up: 9
+
+9.7 Select Statements
+=====================
+
+1
+[There are four forms of the select_statement. One form provides a
+selective wait for one or more select_alternatives. Two provide timed
+and conditional entry calls. The fourth provides asynchronous transfer
+of control.]
+
+ _Syntax_
+
+2
+ select_statement ::=
+ selective_accept
+ | timed_entry_call
+ | conditional_entry_call
+ | asynchronous_select
+
+ _Examples_
+
+3
+Example of a select statement:
+
+4
+ select
+ accept Driver_Awake_Signal;
+ or
+ delay 30.0*Seconds;
+ Stop_The_Train;
+ end select;
+
+ _Extensions to Ada 83_
+
+4.a
+ Asynchronous_select is new.
+
+* Menu:
+
+* 9.7.1 :: Selective Accept
+* 9.7.2 :: Timed Entry Calls
+* 9.7.3 :: Conditional Entry Calls
+* 9.7.4 :: Asynchronous Transfer of Control
+
+\1f
+File: aarm2012.info, Node: 9.7.1, Next: 9.7.2, Up: 9.7
+
+9.7.1 Selective Accept
+----------------------
+
+1
+[This form of the select_statement allows a combination of waiting for,
+and selecting from, one or more alternatives. The selection may depend
+on conditions associated with each alternative of the selective_accept.
+]
+
+ _Syntax_
+
+2
+ selective_accept ::=
+ select
+ [guard]
+ select_alternative
+ { or
+ [guard]
+ select_alternative }
+ [ else
+ sequence_of_statements ]
+ end select;
+
+3
+ guard ::= when condition =>
+
+4
+ select_alternative ::=
+ accept_alternative
+ | delay_alternative
+ | terminate_alternative
+
+5
+ accept_alternative ::=
+ accept_statement [sequence_of_statements]
+
+6
+ delay_alternative ::=
+ delay_statement [sequence_of_statements]
+
+7
+ terminate_alternative ::= terminate;
+
+8
+ A selective_accept shall contain at least one accept_alternative.
+ In addition, it can contain:
+
+9
+ * a terminate_alternative (only one); or
+
+10
+ * one or more delay_alternatives; or
+
+11
+ * an else part (the reserved word else followed by a
+ sequence_of_statements).
+
+12
+ These three possibilities are mutually exclusive.
+
+ _Legality Rules_
+
+13
+If a selective_accept contains more than one delay_alternative, then all
+shall be delay_relative_statement (*note 9.6: S0229.)s, or all shall be
+delay_until_statement (*note 9.6: S0228.)s for the same time type.
+
+13.a
+ Reason: This simplifies the implementation and the description
+ of the semantics.
+
+ _Dynamic Semantics_
+
+14
+A select_alternative is said to be open if it is not immediately
+preceded by a guard, or if the condition of its guard evaluates to True.
+It is said to be closed otherwise.
+
+15
+For the execution of a selective_accept, any guard conditions are
+evaluated; open alternatives are thus determined. For an open
+delay_alternative, the delay_expression is also evaluated. Similarly,
+for an open accept_alternative for an entry of a family, the entry_index
+is also evaluated. These evaluations are performed in an arbitrary
+order, except that a delay_expression or entry_index is not evaluated
+until after evaluating the corresponding condition, if any. Selection
+and execution of one open alternative, or of the else part, then
+completes the execution of the selective_accept; the rules for this
+selection are described below.
+
+16
+Open accept_alternatives are first considered. Selection of one such
+alternative takes place immediately if the corresponding entry already
+has queued calls. If several alternatives can thus be selected, one of
+them is selected according to the entry queuing policy in effect (see
+*note 9.5.3:: and *note D.4::). When such an alternative is selected,
+the selected call is removed from its entry queue and the
+handled_sequence_of_statements (*note 11.2: S0265.) (if any) of the
+corresponding accept_statement is executed; after the rendezvous
+completes any subsequent sequence_of_statements (*note 5.1: S0145.) of
+the alternative is executed. If no selection is immediately possible
+(in the above sense) and there is no else part, the task blocks until an
+open alternative can be selected.
+
+17
+Selection of the other forms of alternative or of an else part is
+performed as follows:
+
+18
+ * An open delay_alternative is selected when its expiration time is
+ reached if no accept_alternative (*note 9.7.1: S0234.) or other
+ delay_alternative (*note 9.7.1: S0235.) can be selected prior to
+ the expiration time. If several delay_alternative (*note 9.7.1:
+ S0235.)s have this same expiration time, one of them is selected
+ according to the queuing policy in effect (see *note D.4::); the
+ default queuing policy chooses arbitrarily among the
+ delay_alternative (*note 9.7.1: S0235.)s whose expiration time has
+ passed.
+
+19
+ * The else part is selected and its sequence_of_statements (*note
+ 5.1: S0145.) is executed if no accept_alternative can immediately
+ be selected; in particular, if all alternatives are closed.
+
+20/3
+ * {AI05-0299-1AI05-0299-1} An open terminate_alternative is selected
+ if the conditions stated at the end of subclause *note 9.3:: are
+ satisfied.
+
+20.a
+ Ramification: In the absence of a requeue_statement, the
+ conditions stated are such that a terminate_alternative cannot
+ be selected while there is a queued entry call for any entry
+ of the task. In the presence of requeues from a task to one
+ of its subtasks, it is possible that when a
+ terminate_alternative of the subtask is selected, requeued
+ calls (for closed entries only) might still be queued on some
+ entry of the subtask. Tasking_Error will be propagated to
+ such callers, as is usual when a task completes while queued
+ callers remain.
+
+21
+The exception Program_Error is raised if all alternatives are closed and
+there is no else part.
+
+ NOTES
+
+22
+ 40 A selective_accept is allowed to have several open
+ delay_alternatives. A selective_accept is allowed to have several
+ open accept_alternatives for the same entry.
+
+ _Examples_
+
+23
+Example of a task body with a selective accept:
+
+24
+ task body Server is
+ Current_Work_Item : Work_Item;
+ begin
+ loop
+ select
+ accept Next_Work_Item(WI : in Work_Item) do
+ Current_Work_Item := WI;
+ end;
+ Process_Work_Item(Current_Work_Item);
+ or
+ accept Shut_Down;
+ exit; -- Premature shut down requested
+ or
+ terminate; -- Normal shutdown at end of scope
+ end select;
+ end loop;
+ end Server;
+
+ _Wording Changes from Ada 83_
+
+24.a
+ The name of selective_wait was changed to selective_accept to
+ better describe what is being waited for. We kept
+ select_alternative as is, because selective_accept_alternative
+ was too easily confused with accept_alternative.
+
+\1f
+File: aarm2012.info, Node: 9.7.2, Next: 9.7.3, Prev: 9.7.1, Up: 9.7
+
+9.7.2 Timed Entry Calls
+-----------------------
+
+1/2
+{AI95-00345-01AI95-00345-01} [A timed_entry_call issues an entry call
+that is cancelled if the call (or a requeue-with-abort of the call) is
+not selected before the expiration time is reached. A procedure call
+may appear rather than an entry call for cases where the procedure might
+be implemented by an entry. ]
+
+ _Syntax_
+
+2
+ timed_entry_call ::=
+ select
+ entry_call_alternative
+ or
+ delay_alternative
+ end select;
+
+3/2
+ {AI95-00345-01AI95-00345-01} entry_call_alternative ::=
+ procedure_or_entry_call [sequence_of_statements]
+
+3.1/2
+ {AI95-00345-01AI95-00345-01} procedure_or_entry_call ::=
+ procedure_call_statement | entry_call_statement
+
+ _Legality Rules_
+
+3.2/2
+{AI95-00345-01AI95-00345-01} If a procedure_call_statement is used for a
+procedure_or_entry_call, the procedure_name or procedure_prefix of the
+procedure_call_statement shall statically denote an entry renamed as a
+procedure or (a view of) a primitive subprogram of a limited interface
+whose first parameter is a controlling parameter (see *note 3.9.2::).
+
+3.a/2
+ Reason: This would be a confusing way to call a procedure, so
+ we only allow it when it is possible that the procedure is
+ actually an entry. We could have allowed formal subprograms
+ here, but we didn't because we'd have to allow all formal
+ subprograms, and it would increase the difficulty of generic
+ code sharing.
+
+3.b/2
+ We say "statically denotes" because an access-to-subprogram
+ cannot be primitive, and we don't have anything like
+ access-to-entry. So only names of entries or procedures are
+ possible.
+
+ _Dynamic Semantics_
+
+4/2
+{AI95-00345-01AI95-00345-01} For the execution of a timed_entry_call,
+the entry_name, procedure_name, or procedure_prefix, and any actual
+parameters are evaluated, as for a simple entry call (see *note 9.5.3::)
+or procedure call (see *note 6.4::). The expiration time (see *note
+9.6::) for the call is determined by evaluating the delay_expression of
+the delay_alternative. If the call is an entry call or a call on a
+procedure implemented by an entry, the entry call is then issued.
+Otherwise, the call proceeds as described in *note 6.4:: for a procedure
+call, followed by the sequence_of_statements (*note 5.1: S0145.) of the
+entry_call_alternative (*note 9.7.2: S0238.); the sequence_of_statements
+(*note 5.1: S0145.) of the delay_alternative (*note 9.7.1: S0235.) is
+ignored.
+
+5
+If the call is queued (including due to a requeue-with-abort), and not
+selected before the expiration time is reached, an attempt to cancel the
+call is made. If the call completes due to the cancellation, the
+optional sequence_of_statements (*note 5.1: S0145.) of the
+delay_alternative (*note 9.7.1: S0235.) is executed; if the entry call
+completes normally, the optional sequence_of_statements (*note 5.1:
+S0145.) of the entry_call_alternative (*note 9.7.2: S0238.) is executed.
+
+5.a/2
+ This paragraph was deleted.{AI95-00345-01AI95-00345-01}
+
+ _Examples_
+
+6
+Example of a timed entry call:
+
+7
+ select
+ Controller.Request(Medium)(Some_Item);
+ or
+ delay 45.0;
+ -- controller too busy, try something else
+ end select;
+
+ _Wording Changes from Ada 83_
+
+7.a/3
+ {AI05-0299-1AI05-0299-1} This subclause comes before the one
+ for Conditional Entry Calls, so we can define conditional
+ entry calls in terms of timed entry calls.
+
+ _Incompatibilities With Ada 95_
+
+7.b/3
+ {AI95-00345-01AI95-00345-01} {AI05-0005-1AI05-0005-1} A
+ procedure call can be used as the entry_call_alternative in a
+ timed or conditional entry call, if the procedure might
+ actually be an entry. Since the fact that something is an
+ entry could be used in resolving these calls in Ada 95, it is
+ possible for timed or conditional entry calls that resolved in
+ Ada 95 to be ambiguous in Ada 2005. That could happen if both
+ an entry and procedure with the same name and profile exist,
+ which should be rare.
+
+\1f
+File: aarm2012.info, Node: 9.7.3, Next: 9.7.4, Prev: 9.7.2, Up: 9.7
+
+9.7.3 Conditional Entry Calls
+-----------------------------
+
+1/2
+{AI95-00345-01AI95-00345-01} [A conditional_entry_call issues an entry
+call that is then cancelled if it is not selected immediately (or if a
+requeue-with-abort of the call is not selected immediately). A
+procedure call may appear rather than an entry call for cases where the
+procedure might be implemented by an entry.]
+
+1.a
+ To be honest: In the case of an entry call on a protected
+ object, it is OK if the entry is closed at the start of the
+ corresponding protected action, so long as it opens and the
+ call is selected before the end of that protected action (due
+ to changes in the Count attribute).
+
+ _Syntax_
+
+2
+ conditional_entry_call ::=
+ select
+ entry_call_alternative
+ else
+ sequence_of_statements
+ end select;
+
+ _Dynamic Semantics_
+
+3
+The execution of a conditional_entry_call is defined to be equivalent to
+the execution of a timed_entry_call (*note 9.7.2: S0237.) with a
+delay_alternative (*note 9.7.1: S0235.) specifying an immediate
+expiration time and the same sequence_of_statements (*note 5.1: S0145.)
+as given after the reserved word else.
+
+ NOTES
+
+4
+ 41 A conditional_entry_call may briefly increase the Count
+ attribute of the entry, even if the conditional call is not
+ selected.
+
+ _Examples_
+
+5
+Example of a conditional entry call:
+
+6
+ procedure Spin(R : in Resource) is
+ begin
+ loop
+ select
+ R.Seize;
+ return;
+ else
+ null; -- busy waiting
+ end select;
+ end loop;
+ end;
+
+ _Wording Changes from Ada 83_
+
+6.a/3
+ {AI05-0299-1AI05-0299-1} This subclause comes after the one
+ for Timed Entry Calls, so we can define conditional entry
+ calls in terms of timed entry calls. We do that so that an
+ "expiration time" is defined for both, thereby simplifying the
+ definition of what happens on a requeue-with-abort.
+
+\1f
+File: aarm2012.info, Node: 9.7.4, Prev: 9.7.3, Up: 9.7
+
+9.7.4 Asynchronous Transfer of Control
+--------------------------------------
+
+1
+[An asynchronous select_statement provides asynchronous transfer of
+control upon completion of an entry call or the expiration of a delay.]
+
+ _Syntax_
+
+2
+ asynchronous_select ::=
+ select
+ triggering_alternative
+ then abort
+ abortable_part
+ end select;
+
+3
+ triggering_alternative ::= triggering_statement [
+ sequence_of_statements]
+
+4/2
+ {AI95-00345-01AI95-00345-01} triggering_statement ::=
+ procedure_or_entry_call | delay_statement
+
+5
+ abortable_part ::= sequence_of_statements
+
+ _Dynamic Semantics_
+
+6/2
+{AI95-00345-01AI95-00345-01} For the execution of an asynchronous_select
+whose triggering_statement (*note 9.7.4: S0243.) is a
+procedure_or_entry_call, the entry_name, procedure_name, or
+procedure_prefix, and actual parameters are evaluated as for a simple
+entry call (see *note 9.5.3::) or procedure call (see *note 6.4::). If
+the call is an entry call or a call on a procedure implemented by an
+entry, the entry call is issued. If the entry call is queued (or
+requeued-with-abort), then the abortable_part is executed. [If the
+entry call is selected immediately, and never requeued-with-abort, then
+the abortable_part is never started.] If the call is on a procedure
+that is not implemented by an entry, the call proceeds as described in
+*note 6.4::, followed by the sequence_of_statements (*note 5.1: S0145.)
+of the triggering_alternative (*note 9.7.4: S0242.)[; the abortable_part
+is never started].
+
+7
+For the execution of an asynchronous_select whose triggering_statement
+(*note 9.7.4: S0243.) is a delay_statement, the delay_expression is
+evaluated and the expiration time is determined, as for a normal
+delay_statement. If the expiration time has not already passed, the
+abortable_part is executed.
+
+8
+If the abortable_part completes and is left prior to completion of the
+triggering_statement (*note 9.7.4: S0243.), an attempt to cancel the
+triggering_statement (*note 9.7.4: S0243.) is made. If the attempt to
+cancel succeeds (see *note 9.5.3:: and *note 9.6::), the
+asynchronous_select is complete.
+
+9
+If the triggering_statement (*note 9.7.4: S0243.) completes other than
+due to cancellation, the abortable_part is aborted (if started but not
+yet completed -- see *note 9.8::). If the triggering_statement (*note
+9.7.4: S0243.) completes normally, the optional sequence_of_statements
+(*note 5.1: S0145.) of the triggering_alternative (*note 9.7.4: S0242.)
+is executed after the abortable_part is left.
+
+9.a
+ Discussion: We currently don't specify when the by-copy [in]
+ out parameters are assigned back into the actuals. We
+ considered requiring that to happen after the abortable_part
+ is left. However, that doesn't seem useful enough to justify
+ possibly overspecifying the implementation approach, since
+ some of the parameters are passed by reference anyway.
+
+9.b
+ In an earlier description, we required that the
+ sequence_of_statements (*note 5.1: S0145.) of the
+ triggering_alternative (*note 9.7.4: S0242.) execute after
+ aborting the abortable_part, but before waiting for it to
+ complete and finalize, to provide more rapid response to the
+ triggering event in case the finalization was unbounded.
+ However, various reviewers felt that this created unnecessary
+ complexity in the description, and a potential for undesirable
+ concurrency (and nondeterminism) within a single task. We
+ have now reverted to simpler, more deterministic semantics,
+ but anticipate that further discussion of this issue might be
+ appropriate during subsequent reviews. One possibility is to
+ leave this area implementation defined, so as to encourage
+ experimentation. The user would then have to assume the worst
+ about what kinds of actions are appropriate for the
+ sequence_of_statements (*note 5.1: S0145.) of the
+ triggering_alternative (*note 9.7.4: S0242.) to achieve
+ portability.
+
+ _Examples_
+
+10
+Example of a main command loop for a command interpreter:
+
+11
+ loop
+ select
+ Terminal.Wait_For_Interrupt;
+ Put_Line("Interrupted");
+ then abort
+ -- This will be abandoned upon terminal interrupt
+ Put_Line("-> ");
+ Get_Line(Command, Last);
+ Process_Command(Command(1..Last));
+ end select;
+ end loop;
+
+12
+Example of a time-limited calculation:
+
+13
+ select
+ delay 5.0;
+ Put_Line("Calculation does not converge");
+ then abort
+ -- This calculation should finish in 5.0 seconds;
+ -- if not, it is assumed to diverge.
+ Horribly_Complicated_Recursive_Function(X, Y);
+ end select;
+
+ _Extensions to Ada 83_
+
+13.a
+ Asynchronous_select is new.
+
+ _Extensions to Ada 95_
+
+13.b/2
+ {AI95-00345-01AI95-00345-01} A procedure can be used as the
+ triggering_statement (*note 9.7.4: S0243.) of an
+ asynchronous_select, if the procedure might actually be an
+ entry.
+
+\1f
+File: aarm2012.info, Node: 9.8, Next: 9.9, Prev: 9.7, Up: 9
+
+9.8 Abort of a Task - Abort of a Sequence of Statements
+=======================================================
+
+1
+[An abort_statement causes one or more tasks to become abnormal, thus
+preventing any further interaction with such tasks. The completion of
+the triggering_statement (*note 9.7.4: S0243.) of an asynchronous_select
+causes a sequence_of_statements (*note 5.1: S0145.) to be aborted.]
+
+ _Syntax_
+
+2
+ abort_statement ::= abort task_name {, task_name};
+
+ _Name Resolution Rules_
+
+3
+Each task_name is expected to be of any task type[; they need not all be
+of the same task type.]
+
+ _Dynamic Semantics_
+
+4
+For the execution of an abort_statement, the given task_names are
+evaluated in an arbitrary order. Each named task is then aborted, which
+consists of making the task abnormal and aborting the execution of the
+corresponding task_body, unless it is already completed.
+
+4.a/2
+ Ramification: {AI95-00114-01AI95-00114-01} Note that aborting
+ those tasks is not defined to be an abort-deferred operation.
+ Therefore, if one of the named tasks is the task executing the
+ abort_statement, or if the task executing the abort_statement
+ depends on one of the named tasks, then it is possible for the
+ execution of the abort_statement to be aborted, thus leaving
+ some of the tasks unaborted. This allows the implementation
+ to use either a sequence of calls to an "abort task" run-time
+ system primitive, or a single call to an "abort list of tasks"
+ run-time system primitive.
+
+5
+When the execution of a construct is aborted (including that of a
+task_body (*note 9.1: S0209.) or of a sequence_of_statements (*note 5.1:
+S0145.)), the execution of every construct included within the aborted
+execution is also aborted, except for executions included within the
+execution of an abort-deferred operation; the execution of an
+abort-deferred operation continues to completion without being affected
+by the abort; the following are the abort-deferred operations:
+
+6
+ * a protected action;
+
+7
+ * waiting for an entry call to complete (after having initiated the
+ attempt to cancel it -- see below);
+
+8
+ * waiting for the termination of dependent tasks;
+
+9
+ * the execution of an Initialize procedure as the last step of the
+ default initialization of a controlled object;
+
+10
+ * the execution of a Finalize procedure as part of the finalization
+ of a controlled object;
+
+11
+ * an assignment operation to an object with a controlled part.
+
+12
+[The last three of these are discussed further in *note 7.6::.]
+
+12.a
+ Reason: Deferring abort during Initialize and finalization
+ allows, for example, the result of an allocator performed in
+ an Initialize operation to be assigned into an access object
+ without being interrupted in the middle, which would cause
+ storage leaks. For an object with several controlled parts,
+ each individual Initialize is abort-deferred. Note that there
+ is generally no semantic difference between making each
+ Finalize abort-deferred, versus making a group of them
+ abort-deferred, because if the task gets aborted, the first
+ thing it will do is complete any remaining finalizations.
+ Individual objects are finalized prior to an assignment
+ operation (if nonlimited controlled) and as part of
+ Unchecked_Deallocation.
+
+12.b
+ Ramification: Abort is deferred during the entire assignment
+ operation to an object with a controlled part, even if only
+ some subcomponents are controlled. Note that this says
+ "assignment operation," not "assignment_statement." Explicit
+ calls to Initialize, Finalize, or Adjust are not
+ abort-deferred.
+
+13
+When a master is aborted, all tasks that depend on that master are
+aborted.
+
+14
+The order in which tasks become abnormal as the result of an
+abort_statement or the abort of a sequence_of_statements (*note 5.1:
+S0145.) is not specified by the language.
+
+15
+If the execution of an entry call is aborted, an immediate attempt is
+made to cancel the entry call (see *note 9.5.3::). If the execution of
+a construct is aborted at a time when the execution is blocked, other
+than for an entry call, at a point that is outside the execution of an
+abort-deferred operation, then the execution of the construct completes
+immediately. For an abort due to an abort_statement, these immediate
+effects occur before the execution of the abort_statement completes.
+Other than for these immediate cases, the execution of a construct that
+is aborted does not necessarily complete before the abort_statement
+completes. However, the execution of the aborted construct completes no
+later than its next abort completion point (if any) that occurs outside
+of an abort-deferred operation; the following are abort completion
+points for an execution:
+
+16
+ * the point where the execution initiates the activation of another
+ task;
+
+17
+ * the end of the activation of a task;
+
+18
+ * the start or end of the execution of an entry call,
+ accept_statement, delay_statement, or abort_statement;
+
+18.a
+ Ramification: Although the abort completion point doesn't
+ occur until the end of the entry call or delay_statement,
+ these operations might be cut short because an abort attempts
+ to cancel them.
+
+19
+ * the start of the execution of a select_statement, or of the
+ sequence_of_statements (*note 5.1: S0145.) of an exception_handler.
+
+19.a
+ Reason: The start of an exception_handler is considered an
+ abort completion point simply because it is easy for an
+ implementation to check at such points.
+
+19.b
+ Implementation Note: Implementations may of course check for
+ abort more often than at each abort completion point; ideally,
+ a fully preemptive implementation of abort will be provided.
+ If preemptive abort is not supported in a given environment,
+ then supporting the checking for abort as part of subprogram
+ calls and loop iterations might be a useful option.
+
+ _Bounded (Run-Time) Errors_
+
+20/3
+{AI05-0264-1AI05-0264-1} An attempt to execute an asynchronous_select as
+part of the execution of an abort-deferred operation is a bounded error.
+Similarly, an attempt to create a task that depends on a master that is
+included entirely within the execution of an abort-deferred operation is
+a bounded error. In both cases, Program_Error is raised if the error is
+detected by the implementation; otherwise, the operations proceed as
+they would outside an abort-deferred operation, except that an abort of
+the abortable_part or the created task might or might not have an
+effect.
+
+20.a
+ Reason: An asynchronous_select relies on an abort of the
+ abortable_part to effect the asynchronous transfer of control.
+ For an asynchronous_select within an abort-deferred operation,
+ the abort might have no effect.
+
+20.b
+ Creating a task dependent on a master included within an
+ abort-deferred operation is considered an error, because such
+ tasks could be aborted while the abort-deferred operation was
+ still progressing, undermining the purpose of abort-deferral.
+ Alternatively, we could say that such tasks are abort-deferred
+ for their entire execution, but that seems too easy to abuse.
+ Note that task creation is already a bounded error in
+ protected actions, so this additional rule only applies to
+ local task creation as part of Initialize, Finalize, or
+ Adjust.
+
+ _Erroneous Execution_
+
+21
+If an assignment operation completes prematurely due to an abort, the
+assignment is said to be disrupted; the target of the assignment or its
+parts can become abnormal, and certain subsequent uses of the object can
+be erroneous, as explained in *note 13.9.1::.
+
+ NOTES
+
+22
+ 42 An abort_statement should be used only in situations requiring
+ unconditional termination.
+
+23
+ 43 A task is allowed to abort any task it can name, including
+ itself.
+
+24
+ 44 Additional requirements associated with abort are given in
+ *note D.6::, "*note D.6:: Preemptive Abort".
+
+ _Wording Changes from Ada 83_
+
+24.a/3
+ {AI05-0299-1AI05-0299-1} This subclause has been rewritten to
+ accommodate the concept of aborting the execution of a
+ construct, rather than just of a task.
+
+\1f
+File: aarm2012.info, Node: 9.9, Next: 9.10, Prev: 9.8, Up: 9
+
+9.9 Task and Entry Attributes
+=============================
+
+ _Dynamic Semantics_
+
+1
+For a prefix T that is of a task type [(after any implicit
+dereference)], the following attributes are defined:
+
+2
+T'Callable
+ Yields the value True when the task denoted by T is
+ callable, and False otherwise; a task is callable unless
+ it is completed or abnormal. The value of this attribute
+ is of the predefined type Boolean.
+
+3
+T'Terminated
+ Yields the value True if the task denoted by T is
+ terminated, and False otherwise. The value of this
+ attribute is of the predefined type Boolean.
+
+4
+For a prefix E that denotes an entry of a task or protected unit, the
+following attribute is defined. This attribute is only allowed within
+the body of the task or protected unit, but excluding, in the case of an
+entry of a task unit, within any program unit that is, itself, inner to
+the body of the task unit.
+
+5
+E'Count
+ Yields the number of calls presently queued on the entry
+ E of the current instance of the unit. The value of this
+ attribute is of the type universal_integer.
+
+ NOTES
+
+6
+ 45 For the Count attribute, the entry can be either a single entry
+ or an entry of a family. The name of the entry or entry family can
+ be either a direct_name or an expanded name.
+
+7
+ 46 Within task units, algorithms interrogating the attribute
+ E'Count should take precautions to allow for the increase of the
+ value of this attribute for incoming entry calls, and its decrease,
+ for example with timed_entry_calls. Also, a conditional_entry_call
+ may briefly increase this value, even if the conditional call is
+ not accepted.
+
+8
+ 47 Within protected units, algorithms interrogating the attribute
+ E'Count in the entry_barrier for the entry E should take
+ precautions to allow for the evaluation of the condition of the
+ barrier both before and after queuing a given caller.
+
+\1f
+File: aarm2012.info, Node: 9.10, Next: 9.11, Prev: 9.9, Up: 9
+
+9.10 Shared Variables
+=====================
+
+ _Static Semantics_
+
+1/3
+{AI05-0009-1AI05-0009-1} {AI05-0201-1AI05-0201-1}
+{AI05-0229-1AI05-0229-1} {AI05-0295-1AI05-0295-1} If two different
+objects, including nonoverlapping parts of the same object, are
+independently addressable, they can be manipulated concurrently by two
+different tasks without synchronization. Any two nonoverlapping objects
+are independently addressable if either object is specified as
+independently addressable (see *note C.6::). Otherwise, two
+nonoverlapping objects are independently addressable except when they
+are both parts of a composite object for which a nonconfirming value is
+specified for any of the following representation aspects: (record)
+Layout, Component_Size, Pack, Atomic, or Convention; in this case it is
+unspecified whether the parts are independently addressable.
+
+1.a/3
+ This paragraph was deleted.
+
+1.b/3
+ Implementation Note: {AI05-0229-1AI05-0229-1} Independent
+ addressability is the only high level semantic effect of
+ aspect Pack. If two objects are independently addressable,
+ the implementation should allocate them in such a way that
+ each can be written by the hardware without writing the other.
+ For example, unless the user asks for it, it is generally not
+ feasible to choose a bit-packed representation on a machine
+ without an atomic bit field insertion instruction, because
+ there might be tasks that update neighboring subcomponents
+ concurrently, and locking operations on all subcomponents is
+ generally not a good idea.
+
+1.c/3
+ {AI05-0229-1AI05-0229-1} Even if Pack or one of the other
+ above-mentioned aspects is specified, subcomponents should
+ still be updated independently if the hardware efficiently
+ supports it.
+
+1.d/3
+ Ramification: {AI05-0009-1AI05-0009-1}
+ {AI05-0201-1AI05-0201-1} An atomic object (including atomic
+ components) is always independently addressable from any other
+ nonoverlapping object. Any aspect_specification or
+ representation item which would prevent this from being true
+ should be rejected, notwithstanding what this Standard says
+ elsewhere. Note, however, that the components of an atomic
+ object are not necessarily atomic.
+
+ _Dynamic Semantics_
+
+2
+[Separate tasks normally proceed independently and concurrently with one
+another. However, task interactions can be used to synchronize the
+actions of two or more tasks to allow, for example, meaningful
+communication by the direct updating and reading of variables shared
+between the tasks.] The actions of two different tasks are synchronized
+in this sense when an action of one task signals an action of the other
+task; an action A1 is defined to signal an action A2 under the following
+circumstances:
+
+3
+ * If A1 and A2 are part of the execution of the same task, and the
+ language rules require A1 to be performed before A2;
+
+4
+ * If A1 is the action of an activator that initiates the activation
+ of a task, and A2 is part of the execution of the task that is
+ activated;
+
+5
+ * If A1 is part of the activation of a task, and A2 is the action of
+ waiting for completion of the activation;
+
+6
+ * If A1 is part of the execution of a task, and A2 is the action of
+ waiting for the termination of the task;
+
+6.1/3
+ * {8652/00318652/0031} {AI95-00118-01AI95-00118-01}
+ {AI05-0072-1AI05-0072-1} If A1 is the termination of a task T, and
+ A2 is either an evaluation of the expression T'Terminated that
+ results in True, or a call to Ada.Task_Identification.Is_Terminated
+ with an actual parameter that identifies T and a result of True
+ (see *note C.7.1::);
+
+7/3
+ * {AI05-0262-1AI05-0262-1} If A1 is the action of issuing an entry
+ call, and A2 is part of the corresponding execution of the
+ appropriate entry_body or accept_statement;
+
+7.a
+ Ramification: Evaluating the entry_index of an
+ accept_statement is not synchronized with a corresponding
+ entry call, nor is evaluating the entry barrier of an
+ entry_body.
+
+8
+ * If A1 is part of the execution of an accept_statement or
+ entry_body, and A2 is the action of returning from the
+ corresponding entry call;
+
+9
+ * If A1 is part of the execution of a protected procedure body or
+ entry_body for a given protected object, and A2 is part of a later
+ execution of an entry_body for the same protected object;
+
+9.a
+ Reason: The underlying principle here is that for one action
+ to "signal" a second, the second action has to follow a
+ potentially blocking operation, whose blocking is dependent on
+ the first action in some way. Protected procedures are not
+ potentially blocking, so they can only be "signalers," they
+ cannot be signaled.
+
+9.b
+ Ramification: Protected subprogram calls are not defined to
+ signal one another, which means that such calls alone cannot
+ be used to synchronize access to shared data outside of a
+ protected object.
+
+9.c
+ Reason: The point of this distinction is so that on
+ multiprocessors with inconsistent caches, the caches only need
+ to be refreshed at the beginning of an entry body, and forced
+ out at the end of an entry body or protected procedure that
+ leaves an entry open. Protected function calls, and protected
+ subprogram calls for entryless protected objects do not
+ require full cache consistency. Entryless protected objects
+ are intended to be treated roughly like atomic objects -- each
+ operation is indivisible with respect to other operations
+ (unless both are reads), but such operations cannot be used to
+ synchronize access to other nonvolatile shared variables.
+
+10
+ * If A1 signals some action that in turn signals A2.
+
+ _Erroneous Execution_
+
+11
+Given an action of assigning to an object, and an action of reading or
+updating a part of the same object (or of a neighboring object if the
+two are not independently addressable), then the execution of the
+actions is erroneous unless the actions are sequential. Two actions are
+sequential if one of the following is true:
+
+12
+ * One action signals the other;
+
+13
+ * Both actions occur as part of the execution of the same task;
+
+13.a
+ Reason: Any two actions of the same task are sequential, even
+ if one does not signal the other because they can be executed
+ in an "arbitrary" (but necessarily equivalent to some
+ "sequential") order.
+
+14
+ * Both actions occur as part of protected actions on the same
+ protected object, and at most one of the actions is part of a call
+ on a protected function of the protected object.
+
+14.a
+ Reason: Because actions within protected actions do not always
+ imply signaling, we have to mention them here explicitly to
+ make sure that actions occurring within different protected
+ actions of the same protected object are sequential with
+ respect to one another (unless both are part of calls on
+ protected functions).
+
+14.b
+ Ramification: It doesn't matter whether or not the variable
+ being assigned is actually a subcomponent of the protected
+ object; globals can be safely updated from within the bodies
+ of protected procedures or entries.
+
+15/3
+{AI05-0229-1AI05-0229-1} Aspect Atomic or aspect Atomic_Components may
+also be specified to ensure that certain reads and updates are
+sequential -- see *note C.6::.
+
+15.a
+ Ramification: If two actions are "sequential" it is known that
+ their executions don't overlap in time, but it is not
+ necessarily specified which occurs first. For example, all
+ actions of a single task are sequential, even though the exact
+ order of execution is not fully specified for all constructs.
+
+15.b
+ Discussion: Note that if two assignments to the same variable
+ are sequential, but neither signals the other, then the
+ program is not erroneous, but it is not specified which
+ assignment ultimately prevails. Such a situation usually
+ corresponds to a programming mistake, but in some (rare)
+ cases, the order makes no difference, and for this reason this
+ situation is not considered erroneous nor even a bounded
+ error. In Ada 83, this was considered an "incorrect order
+ dependence" if the "effect" of the program was affected, but
+ "effect" was never fully defined. In Ada 95, this situation
+ represents a potential nonportability, and a friendly compiler
+ might want to warn the programmer about the situation, but it
+ is not considered an error. An example where this would come
+ up would be in gathering statistics as part of referencing
+ some information, where the assignments associated with
+ statistics gathering don't need to be ordered since they are
+ just accumulating aggregate counts, sums, products, etc.
+
+ _Wording Changes from Ada 95_
+
+15.c/2
+ {8652/00318652/0031} {AI95-00118-01AI95-00118-01} Corrigendum:
+ Clarified that a task T2 can rely on values of variables that
+ are updated by another task T1, if task T2 first verifies that
+ T1'Terminated is True.
+
+ _Wording Changes from Ada 2005_
+
+15.d/3
+ {AI05-0009-1AI05-0009-1} {AI05-0201-1AI05-0201-1} Correction:
+ Revised the definition of independent addressability to
+ exclude conforming representation clauses and to require that
+ atomic and independent objects always have independent
+ addressability. This should not change behavior that the user
+ sees for any Ada program, so it is not an inconsistency.
+
+15.e/3
+ {AI05-0072-1AI05-0072-1} Correction: Corrected the wording of
+ AI95-00118-01 to actually say what was intended (as described
+ above).
+
+\1f
+File: aarm2012.info, Node: 9.11, Prev: 9.10, Up: 9
+
+9.11 Example of Tasking and Synchronization
+===========================================
+
+ _Examples_
+
+1
+The following example defines a buffer protected object to smooth
+variations between the speed of output of a producing task and the speed
+of input of some consuming task. For instance, the producing task might
+have the following structure:
+
+2
+ task Producer;
+
+3/2
+ {AI95-00433-01AI95-00433-01} task body Producer is
+ Person : Person_Name; -- see *note 3.10.1::
+ begin
+ loop
+ ... -- simulate arrival of the next customer
+ Buffer.Append_Wait(Person);
+ exit when Person = null;
+ end loop;
+ end Producer;
+
+4
+and the consuming task might have the following structure:
+
+5
+ task Consumer;
+
+6/2
+ {AI95-00433-01AI95-00433-01} task body Consumer is
+ Person : Person_Name;
+ begin
+ loop
+ Buffer.Remove_First_Wait(Person);
+ exit when Person = null;
+ ... -- simulate serving a customer
+ end loop;
+ end Consumer;
+
+7/2
+{AI95-00433-01AI95-00433-01} The buffer object contains an internal
+array of person names managed in a round-robin fashion. The array has
+two indices, an In_Index denoting the index for the next input person
+name and an Out_Index denoting the index for the next output person
+name.
+
+7.1/2
+{AI95-00433-01AI95-00433-01} The Buffer is defined as an extension of
+the Synchronized_Queue interface (see *note 3.9.4::), and as such
+promises to implement the abstraction defined by that interface. By
+doing so, the Buffer can be passed to the Transfer class-wide operation
+defined for objects of a type covered by Queue'Class.
+
+8/2
+ {AI95-00433-01AI95-00433-01} protected Buffer is new Synchronized_Queue with -- see *note 3.9.4::
+ entry Append_Wait(Person : in Person_Name);
+ entry Remove_First_Wait(Person : out Person_Name);
+ function Cur_Count return Natural;
+ function Max_Count return Natural;
+ procedure Append(Person : in Person_Name);
+ procedure Remove_First(Person : out Person_Name);
+ private
+ Pool : Person_Name_Array(1 .. 100);
+ Count : Natural := 0;
+ In_Index, Out_Index : Positive := 1;
+ end Buffer;
+
+9/2
+ {AI95-00433-01AI95-00433-01} protected body Buffer is
+ entry Append_Wait(Person : in Person_Name)
+ when Count < Pool'Length is
+ begin
+ Append(Person);
+ end Append_Wait;
+
+9.1/2
+ {AI95-00433-01AI95-00433-01} procedure Append(Person : in Person_Name) is
+ begin
+ if Count = Pool'Length then
+ raise Queue_Error with "Buffer Full"; -- see *note 11.3::
+ end if;
+ Pool(In_Index) := Person;
+ In_Index := (In_Index mod Pool'Length) + 1;
+ Count := Count + 1;
+ end Append;
+
+10/2
+ {AI95-00433-01AI95-00433-01} entry Remove_First_Wait(Person : out Person_Name)
+ when Count > 0 is
+ begin
+ Remove_First(Person);
+ end Remove_First_Wait;
+
+11/2
+ {AI95-00433-01AI95-00433-01} procedure Remove_First(Person : out Person_Name) is
+ begin
+ if Count = 0 then
+ raise Queue_Error with "Buffer Empty"; -- see *note 11.3::
+ end if;
+ Person := Pool(Out_Index);
+ Out_Index := (Out_Index mod Pool'Length) + 1;
+ Count := Count - 1;
+ end Remove_First;
+
+12/2
+ {AI95-00433-01AI95-00433-01} function Cur_Count return Natural is
+ begin
+ return Buffer.Count;
+ end Cur_Count;
+
+13/2
+ {AI95-00433-01AI95-00433-01} function Max_Count return Natural is
+ begin
+ return Pool'Length;
+ end Max_Count;
+ end Buffer;
+
+\1f
+File: aarm2012.info, Node: 10, Next: 11, Prev: 9, Up: Top
+
+10 Program Structure and Compilation Issues
+*******************************************
+
+1/3
+{AI05-0299-1AI05-0299-1} [The overall structure of programs and the
+facilities for separate compilation are described in this clause. A
+program is a set of partitions, each of which may execute in a separate
+address space, possibly on a separate computer.
+
+1.a
+ Glossary entry: A program is a set of partitions, each of
+ which may execute in a separate address space, possibly on a
+ separate computer. A partition consists of a set of library
+ units.
+
+1.b
+ Glossary entry: A partition is a part of a program. Each
+ partition consists of a set of library units. Each partition
+ may run in a separate address space, possibly on a separate
+ computer. A program may contain just one partition. A
+ distributed program typically contains multiple partitions,
+ which can execute concurrently.
+
+2
+As explained below, a partition is constructed from library units.
+Syntactically, the declaration of a library unit is a library_item, as
+is the body of a library unit. An implementation may support a concept
+of a program library (or simply, a "library"), which contains
+library_items and their subunits. Library units may be organized into a
+hierarchy of children, grandchildren, and so on.]
+
+3/3
+{AI05-0299-1AI05-0299-1} This clause has two subclauses: *note 10.1::,
+"*note 10.1:: Separate Compilation" discusses compile-time issues
+related to separate compilation. *note 10.2::, "*note 10.2:: Program
+Execution" discusses issues related to what is traditionally known as
+"link time" and "run time" -- building and executing partitions.
+
+ _Language Design Principles_
+
+3.a
+ We should avoid specifying details that are outside the domain
+ of the language itself. The standard is intended (at least in
+ part) to promote portability of Ada programs at the source
+ level. It is not intended to standardize extra-language
+ issues such as how one invokes the compiler (or other tools),
+ how one's source is represented and organized, version
+ management, the format of error messages, etc.
+
+3.b
+ The rules of the language should be enforced even in the
+ presence of separate compilation. Using separate compilation
+ should not make a program less safe.
+
+3.c
+ It should be possible to determine the legality of a
+ compilation unit by looking only at the compilation unit
+ itself and the compilation units upon which it depends
+ semantically. As an example, it should be possible to analyze
+ the legality of two compilation units in parallel if they do
+ not depend semantically upon each other.
+
+3.d
+ On the other hand, it may be necessary to look outside that
+ set in order to generate code -- this is generally true for
+ generic instantiation and inlining, for example. Also on the
+ other hand, it is generally necessary to look outside that set
+ in order to check Post-Compilation Rules.
+
+3.e
+ See also the "generic contract model" Language Design
+ Principle of *note 12.3::, "*note 12.3:: Generic
+ Instantiation".
+
+ _Wording Changes from Ada 83_
+
+3.f/3
+ {AI05-0299-1AI05-0299-1} The clause organization mentioned
+ above is different from that of RM83.
+
+* Menu:
+
+* 10.1 :: Separate Compilation
+* 10.2 :: Program Execution
+
+\1f
+File: aarm2012.info, Node: 10.1, Next: 10.2, Up: 10
+
+10.1 Separate Compilation
+=========================
+
+1
+[ A program unit is either a package, a task unit, a protected unit, a
+protected entry, a generic unit, or an explicitly declared subprogram
+other than an enumeration literal. Certain kinds of program units can
+be separately compiled. Alternatively, they can appear physically
+nested within other program units.
+
+2
+The text of a program can be submitted to the compiler in one or more
+compilations. Each compilation is a succession of compilation_units. A
+compilation_unit contains either the declaration, the body, or a
+renaming of a program unit.] The representation for a compilation is
+implementation-defined.
+
+2.a
+ Implementation defined: The representation for a compilation.
+
+2.b
+ Ramification: Some implementations might choose to make a
+ compilation be a source (text) file. Others might allow
+ multiple source files to be automatically concatenated to form
+ a single compilation. Others still may represent the source
+ in a nontextual form such as a parse tree. Note that the RM95
+ does not even define the concept of a source file.
+
+2.c
+ Note that a protected subprogram is a subprogram, and
+ therefore a program unit. An instance of a generic unit is a
+ program unit.
+
+2.d
+ A protected entry is a program unit, but protected entries
+ cannot be separately compiled.
+
+3
+A library unit is a separately compiled program unit, and is always a
+package, subprogram, or generic unit. Library units may have other
+(logically nested) library units as children, and may have other program
+units physically nested within them. A root library unit, together with
+its children and grandchildren and so on, form a subsystem.
+
+ _Implementation Permissions_
+
+4
+An implementation may impose implementation-defined restrictions on
+compilations that contain multiple compilation_units.
+
+4.a
+ Implementation defined: Any restrictions on compilations that
+ contain multiple compilation_units.
+
+4.b
+ Discussion: For example, an implementation might disallow a
+ compilation that contains two versions of the same compilation
+ unit, or that contains the declarations for library packages
+ P1 and P2, where P1 precedes P2 in the compilation but P1 has
+ a with_clause that mentions P2.
+
+ _Wording Changes from Ada 83_
+
+4.c
+ The interactions between language issues and environmental
+ issues are left open in Ada 95. The environment concept is
+ new. In Ada 83, the concept of the program library, for
+ example, appeared to be quite concrete, although the rules had
+ no force, since implementations could get around them simply
+ by defining various mappings from the concept of an Ada
+ program library to whatever data structures were actually
+ stored in support of separate compilation. Indeed,
+ implementations were encouraged to do so.
+
+4.d
+ In RM83, it was unclear which was the official definition of
+ "program unit." Definitions appeared in RM83-5, 6, 7, and 9,
+ but not 12. Placing it here seems logical, since a program
+ unit is sort of a potential compilation unit.
+
+* Menu:
+
+* 10.1.1 :: Compilation Units - Library Units
+* 10.1.2 :: Context Clauses - With Clauses
+* 10.1.3 :: Subunits of Compilation Units
+* 10.1.4 :: The Compilation Process
+* 10.1.5 :: Pragmas and Program Units
+* 10.1.6 :: Environment-Level Visibility Rules
+
+\1f
+File: aarm2012.info, Node: 10.1.1, Next: 10.1.2, Up: 10.1
+
+10.1.1 Compilation Units - Library Units
+----------------------------------------
+
+1
+[A library_item is a compilation unit that is the declaration, body, or
+renaming of a library unit. Each library unit (except Standard) has a
+parent unit, which is a library package or generic library package.] A
+library unit is a child of its parent unit. The root library units are
+the children of the predefined library package Standard.
+
+1.a
+ Ramification: Standard is a library unit.
+
+ _Syntax_
+
+2
+ compilation ::= {compilation_unit}
+
+3
+ compilation_unit ::=
+ context_clause library_item
+ | context_clause subunit
+
+4
+ library_item ::= [private] library_unit_declaration
+ | library_unit_body
+ | [private] library_unit_renaming_declaration
+
+5
+ library_unit_declaration ::=
+ subprogram_declaration | package_declaration
+ | generic_declaration | generic_instantiation
+
+6
+ library_unit_renaming_declaration ::=
+ package_renaming_declaration
+ | generic_renaming_declaration
+ | subprogram_renaming_declaration
+
+7
+ library_unit_body ::= subprogram_body | package_body
+
+8
+ parent_unit_name ::= name
+
+8.1/2
+ {AI95-00397-01AI95-00397-01} An overriding_indicator is not allowed
+ in a subprogram_declaration, generic_instantiation, or
+ subprogram_renaming_declaration that declares a library unit.
+
+8.a.1/2
+ Reason: All of the listed items syntactically include
+ overriding_indicator, but a library unit can never override
+ anything. A majority of the ARG thought that allowing not
+ overriding in that case would be confusing instead of helpful.
+
+9
+A library unit is a program unit that is declared by a library_item.
+When a program unit is a library unit, the prefix "library" is used to
+refer to it (or "generic library" if generic), as well as to its
+declaration and body, as in "library procedure", "library package_body",
+or "generic library package". The term compilation unit is used to
+refer to a compilation_unit. When the meaning is clear from context,
+the term is also used to refer to the library_item of a compilation_unit
+or to the proper_body of a subunit [(that is, the compilation_unit
+without the context_clause and the separate (parent_unit_name))].
+
+9.a
+ Discussion: In this example:
+
+9.b
+ with Ada.Text_IO;
+ package P is
+ ...
+ end P;
+
+9.c
+ the term "compilation unit" can refer to this text: "with
+ Ada.Text_IO; package P is ... end P;" or to this text:
+ "package P is ... end P;". We use this shorthand because it
+ corresponds to common usage.
+
+9.d
+ We like to use the word "unit" for declaration-plus-body
+ things, and "item" for declaration or body separately (as in
+ declarative_item). The terms "compilation_unit," "compilation
+ unit," and "subunit" are exceptions to this rule. We
+ considered changing "compilation_unit," "compilation unit" to
+ "compilation_item," "compilation item," respectively, but we
+ decided not to.
+
+10
+The parent declaration of a library_item (and of the library unit) is
+the declaration denoted by the parent_unit_name (*note 10.1.1: S0252.),
+if any, of the defining_program_unit_name (*note 6.1: S0169.) of the
+library_item. If there is no parent_unit_name (*note 10.1.1: S0252.),
+the parent declaration is the declaration of Standard, the library_item
+is a root library_item, and the library unit (renaming) is a root
+library unit (renaming). The declaration and body of Standard itself
+have no parent declaration. The parent unit of a library_item or
+library unit is the library unit declared by its parent declaration.
+
+10.a
+ Discussion: The declaration and body of Standard are presumed
+ to exist from the beginning of time, as it were. There is no
+ way to actually write them, since there is no syntactic way to
+ indicate lack of a parent. An attempt to compile a package
+ Standard would result in Standard.Standard.
+
+10.b
+ Reason: Library units (other than Standard) have "parent
+ declarations" and "parent units". Subunits have "parent
+ bodies". We didn't bother to define the other possibilities:
+ parent body of a library unit, parent declaration of a
+ subunit, parent unit of a subunit. These are not needed, and
+ might get in the way of a correct definition of "child."
+
+11
+[The children of a library unit occur immediately within the declarative
+region of the declaration of the library unit.] The ancestors of a
+library unit are itself, its parent, its parent's parent, and so on.
+[(Standard is an ancestor of every library unit.)] The descendant
+relation is the inverse of the ancestor relation.
+
+11.a
+ Reason: These definitions are worded carefully to avoid
+ defining subunits as children. Only library units can be
+ children.
+
+11.b
+ We use the unadorned term "ancestors" here to concisely define
+ both "ancestor unit" and "ancestor declaration."
+
+12
+A library_unit_declaration or a library_unit_renaming_declaration (*note
+10.1.1: S0250.) is private if the declaration is immediately preceded by
+the reserved word private; it is otherwise public. A library unit is
+private or public according to its declaration. The public descendants
+of a library unit are the library unit itself, and the public
+descendants of its public children. Its other descendants are private
+descendants.
+
+12.a
+ Discussion: The first concept defined here is that a
+ library_item is either public or private (not in relation to
+ anything else -- it's just a property of the library unit).
+ The second concept is that a library_item is a public
+ descendant or private descendant of a given ancestor. A given
+ library_item can be a public descendant of one of its
+ ancestors, but a private descendant of some other ancestor.
+
+12.b
+ A subprogram declared by a subprogram_body (as opposed to a
+ subprogram_declaration) is always public, since the syntax
+ rules disallow the reserved word private on a body.
+
+12.c
+ Note that a private library unit is a public descendant of
+ itself, but a private descendant of its parent. This is
+ because it is visible outside itself -- its privateness means
+ that it is not visible outside its parent.
+
+12.d
+ Private children of Standard are legal, and follow the normal
+ rules. It is intended that implementations might have some
+ method for taking an existing environment, and treating it as
+ a package to be "imported" into another environment, treating
+ children of Standard in the imported environment as children
+ of the imported package.
+
+12.e
+ Ramification: Suppose we have a public library unit A, a
+ private library unit A.B, and a public library unit A.B.C.
+ A.B.C is a public descendant of itself and of A.B, but a
+ private descendant of A; since A.B is private to A, we don't
+ allow A.B.C to escape outside A either. This is similar to
+ the situation that would occur with physical nesting, like
+ this:
+
+12.f
+ package A is
+ private
+ package B is
+ package C is
+ end C;
+ private
+ end B;
+ end A;
+
+12.g
+ Here, A.B.C is visible outside itself and outside A.B, but not
+ outside A. (Note that this example is intended to illustrate
+ the visibility of program units from the outside; the
+ visibility within child units is not quite identical to that
+ of physically nested units, since child units are nested after
+ their parent's declaration.)
+
+12.1/2
+{AI95-00217-06AI95-00217-06} For each library package_declaration in the
+environment, there is an implicit declaration of a limited view of that
+library package. The limited view of a package contains:
+
+12.2/3
+ * {AI95-00217-06AI95-00217-06} {AI05-0129-1AI05-0129-1}
+ {AI05-0262-1AI05-0262-1} For each package_declaration occurring
+ immediately within the visible part, a declaration of the limited
+ view of that package, with the same defining_program_unit_name.
+
+12.3/3
+ * {AI95-00217-06AI95-00217-06} {AI95-00326-01AI95-00326-01}
+ {AI05-0108-1AI05-0108-1} {AI05-0129-1AI05-0129-1}
+ {AI05-0262-1AI05-0262-1} For each type_declaration occurring
+ immediately within the visible part that is not an
+ incomplete_type_declaration, an incomplete view of the type with no
+ discriminant_part; if the type_declaration is tagged, then the view
+ is a tagged incomplete view.
+
+12.g.1/3
+ Reason: {AI05-0108-1AI05-0108-1} The incomplete view of a type
+ does not have a discriminant_part even if the type_declaration
+ does have one. This is necessary because semantic analysis
+ (and the associated dependence on with_clauses) would be
+ necessary to determine the types of the discriminants.
+
+12.g.2/3
+ {AI05-0129-1AI05-0129-1} No incomplete views of incomplete
+ types are included in the limited view. The rules of *note
+ 3.10.1:: ensure that the completion of any visible incomplete
+ type is declared in the same visible part, so such an
+ incomplete view would simply be redundant.
+
+12.g.3/2
+ Discussion: {AI95-00217-06AI95-00217-06} The implementation
+ model of a limited view is that it can be determined solely
+ from the syntax of the source of the unit, without any
+ semantic analysis. That allows it to be created without the
+ semantic dependences of a full unit, which is necessary for it
+ to break mutual dependences of units.
+
+12.g.4/2
+ Ramification: The limited view does not include package
+ instances and their contents. Semantic analysis of a unit
+ (and dependence on its with_clauses) would be needed to
+ determine the contents of an instance.
+
+12.4/2
+The limited view of a library package_declaration is private if that
+library package_declaration is immediately preceded by the reserved word
+private.
+
+12.5/2
+[There is no syntax for declaring limited views of packages, because
+they are always implicit.] The implicit declaration of a limited view
+of a library package [is not the declaration of a library unit (the
+library package_declaration is); nonetheless, it] is a library_item.
+The implicit declaration of the limited view of a library package forms
+an (implicit) compilation unit whose context_clause is empty.
+
+12.6/2
+A library package_declaration is the completion of the declaration of
+its limited view.
+
+12.h/2
+ To be honest: This is notwithstanding the rule in *note
+ 3.11.1:: that says that implicit declarations don't have
+ completions.
+
+12.i/2
+ Reason: This rule explains where to find the completions of
+ the incomplete views defined by the limited view.
+
+ _Legality Rules_
+
+13
+The parent unit of a library_item shall be a [library] package or
+generic [library] package.
+
+14
+If a defining_program_unit_name of a given declaration or body has a
+parent_unit_name, then the given declaration or body shall be a
+library_item. The body of a program unit shall be a library_item if and
+only if the declaration of the program unit is a library_item. In a
+library_unit_renaming_declaration (*note 10.1.1: S0250.), the [(old)]
+name shall denote a library_item.
+
+14.a
+ Discussion: We could have allowed nested program units to be
+ children of other program units; their semantics would make
+ sense. We disallow them to keep things simpler and because
+ they wouldn't be particularly useful.
+
+15/2
+{AI95-00217-06AI95-00217-06} A parent_unit_name [(which can be used
+within a defining_program_unit_name of a library_item and in the
+separate clause of a subunit)], and each of its prefixes, shall not
+denote a renaming_declaration. [On the other hand, a name that denotes
+a library_unit_renaming_declaration (*note 10.1.1: S0250.) is allowed in
+a nonlimited_with_clause and other places where the name of a library
+unit is allowed.]
+
+16
+If a library package is an instance of a generic package, then every
+child of the library package shall either be itself an instance or be a
+renaming of a library unit.
+
+16.a
+ Discussion: A child of an instance of a given generic unit
+ will often be an instance of a (generic) child of the given
+ generic unit. This is not required, however.
+
+16.b
+ Reason: Instances are forbidden from having noninstance
+ children for two reasons:
+
+16.c
+ 1. We want all source code that can depend on
+ information from the private part of a library unit to be
+ inside the "subsystem" rooted at the library unit. If an
+ instance of a generic unit were allowed to have a
+ noninstance as a child, the source code of that child
+ might depend on information from the private part of the
+ generic unit, even though it is outside the subsystem
+ rooted at the generic unit.
+
+16.d
+ 2. Disallowing noninstance children simplifies the
+ description of the semantics of children of generic
+ packages.
+
+17/3
+{AI05-0004-1AI05-0004-1} A child of a generic library package shall
+either be itself a generic unit or be a renaming of some other child of
+the same generic unit.
+
+18
+A child of a parent generic package shall be instantiated or renamed
+only within the declarative region of the parent generic.
+
+19/2
+{AI95-00331-01AI95-00331-01} For each child C of some parent generic
+package P, there is a corresponding declaration C nested immediately
+within each instance of P. For the purposes of this rule, if a child C
+itself has a child D, each corresponding declaration for C has a
+corresponding child D. [The corresponding declaration for a child within
+an instance is visible only within the scope of a with_clause that
+mentions the (original) child generic unit.]
+
+19.a
+ Implementation Note: Within the child, like anything nested in
+ a generic unit, one can make up-level references to the
+ current instance of its parent, and thereby gain access to the
+ formal parameters of the parent, to the types declared in the
+ parent, etc. This "nesting" model applies even within the
+ generic_formal_part of the child, as it does for a generic
+ child of a nongeneric unit.
+
+19.b
+ Ramification: Suppose P is a generic library package, and P.C
+ is a generic child of P. P.C can be instantiated inside the
+ declarative region of P. Outside P, P.C can be mentioned only
+ in a with_clause. Conceptually, an instance I of P is a
+ package that has a nested generic unit called I.C. Mentioning
+ P.C in a with_clause allows I.C to be instantiated. I need
+ not be a library unit, and the instantiation of I.C need not
+ be a library unit. If I is a library unit, and an instance of
+ I.C is a child of I, then this instance has to be called
+ something other than C.
+
+20
+A library subprogram shall not override a primitive subprogram.
+
+20.a
+ Reason: This prevents certain obscure anomalies. For example,
+ if a library subprogram were to override a subprogram declared
+ in its parent package, then in a compilation unit that depends
+ indirectly on the library subprogram, the library subprogram
+ could hide the overridden operation from all visibility, but
+ the library subprogram itself would not be visible.
+
+20.b
+ Note that even without this rule, such subprograms would be
+ illegal for tagged types, because of the freezing rules.
+
+21
+The defining name of a function that is a compilation unit shall not be
+an operator_symbol.
+
+21.a
+ Reason: Since overloading is not permitted among compilation
+ units, it seems unlikely that it would be useful to define one
+ as an operator. Note that a subunit could be renamed within
+ its parent to be an operator.
+
+ _Static Semantics_
+
+22
+A subprogram_renaming_declaration that is a
+library_unit_renaming_declaration (*note 10.1.1: S0250.) is a
+renaming-as-declaration, not a renaming-as-body.
+
+23
+[There are two kinds of dependences among compilation units:]
+
+24
+ * [The semantic dependences (see below) are the ones needed to check
+ the compile-time rules across compilation unit boundaries; a
+ compilation unit depends semantically on the other compilation
+ units needed to determine its legality. The visibility rules are
+ based on the semantic dependences.
+
+25
+ * The elaboration dependences (see *note 10.2::) determine the order
+ of elaboration of library_items.]
+
+25.a
+ Discussion: Don't confuse these kinds of dependences with the
+ run-time dependences among tasks and masters defined in *note
+ 9.3::, "*note 9.3:: Task Dependence - Termination of Tasks".
+
+26/2
+{AI95-00217-06AI95-00217-06} A library_item depends semantically upon
+its parent declaration. A subunit depends semantically upon its parent
+body. A library_unit_body depends semantically upon the corresponding
+library_unit_declaration, if any. The declaration of the limited view
+of a library package depends semantically upon the declaration of the
+limited view of its parent. The declaration of a library package
+depends semantically upon the declaration of its limited view. A
+compilation unit depends semantically upon each library_item mentioned
+in a with_clause of the compilation unit. In addition, if a given
+compilation unit contains an attribute_reference of a type defined in
+another compilation unit, then the given compilation unit depends
+semantically upon the other compilation unit. The semantic dependence
+relationship is transitive.
+
+26.a
+ Discussion: The "if any" in the third sentence is necessary
+ because library subprograms are not required to have a
+ subprogram_declaration.
+
+26.b
+ To be honest: If a given compilation unit contains a
+ choice_parameter_specification, then the given compilation
+ unit depends semantically upon the declaration of
+ Ada.Exceptions.
+
+26.c
+ If a given compilation unit contains a pragma with an argument
+ of a type defined in another compilation unit, then the given
+ compilation unit depends semantically upon the other
+ compilation unit.
+
+26.d
+ Discussion: For example, a compilation unit containing
+ X'Address depends semantically upon the declaration of package
+ System.
+
+26.e
+ For the Address attribute, this fixes a hole in Ada 83. Note
+ that in almost all cases, the dependence will need to exist
+ due to with_clauses, even without this rule. Hence, the rule
+ has very little effect on programmers.
+
+26.f
+ Note that the semantic dependence does not have the same
+ effect as a with_clause; in order to denote a declaration in
+ one of those packages, a with_clause will generally be needed.
+
+26.g
+ Note that no special rule is needed for an
+ attribute_definition_clause, since an expression after use
+ will require semantic dependence upon the compilation unit
+ containing the type_declaration of interest.
+
+26.h/2
+ {AI95-00217-06AI95-00217-06} Unlike a full view of a package,
+ a limited view does not depend semantically on units mentioned
+ in with_clauses of the compilation_unit that defines the
+ package. Formally, this is achieved by saying that the
+ limited view has an empty context_clause. This is necessary
+ so that they can be useful for their intended purpose:
+ allowing mutual dependences between packages. The lack of
+ semantic dependence limits the contents of a limited view to
+ the items that can be determined solely from the syntax of the
+ source of the package, without any semantic analysis. That
+ allows it to be created without the semantic dependences of a
+ full package.
+
+ _Dynamic Semantics_
+
+26.1/2
+{AI95-00217-06AI95-00217-06} The elaboration of the declaration of the
+limited view of a package has no effect.
+
+ NOTES
+
+27
+ 1 A simple program may consist of a single compilation unit. A
+ compilation need not have any compilation units; for example, its
+ text can consist of pragmas.
+
+27.a
+ Ramification: Such pragmas cannot have any arguments that are
+ names, by a previous rule of this subclause. A compilation
+ can even be entirely empty, which is probably not useful.
+
+27.b
+ Some interesting properties of the three kinds of dependence:
+ The elaboration dependences also include the semantic
+ dependences, except that subunits are taken together with
+ their parents. The semantic dependences partly determine the
+ order in which the compilation units appear in the environment
+ at compile time. At run time, the order is partly determined
+ by the elaboration dependences.
+
+27.c
+ The model whereby a child is inside its parent's declarative
+ region, after the parent's declaration, as explained in *note
+ 8.1::, has the following ramifications:
+
+27.d
+ * The restrictions on "early" use of a private type
+ (RM83-7.4.1(4)) or a deferred constant (RM83-7.4.3(2)) do
+ not apply to uses in child units, because they follow the
+ full declaration.
+
+27.e
+ * A library subprogram is never primitive, even if its
+ profile includes a type declared immediately within the
+ parent's package_specification, because the child is not
+ declared immediately within the same
+ package_specification as the type (so it doesn't declare
+ a new primitive subprogram), and because the child is
+ forbidden from overriding an old primitive subprogram.
+ It is immediately within the same declarative region, but
+ not the same package_specification. Thus, for a tagged
+ type, it is not possible to call a child subprogram in a
+ dispatching manner. (This is also forbidden by the
+ freezing rules.) Similarly, it is not possible for the
+ user to declare primitive subprograms of the types
+ declared in the declaration of Standard, such as Integer
+ (even if the rules were changed to allow a library unit
+ whose name is an operator symbol).
+
+27.f
+ * When the parent unit is "used" the simple names of the
+ with'd child units are directly visible (see *note 8.4::,
+ "*note 8.4:: Use Clauses").
+
+27.g
+ * When a parent body with's its own child, the defining
+ name of the child is directly visible, and the parent
+ body is not allowed to include a declaration of a
+ homograph of the child unit immediately within the
+ declarative_part of the body (RM83-8.3(17)).
+
+27.h
+ Note that "declaration of a library unit" is different from
+ "library_unit_declaration" -- the former includes
+ subprogram_body. Also, we sometimes really mean "declaration
+ of a view of a library unit", which includes
+ library_unit_renaming_declaration (*note 10.1.1: S0250.)s.
+
+27.i
+ The visibility rules generally imply that the renamed view of
+ a library_unit_renaming_declaration (*note 10.1.1: S0250.) has
+ to be mentioned in a with_clause (*note 10.1.2: S0255.) of the
+ library_unit_renaming_declaration (*note 10.1.1: S0250.).
+
+27.j
+ To be honest: The real rule is that the renamed library unit
+ has to be visible in the library_unit_renaming_declaration
+ (*note 10.1.1: S0250.).
+
+27.k
+ Reason: In most cases, "has to be visible" means there has to
+ be a with_clause. However, it is possible in obscure cases to
+ avoid the need for a with_clause; in particular, a compilation
+ unit such as "package P.Q renames P;" is legal with no
+ with_clauses (though not particularly interesting). ASCII is
+ physically nested in Standard, and so is not a library unit,
+ and cannot be renamed as a library unit.
+
+28
+ 2 The designator of a library function cannot be an
+ operator_symbol, but a nonlibrary renaming_declaration is allowed
+ to rename a library function as an operator. Within a partition,
+ two library subprograms are required to have distinct names and
+ hence cannot overload each other. However, renaming_declarations
+ are allowed to define overloaded names for such subprograms, and a
+ locally declared subprogram is allowed to overload a library
+ subprogram. The expanded name Standard.L can be used to denote a
+ root library unit L (unless the declaration of Standard is hidden)
+ since root library unit declarations occur immediately within the
+ declarative region of package Standard.
+
+ _Examples_
+
+29
+Examples of library units:
+
+30
+ package Rational_Numbers.IO is -- public child of Rational_Numbers, see *note 7.1::
+ procedure Put(R : in Rational);
+ procedure Get(R : out Rational);
+ end Rational_Numbers.IO;
+
+31
+ private procedure Rational_Numbers.Reduce(R : in out Rational);
+ -- private child of Rational_Numbers
+
+32
+ with Rational_Numbers.Reduce; -- refer to a private child
+ package body Rational_Numbers is
+ ...
+ end Rational_Numbers;
+
+33
+ with Rational_Numbers.IO; use Rational_Numbers;
+ with Ada.Text_io; -- see *note A.10::
+ procedure Main is -- a root library procedure
+ R : Rational;
+ begin
+ R := 5/3; -- construct a rational number, see *note 7.1::
+ Ada.Text_IO.Put("The answer is: ");
+ IO.Put(R);
+ Ada.Text_IO.New_Line;
+ end Main;
+
+34
+ with Rational_Numbers.IO;
+ package Rational_IO renames Rational_Numbers.IO;
+ -- a library unit renaming declaration
+
+35
+Each of the above library_items can be submitted to the compiler
+separately.
+
+35.a
+ Discussion: Example of a generic package with children:
+
+35.b
+ generic
+ type Element is private;
+ with function Image(E : Element) return String;
+ package Generic_Bags is
+ type Bag is limited private; -- A bag of Elements.
+ procedure Add(B : in out Bag; E : Element);
+ function Bag_Image(B : Bag) return String;
+ private
+ type Bag is ...;
+ end Generic_Bags;
+
+35.c
+ generic
+ package Generic_Bags.Generic_Iterators is
+ ... -- various additional operations on Bags.
+
+35.d
+ generic
+ with procedure Use_Element(E : in Element);
+ -- Called once per bag element.
+ procedure Iterate(B : in Bag);
+ end Generic_Bags.Generic_Iterators;
+
+35.e
+ A package that instantiates the above generic units:
+
+35.f
+ with Generic_Bags;
+ with Generic_Bags.Generic_Iterators;
+ package My_Abstraction is
+ type My_Type is ...;
+ function Image(X : My_Type) return String;
+ package Bags_Of_My_Type is new Generic_Bags(My_Type, Image);
+ package Iterators_Of_Bags_Of_My_Type is new Bags_Of_My_Type.Generic_Iterators;
+ end My_Abstraction;
+
+35.g
+ In the above example, Bags_Of_My_Type has a nested generic
+ unit called Generic_Iterators. The second with_clause makes
+ that nested unit visible.
+
+35.h
+ Here we show how the generic body could depend on one of its
+ own children:
+
+35.i
+ with Generic_Bags.Generic_Iterators;
+ package body Generic_Bags is
+ procedure Add(B : in out Bag; E : Element) is ... end Add;
+
+35.j
+ package Iters is new Generic_Iterators;
+
+35.k
+ function Bag_Image(B : Bag) return String is
+ Buffer : String(1..10_000);
+ Last : Integer := 0;
+
+35.l
+ procedure Append_Image(E : in Element) is
+ Im : constant String := Image(E);
+ begin
+ if Last /= 0 then -- Insert a comma.
+ Last := Last + 1;
+ Buffer(Last) := ',';
+ end if;
+ Buffer(Last+1 .. Last+Im'Length) := Im;
+ Last := Last + Im'Length;
+ end Append_Image;
+
+35.m
+ procedure Append_All is new Iters.Iterate(Append_Image);
+ begin
+ Append_All(B);
+ return Buffer(1..Last);
+ end Bag_Image;
+ end Generic_Bags;
+
+ _Extensions to Ada 83_
+
+35.n
+ The syntax rule for library_item is modified to allow the
+ reserved word private before a library_unit_declaration.
+
+35.o
+ Children (other than children of Standard) are new in Ada 95.
+
+35.p
+ Library unit renaming is new in Ada 95.
+
+ _Wording Changes from Ada 83_
+
+35.q
+ Standard is considered a library unit in Ada 95. This
+ simplifies the descriptions, since it implies that the parent
+ of each library unit is a library unit. (Standard itself has
+ no parent, of course.) As in Ada 83, the language does not
+ define any way to recompile Standard, since the name given in
+ the declaration of a library unit is always interpreted in
+ relation to Standard. That is, an attempt to compile a
+ package Standard would result in Standard.Standard.
+
+ _Extensions to Ada 95_
+
+35.r/2
+ {AI95-00217-06AI95-00217-06} The concept of a limited view is
+ new. Combined with limited_with_clauses (see *note 10.1.2::),
+ they facilitate construction of mutually recursive types in
+ multiple packages.
+
+ _Wording Changes from Ada 95_
+
+35.s/2
+ {AI95-00331-01AI95-00331-01} Clarified the wording so that a
+ grandchild generic unit will work as expected.
+
+ _Wording Changes from Ada 2005_
+
+35.t/3
+ {AI05-0108-1AI05-0108-1} {AI05-0129-1AI05-0129-1} Correction:
+ Clarified the wording so that it is clear that limited views
+ of types never have discriminants and never are of incomplete
+ types.
+
+\1f
+File: aarm2012.info, Node: 10.1.2, Next: 10.1.3, Prev: 10.1.1, Up: 10.1
+
+10.1.2 Context Clauses - With Clauses
+-------------------------------------
+
+1
+[A context_clause is used to specify the library_items whose names are
+needed within a compilation unit.]
+
+ _Language Design Principles_
+
+1.a
+ The reader should be able to understand a context_clause
+ without looking ahead. Similarly, when compiling a
+ context_clause, the compiler should not have to look ahead at
+ subsequent context_items, nor at the compilation unit to which
+ the context_clause is attached. (We have not completely
+ achieved this.)
+
+1.b/2
+ {AI95-00217-06AI95-00217-06} A ripple effect occurs when the
+ legality of a compilation unit could be affected by adding or
+ removing an otherwise unneeded with_clause on some compilation
+ unit on which the unit depends, directly or indirectly. We
+ try to avoid ripple effects because they make understanding
+ and maintenance more difficult. However, ripple effects can
+ occur because of direct visibility (as in child units); this
+ seems impossible to eliminate. The ripple effect for
+ with_clauses is somewhat similar to the Beaujolais effect (see
+ *note 8.4::) for use_clauses, which we also try to avoid.
+
+ _Syntax_
+
+2
+ context_clause ::= {context_item}
+
+3
+ context_item ::= with_clause | use_clause
+
+4/2
+ {AI95-00217-06AI95-00217-06} {AI95-00262-01AI95-00262-01}
+ with_clause ::= limited_with_clause | nonlimited_with_clause
+
+4.1/2
+ limited_with_clause ::= limited [private] with library_unit_
+ name {, library_unit_name};
+
+4.2/2
+ nonlimited_with_clause ::= [private] with library_unit_
+ name {, library_unit_name};
+
+4.a/2
+ Discussion: {AI95-00217-06AI95-00217-06} A limited_with_clause
+ makes a limited view of a unit visible.
+
+4.b/2
+ {AI95-00262-01AI95-00262-01} A with_clause containing the
+ reserved word private is called a private with_clause. It can
+ be thought of as making items visible only in the private
+ part, although it really makes items visible everywhere except
+ the visible part. It can be used both for documentation
+ purposes (to say that a unit is not used in the visible part),
+ and to allow access to private units that otherwise would be
+ prohibited.
+
+ _Name Resolution Rules_
+
+5
+The scope of a with_clause that appears on a library_unit_declaration
+(*note 10.1.1: S0249.) or library_unit_renaming_declaration (*note
+10.1.1: S0250.) consists of the entire declarative region of the
+declaration[, which includes all children and subunits]. The scope of a
+with_clause that appears on a body consists of the body[, which includes
+all subunits].
+
+5.a/2
+ Discussion: {AI95-00262-01AI95-00262-01} Suppose a nonprivate
+ with_clause of a public library unit mentions one of its
+ private siblings. (This is only allowed on the body of the
+ public library unit.) We considered making the scope of that
+ with_clause not include the visible part of the public library
+ unit. (This would only matter for a subprogram_body, since
+ those are the only kinds of body that have a visible part, and
+ only if the subprogram_body completes a
+ subprogram_declaration, since otherwise the with_clause would
+ be illegal.) We did not put in such a rule for two reasons:
+ (1) It would complicate the wording of the rules, because we
+ would have to split each with_clause into pieces, in order to
+ correctly handle "with P, Q;" where P is public and Q is
+ private. (2) The conformance rules prevent any problems. It
+ doesn't matter if a type name in the spec of the body denotes
+ the completion of a private_type_declaration.
+
+5.b
+ A with_clause also affects visibility within subsequent
+ use_clauses and pragmas of the same context_clause, even
+ though those are not in the scope of the with_clause.
+
+6/2
+{AI95-00217-06AI95-00217-06} A library_item (and the corresponding
+library unit) is named in a with_clause if it is denoted by a
+library_unit_name in the with_clause. A library_item (and the
+corresponding library unit) is mentioned in a with_clause if it is named
+in the with_clause or if it is denoted by a prefix in the with_clause.
+
+6.a/3
+ Discussion: {AI05-0299-1AI05-0299-1} With_clauses control the
+ visibility of declarations or renamings of library units.
+ Mentioning a root library unit in a with_clause makes its
+ declaration directly visible. Mentioning a nonroot library
+ unit makes its declaration visible. See Clause *note 8:: for
+ details.
+
+6.b/2
+ {AI95-00114-01AI95-00114-01} Note that this rule implies that
+ "with A.B.C;" is almost equivalent to "with A, A.B, A.B.C;".
+ The reason for making a with_clause apply to all the ancestor
+ units is to avoid "visibility holes" -- situations in which an
+ inner program unit is visible while an outer one is not.
+ Visibility holes would cause semantic complexity and
+ implementation difficulty. (This is not exactly equivalent
+ because the latter with_clause names A and A.B, while the
+ previous one does not. Whether a unit is "named" does not
+ have any effect on visibility, however, so it is equivalent
+ for visibility purposes.)
+
+7
+[Outside its own declarative region, the declaration or renaming of a
+library unit can be visible only within the scope of a with_clause that
+mentions it. The visibility of the declaration or renaming of a library
+unit otherwise follows from its placement in the environment.]
+
+ _Legality Rules_
+
+8/2
+{AI95-00262-01AI95-00262-01} If a with_clause of a given
+compilation_unit mentions a private child of some library unit, then the
+given compilation_unit shall be one of:
+
+9/2
+ * {AI95-00262-01AI95-00262-01} the declaration, body, or subunit of a
+ private descendant of that library unit;
+
+10/2
+ * {AI95-00220-01AI95-00220-01} {AI95-00262-01AI95-00262-01} the body
+ or subunit of a public descendant of that library unit, but not a
+ subprogram body acting as a subprogram declaration (see *note
+ 10.1.4::); or
+
+11/2
+ * {AI95-00262-01AI95-00262-01} the declaration of a public descendant
+ of that library unit, in which case the with_clause shall include
+ the reserved word private.
+
+11.a/2
+ Reason: {AI95-00262-01AI95-00262-01} The purpose of this rule
+ is to prevent a private child from being visible from outside
+ the subsystem rooted at its parent. A private child can be
+ semantically depended-on without violating this principle if
+ it is used in a private with_clause.
+
+11.b
+ Discussion: This rule violates the one-pass context_clauses
+ Language Design Principle. We rationalize this by saying that
+ at least that Language Design Principle works for legal
+ compilation units.
+
+11.c
+ Example:
+
+11.d
+ package A is
+ end A;
+
+11.e
+ package A.B is
+ end A.B;
+
+11.f
+ private package A.B.C is
+ end A.B.C;
+
+11.g
+ package A.B.C.D is
+ end A.B.C.D;
+
+11.h
+ with A.B.C; -- (1)
+ private package A.B.X is
+ end A.B.X;
+
+11.i
+ package A.B.Y is
+ end A.B.Y;
+
+11.j
+ with A.B.C; -- (2)
+ package body A.B.Y is
+ end A.B.Y;
+
+11.j.1/2
+ private with A.B.C; -- (3)
+ package A.B.Z is
+ end A.B.Z;
+
+11.k/2
+ {AI95-00262-01AI95-00262-01} (1) is OK because it's a private
+ child of A.B -- it would be illegal if we made A.B.X a public
+ child of A.B. (2) is OK because it's the body of a child of
+ A.B. (3) is OK because it's a child of A.B, and it is a
+ private with_clause. It would be illegal to say "with A.B.C;"
+ on any library_item whose name does not start with "A.B". Note
+ that mentioning A.B.C.D in a with_clause automatically
+ mentions A.B.C as well, so "with A.B.C.D;" is illegal in the
+ same places as "with A.B.C;".
+
+12/3
+{AI05-0005-1AI05-0005-1} {AI95-00262-01AI95-00262-01}
+{AI95-00262-01AI95-00262-01} {AI05-0077-1AI05-0077-1}
+{AI05-0122-1AI05-0122-1} A name denoting a library_item (or the
+corresponding declaration for a child of a generic within an instance --
+see *note 10.1.1::), if it is visible only due to being mentioned in one
+or more with_clauses that include the reserved word private, shall
+appear only within:
+
+13/2
+ * a private part;
+
+14/2
+ * a body, but not within the subprogram_specification of a library
+ subprogram body;
+
+15/2
+ * a private descendant of the unit on which one of these with_clauses
+ appear; or
+
+16/2
+ * a pragma within a context clause.
+
+16.a/2
+ Ramification: These rules apply only if all of the
+ with_clauses that mention the name include the reserved word
+ private. They do not apply if the name is mentioned in any
+ with_clause that does not include private.
+
+16.b/3
+ Reason: {AI05-0077-1AI05-0077-1} These rules make the
+ library_item visible anywhere that is not visible outside the
+ subsystem rooted at the compilation_unit having the private
+ with_clause, including private parts of packages nested in the
+ visible part, private parts of child packages, the visible
+ part of private children, and context clause pragmas like
+ Elaborate_All.
+
+16.c/2
+ We considered having the scope of a private with_clause not
+ include the visible part. However, that rule would mean that
+ moving a declaration between the visible part and the private
+ part could change its meaning from one legal interpretation to
+ a different legal interpretation. For example:
+
+16.d/2
+ package A is
+ function B return Integer;
+ end A;
+
+16.e/2
+ function B return Integer;
+
+16.f/2
+ with A;
+ private with B;
+ package C is
+ use A;
+ V1 : Integer := B; -- (1)
+ private
+ V2 : Integer := B; -- (2)
+ end C;
+
+16.g/2
+ If we say that library subprogram B is not in scope in the
+ visible part of C, then the B at (1) resolves to A.B, while
+ (2) resolves to library unit B. Simply moving a declaration
+ could silently change its meaning. With the legality rule
+ defined above, the B at (1) is illegal. If the user really
+ meant A.B, they still can say that.
+
+17/2
+{AI95-00217-06AI95-00217-06} [A library_item mentioned in a
+limited_with_clause shall be the implicit declaration of the limited
+view of a library package, not the declaration of a subprogram, generic
+unit, generic instance, or a renaming.]
+
+17.a/2
+ Proof: This is redundant because only such implicit
+ declarations are visible in a limited_with_clause. See *note
+ 10.1.6::.
+
+18/2
+{AI95-00217-06AI95-00217-06} {AI95-00412-01AI95-00412-01} A
+limited_with_clause shall not appear on a library_unit_body, subunit, or
+library_unit_renaming_declaration (*note 10.1.1: S0250.).
+
+18.a/2
+ Reason: {AI95-00412-01AI95-00412-01} We don't allow a
+ limited_with_clause on a library_unit_renaming_declaration
+ (*note 10.1.1: S0250.) because it would be useless and
+ therefore probably is a mistake. A renaming cannot appear in
+ a limited_with_clause (by the rule prior to this one), and a
+ renaming of a limited view cannot appear in a
+ nonlimited_with_clause (because the name would not be within
+ the scope of a with_clause denoting the package, see *note
+ 8.5.3::). Nor could it be the parent of another unit. That
+ doesn't leave anywhere that the name of such a renaming could
+ appear, so we simply make writing it illegal.
+
+19/2
+{AI95-00217-06AI95-00217-06} A limited_with_clause that names a library
+package shall not appear:
+
+20/3
+ * {AI95-00217-06AI95-00217-06} {AI05-0040-1AI05-0040-1} in the
+ context_clause for the explicit declaration of the named library
+ package or any of its descendants;
+
+20.a/2
+ Reason: We have to explicitly disallow
+
+20.b/2
+ limited with P;
+ package P is ...
+
+20.c/2
+ as we can't depend on the semantic dependence rules to do it
+ for us as with regular withs. This says "named" and not
+ "mentioned" in order that
+
+20.d/2
+ limited private with P.Child;
+ package P is ...
+
+20.e/2
+ can be used to allow a mutual dependence between the private
+ part of P and the private child P.Child, which occurs in
+ interfacing and other problems. Since the child always
+ semantically depends on the parent, this is the only way such
+ a dependence can be broken.
+
+20.f/3
+ {AI05-0040-1AI05-0040-1} The part about descendants catches
+ examples like
+
+20.g/3
+ limited with P;
+ package P.Child is ...
+
+21/3
+ * {AI95-00217-06AI95-00217-06} {AI05-0077-1AI05-0077-1}
+ {AI05-0262-1AI05-0262-1} within a context_clause for a library_item
+ that is within the scope of a nonlimited_with_clause that mentions
+ the same library package; or
+
+21.a.1/3
+ Ramification: {AI05-0077-1AI05-0077-1} This applies to
+ nonlimited_with_clauses found in the same context_clause, as
+ well as nonlimited_with_clauses found on parent units.
+
+21.a/3
+ Reason: {AI05-0077-1AI05-0077-1} Such a limited_with_clause
+ could have no effect, and would be confusing. If a
+ nonlimited_with_clause for the same package is inherited from
+ a parent unit or given in the context_clause, the full view is
+ available, which strictly provides more information than the
+ limited view.
+
+22/3
+ * {AI95-00217-06AI95-00217-06} {AI05-0077-1AI05-0077-1}
+ {AI05-0262-1AI05-0262-1} within a context_clause for a library_item
+ that is within the scope of a use_clause that names an entity
+ declared within the declarative region of the library package.
+
+22.a.1/3
+ Ramification: {AI05-0077-1AI05-0077-1} This applies to
+ use_clauses found in the same context_clause, as well as
+ use_clauses found in (or on) parent units.
+
+22.a/2
+ Reason: This prevents visibility issues, where whether an
+ entity is an incomplete or full view depends on how the name
+ of the entity is written. The limited_with_clause cannot be
+ useful, as we must have the full view available in the parent
+ in order for the use_clause to be legal.
+
+ NOTES
+
+23/2
+ 3 {AI95-00217-06AI95-00217-06} A library_item mentioned in a
+ nonlimited_with_clause of a compilation unit is visible within the
+ compilation unit and hence acts just like an ordinary declaration.
+ Thus, within a compilation unit that mentions its declaration, the
+ name of a library package can be given in use_clauses and can be
+ used to form expanded names, a library subprogram can be called,
+ and instances of a generic library unit can be declared. If a
+ child of a parent generic package is mentioned in a
+ nonlimited_with_clause, then the corresponding declaration nested
+ within each visible instance is visible within the compilation
+ unit. Similarly, a library_item mentioned in a limited_with_clause
+ of a compilation unit is visible within the compilation unit and
+ thus can be used to form expanded names.
+
+23.a
+ Ramification: The rules given for with_clauses are such that
+ the same effect is obtained whether the name of a library unit
+ is mentioned once or more than once by the applicable
+ with_clauses, or even within a given with_clause.
+
+23.b
+ If a with_clause mentions a library_unit_renaming_declaration
+ (*note 10.1.1: S0250.), it only "mentions" the prefixes
+ appearing explicitly in the with_clause (and the renamed view
+ itself); the with_clause is not defined to mention the
+ ancestors of the renamed entity. Thus, if X renames Y.Z, then
+ "with X;" does not make the declarations of Y or Z visible.
+ Note that this does not cause the dreaded visibility holes
+ mentioned above.
+
+ _Examples_
+
+24/2
+ {AI95-00433-01AI95-00433-01} package Office is
+ end Office;
+
+25/2
+ {AI95-00433-01AI95-00433-01} with Ada.Strings.Unbounded;
+ package Office.Locations is
+ type Location is new Ada.Strings.Unbounded.Unbounded_String;
+ end Office.Locations;
+
+26/2
+ {AI95-00433-01AI95-00433-01} limited with Office.Departments; -- types are incomplete
+ private with Office.Locations; -- only visible in private part
+ package Office.Employees is
+ type Employee is private;
+
+27/2
+ function Dept_Of(Emp : Employee) return access Departments.Department;
+ procedure Assign_Dept(Emp : in out Employee;
+ Dept : access Departments.Department);
+
+28/2
+ ...
+ private
+ type Employee is
+ record
+ Dept : access Departments.Department;
+ Loc : Locations.Location;
+ ...
+ end record;
+ end Office.Employees;
+
+29/2
+ limited with Office.Employees;
+ package Office.Departments is
+ type Department is private;
+
+30/2
+ function Manager_Of(Dept : Department) return access Employees.Employee;
+ procedure Assign_Manager(Dept : in out Department;
+ Mgr : access Employees.Employee);
+ ...
+ end Office.Departments;
+
+31/2
+{AI95-00433-01AI95-00433-01} The limited_with_clause may be used to
+support mutually dependent abstractions that are split across multiple
+packages. In this case, an employee is assigned to a department, and a
+department has a manager who is an employee. If a with_clause with the
+reserved word private appears on one library unit and mentions a second
+library unit, it provides visibility to the second library unit, but
+restricts that visibility to the private part and body of the first
+unit. The compiler checks that no use is made of the second unit in the
+visible part of the first unit.
+
+ _Extensions to Ada 83_
+
+31.a
+ The syntax rule for with_clause is modified to allow expanded
+ name notation.
+
+31.b
+ A use_clause in a context_clause may be for a package (or
+ type) nested in a library package.
+
+ _Wording Changes from Ada 83_
+
+31.c
+ The syntax rule for context_clause is modified to more closely
+ reflect the semantics. The Ada 83 syntax rule implies that
+ the use_clauses that appear immediately after a particular
+ with_clause are somehow attached to that with_clause, which is
+ not true. The new syntax allows a use_clause to appear first,
+ but that is prevented by a textual rule that already exists in
+ Ada 83.
+
+31.d
+ The concept of "scope of a with_clause" (which is a region of
+ text) replaces RM83's notion of "apply to" (a with_clause
+ applies to a library_item) The visibility rules are interested
+ in a region of text, not in a set of compilation units.
+
+31.e
+ No need to define "apply to" for use_clauses. Their semantics
+ are fully covered by the "scope (of a use_clause)" definition
+ in *note 8.4::.
+
+ _Incompatibilities With Ada 95_
+
+31.f/2
+ {AI95-00220-01AI95-00220-01} Amendment Correction: A
+ subprogram body acting as a declaration cannot with a private
+ child unit. This would allow public export of types declared
+ in private child packages, and thus cannot be allowed. This
+ was allowed by mistake in Ada 95; a subprogram that does this
+ will now be illegal.
+
+ _Extensions to Ada 95_
+
+31.g/2
+ {AI95-00217-06AI95-00217-06} limited_with_clauses are new.
+ They make a limited view of a package visible, where all of
+ the types in the package are incomplete. They facilitate
+ construction of mutually recursive types in multiple packages.
+
+31.h/3
+ {AI95-00262-01AI95-00262-01} {AI05-0077-1AI05-0077-1} The
+ syntax rules for with_clause are modified to allow the
+ reserved word private. Private with_clauses do not allow the
+ use of their library_item in the visible part of their
+ compilation_unit. They also allow using private units in more
+ locations than in Ada 95.
+
+ _Incompatibilities With Ada 2005_
+
+31.i/3
+ {AI05-0040-1AI05-0040-1} Correction: Added missing rule that a
+ limited with clause cannot name an ancestor unit. This is
+ incompatible if an Ada 2005 program does this, but as this is
+ a new Ada 2005 feature and the unintentionally allowed
+ capability is not useful, the incompatibility is very unlikely
+ to occur in practice.
+
+ _Wording Changes from Ada 2005_
+
+31.j/3
+ {AI05-0077-1AI05-0077-1} Correction: Fixed wording so that we
+ are not checking whether something in a context_clause is
+ "within the scope of" something, as context_clauses are never
+ included in anything's scope. The intended meaning is
+ unchanged, however.
+
+31.k/3
+ {AI05-0122-1AI05-0122-1} Correction: Fixed wording so the
+ rules for private with clauses also apply to "sprouted"
+ generic child units.
+
+\1f
+File: aarm2012.info, Node: 10.1.3, Next: 10.1.4, Prev: 10.1.2, Up: 10.1
+
+10.1.3 Subunits of Compilation Units
+------------------------------------
+
+1
+[Subunits are like child units, with these (important) differences:
+subunits support the separate compilation of bodies only (not
+declarations); the parent contains a body_stub to indicate the existence
+and place of each of its subunits; declarations appearing in the
+parent's body can be visible within the subunits.]
+
+ _Syntax_
+
+2
+ body_stub ::= subprogram_body_stub | package_body_stub |
+ task_body_stub | protected_body_stub
+
+3/3
+ {AI95-00218-03AI95-00218-03} {AI05-0267-1AI05-0267-1}
+ subprogram_body_stub ::=
+ [overriding_indicator]
+ subprogram_specification is separate
+ [aspect_specification];
+
+3.a
+ Discussion: Although this syntax allows a parent_unit_name,
+ that is disallowed by *note 10.1.1::, "*note 10.1.1::
+ Compilation Units - Library Units".
+
+4
+ package_body_stub ::=
+ package body defining_identifier is separate
+ [aspect_specification];
+
+5
+ task_body_stub ::=
+ task body defining_identifier is separate
+ [aspect_specification];
+
+6
+ protected_body_stub ::=
+ protected body defining_identifier is separate
+ [aspect_specification];
+
+7
+ subunit ::= separate (parent_unit_name) proper_body
+
+ _Legality Rules_
+
+8/2
+{AI95-00243-01AI95-00243-01} The parent body of a subunit is the body of
+the program unit denoted by its parent_unit_name. The term subunit is
+used to refer to a subunit and also to the proper_body of a subunit.
+The subunits of a program unit include any subunit that names that
+program unit as its parent, as well as any subunit that names such a
+subunit as its parent (recursively).
+
+8.a.1/2
+ Reason: {AI95-00243-01AI95-00243-01} We want any rule that
+ applies to a subunit to apply to a subunit of a subunit as
+ well.
+
+9
+The parent body of a subunit shall be present in the current
+environment, and shall contain a corresponding body_stub with the same
+defining_identifier as the subunit.
+
+9.a
+ Discussion: This can't be a Name Resolution Rule, because a
+ subunit is not a complete context.
+
+10/3
+{AI05-0004-1AI05-0004-1} A package_body_stub shall be the completion of
+a package_declaration (*note 7.1: S0190.) or generic_package_declaration
+(*note 12.1: S0272.); a task_body_stub (*note 10.1.3: S0261.) shall be
+the completion of a task declaration; a protected_body_stub (*note
+10.1.3: S0262.) shall be the completion of a protected declaration.
+
+11
+In contrast, a subprogram_body_stub need not be the completion of a
+previous declaration, [in which case the _stub declares the subprogram].
+If the _stub is a completion, it shall be the completion of a
+subprogram_declaration or generic_subprogram_declaration. The profile
+of a subprogram_body_stub that completes a declaration shall conform
+fully to that of the declaration.
+
+11.a
+ Discussion: The part about subprogram_body_stubs echoes the
+ corresponding rule for subprogram_bodies in *note 6.3::,
+ "*note 6.3:: Subprogram Bodies".
+
+12
+A subunit that corresponds to a body_stub shall be of the same kind
+(package_, subprogram_, task_, or protected_) as the body_stub. The
+profile of a subprogram_body subunit shall be fully conformant to that
+of the corresponding body_stub.
+
+13
+A body_stub shall appear immediately within the declarative_part of a
+compilation unit body. This rule does not apply within an instance of a
+generic unit.
+
+13.a
+ Discussion: This is a methodological restriction; that is, it
+ is not necessary for the semantics of the language to make
+ sense.
+
+14
+The defining_identifiers of all body_stubs that appear immediately
+within a particular declarative_part shall be distinct.
+
+ _Post-Compilation Rules_
+
+15
+For each body_stub, there shall be a subunit containing the
+corresponding proper_body.
+
+ NOTES
+
+16
+ 4 The rules in *note 10.1.4::, "*note 10.1.4:: The Compilation
+ Process" say that a body_stub is equivalent to the corresponding
+ proper_body. This implies:
+
+17
+ * Visibility within a subunit is the visibility that would be
+ obtained at the place of the corresponding body_stub (within
+ the parent body) if the context_clause of the subunit were
+ appended to that of the parent body.
+
+17.a
+ Ramification: Recursively. Note that this transformation
+ might make the parent illegal; hence it is not a true
+ equivalence, but applies only to visibility within the
+ subunit.
+
+18
+ * The effect of the elaboration of a body_stub is to elaborate
+ the subunit.
+
+18.a
+ Ramification: The elaboration of a subunit is part of its
+ parent body's elaboration, whereas the elaboration of a child
+ unit is not part of its parent declaration's elaboration.
+
+18.b
+ Ramification: A library_item that is mentioned in a
+ with_clause of a subunit can be hidden (from direct
+ visibility) by a declaration (with the same identifier) given
+ in the subunit. Moreover, such a library_item can even be
+ hidden by a declaration given within the parent body since a
+ library unit is declared in its parent's declarative region;
+ this however does not affect the interpretation of the
+ with_clauses themselves, since only library_items are visible
+ or directly visible in with_clauses.
+
+18.c
+ The body of a protected operation cannot be a subunit. This
+ follows from the syntax rules. The body of a protected unit
+ can be a subunit.
+
+ _Examples_
+
+19
+The package Parent is first written without subunits:
+
+20
+ package Parent is
+ procedure Inner;
+ end Parent;
+
+21
+ with Ada.Text_IO;
+ package body Parent is
+ Variable : String := "Hello, there.";
+ procedure Inner is
+ begin
+ Ada.Text_IO.Put_Line(Variable);
+ end Inner;
+ end Parent;
+
+22
+The body of procedure Inner may be turned into a subunit by rewriting
+the package body as follows (with the declaration of Parent remaining
+the same):
+
+23
+ package body Parent is
+ Variable : String := "Hello, there.";
+ procedure Inner is separate;
+ end Parent;
+
+24
+ with Ada.Text_IO;
+ separate(Parent)
+ procedure Inner is
+ begin
+ Ada.Text_IO.Put_Line(Variable);
+ end Inner;
+
+ _Extensions to Ada 83_
+
+24.a
+ Subunits of the same ancestor library unit are no longer
+ restricted to have distinct identifiers. Instead, we require
+ only that the full expanded names be distinct.
+
+ _Extensions to Ada 95_
+
+24.b/2
+ {AI95-00218-03AI95-00218-03} An overriding_indicator (see
+ *note 8.3.1::) is allowed on a subprogram stub.
+
+ _Wording Changes from Ada 95_
+
+24.c/2
+ {AI95-00243-01AI95-00243-01} Clarified that a subunit of a
+ subunit is still a subunit.
+
+ _Extensions to Ada 2005_
+
+24.d/3
+ {AI05-0267-1AI05-0267-1} An optional aspect_specification can
+ be used in a body_stub. This is described in *note 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 10.1.4, Next: 10.1.5, Prev: 10.1.3, Up: 10.1
+
+10.1.4 The Compilation Process
+------------------------------
+
+1
+Each compilation unit submitted to the compiler is compiled in the
+context of an environment declarative_part (or simply, an environment),
+which is a conceptual declarative_part that forms the outermost
+declarative region of the context of any compilation. At run time, an
+environment forms the declarative_part of the body of the environment
+task of a partition (see *note 10.2::, "*note 10.2:: Program
+Execution").
+
+1.a
+ Ramification: At compile time, there is no particular
+ construct that the declarative region is considered to be
+ nested within -- the environment is the universe.
+
+1.b
+ To be honest: The environment is really just a portion of a
+ declarative_part, since there might, for example, be bodies
+ that do not yet exist.
+
+2
+The declarative_items of the environment are library_items appearing in
+an order such that there are no forward semantic dependences. Each
+included subunit occurs in place of the corresponding stub. The
+visibility rules apply as if the environment were the outermost
+declarative region, except that with_clause (*note 10.1.2: S0255.)s are
+needed to make declarations of library units visible (see *note
+10.1.2::).
+
+3/2
+{AI95-00217-06AI95-00217-06} The mechanisms for creating an environment
+and for adding and replacing compilation units within an environment are
+implementation defined. The mechanisms for adding a compilation unit
+mentioned in a limited_with_clause to an environment are implementation
+defined.
+
+3.a
+ Implementation defined: The mechanisms for creating an
+ environment and for adding and replacing compilation units.
+
+3.a.1/2
+ Implementation defined: The mechanisms for adding a
+ compilation unit mentioned in a limited_with_clause to an
+ environment.
+
+3.b
+ Ramification: The traditional model, used by most Ada 83
+ implementations, is that one places a compilation unit in the
+ environment by compiling it. Other models are possible. For
+ example, an implementation might define the environment to be
+ a directory; that is, the compilation units in the environment
+ are all the compilation units in the source files contained in
+ the directory. In this model, the mechanism for replacing a
+ compilation unit with a new one is simply to edit the source
+ file containing that compilation unit.
+
+ _Name Resolution Rules_
+
+4/3
+{8652/00328652/0032} {AI95-00192-01AI95-00192-01}
+{AI05-0264-1AI05-0264-1} If a library_unit_body that is a
+subprogram_body is submitted to the compiler, it is interpreted only as
+a completion if a library_unit_declaration with the same
+defining_program_unit_name already exists in the environment for a
+subprogram other than an instance of a generic subprogram or for a
+generic subprogram (even if the profile of the body is not type
+conformant with that of the declaration); otherwise, the subprogram_body
+is interpreted as both the declaration and body of a library subprogram.
+
+4.a
+ Ramification: The principle here is that a subprogram_body
+ should be interpreted as only a completion if and only if it
+ "might" be legal as the completion of some preexisting
+ declaration, where "might" is defined in a way that does not
+ require overload resolution to determine.
+
+4.b
+ Hence, if the preexisting declaration is a
+ subprogram_declaration or generic_subprogram_declaration, we
+ treat the new subprogram_body as its completion, because it
+ "might" be legal. If it turns out that the profiles don't
+ fully conform, it's an error. In all other cases (the
+ preexisting declaration is a package or a generic package, or
+ an instance of a generic subprogram, or a renaming, or a
+ "spec-less" subprogram, or in the case where there is no
+ preexisting thing), the subprogram_body declares a new
+ subprogram.
+
+4.c
+ See also AI83-00266/09.
+
+ _Legality Rules_
+
+5
+When a compilation unit is compiled, all compilation units upon which it
+depends semantically shall already exist in the environment; the set of
+these compilation units shall be consistent in the sense that the new
+compilation unit shall not semantically depend (directly or indirectly)
+on two different versions of the same compilation unit, nor on an
+earlier version of itself.
+
+5.a
+ Discussion: For example, if package declarations A and B both
+ say "with X;", and the user compiles a compilation unit that
+ says "with A, B;", then the A and B have to be talking about
+ the same version of X.
+
+5.b
+ Ramification: What it means to be a "different version" is not
+ specified by the language. In some implementations, it means
+ that the compilation unit has been recompiled. In others, it
+ means that the source of the compilation unit has been edited
+ in some significant way.
+
+5.c
+ Note that an implementation cannot require the existence of
+ compilation units upon which the given one does not
+ semantically depend. For example, an implementation is
+ required to be able to compile a compilation unit that says
+ "with A;" when A's body does not exist. It has to be able to
+ detect errors without looking at A's body.
+
+5.d/3
+ {AI05-0229-1AI05-0229-1} Similarly, the implementation has to
+ be able to compile a call to a subprogram for which aspect
+ Inline has been specified without seeing the body of that
+ subprogram -- inlining would not be achieved in this case, but
+ the call is still legal.
+
+5.e/3
+ {AI95-00217-06AI95-00217-06} {AI05-0005-1AI05-0005-1} The
+ consistency rule applies to limited views as well as the full
+ view of a compilation unit. That means that an implementation
+ needs a way to enforce consistency of limited views, not just
+ of full views.
+
+ _Implementation Permissions_
+
+6/2
+{AI95-00217-06AI95-00217-06} The implementation may require that a
+compilation unit be legal before it can be mentioned in a
+limited_with_clause or it can be inserted into the environment.
+
+7/3
+{AI95-00214-01AI95-00214-01} {AI05-0229-1AI05-0229-1} When a compilation
+unit that declares or renames a library unit is added to the
+environment, the implementation may remove from the environment any
+preexisting library_item or subunit with the same full expanded name.
+When a compilation unit that is a subunit or the body of a library unit
+is added to the environment, the implementation may remove from the
+environment any preexisting version of the same compilation unit. When
+a compilation unit that contains a body_stub is added to the
+environment, the implementation may remove any preexisting library_item
+or subunit with the same full expanded name as the body_stub. When a
+given compilation unit is removed from the environment, the
+implementation may also remove any compilation unit that depends
+semantically upon the given one. If the given compilation unit contains
+the body of a subprogram for which aspect Inline is True, the
+implementation may also remove any compilation unit containing a call to
+that subprogram.
+
+7.a/3
+ Ramification: {AI05-0005-1AI05-0005-1} The permissions given
+ in this paragraph correspond to the traditional model, where
+ compilation units enter the environment by being compiled into
+ it, and the compiler checks their legality at that time. An
+ implementation model in which the environment consists of all
+ source files in a given directory might not want to take
+ advantage of these permissions. Compilation units would not
+ be checked for legality as soon as they enter the environment;
+ legality checking would happen later, when compilation units
+ are compiled. In this model, compilation units might never be
+ automatically removed from the environment; they would be
+ removed when the user explicitly deletes a source file.
+
+7.b
+ Note that the rule is recursive: if the above permission is
+ used to remove a compilation unit containing an inlined
+ subprogram call, then compilation units that depend
+ semantically upon the removed one may also be removed, and so
+ on.
+
+7.c
+ Note that here we are talking about dependences among existing
+ compilation units in the environment; it doesn't matter what
+ with_clauses are attached to the new compilation unit that
+ triggered all this.
+
+7.d/3
+ {AI05-0229-1AI05-0229-1} An implementation may have other
+ modes in which compilation units in addition to the ones
+ mentioned above are removed. For example, an implementation
+ might inline subprogram calls without an explicit aspect
+ Inline. If so, it either has to have a mode in which that
+ optimization is turned off, or it has to automatically
+ regenerate code for the inlined calls without requiring the
+ user to resubmit them to the compiler.
+
+7.d.1/2
+ Discussion: {8652/01088652/0108} {AI95-00077-01AI95-00077-01}
+ {AI95-00114-01AI95-00114-01} In the standard mode,
+ implementations may only remove units from the environment for
+ one of the reasons listed here, or in response to an explicit
+ user command to modify the environment. It is not intended
+ that the act of compiling a unit is one of the "mechanisms"
+ for removing units other than those specified by this
+ International Standard.
+
+7.e/2
+ {AI95-00214-01AI95-00214-01} These rules are intended to
+ ensure that an implementation never need keep more than one
+ compilation unit with any full expanded name. In particular,
+ it is not necessary to be able to have a subunit and a child
+ unit with the same name in the environment at one time.
+
+ NOTES
+
+8
+ 5 The rules of the language are enforced across compilation and
+ compilation unit boundaries, just as they are enforced within a
+ single compilation unit.
+
+8.a/3
+ Ramification: {AI05-0299-1AI05-0299-1} Note that Clause *note
+ 1:: requires an implementation to detect illegal compilation
+ units at compile time.
+
+9
+ 6 An implementation may support a concept of a library, which
+ contains library_items. If multiple libraries are supported, the
+ implementation has to define how a single environment is
+ constructed when a compilation unit is submitted to the compiler.
+ Naming conflicts between different libraries might be resolved by
+ treating each library as the root of a hierarchy of child library
+ units.
+
+9.a
+ Implementation Note: Alternatively, naming conflicts could be
+ resolved via some sort of hiding rule.
+
+9.b
+ Discussion: For example, the implementation might support a
+ command to import library Y into library X. If a root library
+ unit called LU (that is, Standard.LU) exists in Y, then from
+ the point of view of library X, it could be called Y.LU. X
+ might contain library units that say, "with Y.LU;".
+
+10
+ 7 A compilation unit containing an instantiation of a separately
+ compiled generic unit does not semantically depend on the body of
+ the generic unit. Therefore, replacing the generic body in the
+ environment does not result in the removal of the compilation unit
+ containing the instantiation.
+
+10.a
+ Implementation Note: Therefore, implementations have to be
+ prepared to automatically instantiate generic bodies at
+ link-time, as needed. This might imply a complete automatic
+ recompilation, but it is the intent of the language that
+ generic bodies can be (re)instantiated without forcing all of
+ the compilation units that semantically depend on the
+ compilation unit containing the instantiation to be
+ recompiled.
+
+ _Extensions to Ada 83_
+
+10.b/2
+ {AI95-00077-01AI95-00077-01} {AI95-00114-01AI95-00114-01} Ada
+ 83 allowed implementations to require that the body of a
+ generic unit be available when the instantiation is compiled;
+ that permission is dropped in Ada 95. This isn't really an
+ extension (it doesn't allow Ada users to write anything that
+ they couldn't in Ada 83), but there isn't a more appropriate
+ category, and it does allow users more flexibility when
+ developing programs.
+
+ _Wording Changes from Ada 95_
+
+10.c/2
+ {8652/00328652/0032} {AI95-00192-01AI95-00192-01} Corrigendum:
+ The wording was clarified to ensure that a subprogram_body is
+ not considered a completion of an instance of a generic
+ subprogram.
+
+10.d/2
+ {AI95-00214-01AI95-00214-01} The permissions to remove a unit
+ from the environment were clarified to ensure that it is never
+ necessary to keep multiple (sub)units with the same full
+ expanded name in the environment.
+
+10.e/2
+ {AI95-00217-06AI95-00217-06} Units mentioned in a
+ limited_with_clause were added to several rules; limited views
+ have the same presence in the environment as the corresponding
+ full views.
+
+\1f
+File: aarm2012.info, Node: 10.1.5, Next: 10.1.6, Prev: 10.1.4, Up: 10.1
+
+10.1.5 Pragmas and Program Units
+--------------------------------
+
+1
+[This subclause discusses pragmas related to program units, library
+units, and compilations.]
+
+ _Name Resolution Rules_
+
+2
+Certain pragmas are defined to be program unit pragmas. A name given as
+the argument of a program unit pragma shall resolve to denote the
+declarations or renamings of one or more program units that occur
+immediately within the declarative region or compilation in which the
+pragma immediately occurs, or it shall resolve to denote the declaration
+of the immediately enclosing program unit (if any); the pragma applies
+to the denoted program unit(s). If there are no names given as
+arguments, the pragma applies to the immediately enclosing program unit.
+
+2.a
+ Ramification: The fact that this is a Name Resolution Rule
+ means that the pragma will not apply to declarations from
+ outer declarative regions.
+
+ _Legality Rules_
+
+3
+A program unit pragma shall appear in one of these places:
+
+4
+ * At the place of a compilation_unit, in which case the pragma shall
+ immediately follow in the same compilation (except for other
+ pragmas) a library_unit_declaration (*note 10.1.1: S0249.) that is
+ a subprogram_declaration (*note 6.1: S0163.),
+ generic_subprogram_declaration (*note 12.1: S0271.), or
+ generic_instantiation (*note 12.3: S0275.), and the pragma shall
+ have an argument that is a name denoting that declaration.
+
+4.a
+ Ramification: The name has to denote the immediately preceding
+ library_unit_declaration.
+
+5/1
+ * {8652/00338652/0033} {AI95-00136-01AI95-00136-01} Immediately
+ within the visible part of a program unit and before any nested
+ declaration (but not within a generic formal part), in which case
+ the argument, if any, shall be a direct_name that denotes the
+ immediately enclosing program unit declaration.
+
+5.a
+ Ramification: The argument is optional in this case.
+
+6
+ * At the place of a declaration other than the first, of a
+ declarative_part or program unit declaration, in which case the
+ pragma shall have an argument, which shall be a direct_name that
+ denotes one or more of the following (and nothing else): a
+ subprogram_declaration (*note 6.1: S0163.), a
+ generic_subprogram_declaration (*note 12.1: S0271.), or a
+ generic_instantiation (*note 12.3: S0275.), of the same
+ declarative_part (*note 3.11: S0086.) or program unit declaration.
+
+6.a
+ Ramification: If you want to denote a subprogram_body that is
+ not a completion, or a package_declaration, for example, you
+ have to put the pragma inside.
+
+7/3
+{AI05-0132-1AI05-0132-1} Certain program unit pragmas are defined to be
+library unit pragmas. If a library unit pragma applies to a program
+unit, the program unit shall be a library unit.
+
+7.a
+ Ramification: This, together with the rules for program unit
+ pragmas above, implies that if a library unit pragma applies
+ to a subprogram_declaration (and similar things), it has to
+ appear immediately after the compilation_unit, whereas if the
+ pragma applies to a package_declaration, a subprogram_body
+ that is not a completion (and similar things), it has to
+ appear inside, as the first declarative_item.
+
+ _Static Semantics_
+
+7.1/1
+{8652/00348652/0034} {AI95-00041-01AI95-00041-01} A library unit pragma
+that applies to a generic unit does not apply to its instances, unless a
+specific rule for the pragma specifies the contrary.
+
+ _Post-Compilation Rules_
+
+8
+Certain pragmas are defined to be configuration pragmas; they shall
+appear before the first compilation_unit of a compilation. [They are
+generally used to select a partition-wide or system-wide option.] The
+pragma applies to all compilation_units appearing in the compilation,
+unless there are none, in which case it applies to all future
+compilation_units compiled into the same environment.
+
+ _Implementation Permissions_
+
+9/2
+{AI95-00212-01AI95-00212-01} An implementation may require that
+configuration pragmas that select partition-wide or system-wide options
+be compiled when the environment contains no library_items other than
+those of the predefined environment. In this case, the implementation
+shall still accept configuration pragmas in individual compilations that
+confirm the initially selected partition-wide or system-wide options.
+
+ _Implementation Advice_
+
+10/1
+{8652/00348652/0034} {AI95-00041-01AI95-00041-01} When applied to a
+generic unit, a program unit pragma that is not a library unit pragma
+should apply to each instance of the generic unit for which there is not
+an overriding pragma applied directly to the instance.
+
+10.a/2
+ Implementation Advice: When applied to a generic unit, a
+ program unit pragma that is not a library unit pragma should
+ apply to each instance of the generic unit for which there is
+ not an overriding pragma applied directly to the instance.
+
+ _Wording Changes from Ada 95_
+
+10.b/2
+ {8652/00338652/0033} {AI95-00136-01AI95-00136-01} Corrigendum:
+ The wording was corrected to ensure that a program unit pragma
+ cannot appear in private parts or generic formal parts.
+
+10.c/2
+ {8652/00348652/0034} {AI95-00041-01AI95-00041-01} Corrigendum:
+ The wording was clarified to explain the meaning of program
+ unit and library unit pragmas in generic units.
+
+10.d/2
+ The Implementation Advice added by the Corrigendum was moved,
+ as it was not in the normal order. (This changes the
+ paragraph number.) It originally was directly after the new
+ Static Semantics rule.
+
+10.e/2
+ {AI95-00212-01AI95-00212-01} The permission to place
+ restrictions was clarified to:
+
+10.f/2
+ * Ensure that it applies only to partition-wide
+ configuration pragmas, not ones like Assertion_Policy
+ (see *note 11.4.2::), which can be different in different
+ units; and
+
+10.g/2
+ * Ensure that confirming pragmas are always allowed.
+
+ _Wording Changes from Ada 2005_
+
+10.h/3
+ {AI05-0132-1AI05-0132-1} Correction: A library unit pragma
+ must apply directly to a library unit, even if no name is
+ given in the pragma.
+
+\1f
+File: aarm2012.info, Node: 10.1.6, Prev: 10.1.5, Up: 10.1
+
+10.1.6 Environment-Level Visibility Rules
+-----------------------------------------
+
+1
+[The normal visibility rules do not apply within a parent_unit_name or a
+context_clause, nor within a pragma that appears at the place of a
+compilation unit. The special visibility rules for those contexts are
+given here.]
+
+ _Static Semantics_
+
+2/2
+{AI95-00217-06AI95-00217-06} {AI95-00312-01AI95-00312-01} Within the
+parent_unit_name at the beginning of an explicit library_item, and
+within a nonlimited_with_clause, the only declarations that are visible
+are those that are explicit library_items of the environment, and the
+only declarations that are directly visible are those that are explicit
+root library_items of the environment. Within a limited_with_clause,
+the only declarations that are visible are those that are the implicit
+declaration of the limited view of a library package of the environment,
+and the only declarations that are directly visible are those that are
+the implicit declaration of the limited view of a root library package.
+
+2.a
+ Ramification: In "package P.Q.R is ... end P.Q.R;", this rule
+ requires P to be a root library unit, and Q to be a library
+ unit (because those are the things that are directly visible
+ and visible). Note that visibility does not apply between the
+ "end" and the ";".
+
+2.b
+ Physically nested declarations are not visible at these
+ places.
+
+2.c
+ Although Standard is visible at these places, it is impossible
+ to name it, since it is not directly visible, and it has no
+ parent.
+
+2.c.1/2
+ {AI95-00217-06AI95-00217-06} Only compilation units defining
+ limited views can be mentioned in a limited_with_clause, while
+ only compilation units defining full views (that is, the
+ explicit declarations) can be mentioned in a
+ nonlimited_with_clause. This resolves the conflict inherent
+ in having two compilation units with the same defining name.
+
+2.d/2
+ This paragraph was deleted.{AI95-00312-01AI95-00312-01}
+
+3
+Within a use_clause or pragma that is within a context_clause, each
+library_item mentioned in a previous with_clause of the same
+context_clause is visible, and each root library_item so mentioned is
+directly visible. In addition, within such a use_clause, if a given
+declaration is visible or directly visible, each declaration that occurs
+immediately within the given declaration's visible part is also visible.
+No other declarations are visible or directly visible.
+
+3.a
+ Discussion: Note the word "same". For example, if a
+ with_clause on a declaration mentions X, this does not make X
+ visible in use_clauses and pragmas that are on the body. The
+ reason for this rule is the one-pass context_clauses Language
+ Design Principle.
+
+3.b
+ Note that the second part of the rule does not mention
+ pragmas.
+
+4
+Within the parent_unit_name of a subunit, library_items are visible as
+they are in the parent_unit_name of a library_item; in addition, the
+declaration corresponding to each body_stub in the environment is also
+visible.
+
+4.a
+ Ramification: For a subprogram without a separate
+ subprogram_declaration, the body_stub itself is the
+ declaration.
+
+5
+Within a pragma that appears at the place of a compilation unit, the
+immediately preceding library_item and each of its ancestors is visible.
+The ancestor root library_item is directly visible.
+
+6/2
+{AI95-00312-01AI95-00312-01} Notwithstanding the rules of *note 4.1.3::,
+an expanded name in a with_clause, a pragma in a context_clause, or a
+pragma that appears at the place of a compilation unit may consist of a
+prefix that denotes a generic package and a selector_name that denotes a
+child of that generic package. [(The child is necessarily a generic
+unit; see *note 10.1.1::.)]
+
+6.a/2
+ Reason: This rule allows with A.B; and pragma Elaborate(A.B);
+ where A is a generic library package and B is one of its
+ (generic) children. This is necessary because it is not
+ normally legal to use an expanded name to reach inside a
+ generic package.
+
+ _Wording Changes from Ada 83_
+
+6.b
+ The special visibility rules that apply within a
+ parent_unit_name or a context_clause, and within a pragma that
+ appears at the place of a compilation_unit are clarified.
+
+6.c
+ Note that a context_clause is not part of any declarative
+ region.
+
+6.d
+ We considered making the visibility rules within
+ parent_unit_names and context_clauses follow from the context
+ of compilation. However, this attempt failed for various
+ reasons. For example, it would require use_clauses in
+ context_clauses to be within the declarative region of
+ Standard, which sounds suspiciously like a kludge. And we
+ would still need a special rule to prevent seeing things (in
+ our own context_clause) that were with-ed by our parent, etc.
+
+ _Wording Changes from Ada 95_
+
+6.e/2
+ {AI95-00217-06AI95-00217-06} Added separate visibility rules
+ for limited_with_clauses; the existing rules apply only to
+ nonlimited_with_clauses.
+
+6.f/2
+ {AI95-00312-01AI95-00312-01} Clarified that the name of a
+ generic child unit may appear in a pragma in a context_clause.
+
+\1f
+File: aarm2012.info, Node: 10.2, Prev: 10.1, Up: 10
+
+10.2 Program Execution
+======================
+
+1
+An Ada program consists of a set of partitions[, which can execute in
+parallel with one another, possibly in a separate address space, and
+possibly on a separate computer.]
+
+ _Post-Compilation Rules_
+
+2
+A partition is a program or part of a program that can be invoked from
+outside the Ada implementation. [For example, on many systems, a
+partition might be an executable file generated by the system linker.]
+The user can explicitly assign library units to a partition. The
+assignment is done in an implementation-defined manner. The compilation
+units included in a partition are those of the explicitly assigned
+library units, as well as other compilation units needed by those
+library units. The compilation units needed by a given compilation unit
+are determined as follows (unless specified otherwise via an
+implementation-defined pragma, or by some other implementation-defined
+means):
+
+2.a
+ Discussion: From a run-time point of view, an Ada 95 partition
+ is identical to an Ada 83 program -- implementations were
+ always allowed to provide inter-program communication
+ mechanisms. The additional semantics of partitions is that
+ interfaces between them can be defined to obey normal language
+ rules (as is done in *note Annex E::, "*note Annex E::
+ Distributed Systems"), whereas interfaces between separate
+ programs had no particular semantics.
+
+2.b
+ Implementation defined: The manner of explicitly assigning
+ library units to a partition.
+
+2.c
+ Implementation defined: The implementation-defined means, if
+ any, of specifying which compilation units are needed by a
+ given compilation unit.
+
+2.d
+ Discussion: There are no pragmas that "specify otherwise"
+ defined by the core language. However, an implementation is
+ allowed to provide such pragmas, and in fact *note Annex E::,
+ "*note Annex E:: Distributed Systems" defines some pragmas
+ whose semantics includes reducing the set of compilation units
+ described here.
+
+3
+ * A compilation unit needs itself;
+
+4
+ * If a compilation unit is needed, then so are any compilation units
+ upon which it depends semantically;
+
+5
+ * If a library_unit_declaration is needed, then so is any
+ corresponding library_unit_body;
+
+6/2
+ * {AI95-00217-06AI95-00217-06} If a compilation unit with stubs is
+ needed, then so are any corresponding subunits;
+
+6.a
+ Discussion: Note that in the environment, the stubs are
+ replaced with the corresponding proper_bodies.
+
+6.1/2
+ * {AI95-00217-06AI95-00217-06} If the (implicit) declaration of the
+ limited view of a library package is needed, then so is the
+ explicit declaration of the library package.
+
+6.b
+ Discussion: Note that a child unit is not included just
+ because its parent is included -- to include a child, mention
+ it in a with_clause.
+
+6.c/2
+ {AI95-00217-06AI95-00217-06} A package is included in a
+ partition even if the only reference to it is in a
+ limited_with_clause. While this isn't strictly necessary (no
+ objects of types imported from such a unit can be created), it
+ ensures that all incomplete types are eventually completed,
+ and is the least surprising option.
+
+7
+The user can optionally designate (in an implementation-defined manner)
+one subprogram as the main subprogram for the partition. A main
+subprogram, if specified, shall be a subprogram.
+
+7.a
+ Discussion: This may seem superfluous, since it follows from
+ the definition. But we would like to have every error message
+ that might be generated (before run time) by an implementation
+ correspond to some explicitly stated "shall" rule.
+
+7.b
+ Of course, this does not mean that the "shall" rules
+ correspond one-to-one with an implementation's error messages.
+ For example, the rule that says overload resolution "shall"
+ succeed in producing a single interpretation would correspond
+ to many error messages in a good implementation -- the
+ implementation would want to explain to the user exactly why
+ overload resolution failed. This is especially true for the
+ syntax rules -- they are considered part of overload
+ resolution, but in most cases, one would expect an error
+ message based on the particular syntax rule that was violated.
+
+7.c
+ Implementation defined: The manner of designating the main
+ subprogram of a partition.
+
+7.d
+ Ramification: An implementation cannot require the user to
+ specify, say, all of the library units to be included. It has
+ to support, for example, perhaps the most typical case, where
+ the user specifies just one library unit, the main program.
+ The implementation has to do the work of tracking down all the
+ other ones.
+
+8
+Each partition has an anonymous environment task[, which is an implicit
+outermost task whose execution elaborates the library_items of the
+environment declarative_part, and then calls the main subprogram, if
+there is one. A partition's execution is that of its tasks.]
+
+8.a
+ Ramification: An environment task has no master; all
+ nonenvironment tasks have masters.
+
+8.b
+ An implementation is allowed to support multiple concurrent
+ executions of the same partition.
+
+9
+[The order of elaboration of library units is determined primarily by
+the elaboration dependences.] There is an elaboration dependence of a
+given library_item upon another if the given library_item or any of its
+subunits depends semantically on the other library_item. In addition,
+if a given library_item or any of its subunits has a pragma Elaborate or
+Elaborate_All that names another library unit, then there is an
+elaboration dependence of the given library_item upon the body of the
+other library unit, and, for Elaborate_All only, upon each library_item
+needed by the declaration of the other library unit.
+
+9.a.1/2
+ Discussion: {8652/01078652/0107} {AI95-00180-01AI95-00180-01}
+ {AI95-00256-01AI95-00256-01} "Mentions" was used informally in
+ the above rule; it was not intended to refer to the definition
+ of mentions in *note 10.1.2::. It was changed to "names" to
+ make this clear.
+
+9.a
+ See above for a definition of which library_items are "needed
+ by" a given declaration.
+
+9.b
+ Note that elaboration dependences are among library_items,
+ whereas the other two forms of dependence are among
+ compilation units. Note that elaboration dependence includes
+ semantic dependence. It's a little bit sad that pragma
+ Elaborate_Body can't be folded into this mechanism. It
+ follows from the definition that the elaboration dependence
+ relationship is transitive. Note that the wording of the rule
+ does not need to take into account a semantic dependence of a
+ library_item or one of its subunits upon a subunit of a
+ different library unit, because that can never happen.
+
+10
+The environment task for a partition has the following structure:
+
+11
+ task Environment_Task;
+
+12
+ task body Environment_Task is
+ ... (1) -- The environment declarative_part
+ -- (that is, the sequence of library_items) goes here.
+ begin
+ ... (2) -- Call the main subprogram, if there is one.
+ end Environment_Task;
+
+12.a
+ Ramification: The name of the environment task is written in
+ italics here to indicate that this task is anonymous.
+
+12.b
+ Discussion: The model is different for a "passive partition"
+ (see *note E.1::). Either there is no environment task, or
+ its sequence_of_statements is an infinite loop rather than a
+ call on a main subprogram.
+
+13
+The environment declarative_part at (1) is a sequence of
+declarative_items consisting of copies of the library_items included in
+the partition[. The order of elaboration of library_items is the order
+in which they appear in the environment declarative_part]:
+
+14
+ * The order of all included library_items is such that there are no
+ forward elaboration dependences.
+
+14.a
+ Ramification: This rule is written so that if a library_item
+ depends on itself, we don't require it to be elaborated before
+ itself. See AI83-00113/12. This can happen only in
+ pathological circumstances. For example, if a library
+ subprogram_body has no corresponding subprogram_declaration,
+ and one of the subunits of the subprogram_body mentions the
+ subprogram_body in a with_clause, the subprogram_body will
+ depend on itself. For another example, if a library_unit_body
+ applies a pragma Elaborate_All to its own declaration, then
+ the library_unit_body will depend on itself.
+
+15/3
+ * {AI05-0229-1AI05-0229-1} Any included library_unit_declaration for
+ which aspect Elaborate_Body is True [(including when a pragma
+ Elaborate_Body applies)] is immediately followed by its
+ library_unit_body, if included.
+
+15.a
+ Discussion: This implies that the body of such a library unit
+ shall not "with" any of its own children, or anything else
+ that depends semantically upon the declaration of the library
+ unit.
+
+15.b/3
+ Proof: {AI05-0229-1AI05-0229-1} Pragma Elaborate_Body sets
+ aspect Elaborate_Body, see *note 10.2.1::.
+
+16
+ * All library_items declared pure occur before any that are not
+ declared pure.
+
+17
+ * All preelaborated library_items occur before any that are not
+ preelaborated.
+
+17.a
+ Discussion: Normally, if two partitions contain the same
+ compilation unit, they each contain a separate copy of that
+ compilation unit. See *note Annex E::, "*note Annex E::
+ Distributed Systems" for cases where two partitions share the
+ same copy of something.
+
+17.b
+ There is no requirement that the main subprogram be elaborated
+ last. In fact, it is possible to write a partition in which
+ the main subprogram cannot be elaborated last.
+
+17.c
+ Ramification: This declarative_part has the properties
+ required of all environments (see *note 10.1.4::). However,
+ the environment declarative_part of a partition will typically
+ contain fewer compilation units than the environment
+ declarative_part used at compile time -- only the "needed"
+ ones are included in the partition.
+
+18
+There shall be a total order of the library_items that obeys the above
+rules. The order is otherwise implementation defined.
+
+18.a
+ Discussion: The only way to violate this rule is to have
+ Elaborate, Elaborate_All, or Elaborate_Body pragmas that cause
+ circular ordering requirements, thus preventing an order that
+ has no forward elaboration dependences.
+
+18.b
+ Implementation defined: The order of elaboration of
+ library_items.
+
+18.c
+ To be honest: Notwithstanding what the RM95 says elsewhere,
+ each rule that requires a declaration to have a corresponding
+ completion is considered to be a Post-Compilation Rule when
+ the declaration is that of a library unit.
+
+18.d
+ Discussion: Such rules may be checked at "link time," for
+ example. Rules requiring the completion to have certain
+ properties, on the other hand, are checked at compile time of
+ the completion.
+
+19
+The full expanded names of the library units and subunits included in a
+given partition shall be distinct.
+
+19.a
+ Reason: This is a Post-Compilation Rule because making it a
+ Legality Rule would violate the Language Design Principle
+ labeled "legality determinable via semantic dependences."
+
+20
+The sequence_of_statements of the environment task (see (2) above)
+consists of either:
+
+21
+ * A call to the main subprogram, if the partition has one. If the
+ main subprogram has parameters, they are passed; where the actuals
+ come from is implementation defined. What happens to the result of
+ a main function is also implementation defined.
+
+21.a
+ Implementation defined: Parameter passing and function return
+ for the main subprogram.
+
+22
+or:
+
+23
+ * A null_statement, if there is no main subprogram.
+
+23.a
+ Discussion: For a passive partition, either there is no
+ environment task, or its sequence_of_statements is an infinite
+ loop. See *note E.1::.
+
+24
+The mechanisms for building and running partitions are implementation
+defined. [These might be combined into one operation, as, for example,
+in dynamic linking, or "load-and-go" systems.]
+
+24.a
+ Implementation defined: The mechanisms for building and
+ running partitions.
+
+ _Dynamic Semantics_
+
+25
+The execution of a program consists of the execution of a set of
+partitions. Further details are implementation defined. The execution
+of a partition starts with the execution of its environment task, ends
+when the environment task terminates, and includes the executions of all
+tasks of the partition. [The execution of the (implicit) task_body of
+the environment task acts as a master for all other tasks created as
+part of the execution of the partition. When the environment task
+completes (normally or abnormally), it waits for the termination of all
+such tasks, and then finalizes any remaining objects of the partition.]
+
+25.a
+ Ramification: The "further details" mentioned above include,
+ for example, program termination -- it is implementation
+ defined. There is no need to define it here; it's entirely up
+ to the implementation whether it wants to consider the program
+ as a whole to exist beyond the existence of individual
+ partitions.
+
+25.b
+ Implementation defined: The details of program execution,
+ including program termination.
+
+25.c
+ To be honest: The execution of the partition terminates
+ (normally or abnormally) when the environment task terminates
+ (normally or abnormally, respectively).
+
+ _Bounded (Run-Time) Errors_
+
+26
+Once the environment task has awaited the termination of all other tasks
+of the partition, any further attempt to create a task (during
+finalization) is a bounded error, and may result in the raising of
+Program_Error either upon creation or activation of the task. If such a
+task is activated, it is not specified whether the task is awaited prior
+to termination of the environment task.
+
+ _Implementation Requirements_
+
+27
+The implementation shall ensure that all compilation units included in a
+partition are consistent with one another, and are legal according to
+the rules of the language.
+
+27.a
+ Discussion: The consistency requirement implies that a
+ partition cannot contain two versions of the same compilation
+ unit. That is, a partition cannot contain two different
+ library units with the same full expanded name, nor two
+ different bodies for the same program unit. For example,
+ suppose we compile the following:
+
+27.b
+ package A is -- Version 1.
+ ...
+ end A;
+
+27.c
+ with A;
+ package B is
+ end B;
+
+27.d
+ package A is -- Version 2.
+ ...
+ end A;
+
+27.e
+ with A;
+ package C is
+ end C;
+
+27.f
+ It would be wrong for a partition containing B and C to
+ contain both versions of A. Typically, the implementation
+ would require the use of Version 2 of A, which might require
+ the recompilation of B. Alternatively, the implementation
+ might automatically recompile B when the partition is built.
+ A third alternative would be an incremental compiler that,
+ when Version 2 of A is compiled, automatically patches the
+ object code for B to reflect the changes to A (if there are
+ any relevant changes -- there might not be any).
+
+27.g
+ An implementation that supported fancy version management
+ might allow the use of Version 1 in some circumstances. In no
+ case can the implementation allow the use of both versions in
+ the same partition (unless, of course, it can prove that the
+ two versions are semantically identical).
+
+27.h
+ The core language says nothing about inter-partition
+ consistency; see also *note Annex E::, "*note Annex E::
+ Distributed Systems".
+
+ _Implementation Permissions_
+
+28/3
+{AI05-0299-1AI05-0299-1} The kind of partition described in this
+subclause is known as an active partition. An implementation is allowed
+to support other kinds of partitions, with implementation-defined
+semantics.
+
+28.a
+ Implementation defined: The semantics of any nonactive
+ partitions supported by the implementation.
+
+28.b
+ Discussion: *note Annex E::, "*note Annex E:: Distributed
+ Systems" defines the concept of passive partitions; they may
+ be thought of as a partition without an environment task, or
+ as one with a particularly simple form of environment task,
+ having an infinite loop rather than a call on a main
+ subprogram as its sequence_of_statements.
+
+29
+An implementation may restrict the kinds of subprograms it supports as
+main subprograms. However, an implementation is required to support all
+main subprograms that are public parameterless library procedures.
+
+29.a
+ Ramification: The implementation is required to support main
+ subprograms that are procedures declared by
+ generic_instantiations, as well as those that are children of
+ library units other than Standard. Generic units are, of
+ course, not allowed to be main subprograms, since they are not
+ subprograms.
+
+29.b
+ Note that renamings are irrelevant to this rule. This rules
+ says which subprograms (not views) have to be supported. The
+ implementation can choose any way it wants for the user to
+ indicate which subprogram should be the main subprogram. An
+ implementation might allow any name of any view, including
+ those declared by renamings. Another implementation might
+ require it to be the original name. Another implementation
+ still might use the name of the source file or some such
+ thing.
+
+30
+If the environment task completes abnormally, the implementation may
+abort any dependent tasks.
+
+30.a
+ Reason: If the implementation does not take advantage of this
+ permission, the normal action takes place -- the environment
+ task awaits those tasks.
+
+30.b
+ The possibility of aborting them is not shown in the
+ Environment_Task code above, because there is nowhere to put
+ an exception_handler that can handle exceptions raised in both
+ the environment declarative_part and the main subprogram, such
+ that the dependent tasks can be aborted. If we put an
+ exception_handler in the body of the environment task, then it
+ won't handle exceptions that occur during elaboration of the
+ environment declarative_part. If we were to move those things
+ into a nested block_statement, with the exception_handler
+ outside that, then the block_statement would await the library
+ tasks we are trying to abort.
+
+30.c
+ Furthermore, this is merely a permission, and is not
+ fundamental to the model, so it is probably better to state it
+ separately anyway.
+
+30.d
+ Note that implementations (and tools like debuggers) can have
+ modes that provide other behaviors in addition.
+
+ NOTES
+
+31
+ 8 An implementation may provide inter-partition communication
+ mechanism(s) via special packages and pragmas. Standard pragmas
+ for distribution and methods for specifying inter-partition
+ communication are defined in *note Annex E::, "*note Annex E::
+ Distributed Systems". If no such mechanisms are provided, then
+ each partition is isolated from all others, and behaves as a
+ program in and of itself.
+
+31.a
+ Ramification: Not providing such mechanisms is equivalent to
+ disallowing multi-partition programs.
+
+31.b
+ An implementation may provide mechanisms to facilitate
+ checking the consistency of library units elaborated in
+ different partitions; *note Annex E::, "*note Annex E::
+ Distributed Systems" does so.
+
+32
+ 9 Partitions are not required to run in separate address spaces.
+ For example, an implementation might support dynamic linking via
+ the partition concept.
+
+33
+ 10 An order of elaboration of library_items that is consistent
+ with the partial ordering defined above does not always ensure that
+ each library_unit_body is elaborated before any other compilation
+ unit whose elaboration necessitates that the library_unit_body be
+ already elaborated. (In particular, there is no requirement that
+ the body of a library unit be elaborated as soon as possible after
+ the library_unit_declaration is elaborated, unless the pragmas in
+ subclause *note 10.2.1:: are used.)
+
+34
+ 11 A partition (active or otherwise) need not have a main
+ subprogram. In such a case, all the work done by the partition
+ would be done by elaboration of various library_items, and by tasks
+ created by that elaboration. Passive partitions, which cannot have
+ main subprograms, are defined in *note Annex E::, "*note Annex E::
+ Distributed Systems".
+
+34.a
+ Ramification: The environment task is the outermost semantic
+ level defined by the language.
+
+34.b
+ Standard has no private part. This prevents strange
+ implementation-dependences involving private children of
+ Standard having visibility upon Standard's private part. It
+ doesn't matter where the body of Standard appears in the
+ environment, since it doesn't do anything. See *note Annex
+ A::, "*note Annex A:: Predefined Language Environment".
+
+34.c
+ Note that elaboration dependence is carefully defined in such
+ a way that if (say) the body of something doesn't exist yet,
+ then there is no elaboration dependence upon the nonexistent
+ body. (This follows from the fact that "needed by" is defined
+ that way, and the elaboration dependences caused by a pragma
+ Elaborate or Elaborate_All are defined in terms of "needed
+ by".) This property allows us to use the environment concept
+ both at compile time and at partition-construction time/run
+ time.
+
+ _Extensions to Ada 83_
+
+34.d
+ The concept of partitions is new to Ada 95.
+
+34.e
+ A main subprogram is now optional. The language-defined
+ restrictions on main subprograms are relaxed.
+
+ _Wording Changes from Ada 83_
+
+34.f
+ Ada 95 uses the term "main subprogram" instead of Ada 83's
+ "main program" (which was inherited from Pascal). This is
+ done to avoid confusion -- a main subprogram is a subprogram,
+ not a program. The program as a whole is an entirely
+ different thing.
+
+ _Wording Changes from Ada 95_
+
+34.g/2
+ {AI95-00256-01AI95-00256-01} The mistaken use of "mentions" in
+ the elaboration dependence rule was fixed.
+
+34.h/2
+ {AI95-00217-06AI95-00217-06} The needs relationship was
+ extended to include limited views.
+
+* Menu:
+
+* 10.2.1 :: Elaboration Control
+
+\1f
+File: aarm2012.info, Node: 10.2.1, Up: 10.2
+
+10.2.1 Elaboration Control
+--------------------------
+
+1
+[ This subclause defines pragmas that help control the elaboration order
+of library_items.]
+
+ _Language Design Principles_
+
+1.a
+ The rules governing preelaboration are designed to allow it to
+ be done largely by bulk initialization of statically allocated
+ storage from information in a "load module" created by a
+ linker. Some implementations may require run-time code to be
+ executed in some cases, but we consider these cases rare
+ enough that we need not further complicate the rules.
+
+1.b
+ It is important that programs be able to declare data
+ structures that are link-time initialized with aggregates,
+ string_literals, and concatenations thereof. It is important
+ to be able to write link-time evaluated expressions involving
+ the First, Last, and Length attributes of such data structures
+ (including variables), because they might be initialized with
+ positional aggregates or string_literals, and we don't want
+ the user to have to count the elements. There is no
+ corresponding need for accessing discriminants, since they can
+ be initialized with a static constant, and then the constant
+ can be referred to elsewhere. It is important to allow
+ link-time initialized data structures involving
+ discriminant-dependent components. It is important to be able
+ to write link-time evaluated expressions involving pointers
+ (both access values and addresses) to the above-mentioned data
+ structures.
+
+1.c
+ The rules also ensure that no Elaboration_Check need be
+ performed for calls on library-level subprograms declared
+ within a preelaborated package. This is true also of the
+ Elaboration_Check on task activation for library level task
+ types declared in a preelaborated package. However, it is not
+ true of the Elaboration_Check on instantiations.
+
+1.d
+ A static expression should never prevent a library unit from
+ being preelaborable.
+
+ _Syntax_
+
+2
+ The form of a pragma Preelaborate is as follows:
+
+3
+ pragma Preelaborate[(library_unit_name)];
+
+4
+ A pragma Preelaborate is a library unit pragma.
+
+4.1/2
+ {AI95-00161-01AI95-00161-01} The form of a pragma
+ Preelaborable_Initialization is as follows:
+
+4.2/2
+ pragma Preelaborable_Initialization(direct_name);
+
+ _Legality Rules_
+
+5
+An elaborable construct is preelaborable unless its elaboration performs
+any of the following actions:
+
+5.a
+ Ramification: A preelaborable construct can be elaborated
+ without using any information that is available only at run
+ time. Note that we don't try to prevent exceptions in
+ preelaborable constructs; if the implementation wishes to
+ generate code to raise an exception, that's OK.
+
+5.b
+ Because there is no flow of control and there are no calls
+ (other than to predefined subprograms), these run-time
+ properties can actually be detected at compile time. This is
+ necessary in order to require compile-time enforcement of the
+ rules.
+
+6
+ * The execution of a statement other than a null_statement.
+
+6.a
+ Ramification: A preelaborable construct can contain labels and
+ null_statements.
+
+7
+ * A call to a subprogram other than a static function.
+
+8
+ * The evaluation of a primary that is a name of an object, unless the
+ name is a static expression, or statically denotes a discriminant
+ of an enclosing type.
+
+8.a
+ Ramification: One can evaluate such a name, but not as a
+ primary. For example, one can evaluate an attribute of the
+ object. One can evaluate an attribute_reference, so long as
+ it does not denote an object, and its prefix does not disobey
+ any of these rules. For example, Obj'Access,
+ Obj'Unchecked_Access, and Obj'Address are generally legal in
+ preelaborated library units.
+
+9/3
+ * {AI95-00161-01AI95-00161-01} {AI05-0028-1AI05-0028-1} The creation
+ of an object [(including a component)] that is initialized by
+ default, if its type does not have preelaborable initialization.
+ Similarly, the evaluation of an extension_aggregate (*note 4.3.2:
+ S0111.) with an ancestor subtype_mark (*note 3.2.2: S0028.)
+ denoting a subtype of such a type.
+
+9.a
+ Ramification: One can declare these kinds of types, but one
+ cannot create objects of those types.
+
+9.b
+ It is also nonpreelaborable to create an object if that will
+ cause the evaluation of a default expression that will call a
+ user-defined function. This follows from the rule above
+ forbidding nonnull statements.
+
+9.c/2
+ This paragraph was deleted.{AI95-00161-01AI95-00161-01}
+
+10/2
+{AI95-00403-01AI95-00403-01} A generic body is preelaborable only if
+elaboration of a corresponding instance body would not perform any such
+actions, presuming that:
+
+10.1/3
+ * {AI95-00403-01AI95-00403-01} {AI95-0028-1AI95-0028-1} the actual
+ for each discriminated formal derived type, formal private type, or
+ formal private extension declared within the formal part of the
+ generic unit is a type that does not have preelaborable
+ initialization, unless pragma Preelaborable_Initialization has been
+ applied to the formal type;
+
+10.2/2
+ * {AI95-00403-01AI95-00403-01} the actual for each formal type is
+ nonstatic;
+
+10.3/2
+ * {AI95-00403-01AI95-00403-01} the actual for each formal object is
+ nonstatic; and
+
+10.4/2
+ * {AI95-00403-01AI95-00403-01} the actual for each formal subprogram
+ is a user-defined subprogram.
+
+10.a.1/2
+ Discussion: {AI95-00403-01AI95-00403-01} This is an
+ "assume-the-worst" rule. The elaboration of a generic unit
+ doesn't perform any of the actions listed above, because its
+ sole effect is to establish that the generic can from now on
+ be instantiated. So the elaboration of the generic itself is
+ not the interesting part when it comes to preelaboration
+ rules. The interesting part is what happens when you
+ elaborate "any instantiation" of the generic. For instance,
+ declaring an object of a limited formal private type might
+ well start tasks, call functions, and do all sorts of
+ nonpreelaborable things. We prevent these situations by
+ assuming that the actual parameters are as badly behaved as
+ possible.
+
+10.a
+ Reason: Without this rule about generics, we would have to
+ forbid instantiations in preelaborated library units, which
+ would significantly reduce their usefulness.
+
+11/3
+{8652/00358652/0035} {AI95-00002-01AI95-00002-01}
+{AI05-0034-1AI05-0034-1} {AI05-0243-1AI05-0243-1} A pragma Preelaborate
+(or pragma Pure -- see below) is used to specify that a library unit is
+preelaborated, namely that the Preelaborate aspect of the library unit
+is True; all compilation units of the library unit are preelaborated.
+The declaration and body of a preelaborated library unit, and all
+subunits that are elaborated as part of elaborating the library unit,
+shall be preelaborable. All compilation units of a preelaborated
+library unit shall depend semantically only on declared pure or
+preelaborated library_items. In addition to the places where Legality
+Rules normally apply (see *note 12.3::), these rules also apply in the
+private part of an instance of a generic unit. [ If a library unit is
+preelaborated, then its declaration, if any, and body, if any, are
+elaborated prior to all nonpreelaborated library_items of the
+partition.]
+
+11.a
+ Ramification: In a generic body, we assume the worst about
+ formal private types and extensions.
+
+11.a.1/1
+ {8652/00358652/0035} {AI95-00002-01AI95-00002-01} Subunits of
+ a preelaborated subprogram unit do not need to be
+ preelaborable. This is needed in order to be consistent with
+ units nested in a subprogram body, which do not need to be
+ preelaborable even if the subprogram is preelaborated.
+ However, such subunits cannot depend semantically on
+ nonpreelaborated units, which is also consistent with nested
+ units.
+
+11.b/3
+ Aspect Description for Preelaborate: Code execution during
+ elaboration is avoided for a given package.
+
+11.1/2
+{AI95-00161-01AI95-00161-01} The following rules specify which entities
+have preelaborable initialization:
+
+11.2/3
+ * {AI05-0028-1AI05-0028-1} The partial view of a private type or
+ private extension, a protected type without entry_declarations, a
+ generic formal private type, or a generic formal derived type, has
+ preelaborable initialization if and only if the pragma
+ Preelaborable_Initialization has been applied to them. [A
+ protected type with entry_declarations or a task type never has
+ preelaborable initialization.]
+
+11.3/2
+ * A component (including a discriminant) of a record or protected
+ type has preelaborable initialization if its declaration includes a
+ default_expression whose execution does not perform any actions
+ prohibited in preelaborable constructs as described above, or if
+ its declaration does not include a default expression and its type
+ has preelaborable initialization.
+
+11.4/3
+ * {AI05-0028-1AI05-0028-1} {AI05-0221-1AI05-0221-1} A derived type
+ has preelaborable initialization if its parent type has
+ preelaborable initialization and if the noninherited components all
+ have preelaborable initialization. However, a controlled type with
+ an Initialize procedure that is not a null procedure does not have
+ preelaborable initialization.
+
+11.5/2
+ * {AI95-00161-01AI95-00161-01} {AI95-00345-01AI95-00345-01} A view of
+ a type has preelaborable initialization if it is an elementary
+ type, an array type whose component type has preelaborable
+ initialization, a record type whose components all have
+ preelaborable initialization, or an interface type.
+
+11.6/2
+{AI95-00161-01AI95-00161-01} A pragma Preelaborable_Initialization
+specifies that a type has preelaborable initialization. This pragma
+shall appear in the visible part of a package or generic package.
+
+11.7/3
+{AI95-00161-01AI95-00161-01} {AI95-00345-01AI95-00345-01}
+{AI05-0028-1AI05-0028-1} If the pragma appears in the first list of
+basic_declarative_items of a package_specification, then the direct_name
+shall denote the first subtype of a composite type, and the type shall
+be declared immediately within the same package as the pragma. If the
+pragma is applied to a private type or a private extension, the full
+view of the type shall have preelaborable initialization. If the pragma
+is applied to a protected type, the protected type shall not have
+entries, and each component of the protected type shall have
+preelaborable initialization. For any other composite type, the type
+shall have preelaborable initialization. In addition to the places
+where Legality Rules normally apply (see *note 12.3::), these rules
+apply also in the private part of an instance of a generic unit.
+
+11.c/3
+ Reason: {AI05-0028-1AI05-0028-1} The reason why we need the
+ pragma for private types, private extensions, and protected
+ types is fairly clear: the properties of the full view
+ determine whether the type has preelaborable initialization or
+ not; in order to preserve privacy we need a way to express on
+ the partial view that the full view is well-behaved. The
+ reason why we need the pragma for other composite types is
+ more subtle: a nonnull override for Initialize might occur in
+ the private part, even for a nonprivate type; in order to
+ preserve privacy, we need a way to express on a type declared
+ in a visible part that the private part does not contain any
+ nasty override of Initialize.
+
+11.8/2
+{AI95-00161-01AI95-00161-01} If the pragma appears in a
+generic_formal_part, then the direct_name shall denote a generic formal
+private type or a generic formal derived type declared in the same
+generic_formal_part as the pragma. In a generic_instantiation the
+corresponding actual type shall have preelaborable initialization.
+
+11.d/2
+ Ramification: Not only do protected types with
+ entry_declarations and task types not have preelaborable
+ initialization, but they cannot have pragma
+ Preelaborable_Initialization applied to them.
+
+ _Implementation Advice_
+
+12
+In an implementation, a type declared in a preelaborated package should
+have the same representation in every elaboration of a given version of
+the package, whether the elaborations occur in distinct executions of
+the same program, or in executions of distinct programs or partitions
+that include the given version.
+
+12.a/2
+ Implementation Advice: A type declared in a preelaborated
+ package should have the same representation in every
+ elaboration of a given version of the package.
+
+ _Syntax_
+
+13
+ The form of a pragma Pure is as follows:
+
+14
+ pragma Pure[(library_unit_name)];
+
+15
+ A pragma Pure is a library unit pragma.
+
+ _Static Semantics_
+
+15.1/3
+{AI95-00366-01AI95-00366-01} {AI05-0035-1AI05-0035-1} A pure compilation
+unit is a preelaborable compilation unit whose elaboration does not
+perform any of the following actions:
+
+15.2/2
+ * the elaboration of a variable declaration;
+
+15.3/2
+ * the evaluation of an allocator of an access-to-variable type; for
+ the purposes of this rule, the partial view of a type is presumed
+ to have nonvisible components whose default initialization
+ evaluates such an allocator;
+
+15.a.1/3
+ Reason: {AI05-0004-1AI05-0004-1} Such an allocator would
+ provide a backdoor way to get a global variable into a pure
+ unit, so it is prohibited. Most such allocators are illegal
+ anyway, as their type is required to have Storage_Size = 0
+ (see the next two rules). But access parameters and access
+ discriminants don't necessarily disallow allocators. However,
+ a call is also illegal here (by the preelaboration rules), so
+ access parameters cannot cause trouble. So this rule is
+ really about prohibiting allocators in discriminant
+ constraints:
+
+15.a.2/3
+ type Rec (Acc : access Integer) is record
+ C : Character;
+ end record;
+
+15.a.3/3
+ Not_Const : constant Rec (Acc => new Integer'(2)); -- Illegal in a pure unit.
+
+15.a/3
+ {AI05-0004-1AI05-0004-1} The second half of the rule is needed
+ because aggregates can specify the default initialization of a
+ private type or extension using <> or the ancestor subtype of
+ an extension aggregate. The subtype of a component could use
+ an allocator to initialize an access discriminant; the type
+ still could have a pragma Preelaborable_Initialization given.
+ Ada 95 did not allow such private types to have preelaborable
+ initialization, so such a default initialization could not
+ have occurred. Thus this rule is not incompatible with Ada
+ 95.
+
+15.4/3
+ * {AI05-0035-1AI05-0035-1} the elaboration of the declaration of a
+ nonderived named access-to-variable type unless the Storage_Size of
+ the type has been specified by a static expression with value zero
+ or is defined by the language to be zero;
+
+15.b/2
+ Discussion: A remote access-to-class-wide type (see *note
+ E.2.2::) has its Storage_Size defined to be zero.
+
+15.c/2
+ Reason: {AI95-00366-01AI95-00366-01} We disallow most named
+ access-to-object types because an allocator has a side effect;
+ the pool constitutes variable data. We allow
+ access-to-subprogram types because they don't have allocators.
+ We even allow named access-to-object types if they have an
+ empty predefined pool (they can't have a user-defined pool as
+ System.Storage_Pools is not pure). In this case, most
+ attempts to use an allocator are illegal, and any others (in a
+ generic body) will raise Storage_Error.
+
+15.5/3
+ * {AI05-0035-1AI05-0035-1} the elaboration of the declaration of a
+ nonderived named access-to-constant type for which the Storage_Size
+ has been specified by an expression other than a static expression
+ with value zero.
+
+15.d/2
+ Discussion: We allow access-to-constant types so long as there
+ is no user-specified nonzero Storage_Size; if there were a
+ user-specified nonzero Storage_Size restricting the size of
+ the storage pool, allocators would be problematic since the
+ package is supposedly 'stateless', and the allocated size
+ count for the storage pool would represent state.
+
+15.6/3
+{AI05-0035-1AI05-0035-1} A generic body is pure only if elaboration of a
+corresponding instance body would not perform any such actions presuming
+any composite formal types have nonvisible components whose default
+initialization evaluates an allocator of an access-to-variable type.
+
+15.7/2
+{AI95-00366-01AI95-00366-01} The Storage_Size for an anonymous
+access-to-variable type declared at library level in a library unit that
+is declared pure is defined to be zero.
+
+15.e/2
+ Ramification: This makes allocators illegal for such types
+ (see *note 4.8::), making a storage pool unnecessary for these
+ types. A storage pool would represent state.
+
+15.f/2
+ Note that access discriminants and access parameters are never
+ library-level, even when they are declared in a type or
+ subprogram declared at library-level. That's because they
+ have their own special accessibility rules (see *note
+ 3.10.2::).
+
+ _Legality Rules_
+
+16/2
+This paragraph was deleted.{AI95-00366-01AI95-00366-01}
+
+17/3
+{AI95-00366-01AI95-00366-01} {AI05-0034-1AI05-0034-1}
+{AI05-0035-1AI05-0035-1} {AI05-0243-1AI05-0243-1} A pragma Pure is used
+to specify that a library unit is declared pure, namely that the Pure
+aspect of the library unit is True; all compilation units of the library
+unit are declared pure. In addition, the limited view of any library
+package is declared pure. The declaration and body of a declared pure
+library unit, and all subunits that are elaborated as part of
+elaborating the library unit, shall be pure. All compilation units of a
+declared pure library unit shall depend semantically only on declared
+pure library_items. In addition to the places where Legality Rules
+normally apply (see *note 12.3::), these rules also apply in the private
+part of an instance of a generic unit. Furthermore, the full view of
+any partial view declared in the visible part of a declared pure library
+unit that has any available stream attributes shall support external
+streaming (see *note 13.13.2::).
+
+17.a/3
+ This paragraph was deleted.{AI05-0243-1AI05-0243-1}
+
+17.b
+ Discussion: A declared-pure package is useful for defining
+ types to be shared between partitions with no common address
+ space.
+
+17.c
+ Reason: Note that generic packages are not mentioned in the
+ list of things that can contain variable declarations. Note
+ that the Ada 95 rules for deferred constants make them
+ allowable in library units that are declared pure; that isn't
+ true of Ada 83's deferred constants.
+
+17.d/2
+ Ramification: {AI95-00366-01AI95-00366-01} Anonymous access
+ types are allowed.
+
+17.d.1/3
+ {AI05-0243-1AI05-0243-1} A limited view is not a library unit,
+ so any rule that starts "declared pure library unit" does not
+ apply to a limited view. In particular, the 3rd and last
+ sentences never apply to limited views. However, a limited
+ view is a library_item, so rules that discuss "declared pure
+ library_items" do include limited views.
+
+17.e/2
+ Reason: {AI95-00366-01AI95-00366-01} Ada 95 didn't allow any
+ access types as these (including access-to-subprogram types)
+ cause trouble for *note Annex E::, "*note Annex E::
+ Distributed Systems", because such types allow access values
+ in a shared passive partition to designate objects in an
+ active partition, thus allowing inter-address space
+ references. We decided to disallow such uses in the
+ relatively rare cases where they cause problems, rather than
+ making life harder for the majority of users. Types declared
+ in a pure package can be used in remote operations only if
+ they are externally streamable. That simply means that there
+ is a means to transport values of the type; that's
+ automatically true for nonlimited types that don't have an
+ access part. The only tricky part about this is to avoid
+ privacy leakage; that was handled by ensuring that any private
+ types (and private extensions) declared in a pure package that
+ have available stream attributes (which include all nonlimited
+ types by definition) have to be externally streamable.
+
+17.f/3
+ Aspect Description for Pure: Side effects are avoided in the
+ subprograms of a given package.
+
+ _Implementation Permissions_
+
+18/3
+{AI95-00366-01AI95-00366-01} {AI05-0219-1AI05-0219-1} If a library unit
+is declared pure, then the implementation is permitted to omit a call on
+a library-level subprogram of the library unit if the results are not
+needed after the call. In addition, the implementation may omit a call
+on such a subprogram and simply reuse the results produced by an earlier
+call on the same subprogram, provided that none of the parameters nor
+any object accessible via access values from the parameters have any
+part that is of a type whose full type is an immutably limited type, and
+the addresses and values of all by-reference actual parameters, the
+values of all by-copy-in actual parameters, and the values of all
+objects accessible via access values from the parameters, are the same
+as they were at the earlier call. [This permission applies even if the
+subprogram produces other side effects when called.]
+
+18.a/3
+ Discussion: {AI95-00366-01AI95-00366-01}
+ {AI05-0005-1AI05-0005-1} {AI05-0299-1AI05-0299-1} A
+ declared-pure library_item has no variable state. Hence, a
+ call on one of its (nonnested) subprograms cannot normally
+ have side effects. Side effects are still possible via
+ dispatching calls and via indirect calls through
+ access-to-subprogram values. Other mechanisms that might be
+ used to modify variable state include machine code insertions,
+ imported subprograms, and unchecked conversion to an access
+ type declared within the subprogram; this list is not
+ exhaustive. Thus, the permissions described in this subclause
+ may apply to a subprogram whose execution has side effects.
+ The compiler may omit a call to such a subprogram even if side
+ effects exist, so the writer of such a subprogram has to keep
+ this in mind.
+
+ _Syntax_
+
+19
+ The form of a pragma Elaborate, Elaborate_All, or Elaborate_Body is
+ as follows:
+
+20
+ pragma Elaborate(library_unit_name{, library_unit_name});
+
+21
+ pragma Elaborate_All(library_unit_name{, library_unit_name});
+
+22
+ pragma Elaborate_Body[(library_unit_name)];
+
+23
+ A pragma Elaborate or Elaborate_All is only allowed within a
+ context_clause.
+
+23.a
+ Ramification: "Within a context_clause" allows it to be the
+ last item in the context_clause. It can't be first, because
+ the name has to denote something mentioned earlier.
+
+24
+ A pragma Elaborate_Body is a library unit pragma.
+
+24.a
+ Discussion: Hence, a pragma Elaborate or Elaborate_All is not
+ elaborated, not that it makes any practical difference.
+
+24.b
+ Note that a pragma Elaborate or Elaborate_All is neither a
+ program unit pragma, nor a library unit pragma.
+
+ _Legality Rules_
+
+25/3
+{AI05-0229-1AI05-0229-1} If the aspect Elaborate_Body is True for a
+declaration [(including when pragma Elaborate_Body applies)], then the
+declaration requires a completion [(a body)].
+
+25.a/3
+ Proof: {AI05-0229-1AI05-0229-1} Pragma Elaborate_Body sets the
+ aspect (see below).
+
+25.1/2
+{AI95-00217-06AI95-00217-06} The library_unit_name of a pragma Elaborate
+or Elaborate_All shall denote a nonlimited view of a library unit.
+
+25.b/2
+ Reason: These pragmas are intended to prevent elaboration
+ check failures. But a limited view does not make anything
+ visible that has an elaboration check, so the pragmas cannot
+ do anything useful. Moreover, the pragmas would probably
+ reintroduce the circularity that the limited_with_clause was
+ intended to break. So we make such uses illegal.
+
+ _Static Semantics_
+
+26/3
+{AI05-0229-1AI05-0229-1} [A pragma Elaborate specifies that the body of
+the named library unit is elaborated before the current library_item. A
+pragma Elaborate_All specifies that each library_item that is needed by
+the named library unit declaration is elaborated before the current
+library_item.]
+
+26.a
+ Proof: The official statement of the semantics of these
+ pragmas is given in *note 10.2::.
+
+26.1/3
+{AI05-0229-1AI05-0229-1} A pragma Elaborate_Body sets the Elaborate_Body
+representation aspect of the library unit to which it applies to the
+value True. [If the Elaborate_Body aspect of a library unit is True,
+the body of the library unit is elaborated immediately after its
+declaration.]
+
+26.a.1/3
+ Proof: The official statement of the semantics of this aspect
+ is given in *note 10.2::.
+
+26.b
+ Implementation Note: The presence of a pragma Elaborate_Body
+ simplifies the removal of unnecessary Elaboration_Checks. For
+ a subprogram declared immediately within a library unit to
+ which a pragma Elaborate_Body applies, the only calls that can
+ fail the Elaboration_Check are those that occur in the library
+ unit itself, between the declaration and body of the called
+ subprogram; if there are no such calls (which can easily be
+ detected at compile time if there are no stubs), then no
+ Elaboration_Checks are needed for that subprogram. The same
+ is true for Elaboration_Checks on task activations and
+ instantiations, and for library subprograms and generic units.
+
+26.c
+ Ramification: The fact that the unit of elaboration is the
+ library_item means that if a subprogram_body is not a
+ completion, it is impossible for any library_item to be
+ elaborated between the declaration and the body of such a
+ subprogram. Therefore, it is impossible for a call to such a
+ subprogram to fail its Elaboration_Check.
+
+26.d
+ Discussion: The visibility rules imply that each
+ library_unit_name of a pragma Elaborate or Elaborate_All has
+ to denote a library unit mentioned by a previous with_clause
+ of the same context_clause.
+
+26.e/3
+ Aspect Description for Elaborate_Body: A given package must
+ have a body, and that body is elaborated immediately after the
+ declaration.
+
+ NOTES
+
+27
+ 12 A preelaborated library unit is allowed to have
+ nonpreelaborable children.
+
+27.a/1
+ Ramification: {8652/00358652/0035}
+ {AI95-00002-01AI95-00002-01} But generally not
+ nonpreelaborated subunits. (Nonpreelaborated subunits of
+ subprograms are allowed as discussed above.)
+
+28
+ 13 A library unit that is declared pure is allowed to have impure
+ children.
+
+28.a/1
+ Ramification: {8652/00358652/0035}
+ {AI95-00002-01AI95-00002-01} But generally not impure
+ subunits. (Impure subunits of subprograms are allowed as
+ discussed above.)
+
+28.b
+ Ramification: Pragma Elaborate is mainly for closely related
+ library units, such as when two package bodies 'with' each
+ other's declarations. In such cases, Elaborate_All sometimes
+ won't work.
+
+ _Extensions to Ada 83_
+
+28.c
+ The concepts of preelaborability and purity are new to Ada 95.
+ The Elaborate_All, Elaborate_Body, Preelaborate, and Pure
+ pragmas are new to Ada 95.
+
+28.d
+ Pragmas Elaborate are allowed to be mixed in with the other
+ things in the context_clause -- in Ada 83, they were required
+ to appear last.
+
+ _Incompatibilities With Ada 95_
+
+28.e/2
+ {AI95-00366-01AI95-00366-01} The requirement that a partial
+ view with available stream attributes be externally streamable
+ can cause an incompatibility in rare cases. If there is a
+ limited tagged type declared in a pure package with available
+ attributes, and that type is used to declare a private
+ extension in another pure package, and the full type for the
+ private extension has a component of an explicitly limited
+ record type, a protected type, or a type with access
+ discriminants, then the stream attributes will have to be
+ user-specified in the visible part of the package. That is
+ not a requirement for Ada 95, but this combination seems very
+ unlikely in pure packages. Note that this cannot be an
+ incompatibility for a nonlimited type, as all of the types
+ that are allowed in Ada 95 that would require explicitly
+ defined stream attributes are limited (and thus cannot be used
+ as components in a nonlimited type).
+
+28.f/2
+ {AI95-00403-01AI95-00403-01} Amendment Correction: Added
+ wording to cover missing cases for preelaborated generic
+ units. This is incompatible as a preelaborated unit could
+ have used a formal object to initialize a library-level
+ object; that isn't allowed in Ada 2005. But such a unit
+ wouldn't really be preelaborable, and Ada 95 compilers can
+ reject such units (as this is a Binding Interpretation), so
+ such units should be very rare.
+
+ _Extensions to Ada 95_
+
+28.g/2
+ {AI95-00161-01AI95-00161-01} Amendment Correction: The concept
+ of preelaborable initialization and pragma
+ Preelaborable_Initialization are new. These allow more types
+ of objects to be created in preelaborable units, and fix holes
+ in the old rules.
+
+28.h/2
+ {AI95-00366-01AI95-00366-01} Access-to-subprogram types and
+ access-to-object types with a Storage_Size of 0 are allowed in
+ pure units. The permission to omit calls was adjusted
+ accordingly (which also fixes a hole in Ada 95, as access
+ parameters are allowed, and changes in the values accessed by
+ them must be taken into account).
+
+ _Wording Changes from Ada 95_
+
+28.i/2
+ {AI95-00002-01AI95-00002-01} Corrigendum: The wording was
+ changed so that subunits of a preelaborated subprogram are
+ also preelaborated.
+
+28.j/2
+ {AI95-00217-06AI95-00217-06} Disallowed pragma Elaborate and
+ Elaborate_All for packages that are mentioned in a
+ limited_with_clause.
+
+ _Incompatibilities With Ada 2005_
+
+28.k/3
+ {AI05-0028-1AI05-0028-1} Correction: Corrected a serious
+ unintended incompatibility with Ada 95 in the new
+ preelaboration wording -- explicit initialization of objects
+ of types that don't have preelaborable initialization was not
+ allowed. Ada 2012 switches back to the Ada 95 rule in these
+ cases. This is unlikely to occur in practice, as it is
+ unlikely that a compiler would have implemented the more
+ restrictive rule (it would fail many ACATS tests if it did).
+
+28.l/3
+ {AI05-0035-1AI05-0035-1} Correction: Added an assume-the-worst
+ rule for generic bodies (else they would never be checked for
+ purity) and added the boilerplate so that the entire generic
+ specification is rechecked. Also fixed wording to have
+ consistent handling for subunits for Pure and Preelaborate.
+ An Ada 95 program could have depended on marking a generic
+ pure that was not really pure, although this would defeat the
+ purpose of the categorization and likely cause problems with
+ distributed programs.
+
+ _Extensions to Ada 2005_
+
+28.m/3
+ {AI05-0035-1AI05-0035-1} Correction: Adjusted wording so that
+ a subunit can be pure (it is not a library_item, but it is a
+ compilation unit).
+
+28.n/3
+ {AI05-0035-1AI05-0035-1} Correction: Adjusted wording so that
+ the rules for access types only apply to nonderived types
+ (derived types share their storage pool with their parent, so
+ if the parent access type is legal, so is any derived type.)
+
+28.o/3
+ {AI05-0229-1AI05-0229-1} Elaborate_Body is now an aspect, so
+ it can be specified by an aspect_specification -- although the
+ pragma is still preferred by the Standard.
+
+28.p/3
+ {AI05-0243-1AI05-0243-1} Pure and Preelaborate are now
+ aspects, so they can be specified by an aspect_specification
+ -- although the pragmas are still preferred by the Standard.
+
+ _Wording Changes from Ada 2005_
+
+28.q/3
+ {AI05-0034-1AI05-0034-1} Correction: Added wording so that a
+ limited view is always treated as pure, no matter what
+ categorization is used for the originating unit. This was
+ undefined in Ada 2005.
+
+28.r/3
+ {AI05-0028-1AI05-0028-1} {AI05-0221-1AI05-0221-1} Correction:
+ Fixed minor issues with preelaborable initialization (PI):
+ null Initialize procedures do not make a type non-PI; formal
+ types with pragma PI can be assumed to have PI; formal
+ extensions are assumed to not have PI; all composite types can
+ have pragma PI (so that the possibility of hidden Initialize
+ routines can be handled); added discriminants of a derived
+ type are not considered in calculating PI.
+
+28.s/3
+ {AI05-0219-1AI05-0219-1} Correction: Clarified that the
+ implementation permission to omit pure subprogram calls does
+ not apply if any part of the parameters or any designated
+ object has a part that is immutably limited. The old wording
+ just said "limited type", which can change via visibility and
+ thus isn't appropriate for dynamic semantics permissions.
+
+\1f
+File: aarm2012.info, Node: 11, Next: 12, Prev: 10, Up: Top
+
+11 Exceptions
+*************
+
+1/3
+{AI05-0299-1AI05-0299-1} [This clause defines the facilities for dealing
+with errors or other exceptional situations that arise during program
+execution.] An exception represents a kind of exceptional situation; an
+occurrence of such a situation (at run time) is called an exception
+occurrence. [ To raise an exception is to abandon normal program
+execution so as to draw attention to the fact that the corresponding
+situation has arisen. Performing some actions in response to the
+arising of an exception is called handling the exception. ]
+
+1.a
+ To be honest: ...or handling the exception occurrence.
+
+1.b
+ Ramification: For example, an exception End_Error might
+ represent error situations in which an attempt is made to read
+ beyond end-of-file. During the execution of a partition,
+ there might be numerous occurrences of this exception.
+
+1.c
+ To be honest: When the meaning is clear from the context, we
+ sometimes use "occurrence" as a short-hand for "exception
+ occurrence."
+
+2/3
+{AI05-0043-1AI05-0043-1} {AI05-0258-1AI05-0258-1} [An
+exception_declaration declares a name for an exception. An exception
+can be raised explicitly (for example, by a raise_statement) or
+implicitly (for example, by the failure of a language-defined check).
+When an exception arises, control can be transferred to a user-provided
+exception_handler at the end of a handled_sequence_of_statements (*note
+11.2: S0265.), or it can be propagated to a dynamically enclosing
+execution.]
+
+ _Wording Changes from Ada 83_
+
+2.a
+ We are more explicit about the difference between an exception
+ and an occurrence of an exception. This is necessary because
+ we now have a type (Exception_Occurrence) that represents
+ exception occurrences, so the program can manipulate them.
+ Furthermore, we say that when an exception is propagated, it
+ is the same occurrence that is being propagated (as opposed to
+ a new occurrence of the same exception). The same issue
+ applies to a re-raise statement. In order to understand these
+ semantics, we have to make this distinction.
+
+ _Wording Changes from Ada 2005_
+
+2.b/3
+ {AI05-0043-1AI05-0043-1} Correction: Generalized the
+ introductory description of how an exception can be raised so
+ that it does not appear to cover all of the cases.
+
+* Menu:
+
+* 11.1 :: Exception Declarations
+* 11.2 :: Exception Handlers
+* 11.3 :: Raise Statements
+* 11.4 :: Exception Handling
+* 11.5 :: Suppressing Checks
+* 11.6 :: Exceptions and Optimization
+
+\1f
+File: aarm2012.info, Node: 11.1, Next: 11.2, Up: 11
+
+11.1 Exception Declarations
+===========================
+
+1
+An exception_declaration declares a name for an exception.
+
+ _Syntax_
+
+2/3
+ {AI05-0183-1AI05-0183-1} exception_declaration ::=
+ defining_identifier_list : exception
+ [aspect_specification];
+
+ _Static Semantics_
+
+3
+Each single exception_declaration declares a name for a different
+exception. If a generic unit includes an exception_declaration, the
+exception_declarations implicitly generated by different instantiations
+of the generic unit refer to distinct exceptions (but all have the same
+defining_identifier). The particular exception denoted by an exception
+name is determined at compilation time and is the same regardless of how
+many times the exception_declaration is elaborated.
+
+3.a
+ Reason: We considered removing this requirement inside generic
+ bodies, because it is an implementation burden for
+ implementations that wish to share code among several
+ instances. In the end, it was decided that it would introduce
+ too much implementation dependence.
+
+3.b
+ Ramification: Hence, if an exception_declaration occurs in a
+ recursive subprogram, the exception name denotes the same
+ exception for all invocations of the recursive subprogram.
+ The reason for this rule is that we allow an exception
+ occurrence to propagate out of its declaration's innermost
+ containing master; if exceptions were created by their
+ declarations like other entities, they would presumably be
+ destroyed upon leaving the master; we would have to do
+ something special to prevent them from propagating to places
+ where they no longer exist.
+
+3.c
+ Ramification: Exception identities are unique across all
+ partitions of a program.
+
+4
+The predefined exceptions are the ones declared in the declaration of
+package Standard: Constraint_Error, Program_Error, Storage_Error, and
+Tasking_Error[; one of them is raised when a language-defined check
+fails.]
+
+4.a
+ Ramification: The exceptions declared in the language-defined
+ package IO_Exceptions, for example, are not predefined.
+
+ _Dynamic Semantics_
+
+5
+The elaboration of an exception_declaration has no effect.
+
+6
+The execution of any construct raises Storage_Error if there is
+insufficient storage for that execution. The amount of storage needed
+for the execution of constructs is unspecified.
+
+6.a
+ Ramification: Note that any execution whatsoever can raise
+ Storage_Error. This allows much implementation freedom in
+ storage management.
+
+ _Examples_
+
+7
+Examples of user-defined exception declarations:
+
+8
+ Singular : exception;
+ Error : exception;
+ Overflow, Underflow : exception;
+
+ _Inconsistencies With Ada 83_
+
+8.a
+ The exception Numeric_Error is now defined in the Obsolescent
+ features Annex, as a rename of Constraint_Error. All checks
+ that raise Numeric_Error in Ada 83 instead raise
+ Constraint_Error in Ada 95. To increase upward compatibility,
+ we also changed the rules to allow the same exception to be
+ named more than once by a given handler. Thus, "when
+ Constraint_Error | Numeric_Error =>" will remain legal in Ada
+ 95, even though Constraint_Error and Numeric_Error now denote
+ the same exception. However, it will not be legal to have
+ separate handlers for Constraint_Error and Numeric_Error.
+ This change is inconsistent in the rare case that an existing
+ program explicitly raises Numeric_Error at a point where there
+ is a handler for Constraint_Error; the exception will now be
+ caught by that handler.
+
+ _Wording Changes from Ada 83_
+
+8.b
+ We explicitly define elaboration for exception_declarations.
+
+ _Extensions to Ada 2005_
+
+8.c/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a exception_declaration. This is described in
+ *note 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 11.2, Next: 11.3, Prev: 11.1, Up: 11
+
+11.2 Exception Handlers
+=======================
+
+1
+[The response to one or more exceptions is specified by an
+exception_handler.]
+
+ _Syntax_
+
+2
+ handled_sequence_of_statements ::=
+ sequence_of_statements
+ [exception
+ exception_handler
+ {exception_handler}]
+
+3
+ exception_handler ::=
+ when [choice_parameter_specification:] exception_choice {|
+ exception_choice} =>
+ sequence_of_statements
+
+4
+ choice_parameter_specification ::= defining_identifier
+
+5
+ exception_choice ::= exception_name | others
+
+5.a
+ To be honest: "Handler" is an abbreviation for
+ "exception_handler."
+
+5.b/3
+ {AI05-0299-1AI05-0299-1} Within this clause, we sometimes
+ abbreviate "exception_choice" to "choice."
+
+ _Legality Rules_
+
+6
+A choice with an exception_name covers the named exception. A choice
+with others covers all exceptions not named by previous choices of the
+same handled_sequence_of_statements (*note 11.2: S0265.). Two choices
+in different exception_handlers of the same
+handled_sequence_of_statements (*note 11.2: S0265.) shall not cover the
+same exception.
+
+6.a
+ Ramification: Two exception_choices of the same
+ exception_handler may cover the same exception. For example,
+ given two renaming declarations in separate packages for the
+ same exception, one may nevertheless write, for example, "when
+ Ada.Text_IO.Data_Error | My_Seq_IO.Data_Error =>".
+
+6.b
+ An others choice even covers exceptions that are not visible
+ at the place of the handler. Since exception raising is a
+ dynamic activity, it is entirely possible for an others
+ handler to handle an exception that it could not have named.
+
+7
+A choice with others is allowed only for the last handler of a
+handled_sequence_of_statements and as the only choice of that handler.
+
+8
+An exception_name of a choice shall not denote an exception declared in
+a generic formal package.
+
+8.a
+ Reason: This is because the compiler doesn't know the identity
+ of such an exception, and thus can't enforce the coverage
+ rules.
+
+ _Static Semantics_
+
+9
+A choice_parameter_specification declares a choice parameter, which is a
+constant object of type Exception_Occurrence (see *note 11.4.1::).
+During the handling of an exception occurrence, the choice parameter, if
+any, of the handler represents the exception occurrence that is being
+handled.
+
+ _Dynamic Semantics_
+
+10
+The execution of a handled_sequence_of_statements consists of the
+execution of the sequence_of_statements (*note 5.1: S0145.). [The
+optional handlers are used to handle any exceptions that are propagated
+by the sequence_of_statements (*note 5.1: S0145.).]
+
+ _Examples_
+
+11
+Example of an exception handler:
+
+12
+ begin
+ Open(File, In_File, "input.txt"); -- see *note A.8.2::
+ exception
+ when E : Name_Error =>
+ Put("Cannot open input file : ");
+ Put_Line(Exception_Message(E)); -- see *note 11.4.1::
+ raise;
+ end;
+
+ _Extensions to Ada 83_
+
+12.a
+ The syntax rule for exception_handler is modified to allow a
+ choice_parameter_specification.
+
+12.b/2
+ {AI95-00114-01AI95-00114-01} Different exception_choices of
+ the same exception_handler may cover the same exception. This
+ allows for "when Numeric_Error | Constraint_Error =>" even
+ though Numeric_Error is a rename of Constraint_Error. This
+ also allows one to "with" two different I/O packages, and then
+ write, for example, "when Ada.Text_IO.Data_Error |
+ My_Seq_IO.Data_Error =>" even though these might both be
+ renames of the same exception.
+
+ _Wording Changes from Ada 83_
+
+12.c
+ The syntax rule for handled_sequence_of_statements is new.
+ These are now used in all the places where handlers are
+ allowed. This obviates the need to explain (in Clauses 5, 6,
+ 7, and 9) what portions of the program are handled by the
+ handlers. Note that there are more such cases in Ada 95.
+
+12.d
+ The syntax rule for choice_parameter_specification is new.
+
+\1f
+File: aarm2012.info, Node: 11.3, Next: 11.4, Prev: 11.2, Up: 11
+
+11.3 Raise Statements
+=====================
+
+1
+[A raise_statement raises an exception.]
+
+ _Syntax_
+
+2/2
+ {AI95-00361-01AI95-00361-01} raise_statement ::= raise;
+ | raise exception_name [with string_expression];
+
+ _Legality Rules_
+
+3
+The name, if any, in a raise_statement shall denote an exception. A
+raise_statement with no exception_name (that is, a re-raise statement)
+shall be within a handler, but not within a body enclosed by that
+handler.
+
+ _Name Resolution Rules_
+
+3.1/2
+{AI95-00361-01AI95-00361-01} The expression, if any, in a
+raise_statement, is expected to be of type String.
+
+ _Dynamic Semantics_
+
+4/2
+{AI95-00361-01AI95-00361-01} To raise an exception is to raise a new
+occurrence of that exception[, as explained in *note 11.4::]. For the
+execution of a raise_statement with an exception_name, the named
+exception is raised. [If a string_expression is present, the expression
+is evaluated and its value is associated with the exception occurrence.]
+For the execution of a re-raise statement, the exception occurrence that
+caused transfer of control to the innermost enclosing handler is raised
+[again].
+
+4.a.1/2
+ Proof: {AI95-00361-01AI95-00361-01} The definition of
+ Exceptions.Exception_Message includes a statement that the
+ string is returned (see *note 11.4.1::). We describe the use
+ of the string here so that we don't have an unexplained
+ parameter in this subclause.
+
+4.a
+ Implementation Note: For a re-raise statement, the
+ implementation does not create a new Exception_Occurrence, but
+ instead propagates the same Exception_Occurrence value. This
+ allows the original cause of the exception to be determined.
+
+ _Examples_
+
+5
+Examples of raise statements:
+
+6/2
+ {AI95-00433-01AI95-00433-01} raise Ada.IO_Exceptions.Name_Error; -- see *note A.13::
+ raise Queue_Error with "Buffer Full"; -- see *note 9.11::
+
+7
+ raise; -- re-raise the current exception
+
+ _Wording Changes from Ada 83_
+
+7.a
+ The fact that the name in a raise_statement has to denote an
+ exception is not clear from RM83. Clearly that was the
+ intent, since the italicized part of the syntax rules so
+ indicate, but there was no explicit rule. RM83-1.5(11)
+ doesn't seem to give the italicized parts of the syntax any
+ force.
+
+ _Extensions to Ada 95_
+
+7.b/2
+ {AI95-00361-01AI95-00361-01} The syntax of a raise_statement
+ is extended to include a string message. This is more
+ convenient than calling Exceptions.Exception_Message
+ (exception_name'Identity, string_expression), and should
+ encourage the use of message strings when raising exceptions.
+
+\1f
+File: aarm2012.info, Node: 11.4, Next: 11.5, Prev: 11.3, Up: 11
+
+11.4 Exception Handling
+=======================
+
+1
+[When an exception occurrence is raised, normal program execution is
+abandoned and control is transferred to an applicable exception_handler,
+if any. To handle an exception occurrence is to respond to the
+exceptional event. To propagate an exception occurrence is to raise it
+again in another context; that is, to fail to respond to the exceptional
+event in the present context.]
+
+1.a
+ Ramification: In other words, if the execution of a given
+ construct raises an exception, but does not handle it, the
+ exception is propagated to an enclosing execution (except in
+ the case of a task_body).
+
+1.b/1
+ Propagation involves re-raising the same exception occurrence.
+ For example, calling an entry of an uncallable task raises
+ Tasking_Error; this is not propagation.
+
+ _Dynamic Semantics_
+
+2
+Within a given task, if the execution of construct a is defined by this
+International Standard to consist (in part) of the execution of
+construct b, then while b is executing, the execution of a is said to
+dynamically enclose the execution of b. The innermost dynamically
+enclosing execution of a given execution is the dynamically enclosing
+execution that started most recently.
+
+2.a
+ To be honest: If the execution of a dynamically encloses that
+ of b, then we also say that the execution of b is included in
+ the execution of a.
+
+2.b
+ Ramification: Examples: The execution of an if_statement
+ dynamically encloses the evaluation of the condition after the
+ if (during that evaluation). (Recall that "execution"
+ includes both "elaboration" and "evaluation", as well as other
+ executions.) The evaluation of a function call dynamically
+ encloses the execution of the sequence_of_statements of the
+ function body (during that execution). Note that, due to
+ recursion, several simultaneous executions of the same
+ construct can be occurring at once during the execution of a
+ particular task.
+
+2.c
+ Dynamically enclosing is not defined across task boundaries; a
+ task's execution does not include the execution of any other
+ tasks.
+
+2.d
+ Dynamically enclosing is only defined for executions that are
+ occurring at a given moment in time; if an if_statement is
+ currently executing the sequence_of_statements after then,
+ then the evaluation of the condition is no longer dynamically
+ enclosed by the execution of the if_statement (or anything
+ else).
+
+3
+When an exception occurrence is raised by the execution of a given
+construct, the rest of the execution of that construct is abandoned;
+that is, any portions of the execution that have not yet taken place are
+not performed. The construct is first completed, and then left, as
+explained in *note 7.6.1::. Then:
+
+4
+ * If the construct is a task_body, the exception does not propagate
+ further;
+
+4.a
+ Ramification: When an exception is raised by the execution of
+ a task_body, there is no dynamically enclosing execution, so
+ the exception does not propagate any further. If the
+ exception occurred during the activation of the task, then the
+ activator raises Tasking_Error, as explained in *note 9.2::,
+ "*note 9.2:: Task Execution - Task Activation", but we don't
+ define that as propagation; it's a special rule. Otherwise
+ (the exception occurred during the execution of the
+ handled_sequence_of_statements of the task), the task silently
+ disappears. Thus, abnormal termination of tasks is not always
+ considered to be an error.
+
+5
+ * If the construct is the sequence_of_statements of a
+ handled_sequence_of_statements that has a handler with a choice
+ covering the exception, the occurrence is handled by that handler;
+
+6
+ * Otherwise, the occurrence is propagated to the innermost
+ dynamically enclosing execution, which means that the occurrence is
+ raised again in that context.
+
+6.a
+ To be honest: As shorthands, we refer to the propagation of an
+ exception, and the propagation by a construct, if the
+ execution of the construct propagates an exception occurrence.
+
+7
+When an occurrence is handled by a given handler, the
+choice_parameter_specification, if any, is first elaborated, which
+creates the choice parameter and initializes it to the occurrence.
+Then, the sequence_of_statements of the handler is executed; this
+execution replaces the abandoned portion of the execution of the
+sequence_of_statements.
+
+7.a/2
+ Ramification: {AI95-00318-02AI95-00318-02} This "replacement"
+ semantics implies that the handler can do pretty much anything
+ the abandoned sequence could do; for example, in a function,
+ the handler can execute a return statement that applies to the
+ function.
+
+7.b
+ Ramification: The rules for exceptions raised in library
+ units, main subprograms and partitions follow from the normal
+ rules, plus the semantics of the environment task described in
+ Clause *note 10:: (for example, the environment task of a
+ partition elaborates library units and calls the main
+ subprogram). If an exception is propagated by the main
+ subprogram, it is propagated to the environment task, which
+ then terminates abnormally, causing the partition to terminate
+ abnormally. Although abnormal termination of tasks is not
+ necessarily an error, abnormal termination of a partition due
+ to an exception is an error.
+
+ NOTES
+
+8
+ 1 Note that exceptions raised in a declarative_part of a body are
+ not handled by the handlers of the handled_sequence_of_statements
+ (*note 11.2: S0265.) of that body.
+
+* Menu:
+
+* 11.4.1 :: The Package Exceptions
+* 11.4.2 :: Pragmas Assert and Assertion_Policy
+* 11.4.3 :: Example of Exception Handling
+
+\1f
+File: aarm2012.info, Node: 11.4.1, Next: 11.4.2, Up: 11.4
+
+11.4.1 The Package Exceptions
+-----------------------------
+
+ _Static Semantics_
+
+1
+The following language-defined library package exists:
+
+2/2
+ {AI95-00362-01AI95-00362-01} {AI95-00400-01AI95-00400-01} {AI95-00438-01AI95-00438-01} with Ada.Streams;
+ package Ada.Exceptions is
+ pragma Preelaborate(Exceptions);
+ type Exception_Id is private;
+ pragma Preelaborable_Initialization(Exception_Id);
+ Null_Id : constant Exception_Id;
+ function Exception_Name(Id : Exception_Id) return String;
+ function Wide_Exception_Name(Id : Exception_Id) return Wide_String;
+ function Wide_Wide_Exception_Name(Id : Exception_Id)
+ return Wide_Wide_String;
+
+3/2
+ {AI95-00362-01AI95-00362-01} type Exception_Occurrence is limited private;
+ pragma Preelaborable_Initialization(Exception_Occurrence);
+ type Exception_Occurrence_Access is access all Exception_Occurrence;
+ Null_Occurrence : constant Exception_Occurrence;
+
+4/3
+ {AI95-00329-01AI95-00329-01} {AI05-0229-1AI05-0229-1} procedure Raise_Exception(E : in Exception_Id;
+ Message : in String := "")
+ with No_Return;
+ function Exception_Message(X : Exception_Occurrence) return String;
+ procedure Reraise_Occurrence(X : in Exception_Occurrence);
+
+5/2
+ {AI95-00400-01AI95-00400-01} function Exception_Identity(X : Exception_Occurrence)
+ return Exception_Id;
+ function Exception_Name(X : Exception_Occurrence) return String;
+ -- Same as Exception_Name(Exception_Identity(X)).
+ function Wide_Exception_Name(X : Exception_Occurrence)
+ return Wide_String;
+ -- Same as Wide_Exception_Name(Exception_Identity(X)).
+ function Wide_Wide_Exception_Name(X : Exception_Occurrence)
+ return Wide_Wide_String;
+ -- Same as Wide_Wide_Exception_Name(Exception_Identity(X)).
+ function Exception_Information(X : Exception_Occurrence) return String;
+
+6/2
+ {AI95-00438-01AI95-00438-01} procedure Save_Occurrence(Target : out Exception_Occurrence;
+ Source : in Exception_Occurrence);
+ function Save_Occurrence(Source : Exception_Occurrence)
+ return Exception_Occurrence_Access;
+
+6.1/2
+ {AI95-00438-01AI95-00438-01} procedure Read_Exception_Occurrence
+ (Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+ Item : out Exception_Occurrence);
+ procedure Write_Exception_Occurrence
+ (Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+ Item : in Exception_Occurrence);
+
+6.2/2
+ {AI95-00438-01AI95-00438-01} for Exception_Occurrence'Read use Read_Exception_Occurrence;
+ for Exception_Occurrence'Write use Write_Exception_Occurrence;
+
+6.3/2
+ {AI95-00438-01AI95-00438-01} private
+ ... -- not specified by the language
+ end Ada.Exceptions;
+
+7
+Each distinct exception is represented by a distinct value of type
+Exception_Id. Null_Id does not represent any exception, and is the
+default initial value of type Exception_Id. Each occurrence of an
+exception is represented by a value of type Exception_Occurrence.
+Null_Occurrence does not represent any exception occurrence, and is the
+default initial value of type Exception_Occurrence.
+
+8/1
+For a prefix E that denotes an exception, the following attribute is
+defined:
+
+9
+E'Identity
+ E'Identity returns the unique identity of the exception.
+ The type of this attribute is Exception_Id.
+
+9.a
+ Ramification: In a distributed program, the identity is unique
+ across an entire program, not just across a single partition.
+ Exception propagation works properly across RPC's. An
+ exception can be propagated from one partition to another, and
+ then back to the first, where its identity is known.
+
+10/2
+{AI95-00361-01AI95-00361-01} Raise_Exception raises a new occurrence of
+the identified exception.
+
+10.1/3
+{AI95-00361-01AI95-00361-01} {AI95-00378-01AI95-00378-01}
+{AI05-0043-1AI05-0043-1} {AI05-0248-1AI05-0248-1} Exception_Message
+returns the message associated with the given Exception_Occurrence. For
+an occurrence raised by a call to Raise_Exception, the message is the
+Message parameter passed to Raise_Exception. For the occurrence raised
+by a raise_statement with an exception_name and a string_expression, the
+message is the string_expression. For the occurrence raised by a
+raise_statement with an exception_name but without a string_expression,
+the message is a string giving implementation-defined information about
+the exception occurrence. For an occurrence originally raised in some
+other manner (including by the failure of a language-defined check), the
+message is an unspecified string. In all cases, Exception_Message
+returns a string with lower bound 1.
+
+10.a
+ Implementation defined: The information returned by
+ Exception_Message.
+
+10.a.1/3
+ Discussion: {AI05-0043-1AI05-0043-1} There is Implementation
+ Advice about the contents of this string for language-defined
+ checks.
+
+10.b
+ Ramification: Given an exception E, the raise_statement:
+
+10.c
+ raise E;
+
+10.d
+ is equivalent to this call to Raise_Exception:
+
+10.e
+ Raise_Exception(E'Identity, Message => implementation-defined-string);
+
+10.e.1/2
+ {AI95-00361-01AI95-00361-01} Similarly, the raise_statement:
+
+10.e.2/2
+ raise E with "some information";
+
+10.e.3/2
+ is equivalent to this call to Raise_Exception:
+
+10.e.4/2
+ Raise_Exception(E'Identity, Message => "some information");
+
+10.2/2
+{AI95-00361-01AI95-00361-01} Reraise_Occurrence reraises the specified
+exception occurrence.
+
+10.f
+ Ramification: The following handler:
+
+10.g
+ when others =>
+ Cleanup;
+ raise;
+
+10.h
+ is equivalent to this one:
+
+10.i
+ when X : others =>
+ Cleanup;
+ Reraise_Occurrence(X);
+
+11
+Exception_Identity returns the identity of the exception of the
+occurrence.
+
+12/2
+{AI95-00400-01AI95-00400-01} The Wide_Wide_Exception_Name functions
+return the full expanded name of the exception, in upper case, starting
+with a root library unit. For an exception declared immediately within
+package Standard, the defining_identifier (*note 3.1: S0022.) is
+returned. The result is implementation defined if the exception is
+declared within an unnamed block_statement.
+
+12.a
+ Ramification: See the Implementation Permission below.
+
+12.b
+ To be honest: This name, as well as each prefix of it, does
+ not denote a renaming_declaration.
+
+12.c/2
+ Implementation defined: The result of
+ Exceptions.Wide_Wide_Exception_Name for exceptions declared
+ within an unnamed block_statement.
+
+12.d
+ Ramification: Note that we're talking about the name of the
+ exception, not the name of the occurrence.
+
+12.1/2
+{AI95-00400-01AI95-00400-01} The Exception_Name functions (respectively,
+Wide_Exception_Name) return the same sequence of graphic characters as
+that defined for Wide_Wide_Exception_Name, if all the graphic characters
+are defined in Character (respectively, Wide_Character); otherwise, the
+sequence of characters is implementation defined, but no shorter than
+that returned by Wide_Wide_Exception_Name for the same value of the
+argument.
+
+12.e/2
+ Implementation defined: The sequence of characters of the
+ value returned by Exceptions.Exception_Name (respectively,
+ Exceptions.Wide_Exception_Name) when some of the graphic
+ characters of Exceptions.Wide_Wide_Exception_Name are not
+ defined in Character (respectively, Wide_Character).
+
+12.2/2
+{AI95-00378-01AI95-00378-01} {AI95-00417-01AI95-00417-01} The string
+returned by the Exception_Name, Wide_Exception_Name, and
+Wide_Wide_Exception_Name functions has lower bound 1.
+
+13/2
+{AI95-00378-01AI95-00378-01} Exception_Information returns
+implementation-defined information about the exception occurrence. The
+returned string has lower bound 1.
+
+13.a
+ Implementation defined: The information returned by
+ Exception_Information.
+
+14/2
+{AI95-00241-01AI95-00241-01} {AI95-00446-01AI95-00446-01}
+Reraise_Occurrence has no effect in the case of Null_Occurrence.
+Raise_Exception and Exception_Name raise Constraint_Error for a Null_Id.
+Exception_Message, Exception_Name, and Exception_Information raise
+Constraint_Error for a Null_Occurrence. Exception_Identity applied to
+Null_Occurrence returns Null_Id.
+
+14.a.1/2
+ Ramification: {AI95-00241-01AI95-00241-01} Null_Occurrence can
+ be tested for by comparing Exception_Identity(Occurrence) to
+ Null_Id.
+
+14.a.2/2
+ Discussion: {AI95-00446-01AI95-00446-01} Raise_Exception was
+ changed so that it always raises an exception and thus can be
+ a No_Return procedure. A similar change was not made for
+ Reraise_Occurrence, as doing so was determined to be a
+ significant incompatibility. It is not unusual to pass an
+ Exception_Occurrence to other code to delay raising it. If
+ there was no exception, passing Null_Occurrence works fine
+ (nothing is raised). Moreover, as there is no test for
+ Null_Occurrence in Ada 95, this is the only way to write such
+ code without using additional flags. Breaking this sort of
+ code is unacceptable.
+
+15
+The Save_Occurrence procedure copies the Source to the Target. The
+Save_Occurrence function uses an allocator of type
+Exception_Occurrence_Access to create a new object, copies the Source to
+this new object, and returns an access value designating this new
+object; [the result may be deallocated using an instance of
+Unchecked_Deallocation.]
+
+15.a
+ Ramification: It's OK to pass Null_Occurrence to the
+ Save_Occurrence subprograms; they don't raise an exception,
+ but simply save the Null_Occurrence.
+
+15.1/2
+{AI95-00438-01AI95-00438-01} Write_Exception_Occurrence writes a
+representation of an exception occurrence to a stream;
+Read_Exception_Occurrence reconstructs an exception occurrence from a
+stream (including one written in a different partition).
+
+15.b/2
+ Ramification: This routines are used to define the stream
+ attributes (see *note 13.13.2::) for Exception_Occurrence.
+
+15.c/2
+ The identity of the exception, as well as the Exception_Name
+ and Exception_Message, have to be preserved across partitions.
+
+15.d/2
+ The string returned by Exception_Name or Exception_Message on
+ the result of calling the Read attribute on a given stream has
+ to be the same as the value returned by calling the
+ corresponding function on the exception occurrence that was
+ written into the stream with the Write attribute. The string
+ returned by Exception_Information need not be the same, since
+ it is implementation defined anyway.
+
+15.e/2
+ Reason: This is important for supporting writing exception
+ occurrences to external files for post-mortem analysis, as
+ well as propagating exceptions across remote subprogram calls
+ in a distributed system (see *note E.4::).
+
+Paragraph 16 was deleted.
+
+ _Implementation Permissions_
+
+17
+An implementation of Exception_Name in a space-constrained environment
+may return the defining_identifier (*note 3.1: S0022.) instead of the
+full expanded name.
+
+18
+The string returned by Exception_Message may be truncated (to no less
+than 200 characters) by the Save_Occurrence procedure [(not the
+function)], the Reraise_Occurrence procedure, and the re-raise
+statement.
+
+18.a
+ Reason: The reason for allowing truncation is to ease
+ implementations. The reason for choosing the number 200 is
+ that this is the minimum source line length that
+ implementations have to support, and this feature seems
+ vaguely related since it's usually a "one-liner". Note that
+ an implementation is allowed to do this truncation even if it
+ supports arbitrarily long lines.
+
+ _Implementation Advice_
+
+19
+Exception_Message (by default) and Exception_Information should produce
+information useful for debugging. Exception_Message should be short
+(about one line), whereas Exception_Information can be long.
+Exception_Message should not include the Exception_Name.
+Exception_Information should include both the Exception_Name and the
+Exception_Message.
+
+19.a.1/2
+ Implementation Advice: Exception_Information should provide
+ information useful for debugging, and should include the
+ Exception_Name and Exception_Message.
+
+19.a.2/2
+ Implementation Advice: Exception_Message by default should be
+ short, provide information useful for debugging, and should
+ not include the Exception_Name.
+
+19.a
+ Reason: It may seem strange to define two subprograms whose
+ semantics is implementation defined. The idea is that a
+ program can print out debugging/error-logging information in a
+ portable way. The program is portable in the sense that it
+ will work in any implementation; it might print out different
+ information, but the presumption is that the information
+ printed out is appropriate for debugging/error analysis on
+ that system.
+
+19.b
+ Implementation Note: As an example, Exception_Information
+ might include information identifying the location where the
+ exception occurred, and, for predefined exceptions, the
+ specific kind of language-defined check that failed. There is
+ an implementation trade-off here, between how much information
+ is represented in an Exception_Occurrence, and how much can be
+ passed through a re-raise.
+
+19.c
+ The string returned should be in a form suitable for printing
+ to an error log file. This means that it might need to
+ contain line-termination control characters with
+ implementation-defined I/O semantics. The string should
+ neither start nor end with a newline.
+
+19.d
+ If an implementation chooses to provide additional
+ functionality related to exceptions and their occurrences, it
+ should do so by providing one or more children of
+ Ada.Exceptions.
+
+19.e
+ Note that exceptions behave as if declared at library level;
+ there is no "natural scope" for an exception; an exception
+ always exists. Hence, there is no harm in saving an exception
+ occurrence in a data structure, and reraising it later. The
+ reraise has to occur as part of the same program execution, so
+ saving an exception occurrence in a file, reading it back in
+ from a different program execution, and then reraising it is
+ not required to work. This is similar to I/O of access types.
+ Note that it is possible to use RPC to propagate exceptions
+ across partitions.
+
+19.f
+ Here's one way to implement Exception_Occurrence in the
+ private part of the package. Using this method, an
+ implementation need store only the actual number of characters
+ in exception messages. If the user always uses small
+ messages, then exception occurrences can be small. If the
+ user never uses messages, then exception occurrences can be
+ smaller still:
+
+19.g
+ type Exception_Occurrence(Message_Length : Natural := 200) is
+ limited record
+ Id : Exception_Id;
+ Message : String(1..Message_Length);
+ end record;
+
+19.h
+ At the point where an exception is raised, an
+ Exception_Occurrence can be allocated on the stack with
+ exactly the right amount of space for the message -- none for
+ an empty message. This is just like declaring a constrained
+ object of the type:
+
+19.i
+ Temp : Exception_Occurrence(10); -- for a 10-character message
+
+19.j
+ After finding the appropriate handler, the stack can be cut
+ back, and the Temp copied to the right place. This is similar
+ to returning an unknown-sized object from a function. It is
+ not necessary to allocate the maximum possible size for every
+ Exception_Occurrence. If, however, the user declares an
+ Exception_Occurrence object, the discriminant will be
+ permanently set to 200. The Save_Occurrence procedure would
+ then truncate the Exception_Message. Thus, nothing is lost
+ until the user tries to save the occurrence. If the user is
+ willing to pay the cost of heap allocation, the
+ Save_Occurrence function can be used instead.
+
+19.k
+ Note that any arbitrary-sized implementation-defined
+ Exception_Information can be handled in a similar way. For
+ example, if the Exception_Occurrence includes a stack
+ traceback, a discriminant can control the number of stack
+ frames stored. The traceback would be truncated or entirely
+ deleted by the Save_Occurrence procedure -- as the
+ implementation sees fit.
+
+19.l
+ If the internal representation involves pointers to data
+ structures that might disappear, it would behoove the
+ implementation to implement it as a controlled type, so that
+ assignment can either copy the data structures or else null
+ out the pointers. Alternatively, if the data structures being
+ pointed at are in a task control block, the implementation
+ could keep a unique sequence number for each task, so it could
+ tell when a task's data structures no longer exist.
+
+19.m
+ Using the above method, heap space is never allocated unless
+ the user calls the Save_Occurrence function.
+
+19.n
+ An alternative implementation would be to store the message
+ strings on the heap when the exception is raised. (It could
+ be the global heap, or it could be a special heap just for
+ this purpose -- it doesn't matter.) This representation would
+ be used only for choice parameters. For normal user-defined
+ exception occurrences, the Save_Occurrence procedure would
+ copy the message string into the occurrence itself, truncating
+ as necessary. Thus, in this implementation,
+ Exception_Occurrence would be implemented as a variant record:
+
+19.o
+ type Exception_Occurrence_Kind is (Normal, As_Choice_Param);
+
+19.p
+ type Exception_Occurrence(Kind : Exception_Occurrence_Kind := Normal) is
+ limited record
+ case Kind is
+ when Normal =>
+ ... -- space for 200 characters
+ when As_Choice_Param =>
+ ... -- pointer to heap string
+ end case;
+ end record;
+
+19.q
+ Exception_Occurrences created by the run-time system during
+ exception raising would be As_Choice_Param. User-declared
+ ones would be Normal -- the user cannot see the discriminant,
+ and so cannot set it to As_Choice_Param. The strings in the
+ heap would be freed upon completion of the handler.
+
+19.r
+ This alternative implementation corresponds to a heap-based
+ implementation of functions returning unknown-sized results.
+
+19.s
+ One possible implementation of Reraise_Occurrence is as
+ follows:
+
+19.t
+ procedure Reraise_Occurrence(X : in Exception_Occurrence) is
+ begin
+ Raise_Exception(Identity(X), Exception_Message(X));
+ end Reraise_Occurrence;
+
+19.u
+ However, some implementations may wish to retain more
+ information across a re-raise -- a stack traceback, for
+ example.
+
+19.v
+ Ramification: Note that Exception_Occurrence is a definite
+ subtype. Hence, values of type Exception_Occurrence may be
+ written to an error log for later analysis, or may be passed
+ to subprograms for immediate error analysis.
+
+19.w/2
+ This paragraph was deleted.{AI95-00400-01AI95-00400-01}
+
+ _Extensions to Ada 83_
+
+19.x
+ The Identity attribute of exceptions is new, as is the package
+ Exceptions.
+
+ _Inconsistencies With Ada 95_
+
+19.y/2
+ {AI95-00241-01AI95-00241-01} Amendment Correction:
+ Exception_Identity of an Exception_Occurrence now is defined
+ to return Null_Id for Null_Occurrence, rather than raising
+ Constraint_Error. This provides a simple way to test for
+ Null_Occurrence. We expect that programs that need
+ Constraint_Error raised will be very rare; they can be easily
+ fixed by explicitly testing for Null_Id or by using
+ Exception_Name instead.
+
+19.z/2
+ {AI95-00378-01AI95-00378-01} {AI95-00417-01AI95-00417-01}
+ Amendment Correction: We now define the lower bound of the
+ string returned from [[Wide_]Wide_]Exception_Name,
+ Exception_Message, and Exception_Information. This makes
+ working with the returned string easier, and is consistent
+ with many other string-returning functions in Ada. This is
+ technically an inconsistency; if a program depended on some
+ other lower bound for the string returned from one of these
+ functions, it could fail when compiled with Ada 2005. Such
+ code is not portable even between Ada 95 implementations, so
+ it should be very rare.
+
+19.aa/2
+ {AI95-00446-01AI95-00446-01} Amendment Correction:
+ Raise_Exception now raises Constraint_Error if passed Null_Id.
+ This means that it always raises an exception, and thus we can
+ apply pragma No_Return to it. We expect that programs that
+ call Raise_Exception with Null_Id will be rare, and programs
+ that do that and expect no exception to be raised will be
+ rarer; such programs can be easily fixed by explicitly testing
+ for Null_Id before calling Raise_Exception.
+
+ _Incompatibilities With Ada 95_
+
+19.bb/3
+ {AI95-00400-01AI95-00400-01} {AI95-00438-01AI95-00438-01}
+ {AI05-0005-1AI05-0005-1} Functions Wide_Exception_Name and
+ Wide_Wide_Exception_Name, and procedures
+ Read_Exception_Occurrence and Write_Exception_Occurrence are
+ added to Exceptions. If Exceptions is referenced in a
+ use_clause, and an entity E with the same defining_identifier
+ as a new entity in Exceptions is defined in a package that is
+ also referenced in a use_clause, the entity E may no longer be
+ use-visible, resulting in errors. This should be rare and is
+ easily fixed if it does occur.
+
+ _Extensions to Ada 95_
+
+19.cc/2
+ {AI95-00362-01AI95-00362-01} The package Exceptions is
+ preelaborated, and types Exception_Id and Exception_Occurrence
+ have preelaborable initialization, allowing this package to be
+ used in preelaborated units.
+
+ _Wording Changes from Ada 95_
+
+19.dd/2
+ {AI95-00361-01AI95-00361-01} The meaning of Exception_Message
+ is reworded to reflect that the string can come from a
+ raise_statement as well as a call of Raise_Exception.
+
+19.ee/2
+ {AI95-00400-01AI95-00400-01} Added Wide_Exception_Name and
+ Wide_Wide_Exception_Name because identifiers can now contain
+ characters outside of Latin-1.
+
+ _Wording Changes from Ada 2005_
+
+19.ff/3
+ {AI05-0043-1AI05-0043-1} Correction: Added explicit wording
+ that the exception message for language-defined checks is
+ unspecified. The old wording appeared inclusive, but it was
+ not.
+
+\1f
+File: aarm2012.info, Node: 11.4.2, Next: 11.4.3, Prev: 11.4.1, Up: 11.4
+
+11.4.2 Pragmas Assert and Assertion_Policy
+------------------------------------------
+
+1/3
+{AI95-00286-01AI95-00286-01} {AI05-0274-1AI05-0274-1} Pragma Assert is
+used to assert the truth of a boolean expression at a point within a
+sequence of declarations or statements.
+
+1.1/3
+{AI05-0274-1AI05-0274-1} Assert pragmas, subtype predicates (see *note
+3.2.4::), preconditions and postconditions (see *note 6.1.1::), and type
+invariants (see *note 7.3.2::) are collectively referred to as
+assertions; their boolean expressions are referred to as assertion
+expressions.
+
+1.a.1/3
+ Glossary entry: A predicate is an assertion that is expected
+ to be True for all objects of a given subtype.
+
+1.a.2/3
+ Glossary entry: A precondition is an assertion that is
+ expected to be True when a given subprogram is called.
+
+1.a.3/3
+ Glossary entry: A postcondition is an assertion that is
+ expected to be True when a given subprogram returns normally.
+
+1.a.4/3
+ Glossary entry: A invariant is an assertion that is expected
+ to be True for all objects of a given private type when viewed
+ from outside the defining package.
+
+1.a.5/3
+ Glossary entry: An assertion is a boolean expression that
+ appears in any of the following: a pragma Assert, a predicate,
+ a precondition, a postcondition, an invariant, a constraint,
+ or a null exclusion. An assertion is expected to be True at
+ run time at certain specified places.
+
+1.2/3
+{AI05-0274-1AI05-0274-1} Pragma Assertion_Policy is used to control
+whether assertions are to be ignored by the implementation, checked at
+run time, or handled in some implementation-defined manner.
+
+ _Syntax_
+
+2/2
+ {AI95-00286-01AI95-00286-01} The form of a pragma Assert is as
+ follows:
+
+3/2
+ pragma Assert([Check =>] boolean_expression[, [Message =>]
+ string_expression]);
+
+4/2
+ A pragma Assert is allowed at the place where a declarative_item or
+ a statement is allowed.
+
+5/2
+ {AI95-00286-01AI95-00286-01} The form of a pragma Assertion_Policy
+ is as follows:
+
+6/2
+ pragma Assertion_Policy(policy_identifier);
+
+6.1/3
+ {AI05-0290-1AI05-0290-1} pragma Assertion_Policy(
+ assertion_aspect_mark => policy_identifier
+ {, assertion_aspect_mark => policy_identifier});
+
+7/3
+ {AI05-0290-1AI05-0290-1} A pragma Assertion_Policy is allowed only
+ immediately within a declarative_part, immediately within a
+ package_specification, or as a configuration pragma.
+
+ _Name Resolution Rules_
+
+8/2
+{AI95-00286-01AI95-00286-01} The expected type for the
+boolean_expression of a pragma Assert is any boolean type. The expected
+type for the string_expression of a pragma Assert is type String.
+
+8.a/2
+ Reason: We allow any boolean type to be like if_statements and
+ other conditionals; we only allow String for the message in
+ order to match raise_statements.
+
+ _Legality Rules_
+
+9/3
+{AI95-00286-01AI95-00286-01} {AI05-0290-1AI05-0290-1} The
+assertion_aspect_mark of a pragma Assertion_Policy shall be one of
+Assert, Static_Predicate, Dynamic_Predicate, Pre, Pre'Class, Post,
+Post'Class, Type_Invariant, Type_Invariant'Class, or some implementation
+defined aspect_mark. The policy_identifier shall be either Check,
+Ignore, or some implementation-defined identifier.
+
+9.a/3
+ Implementation defined: Implementation-defined
+ policy_identifiers and assertion_aspect_marks allowed in a
+ pragma Assertion_Policy.
+
+ _Static Semantics_
+
+10/3
+{AI95-00286-01AI95-00286-01} {AI05-0290-1AI05-0290-1} A pragma
+Assertion_Policy determines for each assertion aspect named in the
+pragma_argument_associations whether assertions of the given aspect are
+to be enforced by a run-time check. The policy_identifier Check
+requires that assertion expressions of the given aspect be checked that
+they evaluate to True at the points specified for the given aspect; the
+policy_identifier Ignore requires that the assertion expression not be
+evaluated at these points, and the run-time checks not be performed.
+[Note that for subtype predicate aspects (see *note 3.2.4::), even when
+the applicable Assertion_Policy is Ignore, the predicate will still be
+evaluated as part of membership tests and Valid attribute_references,
+and if static, will still have an effect on loop iteration over the
+subtype, and the selection of case_statement_alternatives and variants.]
+
+10.1/3
+{AI05-0290-1AI05-0290-1} If no assertion_aspect_marks are specified in
+the pragma, the specified policy applies to all assertion aspects.
+
+10.2/3
+{AI05-0290-1AI05-0290-1} A pragma Assertion_Policy applies to the named
+assertion aspects in a specific region, and applies to all assertion
+expressions specified in that region. A pragma Assertion_Policy given
+in a declarative_part or immediately within a package_specification
+applies from the place of the pragma to the end of the innermost
+enclosing declarative region. The region for a pragma Assertion_Policy
+given as a configuration pragma is the declarative region for the entire
+compilation unit (or units) to which it applies.
+
+10.3/3
+{AI05-0290-1AI05-0290-1} If a pragma Assertion_Policy applies to a
+generic_instantiation, then the pragma Assertion_Policy applies to the
+entire instance.
+
+10.a.1/3
+ Ramification: This means that an Assertion_Policy pragma that
+ occurs in a scope enclosing the declaration of a generic unit
+ but not also enclosing the declaration of a given instance of
+ that generic unit will not apply to assertion expressions
+ occurring within the given instance.
+
+10.4/3
+{AI05-0290-1AI05-0290-1} If multiple Assertion_Policy pragmas apply to a
+given construct for a given assertion aspect, the assertion policy is
+determined by the one in the innermost enclosing region of a pragma
+Assertion_Policy specifying a policy for the assertion aspect. If no
+such Assertion_Policy pragma exists, the policy is implementation
+defined.
+
+10.a/2
+ Implementation defined: The default assertion policy.
+
+11/2
+{AI95-00286-01AI95-00286-01} The following language-defined library
+package exists:
+
+12/2
+ package Ada.Assertions is
+ pragma Pure(Assertions);
+
+13/2
+ Assertion_Error : exception;
+
+14/2
+ procedure Assert(Check : in Boolean);
+ procedure Assert(Check : in Boolean; Message : in String);
+
+15/2
+ end Ada.Assertions;
+
+16/3
+{AI95-00286-01AI95-00286-01} {AI05-0290-1AI05-0290-1} A compilation unit
+containing a check for an assertion (including a pragma Assert) has a
+semantic dependence on the Assertions library unit.
+
+17/3
+This paragraph was deleted.{AI95-00286-01AI95-00286-01}
+{AI05-0290-1AI05-0290-1}
+
+ _Dynamic Semantics_
+
+18/3
+{AI95-00286-01AI95-00286-01} {AI05-0290-1AI05-0290-1} If performing
+checks is required by the Assert assertion policy in effect at the place
+of a pragma Assert, the elaboration of the pragma consists of evaluating
+the boolean expression, and if the result is False, evaluating the
+Message argument, if any, and raising the exception
+Assertions.Assertion_Error, with a message if the Message argument is
+provided.
+
+19/2
+{AI95-00286-01AI95-00286-01} Calling the procedure Assertions.Assert
+without a Message parameter is equivalent to:
+
+20/2
+ if Check = False then
+ raise Ada.Assertions.Assertion_Error;
+ end if;
+
+21/2
+{AI95-00286-01AI95-00286-01} Calling the procedure Assertions.Assert
+with a Message parameter is equivalent to:
+
+22/2
+ if Check = False then
+ raise Ada.Assertions.Assertion_Error with Message;
+ end if;
+
+23/2
+{AI95-00286-01AI95-00286-01} The procedures Assertions.Assert have these
+effects independently of the assertion policy in effect.
+
+ _Bounded (Run-Time) Errors_
+
+23.1/3
+{AI05-0274-1AI05-0274-1} It is a bounded error to invoke a potentially
+blocking operation (see *note 9.5.1::) during the evaluation of an
+assertion expression associated with a call on, or return from, a
+protected operation. If the bounded error is detected, Program_Error is
+raised. If not detected, execution proceeds normally, but if it is
+invoked within a protected action, it might result in deadlock or a
+(nested) protected action.
+
+ _Implementation Permissions_
+
+24/2
+{AI95-00286-01AI95-00286-01} Assertion_Error may be declared by renaming
+an implementation-defined exception from another package.
+
+24.a/2
+ Reason: This permission is intended to allow implementations
+ which had an implementation-defined Assert pragma to continue
+ to use their originally defined exception. Without this
+ permission, such an implementation would be incorrect, as
+ Exception_Name would return the wrong name.
+
+25/2
+{AI95-00286-01AI95-00286-01} Implementations may define their own
+assertion policies.
+
+26/3
+{AI05-0274-1AI05-0274-1} If the result of a function call in an
+assertion is not needed to determine the value of the assertion
+expression, an implementation is permitted to omit the function call.
+[This permission applies even if the function has side effects.]
+
+27/3
+{AI05-0274-1AI05-0274-1} An implementation need not allow the
+specification of an assertion expression if the evaluation of the
+expression has a side effect such that an immediate reevaluation of the
+expression could produce a different value. Similarly, an
+implementation need not allow the specification of an assertion
+expression that is checked as part of a call on or return from a
+callable entity C, if the evaluation of the expression has a side effect
+such that the evaluation of some other assertion expression associated
+with the same call of (or return from) C could produce a different value
+than it would if the first expression had not been evaluated.
+
+27.a/3
+ Ramification: This allows an implementation to reject such
+ assertions. To maximize portability, assertions should not
+ include expressions that contain these sorts of side effects.
+
+27.b/3
+ Discussion: The intended effect of the second part of the rule
+ (the part starting with "Similarly") is that an evaluation of
+ the involved assertion expressions (subtype predicates, type
+ invariants, preconditions and postconditions) in any order
+ yields identical results.
+
+27.c/3
+ The rule is intended to apply to all of the assertion
+ expressions that are evaluated at the start of call (and
+ similarly for the assertion expressions that are evaluated
+ during the return from a call), but not other assertions
+ actually given in the body, nor between the assertions checked
+ at the start and end of the call. Specifically, a side effect
+ that alters a variable in a function called from a
+ precondition expression that changes the result of a
+ postcondition expression of the same subprogram does not
+ trigger these rules unless it also changes the value of a
+ reevaluation of the precondition expression.
+
+ NOTES
+
+28/2
+ 2 {AI95-00286-01AI95-00286-01} Normally, the boolean expression in
+ a pragma Assert should not call functions that have significant
+ side effects when the result of the expression is True, so that the
+ particular assertion policy in effect will not affect normal
+ operation of the program.
+
+ _Extensions to Ada 95_
+
+28.a/2
+ {AI95-00286-01AI95-00286-01} Pragmas Assert and
+ Assertion_Policy, and package Assertions are new.
+
+ _Incompatibilities With Ada 2005_
+
+28.b/3
+ {AI05-0274-1AI05-0274-1} There now is an Implementation
+ Permission to reject an assertion expression that calls a
+ function that has a side effect such that an immediate
+ reevalution of the expression could produce a different value.
+ This means that a pragma Assert that works in Ada 2005 might
+ be illegal in Ada 2012 in the unlikely event that the compiler
+ detected such an error. This should be unlikely to occur in
+ practice and it is considered a good thing, as the original
+ expression was tricky and probably was not portable (as order
+ of evaluation is unspecified within an expression). Moreover,
+ no compiler is required to reject such expressions, so there
+ is no need for any compiler to change behavior.
+
+ _Extensions to Ada 2005_
+
+28.c/3
+ {AI05-0290-1AI05-0290-1} Assertion_Policy pragmas are now
+ allowed in more places and can specify behavior for invidivual
+ kinds of assertions.
+
+\1f
+File: aarm2012.info, Node: 11.4.3, Prev: 11.4.2, Up: 11.4
+
+11.4.3 Example of Exception Handling
+------------------------------------
+
+ _Examples_
+
+1
+Exception handling may be used to separate the detection of an error
+from the response to that error:
+
+2/2
+ {AI95-00433-01AI95-00433-01} package File_System is
+ type File_Handle is limited private;
+
+3
+ File_Not_Found : exception;
+ procedure Open(F : in out File_Handle; Name : String);
+ -- raises File_Not_Found if named file does not exist
+
+4
+ End_Of_File : exception;
+ procedure Read(F : in out File_Handle; Data : out Data_Type);
+ -- raises End_Of_File if the file is not open
+
+5
+ ...
+ end File_System;
+
+6/2
+ {AI95-00433-01AI95-00433-01} package body File_System is
+ procedure Open(F : in out File_Handle; Name : String) is
+ begin
+ if File_Exists(Name) then
+ ...
+ else
+ raise File_Not_Found with "File not found: " & Name & ".";
+ end if;
+ end Open;
+
+7
+ procedure Read(F : in out File_Handle; Data : out Data_Type) is
+ begin
+ if F.Current_Position <= F.Last_Position then
+ ...
+ else
+ raise End_Of_File;
+ end if;
+ end Read;
+
+8
+ ...
+
+9
+ end File_System;
+
+10
+ with Ada.Text_IO;
+ with Ada.Exceptions;
+ with File_System; use File_System;
+ use Ada;
+ procedure Main is
+ begin
+ ... -- call operations in File_System
+ exception
+ when End_Of_File =>
+ Close(Some_File);
+ when Not_Found_Error : File_Not_Found =>
+ Text_IO.Put_Line(Exceptions.Exception_Message(Not_Found_Error));
+ when The_Error : others =>
+ Text_IO.Put_Line("Unknown error:");
+ if Verbosity_Desired then
+ Text_IO.Put_Line(Exceptions.Exception_Information(The_Error));
+ else
+ Text_IO.Put_Line(Exceptions.Exception_Name(The_Error));
+ Text_IO.Put_Line(Exceptions.Exception_Message(The_Error));
+ end if;
+ raise;
+ end Main;
+
+11
+In the above example, the File_System package contains information about
+detecting certain exceptional situations, but it does not specify how to
+handle those situations. Procedure Main specifies how to handle them;
+other clients of File_System might have different handlers, even though
+the exceptional situations arise from the same basic causes.
+
+ _Wording Changes from Ada 83_
+
+11.a/3
+ {AI05-0299-1AI05-0299-1} The sections labeled "Exceptions
+ Raised During ..." are subsumed by this subclause, and by
+ parts of Clause *note 9::.
+
+\1f
+File: aarm2012.info, Node: 11.5, Next: 11.6, Prev: 11.4, Up: 11
+
+11.5 Suppressing Checks
+=======================
+
+1/2
+{AI95-00224-01AI95-00224-01} Checking pragmas give instructions to an
+implementation on handling language-defined checks. A pragma Suppress
+gives permission to an implementation to omit certain language-defined
+checks, while a pragma Unsuppress revokes the permission to omit
+checks..
+
+2/3
+{AI05-0264-1AI05-0264-1} A language-defined check (or simply, a "check")
+is one of the situations defined by this International Standard that
+requires a check to be made at run time to determine whether some
+condition is true. A check fails when the condition being checked is
+False, causing an exception to be raised.
+
+2.a
+ Discussion: All such checks are defined under "Dynamic
+ Semantics" in clauses and subclauses throughout the standard.
+
+ _Syntax_
+
+3/2
+ {AI95-00224-01AI95-00224-01} The forms of checking pragmas are as
+ follows:
+
+4/2
+ {AI95-00224-01AI95-00224-01} pragma Suppress(identifier);
+
+4.1/2
+ {AI95-00224-01AI95-00224-01} pragma Unsuppress(identifier);
+
+5/2
+ {AI95-00224-01AI95-00224-01} A checking pragma is allowed only
+ immediately within a declarative_part, immediately within a
+ package_specification (*note 7.1: S0191.), or as a configuration
+ pragma.
+
+ _Legality Rules_
+
+6/2
+{AI95-00224-01AI95-00224-01} The identifier shall be the name of a
+check.
+
+7/2
+This paragraph was deleted.{AI95-00224-01AI95-00224-01}
+
+ _Static Semantics_
+
+7.1/2
+{AI95-00224-01AI95-00224-01} A checking pragma applies to the named
+check in a specific region, and applies to all entities in that region.
+A checking pragma given in a declarative_part or immediately within a
+package_specification applies from the place of the pragma to the end of
+the innermost enclosing declarative region. The region for a checking
+pragma given as a configuration pragma is the declarative region for the
+entire compilation unit (or units) to which it applies.
+
+7.2/3
+{AI95-00224-01AI95-00224-01} {AI05-0229-1AI05-0229-1}
+{AI05-0290-1AI05-0290-1} If a checking pragma applies to a
+generic_instantiation, then the checking pragma also applies to the
+entire instance.
+
+7.a/3
+ Ramification: {AI05-0290-1AI05-0290-1} This means that a
+ Suppress pragma that occurs in a scope enclosing the
+ declaration of a generic unit but not also enclosing the
+ declaration of a given instance of that generic unit will not
+ apply to constructs within the given instance.
+
+8/2
+{AI95-00224-01AI95-00224-01} A pragma Suppress gives permission to an
+implementation to omit the named check (or every check in the case of
+All_Checks) for any entities to which it applies. If permission has
+been given to suppress a given check, the check is said to be
+suppressed.
+
+8.a
+ Ramification: A check is suppressed even if the implementation
+ chooses not to actually generate better code. This allows the
+ implementation to raise Program_Error, for example, if the
+ erroneousness is detected.
+
+8.1/2
+{AI95-00224-01AI95-00224-01} A pragma Unsuppress revokes the permission
+to omit the named check (or every check in the case of All_Checks) given
+by any pragma Suppress that applies at the point of the pragma
+Unsuppress. The permission is revoked for the region to which the
+pragma Unsuppress applies. If there is no such permission at the point
+of a pragma Unsuppress, then the pragma has no effect. A later pragma
+Suppress can renew the permission.
+
+9
+The following are the language-defined checks:
+
+10
+ * [The following checks correspond to situations in which the
+ exception Constraint_Error is raised upon failure.]
+
+11/2
+{8652/00368652/0036} {AI95-00176-01AI95-00176-01}
+{AI95-00231-01AI95-00231-01} Access_Check
+ [When evaluating a dereference (explicit or implicit),
+ check that the value of the name is not null. When
+ converting to a subtype that excludes null, check that
+ the converted value is not null.]
+
+12
+Discriminant_Check
+ [Check that the discriminants of a composite value have
+ the values imposed by a discriminant constraint. Also,
+ when accessing a record component, check that it exists
+ for the current discriminant values.]
+
+13/2
+{AI95-00434-01AI95-00434-01} Division_Check
+ [Check that the second operand is not zero for the
+ operations /, rem and mod.]
+
+14
+Index_Check
+ [Check that the bounds of an array value are equal to the
+ corresponding bounds of an index constraint. Also, when
+ accessing a component of an array object, check for each
+ dimension that the given index value belongs to the range
+ defined by the bounds of the array object. Also, when
+ accessing a slice of an array object, check that the
+ given discrete range is compatible with the range defined
+ by the bounds of the array object.]
+
+15
+Length_Check
+ [Check that two arrays have matching components, in the
+ case of array subtype conversions, and logical operators
+ for arrays of boolean components.]
+
+16
+Overflow_Check
+ [Check that a scalar value is within the base range of
+ its type, in cases where the implementation chooses to
+ raise an exception instead of returning the correct
+ mathematical result.]
+
+17
+Range_Check
+ [Check that a scalar value satisfies a range constraint.
+ Also, for the elaboration of a subtype_indication, check
+ that the constraint (if present) is compatible with the
+ subtype denoted by the subtype_mark. Also, for an
+ aggregate, check that an index or discriminant value
+ belongs to the corresponding subtype. Also, check that
+ when the result of an operation yields an array, the
+ value of each component belongs to the component
+ subtype.]
+
+18
+Tag_Check
+ [Check that operand tags in a dispatching call are all
+ equal. Check for the correct tag on tagged type
+ conversions, for an assignment_statement, and when
+ returning a tagged limited object from a function.]
+
+19
+ * [The following checks correspond to situations in which the
+ exception Program_Error is raised upon failure.]
+
+19.1/2
+{AI95-00280AI95-00280} Accessibility_Check
+ [Check the accessibility level of an entity or view.]
+
+19.2/2
+{AI95-00280AI95-00280} Allocation_Check
+ [For an allocator, check that the master of any tasks to
+ be created by the allocator is not yet completed or some
+ dependents have not yet terminated, and that the
+ finalization of the collection has not started.]
+
+20
+Elaboration_Check
+ [When a subprogram or protected entry is called, a task
+ activation is accomplished, or a generic instantiation is
+ elaborated, check that the body of the corresponding unit
+ has already been elaborated.]
+
+21/2
+
+ This paragraph was deleted.{AI95-00280AI95-00280}
+
+22
+ * [The following check corresponds to situations in which the
+ exception Storage_Error is raised upon failure.]
+
+23
+Storage_Check
+ [Check that evaluation of an allocator does not require
+ more space than is available for a storage pool. Check
+ that the space available for a task or subprogram has not
+ been exceeded.]
+
+23.a
+ Reason: We considered splitting this out into three
+ categories: Pool_Check (for allocators), Stack_Check (for
+ stack usage), and Heap_Check (for implicit use of the heap --
+ use of the heap other than through an allocator).
+ Storage_Check would then represent the union of these three.
+ However, there seems to be no compelling reason to do this,
+ given that it is not feasible to split Storage_Error.
+
+24
+ * [The following check corresponds to all situations in which any
+ predefined exception is raised.]
+
+25/3
+{AI05-0290-1AI05-0290-1} All_Checks
+ Represents the union of all checks; suppressing
+ All_Checks suppresses all checks other than those
+ associated with assertions. In addition, an
+ implementation is allowed (but not required) to behave as
+ if a pragma Assertion_Policy(Ignore) applies to any
+ region to which pragma Suppress(All_Checks) applies.
+
+25.a
+ Ramification: All_Checks includes both language-defined and
+ implementation-defined checks.
+
+25.b/3
+ To be honest: {AI05-0005-1AI05-0005-1} There are additional
+ checks defined in various Specialized Needs Annexes that are
+ not listed here. Nevertheless, they are included in
+ All_Checks and named in a Suppress pragma on implementations
+ that support the relevant annex. Look up "check,
+ language-defined" in the index to find the complete list.
+
+25.c/3
+ Discussion: {AI05-0290-1AI05-0290-1} We don't want to say that
+ assertions are suppressed, because we don't want the potential
+ failure of an assertion to cause erroneous execution (see
+ below). Thus they are excluded from the suppression part of
+ the above rule and then handled with an implicit Ignore
+ policy.
+
+ _Erroneous Execution_
+
+26
+If a given check has been suppressed, and the corresponding error
+situation occurs, the execution of the program is erroneous.
+
+ _Implementation Permissions_
+
+27/2
+{AI95-00224-01AI95-00224-01} An implementation is allowed to place
+restrictions on checking pragmas, subject only to the requirement that
+pragma Unsuppress shall allow any check names supported by pragma
+Suppress. An implementation is allowed to add additional check names,
+with implementation-defined semantics. When Overflow_Check has been
+suppressed, an implementation may also suppress an unspecified subset of
+the Range_Checks.
+
+27.a/2
+ This paragraph was deleted.{AI95-00224-01AI95-00224-01}
+
+27.b
+ Implementation defined: Implementation-defined check names.
+
+27.c
+ Discussion: For Overflow_Check, the intention is that the
+ implementation will suppress any Range_Checks that are
+ implemented in the same manner as Overflow_Checks (unless they
+ are free).
+
+27.1/2
+{AI95-00224-01AI95-00224-01} An implementation may support an additional
+parameter on pragma Unsuppress similar to the one allowed for pragma
+Suppress (see *note J.10::). The meaning of such a parameter is
+implementation-defined.
+
+27.c.1/2
+ Implementation defined: Existence and meaning of second
+ parameter of pragma Unsuppress.
+
+ _Implementation Advice_
+
+28
+The implementation should minimize the code executed for checks that
+have been suppressed.
+
+28.a.1/2
+ Implementation Advice: Code executed for checks that have been
+ suppressed should be minimized.
+
+28.a
+ Implementation Note: However, if a given check comes for free
+ (for example, the hardware automatically performs the check in
+ parallel with doing useful work) or nearly free (for example,
+ the check is a tiny portion of an expensive run-time system
+ call), the implementation should not bother to suppress the
+ check. Similarly, if the implementation detects the failure
+ at compile time and provides a warning message, there is no
+ need to actually suppress the check.
+
+ NOTES
+
+29
+ 3 There is no guarantee that a suppressed check is actually
+ removed; hence a pragma Suppress should be used only for efficiency
+ reasons.
+
+29.1/2
+ 4 {AI95-00224-01AI95-00224-01} It is possible to give both a
+ pragma Suppress and Unsuppress for the same check immediately
+ within the same declarative_part. In that case, the last pragma
+ given determines whether or not the check is suppressed.
+ Similarly, it is possible to resuppress a check which has been
+ unsuppressed by giving a pragma Suppress in an inner declarative
+ region.
+
+ _Examples_
+
+30/2
+{AI95-00224-01AI95-00224-01} Examples of suppressing and unsuppressing
+checks:
+
+31/2
+ {AI95-00224-01AI95-00224-01} pragma Suppress(Index_Check);
+ pragma Unsuppress(Overflow_Check);
+
+ _Extensions to Ada 83_
+
+31.a
+ A pragma Suppress is allowed as a configuration pragma. A
+ pragma Suppress without a name is allowed in a
+ package_specification.
+
+31.b
+ Additional check names are added. We allow implementations to
+ define their own checks.
+
+ _Wording Changes from Ada 83_
+
+31.c
+ We define the checks in a distributed manner. Therefore, the
+ long list of what checks apply to what is merely a NOTE.
+
+31.d
+ We have removed the detailed rules about what is allowed in a
+ pragma Suppress, and allow implementations to invent their
+ own. The RM83 rules weren't quite right, and such a change is
+ necessary anyway in the presence of implementation-defined
+ checks.
+
+31.e
+ We make it clear that the difference between a Range_Check and
+ an Overflow_Check is fuzzy. This was true in Ada 83, given
+ RM83-11.6, but it was not clear. We considered removing
+ Overflow_Check from the language or making it obsolescent,
+ just as we did for Numeric_Error. However, we kept it for
+ upward compatibility, and because it may be useful on machines
+ where range checking costs more than overflow checking, but
+ overflow checking still costs something. Different compilers
+ will suppress different checks when asked to suppress
+ Overflow_Check -- the nonuniformity in this case is not
+ harmful, and removing it would have a serious impact on
+ optimizers.
+
+31.f
+ Under Access_Check, dereferences cover the cases of
+ selected_component, indexed_component, slice, and attribute
+ that are listed in RM83, as well as the new
+ explicit_dereference, which was included in selected_component
+ in RM83.
+
+ _Extensions to Ada 95_
+
+31.g/2
+ {AI95-00224-01AI95-00224-01} Pragma Unsuppress is new.
+
+31.h/2
+ {AI95-00280-01AI95-00280-01} Allocation_Check was added to
+ support suppressing the new check on allocators (see *note
+ 4.8::).
+
+ _Wording Changes from Ada 95_
+
+31.i/2
+ {8652/00368652/0036} {AI95-00176-01AI95-00176-01}
+ {AI95-00224-01AI95-00224-01} The description of Access_Check
+ was corrected by the Corrigendum to include the discriminant
+ case. This change was then replaced by the more general
+ notion of checking conversions to subtypes that exclude null
+ in Ada 2005.
+
+31.j/2
+ {AI95-00224-01AI95-00224-01} The On parameter of pragma
+ Suppress was moved to Annex J (see *note J.10::). This
+ feature's effect is inherently nonportable, depending on the
+ implementation's model of computation. Compiler surveys
+ demonstrated this, showing that implementations vary widely in
+ the interpretation of these parameters, even on the same
+ target. While this is relatively harmless for Suppress (which
+ is never required to do anything), it would be a significant
+ problem for Unsuppress (we want the checks to be made for all
+ implementations). By moving it, we avoid needing to define
+ the meaning of Unsuppress with an On parameter.
+
+31.k/2
+ {AI95-00280-01AI95-00280-01} The order of the Program_Error
+ checks was corrected to be alphabetical.
+
+ _Wording Changes from Ada 2005_
+
+31.l/3
+ {AI05-0290-1AI05-0290-1} The effect of a checking pragma no
+ longer applies inside an inlined subprogram body. While this
+ could change the behavior of a program that depends on a check
+ being suppressed in an inlined body, such a program is
+ erroneous and thus no behavior can be depended upon anyway.
+ It's also likely to be very rare. We make this change so that
+ inlining has no effect on the meaning of the subprogram body
+ (since inlining is never requiring, this is necessary in order
+ to be able to reason about the body), and so that assertion
+ policies and suppress work the same way for inlining.
+
+\1f
+File: aarm2012.info, Node: 11.6, Prev: 11.5, Up: 11
+
+11.6 Exceptions and Optimization
+================================
+
+1/3
+{AI05-0299-1AI05-0299-1} [ This subclause gives permission to the
+implementation to perform certain "optimizations" that do not
+necessarily preserve the canonical semantics.]
+
+ _Dynamic Semantics_
+
+2/3
+{AI05-0299-1AI05-0299-1} The rest of this International Standard
+(outside this subclause) defines the canonical semantics of the
+language. [The canonical semantics of a given (legal) program
+determines a set of possible external effects that can result from the
+execution of the program with given inputs.]
+
+2.a
+ Ramification: Note that the canonical semantics is a set of
+ possible behaviors, since some reordering, parallelism, and
+ nondeterminism is allowed by the canonical semantics.
+
+2.b/3
+ Discussion: {AI05-0299-1AI05-0299-1} The following parts of
+ the canonical semantics are of particular interest to the
+ reader of this subclause:
+
+2.c
+ * Behavior in the presence of abnormal objects and objects
+ with invalid representations (see *note 13.9.1::).
+
+2.d
+ * Various actions that are defined to occur in an arbitrary
+ order.
+
+2.e/3
+ * {AI05-0299-1AI05-0299-1} Behavior in the presence of a
+ misuse of Unchecked_Deallocation, Unchecked_Access, or
+ imported or exported entity (see Clause *note 13::).
+
+3/3
+{AI05-0299-1AI05-0299-1} [As explained in *note 1.1.3::, "*note 1.1.3::
+Conformity of an Implementation with the Standard", the external effect
+of a program is defined in terms of its interactions with its external
+environment. Hence, the implementation can perform any internal actions
+whatsoever, in any order or in parallel, so long as the external effect
+of the execution of the program is one that is allowed by the canonical
+semantics, or by the rules of this subclause.]
+
+3.a
+ Ramification: Note that an optimization can change the
+ external effect of the program, so long as the changed
+ external effect is an external effect that is allowed by the
+ semantics. Note that the canonical semantics of an erroneous
+ execution allows any external effect whatsoever. Hence, if
+ the implementation can prove that program execution will be
+ erroneous in certain circumstances, there need not be any
+ constraints on the machine code executed in those
+ circumstances.
+
+ _Implementation Permissions_
+
+4
+The following additional permissions are granted to the implementation:
+
+5
+ * An implementation need not always raise an exception when a
+ language-defined check fails. Instead, the operation that failed
+ the check can simply yield an undefined result. The exception need
+ be raised by the implementation only if, in the absence of raising
+ it, the value of this undefined result would have some effect on
+ the external interactions of the program. In determining this, the
+ implementation shall not presume that an undefined result has a
+ value that belongs to its subtype, nor even to the base range of
+ its type, if scalar. [Having removed the raise of the exception,
+ the canonical semantics will in general allow the implementation to
+ omit the code for the check, and some or all of the operation
+ itself.]
+
+5.a
+ Ramification: Even without this permission, an implementation
+ can always remove a check if it cannot possibly fail.
+
+5.b
+ Reason: We express the permission in terms of removing the
+ raise, rather than the operation or the check, as it minimizes
+ the disturbance to the canonical semantics (thereby
+ simplifying reasoning). By allowing the implementation to
+ omit the raise, it thereby does not need to "look" at what
+ happens in the exception handler to decide whether the
+ optimization is allowed.
+
+5.c
+ Discussion: The implementation can also omit checks if they
+ cannot possibly fail, or if they could only fail in erroneous
+ executions. This follows from the canonical semantics.
+
+5.d
+ Implementation Note: This permission is intended to allow
+ normal "dead code removal" optimizations, even if some of the
+ removed code might have failed some language-defined check.
+ However, one may not eliminate the raise of an exception if
+ subsequent code presumes in some way that the check succeeded.
+ For example:
+
+5.e
+ if X * Y > Integer'Last then
+ Put_Line("X * Y overflowed");
+ end if;
+ exception
+ when others =>
+ Put_Line("X * Y overflowed");
+
+5.e.1
+ If X*Y does overflow, you may not remove the raise of the
+ exception if the code that does the comparison against
+ Integer'Last presumes that it is comparing it with an in-range
+ Integer value, and hence always yields False.
+
+5.f
+ As another example where a raise may not be eliminated:
+
+5.g
+ subtype Str10 is String(1..10);
+ type P10 is access Str10;
+ X : P10 := null;
+ begin
+ if X.all'Last = 10 then
+ Put_Line("Oops");
+ end if;
+
+5.g.1
+ In the above code, it would be wrong to eliminate the raise of
+ Constraint_Error on the "X.all" (since X is null), if the code
+ to evaluate 'Last always yields 10 by presuming that X.all
+ belongs to the subtype Str10, without even "looking."
+
+6/3
+ * {AI05-0229-1AI05-0229-1} If an exception is raised due to the
+ failure of a language-defined check, then upon reaching the
+ corresponding exception_handler (or the termination of the task, if
+ none), the external interactions that have occurred need reflect
+ only that the exception was raised somewhere within the execution
+ of the sequence_of_statements with the handler (or the task_body),
+ possibly earlier (or later if the interactions are independent of
+ the result of the checked operation) than that defined by the
+ canonical semantics, but not within the execution of some
+ abort-deferred operation or independent subprogram that does not
+ dynamically enclose the execution of the construct whose check
+ failed. An independent subprogram is one that is defined outside
+ the library unit containing the construct whose check failed, and
+ for which the Inline aspect is False. Any assignment that occurred
+ outside of such abort-deferred operations or independent
+ subprograms can be disrupted by the raising of the exception,
+ causing the object or its parts to become abnormal, and certain
+ subsequent uses of the object to be erroneous, as explained in
+ *note 13.9.1::.
+
+6.a
+ Reason: We allow such variables to become abnormal so that
+ assignments (other than to atomic variables) can be disrupted
+ due to "imprecise" exceptions or instruction scheduling, and
+ so that assignments can be reordered so long as the correct
+ results are produced in the end if no language-defined checks
+ fail.
+
+6.b
+ Ramification: If a check fails, no result dependent on the
+ check may be incorporated in an external interaction. In
+ other words, there is no permission to output meaningless
+ results due to postponing a check.
+
+6.c
+ Discussion: We believe it is important to state the extra
+ permission to reorder actions in terms of what the programmer
+ can expect at run time, rather than in terms of what the
+ implementation can assume, or what transformations the
+ implementation can perform. Otherwise, how can the programmer
+ write reliable programs?
+
+6.d/3
+ {AI05-0299-1AI05-0299-1} This subclause has two conflicting
+ goals: to allow as much optimization as possible, and to make
+ program execution as predictable as possible (to ease the
+ writing of reliable programs). The rules given above
+ represent a compromise.
+
+6.e
+ Consider the two extremes:
+
+6.f/3
+ {AI05-0299-1AI05-0299-1} The extreme conservative rule would
+ be to delete this subclause entirely. The semantics of Ada
+ would be the canonical semantics. This achieves the best
+ predictability. It sounds like a disaster from the efficiency
+ point of view, but in practice, implementations would provide
+ modes in which less predictability but more efficiency would
+ be achieved. Such a mode could even be the out-of-the-box
+ mode. In practice, implementers would provide a compromise
+ based on their customer's needs. Therefore, we view this as
+ one viable alternative.
+
+6.g
+ The extreme liberal rule would be "the language does not
+ specify the execution of a program once a language-defined
+ check has failed; such execution can be unpredictable." This
+ achieves the best efficiency. It sounds like a disaster from
+ the predictability point of view, but in practice it might not
+ be so bad. A user would have to assume that exception
+ handlers for exceptions raised by language-defined checks are
+ not portable. They would have to isolate such code (like all
+ nonportable code), and would have to find out, for each
+ implementation of interest, what behaviors can be expected.
+ In practice, implementations would tend to avoid going so far
+ as to punish their customers too much in terms of
+ predictability.
+
+6.h/3
+ {AI05-0299-1AI05-0299-1} The most important thing about this
+ subclause is that users understand what they can expect at run
+ time, and implementers understand what optimizations are
+ allowed. Any solution that makes this subclause contain rules
+ that can interpreted in more than one way is unacceptable.
+
+6.i
+ We have chosen a compromise between the extreme conservative
+ and extreme liberal rules. The current rule essentially
+ allows arbitrary optimizations within a library unit and
+ inlined subprograms reachable from it, but disallow
+ semantics-disrupting optimizations across library units in the
+ absence of inlined subprograms. This allows a library unit to
+ be debugged, and then reused with some confidence that the
+ abstraction it manages cannot be broken by bugs outside the
+ library unit.
+
+ NOTES
+
+7/3
+ 5 {AI05-0299-1AI05-0299-1} The permissions granted by this
+ subclause can have an effect on the semantics of a program only if
+ the program fails a language-defined check.
+
+ _Wording Changes from Ada 83_
+
+7.a
+ RM83-11.6 was unclear. It has been completely rewritten here;
+ we hope this version is clearer. Here's what happened to each
+ paragraph of RM83-11.6:
+
+7.b
+ * Paragraphs 1 and 2 contain no semantics; they are merely
+ pointing out that anything goes if the canonical
+ semantics is preserved. We have similar introductory
+ paragraphs, but we have tried to clarify that these are
+ not granting any "extra" permission beyond what the rest
+ of the document allows.
+
+7.c
+ * Paragraphs 3 and 4 are reflected in the "extra permission
+ to reorder actions". Note that this permission now
+ allows the reordering of assignments in many cases.
+
+7.d
+ * Paragraph 5 is moved to *note 4.5::, "*note 4.5::
+ Operators and Expression Evaluation", where operator
+ association is discussed. Hence, this is no longer an
+ "extra permission" but is part of the canonical
+ semantics.
+
+7.e
+ * Paragraph 6 now follows from the general permission to
+ store out-of-range values for unconstrained subtypes.
+ Note that the parameters and results of all the
+ predefined operators of a type are of the unconstrained
+ subtype of the type.
+
+7.f
+ * Paragraph 7 is reflected in the "extra permission to
+ avoid raising exceptions".
+
+7.g/3
+ {AI05-0299-1AI05-0299-1} We moved subclause *note 11.5::,
+ "*note 11.5:: Suppressing Checks" from after 11.6 to before
+ 11.6, in order to preserve the famous number "11.6" (given the
+ changes to earlier subclauses in Clause *note 11::).
+
+\1f
+File: aarm2012.info, Node: 12, Next: 13, Prev: 11, Up: Top
+
+12 Generic Units
+****************
+
+1
+A generic unit is a program unit that is either a generic subprogram or
+a generic package. A generic unit is a template[, which can be
+parameterized, and from which corresponding (nongeneric) subprograms or
+packages can be obtained]. The resulting program units are said to be
+instances of the original generic unit.
+
+1.a
+ Glossary entry: A generic unit is a template for a
+ (nongeneric) program unit; the template can be parameterized
+ by objects, types, subprograms, and packages. An instance of
+ a generic unit is created by a generic_instantiation. The
+ rules of the language are enforced when a generic unit is
+ compiled, using a generic contract model; additional checks
+ are performed upon instantiation to verify the contract is
+ met. That is, the declaration of a generic unit represents a
+ contract between the body of the generic and instances of the
+ generic. Generic units can be used to perform the role that
+ macros sometimes play in other languages.
+
+2
+[A generic unit is declared by a generic_declaration. This form of
+declaration has a generic_formal_part (*note 12.1: S0273.) declaring any
+generic formal parameters. An instance of a generic unit is obtained as
+the result of a generic_instantiation with appropriate generic actual
+parameters for the generic formal parameters. An instance of a generic
+subprogram is a subprogram. An instance of a generic package is a
+package.
+
+3
+Generic units are templates. As templates they do not have the
+properties that are specific to their nongeneric counterparts. For
+example, a generic subprogram can be instantiated but it cannot be
+called. In contrast, an instance of a generic subprogram is a
+(nongeneric) subprogram; hence, this instance can be called but it
+cannot be used to produce further instances.]
+
+* Menu:
+
+* 12.1 :: Generic Declarations
+* 12.2 :: Generic Bodies
+* 12.3 :: Generic Instantiation
+* 12.4 :: Formal Objects
+* 12.5 :: Formal Types
+* 12.6 :: Formal Subprograms
+* 12.7 :: Formal Packages
+* 12.8 :: Example of a Generic Package
+
+\1f
+File: aarm2012.info, Node: 12.1, Next: 12.2, Up: 12
+
+12.1 Generic Declarations
+=========================
+
+1
+[A generic_declaration declares a generic unit, which is either a
+generic subprogram or a generic package. A generic_declaration includes
+a generic_formal_part declaring any generic formal parameters. A
+generic formal parameter can be an object; alternatively (unlike a
+parameter of a subprogram), it can be a type, a subprogram, or a
+package.]
+
+ _Syntax_
+
+2
+ generic_declaration ::= generic_subprogram_declaration |
+ generic_package_declaration
+
+3/3
+ {AI05-0183-1AI05-0183-1} generic_subprogram_declaration ::=
+ generic_formal_part subprogram_specification
+ [aspect_specification];
+
+4
+ generic_package_declaration ::=
+ generic_formal_part package_specification;
+
+4.a/3
+ Ramification: {AI05-0183-1AI05-0183-1} No syntax change is
+ needed here to allow an aspect_specification; a generic
+ package can have an aspect_specification because a
+ package_specification allows an aspect_specification.
+
+5
+ generic_formal_part ::= generic {
+ generic_formal_parameter_declaration | use_clause}
+
+6
+ generic_formal_parameter_declaration ::=
+ formal_object_declaration
+ | formal_type_declaration
+ | formal_subprogram_declaration
+ | formal_package_declaration
+
+7
+ The only form of subtype_indication allowed within a
+ generic_formal_part is a subtype_mark [(that is, the
+ subtype_indication shall not include an explicit constraint)]. The
+ defining name of a generic subprogram shall be an identifier [(not
+ an operator_symbol)].
+
+7.a
+ Reason: The reason for forbidding constraints in
+ subtype_indications is that it simplifies the elaboration of
+ generic_declarations (since there is nothing to evaluate), and
+ that it simplifies the matching rules, and makes them more
+ checkable at compile time.
+
+ _Static Semantics_
+
+8/2
+{AI95-00434-01AI95-00434-01} A generic_declaration declares a generic
+unit -- a generic package, generic procedure, or generic function, as
+appropriate.
+
+9
+An entity is a generic formal entity if it is declared by a
+generic_formal_parameter_declaration. "Generic formal," or simply
+"formal," is used as a prefix in referring to objects, subtypes (and
+types), functions, procedures and packages, that are generic formal
+entities, as well as to their respective declarations. [Examples:
+"generic formal procedure" or a "formal integer type declaration."]
+
+ _Dynamic Semantics_
+
+10
+The elaboration of a generic_declaration has no effect.
+
+ NOTES
+
+11
+ 1 Outside a generic unit a name that denotes the
+ generic_declaration denotes the generic unit. In contrast, within
+ the declarative region of the generic unit, a name that denotes the
+ generic_declaration denotes the current instance.
+
+11.a
+ Proof: This is stated officially as part of the "current
+ instance" rule in *note 8.6::, "*note 8.6:: The Context of
+ Overload Resolution". See also *note 12.3::, "*note 12.3::
+ Generic Instantiation".
+
+12
+ 2 Within a generic subprogram_body, the name of this program unit
+ acts as the name of a subprogram. Hence this name can be
+ overloaded, and it can appear in a recursive call of the current
+ instance. For the same reason, this name cannot appear after the
+ reserved word new in a (recursive) generic_instantiation.
+
+13
+ 3 A default_expression or default_name appearing in a
+ generic_formal_part is not evaluated during elaboration of the
+ generic_formal_part; instead, it is evaluated when used. (The
+ usual visibility rules apply to any name used in a default: the
+ denoted declaration therefore has to be visible at the place of the
+ expression.)
+
+ _Examples_
+
+14
+Examples of generic formal parts:
+
+15
+ generic -- parameterless
+
+16
+ generic
+ Size : Natural; -- formal object
+
+17
+ generic
+ Length : Integer := 200; -- formal object with a default expression
+
+18
+ Area : Integer := Length*Length; -- formal object with a default expression
+
+19
+ generic
+ type Item is private; -- formal type
+ type Index is (<>); -- formal type
+ type Row is array(Index range <>) of Item; -- formal type
+ with function "<"(X, Y : Item) return Boolean; -- formal subprogram
+
+20
+Examples of generic declarations declaring generic subprograms Exchange
+and Squaring:
+
+21
+ generic
+ type Elem is private;
+ procedure Exchange(U, V : in out Elem);
+
+22
+ generic
+ type Item is private;
+ with function "*"(U, V : Item) return Item is <>;
+ function Squaring(X : Item) return Item;
+
+23
+Example of a generic declaration declaring a generic package:
+
+24
+ generic
+ type Item is private;
+ type Vector is array (Positive range <>) of Item;
+ with function Sum(X, Y : Item) return Item;
+ package On_Vectors is
+ function Sum (A, B : Vector) return Vector;
+ function Sigma(A : Vector) return Item;
+ Length_Error : exception;
+ end On_Vectors;
+
+ _Extensions to Ada 83_
+
+24.a
+ The syntax rule for generic_formal_parameter_declaration is
+ modified to allow the reserved words tagged and abstract, to
+ allow formal derived types, and to allow formal packages.
+
+24.b
+ Use_clauses are allowed in generic_formal_parts. This is
+ necessary in order to allow a use_clause within a formal part
+ to provide direct visibility of declarations within a generic
+ formal package.
+
+ _Wording Changes from Ada 83_
+
+24.c/3
+ {AI05-0299-1AI05-0299-1} The syntax for
+ generic_formal_parameter_declaration and
+ formal_type_definition is split up into more named categories.
+ The rules for these categories are moved to the appropriate
+ subclauses. The names of the categories are changed to be
+ more intuitive and uniform. For example, we changed
+ generic_parameter_declaration to
+ generic_formal_parameter_declaration, because the thing it
+ declares is a generic formal, not a generic. In the others,
+ we abbreviate "generic_formal" to just "formal". We can't do
+ that for generic_formal_parameter_declaration, because of
+ confusion with normal formal parameters of subprograms.
+
+ _Extensions to Ada 2005_
+
+24.d/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a generic_subprogram_declaration (as well as a
+ generic_package_declaration). This is described in *note
+ 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 12.2, Next: 12.3, Prev: 12.1, Up: 12
+
+12.2 Generic Bodies
+===================
+
+1
+The body of a generic unit (a generic body) [is a template for the
+instance bodies. The syntax of a generic body is identical to that of a
+nongeneric body].
+
+1.a
+ Ramification: We also use terms like "generic function body"
+ and "nongeneric package body."
+
+ _Dynamic Semantics_
+
+2
+The elaboration of a generic body has no other effect than to establish
+that the generic unit can from then on be instantiated without failing
+the Elaboration_Check. If the generic body is a child of a generic
+package, then its elaboration establishes that each corresponding
+declaration nested in an instance of the parent (see *note 10.1.1::) can
+from then on be instantiated without failing the Elaboration_Check.
+
+ NOTES
+
+3
+ 4 The syntax of generic subprograms implies that a generic
+ subprogram body is always the completion of a declaration.
+
+ _Examples_
+
+4
+Example of a generic procedure body:
+
+5
+ procedure Exchange(U, V : in out Elem) is -- see *note 12.1::
+ T : Elem; -- the generic formal type
+ begin
+ T := U;
+ U := V;
+ V := T;
+ end Exchange;
+
+6
+Example of a generic function body:
+
+7
+ function Squaring(X : Item) return Item is -- see *note 12.1::
+ begin
+ return X*X; -- the formal operator "*"
+ end Squaring;
+
+8
+Example of a generic package body:
+
+9
+ package body On_Vectors is -- see *note 12.1::
+
+10
+ function Sum(A, B : Vector) return Vector is
+ Result : Vector(A'Range); -- the formal type Vector
+ Bias : constant Integer := B'First - A'First;
+ begin
+ if A'Length /= B'Length then
+ raise Length_Error;
+ end if;
+
+11
+ for N in A'Range loop
+ Result(N) := Sum(A(N), B(N + Bias)); -- the formal function Sum
+ end loop;
+ return Result;
+ end Sum;
+
+12
+ function Sigma(A : Vector) return Item is
+ Total : Item := A(A'First); -- the formal type Item
+ begin
+ for N in A'First + 1 .. A'Last loop
+ Total := Sum(Total, A(N)); -- the formal function Sum
+ end loop;
+ return Total;
+ end Sigma;
+ end On_Vectors;
+
+\1f
+File: aarm2012.info, Node: 12.3, Next: 12.4, Prev: 12.2, Up: 12
+
+12.3 Generic Instantiation
+==========================
+
+1
+[ An instance of a generic unit is declared by a generic_instantiation.]
+
+ _Language Design Principles_
+
+1.a/3
+ {AI05-0299-1AI05-0299-1} The legality of an instance should be
+ determinable without looking at the generic body. Likewise,
+ the legality of a generic body should be determinable without
+ looking at any instances. Thus, the generic_declaration forms
+ a contract between the body and the instances; if each obeys
+ the rules with respect to the generic_declaration, then no
+ legality problems will arise. This is really a special case
+ of the "legality determinable via semantic dependences"
+ Language Design Principle (see Clause *note 10::), given that
+ a generic_instantiation does not depend semantically upon the
+ generic body, nor vice-versa.
+
+1.b
+ Run-time issues are another story. For example, whether
+ parameter passing is by copy or by reference is determined in
+ part by the properties of the generic actuals, and thus cannot
+ be determined at compile time of the generic body. Similarly,
+ the contract model does not apply to Post-Compilation Rules.
+
+ _Syntax_
+
+2/3
+ {AI95-00218-03AI95-00218-03} {AI05-0183-1AI05-0183-1}
+ generic_instantiation ::=
+ package defining_program_unit_name is
+ new generic_package_name [generic_actual_part]
+ [aspect_specification];
+ | [overriding_indicator]
+ procedure defining_program_unit_name is
+ new generic_procedure_name [generic_actual_part]
+ [aspect_specification];
+ | [overriding_indicator]
+ function defining_designator is
+ new generic_function_name [generic_actual_part]
+ [aspect_specification];
+
+3
+ generic_actual_part ::=
+ (generic_association {, generic_association})
+
+4
+ generic_association ::=
+ [generic_formal_parameter_selector_name =>]
+ explicit_generic_actual_parameter
+
+5
+ explicit_generic_actual_parameter ::= expression | variable_name
+ | subprogram_name | entry_name | subtype_mark
+ | package_instance_name
+
+6
+ A generic_association is named or positional according to whether
+ or not the generic_formal_parameter_selector_name (*note 4.1.3:
+ S0099.) is specified. Any positional associations shall precede
+ any named associations.
+
+7/3
+{AI05-0004-1AI05-0004-1} The generic actual parameter is either the
+explicit_generic_actual_parameter given in a generic_association (*note
+12.3: S0277.) for each formal, or the corresponding default_expression
+(*note 3.7: S0063.) or default_name (*note 12.6: S0299.) if no
+generic_association (*note 12.3: S0277.) is given for the formal. When
+the meaning is clear from context, the term "generic actual," or simply
+"actual," is used as a synonym for "generic actual parameter" and also
+for the view denoted by one, or the value of one.
+
+ _Legality Rules_
+
+8
+In a generic_instantiation for a particular kind of program unit
+[(package, procedure, or function)], the name shall denote a generic
+unit of the corresponding kind [(generic package, generic procedure, or
+generic function, respectively)].
+
+9/3
+{AI05-0118-1AI05-0118-1} The generic_formal_parameter_selector_name of a
+named generic_association shall denote a
+generic_formal_parameter_declaration of the generic unit being
+instantiated. If two or more formal subprograms have the same defining
+name, then named associations are not allowed for the corresponding
+actuals.
+
+9.1/3
+{AI05-0118-1AI05-0118-1} The generic_formal_parameter_declaration for a
+positional generic_association is the parameter with the corresponding
+position in the generic_formal_part of the generic unit being
+instantiated.
+
+10
+A generic_instantiation shall contain at most one generic_association
+for each formal. Each formal without an association shall have a
+default_expression or subprogram_default.
+
+11
+In a generic unit Legality Rules are enforced at compile time of the
+generic_declaration and generic body, given the properties of the
+formals. In the visible part and formal part of an instance, Legality
+Rules are enforced at compile time of the generic_instantiation, given
+the properties of the actuals. In other parts of an instance, Legality
+Rules are not enforced; this rule does not apply when a given rule
+explicitly specifies otherwise.
+
+11.a/2
+ Reason: {AI95-00114-01AI95-00114-01} Since rules are checked
+ using the properties of the formals, and since these
+ properties do not always carry over to the actuals, we need to
+ check the rules again in the visible part of the instance.
+ For example, only if a tagged type is limited may an extension
+ of it have limited components in the record_extension_part. A
+ formal tagged limited type is limited, but the actual might be
+ nonlimited. Hence any rule that requires a tagged type to be
+ limited runs into this problem. Such rules are rare; in most
+ cases, the rules for matching of formals and actuals guarantee
+ that if the rule is obeyed in the generic unit, then it has to
+ be obeyed in the instance.
+
+11.a.1/3
+ {AI05-0005-1AI05-0005-1} Ada 2012 addendum: Such Legality
+ Rules are not as rare as the authors of Ada 95 hoped; there
+ are more than 30 of them known at this point. They are
+ indexed under "generic contract issue" and are associated with
+ the boilerplate "In addition to the places where Legality
+ Rules normally apply...". Indeed, there is only one known
+ rule where rechecking in the specification is needed and where
+ rechecking in the private part is not wanted (it is in *note
+ 3.4::, but even it needs rechecking when tagged types are
+ involved).
+
+11.b
+ Ramification: The "properties" of the formals are determined
+ without knowing anything about the actuals:
+
+11.c/1
+ * {8652/00958652/0095} {AI95-00034-01AI95-00034-01} A
+ formal derived subtype is constrained if and only if the
+ ancestor subtype is constrained. A formal array type is
+ constrained if and only if the declarations say so. A
+ formal private type is constrained if it does not have a
+ discriminant part. Other formal subtypes are
+ unconstrained, even though they might be constrained in
+ an instance.
+
+11.d
+ * A formal subtype can be indefinite, even though the copy
+ might be definite in an instance.
+
+11.e
+ * A formal object of mode in is not a static constant; in
+ an instance, the copy is static if the actual is.
+
+11.f
+ * A formal subtype is not static, even though the actual
+ might be.
+
+11.g
+ * Formal types are specific, even though the actual can be
+ class-wide.
+
+11.h
+ * The subtype of a formal object of mode in out is not
+ static. (This covers the case of AI83-00878.)
+
+11.i
+ * The subtype of a formal parameter of a formal subprogram
+ does not provide an applicable index constraint.
+
+11.j/3
+ * {AI05-0239-1AI05-0239-1} The profile of a formal
+ subprogram is not subtype conformant with any other
+ profile.
+
+11.k
+ * A generic formal function is not static.
+
+11.l
+ Ramification: The exceptions to the above rule about when
+ legality rules are enforced fall into these categories:
+
+11.m
+ * Some rules are checked in the generic declaration, and
+ then again in both the visible and private parts of the
+ instance:
+
+11.n
+ * The parent type of a record extension has to be
+ specific (see *note 3.9.1::). This rule is not
+ checked in the instance body.
+
+11.o
+ * The parent type of a private extension has to
+ be specific (see *note 7.3::). This rule is
+ not checked in the instance body.
+
+11.p/3
+ * {AI95-00402-01AI95-00402-01}
+ {AI05-0093-1AI05-0093-1} A type with an access
+ discriminant with a default_expression has to
+ be immutably limited. In the generic body, the
+ definition of immutably limited is adjusted in
+ an assume-the-worst manner (thus the rule is
+ checked that way).
+
+11.q
+ * In the declaration of a record extension, if
+ the parent type is nonlimited, then each of the
+ components of the record_extension_part have to
+ be nonlimited (see *note 3.9.1::). In the
+ generic body, this rule is checked in an
+ assume-the-worst manner.
+
+11.r
+ * A preelaborated library unit has to be
+ preelaborable (see *note 10.2.1::). In the
+ generic body, this rule is checked in an
+ assume-the-worst manner.
+
+11.r.1/2
+ {AI95-00402-01AI95-00402-01} The corrections made by the
+ Corrigendum added a number of such rules, and the
+ Amendment added many more. There doesn't seem to be much
+ value in repeating all of these rules here (as of this
+ writing, there are roughly 33 such rules). As noted
+ below, all such rules are indexed in the AARM.
+
+11.s
+ * For the accessibility rules, the formals have nothing to
+ say about the property in question. Like the above
+ rules, these rules are checked in the generic
+ declaration, and then again in both the visible and
+ private parts of the instance. In the generic body, we
+ have explicit rules that essentially assume the worst (in
+ the cases of type extensions and access-to-subprogram
+ types), and we have run-time checks (in the case of
+ access-to-object types). See *note 3.9.1::, *note
+ 3.10.2::, and *note 4.6::.
+
+11.t
+ We considered run-time checks for access-to-subprogram
+ types as well. However, this would present difficulties
+ for implementations that share generic bodies.
+
+11.u
+ * The rules requiring "reasonable" values for static
+ expressions are ignored when the expected type for the
+ expression is a descendant of a generic formal type other
+ than a generic formal derived type, and do not apply in
+ an instance.
+
+11.v
+ * The rule forbidding two explicit homographs in the same
+ declarative region does not apply in an instance of a
+ generic unit, except that it does apply in the
+ declaration of a record extension that appears in the
+ visible part of an instance.
+
+11.w
+ * Some rules do not apply at all in an instance, not even
+ in the visible part:
+
+11.x
+ * Body_stubs are not normally allowed to be
+ multiply nested, but they can be in instances.
+
+11.y
+ Each rule that is an exception is marked with "generic
+ contract issue;" look that up in the index to find them all.
+
+11.z
+ Ramification: The Legality Rules are the ones labeled Legality
+ Rules. We are talking about all Legality Rules in the entire
+ language here. Note that, with some exceptions, the legality
+ of a generic unit is checked even if there are no
+ instantiations of the generic unit.
+
+11.aa/3
+ Ramification: {AI05-0299-1AI05-0299-1} The Legality Rules are
+ described here, and the overloading rules were described
+ earlier in this subclause. Presumably, every Static Semantic
+ Item is sucked in by one of those. Thus, we have covered all
+ the compile-time rules of the language. There is no need to
+ say anything special about the Post-Compilation Rules or the
+ Dynamic Semantic Items.
+
+11.bb
+ Discussion: Here is an example illustrating how this rule is
+ checked: "In the declaration of a record extension, if the
+ parent type is nonlimited, then each of the components of the
+ record_extension_part shall be nonlimited."
+
+11.cc
+ generic
+ type Parent is tagged private;
+ type Comp is limited private;
+ package G1 is
+ type Extension is new Parent with
+ record
+ C : Comp; -- Illegal!
+ end record;
+ end G1;
+
+11.dd/1
+ The parent type is nonlimited, and the component type is
+ limited, which is illegal. It doesn't matter that one could
+ imagine writing an instantiation with the actual for Comp
+ being nonlimited -- we never get to the instance, because the
+ generic itself is illegal.
+
+11.ee
+ On the other hand:
+
+11.ff
+ generic
+ type Parent is tagged limited private; -- Parent is limited.
+ type Comp is limited private;
+ package G2 is
+ type Extension is new Parent with
+ record
+ C : Comp; -- OK.
+ end record;
+ end G2;
+
+11.gg
+ type Limited_Tagged is tagged limited null record;
+ type Non_Limited_Tagged is tagged null record;
+
+11.hh
+ type Limited_Untagged is limited null record;
+ type Non_Limited_Untagged is null record;
+
+11.ii
+ package Good_1 is new G2(Parent => Limited_Tagged,
+ Comp => Limited_Untagged);
+ package Good_2 is new G2(Parent => Non_Limited_Tagged,
+ Comp => Non_Limited_Untagged);
+ package Bad is new G2(Parent => Non_Limited_Tagged,
+ Comp => Limited_Untagged); -- Illegal!
+
+11.jj
+ The first instantiation is legal, because in the instance the
+ parent is limited, so the rule is not violated. Likewise, in
+ the second instantiation, the rule is not violated in the
+ instance. However, in the Bad instance, the parent type is
+ nonlimited, and the component type is limited, so this
+ instantiation is illegal.
+
+ _Static Semantics_
+
+12
+A generic_instantiation declares an instance; it is equivalent to the
+instance declaration (a package_declaration (*note 7.1: S0190.) or
+subprogram_declaration (*note 6.1: S0163.)) immediately followed by the
+instance body, both at the place of the instantiation.
+
+12.a
+ Ramification: The declaration and the body of the instance are
+ not "implicit" in the technical sense, even though you can't
+ see them in the program text. Nor are declarations within an
+ instance "implicit" (unless they are implicit by other rules).
+ This is necessary because implicit declarations have special
+ semantics that should not be attached to instances. For a
+ generic subprogram, the profile of a generic_instantiation is
+ that of the instance declaration, by the stated equivalence.
+
+12.b
+ Ramification: The visible and private parts of a package
+ instance are defined in *note 7.1::, "*note 7.1:: Package
+ Specifications and Declarations" and *note 12.7::, "*note
+ 12.7:: Formal Packages". The visible and private parts of a
+ subprogram instance are defined in *note 8.2::, "*note 8.2::
+ Scope of Declarations".
+
+13
+The instance is a copy of the text of the template. [Each use of a
+formal parameter becomes (in the copy) a use of the actual, as explained
+below.] An instance of a generic package is a package, that of a
+generic procedure is a procedure, and that of a generic function is a
+function.
+
+13.a
+ Ramification: An instance is a package or subprogram (because
+ we say so), even though it contains a copy of the
+ generic_formal_part, and therefore doesn't look like one.
+ This is strange, but it's OK, since the syntax rules are
+ overloading rules, and therefore do not apply in an instance.
+
+13.b
+ Discussion: We use a macro-expansion model, with some
+ explicitly-stated exceptions (see below). The main exception
+ is that the interpretation of each construct in a generic unit
+ (especially including the denotation of each name) is
+ determined when the declaration and body of the generic unit
+ (as opposed to the instance) are compiled, and in each
+ instance this interpretation is (a copy of) the template
+ interpretation. In other words, if a construct is interpreted
+ as a name denoting a declaration D, then in an instance, the
+ copy of the construct will still be a name, and will still
+ denote D (or a copy of D). From an implementation point of
+ view, overload resolution is performed on the template, and
+ not on each copy.
+
+13.c
+ We describe the substitution of generic actual parameters by
+ saying (in most cases) that the copy of each generic formal
+ parameter declares a view of the actual. Suppose a name in a
+ generic unit denotes a generic_formal_parameter_declaration.
+ The copy of that name in an instance will denote the copy of
+ that generic_formal_parameter_declaration in the instance.
+ Since the generic_formal_parameter_declaration in the instance
+ declares a view of the actual, the name will denote a view of
+ the actual.
+
+13.d/2
+ {AI95-00442-01AI95-00442-01} Other properties of the copy (for
+ example, staticness, categories to which types belong) are
+ recalculated for each instance; this is implied by the fact
+ that it's a copy.
+
+13.e/2
+ {AI95-00317-01AI95-00317-01} Although the generic_formal_part
+ is included in an instance, the declarations in the
+ generic_formal_part are only visible outside the instance in
+ the case of a generic formal package whose
+ formal_package_actual_part includes one or more <> indicators
+ -- see *note 12.7::.
+
+14
+The interpretation of each construct within a generic declaration or
+body is determined using the overloading rules when that generic
+declaration or body is compiled. In an instance, the interpretation of
+each (copied) construct is the same, except in the case of a name that
+denotes the generic_declaration or some declaration within the generic
+unit; the corresponding name in the instance then denotes the
+corresponding copy of the denoted declaration. The overloading rules do
+not apply in the instance.
+
+14.a
+ Ramification: See *note 8.6::, "*note 8.6:: The Context of
+ Overload Resolution" for definitions of "interpretation" and
+ "overloading rule."
+
+14.b
+ Even the generic_formal_parameter_declarations have
+ corresponding declarations in the instance, which declare
+ views of the actuals.
+
+14.c
+ Although the declarations in the instance are copies of those
+ in the generic unit, they often have quite different
+ properties, as explained below. For example a constant
+ declaration in the generic unit might declare a nonstatic
+ constant, whereas the copy of that declaration might declare a
+ static constant. This can happen when the staticness depends
+ on some generic formal.
+
+14.d
+ This rule is partly a ramification of the "current instance"
+ rule in *note 8.6::, "*note 8.6:: The Context of Overload
+ Resolution". Note that that rule doesn't cover the
+ generic_formal_part.
+
+14.e
+ Although the overloading rules are not observed in the
+ instance, they are, of course, observed in the _instantiation
+ in order to determine the interpretation of the constituents
+ of the _instantiation.
+
+14.f
+ Since children are considered to occur within their parent's
+ declarative region, the above rule applies to a name that
+ denotes a child of a generic unit, or a declaration inside
+ such a child.
+
+14.g
+ Since the Syntax Rules are overloading rules, it is possible
+ (legal) to violate them in an instance. For example, it is
+ possible for an instance body to occur in a
+ package_specification, even though the Syntax Rules forbid
+ bodies in package_specifications.
+
+15
+In an instance, a generic_formal_parameter_declaration declares a view
+whose properties are identical to those of the actual, except as
+specified in *note 12.4::, "*note 12.4:: Formal Objects" and *note
+12.6::, "*note 12.6:: Formal Subprograms". Similarly, for a declaration
+within a generic_formal_parameter_declaration, the corresponding
+declaration in an instance declares a view whose properties are
+identical to the corresponding declaration within the declaration of the
+actual.
+
+15.a
+ Ramification: In an instance, there are no "properties" of
+ types and subtypes that come from the formal. The primitive
+ operations of the type come from the formal, but these are
+ declarations in their own right, and are therefore handled
+ separately.
+
+15.b
+ Note that certain properties that come from the actuals are
+ irrelevant in the instance. For example, if an actual type is
+ of a class deeper in the derived-type hierarchy than the
+ formal, it is impossible to call the additional operations of
+ the deeper class in the instance, because any such call would
+ have to be a copy of some corresponding call in the generic
+ unit, which would have been illegal. However, it is sometimes
+ possible to reach into the specification of the instance from
+ outside, and notice such properties. For example, one could
+ pass an object declared in the instance specification to one
+ of the additional operations of the deeper type.
+
+15.c/2
+ {AI95-00114-01AI95-00114-01} A formal_type_declaration can
+ contain discriminant_specifications, a
+ formal_subprogram_declaration can contain
+ parameter_specifications, and a formal_package_declaration can
+ contain many kinds of declarations. These are all inside the
+ generic unit, and have corresponding declarations in the
+ instance.
+
+15.d
+ This rule implies, for example, that if a subtype in a generic
+ unit is a subtype of a generic formal subtype, then the
+ corresponding subtype in the instance is a subtype of the
+ corresponding actual subtype.
+
+15.e
+ For a generic_instantiation, if a generic actual is a static
+ [(scalar or string)] subtype, then each use of the
+ corresponding formal parameter within the specification of the
+ instance is considered to be static. (See AI83-00409.)
+
+15.f
+ Similarly, if a generic actual is a static expression and the
+ corresponding formal parameter has a static [(scalar or
+ string)] subtype, then each use of the formal parameter in the
+ specification of the instance is considered to be static.
+ (See AI83-00505.)
+
+15.g
+ If a primitive subprogram of a type derived from a generic
+ formal derived tagged type is not overriding (that is, it is a
+ new subprogram), it is possible for the copy of that
+ subprogram in an instance to override a subprogram inherited
+ from the actual. For example:
+
+15.h
+ type T1 is tagged record ... end record;
+
+15.i
+ generic
+ type Formal is new T1;
+ package G is
+ type Derived_From_Formal is new Formal with record ... end record;
+ procedure Foo(X : in Derived_From_Formal); -- Does not override anything.
+ end G;
+
+15.j
+ type T2 is new T1 with record ... end record;
+ procedure Foo(X : in T2);
+
+15.k
+ package Inst is new G(Formal => T2);
+
+15.l
+ In the instance Inst, the declaration of Foo for
+ Derived_From_Formal overrides the Foo inherited from T2.
+
+15.m/1
+ Implementation Note: {8652/00098652/0009}
+ {AI95-00137-01AI95-00137-01} For formal types, an
+ implementation that shares the code among multiple instances
+ of the same generic unit needs to beware that things like
+ parameter passing mechanisms (by-copy vs. by-reference) and
+ aspect_clauses are determined by the actual.
+
+16
+[Implicit declarations are also copied, and a name that denotes an
+implicit declaration in the generic denotes the corresponding copy in
+the instance. However, for a type declared within the visible part of
+the generic, a whole new set of primitive subprograms is implicitly
+declared for use outside the instance, and may differ from the copied
+set if the properties of the type in some way depend on the properties
+of some actual type specified in the instantiation. For example, if the
+type in the generic is derived from a formal private type, then in the
+instance the type will inherit subprograms from the corresponding actual
+type.
+
+17
+These new implicit declarations occur immediately after the type
+declaration in the instance, and override the copied ones. The copied
+ones can be called only from within the instance; the new ones can be
+called only from outside the instance, although for tagged types, the
+body of a new one can be executed by a call to an old one.]
+
+17.a
+ Proof: This rule is stated officially in *note 8.3::, "*note
+ 8.3:: Visibility".
+
+17.b
+ Ramification: The new ones follow from the class(es) of the
+ formal types. For example, for a type T derived from a
+ generic formal private type, if the actual is Integer, then
+ the copy of T in the instance has a "+" primitive operator,
+ which can be called from outside the instance (assuming T is
+ declared in the visible part of the instance).
+
+17.c
+ AI83-00398.
+
+17.d/2
+ {AI95-00442-01AI95-00442-01} Since an actual type is always in
+ the category determined for the formal, the new subprograms
+ hide all of the copied ones, except for a declaration of "/="
+ that corresponds to an explicit declaration of "=". Such "/="
+ operators are special, because unlike other implicit
+ declarations of primitive subprograms, they do not appear by
+ virtue of the class, but because of an explicit declaration of
+ "=". If the declaration of "=" is implicit (and therefore
+ overridden in the instance), then a corresponding implicitly
+ declared "/=" is also overridden. But if the declaration of
+ "=" is explicit (and therefore not overridden in the
+ instance), then a corresponding implicitly declared "/=" is
+ not overridden either, even though it's implicit.
+
+17.e
+ Note that the copied ones can be called from inside the
+ instance, even though they are hidden from all visibility,
+ because the names are resolved in the generic unit --
+ visibility is irrelevant for calls in the instance.
+
+18
+[In the visible part of an instance, an explicit declaration overrides
+an implicit declaration if they are homographs, as described in *note
+8.3::.] On the other hand, an explicit declaration in the private part
+of an instance overrides an implicit declaration in the instance, only
+if the corresponding explicit declaration in the generic overrides a
+corresponding implicit declaration in the generic. Corresponding rules
+apply to the other kinds of overriding described in *note 8.3::.
+
+18.a
+ Ramification: For example:
+
+18.b
+ type Ancestor is tagged null record;
+
+18.c
+ generic
+ type Formal is new Ancestor with private;
+ package G is
+ type T is new Formal with null record;
+ procedure P(X : in T); -- (1)
+ private
+ procedure Q(X : in T); -- (2)
+ end G;
+
+18.d
+ type Actual is new Ancestor with null record;
+ procedure P(X : in Actual);
+ procedure Q(X : in Actual);
+
+18.e
+ package Instance is new G(Formal => Actual);
+
+18.f
+ In the instance, the copy of P at (1) overrides Actual's P,
+ whereas the copy of Q at (2) does not override anything; in
+ implementation terms, it occupies a separate slot in the type
+ descriptor.
+
+18.g
+ Reason: The reason for this rule is so a programmer writing an
+ _instantiation need not look at the private part of the
+ generic in order to determine which subprograms will be
+ overridden.
+
+ _Post-Compilation Rules_
+
+19
+Recursive generic instantiation is not allowed in the following sense:
+if a given generic unit includes an instantiation of a second generic
+unit, then the instance generated by this instantiation shall not
+include an instance of the first generic unit [(whether this instance is
+generated directly, or indirectly by intermediate instantiations)].
+
+19.a
+ Discussion: Note that this rule is not a violation of the
+ generic contract model, because it is not a Legality Rule.
+ Some implementations may be able to check this rule at compile
+ time, but that requires access to all the bodies, so we allow
+ implementations to check the rule at link time.
+
+ _Dynamic Semantics_
+
+20
+For the elaboration of a generic_instantiation, each generic_association
+is first evaluated. If a default is used, an implicit
+generic_association is assumed for this rule. These evaluations are
+done in an arbitrary order, except that the evaluation for a default
+actual takes place after the evaluation for another actual if the
+default includes a name that denotes the other one. Finally, the
+instance declaration and body are elaborated.
+
+20.a
+ Ramification: Note that if the evaluation of a default depends
+ on some side effect of some other evaluation, the order is
+ still arbitrary.
+
+21
+For the evaluation of a generic_association the generic actual parameter
+is evaluated. Additional actions are performed in the case of a formal
+object of mode in (see *note 12.4::).
+
+21.a
+ To be honest: Actually, the actual is evaluated only if
+ evaluation is defined for that kind of construct -- we don't
+ actually "evaluate" subtype_marks.
+
+ NOTES
+
+22
+ 5 If a formal type is not tagged, then the type is treated as an
+ untagged type within the generic body. Deriving from such a type
+ in a generic body is permitted; the new type does not get a new tag
+ value, even if the actual is tagged. Overriding operations for
+ such a derived type cannot be dispatched to from outside the
+ instance.
+
+22.a
+ Ramification: If two overloaded subprograms declared in a
+ generic package specification differ only by the (formal) type
+ of their parameters and results, then there exist legal
+ instantiations for which all calls of these subprograms from
+ outside the instance are ambiguous. For example:
+
+22.b
+ generic
+ type A is (<>);
+ type B is private;
+ package G is
+ function Next(X : A) return A;
+ function Next(X : B) return B;
+ end G;
+
+22.c
+ package P is new G(A => Boolean, B => Boolean);
+ -- All calls of P.Next are ambiguous.
+
+22.d
+ Ramification: The following example illustrates some of the
+ subtleties of the substitution of formals and actuals:
+
+22.e
+ generic
+ type T1 is private;
+ -- A predefined "=" operator is implicitly declared here:
+ -- function "="(Left, Right : T1) return Boolean;
+ -- Call this "="1.
+ package G is
+ subtype S1 is T1; -- So we can get our hands on the type from
+ -- outside an instance.
+ type T2 is new T1;
+ -- An inherited "=" operator is implicitly declared here:
+ -- function "="(Left, Right : T2) return Boolean;
+ -- Call this "="2.
+
+22.f
+ T1_Obj : T1 := ...;
+ Bool_1 : Boolean := T1_Obj = T1_Obj;
+
+22.g
+ T2_Obj : T2 := ...;
+ Bool_2 : Boolean := T2_Obj = T2_Obj;
+ end G;
+ ...
+
+22.h
+ package P is
+ type My_Int is new Integer;
+ -- A predefined "=" operator is implicitly declared here:
+ -- function "="(Left, Right : My_Int) return Boolean;
+ -- Call this "="3.
+ function "="(X, Y : My_Int) return Boolean;
+ -- Call this "="4.
+ -- "="3 is hidden from all visibility by "="4.
+ -- Nonetheless, "="3 can "reemerge" in certain circumstances.
+ end P;
+ use P;
+ ...
+ package I is new G(T1 => My_Int); -- "="5 is declared in I (see below).
+ use I;
+
+22.i
+ Another_T1_Obj : S1 := 13; -- Can't denote T1, but S1 will do.
+ Bool_3 : Boolean := Another_T1_Obj = Another_T1_Obj;
+
+22.j
+ Another_T2_Obj : T2 := 45;
+ Bool_4 : Boolean := Another_T2_Obj = Another_T2_Obj;
+
+22.k
+ Double : T2 := T2_Obj + Another_T2_Obj;
+
+22.l
+ In the instance I, there is a copy of "="1 (call it "="1i) and
+ "="2 (call it "="2i). The "="1i and "="2i declare views of
+ the predefined "=" of My_Int (that is, "="3). In the
+ initialization of Bool_1 and Bool_2 in the generic unit G, the
+ names "=" denote "="1 and "="2, respectively. Therefore, the
+ copies of these names in the instances denote "="1i and "="2i,
+ respectively. Thus, the initialization of I.Bool_1 and
+ I.Bool_2 call the predefined equality operator of My_Int; they
+ will not call "="4.
+
+22.m
+ The declarations "="1i and "="2i are hidden from all
+ visibility. This prevents them from being called from outside
+ the instance.
+
+22.n
+ The declaration of Bool_3 calls "="4.
+
+22.o
+ The instance I also contains implicit declarations of the
+ primitive operators of T2, such as "=" (call it "="5) and "+".
+ These operations cannot be called from within the instance,
+ but the declaration of Bool_4 calls "="5.
+
+ _Examples_
+
+23
+Examples of generic instantiations (see *note 12.1::):
+
+24
+ procedure Swap is new Exchange(Elem => Integer);
+ procedure Swap is new Exchange(Character); -- Swap is overloaded
+ function Square is new Squaring(Integer); -- "*" of Integer used by default
+ function Square is new Squaring(Item => Matrix, "*" => Matrix_Product);
+ function Square is new Squaring(Matrix, Matrix_Product); -- same as previous
+
+25
+ package Int_Vectors is new On_Vectors(Integer, Table, "+");
+
+26
+Examples of uses of instantiated units:
+
+27
+ Swap(A, B);
+ A := Square(A);
+
+28
+ T : Table(1 .. 5) := (10, 20, 30, 40, 50);
+ N : Integer := Int_Vectors.Sigma(T); -- 150 (see *note 12.2::, "*note 12.2:: Generic Bodies" for the body of Sigma)
+
+29
+ use Int_Vectors;
+ M : Integer := Sigma(T); -- 150
+
+ _Inconsistencies With Ada 83_
+
+29.a
+ In Ada 83, all explicit actuals are evaluated before all
+ defaults, and the defaults are evaluated in the order of the
+ formal declarations. This ordering requirement is relaxed in
+ Ada 95.
+
+ _Incompatibilities With Ada 83_
+
+29.b
+ We have attempted to remove every violation of the contract
+ model. Any remaining contract model violations should be
+ considered bugs in the RM95. The unfortunate property of
+ reverting to the predefined operators of the actual types is
+ retained for upward compatibility. (Note that fixing this
+ would require subtype conformance rules.) However, tagged
+ types do not revert in this sense.
+
+ _Extensions to Ada 83_
+
+29.c
+ The syntax rule for explicit_generic_actual_parameter is
+ modified to allow a package_instance_name.
+
+ _Wording Changes from Ada 83_
+
+29.d
+ The fact that named associations cannot be used for two formal
+ subprograms with the same defining name is moved to AARM-only
+ material, because it is a ramification of other rules, and
+ because it is not of interest to the average user.
+
+29.e/2
+ {AI95-00114-01AI95-00114-01} The rule that "An explicit
+ explicit_generic_actual_parameter shall not be supplied more
+ than once for a given generic formal parameter" seems to be
+ missing from RM83, although it was clearly the intent.
+
+29.f
+ In the explanation that the instance is a copy of the
+ template, we have left out RM83-12.3(5)'s "apart from the
+ generic formal part", because it seems that things in the
+ formal part still need to exist in instances. This is
+ particularly true for generic formal packages, where you're
+ sometimes allowed to reach in and denote the formals of the
+ formal package from outside it. This simplifies the
+ explanation of what each name in an instance denotes: there
+ are just two cases: the declaration can be inside or outside
+ (where inside needs to include the generic unit itself). Note
+ that the RM83 approach of listing many cases (see
+ RM83-12.5(5-14)) would have become even more unwieldy with the
+ addition of generic formal packages, and the declarations that
+ occur therein.
+
+29.g
+ We have corrected the definition of the elaboration of a
+ generic_instantiation (RM83-12.3(17)); we don't elaborate
+ entities, and the instance is not "implicit."
+
+29.h
+ In RM83, there is a rule saying the formal and actual shall
+ match, and then there is much text defining what it means to
+ match. Here, we simply state all the latter text as rules.
+ For example, "A formal foo is matched by an actual greenish
+ bar" becomes "For a formal foo, the actual shall be a greenish
+ bar." This is necessary to split the Name Resolution Rules
+ from the Legality Rules. Besides, there's really no need to
+ define the concept of matching for generic parameters.
+
+ _Extensions to Ada 95_
+
+29.i/2
+ {AI95-00218-03AI95-00218-03} An overriding_indicator (see
+ *note 8.3.1::) is allowed on a subprogram instantiation.
+
+ _Extensions to Ada 2005_
+
+29.j/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a generic_instantiation. This is described in
+ *note 13.1.1::.
+
+ _Wording Changes from Ada 2005_
+
+29.k/3
+ {AI05-0118-1AI05-0118-1} Correction: Added a definition for
+ positional parameters, as this is missing from Ada 95 and Ada
+ 2005.
+
+\1f
+File: aarm2012.info, Node: 12.4, Next: 12.5, Prev: 12.3, Up: 12
+
+12.4 Formal Objects
+===================
+
+1
+[ A generic formal object can be used to pass a value or variable to a
+generic unit.]
+
+ _Language Design Principles_
+
+1.a
+ A generic formal object of mode in is like a constant
+ initialized to the value of the
+ explicit_generic_actual_parameter.
+
+1.b
+ A generic formal object of mode in out is like a renaming of
+ the explicit_generic_actual_parameter.
+
+ _Syntax_
+
+2/3
+ {AI95-00423-01AI95-00423-01} {AI05-0005-1AI05-0005-1}
+ {AI05-0183-1AI05-0183-1} formal_object_declaration ::=
+ defining_identifier_list : mode [null_exclusion]
+ subtype_mark [:= default_expression]
+ [aspect_specification];
+ | defining_identifier_list : mode access_definition [:=
+ default_expression]
+ [aspect_specification];
+
+ _Name Resolution Rules_
+
+3
+The expected type for the default_expression, if any, of a formal object
+is the type of the formal object.
+
+4
+For a generic formal object of mode in, the expected type for the actual
+is the type of the formal.
+
+5/2
+{AI95-00423-01AI95-00423-01} For a generic formal object of mode in out,
+the type of the actual shall resolve to the type determined by the
+subtype_mark, or for a formal_object_declaration with an
+access_definition, to a specific anonymous access type. If the
+anonymous access type is an access-to-object type, the type of the
+actual shall have the same designated type as that of the
+access_definition. If the anonymous access type is an
+access-to-subprogram type, the type of the actual shall have a
+designated profile which is type conformant with that of the
+access_definition.
+
+5.a
+ Reason: See the corresponding rule for
+ object_renaming_declarations for a discussion of the reason
+ for this rule.
+
+ _Legality Rules_
+
+6
+If a generic formal object has a default_expression, then the mode shall
+be in [(either explicitly or by default)]; otherwise, its mode shall be
+either in or in out.
+
+6.a
+ Ramification: Mode out is not allowed for generic formal
+ objects.
+
+7
+For a generic formal object of mode in, the actual shall be an
+expression. For a generic formal object of mode in out, the actual
+shall be a name that denotes a variable for which renaming is allowed
+(see *note 8.5.1::).
+
+7.a
+ To be honest: The part of this that requires an expression or
+ name is a Name Resolution Rule, but that's too pedantic to
+ worry about. (The part about denoting a variable, and
+ renaming being allowed, is most certainly not a Name
+ Resolution Rule.)
+
+8/2
+{AI95-00287-01AI95-00287-01} {AI95-00423-01AI95-00423-01} In the case
+where the type of the formal is defined by an access_definition, the
+type of the actual and the type of the formal:
+
+8.1/2
+ * {AI95-00423-01AI95-00423-01} shall both be access-to-object types
+ with statically matching designated subtypes and with both or
+ neither being access-to-constant types; or
+
+8.2/2
+ * {AI95-00423-01AI95-00423-01} shall both be access-to-subprogram
+ types with subtype conformant designated profiles.
+
+8.3/2
+{AI95-00423-01AI95-00423-01} For a formal_object_declaration with a
+null_exclusion or an access_definition that has a null_exclusion:
+
+8.4/2
+ * if the actual matching the formal_object_declaration denotes the
+ generic formal object of another generic unit G, and the
+ instantiation containing the actual occurs within the body of G or
+ within the body of a generic unit declared within the declarative
+ region of G, then the declaration of the formal object of G shall
+ have a null_exclusion;
+
+8.5/2
+ * otherwise, the subtype of the actual matching the
+ formal_object_declaration shall exclude null. In addition to the
+ places where Legality Rules normally apply (see *note 12.3::), this
+ rule applies also in the private part of an instance of a generic
+ unit.
+
+8.a/2
+ Reason: {AI95-00287-01AI95-00287-01}
+ {AI95-00423-01AI95-00423-01} This rule prevents "lying". Null
+ must never be the value of an object with an explicit
+ null_exclusion. The first bullet is an assume-the-worst rule
+ which prevents trouble in generic bodies (including bodies of
+ child units) when the subtype of the formal object excludes
+ null implicitly.
+
+ _Static Semantics_
+
+9/2
+{AI95-00255-01AI95-00255-01} {AI95-00423-01AI95-00423-01} A
+formal_object_declaration declares a generic formal object. The default
+mode is in. For a formal object of mode in, the nominal subtype is the
+one denoted by the subtype_mark or access_definition in the declaration
+of the formal. For a formal object of mode in out, its type is
+determined by the subtype_mark or access_definition in the declaration;
+its nominal subtype is nonstatic, even if the subtype_mark denotes a
+static subtype; for a composite type, its nominal subtype is
+unconstrained if the first subtype of the type is unconstrained[, even
+if the subtype_mark denotes a constrained subtype].
+
+9.a/2
+ Reason: {AI95-00255-01AI95-00255-01} We require that the
+ subtype is unconstrained because a formal in out acts like a
+ renaming, and thus the given subtype is ignored for purposes
+ of matching; any value of the type can be passed. Thus we can
+ assume only that the object is constrained if the first
+ subtype is constrained (and thus there can be no unconstrained
+ subtypes for the type). If we didn't do this, it would be
+ possible to rename or take 'Access of components that could
+ disappear due to an assignment to the whole object.
+
+9.b/2
+ Discussion: {AI95-00423-01AI95-00423-01} The two "even if"
+ clauses are OK even though they don't mention
+ access_definitions; an access subtype can neither be a static
+ subtype nor be a composite type.
+
+10/2
+{AI95-00269-01AI95-00269-01} In an instance, a formal_object_declaration
+of mode in is a full constant declaration and declares a new stand-alone
+constant object whose initialization expression is the actual, whereas a
+formal_object_declaration of mode in out declares a view whose
+properties are identical to those of the actual.
+
+10.a/2
+ Ramification: {AI95-00287-01AI95-00287-01} These rules imply
+ that generic formal objects of mode in are passed by copy (or
+ are built-in-place for a limited type), whereas generic formal
+ objects of mode in out are passed by reference.
+
+10.b
+ Initialization and finalization happen for the constant
+ declared by a formal_object_declaration of mode in as for any
+ constant; see *note 3.3.1::, "*note 3.3.1:: Object
+ Declarations" and *note 7.6::, "*note 7.6:: Assignment and
+ Finalization".
+
+10.c
+ In an instance, the subtype of a generic formal object of mode
+ in is as for the equivalent constant. In an instance, the
+ subtype of a generic formal object of mode in out is the
+ subtype of the corresponding generic actual.
+
+ _Dynamic Semantics_
+
+11
+For the evaluation of a generic_association for a formal object of mode
+in, a constant object is created, the value of the actual parameter is
+converted to the nominal subtype of the formal object, and assigned to
+the object[, including any value adjustment -- see *note 7.6::].
+
+11.a
+ Ramification: This includes evaluating the actual and doing a
+ subtype conversion, which might raise an exception.
+
+11.b
+ Discussion: The rule for evaluating a generic_association for
+ a formal object of mode in out is covered by the general
+ Dynamic Semantics rule in *note 12.3::.
+
+ NOTES
+
+12
+ 6 The constraints that apply to a generic formal object of mode in
+ out are those of the corresponding generic actual parameter (not
+ those implied by the subtype_mark that appears in the
+ formal_object_declaration). Therefore, to avoid confusion, it is
+ recommended that the name of a first subtype be used for the
+ declaration of such a formal object.
+
+12.a
+ Ramification: Constraint checks are done at instantiation time
+ for formal objects of mode in, but not for formal objects of
+ mode in out.
+
+ _Extensions to Ada 83_
+
+12.b
+ In Ada 83, it is forbidden to pass a (nongeneric) formal
+ parameter of mode out, or a subcomponent thereof, to a generic
+ formal object of mode in out. This restriction is removed in
+ Ada 95.
+
+ _Wording Changes from Ada 83_
+
+12.c
+ We make "mode" explicit in the syntax. RM83 refers to the
+ mode without saying what it is. This is also more uniform
+ with the way (nongeneric) formal parameters are defined.
+
+12.d
+ We considered allowing mode out in Ada 95, for uniformity with
+ (nongeneric) formal parameters. The semantics would be
+ identical for modes in out and out. (Note that generic formal
+ objects of mode in out are passed by reference. Note that for
+ (nongeneric) formal parameters that are allowed to be passed
+ by reference, the semantics of in out and out is the same.
+ The difference might serve as documentation. The same would
+ be true for generic formal objects, if out were allowed, so it
+ would be consistent.) We decided not to make this change,
+ because it does not produce any important benefit, and any
+ change has some cost.
+
+ _Extensions to Ada 95_
+
+12.e/2
+ {AI95-00287-01AI95-00287-01} A generic formal in object can
+ have a limited type. The actual for such an object must be
+ built-in-place via a function_call or aggregate, see *note
+ 7.5::.
+
+12.f/2
+ {AI95-00423-01AI95-00423-01} A generic formal object can have
+ a null_exclusion or an anonymous access type.
+
+ _Wording Changes from Ada 95_
+
+12.g/2
+ {AI95-00255-01AI95-00255-01} Clarified that the nominal
+ subtype of a composite formal in out object is unconstrained
+ if the first subtype of the type is unconstrained.
+
+12.h/2
+ {AI95-00269-01AI95-00269-01} Clarified that a formal in object
+ can be static when referenced from outside of the instance (by
+ declaring such an object to be a full constant declaration).
+
+ _Extensions to Ada 2005_
+
+12.i/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a formal_object_declaration. This is described in
+ *note 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 12.5, Next: 12.6, Prev: 12.4, Up: 12
+
+12.5 Formal Types
+=================
+
+1/2
+{AI95-00442-01AI95-00442-01} [A generic formal subtype can be used to
+pass to a generic unit a subtype whose type is in a certain category of
+types.]
+
+1.a
+ Reason: We considered having intermediate syntactic categories
+ formal_integer_type_definition, formal_real_type_definition,
+ and formal_fixed_point_definition, to be more uniform with the
+ syntax rules for non-generic-formal types. However, that
+ would make the rules for formal types slightly more
+ complicated, and it would cause confusion, since
+ formal_discrete_type_definition would not fit into the scheme
+ very well.
+
+ _Syntax_
+
+2/3
+ {AI05-0213-1AI05-0213-1} formal_type_declaration ::=
+ formal_complete_type_declaration
+ | formal_incomplete_type_declaration
+
+2.1/3
+ {AI05-0183-1AI05-0183-1} {AI05-0213-1AI05-0213-1}
+ formal_complete_type_declaration ::=
+ type defining_identifier[discriminant_part] is
+ formal_type_definition
+ [aspect_specification];
+
+2.2/3
+ {AI05-0213-1AI05-0213-1} formal_incomplete_type_declaration ::=
+ type defining_identifier[discriminant_part] [is tagged];
+
+3/2
+ {AI95-00251-01AI95-00251-01} formal_type_definition ::=
+ formal_private_type_definition
+ | formal_derived_type_definition
+ | formal_discrete_type_definition
+ | formal_signed_integer_type_definition
+ | formal_modular_type_definition
+ | formal_floating_point_definition
+ | formal_ordinary_fixed_point_definition
+ | formal_decimal_fixed_point_definition
+ | formal_array_type_definition
+ | formal_access_type_definition
+ | formal_interface_type_definition
+
+ _Legality Rules_
+
+4
+For a generic formal subtype, the actual shall be a subtype_mark; it
+denotes the (generic) actual subtype.
+
+4.a
+ Ramification: When we say simply "formal" or "actual" (for a
+ generic formal that denotes a subtype) we're talking about the
+ subtype, not the type, since a name that denotes a
+ formal_type_declaration denotes a subtype, and the
+ corresponding actual also denotes a subtype.
+
+ _Static Semantics_
+
+5
+A formal_type_declaration declares a (generic) formal type, and its
+first subtype, the (generic) formal subtype.
+
+5.a
+ Ramification: A subtype (other than the first subtype) of a
+ generic formal type is not a generic formal subtype.
+
+6/3
+{AI95-00442-01AI95-00442-01} {AI05-0213-1AI05-0213-1} The form of a
+formal_type_definition determines a category (of types) to which the
+formal type belongs. For a formal_private_type_definition the reserved
+words tagged and limited indicate the category of types (see *note
+12.5.1::). The reserved word tagged also plays this role in the case of
+a formal_incomplete_type_declaration. For a
+formal_derived_type_definition the category of types is the derivation
+class rooted at the ancestor type. For other formal types, the name of
+the syntactic category indicates the category of types; a
+formal_discrete_type_definition defines a discrete type, and so on.
+
+6.a
+ Reason: This rule is clearer with the flat syntax rule for
+ formal_type_definition given above. Adding
+ formal_integer_type_definition and others would make this rule
+ harder to state clearly.
+
+6.b/2
+ {AI95-00442-01AI95-00442-01} We use "category' rather than
+ "class" above, because the requirement that classes are closed
+ under derivation is not important here. Moreover, there are
+ interesting categories that are not closed under derivation.
+ For instance, limited and interface are categories that do not
+ form classes.
+
+ _Legality Rules_
+
+7/2
+{AI95-00442-01AI95-00442-01} The actual type shall be in the category
+determined for the formal.
+
+7.a/2
+ Ramification: {AI95-00442-01AI95-00442-01} For example, if the
+ category determined for the formal is the category of all
+ discrete types, then the actual has to be discrete.
+
+7.b/2
+ {AI95-00442-01AI95-00442-01} Note that this rule does not
+ require the actual to belong to every category to which the
+ formal belongs. For example, formal private types are in the
+ category of composite types, but the actual need not be
+ composite. Furthermore, one can imagine an infinite number of
+ categories that are just arbitrary sets of types (even though
+ we don't give them names, since they are uninteresting). We
+ don't want this rule to apply to those categories.
+
+7.c/2
+ {AI95-00114-01AI95-00114-01} {AI95-00442-01AI95-00442-01}
+ "Limited" is not an "interesting" category, but "nonlimited"
+ is; it is legal to pass a nonlimited type to a limited formal
+ type, but not the other way around. The reserved word limited
+ really represents a category containing both limited and
+ nonlimited types. "Private" is not a category for this
+ purpose; a generic formal private type accepts both private
+ and nonprivate actual types.
+
+7.d/2
+ {AI95-00442-01AI95-00442-01} It is legal to pass a class-wide
+ subtype as the actual if it is in the right category, so long
+ as the formal has unknown discriminants.
+
+ _Static Semantics_
+
+8/3
+{8652/00378652/0037} {AI95-00043-01AI95-00043-01}
+{AI95-00233-01AI95-00233-01} {AI95-00442-01AI95-00442-01}
+{AI05-0029-1AI05-0029-1} [The formal type also belongs to each category
+that contains the determined category.] The primitive subprograms of
+the type are as for any type in the determined category. For a formal
+type other than a formal derived type, these are the predefined
+operators of the type. For an elementary formal type, the predefined
+operators are implicitly declared immediately after the declaration of
+the formal type. For a composite formal type, the predefined operators
+are implicitly declared either immediately after the declaration of the
+formal type, or later immediately within the declarative region in which
+the type is declared according to the rules of *note 7.3.1::. In an
+instance, the copy of such an implicit declaration declares a view of
+the predefined operator of the actual type, even if this operator has
+been overridden for the actual type and even if it is never declared for
+the actual type. [The rules specific to formal derived types are given
+in *note 12.5.1::.]
+
+8.a/2
+ Ramification: {AI95-00442-01AI95-00442-01} All properties of
+ the type are as for any type in the category. Some examples:
+ The primitive operations available are as defined by the
+ language for each category. The form of constraint applicable
+ to a formal type in a subtype_indication depends on the
+ category of the type as for a nonformal type. The formal type
+ is tagged if and only if it is declared as a tagged private
+ type, or as a type derived from a (visibly) tagged type.
+ (Note that the actual type might be tagged even if the formal
+ type is not.)
+
+8.b/3
+ Reason: {AI05-0029-1AI05-0029-1} The somewhat cryptic phrase
+ "even if it is never declared" is intended to deal with the
+ following oddity:
+
+8.c/3
+ package Q is
+ type T is limited private;
+ private
+ type T is range 1 .. 10;
+ end Q;
+
+8.d/3
+ generic
+ type A is array (Positive range <>) of T;
+ package Q.G is
+ A1, A2 : A (1 .. 1);
+ private
+ B : Boolean := A1 = A2;
+ end Q.G;
+
+8.e/3
+ with Q.G;
+ package R is
+ type C is array (Positive range <>) of Q.T;
+
+8.f/3
+ package I is new Q.G (C); -- Where is the predefined "=" for C?
+ end R;
+
+8.g/3
+ An "=" is available for the formal type A in the private part
+ of Q.G. However, no "=" operator is ever declared for type C,
+ because its component type Q.T is limited. Still, in the
+ instance I the name "=" declares a view of the "=" for C which
+ exists-but-is-never-declared.
+
+ NOTES
+
+9
+ 7 Generic formal types, like all types, are not named. Instead, a
+ name can denote a generic formal subtype. Within a generic unit, a
+ generic formal type is considered as being distinct from all other
+ (formal or nonformal) types.
+
+9.a
+ Proof: This follows from the fact that each
+ formal_type_declaration declares a type.
+
+10
+ 8 A discriminant_part is allowed only for certain kinds of types,
+ and therefore only for certain kinds of generic formal types. See
+ *note 3.7::.
+
+10.a
+ Ramification: The term "formal floating point type" refers to
+ a type defined by a formal_floating_point_definition. It does
+ not include a formal derived type whose ancestor is floating
+ point. Similar terminology applies to the other kinds of
+ formal_type_definition.
+
+ _Examples_
+
+11
+Examples of generic formal types:
+
+12
+ type Item is private;
+ type Buffer(Length : Natural) is limited private;
+
+13
+ type Enum is (<>);
+ type Int is range <>;
+ type Angle is delta <>;
+ type Mass is digits <>;
+
+14
+ type Table is array (Enum) of Item;
+
+15
+Example of a generic formal part declaring a formal integer type:
+
+16
+ generic
+ type Rank is range <>;
+ First : Rank := Rank'First;
+ Second : Rank := First + 1; -- the operator "+" of the type Rank
+
+ _Wording Changes from Ada 83_
+
+16.a
+ RM83 has separate sections "Generic Formal Xs" and "Matching
+ Rules for Formal Xs" (for various X's) with most of the text
+ redundant between the two. We have combined the two in order
+ to reduce the redundancy. In RM83, there is no "Matching
+ Rules for Formal Types" section; nor is there a "Generic
+ Formal Y Types" section (for Y = Private, Scalar, Array, and
+ Access). This causes, for example, the duplication across all
+ the "Matching Rules for Y Types" sections of the rule that the
+ actual passed to a formal type shall be a subtype; the new
+ organization avoids that problem.
+
+16.b
+ The matching rules are stated more concisely.
+
+16.c
+ We no longer consider the multiplying operators that deliver a
+ result of type universal_fixed to be predefined for the
+ various types; there is only one of each in package Standard.
+ Therefore, we need not mention them here as RM83 had to.
+
+ _Wording Changes from Ada 95_
+
+16.d/2
+ {8652/00378652/0037} {AI95-00043-01AI95-00043-01}
+ {AI95-00233-01AI95-00233-01} Corrigendum 1 corrected the
+ wording to properly define the location where operators are
+ defined for formal array types. The wording here was
+ inconsistent with that in *note 7.3.1::, "*note 7.3.1::
+ Private Operations". For the Amendment, this wording was
+ corrected again, because it didn't reflect the Corrigendum 1
+ revisions in *note 7.3.1::.
+
+16.e/2
+ {AI95-00251-01AI95-00251-01} Formal interface types are
+ defined; see *note 12.5.5::, "*note 12.5.5:: Formal Interface
+ Types".
+
+16.f/2
+ {AI95-00442-01AI95-00442-01} We use "determines a category"
+ rather than class, since not all interesting properties form a
+ class.
+
+ _Extensions to Ada 2005_
+
+16.g/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a formal_type_declaration. This is described in
+ *note 13.1.1::.
+
+ _Wording Changes from Ada 2005_
+
+16.h/3
+ {AI05-0029-1AI05-0029-1} Correction: Updated the wording to
+ acknowledge the possibility of operations that are never
+ declared for an actual type but still can be used inside of a
+ generic unit.
+
+16.i/3
+ {AI05-0213-1AI05-0213-1} {AI05-0299-1AI05-0299-1} Formal
+ incomplete types are added; these are documented as an
+ extension in the next subclause.
+
+* Menu:
+
+* 12.5.1 :: Formal Private and Derived Types
+* 12.5.2 :: Formal Scalar Types
+* 12.5.3 :: Formal Array Types
+* 12.5.4 :: Formal Access Types
+* 12.5.5 :: Formal Interface Types
+
+\1f
+File: aarm2012.info, Node: 12.5.1, Next: 12.5.2, Up: 12.5
+
+12.5.1 Formal Private and Derived Types
+---------------------------------------
+
+1/3
+{AI95-00442-01AI95-00442-01} {AI05-0213-1AI05-0213-1} [In its most
+general form, the category determined for a formal private type is all
+types, but the category can be restricted to only nonlimited types or to
+only tagged types. Similarly, the category for a formal incomplete type
+is all types but the category can be restricted to only tagged types;
+unlike other formal types, the actual type does not need to be able to
+be frozen (see *note 13.14::). The category determined for a formal
+derived type is the derivation class rooted at the ancestor type.]
+
+1.a/3
+ Proof: {AI95-00442-01AI95-00442-01} {AI05-0213-1AI05-0213-1}
+ The first two rules are given normatively below, and the third
+ rule is given normatively in *note 12.5::; they are repeated
+ here to give a capsule summary of what this subclause is
+ about.
+
+1.b/3
+ Ramification: {AI05-0213-1AI05-0213-1} Since the actual of a
+ formal incomplete type does not need to be able to be frozen,
+ the actual can be an incomplete type or a partial view before
+ its completion.
+
+ _Syntax_
+
+2
+ formal_private_type_definition ::=
+ [[abstract] tagged] [limited] private
+
+3/2
+ {AI95-00251-01AI95-00251-01} {AI95-00419-01AI95-00419-01}
+ {AI95-00443-01AI95-00443-01} formal_derived_type_definition ::=
+ [abstract] [limited | synchronized] new subtype_mark [[and
+ interface_list]with private]
+
+ _Legality Rules_
+
+4
+If a generic formal type declaration has a known_discriminant_part, then
+it shall not include a default_expression for a discriminant.
+
+4.a
+ Ramification: Consequently, a generic formal subtype with a
+ known_discriminant_part is an indefinite subtype, so the
+ declaration of a stand-alone variable has to provide a
+ constraint on such a subtype, either explicitly, or by its
+ initial value.
+
+5/3
+{AI95-00401-01AI95-00401-01} {AI95-00419-01AI95-00419-01}
+{AI95-00443-01AI95-00443-01} {AI05-0237-1AI05-0237-1} The ancestor
+subtype of a formal derived type is the subtype denoted by the
+subtype_mark of the formal_derived_type_definition. For a formal
+derived type declaration, the reserved words with private shall appear
+if and only if the ancestor type is a tagged type; in this case the
+formal derived type is a private extension of the ancestor type and the
+ancestor shall not be a class-wide type. [Similarly, an interface_list
+or the optional reserved words abstract or synchronized shall appear
+only if the ancestor type is a tagged type]. The reserved word limited
+or synchronized shall appear only if the ancestor type [and any
+progenitor types] are limited types. The reserved word synchronized
+shall appear (rather than limited) if the ancestor type or any of the
+progenitor types are synchronized interfaces. The ancestor type shall
+be a limited interface if the reserved word synchronized appears.
+
+5.a
+ Reason: We use the term "ancestor" here instead of "parent"
+ because the actual can be any descendant of the ancestor, not
+ necessarily a direct descendant.
+
+5.b/3
+ {AI95-00419-01AI95-00419-01} {AI05-0005-1AI05-0005-1} We
+ require the ancestor type to be limited when limited appears
+ so that we avoid oddities like limited integer types.
+ Normally, limited means "match anything" for a generic formal,
+ but it was felt that allowing limited elementary types to be
+ declared was just too weird. Integer still matches a formal
+ limited private type; it is only a problem when the type is
+ known to be elementary. Note that the progenitors are
+ required to be limited by rules in *note 3.9.4::, thus that
+ part of the rule is redundant.
+
+5.c/2
+ {AI95-00443-01AI95-00443-01} We require that synchronized
+ appear if the ancestor or any of the progenitors are
+ synchronized, so that property is explicitly given in the
+ program text - it is not automatically inherited from the
+ ancestors. However, it can be given even if neither the
+ ancestor nor the progenitors are synchronized.
+
+5.1/3
+{AI95-00251-01AI95-00251-01} {AI95-00401-01AI95-00401-01}
+{AI95-00443-01AI95-00443-01} {AI05-0087-1AI05-0087-1} The actual type
+for a formal derived type shall be a descendant of [the ancestor type
+and] every progenitor of the formal type. If the formal type is
+nonlimited, the actual type shall be nonlimited. If the reserved word
+synchronized appears in the declaration of the formal derived type, the
+actual type shall be a synchronized tagged type.
+
+5.d/2
+ Proof: The actual type has to be a descendant of the ancestor
+ type, in order that it be in the correct class. Thus, that
+ part of the rule is redundant.
+
+5.e/3
+ Discussion: {AI05-0005-1AI05-0005-1} For a nonformal private
+ extension, we require the partial view to be synchronized if
+ the full view is synchronized tagged. This does not apply to
+ a formal private extension -- it is OK if the formal is not
+ synchronized. Any attempt to extend the formal type will be
+ rechecked in the instance, where the rule disallowing
+ extending a synchronized noninterface type will be enforced.
+ This is consistent with the "no hidden interfaces" rule also
+ applying only to nonformal private extensions, as well as the
+ rule that a limited nonformal private extension implies a
+ limited full type. Formal private extensions are exempted
+ from all these rules to enable the construction of generics
+ that can be used with the widest possible range of types. In
+ particular, an indefinite tagged limited formal private type
+ can match any "concrete" actual tagged type.
+
+5.f/3
+ {AI05-0087-1AI05-0087-1} A type (including formal types)
+ derived from a limited interface could be nonlimited; we do
+ not want a limited type derived from such an interface to
+ match a nonlimited formal derived type. Otherwise, we could
+ assign limited objects. Thus, we have to explicitly ban this
+ case.
+
+6/3
+{AI05-0213-1AI05-0213-1} If a formal private or derived subtype is
+definite, then the actual subtype shall also be definite.
+
+6.a
+ Ramification: On the other hand, for an indefinite formal
+ subtype, the actual can be either definite or indefinite.
+
+6.1/3
+{AI05-0213-1AI05-0213-1} A formal_incomplete_type_declaration declares a
+formal incomplete type. The only view of a formal incomplete type is an
+incomplete view. [Thus, a formal incomplete type is subject to the same
+usage restrictions as any other incomplete type -- see *note 3.10.1::.]
+
+7
+For a generic formal derived type with no discriminant_part:
+
+8
+ * If the ancestor subtype is constrained, the actual subtype shall be
+ constrained, and shall be statically compatible with the ancestor;
+
+8.a
+ Ramification: In other words, any constraint on the ancestor
+ subtype is considered part of the "contract."
+
+9
+ * If the ancestor subtype is an unconstrained access or composite
+ subtype, the actual subtype shall be unconstrained.
+
+9.a
+ Reason: This rule ensures that if a composite constraint is
+ allowed on the formal, one is also allowed on the actual. If
+ the ancestor subtype is an unconstrained scalar subtype, the
+ actual is allowed to be constrained, since a scalar constraint
+ does not cause further constraints to be illegal.
+
+10
+ * If the ancestor subtype is an unconstrained discriminated subtype,
+ then the actual shall have the same number of discriminants, and
+ each discriminant of the actual shall correspond to a discriminant
+ of the ancestor, in the sense of *note 3.7::.
+
+10.a
+ Reason: This ensures that if a discriminant constraint is
+ given on the formal subtype, the corresponding constraint in
+ the instance will make sense, without additional run-time
+ checks. This is not necessary for arrays, since the bounds
+ cannot be overridden in a type extension. An
+ unknown_discriminant_part may be used to relax these matching
+ requirements.
+
+10.1/2
+ * {AI95-00231-01AI95-00231-01} If the ancestor subtype is an access
+ subtype, the actual subtype shall exclude null if and only if the
+ ancestor subtype excludes null.
+
+10.b/2
+ Reason: We require that the "excludes null" property match,
+ because it would be difficult to write a correct generic for a
+ formal access type without knowing this property. Many
+ typical algorithms and techniques will not work for a subtype
+ that excludes null (setting an unused component to null,
+ default-initialized objects, and so on). We want this sort of
+ requirement to be reflected in the contract of the generic.
+
+11/3
+{AI05-0213-1AI05-0213-1} The declaration of a formal derived type shall
+not have a known_discriminant_part. For a generic formal private or
+incomplete type with a known_discriminant_part:
+
+12
+ * The actual type shall be a type with the same number of
+ discriminants.
+
+13
+ * The actual subtype shall be unconstrained.
+
+14
+ * The subtype of each discriminant of the actual type shall
+ statically match the subtype of the corresponding discriminant of
+ the formal type.
+
+14.a
+ Reason: We considered defining the first and third rule to be
+ called "subtype conformance" for discriminant_parts. We
+ rejected that idea, because it would require implicit
+ (inherited) discriminant_parts, which seemed like too much
+ mechanism.
+
+15
+[For a generic formal type with an unknown_discriminant_part, the actual
+may, but need not, have discriminants, and may be definite or
+indefinite.]
+
+ _Static Semantics_
+
+16/2
+{AI95-00442-01AI95-00442-01} The category determined for a formal
+private type is as follows:
+
+17/2
+ Type Definition Determined Category
+
+ limited private the category of all types
+ private the category of all nonlimited types
+ tagged limited private the category of all tagged types
+ tagged private the category of all nonlimited tagged types
+
+18
+[The presence of the reserved word abstract determines whether the
+actual type may be abstract.]
+
+18.1/3
+{AI05-0213-1AI05-0213-1} The category determined for a formal incomplete
+type is the category of all types, unless the formal_type_declaration
+includes the reserved word tagged; in this case, it is the category of
+all tagged types.
+
+19
+A formal private or derived type is a private or derived type,
+respectively. A formal derived tagged type is a private extension. [A
+formal private or derived type is abstract if the reserved word abstract
+appears in its declaration.]
+
+20/3
+{AI95-00233-01AI95-00233-01} {AI05-0110-1AI05-0110-1} For a formal
+derived type, the characteristics (including components, but excluding
+discriminants if there is a new discriminant_part), predefined
+operators, and inherited user-defined primitive subprograms are
+determined by its ancestor type and its progenitor types (if any), in
+the same way that those of a derived type are determined by those of its
+parent type and its progenitor types (see *note 3.4:: and *note
+7.3.1::).
+
+21/3
+{8652/00388652/0038} {AI95-00202AI95-00202} {AI95-00233-01AI95-00233-01}
+{AI95-00401-01AI95-00401-01} {AI05-0029-1AI05-0029-1}
+{AI05-0110-1AI05-0110-1} In an instance, the copy of an implicit
+declaration of a primitive subprogram of a formal derived type declares
+a view of the corresponding primitive subprogram of the ancestor or
+progenitor of the formal derived type, even if this primitive has been
+overridden for the actual type and even if it is never declared for the
+actual type. When the ancestor or progenitor of the formal derived type
+is itself a formal type, the copy of the implicit declaration declares a
+view of the corresponding copied operation of the ancestor or
+progenitor. [In the case of a formal private extension, however, the
+tag of the formal type is that of the actual type, so if the tag in a
+call is statically determined to be that of the formal type, the body
+executed will be that corresponding to the actual type.]
+
+21.a/3
+ Ramification: {AI95-00401-01AI95-00401-01}
+ {AI05-0239-1AI05-0239-1} The above rule defining the
+ properties of primitive subprograms in an instance applies
+ even if the subprogram has been overridden or hidden for the
+ actual type. This rule is necessary for untagged types,
+ because their primitive subprograms might have been overridden
+ by operations that are not subtype conformant with the
+ operations defined for the class. For tagged types, the rule
+ still applies, but the primitive subprograms will dispatch to
+ the appropriate implementation based on the type and tag of
+ the operands. Even for tagged types, the formal parameter
+ names and default_expressions are determined by those of the
+ primitive subprograms of the specified ancestor type (or
+ progenitor type, for subprograms inherited from an interface
+ type).
+
+22/1
+For a prefix S that denotes a formal indefinite subtype, the following
+attribute is defined:
+
+23/3
+S'Definite
+ {AI05-0264-1AI05-0264-1} S'Definite yields True if the
+ actual subtype corresponding to S is definite; otherwise,
+ it yields False. The value of this attribute is of the
+ predefined type Boolean.
+
+23.a/2
+ Discussion: {AI95-00114-01AI95-00114-01} Whether an actual
+ subtype is definite or indefinite may have a major effect on
+ the algorithm used in a generic. For example, in a generic
+ I/O package, whether to use fixed-length or variable-length
+ records could depend on whether the actual is definite or
+ indefinite. This attribute is essentially a replacement for
+ the Constrained attribute, which is now considered obsolete.
+
+ _Dynamic Semantics_
+
+23.1/3
+{AI95-00158-01AI95-00158-01} {AI05-0071-1AI05-0071-1} In the case where
+a formal type has unknown discriminants, and the actual type is a
+class-wide type T'Class:
+
+23.2/2
+ * {AI95-00158-01AI95-00158-01} For the purposes of defining the
+ primitive operations of the formal type, each of the primitive
+ operations of the actual type is considered to be a subprogram
+ (with an intrinsic calling convention -- see *note 6.3.1::) whose
+ body consists of a dispatching call upon the corresponding
+ operation of T, with its formal parameters as the actual
+ parameters. If it is a function, the result of the dispatching
+ call is returned.
+
+23.3/2
+ * {AI95-00158-01AI95-00158-01} If the corresponding operation of T
+ has no controlling formal parameters, then the controlling tag
+ value is determined by the context of the call, according to the
+ rules for tag-indeterminate calls (see *note 3.9.2:: and *note
+ 5.2::). In the case where the tag would be statically determined
+ to be that of the formal type, the call raises Program_Error. If
+ such a function is renamed, any call on the renaming raises
+ Program_Error.
+
+23.b/2
+ Discussion: As it states in *note 6.3.1::, the convention of
+ an inherited subprogram of a generic formal tagged type with
+ unknown discriminants is intrinsic.
+
+23.c/2
+ In the case of a corresponding primitive of T with no
+ controlling formal parameters, the context of the call
+ provides the controlling tag value for the dispatch. If no
+ tag is provided by context, Program_Error is raised rather
+ than resorting to a nondispatching call. For example:
+
+23.d/2
+ generic
+ type NT(<>) is new T with private;
+ -- Assume T has operation "function Empty return T;"
+ package G is
+ procedure Test(X : in out NT);
+ end G;
+
+23.e/2
+ package body G is
+ procedure Test(X : in out NT) is
+ begin
+ X := Empty; -- Dispatching based on X'Tag takes
+ -- place if actual is class-wide.
+ declare
+ Y : NT := Empty;
+ -- If actual is class-wide, this raises Program_Error
+ -- as there is no tag provided by context.
+ begin
+ X := Y; -- We never get this far.
+ end;
+ end Test;
+ end G;
+
+23.f/2
+ type T1 is new T with null record;
+ package I is new G(T1'Class);
+
+ NOTES
+
+24/2
+ 9 {AI95-00442-01AI95-00442-01} In accordance with the general rule
+ that the actual type shall belong to the category determined for
+ the formal (see *note 12.5::, "*note 12.5:: Formal Types"):
+
+25
+ * If the formal type is nonlimited, then so shall be the actual;
+
+26
+ * For a formal derived type, the actual shall be in the class
+ rooted at the ancestor subtype.
+
+27
+ 10 The actual type can be abstract only if the formal type is
+ abstract (see *note 3.9.3::).
+
+27.a
+ Reason: This is necessary to avoid contract model problems,
+ since one or more of its primitive subprograms are abstract;
+ it is forbidden to create objects of the type, or to declare
+ functions returning the type.
+
+27.b
+ Ramification: On the other hand, it is OK to pass a
+ nonabstract actual to an abstract formal -- abstract on the
+ formal indicates that the actual might be abstract.
+
+28
+ 11 If the formal has a discriminant_part, the actual can be either
+ definite or indefinite. Otherwise, the actual has to be definite.
+
+ _Incompatibilities With Ada 83_
+
+28.a
+ Ada 83 does not have unknown_discriminant_parts, so it allows
+ indefinite subtypes to be passed to definite formals, and
+ applies a legality rule to the instance body. This is a
+ contract model violation. Ada 95 disallows such cases at the
+ point of the instantiation. The workaround is to add (<>) as
+ the discriminant_part of any formal subtype if it is intended
+ to be used with indefinite actuals. If that's the intent,
+ then there can't be anything in the generic body that would
+ require a definite subtype.
+
+28.b
+ The check for discriminant subtype matching is changed from a
+ run-time check to a compile-time check.
+
+ _Extensions to Ada 95_
+
+28.c/2
+ {AI95-00251-01AI95-00251-01} {AI95-00401-01AI95-00401-01}
+ {AI95-00419-01AI95-00419-01} {AI95-00443-01AI95-00443-01} A
+ generic formal derived type can include progenitors
+ (interfaces) as well as a primary ancestor. It also may
+ include limited to indicate that it is a limited type, and
+ synchronized to indicate that it is a synchronized type.
+
+ _Wording Changes from Ada 95_
+
+28.d/2
+ {8652/00388652/0038} {AI95-00202-01AI95-00202-01} Corrigendum:
+ Corrected wording to define the operations that are inherited
+ when the ancestor of a formal type is itself a formal type to
+ avoid anomalies.
+
+28.e/2
+ {AI95-00158-01AI95-00158-01} Added a semantic description of
+ the meaning of operations of an actual class-wide type, as
+ such a type does not have primitive operations of its own.
+
+28.f/2
+ {AI95-00231-01AI95-00231-01} Added a matching rule for access
+ subtypes that exclude null.
+
+28.g/2
+ {AI95-00233-01AI95-00233-01} The wording for the declaration
+ of implicit operations is corrected to be consistent with
+ *note 7.3.1:: as modified by Corrigendum 1.
+
+28.h/2
+ {AI95-00442-01AI95-00442-01} We change to "determines a
+ category" as that is the new terminology (it avoids confusion,
+ since not all interesting properties form a class).
+
+ _Incompatibilities With Ada 2005_
+
+28.i/3
+ {AI05-0087-1AI05-0087-1} Correction: Added wording to prevent
+ a limited type from being passed to a nonlimited formal
+ derived type. While this was allowed, it would break the
+ contract for the limited type, so hopefully no programs
+ actually depend on that.
+
+ _Extensions to Ada 2005_
+
+28.j/3
+ {AI05-0213-1AI05-0213-1} Formal incomplete types are a new
+ kind of generic formal; these can be instantiated with
+ incomplete types and unfrozen private types.
+
+ _Wording Changes from Ada 2005_
+
+28.k/3
+ {AI05-0029-1AI05-0029-1} Correction: Updated the wording to
+ acknowledge the possibility of operations that are never
+ declared for an actual type but still can be used inside of a
+ generic unit.
+
+28.l/3
+ {AI05-0071-1AI05-0071-1} Correction: Fixed hole that failed to
+ define what happened for "=" for an untagged private type
+ whose actual is class-wide.
+
+28.m/3
+ {AI05-0110-1AI05-0110-1} Correction: Revised the wording for
+ inheritance of characteristics and operations of formal
+ derived types to be reuse the rules as defined for derived
+ types; this should eliminate holes in the wording which have
+ plagued us since Ada 95 was defined (it has been "corrected"
+ four previous times).
+
+28.n/3
+ {AI05-0237-1AI05-0237-1} Correction: Added missing rule for
+ the ancestors of formal derived types. The added rule would
+ formally be incompatible, but since it would be impossible to
+ instantiate any such generic, this cannot happen outside of
+ test suites and thus is not documented as an incompatibility.
+
+\1f
+File: aarm2012.info, Node: 12.5.2, Next: 12.5.3, Prev: 12.5.1, Up: 12.5
+
+12.5.2 Formal Scalar Types
+--------------------------
+
+1/2
+{AI95-00442-01AI95-00442-01} A formal scalar type is one defined by any
+of the formal_type_definitions in this subclause. [The category
+determined for a formal scalar type is the category of all discrete,
+signed integer, modular, floating point, ordinary fixed point, or
+decimal types.]
+
+1.a/2
+ Proof: {AI95-00442-01AI95-00442-01} The second rule follows
+ from the rule in *note 12.5:: that says that the category is
+ determined by the one given in the name of the syntax
+ production. The effect of the rule is repeated here to give a
+ capsule summary of what this subclause is about.
+
+1.b/2
+ Ramification: {AI95-00442-01AI95-00442-01} The "category of a
+ type" includes any classes that the type belongs to.
+
+ _Syntax_
+
+2
+ formal_discrete_type_definition ::= (<>)
+
+3
+ formal_signed_integer_type_definition ::= range <>
+
+4
+ formal_modular_type_definition ::= mod <>
+
+5
+ formal_floating_point_definition ::= digits <>
+
+6
+ formal_ordinary_fixed_point_definition ::= delta <>
+
+7
+ formal_decimal_fixed_point_definition ::= delta <> digits <>
+
+ _Legality Rules_
+
+8
+The actual type for a formal scalar type shall not be a nonstandard
+numeric type.
+
+8.a
+ Reason: This restriction is necessary because nonstandard
+ numeric types have some number of restrictions on their use,
+ which could cause contract model problems in a generic body.
+ Note that nonstandard numeric types can be passed to formal
+ derived and formal private subtypes, assuming they obey all
+ the other rules, and assuming the implementation allows it
+ (being nonstandard means the implementation might disallow
+ anything).
+
+ NOTES
+
+9
+ 12 The actual type shall be in the class of types implied by the
+ syntactic category of the formal type definition (see *note 12.5::,
+ "*note 12.5:: Formal Types"). For example, the actual for a
+ formal_modular_type_definition shall be a modular type.
+
+ _Wording Changes from Ada 95_
+
+9.a/2
+ {AI95-00442-01AI95-00442-01} We change to "determines a
+ category" as that is the new terminology (it avoids confusion,
+ since not all interesting properties form a class).
+
+\1f
+File: aarm2012.info, Node: 12.5.3, Next: 12.5.4, Prev: 12.5.2, Up: 12.5
+
+12.5.3 Formal Array Types
+-------------------------
+
+1/2
+{AI95-00442-01AI95-00442-01} [The category determined for a formal array
+type is the category of all array types.]
+
+1.a/2
+ Proof: {AI95-00442-01AI95-00442-01} This rule follows from the
+ rule in *note 12.5:: that says that the category is determined
+ by the one given in the name of the syntax production. The
+ effect of the rule is repeated here to give a capsule summary
+ of what this subclause is about.
+
+ _Syntax_
+
+2
+ formal_array_type_definition ::= array_type_definition
+
+ _Legality Rules_
+
+3
+The only form of discrete_subtype_definition that is allowed within the
+declaration of a generic formal (constrained) array subtype is a
+subtype_mark.
+
+3.a
+ Reason: The reason is the same as for forbidding constraints
+ in subtype_indications (see *note 12.1::).
+
+4
+For a formal array subtype, the actual subtype shall satisfy the
+following conditions:
+
+5
+ * The formal array type and the actual array type shall have the same
+ dimensionality; the formal subtype and the actual subtype shall be
+ either both constrained or both unconstrained.
+
+6
+ * For each index position, the index types shall be the same, and the
+ index subtypes (if unconstrained), or the index ranges (if
+ constrained), shall statically match (see *note 4.9.1::).
+
+7
+ * The component subtypes of the formal and actual array types shall
+ statically match.
+
+8
+ * If the formal type has aliased components, then so shall the
+ actual.
+
+8.a
+ Ramification: On the other hand, if the formal's components
+ are not aliased, then the actual's components can be either
+ aliased or not.
+
+ _Examples_
+
+9
+Example of formal array types:
+
+10
+ -- given the generic package
+
+11
+ generic
+ type Item is private;
+ type Index is (<>);
+ type Vector is array (Index range <>) of Item;
+ type Table is array (Index) of Item;
+ package P is
+ ...
+ end P;
+
+12
+ -- and the types
+
+13
+ type Mix is array (Color range <>) of Boolean;
+ type Option is array (Color) of Boolean;
+
+14
+ -- then Mix can match Vector and Option can match Table
+
+15
+ package R is new P(Item => Boolean, Index => Color,
+ Vector => Mix, Table => Option);
+
+16
+ -- Note that Mix cannot match Table and Option cannot match Vector
+
+ _Incompatibilities With Ada 83_
+
+16.a
+ The check for matching of component subtypes and index
+ subtypes or index ranges is changed from a run-time check to a
+ compile-time check. The Ada 83 rule that "If the component
+ type is not a scalar type, then the component subtypes shall
+ be either both constrained or both unconstrained" is removed,
+ since it is subsumed by static matching. Likewise, the rules
+ requiring that component types be the same is subsumed.
+
+ _Wording Changes from Ada 95_
+
+16.b/2
+ {AI95-00442-01AI95-00442-01} We change to "determines a
+ category" as that is the new terminology (it avoids confusion,
+ since not all interesting properties form a class).
+
+\1f
+File: aarm2012.info, Node: 12.5.4, Next: 12.5.5, Prev: 12.5.3, Up: 12.5
+
+12.5.4 Formal Access Types
+--------------------------
+
+1/2
+{AI95-00442-01AI95-00442-01} [The category determined for a formal
+access type is the category of all access types.]
+
+1.a/2
+ Proof: {AI95-00442-01AI95-00442-01} This rule follows from the
+ rule in *note 12.5:: that says that the category is determined
+ by the one given in the name of the syntax production. The
+ effect of the rule is repeated here to give a capsule summary
+ of what this subclause is about.
+
+ _Syntax_
+
+2
+ formal_access_type_definition ::= access_type_definition
+
+ _Legality Rules_
+
+3
+For a formal access-to-object type, the designated subtypes of the
+formal and actual types shall statically match.
+
+4/2
+{AI95-00231-01AI95-00231-01} If and only if the general_access_modifier
+constant applies to the formal, the actual shall be an
+access-to-constant type. If the general_access_modifier all applies to
+the formal, then the actual shall be a general access-to-variable type
+(see *note 3.10::). If and only if the formal subtype excludes null,
+the actual subtype shall exclude null.
+
+4.a
+ Ramification: If no _modifier applies to the formal, then the
+ actual type may be either a pool-specific or a general
+ access-to-variable type.
+
+4.a.1/1
+ Reason: {8652/01098652/0109} {AI95-00025-01AI95-00025-01}
+ Matching an access-to-variable to a formal access-to-constant
+ type cannot be allowed. If it were allowed, it would be
+ possible to create an access-to-variable value designating a
+ constant.
+
+4.b/2
+ {AI95-00231-01AI95-00231-01} We require that the "excludes
+ null" property match, because it would be difficult to write a
+ correct generic for a formal access type without knowing this
+ property. Many typical algorithms and techniques will not
+ work for a subtype that excludes null (setting an unused
+ component to null, default-initialized objects, and so on).
+ Even Ada.Unchecked_Deallocation would fail for a subtype that
+ excludes null. Most generics would end up with comments
+ saying that they are not intended to work for subtypes that
+ exclude null. We would rather that this sort of requirement
+ be reflected in the contract of the generic.
+
+5/3
+{AI05-0239-1AI05-0239-1} {AI05-0288-1AI05-0288-1} For a formal
+access-to-subprogram subtype, the designated profiles of the formal and
+the actual shall be subtype conformant.
+
+ _Examples_
+
+6
+Example of formal access types:
+
+7
+ -- the formal types of the generic package
+
+8
+ generic
+ type Node is private;
+ type Link is access Node;
+ package P is
+ ...
+ end P;
+
+9
+ -- can be matched by the actual types
+
+10
+ type Car;
+ type Car_Name is access Car;
+
+11
+ type Car is
+ record
+ Pred, Succ : Car_Name;
+ Number : License_Number;
+ Owner : Person;
+ end record;
+
+12
+ -- in the following generic instantiation
+
+13
+ package R is new P(Node => Car, Link => Car_Name);
+
+ _Incompatibilities With Ada 83_
+
+13.a
+ The check for matching of designated subtypes is changed from
+ a run-time check to a compile-time check. The Ada 83 rule
+ that "If the designated type is other than a scalar type, then
+ the designated subtypes shall be either both constrained or
+ both unconstrained" is removed, since it is subsumed by static
+ matching.
+
+ _Extensions to Ada 83_
+
+13.b
+ Formal access-to-subprogram subtypes and formal general access
+ types are new concepts.
+
+ _Wording Changes from Ada 95_
+
+13.c/2
+ {AI95-00231-01AI95-00231-01} Added a matching rule for
+ subtypes that exclude null.
+
+13.d/2
+ {AI95-00442-01AI95-00442-01} We change to "determines a
+ category" as that is the new terminology (it avoids confusion,
+ since not all interesting properties form a class).
+
+ _Incompatibilities With Ada 2005_
+
+13.e/3
+ {AI05-0288-1AI05-0288-1} Correction: Matching of formal
+ access-to-subprogram types now uses subtype conformance rather
+ than mode conformance, which is needed to plug a hole. This
+ could cause some instantiations legal in Ada 95 and Ada 2005
+ to be rejected in Ada 2012. We believe that formal
+ access-to-subprogram types occur rarely, and actuals that are
+ not subtype conformant are rarer still, so this should not
+ happen often. (In addition, one popular compiler has a bug
+ that causes such instances to be rejected, so no code compiled
+ with that compiler could have an incompatibility.)
+
+\1f
+File: aarm2012.info, Node: 12.5.5, Prev: 12.5.4, Up: 12.5
+
+12.5.5 Formal Interface Types
+-----------------------------
+
+1/2
+{AI95-00251-01AI95-00251-01} {AI95-00442-01AI95-00442-01} [The category
+determined for a formal interface type is the category of all interface
+types.]
+
+1.a/2
+ Proof: {AI95-00442-01AI95-00442-01} This rule follows from the
+ rule in *note 12.5:: that says that the category is determined
+ by the one given in the name of the syntax production. The
+ effect of the rule is repeated here to give a capsule summary
+ of what this subclause is about.
+
+1.b/2
+ Ramification: Here we're taking advantage of our switch in
+ terminology from "determined class" to "determined category";
+ by saying "category" rather than "class", we require that any
+ actual type be an interface type, not just some type derived
+ from an interface type.
+
+ _Syntax_
+
+2/2
+ {AI95-00251-01AI95-00251-01} formal_interface_type_definition ::=
+ interface_type_definition
+
+ _Legality Rules_
+
+3/2
+{AI95-00251AI95-00251} {AI95-00401AI95-00401} The actual type shall be a
+descendant of every progenitor of the formal type.
+
+4/2
+{AI95-00345AI95-00345} The actual type shall be a limited, task,
+protected, or synchronized interface if and only if the formal type is
+also, respectively, a limited, task, protected, or synchronized
+interface.
+
+4.a/2
+ Discussion: We require the kind of interface type to match
+ exactly because without that it is almost impossible to
+ properly implement the interface.
+
+ _Examples_
+
+5/2
+ {AI95-00433-01AI95-00433-01} type Root_Work_Item is tagged private;
+
+6/2
+ {AI95-00433-01AI95-00433-01} generic
+ type Managed_Task is task interface;
+ type Work_Item(<>) is new Root_Work_Item with private;
+ package Server_Manager is
+ task type Server is new Managed_Task with
+ entry Start(Data : in out Work_Item);
+ end Server;
+ end Server_Manager;
+
+7/2
+{AI95-00433-01AI95-00433-01} This generic allows an application to
+establish a standard interface that all tasks need to implement so they
+can be managed appropriately by an application-specific scheduler.
+
+ _Extensions to Ada 95_
+
+7.a/2
+ {AI95-00251-01AI95-00251-01} {AI95-00345-01AI95-00345-01}
+ {AI95-00401-01AI95-00401-01} {AI95-00442-01AI95-00442-01} The
+ formal interface type is new.
+
+\1f
+File: aarm2012.info, Node: 12.6, Next: 12.7, Prev: 12.5, Up: 12
+
+12.6 Formal Subprograms
+=======================
+
+1
+[ Formal subprograms can be used to pass callable entities to a generic
+unit.]
+
+ _Language Design Principles_
+
+1.a
+ Generic formal subprograms are like renames of the
+ explicit_generic_actual_parameter.
+
+ _Syntax_
+
+2/2
+ {AI95-00260-02AI95-00260-02} formal_subprogram_declaration ::=
+ formal_concrete_subprogram_declaration
+ | formal_abstract_subprogram_declaration
+
+2.1/3
+ {AI95-00260-02AI95-00260-02} {AI05-0183-1AI05-0183-1}
+ formal_concrete_subprogram_declaration ::=
+ with subprogram_specification [is subprogram_default]
+ [aspect_specification];
+
+2.2/3
+ {AI95-00260-02AI95-00260-02} {AI05-0183-1AI05-0183-1}
+ formal_abstract_subprogram_declaration ::=
+ with subprogram_specification is abstract [subprogram_default]
+ [aspect_specification];
+
+3/2
+ {AI95-00348-01AI95-00348-01} subprogram_default ::=
+ default_name | <> | null
+
+4
+ default_name ::= name
+
+4.1/2
+ {AI95-00260-02AI95-00260-02} {AI95-00348-01AI95-00348-01} A
+ subprogram_default of null shall not be specified for a formal
+ function or for a formal_abstract_subprogram_declaration.
+
+4.a/2
+ Reason: There are no null functions because the return value
+ has to be constructed somehow. We don't allow null for
+ abstract formal procedures, as the operation is dispatching.
+ It doesn't seem appropriate (or useful) to say that the
+ implementation of something is null in the formal type and all
+ possible descendants of that type. This also would define a
+ dispatching operation that doesn't correspond to a slot in the
+ tag of the controlling type, which would be a new concept.
+ Finally, additional rules would be needed to define the
+ meaning of a dispatching null procedure (for instance, the
+ convention of such a subprogram should be intrinsic, but
+ that's not what the language says). It doesn't seem worth the
+ effort.
+
+ _Name Resolution Rules_
+
+5
+The expected profile for the default_name, if any, is that of the formal
+subprogram.
+
+5.a/3
+ Ramification: {AI05-0299-1AI05-0299-1} This rule, unlike
+ others in this subclause, is observed at compile time of the
+ generic_declaration.
+
+5.b
+ The evaluation of the default_name takes place during the
+ elaboration of each instantiation that uses the default, as
+ defined in *note 12.3::, "*note 12.3:: Generic Instantiation".
+
+6
+For a generic formal subprogram, the expected profile for the actual is
+that of the formal subprogram.
+
+ _Legality Rules_
+
+7/3
+{AI05-0239-1AI05-0239-1} The profiles of the formal and any named
+default shall be mode conformant.
+
+7.a/3
+ Ramification: {AI05-0299-1AI05-0299-1} This rule, unlike
+ others in this subclause, is checked at compile time of the
+ generic_declaration.
+
+8/3
+{AI05-0239-1AI05-0239-1} The profiles of the formal and actual shall be
+mode conformant.
+
+8.1/2
+{AI95-00423-01AI95-00423-01} For a parameter or result subtype of a
+formal_subprogram_declaration that has an explicit null_exclusion:
+
+8.2/2
+ * if the actual matching the formal_subprogram_declaration denotes a
+ generic formal object of another generic unit G, and the
+ instantiation containing the actual that occurs within the body of
+ a generic unit G or within the body of a generic unit declared
+ within the declarative region of the generic unit G, then the
+ corresponding parameter or result type of the formal subprogram of
+ G shall have a null_exclusion;
+
+8.3/2
+ * otherwise, the subtype of the corresponding parameter or result
+ type of the actual matching the formal_subprogram_declaration shall
+ exclude null. In addition to the places where Legality Rules
+ normally apply (see *note 12.3::), this rule applies also in the
+ private part of an instance of a generic unit.
+
+8.a/2
+ Reason: This rule prevents "lying". Null must never be the
+ value of a parameter or result with an explicit
+ null_exclusion. The first bullet is an assume-the-worst rule
+ which prevents trouble in generic bodies (including bodies of
+ child generics) when the formal subtype excludes null
+ implicitly.
+
+8.4/3
+{AI95-00260-02AI95-00260-02} {AI05-0296-1AI05-0296-1} If a formal
+parameter of a formal_abstract_subprogram_declaration (*note 12.6:
+S0297.) is of a specific tagged type T or of an anonymous access type
+designating a specific tagged type T, T is called a controlling type of
+the formal_abstract_subprogram_declaration (*note 12.6: S0297.).
+Similarly, if the result of a formal_abstract_subprogram_declaration
+(*note 12.6: S0297.) for a function is of a specific tagged type T or of
+an anonymous access type designating a specific tagged type T, T is
+called a controlling type of the formal_abstract_subprogram_declaration
+(*note 12.6: S0297.). A formal_abstract_subprogram_declaration (*note
+12.6: S0297.) shall have exactly one controlling type, and that type
+shall not be incomplete.
+
+8.b/2
+ Ramification: The specific tagged type could be any of a
+ formal tagged private type, a formal derived type, a formal
+ interface type, or a normal tagged type. While the last case
+ doesn't seem to be very useful, there isn't any good reason
+ for disallowing it. This rule ensures that the operation is a
+ dispatching operation of some type, and that we unambiguously
+ know what that type is.
+
+8.c/2
+ We informally call a subprogram declared by a
+ formal_abstract_subprogram_declaration (*note 12.6: S0297.) an
+ abstract formal subprogram, but we do not use this term in
+ normative wording. (We do use it often in these notes.)
+
+8.5/2
+{AI95-00260-02AI95-00260-02} The actual subprogram for a
+formal_abstract_subprogram_declaration (*note 12.6: S0297.) shall be a
+dispatching operation of the controlling type or of the actual type
+corresponding to the controlling type.
+
+8.d/2
+ To be honest: We mean the controlling type of the
+ formal_abstract_subprogram_declaration (*note 12.6: S0297.),
+ of course. Saying that gets unwieldy and redundant (so says
+ at least one reviewer, anyway).
+
+8.e/2
+ Ramification: This means that the actual is either a primitive
+ operation of the controlling type, or an abstract formal
+ subprogram. Also note that this prevents the controlling type
+ from being class-wide (with one exception explained below), as
+ only specific types have primitive operations (and a formal
+ subprogram eventually has to have an actual that is a
+ primitive of some type). This could happen in a case like:
+
+8.f/2
+ generic
+ type T(<>) is tagged private;
+ with procedure Foo (Obj : in T) is abstract;
+ package P ...
+
+8.g/2
+ package New_P is new P (Something'Class, Some_Proc);
+
+8.h/2
+ The instantiation here is always illegal, because Some_Proc
+ could never be a primitive operation of Something'Class (there
+ are no such operations). That's good, because we want calls
+ to Foo always to be dispatching calls.
+
+8.i/2
+ Since it is possible for a formal tagged type to be
+ instantiated with a class-wide type, it is possible for the
+ (real) controlling type to be class-wide in one unusual case:
+
+8.j/2
+ generic
+ type NT(<>) is new T with private;
+ -- Presume that T has the following primitive operation:
+ -- with procedure Bar (Obj : in T);
+ package Gr ...
+
+8.k/2
+ package body Gr is
+ package New_P2 is new P (NT, Foo => Bar);
+ end Gr;
+
+8.l/2
+ package New_Gr is new Gr (Something'Class);
+
+8.m/2
+ The instantiation of New_P2 is legal, since Bar is a
+ dispatching operation of the actual type of the controlling
+ type of the abstract formal subprogram Foo. This is not a
+ problem, since the rules given in *note 12.5.1:: explain how
+ this routine dispatches even though its parameter is
+ class-wide.
+
+8.n/2
+ Note that this legality rule never needs to be rechecked in an
+ instance (that contains a nested instantiation). The rule
+ only talks about the actual type of the instantiation; it does
+ not require looking further; if the actual type is in fact a
+ formal type, we do not intend looking at the actual for that
+ formal.
+
+ _Static Semantics_
+
+9
+A formal_subprogram_declaration declares a generic formal subprogram.
+The types of the formal parameters and result, if any, of the formal
+subprogram are those determined by the subtype_marks given in the
+formal_subprogram_declaration; however, independent of the particular
+subtypes that are denoted by the subtype_marks, the nominal subtypes of
+the formal parameters and result, if any, are defined to be nonstatic,
+and unconstrained if of an array type [(no applicable index constraint
+is provided in a call on a formal subprogram)]. In an instance, a
+formal_subprogram_declaration declares a view of the actual. The
+profile of this view takes its subtypes and calling convention from the
+original profile of the actual entity, while taking the formal parameter
+names and default_expression (*note 3.7: S0063.)s from the profile given
+in the formal_subprogram_declaration (*note 12.6: S0295.). The view is
+a function or procedure, never an entry.
+
+9.a
+ Discussion: This rule is intended to be the same as the one
+ for renamings-as-declarations, where the
+ formal_subprogram_declaration is analogous to a
+ renaming-as-declaration, and the actual is analogous to the
+ renamed view.
+
+9.1/3
+{AI05-0071-1AI05-0071-1} {AI05-0131-1AI05-0131-1} If a subtype_mark in
+the profile of the formal_subprogram_declaration denotes a formal
+private or formal derived type and the actual type for this formal type
+is a class-wide type T'Class, then for the purposes of resolving the
+corresponding actual subprogram at the point of the instantiation,
+certain implicit declarations may be available as possible resolutions
+as follows:
+
+9.2/3
+ For each primitive subprogram of T that is directly visible at
+ the point of the instantiation, and that has at least one
+ controlling formal parameter, a corresponding implicitly
+ declared subprogram with the same defining name, and having
+ the same profile as the primitive subprogram except that T is
+ systematically replaced by T'Class in the types of its
+ profile, is potentially use-visible. The body of such a
+ subprogram is as defined in *note 12.5.1:: for primitive
+ subprograms of a formal type when the actual type is
+ class-wide.
+
+9.b/3
+ Reason: {AI05-0071-1AI05-0071-1} {AI05-0131-1AI05-0131-1} This
+ gives the same capabilities to formal subprograms as those
+ that primitive operations of the formal type have when the
+ actual type is class-wide. We do not want to discourage the
+ use of explicit declarations for (formal) subprograms!
+
+9.c/3
+ Implementation Note: {AI05-0071-1AI05-0071-1}
+ {AI05-0131-1AI05-0131-1} Although the above wording seems to
+ require constructing implicit versions of all of the primitive
+ subprograms of type T, it should be clear that a compiler only
+ needs to consider those that could possibly resolve to the
+ corresponding actual subprogram. For instance, if the formal
+ subprogram is a procedure with two parameters, and the actual
+ subprogram name is Bar (either given explicitly or by
+ default), the compiler need not consider primitives that are
+ functions, that have the wrong number of parameters, that have
+ defining names other than Bar, and so on; thus it does not
+ need to construct implicit declarations for those primitives.
+
+9.d/3
+ Ramification: {AI05-0071-1AI05-0071-1}
+ {AI05-0131-1AI05-0131-1} Functions that only have a
+ controlling result and do not have a controlling parameter of
+ T are not covered by this rule, as any call would be required
+ to raise Program_Error by *note 12.5.1::. It is better to
+ detect the error earlier than at run time.
+
+10
+If a generic unit has a subprogram_default specified by a box, and the
+corresponding actual parameter is omitted, then it is equivalent to an
+explicit actual parameter that is a usage name identical to the defining
+name of the formal.
+
+10.1/2
+{AI95-00348-01AI95-00348-01} If a generic unit has a subprogram_default
+specified by the reserved word null, and the corresponding actual
+parameter is omitted, then it is equivalent to an explicit actual
+parameter that is a null procedure having the profile given in the
+formal_subprogram_declaration (*note 12.6: S0295.).
+
+10.2/2
+{AI95-00260-02AI95-00260-02} The subprogram declared by a
+formal_abstract_subprogram_declaration (*note 12.6: S0297.) with a
+controlling type T is a dispatching operation of type T.
+
+10.a/2
+ Reason: This is necessary to trigger all of the dispatching
+ operation rules. It otherwise would not be considered a
+ dispatching operation, as formal subprograms are never
+ primitive operations.
+
+ NOTES
+
+11
+ 13 The matching rules for formal subprograms state requirements
+ that are similar to those applying to
+ subprogram_renaming_declarations (see *note 8.5.4::). In
+ particular, the name of a parameter of the formal subprogram need
+ not be the same as that of the corresponding parameter of the
+ actual subprogram; similarly, for these parameters,
+ default_expressions need not correspond.
+
+12
+ 14 The constraints that apply to a parameter of a formal
+ subprogram are those of the corresponding formal parameter of the
+ matching actual subprogram (not those implied by the corresponding
+ subtype_mark in the _specification of the formal subprogram). A
+ similar remark applies to the result of a function. Therefore, to
+ avoid confusion, it is recommended that the name of a first subtype
+ be used in any declaration of a formal subprogram.
+
+13
+ 15 The subtype specified for a formal parameter of a generic
+ formal subprogram can be any visible subtype, including a generic
+ formal subtype of the same generic_formal_part.
+
+14
+ 16 A formal subprogram is matched by an attribute of a type if the
+ attribute is a function with a matching specification. An
+ enumeration literal of a given type matches a parameterless formal
+ function whose result type is the given type.
+
+15
+ 17 A default_name denotes an entity that is visible or directly
+ visible at the place of the generic_declaration; a box used as a
+ default is equivalent to a name that denotes an entity that is
+ directly visible at the place of the _instantiation.
+
+15.a
+ Proof: Visibility and name resolution are applied to the
+ equivalent explicit actual parameter.
+
+16/2
+ 18 {AI95-00260-02AI95-00260-02} The actual subprogram cannot be
+ abstract unless the formal subprogram is a
+ formal_abstract_subprogram_declaration (*note 12.6: S0297.) (see
+ *note 3.9.3::).
+
+16.1/2
+ 19 {AI95-00260-02AI95-00260-02} The subprogram declared by a
+ formal_abstract_subprogram_declaration (*note 12.6: S0297.) is an
+ abstract subprogram. All calls on a subprogram declared by a
+ formal_abstract_subprogram_declaration (*note 12.6: S0297.) must be
+ dispatching calls. See *note 3.9.3::.
+
+16.2/2
+ 20 {AI95-00348-01AI95-00348-01} A null procedure as a subprogram
+ default has convention Intrinsic (see *note 6.3.1::).
+
+16.a.1/2
+ Proof: This is an implicitly declared subprogram, so it has
+ convention Intrinsic as defined in *note 6.3.1::.
+
+ _Examples_
+
+17
+Examples of generic formal subprograms:
+
+18/2
+ {AI95-00433-01AI95-00433-01} with function "+"(X, Y : Item) return Item is <>;
+ with function Image(X : Enum) return String is Enum'Image;
+ with procedure Update is Default_Update;
+ with procedure Pre_Action(X : in Item) is null; -- defaults to no action
+ with procedure Write(S : not null access Root_Stream_Type'Class;
+ Desc : Descriptor)
+ is abstract Descriptor'Write; -- see *note 13.13.2::
+ -- Dispatching operation on Descriptor with default
+
+19
+ -- given the generic procedure declaration
+
+20
+ generic
+ with procedure Action (X : in Item);
+ procedure Iterate(Seq : in Item_Sequence);
+
+21
+ -- and the procedure
+
+22
+ procedure Put_Item(X : in Item);
+
+23
+ -- the following instantiation is possible
+
+24
+ procedure Put_List is new Iterate(Action => Put_Item);
+
+ _Extensions to Ada 95_
+
+24.a/2
+ {AI95-00260-02AI95-00260-02} The
+ formal_abstract_subprogram_declaration is new. It allows the
+ passing of dispatching operations to generic units.
+
+24.b/2
+ {AI95-00348-01AI95-00348-01} The formal subprogram default of
+ null is new. It allows the default of a generic procedure to
+ do nothing, such as for passing a debugging routine.
+
+ _Wording Changes from Ada 95_
+
+24.c/2
+ {AI95-00423-01AI95-00423-01} Added matching rules for
+ null_exclusions.
+
+ _Incompatibilities With Ada 2005_
+
+24.d/3
+ {AI05-0296-1AI05-0296-1} It is now illegal to declare a formal
+ abstract subprogram whose controlling type is incomplete. It
+ was never intended to allow that, and such a type would have
+ to come from outside of the generic unit in Ada 2005, so it is
+ unlikely to be useful. Moreover, a dispatching call on the
+ subprogram is likely to fail in many implementations. So it
+ is very unlikely that any code will need to be changed because
+ of this new rule.
+
+ _Extensions to Ada 2005_
+
+24.e/3
+ {AI05-0071-1AI05-0071-1} {AI05-0131-1AI05-0131-1} Correction:
+ Added construction of implicit subprograms for primitives of
+ class-wide actual types, to make it possible to import
+ subprograms via formal subprograms as well as by implicit
+ primitive operations of a formal type. (This is a Correction
+ as it is very important for the usability of indefinite
+ containers when instantiated with class-wide types; thus we
+ want Ada 2005 implementations to support it.)
+
+24.f/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a formal_concrete_subprogram_declaration and a
+ formal_abstract_subprogram_declaration. This is described in
+ *note 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 12.7, Next: 12.8, Prev: 12.6, Up: 12
+
+12.7 Formal Packages
+====================
+
+1
+[ Formal packages can be used to pass packages to a generic unit. The
+formal_package_declaration declares that the formal package is an
+instance of a given generic package. Upon instantiation, the actual
+package has to be an instance of that generic package.]
+
+ _Syntax_
+
+2/3
+ {AI05-0183-1AI05-0183-1} formal_package_declaration ::=
+ with package defining_identifier is new generic_package_name
+ formal_package_actual_part
+ [aspect_specification];
+
+3/2
+ {AI95-00317-01AI95-00317-01} formal_package_actual_part ::=
+ ([others =>] <>)
+ | [generic_actual_part]
+ | (formal_package_association {,
+ formal_package_association} [, others => <>])
+
+3.1/2
+ {AI95-00317-01AI95-00317-01} formal_package_association ::=
+ generic_association
+ | generic_formal_parameter_selector_name => <>
+
+3.2/2
+ {AI95-00317-01AI95-00317-01} Any positional
+ formal_package_associations shall precede any named
+ formal_package_associations.
+
+ _Legality Rules_
+
+4
+The generic_package_name shall denote a generic package (the template
+for the formal package); the formal package is an instance of the
+template.
+
+4.1/3
+{AI05-0025-1AI05-0025-1} The generic_formal_parameter_selector_name of a
+formal_package_association shall denote a
+generic_formal_parameter_declaration of the template. If two or more
+formal subprograms of the template have the same defining name, then
+named associations are not allowed for the corresponding actuals.
+
+4.2/3
+{AI95-00398-01AI95-00398-01} A formal_package_actual_part shall contain
+at most one formal_package_association for each formal parameter. If
+the formal_package_actual_part does not include "others => <>", each
+formal parameter without an association shall have a default_expression
+or subprogram_default.
+
+4.3/3
+{AI05-0200-1AI05-0200-1} The rules for matching between
+formal_package_associations and the generic formals of the template are
+as follows:
+
+4.4/3
+ * If all of the formal_package_associations are given by generic
+ associations, the explicit_generic_actual_parameters of the
+ formal_package_associations shall be legal for an instantiation of
+ the template.
+
+4.5/3
+ * If a formal_package_association for a formal type T of the template
+ is given by <>, then the formal_package_association for any other
+ generic_formal_parameter_declaration of the template that mentions
+ T directly or indirectly must be given by <> as well.
+
+4.a/3
+ Discussion: {AI05-0200-1AI05-0200-1} The above rule is simple
+ to state, though it does not reflect the fact that the formal
+ package functions like an instantiation of a special kind,
+ where each box association for a
+ generic_formal_parameter_declaration F is replaced with a new
+ entity F' that has the same characteristics as F: if F is a
+ formal discrete type then F' is a discrete type, if F is a
+ formal subprogram then F' is a subprogram with a similar
+ signature, etc. In practice this is achieved by making the
+ association into a copy of the declaration of the generic
+ formal.
+
+5/2
+{AI95-00317-01AI95-00317-01} The actual shall be an instance of the
+template. If the formal_package_actual_part is (<>) or (others => <>),
+[then the actual may be any instance of the template]; otherwise,
+certain of the actual parameters of the actual instance shall match the
+corresponding actual parameters of the formal package, determined as
+follows:
+
+5.1/2
+ * {AI95-00317-01AI95-00317-01} If the formal_package_actual_part
+ (*note 12.7: S0301.) includes generic_associations as well as
+ associations with <>, then only the actual parameters specified
+ explicitly with generic_associations are required to match;
+
+5.2/2
+ * {AI95-00317-01AI95-00317-01} Otherwise, all actual parameters shall
+ match[, whether any actual parameter is given explicitly or by
+ default].
+
+5.3/2
+{AI95-00317-01AI95-00317-01} The rules for matching of actual parameters
+between the actual instance and the formal package are as follows:
+
+6/2
+ * {AI95-00317-01AI95-00317-01} For a formal object of mode in, the
+ actuals match if they are static expressions with the same value,
+ or if they statically denote the same constant, or if they are both
+ the literal null.
+
+6.a
+ Reason: We can't simply require full conformance between the
+ two actual parameter expressions, because the two expressions
+ are being evaluated at different times.
+
+7
+ * For a formal subtype, the actuals match if they denote statically
+ matching subtypes.
+
+8
+ * For other kinds of formals, the actuals match if they statically
+ denote the same entity.
+
+8.1/1
+{8652/00398652/0039} {AI95-00213-01AI95-00213-01} For the purposes of
+matching, any actual parameter that is the name of a formal object of
+mode in is replaced by the formal object's actual expression
+(recursively).
+
+ _Static Semantics_
+
+9
+A formal_package_declaration declares a generic formal package.
+
+10/2
+{AI95-00317-01AI95-00317-01} The visible part of a formal package
+includes the first list of basic_declarative_items of the
+package_specification (*note 7.1: S0191.). In addition, for each actual
+parameter that is not required to match, a copy of the declaration of
+the corresponding formal parameter of the template is included in the
+visible part of the formal package. If the copied declaration is for a
+formal type, copies of the implicit declarations of the primitive
+subprograms of the formal type are also included in the visible part of
+the formal package.
+
+10.a/2
+ Ramification: {AI95-00317-01AI95-00317-01} If the
+ formal_package_actual_part is (<>), then the declarations that
+ occur immediately within the generic_formal_part of the
+ template for the formal package are visible outside the formal
+ package, and can be denoted by expanded names outside the
+ formal package.If only some of the actual parameters are given
+ by <>, then the declaration corresponding to those parameters
+ (but not the others) are made visible.
+
+10.b/3
+ Reason: {AI05-0005-1AI05-0005-1} We always want either the
+ actuals or the formals of an instance to be nameable from
+ outside, but never both. If both were nameable, one would get
+ some funny anomalies since they denote the same entity, but,
+ in the case of types at least, they might have different and
+ inconsistent sets of primitive operators due to predefined
+ operator "reemergence." Formal derived types exacerbate the
+ difference. We want the implicit declarations of the
+ generic_formal_part as well as the explicit declarations, so
+ we get operations on the formal types.
+
+10.c
+ Ramification: A generic formal package is a package, and is an
+ instance. Hence, it is possible to pass a generic formal
+ package as an actual to another generic formal package.
+
+11/2
+{AI95-00317-01AI95-00317-01} For the purposes of matching, if the actual
+instance A is itself a formal package, then the actual parameters of A
+are those specified explicitly or implicitly in the
+formal_package_actual_part for A, plus, for those not specified, the
+copies of the formal parameters of the template included in the visible
+part of A.
+
+ _Examples_
+
+12/2
+{AI95-00433-01AI95-00433-01} Example of a generic package with formal
+package parameters:
+
+13/2
+ with Ada.Containers.Ordered_Maps; -- see *note A.18.6::
+ generic
+ with package Mapping_1 is new Ada.Containers.Ordered_Maps(<>);
+ with package Mapping_2 is new Ada.Containers.Ordered_Maps
+ (Key_Type => Mapping_1.Element_Type,
+ others => <>);
+ package Ordered_Join is
+ -- Provide a "join" between two mappings
+
+14/2
+ subtype Key_Type is Mapping_1.Key_Type;
+ subtype Element_Type is Mapping_2.Element_Type;
+
+15/2
+ function Lookup(Key : Key_Type) return Element_Type;
+
+16/2
+ ...
+ end Ordered_Join;
+
+17/2
+{AI95-00433-01AI95-00433-01} Example of an instantiation of a package
+with formal packages:
+
+18/2
+ with Ada.Containers.Ordered_Maps;
+ package Symbol_Package is
+
+19/2
+ type String_Id is ...
+
+20/2
+ type Symbol_Info is ...
+
+21/2
+ package String_Table is new Ada.Containers.Ordered_Maps
+ (Key_Type => String,
+ Element_Type => String_Id);
+
+22/2
+ package Symbol_Table is new Ada.Containers.Ordered_Maps
+ (Key_Type => String_Id,
+ Element_Type => Symbol_Info);
+
+23/2
+ package String_Info is new Ordered_Join(Mapping_1 => String_Table,
+ Mapping_2 => Symbol_Table);
+
+24/2
+ Apple_Info : constant Symbol_Info := String_Info.Lookup("Apple");
+
+25/2
+ end Symbol_Package;
+
+ _Extensions to Ada 83_
+
+25.a
+ Formal packages are new to Ada 95.
+
+ _Extensions to Ada 95_
+
+25.b/2
+ {AI95-00317-01AI95-00317-01} {AI95-00398-01AI95-00398-01} It's
+ now allowed to mix actuals of a formal package that are
+ specified with those that are not specified.
+
+ _Wording Changes from Ada 95_
+
+25.c/2
+ {8652/00398652/0039} {AI95-00213-01AI95-00213-01} Corrigendum:
+ Corrected the description of formal package matching to say
+ that formal parameters are always replaced by their actual
+ parameters (recursively). This matches the actual practice of
+ compilers, as the ACATS has always required this behavior.
+
+25.d/2
+ {AI95-00317-01AI95-00317-01} The description of which
+ operations are visible in a formal package has been clarified.
+ We also specify how matching is done when the actual is a
+ formal package.
+
+ _Incompatibilities With Ada 2005_
+
+25.e/3
+ {AI05-0025-1AI05-0025-1} {AI05-0200-1AI05-0200-1} Correction:
+ Added missing rules for parameters of generic formal package
+ that parallel those in *note 12.3::, as well as some specific
+ to <> parameters. These are technically incompatibilities
+ because generic formal package parameters that Ada 95 and Ada
+ 2005 would have considered legal now have to be rejected. But
+ this should not be an issue in practice as such formal
+ parameters could not have matched any actual generics. And it
+ is quite likely that implementations already enforce some of
+ these rules.
+
+ _Extensions to Ada 2005_
+
+25.f/3
+ {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+ be used in a formal_package_declaration. This is described in
+ *note 13.1.1::.
+
+\1f
+File: aarm2012.info, Node: 12.8, Prev: 12.7, Up: 12
+
+12.8 Example of a Generic Package
+=================================
+
+1
+The following example provides a possible formulation of stacks by means
+of a generic package. The size of each stack and the type of the stack
+elements are provided as generic formal parameters.
+
+ _Examples_
+
+2/1
+This paragraph was deleted.
+
+3
+ generic
+ Size : Positive;
+ type Item is private;
+ package Stack is
+ procedure Push(E : in Item);
+ procedure Pop (E : out Item);
+ Overflow, Underflow : exception;
+ end Stack;
+
+4
+ package body Stack is
+
+5
+ type Table is array (Positive range <>) of Item;
+ Space : Table(1 .. Size);
+ Index : Natural := 0;
+
+6
+ procedure Push(E : in Item) is
+ begin
+ if Index >= Size then
+ raise Overflow;
+ end if;
+ Index := Index + 1;
+ Space(Index) := E;
+ end Push;
+
+7
+ procedure Pop(E : out Item) is
+ begin
+ if Index = 0 then
+ raise Underflow;
+ end if;
+ E := Space(Index);
+ Index := Index - 1;
+ end Pop;
+
+8
+ end Stack;
+
+9
+Instances of this generic package can be obtained as follows:
+
+10
+ package Stack_Int is new Stack(Size => 200, Item => Integer);
+ package Stack_Bool is new Stack(100, Boolean);
+
+11
+Thereafter, the procedures of the instantiated packages can be called as
+follows:
+
+12
+ Stack_Int.Push(N);
+ Stack_Bool.Push(True);
+
+13
+Alternatively, a generic formulation of the type Stack can be given as
+follows (package body omitted):
+
+14
+ generic
+ type Item is private;
+ package On_Stacks is
+ type Stack(Size : Positive) is limited private;
+ procedure Push(S : in out Stack; E : in Item);
+ procedure Pop (S : in out Stack; E : out Item);
+ Overflow, Underflow : exception;
+ private
+ type Table is array (Positive range <>) of Item;
+ type Stack(Size : Positive) is
+ record
+ Space : Table(1 .. Size);
+ Index : Natural := 0;
+ end record;
+ end On_Stacks;
+
+15
+In order to use such a package, an instance has to be created and
+thereafter stacks of the corresponding type can be declared:
+
+16
+ declare
+ package Stack_Real is new On_Stacks(Real); use Stack_Real;
+ S : Stack(100);
+ begin
+ ...
+ Push(S, 2.54);
+ ...
+ end;
+
+\1f
+File: aarm2012.info, Node: 13, Next: Annex A, Prev: 12, Up: Top
+
+13 Representation Issues
+************************
+
+1/3
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+{AI05-0299-1AI05-0299-1} [This clause describes features for querying
+and controlling certain aspects of entities and for interfacing to
+hardware.]
+
+ _Wording Changes from Ada 83_
+
+1.a/3
+ {AI05-0299-1AI05-0299-1} The subclauses of this clause have
+ been reorganized. This was necessary to preserve a logical
+ order, given the new Ada 95 semantics given in this section.
+
+* Menu:
+
+* 13.1 :: Operational and Representation Aspects
+* 13.2 :: Packed Types
+* 13.3 :: Operational and Representation Attributes
+* 13.4 :: Enumeration Representation Clauses
+* 13.5 :: Record Layout
+* 13.6 :: Change of Representation
+* 13.7 :: The Package System
+* 13.8 :: Machine Code Insertions
+* 13.9 :: Unchecked Type Conversions
+* 13.10 :: Unchecked Access Value Creation
+* 13.11 :: Storage Management
+* 13.12 :: Pragma Restrictions and Pragma Profile
+* 13.13 :: Streams
+* 13.14 :: Freezing Rules
+
+\1f
+File: aarm2012.info, Node: 13.1, Next: 13.2, Up: 13
+
+13.1 Operational and Representation Aspects
+===========================================
+
+0.1/3
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+{AI05-0295-1AI05-0295-1} [Two kinds of aspects of entities can be
+specified: representation aspects and operational aspects.
+Representation aspects affect how the types and other entities of the
+language are to be mapped onto the underlying machine. Operational
+aspects determine other properties of entities.]
+
+0.2/3
+{AI05-0183-1AI05-0183-1} {AI05-0295-1AI05-0295-1} [Either kind of aspect
+of an entity may be specified by means of an aspect_specification (see
+*note 13.1.1::), which is an optional element of most kinds of
+declarations and applies to the entity or entities being declared.
+Aspects may also be specified by certain other constructs occurring
+subsequent to the declaration of the affected entity: a representation
+aspect value may be specified by means of a representation item and an
+operational aspect value may be specified by means of an operational
+item.]
+
+1/1
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01} There are six kinds of
+representation items: attribute_definition_clause (*note 13.3: S0309.)s
+for representation attributes, enumeration_representation_clause (*note
+13.4: S0310.)s, record_representation_clause (*note 13.5.1: S0312.)s,
+at_clauses, component_clauses, and representation pragmas. [ They can
+be provided to give more efficient representation or to interface with
+features that are outside the domain of the language (for example,
+peripheral hardware). ]
+
+1.1/1
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01} An operational item is
+an attribute_definition_clause for an operational attribute.
+
+1.2/1
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01} [An operational item
+or a representation item applies to an entity identified by a
+local_name, which denotes an entity declared local to the current
+declarative region, or a library unit declared immediately preceding a
+representation pragma in a compilation.]
+
+ _Language Design Principles_
+
+1.a/3
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+ {AI05-0295-1AI05-0295-1} Representation aspects are intended
+ to refer to properties that need to be known before the
+ compiler can generate code to create or access an entity. For
+ instance, the size of an object needs to be known before the
+ object can be created. Conversely, operational aspects are
+ those that only need to be known before they can be used. For
+ instance, how an object is read from a stream only needs to be
+ known when a stream read is executed. Thus, representation
+ aspects have stricter rules as to when they can be specified.
+
+1.a.1/3
+ {AI95-00291-02AI95-00291-02} {AI05-0295-1AI05-0295-1}
+ Confirming the value of an aspect should never change the
+ semantics of the aspect. Thus Size = 8 (for example) means
+ the same thing whether it was specified with a representation
+ item or whether the compiler chose this value by default.
+
+1.a.2/3
+ Glossary entry: An aspect is a specifiable property of an
+ entity. An aspect may be specified by an aspect_specification
+ on the declaration of the entity. Some aspects may be queried
+ via attributes.
+
+ _Syntax_
+
+2/1
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} aspect_clause ::=
+ attribute_definition_clause
+ | enumeration_representation_clause
+ | record_representation_clause
+ | at_clause
+
+3
+ local_name ::= direct_name
+ | direct_name'attribute_designator
+ | library_unit_name
+
+4/1
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} A representation
+ pragma is allowed only at places where an aspect_clause or
+ compilation_unit is allowed.
+
+ _Name Resolution Rules_
+
+5/1
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01} In an operational item
+or representation item, if the local_name is a direct_name, then it
+shall resolve to denote a declaration (or, in the case of a pragma, one
+or more declarations) that occurs immediately within the same
+declarative region as the item. If the local_name has an
+attribute_designator, then it shall resolve to denote an
+implementation-defined component (see *note 13.5.1::) or a class-wide
+type implicitly declared immediately within the same declarative region
+as the item. A local_name that is a library_unit_name (only permitted
+in a representation pragma) shall resolve to denote the library_item
+that immediately precedes (except for other pragmas) the representation
+pragma.
+
+5.a/1
+ Reason: {8652/00098652/0009} {AI95-00137-01AI95-00137-01} This
+ is a Name Resolution Rule, because we don't want an
+ operational or representation item for X to be ambiguous just
+ because there's another X declared in an outer declarative
+ region. It doesn't make much difference, since most
+ operational or representation items are for types or subtypes,
+ and type and subtype names can't be overloaded.
+
+5.b/1
+ Ramification: {8652/00098652/0009}
+ {AI95-00137-01AI95-00137-01} The visibility rules imply that
+ the declaration has to occur before the operational or
+ representation item.
+
+5.c/1
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} For objects,
+ this implies that operational or representation items can be
+ applied only to stand-alone objects.
+
+ _Legality Rules_
+
+6/1
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01} The local_name of an
+aspect_clause or representation pragma shall statically denote an entity
+(or, in the case of a pragma, one or more entities) declared immediately
+preceding it in a compilation, or within the same declarative_part
+(*note 3.11: S0086.), package_specification (*note 7.1: S0191.),
+task_definition (*note 9.1: S0207.), protected_definition (*note 9.4:
+S0212.), or record_definition (*note 3.8: S0067.) as the representation
+or operational item. If a local_name denotes a [local] callable entity,
+it may do so through a [local] subprogram_renaming_declaration (*note
+8.5.4: S0203.) [(as a way to resolve ambiguity in the presence of
+overloading)]; otherwise, the local_name shall not denote a
+renaming_declaration (*note 8.5: S0199.).
+
+6.a
+ Ramification: The "statically denote" part implies that it is
+ impossible to specify the representation of an object that is
+ not a stand-alone object, except in the case of a
+ representation item like pragma Atomic that is allowed inside
+ a component_list (in which case the representation item
+ specifies the representation of components of all objects of
+ the type). It also prevents the problem of renamings of
+ things like "P.all" (where P is an access-to-subprogram value)
+ or "E(I)" (where E is an entry family).
+
+6.b
+ The part about where the denoted entity has to have been
+ declared appears twice -- once as a Name Resolution Rule, and
+ once as a Legality Rule. Suppose P renames Q, and we have a
+ representation item in a declarative_part whose local_name is
+ P. The fact that the representation item has to appear in the
+ same declarative_part as P is a Name Resolution Rule, whereas
+ the fact that the representation item has to appear in the
+ same declarative_part as Q is a Legality Rule. This is
+ subtle, but it seems like the least confusing set of rules.
+
+6.c
+ Discussion: A separate Legality Rule applies for
+ component_clauses. See *note 13.5.1::, "*note 13.5.1:: Record
+ Representation Clauses".
+
+7/2
+{AI95-00291-02AI95-00291-02} The representation of an object consists of
+a certain number of bits (the size of the object). For an object of an
+elementary type, these are the bits that are normally read or updated by
+the machine code when loading, storing, or operating-on the value of the
+object. For an object of a composite type, these are the bits reserved
+for this object, and include bits occupied by subcomponents of the
+object. If the size of an object is greater than that of its subtype,
+the additional bits are padding bits. For an elementary object, these
+padding bits are normally read and updated along with the others. For a
+composite object, padding bits might not be read or updated in any given
+composite operation, depending on the implementation.
+
+7.a/2
+ To be honest: {AI95-00291-02AI95-00291-02} Discontiguous
+ representations are allowed, but the ones we're interested in
+ here are generally contiguous sequences of bits. For a
+ discontiguous representation, the size doesn't necessarily
+ describe the "footprint" of the object in memory (that is, the
+ amount of space taken in the address space for the object).
+
+7.a.1/2
+ Discussion: {AI95-00291-02AI95-00291-02} In the case of
+ composite objects, we want the implementation to have the
+ flexibility to either do operations component-by-component, or
+ with a block operation covering all of the bits. We carefully
+ avoid giving a preference in the wording. There is no
+ requirement for the choice to be documented, either, as the
+ implementation can make that choice based on many factors, and
+ could make a different choice for different operations on the
+ same object.
+
+7.a.2/2
+ {AI95-00291-02AI95-00291-02} In the case of a properly
+ aligned, contiguous object whose size is a multiple of the
+ storage unit size, no other bits should be read or updated as
+ part of operating on the object. We don't say this
+ normatively because it would be difficult to normatively
+ define "properly aligned" or "contiguous".
+
+7.b
+ Ramification: Two objects with the same value do not
+ necessarily have the same representation. For example, an
+ implementation might represent False as zero and True as any
+ odd value. Similarly, two objects (of the same type) with the
+ same sequence of bits do not necessarily have the same value.
+ For example, an implementation might use a biased
+ representation in some cases but not others:
+
+7.c/3
+ {AI05-0229-1AI05-0229-1} subtype S is Integer range 1..256;
+ type A is array(Natural range 1..4) of S
+ with Pack;
+ X : S := 3;
+ Y : A := (1, 2, 3, 4);
+
+7.d
+ The implementation might use a biased-by-1 representation for
+ the array elements, but not for X. X and Y(3) have the same
+ value, but different representation: the representation of X
+ is a sequence of (say) 32 bits: 0...011, whereas the
+ representation of Y(3) is a sequence of 8 bits: 00000010
+ (assuming a two's complement representation).
+
+7.e
+ Such tricks are not required, but are allowed.
+
+7.f
+ Discussion: The value of any padding bits is not specified by
+ the language, though for a numeric type, it will be much
+ harder to properly implement the predefined operations if the
+ padding bits are not either all zero, or a sign extension.
+
+7.g/3
+ Ramification: {AI05-0229-1AI05-0229-1} For example, suppose
+ S'Size = 2, and an object X is of subtype S. If the machine
+ code typically uses a 32-bit load instruction to load the
+ value of X, then X'Size should be 32, even though 30 bits of
+ the value are just zeros or sign-extension bits. On the other
+ hand, if the machine code typically masks out those 30 bits,
+ then X'Size should be 2. Usually, such masking only happens
+ for components of a composite type for which Pack,
+ Component_Size, or record layout is specified.
+
+7.h
+ Note, however, that the formal parameter of an instance of
+ Unchecked_Conversion is a special case. Its Size is required
+ to be the same as that of its subtype.
+
+7.i
+ Note that we don't generally talk about the representation of
+ a value. A value is considered to be an amorphous blob
+ without any particular representation. An object is
+ considered to be more concrete.
+
+8/3
+{AI05-0112-1AI05-0112-1} {AI05-0295-1AI05-0295-1} A representation item
+directly specifies a representation aspect of the entity denoted by the
+local_name, except in the case of a type-related representation item,
+whose local_name shall denote a first subtype, and which directly
+specifies an aspect of the subtype's type. A representation item that
+names a subtype is either subtype-specific (Size and Alignment clauses)
+or type-related (all others). [Subtype-specific aspects may differ for
+different subtypes of the same type.]
+
+8.a
+ To be honest: Type-related and subtype-specific are defined
+ likewise for the corresponding aspects of representation.
+
+8.b
+ To be honest: Some representation items directly specify more
+ than one aspect.
+
+8.c/3
+ Discussion: {AI05-0229-1AI05-0229-1} For example, a pragma
+ Export (see *note J.15.5::) specifies the convention of an
+ entity, and also specifies that it is exported. Such items
+ are obsolescent; directly specifying the associated aspects is
+ preferred.
+
+8.d
+ Ramification: Each specifiable attribute constitutes a
+ separate aspect. An enumeration_representation_clause
+ specifies the coding aspect. A record_representation_clause
+ (without the mod_clause) specifies the record layout aspect.
+ Each representation pragma specifies a separate aspect.
+
+8.e
+ Reason: We don't need to say that an at_clause or a mod_clause
+ specify separate aspects, because these are equivalent to
+ attribute_definition_clauses. See *note J.7::, "*note J.7::
+ At Clauses", and *note J.8::, "*note J.8:: Mod Clauses".
+
+8.e.1/3
+ {AI05-0112-1AI05-0112-1} We give a default naming for
+ representation aspects of representation pragmas so we don't
+ have to do that for every pragma. Operational and
+ representation attributes are given a default naming in *note
+ 13.3::. We don't want any anonymous aspects; that would make
+ other rules more difficult to write and understand.
+
+8.f
+ Ramification: The following representation items are
+ type-related:
+
+8.g
+ * enumeration_representation_clause
+
+8.h
+ * record_representation_clause
+
+8.i
+ * Component_Size clause
+
+8.j/1
+ * This paragraph was deleted.{8652/00098652/0009}
+ {AI95-00137-01AI95-00137-01}
+
+8.k
+ * Small clause
+
+8.l
+ * Bit_Order clause
+
+8.m
+ * Storage_Pool clause
+
+8.n
+ * Storage_Size clause
+
+8.n.1/2
+ * {AI95-00270-01AI95-00270-01} Stream_Size clause
+
+8.o/1
+ * This paragraph was deleted.{8652/00098652/0009}
+ {AI95-00137-01AI95-00137-01}
+
+8.p/1
+ * This paragraph was deleted.{8652/00098652/0009}
+ {AI95-00137-01AI95-00137-01}
+
+8.q/1
+ * This paragraph was deleted.{8652/00098652/0009}
+ {AI95-00137-01AI95-00137-01}
+
+8.r/1
+ * This paragraph was deleted.{8652/00098652/0009}
+ {AI95-00137-01AI95-00137-01}
+
+8.s
+ * Machine_Radix clause
+
+8.t
+ * pragma Pack
+
+8.u
+ * pragmas Import, Export, and Convention (when applied to a
+ type)
+
+8.v/3
+ * {AI05-0009-1AI05-0009-1} pragmas Atomic, Independent, and
+ Volatile (when applied to a type)
+
+8.w/3
+ * {AI05-0009-1AI05-0009-1} pragmas Atomic_Components,
+ Independent_Components, and Volatile_Components (when
+ applied to a type)
+
+8.x
+ * pragma Discard_Names (when applied to an enumeration or
+ tagged type)
+
+8.y
+ The following representation items are subtype-specific:
+
+8.z
+ * Alignment clause (when applied to a first subtype)
+
+8.aa
+ * Size clause (when applied to a first subtype)
+
+8.bb
+ The following representation items do not apply to subtypes,
+ so they are neither type-related nor subtype-specific:
+
+8.cc
+ * Address clause (applies to objects and program units)
+
+8.dd
+ * Alignment clause (when applied to an object)
+
+8.ee
+ * Size clause (when applied to an object)
+
+8.ff
+ * pragmas Import, Export, and Convention (when applied to
+ anything other than a type)
+
+8.gg
+ * pragmas Atomic and Volatile (when applied to an object or
+ a component)
+
+8.hh/3
+ * {AI05-0009-1AI05-0009-1} pragmas Atomic_Components,
+ Independent_Components, and Volatile_Components (when
+ applied to an array object)
+
+8.ii
+ * pragma Discard_Names (when applied to an exception)
+
+8.jj
+ * pragma Asynchronous (applies to procedures)
+
+8.kk/2
+ * {AI95-00414-01AI95-00414-01} pragma No_Return (applies to
+ subprograms)
+
+8.ll/3
+ {AI05-0229-1AI05-0229-1} While an aspect_specification is not
+ a representation item, a similar categorization applies to the
+ aspect that corresponds to each of these representation items
+ (along with aspects that do not have associated representation
+ items).
+
+8.1/3
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+{AI05-0183-1AI05-0183-1} An operational item directly specifies an
+operational aspect of the entity denoted by the local_name, except in
+the case of a type-related operational item, whose local_name shall
+denote a first subtype, and which directly specifies an aspect of the
+type of the subtype.
+
+8.mm/1
+ Ramification: {8652/00098652/0009}
+ {AI95-00137-01AI95-00137-01} The following operational items
+ are type-related:
+
+8.nn/1
+ * External_Tag clause
+
+8.oo/1
+ * Read clause
+
+8.pp/1
+ * Write clause
+
+8.qq/1
+ * Input clause
+
+8.rr/1
+ * Output clause
+
+9/3
+{AI05-0183-1AI05-0183-1} A representation item that directly specifies
+an aspect of a subtype or type shall appear after the type is completely
+defined (see *note 3.11.1::), and before the subtype or type is frozen
+(see *note 13.14::). If a representation item or aspect_specification
+is given that directly specifies an aspect of an entity, then it is
+illegal to give another representation item or aspect_specification that
+directly specifies the same aspect of the entity.
+
+9.a/1
+ Ramification: {8652/00098652/0009}
+ {AI95-00137-01AI95-00137-01} The fact that a representation
+ item (or operational item, see next paragraph) that directly
+ specifies an aspect of an entity is required to appear before
+ the entity is frozen prevents changing the representation of
+ an entity after using the entity in ways that require the
+ representation to be known.
+
+9.b/3
+ To be honest: {AI05-0183-1AI05-0183-1} The rule preventing
+ multiple specification is also intended to cover other ways to
+ specify representation aspects, such as obsolescent pragma
+ Priority. Priority is not a representation pragma, and as
+ such is neither a representation item nor an
+ aspect_specification. Regardless, giving both a pragma
+ Priority and an aspect_specification for Priority is illegal.
+ We didn't want to complicate the wording solely to support
+ obsolescent features.
+
+9.1/3
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+{AI05-0183-1AI05-0183-1} An operational item that directly specifies an
+aspect of an entity shall appear before the entity is frozen (see *note
+13.14::). If an operational item or aspect_specification is given that
+directly specifies an aspect of an entity, then it is illegal to give
+another operational item or aspect_specification that directly specifies
+the same aspect of the entity.
+
+9.c/1
+ Ramification: Unlike representation items, operational items
+ can be specified on partial views. Since they don't affect
+ the representation, the full declaration need not be known to
+ determine their legality.
+
+9.2/3
+{AI05-0106-1AI05-0106-1} {AI05-0295-1AI05-0295-1} Unless otherwise
+specified, it is illegal to specify an operational or representation
+aspect of a generic formal parameter.
+
+9.d/3
+ Reason: Specifying an aspect on a generic formal parameter
+ implies an added contract for a generic unit. That contract
+ needs to be defined via generic parameter matching rules, and,
+ as aspects vary widely, that has to be done for each such
+ aspect. Since most aspects do not need this complexity
+ (including all language-defined aspects as of this writing),
+ we avoid the complexity by saying that such contract-forming
+ aspect specifications are banned unless the rules defining
+ them explicitly exist. Note that the method of specification
+ does not matter: aspect_specifications, representation items,
+ and operational items are all covered by this (and similar)
+ rules.
+
+10/3
+{AI05-0295-1AI05-0295-1} For an untagged derived type, it is illegal to
+specify a type-related representation aspect if the parent type is a
+by-reference type, or has any user-defined primitive subprograms.
+
+10.a/3
+ Ramification: {8652/00098652/0009}
+ {AI95-00137-01AI95-00137-01} {AI05-0295-1AI05-0295-1} On the
+ other hand, subtype-specific representation aspects may be
+ specified for the first subtype of such a type, as can
+ operational aspects.
+
+10.b/3
+ Reason: {AI05-0229-1AI05-0229-1} {AI05-0295-1AI05-0295-1} The
+ reason for forbidding specification of type-related
+ representation aspects on untagged by-reference types is
+ because a change of representation is impossible when passing
+ by reference (to an inherited subprogram). The reason for
+ forbidding specification of type-related representation
+ aspects on untagged types with user-defined primitive
+ subprograms was to prevent implicit change of representation
+ for type-related aspects of representation upon calling
+ inherited subprograms, because such changes of representation
+ are likely to be expensive at run time. Changes of
+ subtype-specific representation attributes, however, are
+ likely to be cheap. This rule is not needed for tagged types,
+ because other rules prevent a type-related representation
+ aspect from changing the representation of the parent part; we
+ want to allow specifying a type-related representation aspect
+ on a type extension to specify aspects of the extension part.
+ For example, specifying aspect Pack will cause packing of the
+ extension part, but not of the parent part.
+
+11/3
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01} {8652/00118652/0011}
+{AI95-00117-01AI95-00117-01} {AI95-00326-01AI95-00326-01}
+{AI05-0295-1AI05-0295-1} Operational and representation aspects of a
+generic formal parameter are the same as those of the actual.
+Operational and representation aspects are the same for all views of a
+type. Specification of a type-related representation aspect is not
+allowed for a descendant of a generic formal untagged type.
+
+11.a/3
+ Ramification: {8652/00098652/0009}
+ {AI95-00137-01AI95-00137-01} {AI05-0295-1AI05-0295-1}
+ Specifying representation aspects is allowed for types whose
+ subcomponent types or index subtypes are generic formal types.
+ Specifying operational aspects and subtype-related
+ representation aspects is allowed on descendants of generic
+ formal types.
+
+11.b/3
+ Reason: {AI05-0295-1AI05-0295-1} Since it is not known whether
+ a formal type has user-defined primitive subprograms,
+ specifying type-related representation aspects for them is not
+ allowed, unless they are tagged (in which case only the
+ extension part is affected in any case).
+
+11.c/2
+ Ramification: {AI95-00326-01AI95-00326-01} All views of a
+ type, including the incomplete and partial views, have the
+ same operational and representation aspects. That's important
+ so that the properties don't change when changing views.
+ While most aspects are not available for an incomplete view,
+ we don't want to leave any holes by not saying that they are
+ the same.
+
+11.d/3
+ {AI05-0083-1AI05-0083-1} However, this does not apply to
+ objects. Different views of an object can have different
+ representation aspects. For instance, an actual object passed
+ by reference and the associated formal parameter may have
+ different values for Alignment even though the formal
+ parameter is merely a view of the actual object. This is
+ necessary to maintain the language design principle that
+ Alignments are always known at compile time.
+
+12/3
+{AI05-0295-1AI05-0295-1} The specification of the Size aspect for a
+given subtype, or the size or storage place for an object (including a
+component) of a given subtype, shall allow for enough storage space to
+accommodate any value of the subtype.
+
+13/3
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+{AI05-0295-1AI05-0295-1} If a specification of a representation or
+operational aspect is not supported by the implementation, it is illegal
+or raises an exception at run time.
+
+13.1/3
+{AI95-00251-01AI95-00251-01} {AI05-0295-1AI05-0295-1} A type_declaration
+is illegal if it has one or more progenitors, and a nonconfirming value
+was specified for a representation aspect of an ancestor, and this
+conflicts with the representation of some other ancestor. The cases
+that cause conflicts are implementation defined.
+
+13.a/2
+ Implementation defined: The cases that cause conflicts between
+ the representation of the ancestors of a type_declaration.
+
+13.b/3
+ Reason: {AI05-0295-1AI05-0295-1} This rule is needed because
+ it may be the case that only the combination of types in a
+ type declaration causes a conflict. Thus it is not possible,
+ in general, to reject the original representation item or
+ aspect_specification. For instance:
+
+13.c/2
+ package Pkg1 is
+ type Ifc is interface;
+ type T is tagged record
+ Fld : Integer;
+ end record;
+ for T use record
+ Fld at 0 range 0 .. Integer'Size - 1;
+ end record;
+ end Pkg1;
+
+13.d/2
+ Assume the implementation uses a single tag with a default
+ offset of zero, and that it allows the use of nondefault
+ locations for the tag (and thus accepts representation items
+ like the one above). The representation item will force a
+ nondefault location for the tag (by putting a component other
+ than the tag into the default location). Clearly, this
+ package will be accepted by the implementation. However,
+ other declarations could cause trouble. For instance, the
+ implementation could reject:
+
+13.e/2
+ with Pkg1;
+ package Pkg2 is
+ type NewT is new Pkg1.T and Pkg1.Ifc with null record;
+ end Pkg2;
+
+13.f/3
+ {AI05-0295-1AI05-0295-1} because the declarations of T and Ifc
+ have a conflict in their representation items. This is
+ clearly necessary (it's hard to imagine how Ifc'Class could
+ work with the tag at a location other than the one it is
+ expecting without introducing distributed overhead).
+
+13.g/3
+ {AI05-0295-1AI05-0295-1} Conflicts will usually involve
+ implementation-defined attributes (for specifying the location
+ of the tag, for instance), although the example above shows
+ that doesn't have to be the case. For this reason, we didn't
+ try to specify exactly what causes a conflict; it will depend
+ on the implementation's implementation model and what
+ representation aspects it allows to be changed.
+
+13.h/3
+ Implementation Note: {AI05-0295-1AI05-0295-1} An
+ implementation can only use this rule to reject
+ type_declarations where one of its ancestors had a
+ nonconfirming representation value specified. An
+ implementation must ensure that the default representations of
+ ancestors cannot conflict.
+
+ _Static Semantics_
+
+14
+If two subtypes statically match, then their subtype-specific aspects
+(Size and Alignment) are the same.
+
+14.a/3
+ Reason: {AI05-0295-1AI05-0295-1} This is necessary because we
+ allow (for example) conversion between access types whose
+ designated subtypes statically match. Note that most aspects
+ (including the subtype-specific aspects Size and Alignment)
+ may not be specified for a nonfirst subtype. The only
+ language-defined exceptions to this rule are the
+ Static_Predicate and Dynamic_Predicate aspects.
+
+14.b
+ Consider, for example:
+
+14.c/1
+ package P1 is
+ subtype S1 is Integer range 0..2**16-1;
+ for S1'Size use 16; -- Illegal!
+ -- S1'Size would be 16 by default.
+ type A1 is access all S1;
+ X1: A1;
+ end P1;
+
+14.d/1
+ package P2 is
+ subtype S2 is Integer range 0..2**16-1;
+ for S2'Size use 32; -- Illegal!
+ type A2 is access all S2;
+ X2: A2;
+ end P2;
+
+14.e/3
+ {AI05-0229-1AI05-0229-1} procedure Q is
+ use P1, P2;
+ type Array1 is array(Integer range <>) of aliased S1
+ with Pack;
+ Obj1: Array1(1..100);
+ type Array2 is array(Integer range <>) of aliased S2
+ with Pack;
+ Obj2: Array2(1..100);
+ begin
+ X1 := Obj2(17)'Unchecked_Access;
+ X2 := Obj1(17)'Unchecked_Access;
+ end Q;
+
+14.f
+ Loads and stores through X1 would read and write 16 bits, but
+ X1 points to a 32-bit location. Depending on the endianness
+ of the machine, loads might load the wrong 16 bits. Stores
+ would fail to zero the other half in any case.
+
+14.g
+ Loads and stores through X2 would read and write 32 bits, but
+ X2 points to a 16-bit location. Thus, adjacent memory
+ locations would be trashed.
+
+14.h
+ Hence, the above is illegal. Furthermore, the compiler is
+ forbidden from choosing different Sizes by default, for the
+ same reason.
+
+14.i
+ The same issues apply to Alignment.
+
+15/3
+{8652/00408652/0040} {AI95-00108-01AI95-00108-01}
+{AI05-0009-1AI05-0009-1} {AI05-0295-1AI05-0295-1} A derived type
+inherits each type-related representation aspect of its parent type that
+was directly specified before the declaration of the derived type, or
+(in the case where the parent is derived) that was inherited by the
+parent type from the grandparent type. A derived subtype inherits each
+subtype-specific representation aspect of its parent subtype that was
+directly specified before the declaration of the derived type, or (in
+the case where the parent is derived) that was inherited by the parent
+subtype from the grandparent subtype, but only if the parent subtype
+statically matches the first subtype of the parent type. An inherited
+representation aspect is overridden by a subsequent aspect_specification
+or representation item that specifies a different value for the same
+aspect of the type or subtype.
+
+15.a
+ To be honest: A record_representation_clause for a record
+ extension does not override the layout of the parent part; if
+ the layout was specified for the parent type, it is inherited
+ by the record extension.
+
+15.b
+ Ramification: If a representation item for the parent appears
+ after the derived_type_definition (*note 3.4: S0035.), then
+ inheritance does not happen for that representation item.
+
+15.b.1/3
+ {AI05-0009-1AI05-0009-1} {AI05-0295-1AI05-0295-1} If an
+ inherited aspect is confirmed by an aspect_specification or a
+ later representation item for a derived type, the confirming
+ specification does not override the inherited one. Thus the
+ derived type has both a specified confirming value and an
+ inherited nonconfirming representation value -- this means
+ that rules that apply only to nonconfirming representation
+ values still apply to this type.
+
+15.1/3
+{8652/00408652/0040} {AI95-00108-01AI95-00108-01}
+{AI95-00444-01AI95-00444-01} {AI05-0183-1AI05-0183-1}
+{AI05-0295-1AI05-0295-1} In contrast, whether operational aspects are
+inherited by a derived type depends on each specific aspect; unless
+specified, an operational aspect is not inherited. When operational
+aspects are inherited by a derived type, aspects that were directly
+specified by aspect_specifications or operational items that are visible
+at the point of the derived type declaration, or (in the case where the
+parent is derived) that were inherited by the parent type from the
+grandparent type are inherited. An inherited operational aspect is
+overridden by a subsequent aspect_specification or operational item that
+specifies the same aspect of the type.
+
+15.b.2/1
+ Ramification: As with representation items, if an operational
+ item for the parent appears after the derived_type_definition
+ (*note 3.4: S0035.), then inheritance does not happen for that
+ operational item.
+
+15.2/2
+{AI95-00444-01AI95-00444-01} When an aspect that is a subprogram is
+inherited, the derived type inherits the aspect in the same way that a
+derived type inherits a user-defined primitive subprogram from its
+parent (see *note 3.4::).
+
+15.c/2
+ Reason: This defines the parameter names and types, and the
+ needed implicit conversions.
+
+16
+Each aspect of representation of an entity is as follows:
+
+17
+ * If the aspect is specified for the entity, meaning that it is
+ either directly specified or inherited, then that aspect of the
+ entity is as specified, except in the case of Storage_Size, which
+ specifies a minimum.
+
+17.a
+ Ramification: This rule implies that queries of the aspect
+ return the specified value. For example, if the user writes
+ "for X'Size use 32;", then a query of X'Size will return 32.
+
+18
+ * If an aspect of representation of an entity is not specified, it is
+ chosen by default in an unspecified manner.
+
+18.a/3
+ Ramification: {8652/00098652/0009}
+ {AI95-00137-01AI95-00137-01} {AI05-0295-1AI05-0295-1} Note
+ that specifying a representation aspect can affect the
+ semantics of the entity.
+
+18.b
+ The rules forbid things like "for S'Base'Alignment use ..."
+ and "for S'Base use record ...".
+
+18.c
+ Discussion: The intent is that implementations will represent
+ the components of a composite value in the same way for all
+ subtypes of a given composite type. Hence, Component_Size and
+ record layout are type-related aspects.
+
+18.d/3
+ Ramification: {AI05-0083-1AI05-0083-1} As noted previously, in
+ the case of an object, the entity mentioned in this text is a
+ specific view of an object. That means that only references
+ to the same view of an object that has a specified value for a
+ representation aspect R necessarily have that value for the
+ aspect R. The value of the aspect R for a different view of
+ that object is unspecified. In particular, this means that
+ the representation values for by-reference parameters is
+ unspecified; they do not have to be the same as those of the
+ underlying object.
+
+18.1/1
+{8652/00408652/0040} {AI95-00108-01AI95-00108-01} If an operational
+aspect is specified for an entity (meaning that it is either directly
+specified or inherited), then that aspect of the entity is as specified.
+Otherwise, the aspect of the entity has the default value for that
+aspect.
+
+18.2/3
+{AI95-00291-02AI95-00291-02} {AI05-0295-1AI05-0295-1} An
+aspect_specification or representation item that specifies a
+representation aspect that would have been chosen in the absence of the
+aspect_specification or representation item is said to be confirming.
+The aspect value specified in this case is said to be a confirming
+representation aspect value. Other values of the aspect are said to be
+nonconfirming, as are the aspect_specifications and representation items
+that specified them.
+
+ _Dynamic Semantics_
+
+19/1
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01} For the elaboration of
+an aspect_clause, any evaluable constructs within it are evaluated.
+
+19.a/3
+ Ramification: {AI05-0299-1AI05-0299-1} Elaboration of
+ representation pragmas is covered by the general rules for
+ pragmas in *note 2.8::.
+
+ _Implementation Permissions_
+
+20/3
+{AI05-0295-1AI05-0295-1} An implementation may interpret representation
+aspects in an implementation-defined manner. An implementation may
+place implementation-defined restrictions on the specification of
+representation aspects. A recommended level of support is defined for
+the specification of representation aspects and related features in each
+subclause. These recommendations are changed to requirements for
+implementations that support the Systems Programming Annex (see *note
+C.2::, "*note C.2:: Required Representation Support").
+
+20.a/3
+ Implementation defined: The interpretation of each
+ representation aspect.
+
+20.b/3
+ Implementation defined: Any restrictions placed upon the
+ specification of representation aspects.
+
+20.c
+ Ramification: Implementation-defined restrictions may be
+ enforced either at compile time or at run time. There is no
+ requirement that an implementation justify any such
+ restrictions. They can be based on avoiding implementation
+ complexity, or on avoiding excessive inefficiency, for
+ example.
+
+20.c.1/1
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} There is no
+ such permission for operational aspects.
+
+ _Implementation Advice_
+
+21/3
+{AI05-0295-1AI05-0295-1} The recommended level of support for the
+specification of all representation aspects is qualified as follows:
+
+21.1/3
+ * {AI95-00291-02AI95-00291-02} {AI05-0295-1AI05-0295-1} A confirming
+ specification for a representation aspect should be supported.
+
+21.a/3
+ To be honest: {AI05-0295-1AI05-0295-1} A confirming
+ representation aspect value might not be possible for some
+ entities. For instance, consider an unconstrained array. The
+ size of such a type is implementation-defined, and might not
+ actually be a representable value, or might not be static.
+
+22/3
+ * {AI05-0295-1AI05-0295-1} An implementation need not support the
+ specification for a representation aspect that contains nonstatic
+ expressions, unless each nonstatic expression is a name that
+ statically denotes a constant declared before the entity.
+
+22.a
+ Reason: This is to avoid the following sort of thing:
+
+22.b
+ X : Integer := F(...);
+ Y : Address := G(...);
+ for X'Address use Y;
+
+22.c
+ In the above, we have to evaluate the initialization
+ expression for X before we know where to put the result. This
+ seems like an unreasonable implementation burden.
+
+22.d
+ The above code should instead be written like this:
+
+22.e
+ Y : constant Address := G(...);
+ X : Integer := F(...);
+ for X'Address use Y;
+
+22.f
+ This allows the expression "Y" to be safely evaluated before X
+ is created.
+
+22.g
+ The constant could be a formal parameter of mode in.
+
+22.h
+ An implementation can support other nonstatic expressions if
+ it wants to. Expressions of type Address are hardly ever
+ static, but their value might be known at compile time anyway
+ in many cases.
+
+23
+ * An implementation need not support a specification for the Size for
+ a given composite subtype, nor the size or storage place for an
+ object (including a component) of a given composite subtype, unless
+ the constraints on the subtype and its composite subcomponents (if
+ any) are all static constraints.
+
+24/3
+ * {AI95-00291-02AI95-00291-02} {AI05-0295-1AI05-0295-1} An
+ implementation need not support specifying a nonconfirming
+ representation aspect value if it could cause an aliased object or
+ an object of a by-reference type to be allocated at a
+ nonaddressable location or, when the alignment attribute of the
+ subtype of such an object is nonzero, at an address that is not an
+ integral multiple of that alignment.
+
+24.a/1
+ Reason: The intent is that access types, type System.Address,
+ and the pointer used for a by-reference parameter should be
+ implementable as a single machine address -- bit-field
+ pointers should not be required. (There is no requirement
+ that this implementation be used -- we just want to make sure
+ it's feasible.)
+
+24.b/2
+ Implementation Note: {AI95-00291-02AI95-00291-02} We want
+ subprograms to be able to assume the properties of the types
+ of their parameters inside of subprograms. While many objects
+ can be copied to allow this (and thus do not need
+ limitations), aliased or by-reference objects cannot be copied
+ (their memory location is part of their identity). Thus, the
+ above rule does not apply to types that merely allow
+ by-reference parameter passing; for such types, a copy
+ typically needs to be made at the call site when a bit-aligned
+ component is passed as a parameter.
+
+25/3
+ * {AI95-00291-02AI95-00291-02} {AI05-0295-1AI05-0295-1} An
+ implementation need not support specifying a nonconfirming
+ representation aspect value if it could cause an aliased object of
+ an elementary type to have a size other than that which would have
+ been chosen by default.
+
+25.a/2
+ Reason: Since all bits of elementary objects participate in
+ operations, aliased objects must not have a different size
+ than that assumed by users of the access type.
+
+26/3
+ * {AI95-00291-02AI95-00291-02} {AI05-0295-1AI05-0295-1} An
+ implementation need not support specifying a nonconfirming
+ representation aspect value if it could cause an aliased object of
+ a composite type, or an object whose type is by-reference, to have
+ a size smaller than that which would have been chosen by default.
+
+26.a/2
+ Reason: Unlike elementary objects, there is no requirement
+ that all bits of a composite object participate in operations.
+ Thus, as long as the object is the same or larger in size than
+ that expected by the access type, all is well.
+
+26.b/2
+ Ramification: This rule presumes that the implementation
+ allocates an object of a size specified to be larger than the
+ default size in such a way that access of the default size
+ suffices to correctly read and write the value of the object.
+
+27/3
+ * {AI95-00291-02AI95-00291-02} {AI05-0295-1AI05-0295-1} An
+ implementation need not support specifying a nonconfirming
+ subtype-specific representation aspect value for an indefinite or
+ abstract subtype.
+
+27.a/3
+ Reason: {AI05-0295-1AI05-0295-1} Representation aspects are
+ often not well-defined for such types.
+
+27.b/3
+ Ramification: {AI95-00291-02AI95-00291-02}
+ {AI05-0229-1AI05-0229-1} A type with the Pack aspect specified
+ will typically not be packed so tightly as to disobey the
+ above rules. A Component_Size clause or
+ record_representation_clause will typically be illegal if it
+ disobeys the above rules. Atomic components have similar
+ restrictions (see *note C.6::, "*note C.6:: Shared Variable
+ Control").
+
+28/3
+{AI95-00291-02AI95-00291-02} {AI05-0295-1AI05-0295-1} For purposes of
+these rules, the determination of whether specifying a representation
+aspect value for a type could cause an object to have some property is
+based solely on the properties of the type itself, not on any available
+information about how the type is used. In particular, it presumes that
+minimally aligned objects of this type might be declared at some point.
+
+28.a/2
+ Implementation Advice: The recommended level of support for
+ all representation items should be followed.
+
+ NOTES
+
+29/3
+ 1 {AI05-0229-1AI05-0229-1} Aspects that can be specified are
+ defined throughout this International Standard, and are summarized
+ in *note K.1::.
+
+ _Incompatibilities With Ada 83_
+
+29.a
+ It is now illegal for a representation item to cause a derived
+ by-reference type to have a different record layout from its
+ parent. This is necessary for by-reference parameter passing
+ to be feasible. This only affects programs that specify the
+ representation of types derived from types containing tasks;
+ most by-reference types are new to Ada 95. For example, if A1
+ is an array of tasks, and A2 is derived from A1, it is illegal
+ to apply a pragma Pack to A2.
+
+ _Extensions to Ada 83_
+
+29.b/1
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} Ada 95
+ allows additional aspect_clauses for objects.
+
+ _Wording Changes from Ada 83_
+
+29.c/1
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} The syntax
+ rule for type_representation_clause is removed; the right-hand
+ side of that rule is moved up to where it was used, in
+ aspect_clause. There are two references to "type
+ representation clause" in RM83, both in Section 13; these have
+ been reworded. Also, the representation_clause has been
+ renamed the aspect_clause to reflect that it can be used to
+ control more than just representation aspects.
+
+29.d/2
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+ {AI95-00114-01AI95-00114-01} We have defined a new term
+ "representation item," which includes all representation
+ clauses and representation pragmas, as well as
+ component_clauses. This is convenient because the rules are
+ almost identical for all of them. We have also defined the
+ new terms "operational item" and "operational aspects" in
+ order to conveniently handle new types of specifiable
+ entities.
+
+29.e
+ All of the forcing occurrence stuff has been moved into its
+ own subclause (see *note 13.14::), and rewritten to use the
+ term "freezing".
+
+29.f
+ RM83-13.1(10) requires implementation-defined restrictions on
+ representation items to be enforced at compile time. However,
+ that is impossible in some cases. If the user specifies a
+ junk (nonstatic) address in an address clause, and the
+ implementation chooses to detect the error (for example, using
+ hardware memory management with protected pages), then it's
+ clearly going to be a run-time error. It seems silly to call
+ that "semantics" rather than "a restriction."
+
+29.g
+ RM83-13.1(10) tries to pretend that representation_clauses
+ don't affect the semantics of the program. One
+ counter-example is the Small clause. Ada 95 has more
+ counter-examples. We have noted the opposite above.
+
+29.h
+ Some of the more stringent requirements are moved to *note
+ C.2::, "*note C.2:: Required Representation Support".
+
+ _Extensions to Ada 95_
+
+29.i/2
+ {AI95-00291-02AI95-00291-02} Amendment Correction: Confirming
+ representation items are defined, and the recommended level of
+ support is now that they always be supported.
+
+ _Wording Changes from Ada 95_
+
+29.j/2
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} Corrigendum:
+ Added operational items in order to eliminate unnecessary
+ restrictions and permissions on stream attributes. As part of
+ this, representation_clause was renamed to aspect_clause.
+
+29.k/2
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+ {AI95-00326-01AI95-00326-01} Corrigendum: Added wording to say
+ that the partial and full views have the same operational and
+ representation aspects. Ada 2005 extends this to cover all
+ views, including the incomplete view.
+
+29.l/2
+ {8652/00408652/0040} {AI95-00108-01AI95-00108-01} Corrigendum:
+ Changed operational items to have inheritance specified for
+ each such aspect.
+
+29.m/2
+ {AI95-00251-01AI95-00251-01} Added wording to allow the
+ rejection of types with progenitors that have conflicting
+ representation items.
+
+29.n/2
+ {AI95-00291-02AI95-00291-02} The description of the
+ representation of an object was clarified (with great
+ difficulty reaching agreement). Added wording to say that
+ representation items on aliased and by-reference objects never
+ need be supported if they would not be implementable without
+ distributed overhead even if other recommended level of
+ support says otherwise. This wording matches the rules with
+ reality.
+
+29.o/3
+ {AI95-00444-01AI95-00444-01} {AI05-0005-1AI05-0005-1} Added
+ wording so that inheritance depends on whether operational
+ items are visible rather than whether they occur before the
+ declaration (we don't want to look into private parts). Also
+ limited operational inheritance to untagged types to avoid
+ anomalies with private extensions (this is not incompatible,
+ no existing operational attribute used this capability). Also
+ added wording to clearly define that subprogram inheritance
+ works like derivation of subprograms.
+
+ _Incompatibilities With Ada 2005_
+
+29.p/3
+ {AI05-0106-1AI05-0106-1} Correction: Specifying a
+ language-defined aspect for a generic formal parameter is no
+ longer allowed. Most aspects could not be specified on these
+ anyway; moreover, this was not allowed in Ada 83, so it is
+ unlikely that compilers are supporting this as a capability
+ (and it is not likely that they have a consistent definition
+ of what it means if it is allowed). Thus, we expect this to
+ occur rarely in existing programs.
+
+ _Wording Changes from Ada 2005_
+
+29.q/3
+ {AI05-0009-1AI05-0009-1} Correction: Defined that overriding
+ of an representation aspect only happens for a nonconfirming
+ representation item. This prevents a derived type from being
+ considered to have only a confirming representation item when
+ the value would be nonconfirming if given on a type that does
+ not inherit any aspects of representation. This change just
+ eliminates a wording confusion and ought not change any
+ behavior.
+
+29.r/3
+ {AI05-0112-1AI05-0112-1} Correction: Defined a default naming
+ for representation aspects that are representation pragmas.
+
+29.s/3
+ {AI05-0183-1AI05-0183-1} Added text ensuring that the rules
+ for representational and operational items also apply
+ appropriately to aspect_specifications; generalized
+ operational aspects so that they can be defined for entities
+ other than types. Any extensions are documented elsewhere.
+
+29.t/3
+ {AI05-0295-1AI05-0295-1} Rewrote many rules to be in terms of
+ "specifying a representation aspect" rather than use of a
+ "representation item". This better separates how an aspect is
+ specified from what rules apply to the value of the aspect.
+
+* Menu:
+
+* 13.1.1 :: Aspect Specifications
+
+\1f
+File: aarm2012.info, Node: 13.1.1, Up: 13.1
+
+13.1.1 Aspect Specifications
+----------------------------
+
+1/3
+{AI05-0183-1AI05-0183-1} [Certain representation or operational aspects
+of an entity may be specified as part of its declaration using an
+aspect_specification, rather than using a separate representation or
+operational item.] The declaration with the aspect_specification is
+termed the associated declaration.
+
+ _Syntax_
+
+2/3
+ {AI05-0183-1AI05-0183-1} aspect_specification ::=
+ with aspect_mark [=> aspect_definition] {,
+ aspect_mark [=> aspect_definition] }
+
+3/3
+ {AI05-0183-1AI05-0183-1} aspect_mark ::= aspect_identifier['Class]
+
+4/3
+ {AI05-0183-1AI05-0183-1} aspect_definition ::= name | expression |
+ identifier
+
+ _Language Design Principles_
+
+4.a/3
+ {AI05-0183-1AI05-0183-1} {AI05-0267-1AI05-0267-1} The
+ aspect_specification is an optional element in most kinds of
+ declarations. Here is a list of all kinds of declarations and
+ an indication of whether or not they allow aspect clauses, and
+ in some cases a short discussion of why (* = allowed, NO = not
+ allowed). Kinds of declarations with no indication are
+ followed by their subdivisions (which have indications).
+
+4.b/3
+ basic_declaration
+ type_declaration
+ full_type_declaration
+ type declaration syntax*
+ task_type_declaration*
+ protected_type_declaration*
+ incomplete_type_declaration -- NO
+ -- Incomplete type aspects cannot be read by an attribute or specified by attribute_definition_clauses
+ -- (the attribute name is illegal), so it would not make sense to allow this in another way.
+ private_type_declaration*
+ private_extension_declaration*
+ subtype_declaration*
+ object_declaration
+ object declaration syntax*
+ single_task_declaration*
+ single_protected_declaration*
+ number_declaration -- NO
+ subprogram_declaration*
+ abstract_subprogram_declaration*
+ null_procedure_declaration*
+ package_declaration* -- via package_specification
+ renaming_declaration*
+ -- There are no language-defined aspects that may be specified
+ -- on renames, but implementations might support some.
+ exception_declaration*
+ generic_declaration
+ generic_subprogram_declaration*
+ generic_package_declaration* -- via package_specification
+ generic_instantiation*
+ enumeration_literal_specification -- NO
+ discriminant_specification -- NO
+ component_declaration*
+ loop_parameter_specification -- NO
+ iterator_specification -- NO
+ parameter_specification -- NO
+ subprogram_body* -- - but language-defined aspects only if there is no explicit specification
+ entry_declaration*
+ entry_index_specification -- NO
+ subprogram_body_stub* -- - but language-defined aspects only if there is no explicit specification
+ choice_parameter_specification -- NO
+ generic_formal_parameter_declaration
+ -- There are no language-defined aspects that may be specified
+ -- on generic formals, but implementations might support some.
+ formal_object_declaration*
+ formal_type_declaration*
+ formal_subprogram_declaration
+ formal_concrete_subprogram_declaration*
+ formal_abstract_subprogram_declaration*
+ formal_package_declaration*
+ extended_return_statement -- NO
+
+4.c/3
+ -- We also allow aspect_specifications on all kinds of bodies, but are no language-defined aspects
+ -- that may be specified on a body. These are allowed for implementation-defined aspects.
+ -- See above for subprogram bodies and stubs (as these can be declarations).
+ package_body*
+ task_body*
+ protected_body*
+ package_body_stub*
+ task_body_stub*
+ protected_body_stub*
+
+4.d/3
+ {AI05-0267-1AI05-0267-1} Syntactically, aspect_specifications
+ generally are located at the end of declarations. When a
+ declaration is all in one piece such as a
+ null_procedure_declaration, object_declaration, or
+ generic_instantiation the aspect_specification goes at the end
+ of the declaration; it is then more visible and less likely to
+ interfere with the layout of the rest of the structure.
+ However, we make an exception for program units (other than
+ subprogram specifications) and bodies, in which the
+ aspect_specification goes before the is. In these cases, the
+ entity could be large and could contain other declarations
+ that also have aspect_specifications, so it is better to put
+ the aspect_specification toward the top of the declaration.
+ (Some aspects - such as Pure - also affect the legality of the
+ contents of a unit, so it would be annoying to only see those
+ after reading the entire unit.)
+
+ _Name Resolution Rules_
+
+5/3
+{AI05-0183-1AI05-0183-1} An aspect_mark identifies an aspect of the
+entity defined by the associated declaration (the associated entity);
+the aspect denotes an object, a value, an expression, a subprogram, or
+some other kind of entity. If the aspect_mark identifies:
+
+6/3
+ * an aspect that denotes an object, the aspect_definition shall be a
+ name. The expected type for the name is the type of the identified
+ aspect of the associated entity;
+
+7/3
+ * an aspect that is a value or an expression, the aspect_definition
+ shall be an expression. The expected type for the expression is
+ the type of the identified aspect of the associated entity;
+
+8/3
+ * an aspect that denotes a subprogram, the aspect_definition shall be
+ a name; the expected profile for the name is the profile required
+ for the aspect of the associated entity;
+
+9/3
+ * an aspect that denotes some other kind of entity, the
+ aspect_definition shall be a name, and the name shall resolve to
+ denote an entity of the appropriate kind;
+
+10/3
+ * an aspect that is given by an identifier specific to the aspect,
+ the aspect_definition shall be an identifier, and the identifier
+ shall be one of the identifiers specific to the identified aspect.
+
+11/3
+{AI05-0183-1AI05-0183-1} The usage names in an aspect_definition [ are
+not resolved at the point of the associated declaration, but rather] are
+resolved at the end of the immediately enclosing declaration list.
+
+12/3
+{AI05-0183-1AI05-0183-1} If the associated declaration is for a
+subprogram or entry, the names of the formal parameters are directly
+visible within the aspect_definition, as are certain attributes, as
+specified elsewhere in this International Standard for the identified
+aspect. If the associated declaration is a type_declaration, within the
+aspect_definition the names of any components are directly visible, and
+the name of the first subtype denotes the current instance of the type
+(see *note 8.6::). If the associated declaration is a
+subtype_declaration, within the aspect_definition the name of the new
+subtype denotes the current instance of the subtype.
+
+ _Legality Rules_
+
+13/3
+{AI05-0183-1AI05-0183-1} If the first freezing point of the associated
+entity comes before the end of the immediately enclosing declaration
+list, then each usage name in the aspect_definition shall resolve to the
+same entity at the first freezing point as it does at the end of the
+immediately enclosing declaration list.
+
+14/3
+{AI05-0183-1AI05-0183-1} At most one occurrence of each aspect_mark is
+allowed within a single aspect_specification. The aspect identified by
+the aspect_mark shall be an aspect that can be specified for the
+associated entity (or view of the entity defined by the associated
+declaration).
+
+15/3
+{AI05-0183-1AI05-0183-1} The aspect_definition associated with a given
+aspect_mark may be omitted only when the aspect_mark identifies an
+aspect of a boolean type, in which case it is equivalent to the
+aspect_definition being specified as True.
+
+16/3
+{AI05-0183-1AI05-0183-1} If the aspect_mark includes 'Class, then the
+associated entity shall be a tagged type or a primitive subprogram of a
+tagged type.
+
+17/3
+{AI05-0183-1AI05-0183-1} {AI05-0267-1AI05-0267-1} There are no
+language-defined aspects that may be specified on a
+renaming_declaration, a generic_formal_parameter_declaration, a subunit,
+a package_body, a task_body, a protected_body, or a body_stub other than
+a subprogram_body_stub.
+
+17.a/3
+ Discussion: Implementation-defined aspects can be allowed on
+ these, of course; the implementation will need to define the
+ semantics. In particular, the implementation will need to
+ define actual type matching rules for any aspects allowed on
+ formal types; there are no default matching rules defined by
+ the language.
+
+18/3
+{AI05-0183-1AI05-0183-1} {AI05-0267-1AI05-0267-1} A language-defined
+aspect shall not be specified in an aspect_specification given on a
+subprogram_body or subprogram_body_stub that is a completion of another
+declaration.
+
+18.a/3
+ Reason: Most language-defined aspects (for example,
+ preconditions) are intended to be available to callers, and
+ specifying them on a body that has a separate declaration
+ hides them from callers. Specific language-defined aspects
+ may allow this, but they have to do so explicitly (by defining
+ an alternative Legality Rule), and provide any needed rules
+ about visibility. Note that this rule does not apply to
+ implementation-defined aspects, so implementers need to
+ carefully define whether such aspects can be applied to bodies
+ and stubs, and what happens if they are specified on both the
+ declaration and body of a unit.
+
+ _Static Semantics_
+
+19/3
+{AI05-0183-1AI05-0183-1} Depending on which aspect is identified by the
+aspect_mark, an aspect_definition specifies:
+
+20/3
+ * a name that denotes a subprogram, object, or other kind of entity;
+
+21/3
+ * an expression, which is either evaluated to produce a single value,
+ or which (as in a precondition) is to be evaluated at particular
+ points during later execution; or
+
+22/3
+ * an identifier specific to the aspect.
+
+23/3
+{AI05-0183-1AI05-0183-1} The identified aspect of the associated entity,
+or in some cases, the view of the entity defined by the declaration, is
+as specified by the aspect_definition (or by the default of True when
+boolean). Whether an aspect_specification applies to an entity or only
+to the particular view of the entity defined by the declaration is
+determined by the aspect_mark and the kind of entity. The following
+aspects are view specific:
+
+24/3
+ * An aspect specified on an object_declaration;
+
+25/3
+ * An aspect specified on a subprogram_declaration;
+
+26/3
+ * An aspect specified on a renaming_declaration.
+
+27/3
+{AI05-0183-1AI05-0183-1} All other aspect_specifications are associated
+with the entity, and apply to all views of the entity, unless otherwise
+specified in this International Standard.
+
+28/3
+{AI05-0183-1AI05-0183-1} If the aspect_mark includes 'Class, then:
+
+29/3
+ * if the associated entity is a tagged type, the specification
+ applies to all descendants of the type;
+
+30/3
+ * if the associated entity is a primitive subprogram of a tagged type
+ T, the specification applies to the corresponding primitive
+ subprogram of all descendants of T.
+
+31/3
+{AI05-0183-1AI05-0183-1} {AI05-0229-1AI05-0229-1} All specifiable
+operational and representation attributes may be specified with an
+aspect_specification instead of an attribute_definition_clause (see
+*note 13.3::).
+
+31.a/3
+ Ramification: The name of the aspect is the same as that of
+ the attribute (see *note 13.3::), so the aspect_mark is the
+ attribute_designator of the attribute.
+
+32/3
+{AI05-0229-1AI05-0229-1} Any aspect specified by a representation pragma
+or library unit pragma that has a local_name as its single argument may
+be specified by an aspect_specification, with the entity being the
+local_name. The aspect_definition is expected to be of type Boolean.
+The expression shall be static.
+
+32.a/3
+ Ramification: The name of the aspect is the same as that of
+ the pragma (see *note 13.1::), so the aspect_mark is the name
+ of the pragma.
+
+33/3
+{AI05-0229-1AI05-0229-1} In addition, other operational and
+representation aspects not associated with specifiable attributes or
+representation pragmas may be specified, as specified elsewhere in this
+International Standard.
+
+34/3
+{AI05-0183-1AI05-0183-1} If an aspect of a derived type is inherited
+from an ancestor type and has the boolean value True, the inherited
+value shall not be overridden to have the value False for the derived
+type, unless otherwise specified in this International Standard.
+
+35/3
+{AI05-0183-1AI05-0183-1} If a Legality Rule or Static Semantics rule
+only applies when a particular aspect has been specified, the aspect is
+considered to have been specified only when the aspect_specification or
+attribute_definition_clause is visible (see *note 8.3::) at the point of
+the application of the rule.
+
+35.a/3
+ Reason: Some rules only apply when an aspect has been
+ specified (for instance, an indexable type is one that has
+ aspect Variable_Indexing specified). In order to prevent
+ privacy breaking, this can only be true when the specification
+ of the aspect is visible. In particular, if the
+ Variable_Indexing aspect is specified on the full view of a
+ private type, the private type is not considered an indexable
+ type.
+
+36/3
+{AI05-0183-1AI05-0183-1} Alternative legality and semantics rules may
+apply for particular aspects, as specified elsewhere in this
+International Standard.
+
+ _Dynamic Semantics_
+
+37/3
+{AI05-0183-1AI05-0183-1} At the freezing point of the associated entity,
+the aspect_specification is elaborated. The elaboration of the
+aspect_specification includes the evaluation of the name or expression,
+if any, unless the aspect itself is an expression. If the corresponding
+aspect represents an expression (as in a precondition), the elaboration
+has no effect; the expression is evaluated later at points within the
+execution as specified elsewhere in this International Standard for the
+particular aspect.
+
+ _Implementation Permissions_
+
+38/3
+{AI05-0183-1AI05-0183-1} Implementations may support
+implementation-defined aspects. The aspect_specification for an
+implementation-defined aspect may use an implementation-defined syntax
+for the aspect_definition, and may follow implementation-defined
+legality and semantics rules.
+
+38.a/3
+ Discussion: The intent is to allow implementations to support
+ aspects that are defined, for example, by a subtype_indication
+ rather than an expression or a name. We chose not to try to
+ enumerate all possible aspect_definition syntaxes, but to give
+ implementations maximum freedom. Unrecognized aspects are
+ illegal whether or not they use custom syntax, so this freedom
+ does not reduce portability.
+
+38.a.1/3
+ Implementation defined: Implementation-defined aspects,
+ inluding the syntax for specifying such aspects and the
+ legality rules for such aspects.
+
+ _Extensions to Ada 2005_
+
+38.b/3
+ {AI05-0183-1AI05-0183-1} {AI05-0229-1AI05-0229-1}
+ {AI05-0267-1AI05-0267-1} Aspect specifications are new.
+
+\1f
+File: aarm2012.info, Node: 13.2, Next: 13.3, Prev: 13.1, Up: 13
+
+13.2 Packed Types
+=================
+
+1/3
+{AI05-0229-1AI05-0229-1} [The Pack aspect having the value True
+specifies that storage minimization should be the main criterion when
+selecting the representation of a composite type.]
+
+Paragraphs 2 through 4 were moved to *note Annex J::, "*note Annex J::
+Obsolescent Features".
+
+ _Static Semantics_
+
+5/3
+{AI05-0229-1AI05-0229-1} For a full type declaration of a composite
+type, the following language-defined representation aspect may be
+specified:
+
+5.1/3
+Pack
+ The type of aspect Pack is Boolean. When aspect Pack is
+ True for a type, the type (or the extension part) is said
+ to be packed. For a type extension, the parent part is
+ packed as for the parent type, and specifying Pack causes
+ packing only of the extension part.
+
+5.a/3
+ Aspect Description for Pack: Minimize storage when laying out
+ records and arrays.
+
+5.2/3
+ If directly specified, the aspect_definition shall be a
+ static expression. If not specified (including by
+ inheritance), the aspect is False.
+
+5.b/3
+ Ramification: {AI05-0229-1AI05-0229-1} The only high level
+ semantic effect of specifying the Pack aspect is potential
+ loss of independent addressability (see *note 9.10::, "*note
+ 9.10:: Shared Variables").]
+
+ _Implementation Advice_
+
+6
+If a type is packed, then the implementation should try to minimize
+storage allocated to objects of the type, possibly at the expense of
+speed of accessing components, subject to reasonable complexity in
+addressing calculations.
+
+6.a.1/2
+ Implementation Advice: Storage allocated to objects of a
+ packed type should be minimized.
+
+6.a/3
+ Ramification: {AI05-0229-1AI05-0229-1} Specifying the Pack
+ aspect is for gaining space efficiency, possibly at the
+ expense of time. If more explicit control over representation
+ is desired, then a record_representation_clause, a
+ Component_Size clause, or a Size clause should be used instead
+ of, or in addition to, the Pack aspect.
+
+6.1/2
+{AI95-00291-02AI95-00291-02} If a packed type has a component that is
+not of a by-reference type and has no aliased part, then such a
+component need not be aligned according to the Alignment of its subtype;
+in particular it need not be allocated on a storage element boundary.
+
+7/3
+{AI05-0229-1AI05-0229-1} The recommended level of support for the Pack
+aspect is:
+
+8
+ * For a packed record type, the components should be packed as
+ tightly as possible subject to the Sizes of the component subtypes,
+ and subject to any record_representation_clause that applies to the
+ type; the implementation may, but need not, reorder components or
+ cross aligned word boundaries to improve the packing. A component
+ whose Size is greater than the word size may be allocated an
+ integral number of words.
+
+8.a
+ Ramification: The implementation can always allocate an
+ integral number of words for a component that will not fit in
+ a word. The rule also allows small component sizes to be
+ rounded up if such rounding does not waste space. For
+ example, if Storage_Unit = 8, then a component of size 8 is
+ probably more efficient than a component of size 7 plus a
+ 1-bit gap (assuming the gap is needed anyway).
+
+9/3
+ * {AI05-0009-1AI05-0009-1} For a packed array type, if the Size of
+ the component subtype is less than or equal to the word size,
+ Component_Size should be less than or equal to the Size of the
+ component subtype, rounded up to the nearest factor of the word
+ size.
+
+9.a
+ Ramification: If a component subtype is aliased, its Size will
+ generally be a multiple of Storage_Unit, so it probably won't
+ get packed very tightly.
+
+9.b/3
+ Implementation Advice: The recommended level of support for
+ the Pack aspect should be followed.
+
+ _Wording Changes from Ada 95_
+
+9.c/3
+ {AI95-00291-02AI95-00291-02} {AI05-0229-1AI05-0229-1} Added
+ clarification that the Pack aspect can ignore alignment
+ requirements on types that don't have by-reference or aliased
+ parts. This was always intended, but there was no wording to
+ that effect.
+
+ _Extensions to Ada 2005_
+
+9.d/3
+ {AI05-0229-1AI05-0229-1} Aspect Pack is new; pragma Pack is
+ now obsolescent.
+
+ _Wording Changes from Ada 2005_
+
+9.e/3
+ {AI05-0009-1AI05-0009-1} Correction: Fixed so that the
+ presence or absence of a confirming Component_Size
+ representation clause does not change the meaning of the Pack
+ aspect.
+
+\1f
+File: aarm2012.info, Node: 13.3, Next: 13.4, Prev: 13.2, Up: 13
+
+13.3 Operational and Representation Attributes
+==============================================
+
+1/1
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01} [ The values of
+certain implementation-dependent characteristics can be obtained by
+interrogating appropriate operational or representation attributes.
+Some of these attributes are specifiable via an
+attribute_definition_clause.]
+
+ _Language Design Principles_
+
+1.a
+ In general, the meaning of a given attribute should not depend
+ on whether the attribute was specified via an
+ attribute_definition_clause, or chosen by default by the
+ implementation.
+
+ _Syntax_
+
+2
+ attribute_definition_clause ::=
+ for local_name'attribute_designator use expression;
+ | for local_name'attribute_designator use name;
+
+ _Name Resolution Rules_
+
+3
+For an attribute_definition_clause that specifies an attribute that
+denotes a value, the form with an expression shall be used. Otherwise,
+the form with a name shall be used.
+
+4
+For an attribute_definition_clause that specifies an attribute that
+denotes a value or an object, the expected type for the expression or
+name is that of the attribute. For an attribute_definition_clause that
+specifies an attribute that denotes a subprogram, the expected profile
+for the name is the profile required for the attribute. For an
+attribute_definition_clause that specifies an attribute that denotes
+some other kind of entity, the name shall resolve to denote an entity of
+the appropriate kind.
+
+4.a
+ Ramification: For example, the Size attribute is of type
+ universal_integer. Therefore, the expected type for Y in "for
+ X'Size use Y;" is universal_integer, which means that Y can be
+ of any integer type.
+
+4.b
+ Discussion: For attributes that denote subprograms, the
+ required profile is indicated separately for the individual
+ attributes.
+
+4.c
+ Ramification: For an attribute_definition_clause with a name,
+ the name need not statically denote the entity it denotes.
+ For example, the following kinds of things are allowed:
+
+4.d
+ for Some_Access_Type'Storage_Pool use Storage_Pool_Array(I);
+ for Some_Type'Read use Subprogram_Pointer.all;
+
+ _Legality Rules_
+
+5/3
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+{AI05-0183-1AI05-0183-1} An attribute_designator is allowed in an
+attribute_definition_clause only if this International Standard
+explicitly allows it, or for an implementation-defined attribute if the
+implementation allows it. Each specifiable attribute constitutes an
+operational aspect or aspect of representation; the name of the aspect
+is that of the attribute.
+
+5.a
+ Discussion: For each specifiable attribute, we generally say
+ something like, "The ... attribute may be specified for ...
+ via an attribute_definition_clause."
+
+5.b
+ The above wording allows for T'Class'Alignment, T'Class'Size,
+ T'Class'Input, and T'Class'Output to be specifiable.
+
+5.c
+ A specifiable attribute is not necessarily specifiable for all
+ entities for which it is defined. For example, one is allowed
+ to ask T'Component_Size for an array subtype T, but "for
+ T'Component_Size use ..." is only allowed if T is a first
+ subtype, because Component_Size is a type-related aspect.
+
+6
+For an attribute_definition_clause that specifies an attribute that
+denotes a subprogram, the profile shall be mode conformant with the one
+required for the attribute, and the convention shall be Ada. Additional
+requirements are defined for particular attributes.
+
+6.a
+ Ramification: This implies, for example, that if one writes:
+
+6.b
+ for T'Read use R;
+
+6.c
+ R has to be a procedure with two parameters with the
+ appropriate subtypes and modes as shown in *note 13.13.2::.
+
+ _Static Semantics_
+
+7/2
+{AI95-00270-01AI95-00270-01} A Size clause is an
+attribute_definition_clause whose attribute_designator is Size. Similar
+definitions apply to the other specifiable attributes.
+
+7.a
+ To be honest: An attribute_definition_clause is type-related
+ or subtype-specific if the attribute_designator denotes a
+ type-related or subtype-specific attribute, respectively.
+
+8
+A storage element is an addressable element of storage in the machine.
+A word is the largest amount of storage that can be conveniently and
+efficiently manipulated by the hardware, given the implementation's
+run-time model. A word consists of an integral number of storage
+elements.
+
+8.a
+ Discussion: A storage element is not intended to be a single
+ bit, unless the machine can efficiently address individual
+ bits.
+
+8.b
+ Ramification: For example, on a machine with 8-bit storage
+ elements, if there exist 32-bit integer registers, with a full
+ set of arithmetic and logical instructions to manipulate those
+ registers, a word ought to be 4 storage elements -- that is,
+ 32 bits.
+
+8.c
+ Discussion: The "given the implementation's run-time model"
+ part is intended to imply that, for example, on an 80386
+ running MS-DOS, the word might be 16 bits, even though the
+ hardware can support 32 bits.
+
+8.d
+ A word is what ACID refers to as a "natural hardware
+ boundary".
+
+8.e
+ Storage elements may, but need not be, independently
+ addressable (see *note 9.10::, "*note 9.10:: Shared
+ Variables"). Words are expected to be independently
+ addressable.
+
+8.1/3
+{AI95-00133-01AI95-00133-01} {AI05-0092-1AI05-0092-1} A machine scalar
+is an amount of storage that can be conveniently and efficiently loaded,
+stored, or operated upon by the hardware. Machine scalars consist of an
+integral number of storage elements. The set of machine scalars is
+implementation defined, but includes at least the storage element and
+the word. Machine scalars are used to interpret component_clauses when
+the nondefault bit ordering applies.
+
+8.e.1/2
+ Implementation defined: The set of machine scalars.
+
+8.f/3
+ Ramification: {AI05-0092-1AI05-0092-1} A single storage
+ element is a machine scalar in all Ada implementations.
+ Similarly, a word is a machine scalar in all implementations
+ (although it might be the same as a storage element). An
+ implementation may define other machine scalars that make
+ sense on the target (a half-word, for instance).
+
+9/3
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+{AI05-0191-1AI05-0191-1} The following representation attributes are
+defined: Address, Alignment, Size, Storage_Size, Component_Size,
+Has_Same_Storage, and Overlaps_Storage.
+
+10/1
+For a prefix X that denotes an object, program unit, or label:
+
+11
+X'Address
+ Denotes the address of the first of the storage elements
+ allocated to X. For a program unit or label, this value
+ refers to the machine code associated with the
+ corresponding body or statement. The value of this
+ attribute is of type System.Address.
+
+11.a
+ Ramification: Here, the "first of the storage elements" is
+ intended to mean the one with the lowest address; the
+ endianness of the machine doesn't matter.
+
+11.1/3
+ {AI05-0095-1AI05-0095-1} The prefix of X'Address shall
+ not statically denote a subprogram that has convention
+ Intrinsic. X'Address raises Program_Error if X denotes a
+ subprogram that has convention Intrinsic.
+
+12
+ Address may be specified for stand-alone objects and for
+ program units via an attribute_definition_clause.
+
+12.a
+ Ramification: Address is not allowed for enumeration literals,
+ predefined operators, derived task types, or derived protected
+ types, since they are not program units.
+
+12.b/3
+ Address is not allowed for intrinsic subprograms, either.
+ That can be checked statically unless the prefix is a generic
+ formal subprogram and the attribute reference is in the body
+ of a generic unit. We define that case to raise
+ Program_Error, in order that the compiler does not have to
+ build a wrapper for intrinsic subprograms.
+
+12.c
+ The validity of a given address depends on the run-time model;
+ thus, in order to use Address clauses correctly, one needs
+ intimate knowledge of the run-time model.
+
+12.d/3
+ {AI05-0229-1AI05-0229-1} If the Address of an object is
+ specified, any explicit or implicit initialization takes place
+ as usual, unless the Import aspect is also specified for the
+ object (in which case any necessary initialization is
+ presumably done in the foreign language).
+
+12.e
+ Any compilation unit containing an attribute_reference of a
+ given type depends semantically on the declaration of the
+ package in which the type is declared, even if not mentioned
+ in an applicable with_clause -- see *note 10.1.1::. In this
+ case, it means that if a compilation unit contains X'Address,
+ then it depends on the declaration of System. Otherwise, the
+ fact that the value of Address is of a type in System wouldn't
+ make sense; it would violate the "legality determinable via
+ semantic dependences" Language Design Principle.
+
+12.f
+ AI83-00305 -- If X is a task type, then within the body of X,
+ X denotes the current task object; thus, X'Address denotes the
+ object's address.
+
+12.g
+ Interrupt entries and their addresses are described in *note
+ J.7.1::, "*note J.7.1:: Interrupt Entries".
+
+12.h
+ If X is not allocated on a storage element boundary, X'Address
+ points at the first of the storage elements that contains any
+ part of X. This is important for the definition of the
+ Position attribute to be sensible.
+
+12.i/3
+ Aspect Description for Address: Machine address of an entity.
+
+ _Erroneous Execution_
+
+13/3
+{AI05-0009-1AI05-0009-1} If an Address is specified, it is the
+programmer's responsibility to ensure that the address is valid and
+appropriate for the entity and its use; otherwise, program execution is
+erroneous.
+
+13.a
+ Discussion: "Appropriate for the entity and its use" covers
+ cases such as misaligned addresses, read-only code addresses
+ for variable data objects (and nonexecutable data addresses
+ for code units), and addresses which would force objects that
+ are supposed to be independently addressable to not be. Such
+ addresses may be "valid" as they designate locations that are
+ accessible to the program, but the program execution is still
+ erroneous (meaning that implementations do not have to worry
+ about these cases).
+
+ _Implementation Advice_
+
+14
+For an array X, X'Address should point at the first component of the
+array, and not at the array bounds.
+
+14.a.1/2
+ Implementation Advice: For an array X, X'Address should point
+ at the first component of the array rather than the array
+ bounds.
+
+14.a
+ Ramification: On the other hand, we have no advice to offer
+ about discriminants and tag fields; whether or not the address
+ points at them is not specified by the language. If
+ discriminants are stored separately, then the Position of a
+ discriminant might be negative, or might raise an exception.
+
+15
+The recommended level of support for the Address attribute is:
+
+16
+ * X'Address should produce a useful result if X is an object that is
+ aliased or of a by-reference type, or is an entity whose Address
+ has been specified.
+
+16.a
+ Reason: Aliased objects are the ones for which the
+ Unchecked_Access attribute is allowed; hence, these have to be
+ allocated on an addressable boundary anyway. Similar
+ considerations apply to objects of a by-reference type.
+
+16.b
+ An implementation need not go to any trouble to make Address
+ work in other cases. For example, if an object X is not
+ aliased and not of a by-reference type, and the implementation
+ chooses to store it in a register, X'Address might return
+ System.Null_Address (assuming registers are not addressable).
+ For a subprogram whose calling convention is Intrinsic, or for
+ a package, the implementation need not generate an out-of-line
+ piece of code for it.
+
+17
+ * An implementation should support Address clauses for imported
+ subprograms.
+
+18/2
+ * This paragraph was deleted.{AI95-00291-02AI95-00291-02}
+
+18.a/2
+ This paragraph was deleted.
+
+19
+ * If the Address of an object is specified, or it is imported or
+ exported, then the implementation should not perform optimizations
+ based on assumptions of no aliases.
+
+19.a/2
+ Implementation Advice: The recommended level of support for
+ the Address attribute should be followed.
+
+ NOTES
+
+20
+ 2 The specification of a link name with the Link_Name aspect (see
+ *note B.1::) for a subprogram or object is an alternative to
+ explicit specification of its link-time address, allowing a
+ link-time directive to place the subprogram or object within
+ memory.
+
+21
+ 3 The rules for the Size attribute imply, for an aliased object X,
+ that if X'Size = Storage_Unit, then X'Address points at a storage
+ element containing all of the bits of X, and only the bits of X.
+
+ _Wording Changes from Ada 83_
+
+21.a
+ The intended meaning of the various attributes, and their
+ attribute_definition_clauses, is more explicit.
+
+21.b
+ The address_clause has been renamed to at_clause and moved to
+ *note Annex J::, "*note Annex J:: Obsolescent Features". One
+ can use an Address clause ("for T'Address use ...;") instead.
+
+21.c
+ The attributes defined in RM83-13.7.3 are moved to *note Annex
+ G::, *note A.5.3::, and *note A.5.4::.
+
+ _Wording Changes from Ada 2005_
+
+21.c.1/3
+ {AI05-0183-1AI05-0183-1} Defined that the names of aspects are
+ the same as the name of the attribute; that gives a name to
+ use in aspect_specifications (see *note 13.1.1::).
+
+ _Language Design Principles_
+
+21.d
+ By default, the Alignment of a subtype should reflect the
+ "natural" alignment for objects of the subtype on the machine.
+ The Alignment, whether specified or default, should be known
+ at compile time, even though Addresses are generally not known
+ at compile time. (The generated code should never need to
+ check at run time the number of zero bits at the end of an
+ address to determine an alignment).
+
+21.e
+ There are two symmetric purposes of Alignment clauses,
+ depending on whether or not the implementation has control
+ over object allocation. If the implementation allocates an
+ object, the implementation should ensure that the Address and
+ Alignment are consistent with each other. If something
+ outside the implementation allocates an object, the
+ implementation should be allowed to assume that the Address
+ and Alignment are consistent, but should not assume stricter
+ alignments than that.
+
+ _Static Semantics_
+
+22/2
+{AI95-00291-02AI95-00291-02} For a prefix X that denotes an object:
+
+23/2
+X'Alignment
+ {AI95-00291-02AI95-00291-02} The value of this attribute
+ is of type universal_integer, and nonnegative; zero means
+ that the object is not necessarily aligned on a storage
+ element boundary. If X'Alignment is not zero, then X is
+ aligned on a storage unit boundary and X'Address is an
+ integral multiple of X'Alignment (that is, the Address
+ modulo the Alignment is zero).
+
+24/2
+
+ This paragraph was deleted.{AI95-00291-02AI95-00291-02}
+
+24.a
+ Ramification: The Alignment is passed by an allocator to the
+ Allocate operation; the implementation has to choose a value
+ such that if the address returned by Allocate is aligned as
+ requested, the generated code can correctly access the object.
+
+24.b
+ The above mention of "modulo" is referring to the "mod"
+ operator declared in System.Storage_Elements; if X mod N = 0,
+ then X is by definition aligned on an N-storage-element
+ boundary.
+
+25/2
+ {AI95-00291-02AI95-00291-02} Alignment may be specified
+ for [stand-alone] objects via an
+ attribute_definition_clause (*note 13.3: S0309.); the
+ expression of such a clause shall be static, and its
+ value nonnegative.
+
+25.a/3
+ Aspect Description for Alignment (object): Alignment of an
+ object.
+
+26/2
+
+ This paragraph was deleted.{AI95-00247-01AI95-00247-01}
+
+26.1/2
+{AI95-00291-02AI95-00291-02} For every subtype S:
+
+26.2/2
+S'Alignment
+ {AI95-00291-02AI95-00291-02} The value of this attribute
+ is of type universal_integer, and nonnegative.
+
+26.3/2
+ {AI95-00051-02AI95-00051-02} {AI95-00291-02AI95-00291-02}
+ For an object X of subtype S, if S'Alignment is not zero,
+ then X'Alignment is a nonzero integral multiple of
+ S'Alignment unless specified otherwise by a
+ representation item.
+
+26.4/2
+ {AI95-00291-02AI95-00291-02} Alignment may be specified
+ for first subtypes via an attribute_definition_clause
+ (*note 13.3: S0309.); the expression of such a clause
+ shall be static, and its value nonnegative.
+
+26.a/3
+ Aspect Description for Alignment (subtype): Alignment of a
+ subtype.
+
+ _Erroneous Execution_
+
+27
+Program execution is erroneous if an Address clause is given that
+conflicts with the Alignment.
+
+27.a
+ Ramification: The user has to either give an Alignment clause
+ also, or else know what Alignment the implementation will
+ choose by default.
+
+28/2
+{AI95-00051-02AI95-00051-02} {AI95-00291-02AI95-00291-02} For an object
+that is not allocated under control of the implementation, execution is
+erroneous if the object is not aligned according to its Alignment.
+
+ _Implementation Advice_
+
+28.1/3
+{AI05-0116-1AI05-0116-1} For any tagged specific subtype S,
+S'Class'Alignment should equal S'Alignment.
+
+28.a/3
+ Reason: A tagged object should never be less aligned than the
+ alignment of the type of its view, so for a class-wide type
+ T'Class, the alignment should be no greater than that of any
+ type covered by T'Class. If the implementation only supports
+ alignments that are required by the recommended level of
+ support (and this is most likely), then the alignment of any
+ covered type has to be the same or greater than that of T --
+ which leaves the only reasonable value of T'Class'Alignment
+ being T'Alignment. Thus we recommend this, but don't require
+ it so that in the unlikely case that the implementation does
+ support smaller alignments for covered types, it can select a
+ smaller value for T'Class'Alignment.
+
+28.a.1/3
+ Implementation Advice: For any tagged specific subtype S,
+ S'Class'Alignment should equal S'Alignment.
+
+29
+The recommended level of support for the Alignment attribute for
+subtypes is:
+
+30/2
+ * {AI95-00051-02AI95-00051-02} An implementation should support an
+ Alignment clause for a discrete type, fixed point type, record
+ type, or array type, specifying an Alignment value that is zero or
+ a power of two, subject to the following:
+
+31/2
+ * {AI95-00051-02AI95-00051-02} An implementation need not support an
+ Alignment clause for a signed integer type specifying an Alignment
+ greater than the largest Alignment value that is ever chosen by
+ default by the implementation for any signed integer type. A
+ corresponding limitation may be imposed for modular integer types,
+ fixed point types, enumeration types, record types, and array
+ types.
+
+32/2
+ * {AI95-00051-02AI95-00051-02} An implementation need not support a
+ nonconfirming Alignment clause which could enable the creation of
+ an object of an elementary type which cannot be easily loaded and
+ stored by available machine instructions.
+
+32.1/2
+ * {AI95-00291-02AI95-00291-02} An implementation need not support an
+ Alignment specified for a derived tagged type which is not a
+ multiple of the Alignment of the parent type. An implementation
+ need not support a nonconfirming Alignment specified for a derived
+ untagged by-reference type.
+
+32.a/2
+ Ramification: {AI95-00291-02AI95-00291-02} There is no
+ recommendation to support any nonconfirming Alignment clauses
+ for types not mentioned above. Remember that *note 13.1::
+ requires support for confirming Alignment clauses for all
+ types.
+
+32.b/3
+ Implementation Note: {AI05-0116-1AI05-0116-1} An
+ implementation that tries to support other alignments for
+ derived tagged types will need to allow inherited subprograms
+ to be passed objects that are less aligned than expected by
+ the parent subprogram and type. This is unlikely to work if
+ alignment has any effect on code selection. Similar issues
+ arise for untagged derived types whose parameters are passed
+ by reference.
+
+33
+The recommended level of support for the Alignment attribute for objects
+is:
+
+34/2
+ * This paragraph was deleted.{AI95-00291-02AI95-00291-02}
+
+35
+ * For stand-alone library-level objects of statically constrained
+ subtypes, the implementation should support all Alignments
+ supported by the target linker. For example, page alignment is
+ likely to be supported for such objects, but not for subtypes.
+
+35.1/2
+ * {AI95-00291-02AI95-00291-02} For other objects, an implementation
+ should at least support the alignments supported for their subtype,
+ subject to the following:
+
+35.2/2
+ * {AI95-00291-02AI95-00291-02} An implementation need not support
+ Alignments specified for objects of a by-reference type or for
+ objects of types containing aliased subcomponents if the specified
+ Alignment is not a multiple of the Alignment of the subtype of the
+ object.
+
+35.a/2
+ Implementation Advice: The recommended level of support for
+ the Alignment attribute should be followed.
+
+ NOTES
+
+36
+ 4 Alignment is a subtype-specific attribute.
+
+37/2
+ This paragraph was deleted.{AI95-00247-01AI95-00247-01}
+
+37.a/2
+ This paragraph was deleted.
+
+38/3
+ 5 {AI05-0229-1AI05-0229-1} {AI05-0269-1AI05-0269-1} A
+ component_clause, Component_Size clause, or specifying the Pack
+ aspect as True can override a specified Alignment.
+
+38.a
+ Discussion: Most objects are allocated by the implementation;
+ for these, the implementation obeys the Alignment. The
+ implementation is of course allowed to make an object more
+ aligned than its Alignment requires -- an object whose
+ Alignment is 4 might just happen to land at an address that's
+ a multiple of 4096. For formal parameters, the implementation
+ might want to force an Alignment stricter than the parameter's
+ subtype. For example, on some systems, it is customary to
+ always align parameters to 4 storage elements.
+
+38.b
+ Hence, one might initially assume that the implementation
+ could evilly make all Alignments 1 by default, even though
+ integers, say, are normally aligned on a 4-storage-element
+ boundary. However, the implementation cannot get away with
+ that -- if the Alignment is 1, the generated code cannot
+ assume an Alignment of 4, at least not for objects allocated
+ outside the control of the implementation.
+
+38.c
+ Of course implementations can assume anything they can prove,
+ but typically an implementation will be unable to prove much
+ about the alignment of, say, an imported object. Furthermore,
+ the information about where an address "came from" can be lost
+ to the compiler due to separate compilation.
+
+38.d/3
+ {AI95-00114-01AI95-00114-01} {AI05-0229-1AI05-0229-1} The
+ Alignment of an object that is a component of a packed
+ composite object will usually be 0, to indicate that the
+ component is not necessarily aligned on a storage element
+ boundary. For a subtype, an Alignment of 0 means that objects
+ of the subtype are not normally aligned on a storage element
+ boundary at all. For example, an implementation might choose
+ to make Component_Size be 1 for an array of Booleans, even
+ when the Pack aspect has not been specified for the array. In
+ this case, Boolean'Alignment would be 0. (In the presence of
+ tasking, this would in general be feasible only on a machine
+ that had atomic test-bit and set-bit instructions.)
+
+38.e
+ If the machine has no particular natural alignments, then all
+ subtype Alignments will probably be 1 by default.
+
+38.f
+ Specifying an Alignment of 0 in an attribute_definition_clause
+ does not require the implementation to do anything (except
+ return 0 when the Alignment is queried). However, it might be
+ taken as advice on some implementations.
+
+38.g
+ It is an error for an Address clause to disobey the object's
+ Alignment. The error cannot be detected at compile time, in
+ general, because the Address is not necessarily known at
+ compile time (and is almost certainly not static). We do not
+ require a run-time check, since efficiency seems paramount
+ here, and Address clauses are treading on thin ice anyway.
+ Hence, this misuse of Address clauses is just like any other
+ misuse of Address clauses -- it's erroneous.
+
+38.h
+ A type extension can have a stricter Alignment than its
+ parent. This can happen, for example, if the Alignment of the
+ parent is 4, but the extension contains a component with
+ Alignment 8. The Alignment of a class-wide type or object
+ will have to be the maximum possible Alignment of any
+ extension.
+
+38.i
+ The recommended level of support for the Alignment attribute
+ is intended to reflect a minimum useful set of capabilities.
+ An implementation can assume that all Alignments are multiples
+ of each other -- 1, 2, 4, and 8 might be the only supported
+ Alignments for subtypes. An Alignment of 3 or 6 is unlikely
+ to be useful. For objects that can be allocated statically,
+ we recommend that the implementation support larger
+ alignments, such as 4096. We do not recommend such large
+ alignments for subtypes, because the maximum subtype alignment
+ will also have to be used as the alignment of stack frames,
+ heap objects, and class-wide objects. Similarly, we do not
+ recommend such large alignments for stack-allocated objects.
+
+38.j
+ If the maximum default Alignment is 8 (say,
+ Long_Float'Alignment = 8), then the implementation can refuse
+ to accept stricter alignments for subtypes. This simplifies
+ the generated code, since the compiler can align the stack and
+ class-wide types to this maximum without a substantial waste
+ of space (or time).
+
+38.k
+ Note that the recommended level of support takes into account
+ interactions between Size and Alignment. For example, on a
+ 32-bit machine with 8-bit storage elements, where load and
+ store instructions have to be aligned according to the size of
+ the thing being loaded or stored, the implementation might
+ accept an Alignment of 1 if the Size is 8, but might reject an
+ Alignment of 1 if the Size is 32. On a machine where
+ unaligned loads and stores are merely inefficient (as opposed
+ to causing hardware traps), we would expect an Alignment of 1
+ to be supported for any Size.
+
+ _Wording Changes from Ada 83_
+
+38.l
+ The nonnegative part is missing from RM83 (for mod_clauses,
+ nee alignment_clauses, which are an obsolete version of
+ Alignment clauses).
+
+ _Static Semantics_
+
+39/1
+For a prefix X that denotes an object:
+
+40
+X'Size
+ Denotes the size in bits of the representation of the
+ object. The value of this attribute is of the type
+ universal_integer.
+
+40.a
+ Ramification: Note that Size is in bits even if Machine_Radix
+ is 10. Each decimal digit (and the sign) is presumably
+ represented as some number of bits.
+
+41
+ Size may be specified for [stand-alone] objects via an
+ attribute_definition_clause; the expression of such a
+ clause shall be static and its value nonnegative.
+
+41.a/3
+ Aspect Description for Size (object): Size in bits of an
+ object.
+
+ _Implementation Advice_
+
+41.1/2
+{AI95-00051-02AI95-00051-02} The size of an array object should not
+include its bounds.
+
+41.a.1/2
+ Implementation Advice: The Size of an array object should not
+ include its bounds.
+
+42/2
+{AI95-00051-02AI95-00051-02} {AI95-00291-02AI95-00291-02} The
+recommended level of support for the Size attribute of objects is the
+same as for subtypes (see below), except that only a confirming Size
+clause need be supported for an aliased elementary object.
+
+43/2
+ * This paragraph was deleted.{AI95-00051-02AI95-00051-02}
+
+ _Static Semantics_
+
+44
+For every subtype S:
+
+45
+S'Size
+ If S is definite, denotes the size [(in bits)] that the
+ implementation would choose for the following objects of
+ subtype S:
+
+46
+ * A record component of subtype S when the record type
+ is packed.
+
+47
+ * The formal parameter of an instance of
+ Unchecked_Conversion that converts from subtype S to
+ some other subtype.
+
+48
+ If S is indefinite, the meaning is implementation
+ defined. The value of this attribute is of the type
+ universal_integer. The Size of an object is at least as
+ large as that of its subtype, unless the object's Size is
+ determined by a Size clause, a component_clause, or a
+ Component_Size clause. Size may be specified for first
+ subtypes via an attribute_definition_clause (*note 13.3:
+ S0309.); the expression of such a clause shall be static
+ and its value nonnegative.
+
+48.a
+ Implementation defined: The meaning of Size for indefinite
+ subtypes.
+
+48.b
+ Reason: The effects of specifying the Size of a subtype are:
+
+48.c
+ * Unchecked_Conversion works in a predictable manner.
+
+48.d
+ * A composite type cannot be packed so tightly as to
+ override the specified Size of a component's subtype.
+
+48.e
+ * Assuming the Implementation Advice is obeyed, if the
+ specified Size allows independent addressability, then
+ the Size of certain objects of the subtype should be
+ equal to the subtype's Size. This applies to stand-alone
+ objects and to components (unless a component_clause or a
+ Component_Size clause applies).
+
+48.f/3
+ {AI05-0229-1AI05-0229-1} A component_clause or a
+ Component_Size clause can cause an object to be smaller than
+ its subtype's specified size. The aspect Pack cannot; if a
+ component subtype's size is specified, this limits how tightly
+ the composite object can be packed.
+
+48.g
+ The Size of a class-wide (tagged) subtype is unspecified,
+ because it's not clear what it should mean; it should
+ certainly not depend on all of the descendants that happen to
+ exist in a given program. Note that this cannot be detected
+ at compile time, because in a generic unit, it is not
+ necessarily known whether a given subtype is class-wide. It
+ might raise an exception on some implementations.
+
+48.h
+ Ramification: A Size clause for a numeric subtype need not
+ affect the underlying numeric type. For example, if I say:
+
+48.i
+ type S is range 1..2;
+ for S'Size use 64;
+
+
+48.j
+ I am not guaranteed that S'Base'Last >= 2**63-1, nor that
+ intermediate results will be represented in 64 bits.
+
+48.k
+ Reason: There is no need to complicate implementations for
+ this sort of thing, because the right way to affect the base
+ range of a type is to use the normal way of declaring the base
+ range:
+
+48.l
+ type Big is range -2**63 .. 2**63 - 1;
+ subtype Small is Big range 1..1000;
+
+
+48.m
+ Ramification: The Size of a large unconstrained subtype (e.g.
+ String'Size) is likely to raise Constraint_Error, since it is
+ a nonstatic expression of type universal_integer that might
+ overflow the largest signed integer type. There is no
+ requirement that the largest integer type be able to represent
+ the size in bits of the largest possible object.
+
+48.n/3
+ Aspect Description for Size (subtype): Size in bits of a
+ subtype.
+
+ _Implementation Requirements_
+
+49
+In an implementation, Boolean'Size shall be 1.
+
+ _Implementation Advice_
+
+50/2
+{AI95-00051-02AI95-00051-02} If the Size of a subtype allows for
+efficient independent addressability (see *note 9.10::) on the target
+architecture, then the Size of the following objects of the subtype
+should equal the Size of the subtype:
+
+51
+ * Aliased objects (including components).
+
+52
+ * Unaliased components, unless the Size of the component is
+ determined by a component_clause or Component_Size clause.
+
+52.a.1/2
+ Implementation Advice: If the Size of a subtype allows for
+ efficient independent addressability, then the Size of most
+ objects of the subtype should equal the Size of the subtype.
+
+52.a
+ Ramification: Thus, on a typical 32-bit machine, "for S'Size
+ use 32;" will guarantee that aliased objects of subtype S, and
+ components whose subtype is S, will have Size = 32 (assuming
+ the implementation chooses to obey this Implementation
+ Advice). On the other hand, if one writes, "for S2'Size use
+ 5;" then stand-alone objects of subtype S2 will typically have
+ their Size rounded up to ensure independent addressability.
+
+52.b
+ Note that "for S'Size use 32;" does not cause things like
+ formal parameters to have Size = 32 -- the implementation is
+ allowed to make all parameters be at least 64 bits, for
+ example.
+
+52.c
+ Note that "for S2'Size use 5;" requires record components
+ whose subtype is S2 to be exactly 5 bits if the record type is
+ packed. The same is not true of array components; their Size
+ may be rounded up to the nearest factor of the word size.
+
+52.d/2
+ Implementation Note: {AI95-00291-02AI95-00291-02} On most
+ machines, arrays don't contain gaps between elementary
+ components; if the Component_Size is greater than the Size of
+ the component subtype, the extra bits are generally considered
+ part of each component, rather than gaps between components.
+ On the other hand, a record might contain gaps between
+ elementary components, depending on what sorts of loads,
+ stores, and masking operations are generally done by the
+ generated code.
+
+52.e/2
+ {AI95-00291-02AI95-00291-02} For an array, any extra bits
+ stored for each elementary component will generally be part of
+ the component -- the whole point of storing extra bits is to
+ make loads and stores more efficient by avoiding the need to
+ mask out extra bits. The PDP-10 is one counter-example; since
+ the hardware supports byte strings with a gap at the end of
+ each word, one would want to pack in that manner.
+
+53
+A Size clause on a composite subtype should not affect the internal
+layout of components.
+
+53.a.1/2
+ Implementation Advice: A Size clause on a composite subtype
+ should not affect the internal layout of components.
+
+53.a/3
+ Reason: {AI05-0229-1AI05-0229-1} That's what Pack aspects,
+ record_representation_clauses, and Component_Size clauses are
+ for.
+
+54
+The recommended level of support for the Size attribute of subtypes is:
+
+55
+ * The Size (if not specified) of a static discrete or fixed point
+ subtype should be the number of bits needed to represent each value
+ belonging to the subtype using an unbiased representation, leaving
+ space for a sign bit only if the subtype contains negative values.
+ If such a subtype is a first subtype, then an implementation should
+ support a specified Size for it that reflects this representation.
+
+55.a
+ Implementation Note: This applies to static enumeration
+ subtypes, using the internal codes used to represent the
+ values.
+
+55.b
+ For a two's-complement machine, this implies that for a static
+ signed integer subtype S, if all values of S are in the range
+ 0 .. 2n-1, or all values of S are in the range -2n-1 ..
+ 2n-1-1, for some n less than or equal to the word size, then
+ S'Size should be <= the smallest such n. For a
+ one's-complement machine, it is the same except that in the
+ second range, the lower bound "-2n-1" is replaced by
+ "-2n-1+1".
+
+55.c
+ If an integer subtype (whether signed or unsigned) contains no
+ negative values, the Size should not include space for a sign
+ bit.
+
+55.d
+ Typically, the implementation will choose to make the Size of
+ a subtype be exactly the smallest such n. However, it might,
+ for example, choose a biased representation, in which case it
+ could choose a smaller value.
+
+55.e/3
+ {AI05-0229-1AI05-0229-1} On most machines, it is in general
+ not a good idea to pack (parts of) multiple stand-alone
+ objects into the same storage element, because (1) it usually
+ doesn't save much space, and (2) it requires locking to
+ prevent tasks from interfering with each other, since separate
+ stand-alone objects are independently addressable. Therefore,
+ if S'Size = 2 on a machine with 8-bit storage elements, the
+ size of a stand-alone object of subtype S will probably not be
+ 2. It might, for example, be 8, 16 or 32, depending on the
+ availability and efficiency of various machine instructions.
+ The same applies to components of composite types, unless
+ Pack, Component_Size, or record layout is specified.
+
+55.f
+ For an unconstrained discriminated object, if the
+ implementation allocates the maximum possible size, then the
+ Size attribute should return that maximum possible size.
+
+55.g
+ Ramification: The Size of an object X is not usually the same
+ as that of its subtype S. If X is a stand-alone object or a
+ parameter, for example, most implementations will round X'Size
+ up to a storage element boundary, or more, so X'Size might be
+ greater than S'Size. On the other hand, X'Size cannot be less
+ than S'Size, even if the implementation can prove, for
+ example, that the range of values actually taken on by X
+ during execution is smaller than the range of S.
+
+55.h
+ For example, if S is a first integer subtype whose range is
+ 0..3, S'Size will be probably be 2 bits, and components of
+ packed composite types of this subtype will be 2 bits
+ (assuming Storage_Unit is a multiple of 2), but stand-alone
+ objects and parameters will probably not have a size of 2
+ bits; they might be rounded up to 32 bits, for example. On
+ the other hand, Unchecked_Conversion will use the 2-bit size,
+ even when converting a stand-alone object, as one would
+ expect.
+
+55.i
+ Another reason for making the Size of an object bigger than
+ its subtype's Size is to support the run-time detection of
+ uninitialized variables. The implementation might add an
+ extra value to a discrete subtype that represents the
+ uninitialized state, and check for this value on use. In some
+ cases, the extra value will require an extra bit in the
+ representation of the object. Such detection is not required
+ by the language. If it is provided, the implementation has to
+ be able to turn it off. For example, if the programmer gives
+ a record_representation_clause or Component_Size clause that
+ makes a component too small to allow the extra bit, then the
+ implementation will not be able to perform the checking (not
+ using this method, anyway).
+
+55.j
+ The fact that the size of an object is not necessarily the
+ same as its subtype can be confusing:
+
+55.k
+ type Device_Register is range 0..2**8 - 1;
+ for Device_Register'Size use 8; -- Confusing!
+ My_Device : Device_Register;
+ for My_Device'Address use To_Address(16#FF00#);
+
+
+55.l
+ The programmer might think that My_Device'Size is 8, and that
+ My_Device'Address points at an 8-bit location. However, this
+ is not true. In Ada 83 (and in Ada 95), My_Device'Size might
+ well be 32, and My_Device'Address might well point at the
+ high-order 8 bits of the 32-bit object, which are always all
+ zero bits. If My_Device'Address is passed to an assembly
+ language subprogram, based on the programmer's assumption, the
+ program will not work properly.
+
+55.m
+ Reason: It is not reasonable to require that an implementation
+ allocate exactly 8 bits to all objects of subtype
+ Device_Register. For example, in many run-time models,
+ stand-alone objects and parameters are always aligned to a
+ word boundary. Such run-time models are generally based on
+ hardware considerations that are beyond the control of the
+ implementer. (It is reasonable to require that an
+ implementation allocate exactly 8 bits to all components of
+ subtype Device_Register, if packed.)
+
+55.n
+ Ramification: The correct way to write the above code is like
+ this:
+
+55.o
+ type Device_Register is range 0..2**8 - 1;
+ My_Device : Device_Register;
+ for My_Device'Size use 8;
+ for My_Device'Address use To_Address(16#FF00#);
+
+
+55.p
+ If the implementation cannot accept 8-bit stand-alone objects,
+ then this will be illegal. However, on a machine where an
+ 8-bit device register exists, the implementation will probably
+ be able to accept 8-bit stand-alone objects. Therefore,
+ My_Device'Size will be 8, and My_Device'Address will point at
+ those 8 bits, as desired.
+
+55.q
+ If an object of subtype Device_Register is passed to a foreign
+ language subprogram, it will be passed according to that
+ subprogram's conventions. Most foreign language
+ implementations have similar run-time model restrictions. For
+ example, when passing to a C function, where the argument is
+ of the C type char* (that is, pointer to char), the C compiler
+ will generally expect a full word value, either on the stack,
+ or in a register. It will not expect a single byte. Thus,
+ Size clauses for subtypes really have nothing to do with
+ passing parameters to foreign language subprograms.
+
+56
+ * For a subtype implemented with levels of indirection, the Size
+ should include the size of the pointers, but not the size of what
+ they point at.
+
+56.a
+ Ramification: For example, if a task object is represented as
+ a pointer to some information (including a task stack), then
+ the size of the object should be the size of the pointer. The
+ Storage_Size, on the other hand, should include the size of
+ the stack.
+
+56.1/2
+ * {AI95-00051-02AI95-00051-02} An implementation should support a
+ Size clause for a discrete type, fixed point type, record type, or
+ array type, subject to the following:
+
+56.2/2
+ * {AI95-00051-02AI95-00051-02} An implementation need not
+ support a Size clause for a signed integer type
+ specifying a Size greater than that of the largest signed
+ integer type supported by the implementation in the
+ absence of a size clause (that is, when the size is
+ chosen by default). A corresponding limitation may be
+ imposed for modular integer types, fixed point types,
+ enumeration types, record types, and array types.
+
+56.b/2
+ Discussion: {AI95-00051-02AI95-00051-02} Note that the
+ "corresponding limitation" for a record or array type implies
+ that an implementation may impose some reasonable maximum size
+ for records and arrays (e.g. 2**32 bits), which is an upper
+ bound ("capacity" limit) on the size, whether chosen by
+ default or by being specified by the user. The largest size
+ supported for records need not be the same as the largest size
+ supported for arrays.
+
+56.b.1/3
+ Ramification: {AI05-0155-1AI05-0155-1} Only Size clauses with
+ a size greater than or equal to the Size that would be chosen
+ by default may be safely presumed to be supported on nonstatic
+ elementary subtypes. Implementations may choose to support
+ smaller sizes, but only if the Size allows any value of the
+ subtype to be represented, for any possible value of the
+ bounds.
+
+56.3/2
+ * {AI95-00291-02AI95-00291-02} A nonconfirming size clause
+ for the first subtype of a derived untagged by-reference
+ type need not be supported.
+
+56.c/2
+ Implementation Advice: The recommended level of support for
+ the Size attribute should be followed.
+
+56.d/2
+ Ramification: {AI95-00291-02AI95-00291-02} There is no
+ recommendation to support any nonconfirming Size clauses for
+ types not mentioned above. Remember that *note 13.1::
+ requires support for confirming Size clauses for all types.
+
+ NOTES
+
+57
+ 6 Size is a subtype-specific attribute.
+
+58/3
+ 7 {AI05-0229-1AI05-0229-1} A component_clause or Component_Size
+ clause can override a specified Size. Aspect Pack cannot.
+
+ _Inconsistencies With Ada 83_
+
+58.a.1/2
+ {AI95-00114-01AI95-00114-01} We specify the meaning of Size in
+ much more detail than Ada 83. This is not technically an
+ inconsistency, but it is in practice, as most Ada 83 compilers
+ use a different definition for Size than is required here.
+ This should have been documented more explicitly during the
+ Ada 9X process.
+
+ _Wording Changes from Ada 83_
+
+58.a
+ The requirement for a nonnegative value in a Size clause was
+ not in RM83, but it's hard to see how it would make sense.
+ For uniformity, we forbid negative sizes, rather than letting
+ implementations define their meaning.
+
+ _Static Semantics_
+
+59/1
+For a prefix T that denotes a task object [(after any implicit
+dereference)]:
+
+60/3
+T'Storage_Size
+ {AI05-0229-1AI05-0229-1} Denotes the number of storage
+ elements reserved for the task. The value of this
+ attribute is of the type universal_integer. The
+ Storage_Size includes the size of the task's stack, if
+ any. The language does not specify whether or not it
+ includes other storage associated with the task (such as
+ the "task control block" used by some implementations.)
+ If the aspect Storage_Size is specified for the type of
+ the object, the value of the Storage_Size attribute is at
+ least the value determined by the aspect.
+
+60.a
+ Ramification: The value of this attribute is never negative,
+ since it is impossible to "reserve" a negative number of
+ storage elements.
+
+60.b
+ If the implementation chooses to allocate an initial amount of
+ storage, and then increase this as needed, the Storage_Size
+ cannot include the additional amounts (assuming the allocation
+ of the additional amounts can raise Storage_Error); this is
+ inherent in the meaning of "reserved."
+
+60.c
+ The implementation is allowed to allocate different amounts of
+ storage for different tasks of the same subtype.
+
+60.d
+ Storage_Size is also defined for access subtypes -- see *note
+ 13.11::.
+
+61/3
+{AI95-0229-1AI95-0229-1} [Aspect Storage_Size specifies the amount of
+storage to be reserved for the execution of a task.]
+
+Paragraphs 62 through 65 were moved to *note Annex J::, "*note Annex J::
+Obsolescent Features".
+
+ _Static Semantics_
+
+65.1/3
+{AI05-0229-1AI05-0229-1} {AI05-0269-1AI05-0269-1} For a task type
+(including the anonymous type of a single_task_declaration), the
+following language-defined representation aspect may be specified:
+
+65.2/3
+Storage_Size
+ The Storage_Size aspect is an expression, which shall be
+ of any integer type.
+
+65.a/3
+ To be honest: This definition somewhat conflicts with the
+ "automatic" one for the obsolescent attribute Storage_Size
+ (which can be specified). The only difference is where the
+ given expression is evaluated. We intend for the above
+ definition to supersede that "automatic" definition for this
+ attribute.
+
+65.b/3
+ Ramification: Note that the value of the Storage_Size aspect
+ is an expression; it is not the value of an expression. The
+ expression is evaluated for each object of the type (see
+ below).
+
+65.c/3
+ Aspect Description for Storage_Size (task): Size in storage
+ elements reserved for a task type or single task object.
+
+ _Legality Rules_
+
+65.3/3
+{AI05-0229-1AI05-0229-1} The Storage_Size aspect shall not be specified
+for a task interface type.
+
+ _Dynamic Semantics_
+
+66/3
+{AI05-0229-1AI05-0229-1} When a task object is created, the expression
+(if any) associated with the Storage_Size aspect of its type is
+evaluated; the Storage_Size attribute of the newly created task object
+is at least the value of the expression.
+
+66.a
+ Ramification: The implementation is allowed to round up a
+ specified Storage_Size amount. For example, if the
+ implementation always allocates in chunks of 4096 bytes, the
+ number 200 might be rounded up to 4096. Also, if the user
+ specifies a negative number, the implementation has to
+ normalize this to 0, or perhaps to a positive number.
+
+66.b/3
+ {AI05-0229-1AI05-0229-1} If the Storage_Size aspect is not
+ specified for the type of the task object, the value of the
+ Storage_Size attribute is unspecified.
+
+67
+At the point of task object creation, or upon task activation,
+Storage_Error is raised if there is insufficient free storage to
+accommodate the requested Storage_Size.
+
+ _Static Semantics_
+
+68/1
+For a prefix X that denotes an array subtype or array object [(after any
+implicit dereference)]:
+
+69
+X'Component_Size
+ Denotes the size in bits of components of the type of X.
+ The value of this attribute is of type universal_integer.
+
+70
+ Component_Size may be specified for array types via an
+ attribute_definition_clause (*note 13.3: S0309.); the
+ expression of such a clause shall be static, and its
+ value nonnegative.
+
+70.a
+ Implementation Note: The intent is that the value of
+ X'Component_Size is always nonnegative. If the array is
+ stored "backwards" in memory (which might be caused by an
+ implementation-defined pragma), X'Component_Size is still
+ positive.
+
+70.b
+ Ramification: For an array object A, A'Component_Size =
+ A(I)'Size for any index I.
+
+70.c/3
+ Aspect Description for Component_Size: Size in bits of a
+ component of an array type.
+
+ _Implementation Advice_
+
+71
+The recommended level of support for the Component_Size attribute is:
+
+72
+ * An implementation need not support specified Component_Sizes that
+ are less than the Size of the component subtype.
+
+73/3
+ * {AI05-0229-1AI05-0229-1} An implementation should support specified
+ Component_Sizes that are factors and multiples of the word size.
+ For such Component_Sizes, the array should contain no gaps between
+ components. For other Component_Sizes (if supported), the array
+ should contain no gaps between components when Pack is also
+ specified; the implementation should forbid this combination in
+ cases where it cannot support a no-gaps representation.
+
+73.a/3
+ Ramification: {AI05-0229-1AI05-0229-1} For example, if
+ Storage_Unit = 8, and Word_Size = 32, then the user is allowed
+ to specify a Component_Size of 1, 2, 4, 8, 16, and 32, with no
+ gaps. In addition, n*32 is allowed for positive integers n,
+ again with no gaps. If the implementation accepts
+ Component_Size = 3, then it might allocate 10 components per
+ word, with a 2-bit gap at the end of each word (unless Pack is
+ also specified), or it might not have any internal gaps at
+ all. (There can be gaps at either end of the array.)
+
+73.b/2
+ Implementation Advice: The recommended level of support for
+ the Component_Size attribute should be followed.
+
+ _Static Semantics_
+
+73.1/3
+{AI05-0191-1AI05-0191-1} For a prefix X that denotes an object:
+
+73.2/3
+X'Has_Same_Storage
+ {AI05-0191-1AI05-0191-1} X'Has_Same_Storage denotes a
+ function with the following specification:
+
+73.3/3
+ function X'Has_Same_Storage (Arg : any_type)
+ return Boolean
+
+73.4/3
+ {AI05-0191-1AI05-0191-1} {AI05-0264-1AI05-0264-1} The
+ actual parameter shall be a name that denotes an object.
+ The object denoted by the actual parameter can be of any
+ type. This function evaluates the names of the objects
+ involved and returns True if the representation of the
+ object denoted by the actual parameter occupies exactly
+ the same bits as the representation of the object denoted
+ by X; otherwise, it returns False.
+
+73.c/3
+ Discussion: Has_Same_Storage means that, if the representation
+ is contiguous, the objects sit at the same address and occupy
+ the same length of memory.
+
+73.5/3
+{AI05-0191-1AI05-0191-1} For a prefix X that denotes an object:
+
+73.6/3
+X'Overlaps_Storage
+ {AI05-0191-1AI05-0191-1} X'Overlaps_Storage denotes a
+ function with the following specification:
+
+73.7/3
+ function X'Overlaps_Storage (Arg : any_type)
+ return Boolean
+
+73.8/3
+ {AI05-0191-1AI05-0191-1} {AI05-0264-1AI05-0264-1} The
+ actual parameter shall be a name that denotes an object.
+ The object denoted by the actual parameter can be of any
+ type. This function evaluates the names of the objects
+ involved and returns True if the representation of the
+ object denoted by the actual parameter shares at least
+ one bit with the representation of the object denoted by
+ X; otherwise, it returns False.
+
+ NOTES
+
+73.9/3
+ 8 {AI05-0191-1AI05-0191-1} X'Has_Same_Storage(Y) implies
+ X'Overlaps_Storage(Y).
+
+73.10/3
+ 9 {AI05-0191-1AI05-0191-1} X'Has_Same_Storage(Y) and
+ X'Overlaps_Storage(Y) are not considered to be reads of X and Y.
+
+ _Static Semantics_
+
+73.11/3
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+{AI05-0183-1AI05-0183-1} The following type-related operational
+attribute is defined: External_Tag.
+
+74/1
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01} For every subtype S of
+a tagged type T (specific or class-wide):
+
+75/3
+S'External_Tag
+ {8652/00408652/0040} {AI95-00108-01AI95-00108-01}
+ {AI05-0092-1AI05-0092-1} S'External_Tag denotes an
+ external string representation for S'Tag; it is of the
+ predefined type String. External_Tag may be specified
+ for a specific tagged type via an
+ attribute_definition_clause; the expression of such a
+ clause shall be static. The default external tag
+ representation is implementation defined. See *note
+ 13.13.2::. The value of External_Tag is never
+ inherited[; the default value is always used unless a new
+ value is directly specified for a type].
+
+75.a
+ Implementation defined: The default external representation
+ for a type tag.
+
+75.b/3
+ Aspect Description for External_Tag: Unique identifier for a
+ tagged type in streams.
+
+ _Dynamic Semantics_
+
+75.1/3
+{AI05-0113-1AI05-0113-1} If a user-specified external tag S'External_Tag
+is the same as T'External_Tag for some other tagged type declared by a
+different declaration in the partition, Program_Error is raised by the
+elaboration of the attribute_definition_clause.
+
+75.c/3
+ Ramification: This rule does not depend on the visibility of
+ the other tagged type, but it does depend on the existence of
+ the other tagged type. The other tagged type could have the
+ default external tag or a user-specified external tag.
+
+75.d/3
+ This rule allows the same declaration to be elaborated
+ multiple times. In that case, different types could have the
+ same external tag. If that happens, Internal_Tag would return
+ some unspecified tag, and Descendant_Tag probably would return
+ the intended tag (using the given ancestor to determine which
+ type is intended). However, in some cases (such as multiple
+ instantiations of a derived tagged type declared in a generic
+ body), Tag_Error might be raised by Descendant_Tag if multiple
+ types are identified.
+
+75.e/3
+ Note that while there is a race condition inherent in this
+ definition (which attribute_definition_clause raises
+ Program_Error depends on the order of elaboration), it doesn't
+ matter as a program with two such clauses is simply wrong.
+ Two types that both come from the same declaration are
+ allowed, as noted previously.
+
+ _Implementation Requirements_
+
+76
+In an implementation, the default external tag for each specific tagged
+type declared in a partition shall be distinct, so long as the type is
+declared outside an instance of a generic body. If the compilation unit
+in which a given tagged type is declared, and all compilation units on
+which it semantically depends, are the same in two different partitions,
+then the external tag for the type shall be the same in the two
+partitions. What it means for a compilation unit to be the same in two
+different partitions is implementation defined. At a minimum, if the
+compilation unit is not recompiled between building the two different
+partitions that include it, the compilation unit is considered the same
+in the two partitions.
+
+76.a
+ Implementation defined: What determines whether a compilation
+ unit is the same in two different partitions.
+
+76.b
+ Reason: These requirements are important because external tags
+ are used for input/output of class-wide types. These
+ requirements ensure that what is written by one program can be
+ read back by some other program so long as they share the same
+ declaration for the type (and everything it depends on).
+
+76.c
+ The user may specify the external tag if (s)he wishes its
+ value to be stable even across changes to the compilation unit
+ in which the type is declared (or changes in some unit on
+ which it depends).
+
+76.d/2
+ {AI95-00114-01AI95-00114-01} We use a String rather than a
+ Stream_Element_Array to represent an external tag for
+ portability.
+
+76.e
+ Ramification: Note that the characters of an external tag need
+ not all be graphic characters. In other words, the external
+ tag can be a sequence of arbitrary 8-bit bytes.
+
+ _Implementation Permissions_
+
+76.1/3
+{AI05-0113-1AI05-0113-1} If a user-specified external tag S'External_Tag
+is the same as T'External_Tag for some other tagged type declared by a
+different declaration in the partition, the partition may be rejected.
+
+76.f/3
+ Ramification: This is, in general, a post-compilation check.
+ This permission is intended for implementations that do
+ link-time construction of the external tag lookup table;
+ implementations that dynamically construct the table will
+ likely prefer to raise Program_Error upon elaboration of the
+ problem construct. We don't want this check to require any
+ implementation complexity, as it will be very rare that there
+ would be a problem.
+
+ NOTES
+
+77/2
+ 10 {AI95-00270-01AI95-00270-01} The following language-defined
+ attributes are specifiable, at least for some of the kinds of
+ entities to which they apply: Address, Alignment, Bit_Order,
+ Component_Size, External_Tag, Input, Machine_Radix, Output, Read,
+ Size, Small, Storage_Pool, Storage_Size, Stream_Size, and Write.
+
+78
+ 11 It follows from the general rules in *note 13.1:: that if one
+ writes "for X'Size use Y;" then the X'Size attribute_reference will
+ return Y (assuming the implementation allows the Size clause). The
+ same is true for all of the specifiable attributes except
+ Storage_Size.
+
+78.a
+ Ramification: An implementation may specify that an
+ implementation-defined attribute is specifiable for certain
+ entities. This follows from the fact that the semantics of
+ implementation-defined attributes is implementation defined.
+ An implementation is not allowed to make a language-defined
+ attribute specifiable if it isn't.
+
+ _Examples_
+
+79
+Examples of attribute definition clauses:
+
+80
+ Byte : constant := 8;
+ Page : constant := 2**12;
+
+81
+ type Medium is range 0 .. 65_000;
+ for Medium'Size use 2*Byte;
+ for Medium'Alignment use 2;
+ Device_Register : Medium;
+ for Device_Register'Size use Medium'Size;
+ for Device_Register'Address use System.Storage_Elements.To_Address(16#FFFF_0020#);
+
+82
+ type Short is delta 0.01 range -100.0 .. 100.0;
+ for Short'Size use 15;
+
+83
+ for Car_Name'Storage_Size use -- specify access type's storage pool size
+ 2000*((Car'Size/System.Storage_Unit) +1); -- approximately 2000 cars
+
+84/2
+ {AI95-00441-01AI95-00441-01} function My_Input(Stream : not null access Ada.Streams.Root_Stream_Type'Class)
+ return T;
+ for T'Input use My_Input; -- see *note 13.13.2::
+
+ NOTES
+
+85
+ 12 Notes on the examples: In the Size clause for Short, fifteen
+ bits is the minimum necessary, since the type definition requires
+ Short'Small <= 2**(-7).
+
+ _Extensions to Ada 83_
+
+85.a
+ The syntax rule for length_clause is replaced with the new
+ syntax rule for attribute_definition_clause, and it is
+ modified to allow a name (as well as an expression).
+
+ _Wording Changes from Ada 83_
+
+85.b
+ The syntax rule for attribute_definition_clause now requires
+ that the prefix of the attribute be a local_name; in Ada 83
+ this rule was stated in the text.
+
+85.c/2
+ {AI95-00114-01AI95-00114-01} In Ada 83, the relationship
+ between a aspect_clause specifying a certain aspect and an
+ attribute that queried that aspect was unclear. In Ada 95,
+ they are the same, except for certain explicit exceptions.
+
+ _Wording Changes from Ada 95_
+
+85.d/2
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} Corrigendum:
+ Added wording to specify for each attribute whether it is an
+ operational or representation attribute.
+
+85.e/2
+ {8652/00408652/0040} {AI95-00108-01AI95-00108-01} Corrigendum:
+ Added wording to specify that External_Tag is never inherited.
+
+85.f/2
+ {AI95-00051-01AI95-00051-01} {AI95-00291-01AI95-00291-01}
+ Adjusted the Recommended Level of Support for Alignment to
+ eliminate nonsense requirements and to ensure that useful
+ capabilities are required.
+
+85.g/2
+ {AI95-00051-01AI95-00051-01} {AI95-00291-01AI95-00291-01}
+ Adjusted the Recommended Level of Support for Size to
+ eliminate nonsense requirements and to ensure that useful
+ capabilities are required. Also eliminated any dependence on
+ whether an aspect was specified (a confirming representation
+ item should not affect the semantics).
+
+85.h/2
+ {AI95-00133-01AI95-00133-01} Added the definition of machine
+ scalar.
+
+85.i/2
+ {AI95-00247-01AI95-00247-01} Removed the requirement that
+ specified alignments for a composite type cannot override
+ those for their components, because it was never intended to
+ apply to components whose location was specified with a
+ representation item. Moreover, it causes a difference in
+ legality when a confirming alignment is specified for one of
+ the composite types.
+
+85.j/2
+ {AI95-00291-02AI95-00291-02} Removed recommended level of
+ support rules about types with by-reference and aliased parts,
+ because there are now blanket rules covering all recommended
+ level of support rules.
+
+85.k/2
+ {AI95-00291-02AI95-00291-02} Split the definition of Alignment
+ for subtypes and for objects. This simplified the wording and
+ eliminated confusion about which rules applied to objects,
+ which applied to subtypes, and which applied to both.
+
+ _Inconsistencies With Ada 2005_
+
+85.l/3
+ {AI95-0095-1AI95-0095-1} Correction: An address attribute with
+ a prefix of a generic formal subprogram whose actual parameter
+ has convention Intrinsic now raises Program_Error. Since it
+ is unlikely that such an attribute would have done anything
+ useful (a subprogram with convention Intrinsic is not expected
+ to have a normal subprogram body), it is highly unlikely that
+ any existing programs would notice the difference, and any
+ that do probably are buggy.
+
+85.m/3
+ {AI95-0113-1AI95-0113-1} Correction: User-specified external
+ tags that conflict with other external tags raise
+ Program_Error (or are optionally illegal). This was legal and
+ did not raise an exception in the past, although the effects
+ were not defined. So while a program might depend on such
+ behavior, the results were not portable (even to different
+ versions of the same implementation). Such programs should be
+ rare.
+
+ _Incompatibilities With Ada 2005_
+
+85.n/3
+ {AI05-0095-1AI05-0095-1} Correction: An address attribute with
+ a prefix of a subprogram with convention Intrinsic is now
+ illegal. Such attributes are very unlikely to have provided a
+ useful answer (the intended meaning of convention Intrinsic is
+ that there is no actual subprogram body for the operation), so
+ this is highly unlikely to affect any existing programs unless
+ they have a hidden bug.
+
+ _Extensions to Ada 2005_
+
+85.o/3
+ {AI05-0191-1AI05-0191-1} Attributes Has_Same_Storage and
+ Overlaps_Storage are new.
+
+85.p/3
+ {AI05-0229-1AI05-0229-1} Aspect Storage_Size is new; pragma
+ Storage_Size is now obsolescent, joining attribute
+ Storage_Size for task types.
+
+ _Wording Changes from Ada 2005_
+
+85.q/3
+ {AI05-0009-1AI05-0009-1} Correction: Improved the description
+ of erroneous execution for address clauses to make it clear
+ that specifying an address inappropriate for the entity will
+ lead to erroneous execution.
+
+85.r/3
+ {AI05-0116-1AI05-0116-1} Correction: Added Implementation
+ Advice for the alignment of class-wide types.
+
+\1f
+File: aarm2012.info, Node: 13.4, Next: 13.5, Prev: 13.3, Up: 13
+
+13.4 Enumeration Representation Clauses
+=======================================
+
+1
+[An enumeration_representation_clause specifies the internal codes for
+enumeration literals.]
+
+ _Syntax_
+
+2
+ enumeration_representation_clause ::=
+ for first_subtype_local_name use enumeration_aggregate;
+
+3
+ enumeration_aggregate ::= array_aggregate
+
+ _Name Resolution Rules_
+
+4
+The enumeration_aggregate shall be written as a one-dimensional
+array_aggregate, for which the index subtype is the unconstrained
+subtype of the enumeration type, and each component expression is
+expected to be of any integer type.
+
+4.a
+ Ramification: The "full coverage rules" for aggregates
+ applies. An others is not allowed -- there is no applicable
+ index constraint in this context.
+
+ _Legality Rules_
+
+5
+The first_subtype_local_name of an enumeration_representation_clause
+shall denote an enumeration subtype.
+
+5.a
+ Ramification: As for all type-related representation items,
+ the local_name is required to denote a first subtype.
+
+6/2
+{AI95-00287-01AI95-00287-01} Each component of the array_aggregate shall
+be given by an expression rather than a <>. The expressions given in
+the array_aggregate shall be static, and shall specify distinct integer
+codes for each value of the enumeration type; the associated integer
+codes shall satisfy the predefined ordering relation of the type.
+
+6.a
+ Reason: Each value of the enumeration type has to be given an
+ internal code, even if the first subtype of the enumeration
+ type is constrained to only a subrange (this is only possible
+ if the enumeration type is a derived type). This "full
+ coverage" requirement is important because one may refer to
+ Enum'Base'First and Enum'Base'Last, which need to have defined
+ representations.
+
+ _Static Semantics_
+
+7
+An enumeration_representation_clause specifies the coding aspect of
+representation. The coding consists of the internal code for each
+enumeration literal, that is, the integral value used internally to
+represent each literal.
+
+7.a/3
+ Aspect Description for Coding: Internal representation of
+ enumeration literals. Specified by an
+ enumeration_representation_clause, not by an
+ aspect_specification.
+
+ _Implementation Requirements_
+
+8
+For nonboolean enumeration types, if the coding is not specified for the
+type, then for each value of the type, the internal code shall be equal
+to its position number.
+
+8.a
+ Reason: This default representation is already used by all
+ known Ada compilers for nonboolean enumeration types.
+ Therefore, we make it a requirement so users can depend on it,
+ rather than feeling obliged to supply for every enumeration
+ type an enumeration representation clause that is equivalent
+ to this default rule.
+
+8.b
+ Discussion: For boolean types, it is relatively common to use
+ all ones for True, and all zeros for False, since some
+ hardware supports that directly. Of course, for a one-bit
+ Boolean object (like in a packed array), False is presumably
+ zero and True is presumably one (choosing the reverse would be
+ extremely unfriendly!).
+
+ _Implementation Advice_
+
+9
+The recommended level of support for enumeration_representation_clauses
+is:
+
+10
+ * An implementation should support at least the internal codes in the
+ range System.Min_Int..System.Max_Int. An implementation need not
+ support enumeration_representation_clause (*note 13.4: S0310.)s for
+ boolean types.
+
+10.a
+ Ramification: The implementation may support numbers outside
+ the above range, such as numbers greater than System.Max_Int.
+ See AI83-00564.
+
+10.b
+ Reason: The benefits of specifying the internal coding of a
+ boolean type do not outweigh the implementation costs.
+ Consider, for example, the implementation of the logical
+ operators on a packed array of booleans with strange internal
+ codes. It's implementable, but not worth it.
+
+10.c/2
+ Implementation Advice: The recommended level of support for
+ enumeration_representation_clauses should be followed.
+
+ NOTES
+
+11/3
+ 13 {8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+ {AI05-0299-1AI05-0299-1} Unchecked_Conversion may be used to query
+ the internal codes used for an enumeration type. The attributes of
+ the type, such as Succ, Pred, and Pos, are unaffected by the
+ enumeration_representation_clause. For example, Pos always returns
+ the position number, not the internal integer code that might have
+ been specified in an enumeration_representation_clause.
+
+11.a
+ Discussion: Suppose the enumeration type in question is
+ derived:
+
+11.b
+ type T1 is (Red, Green, Blue);
+ subtype S1 is T1 range Red .. Green;
+ type S2 is new S1;
+ for S2 use (Red => 10, Green => 20, Blue => 30);
+
+11.c/1
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} The
+ enumeration_representation_clause has to specify values for
+ all enumerals, even ones that are not in S2 (such as Blue).
+ The Base attribute can be used to get at these values. For
+ example:
+
+11.d
+ for I in S2'Base loop
+ ... -- When I equals Blue, the internal code is 30.
+ end loop;
+
+11.e
+ We considered allowing or requiring "for S2'Base use ..." in
+ cases like this, but it didn't seem worth the trouble.
+
+ _Examples_
+
+12
+Example of an enumeration representation clause:
+
+13
+ type Mix_Code is (ADD, SUB, MUL, LDA, STA, STZ);
+
+14
+ for Mix_Code use
+ (ADD => 1, SUB => 2, MUL => 3, LDA => 8, STA => 24, STZ =>33);
+
+ _Extensions to Ada 83_
+
+14.a
+ As in other similar contexts, Ada 95 allows expressions of any
+ integer type, not just expressions of type universal_integer,
+ for the component expressions in the enumeration_aggregate.
+ The preference rules for the predefined operators of
+ root_integer eliminate any ambiguity.
+
+14.b
+ For portability, we now require that the default coding for an
+ enumeration type be the "obvious" coding using position
+ numbers. This is satisfied by all known implementations.
+
+ _Wording Changes from Ada 95_
+
+14.c/2
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} Corrigendum:
+ Updated to reflect that we no longer have something called
+ representation_clause.
+
+14.d/2
+ {AI95-00287-01AI95-00287-01} Added wording to prevent the use
+ of <> in a enumeration_representation_clause. (<> is newly
+ added to array_aggregates.)
+
+\1f
+File: aarm2012.info, Node: 13.5, Next: 13.6, Prev: 13.4, Up: 13
+
+13.5 Record Layout
+==================
+
+1
+The (record) layout aspect of representation consists of the storage
+places for some or all components, that is, storage place attributes of
+the components. The layout can be specified with a
+record_representation_clause (*note 13.5.1: S0312.).
+
+* Menu:
+
+* 13.5.1 :: Record Representation Clauses
+* 13.5.2 :: Storage Place Attributes
+* 13.5.3 :: Bit Ordering
+
+\1f
+File: aarm2012.info, Node: 13.5.1, Next: 13.5.2, Up: 13.5
+
+13.5.1 Record Representation Clauses
+------------------------------------
+
+1
+[A record_representation_clause specifies the storage representation of
+records and record extensions, that is, the order, position, and size of
+components (including discriminants, if any). ]
+
+ _Language Design Principles_
+
+1.a/2
+ {AI95-00114-01AI95-00114-01} It should be feasible for an
+ implementation to use negative offsets in the representation
+ of composite types. However, no implementation should be
+ forced to support negative offsets. Therefore, in the
+ interest of uniformity, negative offsets should be disallowed
+ in record_representation_clauses.
+
+ _Syntax_
+
+2
+ record_representation_clause ::=
+ for first_subtype_local_name use
+ record [mod_clause]
+ {component_clause}
+ end record;
+
+3
+ component_clause ::=
+ component_local_name at position range first_bit .. last_bit;
+
+4
+ position ::= static_expression
+
+5
+ first_bit ::= static_simple_expression
+
+6
+ last_bit ::= static_simple_expression
+
+6.a
+ Reason: First_bit and last_bit need to be simple_expression
+ instead of expression for the same reason as in range (see
+ *note 3.5::, "*note 3.5:: Scalar Types").
+
+ _Name Resolution Rules_
+
+7
+Each position, first_bit, and last_bit is expected to be of any integer
+type.
+
+7.a
+ Ramification: These need not have the same integer type.
+
+ _Legality Rules_
+
+8/2
+{AI95-00436-01AI95-00436-01} The first_subtype_local_name of a
+record_representation_clause shall denote a specific record or record
+extension subtype.
+
+8.a
+ Ramification: As for all type-related representation items,
+ the local_name is required to denote a first subtype.
+
+9
+If the component_local_name is a direct_name, the local_name shall
+denote a component of the type. For a record extension, the component
+shall not be inherited, and shall not be a discriminant that corresponds
+to a discriminant of the parent type. If the component_local_name
+(*note 13.1: S0305.) has an attribute_designator (*note 4.1.4: S0101.),
+the direct_name (*note 4.1: S0092.) of the local_name (*note 13.1:
+S0305.) shall denote either the declaration of the type or a component
+of the type, and the attribute_designator (*note 4.1.4: S0101.) shall
+denote an implementation-defined implicit component of the type.
+
+10
+The position, first_bit, and last_bit shall be static expressions. The
+value of position and first_bit shall be nonnegative. The value of
+last_bit shall be no less than first_bit - 1.
+
+10.a
+ Ramification: A component_clause such as "X at 4 range 0..-1;"
+ is allowed if X can fit in zero bits.
+
+10.1/2
+{AI95-00133-01AI95-00133-01} If the nondefault bit ordering applies to
+the type, then either:
+
+10.2/2
+ * the value of last_bit shall be less than the size of the largest
+ machine scalar; or
+
+10.3/2
+ * the value of first_bit shall be zero and the value of last_bit + 1
+ shall be a multiple of System.Storage_Unit.
+
+11
+At most one component_clause is allowed for each component of the type,
+including for each discriminant (component_clauses may be given for
+some, all, or none of the components). Storage places within a
+component_list shall not overlap, unless they are for components in
+distinct variants of the same variant_part.
+
+12
+A name that denotes a component of a type is not allowed within a
+record_representation_clause for the type, except as the
+component_local_name of a component_clause.
+
+12.a
+ Reason: It might seem strange to make the
+ record_representation_clause part of the declarative region,
+ and then disallow mentions of the components within almost all
+ of the record_representation_clause. The alternative would be
+ to treat the component_local_name like a formal parameter name
+ in a subprogram call (in terms of visibility). However, this
+ rule would imply slightly different semantics, because (given
+ the actual rule) the components can hide other declarations.
+ This was the rule in Ada 83, and we see no reason to change
+ it. The following, for example, was and is illegal:
+
+12.b
+ type T is
+ record
+ X : Integer;
+ end record;
+ X : constant := 31; -- Same defining name as the component.
+ for T use
+ record
+ X at 0 range 0..X; -- Illegal!
+ end record;
+
+
+12.c
+ The component X hides the named number X throughout the
+ record_representation_clause.
+
+ _Static Semantics_
+
+13/2
+{AI95-00133-01AI95-00133-01} A record_representation_clause (without the
+mod_clause) specifies the layout.
+
+13.a/3
+ Aspect Description for Layout (record): Layout of record
+ components. Specified by a record_representation_clause, not
+ by an aspect_specification.
+
+13.b/3
+ Aspect Description for Record layout: See Layout.
+
+13.1/2
+{AI95-00133-01AI95-00133-01} If the default bit ordering applies to the
+type, the position, first_bit, and last_bit of each component_clause
+directly specify the position and size of the corresponding component.
+
+13.2/3
+{AI95-00133-01AI95-00133-01} {AI05-0264-1AI05-0264-1} If the nondefault
+bit ordering applies to the type, then the layout is determined as
+follows:
+
+13.3/2
+ * the component_clauses for which the value of last_bit is greater
+ than or equal to the size of the largest machine scalar directly
+ specify the position and size of the corresponding component;
+
+13.4/2
+ * for other component_clauses, all of the components having the same
+ value of position are considered to be part of a single machine
+ scalar, located at that position; this machine scalar has a size
+ which is the smallest machine scalar size larger than the largest
+ last_bit for all component_clauses at that position; the first_bit
+ and last_bit of each component_clause are then interpreted as bit
+ offsets in this machine scalar.
+
+13.c/2
+ This paragraph was deleted.{AI95-00133-01AI95-00133-01}
+
+13.d
+ Ramification: A component_clause also determines the value of
+ the Size attribute of the component, since this attribute is
+ related to First_Bit and Last_Bit.
+
+14
+[A record_representation_clause for a record extension does not override
+the layout of the parent part;] if the layout was specified for the
+parent type, it is inherited by the record extension.
+
+ _Implementation Permissions_
+
+15
+An implementation may generate implementation-defined components (for
+example, one containing the offset of another component). An
+implementation may generate names that denote such
+implementation-defined components; such names shall be
+implementation-defined attribute_references. An implementation may
+allow such implementation-defined names to be used in
+record_representation_clause (*note 13.5.1: S0312.)s. An implementation
+can restrict such component_clause (*note 13.5.1: S0313.)s in any manner
+it sees fit.
+
+15.a
+ Implementation defined: Implementation-defined components.
+
+15.b
+ Ramification: Of course, since the semantics of
+ implementation-defined attributes is implementation defined,
+ the implementation need not support these names in all
+ situations. They might be purely for the purpose of
+ component_clauses, for example. The visibility rules for such
+ names are up to the implementation.
+
+15.c
+ We do not allow such component names to be normal identifiers
+ -- that would constitute blanket permission to do all kinds of
+ evil things.
+
+15.d
+ Discussion: Such implementation-defined components are known
+ in the vernacular as "dope." Their main purpose is for
+ storing offsets of components that depend on discriminants.
+
+16
+If a record_representation_clause is given for an untagged derived type,
+the storage place attributes for all of the components of the derived
+type may differ from those of the corresponding components of the parent
+type, even for components whose storage place is not specified
+explicitly in the record_representation_clause (*note 13.5.1: S0312.).
+
+16.a
+ Reason: This is clearly necessary, since the whole record may
+ need to be laid out differently.
+
+ _Implementation Advice_
+
+17
+The recommended level of support for record_representation_clauses is:
+
+17.1/2
+ * {AI95-00133-01AI95-00133-01} An implementation should support
+ machine scalars that correspond to all of the integer, floating
+ point, and address formats supported by the machine.
+
+18
+ * An implementation should support storage places that can be
+ extracted with a load, mask, shift sequence of machine code, and
+ set with a load, shift, mask, store sequence, given the available
+ machine instructions and run-time model.
+
+19
+ * A storage place should be supported if its size is equal to the
+ Size of the component subtype, and it starts and ends on a boundary
+ that obeys the Alignment of the component subtype.
+
+20/2
+ * {AI95-00133-01AI95-00133-01} For a component with a subtype whose
+ Size is less than the word size, any storage place that does not
+ cross an aligned word boundary should be supported.
+
+20.a
+ Reason: The above recommendations are sufficient to define
+ interfaces to most interesting hardware. This causes less
+ implementation burden than the definition in ACID, which
+ requires arbitrary bit alignments of arbitrarily large
+ components. Since the ACID definition is neither enforced by
+ the ACVC, nor supported by all implementations, it seems OK
+ for us to weaken it.
+
+21
+ * An implementation may reserve a storage place for the tag field of
+ a tagged type, and disallow other components from overlapping that
+ place.
+
+21.a
+ Ramification: Similar permission for other dope is not
+ granted.
+
+22
+ * An implementation need not support a component_clause for a
+ component of an extension part if the storage place is not after
+ the storage places of all components of the parent type, whether or
+ not those storage places had been specified.
+
+22.a
+ Reason: These restrictions are probably necessary if block
+ equality operations are to be feasible for class-wide types.
+ For block comparison to work, the implementation typically has
+ to fill in any gaps with zero (or one) bits. If a "gap" in
+ the parent type is filled in with a component in a type
+ extension, then this won't work when a class-wide object is
+ passed by reference, as is required.
+
+22.b/2
+ Implementation Advice: The recommended level of support for
+ record_representation_clauses should be followed.
+
+ NOTES
+
+23
+ 14 If no component_clause is given for a component, then the
+ choice of the storage place for the component is left to the
+ implementation. If component_clauses are given for all components,
+ the record_representation_clause completely specifies the
+ representation of the type and will be obeyed exactly by the
+ implementation.
+
+23.a
+ Ramification: The visibility rules prevent the name of a
+ component of the type from appearing in a
+ record_representation_clause at any place except for the
+ component_local_name of a component_clause. However, since
+ the record_representation_clause is part of the declarative
+ region of the type declaration, the component names hide outer
+ homographs throughout.
+
+23.b/1
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} A
+ record_representation_clause cannot be given for a protected
+ type, even though protected types, like record types, have
+ components. The primary reason for this rule is that there is
+ likely to be too much dope in a protected type -- entry
+ queues, bit maps for barrier values, etc. In order to control
+ the representation of the user-defined components, simply
+ declare a record type, give it a record_representation_clause
+ (*note 13.5.1: S0312.), and give the protected type one
+ component whose type is the record type. Alternatively, if
+ the protected object is protecting something like a device
+ register, it makes more sense to keep the thing being
+ protected outside the protected object (possibly with a
+ pointer to it in the protected object), in order to keep
+ implementation-defined components out of the way.
+
+ _Examples_
+
+24
+Example of specifying the layout of a record type:
+
+25
+ Word : constant := 4; -- storage element is byte, 4 bytes per word
+
+26
+ type State is (A,M,W,P);
+ type Mode is (Fix, Dec, Exp, Signif);
+
+27
+ type Byte_Mask is array (0..7) of Boolean;
+ type State_Mask is array (State) of Boolean;
+ type Mode_Mask is array (Mode) of Boolean;
+
+28
+ type Program_Status_Word is
+ record
+ System_Mask : Byte_Mask;
+ Protection_Key : Integer range 0 .. 3;
+ Machine_State : State_Mask;
+ Interrupt_Cause : Interruption_Code;
+ Ilc : Integer range 0 .. 3;
+ Cc : Integer range 0 .. 3;
+ Program_Mask : Mode_Mask;
+ Inst_Address : Address;
+ end record;
+
+29
+ for Program_Status_Word use
+ record
+ System_Mask at 0*Word range 0 .. 7;
+ Protection_Key at 0*Word range 10 .. 11; -- bits 8,9 unused
+ Machine_State at 0*Word range 12 .. 15;
+ Interrupt_Cause at 0*Word range 16 .. 31;
+ Ilc at 1*Word range 0 .. 1; -- second word
+ Cc at 1*Word range 2 .. 3;
+ Program_Mask at 1*Word range 4 .. 7;
+ Inst_Address at 1*Word range 8 .. 31;
+ end record;
+
+30
+ for Program_Status_Word'Size use 8*System.Storage_Unit;
+ for Program_Status_Word'Alignment use 8;
+
+ NOTES
+
+31
+ 15 Note on the example: The record_representation_clause defines
+ the record layout. The Size clause guarantees that (at least)
+ eight storage elements are used for objects of the type. The
+ Alignment clause guarantees that aliased, imported, or exported
+ objects of the type will have addresses divisible by eight.
+
+ _Wording Changes from Ada 83_
+
+31.a
+ The alignment_clause has been renamed to mod_clause and moved
+ to *note Annex J::, "*note Annex J:: Obsolescent Features".
+
+31.b
+ We have clarified that implementation-defined component names
+ have to be in the form of an attribute_reference of a
+ component or of the first subtype itself; surely Ada 83 did
+ not intend to allow arbitrary identifiers.
+
+31.c
+ The RM83-13.4(7) wording incorrectly allows components in
+ nonvariant records to overlap. We have corrected that
+ oversight.
+
+ _Incompatibilities With Ada 95_
+
+31.d/2
+ {AI95-00133-01AI95-00133-01} Amendment Correction: The meaning
+ of a record_representation_clause for the nondefault bit order
+ is now clearly defined. Thus, such clauses can be portably
+ written. In order to do that though, the equivalence of bit 1
+ in word 1 to bit 9 in word 0 (for a machine with Storage_Unit
+ = 8) had to be dropped for the nondefault bit order. Any
+ record_representation_clauses which depends on that
+ equivalence will break (although such code would imply a
+ noncontiguous representation for a component, and it seems
+ unlikely that compilers were supporting that anyway).
+
+ _Extensions to Ada 95_
+
+31.e/2
+ {AI95-00436-01AI95-00436-01} Amendment Correction: The
+ undocumented (and likely unintentional) incompatibility with
+ Ada 83 caused by not allowing record_representation_clauses on
+ limited record types is removed.
+
+\1f
+File: aarm2012.info, Node: 13.5.2, Next: 13.5.3, Prev: 13.5.1, Up: 13.5
+
+13.5.2 Storage Place Attributes
+-------------------------------
+
+ _Static Semantics_
+
+1
+For a component C of a composite, non-array object R, the storage place
+attributes are defined:
+
+1.a
+ Ramification: The storage place attributes are not
+ (individually) specifiable, but the user may control their
+ values by giving a record_representation_clause.
+
+2/2
+R.C'Position
+ {AI95-00133-01AI95-00133-01} If the nondefault bit
+ ordering applies to the composite type, and if a
+ component_clause specifies the placement of C, denotes
+ the value given for the position of the component_clause;
+ otherwise, denotes the same value as R.C'Address -
+ R'Address. The value of this attribute is of the type
+ universal_integer.
+
+2.a/2
+ Ramification: {AI95-00133-01AI95-00133-01} Thus, for the
+ default bit order, R.C'Position is the offset of C in storage
+ elements from the beginning of the object, where the first
+ storage element of an object is numbered zero. R'Address +
+ R.C'Position = R.C'Address. For record extensions, the offset
+ is not measured from the beginning of the extension part, but
+ from the beginning of the whole object, as usual.
+
+2.b
+ In "R.C'Address - R'Address", the "-" operator is the one in
+ System.Storage_Elements that takes two Addresses and returns a
+ Storage_Offset.
+
+3/2
+R.C'First_Bit
+ {AI95-00133-01AI95-00133-01} If the nondefault bit
+ ordering applies to the composite type, and if a
+ component_clause specifies the placement of C, denotes
+ the value given for the first_bit of the
+ component_clause; otherwise, denotes the offset, from the
+ start of the first of the storage elements occupied by C,
+ of the first bit occupied by C. This offset is measured
+ in bits. The first bit of a storage element is numbered
+ zero. The value of this attribute is of the type
+ universal_integer.
+
+4/2
+R.C'Last_Bit
+ {AI95-00133-01AI95-00133-01} If the nondefault bit
+ ordering applies to the composite type, and if a
+ component_clause specifies the placement of C, denotes
+ the value given for the last_bit of the component_clause;
+ otherwise, denotes the offset, from the start of the
+ first of the storage elements occupied by C, of the last
+ bit occupied by C. This offset is measured in bits. The
+ value of this attribute is of the type universal_integer.
+
+4.a/2
+ Ramification: {AI95-00114-01AI95-00114-01} The ordering of
+ bits in a storage element is defined in *note 13.5.3::, "*note
+ 13.5.3:: Bit Ordering".
+
+4.b
+ R.C'Size = R.C'Last_Bit - R.C'First_Bit + 1. (Unless the
+ implementation chooses an indirection representation.)
+
+4.c
+ If a component_clause applies to a component, then that
+ component will be at the same relative storage place in all
+ objects of the type. Otherwise, there is no such requirement.
+
+ _Implementation Advice_
+
+5
+If a component is represented using some form of pointer (such as an
+offset) to the actual data of the component, and this data is contiguous
+with the rest of the object, then the storage place attributes should
+reflect the place of the actual data, not the pointer. If a component
+is allocated discontiguously from the rest of the object, then a warning
+should be generated upon reference to one of its storage place
+attributes.
+
+5.a
+ Reason: For discontiguous components, these attributes make no
+ sense. For example, an implementation might allocate
+ dynamic-sized components on the heap. For another example, an
+ implementation might allocate the discriminants separately
+ from the other components, so that multiple objects of the
+ same subtype can share discriminants. Such representations
+ cannot happen if there is a component_clause for that
+ component.
+
+5.b/2
+ Implementation Advice: If a component is represented using a
+ pointer to the actual data of the component which is
+ contiguous with the rest of the object, then the storage place
+ attributes should reflect the place of the actual data. If a
+ component is allocated discontiguously from the rest of the
+ object, then a warning should be generated upon reference to
+ one of its storage place attributes.
+
+ _Incompatibilities With Ada 95_
+
+5.c/2
+ {AI95-00133-01AI95-00133-01} Amendment Correction: The meaning
+ of the storage place attributes for the nondefault bit order
+ is now clearly defined, and can be different than that given
+ by strictly following the Ada 95 wording. Any code which
+ depends on the original Ada 95 values for a type using the
+ nondefault bit order where they are different will break.
+
+\1f
+File: aarm2012.info, Node: 13.5.3, Prev: 13.5.2, Up: 13.5
+
+13.5.3 Bit Ordering
+-------------------
+
+1
+[The Bit_Order attribute specifies the interpretation of the storage
+place attributes.]
+
+1.a
+ Reason: The intention is to provide uniformity in the
+ interpretation of storage places across implementations on a
+ particular machine by allowing the user to specify the
+ Bit_Order. It is not intended to fully support data
+ interoperability across different machines, although it can be
+ used for that purpose in some situations.
+
+1.b/2
+ {AI95-00114-01AI95-00114-01} We can't require all
+ implementations on a given machine to use the same bit
+ ordering by default; if the user cares, a Bit_Order
+ attribute_definition_clause can be used to force all
+ implementations to use the same bit ordering.
+
+ _Static Semantics_
+
+2
+A bit ordering is a method of interpreting the meaning of the storage
+place attributes. High_Order_First [(known in the vernacular as "big
+endian")] means that the first bit of a storage element (bit 0) is the
+most significant bit (interpreting the sequence of bits that represent a
+component as an unsigned integer value). Low_Order_First [(known in the
+vernacular as "little endian")] means the opposite: the first bit is the
+least significant.
+
+3
+For every specific record subtype S, the following attribute is defined:
+
+4
+S'Bit_Order
+ Denotes the bit ordering for the type of S. The value of
+ this attribute is of type System.Bit_Order. Bit_Order
+ may be specified for specific record types via an
+ attribute_definition_clause; the expression of such a
+ clause shall be static.
+
+4.a/3
+ Aspect Description for Bit_Order: Order of bit numbering in a
+ record_representation_clause.
+
+5
+If Word_Size = Storage_Unit, the default bit ordering is implementation
+defined. If Word_Size > Storage_Unit, the default bit ordering is the
+same as the ordering of storage elements in a word, when interpreted as
+an integer.
+
+5.a
+ Implementation defined: If Word_Size = Storage_Unit, the
+ default bit ordering.
+
+5.b
+ Ramification: Consider machines whose Word_Size = 32, and
+ whose Storage_Unit = 8. Assume the default bit ordering
+ applies. On a machine with big-endian addresses, the most
+ significant storage element of an integer is at the address of
+ the integer. Therefore, bit zero of a storage element is the
+ most significant bit. On a machine with little-endian
+ addresses, the least significant storage element of an integer
+ is at the address of the integer. Therefore, bit zero of a
+ storage element is the least significant bit.
+
+6
+The storage place attributes of a component of a type are interpreted
+according to the bit ordering of the type.
+
+6.a
+ Ramification: This implies that the interpretation of the
+ position, first_bit, and last_bit of a component_clause of a
+ record_representation_clause obey the bit ordering given in a
+ representation item.
+
+ _Implementation Advice_
+
+7
+The recommended level of support for the nondefault bit ordering is:
+
+8/2
+ * {AI95-00133-01AI95-00133-01} The implementation should support the
+ nondefault bit ordering in addition to the default bit ordering.
+
+8.a/2
+ Ramification: {AI95-00133-01AI95-00133-01} The implementation
+ should support both bit orderings. Implementations are
+ required to support storage positions that cross storage
+ element boundaries when Word_Size > Storage_Unit but the
+ definition of the storage place attributes for the nondefault
+ bit order ensures that such storage positions will not be
+ split into two or three pieces. Thus, there is no significant
+ implementation burden to supporting the nondefault bit order,
+ given that the set of machine scalars is
+ implementation-defined.
+
+8.b/2
+ Implementation Advice: The recommended level of support for
+ the nondefault bit ordering should be followed.
+
+ NOTES
+
+9/2
+ 16 {AI95-00133-01AI95-00133-01} Bit_Order clauses make it possible
+ to write record_representation_clauses that can be ported between
+ machines having different bit ordering. They do not guarantee
+ transparent exchange of data between such machines.
+
+ _Extensions to Ada 83_
+
+9.a
+ The Bit_Order attribute is new to Ada 95.
+
+ _Wording Changes from Ada 95_
+
+9.b/2
+ {AI95-00133-01AI95-00133-01} We now suggest that all
+ implementations support the nondefault bit order.
+
+\1f
+File: aarm2012.info, Node: 13.6, Next: 13.7, Prev: 13.5, Up: 13
+
+13.6 Change of Representation
+=============================
+
+1/3
+{AI05-0229-1AI05-0229-1} [ A type_conversion (see *note 4.6::) can be
+used to convert between two different representations of the same array
+or record. To convert an array from one representation to another, two
+array types need to be declared with matching component subtypes, and
+convertible index types. If one type has Pack specified and the other
+does not, then explicit conversion can be used to pack or unpack an
+array.
+
+2
+To convert a record from one representation to another, two record types
+with a common ancestor type need to be declared, with no inherited
+subprograms. Distinct representations can then be specified for the
+record types, and explicit conversion between the types can be used to
+effect a change in representation.]
+
+2.a
+ Ramification: This technique does not work if the first type
+ is an untagged type with user-defined primitive subprograms.
+ It does not work at all for tagged types.
+
+ _Examples_
+
+3
+Example of change of representation:
+
+4
+ -- Packed_Descriptor and Descriptor are two different types
+ -- with identical characteristics, apart from their
+ -- representation
+
+5
+ type Descriptor is
+ record
+ -- components of a descriptor
+ end record;
+
+6
+ type Packed_Descriptor is new Descriptor;
+
+7
+ for Packed_Descriptor use
+ record
+ -- component clauses for some or for all components
+ end record;
+
+8
+ -- Change of representation can now be accomplished by explicit type conversions:
+
+9
+ D : Descriptor;
+ P : Packed_Descriptor;
+
+10
+ P := Packed_Descriptor(D); -- pack D
+ D := Descriptor(P); -- unpack P
+
+\1f
+File: aarm2012.info, Node: 13.7, Next: 13.8, Prev: 13.6, Up: 13
+
+13.7 The Package System
+=======================
+
+1
+[For each implementation there is a library package called System which
+includes the definitions of certain configuration-dependent
+characteristics.]
+
+ _Static Semantics_
+
+2
+The following language-defined library package exists:
+
+2.a/2
+ Implementation defined: The contents of the visible part of
+ package System.
+
+3/2
+ {AI95-00362-01AI95-00362-01} package System is
+ pragma Pure(System);
+
+4
+ type Name is implementation-defined-enumeration-type;
+ System_Name : constant Name := implementation-defined;
+
+5
+ -- System-Dependent Named Numbers:
+
+6
+ Min_Int : constant := root_integer'First;
+ Max_Int : constant := root_integer'Last;
+
+7
+ Max_Binary_Modulus : constant := implementation-defined;
+ Max_Nonbinary_Modulus : constant := implementation-defined;
+
+8
+ Max_Base_Digits : constant := root_real'Digits;
+ Max_Digits : constant := implementation-defined;
+
+9
+ Max_Mantissa : constant := implementation-defined;
+ Fine_Delta : constant := implementation-defined;
+
+10
+ Tick : constant := implementation-defined;
+
+11
+ -- Storage-related Declarations:
+
+12
+ type Address is implementation-defined;
+ Null_Address : constant Address;
+
+13
+ Storage_Unit : constant := implementation-defined;
+ Word_Size : constant := implementation-defined * Storage_Unit;
+ Memory_Size : constant := implementation-defined;
+
+14/3
+ {AI05-0229-1AI05-0229-1} -- Address Comparison:
+ function "<" (Left, Right : Address) return Boolean
+ with Convention => Intrinsic;
+ function "<="(Left, Right : Address) return Boolean
+ with Convention => Intrinsic;
+ function ">" (Left, Right : Address) return Boolean
+ with Convention => Intrinsic;
+ function ">="(Left, Right : Address) return Boolean
+ with Convention => Intrinsic;
+ function "=" (Left, Right : Address) return Boolean
+ with Convention => Intrinsic;
+ -- function "/=" (Left, Right : Address) return Boolean;
+ -- "/=" is implicitly defined
+
+15/2
+ {AI95-00221-01AI95-00221-01} -- Other System-Dependent Declarations:
+ type Bit_Order is (High_Order_First, Low_Order_First);
+ Default_Bit_Order : constant Bit_Order := implementation-defined;
+
+16
+ -- Priority-related declarations (see *note D.1::):
+ subtype Any_Priority is Integer range implementation-defined;
+ subtype Priority is Any_Priority range Any_Priority'First ..
+ implementation-defined;
+ subtype Interrupt_Priority is Any_Priority range Priority'Last+1 ..
+ Any_Priority'Last;
+
+17
+ Default_Priority : constant Priority :=
+ (Priority'First + Priority'Last)/2;
+
+18
+ private
+ ... -- not specified by the language
+ end System;
+
+19
+Name is an enumeration subtype. Values of type Name are the names of
+alternative machine configurations handled by the implementation.
+System_Name represents the current machine configuration.
+
+20
+The named numbers Fine_Delta and Tick are of the type universal_real;
+the others are of the type universal_integer.
+
+21
+The meanings of the named numbers are:
+
+22
+[ Min_Int
+ The smallest (most negative) value allowed for the
+ expressions of a signed_integer_type_definition (*note
+ 3.5.4: S0042.).
+
+23
+Max_Int
+ The largest (most positive) value allowed for the
+ expressions of a signed_integer_type_definition (*note
+ 3.5.4: S0042.).
+
+24
+Max_Binary_Modulus
+ A power of two such that it, and all lesser positive
+ powers of two, are allowed as the modulus of a
+ modular_type_definition.
+
+25
+Max_Nonbinary_Modulus
+ A value such that it, and all lesser positive integers,
+ are allowed as the modulus of a modular_type_definition.
+
+25.a
+ Ramification: There is no requirement that
+ Max_Nonbinary_Modulus be less than or equal to
+ Max_Binary_Modulus, although that's what makes most sense. On
+ a typical 32-bit machine, for example, Max_Binary_Modulus will
+ be 2**32 and Max_Nonbinary_Modulus will be 2**31, because
+ supporting nonbinary moduli in above 2**31 causes
+ implementation difficulties.
+
+26
+Max_Base_Digits
+ The largest value allowed for the requested decimal
+ precision in a floating_point_definition (*note 3.5.7:
+ S0045.).
+
+27
+Max_Digits
+ The largest value allowed for the requested decimal
+ precision in a floating_point_definition (*note 3.5.7:
+ S0045.) that has no real_range_specification (*note
+ 3.5.7: S0046.). Max_Digits is less than or equal to
+ Max_Base_Digits.
+
+28
+Max_Mantissa
+ The largest possible number of binary digits in the
+ mantissa of machine numbers of a user-defined ordinary
+ fixed point type. (The mantissa is defined in *note
+ Annex G::.)
+
+29
+Fine_Delta
+ The smallest delta allowed in an
+ ordinary_fixed_point_definition that has the
+ real_range_specification (*note 3.5.7: S0046.) range -1.0
+ .. 1.0. ]
+
+30
+Tick
+ A period in seconds approximating the real time interval
+ during which the value of Calendar.Clock remains
+ constant.
+
+30.a
+ Ramification: There is no required relationship between
+ System.Tick and Duration'Small, other than the one described
+ here.
+
+30.b
+ The inaccuracy of the delay_statement has no relation to Tick.
+ In particular, it is possible that the clock used for the
+ delay_statement is less accurate than Calendar.Clock.
+
+30.c
+ We considered making Tick a run-time-determined quantity, to
+ allow for easier configurability. However, this would not be
+ upward compatible, and the desired configurability can be
+ achieved using functionality defined in *note Annex D::,
+ "*note Annex D:: Real-Time Systems".
+
+31
+Storage_Unit
+ The number of bits per storage element.
+
+32
+Word_Size
+ The number of bits per word.
+
+33
+Memory_Size
+ An implementation-defined value [that is intended to
+ reflect the memory size of the configuration in storage
+ elements.]
+
+33.a
+ Discussion: It is unspecified whether this refers to the size
+ of the address space, the amount of physical memory on the
+ machine, or perhaps some other interpretation of "memory
+ size." In any case, the value has to be given by a static
+ expression, even though the amount of memory on many modern
+ machines is a dynamic quantity in several ways. Thus,
+ Memory_Size is not very useful.
+
+34/2
+{AI95-00161-01AI95-00161-01} Address is a definite, nonlimited type with
+preelaborable initialization (see *note 10.2.1::). Address represents
+machine addresses capable of addressing individual storage elements.
+Null_Address is an address that is distinct from the address of any
+object or program unit.
+
+34.a
+ Ramification: The implementation has to ensure that there is
+ at least one address that nothing will be allocated to;
+ Null_Address will be one such address.
+
+34.b
+ Ramification: Address is the type of the result of the
+ attribute Address.
+
+34.c
+ Reason: Address is required to be nonlimited and definite
+ because it is important to be able to assign addresses, and to
+ declare uninitialized address variables.
+
+34.d/2
+ Ramification: {AI95-00161-01AI95-00161-01} If System.Address
+ is defined as a private type (as suggested below), it might be
+ necessary to add a pragma Preelaborable_Initialization to the
+ specification of System in order that Address have
+ preelaborable initialization as required.
+
+35/2
+{AI95-00221-01AI95-00221-01} Default_Bit_Order shall be a static
+constant. See *note 13.5.3:: for an explanation of Bit_Order and
+Default_Bit_Order.
+
+ _Implementation Permissions_
+
+36/2
+{AI95-00362-01AI95-00362-01} An implementation may add additional
+implementation-defined declarations to package System and its children.
+[However, it is usually better for the implementation to provide
+additional functionality via implementation-defined children of System.]
+
+36.a
+ Ramification: The declarations in package System and its
+ children can be implicit. For example, since Address is not
+ limited, the predefined "=" and "/=" operations are probably
+ sufficient. However, the implementation is not required to
+ use the predefined "=".
+
+ _Implementation Advice_
+
+37
+Address should be a private type.
+
+37.a
+ Reason: This promotes uniformity by avoiding having
+ implementation-defined predefined operations for the type. We
+ don't require it, because implementations may want to stick
+ with what they have.
+
+37.a.1/2
+ Implementation Advice: Type System.Address should be a private
+ type.
+
+37.b
+ Implementation Note: It is not necessary for Address to be
+ able to point at individual bits within a storage element.
+ Nor is it necessary for it to be able to point at machine
+ registers. It is intended as a memory address that matches
+ the hardware's notion of an address.
+
+37.c
+ The representation of the null value of a general access type
+ should be the same as that of Null_Address; instantiations of
+ Unchecked_Conversion should work accordingly. If the
+ implementation supports interfaces to other languages, the
+ representation of the null value of a general access type
+ should be the same as in those other languages, if
+ appropriate.
+
+37.d
+ Note that the children of the Interfaces package will
+ generally provide foreign-language-specific null values where
+ appropriate. See UI-0065 regarding Null_Address.
+
+ NOTES
+
+38
+ 17 There are also some language-defined child packages of System
+ defined elsewhere.
+
+ _Extensions to Ada 83_
+
+38.a.1/1
+ The declarations Max_Binary_Modulus, Max_Nonbinary_Modulus,
+ Max_Base_Digits, Null_Address, Word_Size, Bit_Order,
+ Default_Bit_Order, Any_Priority, Interrupt_Priority, and
+ Default_Priority are added to System in Ada 95. The presence
+ of ordering operators for type Address is also guaranteed (the
+ existence of these depends on the definition of Address in an
+ Ada 83 implementation). We do not list these as
+ incompatibilities, as the contents of System can vary between
+ implementations anyway; thus a program that depends on the
+ contents of System (by using use System; for example) is
+ already at risk of being incompatible when moved between Ada
+ implementations.
+
+ _Wording Changes from Ada 83_
+
+38.a
+ Much of the content of System is standardized, to provide more
+ uniformity across implementations. Implementations can still
+ add their own declarations to System, but are encouraged to do
+ so via children of System.
+
+38.b
+ Some of the named numbers are defined more explicitly in terms
+ of the standard numeric types.
+
+38.c
+ The pragmas System_Name, Storage_Unit, and Memory_Size are no
+ longer defined by the language. However, the corresponding
+ declarations in package System still exist. Existing
+ implementations may continue to support the three pragmas as
+ implementation-defined pragmas, if they so desire.
+
+38.d
+ Priority semantics, including subtype Priority, have been
+ moved to the Real Time Annex.
+
+ _Extensions to Ada 95_
+
+38.e/2
+ {AI95-00161-01AI95-00161-01} Amendment Correction: Type
+ Address is defined to have preelaborable initialization, so
+ that it can be used without restriction in preelaborated
+ units. (If Address is defined to be a private type, as
+ suggested by the Implementation Advice, in Ada 95 it cannot be
+ used in some contexts in a preelaborated units. This is an
+ unnecessary portability issue.)
+
+38.f/2
+ {AI95-00221-01AI95-00221-01} Amendment Correction:
+ Default_Bit_Order is now a static constant.
+
+38.g/2
+ {AI95-00362-01AI95-00362-01} Package System is now Pure, so it
+ can be portably used in more places. (Ada 95 allowed it to be
+ Pure, but did not require that.)
+
+* Menu:
+
+* 13.7.1 :: The Package System.Storage_Elements
+* 13.7.2 :: The Package System.Address_To_Access_Conversions
+
+\1f
+File: aarm2012.info, Node: 13.7.1, Next: 13.7.2, Up: 13.7
+
+13.7.1 The Package System.Storage_Elements
+------------------------------------------
+
+ _Static Semantics_
+
+1
+The following language-defined library package exists:
+
+2/2
+ {AI95-00362-01AI95-00362-01} package System.Storage_Elements is
+ pragma Pure(Storage_Elements);
+
+3
+ type Storage_Offset is range implementation-defined;
+
+4
+ subtype Storage_Count is Storage_Offset range 0..Storage_Offset'Last;
+
+5
+ type Storage_Element is mod implementation-defined;
+ for Storage_Element'Size use Storage_Unit;
+ type Storage_Array is array
+ (Storage_Offset range <>) of aliased Storage_Element;
+ for Storage_Array'Component_Size use Storage_Unit;
+
+6
+ -- Address Arithmetic:
+
+7/3
+ {AI05-0229-1AI05-0229-1} function "+"(Left : Address; Right : Storage_Offset) return Address
+ with Convention => Intrinsic;
+ function "+"(Left : Storage_Offset; Right : Address) return Address
+ with Convention => Intrinsic;
+ function "-"(Left : Address; Right : Storage_Offset) return Address
+ with Convention => Intrinsic;
+ function "-"(Left, Right : Address) return Storage_Offset
+ with Convention => Intrinsic;
+
+8/3
+ {AI05-0229-1AI05-0229-1} function "mod"(Left : Address; Right : Storage_Offset)
+ return Storage_Offset
+ with Convention => Intrinsic;
+
+9
+ -- Conversion to/from integers:
+
+10/3
+ {AI05-0229-1AI05-0229-1} type Integer_Address is implementation-defined;
+ function To_Address(Value : Integer_Address) return Address
+ with Convention => Intrinsic;
+ function To_Integer(Value : Address) return Integer_Address
+ with Convention => Intrinsic;
+
+11/3
+ {AI05-0229-1AI05-0229-1} end System.Storage_Elements;
+
+11.a/3
+ Reason: {AI05-0229-1AI05-0229-1} The Convention aspects imply
+ that the attribute Access is not allowed for those operations.
+
+11.b
+ The mod function is needed so that the definition of Alignment
+ makes sense.
+
+11.c/2
+ Implementation defined: The range of
+ Storage_Elements.Storage_Offset, the modulus of
+ Storage_Elements.Storage_Element, and the declaration of
+ Storage_Elements.Integer_Address..
+
+12
+Storage_Element represents a storage element. Storage_Offset represents
+an offset in storage elements. Storage_Count represents a number of
+storage elements. Storage_Array represents a contiguous sequence of
+storage elements.
+
+12.a
+ Reason: The index subtype of Storage_Array is Storage_Offset
+ because we wish to allow maximum flexibility. Most
+ Storage_Arrays will probably have a lower bound of 0 or 1, but
+ other lower bounds, including negative ones, make sense in
+ some situations.
+
+12.b/2
+ This paragraph was deleted.{AI95-00114-01AI95-00114-01}
+
+13
+Integer_Address is a [(signed or modular)] integer subtype. To_Address
+and To_Integer convert back and forth between this type and Address.
+
+ _Implementation Requirements_
+
+14
+Storage_Offset'Last shall be greater than or equal to Integer'Last or
+the largest possible storage offset, whichever is smaller.
+Storage_Offset'First shall be <= (-Storage_Offset'Last).
+
+Paragraph 15 was deleted.
+
+ _Implementation Advice_
+
+16
+Operations in System and its children should reflect the target
+environment semantics as closely as is reasonable. For example, on most
+machines, it makes sense for address arithmetic to "wrap around."
+Operations that do not make sense should raise Program_Error.
+
+16.a.1/2
+ Implementation Advice: Operations in System and its children
+ should reflect the target environment; operations that do not
+ make sense should raise Program_Error.
+
+16.a
+ Discussion: For example, on a segmented architecture, X < Y
+ might raise Program_Error if X and Y do not point at the same
+ segment (assuming segments are unordered). Similarly, on a
+ segmented architecture, the conversions between
+ Integer_Address and Address might not make sense for some
+ values, and so might raise Program_Error.
+
+16.b
+ Reason: We considered making Storage_Element a private type.
+ However, it is better to declare it as a modular type in the
+ visible part, since code that uses it is already low level,
+ and might as well have access to the underlying
+ representation. We also considered allowing Storage_Element
+ to be any integer type, signed integer or modular, but it is
+ better to have uniformity across implementations in this
+ regard, and viewing storage elements as unsigned seemed to
+ make the most sense.
+
+16.c
+ Implementation Note: To_Address is intended for use in Address
+ clauses. Implementations should overload To_Address if
+ appropriate. For example, on a segmented architecture, it
+ might make sense to have a record type representing a
+ segment/offset pair, and have a To_Address conversion that
+ converts from that record type to type Address.
+
+ _Extensions to Ada 95_
+
+16.d/2
+ {AI95-00362-01AI95-00362-01} Package System.Storage_Elements
+ is now Pure, so it can be portably used in more places. (Ada
+ 95 allowed it to be Pure, but did not require that.)
+
+\1f
+File: aarm2012.info, Node: 13.7.2, Prev: 13.7.1, Up: 13.7
+
+13.7.2 The Package System.Address_To_Access_Conversions
+-------------------------------------------------------
+
+ _Static Semantics_
+
+1
+The following language-defined generic library package exists:
+
+2
+ generic
+ type Object(<>) is limited private;
+ package System.Address_To_Access_Conversions is
+ pragma Preelaborate(Address_To_Access_Conversions);
+
+3/3
+ {AI05-0229-1AI05-0229-1} type Object_Pointer is access all Object;
+ function To_Pointer(Value : Address) return Object_Pointer
+ with Convention => Intrinsic;
+ function To_Address(Value : Object_Pointer) return Address
+ with Convention => Intrinsic;
+
+4/3
+ {AI05-0229-1AI05-0229-1} end System.Address_To_Access_Conversions;
+
+5/2
+{AI95-00230-01AI95-00230-01} The To_Pointer and To_Address subprograms
+convert back and forth between values of types Object_Pointer and
+Address. To_Pointer(X'Address) is equal to X'Unchecked_Access for any X
+that allows Unchecked_Access. To_Pointer(Null_Address) returns null.
+For other addresses, the behavior is unspecified. To_Address(null)
+returns Null_Address. To_Address(Y), where Y /= null, returns
+Y.all'Address.
+
+5.a/3
+ Discussion: {AI95-00114-01AI95-00114-01}
+ {AI05-0005-1AI05-0005-1} The programmer should ensure that the
+ address passed to To_Pointer is either Null_Address, or the
+ address of an object of type Object. (If Object is not a
+ by-reference type, the object ought to be aliased; recall that
+ the Address attribute is not required to provide a useful
+ result for other objects.) Otherwise, the behavior of the
+ program is unspecified; it might raise an exception or crash,
+ for example.
+
+5.b
+ Reason: Unspecified is almost the same thing as erroneous;
+ they both allow arbitrarily bad behavior. We don't say
+ erroneous here, because the implementation might allow the
+ address passed to To_Pointer to point at some memory that just
+ happens to "look like" an object of type Object. That's not
+ necessarily an error; it's just not portable. However, if the
+ actual type passed to Object is (for example) an array type,
+ the programmer would need to be aware of any dope that the
+ implementation expects to exist, when passing an address that
+ did not come from the Address attribute of an object of type
+ Object.
+
+5.c
+ One might wonder why To_Pointer and To_Address are any better
+ than unchecked conversions. The answer is that Address does
+ not necessarily have the same representation as an access
+ type. For example, an access value might point at the bounds
+ of an array when an address would point at the first element.
+ Or an access value might be an offset in words from someplace,
+ whereas an address might be an offset in bytes from the
+ beginning of memory.
+
+ _Implementation Permissions_
+
+6
+An implementation may place restrictions on instantiations of
+Address_To_Access_Conversions.
+
+6.a
+ Ramification: For example, if the hardware requires aligned
+ loads and stores, then dereferencing an access value that is
+ not properly aligned might raise an exception.
+
+6.b
+ For another example, if the implementation has chosen to use
+ negative component offsets (from an access value), it might
+ not be possible to preserve the semantics, since negative
+ offsets from the Address are not allowed. (The Address
+ attribute always points at "the first of the storage
+ elements....") Note that while the implementation knows how
+ to convert an access value into an address, it might not be
+ able to do the reverse. To avoid generic contract model
+ violations, the restriction might have to be detected at run
+ time in some cases.
+
+\1f
+File: aarm2012.info, Node: 13.8, Next: 13.9, Prev: 13.7, Up: 13
+
+13.8 Machine Code Insertions
+============================
+
+1
+[ A machine code insertion can be achieved by a call to a subprogram
+whose sequence_of_statements contains code_statements.]
+
+ _Syntax_
+
+2
+ code_statement ::= qualified_expression;
+
+3
+ A code_statement is only allowed in the
+ handled_sequence_of_statements (*note 11.2: S0265.) of a
+ subprogram_body (*note 6.3: S0177.). If a subprogram_body (*note
+ 6.3: S0177.) contains any code_statement (*note 13.8: S0317.)s,
+ then within this subprogram_body (*note 6.3: S0177.) the only
+ allowed form of statement is a code_statement (*note 13.8: S0317.)
+ (labeled or not), the only allowed declarative_item (*note 3.11:
+ S0087.)s are use_clause (*note 8.4: S0196.)s, and no
+ exception_handler (*note 11.2: S0266.) is allowed (comments and
+ pragmas are allowed as usual).
+
+ _Name Resolution Rules_
+
+4
+The qualified_expression is expected to be of any type.
+
+ _Legality Rules_
+
+5
+The qualified_expression shall be of a type declared in package
+System.Machine_Code.
+
+5.a
+ Ramification: This includes types declared in children of
+ System.Machine_Code.
+
+6
+A code_statement shall appear only within the scope of a with_clause
+that mentions package System.Machine_Code.
+
+6.a
+ Ramification: Note that this is not a note; without this rule,
+ it would be possible to write machine code in compilation
+ units which depend on System.Machine_Code only indirectly.
+
+ _Static Semantics_
+
+7
+The contents of the library package System.Machine_Code (if provided)
+are implementation defined. The meaning of code_statements is
+implementation defined. [Typically, each qualified_expression
+represents a machine instruction or assembly directive.]
+
+7.a
+ Discussion: For example, an instruction might be a record with
+ an Op_Code component and other components for the operands.
+
+7.b
+ Implementation defined: The contents of the visible part of
+ package System.Machine_Code, and the meaning of
+ code_statements.
+
+ _Implementation Permissions_
+
+8
+An implementation may place restrictions on code_statements. An
+implementation is not required to provide package System.Machine_Code.
+
+ NOTES
+
+9
+ 18 An implementation may provide implementation-defined pragmas
+ specifying register conventions and calling conventions.
+
+10/2
+ 19 {AI95-00318-02AI95-00318-02} Machine code functions are exempt
+ from the rule that a return statement is required. In fact, return
+ statements are forbidden, since only code_statements are allowed.
+
+10.a
+ Discussion: The idea is that the author of a machine code
+ subprogram knows the calling conventions, and refers to
+ parameters and results accordingly. The implementation should
+ document where to put the result of a machine code function,
+ for example, "Scalar results are returned in register 0."
+
+11
+ 20 Intrinsic subprograms (see *note 6.3.1::, "*note 6.3.1::
+ Conformance Rules") can also be used to achieve machine code
+ insertions. Interface to assembly language can be achieved using
+ the features in *note Annex B::, "*note Annex B:: Interface to
+ Other Languages".
+
+ _Examples_
+
+12
+Example of a code statement:
+
+13/3
+ {AI05-0229-1AI05-0229-1} M : Mask;
+ procedure Set_Mask
+ with Inline;
+
+14
+ procedure Set_Mask is
+ use System.Machine_Code; -- assume "with System.Machine_Code;" appears somewhere above
+ begin
+ SI_Format'(Code => SSM, B => M'Base_Reg, D => M'Disp);
+ -- Base_Reg and Disp are implementation-defined attributes
+ end Set_Mask;
+
+ _Extensions to Ada 83_
+
+14.a
+ Machine code functions are allowed in Ada 95; in Ada 83, only
+ procedures were allowed.
+
+ _Wording Changes from Ada 83_
+
+14.b
+ The syntax for code_statement is changed to say
+ "qualified_expression" instead of "subtype_mark'
+ record_aggregate". Requiring the type of each instruction to
+ be a record type is overspecification.
+
+\1f
+File: aarm2012.info, Node: 13.9, Next: 13.10, Prev: 13.8, Up: 13
+
+13.9 Unchecked Type Conversions
+===============================
+
+1
+[ An unchecked type conversion can be achieved by a call to an instance
+of the generic function Unchecked_Conversion.]
+
+ _Static Semantics_
+
+2
+The following language-defined generic library function exists:
+
+3/3
+ {AI05-0229-1AI05-0229-1} generic
+ type Source(<>) is limited private;
+ type Target(<>) is limited private;
+ function Ada.Unchecked_Conversion(S : Source) return Target
+ with Convention => Intrinsic;
+ pragma Pure(Ada.Unchecked_Conversion);
+
+3.a/3
+ Reason: {AI05-0229-1AI05-0229-1} The aspect Convention implies
+ that the attribute Access is not allowed for instances of
+ Unchecked_Conversion.
+
+ _Dynamic Semantics_
+
+4
+The size of the formal parameter S in an instance of
+Unchecked_Conversion is that of its subtype. [This is the actual
+subtype passed to Source, except when the actual is an unconstrained
+composite subtype, in which case the subtype is constrained by the
+bounds or discriminants of the value of the actual expression passed to
+S.]
+
+5
+If all of the following are true, the effect of an unchecked conversion
+is to return the value of an object of the target subtype whose
+representation is the same as that of the source object S:
+
+6
+ * S'Size = Target'Size.
+
+6.a
+ Ramification: Note that there is no requirement that the Sizes
+ be known at compile time.
+
+7/3
+ * {AI05-0078-1AI05-0078-1} S'Alignment is a multiple of
+ Target'Alignment or Target'Alignment is zero.
+
+8
+ * The target subtype is not an unconstrained composite subtype.
+
+9
+ * S and the target subtype both have a contiguous representation.
+
+10
+ * The representation of S is a representation of an object of the
+ target subtype.
+
+11/2
+{AI95-00426-01AI95-00426-01} Otherwise, if the result type is scalar,
+the result of the function is implementation defined, and can have an
+invalid representation (see *note 13.9.1::). If the result type is
+nonscalar, the effect is implementation defined; in particular, the
+result can be abnormal (see *note 13.9.1::).
+
+11.a.1/2
+ Implementation defined: The result of unchecked conversion for
+ instances with scalar result types whose result is not defined
+ by the language.
+
+11.a/2
+ Implementation defined: The effect of unchecked conversion for
+ instances with nonscalar result types whose effect is not
+ defined by the language.
+
+11.a.1/2
+ Reason: {AI95-00426-01AI95-00426-01} Note the difference
+ between these sentences; the first only says that the bits
+ returned are implementation defined, while the latter allows
+ any effect. The difference is because scalar objects should
+ never be abnormal unless their assignment was disrupted or if
+ they are a subcomponent of an abnormal composite object.
+ Neither exception applies to instances of
+ Unchecked_Conversion.
+
+11.a.2/2
+ Ramification: {AI95-00426-01AI95-00426-01} Whenever unchecked
+ conversions are used, it is the programmer's responsibility to
+ ensure that these conversions maintain the properties that are
+ guaranteed by the language for objects of the target type.
+ For nonscalar types, this requires the user to understand the
+ underlying run-time model of the implementation. The
+ execution of a program that violates these properties by means
+ of unchecked conversions returning a nonscalar type is
+ erroneous. Properties of scalar types can be checked by using
+ the Valid attribute (see *note 13.9.2::); programs can avoid
+ violating properties of the type (and erroneous execution) by
+ careful use of this attribute.
+
+11.b
+ An instance of Unchecked_Conversion can be applied to an
+ object of a private type, assuming the implementation allows
+ it.
+
+ _Implementation Permissions_
+
+12
+An implementation may return the result of an unchecked conversion by
+reference, if the Source type is not a by-copy type. [In this case, the
+result of the unchecked conversion represents simply a different
+(read-only) view of the operand of the conversion.]
+
+12.a
+ Ramification: In other words, the result object of a call on
+ an instance of Unchecked_Conversion can occupy the same
+ storage as the formal parameter S.
+
+13
+An implementation may place restrictions on Unchecked_Conversion.
+
+13.a
+ Ramification: For example, an instantiation of
+ Unchecked_Conversion for types for which unchecked conversion
+ doesn't make sense may be disallowed.
+
+ _Implementation Advice_
+
+14/2
+{AI95-00051-02AI95-00051-02} Since the Size of an array object generally
+does not include its bounds, the bounds should not be part of the
+converted data.
+
+14.a.1/2
+ Implementation Advice: Since the Size of an array object
+ generally does not include its bounds, the bounds should not
+ be part of the converted data in an instance of
+ Unchecked_Conversion.
+
+14.a
+ Ramification: On the other hand, we have no advice to offer
+ about discriminants and tag fields.
+
+15
+The implementation should not generate unnecessary run-time checks to
+ensure that the representation of S is a representation of the target
+type. It should take advantage of the permission to return by reference
+when possible. Restrictions on unchecked conversions should be avoided
+unless required by the target environment.
+
+15.a.1/2
+ Implementation Advice: There should not be unnecessary
+ run-time checks on the result of an Unchecked_Conversion; the
+ result should be returned by reference when possible.
+ Restrictions on Unchecked_Conversions should be avoided.
+
+15.a
+ Implementation Note: As an example of an unnecessary run-time
+ check, consider a record type with gaps between components.
+ The compiler might assume that such gaps are always zero bits.
+ If a value is produced that does not obey that assumption,
+ then the program might misbehave. The implementation should
+ not generate extra code to check for zero bits (except,
+ perhaps, in a special error-checking mode).
+
+16
+The recommended level of support for unchecked conversions is:
+
+17/3
+ * {AI05-0299-1AI05-0299-1} Unchecked conversions should be supported
+ and should be reversible in the cases where this subclause defines
+ the result. To enable meaningful use of unchecked conversion, a
+ contiguous representation should be used for elementary subtypes,
+ for statically constrained array subtypes whose component subtype
+ is one of the subtypes described in this paragraph, and for record
+ subtypes without discriminants whose component subtypes are
+ described in this paragraph.
+
+17.a/2
+ Implementation Advice: The recommended level of support for
+ Unchecked_Conversion should be followed.
+
+ _Wording Changes from Ada 95_
+
+17.b/2
+ {AI95-00051-02AI95-00051-02} The implementation advice about
+ the size of array objects was moved to 13.3 so that all of the
+ advice about Size is in one place.
+
+17.c/2
+ {AI95-00426-01AI95-00426-01} Clarified that the result of
+ Unchecked_Conversion for scalar types can be invalid, but not
+ abnormal.
+
+ _Wording Changes from Ada 2005_
+
+17.d/3
+ {AI05-0078-1AI05-0078-1} Correction: Relaxed the alignment
+ requirement slightly, giving a defined result in more cases.
+
+* Menu:
+
+* 13.9.1 :: Data Validity
+* 13.9.2 :: The Valid Attribute
+
+\1f
+File: aarm2012.info, Node: 13.9.1, Next: 13.9.2, Up: 13.9
+
+13.9.1 Data Validity
+--------------------
+
+1
+Certain actions that can potentially lead to erroneous execution are not
+directly erroneous, but instead can cause objects to become abnormal.
+Subsequent uses of abnormal objects can be erroneous.
+
+2
+A scalar object can have an invalid representation, which means that the
+object's representation does not represent any value of the object's
+subtype. The primary cause of invalid representations is uninitialized
+variables.
+
+3
+Abnormal objects and invalid representations are explained in this
+subclause.
+
+ _Dynamic Semantics_
+
+4
+When an object is first created, and any explicit or default
+initializations have been performed, the object and all of its parts are
+in the normal state. Subsequent operations generally leave them normal.
+However, an object or part of an object can become abnormal in the
+following ways:
+
+5
+ * An assignment to the object is disrupted due to an abort (see *note
+ 9.8::) or due to the failure of a language-defined check (see *note
+ 11.6::).
+
+6/2
+ * {AI95-00426-01AI95-00426-01} The object is not scalar, and is
+ passed to an in out or out parameter of an imported procedure, the
+ Read procedure of an instance of Sequential_IO, Direct_IO, or
+ Storage_IO, or the stream attribute T'Read, if after return from
+ the procedure the representation of the parameter does not
+ represent a value of the parameter's subtype.
+
+6.1/2
+ * {AI95-00426-01AI95-00426-01} The object is the return object of a
+ function call of a nonscalar type, and the function is an imported
+ function, an instance of Unchecked_Conversion, or the stream
+ attribute T'Input, if after return from the function the
+ representation of the return object does not represent a value of
+ the function's subtype.
+
+6.a/2
+ Discussion: We explicitly list the routines involved in order
+ to avoid future arguments. All possibilities are listed.
+
+6.b/2
+ We did not include Stream_IO.Read in the list above. A
+ Stream_Element should include all possible bit patterns, and
+ thus it cannot be invalid. Therefore, the parameter will
+ always represent a value of its subtype. By omitting this
+ routine, we make it possible to write arbitrary I/O operations
+ without any possibility of abnormal objects.
+
+6.2/2
+{AI95-00426-01AI95-00426-01} [For an imported object, it is the
+programmer's responsibility to ensure that the object remains in a
+normal state.]
+
+6.c/2
+ Proof: This follows (and echos) the standard rule of
+ interfacing; the programmer must ensure that Ada semantics are
+ followed (see *note B.1::).
+
+7
+Whether or not an object actually becomes abnormal in these cases is not
+specified. An abnormal object becomes normal again upon successful
+completion of an assignment to the object as a whole.
+
+ _Erroneous Execution_
+
+8
+It is erroneous to evaluate a primary that is a name denoting an
+abnormal object, or to evaluate a prefix that denotes an abnormal
+object.
+
+8.a/2
+ This paragraph was deleted.{AI95-00114-01AI95-00114-01}
+
+8.b
+ Ramification: The in out or out parameter case does not apply
+ to scalars; bad scalars are merely invalid representations,
+ rather than abnormal, in this case.
+
+8.c/2
+ Reason: {AI95-00114-01AI95-00114-01} The reason we allow
+ access objects, and objects containing subcomponents of an
+ access type, to become abnormal is because the correctness of
+ an access value cannot necessarily be determined merely by
+ looking at the bits of the object. The reason we allow scalar
+ objects to become abnormal is that we wish to allow the
+ compiler to optimize assuming that the value of a scalar
+ object belongs to the object's subtype, if the compiler can
+ prove that the object is initialized with a value that belongs
+ to the subtype. The reason we allow composite objects to
+ become abnormal is that such object might be represented with
+ implicit levels of indirection; if those are corrupted, then
+ even assigning into a component of the object, or simply
+ asking for its Address, might have an unpredictable effect.
+ The same is true if the discriminants have been destroyed.
+
+ _Bounded (Run-Time) Errors_
+
+9
+If the representation of a scalar object does not represent a value of
+the object's subtype (perhaps because the object was not initialized),
+the object is said to have an invalid representation. It is a bounded
+error to evaluate the value of such an object. If the error is
+detected, either Constraint_Error or Program_Error is raised.
+Otherwise, execution continues using the invalid representation. The
+rules of the language outside this subclause assume that all objects
+have valid representations. The semantics of operations on invalid
+representations are as follows:
+
+9.a
+ Discussion: The AARM is more explicit about what happens when
+ the value of the case expression is an invalid representation.
+
+9.b/2
+ Ramification: {AI95-00426-01AI95-00426-01} This includes the
+ result object of functions, including the result of
+ Unchecked_Conversion, T'Input, and imported functions.
+
+10
+ * If the representation of the object represents a value of the
+ object's type, the value of the type is used.
+
+11
+ * If the representation of the object does not represent a value of
+ the object's type, the semantics of operations on such
+ representations is implementation-defined, but does not by itself
+ lead to erroneous or unpredictable execution, or to other objects
+ becoming abnormal.
+
+11.a/2
+ Implementation Note: {AI95-00426-01AI95-00426-01} This means
+ that the implementation must take care not to use an invalid
+ representation in a way that might cause erroneous execution.
+ For instance, the exception mandated for case_statements must
+ be raised. Array indexing must not cause memory outside of
+ the array to be written (and usually, not read either). These
+ cases and similar cases may require explicit checks by the
+ implementation.
+
+ _Erroneous Execution_
+
+12/3
+{AI95-00167-01AI95-00167-01} {AI05-0279-1AI05-0279-1} A call to an
+imported function or an instance of Unchecked_Conversion is erroneous if
+the result is scalar, the result object has an invalid representation,
+and the result is used other than as the expression of an
+assignment_statement or an object_declaration, as the object_name of an
+object_renaming_declaration, or as the prefix of a Valid attribute. If
+such a result object is used as the source of an assignment, and the
+assigned value is an invalid representation for the target of the
+assignment, then any use of the target object prior to a further
+assignment to the target object, other than as the prefix of a Valid
+attribute reference, is erroneous.
+
+12.a/2
+ Ramification: {AI95-00167-01AI95-00167-01} In a typical
+ implementation, every bit pattern that fits in an object of a
+ signed integer subtype will represent a value of the type, if
+ not of the subtype. However, for an enumeration or floating
+ point type, as well as some modular types, there are typically
+ bit patterns that do not represent any value of the type. In
+ such cases, the implementation ought to define the semantics
+ of operations on the invalid representations in the obvious
+ manner (assuming the bounded error is not detected): a given
+ representation should be equal to itself, a representation
+ that is in between the internal codes of two enumeration
+ literals should behave accordingly when passed to comparison
+ operators and membership tests, etc. We considered requiring
+ such sensible behavior, but it resulted in too much arcane
+ verbiage, and since implementations have little incentive to
+ behave irrationally, such verbiage is not important to have.
+
+12.b/2
+ {AI95-00167-01AI95-00167-01} If a stand-alone scalar object is
+ initialized to a an in-range value, then the implementation
+ can take advantage of the fact that the use of any
+ out-of-range value has to be erroneous. Such an out-of-range
+ value can be produced only by things like unchecked
+ conversion, imported functions, and abnormal values caused by
+ disruption of an assignment due to abort or to failure of a
+ language-defined check. This depends on out-of-range values
+ being checked before assignment (that is, checks are not
+ optimized away unless they are proven redundant).
+
+12.c
+ Consider the following example:
+
+12.d/2
+ {AI95-00167-01AI95-00167-01} type My_Int is range 0..99;
+ function Safe_Convert is new Unchecked_Conversion(My_Int, Integer);
+ function Unsafe_Convert is new Unchecked_Conversion(My_Int, Positive);
+ X : Positive := Safe_Convert(0); -- Raises Constraint_Error.
+ Y : Positive := Unsafe_Convert(0); -- Bounded Error, may be invalid.
+ B : Boolean := Y'Valid; -- OK, B = False.
+ Z : Positive := Y+1; -- Erroneous to use Y.
+
+12.e/2
+ {AI95-00167-01AI95-00167-01} {AI95-00426-01AI95-00426-01} The
+ call to Unsafe_Convert is a bounded error, which might raise
+ Constraint_Error, Program_Error, or return an invalid value.
+ Moreover, if an exception is not raised, most uses of that
+ invalid value (including the use of Y) cause erroneous
+ execution. The call to Safe_Convert is not erroneous. The
+ result object is an object of subtype Integer containing the
+ value 0. The assignment to X is required to do a constraint
+ check; the fact that the conversion is unchecked does not
+ obviate the need for subsequent checks required by the
+ language rules.
+
+12.e.1/2
+ {AI95-00167-01AI95-00167-01} {AI95-00426-01AI95-00426-01} The
+ reason for delaying erroneous execution until the object is
+ used is so that the invalid representation can be tested for
+ validity using the Valid attribute (see *note 13.9.2::)
+ without causing execution to become erroneous. Note that this
+ delay does not imply an exception will not be raised; an
+ implementation could treat both conversions in the example in
+ the same way and raise Constraint_Error.
+
+12.e.2/3
+ {AI05-0279-1AI05-0279-1} The rules are defined in terms of the
+ result object, and thus the name used to reference that object
+ is irrelevant. That is why we don't need any special rules to
+ describe what happens when the function result is renamed.
+
+12.f
+ Implementation Note: If an implementation wants to have a
+ "friendly" mode, it might always assign an uninitialized
+ scalar a default initial value that is outside the object's
+ subtype (if there is one), and check for this value on some or
+ all reads of the object, so as to help detect references to
+ uninitialized scalars. Alternatively, an implementation might
+ want to provide an "unsafe" mode where it presumed even
+ uninitialized scalars were always within their subtype.
+
+12.g
+ Ramification: The above rules imply that it is a bounded error
+ to apply a predefined operator to an object with a scalar
+ subcomponent having an invalid representation, since this
+ implies reading the value of each subcomponent. Either
+ Program_Error or Constraint_Error is raised, or some result is
+ produced, which if composite, might have a corresponding
+ scalar subcomponent still with an invalid representation.
+
+12.h
+ Note that it is not an error to assign, convert, or pass as a
+ parameter a composite object with an uninitialized scalar
+ subcomponent. In the other hand, it is a (bounded) error to
+ apply a predefined operator such as =, <, and xor to a
+ composite operand with an invalid scalar subcomponent.
+
+13/3
+{AI05-0054-2AI05-0054-2} The dereference of an access value is erroneous
+if it does not designate an object of an appropriate type or a
+subprogram with an appropriate profile, if it designates a nonexistent
+object, or if it is an access-to-variable value that designates a
+constant object and it did not originate from an attribute_reference
+applied to an aliased variable view of a controlled or immutably limited
+object. [An access value whose dereference is erroneous can exist, for
+example, because of Unchecked_Deallocation, Unchecked_Access, or
+Unchecked_Conversion.]
+
+13.a
+ Ramification: The above mentioned Unchecked_... features are
+ not the only causes of such access values. For example,
+ interfacing to other languages can also cause the problem.
+
+13.b/3
+ {AI05-0054-2AI05-0054-2} We permit the use of
+ access-to-variable values that designate constant objects so
+ long as they originate from an aliased variable view of a
+ controlled or immutably limited constant, such as during the
+ initialization of a constant (both via the "current instance"
+ and during a call to Initialize) or during an assignment
+ (during a call to Adjust).
+
+ NOTES
+
+14
+ 21 Objects can become abnormal due to other kinds of actions that
+ directly update the object's representation; such actions are
+ generally considered directly erroneous, however.
+
+ _Wording Changes from Ada 83_
+
+14.a
+ In order to reduce the amount of erroneousness, we separate
+ the concept of an undefined value into objects with invalid
+ representation (scalars only) and abnormal objects.
+
+14.b
+ Reading an object with an invalid representation is a bounded
+ error rather than erroneous; reading an abnormal object is
+ still erroneous. In fact, the only safe thing to do to an
+ abnormal object is to assign to the object as a whole.
+
+ _Wording Changes from Ada 95_
+
+14.c/2
+ {AI95-00167-01AI95-00167-01} The description of erroneous
+ execution for Unchecked_Conversion and imported objects was
+ tightened up so that using the Valid attribute to test such a
+ value is not erroneous.
+
+14.d/2
+ {AI95-00426-01AI95-00426-01} Clarified the definition of
+ objects that can become abnormal; made sure that all of the
+ possibilities are included.
+
+ _Wording Changes from Ada 2005_
+
+14.e/3
+ {AI05-0054-2AI05-0054-2} Correction: Common programming
+ techniques such as squirreling away an access to a controlled
+ object during initialization and using a self-referencing
+ discriminant (the so-called "Rosen trick") no longer are
+ immediately erroneous if the object is declared constant, so
+ these techniques can be used portably and safely.
+ Practically, these techniques already worked as compilers did
+ not take much advantage of this rule, so the impact of this
+ change will be slight.
+
+14.f/3
+ {AI05-0279-1AI05-0279-1} Correction: The description of
+ erroneous execution for Unchecked_Conversion and imported
+ objects was adjusted to clarify that renaming such an object
+ is not, by itself, erroneous.
+
+\1f
+File: aarm2012.info, Node: 13.9.2, Prev: 13.9.1, Up: 13.9
+
+13.9.2 The Valid Attribute
+--------------------------
+
+1
+The Valid attribute can be used to check the validity of data produced
+by unchecked conversion, input, interface to foreign languages, and the
+like.
+
+ _Static Semantics_
+
+2
+For a prefix X that denotes a scalar object [(after any implicit
+dereference)], the following attribute is defined:
+
+3/3
+X'Valid
+ {AI05-0153-3AI05-0153-3} Yields True if and only if the
+ object denoted by X is normal, has a valid
+ representation, and the predicate of the nominal subtype
+ of X evaluates to True. The value of this attribute is
+ of the predefined type Boolean.
+
+3.a
+ Ramification: Having checked that X'Valid is True, it is safe
+ to read the value of X without fear of erroneous execution
+ caused by abnormality, or a bounded error caused by an invalid
+ representation. Such a read will produce a value in the
+ subtype of X.
+
+ NOTES
+
+4
+ 22 Invalid data can be created in the following cases (not
+ counting erroneous or unpredictable execution):
+
+5
+ * an uninitialized scalar object,
+
+6
+ * the result of an unchecked conversion,
+
+7
+ * input,
+
+8
+ * interface to another language (including machine code),
+
+9
+ * aborting an assignment,
+
+10
+ * disrupting an assignment due to the failure of a
+ language-defined check (see *note 11.6::), and
+
+11
+ * use of an object whose Address has been specified.
+
+12
+ 23 X'Valid is not considered to be a read of X; hence, it is not
+ an error to check the validity of invalid data.
+
+13/2
+ 24 {AI95-00426-01AI95-00426-01} The Valid attribute may be used to
+ check the result of calling an instance of Unchecked_Conversion (or
+ any other operation that can return invalid values). However, an
+ exception handler should also be provided because implementations
+ are permitted to raise Constraint_Error or Program_Error if they
+ detect the use of an invalid representation (see *note 13.9.1::).
+
+13.a
+ Ramification: If X is of an enumeration type with a
+ representation clause, then X'Valid checks that the value of X
+ when viewed as an integer is one of the specified internal
+ codes.
+
+13.b
+ Reason: Valid is defined only for scalar objects because the
+ implementation and description burden would be too high for
+ other types. For example, given a typical run-time model, it
+ is impossible to check the validity of an access value. The
+ same applies to composite types implemented with internal
+ pointers. One can check the validity of a composite object by
+ checking the validity of each of its scalar subcomponents.
+ The user should ensure that any composite types that need to
+ be checked for validity are represented in a way that does not
+ involve implementation-defined components, or gaps between
+ components. Furthermore, such types should not contain access
+ subcomponents.
+
+13.c/2
+ This paragraph was deleted.{AI95-00114-01AI95-00114-01}
+
+ _Extensions to Ada 83_
+
+13.d
+ X'Valid is new in Ada 95.
+
+ _Wording Changes from Ada 95_
+
+13.e/2
+ {AI95-00426-01AI95-00426-01} Added a note explaining that
+ handlers for Constraint_Error and Program_Error are needed in
+ the general case of testing for validity. (An implementation
+ could document cases where these are not necessary, but there
+ is no language requirement.)
+
+ _Wording Changes from Ada 2005_
+
+13.f/3
+ {AI05-0153-3AI05-0153-3} The validity check now also includes
+ a check of the predicate aspects (see *note 3.2.4::), if any,
+ of the subtype of the object.
+
+\1f
+File: aarm2012.info, Node: 13.10, Next: 13.11, Prev: 13.9, Up: 13
+
+13.10 Unchecked Access Value Creation
+=====================================
+
+1
+[The attribute Unchecked_Access is used to create access values in an
+unsafe manner -- the programmer is responsible for preventing "dangling
+references."]
+
+ _Static Semantics_
+
+2
+The following attribute is defined for a prefix X that denotes an
+aliased view of an object:
+
+3
+X'Unchecked_Access
+ All rules and semantics that apply to X'Access (see *note
+ 3.10.2::) apply also to X'Unchecked_Access, except that,
+ for the purposes of accessibility rules and checks, it is
+ as if X were declared immediately within a library
+ package.
+
+3.a/3
+ Ramification: {AI05-0005-1AI05-0005-1} We say "rules and
+ semantics" here so that library-level accessibility applies to
+ the value created by X'Unchecked_Access as well as to the
+ checks needed for the attribute itself. This means that any
+ anonymous access values that inherit the accessibility of this
+ attribute (such as access parameters) also act as if they have
+ library-level accessibility. We don't want the "real"
+ accessibility of the created value re-emerging at a later
+ point - that would create hard-to-understand bugs.
+
+ NOTES
+
+4
+ 25 This attribute is provided to support the situation where a
+ local object is to be inserted into a global linked data structure,
+ when the programmer knows that it will always be removed from the
+ data structure prior to exiting the object's scope. The Access
+ attribute would be illegal in this case (see *note 3.10.2::, "*note
+ 3.10.2:: Operations of Access Types").
+
+4.a
+ Ramification: The expected type for X'Unchecked_Access is as
+ for X'Access.
+
+4.b
+ If an attribute_reference with Unchecked_Access is used as the
+ actual parameter for an access parameter, an
+ Accessibility_Check can never fail on that access parameter.
+
+5
+ 26 There is no Unchecked_Access attribute for subprograms.
+
+5.a/2
+ Reason: {AI95-00254-01AI95-00254-01} Such an attribute would
+ allow unsafe "downward closures", where an access value
+ designating a more nested subprogram is passed to a less
+ nested subprogram. (Anonymous access-to-subprogram parameters
+ provide safe "downward closures".) This requires some means
+ of reconstructing the global environment for the more nested
+ subprogram, so that it can do up-level references to objects.
+ The two methods of implementing up-level references are
+ displays and static links. If unsafe downward closures were
+ supported, each access-to-subprogram value would have to carry
+ the static link or display with it. We don't want to require
+ the space and time overhead of requiring the extra information
+ for all access-to-subprogram types, especially as including it
+ would make interfacing to other languages (like C) harder.
+
+5.b
+ If desired, an instance of Unchecked_Conversion can be used to
+ create an access value of a global access-to-subprogram type
+ that designates a local subprogram. The semantics of using
+ such a value are not specified by the language. In
+ particular, it is not specified what happens if such
+ subprograms make up-level references; even if the frame being
+ referenced still exists, the up-level reference might go awry
+ if the representation of a value of a global
+ access-to-subprogram type doesn't include a static link.
+
+\1f
+File: aarm2012.info, Node: 13.11, Next: 13.12, Prev: 13.10, Up: 13
+
+13.11 Storage Management
+========================
+
+1
+[ Each access-to-object type has an associated storage pool. The
+storage allocated by an allocator comes from the pool; instances of
+Unchecked_Deallocation return storage to the pool. Several access types
+can share the same pool.]
+
+2/2
+{AI95-00435-01AI95-00435-01} [A storage pool is a variable of a type in
+the class rooted at Root_Storage_Pool, which is an abstract limited
+controlled type. By default, the implementation chooses a standard
+storage pool for each access-to-object type. The user may define new
+pool types, and may override the choice of pool for an access-to-object
+type by specifying Storage_Pool for the type.]
+
+2.a
+ Ramification: By default, the implementation might choose to
+ have a single global storage pool, which is used (by default)
+ by all access types, which might mean that storage is
+ reclaimed automatically only upon partition completion.
+ Alternatively, it might choose to create a new pool at each
+ accessibility level, which might mean that storage is
+ reclaimed for an access type when leaving the appropriate
+ scope. Other schemes are possible.
+
+2.a.1/3
+ Glossary entry: Each access-to-object type has an associated
+ storage pool object. The storage for an object created by an
+ allocator comes from the storage pool of the type of the
+ allocator. Some storage pools may be partitioned into
+ subpools in order to support finer-grained storage management.
+
+ _Legality Rules_
+
+3
+If Storage_Pool is specified for a given access type, Storage_Size shall
+not be specified for it.
+
+3.a
+ Reason: The Storage_Pool determines the Storage_Size; hence it
+ would not make sense to specify both. Note that this rule is
+ simplified by the fact that the aspects in question cannot be
+ specified for derived types, nor for nonfirst subtypes, so we
+ don't have to worry about whether, say, Storage_Pool on a
+ derived type overrides Storage_Size on the parent type. For
+ the same reason, "specified" means the same thing as "directly
+ specified" here.
+
+ _Static Semantics_
+
+4
+The following language-defined library package exists:
+
+5
+ with Ada.Finalization;
+ with System.Storage_Elements;
+ package System.Storage_Pools is
+ pragma Preelaborate(System.Storage_Pools);
+
+6/2
+ {AI95-00161-01AI95-00161-01} type Root_Storage_Pool is
+ abstract new Ada.Finalization.Limited_Controlled with private;
+ pragma Preelaborable_Initialization(Root_Storage_Pool);
+
+7
+ procedure Allocate(
+ Pool : in out Root_Storage_Pool;
+ Storage_Address : out Address;
+ Size_In_Storage_Elements : in Storage_Elements.Storage_Count;
+ Alignment : in Storage_Elements.Storage_Count) is abstract;
+
+8
+ procedure Deallocate(
+ Pool : in out Root_Storage_Pool;
+ Storage_Address : in Address;
+ Size_In_Storage_Elements : in Storage_Elements.Storage_Count;
+ Alignment : in Storage_Elements.Storage_Count) is abstract;
+
+9
+ function Storage_Size(Pool : Root_Storage_Pool)
+ return Storage_Elements.Storage_Count is abstract;
+
+10
+ private
+ ... -- not specified by the language
+ end System.Storage_Pools;
+
+10.a
+ Reason: The Alignment parameter is provided to Deallocate
+ because some allocation strategies require it. If it is not
+ needed, it can be ignored.
+
+11
+A storage pool type (or pool type) is a descendant of Root_Storage_Pool.
+The elements of a storage pool are the objects allocated in the pool by
+allocators.
+
+11.a
+ Discussion: In most cases, an element corresponds to a single
+ memory block allocated by Allocate. However, in some cases
+ the implementation may choose to associate more than one
+ memory block with a given pool element.
+
+12/2
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+{AI95-00435-01AI95-00435-01} For every access-to-object subtype S, the
+following representation attributes are defined:
+
+13
+S'Storage_Pool
+ Denotes the storage pool of the type of S. The type of
+ this attribute is Root_Storage_Pool'Class.
+
+14
+S'Storage_Size
+ Yields the result of calling
+ Storage_Size(S'Storage_Pool)[, which is intended to be a
+ measure of the number of storage elements reserved for
+ the pool.] The type of this attribute is
+ universal_integer.
+
+14.a
+ Ramification: Storage_Size is also defined for task subtypes
+ and objects -- see *note 13.3::.
+
+14.b
+ Storage_Size is not a measure of how much un-allocated space
+ is left in the pool. That is, it includes both allocated and
+ unallocated space. Implementations and users may provide a
+ Storage_Available function for their pools, if so desired.
+
+15
+Storage_Size or Storage_Pool may be specified for a nonderived
+access-to-object type via an attribute_definition_clause (*note 13.3:
+S0309.); the name in a Storage_Pool clause shall denote a variable.
+
+15.a/3
+ Aspect Description for Storage_Pool: Pool of memory from which
+ new will allocate for a given access type.
+
+15.b/3
+ Aspect Description for Storage_Size (access): Sets memory size
+ for allocations for an access type.
+
+16/3
+{AI05-0107-1AI05-0107-1} {AI05-0111-3AI05-0111-3}
+{AI05-0116-1AI05-0116-1} An allocator of a type T that does not support
+subpools allocates storage from T's storage pool. If the storage pool
+is a user-defined object, then the storage is allocated by calling
+Allocate as described below. Allocators for types that support subpools
+are described in *note 13.11.4::.
+
+16.a
+ Ramification: If the implementation chooses to represent the
+ designated subtype in multiple pieces, one allocator
+ evaluation might result in more than one call upon Allocate.
+ In any case, allocators for the access type obtain all the
+ required storage for an object of the designated type by
+ calling the specified Allocate procedure.
+
+16.b/3
+ This paragraph was deleted.{AI05-0107-1AI05-0107-1}
+
+16.b.1/1
+ {8652/01118652/0111} {AI95-00103-01AI95-00103-01} If D (the
+ designated type of T) includes subcomponents of other access
+ types, they will be allocated from the storage pools for those
+ types, even if those allocators are executed as part of the
+ allocator of T (as part of the initialization of the object).
+ For instance, an access-to-task type TT may allocate the data
+ structures used to implement the task value from other storage
+ pools. (In particular, the task stack does not necessarily
+ need to be allocated from the storage pool for TT.)
+
+17
+If Storage_Pool is not specified for a type defined by an
+access_to_object_definition, then the implementation chooses a standard
+storage pool for it in an implementation-defined manner. In this case,
+the exception Storage_Error is raised by an allocator if there is not
+enough storage. It is implementation defined whether or not the
+implementation provides user-accessible names for the standard pool
+type(s).
+
+17.a/2
+ This paragraph was deleted.
+
+17.a.1/2
+ Discussion: The manner of choosing a storage pool is covered
+ by a Documentation Requirement below, so it is not summarized
+ here.
+
+17.b
+ Implementation defined: Whether or not the implementation
+ provides user-accessible names for the standard pool type(s).
+
+17.c/2
+ Ramification: {AI95-00230-01AI95-00230-01} An access-to-object
+ type defined by a derived_type_definition inherits its pool
+ from its parent type, so all access-to-object types in the
+ same derivation class share the same pool. Hence the "defined
+ by an access_to_object_definition" wording above.
+
+17.d
+ There is no requirement that all storage pools be implemented
+ using a contiguous block of memory (although each allocation
+ returns a pointer to a contiguous block of memory).
+
+18
+If Storage_Size is specified for an access type, then the Storage_Size
+of this pool is at least that requested, and the storage for the pool is
+reclaimed when the master containing the declaration of the access type
+is left. If the implementation cannot satisfy the request,
+Storage_Error is raised at the point of the attribute_definition_clause
+(*note 13.3: S0309.). If neither Storage_Pool nor Storage_Size are
+specified, then the meaning of Storage_Size is implementation defined.
+
+18.a/2
+ Implementation defined: The meaning of Storage_Size when
+ neither the Storage_Size nor the Storage_Pool is specified for
+ an access type.
+
+18.b
+ Ramification: The Storage_Size function and attribute will
+ return the actual size, rather than the requested size.
+ Comments about rounding up, zero, and negative on task
+ Storage_Size apply here, as well. See also AI83-00557,
+ AI83-00558, and AI83-00608.
+
+18.c
+ The expression in a Storage_Size clause need not be static.
+
+18.d
+ The reclamation happens after the master is finalized.
+
+18.e
+ Implementation Note: For a pool allocated on the stack, normal
+ stack cut-back can accomplish the reclamation. For a
+ library-level pool, normal partition termination actions can
+ accomplish the reclamation.
+
+19
+If Storage_Pool is specified for an access type, then the specified pool
+is used.
+
+20
+The effect of calling Allocate and Deallocate for a standard storage
+pool directly (rather than implicitly via an allocator or an instance of
+Unchecked_Deallocation) is unspecified.
+
+20.a
+ Ramification: For example, an allocator might put the pool
+ element on a finalization list. If the user directly
+ Deallocates it, instead of calling an instance of
+ Unchecked_Deallocation, then the implementation would probably
+ try to finalize the object upon master completion, which would
+ be bad news. Therefore, the implementation should define such
+ situations as erroneous.
+
+ _Erroneous Execution_
+
+21
+If Storage_Pool is specified for an access type, then if Allocate can
+satisfy the request, it should allocate a contiguous block of memory,
+and return the address of the first storage element in Storage_Address.
+The block should contain Size_In_Storage_Elements storage elements, and
+should be aligned according to Alignment. The allocated storage should
+not be used for any other purpose while the pool element remains in
+existence. If the request cannot be satisfied, then Allocate should
+propagate an exception [(such as Storage_Error)]. If Allocate behaves
+in any other manner, then the program execution is erroneous.
+
+ _Implementation Requirements_
+
+21.1/3
+{AI05-0107-1AI05-0107-1} {AI05-0262-1AI05-0262-1} The Allocate procedure
+of a user-defined storage pool object P may be called by the
+implementation only to allocate storage for a type T whose pool is P,
+only at the following points:
+
+21.2/3
+ * During the execution of an allocator of type T;
+
+21.a/3
+ Ramification: This includes during the evaluation of the
+ initializing expression such as an aggregate; this is
+ important if the initializing expression is built in place.
+ We need to allow allocation to be deferred until the size of
+ the object is known.
+
+21.3/3
+ * During the execution of a return statement for a function whose
+ result is built-in-place in the result of an allocator of type T;
+
+21.b/3
+ Reason: We need this bullet as well as the preceding one in
+ order that exceptions that propagate from such a call to
+ Allocate can be handled within the return statement. We don't
+ want to require the generation of special handling code in
+ this unusual case, as it would add overhead to most return
+ statements of composite types.
+
+21.4/3
+ * During the execution of an assignment operation with a target of an
+ allocated object of type T with a part that has an unconstrained
+ discriminated subtype with defaults.
+
+21.c/3
+ Reason: We allow Allocate to be called during assignment of
+ objects with mutable parts so that mutable objects can be
+ implemented with reallocation on assignment. (Unfortunately,
+ the term "mutable" is only defined in the AARM, so we have to
+ use the long-winded wording shown here.)
+
+21.d/3
+ Discussion: Of course, explicit calls to Allocate are also
+ allowed and are not bound by any of the rules found here.
+
+21.5/3
+{AI05-0107-1AI05-0107-1} {AI05-0116-1AI05-0116-1}
+{AI05-0193-1AI05-0193-1} {AI05-0262-1AI05-0262-1}
+{AI05-0269-1AI05-0269-1} For each of the calls of Allocate described
+above, P (equivalent to T'Storage_Pool) is passed as the Pool parameter.
+The Size_In_Storage_Elements parameter indicates the number of storage
+elements to be allocated, and is no more than
+D'Max_Size_In_Storage_Elements, where D is the designated subtype of T.
+The Alignment parameter is a nonzero integral multiple of D'Alignment if
+D is a specific type, and otherwise is a nonzero integral multiple of
+the alignment of the specific type identified by the tag of the object
+being created; it is unspecified if there is no such value. The
+Alignment parameter is no more than D'Max_Alignment_For_Allocation. The
+result returned in the Storage_Address parameter is used as the address
+of the allocated storage, which is a contiguous block of memory of
+Size_In_Storage_Elements storage elements. [Any exception propagated by
+Allocate is propagated by the construct that contained the call.]
+
+21.e/3
+ Ramification: Note that the implementation does not turn other
+ exceptions into Storage_Error.
+
+21.f/3
+ "Nonzero integral multiple" of an alignment includes the
+ alignment value itself, of course. The value is unspecified
+ if the alignment of the specific type is zero.
+
+21.6/3
+{AI05-0107-1AI05-0107-1} The number of calls to Allocate needed to
+implement an allocator for any particular type is unspecified. The
+number of calls to Deallocate needed to implement an instance of
+Unchecked_Deallocation (see *note 13.11.2::) for any particular object
+is the same as the number of Allocate calls for that object.
+
+21.g/3
+ Reason: This supports objects that are allocated in one or
+ more parts. The second sentence prevents extra or missing
+ calls to Deallocate.
+
+21.h/3
+ To be honest: {AI05-0005-1AI05-0005-1} The number of calls to
+ Deallocate from all sources for an object always will be the
+ same as the number of calls to Allocate from all sources for
+ that object. However, in unusual cases, not all of those
+ Deallocate calls may be made by an instance of
+ Unchecked_Deallocation. Specifically, in the unusual case of
+ assigning to an object of a mutable variant record type such
+ that the variant changes, some of the Deallocate calls may be
+ made by the assignment (as may some of the Allocate calls).
+
+21.i/3
+ Ramification: We do not define the relative order of multiple
+ calls used to deallocate the same object -- that is, if the
+ allocator allocated two pieces x and y, then an instance of
+ Unchecked_Deallocation might deallocate x and then y, or it
+ might deallocate y and then x.
+
+21.7/3
+{AI05-0107-1AI05-0107-1} The Deallocate procedure of a user-defined
+storage pool object P may be called by the implementation to deallocate
+storage for a type T whose pool is P only at the places when an Allocate
+call is allowed for P, during the execution of an instance of
+Unchecked_Deallocation for T, or as part of the finalization of the
+collection of T. For such a call of Deallocate, P (equivalent to
+T'Storage_Pool) is passed as the Pool parameter. The value of the
+Storage_Address parameter for a call to Deallocate is the value returned
+in the Storage_Address parameter of the corresponding successful call to
+Allocate. The values of the Size_In_Storage_Elements and Alignment
+parameters are the same values passed to the corresponding Allocate
+call. Any exception propagated by Deallocate is propagated by the
+construct that contained the call.
+
+21.j/3
+ Reason: We allow Deallocate to be called anywhere that
+ Allocate is, in order to allow the recovery of storage from
+ failed allocations (that is, those that raise exceptions);
+ from extended return statements that exit via a goto, exit, or
+ locally handled exception; and from objects that are
+ reallocated when they are assigned. In each of these cases,
+ we would have a storage leak if the implementation did not
+ recover the storage (there is no way for the programmer to do
+ it). We do not require such recovery, however, as it could be
+ a serious performance drag on these operations.
+
+ _Documentation Requirements_
+
+22
+An implementation shall document the set of values that a user-defined
+Allocate procedure needs to accept for the Alignment parameter. An
+implementation shall document how the standard storage pool is chosen,
+and how storage is allocated by standard storage pools.
+
+22.a/2
+ This paragraph was deleted.
+
+22.b/2
+ Documentation Requirement: The set of values that a
+ user-defined Allocate procedure needs to accept for the
+ Alignment parameter. How the standard storage pool is chosen,
+ and how storage is allocated by standard storage pools.
+
+ _Implementation Advice_
+
+23
+An implementation should document any cases in which it dynamically
+allocates heap storage for a purpose other than the evaluation of an
+allocator.
+
+23.a.1/2
+ Implementation Advice: Any cases in which heap storage is
+ dynamically allocated other than as part of the evaluation of
+ an allocator should be documented.
+
+23.a
+ Reason: This is "Implementation Advice" because the term "heap
+ storage" is not formally definable; therefore, it is not
+ testable whether the implementation obeys this advice.
+
+24
+A default (implementation-provided) storage pool for an
+access-to-constant type should not have overhead to support deallocation
+of individual objects.
+
+24.a.1/2
+ Implementation Advice: A default storage pool for an
+ access-to-constant type should not have overhead to support
+ deallocation of individual objects.
+
+24.a
+ Ramification: Unchecked_Deallocation is not defined for such
+ types. If the access-to-constant type is library-level, then
+ no deallocation (other than at partition completion) will ever
+ be necessary, so if the size needed by an allocator of the
+ type is known at link-time, then the allocation should be
+ performed statically. If, in addition, the initial value of
+ the designated object is known at compile time, the object can
+ be allocated to read-only memory.
+
+24.b
+ Implementation Note: If the Storage_Size for an access type is
+ specified, the storage pool should consist of a contiguous
+ block of memory, possibly allocated on the stack. The pool
+ should contain approximately this number of storage elements.
+ These storage elements should be reserved at the place of the
+ Storage_Size clause, so that allocators cannot raise
+ Storage_Error due to running out of pool space until the
+ appropriate number of storage elements has been used up. This
+ approximate (possibly rounded-up) value should be used as a
+ maximum; the implementation should not increase the size of
+ the pool on the fly. If the Storage_Size for an access type
+ is specified as zero, then the pool should not take up any
+ storage space, and any allocator for the type should raise
+ Storage_Error.
+
+24.c
+ Ramification: Note that most of this is approximate, and so
+ cannot be (portably) tested. That's why we make it an
+ Implementation Note. There is no particular number of
+ allocations that is guaranteed to succeed, and there is no
+ particular number of allocations that is guaranteed to fail.
+
+25/2
+{AI95-00230-01AI95-00230-01} The storage pool used for an allocator of
+an anonymous access type should be determined as follows:
+
+25.1/2
+ * {AI95-00230-01AI95-00230-01} {AI95-00416-01AI95-00416-01} If the
+ allocator is defining a coextension (see *note 3.10.2::) of an
+ object being created by an outer allocator, then the storage pool
+ used for the outer allocator should also be used for the
+ coextension;
+
+25.2/2
+ * {AI95-00230-01AI95-00230-01} For other access discriminants and
+ access parameters, the storage pool should be created at the point
+ of the allocator, and be reclaimed when the allocated object
+ becomes inaccessible;
+
+25.3/3
+ * {AI05-0051-1AI05-0051-1} If the allocator defines the result of a
+ function with an access result, the storage pool is determined as
+ though the allocator were in place of the call of the function. If
+ the call is the operand of a type conversion, the storage pool is
+ that of the target access type of the conversion. If the call is
+ itself defining the result of a function with an access result,
+ this rule is applied recursively;
+
+25.4/2
+ * {AI95-00230-01AI95-00230-01} Otherwise, a default storage pool
+ should be created at the point where the anonymous access type is
+ elaborated; such a storage pool need not support deallocation of
+ individual objects.
+
+25.a.1/2
+ Implementation Advice: Usually, a storage pool for an access
+ discriminant or access parameter should be created at the
+ point of an allocator, and be reclaimed when the designated
+ object becomes inaccessible. For other anonymous access
+ types, the pool should be created at the point where the type
+ is elaborated and need not support deallocation of individual
+ objects.
+
+25.a/2
+ Implementation Note: {AI95-00230-01AI95-00230-01} For access
+ parameters and access discriminants, the "storage pool" for an
+ anonymous access type would not normally exist as a separate
+ entity. Instead, the designated object of the allocator would
+ be allocated, in the case of an access parameter, as a local
+ aliased variable at the call site, and in the case of an
+ access discriminant, contiguous with the object containing the
+ discriminant. This is similar to the way storage for
+ aggregates is typically managed.
+
+25.b/2
+ {AI95-00230-01AI95-00230-01} For other sorts of anonymous
+ access types, this implementation is not possible in general,
+ as the accessibility of the anonymous access type is that of
+ its declaration, while the allocator could be more nested. In
+ this case, a "real" storage pool is required. Note, however,
+ that this storage pool need not support (separate)
+ deallocation, as it is not possible to instantiate
+ Unchecked_Deallocation with an anonymous access type. (If
+ deallocation is needed, the object should be allocated for a
+ named access type and converted.) Thus, deallocation only
+ need happen when the anonymous access type itself goes out of
+ scope; this is similar to the case of an access-to-constant
+ type.
+
+ NOTES
+
+26
+ 27 A user-defined storage pool type can be obtained by extending
+ the Root_Storage_Pool type, and overriding the primitive
+ subprograms Allocate, Deallocate, and Storage_Size. A user-defined
+ storage pool can then be obtained by declaring an object of the
+ type extension. The user can override Initialize and Finalize if
+ there is any need for nontrivial initialization and finalization
+ for a user-defined pool type. For example, Finalize might reclaim
+ blocks of storage that are allocated separately from the pool
+ object itself.
+
+27
+ 28 The writer of the user-defined allocation and deallocation
+ procedures, and users of allocators for the associated access type,
+ are responsible for dealing with any interactions with tasking. In
+ particular:
+
+28
+ * If the allocators are used in different tasks, they require
+ mutual exclusion.
+
+29
+ * If they are used inside protected objects, they cannot block.
+
+30
+ * If they are used by interrupt handlers (see *note C.3::,
+ "*note C.3:: Interrupt Support"), the mutual exclusion
+ mechanism has to work properly in that context.
+
+31
+ 29 The primitives Allocate, Deallocate, and Storage_Size are
+ declared as abstract (see *note 3.9.3::), and therefore they have
+ to be overridden when a new (nonabstract) storage pool type is
+ declared.
+
+31.a
+ Ramification: Note that the Storage_Pool attribute denotes an
+ object, rather than a value, which is somewhat unusual for
+ attributes.
+
+31.b
+ The calls to Allocate, Deallocate, and Storage_Size are
+ dispatching calls -- this follows from the fact that the
+ actual parameter for Pool is T'Storage_Pool, which is of type
+ Root_Storage_Pool'Class. In many cases (including all cases
+ in which Storage_Pool is not specified), the compiler can
+ determine the tag statically. However, it is possible to
+ construct cases where it cannot.
+
+31.c
+ All access types in the same derivation class share the same
+ pool, whether implementation defined or user defined. This is
+ necessary because we allow type conversions among them (even
+ if they are pool-specific), and we want pool-specific access
+ values to always designate an element of the right pool.
+
+31.d
+ Implementation Note: If an access type has a standard storage
+ pool, then the implementation doesn't actually have to follow
+ the pool interface described here, since this would be
+ semantically invisible. For example, the allocator could
+ conceivably be implemented with inline code.
+
+ _Examples_
+
+32
+To associate an access type with a storage pool object, the user first
+declares a pool object of some type derived from Root_Storage_Pool.
+Then, the user defines its Storage_Pool attribute, as follows:
+
+33
+ Pool_Object : Some_Storage_Pool_Type;
+
+34
+ type T is access Designated;
+ for T'Storage_Pool use Pool_Object;
+
+35
+Another access type may be added to an existing storage pool, via:
+
+36
+ for T2'Storage_Pool use T'Storage_Pool;
+
+37
+The semantics of this is implementation defined for a standard storage
+pool.
+
+37.a
+ Reason: For example, the implementation is allowed to choose a
+ storage pool for T that takes advantage of the fact that T is
+ of a certain size. If T2 is not of that size, then the above
+ will probably not work.
+
+38/3
+{AI05-0111-3AI05-0111-3} As usual, a derivative of Root_Storage_Pool may
+define additional operations. For example, consider the
+Mark_Release_Pool_Type defined in *note 13.11.6::, that has two
+additional operations, Mark and Release, the following is a possible
+use:
+
+39/3
+ {8652/00418652/0041} {AI95-00066-01AI95-00066-01} {AI05-0111-3AI05-0111-3} type Mark_Release_Pool_Type
+ (Pool_Size : Storage_Elements.Storage_Count)
+ is new Subpools.Root_Storage_Pool_With_Subpools with private;
+ -- As defined in package MR_Pool, see *note 13.11.6::
+
+40
+ ...
+
+41/3
+ {AI05-0111-3AI05-0111-3} Our_Pool : Mark_Release_Pool_Type (Pool_Size => 2000);
+ My_Mark : MR_Pool.Subpool_Handle; -- See *note 13.11.6::
+
+42/3
+ {AI05-0111-3AI05-0111-3} type Acc is access ...;
+ for Acc'Storage_Pool use Our_Pool;
+ ...
+
+43/3
+ {AI05-0111-3AI05-0111-3} My_Mark := Mark(Our_Pool);
+ ... -- Allocate objects using "new (My_Mark) Designated(...)".
+ Release(My_Mark); -- Finalize objects and reclaim storage.
+
+ _Extensions to Ada 83_
+
+43.a
+ User-defined storage pools are new to Ada 95.
+
+ _Wording Changes from Ada 83_
+
+43.b/3
+ {AI05-0005-1AI05-0005-1} {AI05-0190-1AI05-0190-1} Ada 83
+ originally introduced the concept called a "collection," which
+ is similar to what we call a storage pool. All access types
+ in the same derivation class share the same collection. Ada
+ 95 introduces the storage pool, which is similar in that all
+ access types in the same derivation class share the same
+ storage pool, but other (unrelated) access types can also
+ share the same storage pool, either by default, or as
+ specified by the user. A collection is an amorphous grouping
+ of objects (mainly used to describe finalization of access
+ types); a storage pool is a more concrete concept -- hence the
+ different name.
+
+43.c
+ RM83 states the erroneousness of reading or updating
+ deallocated objects incorrectly by missing various cases.
+
+ _Incompatibilities With Ada 95_
+
+43.d/2
+ {AI95-00435-01AI95-00435-01} Amendment Correction: Storage
+ pools (and Storage_Size) are not defined for
+ access-to-subprogram types. The original Ada 95 wording
+ defined the attributes, but said nothing about their values.
+ If a program uses attributes Storage_Pool or Storage_Size on
+ an access-to-subprogram type, it will need to be corrected for
+ Ada 2005. That's a good thing, as such a use is a bug -- the
+ concepts never were defined for such types.
+
+ _Extensions to Ada 95_
+
+43.e/2
+ {AI95-00161-01AI95-00161-01} Amendment Correction: Added
+ pragma Preelaborable_Initialization to type Root_Storage_Pool,
+ so that extensions of it can be used to declare
+ default-initialized objects in preelaborated units.
+
+ _Wording Changes from Ada 95_
+
+43.f/2
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} Corrigendum:
+ Added wording to specify that these are representation
+ attributes.
+
+43.g/2
+ {AI95-00230-01AI95-00230-01} {AI95-00416-01AI95-00416-01}
+ Added wording to clarify that an allocator for a coextension
+ nested inside an outer allocator shares the pool with the
+ outer allocator.
+
+ _Wording Changes from Ada 2005_
+
+43.h/3
+ {AI05-0051-1AI05-0051-1} Correction: Added the missing
+ definition of the storage pool of an allocator for an
+ anonymous access result type.
+
+43.i/3
+ {AI05-0107-1AI05-0107-1} Correction: Clarified when an
+ implementation is allowed to call Allocate and Deallocate, and
+ the requirements on such calls.
+
+43.j/3
+ {AI05-0111-3AI05-0111-3} Added wording to support subpools and
+ refer to the subpool example, see *note 13.11.4::.
+
+43.k/3
+ {AI05-0116-1AI05-0116-1} Correction: Added wording to specify
+ that the alignment for an allocator with a class-wide
+ designated type comes from the specific type that is
+ allocated.
+
+43.l/3
+ {AI05-0193-1AI05-0193-1} Added wording to allow larger
+ alignments for calls to Allocate made by allocators, up to
+ Max_Alignment_For_Allocation. This eases implementation in
+ some cases.
+
+* Menu:
+
+* 13.11.1 :: Storage Allocation Attributes
+* 13.11.2 :: Unchecked Storage Deallocation
+* 13.11.3 :: Default Storage Pools
+* 13.11.4 :: Storage Subpools
+* 13.11.5 :: Subpool Reclamation
+* 13.11.6 :: Storage Subpool Example
+
+\1f
+File: aarm2012.info, Node: 13.11.1, Next: 13.11.2, Up: 13.11
+
+13.11.1 Storage Allocation Attributes
+-------------------------------------
+
+1/3
+{AI05-0193-1AI05-0193-1} [The Max_Size_In_Storage_Elements and
+Max_Alignment_For_Allocation attributes may be useful in writing
+user-defined pool types.]
+
+ _Static Semantics_
+
+2/3
+{AI05-0193-1AI05-0193-1} For every subtype S, the following attributes
+are defined:
+
+3/3
+S'Max_Size_In_Storage_Elements
+ {AI95-00256-01AI95-00256-01} {AI95-00416-01AI95-00416-01}
+ {AI05-0193-1AI05-0193-1} Denotes the maximum value for
+ Size_In_Storage_Elements that could be requested by the
+ implementation via Allocate for an access type whose
+ designated subtype is S. The value of this attribute is
+ of type universal_integer.
+
+3.a
+ Ramification: If S is an unconstrained array subtype, or an
+ unconstrained subtype with discriminants,
+ S'Max_Size_In_Storage_Elements might be very large.
+
+4/3
+S'Max_Alignment_For_Allocation
+ {AI05-0193-1AI05-0193-1} Denotes the maximum value for
+ Alignment that could be requested by the implementation
+ via Allocate for an access type whose designated subtype
+ is S. The value of this attribute is of type
+ universal_integer.
+
+5/3
+{AI05-0193-1AI05-0193-1} For a type with access discriminants, if the
+implementation allocates space for a coextension in the same pool as
+that of the object having the access discriminant, then these attributes
+account for any calls on Allocate that could be performed to provide
+space for such coextensions.
+
+5.a/3
+ Reason: {AI05-0193-1AI05-0193-1} The values of these
+ attributes should reflect only the calls that might be made to
+ the pool specified for an access type with designated type S.
+ Thus, if the coextensions would normally be allocated from a
+ different pool than the one used for the main object (that is,
+ the Implementation Advice of *note 13.11:: for determining the
+ pool of an anonymous access discriminant is not followed),
+ then these attributes should not reflect any calls on Allocate
+ used to allocate the coextensions.
+
+5.b/3
+ Ramification: {AI05-0193-1AI05-0193-1} Coextensions of
+ coextensions of this type (and so on) are included in the
+ values of these attributes if they are allocated from the same
+ pool.
+
+ _Wording Changes from Ada 95_
+
+5.c/2
+ {AI95-00256-01AI95-00256-01} Corrected the wording so that a
+ fortune-telling compiler that can see the future execution of
+ the program is not required.
+
+ _Extensions to Ada 2005_
+
+5.d/3
+ {AI05-0193-1AI05-0193-1} The Max_Alignment_For_Allocation
+ attribute is new.
+
+\1f
+File: aarm2012.info, Node: 13.11.2, Next: 13.11.3, Prev: 13.11.1, Up: 13.11
+
+13.11.2 Unchecked Storage Deallocation
+--------------------------------------
+
+1
+[ Unchecked storage deallocation of an object designated by a value of
+an access type is achieved by a call to an instance of the generic
+procedure Unchecked_Deallocation.]
+
+ _Static Semantics_
+
+2
+The following language-defined generic library procedure exists:
+
+3/3
+ {AI05-0229-1AI05-0229-1} generic
+ type Object(<>) is limited private;
+ type Name is access Object;
+ procedure Ada.Unchecked_Deallocation(X : in out Name)
+ with Convention => Intrinsic;
+ pragma Preelaborate(Ada.Unchecked_Deallocation);
+
+3.a/3
+ Reason: {AI05-0229-1AI05-0229-1} The aspect Convention implies
+ that the attribute Access is not allowed for instances of
+ Unchecked_Deallocation.
+
+ _Legality Rules_
+
+3.1/3
+{AI05-0157-1AI05-0157-1} A call on an instance of Unchecked_Deallocation
+is illegal if the actual access type of the instance is a type for which
+the Storage_Size has been specified by a static expression with value
+zero or is defined by the language to be zero. In addition to the
+places where Legality Rules normally apply (see *note 12.3::), this rule
+applies also in the private part of an instance of a generic unit.
+
+3.b/3
+ Discussion: This rule is the same as the rule for allocators.
+ We could have left the last sentence out, as a call to
+ Unchecked_Deallocation cannot occur in a specification as it
+ is a procedure call, but we left it for consistency and to
+ avoid future maintenance hazards.
+
+ _Dynamic Semantics_
+
+4
+Given an instance of Unchecked_Deallocation declared as follows:
+
+5
+ procedure Free is
+ new Ada.Unchecked_Deallocation(
+ object_subtype_name, access_to_variable_subtype_name);
+
+6
+Procedure Free has the following effect:
+
+7
+ 1. After executing Free(X), the value of X is null.
+
+8
+ 2. Free(X), when X is already equal to null, has no effect.
+
+9/3
+ 3. {AI95-00416-01AI95-00416-01} {AI05-0107-1AI05-0107-1} Free(X),
+ when X is not equal to null first performs finalization of the
+ object designated by X (and any coextensions of the object -- see
+ *note 3.10.2::), as described in *note 7.6.1::. It then
+ deallocates the storage occupied by the object designated by X (and
+ any coextensions). If the storage pool is a user-defined object,
+ then the storage is deallocated by calling Deallocate as described
+ in *note 13.11::. There is one exception: if the object being
+ freed contains tasks, the object might not be deallocated.
+
+9.a/3
+ Ramification: {AI05-0107-1AI05-0107-1} Free calls only the
+ specified Deallocate procedure to do deallocation.
+
+10/2
+{AI95-00416-01AI95-00416-01} After Free(X), the object designated by X,
+and any subcomponents (and coextensions) thereof, no longer exist; their
+storage can be reused for other purposes.
+
+ _Bounded (Run-Time) Errors_
+
+11
+It is a bounded error to free a discriminated, unterminated task object.
+The possible consequences are:
+
+11.a
+ Reason: This is an error because the task might refer to its
+ discriminants, and the discriminants might be deallocated by
+ freeing the task object.
+
+12
+ * No exception is raised.
+
+13
+ * Program_Error or Tasking_Error is raised at the point of the
+ deallocation.
+
+14
+ * Program_Error or Tasking_Error is raised in the task the next time
+ it references any of the discriminants.
+
+14.a
+ Implementation Note: This last case presumes an implementation
+ where the task references its discriminants indirectly, and
+ the pointer is nulled out when the task object is deallocated.
+
+15
+In the first two cases, the storage for the discriminants (and for any
+enclosing object if it is designated by an access discriminant of the
+task) is not reclaimed prior to task termination.
+
+15.a
+ Ramification: The storage might never be reclaimed.
+
+ _Erroneous Execution_
+
+16/3
+{AI05-0033-1AI05-0033-1} {AI05-0262-1AI05-0262-1} Evaluating a name that
+denotes a nonexistent object, or a protected subprogram or subprogram
+renaming whose associated object (if any) is nonexistent, is erroneous.
+The execution of a call to an instance of Unchecked_Deallocation is
+erroneous if the object was created other than by an allocator for an
+access type whose pool is Name'Storage_Pool.
+
+16.a/3
+ Reason: {AI05-0033-1AI05-0033-1} {AI05-0262-1AI05-0262-1} The
+ part about a protected subprogram is intended to cover the
+ case of an access-to-protected-subprogram where the associated
+ object has been deallocated. The part about a subprogram
+ renaming is intended to cover the case of a renaming of a
+ prefixed view where the prefix object has been deallocated, or
+ the case of a renaming of an entry or protected subprogram
+ where the associated task or protected object has been
+ deallocated.
+
+16.b/3
+ Ramification: {AI05-0157-1AI05-0157-1} This text does not
+ cover the case of a name that contains a null access value, as
+ null does not denote an object (rather than denoting a
+ nonexistent object).
+
+ _Implementation Advice_
+
+17
+For a standard storage pool, Free should actually reclaim the storage.
+
+17.a.1/2
+ Implementation Advice: For a standard storage pool, an
+ instance of Unchecked_Deallocation should actually reclaim the
+ storage.
+
+17.a/2
+ Ramification: {AI95-00114-01AI95-00114-01} This is not a
+ testable property, since we do not know how much storage is
+ used by a given pool element, nor whether fragmentation can
+ occur.
+
+17.1/3
+{AI05-0157-1AI05-0157-1} A call on an instance of Unchecked_Deallocation
+with a nonnull access value should raise Program_Error if the actual
+access type of the instance is a type for which the Storage_Size has
+been specified to be zero or is defined by the language to be zero.
+
+17.a.1/3
+ Implementation Advice: A call on an instance of
+ Unchecked_Deallocation with a nonnull access value should
+ raise Program_Error if the actual access type of the instance
+ is a type for which the Storage_Size has been specified to be
+ zero or is defined by the language to be zero.
+
+17.b
+ Discussion: If the call is not illegal (as in a generic body),
+ we recommend that it raise Program_Error. Since the execution
+ of this call is erroneous (any allocator from the pool will
+ have raised Storage_Error, so the nonnull access value must
+ have been allocated from a different pool or be a
+ stack-allocated object), we can't require any behavior --
+ anything at all would be a legitimate implementation.
+
+ NOTES
+
+18
+ 30 The rules here that refer to Free apply to any instance of
+ Unchecked_Deallocation.
+
+19
+ 31 Unchecked_Deallocation cannot be instantiated for an
+ access-to-constant type. This is implied by the rules of *note
+ 12.5.4::.
+
+ _Wording Changes from Ada 95_
+
+19.a/2
+ {AI95-00416-01AI95-00416-01} The rules for coextensions are
+ clarified (mainly by adding that term). In theory, this
+ reflects no change from Ada 95 (coextensions existed in Ada
+ 95, they just didn't have a name).
+
+ _Wording Changes from Ada 2005_
+
+19.b/3
+ {AI05-0033-1AI05-0033-1} Correction: Added a rule that using
+ an access-to-protected-subprogram is erroneous if the
+ associated object no longer exists. It is hard to imagine an
+ alternative meaning here, and this has no effect on correct
+ programs.
+
+19.c/3
+ {AI05-0107-1AI05-0107-1} Correction: Moved the requirements on
+ an implementation-generated call to Deallocate to *note
+ 13.11::, in order to put all of the rules associated with
+ implementation-generated calls to Allocate and Deallocate
+ together.
+
+19.d/3
+ {AI05-0157-1AI05-0157-1} Correction: Added wording so that
+ calling an instance of Unchecked_Deallocation is treated
+ similarly to allocators for access types where allocators
+ would be banned.
+
+\1f
+File: aarm2012.info, Node: 13.11.3, Next: 13.11.4, Prev: 13.11.2, Up: 13.11
+
+13.11.3 Default Storage Pools
+-----------------------------
+
+1/3
+This paragraph was deleted.{AI05-0229-1AI05-0229-1}
+
+ _Syntax_
+
+2/3
+ {AI05-0190-1AI05-0190-1} {AI05-0229-1AI05-0229-1} The form of a
+ pragma Default_Storage_Pool is as follows:
+
+3/3
+ {AI05-0190-1AI05-0190-1} {AI05-0229-1AI05-0229-1} pragma
+ Default_Storage_Pool (storage_pool_indicator);
+
+3.1/3
+ {AI05-0190-1AI05-0190-1} storage_pool_indicator ::= storage_pool_
+ name | null
+
+3.2/3
+ {AI05-0190-1AI05-0190-1} A pragma Default_Storage_Pool is allowed
+ immediately within the visible part of a package_specification,
+ immediately within a declarative_part, or as a configuration
+ pragma.
+
+ _Name Resolution Rules_
+
+3.3/3
+{AI05-0190-1AI05-0190-1} The storage_pool_name is expected to be of type
+Root_Storage_Pool'Class.
+
+ _Legality Rules_
+
+4/3
+{AI05-0190-1AI05-0190-1} {AI05-0229-1AI05-0229-1} The storage_pool_name
+shall denote a variable.
+
+4.1/3
+{AI05-0190-1AI05-0190-1} If the pragma is used as a configuration
+pragma, the storage_pool_indicator shall be null, and it defines the
+default pool to be null within all applicable compilation units (see
+*note 10.1.5::), except within the immediate scope of another pragma
+Default_Storage_Pool. Otherwise, [the pragma occurs immediately within
+a sequence of declarations, and] it defines the default pool within the
+immediate scope of the pragma to be either null or the pool denoted by
+the storage_pool_name, except within the immediate scope of a later
+pragma Default_Storage_Pool. [Thus, an inner pragma overrides an outer
+one.]
+
+4.2/3
+{AI05-0190-1AI05-0190-1} {AI05-0262-1AI05-0262-1} A pragma
+Default_Storage_Pool shall not be used as a configuration pragma that
+applies to a compilation unit that is within the immediate scope of
+another pragma Default_Storage_Pool.
+
+4.a/3
+ Reason: This is to prevent confusion in cases like this:
+
+4.b/3
+ package Parent is
+ pragma Default_Storage_Pool(...);
+ ...
+ end Parent;
+
+4.c/3
+ pragma Default_Storage_Pool(...); -- Illegal!
+ package Parent.Child is
+ ...
+ end Parent.Child;
+
+4.d/3
+ where the Default_Storage_Pool on Parent.Child would not (if
+ it were legal) override the one in Parent.
+
+ _Static Semantics_
+
+5/3
+{AI05-0190-1AI05-0190-1} {AI05-0229-1AI05-0229-1} The language-defined
+aspect Default_Storage_Pool may be specified for a generic instance; it
+defines the default pool for access types within an instance. The
+expected type for the Default_Storage_Pool aspect is
+Root_Storage_Pool'Class. The aspect_definition must be a name that
+denotes a variable. This aspect overrides any Default_Storage_Pool
+pragma that might apply to the generic unit; if the aspect is not
+specified, the default pool of the instance is that defined for the
+generic unit.
+
+5.a/3
+ Aspect Description for Default_Storage_Pool: Default storage
+ pool for a generic instance.
+
+6/3
+{AI05-0190-1AI05-0190-1} {AI05-0229-1AI05-0229-1} For nonderived access
+types declared in places where the default pool is defined by the pragma
+or aspect, their Storage_Pool or Storage_Size attribute is determined as
+follows, unless Storage_Pool or Storage_Size is specified for the type:
+
+6.1/3
+ * {AI05-0190-1AI05-0190-1} If the default pool is null, the
+ Storage_Size attribute is defined by the language to be zero.
+ [Therefore, an allocator for such a type is illegal.]
+
+6.2/3
+ * {AI05-0190-1AI05-0190-1} If the default pool is nonnull, the
+ Storage_Pool attribute is that pool.
+
+6.3/3
+{AI05-0190-1AI05-0190-1} [Otherwise, there is no default pool; the
+standard storage pool is used for the type as described in *note
+13.11::.]
+
+6.a/3
+ Ramification: {AI05-0190-1AI05-0190-1}
+ {AI05-0229-1AI05-0229-1} Default_Storage_Pool is the only way
+ to specify the storage pool for an anonymous access type.
+
+6.b/3
+ {AI05-0190-1AI05-0190-1} {AI05-0229-1AI05-0229-1} Note that
+ coextensions should be allocated in the same pool (or on the
+ stack) as the outer object (see *note 13.11::); the
+ Storage_Pool of the access discriminant (and hence the
+ Default_Storage_Pool) is supposed to be ignored for
+ coextensions. This matches the required finalization point
+ for coextensions.
+
+6.b.1/3
+ {AI05-0190-1AI05-0190-1} The default storage pool for an
+ allocator that occurs within an instance of a generic is
+ defined by the Default_Storage_Pool aspect of the
+ instantiation (if specified), or by the Default_Storage_Pool
+ pragma that applied to the generic; the Default_Storage_Pool
+ pragma that applies to the instantiation is irrelevant.
+
+6.b.2/3
+ {AI05-0190-1AI05-0190-1} It is possible to specify the
+ Default_Storage_Pool aspect for an instantiation such that
+ allocations will fail. For example, the generic unit might be
+ expecting a pool that supports certain sizes and alignments,
+ and the one on the instance might be more restrictive. It is
+ the programmer's responsibility to get this right.
+
+6.b.3/3
+ {AI05-0190-1AI05-0190-1} The semantics of the
+ Default_Storage_Pool aspect are similar to passing a pool
+ object as a generic formal, and putting pragma
+ Default_Storage_Pool at the top of the generic's visible part,
+ specifying that formal.
+
+7/3
+This paragraph was deleted.{AI05-0229-1AI05-0229-1}
+
+ _Implementation Permissions_
+
+8/3
+{AI05-0190-1AI05-0190-1} {AI05-0229-1AI05-0229-1} An object created by
+an allocator that is passed as the actual parameter to an access
+parameter may be allocated on the stack, and automatically reclaimed,
+regardless of the default pool..
+
+8.a/3
+ Discussion: {AI05-0190-1AI05-0190-1} This matches the required
+ finalization point for such an allocated object.
+
+ NOTES
+
+9/3
+ 32 {AI05-0190-1AI05-0190-1} Default_Storage_Pool may be used with
+ restrictions No_Coextensions and No_Access_Parameter_Allocators
+ (see *note H.4::) to ensure that all allocators use the default
+ pool.
+
+ _Wording Changes from Ada 83_
+
+9.a/3
+ This paragraph was deleted.{AI05-0229-1AI05-0229-1}
+
+ _Incompatibilities With Ada 2005_
+
+9.b/3
+ {AI05-0229-1AI05-0229-1} Pragma Controlled has been dropped
+ from Ada, as it has no effect in any known Ada implementations
+ and it seems to promise capabilities not expected in Ada
+ implementations. This is usually not an incompatibility, as
+ the pragma merely becomes unrecognized (with a warning) and
+ can be implemented as an implementation-defined pragma if
+ desired. However, it is incompatible if it is (now)
+ implemented as an implementation-defined pragma, someone used
+ this pragma in a unit, and they also used restriction
+ No_Implementation_Pragmas on that unit. In that case, the
+ pragma would now violate the restriction; but use of this
+ pragma (which does nothing) should be very rare, so this is
+ not a significant issue.
+
+ _Extensions to Ada 2005_
+
+9.c/3
+ {AI05-0190-1AI05-0190-1} The pragma Default_Storage_Pool is
+ new.
+
+ _Wording Changes from Ada 2005_
+
+9.d/3
+ {AI05-0229-1AI05-0229-1} The entire discussion of garbage
+ collection (and especially that of controlled objects) is
+ deleted. Ada 2012 provides subpools (see *note 13.11.4::) for
+ storage management of objects, including controlled objects, a
+ mechanism which is much more predictable than garbage
+ collection. Note that no version of Ada allows early
+ finalization of controlled objects (other than via the use of
+ Unchecked_Deallocation or Unchecked_Deallocate_Subpool), so
+ that garbage collection of such objects would be ineffective
+ in the standard mode anyway.
+
+\1f
+File: aarm2012.info, Node: 13.11.4, Next: 13.11.5, Prev: 13.11.3, Up: 13.11
+
+13.11.4 Storage Subpools
+------------------------
+
+1/3
+{AI05-0111-3AI05-0111-3} This subclause defines a package to support the
+partitioning of a storage pool into subpools. A subpool may be
+specified as the default to be used for allocation from the associated
+storage pool, or a particular subpool may be specified as part of an
+allocator (see *note 4.8::).
+
+ _Static Semantics_
+
+2/3
+{AI05-0111-3AI05-0111-3} The following language-defined library package
+exists:
+
+3/3
+ package System.Storage_Pools.Subpools is
+ pragma Preelaborate (Subpools);
+
+4/3
+ type Root_Storage_Pool_With_Subpools is
+ abstract new Root_Storage_Pool with private;
+
+5/3
+ type Root_Subpool is abstract tagged limited private;
+
+6/3
+ type Subpool_Handle is access all Root_Subpool'Class;
+ for Subpool_Handle'Storage_Size use 0;
+
+7/3
+ function Create_Subpool (Pool : in out Root_Storage_Pool_With_Subpools)
+ return not null Subpool_Handle is abstract;
+
+8/3
+ {AI05-0252-1AI05-0252-1} -- The following operations are intended for pool implementers:
+
+9/3
+ function Pool_of_Subpool (Subpool : not null Subpool_Handle)
+ return access Root_Storage_Pool_With_Subpools'Class;
+
+10/3
+ procedure Set_Pool_of_Subpool (
+ Subpool : in not null Subpool_Handle;
+ To : in out Root_Storage_Pool_With_Subpools'Class);
+
+11/3
+ procedure Allocate_From_Subpool (
+ Pool : in out Root_Storage_Pool_With_Subpools;
+ Storage_Address : out Address;
+ Size_In_Storage_Elements : in Storage_Elements.Storage_Count;
+ Alignment : in Storage_Elements.Storage_Count;
+ Subpool : in not null Subpool_Handle) is abstract
+ with Pre'Class => Pool_of_Subpool(Subpool) = Pool'Access;
+
+12/3
+ procedure Deallocate_Subpool (
+ Pool : in out Root_Storage_Pool_With_Subpools;
+ Subpool : in out Subpool_Handle) is abstract
+ with Pre'Class => Pool_of_Subpool(Subpool) = Pool'Access;
+
+13/3
+ {AI05-0298-1AI05-0298-1} function Default_Subpool_for_Pool (
+ Pool : in out Root_Storage_Pool_With_Subpools)
+ return not null Subpool_Handle;
+
+14/3
+ overriding
+ procedure Allocate (
+ Pool : in out Root_Storage_Pool_With_Subpools;
+ Storage_Address : out Address;
+ Size_In_Storage_Elements : in Storage_Elements.Storage_Count;
+ Alignment : in Storage_Elements.Storage_Count);
+
+15/3
+ overriding
+ procedure Deallocate (
+ Pool : in out Root_Storage_Pool_With_Subpools;
+ Storage_Address : in Address;
+ Size_In_Storage_Elements : in Storage_Elements.Storage_Count;
+ Alignment : in Storage_Elements.Storage_Count) is null;
+
+16/3
+ {AI05-0298-1AI05-0298-1} overriding
+ function Storage_Size (Pool : Root_Storage_Pool_With_Subpools)
+ return Storage_Elements.Storage_Count
+ is (Storage_Elements.Storage_Count'Last);
+
+17/3
+ private
+ ... -- not specified by the language
+ end System.Storage_Pools.Subpools;
+
+18/3
+{AI05-0111-3AI05-0111-3} A subpool is a separately reclaimable portion
+of a storage pool, identified by an object of type Subpool_Handle (a
+subpool handle). A subpool handle also identifies the enclosing storage
+pool, a storage pool that supports subpools, which is a storage pool
+whose type is descended from Root_Storage_Pool_With_Subpools. A subpool
+is created by calling Create_Subpool or a similar constructor; the
+constructor returns the subpool handle.
+
+19/3
+{AI05-0111-3AI05-0111-3} {AI05-0269-1AI05-0269-1} A subpool object is an
+object of a type descended from Root_Subpool. [Typically, subpool
+objects are managed by the containing storage pool; only the handles
+need be exposed to clients of the storage pool. Subpool objects are
+designated by subpool handles, and are the run-time representation of a
+subpool.]
+
+19.a/3
+ Proof: We know that subpool handles designate subpool objects
+ because the declaration of Subpool_Handle says so.
+
+20/3
+{AI05-0111-3AI05-0111-3} Each subpool belongs to a single storage pool
+[(which will always be a pool that supports subpools)]. An access to
+the pool that a subpool belongs to can be obtained by calling
+Pool_of_Subpool with the subpool handle. Set_Pool_of_Subpool causes the
+subpool of the subpool handle to belong to the given pool[; this is
+intended to be called from subpool constructors like Create_Subpool.]
+Set_Pool_of_Subpool propagates Program_Error if the subpool already
+belongs to a pool.
+
+20.a/3
+ Discussion: Pool_of_Subpool and Set_Pool_of_Subpool are
+ provided by the Ada implementation and typically will not be
+ overridden by the pool implementer.
+
+21/3
+{AI05-0111-3AI05-0111-3} When an allocator for a type whose storage pool
+supports subpools is evaluated, a call is made on Allocate_From_Subpool
+passing in a Subpool_Handle, in addition to the parameters as defined
+for calls on Allocate (see *note 13.11::). The subpool designated by
+the subpool_handle_name is used, if specified in an allocator.
+Otherwise, Default_Subpool_for_Pool of the Pool is used to provide a
+subpool handle. All requirements on the Allocate procedure also apply
+to Allocate_from_Subpool.
+
+21.a/3
+ Discussion: Deallocate_Subpool is expected to do whatever is
+ needed to deallocate all of the objects contained in the
+ subpool; it is called from Unchecked_Deallocate_Subpool (see
+ *note 13.11.5::).
+
+21.b/3
+ Typically, the pool implementer will not override Allocate.
+ In the canonical definition of the language, it will never be
+ called for a pool that supports subpools (there is an
+ Implementation Permission below that allows it to be called in
+ certain rare cases).
+
+ _Legality Rules_
+
+22/3
+{AI05-0111-3AI05-0111-3} If a storage pool that supports subpools is
+specified as the Storage_Pool for an access type, the access type is
+called a subpool access type. A subpool access type shall be a
+pool-specific access type.
+
+23/3
+{AI05-0111-3AI05-0111-3} {AI05-0252-1AI05-0252-1} The accessibility
+level of a subpool access type shall not be statically deeper than that
+of the storage pool object. If the specified storage pool object is a
+storage pool that supports subpools, then the name that denotes the
+object shall not denote part of a formal parameter, nor shall it denote
+part of a dereference of a value of a non-library-level general access
+type. In addition to the places where Legality Rules normally apply
+(see *note 12.3::), these rules also apply in the private part of an
+instance of a generic unit.
+
+ _Dynamic Semantics_
+
+24/3
+{AI05-0111-3AI05-0111-3} {AI05-0252-1AI05-0252-1} When an access type
+with a specified storage pool is frozen (see *note 13.14::), if the tag
+of the storage pool object identifies a storage pool that supports
+subpools, the following checks are made:
+
+25/3
+ * the name used to specify the storage pool object does not denote
+ part of a formal parameter nor part of a dereference of a value of
+ a non-library-level general access type; and
+
+26/3
+ * the accessibility level of the access type is not deeper than that
+ of the storage pool object.
+
+27/3
+{AI05-0252-1AI05-0252-1} Program_Error is raised if either of these
+checks fail.
+
+27.a/3
+ Reason: This check (and its static counterpart) ensures that
+ the type of the allocated objects exists at least as long as
+ the storage pool object, so that the subpools are finalized
+ (which finalizes any remaining allocated objects) before the
+ type of the objects ceases to exist. The access type itself
+ (and the associated collection) will cease to exist before the
+ storage pool ceases to exist.
+
+27.b/3
+ We also disallow the use of formal parameters and dereferences
+ of non-library-level general access types when specifying a
+ storage pool object if it supports subpools, because the
+ "apparent" accessibility level is potentially deeper than that
+ of the underlying object. Neither of these cases is very
+ likely to occur in practice.
+
+28/3
+{AI05-0111-3AI05-0111-3} A call to Subpools.Allocate(P, Addr, Size,
+Align) does the following:
+
+29/3
+ Allocate_From_Subpool
+ (Root_Storage_Pool_With_Subpools'Class(P),
+ Addr, Size, Align,
+ Subpool => Default_Subpool_for_Pool
+ (Root_Storage_Pool_With_Subpools'Class(P)));
+
+30/3
+{AI05-0111-3AI05-0111-3} An allocator that allocates in a subpool raises
+Program_Error if the allocated object has task parts.
+
+30.a/3
+ Reason: This is to ease implementation. We envision relaxing
+ this restriction in a future version of Ada, once
+ implementation experience has been gained. At this time, we
+ are unable to come up with a set of rules for task termination
+ that is both useful, and surely feasible to implement.
+
+31/3
+{AI05-0111-3AI05-0111-3} Unless overridden, Default_Subpool_for_Pool
+propagates Program_Error.
+
+ _Implementation Permissions_
+
+32/3
+{AI05-0111-3AI05-0111-3} When an allocator for a type whose storage pool
+is of type Root_Storage_Pool'Class is evaluated, but supports subpools,
+the implementation may call Allocate rather than Allocate_From_Subpool.
+[This will have the same effect, so long as Allocate has not been
+overridden.]
+
+32.a/3
+ Reason: This ensures either of two implementation models are
+ possible for an allocator with no subpool_specification. Note
+ that the "supports subpools" property is not known at compile
+ time for a pool of the class-wide type.
+
+32.b/3
+ * The implementation can dispatch to
+ Storage_Pools.Allocate. If the pool supports subpools,
+ this will call Allocate_From_Subpool with the default
+ subpool so long as Allocate has not been overridden.
+
+32.c/3
+ * The implementation can declare Allocate_From_Subpool as a
+ primitive of Root_Storage_Pool in the private part of
+ Storage_Pools. This means that the Allocate_From_Subpool
+ for Root_Storage_Pool_With_Subpools overrides that
+ private one. The implementation can thus call the
+ private one, which will call Allocate for
+ non-subpool-supporting pools. The effect of this
+ implementation does not change if Allocate is overridden
+ for a pool that supports subpools.
+
+ NOTES
+
+33/3
+ 33 {AI05-0111-3AI05-0111-3} A user-defined storage pool type that
+ supports subpools can be implemented by extending the
+ Root_Storage_Pool_With_Subpools type, and overriding the primitive
+ subprograms Create_Subpool, Allocate_From_Subpool, and
+ Deallocate_Subpool. Create_Subpool should call Set_Pool_Of_Subpool
+ before returning the subpool handle. To make use of such a pool, a
+ user would declare an object of the type extension, use it to
+ define the Storage_Pool attribute of one or more access types, and
+ then call Create_Subpool to obtain subpool handles associated with
+ the pool.
+
+34/3
+ 34 {AI05-0111-3AI05-0111-3} A user-defined storage pool type that
+ supports subpools may define additional subpool constructors
+ similar to Create_Subpool (these typically will have additional
+ parameters).
+
+35/3
+ 35 {AI05-0111-3AI05-0111-3} The pool implementor should override
+ Default_Subpool_For_Pool if the pool is to support a default
+ subpool for the pool. The implementor can override Deallocate if
+ individual object reclamation is to be supported, and can override
+ Storage_Size if there is some limit on the total size of the
+ storage pool. The implementor can override Initialize and Finalize
+ if there is any need for nontrivial initialization and finalization
+ for the pool as a whole. For example, Finalize might reclaim
+ blocks of storage that are allocated over and above the space
+ occupied by the pool object itself. The pool implementor may
+ extend the Root_Subpool type as necessary to carry additional
+ information with each subpool provided by Create_Subpool.
+
+ _Extensions to Ada 2005_
+
+35.a/3
+ {AI05-0111-3AI05-0111-3} {AI05-0252-1AI05-0252-1} Subpools and
+ the package System.Storage_Pools.Subpools are new.
+
+\1f
+File: aarm2012.info, Node: 13.11.5, Next: 13.11.6, Prev: 13.11.4, Up: 13.11
+
+13.11.5 Subpool Reclamation
+---------------------------
+
+1/3
+{AI05-0111-3AI05-0111-3} A subpool may be explicitly deallocated using
+Unchecked_Deallocate_Subpool.
+
+ _Static Semantics_
+
+2/3
+{AI05-0111-3AI05-0111-3} The following language-defined library
+procedure exists:
+
+3/3
+ with System.Storage_Pools.Subpools;
+ procedure Ada.Unchecked_Deallocate_Subpool
+ (Subpool : in out System.Storage_Pools.Subpools.Subpool_Handle);
+
+4/3
+{AI05-0111-3AI05-0111-3} If Subpool is null, a call on
+Unchecked_Deallocate_Subpool has no effect. Otherwise, the subpool is
+finalized, and Subpool is set to null.
+
+5/3
+{AI05-0111-3AI05-0111-3} Finalization of a subpool has the following
+effects:
+
+6/3
+ * The subpool no longer belongs to any pool;
+
+7/3
+ * Any of the objects allocated from the subpool that still exist are
+ finalized in an arbitrary order;
+
+8/3
+ * The following [dispatching] call is then made:
+
+9/3
+ Deallocate_Subpool(Pool_of_Subpool(Subpool).all, Subpool);
+
+10/3
+{AI05-0111-3AI05-0111-3} Finalization of a
+Root_Storage_Pool_With_Subpools object finalizes all subpools that
+belong to that pool that have not yet been finalized.
+
+10.a/3
+ Discussion: There is no need to call Unchecked_Deallocation on
+ an object allocated in a subpool. Such objects are
+ deallocated all at once, when Unchecked_Deallocate_Subpool is
+ called.
+
+10.b/3
+ If Unchecked_Deallocation is called, the object is finalized,
+ and then Deallocate is called on the Pool, which typically
+ will do nothing. If it wants to free memory, it will need
+ some way to get from the address of the object to the subpool.
+
+10.c/3
+ There is no Deallocate_From_Subpool. There is no efficient
+ way for the implementation to determine the subpool for an
+ arbitrary object, and if the pool implementer can determinate
+ that, they can use that as part of the implementation of
+ Deallocate.
+
+10.d/3
+ If Unchecked_Deallocation is not called (the usual case), the
+ object will be finalized when Unchecked_Deallocate_Subpool is
+ called.
+
+10.e/3
+ If that's never called, then the object will be finalized when
+ the Pool_With_Subpools is finalized (by permission -- it might
+ happen when the collection of the access type is finalized).
+
+ _Extensions to Ada 2005_
+
+10.f/3
+ {AI05-0111-3AI05-0111-3} Unchecked_Deallocate_Subpool is new.
+
+\1f
+File: aarm2012.info, Node: 13.11.6, Prev: 13.11.5, Up: 13.11
+
+13.11.6 Storage Subpool Example
+-------------------------------
+
+ _Examples_
+
+1/3
+{AI05-0111-3AI05-0111-3} The following example is a simple but complete
+implementation of the classic Mark/Release pool using subpools:
+
+2/3
+ with System.Storage_Pools.Subpools;
+ with System.Storage_Elements;
+ with Ada.Unchecked_Deallocate_Subpool;
+ package MR_Pool is
+
+3/3
+ use System.Storage_Pools;
+ -- For uses of Subpools.
+ use System.Storage_Elements;
+ -- For uses of Storage_Count and Storage_Array.
+
+4/3
+ -- Mark and Release work in a stack fashion, and allocations are not allowed
+ -- from a subpool other than the one at the top of the stack. This is also
+ -- the default pool.
+
+5/3
+ subtype Subpool_Handle is Subpools.Subpool_Handle;
+
+6/3
+ type Mark_Release_Pool_Type (Pool_Size : Storage_Count) is new
+ Subpools.Root_Storage_Pool_With_Subpools with private;
+
+7/3
+ function Mark (Pool : in out Mark_Release_Pool_Type)
+ return not null Subpool_Handle;
+
+8/3
+ procedure Release (Subpool : in out Subpool_Handle) renames
+ Ada.Unchecked_Deallocate_Subpool;
+
+9/3
+ private
+
+10/3
+ type MR_Subpool is new Subpools.Root_Subpool with record
+ Start : Storage_Count;
+ end record;
+ subtype Subpool_Indexes is Positive range 1 .. 10;
+ type Subpool_Array is array (Subpool_Indexes) of aliased MR_Subpool;
+
+11/3
+ {AI05-0298-1AI05-0298-1} type Mark_Release_Pool_Type (Pool_Size : Storage_Count) is new
+ Subpools.Root_Storage_Pool_With_Subpools with record
+ Storage : Storage_Array (0 .. Pool_Size-1);
+ Next_Allocation : Storage_Count := 0;
+ Markers : Subpool_Array;
+ Current_Pool : Subpool_Indexes := 1;
+ end record;
+
+12/3
+ {AI05-0298-1AI05-0298-1} overriding
+ function Create_Subpool (Pool : in out Mark_Release_Pool_Type)
+ return not null Subpool_Handle;
+
+13/3
+ function Mark (Pool : in out Mark_Release_Pool_Type)
+ return not null Subpool_Handle renames Create_Subpool;
+
+14/3
+ overriding
+ procedure Allocate_From_Subpool (
+ Pool : in out Mark_Release_Pool_Type;
+ Storage_Address : out System.Address;
+ Size_In_Storage_Elements : in Storage_Count;
+ Alignment : in Storage_Count;
+ Subpool : not null Subpool_Handle);
+
+15/3
+ overriding
+ procedure Deallocate_Subpool (
+ Pool : in out Mark_Release_Pool_Type;
+ Subpool : in out Subpool_Handle);
+
+16/3
+ {AI05-0298-1AI05-0298-1} overriding
+ function Default_Subpool_for_Pool (Pool : in out Mark_Release_Pool_Type)
+ return not null Subpool_Handle;
+
+17/3
+ overriding
+ procedure Initialize (Pool : in out Mark_Release_Pool_Type);
+
+18/3
+ -- We don't need Finalize.
+
+19/3
+ end MR_Pool;
+
+20/3
+ package body MR_Pool is
+
+21/3
+ {AI05-0298-1AI05-0298-1} use type Subpool_Handle;
+
+22/3
+ {AI05-0298-1AI05-0298-1} procedure Initialize (Pool : in out Mark_Release_Pool_Type) is
+ -- Initialize the first default subpool.
+ begin
+ Pool.Markers(1).Start := 1;
+ Subpools.Set_Pool_of_Subpool
+ (Pool.Markers(1)'Unchecked_Access, Pool);
+ end Initialize;
+
+23/3
+ function Create_Subpool (Pool : in out Mark_Release_Pool_Type)
+ return not null Subpool_Handle is
+ -- Mark the current allocation location.
+ begin
+ if Pool.Current_Pool = Subpool_Indexes'Last then
+ raise Storage_Error; -- No more subpools.
+ end if;
+ Pool.Current_Pool := Pool.Current_Pool + 1; -- Move to the next subpool
+
+24/3
+ {AI05-0298-1AI05-0298-1} return Result : constant not null Subpool_Handle :=
+ Pool.Markers(Pool.Current_Pool)'Unchecked_Access
+ do
+ Pool.Markers(Pool.Current_Pool).Start := Pool.Next_Allocation;
+ Subpools.Set_Pool_of_Subpool (Result, Pool);
+ end return;
+ end Create_Subpool;
+
+25/3
+ {AI05-0298-1AI05-0298-1} procedure Deallocate_Subpool (
+ Pool : in out Mark_Release_Pool_Type;
+ Subpool : in out Subpool_Handle) is
+ begin
+ if Subpool /= Pool.Markers(Pool.Current_Pool)'Unchecked_Access then
+ raise Program_Error; -- Only the last marked subpool can be released.
+ end if;
+ if Pool.Current_Pool /= 1 then
+ Pool.Next_Allocation := Pool.Markers(Pool.Current_Pool).Start;
+ Pool.Current_Pool := Pool.Current_Pool - 1; -- Move to the previous subpool
+ else -- Reinitialize the default subpool:
+ Pool.Next_Allocation := 1;
+ Subpools.Set_Pool_of_Subpool
+ (Pool.Markers(1)'Unchecked_Access, Pool);
+ end if;
+ end Deallocate_Subpool;
+
+26/3
+ {AI05-0298-1AI05-0298-1} function Default_Subpool_for_Pool (Pool : in out Mark_Release_Pool_Type)
+ return not null Subpool_Handle is
+ begin
+ return Pool.Markers(Pool.Current_Pool)'Unchecked_Access;
+ end Default_Subpool_for_Pool;
+
+27/3
+ procedure Allocate_From_Subpool (
+ Pool : in out Mark_Release_Pool_Type;
+ Storage_Address : out System.Address;
+ Size_In_Storage_Elements : in Storage_Count;
+ Alignment : in Storage_Count;
+ Subpool : not null Subpool_Handle) is
+ begin
+ if Subpool /= Pool.Markers(Pool.Current_Pool)'Unchecked_Access then
+ raise Program_Error; -- Only the last marked subpool can be used for allocations.
+ end if;
+
+28/3
+ -- Correct the alignment if necessary:
+ Pool.Next_Allocation := Pool.Next_Allocation +
+ ((-Pool.Next_Allocation) mod Alignment);
+ if Pool.Next_Allocation + Size_In_Storage_Elements >
+ Pool.Pool_Size then
+ raise Storage_Error; -- Out of space.
+ end if;
+ Storage_Address := Pool.Storage (Pool.Next_Allocation)'Address;
+ Pool.Next_Allocation :=
+ Pool.Next_Allocation + Size_In_Storage_Elements;
+ end Allocate_From_Subpool;
+
+29/3
+ end MR_Pool;
+
+ _Wording Changes from Ada 2005_
+
+29.a/3
+ {AI05-0111-3AI05-0111-3} This example of subpools is new.
+
+\1f
+File: aarm2012.info, Node: 13.12, Next: 13.13, Prev: 13.11, Up: 13
+
+13.12 Pragma Restrictions and Pragma Profile
+============================================
+
+1/3
+{AI05-0246-1AI05-0246-1} [A pragma Restrictions expresses the user's
+intent to abide by certain restrictions. A pragma Profile expresses the
+user's intent to abide by a set of Restrictions or other specified
+run-time policies. These may facilitate the construction of simpler
+run-time environments.]
+
+ _Syntax_
+
+2
+ The form of a pragma Restrictions is as follows:
+
+3
+ pragma Restrictions(restriction{, restriction});
+
+4/2
+ {AI95-00381-01AI95-00381-01} restriction ::= restriction_identifier
+ | restriction_parameter_identifier =>
+ restriction_parameter_argument
+
+4.1/2
+ {AI95-00381-01AI95-00381-01} restriction_parameter_argument ::=
+ name | expression
+
+ _Name Resolution Rules_
+
+5
+Unless otherwise specified for a particular restriction, the expression
+is expected to be of any integer type.
+
+ _Legality Rules_
+
+6
+Unless otherwise specified for a particular restriction, the expression
+shall be static, and its value shall be nonnegative.
+
+7.a/3
+ This paragraph was deleted.
+
+Paragraph 7 was deleted.
+
+ _Post-Compilation Rules_
+
+8/3
+{AI05-0013-1AI05-0013-1} A pragma Restrictions is a configuration
+pragma. If a pragma Restrictions applies to any compilation unit
+included in the partition, this may impose either (or both) of two kinds
+of requirements, as specified for the particular restriction:
+
+8.1/3
+ * {AI05-0013-1AI05-0013-1} A restriction may impose requirements on
+ some or all of the units comprising the partition. Unless
+ otherwise specified for a particular restriction, such a
+ requirement applies to all of the units comprising the partition
+ and is enforced via a post-compilation check.
+
+8.2/3
+ * {AI05-0013-1AI05-0013-1} A restriction may impose requirements on
+ the run-time behavior of the program, as indicated by the
+ specification of run-time behavior associated with a violation of
+ the requirement.
+
+8.a.1/3
+ Ramification: In this latter case, there is no
+ post-compilation check needed for the requirement.
+
+8.3/1
+{8652/00428652/0042} {AI95-00130-01AI95-00130-01} For the purpose of
+checking whether a partition contains constructs that violate any
+restriction (unless specified otherwise for a particular restriction):
+
+8.4/1
+ * {8652/00428652/0042} {AI95-00130-01AI95-00130-01} Generic instances
+ are logically expanded at the point of instantiation;
+
+8.5/1
+ * {8652/00428652/0042} {AI95-00130-01AI95-00130-01} If an object of a
+ type is declared or allocated and not explicitly initialized, then
+ all expressions appearing in the definition for the type and any of
+ its ancestors are presumed to be used;
+
+8.6/1
+ * {8652/00428652/0042} {AI95-00130-01AI95-00130-01} A
+ default_expression for a formal parameter or a generic formal
+ object is considered to be used if and only if the corresponding
+ actual parameter is not provided in a given call or instantiation.
+
+ _Implementation Permissions_
+
+8.7/3
+{AI05-0269-1AI05-0269-1} An implementation may provide
+implementation-defined restrictions; the identifier for an
+implementation-defined restriction shall differ from those of the
+language-defined restrictions.
+
+8.a.2/3
+ Implementation defined: Implementation-defined restrictions
+ allowed in a pragma Restrictions.
+
+9
+An implementation may place limitations on the values of the expression
+that are supported, and limitations on the supported combinations of
+restrictions. The consequences of violating such limitations are
+implementation defined.
+
+9.a
+ Implementation defined: The consequences of violating
+ limitations on Restrictions pragmas.
+
+9.b
+ Ramification: Such limitations may be enforced at compile time
+ or at run time. Alternatively, the implementation is allowed
+ to declare violations of the restrictions to be erroneous, and
+ not enforce them at all.
+
+9.1/1
+{8652/00428652/0042} {AI95-00130-01AI95-00130-01} An implementation is
+permitted to omit restriction checks for code that is recognized at
+compile time to be unreachable and for which no code is generated.
+
+9.2/1
+{8652/00438652/0043} {AI95-00190-01AI95-00190-01} Whenever enforcement
+of a restriction is not required prior to execution, an implementation
+may nevertheless enforce the restriction prior to execution of a
+partition to which the restriction applies, provided that every
+execution of the partition would violate the restriction.
+
+ _Syntax_
+
+10/3
+ {AI95-00249-01AI95-00249-01} {AI05-0246-1AI05-0246-1} The form of a
+ pragma Profile is as follows:
+
+11/3
+ pragma Profile (profile_identifier {, profile_
+ pragma_argument_association});
+
+ _Legality Rules_
+
+12/3
+{AI95-00249-01AI95-00249-01} {AI05-0246-1AI05-0246-1} The
+profile_identifier shall be the name of a usage profile. The semantics
+of any profile_pragma_argument_association (*note 2.8: S0020.)s are
+defined by the usage profile specified by the profile_identifier.
+
+ _Static Semantics_
+
+13/3
+{AI95-00249-01AI95-00249-01} {AI05-0246-1AI05-0246-1} A profile is
+equivalent to the set of configuration pragmas that is defined for each
+usage profile.
+
+ _Post-Compilation Rules_
+
+14/3
+{AI95-00249-01AI95-00249-01} A pragma Profile is a configuration pragma.
+There may be more than one pragma Profile for a partition.
+
+ _Implementation Permissions_
+
+15/3
+{AI05-0269-1AI05-0269-1} An implementation may provide
+implementation-defined usage profiles; the identifier for an
+implementation-defined usage profile shall differ from those of the
+language-defined usage profiles.
+
+15.a.1/3
+ Implementation defined: Implementation-defined usage profiles
+ allowed in a pragma Profile.
+
+ NOTES
+
+16/2
+ 36 {AI95-00347-01AI95-00347-01} Restrictions intended to
+ facilitate the construction of efficient tasking run-time systems
+ are defined in *note D.7::. Restrictions intended for use when
+ constructing high integrity systems are defined in *note H.4::.
+
+17
+ 37 An implementation has to enforce the restrictions in cases
+ where enforcement is required, even if it chooses not to take
+ advantage of the restrictions in terms of efficiency.
+
+17.a
+ Discussion: It is not the intent that an implementation will
+ support a different run-time system for every possible
+ combination of restrictions. An implementation might support
+ only two run-time systems, and document a set of restrictions
+ that is sufficient to allow use of the more efficient and safe
+ one.
+
+ _Extensions to Ada 83_
+
+17.b
+ Pragma Restrictions is new to Ada 95.
+
+ _Extensions to Ada 95_
+
+17.c/3
+ {AI95-00249-01AI95-00249-01} {AI05-0246-1AI05-0246-1} Pragma
+ Profile is new; it was moved here by Ada 2012 and renamed to a
+ "usage profile" but was otherwise unchanged.
+
+ _Wording Changes from Ada 95_
+
+17.d/2
+ {8652/00428652/0042} {AI95-00130-01AI95-00130-01} Corrigendum:
+ Corrected the wording so that restrictions are checked inside
+ of generic instantiations and in default expressions. Since
+ not making these checks would violate the purpose of
+ restrictions, we are not documenting this as an
+ incompatibility.
+
+17.e/2
+ {8652/00438652/0043} {AI95-00190-01AI95-00190-01} Corrigendum:
+ Added a permission that restrictions can be enforced at
+ compile-time. While this is technically incompatible,
+ documenting it as such would be unnecessarily alarming - there
+ should not be any programs depending on the runtime failure of
+ restrictions.
+
+17.f/2
+ {AI95-00381-01AI95-00381-01} The syntax of a
+ restriction_parameter_argument has been defined to better
+ support restriction No_Dependence (see *note 13.12.1::).
+
+ _Wording Changes from Ada 2005_
+
+17.g/3
+ {AI05-0013-1AI05-0013-1} Correction: When restrictions are
+ checked has been clarified.
+
+* Menu:
+
+* 13.12.1 :: Language-Defined Restrictions and Profiles
+
+\1f
+File: aarm2012.info, Node: 13.12.1, Up: 13.12
+
+13.12.1 Language-Defined Restrictions and Profiles
+--------------------------------------------------
+
+ _Static Semantics_
+
+1/2
+{AI95-00257-01AI95-00257-01} The following restriction_identifiers are
+language defined (additional restrictions are defined in the Specialized
+Needs Annexes):
+
+1.1/3
+{AI05-0241-1AI05-0241-1} No_Implementation_Aspect_Specifications
+ There are no implementation-defined aspects specified by
+ an aspect_specification. This restriction applies only
+ to the current compilation or environment, not the entire
+ partition.
+
+1.a/3
+ Discussion: {AI05-0241-1AI05-0241-1} This restriction (as well
+ as others below) applies only to the current compilation,
+ because it is likely that the runtime (and possibly
+ user-written low-level code) will need to use
+ implementation-defined aspects. But a partition-wide
+ restriction applies everywhere, including the runtime.
+
+2/2
+{AI95-00257-01AI95-00257-01} No_Implementation_Attributes
+ There are no implementation-defined attributes. This
+ restriction applies only to the current compilation or
+ environment, not the entire partition.
+
+2.1/3
+{AI05-0246-1AI05-0246-1} {AI05-0269-1AI05-0269-1}
+No_Implementation_Identifiers
+ There are no usage names that denote declarations with
+ implementation-defined identifiers that occur within
+ language-defined packages or instances of
+ language-defined generic packages. Such identifiers can
+ arise as follows:
+
+2.2/3
+ * The following language-defined packages and generic
+ packages allow implementation-defined identifiers:
+
+2.3/3
+ * package System (see *note 13.7::);
+
+2.4/3
+ * package Standard (see *note A.1::);
+
+2.5/3
+ * package Ada.Command_Line (see *note
+ A.15::);
+
+2.6/3
+ * package Interfaces.C (see *note B.3::);
+
+2.7/3
+ * package Interfaces.C.Strings (see *note
+ B.3.1::);
+
+2.8/3
+ * package Interfaces.C.Pointers (see *note
+ B.3.2::);
+
+2.9/3
+ * package Interfaces.COBOL (see *note
+ B.4::);
+
+2.10/3
+ * package Interfaces.Fortran (see *note
+ B.5::);
+
+2.11/3
+ * The following language-defined packages contain only
+ implementation-defined identifiers:
+
+2.12/3
+ * package System.Machine_Code (see *note
+ 13.8::);
+
+2.13/3
+ * package Ada.Directories.Information (see
+ *note A.16::);
+
+2.14/3
+ * nested Implementation packages of the
+ Queue containers (see *note A.18.28::-31);
+
+2.15/3
+ * package Interfaces (see *note B.2::);
+
+2.16/3
+ * package Ada.Interrupts.Names (see *note
+ C.3.2::).
+
+2.17/3
+ For package Standard, Standard.Long_Integer and
+ Standard.Long_Float are considered language-defined
+ identifiers, but identifiers such as
+ Standard.Short_Short_Integer are considered
+ implementation-defined.
+
+2.18/3
+ This restriction applies only to the current compilation
+ or environment, not the entire partition.
+
+3/2
+{AI95-00257-01AI95-00257-01} No_Implementation_Pragmas
+ There are no implementation-defined pragmas or pragma
+ arguments. This restriction applies only to the current
+ compilation or environment, not the entire partition.
+
+3.1/3
+{AI05-0242-1AI05-0242-1} No_Implementation_Units
+ There is no mention in the context_clause of any
+ implementation-defined descendants of packages Ada,
+ Interfaces, or System. This restriction applies only to
+ the current compilation or environment, not the entire
+ partition.
+
+4/3
+{AI95-00368-01AI95-00368-01} {AI05-0229-1AI05-0229-1}
+No_Obsolescent_Features
+ There is no use of language features defined in Annex J.
+ It is implementation defined whether uses of the
+ renamings of *note J.1:: and of the pragmas of *note
+ J.15:: are detected by this restriction. This
+ restriction applies only to the current compilation or
+ environment, not the entire partition.
+
+4.a/2
+ Reason: A user could compile a rename like
+
+4.b/2
+ with Ada.Text_IO;
+ package Text_IO renames Ada.Text_IO;
+
+4.c/2
+ Such a rename must not be disallowed by this restriction, nor
+ should the compilation of such a rename be restricted by an
+ implementation. Many implementations implement the renames of
+ *note J.1:: by compiling them normally; we do not want to
+ require implementations to use a special mechanism to
+ implement these renames.
+
+4.d/3
+ {AI05-0229-1AI05-0229-1} The pragmas have the same
+ functionality as the corresponding aspect (unlike the typical
+ obsolescent feature), and rejecting them could be a
+ significant portability problem for existing code.
+
+5/3
+{AI95-00381-01AI95-00381-01} {AI05-0241-1AI05-0241-1} The following
+restriction_parameter_identifiers are language defined:
+
+6/2
+{AI95-00381-01AI95-00381-01} No_Dependence
+ Specifies a library unit on which there are no semantic
+ dependences.
+
+6.1/3
+{AI05-0241-1AI05-0241-1} No_Specification_of_Aspect
+ Identifies an aspect for which no aspect_specification,
+ attribute_definition_clause, or pragma is given.
+
+6.2/3
+{AI05-0272-1AI05-0272-1} No_Use_Of_Attribute
+ Identifies an attribute for which no attribute_reference
+ or attribute_definition_clause is given.
+
+6.3/3
+{AI05-0272-1AI05-0272-1} No_Use_Of_Pragma
+ Identifies a pragma which is not to be used.
+
+ _Legality Rules_
+
+7/2
+{AI95-00381-01AI95-00381-01} The restriction_parameter_argument of a
+No_Dependence restriction shall be a name; the name shall have the form
+of a full expanded name of a library unit, but need not denote a unit
+present in the environment.
+
+7.a/2
+ Ramification: This name is not resolved.
+
+7.1/3
+{AI05-0241-1AI05-0241-1} The restriction_parameter_argument of a
+No_Specification_of_Aspect restriction shall be an identifier; this is
+an identifier specific to a pragma (see *note 2.8::) and does not denote
+any declaration.
+
+7.b/3
+ Ramification: This restriction_parameter_argument is not
+ resolved as it is an identifier specific to a pragma. As for
+ No_Dependence, there is no check that the aspect identifier is
+ meaningful; it might refer to an implementation-defined aspect
+ on one implementation, but nothing at all on another
+ implementation.
+
+7.2/3
+{AI05-0272-1AI05-0272-1} The restriction_parameter_argument of a
+No_Use_Of_Attribute restriction shall be an identifier or one of the
+reserved words Access, Delta, Digits, Mod, or Range; this is an
+identifier specific to a pragma.
+
+7.c/3
+ Ramification: This restriction_parameter_argument is not
+ resolved as it is an identifier specific to a pragma. There
+ is no check that the attribute identifier refers to a known
+ attribute_designator; it might refer to an
+ implementation-defined attribute on one implementation, but
+ nothing at all on another implementation.
+
+7.3/3
+{AI05-0272-1AI05-0272-1} The restriction_parameter_argument of a
+No_Use_Of_Pragma restriction shall be an identifier or the reserved word
+Interface; this is an identifier specific to a pragma.
+
+7.d/3
+ Ramification: This restriction_parameter_argument is not
+ resolved as it is an identifier specific to a pragma. There
+ is no check that the pragma identifier refers to a known
+ pragma; it might refer to an implementation-defined pragma on
+ one implementation, but nothing at all on another
+ implementation.
+
+ _Post-Compilation Rules_
+
+8/3
+{AI95-00381-01AI95-00381-01} {AI05-0241-1AI05-0241-1} No compilation
+unit included in the partition shall depend semantically on the library
+unit identified by the name of a No_Dependence restriction.
+
+8.a/2
+ Ramification: There is no requirement that the library unit
+ actually exist. One possible use of the pragma is to prevent
+ the use of implementation-defined units; when the program is
+ ported to a different compiler, it is perfectly reasonable
+ that no unit with the name exist.
+
+ _Static Semantics_
+
+9/3
+{AI05-0246-1AI05-0246-1} The following profile_identifier is language
+defined:
+
+10/3
+{AI05-0246-1AI05-0246-1} No_Implementation_Extensions
+
+11/3
+{AI05-0246-1AI05-0246-1} For usage profile No_Implementation_Extensions,
+there shall be no profile_pragma_argument_associations.
+
+12/3
+{AI05-0246-1AI05-0246-1} The No_Implementation_Extensions usage profile
+is equivalent to the following restrictions:
+
+13/3
+ No_Implementation_Aspect_Specifications,
+ No_Implementation_Attributes,
+ No_Implementation_Identifiers,
+ No_Implementation_Pragmas,
+ No_Implementation_Units.
+
+ _Extensions to Ada 95_
+
+13.a/2
+ {AI95-00257-01AI95-00257-01} {AI95-00368-01AI95-00368-01}
+ Restrictions No_Implementation_Attributes,
+ No_Implementation_Pragmas, and No_Obsolescent_Features are
+ new.
+
+13.b/2
+ {AI95-00381-01AI95-00381-01} Restriction No_Dependence is new.
+
+ _Extensions to Ada 2005_
+
+13.c/3
+ {AI05-0241-1AI05-0241-1} {AI05-0242-1AI05-0242-1}
+ {AI05-0246-1AI05-0246-1} {AI05-0272-1AI05-0272-1} Restrictions
+ No_Implementation_Aspect_Specifications,
+ No_Implementation_Identifiers, No_Implementation_Units,
+ No_Specification_of_Aspect, No_Use_of_Attribute, and
+ No_Use_of_Pragma are new.
+
+13.d/3
+ {AI05-0246-1AI05-0246-1} Profile No_Implementation_Extensions
+ is new.
+
+\1f
+File: aarm2012.info, Node: 13.13, Next: 13.14, Prev: 13.12, Up: 13
+
+13.13 Streams
+=============
+
+1
+A stream is a sequence of elements comprising values from possibly
+different types and allowing sequential access to these values. A
+stream type is a type in the class whose root type is
+Streams.Root_Stream_Type. A stream type may be implemented in various
+ways, such as an external sequential file, an internal buffer, or a
+network channel.
+
+1.a
+ Discussion: A stream element will often be the same size as a
+ storage element, but that is not required.
+
+1.a.1/3
+ Glossary entry: A stream is a sequence of elements that can be
+ used, along with the stream-oriented attributes, to support
+ marshalling and unmarshalling of values of most types.
+
+ _Extensions to Ada 83_
+
+1.b
+ Streams are new in Ada 95.
+
+* Menu:
+
+* 13.13.1 :: The Package Streams
+* 13.13.2 :: Stream-Oriented Attributes
+
+\1f
+File: aarm2012.info, Node: 13.13.1, Next: 13.13.2, Up: 13.13
+
+13.13.1 The Package Streams
+---------------------------
+
+ _Static Semantics_
+
+1
+The abstract type Root_Stream_Type is the root type of the class of
+stream types. The types in this class represent different kinds of
+streams. A new stream type is defined by extending the root type (or
+some other stream type), overriding the Read and Write operations, and
+optionally defining additional primitive subprograms, according to the
+requirements of the particular kind of stream. The predefined
+stream-oriented attributes like T'Read and T'Write make dispatching
+calls on the Read and Write procedures of the Root_Stream_Type.
+(User-defined T'Read and T'Write attributes can also make such calls, or
+can call the Read and Write attributes of other types.)
+
+2
+ package Ada.Streams is
+ pragma Pure(Streams);
+
+3/2
+ {AI95-00161-01AI95-00161-01} type Root_Stream_Type is abstract tagged limited private;
+ pragma Preelaborable_Initialization(Root_Stream_Type);
+
+4/1
+ {8652/00448652/0044} {AI95-00181-01AI95-00181-01} type Stream_Element is mod implementation-defined;
+ type Stream_Element_Offset is range implementation-defined;
+ subtype Stream_Element_Count is
+ Stream_Element_Offset range 0..Stream_Element_Offset'Last;
+ type Stream_Element_Array is
+ array(Stream_Element_Offset range <>) of aliased Stream_Element;
+
+5
+ procedure Read(
+ Stream : in out Root_Stream_Type;
+ Item : out Stream_Element_Array;
+ Last : out Stream_Element_Offset) is abstract;
+
+6
+ procedure Write(
+ Stream : in out Root_Stream_Type;
+ Item : in Stream_Element_Array) is abstract;
+
+7
+ private
+ ... -- not specified by the language
+ end Ada.Streams;
+
+8/2
+{AI95-00227-01AI95-00227-01} The Read operation transfers stream
+elements from the specified stream to fill the array Item. Elements are
+transferred until Item'Length elements have been transferred, or until
+the end of the stream is reached. If any elements are transferred, the
+index of the last stream element transferred is returned in Last.
+Otherwise, Item'First - 1 is returned in Last. Last is less than
+Item'Last only if the end of the stream is reached.
+
+9
+The Write operation appends Item to the specified stream.
+
+9.a/2
+ Discussion: {AI95-00114-01AI95-00114-01} The index subtype of
+ Stream_Element_Array is Stream_Element_Offset because we wish
+ to allow maximum flexibility. Most Stream_Element_Arrays will
+ probably have a lower bound of 0 or 1, but other lower bounds,
+ including negative ones, make sense in some situations.
+
+9.b/3
+ {AI95-00114-01AI95-00114-01} {AI05-0005-1AI05-0005-1} Note
+ that there are some language-defined subprograms that fill
+ part of a Stream_Element_Array, and return the index of the
+ last element filled as a Stream_Element_Offset. The Read
+ procedures declared here, Streams.Stream_IO (see *note
+ A.12.1::), and System.RPC (see *note E.5::) behave in this
+ manner. These will raise Constraint_Error if the resulting
+ Last value is not in Stream_Element_Offset. This implies that
+ the Stream_Element_Array passed to these subprograms should
+ not have a lower bound of Stream_Element_Offset'First, because
+ then a read of 0 elements would always raise Constraint_Error.
+ A better choice of lower bound is 0 or 1.
+
+ _Implementation Permissions_
+
+9.1/1
+{8652/00448652/0044} {AI95-00181-01AI95-00181-01} If Stream_Element'Size
+is not a multiple of System.Storage_Unit, then the components of
+Stream_Element_Array need not be aliased.
+
+9.b.1/2
+ Ramification: {AI95-00114-01AI95-00114-01} If the
+ Stream_Element'Size is less than the size of
+ System.Storage_Unit, then components of Stream_Element_Array
+ need not be aliased. This is necessary as the components of
+ type Stream_Element size might not be addressable on the
+ target architecture.
+
+ NOTES
+
+10
+ 38 See *note A.12.1::, "*note A.12.1:: The Package
+ Streams.Stream_IO" for an example of extending type
+ Root_Stream_Type.
+
+11/2
+ 39 {AI95-00227-01AI95-00227-01} If the end of stream has been
+ reached, and Item'First is Stream_Element_Offset'First, Read will
+ raise Constraint_Error.
+
+11.a/2
+ Ramification: Thus, Stream_Element_Arrays should start at 0 or
+ 1, not Stream_Element_Offset'First.
+
+ _Extensions to Ada 95_
+
+11.b/2
+ {AI95-00161-01AI95-00161-01} Amendment Correction: Added
+ pragma Preelaborable_Initialization to type Root_Stream_Type.
+
+ _Wording Changes from Ada 95_
+
+11.c/2
+ {8652/00448652/0044} {AI95-00181-01AI95-00181-01} Corrigendum:
+ Stream elements are aliased presuming that makes sense.
+
+11.d/2
+ {AI95-00227-01AI95-00227-01} Fixed the wording for Read to
+ properly define the result in Last when no stream elements are
+ transfered.
+
+\1f
+File: aarm2012.info, Node: 13.13.2, Prev: 13.13.1, Up: 13.13
+
+13.13.2 Stream-Oriented Attributes
+----------------------------------
+
+1/3
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+{AI05-0183-1AI05-0183-1} The type-related operational attributes Write,
+Read, Output, and Input convert values to a stream of elements and
+reconstruct values from a stream.
+
+ _Static Semantics_
+
+1.1/2
+{AI95-00270-01AI95-00270-01} For every subtype S of an elementary type
+T, the following representation attribute is defined:
+
+1.2/3
+S'Stream_Size
+ {AI95-00270-01AI95-00270-01} {AI05-0194-1AI05-0194-1}
+ Denotes the number of bits read from or written to a
+ stream by the default implementations of S'Read and
+ S'Write. Hence, the number of stream elements required
+ per item of elementary type T is:
+
+1.3/2
+ T'Stream_Size / Ada.Streams.Stream_Element'Size
+
+1.4/2
+ The value of this attribute is of type universal_integer
+ and is a multiple of Stream_Element'Size.
+
+1.5/2
+ Stream_Size may be specified for first subtypes via an
+ attribute_definition_clause; the expression of such a
+ clause shall be static, nonnegative, and a multiple of
+ Stream_Element'Size.
+
+1.a/3
+ Aspect Description for Stream_Size: Size in bits used to
+ represent elementary objects in a stream.
+
+1.b/2
+ Discussion: Stream_Size is a type-related attribute (see *note
+ 13.1::).
+
+1.c/3
+ Ramification: {AI05-0194-1AI05-0194-1} The value of
+ S'Stream_Size is unaffected by the presence or absence of any
+ attribute_definition_clauses or aspect_specifications
+ specifying the Read or Write attributes of any ancestor of S.
+ S'Stream_Size is defined in terms of the behavior of the
+ default implementations of S'Read and S'Write even if those
+ default implementations are overridden.
+
+ _Implementation Advice_
+
+1.6/2
+{AI95-00270-01AI95-00270-01} If not specified, the value of Stream_Size
+for an elementary type should be the number of bits that corresponds to
+the minimum number of stream elements required by the first subtype of
+the type, rounded up to the nearest factor or multiple of the word size
+that is also a multiple of the stream element size.
+
+1.d/2
+ Implementation Advice: If not specified, the value of
+ Stream_Size for an elementary type should be the number of
+ bits that corresponds to the minimum number of stream elements
+ required by the first subtype of the type, rounded up to the
+ nearest factor or multiple of the word size that is also a
+ multiple of the stream element size.
+
+1.e/2
+ Reason: {AI95-00270-01AI95-00270-01} This is Implementation
+ Advice because we want to allow implementations to remain
+ compatible with their Ada 95 implementations, which may have a
+ different handling of the number of stream elements. Users
+ can always specify Stream_Size if they need a specific number
+ of stream elements.
+
+1.7/2
+{AI95-00270-01AI95-00270-01} The recommended level of support for the
+Stream_Size attribute is:
+
+1.8/2
+ * {AI95-00270-01AI95-00270-01} A Stream_Size clause should be
+ supported for a discrete or fixed point type T if the specified
+ Stream_Size is a multiple of Stream_Element'Size and is no less
+ than the size of the first subtype of T, and no greater than the
+ size of the largest type of the same elementary class (signed
+ integer, modular integer, enumeration, ordinary fixed point, or
+ decimal fixed point).
+
+1.f/2
+ Implementation Advice: The recommended level of support for
+ the Stream_Size attribute should be followed.
+
+1.g/2
+ Ramification: There are no requirements beyond supporting
+ confirming Stream_Size clauses for floating point and access
+ types. Floating point and access types usually only have a
+ handful of defined formats, streaming anything else makes no
+ sense for them.
+
+1.h/2
+ For discrete and fixed point types, this may require support
+ for sizes other than the "natural" ones. For instance, on a
+ typical machine with 32-bit integers and a Stream_Element'Size
+ of 8, setting Stream_Size to 24 must be supported. This is
+ required as such formats can be useful for interoperability
+ with unusual machines, and there is no difficulty with the
+ implementation (drop extra bits on output, sign extend on
+ input).
+
+ _Static Semantics_
+
+2
+For every subtype S of a specific type T, the following attributes are
+defined.
+
+3
+S'Write
+ S'Write denotes a procedure with the following
+ specification:
+
+4/2
+ {AI95-00441-01AI95-00441-01} procedure S'Write(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+ Item : in T)
+
+5
+ S'Write writes the value of Item to Stream.
+
+6
+S'Read
+ S'Read denotes a procedure with the following
+ specification:
+
+7/2
+ {AI95-00441-01AI95-00441-01} procedure S'Read(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+ Item : out T)
+
+8
+ S'Read reads the value of Item from Stream.
+
+8.1/3
+{8652/00408652/0040} {AI95-00108-01AI95-00108-01}
+{AI95-00444-01AI95-00444-01} {AI05-0192-1AI05-0192-1} For an untagged
+derived type, the Write (resp. Read) attribute is inherited according
+to the rules given in *note 13.1:: if the attribute is [specified and]
+available for the parent type at the point where T is declared. For a
+tagged derived type, these attributes are not inherited, but rather the
+default implementations are used.
+
+8.a.1/3
+ Proof: {AI05-0192-1AI05-0192-1} The inheritance rules of *note
+ 13.1:: say that only specified or inherited aspects are
+ inherited; we mention it again here as a clarification.
+
+8.2/2
+{AI95-00444-01AI95-00444-01} The default implementations of the Write
+and Read attributes, where available, execute as follows:
+
+9/3
+{8652/00408652/0040} {AI95-00108-01AI95-00108-01}
+{AI95-00195-01AI95-00195-01} {AI95-00251-01AI95-00251-01}
+{AI95-00270-01AI95-00270-01} {AI05-0139-2AI05-0139-2} For elementary
+types, Read reads (and Write writes) the number of stream elements
+implied by the Stream_Size for the type T; the representation of those
+stream elements is implementation defined. For composite types, the
+Write or Read attribute for each component is called in canonical order,
+which is last dimension varying fastest for an array (unless the
+convention of the array is Fortran, in which case it is first dimension
+varying fastest), and positional aggregate order for a record. Bounds
+are not included in the stream if T is an array type. If T is a
+discriminated type, discriminants are included only if they have
+defaults. If T is a tagged type, the tag is not included. For type
+extensions, the Write or Read attribute for the parent type is called,
+followed by the Write or Read attribute of each component of the
+extension part, in canonical order. For a limited type extension, if
+the attribute of the parent type or any progenitor type of T is
+available anywhere within the immediate scope of T, and the attribute of
+the parent type or the type of any of the extension components is not
+available at the freezing point of T, then the attribute of T shall be
+directly specified.
+
+9.a/2
+ Implementation defined: The contents of the stream elements
+ read and written by the Read and Write attributes of
+ elementary types.
+
+9.1/3
+{AI05-0023-1AI05-0023-1} {AI05-0264-1AI05-0264-1} If T is a
+discriminated type and its discriminants have defaults, then S'Read
+first reads the discriminants from the stream without modifying Item.
+S'Read then creates an object of type T constrained by these
+discriminants. The value of this object is then converted to the
+subtype of Item and is assigned to Item. Finally, the Read attribute
+for each nondiscriminant component of Item is called in canonical order
+as described above. Normal default initialization and finalization take
+place for the created object.
+
+9.b
+ Reason: A discriminant with a default value is treated simply
+ as a component of the object. On the other hand, an array
+ bound or a discriminant without a default value, is treated as
+ "descriptor" or "dope" that must be provided in order to
+ create the object and thus is logically separate from the
+ regular components. Such "descriptor" data are written by
+ 'Output and produced as part of the delivered result by the
+ 'Input function, but they are not written by 'Write nor read
+ by 'Read. A tag is like a discriminant without a default.
+
+9.b.1/1
+ {8652/00408652/0040} {AI95-00108-01AI95-00108-01} For limited
+ type extensions, we must have a definition of 'Read and 'Write
+ if the parent type has one, as it is possible to make a
+ dispatching call through the attributes. The rule is designed
+ to automatically do the right thing in as many cases as
+ possible.
+
+9.b.2/1
+ {AI95-00251-01AI95-00251-01} Similarly, a type that has a
+ progenitor with an available attribute must also have that
+ attribute, for the same reason.
+
+9.b.3/3
+ {AI05-0023-1AI05-0023-1} The semantics of S'Read for a
+ discriminated type with defaults involves an anonymous object
+ so that the point of required initialization and finalization
+ is well-defined, especially for objects that change shape and
+ have controlled components. The creation of this anonymous
+ object often can be omitted (see the Implementation
+ Permissions below).
+
+9.c/2
+ Ramification: {AI95-00195-01AI95-00195-01} For a composite
+ object, the subprogram denoted by the Write or Read attribute
+ of each component is called, whether it is the default or is
+ user-specified. Implementations are allowed to optimize these
+ calls (see below), presuming the properties of the attributes
+ are preserved.
+
+9.2/3
+{AI95-00270-01AI95-00270-01} {AI05-0264-1AI05-0264-1} Constraint_Error
+is raised by the predefined Write attribute if the value of the
+elementary item is outside the range of values representable using
+Stream_Size bits. For a signed integer type, an enumeration type, or a
+fixed point type, the range is unsigned only if the integer code for the
+lower bound of the first subtype is nonnegative, and a (symmetric)
+signed range that covers all values of the first subtype would require
+more than Stream_Size bits; otherwise, the range is signed.
+
+10
+For every subtype S'Class of a class-wide type T'Class:
+
+11
+S'Class'Write
+ S'Class'Write denotes a procedure with the following
+ specification:
+
+12/2
+ {AI95-00441-01AI95-00441-01} procedure S'Class'Write(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+ Item : in T'Class)
+
+13
+ Dispatches to the subprogram denoted by the Write
+ attribute of the specific type identified by the tag of
+ Item.
+
+14
+S'Class'Read
+ S'Class'Read denotes a procedure with the following
+ specification:
+
+15/2
+ {AI95-00441-01AI95-00441-01} procedure S'Class'Read(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+ Item : out T'Class)
+
+16
+ Dispatches to the subprogram denoted by the Read
+ attribute of the specific type identified by the tag of
+ Item.
+
+16.a
+ Reason: It is necessary to have class-wide versions of Read
+ and Write in order to avoid generic contract model violations;
+ in a generic, we don't necessarily know at compile time
+ whether a given type is specific or class-wide.
+
+Paragraph 17 was deleted.
+
+ _Static Semantics_
+
+18
+For every subtype S of a specific type T, the following attributes are
+defined.
+
+19
+S'Output
+ S'Output denotes a procedure with the following
+ specification:
+
+20/2
+ {AI95-00441-01AI95-00441-01} procedure S'Output(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+ Item : in T)
+
+21
+ S'Output writes the value of Item to Stream, including
+ any bounds or discriminants.
+
+21.a
+ Ramification: Note that the bounds are included even for an
+ array type whose first subtype is constrained.
+
+22
+S'Input
+ S'Input denotes a function with the following
+ specification:
+
+23/2
+ {AI95-00441-01AI95-00441-01} function S'Input(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class)
+ return T
+
+24
+ S'Input reads and returns one value from Stream, using
+ any bounds or discriminants written by a corresponding
+ S'Output to determine how much to read.
+
+25/3
+{8652/00408652/0040} {AI95-00108-01AI95-00108-01}
+{AI95-00444-01AI95-00444-01} {AI05-0192-1AI05-0192-1} For an untagged
+derived type, the Output (resp. Input) attribute is inherited according
+to the rules given in *note 13.1:: if the attribute is [specified and]
+available for the parent type at the point where T is declared. For a
+tagged derived type, these attributes are not inherited, but rather the
+default implementations are used.
+
+25.a/3
+ Proof: {AI05-0192-1AI05-0192-1} See the note following the
+ inheritance rules for the Write attribute, above.
+
+25.1/2
+{AI95-00444-01AI95-00444-01} The default implementations of the Output
+and Input attributes, where available, execute as follows:
+
+26/3
+ * {AI05-0269-1AI05-0269-1} If T is an array type, S'Output first
+ writes the bounds, and S'Input first reads the bounds. If T has
+ discriminants without defaults, S'Output first writes the
+ discriminants (using the Write attribute of the discriminant type
+ for each), and S'Input first reads the discriminants (using the
+ Read attribute of the discriminant type for each).
+
+27/3
+ * {AI95-00195-01AI95-00195-01} {AI05-0023-1AI05-0023-1} S'Output then
+ calls S'Write to write the value of Item to the stream. S'Input
+ then creates an object of type T, with the bounds or (when without
+ defaults) the discriminants, if any, taken from the stream, passes
+ it to S'Read, and returns the value of the object. If T has
+ discriminants, then this object is unconstrained if and only the
+ discriminants have defaults. Normal default initialization and
+ finalization take place for this object (see *note 3.3.1::, *note
+ 7.6::, and *note 7.6.1::).
+
+27.1/2
+{AI95-00251-01AI95-00251-01} If T is an abstract type, then S'Input is
+an abstract function.
+
+27.a/2
+ Ramification: For an abstract type T, S'Input can be called in
+ a dispatching call, or passed to an abstract formal
+ subprogram. But it cannot be used in nondispatching contexts,
+ because we don't allow objects of abstract types to exist.
+ The designation of this function as abstract has no impact on
+ descendants of T, as T'Input is not inherited for tagged
+ types, but rather recreated (and the default implementation of
+ T'Input calls T'Read, not the parent type's T'Input). Note
+ that T'Input cannot be specified in this case, as any function
+ with the proper profile is necessarily abstract, and
+ specifying abstract subprograms in an
+ attribute_definition_clause is illegal.
+
+28
+For every subtype S'Class of a class-wide type T'Class:
+
+29
+S'Class'Output
+ S'Class'Output denotes a procedure with the following
+ specification:
+
+30/2
+ {AI95-00441-01AI95-00441-01} procedure S'Class'Output(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+ Item : in T'Class)
+
+31/2
+ {AI95-00344-01AI95-00344-01} First writes the external
+ tag of Item to Stream (by calling String'Output(Stream,
+ Tags.External_Tag(Item'Tag)) -- see *note 3.9::) and then
+ dispatches to the subprogram denoted by the Output
+ attribute of the specific type identified by the tag.
+ Tag_Error is raised if the tag of Item identifies a type
+ declared at an accessibility level deeper than that of S.
+
+31.a/2
+ Reason: {AI95-00344-01AI95-00344-01} We raise Tag_Error here
+ for nested types as such a type cannot be successfully read
+ with S'Class'Input, and it doesn't make sense to allow writing
+ a value that cannot be read.
+
+32
+S'Class'Input
+ S'Class'Input denotes a function with the following
+ specification:
+
+33/2
+ {AI95-00441-01AI95-00441-01} function S'Class'Input(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class)
+ return T'Class
+
+34/3
+ {AI95-00279-01AI95-00279-01} {AI95-00344-01AI95-00344-01}
+ {AI05-0109-1AI05-0109-1} First reads the external tag
+ from Stream and determines the corresponding internal tag
+ (by calling Tags.Descendant_Tag(String'Input(Stream),
+ S'Tag) which might raise Tag_Error -- see *note 3.9::)
+ and then dispatches to the subprogram denoted by the
+ Input attribute of the specific type identified by the
+ internal tag; returns that result. If the specific type
+ identified by the internal tag is abstract,
+ Constraint_Error is raised.
+
+34.a/3
+ Ramification: {AI05-0109-1AI05-0109-1} Descendant_Tag will
+ ensure that the tag it returns is covered by T'Class;
+ Tag_Error will be raised if it would not cover T'Class.
+
+35/3
+{AI95-00195-01AI95-00195-01} {AI05-0228-1AI05-0228-1} In the default
+implementation of Read and Input for a composite type, for each scalar
+component that is a discriminant or that has an implicit initial value,
+a check is made that the value returned by Read for the component
+belongs to its subtype. Constraint_Error is raised if this check fails.
+For other scalar components, no check is made. For each component that
+is of an access type, if the implementation can detect that the value
+returned by Read for the component is not a value of its subtype,
+Constraint_Error is raised. If the value is not a value of its subtype
+and this error is not detected, the component has an abnormal value, and
+erroneous execution can result (see *note 13.9.1::). In the default
+implementation of Read for a composite type with defaulted
+discriminants, if the actual parameter of Read is constrained, a check
+is made that the discriminants read from the stream are equal to those
+of the actual parameter. Constraint_Error is raised if this check
+fails.
+
+35.a/3
+ Reason: {AI05-0228-1AI05-0228-1} The check for scalar
+ components that have an implicit initial value is to preserve
+ our Language Design Principle that all objects that have an
+ implicit initial value do not become "deinitialized".
+
+35.b/3
+ Ramification: {AI05-0228-1AI05-0228-1} A scalar component can
+ have an implicit initial value if it has a default_expression,
+ if the component's type has the Default_Value aspect
+ specified, or if the component is that of an array type that
+ has the Default_Component_Value aspect specified.
+
+35.c/3
+ To be honest: {AI05-0228-1AI05-0228-1} An implementation
+ should always be able to detect the error for a null value
+ read into a component of an access subtype with a null
+ exclusion; the "if the implementation can detect" is intended
+ to cover nonnull access values.
+
+36/2
+{AI95-00195-01AI95-00195-01} It is unspecified at which point and in
+which order these checks are performed. In particular, if
+Constraint_Error is raised due to the failure of one of these checks, it
+is unspecified how many stream elements have been read from the stream.
+
+37/1
+{8652/00458652/0045} {AI95-00132-01AI95-00132-01} In the default
+implementation of Read and Input for a type, End_Error is raised if the
+end of the stream is reached before the reading of a value of the type
+is completed.
+
+38/3
+{8652/00408652/0040} {AI95-00108-01AI95-00108-01}
+{AI95-00195-01AI95-00195-01} {AI95-00251-01AI95-00251-01}
+{AI05-0039-1AI05-0039-1} The stream-oriented attributes may be specified
+for any type via an attribute_definition_clause. The subprogram name
+given in such a clause shall statically denote a subprogram that is not
+an abstract subprogram. Furthermore, if a stream-oriented attribute is
+specified for an interface type by an attribute_definition_clause, the
+subprogram name given in the clause shall statically denote a null
+procedure.
+
+38.a/2
+ This paragraph was deleted.{AI95-00195-01AI95-00195-01}
+
+38.a.1/2
+ This paragraph was deleted.{8652/00408652/0040}
+ {AI95-00108-01AI95-00108-01} {AI95-00195-01AI95-00195-01}
+
+38.b/2
+ Discussion: {AI95-00251-01AI95-00251-01} Stream attributes
+ (other than Input) are always null procedures for interface
+ types (they have no components). We need to allow explicit
+ setting of the Read and Write attributes in order that the
+ class-wide attributes like LI'Class'Input can be made
+ available. (In that case, any descendant of the interface
+ type would require available attributes.) But we don't allow
+ any concrete implementation because these don't participate in
+ extensions (unless the interface is the parent type). If we
+ didn't ban concrete implementations, the order of declaration
+ of a pair of interfaces would become significant. For
+ example, if Int1 and Int2 are interfaces with concrete
+ implementations of 'Read, then the following declarations
+ would have different implementations for 'Read:
+
+38.c/2
+ type Con1 is new Int1 and Int2 with null record;
+ type Con2 is new Int2 and Int1 with null record;
+
+38.d/2
+ This would violate our design principle that the order of the
+ specification of the interfaces in a derived_type_definition
+ doesn't matter.
+
+38.e/2
+ Ramification: The Input attribute cannot be specified for an
+ interface. As it is a function, a null procedure is
+ impossible; a concrete function is not possible anyway as any
+ function returning an abstract type must be abstract. And we
+ don't allow specifying stream attributes to be abstract
+ subprograms. This has no impact, as the availability of
+ Int'Class'Input (where Int is a limited interface) depends on
+ whether Int'Read (not Int'Input) is specified. There is no
+ reason to allow Int'Output to be specified, either, but there
+ is equally no reason to disallow it, so we don't have a
+ special rule for that.
+
+38.f/2
+ Discussion: {AI95-00195-01AI95-00195-01} Limited types
+ generally do not have default implementations of the
+ stream-oriented attributes. The rules defining when a
+ stream-oriented attribute is available (see below) determine
+ when an attribute of a limited type is in fact well defined
+ and usable. The rules are designed to maximize the number of
+ cases in which the attributes are usable. For instance, when
+ the language provides a default implementation of an attribute
+ for a limited type based on a specified attribute for the
+ parent type, we want to be able to call that attribute.
+
+38.g/3
+ Aspect Description for Read: Procedure to read a value from a
+ stream for a given type.
+
+38.h/3
+ Aspect Description for Write: Procedure to write a value to a
+ stream for a given type.
+
+38.i/3
+ Aspect Description for Input: Function to read a value from a
+ stream for a given type, including any bounds and
+ discriminants.
+
+38.j/3
+ Aspect Description for Output: Procedure to write a value to a
+ stream for a given type, including any bounds and
+ discriminants.
+
+39/2
+{AI95-00195-01AI95-00195-01} A stream-oriented attribute for a subtype
+of a specific type T is available at places where one of the following
+conditions is true:
+
+40/2
+ * T is nonlimited.
+
+41/2
+ * The attribute_designator is Read (resp. Write) and T is a limited
+ record extension, and the attribute Read (resp. Write) is
+ available for the parent type of T and for the types of all of the
+ extension components.
+
+41.a/2
+ Reason: In this case, the language provides a well-defined
+ default implementation, which we want to be able to call.
+
+42/2
+ * T is a limited untagged derived type, and the attribute was
+ inherited for the type.
+
+42.a/2
+ Reason: Attributes are only inherited for untagged derived
+ types, and surely we want to be able to call inherited
+ attributes.
+
+43/2
+ * The attribute_designator is Input (resp. Output), and T is a
+ limited type, and the attribute Read (resp. Write) is available
+ for T.
+
+43.a/2
+ Reason: The default implementation of Input and Output are
+ based on Read and Write; so if the implementation of Read or
+ Write is good, so is the matching implementation of Input or
+ Output.
+
+44/2
+ * The attribute has been specified via an
+ attribute_definition_clause, and the attribute_definition_clause is
+ visible.
+
+44.a/2
+ Reason: We always want to allow calling a specified attribute.
+ But we don't want availability to break privacy. Therefore,
+ only attributes whose specification can be seen count. Yes,
+ we defined the visibility of an attribute_definition_clause
+ (see *note 8.3::).
+
+45/2
+{AI95-00195-01AI95-00195-01} A stream-oriented attribute for a subtype
+of a class-wide type T'Class is available at places where one of the
+following conditions is true:
+
+46/2
+ * T is nonlimited;
+
+47/2
+ * the attribute has been specified via an
+ attribute_definition_clause, and the attribute_definition_clause is
+ visible; or
+
+48/2
+ * the corresponding attribute of T is available, provided that if T
+ has a partial view, the corresponding attribute is available at the
+ end of the visible part where T is declared.
+
+48.a/2
+ Reason: The rules are stricter for class-wide attributes
+ because (for the default implementation) we must ensure that
+ any specific attribute that might ever be dispatched to is
+ available. Because we require specification of attributes for
+ extensions of limited parent types with available attributes,
+ we can in fact know this. Otherwise, we would not be able to
+ use default class-wide attributes with limited types, a
+ significant limitation.
+
+49/2
+{AI95-00195-01AI95-00195-01} An attribute_reference for one of the
+stream-oriented attributes is illegal unless the attribute is available
+at the place of the attribute_reference. Furthermore, an
+attribute_reference for T'Input is illegal if T is an abstract type.
+
+49.a/2
+ Discussion: Stream attributes always exist. It is illegal to
+ call them in some cases. Having the attributes not be defined
+ for some limited types would seem to be a cleaner solution,
+ but it would lead to contract model problems for limited
+ private types.
+
+49.b/2
+ T'Input is available for abstract types so that T'Class'Input
+ is available. But we certainly don't want to allow calls that
+ could create an object of an abstract type. Remember that
+ T'Class is never abstract, so the above legality rule doesn't
+ apply to it. We don't have to discuss whether the attribute
+ is specified, as it cannot be: any function returning the type
+ would have to be abstract, and we do not allow specifying an
+ attribute with an abstract subprogram.
+
+50/3
+{AI95-00195-01AI95-00195-01} {AI05-0192-1AI05-0192-1} In the
+parameter_and_result_profiles for the default implementations of the
+stream-oriented attributes, the subtype of the Item parameter is the
+base subtype of T if T is a scalar type, and the first subtype
+otherwise. The same rule applies to the result of the Input attribute.
+
+50.a/3
+ Discussion: {AI05-0192-1AI05-0192-1} An inherited stream
+ attribute has a profile as determined by the rules for
+ inheriting primitive subprograms (see *note 13.1:: and *note
+ 3.4::).
+
+51/3
+{AI95-00195-01AI95-00195-01} {AI05-0007-1AI05-0007-1} For an
+attribute_definition_clause specifying one of these attributes, the
+subtype of the Item parameter shall be the first subtype or the base
+subtype if scalar, and the first subtype if not scalar. The same rule
+applies to the result of the Input function.
+
+51.a/2
+ Reason: This is to simplify implementation.
+
+51.b/3
+ Ramification: The view of the type at the point of the
+ attribute_definition_clause determines whether the base
+ subtype is allowed. Thus, for a scalar type with a partial
+ view (which is never scalar), whether the base subtype is
+ allowed is determined by whether the
+ attribute_definition_clause occurs before or after the full
+ definition of the scalar type.
+
+52/3
+{AI95-00366-01AI95-00366-01} {AI05-0065-1AI05-0065-1} [A type is said to
+support external streaming if Read and Write attributes are provided for
+sending values of such a type between active partitions, with Write
+marshalling the representation, and Read unmarshalling the
+representation.] A limited type supports external streaming only if it
+has available Read and Write attributes. A type with a part that is of
+a nonremote access type supports external streaming only if that access
+type or the type of some part that includes the access type component,
+has Read and Write attributes that have been specified via an
+attribute_definition_clause, and that attribute_definition_clause is
+visible. [An anonymous access type does not support external streaming.
+]All other types (including remote access types, see *note E.2.2::)
+support external streaming.
+
+52.a/3
+ Ramification: A limited type with a part that is of a
+ nonremote access type needs to satisfy both rules.
+
+ _Erroneous Execution_
+
+53/2
+{AI95-00279-01AI95-00279-01} {AI95-00344-01AI95-00344-01} If the
+internal tag returned by Descendant_Tag to T'Class'Input identifies a
+type that is not library-level and whose tag has not been created, or
+does not exist in the partition at the time of the call, execution is
+erroneous.
+
+53.a/2
+ Ramification: The definition of Descendant_Tag prevents such a
+ tag from being provided to T'Class'Input if T is a
+ library-level type. However, this rule is needed for nested
+ tagged types.
+
+ _Implementation Requirements_
+
+54/1
+{8652/00408652/0040} {AI95-00108-01AI95-00108-01} For every subtype S of
+a language-defined nonlimited specific type T, the output generated by
+S'Output or S'Write shall be readable by S'Input or S'Read,
+respectively. This rule applies across partitions if the implementation
+conforms to the Distributed Systems Annex.
+
+55/3
+{AI95-00195-01AI95-00195-01} {AI05-0092-1AI05-0092-1} If
+Constraint_Error is raised during a call to Read because of failure of
+one the above checks, the implementation shall ensure that the
+discriminants of the actual parameter of Read are not modified.
+
+ _Implementation Permissions_
+
+56/3
+{AI95-00195-01AI95-00195-01} {AI05-0092-1AI05-0092-1} The number of
+calls performed by the predefined implementation of the stream-oriented
+attributes on the Read and Write operations of the stream type is
+unspecified. An implementation may take advantage of this permission to
+perform internal buffering. However, all the calls on the Read and
+Write operations of the stream type needed to implement an explicit
+invocation of a stream-oriented attribute shall take place before this
+invocation returns. An explicit invocation is one appearing explicitly
+in the program text, possibly through a generic instantiation (see *note
+12.3::).
+
+56.1/3
+{AI05-0023-1AI05-0023-1} {AI05-0264-1AI05-0264-1} If T is a
+discriminated type and its discriminants have defaults, then in two
+cases an execution of the default implementation of S'Read is not
+required to create an anonymous object of type T: If the discriminant
+values that are read in are equal to the corresponding discriminant
+values of Item, then no object of type T need be created and Item may be
+used instead. If they are not equal and Item is a constrained variable,
+then Constraint_Error may be raised at that point, before any further
+values are read from the stream and before the object of type T is
+created.
+
+56.2/3
+{AI05-0023-1AI05-0023-1} A default implementation of S'Input that calls
+the default implementation of S'Read may create a constrained anonymous
+object with discriminants that match those in the stream.
+
+56.a/3
+ Implementation Note: This allows the combined executions of
+ S'Input and S'Read to create one object of type T instead of
+ two. If this option is exercised, then:
+
+56.b/3
+ * The discriminants are read from the stream by S'Input,
+ not S'Read.
+
+56.c/3
+ * S'Input declares an object of type T constrained by the
+ discriminants read from the stream, not an unconstrained
+ object.
+
+56.d/3
+ * The discriminant values that S'Read would normally have
+ read from the stream are read from Item instead.
+
+56.e/3
+ * The permissions of the preceding paragraph then apply and
+ no object of type T need be created by the execution of
+ S'Read.
+
+ NOTES
+
+57
+ 40 For a definite subtype S of a type T, only T'Write and T'Read
+ are needed to pass an arbitrary value of the subtype through a
+ stream. For an indefinite subtype S of a type T, T'Output and
+ T'Input will normally be needed, since T'Write and T'Read do not
+ pass bounds, discriminants, or tags.
+
+58
+ 41 User-specified attributes of S'Class are not inherited by other
+ class-wide types descended from S.
+
+ _Examples_
+
+59
+Example of user-defined Write attribute:
+
+60/2
+ {AI95-00441-01AI95-00441-01} procedure My_Write(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+ Item : My_Integer'Base);
+ for My_Integer'Write use My_Write;
+
+60.a
+ Discussion: Example of network input/output using input output
+ attributes:
+
+60.b
+ with Ada.Streams; use Ada.Streams;
+ generic
+ type Msg_Type(<>) is private;
+ package Network_IO is
+ -- Connect/Disconnect are used to establish the stream
+ procedure Connect(...);
+ procedure Disconnect(...);
+
+60.c
+ -- Send/Receive transfer messages across the network
+ procedure Send(X : in Msg_Type);
+ function Receive return Msg_Type;
+ private
+ type Network_Stream is new Root_Stream_Type with ...
+ procedure Read(...); -- define Read/Write for Network_Stream
+ procedure Write(...);
+ end Network_IO;
+
+60.d
+ with Ada.Streams; use Ada.Streams;
+ package body Network_IO is
+ Current_Stream : aliased Network_Stream;
+ . . .
+ procedure Connect(...) is ...;
+ procedure Disconnect(...) is ...;
+
+60.e
+ procedure Send(X : in Msg_Type) is
+ begin
+ Msg_Type'Output(Current_Stream'Access, X);
+ end Send;
+
+60.f
+ function Receive return Msg_Type is
+ begin
+ return Msg_Type'Input(Current_Stream'Access);
+ end Receive;
+ end Network_IO;
+
+ _Inconsistencies With Ada 95_
+
+60.g/2
+ {8652/00408652/0040} {AI95-00108-01AI95-00108-01} Corrigendum:
+ Clarified how the default implementation for stream attributes
+ is determined (eliminating conflicting language). The new
+ wording provides that attributes for type extensions are
+ created by composing the parent's attribute with those for the
+ extension components if any. If a program was written
+ assuming that the extension components were not included in
+ the stream (as in original Ada 95), it would fail to work in
+ the language as corrected by the Corrigendum.
+
+60.h/2
+ {AI95-00195-01AI95-00195-01} Amendment Correction: Explicitly
+ provided a permission that the number of calls to the
+ underlying stream Read and Write operations may differ from
+ the number determined by the canonical operations. If Ada 95
+ code somehow depended on the number of calls to Read or Write,
+ it could fail with an Ada 2005 implementation. Such code is
+ likely to be very rare; moreover, such code is really wrong,
+ as the permission applies to Ada 95 as well.
+
+ _Extensions to Ada 95_
+
+60.i/2
+ {AI95-00270-01AI95-00270-01} The Stream_Size attribute is new.
+ It allows specifying the number of bits that will be streamed
+ for a type. The Implementation Advice involving this also was
+ changed; this is not incompatible because Implementation
+ Advice does not have to be followed.
+
+60.j/2
+ {8652/00408652/0040} {AI95-00108-01AI95-00108-01}
+ {AI95-00195-01AI95-00195-01} {AI95-00444-01AI95-00444-01}
+ Corrigendum: Limited types may have default constructed
+ attributes if all of the parent and (for extensions) extension
+ components have available attributes. Ada 2005 adds the
+ notion of availability to patch up some holes in the
+ Corrigendum model.
+
+ _Wording Changes from Ada 95_
+
+60.k/2
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} Corrigendum:
+ Added wording to specify that these are operational
+ attributes.
+
+60.l/2
+ {8652/00458652/0045} {AI95-00132-01AI95-00132-01} Corrigendum:
+ Clarified that End_Error is raised by the default
+ implementation of Read and Input if the end of the stream is
+ reached. (The result could have been abnormal without this
+ clarification, thus this is not an inconsistency, as the
+ programmer could not have depended on the previous behavior.)
+
+60.m/2
+ {AI95-00195-01AI95-00195-01} Clarified that the default
+ implementation of S'Input does normal initialization on the
+ object that it passes to S'Read.
+
+60.n/2
+ {AI95-00195-01AI95-00195-01} Explicitly stated that what is
+ read from a stream when a required check fails is unspecified.
+
+60.o/2
+ {AI95-00251-01AI95-00251-01} Defined availability and default
+ implementations for types with progenitors.
+
+60.p/2
+ {AI95-00279-01AI95-00279-01} Specified that Constraint_Error
+ is raised if the internal tag retrieved for S'Class'Input is
+ for some type not covered by S'Class or is abstract. We also
+ explicitly state that the program is erroneous if the tag has
+ not been created or does not currently exist in the partition.
+ (Ada 95 did not specify what happened in these cases; it's
+ very unlikely to have provided some useful result, so this is
+ not considered an inconsistency.)
+
+60.q/2
+ {AI95-00344-01AI95-00344-01} Added wording to support nested
+ type extensions. S'Input and S'Output always raise Tag_Error
+ for such extensions, and such extensions were not permitted in
+ Ada 95, so this is neither an extension nor an
+ incompatibility.
+
+60.r/2
+ {AI95-00366-01AI95-00366-01} Defined supports external
+ streaming to put all of the rules about "good" stream
+ attributes in one place. This is used for distribution and
+ for defining pragma Pure.
+
+60.s/2
+ {AI95-00441-01AI95-00441-01} Added the not null qualifier to
+ the first parameter of all of the stream attributes, so that
+ the semantics doesn't change between Ada 95 and Ada 2005.
+ This change is compatible, because mode conformance is
+ required for subprograms specified as stream attributes, and
+ null_exclusions are not considered for mode conformance.
+
+60.t/2
+ {AI95-00444-01AI95-00444-01} Improved the wording to make it
+ clear that we don't define the default implementations of
+ attributes that cannot be called (that is, aren't
+ "available"). Also clarified when inheritance takes place.
+
+ _Incompatibilities With Ada 2005_
+
+60.u/3
+ {AI05-0039-1AI05-0039-1} Correction: Added a requirement that
+ stream attributes be specified by a static subprogram name
+ rather than a dynamic expression. Expressions cannot provide
+ any useful functionality because of the freezing rules, and
+ the possibility of them complicates implementations. Only
+ pathological programs should be affected.
+
+ _Extensions to Ada 2005_
+
+60.v/3
+ {AI05-0007-1AI05-0007-1} Correction: Stream attributes for
+ scalar types can be specified with subprograms that take the
+ first subtype as well as the base type. This eliminates
+ confusion about which subtype is appropriate for attributes
+ specified for partial views whose full type is a scalar type.
+ It also eliminates a common user error (forgetting 'Base).
+
+ _Wording Changes from Ada 2005_
+
+60.w/3
+ {AI05-0023-1AI05-0023-1} Correction: Corrected the definition
+ of the default version S'Read and S'Input to be well-defined
+ if S is a discriminated type with defaulted discriminants and
+ some components require initialization and/or finalizations.
+
+60.x/3
+ {AI05-0065-1AI05-0065-1} Correction: Defined remote access
+ types to support external streaming, since that is their
+ purpose.
+
+60.y/3
+ {AI05-0109-1AI05-0109-1} Correction: Removed a misleading
+ phrase which implies that Constraint_Error is raised for
+ internal tags of the wrong type, when Tag_Error should be
+ raised for such tags.
+
+60.z/3
+ {AI05-0139-2AI05-0139-2} Clarified that arrays with convention
+ Fortran are written in column-major order, rather then
+ row-major order. This is necessary in order that streaming of
+ Fortran arrays is efficient.
+
+60.aa/3
+ {AI05-0192-1AI05-0192-1} Correction: Clarified that the
+ profile of an inherited stream attribute is as defined for an
+ inherited primitive subprogram, while the default
+ implementation of the same attribute might have a different
+ profile.
+
+60.bb/3
+ {AI05-0194-1AI05-0194-1} Correction: Clarified that
+ Stream_Size has no effect on and is not effected by
+ user-defined stream attributes.
+
+\1f
+File: aarm2012.info, Node: 13.14, Prev: 13.13, Up: 13
+
+13.14 Freezing Rules
+====================
+
+1/3
+{AI05-0299-1AI05-0299-1} [This subclause defines a place in the program
+text where each declared entity becomes "frozen." A use of an entity,
+such as a reference to it by name, or (for a type) an expression of the
+type, causes freezing of the entity in some contexts, as described
+below. The Legality Rules forbid certain kinds of uses of an entity in
+the region of text where it is frozen.]
+
+1.a
+ Reason: This concept has two purposes: a compile-time one and
+ a run-time one.
+
+1.b
+ The compile-time purpose of the freezing rules comes from the
+ fact that the evaluation of static expressions depends on
+ overload resolution, and overload resolution sometimes depends
+ on the value of a static expression. (The dependence of
+ static evaluation upon overload resolution is obvious. The
+ dependence in the other direction is more subtle. There are
+ three rules that require static expressions in contexts that
+ can appear in declarative places: The expression in an
+ attribute_designator shall be static. In a record aggregate,
+ variant-controlling discriminants shall be static. In an
+ array aggregate with more than one named association, the
+ choices shall be static. The compiler needs to know the value
+ of these expressions in order to perform overload resolution
+ and legality checking.) We wish to allow a compiler to
+ evaluate static expressions when it sees them in a single pass
+ over the compilation_unit. The freezing rules ensure that.
+
+1.c
+ The run-time purpose of the freezing rules is called the
+ "linear elaboration model." This means that declarations are
+ elaborated in the order in which they appear in the program
+ text, and later elaborations can depend on the results of
+ earlier ones. The elaboration of the declarations of certain
+ entities requires run-time information about the
+ implementation details of other entities. The freezing rules
+ ensure that this information has been calculated by the time
+ it is used. For example, suppose the initial value of a
+ constant is the result of a function call that takes a
+ parameter of type T. In order to pass that parameter, the size
+ of type T has to be known. If T is composite, that size might
+ be known only at run time.
+
+1.d
+ (Note that in these discussions, words like "before" and
+ "after" generally refer to places in the program text, as
+ opposed to times at run time.)
+
+1.e
+ Discussion: The "implementation details" we're talking about
+ above are:
+
+1.f
+ * For a tagged type, the implementations of all the
+ primitive subprograms of the type -- that is (in the
+ canonical implementation model), the contents of the type
+ descriptor, which contains pointers to the code for each
+ primitive subprogram.
+
+1.g
+ * For a type, the full type declaration of any parts
+ (including the type itself) that are private.
+
+1.h
+ * For a deferred constant, the full constant declaration,
+ which gives the constant's value. (Since this
+ information necessarily comes after the constant's type
+ and subtype are fully known, there's no need to worry
+ about its type or subtype.)
+
+1.i
+ * For any entity, representation information specified by
+ the user via representation items. Most representation
+ items are for types or subtypes; however, various other
+ kinds of entities, such as objects and subprograms, are
+ possible.
+
+1.j/3
+ {AI05-0005-1AI05-0005-1} Similar issues arise for incomplete
+ types. However, we do not use freezing to prevent premature
+ access; incomplete types have different, more severe,
+ restrictions. Similar issues also arise for subprograms,
+ protected operations, tasks and generic units. However, we do
+ not use freezing to prevent premature access for those,
+ either; *note 3.11:: prevents problems with run-time
+ Elaboration_Checks. Even so, freezing is used for these
+ entities to prevent giving representation items too late (that
+ is, after uses that require representation information, such
+ as calls).
+
+ _Language Design Principles_
+
+1.k
+ An evaluable construct should freeze anything that's needed to
+ evaluate it.
+
+1.l
+ However, if the construct is not evaluated where it appears,
+ let it cause freezing later, when it is evaluated. This is
+ the case for default_expressions and default_names. (Formal
+ parameters, generic formal parameters, and components can have
+ default_expressions or default_names.)
+
+1.m
+ The compiler should be allowed to evaluate static expressions
+ without knowledge of their context. (I.e. there should not
+ be any special rules for static expressions that happen to
+ occur in a context that requires a static expression.)
+
+1.n
+ Compilers should be allowed to evaluate static expressions
+ (and record the results) using the run-time representation of
+ the type. For example, suppose Color'Pos(Red) = 1, but the
+ internal code for Red is 37. If the value of a static
+ expression is Red, some compilers might store 1 in their
+ symbol table, and other compilers might store 37. Either
+ compiler design should be feasible.
+
+1.o
+ Compilers should never be required to detect erroneousness or
+ exceptions at compile time (although it's very nice if they
+ do). This implies that we should not require code-generation
+ for a nonstatic expression of type T too early, even if we can
+ prove that that expression will be erroneous, or will raise an
+ exception.
+
+1.p
+ Here's an example (modified from AI83-00039, Example 3):
+
+1.q
+ type T is
+ record
+ ...
+ end record;
+ function F return T;
+ function G(X : T) return Boolean;
+ Y : Boolean := G(F); -- doesn't force T in Ada 83
+ for T use
+ record
+ ...
+ end record;
+
+1.r
+ AI83-00039 says this is legal. Of course, it raises
+ Program_Error because the function bodies aren't elaborated
+ yet. A one-pass compiler has to generate code for an
+ expression of type T before it knows the representation of T.
+ Here's a similar example, which AI83-00039 also says is legal:
+
+1.s
+ package P is
+ type T is private;
+ function F return T;
+ function G(X : T) return Boolean;
+ Y : Boolean := G(F); -- doesn't force T in Ada 83
+ private
+ type T is
+ record
+ ...
+ end record;
+ end P;
+
+1.t
+ If T's size were dynamic, that size would be stored in some
+ compiler-generated dope; this dope would be initialized at the
+ place of the full type declaration. However, the generated
+ code for the function calls would most likely allocate a temp
+ of the size specified by the dope before checking for
+ Program_Error. That dope would contain uninitialized junk,
+ resulting in disaster. To avoid doing that, the compiler
+ would have to determine, at compile time, that the expression
+ will raise Program_Error.
+
+1.u
+ This is silly. If we're going to require compilers to detect
+ the exception at compile time, we might as well formulate the
+ rule as a legality rule.
+
+1.v
+ Compilers should not be required to generate code to load the
+ value of a variable before the address of the variable has
+ been determined.
+
+1.w
+ After an entity has been frozen, no further requirements may
+ be placed on its representation (such as by a representation
+ item or a full_type_declaration).
+
+2
+The freezing of an entity occurs at one or more places (freezing points)
+in the program text where the representation for the entity has to be
+fully determined. Each entity is frozen from its first freezing point
+to the end of the program text (given the ordering of compilation units
+defined in *note 10.1.4::).
+
+2.a
+ Ramification: The "representation" for a subprogram includes
+ its calling convention and means for referencing the
+ subprogram body, either a "link-name" or specified address.
+ It does not include the code for the subprogram body itself,
+ nor its address if a link-name is used to reference the body.
+
+2.1/3
+{AI05-0019-1AI05-0019-1} {AI05-0299-1AI05-0299-1} This subclause also
+defines a place in the program text where the profile of each declared
+callable entity becomes frozen. A use of a callable entity causes
+freezing of its profile in some contexts, as described below. At the
+place where the profile of a callable entity becomes frozen, the entity
+itself becomes frozen.
+
+3/3
+{8652/00148652/0014} {AI05-0017-1AI05-0017-1} {AI05-0019-1AI05-0019-1}
+The end of a declarative_part, protected_body, or a declaration of a
+library package or generic library package, causes freezing of each
+entity and profile declared within it, except for incomplete types. A
+noninstance body other than a renames-as-body causes freezing of each
+entity and profile declared before it within the same declarative_part
+that is not an incomplete type; it only causes freezing of an incomplete
+type if the body is within the immediate scope of the incomplete type.
+
+3.a
+ Discussion: This is worded carefully to handle nested packages
+ and private types. Entities declared in a nested
+ package_specification will be frozen by some containing
+ construct.
+
+3.b/3
+ {AI05-0017-1AI05-0017-1} An incomplete type declared in the
+ private part of a library package_specification can be
+ completed in the body. For other incomplete types (and in the
+ bodies of library packages), the completion of the type will
+ be frozen at the end of the package or declarative_part, and
+ that will freeze the incomplete view as well.
+
+3.b.1/3
+ {AI05-0017-1AI05-0017-1} The reason we have to worry about
+ freezing of incomplete types is to prevent premature uses of
+ the types in dispatching calls. Such uses may need access to
+ the tag of the type, and the type has to be frozen to know
+ where the tag is stored.
+
+3.c/3
+ Ramification: {AI05-0229-1AI05-0229-1} The part about bodies
+ does not say immediately within. A renaming-as-body does not
+ have this property. Nor does an imported body
+
+3.d
+ Reason: The reason bodies cause freezing is because we want
+ proper_bodies and body_stubs to be interchangeable -- one
+ should be able to move a proper_body to a subunit, and
+ vice-versa, without changing the semantics. Clearly, anything
+ that should cause freezing should do so even if it's inside a
+ proper_body. However, if we make it a body_stub, then the
+ compiler can't see that thing that should cause freezing. So
+ we make body_stubs cause freezing, just in case they contain
+ something that should cause freezing. But that means we need
+ to do the same for proper_bodies.
+
+3.e
+ Another reason for bodies to cause freezing, there could be an
+ added implementation burden if an entity declared in an
+ enclosing declarative_part is frozen within a nested body,
+ since some compilers look at bodies after looking at the
+ containing declarative_part.
+
+3.f/3
+ {AI05-0177-1AI05-0177-1} Note that "body" includes
+ null_procedure_declarations and
+ expression_function_declarations when those are used as
+ completions, as well as entry_bodys (see *note 3.11.1::).
+ These all cause freezing, along with proper_bodys and
+ body_stubs.
+
+4/1
+{8652/00468652/0046} {AI95-00106-01AI95-00106-01} A construct that
+(explicitly or implicitly) references an entity can cause the freezing
+of the entity, as defined by subsequent paragraphs. At the place where
+a construct causes freezing, each name, expression,
+implicit_dereference[, or range] within the construct causes freezing:
+
+4.a
+ Ramification: Note that in the sense of this paragraph, a
+ subtype_mark "references" the denoted subtype, but not the
+ type.
+
+5/3
+ * {AI05-0213-1AI05-0213-1} The occurrence of a generic_instantiation
+ causes freezing, except that a name which is a generic actual
+ parameter whose corresponding generic formal parameter is a formal
+ incomplete type (see *note 12.5.1::) does not cause freezing. In
+ addition, if a parameter of the instantiation is defaulted, the
+ default_expression or default_name for that parameter causes
+ freezing.
+
+5.a/3
+ Ramification: {AI05-0213-1AI05-0213-1} Thus, an actual
+ parameter corresponding to a formal incomplete type parameter
+ may denote an incomplete or private type which is not
+ completely defined at the point of the generic_instantiation.
+
+6
+ * The occurrence of an object_declaration that has no corresponding
+ completion causes freezing.
+
+6.a
+ Ramification: Note that this does not include a
+ formal_object_declaration.
+
+7
+ * The declaration of a record extension causes freezing of the parent
+ subtype.
+
+7.a
+ Ramification: This combined with another rule specifying that
+ primitive subprogram declarations shall precede freezing
+ ensures that all descendants of a tagged type implement all of
+ its dispatching operations.
+
+7.b/2
+ {AI95-00251-01AI95-00251-01} The declaration of a private
+ extension does not cause freezing. The freezing is deferred
+ until the full type declaration, which will necessarily be for
+ a record extension, task, or protected type (the latter only
+ for a limited private extension derived from an interface).
+
+7.1/2
+ * {AI95-00251-01AI95-00251-01} The declaration of a record extension,
+ interface type, task unit, or protected unit causes freezing of any
+ progenitor types specified in the declaration.
+
+7.b.1/2
+ Reason: This rule has the same purpose as the one above:
+ ensuring that all descendants of an interface tagged type
+ implement all of its dispatching operations. As with the
+ previous rule, a private extension does not freeze its
+ progenitors; the full type declaration (which must have the
+ same progenitors) will do that.
+
+7.b.2/2
+ Ramification: An interface type can be a parent as well as a
+ progenitor; these rules are similar so that the location of an
+ interface in a record extension does not have an effect on the
+ freezing of the interface type.
+
+7.2/3
+ * {AI05-0183-1AI05-0183-1} At the freezing point of the entity
+ associated with an aspect_specification, any expressions or names
+ within the aspect_specification cause freezing. Any static
+ expressions within an aspect_specification also cause freezing at
+ the end of the immediately enclosing declaration list.
+
+8/3
+{8652/00468652/0046} {AI95-00106-01AI95-00106-01}
+{AI05-0177-1AI05-0177-1} {AI05-0183-1AI05-0183-1} A static expression
+(other than within an aspect_specification) causes freezing where it
+occurs. An object name or nonstatic expression causes freezing where it
+occurs, unless the name or expression is part of a default_expression, a
+default_name, the expression of an expression function, an
+aspect_specification, or a per-object expression of a component's
+constraint, in which case, the freezing occurs later as part of another
+construct or at the freezing point of an associated entity.
+
+8.1/3
+{8652/00468652/0046} {AI95-00106-01AI95-00106-01}
+{AI05-0019-1AI05-0019-1} An implicit call freezes the same entities and
+profiles that would be frozen by an explicit call. This is true even if
+the implicit call is removed via implementation permissions.
+
+8.2/1
+{8652/00468652/0046} {AI95-00106-01AI95-00106-01} If an expression is
+implicitly converted to a type or subtype T, then at the place where the
+expression causes freezing, T is frozen.
+
+9
+The following rules define which entities are frozen at the place where
+a construct causes freezing:
+
+10
+ * At the place where an expression causes freezing, the type of the
+ expression is frozen, unless the expression is an enumeration
+ literal used as a discrete_choice of the array_aggregate (*note
+ 4.3.3: S0113.) of an enumeration_representation_clause (*note 13.4:
+ S0310.).
+
+10.a
+ Reason: We considered making enumeration literals never cause
+ freezing, which would be more upward compatible, but examples
+ like the variant record aggregate (Discrim => Red, ...)
+ caused us to change our mind. Furthermore, an enumeration
+ literal is a static expression, so the implementation should
+ be allowed to represent it using its representation.
+
+10.b
+ Ramification: The following pathological example was legal in
+ Ada 83, but is illegal in Ada 95:
+
+10.c
+ package P1 is
+ type T is private;
+ package P2 is
+ type Composite(D : Boolean) is
+ record
+ case D is
+ when False => Cf : Integer;
+ when True => Ct : T;
+ end case;
+ end record;
+ end P2;
+ X : Boolean := P2."="( (False,1), (False,1) );
+ private
+ type T is array(1..Func_Call) of Integer;
+ end;
+
+10.d
+ In Ada 95, the declaration of X freezes Composite (because it
+ contains an expression of that type), which in turn freezes T
+ (even though Ct does not exist in this particular case). But
+ type T is not completely defined at that point, violating the
+ rule that a type shall be completely defined before it is
+ frozen. In Ada 83, on the other hand, there is no occurrence
+ of the name T, hence no forcing occurrence of T.
+
+10.1/3
+ * {AI05-0019-1AI05-0019-1} {AI05-0177-1AI05-0177-1} At the place
+ where a function call causes freezing, the profile of the function
+ is frozen. Furthermore, if a parameter of the call is defaulted,
+ the default_expression for that parameter causes freezing. If the
+ function call is to an expression function, the expression of the
+ expression function causes freezing.
+
+10.e/3
+ Reason: {AI05-0019-1AI05-0019-1} This is the important rule
+ for profile freezing: a call freezes the profile. That's
+ because generating the call will need to know how the
+ parameters are passed, and that will require knowing details
+ of the types. Other uses of subprograms do not need to know
+ about the parameters, and thus only freeze the subprogram, and
+ not the profile.
+
+10.f/3
+ Note that we don't need to consider procedure or entry calls,
+ since a body freezes everything that precedes it, and the end
+ of a declarative part freezes everything in the declarative
+ part.
+
+10.g/3
+ Ramification: {AI05-0177-1AI05-0177-1} Freezing of the
+ expression of an expression function only needs to be
+ considered when the expression function is in the same
+ compilation unit and there are no intervening bodies; the end
+ of a declarative_part or library package freezes everything in
+ it, and a body freezes everything declared before it.
+
+10.2/3
+ * {AI05-0019-1AI05-0019-1} {AI05-0177-1AI05-0177-1}
+ {AI05-0296-1AI05-0296-1} At the place where a generic_instantiation
+ causes freezing of a callable entity, the profile of that entity is
+ frozen unless the formal subprogram corresponding to the callable
+ entity has a parameter or result of a formal untagged incomplete
+ type; if the callable entity is an expression function, the
+ expression of the expression function causes freezing.
+
+10.h/3
+ Reason: Elaboration of the generic might call the actual for
+ one of its formal subprograms, so we need to know the profile
+ and (for an expression function) expression.
+
+10.3/3
+ * {AI05-0177-1AI05-0177-1} At the place where a use of the Access or
+ Unchecked_Access attribute whose prefix denotes an expression
+ function causes freezing, the expression of the expression function
+ causes freezing.
+
+10.i/3
+ Reason: This is needed to avoid calls to unfrozen expressions.
+ Consider:
+
+10.j/3
+ package Pack is
+
+10.k/3
+ type Flub is range 0 .. 100;
+
+10.l/3
+ function Foo (A : in Natural) return Natural is
+ (A + Flub'Size); -- The expression is not frozen here.
+
+10.m/3
+ type Bar is access function Foo (A : in Natural) return Natural;
+
+10.n/3
+ P : Bar := Foo'Access; -- (A)
+
+10.o/3
+ Val : Natural := P.all(5); -- (B)
+
+10.p/3
+ end Pack;
+
+10.q/3
+ If point (A) did not freeze the expression of Foo (which
+ freezes Flub), then the call at point (B) would be depending
+ on the aspects of the unfrozen type Flub. That would be bad.
+
+11
+ * At the place where a name causes freezing, the entity denoted by
+ the name is frozen, unless the name is a prefix of an expanded
+ name; at the place where an object name causes freezing, the
+ nominal subtype associated with the name is frozen.
+
+11.a/2
+ Ramification: {AI95-00114-01AI95-00114-01} This only matters
+ in the presence of deferred constants or access types; an
+ object_declaration other than a deferred constant declaration
+ causes freezing of the nominal subtype, plus all component
+ junk.
+
+11.b/1
+ This paragraph was deleted.{8652/00468652/0046}
+ {AI95-00106-01AI95-00106-01}
+
+11.1/1
+ * {8652/00468652/0046} {AI95-00106-01AI95-00106-01} At the place
+ where an implicit_dereference causes freezing, the nominal subtype
+ associated with the implicit_dereference is frozen.
+
+11.c/2
+ Discussion: This rule ensures that X.D freezes the same
+ entities that X.all.D does. Note that an implicit_dereference
+ is neither a name nor expression by itself, so it isn't
+ covered by other rules.
+
+12
+ * [ At the place where a range causes freezing, the type of the range
+ is frozen.]
+
+12.a
+ Proof: This is consequence of the facts that expressions
+ freeze their type, and the Range attribute is defined to be
+ equivalent to a pair of expressions separated by "..".}
+
+13
+ * At the place where an allocator causes freezing, the designated
+ subtype of its type is frozen. If the type of the allocator is a
+ derived type, then all ancestor types are also frozen.
+
+13.a
+ Ramification: Allocators also freeze the named subtype, as a
+ consequence of other rules.
+
+13.b
+ The ancestor types are frozen to prevent things like this:
+
+13.c
+ type Pool_Ptr is access System.Storage_Pools.Root_Storage_Pool'Class;
+ function F return Pool_Ptr;
+
+13.d
+ package P is
+ type A1 is access Boolean;
+ type A2 is new A1;
+ type A3 is new A2;
+ X : A3 := new Boolean; -- Don't know what pool yet!
+ for A1'Storage_Pool use F.all;
+ end P;
+
+13.e
+ This is necessary because derived access types share their
+ parent's pool.
+
+14/3
+ * {AI05-0019-1AI05-0019-1} At the place where a profile is frozen,
+ each subtype of the profile is frozen. If the corresponding
+ callable entity is a member of an entry family, the index subtype
+ of the family is frozen.
+
+14.a/3
+ This paragraph was deleted.
+
+15
+ * At the place where a subtype is frozen, its type is frozen. At the
+ place where a type is frozen, any expressions or names within the
+ full type definition cause freezing; the first subtype, and any
+ component subtypes, index subtypes, and parent subtype of the type
+ are frozen as well. For a specific tagged type, the corresponding
+ class-wide type is frozen as well. For a class-wide type, the
+ corresponding specific type is frozen as well.
+
+15.a
+ Ramification: Freezing a type needs to freeze its first
+ subtype in order to preserve the property that the
+ subtype-specific aspects of statically matching subtypes are
+ the same.
+
+15.b
+ Freezing an access type does not freeze its designated
+ subtype.
+
+15.1/3
+ * {AI95-00341-01AI95-00341-01} {AI05-0019-1AI05-0019-1} At the place
+ where a specific tagged type is frozen, the primitive subprograms
+ of the type are frozen. At the place where a type is frozen, any
+ subprogram named in an attribute_definition_clause for the type is
+ frozen.
+
+15.c/2
+ Reason: We have a language design principle that all of the
+ details of a specific tagged type are known at its freezing
+ point. But that is only true if the primitive subprograms are
+ frozen at this point as well. Late changes of Import and
+ address clauses violate the principle.
+
+15.d/2
+ Implementation Note: This rule means that no implicit call to
+ Initialize or Adjust can freeze a subprogram (the type and
+ thus subprograms would have been frozen at worst at the same
+ point).
+
+15.e/3
+ Discussion: {AI05-0019-1AI05-0019-1} The second sentence is
+ the rule that makes it possible to check that only subprograms
+ with convention Ada are specified in
+ attribute_definition_clauses without jumping through hoops.
+
+ _Legality Rules_
+
+16
+[The explicit declaration of a primitive subprogram of a tagged type
+shall occur before the type is frozen (see *note 3.9.2::).]
+
+16.a
+ Reason: This rule is needed because (1) we don't want people
+ dispatching to things that haven't been declared yet, and (2)
+ we want to allow tagged type descriptors to be static
+ (allocated statically, and initialized to link-time-known
+ symbols). Suppose T2 inherits primitive P from T1, and then
+ overrides P. Suppose P is called before the declaration of the
+ overriding P. What should it dispatch to? If the answer is
+ the new P, we've violated the first principle above. If the
+ answer is the old P, we've violated the second principle. (A
+ call to the new one necessarily raises Program_Error, but
+ that's beside the point.)
+
+16.b
+ Note that a call upon a dispatching operation of type T will
+ freeze T.
+
+16.c
+ We considered applying this rule to all derived types, for
+ uniformity. However, that would be upward incompatible, so we
+ rejected the idea. As in Ada 83, for an untagged type, the
+ above call upon P will call the old P (which is arguably
+ confusing).
+
+16.d/3
+ To be honest: {AI05-0222-1AI05-0222-1} This rule only applies
+ to "original" declarations and not to the completion of a
+ primitive subprogram, even though a completion is technically
+ an explicit declaration, and it may declare a primitive
+ subprogram.
+
+17
+[A type shall be completely defined before it is frozen (see *note
+3.11.1:: and *note 7.3::).]
+
+18
+[The completion of a deferred constant declaration shall occur before
+the constant is frozen (see *note 7.4::).]
+
+18.a/3
+ Proof: {AI95-00114-01AI95-00114-01} {AI05-0299-1AI05-0299-1}
+ The above Legality Rules are stated "officially" in the
+ referenced subclauses.
+
+19/1
+{8652/00098652/0009} {AI95-00137-01AI95-00137-01} An operational or
+representation item that directly specifies an aspect of an entity shall
+appear before the entity is frozen (see *note 13.1::).
+
+19.a/1
+ Discussion: {8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+ From RM83-13.1(7). The wording here forbids freezing within
+ the aspect_clause itself, which was not true of the Ada 83
+ wording. The wording of this rule is carefully written to
+ work properly for type-related representation items. For
+ example, an enumeration_representation_clause (*note 13.4:
+ S0310.) is illegal after the type is frozen, even though the
+ _clause refers to the first subtype.
+
+19.a.1/2
+ {AI95-00114-01AI95-00114-01} The above Legality Rule is stated
+ for types and subtypes in *note 13.1::, but the rule here
+ covers all other entities as well.
+
+19.b/2
+ This paragraph was deleted.{AI95-00114-01AI95-00114-01}
+
+19.c
+ Discussion: Here's an example that illustrates when freezing
+ occurs in the presence of defaults:
+
+19.d
+ type T is ...;
+ function F return T;
+ type R is
+ record
+ C : T := F;
+ D : Boolean := F = F;
+ end record;
+ X : R;
+
+19.e
+ Since the elaboration of R's declaration does not allocate
+ component C, there is no need to freeze C's subtype at that
+ place. Similarly, since the elaboration of R does not
+ evaluate the default_expression "F = F", there is no need to
+ freeze the types involved at that point. However, the
+ declaration of X does need to freeze these things. Note that
+ even if component C did not exist, the elaboration of the
+ declaration of X would still need information about T -- even
+ though D is not of type T, its default_expression requires
+ that information.
+
+19.f/3
+ Ramification: {AI05-0299-1AI05-0299-1} Although we define
+ freezing in terms of the program text as a whole (i.e. after
+ applying the rules of Clause *note 10::), the freezing rules
+ actually have no effect beyond compilation unit boundaries.
+
+19.g/3
+ Reason: {AI05-0299-1AI05-0299-1} That is important, because
+ Clause *note 10:: allows some implementation definedness in
+ the order of things, and we don't want the freezing rules to
+ be implementation defined.
+
+19.h
+ Ramification: These rules also have no effect in statements --
+ they only apply within a single declarative_part,
+ package_specification, task_definition, protected_definition,
+ or protected_body.
+
+19.i
+ Implementation Note: An implementation may choose to generate
+ code for default_expressions and default_names in line at the
+ place of use. Alternatively, an implementation may choose to
+ generate thunks (subprograms implicitly generated by the
+ compiler) for evaluation of defaults. Thunk generation
+ cannot, in general, be done at the place of the declaration
+ that includes the default. Instead, they can be generated at
+ the first freezing point of the type(s) involved. (It is
+ impossible to write a purely one-pass Ada compiler, for
+ various reasons. This is one of them -- the compiler needs to
+ store a representation of defaults in its symbol table, and
+ then walk that representation later, no earlier than the first
+ freezing point.)
+
+19.j
+ In implementation terms, the linear elaboration model can be
+ thought of as preventing uninitialized dope. For example, the
+ implementation might generate dope to contain the size of a
+ private type. This dope is initialized at the place where the
+ type becomes completely defined. It cannot be initialized
+ earlier, because of the order-of-elaboration rules. The
+ freezing rules prevent elaboration of earlier declarations
+ from accessing the size dope for a private type before it is
+ initialized.
+
+19.k
+ *note 2.8:: overrides the freezing rules in the case of
+ unrecognized pragmas.
+
+19.l/1
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} An
+ aspect_clause for an entity should most certainly not be a
+ freezing point for the entity.
+
+ _Dynamic Semantics_
+
+20/2
+{AI95-00279-01AI95-00279-01} The tag (see *note 3.9::) of a tagged type
+T is created at the point where T is frozen.
+
+ _Incompatibilities With Ada 83_
+
+20.a
+ RM83 defines a forcing occurrence of a type as follows: "A
+ forcing occurrence is any occurrence [of the name of the type,
+ subtypes of the type, or types or subtypes with subcomponents
+ of the type] other than in a type or subtype declaration, a
+ subprogram specification, an entry declaration, a deferred
+ constant declaration, a pragma, or a representation_clause for
+ the type itself. In any case, an occurrence within an
+ expression is always forcing."
+
+20.b
+ It seems like the wording allows things like this:
+
+20.c
+ type A is array(Integer range 1..10) of Boolean;
+ subtype S is Integer range A'Range;
+ -- not forcing for A
+
+20.d
+ Occurrences within pragmas can cause freezing in Ada 95.
+ (Since such pragmas are ignored in Ada 83, this will probably
+ fix more bugs than it causes.)
+
+ _Extensions to Ada 83_
+
+20.e
+ In Ada 95, generic_formal_parameter_declarations do not
+ normally freeze the entities from which they are defined. For
+ example:
+
+20.f
+ package Outer is
+ type T is tagged limited private;
+ generic
+ type T2 is
+ new T with private; -- Does not freeze T
+ -- in Ada 95.
+ package Inner is
+ ...
+ end Inner;
+ private
+ type T is ...;
+ end Outer;
+
+20.g
+ This is important for the usability of generics. The above
+ example uses the Ada 95 feature of formal derived types.
+ Examples using the kinds of formal parameters already allowed
+ in Ada 83 are well known. See, for example, comments 83-00627
+ and 83-00688. The extensive use expected for formal derived
+ types makes this issue even more compelling than described by
+ those comments. Unfortunately, we are unable to solve the
+ problem that explicit_generic_actual_parameters cause
+ freezing, even though a package equivalent to the instance
+ would not cause freezing. This is primarily because such an
+ equivalent package would have its body in the body of the
+ containing program unit, whereas an instance has its body
+ right there.
+
+ _Wording Changes from Ada 83_
+
+20.h
+ The concept of freezing is based on Ada 83's concept of
+ "forcing occurrences." The first freezing point of an entity
+ corresponds roughly to the place of the first forcing
+ occurrence, in Ada 83 terms. The reason for changing the
+ terminology is that the new rules do not refer to any
+ particular "occurrence" of a name of an entity. Instead, we
+ refer to "uses" of an entity, which are sometimes implicit.
+
+20.i
+ In Ada 83, forcing occurrences were used only in rules about
+ representation_clauses. We have expanded the concept to cover
+ private types, because the rules stated in RM83-7.4.1(4) are
+ almost identical to the forcing occurrence rules.
+
+20.j
+ The Ada 83 rules are changed in Ada 95 for the following
+ reasons:
+
+20.k
+ * The Ada 83 rules do not work right for subtype-specific
+ aspects. In an earlier version of Ada 9X, we considered
+ allowing representation items to apply to subtypes other
+ than the first subtype. This was part of the reason for
+ changing the Ada 83 rules. However, now that we have
+ dropped that functionality, we still need the rules to be
+ different from the Ada 83 rules.
+
+20.l
+ * The Ada 83 rules do not achieve the intended effect. In
+ Ada 83, either with or without the AIs, it is possible to
+ force the compiler to generate code that references
+ uninitialized dope, or force it to detect erroneousness
+ and exception raising at compile time.
+
+20.m
+ * It was a goal of Ada 83 to avoid uninitialized access
+ values. However, in the case of deferred constants, this
+ goal was not achieved.
+
+20.n
+ * The Ada 83 rules are not only too weak -- they are also
+ too strong. They allow loopholes (as described above),
+ but they also prevent certain kinds of
+ default_expressions that are harmless, and certain kinds
+ of generic_declarations that are both harmless and very
+ useful.
+
+20.o/2
+ * {AI95-00114-01AI95-00114-01} Ada 83 had a case where an
+ aspect_clause had a strong effect on the semantics of the
+ program -- 'Small. This caused certain semantic
+ anomalies. There are more cases in Ada 95, because the
+ attribute_definition_clause has been generalized.
+
+ _Incompatibilities With Ada 95_
+
+20.p/2
+ {8652/00468652/0046} {AI95-00106-01AI95-00106-01}
+ {AI95-00341-01AI95-00341-01} Corrigendum: Various freezing
+ rules were added to fix holes in the rules. Most importantly,
+ implicit calls are now freezing, which make some
+ representation clauses illegal in Ada 2005 that were legal
+ (but dubious) in Ada 95. Amendment Correction: Similarly, the
+ primitive subprograms of a specific tagged type are frozen
+ when the type is frozen, preventing dubious convention changes
+ (and address clauses) after the freezing point. In both
+ cases, the code is dubious and the workaround is easy.
+
+ _Wording Changes from Ada 95_
+
+20.q/2
+ {8652/00098652/0009} {AI95-00137-01AI95-00137-01} Corrigendum:
+ Added wording to specify that both operational and
+ representation attributes must be specified before the type is
+ frozen.
+
+20.r/2
+ {AI95-00251-01AI95-00251-01} Added wording that declaring a
+ specific descendant of an interface type freezes the interface
+ type.
+
+20.s/2
+ {AI95-00279-01AI95-00279-01} Added wording that defines when a
+ tag is created for a type (at the freezing point of the type).
+ This is used to specify checking for uncreated tags (see *note
+ 3.9::).
+
+ _Incompatibilities With Ada 2005_
+
+20.t/3
+ {AI05-0019-1AI05-0019-1} Correction: Separated the freezing of
+ the profile from the rest of a subprogram, in order to reduce
+ the impact of the Ada 95 incompatibility noted above. (The
+ effects were much more limiting than expected.)
+
+ _Wording Changes from Ada 2005_
+
+20.u/3
+ {AI05-0017-1AI05-0017-1} Correction: Reworded so that
+ incomplete types with a deferred completion aren't prematurely
+ frozen.
+
+20.v/3
+ {AI05-0177-1AI05-0177-1} Added freezing rules for expression
+ functions; these are frozen at the point of call, not the
+ point of declaration, like default expressions.
+
+20.w/3
+ {AI05-0183-1AI05-0183-1} Added freezing rules for
+ aspect_specifications; these are frozen at the freezing point
+ of the associated entity, not the point of declaration.
+
+20.x/3
+ {AI05-0213-1AI05-0213-1} Added freezing rules for formal
+ incomplete types; the corresponding actual is not frozen.
+
+\1f
+File: aarm2012.info, Node: Annex A, Next: Annex B, Prev: 13, Up: Top
+
+Annex A Predefined Language Environment
+***************************************
+
+1
+[ This Annex contains the specifications of library units that shall be
+provided by every implementation. There are three root library units:
+Ada, Interfaces, and System; other library units are children of these:]
+
+2/3
+{8652/00478652/0047} {AI95-00081-01AI95-00081-01}
+{AI95-00424-01AI95-00424-01} {AI05-0001-1AI05-0001-1}
+{AI05-0049-1AI05-0049-1} {AI05-0069-1AI05-0069-1}
+{AI05-0111-3AI05-0111-3} {AI05-0136-1AI05-0136-1}
+{AI05-0137-1AI05-0137-1} {AI05-0166-1AI05-0166-1}
+{AI05-0168-1AI05-0168-1}
+
+
+ [Standard -- *note A.1::
+ Ada -- *note A.2::
+ Assertions -- *note 11.4.2::
+ Asynchronous_Task_Control -- *note D.11::
+ Calendar -- *note 9.6::
+ Arithmetic -- *note 9.6.1::
+ Formatting -- *note 9.6.1::
+ Time_Zones -- *note 9.6.1::
+ Characters -- *note A.3.1::
+ Conversions -- *note A.3.4::
+ Handling -- *note A.3.2::
+ Latin_1 -- *note A.3.3::
+ Command_Line -- *note A.15::
+ Complex_Text_IO -- *note G.1.3::
+ Containers -- *note A.18.1::
+ Bounded_Doubly_Linked_Lists
+ -- *note A.18.20::
+ Bounded_Hashed_Maps -- *note A.18.21::
+ Bounded_Hashed_Sets -- *note A.18.23::
+ Bounded_Multiway_Trees -- *note A.18.25::
+ Bounded_Ordered_Maps -- *note A.18.22::
+ Bounded_Ordered_Sets -- *note A.18.24::
+ Bounded_Priority_Queues -- *note A.18.31::
+ Bounded_Synchronized_Queues
+ -- *note A.18.29::
+ Bounded_Vectors -- *note A.18.19::
+ Doubly_Linked_Lists -- *note A.18.3::
+ Generic_Array_Sort -- *note A.18.26::
+ Generic_Constrained_Array_Sort
+ -- *note A.18.26::
+ Generic_Sort -- *note A.18.26::
+ Hashed_Maps -- *note A.18.5::
+ Hashed_Sets -- *note A.18.8::
+ Indefinite_Doubly_Linked_Lists
+ -- *note A.18.12::
+ Indefinite_Hashed_Maps -- *note A.18.13::
+ Indefinite_Hashed_Sets -- *note A.18.15::
+ Indefinite_Holders -- *note A.18.18::
+ Indefinite_Multiway_Trees -- *note A.18.17::
+ Indefinite_Ordered_Maps -- *note A.18.14::
+ Indefinite_Ordered_Sets -- *note A.18.16::
+ Indefinite_Vectors -- *note A.18.11::
+
+ Standard (...continued)
+ Ada (...continued)
+ Containers (...continued)
+ Multiway_Trees -- *note A.18.10::
+ Ordered_Maps -- *note A.18.6::
+ Ordered_Sets -- *note A.18.9::
+ Synchronized_Queue_Interfaces
+ -- *note A.18.27::
+ Unbounded_Priority_Queues
+ -- *note A.18.30::
+ Unbounded_Synchronized_Queues
+ -- *note A.18.28::
+ Vectors -- *note A.18.2::
+ Decimal -- *note F.2::
+ Direct_IO -- *note A.8.4::
+ Directories -- *note A.16::
+ Hierarchical_File_Names -- *note A.16.1::
+ Information -- *note A.16::
+ Dispatching -- *note D.2.1::
+ EDF -- *note D.2.6::
+ Non_Preemptive -- *note D.2.4::
+ Round_Robin -- *note D.2.5::
+ Dynamic_Priorities -- *note D.5.1::
+ Environment_Variables -- *note A.17::
+ Exceptions -- *note 11.4.1::
+ Execution_Time -- *note D.14::
+ Group_Budgets -- *note D.14.2::
+ Interrupts -- *note D.14.3::
+ Timers -- *note D.14.1::
+ Finalization -- *note 7.6::
+ Float_Text_IO -- *note A.10.9::
+ Float_Wide_Text_IO -- *note A.11::
+ Float_Wide_Wide_Text_IO -- *note A.11::
+ Integer_Text_IO -- *note A.10.8::
+ Integer_Wide_Text_IO -- *note A.11::
+ Integer_Wide_Wide_Text_IO -- *note A.11::
+ Interrupts -- *note C.3.2::
+ Names -- *note C.3.2::
+ IO_Exceptions -- *note A.13::
+ Iterator_Interfaces -- *note 5.5.1::
+ Locales -- *note A.19::
+
+ Standard (...continued)
+ Ada (...continued)
+ Numerics -- *note A.5::
+ Complex_Arrays -- *note G.3.2::
+ Complex_Elementary_Functions -- *note G.1.2::
+ Complex_Types -- *note G.1.1::
+ Discrete_Random -- *note A.5.2::
+ Elementary_Functions -- *note A.5.1::
+ Float_Random -- *note A.5.2::
+ Generic_Complex_Arrays -- *note G.3.2::
+ Generic_Complex_Elementary_Functions
+ -- *note G.1.2::
+ Generic_Complex_Types -- *note G.1.1::
+ Generic_Elementary_Functions -- *note A.5.1::
+ Generic_Real_Arrays -- *note G.3.1::
+ Real_Arrays -- *note G.3.1::
+ Real_Time -- *note D.8::
+ Timing_Events -- *note D.15::
+ Sequential_IO -- *note A.8.1::
+ Storage_IO -- *note A.9::
+ Streams -- *note 13.13.1::
+ Stream_IO -- *note A.12.1::
+ Strings -- *note A.4.1::
+ Bounded -- *note A.4.4::
+ Equal_Case_Insensitive -- *note A.4.10::
+ Hash -- *note A.4.9::
+ Hash_Case_Insensitive -- *note A.4.9::
+ Less_Case_Insensitive -- *note A.4.10::
+ Fixed -- *note A.4.3::
+ Equal_Case_Insensitive -- *note A.4.10::
+ Hash -- *note A.4.9::
+ Hash_Case_Insensitive -- *note A.4.9::
+ Less_Case_Insensitive -- *note A.4.10::
+ Equal_Case_Insensitive -- *note A.4.10::
+ Hash -- *note A.4.9::
+ Hash_Case_Insensitive -- *note A.4.9::
+ Less_Case_Insensitive -- *note A.4.10::
+ Maps -- *note A.4.2::
+ Constants -- *note A.4.6::
+ Unbounded -- *note A.4.5::
+ Equal_Case_Insensitive -- *note A.4.10::
+ Hash -- *note A.4.9::
+ Hash_Case_Insensitive -- *note A.4.9::
+ Less_Case_Insensitive -- *note A.4.10::
+ UTF_Encoding -- *note A.4.11::
+ Conversions -- *note A.4.11::
+ Strings -- *note A.4.11::
+ Wide_Strings -- *note A.4.11::
+ Wide_Wide_Strings -- *note A.4.11::
+
+ Standard (...continued)
+ Ada (...continued)
+ Strings (...continued)
+ Wide_Bounded -- *note A.4.7::
+ Wide_Equal_Case_Insensitive
+ -- *note A.4.7::
+ Wide_Hash -- *note A.4.7::
+ Wide_Hash_Case_Insensitive -- *note A.4.7::
+ Wide_Equal_Case_Insensitive -- *note A.4.7::
+ Wide_Fixed -- *note A.4.7::
+ Wide_Equal_Case_Insensitive
+ -- *note A.4.7::
+ Wide_Hash -- *note A.4.7::
+ Wide_Hash_Case_Insensitive -- *note A.4.7::
+ Wide_Hash -- *note A.4.7::
+ Wide_Hash_Case_Insensitive -- *note A.4.7::
+ Wide_Maps -- *note A.4.7::
+ Wide_Constants -- *note A.4.7::
+ Wide_Unbounded -- *note A.4.7::
+ Wide_Equal_Case_Insensitive
+ -- *note A.4.7::
+ Wide_Hash -- *note A.4.7::
+ Wide_Hash_Case_Insensitive -- *note A.4.7::
+ Wide_Wide_Bounded -- *note A.4.8::
+ Wide_Wide_Equal_Case_Insensitive
+ -- *note A.4.8::
+ Wide_Wide_Hash -- *note A.4.8::
+ Wide_Wide_Hash_Case_Insensitive
+ -- *note A.4.8::
+ Wide_Wide_Equal_Case_Insensitive
+ -- *note A.4.8::
+ Wide_Wide_Fixed -- *note A.4.8::
+ Wide_Wide_Equal_Case_Insensitive
+ -- *note A.4.8::
+ Wide_Wide_Hash -- *note A.4.8::
+ Wide_Wide_Hash_Case_Insensitive
+ -- *note A.4.8::
+ Wide_Wide_Hash -- *note A.4.8::
+ Wide_Wide_Hash_Case_Insensitive
+ -- *note A.4.8::
+ Wide_Wide_Maps -- *note A.4.8::
+ Wide_Wide_Constants -- *note A.4.8::
+ Wide_Wide_Unbounded -- *note A.4.8::
+ Wide_Wide_Equal_Case_Insensitive
+ -- *note A.4.8::
+ Wide_Wide_Hash -- *note A.4.8::
+ Wide_Wide_Hash_Case_Insensitive
+ -- *note A.4.8::
+ Synchronous_Barriers -- *note D.10.1::
+ Synchronous_Task_Control -- *note D.10::
+ EDF -- *note D.10::
+
+ Standard (...continued)
+ Ada (...continued)
+ Tags -- *note 3.9::
+ Generic_Dispatching_Constructor -- *note 3.9::
+ Task_Attributes -- *note C.7.2::
+ Task_Identification -- *note C.7.1::
+ Task_Termination -- *note C.7.3::
+ Text_IO -- *note A.10.1::
+ Bounded_IO -- *note A.10.11::
+ Complex_IO -- *note G.1.3::
+ Editing -- *note F.3.3::
+ Text_Streams -- *note A.12.2::
+ Unbounded_IO -- *note A.10.12::
+ Unchecked_Conversion -- *note 13.9::
+ Unchecked_Deallocate_Subpool -- *note 13.11.5::
+ Unchecked_Deallocation -- *note 13.11.2::
+ Wide_Characters -- *note A.3.1::
+ Handling -- *note A.3.5::
+ Wide_Text_IO -- *note A.11::
+ Complex_IO -- *note G.1.4::
+ Editing -- *note F.3.4::
+ Text_Streams -- *note A.12.3::
+ Wide_Bounded_IO -- *note A.11::
+ Wide_Unbounded_IO -- *note A.11::
+ Wide_Wide_Characters -- *note A.3.1::
+ Handling -- *note A.3.6::
+ Wide_Wide_Text_IO -- *note A.11::
+ Complex_IO -- *note G.1.5::
+ Editing -- *note F.3.5::
+ Text_Streams -- *note A.12.4::
+ Wide_Wide_Bounded_IO -- *note A.11::
+ Wide_Wide_Unbounded_IO -- *note A.11::
+
+ Interfaces -- *note B.2::
+ C -- *note B.3::
+ Pointers -- *note B.3.2::
+ Strings -- *note B.3.1::
+ COBOL -- *note B.4::
+ Fortran -- *note B.5::
+
+ System -- *note 13.7::
+ Address_To_Access_Conversions -- *note 13.7.2::
+ Machine_Code -- *note 13.8::
+ Multiprocessors -- *note D.16::
+ Dispatching_Domains -- *note D.16.1::
+ RPC -- *note E.5::
+ Storage_Elements -- *note 13.7.1::
+ Storage_Pools -- *note 13.11::
+ Subpools -- *note 13.11.4::]
+
+2.a
+ Discussion: In running text, we generally leave out the "Ada."
+ when referring to a child of Ada.
+
+2.b
+ Reason: We had no strict rule for which of Ada, Interfaces, or
+ System should be the parent of a given library unit. However,
+ we have tried to place as many things as possible under Ada,
+ except that interfacing is a separate category, and we have
+ tried to place library units whose use is highly nonportable
+ under System.
+
+ _Implementation Requirements_
+
+3/2
+{AI95-00434-01AI95-00434-01} The implementation shall ensure that each
+language-defined subprogram is reentrant in the sense that concurrent
+calls on the same subprogram perform as specified, so long as all
+parameters that could be passed by reference denote nonoverlapping
+objects.
+
+3.a
+ Ramification: For example, simultaneous calls to Text_IO.Put
+ will work properly, so long as they are going to two different
+ files. On the other hand, simultaneous output to the same
+ file constitutes erroneous use of shared variables.
+
+3.b
+ To be honest: Here, "language defined subprogram" means a
+ language defined library subprogram, a subprogram declared in
+ the visible part of a language defined library package, an
+ instance of a language defined generic library subprogram, or
+ a subprogram declared in the visible part of an instance of a
+ language defined generic library package.
+
+3.c
+ Ramification: The rule implies that any data local to the
+ private part or body of the package has to be somehow
+ protected against simultaneous access.
+
+3.1/3
+{AI05-0048-1AI05-0048-1} If a descendant of a language-defined tagged
+type is declared, the implementation shall ensure that each inherited
+language-defined subprogram behaves as described in this International
+Standard. In particular, overriding a language-defined subprogram shall
+not alter the effect of any inherited language-defined subprogram.
+
+3.d/3
+ Reason: This means that internally the implementation must not
+ do redispatching unless it is required by the Standard. So
+ when we say that some subprogram Bar is equivalent to Foo,
+ overriding Foo for a derived type doesn't change the semantics
+ of Bar, and in particular it means that Bar may no longer be
+ equivalent to Foo. The word "equivalent" is always a bit of a
+ lie anyway.
+
+ _Implementation Permissions_
+
+4
+The implementation may restrict the replacement of language-defined
+compilation units. The implementation may restrict children of
+language-defined library units (other than Standard).
+
+4.a
+ Ramification: For example, the implementation may say, "you
+ cannot compile a library unit called System" or "you cannot
+ compile a child of package System" or "if you compile a
+ library unit called System, it has to be a package, and it has
+ to contain at least the following declarations: ...".
+
+ _Wording Changes from Ada 83_
+
+4.b
+ Many of Ada 83's language-defined library units are now
+ children of Ada or System. For upward compatibility, these
+ are renamed as root library units (see *note J.1::).
+
+4.c
+ The order and lettering of the annexes has been changed.
+
+ _Wording Changes from Ada 95_
+
+4.d/2
+ {8652/00478652/0047} {AI95-00081-01AI95-00081-01} Corrigendum:
+ Units missing from the list of predefined units were added.
+
+4.e/2
+ {AI95-00424-01AI95-00424-01} Added new units to the list of
+ predefined units.
+
+ _Wording Changes from Ada 2005_
+
+4.f/3
+ {AI05-0048-1AI05-0048-1} Correction: Added wording to ban
+ redispatching unless it is explicitly required, in order to
+ safeguard portability when overriding language-defined
+ routines.
+
+4.g/3
+ {AI05-0060-1AI05-0060-1} {AI05-0206-1AI05-0206-1} Correction:
+ Added a permission to omit pragma Remote_Types from
+ language-defined units if Annex E is not supported. This was
+ later removed, as a better method of supporting the reason is
+ now available. Note that this requires all implementations to
+ provide minimal support for the Remote_Types categorization
+ even if Annex E is not supported; being unable to compile
+ language-defined units is not allowed.
+
+4.h/3
+ {AI05-0001-1AI05-0001-1} {AI05-0049-1AI05-0049-1}
+ {AI05-0069-1AI05-0069-1} {AI05-0111-3AI05-0111-3}
+ {AI05-0136-1AI05-0136-1} {AI05-0137-1AI05-0137-1}
+ {AI05-0166-1AI05-0166-1} {AI05-0168-1AI05-0168-1} Added
+ various new units to the list of predefined units.
+
+* Menu:
+
+* A.1 :: The Package Standard
+* A.2 :: The Package Ada
+* A.3 :: Character Handling
+* A.4 :: String Handling
+* A.5 :: The Numerics Packages
+* A.6 :: Input-Output
+* A.7 :: External Files and File Objects
+* A.8 :: Sequential and Direct Files
+* A.9 :: The Generic Package Storage_IO
+* A.10 :: Text Input-Output
+* A.11 :: Wide Text Input-Output and Wide Wide Text Input-Output
+* A.12 :: Stream Input-Output
+* A.13 :: Exceptions in Input-Output
+* A.14 :: File Sharing
+* A.15 :: The Package Command_Line
+* A.16 :: The Package Directories
+* A.17 :: The Package Environment_Variables
+* A.18 :: Containers
+* A.19 :: The Package Locales
+
+\1f
+File: aarm2012.info, Node: A.1, Next: A.2, Up: Annex A
+
+A.1 The Package Standard
+========================
+
+1/3
+{AI05-0299-1AI05-0299-1} This subclause outlines the specification of
+the package Standard containing all predefined identifiers in the
+language. The corresponding package body is not specified by the
+language.
+
+2
+The operators that are predefined for the types declared in the package
+Standard are given in comments since they are implicitly declared.
+Italics are used for pseudo-names of anonymous types (such as root_real)
+and for undefined information (such as implementation-defined).
+
+2.a
+ Ramification: All of the predefined operators are of
+ convention Intrinsic.
+
+ _Static Semantics_
+
+3
+The library package Standard has the following declaration:
+
+3.a
+ Implementation defined: The names and characteristics of the
+ numeric subtypes declared in the visible part of package
+ Standard.
+
+4
+ package Standard is
+ pragma Pure(Standard);
+
+5
+ type Boolean is (False, True);
+
+6
+ -- The predefined relational operators for this type are as follows:
+
+7/1
+ {8652/00288652/0028} {AI95-00145-01AI95-00145-01} -- function "=" (Left, Right : Boolean'Base) return Boolean;
+ -- function "/=" (Left, Right : Boolean'Base) return Boolean;
+ -- function "<" (Left, Right : Boolean'Base) return Boolean;
+ -- function "<=" (Left, Right : Boolean'Base) return Boolean;
+ -- function ">" (Left, Right : Boolean'Base) return Boolean;
+ -- function ">=" (Left, Right : Boolean'Base) return Boolean;
+
+8
+ -- The predefined logical operators and the predefined logical
+ -- negation operator are as follows:
+
+9/1
+ {8652/00288652/0028} {AI95-00145-01AI95-00145-01} -- function "and" (Left, Right : Boolean'Base) return Boolean'Base;
+ -- function "or" (Left, Right : Boolean'Base) return Boolean'Base;
+ -- function "xor" (Left, Right : Boolean'Base) return Boolean'Base;
+
+10/1
+ {8652/00288652/0028} {AI95-00145-01AI95-00145-01} -- function "not" (Right : Boolean'Base) return Boolean'Base;
+
+11/2
+ {AI95-00434-01AI95-00434-01} -- The integer type root_integer and the
+ -- corresponding universal type universal_integer are predefined.
+
+12
+ type Integer is range implementation-defined;
+
+13
+ subtype Natural is Integer range 0 .. Integer'Last;
+ subtype Positive is Integer range 1 .. Integer'Last;
+
+14
+ -- The predefined operators for type Integer are as follows:
+
+15
+ -- function "=" (Left, Right : Integer'Base) return Boolean;
+ -- function "/=" (Left, Right : Integer'Base) return Boolean;
+ -- function "<" (Left, Right : Integer'Base) return Boolean;
+ -- function "<=" (Left, Right : Integer'Base) return Boolean;
+ -- function ">" (Left, Right : Integer'Base) return Boolean;
+ -- function ">=" (Left, Right : Integer'Base) return Boolean;
+
+16
+ -- function "+" (Right : Integer'Base) return Integer'Base;
+ -- function "-" (Right : Integer'Base) return Integer'Base;
+ -- function "abs" (Right : Integer'Base) return Integer'Base;
+
+17
+ -- function "+" (Left, Right : Integer'Base) return Integer'Base;
+ -- function "-" (Left, Right : Integer'Base) return Integer'Base;
+ -- function "*" (Left, Right : Integer'Base) return Integer'Base;
+ -- function "/" (Left, Right : Integer'Base) return Integer'Base;
+ -- function "rem" (Left, Right : Integer'Base) return Integer'Base;
+ -- function "mod" (Left, Right : Integer'Base) return Integer'Base;
+
+18
+ -- function "**" (Left : Integer'Base; Right : Natural)
+ -- return Integer'Base;
+
+19
+ -- The specification of each operator for the type
+ -- root_integer, or for any additional predefined integer
+ -- type, is obtained by replacing Integer by the name of the type
+ -- in the specification of the corresponding operator of the type
+ -- Integer. The right operand of the exponentiation operator
+ -- remains as subtype Natural.
+
+20/2
+ {AI95-00434-01AI95-00434-01} -- The floating point type root_real and the
+ -- corresponding universal type universal_real are predefined.
+
+21
+ type Float is digits implementation-defined;
+
+22
+ -- The predefined operators for this type are as follows:
+
+23
+ -- function "=" (Left, Right : Float) return Boolean;
+ -- function "/=" (Left, Right : Float) return Boolean;
+ -- function "<" (Left, Right : Float) return Boolean;
+ -- function "<=" (Left, Right : Float) return Boolean;
+ -- function ">" (Left, Right : Float) return Boolean;
+ -- function ">=" (Left, Right : Float) return Boolean;
+
+24
+ -- function "+" (Right : Float) return Float;
+ -- function "-" (Right : Float) return Float;
+ -- function "abs" (Right : Float) return Float;
+
+25
+ -- function "+" (Left, Right : Float) return Float;
+ -- function "-" (Left, Right : Float) return Float;
+ -- function "*" (Left, Right : Float) return Float;
+ -- function "/" (Left, Right : Float) return Float;
+
+26
+ -- function "**" (Left : Float; Right : Integer'Base) return Float;
+
+27
+ -- The specification of each operator for the type root_real, or for
+ -- any additional predefined floating point type, is obtained by
+ -- replacing Float by the name of the type in the specification of the
+ -- corresponding operator of the type Float.
+
+28
+ -- In addition, the following operators are predefined for the root
+ -- numeric types:
+
+29
+ function "*" (Left : root_integer; Right : root_real)
+ return root_real;
+
+30
+ function "*" (Left : root_real; Right : root_integer)
+ return root_real;
+
+31
+ function "/" (Left : root_real; Right : root_integer)
+ return root_real;
+
+32
+ -- The type universal_fixed is predefined.
+ -- The only multiplying operators defined between
+ -- fixed point types are
+
+33
+ function "*" (Left : universal_fixed; Right : universal_fixed)
+ return universal_fixed;
+
+34
+ function "/" (Left : universal_fixed; Right : universal_fixed)
+ return universal_fixed;
+
+34.1/2
+ {AI95-00230-01AI95-00230-01} -- The type universal_access is predefined.
+ -- The following equality operators are predefined:
+
+34.2/2
+ {AI95-00230-01AI95-00230-01} function "=" (Left, Right: universal_access) return Boolean;
+ function "/=" (Left, Right: universal_access) return Boolean;
+
+35/3
+ {AI95-00415-01AI95-00415-01} {AI05-0181-1AI05-0181-1} {AI05-0248-1AI05-0248-1} -- The declaration of type Character is based on the standard ISO 8859-1 character set.
+
+ -- There are no character literals corresponding to the positions for control characters.
+ -- They are indicated in italics in this definition. See *note 3.5.2::.
+
+ type Character is
+ (nul, soh, stx, etx, eot, enq, ack, bel, --0 (16#00#) .. 7 (16#07#)
+ bs, ht, lf, vt, ff, cr, so, si, --8 (16#08#) .. 15 (16#0F#)
+
+ dle, dc1, dc2, dc3, dc4, nak, syn, etb, --16 (16#10#) .. 23 (16#17#)
+ can, em, sub, esc, fs, gs, rs, us, --24 (16#18#) .. 31 (16#1F#)
+
+ ' ', '!', '"', '#', '$', '%', '&', ''', --32 (16#20#) .. 39 (16#27#)
+ '(', ')', '*', '+', ',', '-', '.', '/', --40 (16#28#) .. 47 (16#2F#)
+
+ '0', '1', '2', '3', '4', '5', '6', '7', --48 (16#30#) .. 55 (16#37#)
+ '8', '9', ':', ';', '<', '=', '>', '?', --56 (16#38#) .. 63 (16#3F#)
+
+ '@', 'A', 'B', 'C', 'D', 'E', 'F', 'G', --64 (16#40#) .. 71 (16#47#)
+ 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', --72 (16#48#) .. 79 (16#4F#)
+
+ 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', --80 (16#50#) .. 87 (16#57#)
+ 'X', 'Y', 'Z', '[', '\', ']', '^', '_', --88 (16#58#) .. 95 (16#5F#)
+
+ '`', 'a', 'b', 'c', 'd', 'e', 'f', 'g', --96 (16#60#) .. 103 (16#67#)
+ 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', --104 (16#68#) .. 111 (16#6F#)
+
+ 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', --112 (16#70#) .. 119 (16#77#)
+ 'x', 'y', 'z', '{', '|', '}', '~', del, --120 (16#78#) .. 127 (16#7F#)
+
+ reserved_128, reserved_129, bph, nbh, --128 (16#80#) .. 131 (16#83#)
+ reserved_132, nel, ssa, esa, --132 (16#84#) .. 135 (16#87#)
+ hts, htj, vts, pld, plu, ri, ss2, ss3, --136 (16#88#) .. 143 (16#8F#)
+
+ dcs, pu1, pu2, sts, cch, mw, spa, epa, --144 (16#90#) .. 151 (16#97#)
+ sos, reserved_153, sci, csi, --152 (16#98#) .. 155 (16#9B#)
+ st, osc, pm, apc, --156 (16#9C#) .. 159 (16#9F#)
+
+ ' ', '¡', '¢', '£', '¤', '¥', '¦', '§', --160 (16#A0#) .. 167 (16#A7#)
+ '¨', '©', 'ª', '«', --168 (16#A8#) .. 171 (16#AB#)
+ ¬', soft_hyphen, '®', '¯', --172 (16#AC#) .. 175 (16#AF#)
+
+ '°', '±', '²', '³', '´', 'µ', '¶', '·', --176 (16#B0#) .. 183 (16#B7#)
+ '¸', '¹', 'º', '»', '¼', '½', '¾', '¿', --184 (16#B8#) .. 191 (16#BF#)
+
+ 'À', 'Á', 'Â', 'Ã', 'Ä', 'Å', 'Æ', 'Ç', --192 (16#C0#) .. 199 (16#C7#)
+ 'È', 'É', 'Ê', 'Ë', 'Ì', 'Í', 'Î', 'Ï', --200 (16#C8#) .. 207 (16#CF#)
+
+ 'Ð', 'Ñ', 'Ò', 'Ó', 'Ô', 'Õ', 'Ö', '×', --208 (16#D0#) .. 215 (16#D7#)
+ 'Ø', 'Ù', 'Ú', 'Û', 'Ü', 'Ý', 'Þ', 'ß', --216 (16#D8#) .. 223 (16#DF#)
+
+ 'à', 'á', 'â', 'ã', 'ä', 'å', 'æ', 'ç', --224 (16#E0#) .. 231 (16#E7#)
+ 'è', 'é', 'ê', 'ë', 'ì', 'í', 'î', 'ï', --232 (16#E8#) .. 239 (16#EF#)
+
+ 'ð', 'ñ', 'ò', 'ó', 'ô', 'õ', 'ö', '÷', --240 (16#F0#) .. 247 (16#F7#)
+ 'ø', 'ù', 'ú', 'û', 'ü', 'ý', 'þ', 'ÿ');--248 (16#F8#) .. 255 (16#FF#)
+
+36
+ -- The predefined operators for the type Character are the same as for
+ -- any enumeration type.
+
+
+36.1/3
+ {AI95-00395-01AI95-00395-01} {AI05-0266-1AI05-0266-1} -- The declaration of type Wide_Character is based on the standard ISO/IEC 10646:2011 BMP character
+ -- set. The first 256 positions have the same contents as type Character. See *note 3.5.2::.
+
+ type Wide_Character is (nul, soh ... Hex_0000FFFE, Hex_0000FFFF);
+
+36.2/3
+ {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01} {AI05-0266-1AI05-0266-1} -- The declaration of type Wide_Wide_Character is based on the full
+ -- ISO/IEC 10646:2011 character set. The first 65536 positions have the
+ -- same contents as type Wide_Character. See *note 3.5.2::.
+
+ type Wide_Wide_Character is (nul, soh ... Hex_7FFFFFFE, Hex_7FFFFFFF);
+ for Wide_Wide_Character'Size use 32;
+
+36.3/2
+ package ASCII is ... end ASCII; --Obsolescent; see *note J.5::
+
+
+
+37/3
+ {AI05-0229-1AI05-0229-1} -- Predefined string types:
+
+ type String is array(Positive range <>) of Character
+ with Pack;
+
+38
+ -- The predefined operators for this type are as follows:
+
+39
+ -- function "=" (Left, Right: String) return Boolean;
+ -- function "/=" (Left, Right: String) return Boolean;
+ -- function "<" (Left, Right: String) return Boolean;
+ -- function "<=" (Left, Right: String) return Boolean;
+ -- function ">" (Left, Right: String) return Boolean;
+ -- function ">=" (Left, Right: String) return Boolean;
+
+40
+ -- function "&" (Left: String; Right: String) return String;
+ -- function "&" (Left: Character; Right: String) return String;
+ -- function "&" (Left: String; Right: Character) return String;
+ -- function "&" (Left: Character; Right: Character) return String;
+
+41/3
+ {AI05-0229-1AI05-0229-1} type Wide_String is array(Positive range <>) of Wide_Character
+ with Pack;
+
+42
+ -- The predefined operators for this type correspond to those for String.
+
+42.1/3
+ {AI95-00285-01AI95-00285-01} {AI05-0229-1AI05-0229-1} type Wide_Wide_String is array (Positive range <>)
+ of Wide_Wide_Character
+ with Pack;
+
+42.2/2
+ {AI95-00285-01AI95-00285-01} -- The predefined operators for this type correspond to those for String.
+
+43
+ type Duration is delta implementation-defined range implementation-defined;
+
+44
+ -- The predefined operators for the type Duration are the same as for
+ -- any fixed point type.
+
+45
+ -- The predefined exceptions:
+
+46
+ Constraint_Error: exception;
+ Program_Error : exception;
+ Storage_Error : exception;
+ Tasking_Error : exception;
+
+47
+ end Standard;
+
+48
+Standard has no private part.
+
+48.a
+ Reason: This is important for portability. All library
+ packages are children of Standard, and if Standard had a
+ private part then it would be visible to all of them.
+
+49/2
+{AI95-00285-01AI95-00285-01} In each of the types Character,
+Wide_Character, and Wide_Wide_Character, the character literals for the
+space character (position 32) and the non-breaking space character
+(position 160) correspond to different values. Unless indicated
+otherwise, each occurrence of the character literal ' ' in this
+International Standard refers to the space character. Similarly, the
+character literals for hyphen (position 45) and soft hyphen (position
+173) correspond to different values. Unless indicated otherwise, each
+occurrence of the character literal '-' in this International Standard
+refers to the hyphen character.
+
+ _Dynamic Semantics_
+
+50
+Elaboration of the body of Standard has no effect.
+
+50.a
+ Discussion: Note that the language does not define where this
+ body appears in the environment declarative_part -- see *note
+ 10::, "*note 10:: Program Structure and Compilation Issues".
+
+ _Implementation Permissions_
+
+51
+An implementation may provide additional predefined integer types and
+additional predefined floating point types. Not all of these types need
+have names.
+
+51.a
+ To be honest: An implementation may add representation items
+ to package Standard, for example to specify the internal codes
+ of type Boolean, or the Small of type Duration.
+
+ _Implementation Advice_
+
+52
+If an implementation provides additional named predefined integer types,
+then the names should end with "Integer" as in "Long_Integer". If an
+implementation provides additional named predefined floating point
+types, then the names should end with "Float" as in "Long_Float".
+
+52.a/2
+ Implementation Advice: If an implementation provides
+ additional named predefined integer types, then the names
+ should end with "Integer". If an implementation provides
+ additional named predefined floating point types, then the
+ names should end with "Float".
+
+ NOTES
+
+53
+ 1 Certain aspects of the predefined entities cannot be completely
+ described in the language itself. For example, although the
+ enumeration type Boolean can be written showing the two enumeration
+ literals False and True, the short-circuit control forms cannot be
+ expressed in the language.
+
+54
+ 2 As explained in *note 8.1::, "*note 8.1:: Declarative Region"
+ and *note 10.1.4::, "*note 10.1.4:: The Compilation Process", the
+ declarative region of the package Standard encloses every library
+ unit and consequently the main subprogram; the declaration of every
+ library unit is assumed to occur within this declarative region.
+ Library_items are assumed to be ordered in such a way that there
+ are no forward semantic dependences. However, as explained in
+ *note 8.3::, "*note 8.3:: Visibility", the only library units that
+ are visible within a given compilation unit are the library units
+ named by all with_clauses that apply to the given unit, and
+ moreover, within the declarative region of a given library unit,
+ that library unit itself.
+
+55
+ 3 If all block_statements of a program are named, then the name of
+ each program unit can always be written as an expanded name
+ starting with Standard (unless Standard is itself hidden). The
+ name of a library unit cannot be a homograph of a name (such as
+ Integer) that is already declared in Standard.
+
+56
+ 4 The exception Standard.Numeric_Error is defined in *note J.6::.
+
+56.a
+ Discussion: The declaration of Natural needs to appear between
+ the declaration of Integer and the (implicit) declaration of
+ the "**" operator for Integer, because a formal parameter of
+ "**" is of subtype Natural. This would be impossible in
+ normal code, because the implicit declarations for a type
+ occur immediately after the type declaration, with no
+ possibility of intervening explicit declarations. But we're
+ in Standard, and Standard is somewhat magic anyway.
+
+56.b
+ Using Natural as the subtype of the formal of "**" seems
+ natural; it would be silly to have a textual rule about
+ Constraint_Error being raised when there is a perfectly good
+ subtype that means just that. Furthermore, by not using
+ Integer for that formal, it helps remind the reader that the
+ exponent remains Natural even when the left operand is
+ replaced with the derivative of Integer. It doesn't logically
+ imply that, but it's still useful as a reminder.
+
+56.c
+ In any case, declaring these general-purpose subtypes of
+ Integer close to Integer seems more readable than declaring
+ them much later.
+
+ _Extensions to Ada 83_
+
+56.d
+ Package Standard is declared to be pure.
+
+56.e
+ Discussion: The introduction of the types Wide_Character and
+ Wide_String is not an Ada 95 extension to Ada 83, since ISO
+ WG9 has approved these as an authorized extension of the
+ original Ada 83 standard that is part of that standard.
+
+ _Wording Changes from Ada 83_
+
+56.f
+ Numeric_Error is made obsolescent.
+
+56.g
+ The declarations of Natural and Positive are moved to just
+ after the declaration of Integer, so that "**" can refer to
+ Natural without a forward reference. There's no real need to
+ move Positive, too -- it just came along for the ride.
+
+ _Extensions to Ada 95_
+
+56.h/2
+ {AI95-00285-01AI95-00285-01} Types Wide_Wide_Character and
+ Wide_Wide_String are new.
+
+56.i/2
+ Discussion: The inconsistencies associated with these types
+ are documented in *note 3.5.2:: and *note 3.6.3::.
+
+56.j/2
+ {AI95-00230-01AI95-00230-01} Type universal_access and the
+ equality operations for it are new.
+
+ _Wording Changes from Ada 95_
+
+56.k/2
+ {8652/00288652/0028} {AI95-00145-01AI95-00145-01} Corrigendum:
+ Corrected the parameter type for the Boolean operators
+ declared in Standard..
+
+ _Wording Changes from Ada 2005_
+
+56.l/3
+ {AI05-0181-1AI05-0181-1} Correction: Since soft_hyphen
+ (position 173) is defined to be nongraphic, gave it a name.
+
+56.m/3
+ Discussion: The inconsistencies associated with this change
+ are documented in *note 3.5::.
+
+\1f
+File: aarm2012.info, Node: A.2, Next: A.3, Prev: A.1, Up: Annex A
+
+A.2 The Package Ada
+===================
+
+ _Static Semantics_
+
+1
+The following language-defined library package exists:
+
+2
+ package Ada is
+ pragma Pure(Ada);
+ end Ada;
+
+3
+Ada serves as the parent of most of the other language-defined library
+units; its declaration is empty (except for the pragma Pure).
+
+ _Legality Rules_
+
+4
+In the standard mode, it is illegal to compile a child of package Ada.
+
+4.a
+ Reason: The intention is that mentioning, say, Ada.Text_IO in
+ a with_clause is guaranteed (at least in the standard mode) to
+ refer to the standard version of Ada.Text_IO. The user can
+ compile a root library unit Text_IO that has no relation to
+ the standard version of Text_IO.
+
+4.b
+ Ramification: Note that Ada can have non-language-defined
+ grandchildren, assuming the implementation allows it. Also,
+ packages System and Interfaces can have children, assuming the
+ implementation allows it.
+
+4.c
+ Implementation Note: An implementation will typically support
+ a nonstandard mode in which compiling the language defined
+ library units is allowed. Whether or not this mode is made
+ available to users is up to the implementer.
+
+4.d
+ An implementation could theoretically have private children of
+ Ada, since that would be semantically neutral. However, a
+ programmer cannot compile such a library unit.
+
+ _Extensions to Ada 83_
+
+4.e/3
+ {AI05-0299-1AI05-0299-1} This subclause is new to Ada 95.
+
+\1f
+File: aarm2012.info, Node: A.3, Next: A.4, Prev: A.2, Up: Annex A
+
+A.3 Character Handling
+======================
+
+1/3
+{AI95-00285-01AI95-00285-01} {AI05-0243-1AI05-0243-1}
+{AI05-0299-1AI05-0299-1} This subclause presents the packages related to
+character processing: an empty declared pure package Characters and
+child packages Characters.Handling and Characters.Latin_1. The package
+Characters.Handling provides classification and conversion functions for
+Character data, and some simple functions for dealing with
+Wide_Character and Wide_Wide_Character data. The child package
+Characters.Latin_1 declares a set of constants initialized to values of
+type Character.
+
+ _Extensions to Ada 83_
+
+1.a/3
+ {AI05-0299-1AI05-0299-1} This subclause is new to Ada 95.
+
+ _Wording Changes from Ada 95_
+
+1.b/2
+ {AI95-00285-01AI95-00285-01} Included Wide_Wide_Character in
+ this description; the individual changes are documented as
+ extensions as needed.
+
+* Menu:
+
+* A.3.1 :: The Packages Characters, Wide_Characters, and Wide_Wide_Characters
+* A.3.2 :: The Package Characters.Handling
+* A.3.3 :: The Package Characters.Latin_1
+* A.3.4 :: The Package Characters.Conversions
+* A.3.5 :: The Package Wide_Characters.Handling
+* A.3.6 :: The Package Wide_Wide_Characters.Handling
+
+\1f
+File: aarm2012.info, Node: A.3.1, Next: A.3.2, Up: A.3
+
+A.3.1 The Packages Characters, Wide_Characters, and Wide_Wide_Characters
+------------------------------------------------------------------------
+
+ _Static Semantics_
+
+1
+The library package Characters has the following declaration:
+
+2
+ package Ada.Characters is
+ pragma Pure(Characters);
+ end Ada.Characters;
+
+3/2
+{AI95-00395-01AI95-00395-01} The library package Wide_Characters has the
+following declaration:
+
+4/2
+ package Ada.Wide_Characters is
+ pragma Pure(Wide_Characters);
+ end Ada.Wide_Characters;
+
+5/2
+{AI95-00395-01AI95-00395-01} The library package Wide_Wide_Characters
+has the following declaration:
+
+6/2
+ package Ada.Wide_Wide_Characters is
+ pragma Pure(Wide_Wide_Characters);
+ end Ada.Wide_Wide_Characters;
+
+ _Implementation Advice_
+
+7/3
+{AI95-00395-01AI95-00395-01} {AI05-0185-1AI05-0185-1} If an
+implementation chooses to provide implementation-defined operations on
+Wide_Character or Wide_String (such as collating and sorting, etc.) it
+should do so by providing child units of Wide_Characters. Similarly if
+it chooses to provide implementation-defined operations on
+Wide_Wide_Character or Wide_Wide_String it should do so by providing
+child units of Wide_Wide_Characters.
+
+7.a/2
+ Implementation Advice: Implementation-defined operations on
+ Wide_Character, Wide_String, Wide_Wide_Character, and
+ Wide_Wide_String should be child units of Wide_Characters or
+ Wide_Wide_Characters.
+
+ _Extensions to Ada 95_
+
+7.b/2
+ {AI95-00395-01AI95-00395-01} The packages Wide_Characters and
+ Wide_Wide_Characters are new.
+
+\1f
+File: aarm2012.info, Node: A.3.2, Next: A.3.3, Prev: A.3.1, Up: A.3
+
+A.3.2 The Package Characters.Handling
+-------------------------------------
+
+ _Static Semantics_
+
+1
+The library package Characters.Handling has the following declaration:
+
+2/2
+ {AI95-00362-01AI95-00362-01} {AI95-00395-01AI95-00395-01} with Ada.Characters.Conversions;
+ package Ada.Characters.Handling is
+ pragma Pure(Handling);
+
+3
+ --Character classification functions
+
+4/3
+ {AI05-0185-1AI05-0185-1} function Is_Control (Item : in Character) return Boolean;
+ function Is_Graphic (Item : in Character) return Boolean;
+ function Is_Letter (Item : in Character) return Boolean;
+ function Is_Lower (Item : in Character) return Boolean;
+ function Is_Upper (Item : in Character) return Boolean;
+ function Is_Basic (Item : in Character) return Boolean;
+ function Is_Digit (Item : in Character) return Boolean;
+ function Is_Decimal_Digit (Item : in Character) return Boolean
+ renames Is_Digit;
+ function Is_Hexadecimal_Digit (Item : in Character) return Boolean;
+ function Is_Alphanumeric (Item : in Character) return Boolean;
+ function Is_Special (Item : in Character) return Boolean;
+ function Is_Line_Terminator (Item : in Character) return Boolean;
+ function Is_Mark (Item : in Character) return Boolean;
+ function Is_Other_Format (Item : in Character) return Boolean;
+ function Is_Punctuation_Connector (Item : in Character) return Boolean;
+ function Is_Space (Item : in Character) return Boolean;
+
+5
+ --Conversion functions for Character and String
+
+6
+ function To_Lower (Item : in Character) return Character;
+ function To_Upper (Item : in Character) return Character;
+ function To_Basic (Item : in Character) return Character;
+
+7
+ function To_Lower (Item : in String) return String;
+ function To_Upper (Item : in String) return String;
+ function To_Basic (Item : in String) return String;
+
+8
+ --Classifications of and conversions between Character and ISO 646
+
+9
+ subtype ISO_646 is
+ Character range Character'Val(0) .. Character'Val(127);
+
+10
+ function Is_ISO_646 (Item : in Character) return Boolean;
+ function Is_ISO_646 (Item : in String) return Boolean;
+
+11
+ function To_ISO_646 (Item : in Character;
+ Substitute : in ISO_646 := ' ')
+ return ISO_646;
+
+12
+ function To_ISO_646 (Item : in String;
+ Substitute : in ISO_646 := ' ')
+ return String;
+
+13/2
+ {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01} -- The functions Is_Character, Is_String, To_Character, To_String, To_Wide_Character,
+ -- and To_Wide_String are obsolescent; see *note J.14::.
+
+ Paragraphs 14 through 18 were deleted.
+
+19
+ end Ada.Characters.Handling;
+
+19.a/2
+ Discussion: {AI95-00395-01AI95-00395-01} The with_clause for
+ Ada.Characters.Conversions is needed for the definition of the
+ obsolescent functions (see *note J.14::). It would be odd to
+ put this clause into *note J.14:: as it was not present in Ada
+ 95, and with_clauses are semantically neutral to clients
+ anyway.
+
+20
+In the description below for each function that returns a Boolean
+result, the effect is described in terms of the conditions under which
+the value True is returned. If these conditions are not met, then the
+function returns False.
+
+21
+Each of the following classification functions has a formal Character
+parameter, Item, and returns a Boolean result.
+
+22
+Is_Control
+ True if Item is a control character. A control character
+ is a character whose position is in one of the ranges
+ 0..31 or 127..159.
+
+23
+Is_Graphic
+ True if Item is a graphic character. A graphic character
+ is a character whose position is in one of the ranges
+ 32..126 or 160..255.
+
+24
+Is_Letter
+ True if Item is a letter. A letter is a character that
+ is in one of the ranges 'A'..'Z' or 'a'..'z', or whose
+ position is in one of the ranges 192..214, 216..246, or
+ 248..255.
+
+25
+Is_Lower
+ True if Item is a lower-case letter. A lower-case letter
+ is a character that is in the range 'a'..'z', or whose
+ position is in one of the ranges 223..246 or 248..255.
+
+26
+Is_Upper
+ True if Item is an upper-case letter. An upper-case
+ letter is a character that is in the range 'A'..'Z' or
+ whose position is in one of the ranges 192..214 or 216..
+ 222.
+
+27
+Is_Basic
+ True if Item is a basic letter. A basic letter is a
+ character that is in one of the ranges 'A'..'Z' and
+ 'a'..'z', or that is one of the following: 'Æ', 'æ', 'Ð',
+ 'ð', 'Þ', 'þ', or 'ß'.
+
+28
+Is_Digit
+ True if Item is a decimal digit. A decimal digit is a
+ character in the range '0'..'9'.
+
+29
+Is_Decimal_Digit
+ A renaming of Is_Digit.
+
+30
+Is_Hexadecimal_Digit
+ True if Item is a hexadecimal digit. A hexadecimal digit
+ is a character that is either a decimal digit or that is
+ in one of the ranges 'A' .. 'F' or 'a' .. 'f'.
+
+31
+Is_Alphanumeric
+ True if Item is an alphanumeric character. An
+ alphanumeric character is a character that is either a
+ letter or a decimal digit.
+
+32
+Is_Special
+ True if Item is a special graphic character. A special
+ graphic character is a graphic character that is not
+ alphanumeric.
+
+32.1/3
+{AI05-0185-1AI05-0185-1} Is_Line_Terminator
+ True if Item is a character with position 10 .. 13
+ (Line_Feed, Line_Tabulation, Form_Feed, Carriage_Return)
+ or 133 (Next_Line).
+
+32.2/3
+{AI05-0185-1AI05-0185-1} Is_Mark
+ Never True (no value of type Character has categories
+ Mark, Non-Spacing or Mark, Spacing Combining).
+
+32.3/3
+{AI05-0185-1AI05-0185-1} Is_Other_Format
+ True if Item is a character with position 173
+ (Soft_Hyphen).
+
+32.4/3
+{AI05-0185-1AI05-0185-1} Is_Punctuation_Connector
+ True if Item is a character with position 95 ('_', known
+ as Low_Line or Underscore).
+
+32.5/3
+{AI05-0185-1AI05-0185-1} Is_Space
+ True if Item is a character with position 32 (' ') or 160
+ (No_Break_Space).
+
+33
+Each of the names To_Lower, To_Upper, and To_Basic refers to two
+functions: one that converts from Character to Character, and the other
+that converts from String to String. The result of each
+Character-to-Character function is described below, in terms of the
+conversion applied to Item, its formal Character parameter. The result
+of each String-to-String conversion is obtained by applying to each
+element of the function's String parameter the corresponding
+Character-to-Character conversion; the result is the null String if the
+value of the formal parameter is the null String. The lower bound of
+the result String is 1.
+
+34
+To_Lower
+ Returns the corresponding lower-case value for Item if
+ Is_Upper(Item), and returns Item otherwise.
+
+35
+To_Upper
+ Returns the corresponding upper-case value for Item if
+ Is_Lower(Item) and Item has an upper-case form, and
+ returns Item otherwise. The lower case letters 'ß' and
+ 'ÿ' do not have upper case forms.
+
+36
+To_Basic
+ Returns the letter corresponding to Item but with no
+ diacritical mark, if Item is a letter but not a basic
+ letter; returns Item otherwise.
+
+37
+The following set of functions test for membership in the ISO 646
+character range, or convert between ISO 646 and Character.
+
+38
+Is_ISO_646
+ The function whose formal parameter, Item, is of type
+ Character returns True if Item is in the subtype ISO_646.
+
+39
+Is_ISO_646
+ The function whose formal parameter, Item, is of type
+ String returns True if Is_ISO_646(Item(I)) is True for
+ each I in Item'Range.
+
+40
+To_ISO_646
+ The function whose first formal parameter, Item, is of
+ type Character returns Item if Is_ISO_646(Item), and
+ returns the Substitute ISO_646 character otherwise.
+
+41
+To_ISO_646
+ The function whose first formal parameter, Item, is of
+ type String returns the String whose Range is
+ 1..Item'Length and each of whose elements is given by
+ To_ISO_646 of the corresponding element in Item.
+
+Paragraphs 42 through 49 were deleted.
+
+ NOTES
+
+50
+ 5 A basic letter is a letter without a diacritical mark.
+
+51
+ 6 Except for the hexadecimal digits, basic letters, and ISO_646
+ characters, the categories identified in the classification
+ functions form a strict hierarchy:
+
+52
+ -- Control characters
+
+53
+ -- Graphic characters
+
+54
+ -- Alphanumeric characters
+
+55
+ -- Letters
+
+56
+ -- Upper-case letters
+
+57
+ -- Lower-case letters
+
+58
+ -- Decimal digits
+
+59
+ -- Special graphic characters
+
+59.a
+ Ramification: Thus each Character value is either a control
+ character or a graphic character but not both; each graphic
+ character is either an alphanumeric or special graphic but not
+ both; each alphanumeric is either a letter or decimal digit
+ but not both; each letter is either upper case or lower case
+ but not both.
+
+60/3
+ 7 {AI05-0114-1AI05-0114-1} There are certain characters which are
+ defined to be lower case letters by ISO 10646 and are therefore
+ allowed in identifiers, but are not considered lower case letters
+ by Ada.Characters.Handling.
+
+60.a/3
+ Reason: This is to maintain runtime compatibility with the Ada
+ 95 definitions of these functions. We don't list the exact
+ characters involved because they're likely to change in future
+ character set standards; the list for ISO 10646:2011 can be
+ found in AI05-0114-1AI05-0114-1.
+
+60.b/3
+ Ramification: No version of Characters.Handling is intended to
+ do portable (Ada-version independent) manipulation of Ada
+ identifiers. The classification given by
+ Wide_Characters.Handling will be correct for the current
+ implementation for Ada 2012 identifiers, but it might not be
+ correct for a different implementation or version of Ada.
+
+ _Extensions to Ada 95_
+
+60.c/2
+ {AI95-00362-01AI95-00362-01} Characters.Handling is now Pure,
+ so it can be used in pure units.
+
+ _Incompatibilities With Ada 2005_
+
+60.d/3
+ {AI05-0185-1AI05-0185-1} Added additional classification
+ routines so that Characters.Handling has all of the routines
+ available in Wide_Characters.Handling. If Characters.Handling
+ is referenced in a use_clause, and an entity E with a
+ defining_identifier that is the same as one of the new
+ functions is defined in a package that is also referenced in a
+ use_clause, the entity E may no longer be use-visible,
+ resulting in errors. This should be rare and is easily fixed
+ if it does occur.
+
+ _Wording Changes from Ada 95_
+
+60.e/2
+ {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01} The
+ conversion functions are made obsolescent; a more complete set
+ is available in Characters.Conversions -- see *note A.3.4::.
+
+60.f/3
+ {AI95-00285-01AI95-00285-01} {AI05-0248-1AI05-0248-1} We no
+ longer talk about localized character sets; these are a
+ nonstandard mode, which is none of our business.
+
+ _Wording Changes from Ada 2005_
+
+60.g/3
+ {AI05-0114-1AI05-0114-1} Correction: Added a note to clarify
+ that these functions don't have any relationship to the
+ characters allowed in identifiers.
+
+\1f
+File: aarm2012.info, Node: A.3.3, Next: A.3.4, Prev: A.3.2, Up: A.3
+
+A.3.3 The Package Characters.Latin_1
+------------------------------------
+
+1
+The package Characters.Latin_1 declares constants for characters in ISO
+8859-1.
+
+1.a
+ Reason: The constants for the ISO 646 characters could have
+ been declared as renamings of objects declared in package
+ ASCII, as opposed to explicit constants. The main reason for
+ explicit constants was for consistency of style with the
+ upper-half constants, and to avoid emphasizing the package
+ ASCII.
+
+ _Static Semantics_
+
+2
+The library package Characters.Latin_1 has the following declaration:
+
+3
+ package Ada.Characters.Latin_1 is
+ pragma Pure(Latin_1);
+
+4
+ -- Control characters:
+
+5
+ NUL : constant Character := Character'Val(0);
+ SOH : constant Character := Character'Val(1);
+ STX : constant Character := Character'Val(2);
+ ETX : constant Character := Character'Val(3);
+ EOT : constant Character := Character'Val(4);
+ ENQ : constant Character := Character'Val(5);
+ ACK : constant Character := Character'Val(6);
+ BEL : constant Character := Character'Val(7);
+ BS : constant Character := Character'Val(8);
+ HT : constant Character := Character'Val(9);
+ LF : constant Character := Character'Val(10);
+ VT : constant Character := Character'Val(11);
+ FF : constant Character := Character'Val(12);
+ CR : constant Character := Character'Val(13);
+ SO : constant Character := Character'Val(14);
+ SI : constant Character := Character'Val(15);
+
+6
+ DLE : constant Character := Character'Val(16);
+ DC1 : constant Character := Character'Val(17);
+ DC2 : constant Character := Character'Val(18);
+ DC3 : constant Character := Character'Val(19);
+ DC4 : constant Character := Character'Val(20);
+ NAK : constant Character := Character'Val(21);
+ SYN : constant Character := Character'Val(22);
+ ETB : constant Character := Character'Val(23);
+ CAN : constant Character := Character'Val(24);
+ EM : constant Character := Character'Val(25);
+ SUB : constant Character := Character'Val(26);
+ ESC : constant Character := Character'Val(27);
+ FS : constant Character := Character'Val(28);
+ GS : constant Character := Character'Val(29);
+ RS : constant Character := Character'Val(30);
+ US : constant Character := Character'Val(31);
+
+7
+ -- ISO 646 graphic characters:
+
+8
+ Space : constant Character := ' '; -- Character'Val(32)
+ Exclamation : constant Character := '!'; -- Character'Val(33)
+ Quotation : constant Character := '"'; -- Character'Val(34)
+ Number_Sign : constant Character := '#'; -- Character'Val(35)
+ Dollar_Sign : constant Character := '$'; -- Character'Val(36)
+ Percent_Sign : constant Character := '%'; -- Character'Val(37)
+ Ampersand : constant Character := '&'; -- Character'Val(38)
+ Apostrophe : constant Character := '''; -- Character'Val(39)
+ Left_Parenthesis : constant Character := '('; -- Character'Val(40)
+ Right_Parenthesis : constant Character := ')'; -- Character'Val(41)
+ Asterisk : constant Character := '*'; -- Character'Val(42)
+ Plus_Sign : constant Character := '+'; -- Character'Val(43)
+ Comma : constant Character := ','; -- Character'Val(44)
+ Hyphen : constant Character := '-'; -- Character'Val(45)
+ Minus_Sign : Character renames Hyphen;
+ Full_Stop : constant Character := '.'; -- Character'Val(46)
+ Solidus : constant Character := '/'; -- Character'Val(47)
+
+9
+ -- Decimal digits '0' though '9' are at positions 48 through 57
+
+10
+ Colon : constant Character := ':'; -- Character'Val(58)
+ Semicolon : constant Character := ';'; -- Character'Val(59)
+ Less_Than_Sign : constant Character := '<'; -- Character'Val(60)
+ Equals_Sign : constant Character := '='; -- Character'Val(61)
+ Greater_Than_Sign : constant Character := '>'; -- Character'Val(62)
+ Question : constant Character := '?'; -- Character'Val(63)
+ Commercial_At : constant Character := '@'; -- Character'Val(64)
+
+11
+ -- Letters 'A' through 'Z' are at positions 65 through 90
+
+12
+ Left_Square_Bracket : constant Character := '['; -- Character'Val(91)
+ Reverse_Solidus : constant Character := '\'; -- Character'Val(92)
+ Right_Square_Bracket : constant Character := ']'; -- Character'Val(93)
+ Circumflex : constant Character := '^'; -- Character'Val(94)
+ Low_Line : constant Character := '_'; -- Character'Val(95)
+
+13
+ Grave : constant Character := '`'; -- Character'Val(96)
+ LC_A : constant Character := 'a'; -- Character'Val(97)
+ LC_B : constant Character := 'b'; -- Character'Val(98)
+ LC_C : constant Character := 'c'; -- Character'Val(99)
+ LC_D : constant Character := 'd'; -- Character'Val(100)
+ LC_E : constant Character := 'e'; -- Character'Val(101)
+ LC_F : constant Character := 'f'; -- Character'Val(102)
+ LC_G : constant Character := 'g'; -- Character'Val(103)
+ LC_H : constant Character := 'h'; -- Character'Val(104)
+ LC_I : constant Character := 'i'; -- Character'Val(105)
+ LC_J : constant Character := 'j'; -- Character'Val(106)
+ LC_K : constant Character := 'k'; -- Character'Val(107)
+ LC_L : constant Character := 'l'; -- Character'Val(108)
+ LC_M : constant Character := 'm'; -- Character'Val(109)
+ LC_N : constant Character := 'n'; -- Character'Val(110)
+ LC_O : constant Character := 'o'; -- Character'Val(111)
+
+14
+ LC_P : constant Character := 'p'; -- Character'Val(112)
+ LC_Q : constant Character := 'q'; -- Character'Val(113)
+ LC_R : constant Character := 'r'; -- Character'Val(114)
+ LC_S : constant Character := 's'; -- Character'Val(115)
+ LC_T : constant Character := 't'; -- Character'Val(116)
+ LC_U : constant Character := 'u'; -- Character'Val(117)
+ LC_V : constant Character := 'v'; -- Character'Val(118)
+ LC_W : constant Character := 'w'; -- Character'Val(119)
+ LC_X : constant Character := 'x'; -- Character'Val(120)
+ LC_Y : constant Character := 'y'; -- Character'Val(121)
+ LC_Z : constant Character := 'z'; -- Character'Val(122)
+ Left_Curly_Bracket : constant Character := '{'; -- Character'Val(123)
+ Vertical_Line : constant Character := '|'; -- Character'Val(124)
+ Right_Curly_Bracket : constant Character := '}'; -- Character'Val(125)
+ Tilde : constant Character := '~'; -- Character'Val(126)
+ DEL : constant Character := Character'Val(127);
+
+15
+ -- ISO 6429 control characters:
+
+16
+ IS4 : Character renames FS;
+ IS3 : Character renames GS;
+ IS2 : Character renames RS;
+ IS1 : Character renames US;
+
+17
+ Reserved_128 : constant Character := Character'Val(128);
+ Reserved_129 : constant Character := Character'Val(129);
+ BPH : constant Character := Character'Val(130);
+ NBH : constant Character := Character'Val(131);
+ Reserved_132 : constant Character := Character'Val(132);
+ NEL : constant Character := Character'Val(133);
+ SSA : constant Character := Character'Val(134);
+ ESA : constant Character := Character'Val(135);
+ HTS : constant Character := Character'Val(136);
+ HTJ : constant Character := Character'Val(137);
+ VTS : constant Character := Character'Val(138);
+ PLD : constant Character := Character'Val(139);
+ PLU : constant Character := Character'Val(140);
+ RI : constant Character := Character'Val(141);
+ SS2 : constant Character := Character'Val(142);
+ SS3 : constant Character := Character'Val(143);
+
+18
+ DCS : constant Character := Character'Val(144);
+ PU1 : constant Character := Character'Val(145);
+ PU2 : constant Character := Character'Val(146);
+ STS : constant Character := Character'Val(147);
+ CCH : constant Character := Character'Val(148);
+ MW : constant Character := Character'Val(149);
+ SPA : constant Character := Character'Val(150);
+ EPA : constant Character := Character'Val(151);
+
+19
+ SOS : constant Character := Character'Val(152);
+ Reserved_153 : constant Character := Character'Val(153);
+ SCI : constant Character := Character'Val(154);
+ CSI : constant Character := Character'Val(155);
+ ST : constant Character := Character'Val(156);
+ OSC : constant Character := Character'Val(157);
+ PM : constant Character := Character'Val(158);
+ APC : constant Character := Character'Val(159);
+
+20
+ -- Other graphic characters:
+
+21/3
+ {AI05-0181-1AI05-0181-1} -- Character positions 160 (16#A0#) .. 175 (16#AF#):
+ No_Break_Space : constant Character := ' '; --Character'Val(160)
+ NBSP : Character renames No_Break_Space;
+ Inverted_Exclamation : constant Character := '¡'; --Character'Val(161)
+ Cent_Sign : constant Character := '¢'; --Character'Val(162)
+ Pound_Sign : constant Character := '£'; --Character'Val(163)
+ Currency_Sign : constant Character := '¤'; --Character'Val(164)
+ Yen_Sign : constant Character := '¥'; --Character'Val(165)
+ Broken_Bar : constant Character := '¦'; --Character'Val(166)
+ Section_Sign : constant Character := '§'; --Character'Val(167)
+ Diaeresis : constant Character := '¨'; --Character'Val(168)
+ Copyright_Sign : constant Character := '©'; --Character'Val(169)
+ Feminine_Ordinal_Indicator : constant Character := 'ª'; --Character'Val(170)
+ Left_Angle_Quotation : constant Character := '«'; --Character'Val(171)
+ Not_Sign : constant Character := '¬'; --Character'Val(172)
+ Soft_Hyphen : constant Character := Character'Val(173);
+ Registered_Trade_Mark_Sign : constant Character := '®'; --Character'Val(174)
+ Macron : constant Character := '¯'; --Character'Val(175)
+
+22
+ -- Character positions 176 (16#B0#) .. 191 (16#BF#):
+ Degree_Sign : constant Character := '°'; --Character'Val(176)
+ Ring_Above : Character renames Degree_Sign;
+ Plus_Minus_Sign : constant Character := '±'; --Character'Val(177)
+ Superscript_Two : constant Character := '²'; --Character'Val(178)
+ Superscript_Three : constant Character := '³'; --Character'Val(179)
+ Acute : constant Character := '´'; --Character'Val(180)
+ Micro_Sign : constant Character := 'µ'; --Character'Val(181)
+ Pilcrow_Sign : constant Character := '¶'; --Character'Val(182)
+ Paragraph_Sign : Character renames Pilcrow_Sign;
+ Middle_Dot : constant Character := '·'; --Character'Val(183)
+ Cedilla : constant Character := '¸'; --Character'Val(184)
+ Superscript_One : constant Character := '¹'; --Character'Val(185)
+ Masculine_Ordinal_Indicator: constant Character := 'º'; --Character'Val(186)
+ Right_Angle_Quotation : constant Character := '»'; --Character'Val(187)
+ Fraction_One_Quarter : constant Character := '¼'; --Character'Val(188)
+ Fraction_One_Half : constant Character := '½'; --Character'Val(189)
+ Fraction_Three_Quarters : constant Character := '¾'; --Character'Val(190)
+ Inverted_Question : constant Character := '¿'; --Character'Val(191)
+
+23
+ -- Character positions 192 (16#C0#) .. 207 (16#CF#):
+ UC_A_Grave : constant Character := 'À'; --Character'Val(192)
+ UC_A_Acute : constant Character := 'Á'; --Character'Val(193)
+ UC_A_Circumflex : constant Character := 'Â'; --Character'Val(194)
+ UC_A_Tilde : constant Character := 'Ã'; --Character'Val(195)
+ UC_A_Diaeresis : constant Character := 'Ä'; --Character'Val(196)
+ UC_A_Ring : constant Character := 'Å'; --Character'Val(197)
+ UC_AE_Diphthong : constant Character := 'Æ'; --Character'Val(198)
+ UC_C_Cedilla : constant Character := 'Ç'; --Character'Val(199)
+ UC_E_Grave : constant Character := 'È'; --Character'Val(200)
+ UC_E_Acute : constant Character := 'É'; --Character'Val(201)
+ UC_E_Circumflex : constant Character := 'Ê'; --Character'Val(202)
+ UC_E_Diaeresis : constant Character := 'Ë'; --Character'Val(203)
+ UC_I_Grave : constant Character := 'Ì'; --Character'Val(204)
+ UC_I_Acute : constant Character := 'Í'; --Character'Val(205)
+ UC_I_Circumflex : constant Character := 'Î'; --Character'Val(206)
+ UC_I_Diaeresis : constant Character := 'Ï'; --Character'Val(207)
+
+24
+ -- Character positions 208 (16#D0#) .. 223 (16#DF#):
+ UC_Icelandic_Eth : constant Character := 'Ð'; --Character'Val(208)
+ UC_N_Tilde : constant Character := 'Ñ'; --Character'Val(209)
+ UC_O_Grave : constant Character := 'Ò'; --Character'Val(210)
+ UC_O_Acute : constant Character := 'Ó'; --Character'Val(211)
+ UC_O_Circumflex : constant Character := 'Ô'; --Character'Val(212)
+ UC_O_Tilde : constant Character := 'Õ'; --Character'Val(213)
+ UC_O_Diaeresis : constant Character := 'Ö'; --Character'Val(214)
+ Multiplication_Sign : constant Character := '×'; --Character'Val(215)
+ UC_O_Oblique_Stroke : constant Character := 'Ø'; --Character'Val(216)
+ UC_U_Grave : constant Character := 'Ù'; --Character'Val(217)
+ UC_U_Acute : constant Character := 'Ú'; --Character'Val(218)
+ UC_U_Circumflex : constant Character := 'Û'; --Character'Val(219)
+ UC_U_Diaeresis : constant Character := 'Ü'; --Character'Val(220)
+ UC_Y_Acute : constant Character := 'Ý'; --Character'Val(221)
+ UC_Icelandic_Thorn : constant Character := 'Þ'; --Character'Val(222)
+ LC_German_Sharp_S : constant Character := 'ß'; --Character'Val(223)
+
+25
+ -- Character positions 224 (16#E0#) .. 239 (16#EF#):
+ LC_A_Grave : constant Character := 'à'; --Character'Val(224)
+ LC_A_Acute : constant Character := 'á'; --Character'Val(225)
+ LC_A_Circumflex : constant Character := 'â'; --Character'Val(226)
+ LC_A_Tilde : constant Character := 'ã'; --Character'Val(227)
+ LC_A_Diaeresis : constant Character := 'ä'; --Character'Val(228)
+ LC_A_Ring : constant Character := 'å'; --Character'Val(229)
+ LC_AE_Diphthong : constant Character := 'æ'; --Character'Val(230)
+ LC_C_Cedilla : constant Character := 'ç'; --Character'Val(231)
+ LC_E_Grave : constant Character := 'è'; --Character'Val(232)
+ LC_E_Acute : constant Character := 'é'; --Character'Val(233)
+ LC_E_Circumflex : constant Character := 'ê'; --Character'Val(234)
+ LC_E_Diaeresis : constant Character := 'ë'; --Character'Val(235)
+ LC_I_Grave : constant Character := 'ì'; --Character'Val(236)
+ LC_I_Acute : constant Character := 'í'; --Character'Val(237)
+ LC_I_Circumflex : constant Character := 'î'; --Character'Val(238)
+ LC_I_Diaeresis : constant Character := 'ï'; --Character'Val(239)
+
+26
+ -- Character positions 240 (16#F0#) .. 255 (16#FF#):
+ LC_Icelandic_Eth : constant Character := 'ð'; --Character'Val(240)
+ LC_N_Tilde : constant Character := 'ñ'; --Character'Val(241)
+ LC_O_Grave : constant Character := 'ò'; --Character'Val(242)
+ LC_O_Acute : constant Character := 'ó'; --Character'Val(243)
+ LC_O_Circumflex : constant Character := 'ô'; --Character'Val(244)
+ LC_O_Tilde : constant Character := 'õ'; --Character'Val(245)
+ LC_O_Diaeresis : constant Character := 'ö'; --Character'Val(246)
+ Division_Sign : constant Character := '÷'; --Character'Val(247)
+ LC_O_Oblique_Stroke : constant Character := 'ø'; --Character'Val(248)
+ LC_U_Grave : constant Character := 'ù'; --Character'Val(249)
+ LC_U_Acute : constant Character := 'ú'; --Character'Val(250)
+ LC_U_Circumflex : constant Character := 'û'; --Character'Val(251)
+ LC_U_Diaeresis : constant Character := 'ü'; --Character'Val(252)
+ LC_Y_Acute : constant Character := 'ý'; --Character'Val(253)
+ LC_Icelandic_Thorn : constant Character := 'þ'; --Character'Val(254)
+ LC_Y_Diaeresis : constant Character := 'ÿ'; --Character'Val(255)
+ end Ada.Characters.Latin_1;
+
+ _Implementation Permissions_
+
+27
+An implementation may provide additional packages as children of
+Ada.Characters, to declare names for the symbols of the local character
+set or other character sets.
+
+ _Wording Changes from Ada 2005_
+
+27.a/3
+ {AI05-0181-1AI05-0181-1} Correction: Soft_Hyphen is not a
+ graphic character, and thus a character literal for it is
+ illegal. So we have to use the position value. This makes no
+ semantic change to users of the constant.
+
+\1f
+File: aarm2012.info, Node: A.3.4, Next: A.3.5, Prev: A.3.3, Up: A.3
+
+A.3.4 The Package Characters.Conversions
+----------------------------------------
+
+ _Static Semantics_
+
+1/2
+{AI95-00395-01AI95-00395-01} The library package Characters.Conversions
+has the following declaration:
+
+2/2
+ package Ada.Characters.Conversions is
+ pragma Pure(Conversions);
+
+3/2
+ function Is_Character (Item : in Wide_Character) return Boolean;
+ function Is_String (Item : in Wide_String) return Boolean;
+ function Is_Character (Item : in Wide_Wide_Character) return Boolean;
+ function Is_String (Item : in Wide_Wide_String) return Boolean;
+ function Is_Wide_Character (Item : in Wide_Wide_Character)
+ return Boolean;
+ function Is_Wide_String (Item : in Wide_Wide_String)
+ return Boolean;
+
+4/2
+ function To_Wide_Character (Item : in Character) return Wide_Character;
+ function To_Wide_String (Item : in String) return Wide_String;
+ function To_Wide_Wide_Character (Item : in Character)
+ return Wide_Wide_Character;
+ function To_Wide_Wide_String (Item : in String)
+ return Wide_Wide_String;
+ function To_Wide_Wide_Character (Item : in Wide_Character)
+ return Wide_Wide_Character;
+ function To_Wide_Wide_String (Item : in Wide_String)
+ return Wide_Wide_String;
+
+5/2
+ function To_Character (Item : in Wide_Character;
+ Substitute : in Character := ' ')
+ return Character;
+ function To_String (Item : in Wide_String;
+ Substitute : in Character := ' ')
+ return String;
+ function To_Character (Item : in Wide_Wide_Character;
+ Substitute : in Character := ' ')
+ return Character;
+ function To_String (Item : in Wide_Wide_String;
+ Substitute : in Character := ' ')
+ return String;
+ function To_Wide_Character (Item : in Wide_Wide_Character;
+ Substitute : in Wide_Character := ' ')
+ return Wide_Character;
+ function To_Wide_String (Item : in Wide_Wide_String;
+ Substitute : in Wide_Character := ' ')
+ return Wide_String;
+
+6/2
+ end Ada.Characters.Conversions;
+
+7/2
+{AI95-00395-01AI95-00395-01} The functions in package
+Characters.Conversions test Wide_Wide_Character or Wide_Character values
+for membership in Wide_Character or Character, or convert between
+corresponding characters of Wide_Wide_Character, Wide_Character, and
+Character.
+
+8/2
+ function Is_Character (Item : in Wide_Character) return Boolean;
+
+9/2
+ {AI95-00395-01AI95-00395-01} Returns True if
+ Wide_Character'Pos(Item) <= Character'Pos(Character'Last).
+
+10/2
+ function Is_Character (Item : in Wide_Wide_Character) return Boolean;
+
+11/2
+ {AI95-00395-01AI95-00395-01} Returns True if
+ Wide_Wide_Character'Pos(Item) <=
+ Character'Pos(Character'Last).
+
+12/2
+ function Is_Wide_Character (Item : in Wide_Wide_Character) return Boolean;
+
+13/2
+ {AI95-00395-01AI95-00395-01} Returns True if
+ Wide_Wide_Character'Pos(Item) <=
+ Wide_Character'Pos(Wide_Character'Last).
+
+14/2
+ function Is_String (Item : in Wide_String) return Boolean;
+ function Is_String (Item : in Wide_Wide_String) return Boolean;
+
+15/2
+ {AI95-00395-01AI95-00395-01} Returns True if
+ Is_Character(Item(I)) is True for each I in Item'Range.
+
+16/2
+ function Is_Wide_String (Item : in Wide_Wide_String) return Boolean;
+
+17/2
+ {AI95-00395-01AI95-00395-01} Returns True if
+ Is_Wide_Character(Item(I)) is True for each I in Item'Range.
+
+18/2
+ function To_Character (Item : in Wide_Character;
+ Substitute : in Character := ' ') return Character;
+ function To_Character (Item : in Wide_Wide_Character;
+ Substitute : in Character := ' ') return Character;
+
+19/2
+ {AI95-00395-01AI95-00395-01} Returns the Character
+ corresponding to Item if Is_Character(Item), and returns the
+ Substitute Character otherwise.
+
+20/2
+ function To_Wide_Character (Item : in Character) return Wide_Character;
+
+21/2
+ {AI95-00395-01AI95-00395-01} Returns the Wide_Character X such
+ that Character'Pos(Item) = Wide_Character'Pos (X).
+
+22/2
+ function To_Wide_Character (Item : in Wide_Wide_Character;
+ Substitute : in Wide_Character := ' ')
+ return Wide_Character;
+
+23/2
+ {AI95-00395-01AI95-00395-01} Returns the Wide_Character
+ corresponding to Item if Is_Wide_Character(Item), and returns
+ the Substitute Wide_Character otherwise.
+
+24/2
+ function To_Wide_Wide_Character (Item : in Character)
+ return Wide_Wide_Character;
+
+25/2
+ {AI95-00395-01AI95-00395-01} Returns the Wide_Wide_Character X
+ such that Character'Pos(Item) = Wide_Wide_Character'Pos (X).
+
+26/2
+ function To_Wide_Wide_Character (Item : in Wide_Character)
+ return Wide_Wide_Character;
+
+27/2
+ {AI95-00395-01AI95-00395-01} Returns the Wide_Wide_Character X
+ such that Wide_Character'Pos(Item) = Wide_Wide_Character'Pos
+ (X).
+
+28/2
+ function To_String (Item : in Wide_String;
+ Substitute : in Character := ' ') return String;
+ function To_String (Item : in Wide_Wide_String;
+ Substitute : in Character := ' ') return String;
+
+29/2
+ {AI95-00395-01AI95-00395-01} Returns the String whose range is
+ 1..Item'Length and each of whose elements is given by
+ To_Character of the corresponding element in Item.
+
+30/2
+ function To_Wide_String (Item : in String) return Wide_String;
+
+31/2
+ {AI95-00395-01AI95-00395-01} Returns the Wide_String whose
+ range is 1..Item'Length and each of whose elements is given by
+ To_Wide_Character of the corresponding element in Item.
+
+32/2
+ function To_Wide_String (Item : in Wide_Wide_String;
+ Substitute : in Wide_Character := ' ')
+ return Wide_String;
+
+33/2
+ {AI95-00395-01AI95-00395-01} Returns the Wide_String whose
+ range is 1..Item'Length and each of whose elements is given by
+ To_Wide_Character of the corresponding element in Item with
+ the given Substitute Wide_Character.
+
+34/2
+ function To_Wide_Wide_String (Item : in String) return Wide_Wide_String;
+ function To_Wide_Wide_String (Item : in Wide_String)
+ return Wide_Wide_String;
+
+35/2
+ {AI95-00395-01AI95-00395-01} Returns the Wide_Wide_String
+ whose range is 1..Item'Length and each of whose elements is
+ given by To_Wide_Wide_Character of the corresponding element
+ in Item.
+
+ _Extensions to Ada 95_
+
+35.a/2
+ {AI95-00395-01AI95-00395-01} The package
+ Characters.Conversions is new, replacing functions previously
+ found in Characters.Handling.
+
+\1f
+File: aarm2012.info, Node: A.3.5, Next: A.3.6, Prev: A.3.4, Up: A.3
+
+A.3.5 The Package Wide_Characters.Handling
+------------------------------------------
+
+1/3
+{AI05-0185-1AI05-0185-1} The package Wide_Characters.Handling provides
+operations for classifying Wide_Characters and case folding for
+Wide_Characters.
+
+ _Static Semantics_
+
+2/3
+{AI05-0185-1AI05-0185-1} The library package Wide_Characters.Handling
+has the following declaration:
+
+3/3
+ {AI05-0185-1AI05-0185-1} {AI05-0266-1AI05-0266-1} package Ada.Wide_Characters.Handling is
+ pragma Pure(Handling);
+
+4/3
+ {AI05-0266-1AI05-0266-1} function Character_Set_Version return String;
+
+5/3
+ function Is_Control (Item : Wide_Character) return Boolean;
+
+6/3
+ function Is_Letter (Item : Wide_Character) return Boolean;
+
+7/3
+ function Is_Lower (Item : Wide_Character) return Boolean;
+
+8/3
+ function Is_Upper (Item : Wide_Character) return Boolean;
+
+9/3
+ function Is_Digit (Item : Wide_Character) return Boolean;
+
+10/3
+ function Is_Decimal_Digit (Item : Wide_Character) return Boolean
+ renames Is_Digit;
+
+11/3
+ function Is_Hexadecimal_Digit (Item : Wide_Character) return Boolean;
+
+12/3
+ function Is_Alphanumeric (Item : Wide_Character) return Boolean;
+
+13/3
+ function Is_Special (Item : Wide_Character) return Boolean;
+
+14/3
+ function Is_Line_Terminator (Item : Wide_Character) return Boolean;
+
+15/3
+ function Is_Mark (Item : Wide_Character) return Boolean;
+
+16/3
+ function Is_Other_Format (Item : Wide_Character) return Boolean;
+
+17/3
+ function Is_Punctuation_Connector (Item : Wide_Character) return Boolean;
+
+18/3
+ function Is_Space (Item : Wide_Character) return Boolean;
+
+19/3
+ function Is_Graphic (Item : Wide_Character) return Boolean;
+
+20/3
+ function To_Lower (Item : Wide_Character) return Wide_Character;
+ function To_Upper (Item : Wide_Character) return Wide_Character;
+
+21/3
+ function To_Lower (Item : Wide_String) return Wide_String;
+ function To_Upper (Item : Wide_String) return Wide_String;
+
+22/3
+ end Ada.Wide_Characters.Handling;
+
+23/3
+{AI05-0185-1AI05-0185-1} The subprograms defined in
+Wide_Characters.Handling are locale independent.
+
+24/3
+ function Character_Set_Version return String;
+
+25/3
+ {AI05-0266-1AI05-0266-1} Returns an implementation-defined
+ identifier that identifies the version of the character set
+ standard that is used for categorizing characters by the
+ implementation.
+
+26/3
+ function Is_Control (Item : Wide_Character) return Boolean;
+
+27/3
+ {AI05-0185-1AI05-0185-1} Returns True if the Wide_Character
+ designated by Item is categorized as other_control; otherwise
+ returns False.
+
+28/3
+ function Is_Letter (Item : Wide_Character) return Boolean;
+
+29/3
+ {AI05-0185-1AI05-0185-1} Returns True if the Wide_Character
+ designated by Item is categorized as letter_uppercase,
+ letter_lowercase, letter_titlecase, letter_modifier,
+ letter_other, or number_letter; otherwise returns False.
+
+30/3
+ function Is_Lower (Item : Wide_Character) return Boolean;
+
+31/3
+ {AI05-0185-1AI05-0185-1} Returns True if the Wide_Character
+ designated by Item is categorized as letter_lowercase;
+ otherwise returns False.
+
+32/3
+ function Is_Upper (Item : Wide_Character) return Boolean;
+
+33/3
+ {AI05-0185-1AI05-0185-1} Returns True if the Wide_Character
+ designated by Item is categorized as letter_uppercase;
+ otherwise returns False.
+
+34/3
+ function Is_Digit (Item : Wide_Character) return Boolean;
+
+35/3
+ {AI05-0185-1AI05-0185-1} Returns True if the Wide_Character
+ designated by Item is categorized as number_decimal; otherwise
+ returns False.
+
+36/3
+ function Is_Hexadecimal_Digit (Item : Wide_Character) return Boolean;
+
+37/3
+ {AI05-0185-1AI05-0185-1} Returns True if the Wide_Character
+ designated by Item is categorized as number_decimal, or is in
+ the range 'A' .. 'F' or 'a' .. 'f'; otherwise returns False.
+
+38/3
+ function Is_Alphanumeric (Item : Wide_Character) return Boolean;
+
+39/3
+ {AI05-0185-1AI05-0185-1} Returns True if the Wide_Character
+ designated by Item is categorized as letter_uppercase,
+ letter_lowercase, letter_titlecase, letter_modifier,
+ letter_other, number_letter, or number_decimal; otherwise
+ returns False.
+
+40/3
+ function Is_Special (Item : Wide_Character) return Boolean;
+
+41/3
+ {AI05-0185-1AI05-0185-1} Returns True if the Wide_Character
+ designated by Item is categorized as graphic_character, but
+ not categorized as letter_uppercase, letter_lowercase,
+ letter_titlecase, letter_modifier, letter_other,
+ number_letter, or number_decimal; otherwise returns False.
+
+42/3
+ function Is_Line_Terminator (Item : Wide_Character) return Boolean;
+
+43/3
+ {AI05-0185-1AI05-0185-1} Returns True if the Wide_Character
+ designated by Item is categorized as separator_line or
+ separator_paragraph, or if Item is a conventional line
+ terminator character (Line_Feed, Line_Tabulation, Form_Feed,
+ Carriage_Return, Next_Line); otherwise returns False.
+
+44/3
+ function Is_Mark (Item : Wide_Character) return Boolean;
+
+45/3
+ {AI05-0185-1AI05-0185-1} Returns True if the Wide_Character
+ designated by Item is categorized as mark_non_spacing or
+ mark_spacing_combining; otherwise returns False.
+
+46/3
+ function Is_Other_Format (Item : Wide_Character) return Boolean;
+
+47/3
+ {AI05-0185-1AI05-0185-1} Returns True if the Wide_Character
+ designated by Item is categorized as other_format; otherwise
+ returns False.
+
+48/3
+ function Is_Punctuation_Connector (Item : Wide_Character) return Boolean;
+
+49/3
+ {AI05-0185-1AI05-0185-1} Returns True if the Wide_Character
+ designated by Item is categorized as punctuation_connector;
+ otherwise returns False.
+
+50/3
+ function Is_Space (Item : Wide_Character) return Boolean;
+
+51/3
+ {AI05-0185-1AI05-0185-1} Returns True if the Wide_Character
+ designated by Item is categorized as separator_space;
+ otherwise returns False.
+
+52/3
+ function Is_Graphic (Item : Wide_Character) return Boolean;
+
+53/3
+ {AI05-0185-1AI05-0185-1} Returns True if the Wide_Character
+ designated by Item is categorized as graphic_character;
+ otherwise returns False.
+
+54/3
+ function To_Lower (Item : Wide_Character) return Wide_Character;
+
+55/3
+ {AI05-0185-1AI05-0185-1} {AI05-0266-1AI05-0266-1}
+ {AI05-0299-1AI05-0299-1} Returns the Simple Lowercase Mapping
+ as defined by documents referenced in the note in Clause 1 of
+ ISO/IEC 10646:2011 of the Wide_Character designated by Item.
+ If the Simple Lowercase Mapping does not exist for the
+ Wide_Character designated by Item, then the value of Item is
+ returned.
+
+55.a/3
+ Discussion: The case mappings come from Unicode as ISO/IEC
+ 10646:2011 does not include case mappings (but rather
+ references the Unicode ones as above).
+
+56/3
+ function To_Lower (Item : Wide_String) return Wide_String;
+
+57/3
+ {AI05-0185-1AI05-0185-1} Returns the result of applying the
+ To_Lower conversion to each Wide_Character element of the
+ Wide_String designated by Item. The result is the null
+ Wide_String if the value of the formal parameter is the null
+ Wide_String. The lower bound of the result Wide_String is 1.
+
+58/3
+ function To_Upper (Item : Wide_Character) return Wide_Character;
+
+59/3
+ {AI05-0185-1AI05-0185-1} {AI05-0266-1AI05-0266-1}
+ {AI05-0299-1AI05-0299-1} Returns the Simple Uppercase Mapping
+ as defined by documents referenced in the note in Clause 1 of
+ ISO/IEC 10646:2011 of the Wide_Character designated by Item.
+ If the Simple Uppercase Mapping does not exist for the
+ Wide_Character designated by Item, then the value of Item is
+ returned.
+
+60/3
+ function To_Upper (Item : Wide_String) return Wide_String;
+
+61/3
+ {AI05-0185-1AI05-0185-1} Returns the result of applying the
+ To_Upper conversion to each Wide_Character element of the
+ Wide_String designated by Item. The result is the null
+ Wide_String if the value of the formal parameter is the null
+ Wide_String. The lower bound of the result Wide_String is 1.
+
+ _Implementation Advice_
+
+62/3
+{AI05-0266-1AI05-0266-1} The string returned by Character_Set_Version
+should include either "10646:" or "Unicode".
+
+62.a.1/3
+ Implementation Advice: The string returned by
+ Wide_Characters.Handling.Character_Set_Version should include
+ either "10646:" or "Unicode".
+
+62.a/3
+ Discussion: The intent is that the returned string include the
+ year for 10646 (as in "10646:2011"), and the version number
+ for Unicode (as in "Unicode 6.0"). We don't try to specify
+ that further so we don't need to decide how to represent
+ Corrigenda for 10646, nor which of these is preferred.
+ (Giving a Unicode version is more accurate, as the case
+ folding and mapping rules always come from a Unicode version
+ [10646 just tells one to look at Unicode to get those], and
+ the character classifications ought to be the same for
+ equivalent versions, but we don't want to talk about non-ISO
+ standards in an ISO standard.)
+
+ NOTES
+
+63/3
+ 8 {AI05-0266-1AI05-0266-1} The results returned by these functions
+ may depend on which particular version of the 10646 standard is
+ supported by the implementation (see *note 2.1::).
+
+64/3
+ 9 {AI05-0286-1AI05-0286-1} The case insensitive equality
+ comparison routines provided in *note A.4.10::, "*note A.4.10::
+ String Comparison" are also available for wide strings (see *note
+ A.4.7::).
+
+ _Extensions to Ada 2005_
+
+64.a/3
+ {AI05-0185-1AI05-0185-1} {AI05-0266-1AI05-0266-1} The package
+ Wide_Characters.Handling is new.
+
+\1f
+File: aarm2012.info, Node: A.3.6, Prev: A.3.5, Up: A.3
+
+A.3.6 The Package Wide_Wide_Characters.Handling
+-----------------------------------------------
+
+1/3
+{AI05-0185-1AI05-0185-1} The package Wide_Wide_Characters.Handling has
+the same contents as Wide_Characters.Handling except that each
+occurrence of Wide_Character is replaced by Wide_Wide_Character, and
+each occurrence of Wide_String is replaced by Wide_Wide_String.
+
+ _Extensions to Ada 2005_
+
+1.a/3
+ {AI05-0185-1AI05-0185-1} The package
+ Wide_Wide_Characters.Handling is new.
+
+\1f
+File: aarm2012.info, Node: A.4, Next: A.5, Prev: A.3, Up: Annex A
+
+A.4 String Handling
+===================
+
+1/3
+{AI95-00285-01AI95-00285-01} {AI05-0299-1AI05-0299-1} This subclause
+presents the specifications of the package Strings and several child
+packages, which provide facilities for dealing with string data.
+Fixed-length, bounded-length, and unbounded-length strings are
+supported, for String, Wide_String, and Wide_Wide_String. The
+string-handling subprograms include searches for pattern strings and for
+characters in program-specified sets, translation (via a
+character-to-character mapping), and transformation (replacing,
+inserting, overwriting, and deleting of substrings).
+
+ _Extensions to Ada 83_
+
+1.a/3
+ {AI05-0299-1AI05-0299-1} This subclause is new to Ada 95.
+
+ _Wording Changes from Ada 95_
+
+1.b/2
+ {AI95-00285-01AI95-00285-01} Included Wide_Wide_String in this
+ description; the individual changes are documented as
+ extensions as needed.
+
+* Menu:
+
+* A.4.1 :: The Package Strings
+* A.4.2 :: The Package Strings.Maps
+* A.4.3 :: Fixed-Length String Handling
+* A.4.4 :: Bounded-Length String Handling
+* A.4.5 :: Unbounded-Length String Handling
+* A.4.6 :: String-Handling Sets and Mappings
+* A.4.7 :: Wide_String Handling
+* A.4.8 :: Wide_Wide_String Handling
+* A.4.9 :: String Hashing
+* A.4.10 :: String Comparison
+* A.4.11 :: String Encoding
+
+\1f
+File: aarm2012.info, Node: A.4.1, Next: A.4.2, Up: A.4
+
+A.4.1 The Package Strings
+-------------------------
+
+1
+The package Strings provides declarations common to the string handling
+packages.
+
+ _Static Semantics_
+
+2
+The library package Strings has the following declaration:
+
+3
+ package Ada.Strings is
+ pragma Pure(Strings);
+
+4/2
+ {AI95-00285-01AI95-00285-01} Space : constant Character := ' ';
+ Wide_Space : constant Wide_Character := ' ';
+ Wide_Wide_Space : constant Wide_Wide_Character := ' ';
+
+5
+ Length_Error, Pattern_Error, Index_Error, Translation_Error : exception;
+
+6
+ type Alignment is (Left, Right, Center);
+ type Truncation is (Left, Right, Error);
+ type Membership is (Inside, Outside);
+ type Direction is (Forward, Backward);
+ type Trim_End is (Left, Right, Both);
+ end Ada.Strings;
+
+ _Incompatibilities With Ada 95_
+
+6.a/3
+ {AI95-00285-01AI95-00285-01} {AI05-0005-1AI05-0005-1} Constant
+ Wide_Wide_Space is added to Ada.Strings. If Ada.Strings is
+ referenced in a use_clause, and an entity E with a
+ defining_identifier of Wide_Wide_Space is defined in a package
+ that is also referenced in a use_clause, the entity E may no
+ longer be use-visible, resulting in errors. This should be
+ rare and is easily fixed if it does occur.
+
+\1f
+File: aarm2012.info, Node: A.4.2, Next: A.4.3, Prev: A.4.1, Up: A.4
+
+A.4.2 The Package Strings.Maps
+------------------------------
+
+1
+The package Strings.Maps defines the types, operations, and other
+entities needed for character sets and character-to-character mappings.
+
+ _Static Semantics_
+
+2
+The library package Strings.Maps has the following declaration:
+
+3/2
+ {AI95-00362-01AI95-00362-01} package Ada.Strings.Maps is
+ pragma Pure(Maps);
+
+4/2
+ {AI95-00161-01AI95-00161-01} -- Representation for a set of character values:
+ type Character_Set is private;
+ pragma Preelaborable_Initialization(Character_Set);
+
+5
+ Null_Set : constant Character_Set;
+
+6
+ type Character_Range is
+ record
+ Low : Character;
+ High : Character;
+ end record;
+ -- Represents Character range Low..High
+
+7
+ type Character_Ranges is array (Positive range <>) of Character_Range;
+
+8
+ function To_Set (Ranges : in Character_Ranges)return Character_Set;
+
+9
+ function To_Set (Span : in Character_Range)return Character_Set;
+
+10
+ function To_Ranges (Set : in Character_Set) return Character_Ranges;
+
+11
+ function "=" (Left, Right : in Character_Set) return Boolean;
+
+12
+ function "not" (Right : in Character_Set) return Character_Set;
+ function "and" (Left, Right : in Character_Set) return Character_Set;
+ function "or" (Left, Right : in Character_Set) return Character_Set;
+ function "xor" (Left, Right : in Character_Set) return Character_Set;
+ function "-" (Left, Right : in Character_Set) return Character_Set;
+
+13
+ function Is_In (Element : in Character;
+ Set : in Character_Set)
+ return Boolean;
+
+14
+ function Is_Subset (Elements : in Character_Set;
+ Set : in Character_Set)
+ return Boolean;
+
+15
+ function "<=" (Left : in Character_Set;
+ Right : in Character_Set)
+ return Boolean renames Is_Subset;
+
+16
+ -- Alternative representation for a set of character values:
+ subtype Character_Sequence is String;
+
+17
+ function To_Set (Sequence : in Character_Sequence)return Character_Set;
+
+18
+ function To_Set (Singleton : in Character) return Character_Set;
+
+19
+ function To_Sequence (Set : in Character_Set) return Character_Sequence;
+
+20/2
+ {AI95-00161-01AI95-00161-01} -- Representation for a character to character mapping:
+ type Character_Mapping is private;
+ pragma Preelaborable_Initialization(Character_Mapping);
+
+21
+ function Value (Map : in Character_Mapping;
+ Element : in Character)
+ return Character;
+
+22
+ Identity : constant Character_Mapping;
+
+23
+ function To_Mapping (From, To : in Character_Sequence)
+ return Character_Mapping;
+
+24
+ function To_Domain (Map : in Character_Mapping)
+ return Character_Sequence;
+ function To_Range (Map : in Character_Mapping)
+ return Character_Sequence;
+
+25
+ type Character_Mapping_Function is
+ access function (From : in Character) return Character;
+
+26
+ private
+ ... -- not specified by the language
+ end Ada.Strings.Maps;
+
+27
+An object of type Character_Set represents a set of characters.
+
+28
+Null_Set represents the set containing no characters.
+
+29
+An object Obj of type Character_Range represents the set of characters
+in the range Obj.Low .. Obj.High.
+
+30
+An object Obj of type Character_Ranges represents the union of the sets
+corresponding to Obj(I) for I in Obj'Range.
+
+31
+ function To_Set (Ranges : in Character_Ranges) return Character_Set;
+
+32/3
+ {AI05-0264-1AI05-0264-1} If Ranges'Length=0 then Null_Set is
+ returned; otherwise, the returned value represents the set
+ corresponding to Ranges.
+
+33
+ function To_Set (Span : in Character_Range) return Character_Set;
+
+34
+ The returned value represents the set containing each
+ character in Span.
+
+35
+ function To_Ranges (Set : in Character_Set) return Character_Ranges;
+
+36/3
+ {AI05-0264-1AI05-0264-1} If Set = Null_Set, then an empty
+ Character_Ranges array is returned; otherwise, the shortest
+ array of contiguous ranges of Character values in Set, in
+ increasing order of Low, is returned.
+
+37
+ function "=" (Left, Right : in Character_Set) return Boolean;
+
+38
+ The function "=" returns True if Left and Right represent
+ identical sets, and False otherwise.
+
+39
+Each of the logical operators "not", "and", "or", and "xor" returns a
+Character_Set value that represents the set obtained by applying the
+corresponding operation to the set(s) represented by the parameter(s) of
+the operator. "-"(Left, Right) is equivalent to "and"(Left,
+"not"(Right)).
+
+39.a
+ Reason: The set minus operator is provided for efficiency.
+
+40
+ function Is_In (Element : in Character;
+ Set : in Character_Set);
+ return Boolean;
+
+41
+ Is_In returns True if Element is in Set, and False otherwise.
+
+42
+ function Is_Subset (Elements : in Character_Set;
+ Set : in Character_Set)
+ return Boolean;
+
+43
+ Is_Subset returns True if Elements is a subset of Set, and
+ False otherwise.
+
+44
+ subtype Character_Sequence is String;
+
+45
+ The Character_Sequence subtype is used to portray a set of
+ character values and also to identify the domain and range of
+ a character mapping.
+
+45.a
+ Reason: Although a named subtype is redundant -- the
+ predefined type String could have been used for the parameter
+ to To_Set and To_Mapping below -- the use of a differently
+ named subtype identifies the intended purpose of the
+ parameter.
+
+46
+ function To_Set (Sequence : in Character_Sequence) return Character_Set;
+
+ function To_Set (Singleton : in Character) return Character_Set;
+
+47
+ Sequence portrays the set of character values that it
+ explicitly contains (ignoring duplicates). Singleton portrays
+ the set comprising a single Character. Each of the To_Set
+ functions returns a Character_Set value that represents the
+ set portrayed by Sequence or Singleton.
+
+48
+ function To_Sequence (Set : in Character_Set) return Character_Sequence;
+
+49
+ The function To_Sequence returns a Character_Sequence value
+ containing each of the characters in the set represented by
+ Set, in ascending order with no duplicates.
+
+50
+ type Character_Mapping is private;
+
+51
+ An object of type Character_Mapping represents a
+ Character-to-Character mapping.
+
+52
+ function Value (Map : in Character_Mapping;
+ Element : in Character)
+ return Character;
+
+53
+ The function Value returns the Character value to which
+ Element maps with respect to the mapping represented by Map.
+
+54
+A character C matches a pattern character P with respect to a given
+Character_Mapping value Map if Value(Map, C) = P. A string S matches a
+pattern string P with respect to a given Character_Mapping if their
+lengths are the same and if each character in S matches its
+corresponding character in the pattern string P.
+
+54.a
+ Discussion: In an earlier version of the string handling
+ packages, the definition of matching was symmetrical, namely C
+ matches P if Value(Map,C) = Value(Map,P). However, applying
+ the mapping to the pattern was confusing according to some
+ reviewers. Furthermore, if the symmetrical version is needed,
+ it can be achieved by applying the mapping to the pattern (via
+ translation) prior to passing it as a parameter.
+
+55
+String handling subprograms that deal with character mappings have
+parameters whose type is Character_Mapping.
+
+56
+ Identity : constant Character_Mapping;
+
+57
+ Identity maps each Character to itself.
+
+58
+ function To_Mapping (From, To : in Character_Sequence)
+ return Character_Mapping;
+
+59
+ To_Mapping produces a Character_Mapping such that each element
+ of From maps to the corresponding element of To, and each
+ other character maps to itself. If From'Length /= To'Length,
+ or if some character is repeated in From, then
+ Translation_Error is propagated.
+
+60
+ function To_Domain (Map : in Character_Mapping) return Character_Sequence;
+
+61
+ To_Domain returns the shortest Character_Sequence value D such
+ that each character not in D maps to itself, and such that the
+ characters in D are in ascending order. The lower bound of D
+ is 1.
+
+62
+ function To_Range (Map : in Character_Mapping) return Character_Sequence;
+
+63/1
+ {8652/00488652/0048} {AI95-00151-01AI95-00151-01} To_Range
+ returns the Character_Sequence value R, such that if D =
+ To_Domain(Map), then R has the same bounds as D, and D(I) maps
+ to R(I) for each I in D'Range.
+
+64
+An object F of type Character_Mapping_Function maps a Character value C
+to the Character value F.all(C), which is said to match C with respect
+to mapping function F.
+
+ NOTES
+
+65
+ 10 Character_Mapping and Character_Mapping_Function are used both
+ for character equivalence mappings in the search subprograms (such
+ as for case insensitivity) and as transformational mappings in the
+ Translate subprograms.
+
+66
+ 11 To_Domain(Identity) and To_Range(Identity) each returns the
+ null string.
+
+66.a
+ Reason: Package Strings.Maps is not pure, since it declares an
+ access-to-subprogram type.
+
+ _Examples_
+
+67
+To_Mapping("ABCD", "ZZAB") returns a Character_Mapping that maps 'A' and
+'B' to 'Z', 'C' to 'A', 'D' to 'B', and each other Character to itself.
+
+ _Extensions to Ada 95_
+
+67.a/2
+ {AI95-00161-01AI95-00161-01} Amendment Correction: Added
+ pragma Preelaborable_Initialization to types Character_Set and
+ Character_Mapping, so that they can be used to declare
+ default-initialized objects in preelaborated units.
+
+67.b/2
+ {AI95-00362-01AI95-00362-01} Strings.Maps is now Pure, so it
+ can be used in pure units.
+
+ _Wording Changes from Ada 95_
+
+67.c/2
+ {8652/00488652/0048} {AI95-00151-01AI95-00151-01} Corrigendum:
+ Corrected the definition of the range of the result of
+ To_Range, since the Ada 95 definition makes no sense.
+
+\1f
+File: aarm2012.info, Node: A.4.3, Next: A.4.4, Prev: A.4.2, Up: A.4
+
+A.4.3 Fixed-Length String Handling
+----------------------------------
+
+1
+The language-defined package Strings.Fixed provides string-handling
+subprograms for fixed-length strings; that is, for values of type
+Standard.String. Several of these subprograms are procedures that
+modify the contents of a String that is passed as an out or an in out
+parameter; each has additional parameters to control the effect when the
+logical length of the result differs from the parameter's length.
+
+2
+For each function that returns a String, the lower bound of the returned
+value is 1.
+
+2.a/2
+ Discussion: {AI95-00114-01AI95-00114-01} Most operations that
+ yield a String are provided both as a function and as a
+ procedure. The functional form is possibly a more aesthetic
+ style but may introduce overhead due to extra copying or
+ dynamic memory usage in some implementations. Thus a
+ procedural form, with an in out parameter so that all copying
+ is done 'in place', is also supplied.
+
+3
+The basic model embodied in the package is that a fixed-length string
+comprises significant characters and possibly padding (with space
+characters) on either or both ends. When a shorter string is copied to
+a longer string, padding is inserted, and when a longer string is copied
+to a shorter one, padding is stripped. The Move procedure in
+Strings.Fixed, which takes a String as an out parameter, allows the
+programmer to control these effects. Similar control is provided by the
+string transformation procedures.
+
+ _Static Semantics_
+
+4
+The library package Strings.Fixed has the following declaration:
+
+5
+ with Ada.Strings.Maps;
+ package Ada.Strings.Fixed is
+ pragma Preelaborate(Fixed);
+
+6
+ -- "Copy" procedure for strings of possibly different lengths
+
+7
+ procedure Move (Source : in String;
+ Target : out String;
+ Drop : in Truncation := Error;
+ Justify : in Alignment := Left;
+ Pad : in Character := Space);
+
+8
+ -- Search subprograms
+
+8.1/2
+ {AI95-00301-01AI95-00301-01} function Index (Source : in String;
+ Pattern : in String;
+ From : in Positive;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping := Maps.Identity)
+ return Natural;
+
+8.2/2
+ {AI95-00301-01AI95-00301-01} function Index (Source : in String;
+ Pattern : in String;
+ From : in Positive;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping_Function)
+ return Natural;
+
+9
+ function Index (Source : in String;
+ Pattern : in String;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping
+ := Maps.Identity)
+ return Natural;
+
+10
+ function Index (Source : in String;
+ Pattern : in String;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping_Function)
+ return Natural;
+
+10.1/2
+ {AI95-00301-01AI95-00301-01} function Index (Source : in String;
+ Set : in Maps.Character_Set;
+ From : in Positive;
+ Test : in Membership := Inside;
+ Going : in Direction := Forward)
+ return Natural;
+
+11
+ function Index (Source : in String;
+ Set : in Maps.Character_Set;
+ Test : in Membership := Inside;
+ Going : in Direction := Forward)
+ return Natural;
+
+11.1/2
+ {AI95-00301-01AI95-00301-01} function Index_Non_Blank (Source : in String;
+ From : in Positive;
+ Going : in Direction := Forward)
+ return Natural;
+
+12
+ function Index_Non_Blank (Source : in String;
+ Going : in Direction := Forward)
+ return Natural;
+
+13
+ function Count (Source : in String;
+ Pattern : in String;
+ Mapping : in Maps.Character_Mapping
+ := Maps.Identity)
+ return Natural;
+
+14
+ function Count (Source : in String;
+ Pattern : in String;
+ Mapping : in Maps.Character_Mapping_Function)
+ return Natural;
+
+15
+ function Count (Source : in String;
+ Set : in Maps.Character_Set)
+ return Natural;
+
+15.1/3
+ {AI05-0031-1AI05-0031-1} procedure Find_Token (Source : in String;
+ Set : in Maps.Character_Set;
+ From : in Positive;
+ Test : in Membership;
+ First : out Positive;
+ Last : out Natural);
+
+16
+ procedure Find_Token (Source : in String;
+ Set : in Maps.Character_Set;
+ Test : in Membership;
+ First : out Positive;
+ Last : out Natural);
+
+17
+ -- String translation subprograms
+
+18
+ function Translate (Source : in String;
+ Mapping : in Maps.Character_Mapping)
+ return String;
+
+19
+ procedure Translate (Source : in out String;
+ Mapping : in Maps.Character_Mapping);
+
+20
+ function Translate (Source : in String;
+ Mapping : in Maps.Character_Mapping_Function)
+ return String;
+
+21
+ procedure Translate (Source : in out String;
+ Mapping : in Maps.Character_Mapping_Function);
+
+22
+ -- String transformation subprograms
+
+23
+ function Replace_Slice (Source : in String;
+ Low : in Positive;
+ High : in Natural;
+ By : in String)
+ return String;
+
+24
+ procedure Replace_Slice (Source : in out String;
+ Low : in Positive;
+ High : in Natural;
+ By : in String;
+ Drop : in Truncation := Error;
+ Justify : in Alignment := Left;
+ Pad : in Character := Space);
+
+25
+ function Insert (Source : in String;
+ Before : in Positive;
+ New_Item : in String)
+ return String;
+
+26
+ procedure Insert (Source : in out String;
+ Before : in Positive;
+ New_Item : in String;
+ Drop : in Truncation := Error);
+
+27
+ function Overwrite (Source : in String;
+ Position : in Positive;
+ New_Item : in String)
+ return String;
+
+28
+ procedure Overwrite (Source : in out String;
+ Position : in Positive;
+ New_Item : in String;
+ Drop : in Truncation := Right);
+
+29
+ function Delete (Source : in String;
+ From : in Positive;
+ Through : in Natural)
+ return String;
+
+30
+ procedure Delete (Source : in out String;
+ From : in Positive;
+ Through : in Natural;
+ Justify : in Alignment := Left;
+ Pad : in Character := Space);
+
+31
+ --String selector subprograms
+ function Trim (Source : in String;
+ Side : in Trim_End)
+ return String;
+
+32
+ procedure Trim (Source : in out String;
+ Side : in Trim_End;
+ Justify : in Alignment := Left;
+ Pad : in Character := Space);
+
+33
+ function Trim (Source : in String;
+ Left : in Maps.Character_Set;
+ Right : in Maps.Character_Set)
+ return String;
+
+34
+ procedure Trim (Source : in out String;
+ Left : in Maps.Character_Set;
+ Right : in Maps.Character_Set;
+ Justify : in Alignment := Strings.Left;
+ Pad : in Character := Space);
+
+35
+ function Head (Source : in String;
+ Count : in Natural;
+ Pad : in Character := Space)
+ return String;
+
+36
+ procedure Head (Source : in out String;
+ Count : in Natural;
+ Justify : in Alignment := Left;
+ Pad : in Character := Space);
+
+37
+ function Tail (Source : in String;
+ Count : in Natural;
+ Pad : in Character := Space)
+ return String;
+
+38
+ procedure Tail (Source : in out String;
+ Count : in Natural;
+ Justify : in Alignment := Left;
+ Pad : in Character := Space);
+
+39
+ --String constructor functions
+
+40
+ function "*" (Left : in Natural;
+ Right : in Character) return String;
+
+41
+ function "*" (Left : in Natural;
+ Right : in String) return String;
+
+42
+ end Ada.Strings.Fixed;
+
+43
+The effects of the above subprograms are as follows.
+
+44
+ procedure Move (Source : in String;
+ Target : out String;
+ Drop : in Truncation := Error;
+ Justify : in Alignment := Left;
+ Pad : in Character := Space);
+
+45/3
+ {AI05-0264-1AI05-0264-1} The Move procedure copies characters
+ from Source to Target. If Source has the same length as
+ Target, then the effect is to assign Source to Target. If
+ Source is shorter than Target, then:
+
+46
+ * If Justify=Left, then Source is copied into the first
+ Source'Length characters of Target.
+
+47
+ * If Justify=Right, then Source is copied into the last
+ Source'Length characters of Target.
+
+48
+ * If Justify=Center, then Source is copied into the middle
+ Source'Length characters of Target. In this case, if the
+ difference in length between Target and Source is odd,
+ then the extra Pad character is on the right.
+
+49
+ * Pad is copied to each Target character not otherwise
+ assigned.
+
+50
+ If Source is longer than Target, then the effect is based on
+ Drop.
+
+51
+ * If Drop=Left, then the rightmost Target'Length characters
+ of Source are copied into Target.
+
+52
+ * If Drop=Right, then the leftmost Target'Length characters
+ of Source are copied into Target.
+
+53
+ * If Drop=Error, then the effect depends on the value of
+ the Justify parameter and also on whether any characters
+ in Source other than Pad would fail to be copied:
+
+54
+ * If Justify=Left, and if each of the rightmost
+ Source'Length-Target'Length characters in
+ Source is Pad, then the leftmost Target'Length
+ characters of Source are copied to Target.
+
+55
+ * If Justify=Right, and if each of the leftmost
+ Source'Length-Target'Length characters in
+ Source is Pad, then the rightmost Target'Length
+ characters of Source are copied to Target.
+
+56
+ * Otherwise, Length_Error is propagated.
+
+56.a
+ Ramification: The Move procedure will work even if Source and
+ Target overlap.
+
+56.b
+ Reason: The order of parameters (Source before Target)
+ corresponds to the order in COBOL's MOVE verb.
+
+56.1/2
+ function Index (Source : in String;
+ Pattern : in String;
+ From : in Positive;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping := Maps.Identity)
+ return Natural;
+
+ function Index (Source : in String;
+ Pattern : in String;
+ From : in Positive;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping_Function)
+ return Natural;
+
+56.2/3
+ {AI95-00301-01AI95-00301-01} {AI05-0056-1AI05-0056-1} Each
+ Index function searches, starting from From, for a slice of
+ Source, with length Pattern'Length, that matches Pattern with
+ respect to Mapping; the parameter Going indicates the
+ direction of the lookup. If Source is the null string, Index
+ returns 0; otherwise, if From is not in Source'Range, then
+ Index_Error is propagated. If Going = Forward, then Index
+ returns the smallest index I which is greater than or equal to
+ From such that the slice of Source starting at I matches
+ Pattern. If Going = Backward, then Index returns the largest
+ index I such that the slice of Source starting at I matches
+ Pattern and has an upper bound less than or equal to From. If
+ there is no such slice, then 0 is returned. If Pattern is the
+ null string, then Pattern_Error is propagated.
+
+56.c/2
+ Discussion: There is no default parameter for From; the
+ default value would need to depend on other parameters (the
+ bounds of Source and the direction Going). It is better to
+ use overloaded functions rather than a special value to
+ represent the default.
+
+56.d/2
+ There is no default value for the Mapping parameter that is a
+ Character_Mapping_Function; if there were, a call would be
+ ambiguous since there is also a default for the Mapping
+ parameter that is a Character_Mapping.
+
+56.e/3
+ {AI05-0056-1AI05-0056-1} The language does not define when the
+ Pattern_Error check is made. (That's because many common
+ searching implementations require a nonempty pattern) That
+ means that the result for a call like Index ("", "") could be
+ 0 or could raise Pattern_Error. Similarly, in the call Index
+ ("", "", From => 2), the language does not define whether
+ Pattern_Error or Index_Error is raised.
+
+57
+ function Index (Source : in String;
+ Pattern : in String;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping
+ := Maps.Identity)
+ return Natural;
+
+ function Index (Source : in String;
+ Pattern : in String;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping_Function)
+ return Natural;
+
+58/2
+ {AI95-00301-01AI95-00301-01} If Going = Forward, returns
+
+58.1/2
+ Index (Source, Pattern, Source'First, Forward, Mapping);
+
+58.2/3
+ {AI05-0264-1AI05-0264-1} otherwise, returns
+
+58.3/2
+ Index (Source, Pattern, Source'Last, Backward, Mapping);
+
+58.a/2
+ This paragraph was deleted.There is no default value for the
+ Mapping parameter that is a Character_Mapping_Function; if
+ there were, a call would be ambiguous since there is also a
+ default for the Mapping parameter that is a Character_Mapping.
+
+58.4/2
+ function Index (Source : in String;
+ Set : in Maps.Character_Set;
+ From : in Positive;
+ Test : in Membership := Inside;
+ Going : in Direction := Forward)
+ return Natural;
+
+58.5/3
+ {AI95-00301-01AI95-00301-01} {AI05-0056-1AI05-0056-1} Index
+ searches for the first or last occurrence of any of a set of
+ characters (when Test=Inside), or any of the complement of a
+ set of characters (when Test=Outside). If Source is the null
+ string, Index returns 0; otherwise, if From is not in
+ Source'Range, then Index_Error is propagated. Otherwise, it
+ returns the smallest index I >= From (if Going=Forward) or the
+ largest index I <= From (if Going=Backward) such that
+ Source(I) satisfies the Test condition with respect to Set; it
+ returns 0 if there is no such Character in Source.
+
+59
+ function Index (Source : in String;
+ Set : in Maps.Character_Set;
+ Test : in Membership := Inside;
+ Going : in Direction := Forward)
+ return Natural;
+
+60/2
+ {AI95-00301-01AI95-00301-01} If Going = Forward, returns
+
+60.1/2
+ Index (Source, Set, Source'First, Test, Forward);
+
+60.2/3
+ {AI05-0264-1AI05-0264-1} otherwise, returns
+
+60.3/2
+ Index (Source, Set, Source'Last, Test, Backward);
+
+60.4/2
+ function Index_Non_Blank (Source : in String;
+ From : in Positive;
+ Going : in Direction := Forward)
+ return Natural;
+
+60.5/2
+ {AI95-00301-01AI95-00301-01} Returns Index (Source,
+ Maps.To_Set(Space), From, Outside, Going);
+
+61
+ function Index_Non_Blank (Source : in String;
+ Going : in Direction := Forward)
+ return Natural;
+
+62
+ Returns Index(Source, Maps.To_Set(Space), Outside, Going)
+
+63
+ function Count (Source : in String;
+ Pattern : in String;
+ Mapping : in Maps.Character_Mapping
+ := Maps.Identity)
+ return Natural;
+
+ function Count (Source : in String;
+ Pattern : in String;
+ Mapping : in Maps.Character_Mapping_Function)
+ return Natural;
+
+64
+ Returns the maximum number of nonoverlapping slices of Source
+ that match Pattern with respect to Mapping. If Pattern is the
+ null string then Pattern_Error is propagated.
+
+64.a
+ Reason: We say 'maximum number' because it is possible to
+ slice a source string in different ways yielding different
+ numbers of matches. For example if Source is "ABABABA" and
+ Pattern is "ABA", then Count yields 2, although there is a
+ partitioning of Source that yields just 1 match, for the
+ middle slice. Saying 'maximum number' is equivalent to saying
+ that the pattern match starts either at the low index or the
+ high index position.
+
+65
+ function Count (Source : in String;
+ Set : in Maps.Character_Set)
+ return Natural;
+
+66
+ Returns the number of occurrences in Source of characters that
+ are in Set.
+
+66.1/3
+ procedure Find_Token (Source : in String;
+ Set : in Maps.Character_Set;
+ From : in Positive;
+ Test : in Membership;
+ First : out Positive;
+ Last : out Natural);
+
+66.2/3
+ {AI05-0031-1AI05-0031-1} If Source is not the null string and
+ From is not in Source'Range, then Index_Error is raised.
+ Otherwise, First is set to the index of the first character in
+ Source(From .. Source'Last) that satisfies the Test
+ condition. Last is set to the largest index such that all
+ characters in Source(First .. Last) satisfy the Test
+ condition. If no characters in Source(From .. Source'Last)
+ satisfy the Test condition, First is set to From, and Last is
+ set to 0.
+
+67
+ procedure Find_Token (Source : in String;
+ Set : in Maps.Character_Set;
+ Test : in Membership;
+ First : out Positive;
+ Last : out Natural);
+
+68/3
+ {8652/00498652/0049} {AI95-00128-01AI95-00128-01}
+ {AI05-0031-1AI05-0031-1} Equivalent to Find_Token (Source,
+ Set, Source'First, Test, First, Last).
+
+68.a/3
+ Ramification: {AI05-0031-1AI05-0031-1} If Source'First is not
+ in Positive, which can only happen for an empty string, this
+ will raise Constraint_Error.
+
+69
+ function Translate (Source : in String;
+ Mapping : in Maps.Character_Mapping)
+ return String;
+
+ function Translate (Source : in String;
+ Mapping : in Maps.Character_Mapping_Function)
+ return String;
+
+70
+ Returns the string S whose length is Source'Length and such
+ that S(I) is the character to which Mapping maps the
+ corresponding element of Source, for I in 1..Source'Length.
+
+71
+ procedure Translate (Source : in out String;
+ Mapping : in Maps.Character_Mapping);
+
+ procedure Translate (Source : in out String;
+ Mapping : in Maps.Character_Mapping_Function);
+
+72
+ Equivalent to Source := Translate(Source, Mapping).
+
+73
+ function Replace_Slice (Source : in String;
+ Low : in Positive;
+ High : in Natural;
+ By : in String)
+ return String;
+
+74/1
+ {8652/00498652/0049} {AI95-00128-01AI95-00128-01} If Low >
+ Source'Last+1, or High < Source'First-1, then Index_Error is
+ propagated. Otherwise:
+
+74.1/1
+ * {8652/00498652/0049} {AI95-00128-01AI95-00128-01} If High
+ >= Low, then the returned string comprises
+ Source(Source'First..Low-1) & By &
+ Source(High+1..Source'Last), but with lower bound 1.
+
+74.2/1
+ * {8652/00498652/0049} {AI95-00128-01AI95-00128-01} If High
+ < Low, then the returned string is Insert(Source,
+ Before=>Low, New_Item=>By).
+
+75
+ procedure Replace_Slice (Source : in out String;
+ Low : in Positive;
+ High : in Natural;
+ By : in String;
+ Drop : in Truncation := Error;
+ Justify : in Alignment := Left;
+ Pad : in Character := Space);
+
+76
+ Equivalent to Move(Replace_Slice(Source, Low, High, By),
+ Source, Drop, Justify, Pad).
+
+77
+ function Insert (Source : in String;
+ Before : in Positive;
+ New_Item : in String)
+ return String;
+
+78/3
+ {AI05-0264-1AI05-0264-1} Propagates Index_Error if Before is
+ not in Source'First .. Source'Last+1; otherwise, returns
+ Source(Source'First..Before-1) & New_Item &
+ Source(Before..Source'Last), but with lower bound 1.
+
+79
+ procedure Insert (Source : in out String;
+ Before : in Positive;
+ New_Item : in String;
+ Drop : in Truncation := Error);
+
+80
+ Equivalent to Move(Insert(Source, Before, New_Item), Source,
+ Drop).
+
+81
+ function Overwrite (Source : in String;
+ Position : in Positive;
+ New_Item : in String)
+ return String;
+
+82/3
+ {AI05-0264-1AI05-0264-1} Propagates Index_Error if Position is
+ not in Source'First .. Source'Last+1; otherwise, returns the
+ string obtained from Source by consecutively replacing
+ characters starting at Position with corresponding characters
+ from New_Item. If the end of Source is reached before the
+ characters in New_Item are exhausted, the remaining characters
+ from New_Item are appended to the string.
+
+83
+ procedure Overwrite (Source : in out String;
+ Position : in Positive;
+ New_Item : in String;
+ Drop : in Truncation := Right);
+
+84
+ Equivalent to Move(Overwrite(Source, Position, New_Item),
+ Source, Drop).
+
+85
+ function Delete (Source : in String;
+ From : in Positive;
+ Through : in Natural)
+ return String;
+
+86/3
+ {8652/00498652/0049} {AI95-00128-01AI95-00128-01}
+ {AI05-0264-1AI05-0264-1} If From <= Through, the returned
+ string is Replace_Slice(Source, From, Through, ""); otherwise,
+ it is Source with lower bound 1.
+
+87
+ procedure Delete (Source : in out String;
+ From : in Positive;
+ Through : in Natural;
+ Justify : in Alignment := Left;
+ Pad : in Character := Space);
+
+88
+ Equivalent to Move(Delete(Source, From, Through), Source,
+ Justify => Justify, Pad => Pad).
+
+89
+ function Trim (Source : in String;
+ Side : in Trim_End)
+ return String;
+
+90
+ Returns the string obtained by removing from Source all
+ leading Space characters (if Side = Left), all trailing Space
+ characters (if Side = Right), or all leading and trailing
+ Space characters (if Side = Both).
+
+91
+ procedure Trim (Source : in out String;
+ Side : in Trim_End;
+ Justify : in Alignment := Left;
+ Pad : in Character := Space);
+
+92
+ Equivalent to Move(Trim(Source, Side), Source,
+ Justify=>Justify, Pad=>Pad).
+
+93
+ function Trim (Source : in String;
+ Left : in Maps.Character_Set;
+ Right : in Maps.Character_Set)
+ return String;
+
+94
+ Returns the string obtained by removing from Source all
+ leading characters in Left and all trailing characters in
+ Right.
+
+95
+ procedure Trim (Source : in out String;
+ Left : in Maps.Character_Set;
+ Right : in Maps.Character_Set;
+ Justify : in Alignment := Strings.Left;
+ Pad : in Character := Space);
+
+96
+ Equivalent to Move(Trim(Source, Left, Right), Source, Justify
+ => Justify, Pad=>Pad).
+
+97
+ function Head (Source : in String;
+ Count : in Natural;
+ Pad : in Character := Space)
+ return String;
+
+98/3
+ {AI05-0264-1AI05-0264-1} Returns a string of length Count. If
+ Count <= Source'Length, the string comprises the first Count
+ characters of Source. Otherwise, its contents are Source
+ concatenated with Count-Source'Length Pad characters.
+
+99
+ procedure Head (Source : in out String;
+ Count : in Natural;
+ Justify : in Alignment := Left;
+ Pad : in Character := Space);
+
+100
+ Equivalent to Move(Head(Source, Count, Pad), Source,
+ Drop=>Error, Justify=>Justify, Pad=>Pad).
+
+101
+ function Tail (Source : in String;
+ Count : in Natural;
+ Pad : in Character := Space)
+ return String;
+
+102/3
+ {AI05-0264-1AI05-0264-1} Returns a string of length Count. If
+ Count <= Source'Length, the string comprises the last Count
+ characters of Source. Otherwise, its contents are
+ Count-Source'Length Pad characters concatenated with Source.
+
+103
+ procedure Tail (Source : in out String;
+ Count : in Natural;
+ Justify : in Alignment := Left;
+ Pad : in Character := Space);
+
+104
+ Equivalent to Move(Tail(Source, Count, Pad), Source,
+ Drop=>Error, Justify=>Justify, Pad=>Pad).
+
+105
+ function "*" (Left : in Natural;
+ Right : in Character) return String;
+
+ function "*" (Left : in Natural;
+ Right : in String) return String;
+
+106/1
+ {8652/00498652/0049} {AI95-00128-01AI95-00128-01} These
+ functions replicate a character or string a specified number
+ of times. The first function returns a string whose length is
+ Left and each of whose elements is Right. The second function
+ returns a string whose length is Left*Right'Length and whose
+ value is the null string if Left = 0 and otherwise is
+ (Left-1)*Right & Right with lower bound 1.
+
+ NOTES
+
+107/3
+ 12 {AI05-0264-1AI05-0264-1} In the Index and Count functions
+ taking Pattern and Mapping parameters, the actual String parameter
+ passed to Pattern should comprise characters occurring as target
+ characters of the mapping. Otherwise, the pattern will not match.
+
+108
+ 13 In the Insert subprograms, inserting at the end of a string is
+ obtained by passing Source'Last+1 as the Before parameter.
+
+109
+ 14 If a null Character_Mapping_Function is passed to any of the
+ string handling subprograms, Constraint_Error is propagated.
+
+ _Incompatibilities With Ada 95_
+
+109.a/3
+ {AI95-00301-01AI95-00301-01} {AI05-0005-1AI05-0005-1}
+ Overloaded versions of Index and Index_Non_Blank are added to
+ Strings.Fixed. If Strings.Fixed is referenced in a
+ use_clause, and an entity E with a defining_identifier of
+ Index or Index_Non_Blank is defined in a package that is also
+ referenced in a use_clause, the entity E may no longer be
+ use-visible, resulting in errors. This should be rare and is
+ easily fixed if it does occur.
+
+ _Wording Changes from Ada 95_
+
+109.b/2
+ {8652/00498652/0049} {AI95-00128-01AI95-00128-01} Corrigendum:
+ Clarified that Find_Token may raise Constraint_Error if
+ Source'First is not in Positive (which is only possible for a
+ null string).
+
+109.c/2
+ {8652/00498652/0049} {AI95-00128-01AI95-00128-01} Corrigendum:
+ Clarified that Replace_Slice, Delete, and "*" always return a
+ string with lower bound 1.
+
+ _Incompatibilities With Ada 2005_
+
+109.d/3
+ {AI05-0031-1AI05-0031-1} An overloaded version of Find_Token
+ is added to Strings.Fixed. If Strings.Fixed is referenced in
+ a use_clause, and an entity E with a defining_identifier of
+ Find_Token is defined in a package that is also referenced in
+ a use_clause, the entity E may no longer be use-visible,
+ resulting in errors. This should be rare and is easily fixed
+ if it does occur.
+
+ _Wording Changes from Ada 2005_
+
+109.e/3
+ {AI05-0056-1AI05-0056-1} Correction: Clarified that Index
+ never raises Index_Error if the source string is null.
+
+\1f
+File: aarm2012.info, Node: A.4.4, Next: A.4.5, Prev: A.4.3, Up: A.4
+
+A.4.4 Bounded-Length String Handling
+------------------------------------
+
+1
+The language-defined package Strings.Bounded provides a generic package
+each of whose instances yields a private type Bounded_String and a set
+of operations. An object of a particular Bounded_String type represents
+a String whose low bound is 1 and whose length can vary conceptually
+between 0 and a maximum size established at the generic instantiation.
+The subprograms for fixed-length string handling are either overloaded
+directly for Bounded_String, or are modified as needed to reflect the
+variability in length. Additionally, since the Bounded_String type is
+private, appropriate constructor and selector operations are provided.
+
+1.a
+ Reason: Strings.Bounded declares an inner generic package,
+ versus itself being directly a generic child of Strings, in
+ order to retain compatibility with a version of the
+ string-handling packages that is generic with respect to the
+ character and string types.
+
+1.b
+ Reason: The bound of a bounded-length string is specified as a
+ parameter to a generic, versus as the value for a
+ discriminant, because of the inappropriateness of assignment
+ and equality of discriminated types for the copying and
+ comparison of bounded strings.
+
+ _Static Semantics_
+
+2
+The library package Strings.Bounded has the following declaration:
+
+3
+ with Ada.Strings.Maps;
+ package Ada.Strings.Bounded is
+ pragma Preelaborate(Bounded);
+
+4
+ generic
+ Max : Positive; -- Maximum length of a Bounded_String
+ package Generic_Bounded_Length is
+
+5
+ Max_Length : constant Positive := Max;
+
+6
+ type Bounded_String is private;
+
+7
+ Null_Bounded_String : constant Bounded_String;
+
+8
+ subtype Length_Range is Natural range 0 .. Max_Length;
+
+9
+ function Length (Source : in Bounded_String) return Length_Range;
+
+10
+ -- Conversion, Concatenation, and Selection functions
+
+11
+ function To_Bounded_String (Source : in String;
+ Drop : in Truncation := Error)
+ return Bounded_String;
+
+12
+ function To_String (Source : in Bounded_String) return String;
+
+12.1/2
+ {AI95-00301-01AI95-00301-01} procedure Set_Bounded_String
+ (Target : out Bounded_String;
+ Source : in String;
+ Drop : in Truncation := Error);
+
+13
+ function Append (Left, Right : in Bounded_String;
+ Drop : in Truncation := Error)
+ return Bounded_String;
+
+14
+ function Append (Left : in Bounded_String;
+ Right : in String;
+ Drop : in Truncation := Error)
+ return Bounded_String;
+
+15
+ function Append (Left : in String;
+ Right : in Bounded_String;
+ Drop : in Truncation := Error)
+ return Bounded_String;
+
+16
+ function Append (Left : in Bounded_String;
+ Right : in Character;
+ Drop : in Truncation := Error)
+ return Bounded_String;
+
+17
+ function Append (Left : in Character;
+ Right : in Bounded_String;
+ Drop : in Truncation := Error)
+ return Bounded_String;
+
+18
+ procedure Append (Source : in out Bounded_String;
+ New_Item : in Bounded_String;
+ Drop : in Truncation := Error);
+
+19
+ procedure Append (Source : in out Bounded_String;
+ New_Item : in String;
+ Drop : in Truncation := Error);
+
+20
+ procedure Append (Source : in out Bounded_String;
+ New_Item : in Character;
+ Drop : in Truncation := Error);
+
+21
+ function "&" (Left, Right : in Bounded_String)
+ return Bounded_String;
+
+22
+ function "&" (Left : in Bounded_String; Right : in String)
+ return Bounded_String;
+
+23
+ function "&" (Left : in String; Right : in Bounded_String)
+ return Bounded_String;
+
+24
+ function "&" (Left : in Bounded_String; Right : in Character)
+ return Bounded_String;
+
+25
+ function "&" (Left : in Character; Right : in Bounded_String)
+ return Bounded_String;
+
+26
+ function Element (Source : in Bounded_String;
+ Index : in Positive)
+ return Character;
+
+27
+ procedure Replace_Element (Source : in out Bounded_String;
+ Index : in Positive;
+ By : in Character);
+
+28
+ function Slice (Source : in Bounded_String;
+ Low : in Positive;
+ High : in Natural)
+ return String;
+
+28.1/2
+ {AI95-00301-01AI95-00301-01} function Bounded_Slice
+ (Source : in Bounded_String;
+ Low : in Positive;
+ High : in Natural)
+ return Bounded_String;
+
+28.2/2
+ {AI95-00301-01AI95-00301-01} procedure Bounded_Slice
+ (Source : in Bounded_String;
+ Target : out Bounded_String;
+ Low : in Positive;
+ High : in Natural);
+
+29
+ function "=" (Left, Right : in Bounded_String) return Boolean;
+ function "=" (Left : in Bounded_String; Right : in String)
+ return Boolean;
+
+30
+ function "=" (Left : in String; Right : in Bounded_String)
+ return Boolean;
+
+31
+ function "<" (Left, Right : in Bounded_String) return Boolean;
+
+32
+ function "<" (Left : in Bounded_String; Right : in String)
+ return Boolean;
+
+33
+ function "<" (Left : in String; Right : in Bounded_String)
+ return Boolean;
+
+34
+ function "<=" (Left, Right : in Bounded_String) return Boolean;
+
+35
+ function "<=" (Left : in Bounded_String; Right : in String)
+ return Boolean;
+
+36
+ function "<=" (Left : in String; Right : in Bounded_String)
+ return Boolean;
+
+37
+ function ">" (Left, Right : in Bounded_String) return Boolean;
+
+38
+ function ">" (Left : in Bounded_String; Right : in String)
+ return Boolean;
+
+39
+ function ">" (Left : in String; Right : in Bounded_String)
+ return Boolean;
+
+40
+ function ">=" (Left, Right : in Bounded_String) return Boolean;
+
+41
+ function ">=" (Left : in Bounded_String; Right : in String)
+ return Boolean;
+
+42
+ function ">=" (Left : in String; Right : in Bounded_String)
+ return Boolean;
+
+43/2
+ {AI95-00301-01AI95-00301-01} -- Search subprograms
+
+43.1/2
+ {AI95-00301-01AI95-00301-01} function Index (Source : in Bounded_String;
+ Pattern : in String;
+ From : in Positive;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping := Maps.Identity)
+ return Natural;
+
+43.2/2
+ {AI95-00301-01AI95-00301-01} function Index (Source : in Bounded_String;
+ Pattern : in String;
+ From : in Positive;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping_Function)
+ return Natural;
+
+44
+ function Index (Source : in Bounded_String;
+ Pattern : in String;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping
+ := Maps.Identity)
+ return Natural;
+
+45
+ function Index (Source : in Bounded_String;
+ Pattern : in String;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping_Function)
+ return Natural;
+
+45.1/2
+ {AI95-00301-01AI95-00301-01} function Index (Source : in Bounded_String;
+ Set : in Maps.Character_Set;
+ From : in Positive;
+ Test : in Membership := Inside;
+ Going : in Direction := Forward)
+ return Natural;
+
+46
+ function Index (Source : in Bounded_String;
+ Set : in Maps.Character_Set;
+ Test : in Membership := Inside;
+ Going : in Direction := Forward)
+ return Natural;
+
+46.1/2
+ {AI95-00301-01AI95-00301-01} function Index_Non_Blank (Source : in Bounded_String;
+ From : in Positive;
+ Going : in Direction := Forward)
+ return Natural;
+
+47
+ function Index_Non_Blank (Source : in Bounded_String;
+ Going : in Direction := Forward)
+ return Natural;
+
+48
+ function Count (Source : in Bounded_String;
+ Pattern : in String;
+ Mapping : in Maps.Character_Mapping
+ := Maps.Identity)
+ return Natural;
+
+49
+ function Count (Source : in Bounded_String;
+ Pattern : in String;
+ Mapping : in Maps.Character_Mapping_Function)
+ return Natural;
+
+50
+ function Count (Source : in Bounded_String;
+ Set : in Maps.Character_Set)
+ return Natural;
+
+50.1/3
+ {AI05-0031-1AI05-0031-1} procedure Find_Token (Source : in Bounded_String;
+ Set : in Maps.Character_Set;
+ From : in Positive;
+ Test : in Membership;
+ First : out Positive;
+ Last : out Natural);
+
+51
+ procedure Find_Token (Source : in Bounded_String;
+ Set : in Maps.Character_Set;
+ Test : in Membership;
+ First : out Positive;
+ Last : out Natural);
+
+52
+ -- String translation subprograms
+
+53
+ function Translate (Source : in Bounded_String;
+ Mapping : in Maps.Character_Mapping)
+ return Bounded_String;
+
+54
+ procedure Translate (Source : in out Bounded_String;
+ Mapping : in Maps.Character_Mapping);
+
+55
+ function Translate (Source : in Bounded_String;
+ Mapping : in Maps.Character_Mapping_Function)
+ return Bounded_String;
+
+56
+ procedure Translate (Source : in out Bounded_String;
+ Mapping : in Maps.Character_Mapping_Function);
+
+57
+ -- String transformation subprograms
+
+58
+ function Replace_Slice (Source : in Bounded_String;
+ Low : in Positive;
+ High : in Natural;
+ By : in String;
+ Drop : in Truncation := Error)
+ return Bounded_String;
+
+59
+ procedure Replace_Slice (Source : in out Bounded_String;
+ Low : in Positive;
+ High : in Natural;
+ By : in String;
+ Drop : in Truncation := Error);
+
+60
+ function Insert (Source : in Bounded_String;
+ Before : in Positive;
+ New_Item : in String;
+ Drop : in Truncation := Error)
+ return Bounded_String;
+
+61
+ procedure Insert (Source : in out Bounded_String;
+ Before : in Positive;
+ New_Item : in String;
+ Drop : in Truncation := Error);
+
+62
+ function Overwrite (Source : in Bounded_String;
+ Position : in Positive;
+ New_Item : in String;
+ Drop : in Truncation := Error)
+ return Bounded_String;
+
+63
+ procedure Overwrite (Source : in out Bounded_String;
+ Position : in Positive;
+ New_Item : in String;
+ Drop : in Truncation := Error);
+
+64
+ function Delete (Source : in Bounded_String;
+ From : in Positive;
+ Through : in Natural)
+ return Bounded_String;
+
+65
+ procedure Delete (Source : in out Bounded_String;
+ From : in Positive;
+ Through : in Natural);
+
+66
+ --String selector subprograms
+
+67
+ function Trim (Source : in Bounded_String;
+ Side : in Trim_End)
+ return Bounded_String;
+ procedure Trim (Source : in out Bounded_String;
+ Side : in Trim_End);
+
+68
+ function Trim (Source : in Bounded_String;
+ Left : in Maps.Character_Set;
+ Right : in Maps.Character_Set)
+ return Bounded_String;
+
+69
+ procedure Trim (Source : in out Bounded_String;
+ Left : in Maps.Character_Set;
+ Right : in Maps.Character_Set);
+
+70
+ function Head (Source : in Bounded_String;
+ Count : in Natural;
+ Pad : in Character := Space;
+ Drop : in Truncation := Error)
+ return Bounded_String;
+
+71
+ procedure Head (Source : in out Bounded_String;
+ Count : in Natural;
+ Pad : in Character := Space;
+ Drop : in Truncation := Error);
+
+72
+ function Tail (Source : in Bounded_String;
+ Count : in Natural;
+ Pad : in Character := Space;
+ Drop : in Truncation := Error)
+ return Bounded_String;
+
+73
+ procedure Tail (Source : in out Bounded_String;
+ Count : in Natural;
+ Pad : in Character := Space;
+ Drop : in Truncation := Error);
+
+74
+ --String constructor subprograms
+
+75
+ function "*" (Left : in Natural;
+ Right : in Character)
+ return Bounded_String;
+
+76
+ function "*" (Left : in Natural;
+ Right : in String)
+ return Bounded_String;
+
+77
+ function "*" (Left : in Natural;
+ Right : in Bounded_String)
+ return Bounded_String;
+
+78
+ function Replicate (Count : in Natural;
+ Item : in Character;
+ Drop : in Truncation := Error)
+ return Bounded_String;
+
+79
+ function Replicate (Count : in Natural;
+ Item : in String;
+ Drop : in Truncation := Error)
+ return Bounded_String;
+
+80
+ function Replicate (Count : in Natural;
+ Item : in Bounded_String;
+ Drop : in Truncation := Error)
+ return Bounded_String;
+
+81
+ private
+ ... -- not specified by the language
+ end Generic_Bounded_Length;
+
+82
+ end Ada.Strings.Bounded;
+
+82.a.1/2
+ This paragraph was deleted.{8652/00978652/0097}
+ {AI95-00115-01AI95-00115-01} {AI95-00344-01AI95-00344-01}
+
+83
+Null_Bounded_String represents the null string. If an object of type
+Bounded_String is not otherwise initialized, it will be initialized to
+the same value as Null_Bounded_String.
+
+84
+ function Length (Source : in Bounded_String) return Length_Range;
+
+85
+ The Length function returns the length of the string
+ represented by Source.
+
+86
+ function To_Bounded_String (Source : in String;
+ Drop : in Truncation := Error)
+ return Bounded_String;
+
+87/3
+ {AI05-0264-1AI05-0264-1} If Source'Length <= Max_Length, then
+ this function returns a Bounded_String that represents Source.
+ Otherwise, the effect depends on the value of Drop:
+
+88
+ * If Drop=Left, then the result is a Bounded_String that
+ represents the string comprising the rightmost Max_Length
+ characters of Source.
+
+89
+ * If Drop=Right, then the result is a Bounded_String that
+ represents the string comprising the leftmost Max_Length
+ characters of Source.
+
+90
+ * If Drop=Error, then Strings.Length_Error is propagated.
+
+91
+ function To_String (Source : in Bounded_String) return String;
+
+92
+ To_String returns the String value with lower bound 1
+ represented by Source. If B is a Bounded_String, then B =
+ To_Bounded_String(To_String(B)).
+
+92.1/2
+ procedure Set_Bounded_String
+ (Target : out Bounded_String;
+ Source : in String;
+ Drop : in Truncation := Error);
+
+92.2/2
+ {AI95-00301-01AI95-00301-01} Equivalent to Target :=
+ To_Bounded_String (Source, Drop);
+
+93
+Each of the Append functions returns a Bounded_String obtained by
+concatenating the string or character given or represented by one of the
+parameters, with the string or character given or represented by the
+other parameter, and applying To_Bounded_String to the concatenation
+result string, with Drop as provided to the Append function.
+
+94
+Each of the procedures Append(Source, New_Item, Drop) has the same
+effect as the corresponding assignment Source := Append(Source,
+New_Item, Drop).
+
+95
+Each of the "&" functions has the same effect as the corresponding
+Append function, with Error as the Drop parameter.
+
+96
+ function Element (Source : in Bounded_String;
+ Index : in Positive)
+ return Character;
+
+97
+ Returns the character at position Index in the string
+ represented by Source; propagates Index_Error if Index >
+ Length(Source).
+
+98
+ procedure Replace_Element (Source : in out Bounded_String;
+ Index : in Positive;
+ By : in Character);
+
+99
+ Updates Source such that the character at position Index in
+ the string represented by Source is By; propagates Index_Error
+ if Index > Length(Source).
+
+100
+ function Slice (Source : in Bounded_String;
+ Low : in Positive;
+ High : in Natural)
+ return String;
+
+101/1
+ {8652/00498652/0049} {AI95-00128-01AI95-00128-01}
+ {AI95-00238-01AI95-00238-01} Returns the slice at positions
+ Low through High in the string represented by Source;
+ propagates Index_Error if Low > Length(Source)+1 or High >
+ Length(Source). The bounds of the returned string are Low and
+ High..
+
+101.1/2
+ function Bounded_Slice
+ (Source : in Bounded_String;
+ Low : in Positive;
+ High : in Natural)
+ return Bounded_String;
+
+101.2/2
+ {AI95-00301-01AI95-00301-01} Returns the slice at positions
+ Low through High in the string represented by Source as a
+ bounded string; propagates Index_Error if Low >
+ Length(Source)+1 or High > Length(Source).
+
+101.3/2
+ procedure Bounded_Slice
+ (Source : in Bounded_String;
+ Target : out Bounded_String;
+ Low : in Positive;
+ High : in Natural);
+
+101.4/2
+ {AI95-00301-01AI95-00301-01} Equivalent to Target :=
+ Bounded_Slice (Source, Low, High);
+
+102
+Each of the functions "=", "<", ">", "<=", and ">=" returns the same
+result as the corresponding String operation applied to the String
+values given or represented by the two parameters.
+
+103
+Each of the search subprograms (Index, Index_Non_Blank, Count,
+Find_Token) has the same effect as the corresponding subprogram in
+Strings.Fixed applied to the string represented by the Bounded_String
+parameter.
+
+104
+Each of the Translate subprograms, when applied to a Bounded_String, has
+an analogous effect to the corresponding subprogram in Strings.Fixed.
+For the Translate function, the translation is applied to the string
+represented by the Bounded_String parameter, and the result is converted
+(via To_Bounded_String) to a Bounded_String. For the Translate
+procedure, the string represented by the Bounded_String parameter after
+the translation is given by the Translate function for fixed-length
+strings applied to the string represented by the original value of the
+parameter.
+
+105/1
+{8652/00498652/0049} {AI95-00128-01AI95-00128-01} Each of the
+transformation subprograms (Replace_Slice, Insert, Overwrite, Delete),
+selector subprograms (Trim, Head, Tail), and constructor functions ("*")
+has an effect based on its corresponding subprogram in Strings.Fixed,
+and Replicate is based on Fixed."*". In the case of a function, the
+corresponding fixed-length string subprogram is applied to the string
+represented by the Bounded_String parameter. To_Bounded_String is
+applied the result string, with Drop (or Error in the case of
+Generic_Bounded_Length."*") determining the effect when the string
+length exceeds Max_Length. In the case of a procedure, the
+corresponding function in Strings.Bounded.Generic_Bounded_Length is
+applied, with the result assigned into the Source parameter.
+
+105.a/2
+ Ramification: {AI95-00114-01AI95-00114-01} The "/=" operations
+ between Bounded_String and String, and between String and
+ Bounded_String, are automatically defined based on the
+ corresponding "=" operations.
+
+ _Implementation Advice_
+
+106
+Bounded string objects should not be implemented by implicit pointers
+and dynamic allocation.
+
+106.a.1/2
+ Implementation Advice: Bounded string objects should not be
+ implemented by implicit pointers and dynamic allocation.
+
+106.a
+ Implementation Note: The following is a possible
+ implementation of the private part of the package:
+
+106.b
+ type Bounded_String_Internals (Length : Length_Range := 0) is
+ record
+ Data : String(1..Length);
+ end record;
+
+106.c
+ type Bounded_String is
+ record
+ Data : Bounded_String_Internals; -- Unconstrained
+ end record;
+
+106.d
+ Null_Bounded_String : constant Bounded_String :=
+ (Data => (Length => 0,
+ Data => (1..0 => ' ')));
+
+ _Inconsistencies With Ada 95_
+
+106.e/2
+ {AI95-00238-01AI95-00238-01} Amendment Correction: The bounds
+ of the string returned from Slice are now defined. This is
+ technically an inconsistency; if a program depended on some
+ other lower bound for the string returned from Slice, it could
+ fail when compiled with Ada 2005. Such code is not portable
+ even between Ada 95 implementations, so it should be very
+ rare.
+
+ _Incompatibilities With Ada 95_
+
+106.f/3
+ {AI95-00301-01AI95-00301-01} {AI05-0005-1AI05-0005-1}
+ Procedure Set_Bounded_String, two Bounded_Slice subprograms,
+ and overloaded versions of Index and Index_Non_Blank are added
+ to Strings.Bounded.Generic_Bounded_Length. If an instance of
+ Generic_Bounded_Length is referenced in a use_clause, and an
+ entity E with the defining_identifier as a new entity in
+ Generic_Bounded_Length is defined in a package that is also
+ referenced in a use_clause, the entity E may no longer be
+ use-visible, resulting in errors. This should be rare and is
+ easily fixed if it does occur.
+
+ _Wording Changes from Ada 95_
+
+106.g/2
+ {8652/00498652/0049} {AI95-00128-01AI95-00128-01} Corrigendum:
+ Corrected the conditions for which Slice raises Index_Error.
+
+106.h/2
+ {8652/00498652/0049} {AI95-00128-01AI95-00128-01} Corrigendum:
+ Clarified the meaning of transformation, selector, and
+ constructor subprograms by describing the effects of
+ procedures and functions separately.
+
+ _Incompatibilities With Ada 2005_
+
+106.i/3
+ {AI05-0031-1AI05-0031-1} An overloaded version of Find_Token
+ is added to Strings.Bounded.Generic_Bounded_Length. If an
+ instance of Generic_Bounded_Length is referenced in a
+ use_clause, and an entity E with a defining_identifier of
+ Find_Token is defined in a package that is also referenced in
+ a use_clause, the entity E may no longer be use-visible,
+ resulting in errors. This should be rare and is easily fixed
+ if it does occur.
+
+\1f
+File: aarm2012.info, Node: A.4.5, Next: A.4.6, Prev: A.4.4, Up: A.4
+
+A.4.5 Unbounded-Length String Handling
+--------------------------------------
+
+1
+The language-defined package Strings.Unbounded provides a private type
+Unbounded_String and a set of operations. An object of type
+Unbounded_String represents a String whose low bound is 1 and whose
+length can vary conceptually between 0 and Natural'Last. The
+subprograms for fixed-length string handling are either overloaded
+directly for Unbounded_String, or are modified as needed to reflect the
+flexibility in length. Since the Unbounded_String type is private,
+relevant constructor and selector operations are provided.
+
+1.a
+ Reason: The transformation operations for fixed- and
+ bounded-length strings that are not necessarily length
+ preserving are supplied for Unbounded_String as procedures as
+ well as functions. This allows an implementation to do an
+ initial allocation for an unbounded string and to avoid
+ further allocations as long as the length does not exceed the
+ allocated length.
+
+ _Static Semantics_
+
+2
+The library package Strings.Unbounded has the following declaration:
+
+3
+ with Ada.Strings.Maps;
+ package Ada.Strings.Unbounded is
+ pragma Preelaborate(Unbounded);
+
+4/2
+ {AI95-00161-01AI95-00161-01} type Unbounded_String is private;
+ pragma Preelaborable_Initialization(Unbounded_String);
+
+5
+ Null_Unbounded_String : constant Unbounded_String;
+
+6
+ function Length (Source : in Unbounded_String) return Natural;
+
+7
+ type String_Access is access all String;
+ procedure Free (X : in out String_Access);
+
+8
+ -- Conversion, Concatenation, and Selection functions
+
+9
+ function To_Unbounded_String (Source : in String)
+ return Unbounded_String;
+
+10
+ function To_Unbounded_String (Length : in Natural)
+ return Unbounded_String;
+
+11
+ function To_String (Source : in Unbounded_String) return String;
+
+11.1/2
+ {AI95-00301-01AI95-00301-01} procedure Set_Unbounded_String
+ (Target : out Unbounded_String;
+ Source : in String);
+
+12
+ procedure Append (Source : in out Unbounded_String;
+ New_Item : in Unbounded_String);
+
+13
+ procedure Append (Source : in out Unbounded_String;
+ New_Item : in String);
+
+14
+ procedure Append (Source : in out Unbounded_String;
+ New_Item : in Character);
+
+15
+ function "&" (Left, Right : in Unbounded_String)
+ return Unbounded_String;
+
+16
+ function "&" (Left : in Unbounded_String; Right : in String)
+ return Unbounded_String;
+
+17
+ function "&" (Left : in String; Right : in Unbounded_String)
+ return Unbounded_String;
+
+18
+ function "&" (Left : in Unbounded_String; Right : in Character)
+ return Unbounded_String;
+
+19
+ function "&" (Left : in Character; Right : in Unbounded_String)
+ return Unbounded_String;
+
+20
+ function Element (Source : in Unbounded_String;
+ Index : in Positive)
+ return Character;
+
+21
+ procedure Replace_Element (Source : in out Unbounded_String;
+ Index : in Positive;
+ By : in Character);
+
+22
+ function Slice (Source : in Unbounded_String;
+ Low : in Positive;
+ High : in Natural)
+ return String;
+
+22.1/2
+ {AI95-00301-01AI95-00301-01} function Unbounded_Slice
+ (Source : in Unbounded_String;
+ Low : in Positive;
+ High : in Natural)
+ return Unbounded_String;
+
+22.2/2
+ {AI95-00301-01AI95-00301-01} procedure Unbounded_Slice
+ (Source : in Unbounded_String;
+ Target : out Unbounded_String;
+ Low : in Positive;
+ High : in Natural);
+
+23
+ function "=" (Left, Right : in Unbounded_String) return Boolean;
+
+24
+ function "=" (Left : in Unbounded_String; Right : in String)
+ return Boolean;
+
+25
+ function "=" (Left : in String; Right : in Unbounded_String)
+ return Boolean;
+
+26
+ function "<" (Left, Right : in Unbounded_String) return Boolean;
+
+27
+ function "<" (Left : in Unbounded_String; Right : in String)
+ return Boolean;
+
+28
+ function "<" (Left : in String; Right : in Unbounded_String)
+ return Boolean;
+
+29
+ function "<=" (Left, Right : in Unbounded_String) return Boolean;
+
+30
+ function "<=" (Left : in Unbounded_String; Right : in String)
+ return Boolean;
+
+31
+ function "<=" (Left : in String; Right : in Unbounded_String)
+ return Boolean;
+
+32
+ function ">" (Left, Right : in Unbounded_String) return Boolean;
+
+33
+ function ">" (Left : in Unbounded_String; Right : in String)
+ return Boolean;
+
+34
+ function ">" (Left : in String; Right : in Unbounded_String)
+ return Boolean;
+
+35
+ function ">=" (Left, Right : in Unbounded_String) return Boolean;
+
+36
+ function ">=" (Left : in Unbounded_String; Right : in String)
+ return Boolean;
+
+37
+ function ">=" (Left : in String; Right : in Unbounded_String)
+ return Boolean;
+
+38
+ -- Search subprograms
+
+38.1/2
+ {AI95-00301-01AI95-00301-01} function Index (Source : in Unbounded_String;
+ Pattern : in String;
+ From : in Positive;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping := Maps.Identity)
+ return Natural;
+
+38.2/2
+ {AI95-00301-01AI95-00301-01} function Index (Source : in Unbounded_String;
+ Pattern : in String;
+ From : in Positive;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping_Function)
+ return Natural;
+
+39
+ function Index (Source : in Unbounded_String;
+ Pattern : in String;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping
+ := Maps.Identity)
+ return Natural;
+
+40
+ function Index (Source : in Unbounded_String;
+ Pattern : in String;
+ Going : in Direction := Forward;
+ Mapping : in Maps.Character_Mapping_Function)
+ return Natural;
+
+40.1/2
+ {AI95-00301-01AI95-00301-01} function Index (Source : in Unbounded_String;
+ Set : in Maps.Character_Set;
+ From : in Positive;
+ Test : in Membership := Inside;
+ Going : in Direction := Forward)
+ return Natural;
+
+41
+ function Index (Source : in Unbounded_String;
+ Set : in Maps.Character_Set;
+ Test : in Membership := Inside;
+ Going : in Direction := Forward) return Natural;
+
+41.1/2
+ {AI95-00301-01AI95-00301-01} function Index_Non_Blank (Source : in Unbounded_String;
+ From : in Positive;
+ Going : in Direction := Forward)
+ return Natural;
+
+42
+ function Index_Non_Blank (Source : in Unbounded_String;
+ Going : in Direction := Forward)
+ return Natural;
+
+43
+ function Count (Source : in Unbounded_String;
+ Pattern : in String;
+ Mapping : in Maps.Character_Mapping
+ := Maps.Identity)
+ return Natural;
+
+44
+ function Count (Source : in Unbounded_String;
+ Pattern : in String;
+ Mapping : in Maps.Character_Mapping_Function)
+ return Natural;
+
+45
+ function Count (Source : in Unbounded_String;
+ Set : in Maps.Character_Set)
+ return Natural;
+
+45.1/3
+ {AI05-0031-1AI05-0031-1} procedure Find_Token (Source : in Unbounded_String;
+ Set : in Maps.Character_Set;
+ From : in Positive;
+ Test : in Membership;
+ First : out Positive;
+ Last : out Natural);
+
+46
+ procedure Find_Token (Source : in Unbounded_String;
+ Set : in Maps.Character_Set;
+ Test : in Membership;
+ First : out Positive;
+ Last : out Natural);
+
+47
+ -- String translation subprograms
+
+48
+ function Translate (Source : in Unbounded_String;
+ Mapping : in Maps.Character_Mapping)
+ return Unbounded_String;
+
+49
+ procedure Translate (Source : in out Unbounded_String;
+ Mapping : in Maps.Character_Mapping);
+
+50
+ function Translate (Source : in Unbounded_String;
+ Mapping : in Maps.Character_Mapping_Function)
+ return Unbounded_String;
+
+51
+ procedure Translate (Source : in out Unbounded_String;
+ Mapping : in Maps.Character_Mapping_Function);
+
+52
+ -- String transformation subprograms
+
+53
+ function Replace_Slice (Source : in Unbounded_String;
+ Low : in Positive;
+ High : in Natural;
+ By : in String)
+ return Unbounded_String;
+
+54
+ procedure Replace_Slice (Source : in out Unbounded_String;
+ Low : in Positive;
+ High : in Natural;
+ By : in String);
+
+55
+ function Insert (Source : in Unbounded_String;
+ Before : in Positive;
+ New_Item : in String)
+ return Unbounded_String;
+
+56
+ procedure Insert (Source : in out Unbounded_String;
+ Before : in Positive;
+ New_Item : in String);
+
+57
+ function Overwrite (Source : in Unbounded_String;
+ Position : in Positive;
+ New_Item : in String)
+ return Unbounded_String;
+
+58
+ procedure Overwrite (Source : in out Unbounded_String;
+ Position : in Positive;
+ New_Item : in String);
+
+59
+ function Delete (Source : in Unbounded_String;
+ From : in Positive;
+ Through : in Natural)
+ return Unbounded_String;
+
+60
+ procedure Delete (Source : in out Unbounded_String;
+ From : in Positive;
+ Through : in Natural);
+
+61
+ function Trim (Source : in Unbounded_String;
+ Side : in Trim_End)
+ return Unbounded_String;
+
+62
+ procedure Trim (Source : in out Unbounded_String;
+ Side : in Trim_End);
+
+63
+ function Trim (Source : in Unbounded_String;
+ Left : in Maps.Character_Set;
+ Right : in Maps.Character_Set)
+ return Unbounded_String;
+
+64
+ procedure Trim (Source : in out Unbounded_String;
+ Left : in Maps.Character_Set;
+ Right : in Maps.Character_Set);
+
+65
+ function Head (Source : in Unbounded_String;
+ Count : in Natural;
+ Pad : in Character := Space)
+ return Unbounded_String;
+
+66
+ procedure Head (Source : in out Unbounded_String;
+ Count : in Natural;
+ Pad : in Character := Space);
+
+67
+ function Tail (Source : in Unbounded_String;
+ Count : in Natural;
+ Pad : in Character := Space)
+ return Unbounded_String;
+
+68
+ procedure Tail (Source : in out Unbounded_String;
+ Count : in Natural;
+ Pad : in Character := Space);
+
+69
+ function "*" (Left : in Natural;
+ Right : in Character)
+ return Unbounded_String;
+
+70
+ function "*" (Left : in Natural;
+ Right : in String)
+ return Unbounded_String;
+
+71
+ function "*" (Left : in Natural;
+ Right : in Unbounded_String)
+ return Unbounded_String;
+
+72
+ private
+ ... -- not specified by the language
+ end Ada.Strings.Unbounded;
+
+72.1/2
+{AI95-00360-01AI95-00360-01} The type Unbounded_String needs
+finalization (see *note 7.6::).
+
+73
+Null_Unbounded_String represents the null String. If an object of type
+Unbounded_String is not otherwise initialized, it will be initialized to
+the same value as Null_Unbounded_String.
+
+74
+The function Length returns the length of the String represented by
+Source.
+
+75
+The type String_Access provides a (nonprivate) access type for explicit
+processing of unbounded-length strings. The procedure Free performs an
+unchecked deallocation of an object of type String_Access.
+
+76
+The function To_Unbounded_String(Source : in String) returns an
+Unbounded_String that represents Source. The function
+To_Unbounded_String(Length : in Natural) returns an Unbounded_String
+that represents an uninitialized String whose length is Length.
+
+77
+The function To_String returns the String with lower bound 1 represented
+by Source. To_String and To_Unbounded_String are related as follows:
+
+78
+ * If S is a String, then To_String(To_Unbounded_String(S)) = S.
+
+79
+ * If U is an Unbounded_String, then To_Unbounded_String(To_String(U))
+ = U.
+
+79.1/2
+{AI95-00301-01AI95-00301-01} The procedure Set_Unbounded_String sets
+Target to an Unbounded_String that represents Source.
+
+80
+For each of the Append procedures, the resulting string represented by
+the Source parameter is given by the concatenation of the original value
+of Source and the value of New_Item.
+
+81
+Each of the "&" functions returns an Unbounded_String obtained by
+concatenating the string or character given or represented by one of the
+parameters, with the string or character given or represented by the
+other parameter, and applying To_Unbounded_String to the concatenation
+result string.
+
+82
+The Element, Replace_Element, and Slice subprograms have the same effect
+as the corresponding bounded-length string subprograms.
+
+82.1/3
+{AI95-00301-01AI95-00301-01} {AI05-0262-1AI05-0262-1} The function
+Unbounded_Slice returns the slice at positions Low through High in the
+string represented by Source as an Unbounded_String. The procedure
+Unbounded_Slice sets Target to the Unbounded_String representing the
+slice at positions Low through High in the string represented by Source.
+Both subprograms propagate Index_Error if Low > Length(Source)+1 or High
+> Length(Source).
+
+83
+Each of the functions "=", "<", ">", "<=", and ">=" returns the same
+result as the corresponding String operation applied to the String
+values given or represented by Left and Right.
+
+84
+Each of the search subprograms (Index, Index_Non_Blank, Count,
+Find_Token) has the same effect as the corresponding subprogram in
+Strings.Fixed applied to the string represented by the Unbounded_String
+parameter.
+
+85
+The Translate function has an analogous effect to the corresponding
+subprogram in Strings.Fixed. The translation is applied to the string
+represented by the Unbounded_String parameter, and the result is
+converted (via To_Unbounded_String) to an Unbounded_String.
+
+86
+Each of the transformation functions (Replace_Slice, Insert, Overwrite,
+Delete), selector functions (Trim, Head, Tail), and constructor
+functions ("*") is likewise analogous to its corresponding subprogram in
+Strings.Fixed. For each of the subprograms, the corresponding
+fixed-length string subprogram is applied to the string represented by
+the Unbounded_String parameter, and To_Unbounded_String is applied the
+result string.
+
+87
+For each of the procedures Translate, Replace_Slice, Insert, Overwrite,
+Delete, Trim, Head, and Tail, the resulting string represented by the
+Source parameter is given by the corresponding function for fixed-length
+strings applied to the string represented by Source's original value.
+
+ _Implementation Requirements_
+
+88
+No storage associated with an Unbounded_String object shall be lost upon
+assignment or scope exit.
+
+88.a/2
+ Implementation Note: {AI95-00301-01AI95-00301-01} A sample
+ implementation of the private part of the package and several
+ of the subprograms appears in the Ada 95 Rationale.
+
+ _Incompatibilities With Ada 95_
+
+88.b/2
+ {AI95-00360-01AI95-00360-01} Amendment Correction: Type
+ Unbounded_String is defined to need finalization. If the
+ restriction No_Nested_Finalization (see *note D.7::) applies
+ to the partition, and Unbounded_String does not have a
+ controlled part, it will not be allowed in local objects in
+ Ada 2005 whereas it would be allowed in original Ada 95. Such
+ code is not portable, as most Ada compilers have a controlled
+ part in Unbounded_String, and thus would be illegal.
+
+88.c/3
+ {AI95-00301-01AI95-00301-01} {AI05-0005-1AI05-0005-1}
+ Procedure Set_Unbounded_String, two Unbounded_Slice
+ subprograms, and overloaded versions of Index and
+ Index_Non_Blank are added to Strings.Unbounded. If
+ Strings.Unbounded is referenced in a use_clause, and an entity
+ E with the same defining_identifier as a new entity in
+ Strings.Unbounded is defined in a package that is also
+ referenced in a use_clause, the entity E may no longer be
+ use-visible, resulting in errors. This should be rare and is
+ easily fixed if it does occur.
+
+ _Extensions to Ada 95_
+
+88.d/2
+ {AI95-00161-01AI95-00161-01} Amendment Correction: Added a
+ pragma Preelaborable_Initialization to type Unbounded_String,
+ so that it can be used to declare default-initialized objects
+ in preelaborated units.
+
+ _Incompatibilities With Ada 2005_
+
+88.e/3
+ {AI05-0031-1AI05-0031-1} An overloaded version of Find_Token
+ is added to Strings.Unbounded. If Strings.Unbounded is
+ referenced in a use_clause, and an entity E with a
+ defining_identifier of Find_Token is defined in a package that
+ is also referenced in a use_clause, the entity E may no longer
+ be use-visible, resulting in errors. This should be rare and
+ is easily fixed if it does occur.
+
+\1f
+File: aarm2012.info, Node: A.4.6, Next: A.4.7, Prev: A.4.5, Up: A.4
+
+A.4.6 String-Handling Sets and Mappings
+---------------------------------------
+
+1
+The language-defined package Strings.Maps.Constants declares
+Character_Set and Character_Mapping constants corresponding to
+classification and conversion functions in package Characters.Handling.
+
+1.a
+ Discussion: The Constants package is a child of Strings.Maps
+ since it needs visibility of the private part of Strings.Maps
+ in order to initialize the constants in a preelaborable way
+ (i.e. via aggregates versus function calls).
+
+ _Static Semantics_
+
+2
+The library package Strings.Maps.Constants has the following
+declaration:
+
+3/2
+ {AI95-00362-01AI95-00362-01} package Ada.Strings.Maps.Constants is
+ pragma Pure(Constants);
+
+4
+ Control_Set : constant Character_Set;
+ Graphic_Set : constant Character_Set;
+ Letter_Set : constant Character_Set;
+ Lower_Set : constant Character_Set;
+ Upper_Set : constant Character_Set;
+ Basic_Set : constant Character_Set;
+ Decimal_Digit_Set : constant Character_Set;
+ Hexadecimal_Digit_Set : constant Character_Set;
+ Alphanumeric_Set : constant Character_Set;
+ Special_Set : constant Character_Set;
+ ISO_646_Set : constant Character_Set;
+
+5
+ Lower_Case_Map : constant Character_Mapping;
+ --Maps to lower case for letters, else identity
+ Upper_Case_Map : constant Character_Mapping;
+ --Maps to upper case for letters, else identity
+ Basic_Map : constant Character_Mapping;
+ --Maps to basic letter for letters, else identity
+
+6
+ private
+ ... -- not specified by the language
+ end Ada.Strings.Maps.Constants;
+
+7
+Each of these constants represents a correspondingly named set of
+characters or character mapping in Characters.Handling (see *note
+A.3.2::).
+
+ NOTES
+
+8/3
+ 15 {AI05-0114-1AI05-0114-1} There are certain characters which are
+ defined to be lower case letters by ISO 10646 and are therefore
+ allowed in identifiers, but are not considered lower case letters
+ by Ada.Strings.Maps.Constants.
+
+8.a/3
+ Reason: This is to maintain runtime compatibility with the Ada
+ 95 definitions of these constants; existing correct programs
+ could break if the definitions were changed in a way the
+ programs did not anticipate.
+
+ _Extensions to Ada 95_
+
+8.b/2
+ {AI95-00362-01AI95-00362-01} Strings.Maps.Constants is now
+ Pure, so it can be used in pure units.
+
+ _Wording Changes from Ada 2005_
+
+8.c/3
+ {AI05-0114-1AI05-0114-1} Correction: Added a note to clarify
+ that these constants don't have any relationship to the
+ characters allowed in identifiers.
+
+\1f
+File: aarm2012.info, Node: A.4.7, Next: A.4.8, Prev: A.4.6, Up: A.4
+
+A.4.7 Wide_String Handling
+--------------------------
+
+1/3
+{AI95-00302-03AI95-00302-03} {AI05-0286-1AI05-0286-1} Facilities for
+handling strings of Wide_Character elements are found in the packages
+Strings.Wide_Maps, Strings.Wide_Fixed, Strings.Wide_Bounded,
+Strings.Wide_Unbounded, and Strings.Wide_Maps.Wide_Constants, and in the
+library functions Strings.Wide_Hash, Strings.Wide_Fixed.Wide_Hash,
+Strings.Wide_Bounded.Wide_Hash, Strings.Wide_Unbounded.Wide_Hash,
+Strings.Wide_Hash_Case_Insensitive,
+Strings.Wide_Fixed.Wide_Hash_Case_Insensitive,
+Strings.Wide_Bounded.Wide_Hash_Case_Insensitive,
+Strings.Wide_Unbounded.Wide_Hash_Case_Insensitive,
+Strings.Wide_Equal_Case_Insensitive,
+Strings.Wide_Fixed.Wide_Equal_Case_Insensitive,
+Strings.Wide_Bounded.Wide_Equal_Case_Insensitive, and
+Strings.Wide_Unbounded.Wide_Equal_Case_Insensitive. They provide the
+same string-handling operations as the corresponding packages and
+functions for strings of Character elements.
+
+ _Static Semantics_
+
+2
+The package Strings.Wide_Maps has the following declaration.
+
+3
+ package Ada.Strings.Wide_Maps is
+ pragma Preelaborate(Wide_Maps);
+
+4/2
+ {AI95-00161-01AI95-00161-01} -- Representation for a set of Wide_Character values:
+ type Wide_Character_Set is private;
+ pragma Preelaborable_Initialization(Wide_Character_Set);
+
+5
+ Null_Set : constant Wide_Character_Set;
+
+6
+ type Wide_Character_Range is
+ record
+ Low : Wide_Character;
+ High : Wide_Character;
+ end record;
+ -- Represents Wide_Character range Low..High
+
+7
+ type Wide_Character_Ranges is array (Positive range <>)
+ of Wide_Character_Range;
+
+8
+ function To_Set (Ranges : in Wide_Character_Ranges)
+ return Wide_Character_Set;
+
+9
+ function To_Set (Span : in Wide_Character_Range)
+ return Wide_Character_Set;
+
+10
+ function To_Ranges (Set : in Wide_Character_Set)
+ return Wide_Character_Ranges;
+
+11
+ function "=" (Left, Right : in Wide_Character_Set) return Boolean;
+
+12
+ function "not" (Right : in Wide_Character_Set)
+ return Wide_Character_Set;
+ function "and" (Left, Right : in Wide_Character_Set)
+ return Wide_Character_Set;
+ function "or" (Left, Right : in Wide_Character_Set)
+ return Wide_Character_Set;
+ function "xor" (Left, Right : in Wide_Character_Set)
+ return Wide_Character_Set;
+ function "-" (Left, Right : in Wide_Character_Set)
+ return Wide_Character_Set;
+
+13
+ function Is_In (Element : in Wide_Character;
+ Set : in Wide_Character_Set)
+ return Boolean;
+
+14
+ function Is_Subset (Elements : in Wide_Character_Set;
+ Set : in Wide_Character_Set)
+ return Boolean;
+
+15
+ function "<=" (Left : in Wide_Character_Set;
+ Right : in Wide_Character_Set)
+ return Boolean renames Is_Subset;
+
+16
+ -- Alternative representation for a set of Wide_Character values:
+ subtype Wide_Character_Sequence is Wide_String;
+
+17
+ function To_Set (Sequence : in Wide_Character_Sequence)
+ return Wide_Character_Set;
+
+18
+ function To_Set (Singleton : in Wide_Character)
+ return Wide_Character_Set;
+
+19
+ function To_Sequence (Set : in Wide_Character_Set)
+ return Wide_Character_Sequence;
+
+20/2
+ {AI95-00161-01AI95-00161-01} -- Representation for a Wide_Character to Wide_Character mapping:
+ type Wide_Character_Mapping is private;
+ pragma Preelaborable_Initialization(Wide_Character_Mapping);
+
+21
+ function Value (Map : in Wide_Character_Mapping;
+ Element : in Wide_Character)
+ return Wide_Character;
+
+22
+ Identity : constant Wide_Character_Mapping;
+
+23
+ function To_Mapping (From, To : in Wide_Character_Sequence)
+ return Wide_Character_Mapping;
+
+24
+ function To_Domain (Map : in Wide_Character_Mapping)
+ return Wide_Character_Sequence;
+
+25
+ function To_Range (Map : in Wide_Character_Mapping)
+ return Wide_Character_Sequence;
+
+26
+ type Wide_Character_Mapping_Function is
+ access function (From : in Wide_Character) return Wide_Character;
+
+27
+ private
+ ... -- not specified by the language
+ end Ada.Strings.Wide_Maps;
+
+28
+The context clause for each of the packages Strings.Wide_Fixed,
+Strings.Wide_Bounded, and Strings.Wide_Unbounded identifies
+Strings.Wide_Maps instead of Strings.Maps.
+
+28.1/3
+{AI05-0223-1AI05-0223-1} Types Wide_Character_Set and
+Wide_Character_Mapping need finalization.
+
+29/3
+{AI95-00302-03AI95-00302-03} {AI05-0286-1AI05-0286-1} For each of the
+packages Strings.Fixed, Strings.Bounded, Strings.Unbounded, and
+Strings.Maps.Constants, and for library functions Strings.Hash,
+Strings.Fixed.Hash, Strings.Bounded.Hash, Strings.Unbounded.Hash,
+Strings.Hash_Case_Insensitive, Strings.Fixed.Hash_Case_Insensitive,
+Strings.Bounded.Hash_Case_Insensitive,
+Strings.Unbounded.Hash_Case_Insensitive, Strings.Equal_Case_Insensitive,
+Strings.Fixed.Equal_Case_Insensitive,
+Strings.Bounded.Equal_Case_Insensitive, and
+Strings.Unbounded.Equal_Case_Insensitive, the corresponding wide string
+package or function has the same contents except that
+
+30
+ * Wide_Space replaces Space
+
+31
+ * Wide_Character replaces Character
+
+32
+ * Wide_String replaces String
+
+33
+ * Wide_Character_Set replaces Character_Set
+
+34
+ * Wide_Character_Mapping replaces Character_Mapping
+
+35
+ * Wide_Character_Mapping_Function replaces Character_Mapping_Function
+
+36
+ * Wide_Maps replaces Maps
+
+37
+ * Bounded_Wide_String replaces Bounded_String
+
+38
+ * Null_Bounded_Wide_String replaces Null_Bounded_String
+
+39
+ * To_Bounded_Wide_String replaces To_Bounded_String
+
+40
+ * To_Wide_String replaces To_String
+
+40.1/2
+ * {AI95-00301-01AI95-00301-01} Set_Bounded_Wide_String replaces
+ Set_Bounded_String
+
+41
+ * Unbounded_Wide_String replaces Unbounded_String
+
+42
+ * Null_Unbounded_Wide_String replaces Null_Unbounded_String
+
+43
+ * Wide_String_Access replaces String_Access
+
+44
+ * To_Unbounded_Wide_String replaces To_Unbounded_String
+
+44.1/2
+ * {AI95-00301-01AI95-00301-01} Set_Unbounded_Wide_String replaces
+ Set_Unbounded_String
+
+45
+The following additional declaration is present in
+Strings.Wide_Maps.Wide_Constants:
+
+46/2
+ {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01} Character_Set : constant Wide_Maps.Wide_Character_Set;
+ --Contains each Wide_Character value WC such that
+ --Characters.Conversions.Is_Character(WC) is True
+
+46.1/2
+{AI95-00395-01AI95-00395-01} Each Wide_Character_Set constant in the
+package Strings.Wide_Maps.Wide_Constants contains no values outside the
+Character portion of Wide_Character. Similarly, each
+Wide_Character_Mapping constant in this package is the identity mapping
+when applied to any element outside the Character portion of
+Wide_Character.
+
+46.2/2
+{AI95-00362-01AI95-00362-01} Pragma Pure is replaced by pragma
+Preelaborate in Strings.Wide_Maps.Wide_Constants.
+
+ NOTES
+
+47
+ 16 If a null Wide_Character_Mapping_Function is passed to any of
+ the Wide_String handling subprograms, Constraint_Error is
+ propagated.
+
+ _Incompatibilities With Ada 95_
+
+48.a/2
+ {AI95-00301-01AI95-00301-01} Various new operations are added
+ to Strings.Wide_Fixed, Strings.Wide_Bounded, and
+ Strings.Wide_Unbounded. If one of these packages is
+ referenced in a use_clause, and an entity E with the same
+ defining_identifier as a new entity is defined in a package
+ that is also referenced in a use_clause, the entity E may no
+ longer be use-visible, resulting in errors. This should be
+ rare and is easily fixed if it does occur.
+
+ _Extensions to Ada 95_
+
+48.b/2
+ {AI95-00161-01AI95-00161-01} Amendment Correction: Added
+ pragma Preelaborable_Initialization to types
+ Wide_Character_Set and Wide_Character_Mapping, so that they
+ can be used to declare default-initialized objects in
+ preelaborated units.
+
+ _Wording Changes from Ada 95_
+
+48.c/2
+ {AI95-00285-01AI95-00285-01} Corrected the description of
+ Character_Set.
+
+48.d/2
+ {AI95-00302-03AI95-00302-03} Added wide versions of
+ Strings.Hash and Strings.Unbounded.Hash.
+
+48.e/2
+ {AI95-00362-01AI95-00362-01} Added wording so that
+ Strings.Wide_Maps.Wide_Constants does not change to Pure.
+
+48.f/2
+ {AI95-00395-01AI95-00395-01} The second Note is now normative
+ text, since there is no way to derive it from the other rules.
+ It's a little weird given the use of Unicode character
+ classifications in Ada 2005; but changing it would be
+ inconsistent with Ada 95 and a one-to-one mapping isn't
+ necessarily correct anyway.
+
+ _Extensions to Ada 2005_
+
+48.g/3
+ {AI05-0286-1AI05-0286-1} The case insenstive library functions
+ (Strings.Wide_Equal_Case_Insensitive,
+ Strings.Wide_Fixed.Wide_Equal_Case_Insensitive,
+ Strings.Wide_Bounded.Wide_Equal_Case_Insensitive,
+ Strings.Wide_Unbounded.Wide_Equal_Case_Insensitive,
+ Strings.Wide_Hash_Case_Insensitive,
+ Strings.Wide_Fixed.Wide_Hash_Case_Insensitive,
+ Strings.Wide_Bounded.Wide_Hash_Case_Insensitive, and
+ Strings.Wide_Unbounded.Wide_Hash_Case_Insensitive) are new.
+
+ _Wording Changes from Ada 2005_
+
+48.h/3
+ {AI05-0223-1AI05-0223-1} Correction: Identified
+ Wide_Character_Set and Wide_Character_Mapping as needing
+ finalization. It is likely that they are implemented with a
+ controlled type, so this change is unlikely to make any
+ difference in practice.
+
+\1f
+File: aarm2012.info, Node: A.4.8, Next: A.4.9, Prev: A.4.7, Up: A.4
+
+A.4.8 Wide_Wide_String Handling
+-------------------------------
+
+1/3
+{AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+{AI05-0286-1AI05-0286-1} Facilities for handling strings of
+Wide_Wide_Character elements are found in the packages
+Strings.Wide_Wide_Maps, Strings.Wide_Wide_Fixed,
+Strings.Wide_Wide_Bounded, Strings.Wide_Wide_Unbounded, and
+Strings.Wide_Wide_Maps.Wide_Wide_Constants, and in the library functions
+Strings.Wide_Wide_Hash, Strings.Wide_Wide_Fixed.Wide_Wide_Hash,
+Strings.Wide_Wide_Bounded.Wide_Wide_Hash,
+Strings.Wide_Wide_Unbounded.Wide_Wide_Hash,
+Strings.Wide_Wide_Hash_Case_Insensitive,
+Strings.Wide_Wide_Fixed.Wide_Wide_Hash_Case_Insensitive,
+Strings.Wide_Wide_Bounded.Wide_Wide_Hash_Case_Insensitive,
+Strings.Wide_Wide_Unbounded.Wide_Wide_Hash_Case_Insensitive,
+Strings.Wide_Wide_Equal_Case_Insensitive,
+Strings.Wide_Wide_Fixed.Wide_Wide_Equal_Case_Insensitive,
+Strings.Wide_Wide_Bounded.Wide_Wide_Equal_Case_Insensitive, and
+Strings.Wide_Wide_Unbounded.Wide_Wide_Equal_Case_Insensitive. They
+provide the same string-handling operations as the corresponding
+packages and functions for strings of Character elements.
+
+ _Static Semantics_
+
+2/2
+{AI95-00285-01AI95-00285-01} The library package Strings.Wide_Wide_Maps
+has the following declaration.
+
+3/2
+ package Ada.Strings.Wide_Wide_Maps is
+ pragma Preelaborate(Wide_Wide_Maps);
+
+4/2
+ -- Representation for a set of Wide_Wide_Character values:
+ type Wide_Wide_Character_Set is private;
+ pragma Preelaborable_Initialization(Wide_Wide_Character_Set);
+
+5/2
+ Null_Set : constant Wide_Wide_Character_Set;
+
+6/2
+ type Wide_Wide_Character_Range is
+ record
+ Low : Wide_Wide_Character;
+ High : Wide_Wide_Character;
+ end record;
+ -- Represents Wide_Wide_Character range Low..High
+
+7/2
+ type Wide_Wide_Character_Ranges is array (Positive range <>)
+ of Wide_Wide_Character_Range;
+
+8/2
+ function To_Set (Ranges : in Wide_Wide_Character_Ranges)
+ return Wide_Wide_Character_Set;
+
+9/2
+ function To_Set (Span : in Wide_Wide_Character_Range)
+ return Wide_Wide_Character_Set;
+
+10/2
+ function To_Ranges (Set : in Wide_Wide_Character_Set)
+ return Wide_Wide_Character_Ranges;
+
+11/2
+ function "=" (Left, Right : in Wide_Wide_Character_Set) return Boolean;
+
+12/2
+ function "not" (Right : in Wide_Wide_Character_Set)
+ return Wide_Wide_Character_Set;
+ function "and" (Left, Right : in Wide_Wide_Character_Set)
+ return Wide_Wide_Character_Set;
+ function "or" (Left, Right : in Wide_Wide_Character_Set)
+ return Wide_Wide_Character_Set;
+ function "xor" (Left, Right : in Wide_Wide_Character_Set)
+ return Wide_Wide_Character_Set;
+ function "-" (Left, Right : in Wide_Wide_Character_Set)
+ return Wide_Wide_Character_Set;
+
+13/2
+ function Is_In (Element : in Wide_Wide_Character;
+ Set : in Wide_Wide_Character_Set)
+ return Boolean;
+
+14/2
+ function Is_Subset (Elements : in Wide_Wide_Character_Set;
+ Set : in Wide_Wide_Character_Set)
+ return Boolean;
+
+15/2
+ function "<=" (Left : in Wide_Wide_Character_Set;
+ Right : in Wide_Wide_Character_Set)
+ return Boolean renames Is_Subset;
+
+16/2
+ -- Alternative representation for a set of Wide_Wide_Character values:
+ subtype Wide_Wide_Character_Sequence is Wide_Wide_String;
+
+17/2
+ function To_Set (Sequence : in Wide_Wide_Character_Sequence)
+ return Wide_Wide_Character_Set;
+
+18/2
+ function To_Set (Singleton : in Wide_Wide_Character)
+ return Wide_Wide_Character_Set;
+
+19/2
+ function To_Sequence (Set : in Wide_Wide_Character_Set)
+ return Wide_Wide_Character_Sequence;
+
+20/2
+ -- Representation for a Wide_Wide_Character to Wide_Wide_Character
+ -- mapping:
+ type Wide_Wide_Character_Mapping is private;
+ pragma Preelaborable_Initialization(Wide_Wide_Character_Mapping);
+
+21/2
+ function Value (Map : in Wide_Wide_Character_Mapping;
+ Element : in Wide_Wide_Character)
+ return Wide_Wide_Character;
+
+22/2
+ Identity : constant Wide_Wide_Character_Mapping;
+
+23/2
+ function To_Mapping (From, To : in Wide_Wide_Character_Sequence)
+ return Wide_Wide_Character_Mapping;
+
+24/2
+ function To_Domain (Map : in Wide_Wide_Character_Mapping)
+ return Wide_Wide_Character_Sequence;
+
+25/2
+ function To_Range (Map : in Wide_Wide_Character_Mapping)
+ return Wide_Wide_Character_Sequence;
+
+26/2
+ type Wide_Wide_Character_Mapping_Function is
+ access function (From : in Wide_Wide_Character)
+ return Wide_Wide_Character;
+
+27/2
+ private
+ ... -- not specified by the language
+ end Ada.Strings.Wide_Wide_Maps;
+
+28/2
+{AI95-00285-01AI95-00285-01} The context clause for each of the packages
+Strings.Wide_Wide_Fixed, Strings.Wide_Wide_Bounded, and
+Strings.Wide_Wide_Unbounded identifies Strings.Wide_Wide_Maps instead of
+Strings.Maps.
+
+28.1/3
+{AI05-0223-1AI05-0223-1} Types Wide_Wide_Character_Set and
+Wide_Wide_Character_Mapping need finalization.
+
+29/3
+{AI95-00285-01AI95-00285-01} {AI05-0286-1AI05-0286-1} For each of the
+packages Strings.Fixed, Strings.Bounded, Strings.Unbounded, and
+Strings.Maps.Constants, and for library functions Strings.Hash,
+Strings.Fixed.Hash, Strings.Bounded.Hash, Strings.Unbounded.Hash,
+Strings.Hash_Case_Insensitive, Strings.Fixed.Hash_Case_Insensitive,
+Strings.Bounded.Hash_Case_Insensitive,
+Strings.Unbounded.Hash_Case_Insensitive, Strings.Equal_Case_Insensitive,
+Strings.Fixed.Equal_Case_Insensitive,
+Strings.Bounded.Equal_Case_Insensitive, and
+Strings.Unbounded.Equal_Case_Insensitive, the corresponding wide wide
+string package or function has the same contents except that
+
+30/2
+ * Wide_Wide_Space replaces Space
+
+31/2
+ * Wide_Wide_Character replaces Character
+
+32/2
+ * Wide_Wide_String replaces String
+
+33/2
+ * Wide_Wide_Character_Set replaces Character_Set
+
+34/2
+ * Wide_Wide_Character_Mapping replaces Character_Mapping
+
+35/2
+ * Wide_Wide_Character_Mapping_Function replaces
+ Character_Mapping_Function
+
+36/2
+ * Wide_Wide_Maps replaces Maps
+
+37/2
+ * Bounded_Wide_Wide_String replaces Bounded_String
+
+38/2
+ * Null_Bounded_Wide_Wide_String replaces Null_Bounded_String
+
+39/2
+ * To_Bounded_Wide_Wide_String replaces To_Bounded_String
+
+40/2
+ * To_Wide_Wide_String replaces To_String
+
+41/2
+ * {AI95-00301-01AI95-00301-01} Set_Bounded_Wide_Wide_String replaces
+ Set_Bounded_String
+
+42/2
+ * Unbounded_Wide_Wide_String replaces Unbounded_String
+
+43/2
+ * Null_Unbounded_Wide_Wide_String replaces Null_Unbounded_String
+
+44/2
+ * Wide_Wide_String_Access replaces String_Access
+
+45/2
+ * To_Unbounded_Wide_Wide_String replaces To_Unbounded_String
+
+46/2
+ * {AI95-00301-01AI95-00301-01} Set_Unbounded_Wide_Wide_String
+ replaces Set_Unbounded_String
+
+47/2
+{AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01} The following
+additional declarations are present in
+Strings.Wide_Wide_Maps.Wide_Wide_Constants:
+
+48/2
+ Character_Set : constant Wide_Wide_Maps.Wide_Wide_Character_Set;
+ -- Contains each Wide_Wide_Character value WWC such that
+ -- Characters.Conversions.Is_Character(WWC) is True
+ Wide_Character_Set : constant Wide_Wide_Maps.Wide_Wide_Character_Set;
+ -- Contains each Wide_Wide_Character value WWC such that
+ -- Characters.Conversions.Is_Wide_Character(WWC) is True
+
+49/2
+{AI95-00395-01AI95-00395-01} Each Wide_Wide_Character_Set constant in
+the package Strings.Wide_Wide_Maps.Wide_Wide_Constants contains no
+values outside the Character portion of Wide_Wide_Character. Similarly,
+each Wide_Wide_Character_Mapping constant in this package is the
+identity mapping when applied to any element outside the Character
+portion of Wide_Wide_Character.
+
+50/2
+{AI95-00395-01AI95-00395-01} Pragma Pure is replaced by pragma
+Preelaborate in Strings.Wide_Wide_Maps.Wide_Wide_Constants.
+
+ NOTES
+
+51/2
+ 17 {AI95-00285-01AI95-00285-01} If a null
+ Wide_Wide_Character_Mapping_Function is passed to any of the
+ Wide_Wide_String handling subprograms, Constraint_Error is
+ propagated.
+
+ _Extensions to Ada 95_
+
+51.a/2
+ {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01} The
+ double-wide string-handling packages (Strings.Wide_Wide_Maps,
+ Strings.Wide_Wide_Fixed, Strings.Wide_Wide_Bounded,
+ Strings.Wide_Wide_Unbounded, and
+ Strings.Wide_Wide_Maps.Wide_Wide_Constants), and functions
+ Strings.Wide_Wide_Hash and
+ Strings.Wide_Wide_Unbounded.Wide_Wide_Hash are new.
+
+ _Extensions to Ada 2005_
+
+51.b/3
+ {AI05-0286-1AI05-0286-1} The case insenstive library functions
+ (Strings.Wide_Wide_Equal_Case_Insensitive,
+ Strings.Wide_Wide_Fixed.Wide_Wide_Equal_Case_Insensitive,
+ Strings.Wide_Wide_Bounded.Wide_Wide_Equal_Case_Insensitive,
+ Strings.Wide_Wide_Unbounded.Wide_Wide_Equal_Case_Insensitive,
+ Strings.Wide_Wide_Hash_Case_Insensitive,
+ Strings.Wide_Wide_Fixed.Wide_Wide_Hash_Case_Insensitive,
+ Strings.Wide_Wide_Bounded.Wide_Wide_Hash_Case_Insensitive, and
+ Strings.Wide_Wide_Unbounded.Wide_Wide_Hash_Case_Insensitive)
+ are new.
+
+ _Wording Changes from Ada 2005_
+
+51.c/3
+ {AI05-0223-1AI05-0223-1} Correction: Identified
+ Wide_Wide_Character_Set and Wide_Wide_Character_Mapping as
+ needing finalization. It is likely that they are implemented
+ with a controlled type, so this change is unlikely to make any
+ difference in practice.
+
+\1f
+File: aarm2012.info, Node: A.4.9, Next: A.4.10, Prev: A.4.8, Up: A.4
+
+A.4.9 String Hashing
+--------------------
+
+ _Static Semantics_
+
+1/2
+{AI95-00302-03AI95-00302-03} The library function Strings.Hash has the
+following declaration:
+
+2/3
+ {AI05-0298-1AI05-0298-1} with Ada.Containers;
+ function Ada.Strings.Hash (Key : String) return Containers.Hash_Type;
+ pragma Pure(Ada.Strings.Hash);
+
+3/2
+ Returns an implementation-defined value which is a function of
+ the value of Key. If A and B are strings such that A equals
+ B, Hash(A) equals Hash(B).
+
+3.a/2
+ Implementation defined: The values returned by Strings.Hash.
+
+4/2
+{AI95-00302-03AI95-00302-03} The library function Strings.Fixed.Hash has
+the following declaration:
+
+5/3
+ {AI05-0298-1AI05-0298-1} with Ada.Containers, Ada.Strings.Hash;
+ function Ada.Strings.Fixed.Hash (Key : String) return Containers.Hash_Type
+ renames Ada.Strings.Hash;
+
+6/2
+{AI95-00302-03AI95-00302-03} The generic library function
+Strings.Bounded.Hash has the following declaration:
+
+7/3
+ {AI05-0298-1AI05-0298-1} with Ada.Containers;
+ generic
+ with package Bounded is
+ new Ada.Strings.Bounded.Generic_Bounded_Length (<>);
+ function Ada.Strings.Bounded.Hash (Key : Bounded.Bounded_String)
+ return Containers.Hash_Type;
+ pragma Preelaborate(Ada.Strings.Bounded.Hash);
+
+8/3
+ {AI05-0001-1AI05-0001-1} Equivalent to Strings.Hash
+ (Bounded.To_String (Key));
+
+9/2
+{AI95-00302-03AI95-00302-03} The library function Strings.Unbounded.Hash
+has the following declaration:
+
+10/3
+ {AI05-0298-1AI05-0298-1} with Ada.Containers;
+ function Ada.Strings.Unbounded.Hash (Key : Unbounded_String)
+ return Containers.Hash_Type;
+ pragma Preelaborate(Ada.Strings.Unbounded.Hash);
+
+11/3
+ {AI05-0001-1AI05-0001-1} Equivalent to Strings.Hash (To_String
+ (Key));
+
+11.1/3
+{AI05-0001-1AI05-0001-1} {AI05-0298-1AI05-0298-1} The library function
+Strings.Hash_Case_Insensitive has the following declaration:
+
+11.2/3
+ with Ada.Containers;
+ function Ada.Strings.Hash_Case_Insensitive (Key : String)
+ return Containers.Hash_Type;
+ pragma Pure(Ada.Strings.Hash_Case_Insensitive);
+
+11.3/3
+ Returns an implementation-defined value which is a function of
+ the value of Key, converted to lower case. If A and B are
+ strings such that Strings.Equal_Case_Insensitive (A, B) (see
+ *note A.4.10::) is True, then Hash_Case_Insensitive(A) equals
+ Hash_Case_Insensitive(B).
+
+11.4/3
+{AI05-0001-1AI05-0001-1} {AI05-0298-1AI05-0298-1} The library function
+Strings.Fixed.Hash_Case_Insensitive has the following declaration:
+
+11.5/3
+ with Ada.Containers, Ada.Strings.Hash_Case_Insensitive;
+ function Ada.Strings.Fixed.Hash_Case_Insensitive (Key : String)
+ return Containers.Hash_Type renames Ada.Strings.Hash_Case_Insensitive;
+
+11.6/3
+{AI05-0001-1AI05-0001-1} {AI05-0298-1AI05-0298-1} The generic library
+function Strings.Bounded.Hash_Case_Insensitive has the following
+declaration:
+
+11.7/3
+ with Ada.Containers;
+ generic
+ with package Bounded is
+ new Ada.Strings.Bounded.Generic_Bounded_Length (<>);
+ function Ada.Strings.Bounded.Hash_Case_Insensitive
+ (Key : Bounded.Bounded_String) return Containers.Hash_Type;
+ pragma Preelaborate(Ada.Strings.Bounded.Hash_Case_Insensitive);
+
+11.8/3
+ Equivalent to Strings.Hash_Case_Insensitive (Bounded.To_String
+ (Key));
+
+11.9/3
+{AI05-0001-1AI05-0001-1} {AI05-0298-1AI05-0298-1} The library function
+Strings.Unbounded.Hash_Case_Insensitive has the following declaration:
+
+11.10/3
+ with Ada.Containers;
+ function Ada.Strings.Unbounded.Hash_Case_Insensitive
+ (Key : Unbounded_String) return Containers.Hash_Type;
+ pragma Preelaborate(Ada.Strings.Unbounded.Hash_Case_Insensitive);
+
+11.11/3
+ Equivalent to Strings.Hash_Case_Insensitive (To_String (Key));
+
+ _Implementation Advice_
+
+12/2
+{AI95-00302-03AI95-00302-03} The Hash functions should be good hash
+functions, returning a wide spread of values for different string
+values. It should be unlikely for similar strings to return the same
+value.
+
+12.a/2
+ Implementation Advice: Strings.Hash should be good a hash
+ function, returning a wide spread of values for different
+ string values, and similar strings should rarely return the
+ same value.
+
+12.b/2
+ Ramification: The other functions are defined in terms of
+ Strings.Hash, so they don't need separate advice in the Annex.
+
+ _Extensions to Ada 95_
+
+12.c/2
+ {AI95-00302-03AI95-00302-03} The Strings.Hash,
+ Strings.Fixed.Hash, Strings.Bounded.Hash, and
+ Strings.Unbounded.Hash functions are new.
+
+ _Extensions to Ada 2005_
+
+12.d/3
+ {AI05-0001-1AI05-0001-1} The Strings.Hash_Case_Insensitive,
+ Strings.Fixed.Hash_Case_Insensitive,
+ Strings.Bounded.Hash_Case_Insensitive, and
+ Strings.Unbounded.Hash_Case_Insensitive functions are new.
+
+\1f
+File: aarm2012.info, Node: A.4.10, Next: A.4.11, Prev: A.4.9, Up: A.4
+
+A.4.10 String Comparison
+------------------------
+
+ _Static Semantics_
+
+1/3
+{AI05-0001-1AI05-0001-1} {AI05-0286-1AI05-0286-1}
+{AI05-0298-1AI05-0298-1} The library function
+Strings.Equal_Case_Insensitive has the following declaration:
+
+2/3
+ function Ada.Strings.Equal_Case_Insensitive (Left, Right : String)
+ return Boolean;
+ pragma Pure(Ada.Strings.Equal_Case_Insensitive);
+
+3/3
+ Returns True if the strings consist of the same sequence of
+ characters after applying locale-independent simple case
+ folding, as defined by documents referenced in the note in
+ Clause 1 of ISO/IEC 10646:2011. Otherwise, returns False.
+ This function uses the same method as is used to determine
+ whether two identifiers are the same.
+
+3.a/3
+ Discussion: {AI05-0286-1AI05-0286-1} For String, this is
+ equivalent to converting to lower case and comparing. Not so
+ for other string types. For Wide_Strings and
+ Wide_Wide_Strings, note that this result is a more accurate
+ comparison than converting the strings to lower case and
+ comparing the results; it is possible that the lower case
+ conversions are the same but this routine will report the
+ strings as different. Additionally, Unicode says that the
+ result of this function will never change for strings made up
+ solely of defined code points; there is no such guarantee for
+ case conversion to lower case.
+
+4/3
+{AI05-0001-1AI05-0001-1} {AI05-0248-1AI05-0248-1}
+{AI05-0298-1AI05-0298-1} The library function
+Strings.Fixed.Equal_Case_Insensitive has the following declaration:
+
+5/3
+ with Ada.Strings.Equal_Case_Insensitive;
+ function Ada.Strings.Fixed.Equal_Case_Insensitive
+ (Left, Right : String) return Boolean
+ renames Ada.Strings.Equal_Case_Insensitive;
+
+6/3
+{AI05-0001-1AI05-0001-1} {AI05-0248-1AI05-0248-1}
+{AI05-0298-1AI05-0298-1} The generic library function
+Strings.Bounded.Equal_Case_Insensitive has the following declaration:
+
+7/3
+ generic
+ with package Bounded is
+ new Ada.Strings.Bounded.Generic_Bounded_Length (<>);
+ function Ada.Strings.Bounded.Equal_Case_Insensitive
+ (Left, Right : Bounded.Bounded_String) return Boolean;
+ pragma Preelaborate(Ada.Strings.Bounded.Equal_Case_Insensitive);
+
+8/3
+ Equivalent to Strings.Equal_Case_Insensitive
+ (Bounded.To_String (Left), Bounded.To_String (Right));
+
+9/3
+{AI05-0001-1AI05-0001-1} {AI05-0248-1AI05-0248-1}
+{AI05-0298-1AI05-0298-1} The library function
+Strings.Unbounded.Equal_Case_Insensitive has the following declaration:
+
+10/3
+ function Ada.Strings.Unbounded.Equal_Case_Insensitive
+ (Left, Right : Unbounded_String) return Boolean;
+ pragma Preelaborate(Ada.Strings.Unbounded.Equal_Case_Insensitive);
+
+11/3
+ Equivalent to Strings.Equal_Case_Insensitive (To_String
+ (Left), To_String (Right));
+
+12/3
+{AI05-0001-1AI05-0001-1} {AI05-0298-1AI05-0298-1} The library function
+Strings.Less_Case_Insensitive has the following declaration:
+
+13/3
+ function Ada.Strings.Less_Case_Insensitive (Left, Right : String)
+ return Boolean;
+ pragma Pure(Ada.Strings.Less_Case_Insensitive);
+
+14/3
+ Performs a lexicographic comparison of strings Left and Right,
+ converted to lower case.
+
+15/3
+{AI05-0001-1AI05-0001-1} {AI05-0248-1AI05-0248-1}
+{AI05-0298-1AI05-0298-1} The library function
+Strings.Fixed.Less_Case_Insensitive has the following declaration:
+
+16/3
+ with Ada.Strings.Less_Case_Insensitive;
+ function Ada.Strings.Fixed.Less_Case_Insensitive
+ (Left, Right : String) return Boolean
+ renames Ada.Strings.Less_Case_Insensitive;
+
+17/3
+{AI05-0001-1AI05-0001-1} {AI05-0248-1AI05-0248-1}
+{AI05-0298-1AI05-0298-1} The generic library function
+Strings.Bounded.Less_Case_Insensitive has the following declaration:
+
+18/3
+ generic
+ with package Bounded is
+ new Ada.Strings.Bounded.Generic_Bounded_Length (<>);
+ function Ada.Strings.Bounded.Less_Case_Insensitive
+ (Left, Right : Bounded.Bounded_String) return Boolean;
+ pragma Preelaborate(Ada.Strings.Bounded.Less_Case_Insensitive);
+
+19/3
+ Equivalent to Strings.Less_Case_Insensitive (Bounded.To_String
+ (Left), Bounded.To_String (Right));
+
+20/3
+{AI05-0001-1AI05-0001-1} {AI05-0248-1AI05-0248-1}
+{AI05-0298-1AI05-0298-1} The library function
+Strings.Unbounded.Less_Case_Insensitive has the following declaration:
+
+21/3
+ function Ada.Strings.Unbounded.Less_Case_Insensitive
+ (Left, Right : Unbounded_String) return Boolean;
+ pragma Preelaborate(Ada.Strings.Unbounded.Less_Case_Insensitive);
+
+22/3
+ Equivalent to Strings.Less_Case_Insensitive (To_String (Left),
+ To_String (Right));
+
+ _Extensions to Ada 2005_
+
+22.a/3
+ {AI05-0001-1AI05-0001-1} {AI05-0286-1AI05-0286-1} The
+ Strings.Equal_Case_Insensitive,
+ Strings.Fixed.Equal_Case_Insensitive,
+ Strings.Bounded.Equal_Case_Insensitive,
+ Strings.Unbounded.Equal_Case_Insensitive,
+ Strings.Less_Case_Insensitive,
+ Strings.Fixed.Less_Case_Insensitive,
+ Strings.Bounded.Less_Case_Insensitive,
+ Strings.Unbounded.Less_Case_Insensitive functions are new.
+
+\1f
+File: aarm2012.info, Node: A.4.11, Prev: A.4.10, Up: A.4
+
+A.4.11 String Encoding
+----------------------
+
+1/3
+{AI05-0137-2AI05-0137-2} Facilities for encoding, decoding, and
+converting strings in various character encoding schemes are provided by
+packages Strings.UTF_Encoding, Strings.UTF_Encoding.Conversions,
+Strings.UTF_Encoding.Strings, Strings.UTF_Encoding.Wide_Strings, and
+Strings.UTF_Encoding.Wide_Wide_Strings.
+
+ _Static Semantics_
+
+2/3
+{AI05-0137-2AI05-0137-2} The encoding library packages have the
+following declarations:
+
+3/3
+ {AI05-0137-2AI05-0137-2} package Ada.Strings.UTF_Encoding is
+ pragma Pure (UTF_Encoding);
+
+4/3
+ -- Declarations common to the string encoding packages
+ type Encoding_Scheme is (UTF_8, UTF_16BE, UTF_16LE);
+
+5/3
+ subtype UTF_String is String;
+
+6/3
+ subtype UTF_8_String is String;
+
+7/3
+ subtype UTF_16_Wide_String is Wide_String;
+
+8/3
+ Encoding_Error : exception;
+
+9/3
+ BOM_8 : constant UTF_8_String :=
+ Character'Val(16#EF#) &
+ Character'Val(16#BB#) &
+ Character'Val(16#BF#);
+
+10/3
+ BOM_16BE : constant UTF_String :=
+ Character'Val(16#FE#) &
+ Character'Val(16#FF#);
+
+11/3
+ BOM_16LE : constant UTF_String :=
+ Character'Val(16#FF#) &
+ Character'Val(16#FE#);
+
+12/3
+ BOM_16 : constant UTF_16_Wide_String :=
+ (1 => Wide_Character'Val(16#FEFF#));
+
+13/3
+ function Encoding (Item : UTF_String;
+ Default : Encoding_Scheme := UTF_8)
+ return Encoding_Scheme;
+
+14/3
+ end Ada.Strings.UTF_Encoding;
+
+15/3
+ {AI05-0137-2AI05-0137-2} package Ada.Strings.UTF_Encoding.Conversions is
+ pragma Pure (Conversions);
+
+16/3
+ -- Conversions between various encoding schemes
+ function Convert (Item : UTF_String;
+ Input_Scheme : Encoding_Scheme;
+ Output_Scheme : Encoding_Scheme;
+ Output_BOM : Boolean := False) return UTF_String;
+
+17/3
+ function Convert (Item : UTF_String;
+ Input_Scheme : Encoding_Scheme;
+ Output_BOM : Boolean := False)
+ return UTF_16_Wide_String;
+
+18/3
+ function Convert (Item : UTF_8_String;
+ Output_BOM : Boolean := False)
+ return UTF_16_Wide_String;
+
+19/3
+ function Convert (Item : UTF_16_Wide_String;
+ Output_Scheme : Encoding_Scheme;
+ Output_BOM : Boolean := False) return UTF_String;
+
+20/3
+ function Convert (Item : UTF_16_Wide_String;
+ Output_BOM : Boolean := False) return UTF_8_String;
+
+21/3
+ end Ada.Strings.UTF_Encoding.Conversions;
+
+22/3
+ {AI05-0137-2AI05-0137-2} package Ada.Strings.UTF_Encoding.Strings is
+ pragma Pure (Strings);
+
+23/3
+ -- Encoding / decoding between String and various encoding schemes
+ function Encode (Item : String;
+ Output_Scheme : Encoding_Scheme;
+ Output_BOM : Boolean := False) return UTF_String;
+
+24/3
+ function Encode (Item : String;
+ Output_BOM : Boolean := False) return UTF_8_String;
+
+25/3
+ function Encode (Item : String;
+ Output_BOM : Boolean := False)
+ return UTF_16_Wide_String;
+
+26/3
+ function Decode (Item : UTF_String;
+ Input_Scheme : Encoding_Scheme) return String;
+
+27/3
+ function Decode (Item : UTF_8_String) return String;
+
+28/3
+ function Decode (Item : UTF_16_Wide_String) return String;
+
+29/3
+ end Ada.Strings.UTF_Encoding.Strings;
+
+30/3
+ {AI05-0137-2AI05-0137-2} package Ada.Strings.UTF_Encoding.Wide_Strings is
+ pragma Pure (Wide_Strings);
+
+31/3
+ -- Encoding / decoding between Wide_String and various encoding schemes
+ function Encode (Item : Wide_String;
+ Output_Scheme : Encoding_Scheme;
+ Output_BOM : Boolean := False) return UTF_String;
+
+32/3
+ function Encode (Item : Wide_String;
+ Output_BOM : Boolean := False) return UTF_8_String;
+
+33/3
+ function Encode (Item : Wide_String;
+ Output_BOM : Boolean := False)
+ return UTF_16_Wide_String;
+
+34/3
+ function Decode (Item : UTF_String;
+ Input_Scheme : Encoding_Scheme) return Wide_String;
+
+35/3
+ function Decode (Item : UTF_8_String) return Wide_String;
+
+36/3
+ function Decode (Item : UTF_16_Wide_String) return Wide_String;
+
+37/3
+ end Ada.Strings.UTF_Encoding.Wide_Strings;
+
+38/3
+ {AI05-0137-2AI05-0137-2} package Ada.Strings.UTF_Encoding.Wide_Wide_Strings is
+ pragma Pure (Wide_Wide_Strings);
+
+39/3
+ -- Encoding / decoding between Wide_Wide_String and various encoding schemes
+ function Encode (Item : Wide_Wide_String;
+ Output_Scheme : Encoding_Scheme;
+ Output_BOM : Boolean := False) return UTF_String;
+
+40/3
+ function Encode (Item : Wide_Wide_String;
+ Output_BOM : Boolean := False) return UTF_8_String;
+
+41/3
+ function Encode (Item : Wide_Wide_String;
+ Output_BOM : Boolean := False)
+ return UTF_16_Wide_String;
+
+42/3
+ function Decode (Item : UTF_String;
+ Input_Scheme : Encoding_Scheme) return Wide_Wide_String;
+
+43/3
+ function Decode (Item : UTF_8_String) return Wide_Wide_String;
+
+44/3
+ function Decode (Item : UTF_16_Wide_String) return Wide_Wide_String;
+
+45/3
+ end Ada.Strings.UTF_Encoding.Wide_Wide_Strings;
+
+46/3
+{AI05-0137-2AI05-0137-2} {AI05-0262-1AI05-0262-1} The type
+Encoding_Scheme defines encoding schemes. UTF_8 corresponds to the
+UTF-8 encoding scheme defined by Annex D of ISO/IEC 10646. UTF_16BE
+corresponds to the UTF-16 encoding scheme defined by Annex C of ISO/IEC
+10646 in 8 bit, big-endian order; and UTF_16LE corresponds to the UTF-16
+encoding scheme in 8 bit, little-endian order.
+
+47/3
+{AI05-0137-2AI05-0137-2} The subtype UTF_String is used to represent a
+String of 8-bit values containing a sequence of values encoded in one of
+three ways (UTF-8, UTF-16BE, or UTF-16LE). The subtype UTF_8_String is
+used to represent a String of 8-bit values containing a sequence of
+values encoded in UTF-8. The subtype UTF_16_Wide_String is used to
+represent a Wide_String of 16-bit values containing a sequence of values
+encoded in UTF-16.
+
+48/3
+{AI05-0137-2AI05-0137-2} {AI05-0262-1AI05-0262-1} The BOM_8, BOM_16BE,
+BOM_16LE, and BOM_16 constants correspond to values used at the start of
+a string to indicate the encoding.
+
+49/3
+{AI05-0262-1AI05-0262-1} {AI05-0269-1AI05-0269-1} Each of the Encode
+functions takes a String, Wide_String, or Wide_Wide_String Item
+parameter that is assumed to be an array of unencoded characters. Each
+of the Convert functions takes a UTF_String, UTF_8_String, or
+UTF_16_String Item parameter that is assumed to contain characters whose
+position values correspond to a valid encoding sequence according to the
+encoding scheme required by the function or specified by its
+Input_Scheme parameter.
+
+50/3
+{AI05-0137-2AI05-0137-2} {AI05-0262-1AI05-0262-1}
+{AI05-0269-1AI05-0269-1} Each of the Convert and Encode functions
+returns a UTF_String, UTF_8_String, or UTF_16_String value whose
+characters have position values that correspond to the encoding of the
+Item parameter according to the encoding scheme required by the function
+or specified by its Output_Scheme parameter. For UTF_8, no overlong
+encoding is returned. A BOM is included at the start of the returned
+string if the Output_BOM parameter is set to True. The lower bound of
+the returned string is 1.
+
+51/3
+{AI05-0137-2AI05-0137-2} {AI05-0262-1AI05-0262-1} Each of the Decode
+functions takes a UTF_String, UTF_8_String, or UTF_16_String Item
+parameter which is assumed to contain characters whose position values
+correspond to a valid encoding sequence according to the encoding scheme
+required by the function or specified by its Input_Scheme parameter, and
+returns the corresponding String, Wide_String, or Wide_Wide_String
+value. The lower bound of the returned string is 1.
+
+52/3
+{AI05-0137-2AI05-0137-2} {AI05-0262-1AI05-0262-1} For each of the
+Convert and Decode functions, an initial BOM in the input that matches
+the expected encoding scheme is ignored, and a different initial BOM
+causes Encoding_Error to be propagated.
+
+53/3
+{AI05-0137-2AI05-0137-2} The exception Encoding_Error is also propagated
+in the following situations:
+
+54/3
+ * By a Decode function when a UTF encoded string contains an invalid
+ encoding sequence.
+
+55/3
+ * By a Decode function when the expected encoding is UTF-16BE or
+ UTF-16LE and the input string has an odd length.
+
+56/3
+ * {AI05-0262-1AI05-0262-1} By a Decode function yielding a String
+ when the decoding of a sequence results in a code point whose value
+ exceeds 16#FF#.
+
+57/3
+ * By a Decode function yielding a Wide_String when the decoding of a
+ sequence results in a code point whose value exceeds 16#FFFF#.
+
+58/3
+ * {AI05-0262-1AI05-0262-1} By an Encode function taking a Wide_String
+ as input when an invalid character appears in the input. In
+ particular, the characters whose position is in the range 16#D800#
+ .. 16#DFFF# are invalid because they conflict with UTF-16
+ surrogate encodings, and the characters whose position is 16#FFFE#
+ or 16#FFFF# are also invalid because they conflict with BOM codes.
+
+59/3
+ {AI05-0137-2AI05-0137-2} function Encoding (Item : UTF_String;
+ Default : Encoding_Scheme := UTF_8)
+ return Encoding_Scheme;
+
+60/3
+ {AI05-0137-2AI05-0137-2} {AI05-0269-1AI05-0269-1} Inspects a
+ UTF_String value to determine whether it starts with a BOM for
+ UTF-8, UTF-16BE, or UTF_16LE. If so, returns the scheme
+ corresponding to the BOM; otherwise, returns the value of
+ Default.
+
+61/3
+ {AI05-0137-2AI05-0137-2} function Convert (Item : UTF_String;
+ Input_Scheme : Encoding_Scheme;
+ Output_Scheme : Encoding_Scheme;
+ Output_BOM : Boolean := False) return UTF_String;
+
+62/3
+ Returns the value of Item (originally encoded in UTF-8,
+ UTF-16LE, or UTF-16BE as specified by Input_Scheme) encoded in
+ one of these three schemes as specified by Output_Scheme.
+
+63/3
+ {AI05-0137-2AI05-0137-2} function Convert (Item : UTF_String;
+ Input_Scheme : Encoding_Scheme;
+ Output_BOM : Boolean := False)
+ return UTF_16_Wide_String;
+
+64/3
+ Returns the value of Item (originally encoded in UTF-8,
+ UTF-16LE, or UTF-16BE as specified by Input_Scheme) encoded in
+ UTF-16.
+
+65/3
+ {AI05-0137-2AI05-0137-2} function Convert (Item : UTF_8_String;
+ Output_BOM : Boolean := False)
+ return UTF_16_Wide_String;
+
+66/3
+ Returns the value of Item (originally encoded in UTF-8)
+ encoded in UTF-16.
+
+67/3
+ {AI05-0137-2AI05-0137-2} function Convert (Item : UTF_16_Wide_String;
+ Output_Scheme : Encoding_Scheme;
+ Output_BOM : Boolean := False) return UTF_String;
+
+68/3
+ Returns the value of Item (originally encoded in UTF-16)
+ encoded in UTF-8, UTF-16LE, or UTF-16BE as specified by
+ Output_Scheme.
+
+69/3
+ {AI05-0137-2AI05-0137-2} function Convert (Item : UTF_16_Wide_String;
+ Output_BOM : Boolean := False) return UTF_8_String;
+
+70/3
+ Returns the value of Item (originally encoded in UTF-16)
+ encoded in UTF-8.
+
+71/3
+ {AI05-0137-2AI05-0137-2} function Encode (Item : String;
+ Output_Scheme : Encoding_Scheme;
+ Output_BOM : Boolean := False) return UTF_String;
+
+72/3
+ {AI05-0262-1AI05-0262-1} Returns the value of Item encoded in
+ UTF-8, UTF-16LE, or UTF-16BE as specified by Output_Scheme.
+
+73/3
+ {AI05-0137-2AI05-0137-2} function Encode (Item : String;
+ Output_BOM : Boolean := False) return UTF_8_String;
+
+74/3
+ Returns the value of Item encoded in UTF-8.
+
+75/3
+ {AI05-0137-2AI05-0137-2} function Encode (Item : String;
+ Output_BOM : Boolean := False) return UTF_16_Wide_String;
+
+76/3
+ Returns the value of Item encoded in UTF_16.
+
+77/3
+ {AI05-0137-2AI05-0137-2} function Decode (Item : UTF_String;
+ Input_Scheme : Encoding_Scheme) return String;
+
+78/3
+ Returns the result of decoding Item, which is encoded in
+ UTF-8, UTF-16LE, or UTF-16BE as specified by Input_Scheme.
+
+79/3
+ {AI05-0137-2AI05-0137-2} function Decode (Item : UTF_8_String) return String;
+
+80/3
+ Returns the result of decoding Item, which is encoded in
+ UTF-8.
+
+81/3
+ {AI05-0137-2AI05-0137-2} function Decode (Item : UTF_16_Wide_String) return String;
+
+82/3
+ Returns the result of decoding Item, which is encoded in
+ UTF-16.
+
+83/3
+ {AI05-0137-2AI05-0137-2} function Encode (Item : Wide_String;
+ Output_Scheme : Encoding_Scheme;
+ Output_BOM : Boolean := False) return UTF_String;
+
+84/3
+ {AI05-0262-1AI05-0262-1} Returns the value of Item encoded in
+ UTF-8, UTF-16LE, or UTF-16BE as specified by Output_Scheme.
+
+85/3
+ {AI05-0137-2AI05-0137-2} function Encode (Item : Wide_String;
+ Output_BOM : Boolean := False) return UTF_8_String;
+
+86/3
+ Returns the value of Item encoded in UTF-8.
+
+87/3
+ {AI05-0137-2AI05-0137-2} function Encode (Item : Wide_String;
+ Output_BOM : Boolean := False) return UTF_16_Wide_String;
+
+88/3
+ Returns the value of Item encoded in UTF_16.
+
+89/3
+ {AI05-0137-2AI05-0137-2} function Decode (Item : UTF_String;
+ Input_Scheme : Encoding_Scheme) return Wide_String;
+
+90/3
+ Returns the result of decoding Item, which is encoded in
+ UTF-8, UTF-16LE, or UTF-16BE as specified by Input_Scheme.
+
+91/3
+ {AI05-0137-2AI05-0137-2} function Decode (Item : UTF_8_String) return Wide_String;
+
+92/3
+ Returns the result of decoding Item, which is encoded in
+ UTF-8.
+
+93/3
+ {AI05-0137-2AI05-0137-2} function Decode (Item : UTF_16_Wide_String) return Wide_String;
+
+94/3
+ Returns the result of decoding Item, which is encoded in
+ UTF-16.
+
+95/3
+ {AI05-0137-2AI05-0137-2} function Encode (Item : Wide_Wide_String;
+ Output_Scheme : Encoding_Scheme;
+ Output_BOM : Boolean := False) return UTF_String;
+
+96/3
+ {AI05-0262-1AI05-0262-1} Returns the value of Item encoded in
+ UTF-8, UTF-16LE, or UTF-16BE as specified by Output_Scheme.
+
+97/3
+ {AI05-0137-2AI05-0137-2} function Encode (Item : Wide_Wide_String;
+ Output_BOM : Boolean := False) return UTF_8_String;
+
+98/3
+ Returns the value of Item encoded in UTF-8.
+
+99/3
+ {AI05-0137-2AI05-0137-2} function Encode (Item : Wide_Wide_String;
+ Output_BOM : Boolean := False) return UTF_16_Wide_String;
+
+100/3
+ Returns the value of Item encoded in UTF_16.
+
+101/3
+ {AI05-0137-2AI05-0137-2} function Decode (Item : UTF_String;
+ Input_Scheme : Encoding_Scheme) return Wide_Wide_String;
+
+102/3
+ Returns the result of decoding Item, which is encoded in
+ UTF-8, UTF-16LE, or UTF-16BE as specified by Input_Scheme.
+
+103/3
+ {AI05-0137-2AI05-0137-2} function Decode (Item : UTF_8_String) return Wide_Wide_String;
+
+104/3
+ Returns the result of decoding Item, which is encoded in
+ UTF-8.
+
+105/3
+ {AI05-0137-2AI05-0137-2} function Decode (Item : UTF_16_Wide_String) return Wide_Wide_String;
+
+106/3
+ Returns the result of decoding Item, which is encoded in
+ UTF-16.
+
+ _Implementation Advice_
+
+107/3
+{AI05-0137-2AI05-0137-2} If an implementation supports other encoding
+schemes, another similar child of Ada.Strings should be defined.
+
+107.a.1/3
+ Implementation Advice: If an implementation supports other
+ string encoding schemes, a child of Ada.Strings similar to
+ UTF_Encoding should be defined.
+
+ NOTES
+
+108/3
+ 18 {AI05-0137-2AI05-0137-2} A BOM (Byte-Order Mark, code position
+ 16#FEFF#) can be included in a file or other entity to indicate the
+ encoding; it is skipped when decoding. Typically, only the first
+ line of a file or other entity contains a BOM. When decoding, the
+ Encoding function can be called on the first line to determine the
+ encoding; this encoding will then be used in subsequent calls to
+ Decode to convert all of the lines to an internal format.
+
+ _Extensions to Ada 2005_
+
+108.a/3
+ {AI05-0137-2AI05-0137-2} The packages Strings.UTF_Encoding,
+ Strings.UTF_Encoding.Conversions,
+ Strings.UTF_Encoding.Strings,
+ Strings.UTF_Encoding.Wide_Strings, and
+ Strings.UTF_Encoding.Wide_Wide_Strings are new.
+
+\1f
+File: aarm2012.info, Node: A.5, Next: A.6, Prev: A.4, Up: Annex A
+
+A.5 The Numerics Packages
+=========================
+
+1
+The library package Numerics is the parent of several child units that
+provide facilities for mathematical computation. One child, the generic
+package Generic_Elementary_Functions, is defined in *note A.5.1::,
+together with nongeneric equivalents; two others, the package
+Float_Random and the generic package Discrete_Random, are defined in
+*note A.5.2::. Additional (optional) children are defined in *note
+Annex G::, "*note Annex G:: Numerics".
+
+ _Static Semantics_
+
+2/1
+This paragraph was deleted.
+
+3/2
+ {AI95-00388-01AI95-00388-01} package Ada.Numerics is
+ pragma Pure(Numerics);
+ Argument_Error : exception;
+ Pi : constant :=
+ 3.14159_26535_89793_23846_26433_83279_50288_41971_69399_37511;
+ PI : constant := Pi;
+ e : constant :=
+ 2.71828_18284_59045_23536_02874_71352_66249_77572_47093_69996;
+ end Ada.Numerics;
+
+4
+The Argument_Error exception is raised by a subprogram in a child unit
+of Numerics to signal that one or more of the actual subprogram
+parameters are outside the domain of the corresponding mathematical
+function.
+
+ _Implementation Permissions_
+
+5
+The implementation may specify the values of Pi and e to a larger number
+of significant digits.
+
+5.a
+ Reason: 51 digits seem more than adequate for all present
+ computers; converted to binary, the values given above are
+ accurate to more than 160 bits. Nevertheless, the permission
+ allows implementations to accommodate unforeseen hardware
+ advances.
+
+ _Extensions to Ada 83_
+
+5.b
+ Numerics and its children were not predefined in Ada 83.
+
+ _Extensions to Ada 95_
+
+5.c/2
+ {AI95-00388-01AI95-00388-01} The alternative declaration of PI
+ is new.
+
+* Menu:
+
+* A.5.1 :: Elementary Functions
+* A.5.2 :: Random Number Generation
+* A.5.3 :: Attributes of Floating Point Types
+* A.5.4 :: Attributes of Fixed Point Types
+
+\1f
+File: aarm2012.info, Node: A.5.1, Next: A.5.2, Up: A.5
+
+A.5.1 Elementary Functions
+--------------------------
+
+1
+Implementation-defined approximations to the mathematical functions
+known as the "elementary functions" are provided by the subprograms in
+Numerics.Generic_Elementary_Functions. Nongeneric equivalents of this
+generic package for each of the predefined floating point types are also
+provided as children of Numerics.
+
+1.a
+ Implementation defined: The accuracy actually achieved by the
+ elementary functions.
+
+ _Static Semantics_
+
+2
+The generic library package Numerics.Generic_Elementary_Functions has
+the following declaration:
+
+3
+ generic
+ type Float_Type is digits <>;
+
+ package Ada.Numerics.Generic_Elementary_Functions is
+ pragma Pure(Generic_Elementary_Functions);
+
+4
+ function Sqrt (X : Float_Type'Base) return Float_Type'Base;
+ function Log (X : Float_Type'Base) return Float_Type'Base;
+ function Log (X, Base : Float_Type'Base) return Float_Type'Base;
+ function Exp (X : Float_Type'Base) return Float_Type'Base;
+ function "**" (Left, Right : Float_Type'Base) return Float_Type'Base;
+
+5
+ function Sin (X : Float_Type'Base) return Float_Type'Base;
+ function Sin (X, Cycle : Float_Type'Base) return Float_Type'Base;
+ function Cos (X : Float_Type'Base) return Float_Type'Base;
+ function Cos (X, Cycle : Float_Type'Base) return Float_Type'Base;
+ function Tan (X : Float_Type'Base) return Float_Type'Base;
+ function Tan (X, Cycle : Float_Type'Base) return Float_Type'Base;
+ function Cot (X : Float_Type'Base) return Float_Type'Base;
+ function Cot (X, Cycle : Float_Type'Base) return Float_Type'Base;
+
+6
+ function Arcsin (X : Float_Type'Base) return Float_Type'Base;
+ function Arcsin (X, Cycle : Float_Type'Base) return Float_Type'Base;
+ function Arccos (X : Float_Type'Base) return Float_Type'Base;
+ function Arccos (X, Cycle : Float_Type'Base) return Float_Type'Base;
+ function Arctan (Y : Float_Type'Base;
+ X : Float_Type'Base := 1.0)
+ return Float_Type'Base;
+ function Arctan (Y : Float_Type'Base;
+ X : Float_Type'Base := 1.0;
+ Cycle : Float_Type'Base) return Float_Type'Base;
+ function Arccot (X : Float_Type'Base;
+ Y : Float_Type'Base := 1.0)
+ return Float_Type'Base;
+ function Arccot (X : Float_Type'Base;
+ Y : Float_Type'Base := 1.0;
+ Cycle : Float_Type'Base) return Float_Type'Base;
+
+7
+ function Sinh (X : Float_Type'Base) return Float_Type'Base;
+ function Cosh (X : Float_Type'Base) return Float_Type'Base;
+ function Tanh (X : Float_Type'Base) return Float_Type'Base;
+ function Coth (X : Float_Type'Base) return Float_Type'Base;
+ function Arcsinh (X : Float_Type'Base) return Float_Type'Base;
+ function Arccosh (X : Float_Type'Base) return Float_Type'Base;
+ function Arctanh (X : Float_Type'Base) return Float_Type'Base;
+ function Arccoth (X : Float_Type'Base) return Float_Type'Base;
+
+8
+ end Ada.Numerics.Generic_Elementary_Functions;
+
+9/1
+{8652/00208652/0020} {AI95-00126-01AI95-00126-01} The library package
+Numerics.Elementary_Functions is declared pure and defines the same
+subprograms as Numerics.Generic_Elementary_Functions, except that the
+predefined type Float is systematically substituted for Float_Type'Base
+throughout. Nongeneric equivalents of
+Numerics.Generic_Elementary_Functions for each of the other predefined
+floating point types are defined similarly, with the names
+Numerics.Short_Elementary_Functions, Numerics.Long_Elementary_Functions,
+etc.
+
+9.a
+ Reason: The nongeneric equivalents are provided to allow the
+ programmer to construct simple mathematical applications
+ without being required to understand and use generics.
+
+10
+The functions have their usual mathematical meanings. When the Base
+parameter is specified, the Log function computes the logarithm to the
+given base; otherwise, it computes the natural logarithm. When the
+Cycle parameter is specified, the parameter X of the forward
+trigonometric functions (Sin, Cos, Tan, and Cot) and the results of the
+inverse trigonometric functions (Arcsin, Arccos, Arctan, and Arccot) are
+measured in units such that a full cycle of revolution has the given
+value; otherwise, they are measured in radians.
+
+11
+The computed results of the mathematically multivalued functions are
+rendered single-valued by the following conventions, which are meant to
+imply the principal branch:
+
+12
+ * The results of the Sqrt and Arccosh functions and that of the
+ exponentiation operator are nonnegative.
+
+13
+ * The result of the Arcsin function is in the quadrant containing the
+ point (1.0, x), where x is the value of the parameter X. This
+ quadrant is I or IV; thus, the range of the Arcsin function is
+ approximately -PI/2.0 to PI/2.0 (-Cycle/4.0 to Cycle/4.0, if the
+ parameter Cycle is specified).
+
+14
+ * The result of the Arccos function is in the quadrant containing the
+ point (x, 1.0), where x is the value of the parameter X. This
+ quadrant is I or II; thus, the Arccos function ranges from 0.0 to
+ approximately PI (Cycle/2.0, if the parameter Cycle is specified).
+
+15
+ * The results of the Arctan and Arccot functions are in the quadrant
+ containing the point (x, y), where x and y are the values of the
+ parameters X and Y, respectively. This may be any quadrant (I
+ through IV) when the parameter X (resp., Y) of Arctan (resp.,
+ Arccot) is specified, but it is restricted to quadrants I and IV
+ (resp., I and II) when that parameter is omitted. Thus, the range
+ when that parameter is specified is approximately -PI to PI
+ (-Cycle/2.0 to Cycle/2.0, if the parameter Cycle is specified);
+ when omitted, the range of Arctan (resp., Arccot) is that of Arcsin
+ (resp., Arccos), as given above. When the point (x, y) lies on the
+ negative x-axis, the result approximates
+
+16
+ * PI (resp., -PI) when the sign of the parameter Y is positive
+ (resp., negative), if Float_Type'Signed_Zeros is True;
+
+17
+ * PI, if Float_Type'Signed_Zeros is False.
+
+18
+(In the case of the inverse trigonometric functions, in which a result
+lying on or near one of the axes may not be exactly representable, the
+approximation inherent in computing the result may place it in an
+adjacent quadrant, close to but on the wrong side of the axis.)
+
+ _Dynamic Semantics_
+
+19
+The exception Numerics.Argument_Error is raised, signaling a parameter
+value outside the domain of the corresponding mathematical function, in
+the following cases:
+
+20
+ * by any forward or inverse trigonometric function with specified
+ cycle, when the value of the parameter Cycle is zero or negative;
+
+21
+ * by the Log function with specified base, when the value of the
+ parameter Base is zero, one, or negative;
+
+22
+ * by the Sqrt and Log functions, when the value of the parameter X is
+ negative;
+
+23
+ * by the exponentiation operator, when the value of the left operand
+ is negative or when both operands have the value zero;
+
+24
+ * by the Arcsin, Arccos, and Arctanh functions, when the absolute
+ value of the parameter X exceeds one;
+
+25
+ * by the Arctan and Arccot functions, when the parameters X and Y
+ both have the value zero;
+
+26
+ * by the Arccosh function, when the value of the parameter X is less
+ than one; and
+
+27
+ * by the Arccoth function, when the absolute value of the parameter X
+ is less than one.
+
+28
+The exception Constraint_Error is raised, signaling a pole of the
+mathematical function (analogous to dividing by zero), in the following
+cases, provided that Float_Type'Machine_Overflows is True:
+
+29
+ * by the Log, Cot, and Coth functions, when the value of the
+ parameter X is zero;
+
+30
+ * by the exponentiation operator, when the value of the left operand
+ is zero and the value of the exponent is negative;
+
+31
+ * by the Tan function with specified cycle, when the value of the
+ parameter X is an odd multiple of the quarter cycle;
+
+32
+ * by the Cot function with specified cycle, when the value of the
+ parameter X is zero or a multiple of the half cycle; and
+
+33
+ * by the Arctanh and Arccoth functions, when the absolute value of
+ the parameter X is one.
+
+34
+[Constraint_Error can also be raised when a finite result overflows (see
+*note G.2.4::); this may occur for parameter values sufficiently near
+poles, and, in the case of some of the functions, for parameter values
+with sufficiently large magnitudes.] When Float_Type'Machine_Overflows
+is False, the result at poles is unspecified.
+
+34.a
+ Reason: The purpose of raising Constraint_Error (rather than
+ Numerics.Argument_Error) at the poles of a function, when
+ Float_Type'Machine_Overflows is True, is to provide continuous
+ behavior as the actual parameters of the function approach the
+ pole and finally reach it.
+
+34.b
+ Discussion: It is anticipated that an Ada binding to IEC
+ 559:1989 will be developed in the future. As part of such a
+ binding, the Machine_Overflows attribute of a conformant
+ floating point type will be specified to yield False, which
+ will permit both the predefined arithmetic operations and
+ implementations of the elementary functions to deliver signed
+ infinities (and set the overflow flag defined by the binding)
+ instead of raising Constraint_Error in overflow situations,
+ when traps are disabled. Similarly, it is appropriate for the
+ elementary functions to deliver signed infinities (and set the
+ zero-divide flag defined by the binding) instead of raising
+ Constraint_Error at poles, when traps are disabled. Finally,
+ such a binding should also specify the behavior of the
+ elementary functions, when sensible, given parameters with
+ infinite values.
+
+35
+When one parameter of a function with multiple parameters represents a
+pole and another is outside the function's domain, the latter takes
+precedence (i.e., Numerics.Argument_Error is raised).
+
+ _Implementation Requirements_
+
+36
+In the implementation of Numerics.Generic_Elementary_Functions, the
+range of intermediate values allowed during the calculation of a final
+result shall not be affected by any range constraint of the subtype
+Float_Type.
+
+36.a
+ Implementation Note: Implementations of
+ Numerics.Generic_Elementary_Functions written in Ada should
+ therefore avoid declaring local variables of subtype
+ Float_Type; the subtype Float_Type'Base should be used
+ instead.
+
+37
+In the following cases, evaluation of an elementary function shall yield
+the prescribed result, provided that the preceding rules do not call for
+an exception to be raised:
+
+38
+ * When the parameter X has the value zero, the Sqrt, Sin, Arcsin,
+ Tan, Sinh, Arcsinh, Tanh, and Arctanh functions yield a result of
+ zero, and the Exp, Cos, and Cosh functions yield a result of one.
+
+39
+ * When the parameter X has the value one, the Sqrt function yields a
+ result of one, and the Log, Arccos, and Arccosh functions yield a
+ result of zero.
+
+40
+ * When the parameter Y has the value zero and the parameter X has a
+ positive value, the Arctan and Arccot functions yield a result of
+ zero.
+
+41
+ * The results of the Sin, Cos, Tan, and Cot functions with specified
+ cycle are exact when the mathematical result is zero; those of the
+ first two are also exact when the mathematical result is ± 1.0.
+
+42
+ * Exponentiation by a zero exponent yields the value one.
+ Exponentiation by a unit exponent yields the value of the left
+ operand. Exponentiation of the value one yields the value one.
+ Exponentiation of the value zero yields the value zero.
+
+43
+Other accuracy requirements for the elementary functions, which apply
+only in implementations conforming to the Numerics Annex, and then only
+in the "strict" mode defined there (see *note G.2::), are given in *note
+G.2.4::.
+
+44
+When Float_Type'Signed_Zeros is True, the sign of a zero result shall be
+as follows:
+
+45
+ * A prescribed zero result delivered at the origin by one of the odd
+ functions (Sin, Arcsin, Sinh, Arcsinh, Tan, Arctan or Arccot as a
+ function of Y when X is fixed and positive, Tanh, and Arctanh) has
+ the sign of the parameter X (Y, in the case of Arctan or Arccot).
+
+46
+ * A prescribed zero result delivered by one of the odd functions away
+ from the origin, or by some other elementary function, has an
+ implementation-defined sign.
+
+46.a
+ Implementation defined: The sign of a zero result from some of
+ the operators or functions in
+ Numerics.Generic_Elementary_Functions, when
+ Float_Type'Signed_Zeros is True.
+
+47
+ * [A zero result that is not a prescribed result (i.e., one that
+ results from rounding or underflow) has the correct mathematical
+ sign.]
+
+47.a
+ Reason: This is a consequence of the rules specified in IEC
+ 559:1989 as they apply to underflow situations with traps
+ disabled.
+
+ _Implementation Permissions_
+
+48
+The nongeneric equivalent packages may, but need not, be actual
+instantiations of the generic package for the appropriate predefined
+type.
+
+ _Wording Changes from Ada 83_
+
+48.a
+ The semantics of Numerics.Generic_Elementary_Functions differs
+ from Generic_Elementary_Functions as defined in ISO/IEC DIS
+ 11430 (for Ada 83) in the following ways:
+
+48.b
+ * The generic package is a child unit of the package
+ defining the Argument_Error exception.
+
+48.c
+ * DIS 11430 specified names for the nongeneric equivalents,
+ if provided. Here, those nongeneric equivalents are
+ required.
+
+48.d
+ * Implementations are not allowed to impose an optional
+ restriction that the generic actual parameter associated
+ with Float_Type be unconstrained. (In view of the
+ ability to declare variables of subtype Float_Type'Base
+ in implementations of
+ Numerics.Generic_Elementary_Functions, this flexibility
+ is no longer needed.)
+
+48.e
+ * The sign of a prescribed zero result at the origin of the
+ odd functions is specified, when Float_Type'Signed_Zeros
+ is True. This conforms with recommendations of Kahan and
+ other numerical analysts.
+
+48.f
+ * The dependence of Arctan and Arccot on the sign of a
+ parameter value of zero is tied to the value of
+ Float_Type'Signed_Zeros.
+
+48.g
+ * Sqrt is prescribed to yield a result of one when its
+ parameter has the value one. This guarantee makes it
+ easier to achieve certain prescribed results of the
+ complex elementary functions (see *note G.1.2::, "*note
+ G.1.2:: Complex Elementary Functions").
+
+48.h
+ * Conformance to accuracy requirements is conditional.
+
+ _Wording Changes from Ada 95_
+
+48.i/2
+ {8652/00208652/0020} {AI95-00126-01AI95-00126-01} Corrigendum:
+ Explicitly stated that the nongeneric equivalents of
+ Generic_Elementary_Functions are pure.
+
+\1f
+File: aarm2012.info, Node: A.5.2, Next: A.5.3, Prev: A.5.1, Up: A.5
+
+A.5.2 Random Number Generation
+------------------------------
+
+1
+[Facilities for the generation of pseudo-random floating point numbers
+are provided in the package Numerics.Float_Random; the generic package
+Numerics.Discrete_Random provides similar facilities for the generation
+of pseudo-random integers and pseudo-random values of enumeration types.
+For brevity, pseudo-random values of any of these types are called
+random numbers.
+
+2
+Some of the facilities provided are basic to all applications of random
+numbers. These include a limited private type each of whose objects
+serves as the generator of a (possibly distinct) sequence of random
+numbers; a function to obtain the "next" random number from a given
+sequence of random numbers (that is, from its generator); and
+subprograms to initialize or reinitialize a given generator to a
+time-dependent state or a state denoted by a single integer.
+
+3
+Other facilities are provided specifically for advanced applications.
+These include subprograms to save and restore the state of a given
+generator; a private type whose objects can be used to hold the saved
+state of a generator; and subprograms to obtain a string representation
+of a given generator state, or, given such a string representation, the
+corresponding state.]
+
+3.a
+ Discussion: These facilities support a variety of requirements
+ ranging from repeatable sequences (for debugging) to unique
+ sequences in each execution of a program.
+
+ _Static Semantics_
+
+4
+The library package Numerics.Float_Random has the following declaration:
+
+5
+ package Ada.Numerics.Float_Random is
+
+6
+ -- Basic facilities
+
+7
+ type Generator is limited private;
+
+8
+ subtype Uniformly_Distributed is Float range 0.0 .. 1.0;
+ function Random (Gen : Generator) return Uniformly_Distributed;
+
+9
+ procedure Reset (Gen : in Generator;
+ Initiator : in Integer);
+ procedure Reset (Gen : in Generator);
+
+10
+ -- Advanced facilities
+
+11
+ type State is private;
+
+12
+ procedure Save (Gen : in Generator;
+ To_State : out State);
+ procedure Reset (Gen : in Generator;
+ From_State : in State);
+
+13
+ Max_Image_Width : constant := implementation-defined integer value;
+
+14
+ function Image (Of_State : State) return String;
+ function Value (Coded_State : String) return State;
+
+15
+ private
+ ... -- not specified by the language
+ end Ada.Numerics.Float_Random;
+
+15.1/2
+{AI95-00360-01AI95-00360-01} The type Generator needs finalization (see
+*note 7.6::).
+
+16
+The generic library package Numerics.Discrete_Random has the following
+declaration:
+
+17
+
+ generic
+ type Result_Subtype is (<>);
+ package Ada.Numerics.Discrete_Random is
+
+18
+ -- Basic facilities
+
+19
+ type Generator is limited private;
+
+20
+ function Random (Gen : Generator) return Result_Subtype;
+
+21
+ procedure Reset (Gen : in Generator;
+ Initiator : in Integer);
+ procedure Reset (Gen : in Generator);
+
+22
+ -- Advanced facilities
+
+23
+ type State is private;
+
+24
+ procedure Save (Gen : in Generator;
+ To_State : out State);
+ procedure Reset (Gen : in Generator;
+ From_State : in State);
+
+25
+ Max_Image_Width : constant := implementation-defined integer value;
+
+26
+ function Image (Of_State : State) return String;
+ function Value (Coded_State : String) return State;
+
+27
+ private
+ ... -- not specified by the language
+ end Ada.Numerics.Discrete_Random;
+
+27.a
+ Implementation defined: The value of
+ Numerics.Float_Random.Max_Image_Width.
+
+27.b
+ Implementation defined: The value of
+ Numerics.Discrete_Random.Max_Image_Width.
+
+27.c/1
+ Implementation Note: {8652/00978652/0097}
+ {AI95-00115-01AI95-00115-01} The following is a possible
+ implementation of the private part of Numerics.Float_Random
+ (assuming the presence of "with Ada.Finalization;" as a
+ context clause):
+
+27.d
+ type State is ...;
+ type Access_State is access State;
+ type Generator is new Finalization.Limited_Controlled with
+ record
+ S : Access_State := new State'(...);
+ end record;
+ procedure Finalize (G : in out Generator);
+
+27.d.1/2
+ {8652/00978652/0097} {AI95-00115-01AI95-00115-01}
+ {AI95-00344-01AI95-00344-01}
+ Numerics.Discrete_Random.Generator also can be implemented
+ this way.
+
+27.e
+ Clearly some level of indirection is required in the
+ implementation of a Generator, since the parameter mode is in
+ for all operations on a Generator. For this reason,
+ Numerics.Float_Random and Numerics.Discrete_Random cannot be
+ declared pure.
+
+27.1/2
+{AI95-00360-01AI95-00360-01} The type Generator needs finalization (see
+*note 7.6::) in every instantiation of Numerics.Discrete_Random.
+
+28
+An object of the limited private type Generator is associated with a
+sequence of random numbers. Each generator has a hidden (internal)
+state, which the operations on generators use to determine the position
+in the associated sequence. All generators are implicitly initialized
+to an unspecified state that does not vary from one program execution to
+another; they may also be explicitly initialized, or reinitialized, to a
+time-dependent state, to a previously saved state, or to a state
+uniquely denoted by an integer value.
+
+28.a
+ Discussion: The repeatability provided by the implicit
+ initialization may be exploited for testing or debugging
+ purposes.
+
+29/3
+{AI05-0280-1AI05-0280-1} An object of the private type State can be used
+to hold the internal state of a generator. Such objects are only needed
+if the application is designed to save and restore generator states or
+to examine or manufacture them. The implicit initial value of type
+State corresponds to the implicit initial value of all generators.
+
+29.a/3
+ Discussion: {AI05-0280-1AI05-0280-1} All generators are
+ implicitly initialized to the same unchanging value, and using
+ Reset on a default initialized object of type State will
+ produce a generator with that same value.
+
+30
+The operations on generators affect the state and therefore the future
+values of the associated sequence. The semantics of the operations on
+generators and states are defined below.
+
+31
+ function Random (Gen : Generator) return Uniformly_Distributed;
+ function Random (Gen : Generator) return Result_Subtype;
+
+32
+ Obtains the "next" random number from the given generator,
+ relative to its current state, according to an
+ implementation-defined algorithm. The result of the function
+ in Numerics.Float_Random is delivered as a value of the
+ subtype Uniformly_Distributed, which is a subtype of the
+ predefined type Float having a range of 0.0 .. 1.0. The
+ result of the function in an instantiation of
+ Numerics.Discrete_Random is delivered as a value of the
+ generic formal subtype Result_Subtype.
+
+32.a/2
+ This paragraph was deleted.
+
+32.a.1/2
+ Discussion: The algorithm is the subject of a Documentation
+ Requirement, so we don't separately summarize this
+ implementation-defined item.
+
+32.b
+ Reason: The requirement for a level of indirection in
+ accessing the internal state of a generator arises from the
+ desire to make Random a function, rather than a procedure.
+
+33
+ procedure Reset (Gen : in Generator;
+ Initiator : in Integer);
+ procedure Reset (Gen : in Generator);
+
+34
+ Sets the state of the specified generator to one that is an
+ unspecified function of the value of the parameter Initiator
+ (or to a time-dependent state, if only a generator parameter
+ is specified). The latter form of the procedure is known as
+ the time-dependent Reset procedure.
+
+34.a
+ Implementation Note: The time-dependent Reset procedure can be
+ implemented by mapping the current time and date as determined
+ by the system clock into a state, but other implementations
+ are possible. For example, a white-noise generator or a
+ radioactive source can be used to generate time-dependent
+ states.
+
+35
+ procedure Save (Gen : in Generator;
+ To_State : out State);
+ procedure Reset (Gen : in Generator;
+ From_State : in State);
+
+36
+ Save obtains the current state of a generator. Reset gives a
+ generator the specified state. A generator that is reset to a
+ state previously obtained by invoking Save is restored to the
+ state it had when Save was invoked.
+
+37
+ function Image (Of_State : State) return String;
+ function Value (Coded_State : String) return State;
+
+38
+ Image provides a representation of a state coded (in an
+ implementation-defined way) as a string whose length is
+ bounded by the value of Max_Image_Width. Value is the inverse
+ of Image: Value(Image(S)) = S for each state S that can be
+ obtained from a generator by invoking Save.
+
+38.a
+ Implementation defined: The string representation of a random
+ number generator's state.
+
+ _Dynamic Semantics_
+
+39
+Instantiation of Numerics.Discrete_Random with a subtype having a null
+range raises Constraint_Error.
+
+40/1
+This paragraph was deleted.{8652/00508652/0050} {AI95-00089AI95-00089}
+
+ _Bounded (Run-Time) Errors_
+
+40.1/1
+{8652/00508652/0050} {AI95-00089AI95-00089} It is a bounded error to
+invoke Value with a string that is not the image of any generator state.
+If the error is detected, Constraint_Error or Program_Error is raised.
+Otherwise, a call to Reset with the resulting state will produce a
+generator such that calls to Random with this generator will produce a
+sequence of values of the appropriate subtype, but which might not be
+random in character. That is, the sequence of values might not fulfill
+the implementation requirements of this subclause.
+
+ _Implementation Requirements_
+
+41
+A sufficiently long sequence of random numbers obtained by successive
+calls to Random is approximately uniformly distributed over the range of
+the result subtype.
+
+42
+The Random function in an instantiation of Numerics.Discrete_Random is
+guaranteed to yield each value in its result subtype in a finite number
+of calls, provided that the number of such values does not exceed 2 15.
+
+43
+Other performance requirements for the random number generator, which
+apply only in implementations conforming to the Numerics Annex, and then
+only in the "strict" mode defined there (see *note G.2::), are given in
+*note G.2.5::.
+
+ _Documentation Requirements_
+
+44
+No one algorithm for random number generation is best for all
+applications. To enable the user to determine the suitability of the
+random number generators for the intended application, the
+implementation shall describe the algorithm used and shall give its
+period, if known exactly, or a lower bound on the period, if the exact
+period is unknown. Periods that are so long that the periodicity is
+unobservable in practice can be described in such terms, without giving
+a numerical bound.
+
+44.a/2
+ Documentation Requirement: The algorithm used for random
+ number generation, including a description of its period.
+
+45
+The implementation also shall document the minimum time interval between
+calls to the time-dependent Reset procedure that are guaranteed to
+initiate different sequences, and it shall document the nature of the
+strings that Value will accept without raising Constraint_Error.
+
+45.a/2
+ This paragraph was deleted.
+
+45.b/2
+ Documentation Requirement: The minimum time interval between
+ calls to the time-dependent Reset procedure that is guaranteed
+ to initiate different random number sequences.
+
+ _Implementation Advice_
+
+46
+Any storage associated with an object of type Generator should be
+reclaimed on exit from the scope of the object.
+
+46.a.1/2
+ Implementation Advice: Any storage associated with an object
+ of type Generator of the random number packages should be
+ reclaimed on exit from the scope of the object.
+
+46.a
+ Ramification: A level of indirection is implicit in the
+ semantics of the operations, given that they all take
+ parameters of mode in. This implies that the full type of
+ Generator probably should be a controlled type, with
+ appropriate finalization to reclaim any heap-allocated
+ storage.
+
+47
+If the generator period is sufficiently long in relation to the number
+of distinct initiator values, then each possible value of Initiator
+passed to Reset should initiate a sequence of random numbers that does
+not, in a practical sense, overlap the sequence initiated by any other
+value. If this is not possible, then the mapping between initiator
+values and generator states should be a rapidly varying function of the
+initiator value.
+
+47.a/2
+ Implementation Advice: Each value of Initiator passed to Reset
+ for the random number packages should initiate a distinct
+ sequence of random numbers, or, if that is not possible, be at
+ least a rapidly varying function of the initiator value.
+
+ NOTES
+
+48
+ 19 If two or more tasks are to share the same generator, then the
+ tasks have to synchronize their access to the generator as for any
+ shared variable (see *note 9.10::).
+
+49
+ 20 Within a given implementation, a repeatable random number
+ sequence can be obtained by relying on the implicit initialization
+ of generators or by explicitly initializing a generator with a
+ repeatable initiator value. Different sequences of random numbers
+ can be obtained from a given generator in different program
+ executions by explicitly initializing the generator to a
+ time-dependent state.
+
+50
+ 21 A given implementation of the Random function in
+ Numerics.Float_Random may or may not be capable of delivering the
+ values 0.0 or 1.0. Portable applications should assume that these
+ values, or values sufficiently close to them to behave
+ indistinguishably from them, can occur. If a sequence of random
+ integers from some fixed range is needed, the application should
+ use the Random function in an appropriate instantiation of
+ Numerics.Discrete_Random, rather than transforming the result of
+ the Random function in Numerics.Float_Random. However, some
+ applications with unusual requirements, such as for a sequence of
+ random integers each drawn from a different range, will find it
+ more convenient to transform the result of the floating point
+ Random function. For M >= 1, the expression
+
+51
+ Integer(Float(M) * Random(G)) mod M
+
+52
+ transforms the result of Random(G) to an integer uniformly
+ distributed over the range 0 .. M-1; it is valid even if Random
+ delivers 0.0 or 1.0. Each value of the result range is possible,
+ provided that M is not too large. Exponentially distributed
+ (floating point) random numbers with mean and standard deviation
+ 1.0 can be obtained by the transformation
+
+53/2
+ {AI95-00434-01AI95-00434-01} -Log(Random(G) + Float'Model_Small)
+
+54
+ where Log comes from Numerics.Elementary_Functions (see *note
+ A.5.1::); in this expression, the addition of Float'Model_Small
+ avoids the exception that would be raised were Log to be given the
+ value zero, without affecting the result (in most implementations)
+ when Random returns a nonzero value.
+
+ _Examples_
+
+55
+Example of a program that plays a simulated dice game:
+
+56
+ with Ada.Numerics.Discrete_Random;
+ procedure Dice_Game is
+ subtype Die is Integer range 1 .. 6;
+ subtype Dice is Integer range 2*Die'First .. 2*Die'Last;
+ package Random_Die is new Ada.Numerics.Discrete_Random (Die);
+ use Random_Die;
+ G : Generator;
+ D : Dice;
+ begin
+ Reset (G); -- Start the generator in a unique state in each run
+ loop
+ -- Roll a pair of dice; sum and process the results
+ D := Random(G) + Random(G);
+ ...
+ end loop;
+ end Dice_Game;
+
+57
+Example of a program that simulates coin tosses:
+
+58
+ with Ada.Numerics.Discrete_Random;
+ procedure Flip_A_Coin is
+ type Coin is (Heads, Tails);
+ package Random_Coin is new Ada.Numerics.Discrete_Random (Coin);
+ use Random_Coin;
+ G : Generator;
+ begin
+ Reset (G); -- Start the generator in a unique state in each run
+ loop
+ -- Toss a coin and process the result
+ case Random(G) is
+ when Heads =>
+ ...
+ when Tails =>
+ ...
+ end case;
+ ...
+ end loop;
+ end Flip_A_Coin;
+
+59
+Example of a parallel simulation of a physical system, with a separate
+generator of event probabilities in each task:
+
+60
+ with Ada.Numerics.Float_Random;
+ procedure Parallel_Simulation is
+ use Ada.Numerics.Float_Random;
+ task type Worker is
+ entry Initialize_Generator (Initiator : in Integer);
+ ...
+ end Worker;
+ W : array (1 .. 10) of Worker;
+ task body Worker is
+ G : Generator;
+ Probability_Of_Event : Uniformly_Distributed;
+ begin
+ accept Initialize_Generator (Initiator : in Integer) do
+ Reset (G, Initiator);
+ end Initialize_Generator;
+ loop
+ ...
+ Probability_Of_Event := Random(G);
+ ...
+ end loop;
+ end Worker;
+ begin
+ -- Initialize the generators in the Worker tasks to different states
+ for I in W'Range loop
+ W(I).Initialize_Generator (I);
+ end loop;
+ ... -- Wait for the Worker tasks to terminate
+ end Parallel_Simulation;
+
+ NOTES
+
+61
+ 22 Notes on the last example: Although each Worker task
+ initializes its generator to a different state, those states will
+ be the same in every execution of the program. The generator
+ states can be initialized uniquely in each program execution by
+ instantiating Ada.Numerics.Discrete_Random for the type Integer in
+ the main procedure, resetting the generator obtained from that
+ instance to a time-dependent state, and then using random integers
+ obtained from that generator to initialize the generators in each
+ Worker task.
+
+ _Incompatibilities With Ada 95_
+
+61.a/2
+ {AI95-00360-01AI95-00360-01} Amendment Correction: Type
+ Generator in Numerics.Float_Random and in an instance of
+ Numerics.Discrete_Random is defined to need finalization. If
+ the restriction No_Nested_Finalization (see *note D.7::)
+ applies to the partition, and Generator does not have a
+ controlled part, it will not be allowed in local objects in
+ Ada 2005 whereas it would be allowed in original Ada 95. Such
+ code is not portable, as another Ada compiler may have a
+ controlled part in Generator, and thus would be illegal.
+
+ _Wording Changes from Ada 95_
+
+61.b/3
+ {8652/00508652/0050} {AI95-00089-01AI95-00089-01}
+ {AI05-0005-1AI05-0005-1} Corrigendum: Made the passing of an
+ incorrect Image of a generator a bounded error, as it might
+ not be practical to check for problems (if a generator
+ consists of several related values).
+
+ _Wording Changes from Ada 2005_
+
+61.c/3
+ {AI05-0280-1AI05-0280-1} Correction: Specified the implicit
+ initial value for (sub)type State. This was unspecified in
+ Ada 95 and Ada 2005, so a program depending on some other
+ initial value is very unlikely and certainly was not portable.
+ An implementation can use default expressions, aspect
+ Default_Value, or aspect Default_Component_Value to keep the
+ representation of the type unchanged while meeting this new
+ requirement.
+
+\1f
+File: aarm2012.info, Node: A.5.3, Next: A.5.4, Prev: A.5.2, Up: A.5
+
+A.5.3 Attributes of Floating Point Types
+----------------------------------------
+
+ _Static Semantics_
+
+1
+The following representation-oriented attributes are defined for every
+subtype S of a floating point type T.
+
+2
+S'Machine_Radix
+ Yields the radix of the hardware representation of the
+ type T. The value of this attribute is of the type
+ universal_integer.
+
+3
+The values of other representation-oriented attributes of a floating
+point subtype, and of the "primitive function" attributes of a floating
+point subtype described later, are defined in terms of a particular
+representation of nonzero values called the canonical form. The
+canonical form (for the type T) is the form
+ ± mantissa · T'Machine_Radixexponent
+where
+
+4
+ * mantissa is a fraction in the number base T'Machine_Radix, the
+ first digit of which is nonzero, and
+
+5
+ * exponent is an integer.
+
+6
+S'Machine_Mantissa
+ Yields the largest value of p such that every value
+ expressible in the canonical form (for the type T),
+ having a p-digit mantissa and an exponent between
+ T'Machine_Emin and T'Machine_Emax, is a machine number
+ (see *note 3.5.7::) of the type T. This attribute yields
+ a value of the type universal_integer.
+
+6.a
+ Ramification: Values of a type held in an extended register
+ are, in general, not machine numbers of the type, since they
+ cannot be expressed in the canonical form with a sufficiently
+ short mantissa.
+
+7
+S'Machine_Emin
+ Yields the smallest (most negative) value of exponent
+ such that every value expressible in the canonical form
+ (for the type T), having a mantissa of T'Machine_Mantissa
+ digits, is a machine number (see *note 3.5.7::) of the
+ type T. This attribute yields a value of the type
+ universal_integer.
+
+8
+S'Machine_Emax
+ Yields the largest (most positive) value of exponent such
+ that every value expressible in the canonical form (for
+ the type T), having a mantissa of T'Machine_Mantissa
+ digits, is a machine number (see *note 3.5.7::) of the
+ type T. This attribute yields a value of the type
+ universal_integer.
+
+8.a
+ Ramification: Note that the above definitions do not determine
+ unique values for the representation-oriented attributes of
+ floating point types. The implementation may choose any set
+ of values that collectively satisfies the definitions.
+
+9
+S'Denorm
+ Yields the value True if every value expressible in the
+ form
+ ± mantissa · T'Machine_RadixT'Machine_Emin
+ where mantissa is a nonzero T'Machine_Mantissa-digit
+ fraction in the number base T'Machine_Radix, the first
+ digit of which is zero, is a machine number (see *note
+ 3.5.7::) of the type T; yields the value False otherwise.
+ The value of this attribute is of the predefined type
+ Boolean.
+
+10
+The values described by the formula in the definition of S'Denorm are
+called denormalized numbers. A nonzero machine number that is not a
+denormalized number is a normalized number. A normalized number x of a
+given type T is said to be represented in canonical form when it is
+expressed in the canonical form (for the type T) with a mantissa having
+T'Machine_Mantissa digits; the resulting form is the canonical-form
+representation of x.
+
+10.a
+ Discussion: The intent is that S'Denorm be True when such
+ denormalized numbers exist and are generated in the
+ circumstances defined by IEC 559:1989, though the latter
+ requirement is not formalized here.
+
+11
+S'Machine_Rounds
+ Yields the value True if rounding is performed on inexact
+ results of every predefined operation that yields a
+ result of the type T; yields the value False otherwise.
+ The value of this attribute is of the predefined type
+ Boolean.
+
+11.a
+ Discussion: It is difficult to be more precise about what it
+ means to round the result of a predefined operation. If the
+ implementation does not use extended registers, so that every
+ arithmetic result is necessarily a machine number, then
+ rounding seems to imply two things:
+
+11.b
+ * S'Model_Mantissa = S'Machine_Mantissa, so that operand
+ preperturbation never occurs;
+
+11.c
+ * when the exact mathematical result is not a machine
+ number, the result of a predefined operation must be the
+ nearer of the two adjacent machine numbers.
+
+11.d
+ Technically, this attribute should yield False when extended
+ registers are used, since a few computed results will cross
+ over the half-way point as a result of double rounding, if and
+ when a value held in an extended register has to be reduced in
+ precision to that of the machine numbers. It does not seem
+ desirable to preclude the use of extended registers when
+ S'Machine_Rounds could otherwise be True.
+
+12
+S'Machine_Overflows
+ Yields the value True if overflow and divide-by-zero are
+ detected and reported by raising Constraint_Error for
+ every predefined operation that yields a result of the
+ type T; yields the value False otherwise. The value of
+ this attribute is of the predefined type Boolean.
+
+13
+S'Signed_Zeros
+ Yields the value True if the hardware representation for
+ the type T has the capability of representing both
+ positively and negatively signed zeros, these being
+ generated and used by the predefined operations of the
+ type T as specified in IEC 559:1989; yields the value
+ False otherwise. The value of this attribute is of the
+ predefined type Boolean.
+
+14
+For every value x of a floating point type T, the normalized exponent of
+x is defined as follows:
+
+15
+ * the normalized exponent of zero is (by convention) zero;
+
+16
+ * for nonzero x, the normalized exponent of x is the unique integer k
+ such that T'Machine_Radixk-1 <= |x| < T'Machine_Radixk.
+
+16.a
+ Ramification: The normalized exponent of a normalized number x
+ is the value of exponent in the canonical-form representation
+ of x.
+
+16.b
+ The normalized exponent of a denormalized number is less than
+ the value of T'Machine_Emin.
+
+17
+The following primitive function attributes are defined for any subtype
+S of a floating point type T.
+
+18
+S'Exponent
+ S'Exponent denotes a function with the following
+ specification:
+
+19
+ function S'Exponent (X : T)
+ return universal_integer
+
+20
+ The function yields the normalized exponent of X.
+
+21
+S'Fraction
+ S'Fraction denotes a function with the following
+ specification:
+
+22
+ function S'Fraction (X : T)
+ return T
+
+23
+ The function yields the value X · T'Machine_Radix-k,
+ where k is the normalized exponent of X. A zero result[,
+ which can only occur when X is zero,] has the sign of X.
+
+23.a
+ Discussion: Informally, when X is a normalized number, the
+ result is the value obtained by replacing the exponent by zero
+ in the canonical-form representation of X.
+
+23.b
+ Ramification: Except when X is zero, the magnitude of the
+ result is greater than or equal to the reciprocal of
+ T'Machine_Radix and less than one; consequently, the result is
+ always a normalized number, even when X is a denormalized
+ number.
+
+23.c
+ Implementation Note: When X is a denormalized number, the
+ result is the value obtained by replacing the exponent by zero
+ in the canonical-form representation of the result of scaling
+ X up sufficiently to normalize it.
+
+24
+S'Compose
+ S'Compose denotes a function with the following
+ specification:
+
+25
+ function S'Compose (Fraction : T;
+ Exponent : universal_integer)
+ return T
+
+26
+ Let v be the value Fraction · T'Machine_RadixExponent-k,
+ where k is the normalized exponent of Fraction. If v is
+ a machine number of the type T, or if |v| >=
+ T'Model_Small, the function yields v; otherwise, it
+ yields either one of the machine numbers of the type T
+ adjacent to v. Constraint_Error is optionally raised if
+ v is outside the base range of S. A zero result has the
+ sign of Fraction when S'Signed_Zeros is True.
+
+26.a
+ Discussion: Informally, when Fraction and v are both
+ normalized numbers, the result is the value obtained by
+ replacing the exponent by Exponent in the canonical-form
+ representation of Fraction.
+
+26.b
+ Ramification: If Exponent is less than T'Machine_Emin and
+ Fraction is nonzero, the result is either zero, T'Model_Small,
+ or (if T'Denorm is True) a denormalized number.
+
+27
+S'Scaling
+ S'Scaling denotes a function with the following
+ specification:
+
+28
+ function S'Scaling (X : T;
+ Adjustment : universal_integer)
+ return T
+
+29
+ Let v be the value X · T'Machine_RadixAdjustment. If v
+ is a machine number of the type T, or if |v| >=
+ T'Model_Small, the function yields v; otherwise, it
+ yields either one of the machine numbers of the type T
+ adjacent to v. Constraint_Error is optionally raised if
+ v is outside the base range of S. A zero result has the
+ sign of X when S'Signed_Zeros is True.
+
+29.a
+ Discussion: Informally, when X and v are both normalized
+ numbers, the result is the value obtained by increasing the
+ exponent by Adjustment in the canonical-form representation of
+ X.
+
+29.b
+ Ramification: If Adjustment is sufficiently small (i.e.,
+ sufficiently negative), the result is either zero,
+ T'Model_Small, or (if T'Denorm is True) a denormalized number.
+
+30
+S'Floor
+ S'Floor denotes a function with the following
+ specification:
+
+31
+ function S'Floor (X : T)
+ return T
+
+32
+ The function yields the value 'floor(X)', i.e., the
+ largest (most positive) integral value less than or equal
+ to X. When X is zero, the result has the sign of X; a
+ zero result otherwise has a positive sign.
+
+33
+S'Ceiling
+ S'Ceiling denotes a function with the following
+ specification:
+
+34
+ function S'Ceiling (X : T)
+ return T
+
+35
+ The function yields the value 'ceiling(X)', i.e., the
+ smallest (most negative) integral value greater than or
+ equal to X. When X is zero, the result has the sign of X;
+ a zero result otherwise has a negative sign when
+ S'Signed_Zeros is True.
+
+36
+S'Rounding
+ S'Rounding denotes a function with the following
+ specification:
+
+37
+ function S'Rounding (X : T)
+ return T
+
+38
+ The function yields the integral value nearest to X,
+ rounding away from zero if X lies exactly halfway between
+ two integers. A zero result has the sign of X when
+ S'Signed_Zeros is True.
+
+39
+S'Unbiased_Rounding
+ S'Unbiased_Rounding denotes a function with the following
+ specification:
+
+40
+ function S'Unbiased_Rounding (X : T)
+ return T
+
+41
+ The function yields the integral value nearest to X,
+ rounding toward the even integer if X lies exactly
+ halfway between two integers. A zero result has the sign
+ of X when S'Signed_Zeros is True.
+
+41.1/2
+S'Machine_Rounding
+ {AI95-00267-01AI95-00267-01} S'Machine_Rounding denotes a
+ function with the following specification:
+
+41.2/2
+ function S'Machine_Rounding (X : T)
+ return T
+
+41.3/2
+ The function yields the integral value nearest to X. If X
+ lies exactly halfway between two integers, one of those
+ integers is returned, but which of them is returned is
+ unspecified. A zero result has the sign of X when
+ S'Signed_Zeros is True. This function provides access to
+ the rounding behavior which is most efficient on the
+ target processor.
+
+41.a.1/2
+ Discussion: We leave the rounding unspecified, so that users
+ cannot depend on a particular rounding. This attribute is
+ intended for use in cases where the particular rounding chosen
+ is irrelevant. If there is a need to know which way values
+ halfway between two integers are rounded, one of the other
+ rounding attributes should be used.
+
+42
+S'Truncation
+ S'Truncation denotes a function with the following
+ specification:
+
+43
+ function S'Truncation (X : T)
+ return T
+
+44
+ The function yields the value 'ceiling(X)' when X is
+ negative, and 'floor(X)' otherwise. A zero result has
+ the sign of X when S'Signed_Zeros is True.
+
+45
+S'Remainder
+ S'Remainder denotes a function with the following
+ specification:
+
+46
+ function S'Remainder (X, Y : T)
+ return T
+
+47
+ For nonzero Y, let v be the value X - n · Y, where n is
+ the integer nearest to the exact value of X/Y; if |n -
+ X/Y| = 1/2, then n is chosen to be even. If v is a
+ machine number of the type T, the function yields v;
+ otherwise, it yields zero. Constraint_Error is raised if
+ Y is zero. A zero result has the sign of X when
+ S'Signed_Zeros is True.
+
+47.a
+ Ramification: The magnitude of the result is less than or
+ equal to one-half the magnitude of Y.
+
+47.b
+ Discussion: Given machine numbers X and Y of the type T, v is
+ necessarily a machine number of the type T, except when Y is
+ in the neighborhood of zero, X is sufficiently close to a
+ multiple of Y, and T'Denorm is False.
+
+48
+S'Adjacent
+ S'Adjacent denotes a function with the following
+ specification:
+
+49
+ function S'Adjacent (X, Towards : T)
+ return T
+
+50
+ If Towards = X, the function yields X; otherwise, it
+ yields the machine number of the type T adjacent to X in
+ the direction of Towards, if that machine number exists.
+ If the result would be outside the base range of S,
+ Constraint_Error is raised. When T'Signed_Zeros is True,
+ a zero result has the sign of X. When Towards is zero,
+ its sign has no bearing on the result.
+
+50.a
+ Ramification: The value of S'Adjacent(0.0, 1.0) is the
+ smallest normalized positive number of the type T when
+ T'Denorm is False and the smallest denormalized positive
+ number of the type T when T'Denorm is True.
+
+51
+S'Copy_Sign
+ S'Copy_Sign denotes a function with the following
+ specification:
+
+52
+ function S'Copy_Sign (Value, Sign : T)
+ return T
+
+53
+ If the value of Value is nonzero, the function yields a
+ result whose magnitude is that of Value and whose sign is
+ that of Sign; otherwise, it yields the value zero.
+ Constraint_Error is optionally raised if the result is
+ outside the base range of S. A zero result has the sign
+ of Sign when S'Signed_Zeros is True.
+
+53.a
+ Discussion: S'Copy_Sign is provided for convenience in
+ restoring the sign to a quantity from which it has been
+ temporarily removed, or to a related quantity. When
+ S'Signed_Zeros is True, it is also instrumental in determining
+ the sign of a zero quantity, when required. (Because negative
+ and positive zeros compare equal in systems conforming to IEC
+ 559:1989, a negative zero does not appear to be negative when
+ compared to zero.) The sign determination is accomplished by
+ transferring the sign of the zero quantity to a nonzero
+ quantity and then testing for a negative result.
+
+54
+S'Leading_Part
+ S'Leading_Part denotes a function with the following
+ specification:
+
+55
+ function S'Leading_Part (X : T;
+ Radix_Digits : universal_integer)
+ return T
+
+56
+ Let v be the value T'Machine_Radixk-Radix_Digits, where k
+ is the normalized exponent of X. The function yields the
+ value
+
+57
+ * 'floor(X/v)' · v, when X is nonnegative and
+ Radix_Digits is positive;
+
+58
+ * 'ceiling(X/v)' · v, when X is negative and
+ Radix_Digits is positive.
+
+59
+ Constraint_Error is raised when Radix_Digits is zero or
+ negative. A zero result[, which can only occur when X is
+ zero,] has the sign of X.
+
+59.a
+ Discussion: Informally, if X is nonzero, the result is the
+ value obtained by retaining only the specified number of
+ (leading) significant digits of X (in the machine radix),
+ setting all other digits to zero.
+
+59.b
+ Implementation Note: The result can be obtained by first
+ scaling X up, if necessary to normalize it, then masking the
+ mantissa so as to retain only the specified number of leading
+ digits, then scaling the result back down if X was scaled up.
+
+60
+S'Machine
+ S'Machine denotes a function with the following
+ specification:
+
+61
+ function S'Machine (X : T)
+ return T
+
+62
+ If X is a machine number of the type T, the function
+ yields X; otherwise, it yields the value obtained by
+ rounding or truncating X to either one of the adjacent
+ machine numbers of the type T. Constraint_Error is raised
+ if rounding or truncating X to the precision of the
+ machine numbers results in a value outside the base range
+ of S. A zero result has the sign of X when S'Signed_Zeros
+ is True.
+
+62.a/3
+ Discussion: {AI05-0005-1AI05-0005-1} All of the primitive
+ function attributes except Rounding and Machine correspond to
+ subprograms in the Generic_Primitive_Functions generic package
+ that was proposed as a separate ISO standard (ISO/IEC DIS
+ 11729) for Ada 83. The Scaling, Unbiased_Rounding, and
+ Truncation attributes correspond to the Scale, Round, and
+ Truncate functions, respectively, in
+ Generic_Primitive_Functions. The Rounding attribute rounds
+ away from zero; this functionality was not provided in
+ Generic_Primitive_Functions. The name Round was not available
+ for either of the primitive function attributes that perform
+ rounding, since an attribute of that name is used for a
+ different purpose for decimal fixed point types. Likewise,
+ the name Scale was not available, since an attribute of that
+ name is also used for a different purpose for decimal fixed
+ point types. The functionality of the Machine attribute was
+ also not provided in Generic_Primitive_Functions. The
+ functionality of the Decompose procedure of
+ Generic_Primitive_Functions is only provided in the form of
+ the separate attributes Exponent and Fraction. The
+ functionality of the Successor and Predecessor functions of
+ Generic_Primitive_Functions is provided by the extension of
+ the existing Succ and Pred attributes.
+
+62.b
+ Implementation Note: The primitive function attributes may be
+ implemented either with appropriate floating point arithmetic
+ operations or with integer and logical operations that act on
+ parts of the representation directly. The latter is strongly
+ encouraged when it is more efficient than the former; it is
+ mandatory when the former cannot deliver the required accuracy
+ due to limitations of the implementation's arithmetic
+ operations.
+
+63
+The following model-oriented attributes are defined for any subtype S of
+a floating point type T.
+
+64
+S'Model_Mantissa
+ If the Numerics Annex is not supported, this attribute
+ yields an implementation defined value that is greater
+ than or equal to 'ceiling(d · log(10) /
+ log(T'Machine_Radix))' + 1, where d is the requested
+ decimal precision of T, and less than or equal to the
+ value of T'Machine_Mantissa. See *note G.2.2:: for
+ further requirements that apply to implementations
+ supporting the Numerics Annex. The value of this
+ attribute is of the type universal_integer.
+
+65
+S'Model_Emin
+ If the Numerics Annex is not supported, this attribute
+ yields an implementation defined value that is greater
+ than or equal to the value of T'Machine_Emin. See *note
+ G.2.2:: for further requirements that apply to
+ implementations supporting the Numerics Annex. The value
+ of this attribute is of the type universal_integer.
+
+66
+S'Model_Epsilon
+ Yields the value T'Machine_Radix1 - T'Model_Mantissa.
+ The value of this attribute is of the type
+ universal_real.
+
+66.a
+ Discussion: In most implementations, this attribute yields the
+ absolute value of the difference between one and the smallest
+ machine number of the type T above one which, when added to
+ one, yields a machine number different from one. Further
+ discussion can be found in *note G.2.2::.
+
+67
+S'Model_Small
+ Yields the value T'Machine_RadixT'Model_Emin - 1. The
+ value of this attribute is of the type universal_real.
+
+67.a
+ Discussion: In most implementations, this attribute yields the
+ smallest positive normalized number of the type T, i.e. the
+ number corresponding to the positive underflow threshold. In
+ some implementations employing a radix-complement
+ representation for the type T, the positive underflow
+ threshold is closer to zero than is the negative underflow
+ threshold, with the consequence that the smallest positive
+ normalized number does not coincide with the positive
+ underflow threshold (i.e., it exceeds the latter). Further
+ discussion can be found in *note G.2.2::.
+
+68
+S'Model
+ S'Model denotes a function with the following
+ specification:
+
+69
+ function S'Model (X : T)
+ return T
+
+70
+ If the Numerics Annex is not supported, the meaning of
+ this attribute is implementation defined; see *note
+ G.2.2:: for the definition that applies to
+ implementations supporting the Numerics Annex.
+
+71
+S'Safe_First
+ Yields the lower bound of the safe range (see *note
+ 3.5.7::) of the type T. If the Numerics Annex is not
+ supported, the value of this attribute is implementation
+ defined; see *note G.2.2:: for the definition that
+ applies to implementations supporting the Numerics Annex.
+ The value of this attribute is of the type
+ universal_real.
+
+72
+S'Safe_Last
+ Yields the upper bound of the safe range (see *note
+ 3.5.7::) of the type T. If the Numerics Annex is not
+ supported, the value of this attribute is implementation
+ defined; see *note G.2.2:: for the definition that
+ applies to implementations supporting the Numerics Annex.
+ The value of this attribute is of the type
+ universal_real.
+
+72.a
+ Discussion: A predefined floating point arithmetic operation
+ that yields a value in the safe range of its result type is
+ guaranteed not to overflow.
+
+72.b
+ To be honest: An exception is made for exponentiation by a
+ negative exponent in *note 4.5.6::.
+
+72.c
+ Implementation defined: The values of the Model_Mantissa,
+ Model_Emin, Model_Epsilon, Model, Safe_First, and Safe_Last
+ attributes, if the Numerics Annex is not supported.
+
+ _Incompatibilities With Ada 83_
+
+72.d
+ The Epsilon and Mantissa attributes of floating point types
+ are removed from the language and replaced by Model_Epsilon
+ and Model_Mantissa, which may have different values (as a
+ result of changes in the definition of model numbers); the
+ replacement of one set of attributes by another is intended to
+ convert what would be an inconsistent change into an
+ incompatible change.
+
+72.e
+ The Emax, Small, Large, Safe_Emax, Safe_Small, and Safe_Large
+ attributes of floating point types are removed from the
+ language. Small and Safe_Small are collectively replaced by
+ Model_Small, which is functionally equivalent to Safe_Small,
+ though it may have a slightly different value. The others are
+ collectively replaced by Safe_First and Safe_Last. Safe_Last
+ is functionally equivalent to Safe_Large, though it may have a
+ different value; Safe_First is comparable to the negation of
+ Safe_Large but may differ slightly from it as well as from the
+ negation of Safe_Last. Emax and Safe_Emax had relatively few
+ uses in Ada 83; T'Safe_Emax can be computed in the revised
+ language as Integer'Min(T'Exponent(T'Safe_First),
+ T'Exponent(T'Safe_Last)).
+
+72.f
+ Implementations are encouraged to eliminate the
+ incompatibilities discussed here by retaining the old
+ attributes, during a transition period, in the form of
+ implementation-defined attributes with their former values.
+
+ _Extensions to Ada 83_
+
+72.g
+ The Model_Emin attribute is new. It is conceptually similar
+ to the negation of Safe_Emax attribute of Ada 83, adjusted for
+ the fact that the model numbers now have the hardware radix.
+ It is a fundamental determinant, along with Model_Mantissa, of
+ the set of model numbers of a type (see *note G.2.1::).
+
+72.h
+ The Denorm and Signed_Zeros attributes are new, as are all of
+ the primitive function attributes.
+
+ _Extensions to Ada 95_
+
+72.i/2
+ {AI95-00388-01AI95-00388-01} The Machine_Rounding attribute is
+ new.
+
+\1f
+File: aarm2012.info, Node: A.5.4, Prev: A.5.3, Up: A.5
+
+A.5.4 Attributes of Fixed Point Types
+-------------------------------------
+
+ _Static Semantics_
+
+1
+The following representation-oriented attributes are defined for every
+subtype S of a fixed point type T.
+
+2
+S'Machine_Radix
+ Yields the radix of the hardware representation of the
+ type T. The value of this attribute is of the type
+ universal_integer.
+
+3
+S'Machine_Rounds
+ Yields the value True if rounding is performed on inexact
+ results of every predefined operation that yields a
+ result of the type T; yields the value False otherwise.
+ The value of this attribute is of the predefined type
+ Boolean.
+
+4
+S'Machine_Overflows
+ Yields the value True if overflow and divide-by-zero are
+ detected and reported by raising Constraint_Error for
+ every predefined operation that yields a result of the
+ type T; yields the value False otherwise. The value of
+ this attribute is of the predefined type Boolean.
+
+ _Incompatibilities With Ada 83_
+
+4.a
+ The Mantissa, Large, Safe_Small, and Safe_Large attributes of
+ fixed point types are removed from the language.
+
+4.b
+ Implementations are encouraged to eliminate the resulting
+ incompatibility by retaining these attributes, during a
+ transition period, in the form of implementation-defined
+ attributes with their former values.
+
+ _Extensions to Ada 83_
+
+4.c
+ The Machine_Radix attribute is now allowed for fixed point
+ types. It is also specifiable in an attribute definition
+ clause (see *note F.1::).
+
+\1f
+File: aarm2012.info, Node: A.6, Next: A.7, Prev: A.5, Up: Annex A
+
+A.6 Input-Output
+================
+
+1/2
+{AI95-00285-01AI95-00285-01} [ Input-output is provided through
+language-defined packages, each of which is a child of the root package
+Ada. The generic packages Sequential_IO and Direct_IO define
+input-output operations applicable to files containing elements of a
+given type. The generic package Storage_IO supports reading from and
+writing to an in-memory buffer. Additional operations for text
+input-output are supplied in the packages Text_IO, Wide_Text_IO, and
+Wide_Wide_Text_IO. Heterogeneous input-output is provided through the
+child packages Streams.Stream_IO and Text_IO.Text_Streams (see also
+*note 13.13::). The package IO_Exceptions defines the exceptions needed
+by the predefined input-output packages.]
+
+ _Inconsistencies With Ada 83_
+
+1.a
+ The introduction of Append_File as a new element of the
+ enumeration type File_Mode in Sequential_IO and Text_IO, and
+ the introduction of several new declarations in Text_IO, may
+ result in name clashes in the presence of use clauses.
+
+ _Extensions to Ada 83_
+
+1.b
+ Text_IO enhancements (Get_Immediate, Look_Ahead,
+ Standard_Error, Modular_IO, Decimal_IO), Wide_Text_IO, and the
+ stream input-output facilities are new in Ada 95.
+
+ _Wording Changes from Ada 83_
+
+1.c
+ RM83-14.6, "Low Level Input-Output," is removed. This has no
+ semantic effect, since the package was entirely implementation
+ defined, nobody actually implemented it, and if they did, they
+ can always provide it as a vendor-supplied package.
+
+ _Wording Changes from Ada 95_
+
+1.d/2
+ {AI95-00285-01AI95-00285-01} Included package
+ Wide_Wide_Text_IO in this description.
+
+\1f
+File: aarm2012.info, Node: A.7, Next: A.8, Prev: A.6, Up: Annex A
+
+A.7 External Files and File Objects
+===================================
+
+ _Static Semantics_
+
+1
+Values input from the external environment of the program, or output to
+the external environment, are considered to occupy external files. An
+external file can be anything external to the program that can produce a
+value to be read or receive a value to be written. An external file is
+identified by a string (the name). A second string (the form) gives
+further system-dependent characteristics that may be associated with the
+file, such as the physical organization or access rights. The
+conventions governing the interpretation of such strings shall be
+documented.
+
+2/3
+{AI05-0299-1AI05-0299-1} Input and output operations are expressed as
+operations on objects of some file type, rather than directly in terms
+of the external files. In the remainder of this clause, the term file
+is always used to refer to a file object; the term external file is used
+otherwise.
+
+3
+Input-output for sequential files of values of a single element type is
+defined by means of the generic package Sequential_IO. In order to
+define sequential input-output for a given element type, an
+instantiation of this generic unit, with the given type as actual
+parameter, has to be declared. The resulting package contains the
+declaration of a file type (called File_Type) for files of such
+elements, as well as the operations applicable to these files, such as
+the Open, Read, and Write procedures.
+
+4/2
+{AI95-00285-01AI95-00285-01} Input-output for direct access files is
+likewise defined by a generic package called Direct_IO. Input-output in
+human-readable form is defined by the (nongeneric) packages Text_IO for
+Character and String data, Wide_Text_IO for Wide_Character and
+Wide_String data, and Wide_Wide_Text_IO for Wide_Wide_Character and
+Wide_Wide_String data. Input-output for files containing streams of
+elements representing values of possibly different types is defined by
+means of the (nongeneric) package Streams.Stream_IO.
+
+5
+Before input or output operations can be performed on a file, the file
+first has to be associated with an external file. While such an
+association is in effect, the file is said to be open, and otherwise the
+file is said to be closed.
+
+6
+The language does not define what happens to external files after the
+completion of the main program and all the library tasks (in particular,
+if corresponding files have not been closed). The effect of
+input-output for access types is unspecified.
+
+7
+An open file has a current mode, which is a value of one of the
+following enumeration types:
+
+8
+ type File_Mode is (In_File, Inout_File, Out_File); -- for Direct_IO
+
+9
+ These values correspond respectively to the cases where only
+ reading, both reading and writing, or only writing are to be
+ performed.
+
+10/2
+ {AI95-00285-01AI95-00285-01} type File_Mode is (In_File, Out_File, Append_File);
+ -- for Sequential_IO, Text_IO, Wide_Text_IO, Wide_Wide_Text_IO, and Stream_IO
+
+11
+ These values correspond respectively to the cases where only
+ reading, only writing, or only appending are to be performed.
+
+12
+ The mode of a file can be changed.
+
+13/2
+{AI95-00285-01AI95-00285-01} Several file management operations are
+common to Sequential_IO, Direct_IO, Text_IO, Wide_Text_IO, and
+Wide_Wide_Text_IO. These operations are described in subclause *note
+A.8.2:: for sequential and direct files. Any additional effects
+concerning text input-output are described in subclause *note A.10.2::.
+
+14/3
+{AI05-0299-1AI05-0299-1} The exceptions that can be propagated by the
+execution of an input-output subprogram are defined in the package
+IO_Exceptions; the situations in which they can be propagated are
+described following the description of the subprogram (and in subclause
+*note A.13::). The exceptions Storage_Error and Program_Error may be
+propagated. (Program_Error can only be propagated due to errors made by
+the caller of the subprogram.) Finally, exceptions can be propagated in
+certain implementation-defined situations.
+
+14.a/2
+ This paragraph was deleted.
+
+14.b/2
+ Discussion: The last sentence here is referring to the
+ documentation requirements in *note A.13::, "*note A.13::
+ Exceptions in Input-Output", and the documentation summary
+ item is provided there.
+
+ NOTES
+
+15/2
+ 23 {AI95-00285-01AI95-00285-01} Each instantiation of the generic
+ packages Sequential_IO and Direct_IO declares a different type
+ File_Type. In the case of Text_IO, Wide_Text_IO,
+ Wide_Wide_Text_IO, and Streams.Stream_IO, the corresponding type
+ File_Type is unique.
+
+16
+ 24 A bidirectional device can often be modeled as two sequential
+ files associated with the device, one of mode In_File, and one of
+ mode Out_File. An implementation may restrict the number of files
+ that may be associated with a given external file.
+
+ _Wording Changes from Ada 95_
+
+16.a/2
+ {AI95-00285-01AI95-00285-01} Included package
+ Wide_Wide_Text_IO in this description.
+
+\1f
+File: aarm2012.info, Node: A.8, Next: A.9, Prev: A.7, Up: Annex A
+
+A.8 Sequential and Direct Files
+===============================
+
+ _Static Semantics_
+
+1/2
+{AI95-00283-01AI95-00283-01} Two kinds of access to external files are
+defined in this subclause: sequential access and direct access. The
+corresponding file types and the associated operations are provided by
+the generic packages Sequential_IO and Direct_IO. A file object to be
+used for sequential access is called a sequential file, and one to be
+used for direct access is called a direct file. Access to stream files
+is described in *note A.12.1::.
+
+2
+For sequential access, the file is viewed as a sequence of values that
+are transferred in the order of their appearance (as produced by the
+program or by the external environment). When the file is opened with
+mode In_File or Out_File, transfer starts respectively from or to the
+beginning of the file. When the file is opened with mode Append_File,
+transfer to the file starts after the last element of the file.
+
+2.a
+ Discussion: Adding stream I/O necessitates a review of the
+ terminology. In Ada 83, 'sequential' implies both the access
+ method (purely sequential -- that is, no indexing or
+ positional access) and homogeneity. Direct access includes
+ purely sequential access and indexed access, as well as
+ homogeneity. In Ada 95, streams allow purely sequential
+ access but also positional access to an individual element,
+ and are heterogeneous. We considered generalizing the notion
+ of 'sequential file' to include both Sequential_IO and
+ Stream_IO files, but since streams allow positional access it
+ seems misleading to call them sequential files. Or, looked at
+ differently, if the criterion for calling something a
+ sequential file is whether it permits (versus requires) purely
+ sequential access, then one could just as soon regard a
+ Direct_IO file as a sequential file.
+
+2.b
+ It seems better to regard 'sequential file' as meaning 'only
+ permitting purely sequential access'; hence we have decided to
+ supplement 'sequential access' and 'direct access' with a
+ third category, informally called 'access to streams'. (We
+ decided against the term 'stream access' because of possible
+ confusion with the Stream_Access type declared in one of the
+ stream packages.)
+
+3
+For direct access, the file is viewed as a set of elements occupying
+consecutive positions in linear order; a value can be transferred to or
+from an element of the file at any selected position. The position of
+an element is specified by its index, which is a number, greater than
+zero, of the implementation-defined integer type Count. The first
+element, if any, has index one; the index of the last element, if any,
+is called the current size; the current size is zero if there are no
+elements. The current size is a property of the external file.
+
+4
+An open direct file has a current index, which is the index that will be
+used by the next read or write operation. When a direct file is opened,
+the current index is set to one. The current index of a direct file is
+a property of a file object, not of an external file.
+
+ _Wording Changes from Ada 95_
+
+4.a/2
+ {AI95-00283-01AI95-00283-01} Italicized "stream file" to
+ clarify that this is another kind of file.
+
+* Menu:
+
+* A.8.1 :: The Generic Package Sequential_IO
+* A.8.2 :: File Management
+* A.8.3 :: Sequential Input-Output Operations
+* A.8.4 :: The Generic Package Direct_IO
+* A.8.5 :: Direct Input-Output Operations
+
+\1f
+File: aarm2012.info, Node: A.8.1, Next: A.8.2, Up: A.8
+
+A.8.1 The Generic Package Sequential_IO
+---------------------------------------
+
+ _Static Semantics_
+
+1
+The generic library package Sequential_IO has the following declaration:
+
+2
+ with Ada.IO_Exceptions;
+ generic
+ type Element_Type(<>) is private;
+ package Ada.Sequential_IO is
+
+3
+ type File_Type is limited private;
+
+4
+ type File_Mode is (In_File, Out_File, Append_File);
+
+5
+ -- File management
+
+6
+ procedure Create(File : in out File_Type;
+ Mode : in File_Mode := Out_File;
+ Name : in String := "";
+ Form : in String := "");
+
+7
+ procedure Open (File : in out File_Type;
+ Mode : in File_Mode;
+ Name : in String;
+ Form : in String := "");
+
+8
+ procedure Close (File : in out File_Type);
+ procedure Delete(File : in out File_Type);
+ procedure Reset (File : in out File_Type; Mode : in File_Mode);
+ procedure Reset (File : in out File_Type);
+
+9
+ function Mode (File : in File_Type) return File_Mode;
+ function Name (File : in File_Type) return String;
+ function Form (File : in File_Type) return String;
+
+10
+ function Is_Open(File : in File_Type) return Boolean;
+
+11
+ -- Input and output operations
+
+12
+ procedure Read (File : in File_Type; Item : out Element_Type);
+ procedure Write (File : in File_Type; Item : in Element_Type);
+
+13
+ function End_Of_File(File : in File_Type) return Boolean;
+
+14
+ -- Exceptions
+
+15
+ Status_Error : exception renames IO_Exceptions.Status_Error;
+ Mode_Error : exception renames IO_Exceptions.Mode_Error;
+ Name_Error : exception renames IO_Exceptions.Name_Error;
+ Use_Error : exception renames IO_Exceptions.Use_Error;
+ Device_Error : exception renames IO_Exceptions.Device_Error;
+ End_Error : exception renames IO_Exceptions.End_Error;
+ Data_Error : exception renames IO_Exceptions.Data_Error;
+
+16
+ private
+ ... -- not specified by the language
+ end Ada.Sequential_IO;
+
+17/2
+{AI95-00360-01AI95-00360-01} The type File_Type needs finalization (see
+*note 7.6::) in every instantiation of Sequential_IO.
+
+ _Incompatibilities With Ada 83_
+
+17.a
+ The new enumeration element Append_File may introduce upward
+ incompatibilities. It is possible that a program based on the
+ assumption that File_Mode'Last = Out_File will be illegal
+ (e.g., case statement choice coverage) or execute with a
+ different effect in Ada 95.
+
+17.a.1/2
+ This paragraph was deleted.{8652/00978652/0097}
+ {AI95-00115-01AI95-00115-01} {AI95-00344-01AI95-00344-01}
+
+ _Incompatibilities With Ada 95_
+
+17.b/2
+ {AI95-00360-01AI95-00360-01} Amendment Correction: File_Type
+ in an instance of Sequential_IO is defined to need
+ finalization. If the restriction No_Nested_Finalization (see
+ *note D.7::) applies to the partition, and File_Type does not
+ have a controlled part, it will not be allowed in local
+ objects in Ada 2005 whereas it would be allowed in original
+ Ada 95. Such code is not portable, as another Ada compiler
+ may have a controlled part in File_Type, and thus would be
+ illegal.
+
+\1f
+File: aarm2012.info, Node: A.8.2, Next: A.8.3, Prev: A.8.1, Up: A.8
+
+A.8.2 File Management
+---------------------
+
+ _Static Semantics_
+
+1
+The procedures and functions described in this subclause provide for the
+control of external files; their declarations are repeated in each of
+the packages for sequential, direct, text, and stream input-output. For
+text input-output, the procedures Create, Open, and Reset have
+additional effects described in subclause *note A.10.2::.
+
+2
+ procedure Create(File : in out File_Type;
+ Mode : in File_Mode := default_mode;
+ Name : in String := "";
+ Form : in String := "");
+
+3/2
+ {AI95-00283-01AI95-00283-01} Establishes a new external file,
+ with the given name and form, and associates this external
+ file with the given file. The given file is left open. The
+ current mode of the given file is set to the given access
+ mode. The default access mode is the mode Out_File for
+ sequential, stream, and text input-output; it is the mode
+ Inout_File for direct input-output. For direct access, the
+ size of the created file is implementation defined.
+
+4
+ A null string for Name specifies an external file that is not
+ accessible after the completion of the main program (a
+ temporary file). A null string for Form specifies the use of
+ the default options of the implementation for the external
+ file.
+
+5
+ The exception Status_Error is propagated if the given file is
+ already open. The exception Name_Error is propagated if the
+ string given as Name does not allow the identification of an
+ external file. The exception Use_Error is propagated if, for
+ the specified mode, the external environment does not support
+ creation of an external file with the given name (in the
+ absence of Name_Error) and form.
+
+6
+ procedure Open(File : in out File_Type;
+ Mode : in File_Mode;
+ Name : in String;
+ Form : in String := "");
+
+7
+ Associates the given file with an existing external file
+ having the given name and form, and sets the current mode of
+ the given file to the given mode. The given file is left
+ open.
+
+8
+ The exception Status_Error is propagated if the given file is
+ already open. The exception Name_Error is propagated if the
+ string given as Name does not allow the identification of an
+ external file; in particular, this exception is propagated if
+ no external file with the given name exists. The exception
+ Use_Error is propagated if, for the specified mode, the
+ external environment does not support opening for an external
+ file with the given name (in the absence of Name_Error) and
+ form.
+
+9
+ procedure Close(File : in out File_Type);
+
+10
+ Severs the association between the given file and its
+ associated external file. The given file is left closed. In
+ addition, for sequential files, if the file being closed has
+ mode Out_File or Append_File, then the last element written
+ since the most recent open or reset is the last element that
+ can be read from the file. If no elements have been written
+ and the file mode is Out_File, then the closed file is empty.
+ If no elements have been written and the file mode is
+ Append_File, then the closed file is unchanged.
+
+11
+ The exception Status_Error is propagated if the given file is
+ not open.
+
+12
+ procedure Delete(File : in out File_Type);
+
+13
+ Deletes the external file associated with the given file. The
+ given file is closed, and the external file ceases to exist.
+
+14
+ The exception Status_Error is propagated if the given file is
+ not open. The exception Use_Error is propagated if deletion
+ of the external file is not supported by the external
+ environment.
+
+15
+ procedure Reset(File : in out File_Type; Mode : in File_Mode);
+ procedure Reset(File : in out File_Type);
+
+16/2
+ {AI95-00085-01AI95-00085-01} Resets the given file so that
+ reading from its elements can be restarted from the beginning
+ of the external file (for modes In_File and Inout_File), and
+ so that writing to its elements can be restarted at the
+ beginning of the external file (for modes Out_File and
+ Inout_File) or after the last element of the external file
+ (for mode Append_File). In particular, for direct access this
+ means that the current index is set to one. If a Mode
+ parameter is supplied, the current mode of the given file is
+ set to the given mode. In addition, for sequential files, if
+ the given file has mode Out_File or Append_File when Reset is
+ called, the last element written since the most recent open or
+ reset is the last element that can be read from the external
+ file. If no elements have been written and the file mode is
+ Out_File, the reset file is empty. If no elements have been
+ written and the file mode is Append_File, then the reset file
+ is unchanged.
+
+17
+ The exception Status_Error is propagated if the file is not
+ open. The exception Use_Error is propagated if the external
+ environment does not support resetting for the external file
+ and, also, if the external environment does not support
+ resetting to the specified mode for the external file.
+
+18
+ function Mode(File : in File_Type) return File_Mode;
+
+19
+ Returns the current mode of the given file.
+
+20
+ The exception Status_Error is propagated if the file is not
+ open.
+
+21
+ function Name(File : in File_Type) return String;
+
+22/2
+ {AI95-00248-01AI95-00248-01} Returns a string which uniquely
+ identifies the external file currently associated with the
+ given file (and may thus be used in an Open operation).
+
+22.a/2
+ Discussion: {AI95-00248-01AI95-00248-01} Retrieving the full
+ path can be accomplished by passing the result of Name to
+ Directories.Full_Name (see *note A.16::). It is important to
+ drop the requirement on Name, as the only way to accomplish
+ this requirement given that the current directory can be
+ changed with package Directories is to store the full path
+ when the file is opened. That's expensive, and it's better
+ for users that need the full path to explicitly request it.
+
+23
+ The exception Status_Error is propagated if the given file is
+ not open. The exception Use_Error is propagated if the
+ associated external file is a temporary file that cannot be
+ opened by any name.
+
+24
+ function Form(File : in File_Type) return String;
+
+25
+ Returns the form string for the external file currently
+ associated with the given file. If an external environment
+ allows alternative specifications of the form (for example,
+ abbreviations using default options), the string returned by
+ the function should correspond to a full specification (that
+ is, it should indicate explicitly all options selected,
+ including default options).
+
+26
+ The exception Status_Error is propagated if the given file is
+ not open.
+
+27
+ function Is_Open(File : in File_Type) return Boolean;
+
+28/3
+ {AI05-0264-1AI05-0264-1} Returns True if the file is open
+ (that is, if it is associated with an external file);
+ otherwise, returns False.
+
+ _Implementation Permissions_
+
+29
+An implementation may propagate Name_Error or Use_Error if an attempt is
+made to use an I/O feature that cannot be supported by the
+implementation due to limitations in the external environment. Any such
+restriction should be documented.
+
+ _Wording Changes from Ada 95_
+
+29.a/2
+ {AI95-00085-01AI95-00085-01} Clarified that Reset affects and
+ depends on the external file.
+
+29.b/2
+ {AI95-00248-01AI95-00248-01} Removed the requirement for Name
+ to return a full path; this is now accomplished by
+ Directories.Full_Name(Name(File)) (see *note A.16::). This is
+ not documented as an inconsistency, because there is no
+ requirement for implementations to change -- the Ada 95
+ behavior is still allowed, it just is no longer required.
+
+29.c/2
+ {AI95-00283-01AI95-00283-01} Added text to specify the default
+ mode for a stream file.
+
+\1f
+File: aarm2012.info, Node: A.8.3, Next: A.8.4, Prev: A.8.2, Up: A.8
+
+A.8.3 Sequential Input-Output Operations
+----------------------------------------
+
+ _Static Semantics_
+
+1
+The operations available for sequential input and output are described
+in this subclause. The exception Status_Error is propagated if any of
+these operations is attempted for a file that is not open.
+
+2
+ procedure Read(File : in File_Type; Item : out Element_Type);
+
+3
+ Operates on a file of mode In_File. Reads an element from the
+ given file, and returns the value of this element in the Item
+ parameter.
+
+3.a
+ Discussion: We considered basing Sequential_IO.Read on
+ Element_Type'Read from an implicit stream associated with the
+ sequential file. However, Element_Type'Read is a type-related
+ attribute, whereas Sequential_IO should take advantage of the
+ particular constraints of the actual subtype corresponding to
+ Element_Type to minimize the size of the external file.
+ Furthermore, forcing the implementation of Sequential_IO to be
+ based on Element_Type'Read would create an upward
+ incompatibility since existing data files written by an Ada 83
+ program using Sequential_IO might not be readable by the
+ identical program built with an Ada 95 implementation of
+ Sequential_IO.
+
+3.b
+ An Ada 95 implementation might still use an
+ implementation-defined attribute analogous to 'Read to
+ implement the procedure Read, but that attribute will likely
+ have to be subtype-specific rather than type-related, and it
+ need not be user-specifiable. Such an attribute will
+ presumably be needed to implement the generic package
+ Storage_IO (see *note A.9::).
+
+4
+ The exception Mode_Error is propagated if the mode is not
+ In_File. The exception End_Error is propagated if no more
+ elements can be read from the given file. The exception
+ Data_Error can be propagated if the element read cannot be
+ interpreted as a value of the subtype Element_Type (see *note
+ A.13::, "*note A.13:: Exceptions in Input-Output").
+
+4.a
+ Discussion: Data_Error need not be propagated if the check is
+ too complex. See *note A.13::, "*note A.13:: Exceptions in
+ Input-Output".
+
+5
+ procedure Write(File : in File_Type; Item : in Element_Type);
+
+6
+ Operates on a file of mode Out_File or Append_File. Writes
+ the value of Item to the given file.
+
+7
+ The exception Mode_Error is propagated if the mode is not
+ Out_File or Append_File. The exception Use_Error is
+ propagated if the capacity of the external file is exceeded.
+
+8
+ function End_Of_File(File : in File_Type) return Boolean;
+
+9/3
+ {AI05-0264-1AI05-0264-1} Operates on a file of mode In_File.
+ Returns True if no more elements can be read from the given
+ file; otherwise, returns False.
+
+10
+ The exception Mode_Error is propagated if the mode is not
+ In_File.
+
+\1f
+File: aarm2012.info, Node: A.8.4, Next: A.8.5, Prev: A.8.3, Up: A.8
+
+A.8.4 The Generic Package Direct_IO
+-----------------------------------
+
+ _Static Semantics_
+
+1
+The generic library package Direct_IO has the following declaration:
+
+2
+ with Ada.IO_Exceptions;
+ generic
+ type Element_Type is private;
+ package Ada.Direct_IO is
+
+3
+ type File_Type is limited private;
+
+4
+ type File_Mode is (In_File, Inout_File, Out_File);
+ type Count is range 0 .. implementation-defined;
+ subtype Positive_Count is Count range 1 .. Count'Last;
+
+5
+ -- File management
+
+6
+ procedure Create(File : in out File_Type;
+ Mode : in File_Mode := Inout_File;
+ Name : in String := "";
+ Form : in String := "");
+
+7
+ procedure Open (File : in out File_Type;
+ Mode : in File_Mode;
+ Name : in String;
+ Form : in String := "");
+
+8
+ procedure Close (File : in out File_Type);
+ procedure Delete(File : in out File_Type);
+ procedure Reset (File : in out File_Type; Mode : in File_Mode);
+ procedure Reset (File : in out File_Type);
+
+9
+ function Mode (File : in File_Type) return File_Mode;
+ function Name (File : in File_Type) return String;
+ function Form (File : in File_Type) return String;
+
+10
+ function Is_Open(File : in File_Type) return Boolean;
+
+11
+ -- Input and output operations
+
+12
+ procedure Read (File : in File_Type; Item : out Element_Type;
+ From : in Positive_Count);
+ procedure Read (File : in File_Type; Item : out Element_Type);
+
+13
+ procedure Write(File : in File_Type; Item : in Element_Type;
+ To : in Positive_Count);
+ procedure Write(File : in File_Type; Item : in Element_Type);
+
+14
+ procedure Set_Index(File : in File_Type; To : in Positive_Count);
+
+15
+ function Index(File : in File_Type) return Positive_Count;
+ function Size (File : in File_Type) return Count;
+
+16
+ function End_Of_File(File : in File_Type) return Boolean;
+
+17
+ -- Exceptions
+
+18
+ Status_Error : exception renames IO_Exceptions.Status_Error;
+ Mode_Error : exception renames IO_Exceptions.Mode_Error;
+ Name_Error : exception renames IO_Exceptions.Name_Error;
+ Use_Error : exception renames IO_Exceptions.Use_Error;
+ Device_Error : exception renames IO_Exceptions.Device_Error;
+ End_Error : exception renames IO_Exceptions.End_Error;
+ Data_Error : exception renames IO_Exceptions.Data_Error;
+
+19
+ private
+ ... -- not specified by the language
+ end Ada.Direct_IO;
+
+19.a
+ Reason: The Element_Type formal of Direct_IO does not have an
+ unknown_discriminant_part (unlike Sequential_IO) so that the
+ implementation can make use of the ability to declare
+ uninitialized variables of the type.
+
+20/2
+{AI95-00360-01AI95-00360-01} The type File_Type needs finalization (see
+*note 7.6::) in every instantiation of Direct_IO.
+
+20.a.1/2
+ This paragraph was deleted.{8652/00978652/0097}
+ {AI95-00115-01AI95-00115-01} {AI95-00344-01AI95-00344-01}
+
+ _Incompatibilities With Ada 95_
+
+20.a/2
+ {AI95-00360-01AI95-00360-01} Amendment Correction: File_Type
+ in an instance of Direct_IO is defined to need finalization.
+ If the restriction No_Nested_Finalization (see *note D.7::)
+ applies to the partition, and File_Type does not have a
+ controlled part, it will not be allowed in local objects in
+ Ada 2005 whereas it would be allowed in original Ada 95. Such
+ code is not portable, as another Ada compiler may have a
+ controlled part in File_Type, and thus would be illegal.
+
+\1f
+File: aarm2012.info, Node: A.8.5, Prev: A.8.4, Up: A.8
+
+A.8.5 Direct Input-Output Operations
+------------------------------------
+
+ _Static Semantics_
+
+1
+The operations available for direct input and output are described in
+this subclause. The exception Status_Error is propagated if any of
+these operations is attempted for a file that is not open.
+
+2
+ procedure Read(File : in File_Type; Item : out Element_Type;
+ From : in Positive_Count);
+ procedure Read(File : in File_Type; Item : out Element_Type);
+
+3
+ Operates on a file of mode In_File or Inout_File. In the case
+ of the first form, sets the current index of the given file to
+ the index value given by the parameter From. Then (for both
+ forms) returns, in the parameter Item, the value of the
+ element whose position in the given file is specified by the
+ current index of the file; finally, increases the current
+ index by one.
+
+4
+ The exception Mode_Error is propagated if the mode of the
+ given file is Out_File. The exception End_Error is propagated
+ if the index to be used exceeds the size of the external file.
+ The exception Data_Error can be propagated if the element read
+ cannot be interpreted as a value of the subtype Element_Type
+ (see *note A.13::).
+
+5
+ procedure Write(File : in File_Type; Item : in Element_Type;
+ To : in Positive_Count);
+ procedure Write(File : in File_Type; Item : in Element_Type);
+
+6
+ Operates on a file of mode Inout_File or Out_File. In the
+ case of the first form, sets the index of the given file to
+ the index value given by the parameter To. Then (for both
+ forms) gives the value of the parameter Item to the element
+ whose position in the given file is specified by the current
+ index of the file; finally, increases the current index by
+ one.
+
+7
+ The exception Mode_Error is propagated if the mode of the
+ given file is In_File. The exception Use_Error is propagated
+ if the capacity of the external file is exceeded.
+
+8
+ procedure Set_Index(File : in File_Type; To : in Positive_Count);
+
+9
+ Operates on a file of any mode. Sets the current index of the
+ given file to the given index value (which may exceed the
+ current size of the file).
+
+10
+ function Index(File : in File_Type) return Positive_Count;
+
+11
+ Operates on a file of any mode. Returns the current index of
+ the given file.
+
+12
+ function Size(File : in File_Type) return Count;
+
+13
+ Operates on a file of any mode. Returns the current size of
+ the external file that is associated with the given file.
+
+14
+ function End_Of_File(File : in File_Type) return Boolean;
+
+15/3
+ {AI05-0264-1AI05-0264-1} Operates on a file of mode In_File or
+ Inout_File. Returns True if the current index exceeds the
+ size of the external file; otherwise, returns False.
+
+16
+ The exception Mode_Error is propagated if the mode of the
+ given file is Out_File.
+
+ NOTES
+
+17
+ 25 Append_File mode is not supported for the generic package
+ Direct_IO.
+
+\1f
+File: aarm2012.info, Node: A.9, Next: A.10, Prev: A.8, Up: Annex A
+
+A.9 The Generic Package Storage_IO
+==================================
+
+1
+The generic package Storage_IO provides for reading from and writing to
+an in-memory buffer. This generic package supports the construction of
+user-defined input-output packages.
+
+1.a
+ Reason: This package exists to allow the portable construction
+ of user-defined direct-access-oriented input-output packages.
+ The Write procedure writes a value of type Element_Type into a
+ Storage_Array of size Buffer_Size, flattening out any implicit
+ levels of indirection used in the representation of the type.
+ The Read procedure reads a value of type Element_Type from the
+ buffer, reconstructing any implicit levels of indirection used
+ in the representation of the type. It also properly
+ initializes any type tags that appear within the value,
+ presuming that the buffer was written by a different program
+ and that tag values for the"same" type might vary from one
+ executable to another.
+
+ _Static Semantics_
+
+2
+The generic library package Storage_IO has the following declaration:
+
+3
+ with Ada.IO_Exceptions;
+ with System.Storage_Elements;
+ generic
+ type Element_Type is private;
+ package Ada.Storage_IO is
+ pragma Preelaborate(Storage_IO);
+
+4
+ Buffer_Size : constant System.Storage_Elements.Storage_Count :=
+ implementation-defined;
+ subtype Buffer_Type is
+ System.Storage_Elements.Storage_Array(1..Buffer_Size);
+
+5
+ -- Input and output operations
+
+6
+ procedure Read (Buffer : in Buffer_Type; Item : out Element_Type);
+
+7
+ procedure Write(Buffer : out Buffer_Type; Item : in Element_Type);
+
+8
+ -- Exceptions
+
+9
+ Data_Error : exception renames IO_Exceptions.Data_Error;
+ end Ada.Storage_IO;
+
+10
+In each instance, the constant Buffer_Size has a value that is the size
+(in storage elements) of the buffer required to represent the content of
+an object of subtype Element_Type, including any implicit levels of
+indirection used by the implementation. The Read and Write procedures
+of Storage_IO correspond to the Read and Write procedures of Direct_IO
+(see *note A.8.4::), but with the content of the Item parameter being
+read from or written into the specified Buffer, rather than an external
+file.
+
+10.a
+ Reason: As with Direct_IO, the Element_Type formal of
+ Storage_IO does not have an unknown_discriminant_part so that
+ there is a well-defined upper bound on the size of the buffer
+ needed to hold the content of an object of the formal subtype
+ (i.e. Buffer_Size). If there are no implicit levels of
+ indirection, Buffer_Size will typically equal:
+
+10.b
+ (Element_Type'Size + System.Storage_Unit - 1) / System.Storage_Unit
+
+10.c
+ Implementation defined: The value of Buffer_Size in
+ Storage_IO.
+
+ NOTES
+
+11
+ 26 A buffer used for Storage_IO holds only one element at a time;
+ an external file used for Direct_IO holds a sequence of elements.
+
+ _Extensions to Ada 83_
+
+11.a/3
+ {AI05-0005-1AI05-0005-1} Storage_IO is new in Ada 95.
+
+\1f
+File: aarm2012.info, Node: A.10, Next: A.11, Prev: A.9, Up: Annex A
+
+A.10 Text Input-Output
+======================
+
+ _Static Semantics_
+
+1/3
+{AI05-0299-1AI05-0299-1} This subclause describes the package Text_IO,
+which provides facilities for input and output in human-readable form.
+Each file is read or written sequentially, as a sequence of characters
+grouped into lines, and as a sequence of lines grouped into pages. The
+specification of the package is given below in subclause *note A.10.1::.
+
+2/3
+{AI05-0299-1AI05-0299-1} The facilities for file management given above,
+in subclauses *note A.8.2:: and *note A.8.3::, are available for text
+input-output. In place of Read and Write, however, there are procedures
+Get and Put that input values of suitable types from text files, and
+output values to them. These values are provided to the Put procedures,
+and returned by the Get procedures, in a parameter Item. Several
+overloaded procedures of these names exist, for different types of Item.
+These Get procedures analyze the input sequences of characters based on
+lexical elements (see Clause *note 2::) and return the corresponding
+values; the Put procedures output the given values as appropriate
+lexical elements. Procedures Get and Put are also available that input
+and output individual characters treated as character values rather than
+as lexical elements. Related to character input are procedures to look
+ahead at the next character without reading it, and to read a character
+"immediately" without waiting for an end-of-line to signal availability.
+
+3
+In addition to the procedures Get and Put for numeric and enumeration
+types of Item that operate on text files, analogous procedures are
+provided that read from and write to a parameter of type String. These
+procedures perform the same analysis and composition of character
+sequences as their counterparts which have a file parameter.
+
+4
+For all Get and Put procedures that operate on text files, and for many
+other subprograms, there are forms with and without a file parameter.
+Each such Get procedure operates on an input file, and each such Put
+procedure operates on an output file. If no file is specified, a
+default input file or a default output file is used.
+
+5
+At the beginning of program execution the default input and output files
+are the so-called standard input file and standard output file. These
+files are open, have respectively the current modes In_File and
+Out_File, and are associated with two implementation-defined external
+files. Procedures are provided to change the current default input file
+and the current default output file.
+
+5.a/2
+ Implementation defined: The external files associated with the
+ standard input, standard output, and standard error files.
+
+5.a.1/1
+ Implementation Note: {8652/01138652/0113}
+ {AI95-00087-01AI95-00087-01} The default input file and
+ default output file are not the names of distinct file
+ objects, but rather the role played by one or more (other)
+ file object(s). Thus, they generally will be implemented as
+ accesses to another file object. An implementation that
+ implements them by copying them is incorrect.
+
+6
+At the beginning of program execution a default file for
+program-dependent error-related text output is the so-called standard
+error file. This file is open, has the current mode Out_File, and is
+associated with an implementation-defined external file. A procedure is
+provided to change the current default error file.
+
+7
+From a logical point of view, a text file is a sequence of pages, a page
+is a sequence of lines, and a line is a sequence of characters; the end
+of a line is marked by a line terminator; the end of a page is marked by
+the combination of a line terminator immediately followed by a page
+terminator; and the end of a file is marked by the combination of a line
+terminator immediately followed by a page terminator and then a file
+terminator. Terminators are generated during output; either by calls of
+procedures provided expressly for that purpose; or implicitly as part of
+other operations, for example, when a bounded line length, a bounded
+page length, or both, have been specified for a file.
+
+8
+The actual nature of terminators is not defined by the language and
+hence depends on the implementation. Although terminators are
+recognized or generated by certain of the procedures that follow, they
+are not necessarily implemented as characters or as sequences of
+characters. Whether they are characters (and if so which ones) in any
+particular implementation need not concern a user who neither explicitly
+outputs nor explicitly inputs control characters. The effect of input
+(Get) or output (Put) of control characters (other than horizontal
+tabulation) is not specified by the language.
+
+9
+The characters of a line are numbered, starting from one; the number of
+a character is called its column number. For a line terminator, a
+column number is also defined: it is one more than the number of
+characters in the line. The lines of a page, and the pages of a file,
+are similarly numbered. The current column number is the column number
+of the next character or line terminator to be transferred. The current
+line number is the number of the current line. The current page number
+is the number of the current page. These numbers are values of the
+subtype Positive_Count of the type Count (by convention, the value zero
+of the type Count is used to indicate special conditions).
+
+10
+ type Count is range 0 .. implementation-defined;
+ subtype Positive_Count is Count range 1 .. Count'Last;
+
+11
+For an output file or an append file, a maximum line length can be
+specified and a maximum page length can be specified. If a value to be
+output cannot fit on the current line, for a specified maximum line
+length, then a new line is automatically started before the value is
+output; if, further, this new line cannot fit on the current page, for a
+specified maximum page length, then a new page is automatically started
+before the value is output. Functions are provided to determine the
+maximum line length and the maximum page length. When a file is opened
+with mode Out_File or Append_File, both values are zero: by convention,
+this means that the line lengths and page lengths are unbounded.
+(Consequently, output consists of a single line if the subprograms for
+explicit control of line and page structure are not used.) The constant
+Unbounded is provided for this purpose.
+
+ _Extensions to Ada 83_
+
+11.a
+ Append_File is new in Ada 95.
+
+* Menu:
+
+* A.10.1 :: The Package Text_IO
+* A.10.2 :: Text File Management
+* A.10.3 :: Default Input, Output, and Error Files
+* A.10.4 :: Specification of Line and Page Lengths
+* A.10.5 :: Operations on Columns, Lines, and Pages
+* A.10.6 :: Get and Put Procedures
+* A.10.7 :: Input-Output of Characters and Strings
+* A.10.8 :: Input-Output for Integer Types
+* A.10.9 :: Input-Output for Real Types
+* A.10.10 :: Input-Output for Enumeration Types
+* A.10.11 :: Input-Output for Bounded Strings
+* A.10.12 :: Input-Output for Unbounded Strings
+
+\1f
+File: aarm2012.info, Node: A.10.1, Next: A.10.2, Up: A.10
+
+A.10.1 The Package Text_IO
+--------------------------
+
+ _Static Semantics_
+
+1
+The library package Text_IO has the following declaration:
+
+2
+ with Ada.IO_Exceptions;
+ package Ada.Text_IO is
+
+3
+ type File_Type is limited private;
+
+4
+ type File_Mode is (In_File, Out_File, Append_File);
+
+5
+ type Count is range 0 .. implementation-defined;
+ subtype Positive_Count is Count range 1 .. Count'Last;
+ Unbounded : constant Count := 0; -- line and page length
+
+6
+ subtype Field is Integer range 0 .. implementation-defined;
+ subtype Number_Base is Integer range 2 .. 16;
+
+7
+ type Type_Set is (Lower_Case, Upper_Case);
+
+8
+ -- File Management
+
+9
+ procedure Create (File : in out File_Type;
+ Mode : in File_Mode := Out_File;
+ Name : in String := "";
+ Form : in String := "");
+
+10
+ procedure Open (File : in out File_Type;
+ Mode : in File_Mode;
+ Name : in String;
+ Form : in String := "");
+
+11
+ procedure Close (File : in out File_Type);
+ procedure Delete (File : in out File_Type);
+ procedure Reset (File : in out File_Type; Mode : in File_Mode);
+ procedure Reset (File : in out File_Type);
+
+12
+ function Mode (File : in File_Type) return File_Mode;
+ function Name (File : in File_Type) return String;
+ function Form (File : in File_Type) return String;
+
+13
+ function Is_Open(File : in File_Type) return Boolean;
+
+14
+ -- Control of default input and output files
+
+15
+ procedure Set_Input (File : in File_Type);
+ procedure Set_Output(File : in File_Type);
+ procedure Set_Error (File : in File_Type);
+
+16
+ function Standard_Input return File_Type;
+ function Standard_Output return File_Type;
+ function Standard_Error return File_Type;
+
+17
+ function Current_Input return File_Type;
+ function Current_Output return File_Type;
+ function Current_Error return File_Type;
+
+18
+ type File_Access is access constant File_Type;
+
+19
+ function Standard_Input return File_Access;
+ function Standard_Output return File_Access;
+ function Standard_Error return File_Access;
+
+20
+ function Current_Input return File_Access;
+ function Current_Output return File_Access;
+ function Current_Error return File_Access;
+
+21/1
+ {8652/00518652/0051} {AI95-00057-01AI95-00057-01} --Buffer control
+ procedure Flush (File : in File_Type);
+ procedure Flush;
+
+22
+ -- Specification of line and page lengths
+
+23
+ procedure Set_Line_Length(File : in File_Type; To : in Count);
+ procedure Set_Line_Length(To : in Count);
+
+24
+ procedure Set_Page_Length(File : in File_Type; To : in Count);
+ procedure Set_Page_Length(To : in Count);
+
+25
+ function Line_Length(File : in File_Type) return Count;
+ function Line_Length return Count;
+
+26
+ function Page_Length(File : in File_Type) return Count;
+ function Page_Length return Count;
+
+27
+ -- Column, Line, and Page Control
+
+28
+ procedure New_Line (File : in File_Type;
+ Spacing : in Positive_Count := 1);
+ procedure New_Line (Spacing : in Positive_Count := 1);
+
+29
+ procedure Skip_Line (File : in File_Type;
+ Spacing : in Positive_Count := 1);
+ procedure Skip_Line (Spacing : in Positive_Count := 1);
+
+30
+ function End_Of_Line(File : in File_Type) return Boolean;
+ function End_Of_Line return Boolean;
+
+31
+ procedure New_Page (File : in File_Type);
+ procedure New_Page;
+
+32
+ procedure Skip_Page (File : in File_Type);
+ procedure Skip_Page;
+
+33
+ function End_Of_Page(File : in File_Type) return Boolean;
+ function End_Of_Page return Boolean;
+
+34
+ function End_Of_File(File : in File_Type) return Boolean;
+ function End_Of_File return Boolean;
+
+35
+ procedure Set_Col (File : in File_Type; To : in Positive_Count);
+ procedure Set_Col (To : in Positive_Count);
+
+36
+ procedure Set_Line(File : in File_Type; To : in Positive_Count);
+ procedure Set_Line(To : in Positive_Count);
+
+37
+ function Col (File : in File_Type) return Positive_Count;
+ function Col return Positive_Count;
+
+38
+ function Line(File : in File_Type) return Positive_Count;
+ function Line return Positive_Count;
+
+39
+ function Page(File : in File_Type) return Positive_Count;
+ function Page return Positive_Count;
+
+40
+ -- Character Input-Output
+
+41
+ procedure Get(File : in File_Type; Item : out Character);
+ procedure Get(Item : out Character);
+
+42
+ procedure Put(File : in File_Type; Item : in Character);
+ procedure Put(Item : in Character);
+
+43
+ procedure Look_Ahead (File : in File_Type;
+ Item : out Character;
+ End_Of_Line : out Boolean);
+ procedure Look_Ahead (Item : out Character;
+ End_Of_Line : out Boolean);
+
+44
+ procedure Get_Immediate(File : in File_Type;
+ Item : out Character);
+ procedure Get_Immediate(Item : out Character);
+
+45
+ procedure Get_Immediate(File : in File_Type;
+ Item : out Character;
+ Available : out Boolean);
+ procedure Get_Immediate(Item : out Character;
+ Available : out Boolean);
+
+46
+ -- String Input-Output
+
+47
+ procedure Get(File : in File_Type; Item : out String);
+ procedure Get(Item : out String);
+
+48
+ procedure Put(File : in File_Type; Item : in String);
+ procedure Put(Item : in String);
+
+49
+ procedure Get_Line(File : in File_Type;
+ Item : out String;
+ Last : out Natural);
+ procedure Get_Line(Item : out String; Last : out Natural);
+
+49.1/2
+ {AI95-00301-01AI95-00301-01} function Get_Line(File : in File_Type) return String;
+ function Get_Line return String;
+
+50
+ procedure Put_Line(File : in File_Type; Item : in String);
+ procedure Put_Line(Item : in String);
+
+51
+ -- Generic packages for Input-Output of Integer Types
+
+52
+ generic
+ type Num is range <>;
+ package Integer_IO is
+
+53
+ Default_Width : Field := Num'Width;
+ Default_Base : Number_Base := 10;
+
+54
+ procedure Get(File : in File_Type;
+ Item : out Num;
+ Width : in Field := 0);
+ procedure Get(Item : out Num;
+ Width : in Field := 0);
+
+55
+ procedure Put(File : in File_Type;
+ Item : in Num;
+ Width : in Field := Default_Width;
+ Base : in Number_Base := Default_Base);
+ procedure Put(Item : in Num;
+ Width : in Field := Default_Width;
+ Base : in Number_Base := Default_Base);
+ procedure Get(From : in String;
+ Item : out Num;
+ Last : out Positive);
+ procedure Put(To : out String;
+ Item : in Num;
+ Base : in Number_Base := Default_Base);
+
+56
+ end Integer_IO;
+
+57
+ generic
+ type Num is mod <>;
+ package Modular_IO is
+
+58
+ Default_Width : Field := Num'Width;
+ Default_Base : Number_Base := 10;
+
+59
+ procedure Get(File : in File_Type;
+ Item : out Num;
+ Width : in Field := 0);
+ procedure Get(Item : out Num;
+ Width : in Field := 0);
+
+60
+ procedure Put(File : in File_Type;
+ Item : in Num;
+ Width : in Field := Default_Width;
+ Base : in Number_Base := Default_Base);
+ procedure Put(Item : in Num;
+ Width : in Field := Default_Width;
+ Base : in Number_Base := Default_Base);
+ procedure Get(From : in String;
+ Item : out Num;
+ Last : out Positive);
+ procedure Put(To : out String;
+ Item : in Num;
+ Base : in Number_Base := Default_Base);
+
+61
+ end Modular_IO;
+
+62
+ -- Generic packages for Input-Output of Real Types
+
+63
+ generic
+ type Num is digits <>;
+ package Float_IO is
+
+64
+ Default_Fore : Field := 2;
+ Default_Aft : Field := Num'Digits-1;
+ Default_Exp : Field := 3;
+
+65
+ procedure Get(File : in File_Type;
+ Item : out Num;
+ Width : in Field := 0);
+ procedure Get(Item : out Num;
+ Width : in Field := 0);
+
+66
+ procedure Put(File : in File_Type;
+ Item : in Num;
+ Fore : in Field := Default_Fore;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+ procedure Put(Item : in Num;
+ Fore : in Field := Default_Fore;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+
+67
+ procedure Get(From : in String;
+ Item : out Num;
+ Last : out Positive);
+ procedure Put(To : out String;
+ Item : in Num;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+ end Float_IO;
+
+68
+ generic
+ type Num is delta <>;
+ package Fixed_IO is
+
+69
+ Default_Fore : Field := Num'Fore;
+ Default_Aft : Field := Num'Aft;
+ Default_Exp : Field := 0;
+
+70
+ procedure Get(File : in File_Type;
+ Item : out Num;
+ Width : in Field := 0);
+ procedure Get(Item : out Num;
+ Width : in Field := 0);
+
+71
+ procedure Put(File : in File_Type;
+ Item : in Num;
+ Fore : in Field := Default_Fore;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+ procedure Put(Item : in Num;
+ Fore : in Field := Default_Fore;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+
+72
+ procedure Get(From : in String;
+ Item : out Num;
+ Last : out Positive);
+ procedure Put(To : out String;
+ Item : in Num;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+ end Fixed_IO;
+
+73
+ generic
+ type Num is delta <> digits <>;
+ package Decimal_IO is
+
+74
+ Default_Fore : Field := Num'Fore;
+ Default_Aft : Field := Num'Aft;
+ Default_Exp : Field := 0;
+
+75
+ procedure Get(File : in File_Type;
+ Item : out Num;
+ Width : in Field := 0);
+ procedure Get(Item : out Num;
+ Width : in Field := 0);
+
+76
+ procedure Put(File : in File_Type;
+ Item : in Num;
+ Fore : in Field := Default_Fore;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+ procedure Put(Item : in Num;
+ Fore : in Field := Default_Fore;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+
+77
+ procedure Get(From : in String;
+ Item : out Num;
+ Last : out Positive);
+ procedure Put(To : out String;
+ Item : in Num;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+ end Decimal_IO;
+
+78
+ -- Generic package for Input-Output of Enumeration Types
+
+79
+ generic
+ type Enum is (<>);
+ package Enumeration_IO is
+
+80
+ Default_Width : Field := 0;
+ Default_Setting : Type_Set := Upper_Case;
+
+81
+ procedure Get(File : in File_Type;
+ Item : out Enum);
+ procedure Get(Item : out Enum);
+
+82
+ procedure Put(File : in File_Type;
+ Item : in Enum;
+ Width : in Field := Default_Width;
+ Set : in Type_Set := Default_Setting);
+ procedure Put(Item : in Enum;
+ Width : in Field := Default_Width;
+ Set : in Type_Set := Default_Setting);
+
+83
+ procedure Get(From : in String;
+ Item : out Enum;
+ Last : out Positive);
+ procedure Put(To : out String;
+ Item : in Enum;
+ Set : in Type_Set := Default_Setting);
+ end Enumeration_IO;
+
+84
+ -- Exceptions
+
+85
+ Status_Error : exception renames IO_Exceptions.Status_Error;
+ Mode_Error : exception renames IO_Exceptions.Mode_Error;
+ Name_Error : exception renames IO_Exceptions.Name_Error;
+ Use_Error : exception renames IO_Exceptions.Use_Error;
+ Device_Error : exception renames IO_Exceptions.Device_Error;
+ End_Error : exception renames IO_Exceptions.End_Error;
+ Data_Error : exception renames IO_Exceptions.Data_Error;
+ Layout_Error : exception renames IO_Exceptions.Layout_Error;
+ private
+ ... -- not specified by the language
+ end Ada.Text_IO;
+
+86/2
+{AI95-00360-01AI95-00360-01} The type File_Type needs finalization (see
+*note 7.6::).
+
+ _Incompatibilities With Ada 83_
+
+86.a
+ Append_File is a new element of enumeration type File_Mode.
+
+ _Extensions to Ada 83_
+
+86.b
+ Get_Immediate, Look_Ahead, the subprograms for dealing with
+ standard error, the type File_Access and its associated
+ subprograms, and the generic packages Modular_IO and
+ Decimal_IO are new in Ada 95.
+
+ _Incompatibilities With Ada 95_
+
+86.c/2
+ {AI95-00360-01AI95-00360-01} Amendment Correction:
+ Text_IO.File_Type is defined to need finalization. If the
+ restriction No_Nested_Finalization (see *note D.7::) applies
+ to the partition, and File_Type does not have a controlled
+ part, it will not be allowed in local objects in Ada 2005
+ whereas it would be allowed in original Ada 95. Such code is
+ not portable, as another Ada compiler may have a controlled
+ part in File_Type, and thus would be illegal.
+
+ _Wording Changes from Ada 95_
+
+86.d/2
+ {8652/00518652/0051} {AI95-00057-01AI95-00057-01} Corrigendum:
+ Corrected the parameter mode of Flush; otherwise it could not
+ be used on Standard_Output.
+
+86.e/2
+ {AI95-00301-01AI95-00301-01} The Text_IO.Get_Line functions
+ are new; they are described in *note A.10.7::, "*note A.10.7::
+ Input-Output of Characters and Strings".
+
+\1f
+File: aarm2012.info, Node: A.10.2, Next: A.10.3, Prev: A.10.1, Up: A.10
+
+A.10.2 Text File Management
+---------------------------
+
+ _Static Semantics_
+
+1
+The only allowed file modes for text files are the modes In_File,
+Out_File, and Append_File. The subprograms given in subclause *note
+A.8.2:: for the control of external files, and the function End_Of_File
+given in subclause *note A.8.3:: for sequential input-output, are also
+available for text files. There is also a version of End_Of_File that
+refers to the current default input file. For text files, the
+procedures have the following additional effects:
+
+2
+ * For the procedures Create and Open: After a file with mode Out_File
+ or Append_File is opened, the page length and line length are
+ unbounded (both have the conventional value zero). After a file
+ (of any mode) is opened, the current column, current line, and
+ current page numbers are set to one. If the mode is Append_File,
+ it is implementation defined whether a page terminator will
+ separate preexisting text in the file from the new text to be
+ written.
+
+2.a
+ Reason: For a file with mode Append_File, although it may seem
+ more sensible for Open to set the current column, line, and
+ page number based on the number of pages in the file, the
+ number of lines on the last page, and the number of columns in
+ the last line, we rejected this approach because of
+ implementation costs; it would require the implementation to
+ scan the file before doing the append, or to do processing
+ that would be equivalent in effect.
+
+2.b
+ For similar reasons, there is no requirement to erase the last
+ page terminator of the file, nor to insert an explicit page
+ terminator in the case when the final page terminator of a
+ file is represented implicitly by the implementation.
+
+3
+ * For the procedure Close: If the file has the current mode Out_File
+ or Append_File, has the effect of calling New_Page, unless the
+ current page is already terminated; then outputs a file terminator.
+
+4
+ * For the procedure Reset: If the file has the current mode Out_File
+ or Append_File, has the effect of calling New_Page, unless the
+ current page is already terminated; then outputs a file terminator.
+ The current column, line, and page numbers are set to one, and the
+ line and page lengths to Unbounded. If the new mode is
+ Append_File, it is implementation defined whether a page terminator
+ will separate preexisting text in the file from the new text to be
+ written.
+
+4.a
+ Reason: The behavior of Reset should be similar to closing a
+ file and reopening it with the given mode
+
+5
+The exception Mode_Error is propagated by the procedure Reset upon an
+attempt to change the mode of a file that is the current default input
+file, the current default output file, or the current default error
+file.
+
+ NOTES
+
+6
+ 27 An implementation can define the Form parameter of Create and
+ Open to control effects including the following:
+
+7
+ * the interpretation of line and column numbers for an
+ interactive file, and
+
+8
+ * the interpretation of text formats in a file created by a
+ foreign program.
+
+\1f
+File: aarm2012.info, Node: A.10.3, Next: A.10.4, Prev: A.10.2, Up: A.10
+
+A.10.3 Default Input, Output, and Error Files
+---------------------------------------------
+
+ _Static Semantics_
+
+1
+The following subprograms provide for the control of the particular
+default files that are used when a file parameter is omitted from a Get,
+Put, or other operation of text input-output described below, or when
+application-dependent error-related text is to be output.
+
+2
+ procedure Set_Input(File : in File_Type);
+
+3
+ Operates on a file of mode In_File. Sets the current default
+ input file to File.
+
+4
+ The exception Status_Error is propagated if the given file is
+ not open. The exception Mode_Error is propagated if the mode
+ of the given file is not In_File.
+
+5
+ procedure Set_Output(File : in File_Type);
+ procedure Set_Error (File : in File_Type);
+
+6
+ Each operates on a file of mode Out_File or Append_File.
+ Set_Output sets the current default output file to File.
+ Set_Error sets the current default error file to File. The
+ exception Status_Error is propagated if the given file is not
+ open. The exception Mode_Error is propagated if the mode of
+ the given file is not Out_File or Append_File.
+
+7
+ function Standard_Input return File_Type;
+ function Standard_Input return File_Access;
+
+8
+ Returns the standard input file (see *note A.10::), or an
+ access value designating the standard input file,
+ respectively.
+
+9
+ function Standard_Output return File_Type;
+ function Standard_Output return File_Access;
+
+10
+ Returns the standard output file (see *note A.10::) or an
+ access value designating the standard output file,
+ respectively.
+
+11
+ function Standard_Error return File_Type;
+ function Standard_Error return File_Access;
+
+12/1
+ {8652/00528652/0052} {AI95-00194-01AI95-00194-01} Returns the
+ standard error file (see *note A.10::), or an access value
+ designating the standard error file, respectively.
+
+13
+The Form strings implicitly associated with the opening of
+Standard_Input, Standard_Output, and Standard_Error at the start of
+program execution are implementation defined.
+
+14
+ function Current_Input return File_Type;
+ function Current_Input return File_Access;
+
+15
+ Returns the current default input file, or an access value
+ designating the current default input file, respectively.
+
+16
+ function Current_Output return File_Type;
+ function Current_Output return File_Access;
+
+17
+ Returns the current default output file, or an access value
+ designating the current default output file, respectively.
+
+18
+ function Current_Error return File_Type;
+ function Current_Error return File_Access;
+
+19
+ Returns the current default error file, or an access value
+ designating the current default error file, respectively.
+
+20/1
+ {8652/00518652/0051} {AI95-00057-01AI95-00057-01} procedure Flush (File : in File_Type);
+ procedure Flush;
+
+21
+ The effect of Flush is the same as the corresponding
+ subprogram in Streams.Stream_IO (see *note A.12.1::). If File
+ is not explicitly specified, Current_Output is used.
+
+ _Erroneous Execution_
+
+22/1
+{8652/00538652/0053} {AI95-00063-01AI95-00063-01} The execution of a
+program is erroneous if it invokes an operation on a current default
+input, default output, or default error file, and if the corresponding
+file object is closed or no longer exists.
+
+22.a.1/1
+ Ramification: {8652/00538652/0053}
+ {AI95-00063-01AI95-00063-01} Closing a default file, then
+ setting the default file to another open file before accessing
+ it is not erroneous.
+
+23/1
+This paragraph was deleted.{8652/00538652/0053}
+{AI95-00063-01AI95-00063-01}
+
+ NOTES
+
+24
+ 28 The standard input, standard output, and standard error files
+ cannot be opened, closed, reset, or deleted, because the parameter
+ File of the corresponding procedures has the mode in out.
+
+25
+ 29 The standard input, standard output, and standard error files
+ are different file objects, but not necessarily different external
+ files.
+
+ _Wording Changes from Ada 95_
+
+25.a/2
+ {8652/00518652/0051} {AI95-00057-01AI95-00057-01} Corrigendum:
+ Corrected the parameter mode of Flush; otherwise it could not
+ be used on Standard_Output.
+
+25.b/2
+ {8652/00528652/0052} {AI95-00194-01AI95-00194-01} Corrigendum:
+ Corrected Standard_Error so it refers to the correct file.
+
+25.c/2
+ {8652/00538652/0053} {AI95-00063-01AI95-00063-01} Corrigendum:
+ Clarified that execution is erroneous only when a closed
+ default file is accessed.
+
+\1f
+File: aarm2012.info, Node: A.10.4, Next: A.10.5, Prev: A.10.3, Up: A.10
+
+A.10.4 Specification of Line and Page Lengths
+---------------------------------------------
+
+ _Static Semantics_
+
+1
+The subprograms described in this subclause are concerned with the line
+and page structure of a file of mode Out_File or Append_File. They
+operate either on the file given as the first parameter, or, in the
+absence of such a file parameter, on the current default output file.
+They provide for output of text with a specified maximum line length or
+page length. In these cases, line and page terminators are output
+implicitly and automatically when needed. When line and page lengths
+are unbounded (that is, when they have the conventional value zero), as
+in the case of a newly opened file, new lines and new pages are only
+started when explicitly called for.
+
+2
+In all cases, the exception Status_Error is propagated if the file to be
+used is not open; the exception Mode_Error is propagated if the mode of
+the file is not Out_File or Append_File.
+
+3
+ procedure Set_Line_Length(File : in File_Type; To : in Count);
+ procedure Set_Line_Length(To : in Count);
+
+4
+ Sets the maximum line length of the specified output or append
+ file to the number of characters specified by To. The value
+ zero for To specifies an unbounded line length.
+
+4.a
+ Ramification: The setting does not affect the lengths of lines
+ in the existing file, rather it only influences subsequent
+ output operations.
+
+5
+ The exception Use_Error is propagated if the specified line
+ length is inappropriate for the associated external file.
+
+6
+ procedure Set_Page_Length(File : in File_Type; To : in Count);
+ procedure Set_Page_Length(To : in Count);
+
+7
+ Sets the maximum page length of the specified output or append
+ file to the number of lines specified by To. The value zero
+ for To specifies an unbounded page length.
+
+8
+ The exception Use_Error is propagated if the specified page
+ length is inappropriate for the associated external file.
+
+9
+ function Line_Length(File : in File_Type) return Count;
+ function Line_Length return Count;
+
+10
+ Returns the maximum line length currently set for the
+ specified output or append file, or zero if the line length is
+ unbounded.
+
+11
+ function Page_Length(File : in File_Type) return Count;
+ function Page_Length return Count;
+
+12
+ Returns the maximum page length currently set for the
+ specified output or append file, or zero if the page length is
+ unbounded.
+
+\1f
+File: aarm2012.info, Node: A.10.5, Next: A.10.6, Prev: A.10.4, Up: A.10
+
+A.10.5 Operations on Columns, Lines, and Pages
+----------------------------------------------
+
+ _Static Semantics_
+
+1
+The subprograms described in this subclause provide for explicit control
+of line and page structure; they operate either on the file given as the
+first parameter, or, in the absence of such a file parameter, on the
+appropriate (input or output) current default file. The exception
+Status_Error is propagated by any of these subprograms if the file to be
+used is not open.
+
+2
+ procedure New_Line(File : in File_Type; Spacing : in Positive_Count := 1);
+ procedure New_Line(Spacing : in Positive_Count := 1);
+
+3
+ Operates on a file of mode Out_File or Append_File.
+
+4
+ For a Spacing of one: Outputs a line terminator and sets the
+ current column number to one. Then increments the current
+ line number by one, except in the case that the current line
+ number is already greater than or equal to the maximum page
+ length, for a bounded page length; in that case a page
+ terminator is output, the current page number is incremented
+ by one, and the current line number is set to one.
+
+5
+ For a Spacing greater than one, the above actions are
+ performed Spacing times.
+
+6
+ The exception Mode_Error is propagated if the mode is not
+ Out_File or Append_File.
+
+7
+ procedure Skip_Line(File : in File_Type; Spacing : in Positive_Count := 1);
+ procedure Skip_Line(Spacing : in Positive_Count := 1);
+
+8
+ Operates on a file of mode In_File.
+
+9
+ For a Spacing of one: Reads and discards all characters until
+ a line terminator has been read, and then sets the current
+ column number to one. If the line terminator is not
+ immediately followed by a page terminator, the current line
+ number is incremented by one. Otherwise, if the line
+ terminator is immediately followed by a page terminator, then
+ the page terminator is skipped, the current page number is
+ incremented by one, and the current line number is set to one.
+
+10
+ For a Spacing greater than one, the above actions are
+ performed Spacing times.
+
+11
+ The exception Mode_Error is propagated if the mode is not
+ In_File. The exception End_Error is propagated if an attempt
+ is made to read a file terminator.
+
+12
+ function End_Of_Line(File : in File_Type) return Boolean;
+ function End_Of_Line return Boolean;
+
+13/3
+ {AI05-0264-1AI05-0264-1} Operates on a file of mode In_File.
+ Returns True if a line terminator or a file terminator is
+ next; otherwise, returns False.
+
+14
+ The exception Mode_Error is propagated if the mode is not
+ In_File.
+
+15
+ procedure New_Page(File : in File_Type);
+ procedure New_Page;
+
+16
+ Operates on a file of mode Out_File or Append_File. Outputs a
+ line terminator if the current line is not terminated, or if
+ the current page is empty (that is, if the current column and
+ line numbers are both equal to one). Then outputs a page
+ terminator, which terminates the current page. Adds one to
+ the current page number and sets the current column and line
+ numbers to one.
+
+17
+ The exception Mode_Error is propagated if the mode is not
+ Out_File or Append_File.
+
+18
+ procedure Skip_Page(File : in File_Type);
+ procedure Skip_Page;
+
+19
+ Operates on a file of mode In_File. Reads and discards all
+ characters and line terminators until a page terminator has
+ been read. Then adds one to the current page number, and sets
+ the current column and line numbers to one.
+
+20
+ The exception Mode_Error is propagated if the mode is not
+ In_File. The exception End_Error is propagated if an attempt
+ is made to read a file terminator.
+
+21
+ function End_Of_Page(File : in File_Type) return Boolean;
+ function End_Of_Page return Boolean;
+
+22/3
+ {AI05-0264-1AI05-0264-1} Operates on a file of mode In_File.
+ Returns True if the combination of a line terminator and a
+ page terminator is next, or if a file terminator is next;
+ otherwise, returns False.
+
+23
+ The exception Mode_Error is propagated if the mode is not
+ In_File.
+
+24
+ function End_Of_File(File : in File_Type) return Boolean;
+ function End_Of_File return Boolean;
+
+25/3
+ {AI05-0264-1AI05-0264-1} Operates on a file of mode In_File.
+ Returns True if a file terminator is next, or if the
+ combination of a line, a page, and a file terminator is next;
+ otherwise, returns False.
+
+26
+ The exception Mode_Error is propagated if the mode is not
+ In_File.
+
+27
+The following subprograms provide for the control of the current
+position of reading or writing in a file. In all cases, the default
+file is the current output file.
+
+28
+ procedure Set_Col(File : in File_Type; To : in Positive_Count);
+ procedure Set_Col(To : in Positive_Count);
+
+29
+ If the file mode is Out_File or Append_File:
+
+30
+ * If the value specified by To is greater than the current
+ column number, outputs spaces, adding one to the current
+ column number after each space, until the current column
+ number equals the specified value. If the value
+ specified by To is equal to the current column number,
+ there is no effect. If the value specified by To is less
+ than the current column number, has the effect of calling
+ New_Line (with a spacing of one), then outputs (To - 1)
+ spaces, and sets the current column number to the
+ specified value.
+
+31
+ * The exception Layout_Error is propagated if the value
+ specified by To exceeds Line_Length when the line length
+ is bounded (that is, when it does not have the
+ conventional value zero).
+
+32
+ If the file mode is In_File:
+
+33
+ * Reads (and discards) individual characters, line
+ terminators, and page terminators, until the next
+ character to be read has a column number that equals the
+ value specified by To; there is no effect if the current
+ column number already equals this value. Each transfer
+ of a character or terminator maintains the current
+ column, line, and page numbers in the same way as a Get
+ procedure (see *note A.10.6::). (Short lines will be
+ skipped until a line is reached that has a character at
+ the specified column position.)
+
+34
+ * The exception End_Error is propagated if an attempt is
+ made to read a file terminator.
+
+35
+ procedure Set_Line(File : in File_Type; To : in Positive_Count);
+ procedure Set_Line(To : in Positive_Count);
+
+36
+ If the file mode is Out_File or Append_File:
+
+37/3
+ * {AI05-0038-1AI05-0038-1} If the value specified by To is
+ greater than the current line number, has the effect of
+ repeatedly calling New_Line (with a spacing of one),
+ until the current line number equals the specified value.
+ If the value specified by To is equal to the current line
+ number, there is no effect. If the value specified by To
+ is less than the current line number, has the effect of
+ calling New_Page followed, if To is greater than 1, by a
+ call of New_Line with a spacing equal to (To - 1).
+
+38
+ * The exception Layout_Error is propagated if the value
+ specified by To exceeds Page_Length when the page length
+ is bounded (that is, when it does not have the
+ conventional value zero).
+
+39
+ If the mode is In_File:
+
+40
+ * Has the effect of repeatedly calling Skip_Line (with a
+ spacing of one), until the current line number equals the
+ value specified by To; there is no effect if the current
+ line number already equals this value. (Short pages will
+ be skipped until a page is reached that has a line at the
+ specified line position.)
+
+41
+ * The exception End_Error is propagated if an attempt is
+ made to read a file terminator.
+
+42
+ function Col(File : in File_Type) return Positive_Count;
+ function Col return Positive_Count;
+
+43
+ Returns the current column number.
+
+44
+ The exception Layout_Error is propagated if this number
+ exceeds Count'Last.
+
+45
+ function Line(File : in File_Type) return Positive_Count;
+ function Line return Positive_Count;
+
+46
+ Returns the current line number.
+
+47
+ The exception Layout_Error is propagated if this number
+ exceeds Count'Last.
+
+48
+ function Page(File : in File_Type) return Positive_Count;
+ function Page return Positive_Count;
+
+49
+ Returns the current page number.
+
+50
+ The exception Layout_Error is propagated if this number
+ exceeds Count'Last.
+
+51
+The column number, line number, or page number are allowed to exceed
+Count'Last (as a consequence of the input or output of sufficiently many
+characters, lines, or pages). These events do not cause any exception
+to be propagated. However, a call of Col, Line, or Page propagates the
+exception Layout_Error if the corresponding number exceeds Count'Last.
+
+ NOTES
+
+52
+ 30 A page terminator is always skipped whenever the preceding line
+ terminator is skipped. An implementation may represent the
+ combination of these terminators by a single character, provided
+ that it is properly recognized on input.
+
+ _Inconsistencies With Ada 2005_
+
+52.a/3
+ {AI05-0038-1AI05-0038-1} Correction: Fixed a glitch in
+ Set_Line such that we could have called New_Line(0), which
+ would have to raise Constraint_Error. It's now defined to
+ work. The bug occurred in Ada 95 and Ada 2005. It's very
+ unlikely that any real programs depend on this exception being
+ raised.
+
+\1f
+File: aarm2012.info, Node: A.10.6, Next: A.10.7, Prev: A.10.5, Up: A.10
+
+A.10.6 Get and Put Procedures
+-----------------------------
+
+ _Static Semantics_
+
+1
+The procedures Get and Put for items of the type Character, String,
+numeric types, and enumeration types are described in subsequent
+subclauses. Features of these procedures that are common to most of
+these types are described in this subclause. The Get and Put procedures
+for items of type Character and String deal with individual character
+values; the Get and Put procedures for numeric and enumeration types
+treat the items as lexical elements.
+
+2
+All procedures Get and Put have forms with a file parameter, written
+first. Where this parameter is omitted, the appropriate (input or
+output) current default file is understood to be specified. Each
+procedure Get operates on a file of mode In_File. Each procedure Put
+operates on a file of mode Out_File or Append_File.
+
+3
+All procedures Get and Put maintain the current column, line, and page
+numbers of the specified file: the effect of each of these procedures
+upon these numbers is the result of the effects of individual transfers
+of characters and of individual output or skipping of terminators. Each
+transfer of a character adds one to the current column number. Each
+output of a line terminator sets the current column number to one and
+adds one to the current line number. Each output of a page terminator
+sets the current column and line numbers to one and adds one to the
+current page number. For input, each skipping of a line terminator sets
+the current column number to one and adds one to the current line
+number; each skipping of a page terminator sets the current column and
+line numbers to one and adds one to the current page number. Similar
+considerations apply to the procedures Get_Line, Put_Line, and Set_Col.
+
+4
+Several Get and Put procedures, for numeric and enumeration types, have
+format parameters which specify field lengths; these parameters are of
+the nonnegative subtype Field of the type Integer.
+
+5/2
+{AI95-00223-01AI95-00223-01} Input-output of enumeration values uses the
+syntax of the corresponding lexical elements. Any Get procedure for an
+enumeration type begins by skipping any leading blanks, or line or page
+terminators. A blank is defined as a space or a horizontal tabulation
+character. Next, characters are input only so long as the sequence
+input is an initial sequence of an identifier or of a character literal
+(in particular, input ceases when a line terminator is encountered).
+The character or line terminator that causes input to cease remains
+available for subsequent input.
+
+6
+For a numeric type, the Get procedures have a format parameter called
+Width. If the value given for this parameter is zero, the Get procedure
+proceeds in the same manner as for enumeration types, but using the
+syntax of numeric literals instead of that of enumeration literals. If
+a nonzero value is given, then exactly Width characters are input, or
+the characters up to a line terminator, whichever comes first; any
+skipped leading blanks are included in the count. The syntax used for
+numeric literals is an extended syntax that allows a leading sign (but
+no intervening blanks, or line or page terminators) and that also allows
+(for real types) an integer literal as well as forms that have digits
+only before the point or only after the point.
+
+7
+Any Put procedure, for an item of a numeric or an enumeration type,
+outputs the value of the item as a numeric literal, identifier, or
+character literal, as appropriate. This is preceded by leading spaces
+if required by the format parameters Width or Fore (as described in
+later subclauses), and then a minus sign for a negative value; for an
+enumeration type, the spaces follow instead of leading. The format
+given for a Put procedure is overridden if it is insufficiently wide, by
+using the minimum needed width.
+
+8
+Two further cases arise for Put procedures for numeric and enumeration
+types, if the line length of the specified output file is bounded (that
+is, if it does not have the conventional value zero). If the number of
+characters to be output does not exceed the maximum line length, but is
+such that they cannot fit on the current line, starting from the current
+column, then (in effect) New_Line is called (with a spacing of one)
+before output of the item. Otherwise, if the number of characters
+exceeds the maximum line length, then the exception Layout_Error is
+propagated and nothing is output.
+
+9
+The exception Status_Error is propagated by any of the procedures Get,
+Get_Line, Put, and Put_Line if the file to be used is not open. The
+exception Mode_Error is propagated by the procedures Get and Get_Line if
+the mode of the file to be used is not In_File; and by the procedures
+Put and Put_Line, if the mode is not Out_File or Append_File.
+
+10
+The exception End_Error is propagated by a Get procedure if an attempt
+is made to skip a file terminator. The exception Data_Error is
+propagated by a Get procedure if the sequence finally input is not a
+lexical element corresponding to the type, in particular if no
+characters were input; for this test, leading blanks are ignored; for an
+item of a numeric type, when a sign is input, this rule applies to the
+succeeding numeric literal. The exception Layout_Error is propagated by
+a Put procedure that outputs to a parameter of type String, if the
+length of the actual string is insufficient for the output of the item.
+
+ _Examples_
+
+11
+In the examples, here and in subclauses *note A.10.8:: and *note
+A.10.9::, the string quotes and the lower case letter b are not
+transferred: they are shown only to reveal the layout and spaces.
+
+12
+ N : Integer;
+ ...
+ Get(N);
+
+13
+ -- Characters at input Sequence input Value of N
+
+ -- bb-12535b -12535 -12535
+ -- bb12_535e1b 12_535e1 125350
+ -- bb12_535e; 12_535e (none) Data_Error raised
+
+14
+Example of overridden width parameter:
+
+15
+ Put(Item => -23, Width => 2); -- "-23"
+
+ _Wording Changes from Ada 95_
+
+15.a/2
+ {AI95-00223-01AI95-00223-01} Removed conflicting text
+ describing the skipping of blanks for a Get procedure.
+
+\1f
+File: aarm2012.info, Node: A.10.7, Next: A.10.8, Prev: A.10.6, Up: A.10
+
+A.10.7 Input-Output of Characters and Strings
+---------------------------------------------
+
+ _Static Semantics_
+
+1
+For an item of type Character the following procedures are provided:
+
+2
+ procedure Get(File : in File_Type; Item : out Character);
+ procedure Get(Item : out Character);
+
+3
+ After skipping any line terminators and any page terminators,
+ reads the next character from the specified input file and
+ returns the value of this character in the out parameter Item.
+
+4
+ The exception End_Error is propagated if an attempt is made to
+ skip a file terminator.
+
+5
+ procedure Put(File : in File_Type; Item : in Character);
+ procedure Put(Item : in Character);
+
+6
+ If the line length of the specified output file is bounded
+ (that is, does not have the conventional value zero), and the
+ current column number exceeds it, has the effect of calling
+ New_Line with a spacing of one. Then, or otherwise, outputs
+ the given character to the file.
+
+7
+ procedure Look_Ahead (File : in File_Type;
+ Item : out Character;
+ End_Of_Line : out Boolean);
+ procedure Look_Ahead (Item : out Character;
+ End_Of_Line : out Boolean);
+
+8/3
+ {AI05-0038-1AI05-0038-1} {AI05-0264-1AI05-0264-1} Status_Error
+ is propagated if the file is not open. Mode_Error is
+ propagated if the mode of the file is not In_File. Sets
+ End_Of_Line to True if at end of line, including if at end of
+ page or at end of file; in each of these cases the value of
+ Item is not specified. Otherwise, End_Of_Line is set to False
+ and Item is set to the next character (without consuming it)
+ from the file.
+
+9
+ procedure Get_Immediate(File : in File_Type;
+ Item : out Character);
+ procedure Get_Immediate(Item : out Character);
+
+10/3
+ {AI05-0038-1AI05-0038-1} Reads the next character, either
+ control or graphic, from the specified File or the default
+ input file. Status_Error is propagated if the file is not
+ open. Mode_Error is propagated if the mode of the file is not
+ In_File. End_Error is propagated if at the end of the file.
+ The current column, line and page numbers for the file are not
+ affected.
+
+11
+ procedure Get_Immediate(File : in File_Type;
+ Item : out Character;
+ Available : out Boolean);
+ procedure Get_Immediate(Item : out Character;
+ Available : out Boolean);
+
+12/3
+ {AI05-0038-1AI05-0038-1} If a character, either control or
+ graphic, is available from the specified File or the default
+ input file, then the character is read; Available is True and
+ Item contains the value of this character. If a character is
+ not available, then Available is False and the value of Item
+ is not specified. Status_Error is propagated if the file is
+ not open. Mode_Error is propagated if the mode of the file is
+ not In_File. End_Error is propagated if at the end of the
+ file. The current column, line and page numbers for the file
+ are not affected.
+
+13/2
+{AI95-00301-01AI95-00301-01} For an item of type String the following
+subprograms are provided:
+
+14
+ procedure Get(File : in File_Type; Item : out String);
+ procedure Get(Item : out String);
+
+15
+ Determines the length of the given string and attempts that
+ number of Get operations for successive characters of the
+ string (in particular, no operation is performed if the string
+ is null).
+
+16
+ procedure Put(File : in File_Type; Item : in String);
+ procedure Put(Item : in String);
+
+17
+ Determines the length of the given string and attempts that
+ number of Put operations for successive characters of the
+ string (in particular, no operation is performed if the string
+ is null).
+
+17.1/2
+ function Get_Line(File : in File_Type) return String;
+ function Get_Line return String;
+
+17.2/2
+ {AI95-00301-01AI95-00301-01} Returns a result string
+ constructed by reading successive characters from the
+ specified input file, and assigning them to successive
+ characters of the result string. The result string has a
+ lower bound of 1 and an upper bound of the number of
+ characters read. Reading stops when the end of the line is
+ met; Skip_Line is then (in effect) called with a spacing of 1.
+
+17.3/2
+ {AI95-00301-01AI95-00301-01} Constraint_Error is raised if the
+ length of the line exceeds Positive'Last; in this case, the
+ line number and page number are unchanged, and the column
+ number is unspecified but no less than it was before the call.
+ The exception End_Error is propagated if an attempt is made to
+ skip a file terminator.
+
+17.a/2
+ Ramification: {AI95-00301-01AI95-00301-01} Precisely what is
+ left in the file is unspecified if Constraint_Error is raised
+ because the line doesn't fit in a String; it should be
+ consistent with column number. This allows implementers to
+ use whatever buffering scheme makes sense. But the line
+ terminator is not skipped in this case.
+
+18
+ procedure Get_Line(File : in File_Type;
+ Item : out String;
+ Last : out Natural);
+ procedure Get_Line(Item : out String;
+ Last : out Natural);
+
+19
+ Reads successive characters from the specified input file and
+ assigns them to successive characters of the specified string.
+ Reading stops if the end of the string is met. Reading also
+ stops if the end of the line is met before meeting the end of
+ the string; in this case Skip_Line is (in effect) called with
+ a spacing of 1. The values of characters not assigned are not
+ specified.
+
+20
+ If characters are read, returns in Last the index value such
+ that Item(Last) is the last character assigned (the index of
+ the first character assigned is Item'First). If no characters
+ are read, returns in Last an index value that is one less than
+ Item'First. The exception End_Error is propagated if an
+ attempt is made to skip a file terminator.
+
+21
+ procedure Put_Line(File : in File_Type; Item : in String);
+ procedure Put_Line(Item : in String);
+
+22
+ Calls the procedure Put for the given string, and then the
+ procedure New_Line with a spacing of one.
+
+ _Implementation Advice_
+
+23
+The Get_Immediate procedures should be implemented with unbuffered
+input. For a device such as a keyboard, input should be "available" if
+a key has already been typed, whereas for a disk file, input should
+always be available except at end of file. For a file associated with a
+keyboard-like device, any line-editing features of the underlying
+operating system should be disabled during the execution of
+Get_Immediate.
+
+23.a/2
+ Implementation Advice: Get_Immediate should be implemented
+ with unbuffered input; input should be available immediately;
+ line-editing should be disabled.
+
+ NOTES
+
+24
+ 31 Get_Immediate can be used to read a single key from the
+ keyboard "immediately"; that is, without waiting for an end of
+ line. In a call of Get_Immediate without the parameter Available,
+ the caller will wait until a character is available.
+
+25
+ 32 In a literal string parameter of Put, the enclosing string
+ bracket characters are not output. Each doubled string bracket
+ character in the enclosed string is output as a single string
+ bracket character, as a consequence of the rule for string literals
+ (see *note 2.6::).
+
+26
+ 33 A string read by Get or written by Put can extend over several
+ lines. An implementation is allowed to assume that certain
+ external files do not contain page terminators, in which case
+ Get_Line and Skip_Line can return as soon as a line terminator is
+ read.
+
+ _Incompatibilities With Ada 95_
+
+26.a/3
+ {AI95-00301-01AI95-00301-01} {AI05-0005-1AI05-0005-1} The
+ Get_Line functions are added to Ada.Text_IO. If Ada.Text_IO is
+ referenced in a use_clause, and a function Get_Line is defined
+ in a package that is also referenced in a use_clause, the
+ user-defined Get_Line may no longer be use-visible, resulting
+ in errors. This should be rare and is easily fixed if it does
+ occur.
+
+ _Extensions to Ada 95_
+
+26.b/2
+ {AI95-00301-01AI95-00301-01} The Text_IO.Get_Line functions
+ are new.
+
+ _Wording Changes from Ada 2005_
+
+26.c/3
+ {AI05-0038-1AI05-0038-1} Correction: Added missing wording
+ about raising Status_Error to Look_Ahead and Get_Immediate.
+
+\1f
+File: aarm2012.info, Node: A.10.8, Next: A.10.9, Prev: A.10.7, Up: A.10
+
+A.10.8 Input-Output for Integer Types
+-------------------------------------
+
+ _Static Semantics_
+
+1
+The following procedures are defined in the generic packages Integer_IO
+and Modular_IO, which have to be instantiated for the appropriate signed
+integer or modular type respectively (indicated by Num in the
+specifications).
+
+2
+Values are output as decimal or based literals, without low line
+characters or exponent, and, for Integer_IO, preceded by a minus sign if
+negative. The format (which includes any leading spaces and minus sign)
+can be specified by an optional field width parameter. Values of widths
+of fields in output formats are of the nonnegative integer subtype
+Field. Values of bases are of the integer subtype Number_Base.
+
+3
+ subtype Number_Base is Integer range 2 .. 16;
+
+4
+The default field width and base to be used by output procedures are
+defined by the following variables that are declared in the generic
+packages Integer_IO and Modular_IO:
+
+5
+ Default_Width : Field := Num'Width;
+ Default_Base : Number_Base := 10;
+
+6
+The following procedures are provided:
+
+7
+ procedure Get(File : in File_Type; Item : out Num; Width : in Field := 0);
+ procedure Get(Item : out Num; Width : in Field := 0);
+
+8
+ If the value of the parameter Width is zero, skips any leading
+ blanks, line terminators, or page terminators, then reads a
+ plus sign if present or (for a signed type only) a minus sign
+ if present, then reads the longest possible sequence of
+ characters matching the syntax of a numeric literal without a
+ point. If a nonzero value of Width is supplied, then exactly
+ Width characters are input, or the characters (possibly none)
+ up to a line terminator, whichever comes first; any skipped
+ leading blanks are included in the count.
+
+9
+ Returns, in the parameter Item, the value of type Num that
+ corresponds to the sequence input.
+
+10/3
+ {AI05-0038-1AI05-0038-1} The exception Data_Error is
+ propagated if the sequence of characters read does not form a
+ legal integer literal or if the value obtained is not of the
+ subtype Num.
+
+11
+ procedure Put(File : in File_Type;
+ Item : in Num;
+ Width : in Field := Default_Width;
+ Base : in Number_Base := Default_Base);
+
+ procedure Put(Item : in Num;
+ Width : in Field := Default_Width;
+ Base : in Number_Base := Default_Base);
+
+12
+ Outputs the value of the parameter Item as an integer literal,
+ with no low lines, no exponent, and no leading zeros (but a
+ single zero for the value zero), and a preceding minus sign
+ for a negative value.
+
+13
+ If the resulting sequence of characters to be output has fewer
+ than Width characters, then leading spaces are first output to
+ make up the difference.
+
+14
+ Uses the syntax for decimal literal if the parameter Base has
+ the value ten (either explicitly or through Default_Base);
+ otherwise, uses the syntax for based literal, with any letters
+ in upper case.
+
+15
+ procedure Get(From : in String; Item : out Num; Last : out Positive);
+
+16
+ Reads an integer value from the beginning of the given string,
+ following the same rules as the Get procedure that reads an
+ integer value from a file, but treating the end of the string
+ as a file terminator. Returns, in the parameter Item, the
+ value of type Num that corresponds to the sequence input.
+ Returns in Last the index value such that From(Last) is the
+ last character read.
+
+17
+ The exception Data_Error is propagated if the sequence input
+ does not have the required syntax or if the value obtained is
+ not of the subtype Num.
+
+18
+ procedure Put(To : out String;
+ Item : in Num;
+ Base : in Number_Base := Default_Base);
+
+19
+ Outputs the value of the parameter Item to the given string,
+ following the same rule as for output to a file, using the
+ length of the given string as the value for Width.
+
+20
+Integer_Text_IO is a library package that is a nongeneric equivalent to
+Text_IO.Integer_IO for the predefined type Integer:
+
+21
+ with Ada.Text_IO;
+ package Ada.Integer_Text_IO is new Ada.Text_IO.Integer_IO(Integer);
+
+22
+For each predefined signed integer type, a nongeneric equivalent to
+Text_IO.Integer_IO is provided, with names such as
+Ada.Long_Integer_Text_IO.
+
+ _Implementation Permissions_
+
+23
+The nongeneric equivalent packages may, but need not, be actual
+instantiations of the generic package for the appropriate predefined
+type.
+
+Paragraphs 24 and 25 were deleted.
+
+ _Examples_
+
+26/3
+ {AI05-0298-1AI05-0298-1} subtype Byte_Int is Integer range -127 .. 127;
+ package Int_IO is new Integer_IO(Byte_Int); use Int_IO;
+ -- default format used at instantiation,
+ -- Default_Width = 4, Default_Base = 10
+
+27
+ Put(126); -- "b126"
+ Put(-126, 7); -- "bbb-126"
+ Put(126, Width => 13, Base => 2); -- "bbb2#1111110#"
+
+ _Inconsistencies With Ada 2005_
+
+27.a/3
+ {AI05-0038-1AI05-0038-1} Correction: Changed wording to make
+ Integer_IO and Modular_IO raise Data_Error in the same way
+ when the bounds of the subtype are exceeded. There is no
+ value to different behavior, and all surveyed compilers
+ already treat integer and modular values the same way. This
+ could only cause a problem if a program was compiled with some
+ unsurveyed compiler, and the Ada 95-defined behavior is
+ expected for Modular_IO. But note that such code is not
+ portable anyway, as most widely used compilers behave
+ consistently with the new wording, so it is unlikely that such
+ code exists.
+
+\1f
+File: aarm2012.info, Node: A.10.9, Next: A.10.10, Prev: A.10.8, Up: A.10
+
+A.10.9 Input-Output for Real Types
+----------------------------------
+
+ _Static Semantics_
+
+1
+The following procedures are defined in the generic packages Float_IO,
+Fixed_IO, and Decimal_IO, which have to be instantiated for the
+appropriate floating point, ordinary fixed point, or decimal fixed point
+type respectively (indicated by Num in the specifications).
+
+2
+Values are output as decimal literals without low line characters. The
+format of each value output consists of a Fore field, a decimal point,
+an Aft field, and (if a nonzero Exp parameter is supplied) the letter E
+and an Exp field. The two possible formats thus correspond to:
+
+3
+ Fore . Aft
+
+4
+and to:
+
+5
+ Fore . Aft E Exp
+
+6
+without any spaces between these fields. The Fore field may include
+leading spaces, and a minus sign for negative values. The Aft field
+includes only decimal digits (possibly with trailing zeros). The Exp
+field includes the sign (plus or minus) and the exponent (possibly with
+leading zeros).
+
+7
+For floating point types, the default lengths of these fields are
+defined by the following variables that are declared in the generic
+package Float_IO:
+
+8
+ Default_Fore : Field := 2;
+ Default_Aft : Field := Num'Digits-1;
+ Default_Exp : Field := 3;
+
+9
+For ordinary or decimal fixed point types, the default lengths of these
+fields are defined by the following variables that are declared in the
+generic packages Fixed_IO and Decimal_IO, respectively:
+
+10
+ Default_Fore : Field := Num'Fore;
+ Default_Aft : Field := Num'Aft;
+ Default_Exp : Field := 0;
+
+11
+The following procedures are provided:
+
+12
+ procedure Get(File : in File_Type; Item : out Num; Width : in Field := 0);
+ procedure Get(Item : out Num; Width : in Field := 0);
+
+13
+ If the value of the parameter Width is zero, skips any leading
+ blanks, line terminators, or page terminators, then reads the
+ longest possible sequence of characters matching the syntax of
+ any of the following (see *note 2.4::):
+
+14
+ * [+|-]numeric_literal
+
+15
+ * [+|-]numeral.[exponent]
+
+16
+ * [+|-].numeral[exponent]
+
+17
+ * [+|-]base#based_numeral.#[exponent]
+
+18
+ * [+|-]base#.based_numeral#[exponent]
+
+19
+ If a nonzero value of Width is supplied, then exactly Width
+ characters are input, or the characters (possibly none) up to
+ a line terminator, whichever comes first; any skipped leading
+ blanks are included in the count.
+
+20
+ Returns in the parameter Item the value of type Num that
+ corresponds to the sequence input, preserving the sign
+ (positive if none has been specified) of a zero value if Num
+ is a floating point type and Num'Signed_Zeros is True.
+
+21
+ The exception Data_Error is propagated if the sequence input
+ does not have the required syntax or if the value obtained is
+ not of the subtype Num.
+
+22
+ procedure Put(File : in File_Type;
+ Item : in Num;
+ Fore : in Field := Default_Fore;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+
+ procedure Put(Item : in Num;
+ Fore : in Field := Default_Fore;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+
+23
+ Outputs the value of the parameter Item as a decimal literal
+ with the format defined by Fore, Aft and Exp. If the value is
+ negative, or if Num is a floating point type where
+ Num'Signed_Zeros is True and the value is a negatively signed
+ zero, then a minus sign is included in the integer part. If
+ Exp has the value zero, then the integer part to be output has
+ as many digits as are needed to represent the integer part of
+ the value of Item, overriding Fore if necessary, or consists
+ of the digit zero if the value of Item has no integer part.
+
+24
+ If Exp has a value greater than zero, then the integer part to
+ be output has a single digit, which is nonzero except for the
+ value 0.0 of Item.
+
+25
+ In both cases, however, if the integer part to be output has
+ fewer than Fore characters, including any minus sign, then
+ leading spaces are first output to make up the difference.
+ The number of digits of the fractional part is given by Aft,
+ or is one if Aft equals zero. The value is rounded; a value
+ of exactly one half in the last place is rounded away from
+ zero.
+
+26
+ If Exp has the value zero, there is no exponent part. If Exp
+ has a value greater than zero, then the exponent part to be
+ output has as many digits as are needed to represent the
+ exponent part of the value of Item (for which a single digit
+ integer part is used), and includes an initial sign (plus or
+ minus). If the exponent part to be output has fewer than Exp
+ characters, including the sign, then leading zeros precede the
+ digits, to make up the difference. For the value 0.0 of Item,
+ the exponent has the value zero.
+
+27
+ procedure Get(From : in String; Item : out Num; Last : out Positive);
+
+28
+ Reads a real value from the beginning of the given string,
+ following the same rule as the Get procedure that reads a real
+ value from a file, but treating the end of the string as a
+ file terminator. Returns, in the parameter Item, the value of
+ type Num that corresponds to the sequence input. Returns in
+ Last the index value such that From(Last) is the last
+ character read.
+
+29
+ The exception Data_Error is propagated if the sequence input
+ does not have the required syntax, or if the value obtained is
+ not of the subtype Num.
+
+30
+ procedure Put(To : out String;
+ Item : in Num;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+
+31
+ Outputs the value of the parameter Item to the given string,
+ following the same rule as for output to a file, using a value
+ for Fore such that the sequence of characters output exactly
+ fills the string, including any leading spaces.
+
+32
+Float_Text_IO is a library package that is a nongeneric equivalent to
+Text_IO.Float_IO for the predefined type Float:
+
+33
+ with Ada.Text_IO;
+ package Ada.Float_Text_IO is new Ada.Text_IO.Float_IO(Float);
+
+34
+For each predefined floating point type, a nongeneric equivalent to
+Text_IO.Float_IO is provided, with names such as Ada.Long_Float_Text_IO.
+
+ _Implementation Permissions_
+
+35
+An implementation may extend Get [and Put] for floating point types to
+support special values such as infinities and NaNs.
+
+35.a/3
+ Discussion: {AI05-0005-1AI05-0005-1} See also the similar
+ permission for the Wide_Wide_Value, Wide_Value, and Value
+ attributes in *note 3.5::.
+
+36
+The implementation of Put need not produce an output value with greater
+accuracy than is supported for the base subtype. The additional
+accuracy, if any, of the value produced by Put when the number of
+requested digits in the integer and fractional parts exceeds the
+required accuracy is implementation defined.
+
+36.a
+ Discussion: The required accuracy is thus Num'Base'Digits
+ digits if Num is a floating point subtype. For a fixed point
+ subtype the required accuracy is a function of the subtype's
+ Fore, Aft, and Delta attributes.
+
+36.b
+ Implementation defined: The accuracy of the value produced by
+ Put.
+
+37
+The nongeneric equivalent packages may, but need not, be actual
+instantiations of the generic package for the appropriate predefined
+type.
+
+ NOTES
+
+38
+ 34 For an item with a positive value, if output to a string
+ exactly fills the string without leading spaces, then output of the
+ corresponding negative value will propagate Layout_Error.
+
+39
+ 35 The rules for the Value attribute (see *note 3.5::) and the
+ rules for Get are based on the same set of formats.
+
+ _Examples_
+
+40/1
+ This paragraph was deleted.
+
+41
+ package Real_IO is new Float_IO(Real); use Real_IO;
+ -- default format used at instantiation, Default_Exp = 3
+
+42
+ X : Real := -123.4567; -- digits 8 (see *note 3.5.7::)
+
+43
+ Put(X); -- default format "-1.2345670E+02"
+ Put(X, Fore => 5, Aft => 3, Exp => 2); -- "bbb-1.235E+2"
+ Put(X, 5, 3, 0); -- "b-123.457"
+
+\1f
+File: aarm2012.info, Node: A.10.10, Next: A.10.11, Prev: A.10.9, Up: A.10
+
+A.10.10 Input-Output for Enumeration Types
+------------------------------------------
+
+ _Static Semantics_
+
+1
+The following procedures are defined in the generic package
+Enumeration_IO, which has to be instantiated for the appropriate
+enumeration type (indicated by Enum in the specification).
+
+2
+Values are output using either upper or lower case letters for
+identifiers. This is specified by the parameter Set, which is of the
+enumeration type Type_Set.
+
+3
+ type Type_Set is (Lower_Case, Upper_Case);
+
+4
+The format (which includes any trailing spaces) can be specified by an
+optional field width parameter. The default field width and letter case
+are defined by the following variables that are declared in the generic
+package Enumeration_IO:
+
+5
+ Default_Width : Field := 0;
+ Default_Setting : Type_Set := Upper_Case;
+
+6
+The following procedures are provided:
+
+7
+ procedure Get(File : in File_Type; Item : out Enum);
+ procedure Get(Item : out Enum);
+
+8
+ After skipping any leading blanks, line terminators, or page
+ terminators, reads an identifier according to the syntax of
+ this lexical element (lower and upper case being considered
+ equivalent), or a character literal according to the syntax of
+ this lexical element (including the apostrophes). Returns, in
+ the parameter Item, the value of type Enum that corresponds to
+ the sequence input.
+
+9
+ The exception Data_Error is propagated if the sequence input
+ does not have the required syntax, or if the identifier or
+ character literal does not correspond to a value of the
+ subtype Enum.
+
+10
+ procedure Put(File : in File_Type;
+ Item : in Enum;
+ Width : in Field := Default_Width;
+ Set : in Type_Set := Default_Setting);
+
+ procedure Put(Item : in Enum;
+ Width : in Field := Default_Width;
+ Set : in Type_Set := Default_Setting);
+
+11
+ Outputs the value of the parameter Item as an enumeration
+ literal (either an identifier or a character literal). The
+ optional parameter Set indicates whether lower case or upper
+ case is used for identifiers; it has no effect for character
+ literals. If the sequence of characters produced has fewer
+ than Width characters, then trailing spaces are finally output
+ to make up the difference. If Enum is a character type, the
+ sequence of characters produced is as for Enum'Image(Item), as
+ modified by the Width and Set parameters.
+
+11.a/3
+ Discussion: {AI05-0005-1AI05-0005-1} For a character type, the
+ literal might be a Wide_Wide_Character, Wide_Character, or a
+ control character. Whatever Image does for these things is
+ appropriate here, too.
+
+11.b/3
+ {AI05-0036-1AI05-0036-1} The "characters produced" defines the
+ "characters to be output" in the sense of *note A.10.6::, so a
+ result that cannot fit on any bounded line will raise
+ Layout_Error.
+
+12
+ procedure Get(From : in String; Item : out Enum; Last : out Positive);
+
+13
+ Reads an enumeration value from the beginning of the given
+ string, following the same rule as the Get procedure that
+ reads an enumeration value from a file, but treating the end
+ of the string as a file terminator. Returns, in the parameter
+ Item, the value of type Enum that corresponds to the sequence
+ input. Returns in Last the index value such that From(Last)
+ is the last character read.
+
+14
+ The exception Data_Error is propagated if the sequence input
+ does not have the required syntax, or if the identifier or
+ character literal does not correspond to a value of the
+ subtype Enum.
+
+14.a/3
+ To be honest: {AI05-0005-1AI05-0005-1} For a character type,
+ it is permissible for the implementation to make Get do the
+ inverse of what Put does, in the case of wide and wide_wide
+ character_literals and control characters.
+
+15
+ procedure Put(To : out String;
+ Item : in Enum;
+ Set : in Type_Set := Default_Setting);
+
+16
+ Outputs the value of the parameter Item to the given string,
+ following the same rule as for output to a file, using the
+ length of the given string as the value for Width.
+
+17/1
+{8652/00548652/0054} {AI95-00007-01AI95-00007-01} Although the
+specification of the generic package Enumeration_IO would allow
+instantiation for an integer type, this is not the intended purpose of
+this generic package, and the effect of such instantiations is not
+defined by the language.
+
+ NOTES
+
+18
+ 36 There is a difference between Put defined for characters, and
+ for enumeration values. Thus
+
+19
+ Ada.Text_IO.Put('A'); -- outputs the character A
+
+20
+ package Char_IO is new Ada.Text_IO.Enumeration_IO(Character);
+ Char_IO.Put('A'); -- outputs the character 'A', between apostrophes
+
+21
+ 37 The type Boolean is an enumeration type, hence Enumeration_IO
+ can be instantiated for this type.
+
+ _Wording Changes from Ada 95_
+
+21.a/2
+ {8652/00548652/0054} {AI95-00007-01AI95-00007-01} Corrigendum:
+ Corrected the wording to say Enumeration_IO can be
+ instantiated with an integer type, not a float type.
+
+\1f
+File: aarm2012.info, Node: A.10.11, Next: A.10.12, Prev: A.10.10, Up: A.10
+
+A.10.11 Input-Output for Bounded Strings
+----------------------------------------
+
+1/2
+{AI95-00428-01AI95-00428-01} The package Text_IO.Bounded_IO provides
+input-output in human-readable form for Bounded_Strings.
+
+ _Static Semantics_
+
+2/2
+{AI95-00428-01AI95-00428-01} The generic library package
+Text_IO.Bounded_IO has the following declaration:
+
+3/2
+ with Ada.Strings.Bounded;
+ generic
+ with package Bounded is
+ new Ada.Strings.Bounded.Generic_Bounded_Length (<>);
+ package Ada.Text_IO.Bounded_IO is
+
+4/2
+ procedure Put
+ (File : in File_Type;
+ Item : in Bounded.Bounded_String);
+
+5/2
+ procedure Put
+ (Item : in Bounded.Bounded_String);
+
+6/2
+ procedure Put_Line
+ (File : in File_Type;
+ Item : in Bounded.Bounded_String);
+
+7/2
+ procedure Put_Line
+ (Item : in Bounded.Bounded_String);
+
+8/2
+ function Get_Line
+ (File : in File_Type)
+ return Bounded.Bounded_String;
+
+9/2
+ function Get_Line
+ return Bounded.Bounded_String;
+
+10/2
+ procedure Get_Line
+ (File : in File_Type; Item : out Bounded.Bounded_String);
+
+11/2
+ procedure Get_Line
+ (Item : out Bounded.Bounded_String);
+
+12/2
+ end Ada.Text_IO.Bounded_IO;
+
+13/2
+{AI95-00428-01AI95-00428-01} For an item of type Bounded_String, the
+following subprograms are provided:
+
+14/2
+ procedure Put
+ (File : in File_Type;
+ Item : in Bounded.Bounded_String);
+
+15/2
+ {AI95-00428-01AI95-00428-01} Equivalent to Text_IO.Put (File,
+ Bounded.To_String(Item));
+
+16/2
+ procedure Put
+ (Item : in Bounded.Bounded_String);
+
+17/2
+ {AI95-00428-01AI95-00428-01} Equivalent to Text_IO.Put
+ (Bounded.To_String(Item));
+
+18/2
+ procedure Put_Line
+ (File : in File_Type;
+ Item : in Bounded.Bounded_String);
+
+19/2
+ {AI95-00428-01AI95-00428-01} Equivalent to Text_IO.Put_Line
+ (File, Bounded.To_String(Item));
+
+20/2
+ procedure Put_Line
+ (Item : in Bounded.Bounded_String);
+
+21/2
+ {AI95-00428-01AI95-00428-01} Equivalent to Text_IO.Put_Line
+ (Bounded.To_String(Item));
+
+22/2
+ function Get_Line
+ (File : in File_Type)
+ return Bounded.Bounded_String;
+
+23/2
+ {AI95-00428-01AI95-00428-01} Returns
+ Bounded.To_Bounded_String(Text_IO.Get_Line(File));
+
+24/2
+ function Get_Line
+ return Bounded.Bounded_String;
+
+25/2
+ {AI95-00428-01AI95-00428-01} Returns
+ Bounded.To_Bounded_String(Text_IO.Get_Line);
+
+26/2
+ procedure Get_Line
+ (File : in File_Type; Item : out Bounded.Bounded_String);
+
+27/2
+ {AI95-00428-01AI95-00428-01} Equivalent to Item := Get_Line
+ (File);
+
+28/2
+ procedure Get_Line
+ (Item : out Bounded.Bounded_String);
+
+29/2
+ {AI95-00428-01AI95-00428-01} Equivalent to Item := Get_Line;
+
+ _Extensions to Ada 95_
+
+29.a/2
+ {AI95-00428-01AI95-00428-01} Package Text_IO.Bounded_IO is
+ new.
+
+\1f
+File: aarm2012.info, Node: A.10.12, Prev: A.10.11, Up: A.10
+
+A.10.12 Input-Output for Unbounded Strings
+------------------------------------------
+
+1/2
+{AI95-00301-01AI95-00301-01} The package Text_IO.Unbounded_IO provides
+input-output in human-readable form for Unbounded_Strings.
+
+ _Static Semantics_
+
+2/2
+{AI95-00301-01AI95-00301-01} The library package Text_IO.Unbounded_IO
+has the following declaration:
+
+3/2
+ with Ada.Strings.Unbounded;
+ package Ada.Text_IO.Unbounded_IO is
+
+4/2
+ procedure Put
+ (File : in File_Type;
+ Item : in Strings.Unbounded.Unbounded_String);
+
+5/2
+ procedure Put
+ (Item : in Strings.Unbounded.Unbounded_String);
+
+6/2
+ procedure Put_Line
+ (File : in File_Type;
+ Item : in Strings.Unbounded.Unbounded_String);
+
+7/2
+ procedure Put_Line
+ (Item : in Strings.Unbounded.Unbounded_String);
+
+8/2
+ function Get_Line
+ (File : in File_Type)
+ return Strings.Unbounded.Unbounded_String;
+
+9/2
+ function Get_Line
+ return Strings.Unbounded.Unbounded_String;
+
+10/2
+ procedure Get_Line
+ (File : in File_Type; Item : out Strings.Unbounded.Unbounded_String);
+
+11/2
+ procedure Get_Line
+ (Item : out Strings.Unbounded.Unbounded_String);
+
+12/2
+ end Ada.Text_IO.Unbounded_IO;
+
+13/2
+{AI95-00301-01AI95-00301-01} For an item of type Unbounded_String, the
+following subprograms are provided:
+
+14/2
+ procedure Put
+ (File : in File_Type;
+ Item : in Strings.Unbounded.Unbounded_String);
+
+15/2
+ {AI95-00301-01AI95-00301-01} Equivalent to Text_IO.Put (File,
+ Strings.Unbounded.To_String(Item));
+
+16/2
+ procedure Put
+ (Item : in Strings.Unbounded.Unbounded_String);
+
+17/2
+ {AI95-00301-01AI95-00301-01} Equivalent to Text_IO.Put
+ (Strings.Unbounded.To_String(Item));
+
+18/2
+ procedure Put_Line
+ (File : in File_Type;
+ Item : in Strings.Unbounded.Unbounded_String);
+
+19/2
+ {AI95-00301-01AI95-00301-01} Equivalent to Text_IO.Put_Line
+ (File, Strings.Unbounded.To_String(Item));
+
+20/2
+ procedure Put_Line
+ (Item : in Strings.Unbounded.Unbounded_String);
+
+21/2
+ {AI95-00301-01AI95-00301-01} Equivalent to Text_IO.Put_Line
+ (Strings.Unbounded.To_String(Item));
+
+22/2
+ function Get_Line
+ (File : in File_Type)
+ return Strings.Unbounded.Unbounded_String;
+
+23/2
+ {AI95-00301-01AI95-00301-01} Returns
+ Strings.Unbounded.To_Unbounded_String(Text_IO.Get_Line(File));
+
+24/2
+ function Get_Line
+ return Strings.Unbounded.Unbounded_String;
+
+25/2
+ {AI95-00301-01AI95-00301-01} Returns
+ Strings.Unbounded.To_Unbounded_String(Text_IO.Get_Line);
+
+26/2
+ procedure Get_Line
+ (File : in File_Type; Item : out Strings.Unbounded.Unbounded_String);
+
+27/2
+ {AI95-00301-01AI95-00301-01} Equivalent to Item := Get_Line
+ (File);
+
+28/2
+ procedure Get_Line
+ (Item : out Strings.Unbounded.Unbounded_String);
+
+29/2
+ {AI95-00301-01AI95-00301-01} Equivalent to Item := Get_Line;
+
+ _Extensions to Ada 95_
+
+29.a/2
+ {AI95-00301-01AI95-00301-01} Package Text_IO.Unbounded_IO is
+ new.
+
+\1f
+File: aarm2012.info, Node: A.11, Next: A.12, Prev: A.10, Up: Annex A
+
+A.11 Wide Text Input-Output and Wide Wide Text Input-Output
+===========================================================
+
+1/2
+{AI95-00285-01AI95-00285-01} The packages Wide_Text_IO and
+Wide_Wide_Text_IO provide facilities for input and output in
+human-readable form. Each file is read or written sequentially, as a
+sequence of wide characters (or wide wide characters) grouped into
+lines, and as a sequence of lines grouped into pages.
+
+ _Static Semantics_
+
+2/2
+{AI95-00285-01AI95-00285-01} {AI95-00301-01AI95-00301-01} The
+specification of package Wide_Text_IO is the same as that for Text_IO,
+except that in each Get, Look_Ahead, Get_Immediate, Get_Line, Put, and
+Put_Line subprogram, any occurrence of Character is replaced by
+Wide_Character, and any occurrence of String is replaced by Wide_String.
+Nongeneric equivalents of Wide_Text_IO.Integer_IO and
+Wide_Text_IO.Float_IO are provided (as for Text_IO) for each predefined
+numeric type, with names such as Ada.Integer_Wide_Text_IO,
+Ada.Long_Integer_Wide_Text_IO, Ada.Float_Wide_Text_IO,
+Ada.Long_Float_Wide_Text_IO.
+
+3/2
+{AI95-00285-01AI95-00285-01} {AI95-00301-01AI95-00301-01} The
+specification of package Wide_Wide_Text_IO is the same as that for
+Text_IO, except that in each Get, Look_Ahead, Get_Immediate, Get_Line,
+Put, and Put_Line subprogram, any occurrence of Character is replaced by
+Wide_Wide_Character, and any occurrence of String is replaced by
+Wide_Wide_String. Nongeneric equivalents of
+Wide_Wide_Text_IO.Integer_IO and Wide_Wide_Text_IO.Float_IO are provided
+(as for Text_IO) for each predefined numeric type, with names such as
+Ada.Integer_Wide_Wide_Text_IO, Ada.Long_Integer_Wide_Wide_Text_IO,
+Ada.Float_Wide_Wide_Text_IO, Ada.Long_Float_Wide_Wide_Text_IO.
+
+4/3
+{AI95-00285-01AI95-00285-01} {AI95-00428-01AI95-00428-01}
+{AI05-0004-1AI05-0004-1} {AI05-0092-1AI05-0092-1} The specification of
+package Wide_Text_IO.Wide_Bounded_IO is the same as that for
+Text_IO.Bounded_IO, except that any occurrence of Bounded_String is
+replaced by Bounded_Wide_String, and any occurrence of package Bounded
+is replaced by Wide_Bounded. The specification of package
+Wide_Wide_Text_IO.Wide_Wide_Bounded_IO is the same as that for
+Text_IO.Bounded_IO, except that any occurrence of Bounded_String is
+replaced by Bounded_Wide_Wide_String, and any occurrence of package
+Bounded is replaced by Wide_Wide_Bounded.
+
+4.a/3
+ To be honest: {AI05-0005-1AI05-0005-1} "package Bounded"
+ refers to both the package Ada.Strings.Bounded and the formal
+ package parameter named Bounded.
+
+5/3
+{AI95-00285-01AI95-00285-01} {AI95-00301-01AI95-00301-01}
+{AI05-0092-1AI05-0092-1} The specification of package
+Wide_Text_IO.Wide_Unbounded_IO is the same as that for
+Text_IO.Unbounded_IO, except that any occurrence of Unbounded_String is
+replaced by Unbounded_Wide_String, and any occurrence of package
+Unbounded is replaced by Wide_Unbounded. The specification of package
+Wide_Wide_Text_IO.Wide_Wide_Unbounded_IO is the same as that for
+Text_IO.Unbounded_IO, except that any occurrence of Unbounded_String is
+replaced by Unbounded_Wide_Wide_String, and any occurrence of package
+Unbounded is replaced by Wide_Wide_Unbounded.
+
+ _Extensions to Ada 83_
+
+5.a
+ Support for Wide_Character and Wide_String I/O is new in Ada
+ 95.
+
+ _Extensions to Ada 95_
+
+5.b/2
+ {AI95-00285-01AI95-00285-01} Package Wide_Wide_Text_IO is new.
+ Be glad it wasn't called Double_Wide_Text_IO (for use in
+ trailer parks) or Really_Wide_Text_IO.
+
+5.c/2
+ {AI95-00301-01AI95-00301-01} Packages
+ Wide_Text_IO.Wide_Unbounded_IO and
+ Wide_Wide_Text_IO.Wide_Wide_Unbounded_IO are also new.
+
+5.d/2
+ {AI95-00428-01AI95-00428-01} Packages
+ Wide_Text_IO.Wide_Bounded_IO and
+ Wide_Wide_Text_IO.Wide_Wide_Bounded_IO are new as well.
+
+ _Wording Changes from Ada 2005_
+
+5.e/3
+ {AI05-0092-1AI05-0092-1} Correction: Corrected the names of
+ various entities in the above description. Since the
+ previously named entities don't exist and the intent is
+ obvious, this is just considered a presentation change.
+
+\1f
+File: aarm2012.info, Node: A.12, Next: A.13, Prev: A.11, Up: Annex A
+
+A.12 Stream Input-Output
+========================
+
+1/2
+{AI95-00285-01AI95-00285-01} The packages Streams.Stream_IO,
+Text_IO.Text_Streams, Wide_Text_IO.Text_Streams, and
+Wide_Wide_Text_IO.Text_Streams provide stream-oriented operations on
+files.
+
+ _Wording Changes from Ada 95_
+
+1.a/2
+ {AI95-00285-01AI95-00285-01} Included package
+ Wide_Wide_Text_IO.Text_Streams in this description.
+
+* Menu:
+
+* A.12.1 :: The Package Streams.Stream_IO
+* A.12.2 :: The Package Text_IO.Text_Streams
+* A.12.3 :: The Package Wide_Text_IO.Text_Streams
+* A.12.4 :: The Package Wide_Wide_Text_IO.Text_Streams
+
+\1f
+File: aarm2012.info, Node: A.12.1, Next: A.12.2, Up: A.12
+
+A.12.1 The Package Streams.Stream_IO
+------------------------------------
+
+1
+[The subprograms in the child package Streams.Stream_IO provide control
+over stream files. Access to a stream file is either sequential, via a
+call on Read or Write to transfer an array of stream elements, or
+positional (if supported by the implementation for the given file), by
+specifying a relative index for an element. Since a stream file can be
+converted to a Stream_Access value, calling stream-oriented attribute
+subprograms of different element types with the same Stream_Access value
+provides heterogeneous input-output.] See *note 13.13:: for a general
+discussion of streams.
+
+ _Static Semantics_
+
+1.1/1
+{8652/00558652/0055} {AI95-00026-01AI95-00026-01} The elements of a
+stream file are stream elements. If positioning is supported for the
+specified external file, a current index and current size are maintained
+for the file as described in *note A.8::. If positioning is not
+supported, a current index is not maintained, and the current size is
+implementation defined.
+
+1.a.1/1
+ Implementation defined: Current size for a stream file for
+ which positioning is not supported.
+
+2
+The library package Streams.Stream_IO has the following declaration:
+
+3/3
+ {AI05-0283-1AI05-0283-1} with Ada.IO_Exceptions;
+ package Ada.Streams.Stream_IO is
+ pragma Preelaborate(Stream_IO);
+
+4
+ type Stream_Access is access all Root_Stream_Type'Class;
+
+5
+ type File_Type is limited private;
+
+6
+ type File_Mode is (In_File, Out_File, Append_File);
+
+7
+ type Count is range 0 .. implementation-defined;
+ subtype Positive_Count is Count range 1 .. Count'Last;
+ -- Index into file, in stream elements.
+
+8
+ procedure Create (File : in out File_Type;
+ Mode : in File_Mode := Out_File;
+ Name : in String := "";
+ Form : in String := "");
+
+9
+ procedure Open (File : in out File_Type;
+ Mode : in File_Mode;
+ Name : in String;
+ Form : in String := "");
+
+10
+ procedure Close (File : in out File_Type);
+ procedure Delete (File : in out File_Type);
+ procedure Reset (File : in out File_Type; Mode : in File_Mode);
+ procedure Reset (File : in out File_Type);
+
+11
+ function Mode (File : in File_Type) return File_Mode;
+ function Name (File : in File_Type) return String;
+ function Form (File : in File_Type) return String;
+
+12
+ function Is_Open (File : in File_Type) return Boolean;
+ function End_Of_File (File : in File_Type) return Boolean;
+
+13
+ function Stream (File : in File_Type) return Stream_Access;
+ -- Return stream access for use with T'Input and T'Output
+
+14/1
+ This paragraph was deleted.
+
+15
+ -- Read array of stream elements from file
+ procedure Read (File : in File_Type;
+ Item : out Stream_Element_Array;
+ Last : out Stream_Element_Offset;
+ From : in Positive_Count);
+
+16
+ procedure Read (File : in File_Type;
+ Item : out Stream_Element_Array;
+ Last : out Stream_Element_Offset);
+
+17/1
+ This paragraph was deleted.
+
+18
+ -- Write array of stream elements into file
+ procedure Write (File : in File_Type;
+ Item : in Stream_Element_Array;
+ To : in Positive_Count);
+
+19
+ procedure Write (File : in File_Type;
+ Item : in Stream_Element_Array);
+
+20/1
+ This paragraph was deleted.
+
+21
+ -- Operations on position within file
+
+22
+ procedure Set_Index(File : in File_Type; To : in Positive_Count);
+
+23
+ function Index(File : in File_Type) return Positive_Count;
+ function Size (File : in File_Type) return Count;
+
+24
+ procedure Set_Mode(File : in out File_Type; Mode : in File_Mode);
+
+25/1
+ {8652/00518652/0051} {AI95-00057-01AI95-00057-01} procedure Flush(File : in File_Type);
+
+26
+ -- exceptions
+ Status_Error : exception renames IO_Exceptions.Status_Error;
+ Mode_Error : exception renames IO_Exceptions.Mode_Error;
+ Name_Error : exception renames IO_Exceptions.Name_Error;
+ Use_Error : exception renames IO_Exceptions.Use_Error;
+ Device_Error : exception renames IO_Exceptions.Device_Error;
+ End_Error : exception renames IO_Exceptions.End_Error;
+ Data_Error : exception renames IO_Exceptions.Data_Error;
+
+27
+ private
+ ... -- not specified by the language
+ end Ada.Streams.Stream_IO;
+
+27.1/2
+{AI95-00360-01AI95-00360-01} The type File_Type needs finalization (see
+*note 7.6::).
+
+28/2
+{AI95-00283-01AI95-00283-01} The subprograms given in subclause *note
+A.8.2:: for the control of external files (Create, Open, Close, Delete,
+Reset, Mode, Name, Form, and Is_Open) are available for stream files.
+
+28.1/2
+{AI95-00283-01AI95-00283-01} The End_Of_File function:
+
+28.2/2
+ * Propagates Mode_Error if the mode of the file is not In_File;
+
+28.3/3
+ * {AI05-0264-1AI05-0264-1} If positioning is supported for the given
+ external file, the function returns True if the current index
+ exceeds the size of the external file; otherwise, it returns False;
+
+28.4/3
+ * {AI05-0264-1AI05-0264-1} If positioning is not supported for the
+ given external file, the function returns True if no more elements
+ can be read from the given file; otherwise, it returns False.
+
+28.5/2
+{8652/00558652/0055} {AI95-00026-01AI95-00026-01}
+{AI95-00085-01AI95-00085-01} The Set_Mode procedure sets the mode of the
+file. If the new mode is Append_File, the file is positioned to its
+end; otherwise, the position in the file is unchanged.
+
+28.6/1
+{8652/00558652/0055} {AI95-00026-01AI95-00026-01} The Flush procedure
+synchronizes the external file with the internal file (by flushing any
+internal buffers) without closing the file or changing the position.
+Mode_Error is propagated if the mode of the file is In_File.
+
+29/1
+{8652/00568652/0056} {AI95-00001-01AI95-00001-01} The Stream function
+returns a Stream_Access result from a File_Type object, thus allowing
+the stream-oriented attributes Read, Write, Input, and Output to be used
+on the same file for multiple types. Stream propagates Status_Error if
+File is not open.
+
+30/2
+{AI95-00256-01AI95-00256-01} The procedures Read and Write are
+equivalent to the corresponding operations in the package Streams. Read
+propagates Mode_Error if the mode of File is not In_File. Write
+propagates Mode_Error if the mode of File is not Out_File or
+Append_File. The Read procedure with a Positive_Count parameter starts
+reading at the specified index. The Write procedure with a
+Positive_Count parameter starts writing at the specified index. For a
+file that supports positioning, Read without a Positive_Count parameter
+starts reading at the current index, and Write without a Positive_Count
+parameter starts writing at the current index.
+
+30.1/1
+{8652/00558652/0055} {AI95-00026-01AI95-00026-01} The Size function
+returns the current size of the file.
+
+31/1
+{8652/00558652/0055} {AI95-00026-01AI95-00026-01} The Index function
+returns the current index.
+
+31.a/1
+ This paragraph was deleted.
+
+32
+The Set_Index procedure sets the current index to the specified value.
+
+32.1/1
+{8652/00558652/0055} {AI95-00026-01AI95-00026-01} If positioning is
+supported for the external file, the current index is maintained as
+follows:
+
+32.2/1
+ * {8652/00558652/0055} {AI95-00026-01AI95-00026-01} For Open and
+ Create, if the Mode parameter is Append_File, the current index is
+ set to the current size of the file plus one; otherwise, the
+ current index is set to one.
+
+32.3/1
+ * {8652/00558652/0055} {AI95-00026-01AI95-00026-01} For Reset, if the
+ Mode parameter is Append_File, or no Mode parameter is given and
+ the current mode is Append_File, the current index is set to the
+ current size of the file plus one; otherwise, the current index is
+ set to one.
+
+32.4/1
+ * {8652/00558652/0055} {AI95-00026-01AI95-00026-01} For Set_Mode, if
+ the new mode is Append_File, the current index is set to current
+ size plus one; otherwise, the current index is unchanged.
+
+32.5/1
+ * {8652/00558652/0055} {AI95-00026-01AI95-00026-01} For Read and
+ Write without a Positive_Count parameter, the current index is
+ incremented by the number of stream elements read or written.
+
+32.6/1
+ * {8652/00558652/0055} {AI95-00026-01AI95-00026-01} For Read and
+ Write with a Positive_Count parameter, the value of the current
+ index is set to the value of the Positive_Count parameter plus the
+ number of stream elements read or written.
+
+33
+If positioning is not supported for the given file, then a call of Index
+or Set_Index propagates Use_Error. Similarly, a call of Read or Write
+with a Positive_Count parameter propagates Use_Error.
+
+33.a/2
+ Implementation Note: {AI95-00085-01AI95-00085-01} It is
+ permissible for an implementation to implement mode
+ Append_File using the Unix append mode (the O_APPEND bit).
+ Such an implementation does not support positioning when the
+ mode is Append_File, and therefore the operations listed above
+ must raise Use_Error. This is acceptable as there is no
+ requirement that any particular file support positioning;
+ therefore it is acceptable that a file support positioning
+ when opened with mode Out_File, and the same file not support
+ positioning when opened with mode Append_File. But it is not
+ acceptable for a file to support positioning (by allowing the
+ above operations), but to do something other than the defined
+ semantics (that is, always write at the end, even when
+ explicitly commanded to write somewhere else).
+
+Paragraphs 34 through 36 were deleted.
+
+ _Erroneous Execution_
+
+36.1/1
+{8652/00568652/0056} {AI95-00001-01AI95-00001-01} If the File_Type
+object passed to the Stream function is later closed or finalized, and
+the stream-oriented attributes are subsequently called (explicitly or
+implicitly) on the Stream_Access value returned by Stream, execution is
+erroneous. This rule applies even if the File_Type object was opened
+again after it had been closed.
+
+36.a.1/1
+ Reason: These rules are analogous to the rule for the result
+ of the Current_Input, Current_Output, and Current_Error
+ functions. These rules make it possible to represent a value
+ of (some descendant of) Root_Stream_Type which represents a
+ file as an access value, with a null value corresponding to a
+ closed file.
+
+ _Inconsistencies With Ada 95_
+
+36.a/3
+ {AI95-00283-01AI95-00283-01} {AI05-0005-1AI05-0005-1}
+ Amendment Correction: The description of the subprograms for
+ managing files was corrected so that they do not require
+ truncation of the external file -- a stream file is not a
+ sequential file. An Ada 95 program that expects truncation of
+ the stream file might not work under Ada 2005. Note that the
+ Ada 95 standard was ambiguous on this point (the normative
+ wording seemed to require truncation, but didn't explain
+ where; the AARM notes seemed to expect behavior like
+ Direct_IO), and implementations varied widely. Therefore, as
+ a practical matter, code that depends on stream truncation
+ might not work even in Ada 95; deleting the file before
+ opening it provides truncation that works in both Ada 95 and
+ Ada 2005.
+
+ _Incompatibilities With Ada 95_
+
+36.b/2
+ {AI95-00360-01AI95-00360-01} Amendment Correction:
+ Stream_IO.File_Type is defined to need finalization. If the
+ restriction No_Nested_Finalization (see *note D.7::) applies
+ to the partition, and File_Type does not have a controlled
+ part, it will not be allowed in local objects in Ada 2005
+ whereas it would be allowed in original Ada 95. Such code is
+ not portable, as another Ada compiler may have a controlled
+ part in File_Type, and thus would be illegal.
+
+ _Wording Changes from Ada 95_
+
+36.c/2
+ {8652/00518652/0051} {AI95-00057-01AI95-00057-01} Corrigendum:
+ Corrected the parameter mode of Flush; otherwise it could not
+ be used on Standard_Output.
+
+36.d/2
+ {8652/00558652/0055} {AI95-00026-01AI95-00026-01}
+ {AI95-00256-01AI95-00256-01} Corrigendum: Added wording to
+ describe the effects of the various operations on the current
+ index. The Amendment adds an explanation of the use of
+ current index for Read and Write.
+
+36.e/2
+ {8652/00568652/0056} {AI95-00001-01AI95-00001-01} Corrigendum:
+ Clarified that Stream can raise Status_Error, and clarified
+ that using a Stream_Access whose file has been closed is
+ erroneous.
+
+36.f/2
+ {AI95-00085-01AI95-00085-01} Clarified that Set_Mode can be
+ called with the current mode.
+
+ _Extensions to Ada 2005_
+
+36.g/3
+ {AI05-0283-1AI05-0283-1} Package Ada.Streams.Stream_IO is now
+ preelaborated, allowing it to be used in more contexts
+ (including in distributed systems). Note that is not a remote
+ types package; File_Type objects cannot be passed between
+ partitions.
+
+\1f
+File: aarm2012.info, Node: A.12.2, Next: A.12.3, Prev: A.12.1, Up: A.12
+
+A.12.2 The Package Text_IO.Text_Streams
+---------------------------------------
+
+1
+The package Text_IO.Text_Streams provides a function for treating a text
+file as a stream.
+
+ _Static Semantics_
+
+2
+The library package Text_IO.Text_Streams has the following declaration:
+
+3
+ with Ada.Streams;
+ package Ada.Text_IO.Text_Streams is
+ type Stream_Access is access all Streams.Root_Stream_Type'Class;
+
+4
+ function Stream (File : in File_Type) return Stream_Access;
+ end Ada.Text_IO.Text_Streams;
+
+5
+The Stream function has the same effect as the corresponding function in
+Streams.Stream_IO.
+
+ NOTES
+
+6
+ 38 The ability to obtain a stream for a text file allows
+ Current_Input, Current_Output, and Current_Error to be processed
+ with the functionality of streams, including the mixing of text and
+ binary input-output, and the mixing of binary input-output for
+ different types.
+
+7
+ 39 Performing operations on the stream associated with a text file
+ does not affect the column, line, or page counts.
+
+\1f
+File: aarm2012.info, Node: A.12.3, Next: A.12.4, Prev: A.12.2, Up: A.12
+
+A.12.3 The Package Wide_Text_IO.Text_Streams
+--------------------------------------------
+
+1
+The package Wide_Text_IO.Text_Streams provides a function for treating a
+wide text file as a stream.
+
+ _Static Semantics_
+
+2
+The library package Wide_Text_IO.Text_Streams has the following
+declaration:
+
+3
+ with Ada.Streams;
+ package Ada.Wide_Text_IO.Text_Streams is
+ type Stream_Access is access all Streams.Root_Stream_Type'Class;
+
+4
+ function Stream (File : in File_Type) return Stream_Access;
+ end Ada.Wide_Text_IO.Text_Streams;
+
+5
+The Stream function has the same effect as the corresponding function in
+Streams.Stream_IO.
+
+\1f
+File: aarm2012.info, Node: A.12.4, Prev: A.12.3, Up: A.12
+
+A.12.4 The Package Wide_Wide_Text_IO.Text_Streams
+-------------------------------------------------
+
+1/2
+{AI95-00285-01AI95-00285-01} The package Wide_Wide_Text_IO.Text_Streams
+provides a function for treating a wide wide text file as a stream.
+
+ _Static Semantics_
+
+2/2
+{AI95-00285-01AI95-00285-01} The library package
+Wide_Wide_Text_IO.Text_Streams has the following declaration:
+
+3/2
+ with Ada.Streams;
+ package Ada.Wide_Wide_Text_IO.Text_Streams is
+ type Stream_Access is access all Streams.Root_Stream_Type'Class;
+
+4/2
+ function Stream (File : in File_Type) return Stream_Access;
+ end Ada.Wide_Wide_Text_IO.Text_Streams;
+
+5/2
+{AI95-00285-01AI95-00285-01} The Stream function has the same effect as
+the corresponding function in Streams.Stream_IO.
+
+ _Extensions to Ada 95_
+
+5.a/2
+ {AI95-00285-01AI95-00285-01} Package
+ Wide_Wide_Text_IO.Text_Streams is new.
+
+\1f
+File: aarm2012.info, Node: A.13, Next: A.14, Prev: A.12, Up: Annex A
+
+A.13 Exceptions in Input-Output
+===============================
+
+1
+The package IO_Exceptions defines the exceptions needed by the
+predefined input-output packages.
+
+ _Static Semantics_
+
+2
+The library package IO_Exceptions has the following declaration:
+
+3
+ package Ada.IO_Exceptions is
+ pragma Pure(IO_Exceptions);
+
+4
+ Status_Error : exception;
+ Mode_Error : exception;
+ Name_Error : exception;
+ Use_Error : exception;
+ Device_Error : exception;
+ End_Error : exception;
+ Data_Error : exception;
+ Layout_Error : exception;
+
+5
+ end Ada.IO_Exceptions;
+
+6
+If more than one error condition exists, the corresponding exception
+that appears earliest in the following list is the one that is
+propagated.
+
+7
+The exception Status_Error is propagated by an attempt to operate upon a
+file that is not open, and by an attempt to open a file that is already
+open.
+
+8
+The exception Mode_Error is propagated by an attempt to read from, or
+test for the end of, a file whose current mode is Out_File or
+Append_File, and also by an attempt to write to a file whose current
+mode is In_File. In the case of Text_IO, the exception Mode_Error is
+also propagated by specifying a file whose current mode is Out_File or
+Append_File in a call of Set_Input, Skip_Line, End_Of_Line, Skip_Page,
+or End_Of_Page; and by specifying a file whose current mode is In_File
+in a call of Set_Output, Set_Line_Length, Set_Page_Length, Line_Length,
+Page_Length, New_Line, or New_Page.
+
+9
+The exception Name_Error is propagated by a call of Create or Open if
+the string given for the parameter Name does not allow the
+identification of an external file. For example, this exception is
+propagated if the string is improper, or, alternatively, if either none
+or more than one external file corresponds to the string.
+
+10
+The exception Use_Error is propagated if an operation is attempted that
+is not possible for reasons that depend on characteristics of the
+external file. For example, this exception is propagated by the
+procedure Create, among other circumstances, if the given mode is
+Out_File but the form specifies an input only device, if the parameter
+Form specifies invalid access rights, or if an external file with the
+given name already exists and overwriting is not allowed.
+
+11
+The exception Device_Error is propagated if an input-output operation
+cannot be completed because of a malfunction of the underlying system.
+
+12
+The exception End_Error is propagated by an attempt to skip (read past)
+the end of a file.
+
+13
+The exception Data_Error can be propagated by the procedure Read (or by
+the Read attribute) if the element read cannot be interpreted as a value
+of the required subtype. This exception is also propagated by a
+procedure Get (defined in the package Text_IO) if the input character
+sequence fails to satisfy the required syntax, or if the value input
+does not belong to the range of the required subtype.
+
+14
+The exception Layout_Error is propagated (in text input-output) by Col,
+Line, or Page if the value returned exceeds Count'Last. The exception
+Layout_Error is also propagated on output by an attempt to set column or
+line numbers in excess of specified maximum line or page lengths,
+respectively (excluding the unbounded cases). It is also propagated by
+an attempt to Put too many characters to a string.
+
+14.1/3
+{AI05-0262-1AI05-0262-1} These exceptions are also propagated by various
+other language-defined packages and operations, see the definition of
+those entities for other reasons that these exceptions are propagated.
+
+14.a/3
+ Reason: {AI05-0299-1AI05-0299-1} This subclause is based in
+ Ada 95. Later versions of Ada (starting with Technical
+ Corrigendum 1) have added a number of additional places and
+ reasons that cause these exceptions. In particular, TC1 says
+ that stream attributes need to raise End_Error in some
+ circumstances; Amendment 1 adds Ada.Directories and a number
+ of new places and reasons that Name_Error and Use_Error are
+ raised. There are more. We don't want to try to update this
+ text (or even this note!) for every possible reason and place
+ that might raise one of these exceptions, so we add this
+ blanket statement.
+
+ _Documentation Requirements_
+
+15
+The implementation shall document the conditions under which Name_Error,
+Use_Error and Device_Error are propagated.
+
+15.a/2
+ Documentation Requirement: The conditions under which
+ Io_Exceptions.Name_Error, Io_Exceptions.Use_Error, and
+ Io_Exceptions.Device_Error are propagated.
+
+ _Implementation Permissions_
+
+16
+If the associated check is too complex, an implementation need not
+propagate Data_Error as part of a procedure Read (or the Read attribute)
+if the value read cannot be interpreted as a value of the required
+subtype.
+
+16.a
+ Ramification: An example where the implementation may choose
+ not to perform the check is an enumeration type with a
+ representation clause with "holes" in the range of internal
+ codes.
+
+ _Erroneous Execution_
+
+17
+[If the element read by the procedure Read (or by the Read attribute)
+cannot be interpreted as a value of the required subtype, but this is
+not detected and Data_Error is not propagated, then the resulting value
+can be abnormal, and subsequent references to the value can lead to
+erroneous execution, as explained in *note 13.9.1::. ]
+
+\1f
+File: aarm2012.info, Node: A.14, Next: A.15, Prev: A.13, Up: Annex A
+
+A.14 File Sharing
+=================
+
+ _Dynamic Semantics_
+
+1
+It is not specified by the language whether the same external file can
+be associated with more than one file object. If such sharing is
+supported by the implementation, the following effects are defined:
+
+2
+ * Operations on one text file object do not affect the column, line,
+ and page numbers of any other file object.
+
+3/1
+ * This paragraph was deleted.{8652/00578652/0057}
+ {AI95-00050-01AI95-00050-01}
+
+4
+ * For direct and stream files, the current index is a property of
+ each file object; an operation on one file object does not affect
+ the current index of any other file object.
+
+5
+ * For direct and stream files, the current size of the file is a
+ property of the external file.
+
+6
+All other effects are identical.
+
+ _Wording Changes from Ada 95_
+
+6.a/2
+ {8652/00578652/0057} {AI95-00050-01AI95-00050-01} Corrigendum:
+ Removed the incorrect statement that the external files
+ associated with the standard input, standard output, and
+ standard error files are distinct.
+
+\1f
+File: aarm2012.info, Node: A.15, Next: A.16, Prev: A.14, Up: Annex A
+
+A.15 The Package Command_Line
+=============================
+
+1
+The package Command_Line allows a program to obtain the values of its
+arguments and to set the exit status code to be returned on normal
+termination.
+
+1.a/2
+ Implementation defined: The meaning of Argument_Count,
+ Argument, and Command_Name for package Command_Line. The
+ bounds of type Command_Line.Exit_Status.
+
+ _Static Semantics_
+
+2
+The library package Ada.Command_Line has the following declaration:
+
+3
+ package Ada.Command_Line is
+ pragma Preelaborate(Command_Line);
+
+4
+ function Argument_Count return Natural;
+
+5
+ function Argument (Number : in Positive) return String;
+
+6
+ function Command_Name return String;
+
+7
+ type Exit_Status is implementation-defined integer type;
+
+8
+ Success : constant Exit_Status;
+ Failure : constant Exit_Status;
+
+9
+ procedure Set_Exit_Status (Code : in Exit_Status);
+
+10
+ private
+ ... -- not specified by the language
+ end Ada.Command_Line;
+
+
+11
+ function Argument_Count return Natural;
+
+12/3
+ {AI05-0264-1AI05-0264-1} If the external execution environment
+ supports passing arguments to a program, then Argument_Count
+ returns the number of arguments passed to the program invoking
+ the function. Otherwise, it returns 0. The meaning of
+ "number of arguments" is implementation defined.
+
+13
+ function Argument (Number : in Positive) return String;
+
+14
+ If the external execution environment supports passing
+ arguments to a program, then Argument returns an
+ implementation-defined value corresponding to the argument at
+ relative position Number. If Number is outside the range
+ 1..Argument_Count, then Constraint_Error is propagated.
+
+14.a
+ Ramification: If the external execution environment does not
+ support passing arguments to a program, then Argument(N) for
+ any N will raise Constraint_Error, since Argument_Count is 0.
+
+15
+ function Command_Name return String;
+
+16/3
+ {AI05-0264-1AI05-0264-1} If the external execution environment
+ supports passing arguments to a program, then Command_Name
+ returns an implementation-defined value corresponding to the
+ name of the command invoking the program; otherwise,
+ Command_Name returns the null string.
+
+16.1/1
+ type Exit_Status is implementation-defined integer type;
+
+17
+ The type Exit_Status represents the range of exit status
+ values supported by the external execution environment. The
+ constants Success and Failure correspond to success and
+ failure, respectively.
+
+18
+ procedure Set_Exit_Status (Code : in Exit_Status);
+
+19
+ If the external execution environment supports returning an
+ exit status from a program, then Set_Exit_Status sets Code as
+ the status. Normal termination of a program returns as the
+ exit status the value most recently set by Set_Exit_Status,
+ or, if no such value has been set, then the value Success. If
+ a program terminates abnormally, the status set by
+ Set_Exit_Status is ignored, and an implementation-defined exit
+ status value is set.
+
+20
+ If the external execution environment does not support
+ returning an exit value from a program, then Set_Exit_Status
+ does nothing.
+
+ _Implementation Permissions_
+
+21
+An alternative declaration is allowed for package Command_Line if
+different functionality is appropriate for the external execution
+environment.
+
+ NOTES
+
+22
+ 40 Argument_Count, Argument, and Command_Name correspond to the C
+ language's argc, argv[n] (for n>0) and argv[0], respectively.
+
+22.a
+ To be honest: The correspondence of Argument_Count to argc is
+ not direct -- argc would be one more than Argument_Count,
+ since the argc count includes the command name, whereas
+ Argument_Count does not.
+
+ _Extensions to Ada 83_
+
+22.b/3
+ {AI05-0299-1AI05-0299-1} This subclause is new in Ada 95.
+
+\1f
+File: aarm2012.info, Node: A.16, Next: A.17, Prev: A.15, Up: Annex A
+
+A.16 The Package Directories
+============================
+
+1/2
+{AI95-00248-01AI95-00248-01} The package Directories provides operations
+for manipulating files and directories, and their names.
+
+1.a/3
+ Discussion: {AI05-0299-1AI05-0299-1} The notes for this
+ subclause contain the expected interpretations of some of the
+ operations on various target systems. "Unix" refers to the
+ UNIX® operating system, and in most cases also covers
+ Unix-like systems such as Linux and POSIX. "Windows®" refers
+ to the Microsoft® Windows® 2000 operating system and usually
+ also covers most other versions that use the Win32 API.
+
+ _Static Semantics_
+
+2/2
+{AI95-00248-01AI95-00248-01} The library package Directories has the
+following declaration:
+
+3/2
+ with Ada.IO_Exceptions;
+ with Ada.Calendar;
+ package Ada.Directories is
+
+4/2
+ -- Directory and file operations:
+
+5/2
+ function Current_Directory return String;
+
+6/2
+ procedure Set_Directory (Directory : in String);
+
+7/2
+ procedure Create_Directory (New_Directory : in String;
+ Form : in String := "");
+
+8/2
+ procedure Delete_Directory (Directory : in String);
+
+9/2
+ procedure Create_Path (New_Directory : in String;
+ Form : in String := "");
+
+10/2
+ procedure Delete_Tree (Directory : in String);
+
+11/2
+ procedure Delete_File (Name : in String);
+
+12/2
+ procedure Rename (Old_Name, New_Name : in String);
+
+13/2
+ procedure Copy_File (Source_Name,
+ Target_Name : in String;
+ Form : in String := "");
+
+14/2
+ -- File and directory name operations:
+
+15/2
+ function Full_Name (Name : in String) return String;
+
+16/2
+ function Simple_Name (Name : in String) return String;
+
+17/2
+ function Containing_Directory (Name : in String) return String;
+
+18/2
+ function Extension (Name : in String) return String;
+
+19/2
+ function Base_Name (Name : in String) return String;
+
+20/2
+ function Compose (Containing_Directory : in String := "";
+ Name : in String;
+ Extension : in String := "") return String;
+
+20.1/3
+ {AI05-0049-1AI05-0049-1} type Name_Case_Kind is
+ (Unknown, Case_Sensitive, Case_Insensitive, Case_Preserving);
+
+20.2/3
+ {AI05-0049-1AI05-0049-1} function Name_Case_Equivalence (Name : in String) return Name_Case_Kind;
+
+21/2
+ -- File and directory queries:
+
+22/2
+ type File_Kind is (Directory, Ordinary_File, Special_File);
+
+23/2
+ type File_Size is range 0 .. implementation-defined;
+
+24/2
+ function Exists (Name : in String) return Boolean;
+
+25/2
+ function Kind (Name : in String) return File_Kind;
+
+26/2
+ function Size (Name : in String) return File_Size;
+
+27/2
+ function Modification_Time (Name : in String) return Ada.Calendar.Time;
+
+28/2
+ -- Directory searching:
+
+29/2
+ type Directory_Entry_Type is limited private;
+
+30/2
+ type Filter_Type is array (File_Kind) of Boolean;
+
+31/2
+ type Search_Type is limited private;
+
+32/2
+ procedure Start_Search (Search : in out Search_Type;
+ Directory : in String;
+ Pattern : in String;
+ Filter : in Filter_Type := (others => True));
+
+33/2
+ procedure End_Search (Search : in out Search_Type);
+
+34/2
+ function More_Entries (Search : in Search_Type) return Boolean;
+
+35/2
+ procedure Get_Next_Entry (Search : in out Search_Type;
+ Directory_Entry : out Directory_Entry_Type);
+
+36/2
+ procedure Search (
+ Directory : in String;
+ Pattern : in String;
+ Filter : in Filter_Type := (others => True);
+ Process : not null access procedure (
+ Directory_Entry : in Directory_Entry_Type));
+
+37/2
+ -- Operations on Directory Entries:
+
+38/2
+ function Simple_Name (Directory_Entry : in Directory_Entry_Type)
+ return String;
+
+39/2
+ function Full_Name (Directory_Entry : in Directory_Entry_Type)
+ return String;
+
+40/2
+ function Kind (Directory_Entry : in Directory_Entry_Type)
+ return File_Kind;
+
+41/2
+ function Size (Directory_Entry : in Directory_Entry_Type)
+ return File_Size;
+
+42/2
+ function Modification_Time (Directory_Entry : in Directory_Entry_Type)
+ return Ada.Calendar.Time;
+
+43/2
+ Status_Error : exception renames Ada.IO_Exceptions.Status_Error;
+ Name_Error : exception renames Ada.IO_Exceptions.Name_Error;
+ Use_Error : exception renames Ada.IO_Exceptions.Use_Error;
+ Device_Error : exception renames Ada.IO_Exceptions.Device_Error;
+
+44/3
+ {AI05-0092-1AI05-0092-1} private
+ ... -- not specified by the language
+ end Ada.Directories;
+
+45/2
+{AI95-00248-01AI95-00248-01} External files may be classified as
+directories, special files, or ordinary files. A directory is an
+external file that is a container for files on the target system. A
+special file is an external file that cannot be created or read by a
+predefined Ada input-output package. External files that are not
+special files or directories are called ordinary files.
+
+45.a/2
+ Ramification: A directory is an external file, although it may
+ not have a name on some targets. A directory is not a special
+ file, as it can be created and read by Directories.
+
+45.b/2
+ Discussion: Devices and soft links are examples of special
+ files on Windows® and Unix.
+
+45.c/2
+ Even if an implementation provides a package to create and
+ read soft links, such links are still special files.
+
+46/2
+{AI95-00248-01AI95-00248-01} A file name is a string identifying an
+external file. Similarly, a directory name is a string identifying a
+directory. The interpretation of file names and directory names is
+implementation-defined.
+
+46.a/2
+ Implementation defined: The interpretation of file names and
+ directory names.
+
+47/2
+{AI95-00248-01AI95-00248-01} The full name of an external file is a full
+specification of the name of the file. If the external environment
+allows alternative specifications of the name (for example,
+abbreviations), the full name should not use such alternatives. A full
+name typically will include the names of all of the directories that
+contain the item. The simple name of an external file is the name of
+the item, not including any containing directory names. Unless
+otherwise specified, a file name or directory name parameter in a call
+to a predefined Ada input-output subprogram can be a full name, a simple
+name, or any other form of name supported by the implementation.
+
+47.a/2
+ Discussion: The full name on Unix is a complete path to the
+ root. For Windows®, the full name includes a complete path,
+ as well as a disk name ("C:") or network share name. For both
+ systems, the simple name is the part of the name following the
+ last '/' (or ''\'' for Windows®). For example, in the name
+ "/usr/randy/ada-directories.ads", "ada-directories.ads" is the
+ simple name.
+
+47.b/2
+ Ramification: It is possible for a file or directory name to
+ be neither a full name nor a simple name. For instance, the
+ Unix name "../parent/myfile" is neither a full name nor a
+ simple name.
+
+48/2
+{AI95-00248-01AI95-00248-01} The default directory is the directory that
+is used if a directory or file name is not a full name (that is, when
+the name does not fully identify all of the containing directories).
+
+48.a/2
+ Discussion: The default directory is the one maintained by the
+ familiar "cd" command on Unix and Windows®. Note that
+ Windows® maintains separate default directories for each disk
+ drive; implementations should use the natural implementation.
+
+49/2
+{AI95-00248-01AI95-00248-01} A directory entry is a single item in a
+directory, identifying a single external file (including directories and
+special files).
+
+50/2
+{AI95-00248-01AI95-00248-01} For each function that returns a string,
+the lower bound of the returned value is 1.
+
+51/2
+{AI95-00248-01AI95-00248-01} The following file and directory operations
+are provided:
+
+52/2
+ function Current_Directory return String;
+
+53/2
+ Returns the full directory name for the current default
+ directory. The name returned shall be suitable for a future
+ call to Set_Directory. The exception Use_Error is propagated
+ if a default directory is not supported by the external
+ environment.
+
+54/2
+ procedure Set_Directory (Directory : in String);
+
+55/2
+ Sets the current default directory. The exception Name_Error
+ is propagated if the string given as Directory does not
+ identify an existing directory. The exception Use_Error is
+ propagated if the external environment does not support making
+ Directory (in the absence of Name_Error) a default directory.
+
+56/2
+ procedure Create_Directory (New_Directory : in String;
+ Form : in String := "");
+
+57/2
+ Creates a directory with name New_Directory. The Form
+ parameter can be used to give system-dependent characteristics
+ of the directory; the interpretation of the Form parameter is
+ implementation-defined. A null string for Form specifies the
+ use of the default options of the implementation of the new
+ directory. The exception Name_Error is propagated if the
+ string given as New_Directory does not allow the
+ identification of a directory. The exception Use_Error is
+ propagated if the external environment does not support the
+ creation of a directory with the given name (in the absence of
+ Name_Error) and form.
+
+58/2
+ procedure Delete_Directory (Directory : in String);
+
+59/3
+ {AI05-0231-1AI05-0231-1} Deletes an existing empty directory
+ with name Directory. The exception Name_Error is propagated
+ if the string given as Directory does not identify an existing
+ directory. The exception Use_Error is propagated if the
+ directory is not empty or the external environment does not
+ support the deletion of the directory with the given name (in
+ the absence of Name_Error).
+
+60/2
+ procedure Create_Path (New_Directory : in String;
+ Form : in String := "");
+
+61/3
+ {AI05-0271-1AI05-0271-1} Creates zero or more directories with
+ name New_Directory. Each nonexistent directory named by
+ New_Directory is created.[ For example, on a typical Unix
+ system, Create_Path ("/usr/me/my"); would create directory
+ "me" in directory "usr", then create directory "my" in
+ directory "me".] The Form parameter can be used to give
+ system-dependent characteristics of the directory; the
+ interpretation of the Form parameter is
+ implementation-defined. A null string for Form specifies the
+ use of the default options of the implementation of the new
+ directory. The exception Name_Error is propagated if the
+ string given as New_Directory does not allow the
+ identification of any directory. The exception Use_Error is
+ propagated if the external environment does not support the
+ creation of any directories with the given name (in the
+ absence of Name_Error) and form. If Use_Error is propagated,
+ it is unspecified whether a portion of the directory path is
+ created.
+
+62/2
+ procedure Delete_Tree (Directory : in String);
+
+63/2
+ Deletes an existing directory with name Directory. The
+ directory and all of its contents (possibly including other
+ directories) are deleted. The exception Name_Error is
+ propagated if the string given as Directory does not identify
+ an existing directory. The exception Use_Error is propagated
+ if the external environment does not support the deletion of
+ the directory or some portion of its contents with the given
+ name (in the absence of Name_Error). If Use_Error is
+ propagated, it is unspecified whether a portion of the
+ contents of the directory is deleted.
+
+64/2
+ procedure Delete_File (Name : in String);
+
+65/2
+ Deletes an existing ordinary or special file with name Name.
+ The exception Name_Error is propagated if the string given as
+ Name does not identify an existing ordinary or special
+ external file. The exception Use_Error is propagated if the
+ external environment does not support the deletion of the file
+ with the given name (in the absence of Name_Error).
+
+66/2
+ procedure Rename (Old_Name, New_Name : in String);
+
+67/3
+ {AI05-0231-1AI05-0231-1} Renames an existing external file
+ (including directories) with name Old_Name to New_Name. The
+ exception Name_Error is propagated if the string given as
+ Old_Name does not identify an existing external file or if the
+ string given as New_Name does not allow the identification of
+ an external file. The exception Use_Error is propagated if
+ the external environment does not support the renaming of the
+ file with the given name (in the absence of Name_Error). In
+ particular, Use_Error is propagated if a file or directory
+ already exists with name New_Name.
+
+67.a/2
+ Implementation Note: This operation is expected to work within
+ a single directory, and implementers are encouraged to support
+ it across directories on a single device. Copying files from
+ one device to another is discouraged (that's what Copy_File is
+ for). However, there is no requirement to detect file copying
+ by the target system. If the target system has an API that
+ gives that for "free", it can be used. For Windows®, for
+ instance, MoveFile can be used to implement Rename.
+
+68/3
+ {AI05-0092-1AI05-0092-1} procedure Copy_File (Source_Name,
+ Target_Name : in String;
+ Form : in String := "");
+
+69/3
+ {AI05-0271-1AI05-0271-1} Copies the contents of the existing
+ external file with name Source_Name to an external file with
+ name Target_Name. The resulting external file is a duplicate
+ of the source external file. The Form parameter can be used
+ to give system-dependent characteristics of the resulting
+ external file; the interpretation of the Form parameter is
+ implementation-defined. Exception Name_Error is propagated if
+ the string given as Source_Name does not identify an existing
+ external ordinary or special file, or if the string given as
+ Target_Name does not allow the identification of an external
+ file. The exception Use_Error is propagated if the external
+ environment does not support creating the file with the name
+ given by Target_Name and form given by Form, or copying of the
+ file with the name given by Source_Name (in the absence of
+ Name_Error). If Use_Error is propagated, it is unspecified
+ whether a portion of the file is copied.
+
+69.a/2
+ Ramification: Name_Error is always raised if Source_Name
+ identifies a directory. It is up to the implementation
+ whether special files can be copied, or if Use_Error will be
+ raised.
+
+70/2
+{AI95-00248-01AI95-00248-01} The following file and directory name
+operations are provided:
+
+71/2
+ function Full_Name (Name : in String) return String;
+
+72/2
+ Returns the full name corresponding to the file name specified
+ by Name. The exception Name_Error is propagated if the string
+ given as Name does not allow the identification of an external
+ file (including directories and special files).
+
+72.a/2
+ Discussion: Full name means that no abbreviations are used in
+ the returned name, and that it is a full specification of the
+ name. Thus, for Unix and Windows®, the result should be a
+ full path that does not contain any "." or ".." directories.
+ Typically, the default directory is used to fill in any
+ missing information.
+
+73/2
+ function Simple_Name (Name : in String) return String;
+
+74/2
+ Returns the simple name portion of the file name specified by
+ Name. The exception Name_Error is propagated if the string
+ given as Name does not allow the identification of an external
+ file (including directories and special files).
+
+75/2
+ function Containing_Directory (Name : in String) return String;
+
+76/2
+ Returns the name of the containing directory of the external
+ file (including directories) identified by Name. (If more
+ than one directory can contain Name, the directory name
+ returned is implementation-defined.) The exception Name_Error
+ is propagated if the string given as Name does not allow the
+ identification of an external file. The exception Use_Error
+ is propagated if the external file does not have a containing
+ directory.
+
+76.a/2
+ Discussion: This is purely a string manipulation function. If
+ Name is not given as a full name, the containing directory
+ probably won't be one, either. For example, if
+ Containing_Directory ("..'\'AARM'\'RM-A-8") is called on
+ Windows®, the result should be "..'\'AARM". If there is no
+ path at all on the name, the result should be "." (which
+ represents the current directory). Use Full_Name on the
+ result of Containing_Directory if the full name is needed.
+
+77/2
+ function Extension (Name : in String) return String;
+
+78/2
+ Returns the extension name corresponding to Name. The
+ extension name is a portion of a simple name (not including
+ any separator characters), typically used to identify the file
+ class. If the external environment does not have extension
+ names, then the null string is returned. The exception
+ Name_Error is propagated if the string given as Name does not
+ allow the identification of an external file.
+
+78.a/2
+ Discussion: For Unix and Windows®, the extension is the
+ portion of the simple name following the rightmost period.
+ For example, in the simple name "RM-A-8.html", the extension
+ is "html".
+
+79/2
+ function Base_Name (Name : in String) return String;
+
+80/2
+ Returns the base name corresponding to Name. The base name is
+ the remainder of a simple name after removing any extension
+ and extension separators. The exception Name_Error is
+ propagated if the string given as Name does not allow the
+ identification of an external file (including directories and
+ special files).
+
+80.a/2
+ Discussion: For Unix and Windows®, the base name is the
+ portion of the simple name preceding the rightmost period
+ (except for the special directory names "." and "..", whose
+ Base_Name is "." and ".."). For example, in the simple name
+ "RM-A-8.html", the base name is "RM-A-8".
+
+81/2
+ function Compose (Containing_Directory : in String := "";
+ Name : in String;
+ Extension : in String := "") return String;
+
+82/3
+ {AI05-0264-1AI05-0264-1} Returns the name of the external file
+ with the specified Containing_Directory, Name, and Extension.
+ If Extension is the null string, then Name is interpreted as a
+ simple name; otherwise, Name is interpreted as a base name.
+ The exception Name_Error is propagated if the string given as
+ Containing_Directory is not null and does not allow the
+ identification of a directory, or if the string given as
+ Extension is not null and is not a possible extension, or if
+ the string given as Name is not a possible simple name (if
+ Extension is null) or base name (if Extension is nonnull).
+
+82.a/2
+ Ramification: The above definition implies that if the
+ Extension is null, for Unix and Windows® no '.' is added to
+ Name.
+
+82.b/2
+ Discussion: If Name is null, Name_Error should be raised, as
+ nothing is not a possible simple name or base name.
+
+82.c/2
+ Generally, Compose(Containing_Directory(F),
+ Base_Name(F),Extension(F)) = F. However, this is not true on
+ Unix or Windows® for file names that end with a '.';
+ Compose(Base_Name("Fooey."),Extension("Fooey.")) = "Fooey".
+ This is not a problem for Windows®, as the names have the same
+ meaning with or without the '.', but these are different names
+ for Unix. Thus, care needs to be taken on Unix; if Extension
+ is null, Base_Name should be avoided. (That's not usually a
+ problem with file names generated by a program.)
+
+82.1/3
+ {AI05-0049-1AI05-0049-1} function Name_Case_Equivalence (Name : in String) return Name_Case_Kind;
+
+82.2/3
+ {AI05-0049-1AI05-0049-1} {AI05-0248-1AI05-0248-1} Returns the
+ file name equivalence rule for the directory containing Name.
+ Raises Name_Error if Name is not a full name. Returns
+ Case_Sensitive if file names that differ only in the case of
+ letters are considered different names. If file names that
+ differ only in the case of letters are considered the same
+ name, then Case_Preserving is returned if names have the case
+ of the file name used when a file is created; and
+ Case_Insensitive is returned otherwise. Returns Unknown if
+ the file name equivalence is not known.
+
+82.c.1/3
+ Implementation Note: Unix, Linux, and their relatives are
+ Case_Sensitive systems. Microsoft® Windows® is a
+ Case_Preserving system (unless the rarely used POSIX mode is
+ used). Ancient systems like CP/M and early MS-DOS were
+ Case_Insensitive systems (file names were always in UPPER
+ CASE). Unknown is provided in case it is impossible to tell
+ (such as could be the case for network files).
+
+83/2
+{AI95-00248-01AI95-00248-01} The following file and directory queries
+and types are provided:
+
+84/2
+ type File_Kind is (Directory, Ordinary_File, Special_File);
+
+85/2
+ The type File_Kind represents the kind of file represented by
+ an external file or directory.
+
+86/2
+ type File_Size is range 0 .. implementation-defined;
+
+87/2
+ The type File_Size represents the size of an external file.
+
+87.a/2
+ Implementation defined: The maximum value for a file size in
+ Directories.
+
+88/2
+ function Exists (Name : in String) return Boolean;
+
+89/2
+ Returns True if an external file represented by Name exists,
+ and False otherwise. The exception Name_Error is propagated
+ if the string given as Name does not allow the identification
+ of an external file (including directories and special files).
+
+90/2
+ function Kind (Name : in String) return File_Kind;
+
+91/2
+ Returns the kind of external file represented by Name. The
+ exception Name_Error is propagated if the string given as Name
+ does not allow the identification of an existing external
+ file.
+
+92/2
+ function Size (Name : in String) return File_Size;
+
+93/2
+ Returns the size of the external file represented by Name.
+ The size of an external file is the number of stream elements
+ contained in the file. If the external file is not an
+ ordinary file, the result is implementation-defined. The
+ exception Name_Error is propagated if the string given as Name
+ does not allow the identification of an existing external
+ file. The exception Constraint_Error is propagated if the
+ file size is not a value of type File_Size.
+
+93.a/2
+ Implementation defined: The result for Directories.Size for a
+ directory or special file
+
+93.b/2
+ Discussion: We allow raising Constraint_Error, so that an
+ implementation for a system with 64-bit file sizes does not
+ need to support full numerics on 64-bit integers just to
+ implement this package. Of course, if 64-bit integers are
+ available on such a system, they should be used when defining
+ type File_Size.
+
+94/2
+ function Modification_Time (Name : in String) return Ada.Calendar.Time;
+
+95/2
+ Returns the time that the external file represented by Name
+ was most recently modified. If the external file is not an
+ ordinary file, the result is implementation-defined. The
+ exception Name_Error is propagated if the string given as Name
+ does not allow the identification of an existing external
+ file. The exception Use_Error is propagated if the external
+ environment does not support reading the modification time of
+ the file with the name given by Name (in the absence of
+ Name_Error).
+
+95.a/2
+ Implementation defined: The result for
+ Directories.Modification_Time for a directory or special file.
+
+96/2
+{AI95-00248-01AI95-00248-01} The following directory searching
+operations and types are provided:
+
+97/2
+ type Directory_Entry_Type is limited private;
+
+98/2
+ The type Directory_Entry_Type represents a single item in a
+ directory. These items can only be created by the
+ Get_Next_Entry procedure in this package. Information about
+ the item can be obtained from the functions declared in this
+ package. A default-initialized object of this type is
+ invalid; objects returned from Get_Next_Entry are valid.
+
+99/2
+ type Filter_Type is array (File_Kind) of Boolean;
+
+100/2
+ The type Filter_Type specifies which directory entries are
+ provided from a search operation. If the Directory component
+ is True, directory entries representing directories are
+ provided. If the Ordinary_File component is True, directory
+ entries representing ordinary files are provided. If the
+ Special_File component is True, directory entries representing
+ special files are provided.
+
+101/2
+ type Search_Type is limited private;
+
+102/2
+ The type Search_Type contains the state of a directory search.
+ A default-initialized Search_Type object has no entries
+ available (function More_Entries returns False). Type
+ Search_Type needs finalization (see *note 7.6::).
+
+103/2
+ procedure Start_Search (Search : in out Search_Type;
+ Directory : in String;
+ Pattern : in String;
+ Filter : in Filter_Type := (others => True));
+
+104/3
+ {AI05-0092-1AI05-0092-1} {AI05-0262-1AI05-0262-1} Starts a
+ search in the directory named by Directory for entries
+ matching Pattern and Filter. Pattern represents a pattern for
+ matching file names. If Pattern is the null string, all items
+ in the directory are matched; otherwise, the interpretation of
+ Pattern is implementation-defined. Only items that match
+ Filter will be returned. After a successful call on
+ Start_Search, the object Search may have entries available,
+ but it may have no entries available if no files or
+ directories match Pattern and Filter. The exception
+ Name_Error is propagated if the string given by Directory does
+ not identify an existing directory, or if Pattern does not
+ allow the identification of any possible external file or
+ directory. The exception Use_Error is propagated if the
+ external environment does not support the searching of the
+ directory with the given name (in the absence of Name_Error).
+ When Start_Search propagates Name_Error or Use_Error, the
+ object Search will have no entries available.
+
+104.a/2
+ Implementation defined: The interpretation of a nonnull search
+ pattern in Directories.
+
+105/2
+ procedure End_Search (Search : in out Search_Type);
+
+106/2
+ Ends the search represented by Search. After a successful
+ call on End_Search, the object Search will have no entries
+ available.
+
+106.a/2
+ Ramification: The only way that a call to End_Search could be
+ unsuccessful if Device_Error (see *note A.13::) is raised
+ because of an underlying failure (or bug).
+
+107/2
+ function More_Entries (Search : in Search_Type) return Boolean;
+
+108/2
+ Returns True if more entries are available to be returned by a
+ call to Get_Next_Entry for the specified search object, and
+ False otherwise.
+
+109/2
+ procedure Get_Next_Entry (Search : in out Search_Type;
+ Directory_Entry : out Directory_Entry_Type);
+
+110/3
+ {AI05-0262-1AI05-0262-1} Returns the next Directory_Entry for
+ the search described by Search that matches the pattern and
+ filter. If no further matches are available, Status_Error is
+ raised. It is implementation-defined as to whether the
+ results returned by this subprogram are altered if the
+ contents of the directory are altered while the Search object
+ is valid (for example, by another program). The exception
+ Use_Error is propagated if the external environment does not
+ support continued searching of the directory represented by
+ Search.
+
+110.a/2
+ Implementation defined: The results of a Directories search if
+ the contents of the directory are altered while a search is in
+ progress.
+
+111/2
+ procedure Search (
+ Directory : in String;
+ Pattern : in String;
+ Filter : in Filter_Type := (others => True);
+ Process : not null access procedure (
+ Directory_Entry : in Directory_Entry_Type));
+
+112/3
+ {AI05-0092-1AI05-0092-1} {AI05-0262-1AI05-0262-1} Searches in
+ the directory named by Directory for entries matching Pattern
+ and Filter. The subprogram designated by Process is called
+ with each matching entry in turn. Pattern represents a
+ pattern for matching file names. If Pattern is the null
+ string, all items in the directory are matched; otherwise, the
+ interpretation of Pattern is implementation-defined. Only
+ items that match Filter will be returned. The exception
+ Name_Error is propagated if the string given by Directory does
+ not identify an existing directory, or if Pattern does not
+ allow the identification of any possible external file or
+ directory. The exception Use_Error is propagated if the
+ external environment does not support the searching of the
+ directory with the given name (in the absence of Name_Error).
+
+112.a/2
+ Discussion: "In turn" means that the calls to the subprogram
+ designated by Process are not made in parallel; they can be
+ made in any order but must be in sequence.
+
+113/2
+ function Simple_Name (Directory_Entry : in Directory_Entry_Type)
+ return String;
+
+114/2
+ Returns the simple external name of the external file
+ (including directories) represented by Directory_Entry. The
+ format of the name returned is implementation-defined. The
+ exception Status_Error is propagated if Directory_Entry is
+ invalid.
+
+115/2
+ function Full_Name (Directory_Entry : in Directory_Entry_Type)
+ return String;
+
+116/2
+ Returns the full external name of the external file (including
+ directories) represented by Directory_Entry. The format of
+ the name returned is implementation-defined. The exception
+ Status_Error is propagated if Directory_Entry is invalid.
+
+117/2
+ function Kind (Directory_Entry : in Directory_Entry_Type)
+ return File_Kind;
+
+118/2
+ Returns the kind of external file represented by
+ Directory_Entry. The exception Status_Error is propagated if
+ Directory_Entry is invalid.
+
+119/2
+ function Size (Directory_Entry : in Directory_Entry_Type)
+ return File_Size;
+
+120/2
+ Returns the size of the external file represented by
+ Directory_Entry. The size of an external file is the number
+ of stream elements contained in the file. If the external
+ file represented by Directory_Entry is not an ordinary file,
+ the result is implementation-defined. The exception
+ Status_Error is propagated if Directory_Entry is invalid. The
+ exception Constraint_Error is propagated if the file size is
+ not a value of type File_Size.
+
+121/2
+ function Modification_Time (Directory_Entry : in Directory_Entry_Type)
+ return Ada.Calendar.Time;
+
+122/2
+ Returns the time that the external file represented by
+ Directory_Entry was most recently modified. If the external
+ file represented by Directory_Entry is not an ordinary file,
+ the result is implementation-defined. The exception
+ Status_Error is propagated if Directory_Entry is invalid. The
+ exception Use_Error is propagated if the external environment
+ does not support reading the modification time of the file
+ represented by Directory_Entry.
+
+ _Implementation Requirements_
+
+123/2
+For Copy_File, if Source_Name identifies an existing external ordinary
+file created by a predefined Ada input-output package, and Target_Name
+and Form can be used in the Create operation of that input-output
+package with mode Out_File without raising an exception, then Copy_File
+shall not propagate Use_Error.
+
+123.a/2
+ Discussion: This means that Copy_File will copy any file that
+ the Ada programmer could copy (by writing some possibly
+ complicated Ada code).
+
+ _Implementation Advice_
+
+124/2
+If other information about a file (such as the owner or creation date)
+is available in a directory entry, the implementation should provide
+functions in a child package Directories.Information to retrieve it.
+
+124.a/2
+ Implementation Advice: Package Directories.Information should
+ be provided to retrieve other information about a file.
+
+124.b/2
+ Implementation Note: For Windows®, Directories.Information
+ should contain at least the following routines:
+
+124.c/2
+ package Ada.Directories.Information is
+ -- System-specific directory information.
+ -- Version for the Microsoft® Windows® operating system.
+
+124.d/2
+ function Creation_Time (Name : in String) return Ada.Calendar.Time;
+
+124.e/2
+ function Last_Access_Time (Name : in String) return Ada.Calendar.Time;
+
+124.f/2
+ function Is_Read_Only (Name : in String) return Boolean;
+
+124.g/2
+ function Needs_Archiving (Name : in String) return Boolean;
+ -- This generally means that the file needs to be backed up.
+ -- The flag is only cleared by backup programs.
+
+124.h/2
+ function Is_Compressed (Name : in String) return Boolean;
+
+124.i/2
+ function Is_Encrypted (Name : in String) return Boolean;
+
+124.j/2
+ function Is_Hidden (Name : in String) return Boolean;
+
+124.k/2
+ function Is_System (Name : in String) return Boolean;
+
+124.l/2
+ function Is_Offline (Name : in String) return Boolean;
+
+124.m/2
+ function Is_Temporary (Name : in String) return Boolean;
+
+124.n/2
+ function Is_Sparse (Name : in String) return Boolean;
+
+124.o/2
+ function Is_Not_Indexed (Name : in String) return Boolean;
+
+124.p/2
+ function Creation_Time (Directory_Entry : in Directory_Entry_Type)
+ return Ada.Calendar.Time;
+
+124.q/2
+ function Last_Access_Time (Directory_Entry : in Directory_Entry_Type)
+ return Ada.Calendar.Time;
+
+124.r/2
+ function Is_Read_Only (Directory_Entry : in Directory_Entry_Type) return Boolean;
+
+124.s/2
+ function Needs_Archiving (Directory_Entry : in Directory_Entry_Type) return Boolean;
+ -- This generally means that the file needs to be backed up.
+ -- The flag is only cleared by backup programs.
+
+124.t/2
+ function Is_Compressed (Directory_Entry : in Directory_Entry_Type) return Boolean;
+
+124.u/2
+ function Is_Encrypted (Directory_Entry : in Directory_Entry_Type) return Boolean;
+
+124.v/2
+ function Is_Hidden (Directory_Entry : in Directory_Entry_Type) return Boolean;
+
+124.w/2
+ function Is_System (Directory_Entry : in Directory_Entry_Type) return Boolean;
+
+124.x/2
+ function Is_Offline (Directory_Entry : in Directory_Entry_Type) return Boolean;
+
+124.y/2
+ function Is_Temporary (Directory_Entry : in Directory_Entry_Type) return Boolean;
+
+124.z/2
+ function Is_Sparse (Directory_Entry : in Directory_Entry_Type) return Boolean;
+
+124.aa/2
+ function Is_Not_Indexed (Directory_Entry : in Directory_Entry_Type) return Boolean;
+
+124.bb/2
+ -- Additional implementation-defined subprograms allowed here.
+ end Ada.Directories.Information;
+
+124.cc/2
+ For Unix-like systems (Unix, POSIX, Linux, etc.),
+ Directories.Information should contain at least the following
+ routines:
+
+124.dd/2
+ package Ada.Directories.Information is
+ -- System-specific directory information.
+ -- Unix and similar systems version.
+
+124.ee/2
+ function Last_Access_Time (Name : in String) return Ada.Calendar.Time;
+
+124.ff/2
+ function Last_Status_Change_Time (Name : in String) return Ada.Calendar.Time;
+
+124.gg/2
+ type Permission is
+ (Others_Execute, Others_Write, Others_Read,
+ Group_Execute, Group_Write, Group_Read,
+ Owner_Execute, Owner_Write, Owner_Read,
+ Set_Group_ID, Set_User_ID);
+
+124.hh/2
+ type Permission_Set_Type is array (Permission) of Boolean;
+
+124.ii/2
+ function Permission_Set (Name : in String) return Permission_Set_Type;
+
+124.jj/2
+ function Owner (Name : in String) return String;
+ -- Returns the image of the User_Id. If a definition of User_Id
+ -- is available, an implementation-defined version of Owner
+ -- returning User_Id should also be defined.
+
+124.kk/3
+ {AI05-0005-1AI05-0005-1} function Group (Name : in String) return String;
+ -- Returns the image of the Group_Id. If a definition of Group_Id
+ -- is available, an implementation-defined version of Group
+ -- returning Group_Id should also be defined.
+
+124.ll/2
+ function Is_Block_Special_File (Name : in String) return Boolean;
+
+124.mm/2
+ function Is_Character_Special_File (Name : in String) return Boolean;
+
+124.nn/2
+ function Is_FIFO (Name : in String) return Boolean;
+
+124.oo/2
+ function Is_Symbolic_Link (Name : in String) return Boolean;
+
+124.pp/2
+ function Is_Socket (Name : in String) return Boolean;
+
+124.qq/2
+ function Last_Access_Time (Directory_Entry : in Directory_Entry_Type)
+ return Ada.Calendar.Time;
+
+124.rr/2
+ function Last_Status_Change_Time (Directory_Entry : in Directory_Entry_Type)
+ return Ada.Calendar.Time;
+
+124.ss/2
+ function Permission_Set (Directory_Entry : in Directory_Entry_Type)
+ return Permission_Set_Type;
+
+124.tt/2
+ function Owner (Directory_Entry : in Directory_Entry_Type) return String;
+ -- See Owner above.
+
+124.uu/2
+ function Group (Directory_Entry : in Directory_Entry_Type) return String;
+ -- See Group above.
+
+124.vv/2
+ function Is_Block_Special_File (Directory_Entry : in Directory_Entry_Type)
+ return Boolean;
+
+124.ww/2
+ function Is_Character_Special_File (Directory_Entry : in Directory_Entry_Type)
+ return Boolean;
+
+124.xx/2
+ function Is_FIFO (Directory_Entry : in Directory_Entry_Type) return Boolean;
+
+124.yy/2
+ function Is_Symbolic_Link (Directory_Entry : in Directory_Entry_Type)
+ return Boolean;
+
+124.zz/2
+ function Is_Socket (Directory_Entry : in Directory_Entry_Type) return Boolean;
+
+124.aaa/2
+ -- Additional implementation-defined subprograms allowed here.
+ end Ada.Directories.Information;
+
+124.bbb/2
+ We give these definitions to give guidance so that every
+ implementation for a given target is not unnecessarily
+ different. Implementers are encouraged to make packages for
+ other targets as similar to these as possible.
+
+125/3
+{AI05-0231-1AI05-0231-1} Start_Search and Search should raise Name_Error
+if Pattern is malformed, but not if it could represent a file in the
+directory but does not actually do so.
+
+125.a/3
+ Implementation Advice: Directories.Start_Search and
+ Directories.Search should raise Name_Error for malformed
+ patterns.
+
+126/2
+Rename should be supported at least when both New_Name and Old_Name are
+simple names and New_Name does not identify an existing external file.
+
+126.a/2
+ Implementation Advice: Directories.Rename should be supported
+ at least when both New_Name and Old_Name are simple names and
+ New_Name does not identify an existing external file.
+
+126.b/2
+ Discussion: "Supported" includes raising an exception if
+ either name is malformed, the file to rename doesn't exist,
+ insufficient permission for the operation exists, or similar
+ problems. But this advice requires implementations to
+ document what they do, and tells implementers that simply
+ raising Use_Error isn't acceptable.
+
+ NOTES
+
+127/2
+ 41 The operations Containing_Directory, Full_Name, Simple_Name,
+ Base_Name, Extension, and Compose operate on file names, not
+ external files. The files identified by these operations do not
+ need to exist. Name_Error is raised only if the file name is
+ malformed and cannot possibly identify a file. Of these
+ operations, only the result of Full_Name depends on the current
+ default directory; the result of the others depends only on their
+ parameters.
+
+128/2
+ 42 Using access types, values of Search_Type and
+ Directory_Entry_Type can be saved and queried later. However,
+ another task or application can modify or delete the file
+ represented by a Directory_Entry_Type value or the directory
+ represented by a Search_Type value; such a value can only give the
+ information valid at the time it is created. Therefore, long-term
+ storage of these values is not recommended.
+
+129/2
+ 43 If the target system does not support directories inside of
+ directories, then Kind will never return Directory and
+ Containing_Directory will always raise Use_Error.
+
+130/2
+ 44 If the target system does not support creation or deletion of
+ directories, then Create_Directory, Create_Path, Delete_Directory,
+ and Delete_Tree will always propagate Use_Error.
+
+131/2
+ 45 To move a file or directory to a different location, use
+ Rename. Most target systems will allow renaming of files from one
+ directory to another. If the target file or directory might
+ already exist, it should be deleted first.
+
+131.a/2
+ Discussion: While Rename is only guaranteed to work for name
+ changes within a single directory, its unlikely that
+ implementers would purposely prevent functionality present in
+ the underlying system from working. To move a file totally
+ portably, it's necessary to handle failure of the Rename and
+ fall back to Copy_File and Delete:
+
+131.b
+ begin
+ Rename (Source, Target);
+ exception
+ when Use_Error =>
+ Copy_File (Source, Target);
+ Delete (Source);
+ end;
+
+ _Extensions to Ada 95_
+
+131.c/2
+ {AI95-00248-01AI95-00248-01} Package Ada.Directories is new.
+
+ _Inconsistencies With Ada 2005_
+
+131.d/3
+ {AI05-0231-1AI05-0231-1} Correction: Clarified when and which
+ exceptions are raised for Start_Search, Search,
+ Delete_Directory, and Rename. If an implementation followed
+ the original incorrect wording, it might raise Use_Error
+ instead of Name_Error for Start_Search and Search, Name_Error
+ instead of Use_Error for Rename, and might have deleted a
+ nonempty directory instead of raising Use_Error for
+ Delete_Directory. The first two cases are very unlikely to
+ matter in practice, and it unlikely that an implementation
+ would have followed the latter implementation strategy, as it
+ would be more work and would make Delete_Directory identical
+ to Delete_Tree (which is obvious nonsense).
+
+ _Incompatibilities With Ada 2005_
+
+131.e/3
+ {AI05-0049-1AI05-0049-1} A new enumeration type Name_Case_Kind
+ and a new function Name_Case_Equivalence is added to
+ Directories. If Directories is referenced in a use_clause,
+ and an entity E with a defining_identifier of one of the new
+ entities is defined in a package that is also referenced in a
+ use_clause, the entity E may no longer be use-visible,
+ resulting in errors. This should be rare and is easily fixed
+ if it does occur.
+
+ _Wording Changes from Ada 2005_
+
+131.f/3
+ {AI05-0271-1AI05-0271-1} Correction: We now explicitly say
+ that the behavior of Create_Path and Copy_File is unspecified
+ when Use_Error is raised. Nothing has changed here, as the
+ behavior was (implicitly) unspecified in the 2007 Amendment.
+
+* Menu:
+
+* A.16.1 :: The Package Directories.Hierarchical_File_Names
+
+\1f
+File: aarm2012.info, Node: A.16.1, Up: A.16
+
+A.16.1 The Package Directories.Hierarchical_File_Names
+------------------------------------------------------
+
+1/3
+{AI05-0049-1AI05-0049-1} The library package
+Directories.Hierarchical_File_Names is an optional package providing
+operations for file name construction and decomposition for targets with
+hierarchical file naming.
+
+ _Static Semantics_
+
+2/3
+{AI05-0049-1AI05-0049-1} If provided, the library package
+Directories.Hierarchical_File_Names has the following declaration:
+
+3/3
+ package Ada.Directories.Hierarchical_File_Names is
+
+4/3
+ function Is_Simple_Name (Name : in String) return Boolean;
+
+5/3
+ function Is_Root_Directory_Name (Name : in String) return Boolean;
+
+6/3
+ function Is_Parent_Directory_Name (Name : in String) return Boolean;
+
+7/3
+ function Is_Current_Directory_Name (Name : in String) return Boolean;
+
+8/3
+ function Is_Full_Name (Name : in String) return Boolean;
+
+9/3
+ function Is_Relative_Name (Name : in String) return Boolean;
+
+10/3
+ function Simple_Name (Name : in String) return String
+ renames Ada.Directories.Simple_Name;
+
+11/3
+ function Containing_Directory (Name : in String) return String
+ renames Ada.Directories.Containing_Directory;
+
+12/3
+ function Initial_Directory (Name : in String) return String;
+
+13/3
+ function Relative_Name (Name : in String) return String;
+
+14/3
+ function Compose (Directory : in String := "";
+ Relative_Name : in String;
+ Extension : in String := "") return String;
+
+15/3
+ end Ada.Directories.Hierarchical_File_Names;
+
+16/3
+{AI05-0049-1AI05-0049-1} {AI05-0269-1AI05-0269-1} In addition to the
+operations provided in package Directories.Hierarchical_File_Names, the
+operations in package Directories can be used with hierarchical file
+names. In particular, functions Full_Name, Base_Name, and Extension
+provide additional capabilities for hierarchical file names.
+
+17/3
+ function Is_Simple_Name (Name : in String) return Boolean;
+
+18/3
+ Returns True if Name is a simple name, and returns False
+ otherwise.
+
+19/3
+ function Is_Root_Directory_Name (Name : in String) return Boolean;
+
+20/3
+ Returns True if Name is syntactically a root (a directory that
+ cannot be decomposed further), and returns False otherwise.
+
+20.a/3
+ Implementation Note: For Unix and Unix-like systems, "/" is
+ the root. For Windows, "C:'\'" and "'\''\'Computer'\'Share"
+ are roots.
+
+21/3
+ function Is_Parent_Directory_Name (Name : in String) return Boolean;
+
+22/3
+ Returns True if Name can be used to indicate symbolically the
+ parent directory of any directory, and returns False
+ otherwise.
+
+22.a/3
+ Implementation Note: Is_Parent_Directory_Name returns True if
+ and only if Name is ".." for both Unix and Windows.
+
+23/3
+ function Is_Current_Directory_Name (Name : in String) return Boolean;
+
+24/3
+ Returns True if Name can be used to indicate symbolically the
+ directory itself for any directory, and returns False
+ otherwise.
+
+24.a/3
+ Implementation Note: Is_Current_Directory_Name returns True if
+ and only if Name is "." for both Unix and Windows.
+
+25/3
+ function Is_Full_Name (Name : in String) return Boolean;
+
+26/3
+ Returns True if the leftmost directory part of Name is a root,
+ and returns False otherwise.
+
+27/3
+ function Is_Relative_Name (Name : in String) return Boolean;
+
+28/3
+ {AI05-0049-1AI05-0049-1} {AI05-0269-1AI05-0269-1} Returns True
+ if Name allows the identification of an external file
+ (including directories and special files) but is not a full
+ name, and returns False otherwise.
+
+28.a/3
+ Ramification: Relative names include simple names as a special
+ case. This function returns False if the syntax of the name
+ is incorrect.
+
+29/3
+ function Initial_Directory (Name : in String) return String;
+
+30/3
+ {AI05-0049-1AI05-0049-1} {AI05-0248-1AI05-0248-1} Returns the
+ leftmost directory part in Name. [That is, it returns a root
+ directory name (for a full name), or one of a parent directory
+ name, a current directory name, or a simple name (for a
+ relative name).] The exception Name_Error is propagated if
+ the string given as Name does not allow the identification of
+ an external file (including directories and special files).
+
+31/3
+ function Relative_Name (Name : in String) return String;
+
+32/3
+ Returns the entire file name except the Initial_Directory
+ portion. The exception Name_Error is propagated if the string
+ given as Name does not allow the identification of an external
+ file (including directories and special files), or if Name has
+ a single part (this includes if any of Is_Simple_Name,
+ Is_Root_Directory_Name, Is_Parent_Directory_Name, or
+ Is_Current_Directory_Name are True).
+
+32.a/3
+ Ramification: The result might be a simple name.
+
+33/3
+ function Compose (Directory : in String := "";
+ Relative_Name : in String;
+ Extension : in String := "") return String;
+
+34/3
+ Returns the name of the external file with the specified
+ Directory, Relative_Name, and Extension. The exception
+ Name_Error is propagated if the string given as Directory is
+ not the null string and does not allow the identification of a
+ directory, or if Is_Relative_Name (Relative_Name) is False, or
+ if the string given as Extension is not the null string and is
+ not a possible extension, or if Extension is not the null
+ string and Simple_Name (Relative_Name) is not a base name.
+
+35/3
+ The result of Compose is a full name if Is_Full_Name
+ (Directory) is True; result is a relative name otherwise.
+
+35.a/3
+ Ramification: Name_Error is raised by Compose if Directory is
+ not the null string, and both Is_Full_Name and
+ Is_Relative_Name return False.
+
+35.b/3
+ Discussion: A common security problem is to include a parent
+ directory name in the middle of a file name; this is often
+ used to navigate outside of an intended root directory. We
+ considered attempting to prevent that case by having Compose
+ detect it and raise an exception. But the extra rules
+ necessary were more confusing than helpful.
+
+35.c/3
+ We can say more about the details of these operations by
+ adopting the notation of a subscript to specify how many path
+ fragments a particular result has. Then, we can abbreviate
+ "Full Name" as "Full" and "Relative Name" as "Rel". In this
+ notation, Unix file name "a/b" is a Rel(2), "../c/d" is a
+ Rel(3), and "/a/b" is a Full(2). Rel(1) is equivalent to a
+ simple name; thus we don't have to describe that separately.
+
+35.d/3
+ In this notation,
+
+35.e/3
+ For N>1,
+ Containing_Directory(Rel(N)) = Leftmost Rel(N-1),
+ Containing_Directory(Full(N)) = Leftmost Full(N-1),
+ Else if N = 1, raise Name_Error.
+
+
+35.f/3
+ Similarly,
+
+35.g/3
+ For N>1,
+ Relative_Name(Rel(N)) = Rightmost Rel(N-1),
+ Relative_Name(Full(N)) = Rightmost Full(N-1),
+ Else if N = 1, raise Name_Error.
+
+
+35.h/3
+ Finally, for Compose (ignoring the extension here):
+
+35.i/3
+ Compose (Directory => Full(N), Relative_Name => Rel(M)) => Full(N+M)
+ Compose (Directory => Rel(N), Relative_Name => Rel(M)) => Rel(N+M)
+ Name_Error if Relative_Name is a Full(M).
+
+
+35.j/3
+ We didn't try to write wording to reflect these details of
+ these functions.
+
+ _Implementation Advice_
+
+36/3
+{AI05-0049-1AI05-0049-1} Directories.Hierarchical_File_Names should be
+provided for systems with hierarchical file naming, and should not be
+provided on other systems.
+
+36.a/3
+ Implementation Advice: Directories.Hierarchical_File_Names
+ should be provided for systems with hierarchical file naming,
+ and should not be provided on other systems.
+
+36.b/3
+ Implementation Note: This package should be provided when
+ targeting Microsoft® Windows®, Unix, Linux, and most Unix-like
+ systems.
+
+ NOTES
+
+37/3
+ 46 {AI05-0049-1AI05-0049-1} These operations operate on file
+ names, not external files. The files identified by these
+ operations do not need to exist. Name_Error is raised only as
+ specified or if the file name is malformed and cannot possibly
+ identify a file. The result of these operations depends only on
+ their parameters.
+
+38/3
+ 47 {AI05-0049-1AI05-0049-1} Containing_Directory raises Use_Error
+ if Name does not have a containing directory, including when any of
+ Is_Simple_Name, Is_Root_Directory_Name, Is_Parent_Directory_Name,
+ or Is_Current_Directory_Name are True.
+
+38.a/3
+ Ramification: In particular, the default directory is not used
+ to find the containing directory either when
+ Is_Parent_Directory_Name or Is_Current_Directory_Name is True.
+ As noted above, these functions operate purely on the syntax
+ of the file names and do not attempt to interpret them. If
+ interpretation is needed, Directories.Full_Name can be to
+ expand any shorthands used before calling
+ Containing_Directory.
+
+ _Extensions to Ada 2005_
+
+38.b/3
+ {AI05-0049-1AI05-0049-1} Package
+ Ada.Directories.Hierarchical_File_Names is new.
+
+\1f
+File: aarm2012.info, Node: A.17, Next: A.18, Prev: A.16, Up: Annex A
+
+A.17 The Package Environment_Variables
+======================================
+
+1/2
+{AI95-00370-01AI95-00370-01} The package Environment_Variables allows a
+program to read or modify environment variables. Environment variables
+are name-value pairs, where both the name and value are strings. The
+definition of what constitutes an environment variable, and the meaning
+of the name and value, are implementation defined.
+
+1.a/2
+ Implementation defined: The definition and meaning of an
+ environment variable.
+
+ _Static Semantics_
+
+2/2
+{AI95-00370-01AI95-00370-01} The library package Environment_Variables
+has the following declaration:
+
+3/2
+ package Ada.Environment_Variables is
+ pragma Preelaborate(Environment_Variables);
+
+4/2
+ function Value (Name : in String) return String;
+
+4.1/3
+ {AI05-0285-1AI05-0285-1} function Value (Name : in String; Default : in String) return String;
+
+5/2
+ function Exists (Name : in String) return Boolean;
+
+6/2
+ procedure Set (Name : in String; Value : in String);
+
+7/2
+ procedure Clear (Name : in String);
+ procedure Clear;
+
+8/3
+ {AI05-0248-1AI05-0248-1} procedure Iterate
+ (Process : not null access procedure (Name, Value : in String));
+
+9/2
+ end Ada.Environment_Variables;
+
+10/2
+ function Value (Name : in String) return String;
+
+11/2
+ {AI95-00370-01AI95-00370-01} If the external execution
+ environment supports environment variables, then Value returns
+ the value of the environment variable with the given name. If
+ no environment variable with the given name exists, then
+ Constraint_Error is propagated. If the execution environment
+ does not support environment variables, then Program_Error is
+ propagated.
+
+11.1/3
+ function Value (Name : in String; Default : in String) return String;
+
+11.2/3
+ {AI05-0285-1AI05-0285-1} If the external execution environment
+ supports environment variables and an environment variable
+ with the given name currently exists, then Value returns its
+ value; otherwise, it returns Default.
+
+12/2
+ function Exists (Name : in String) return Boolean;
+
+13/3
+ {AI95-00370-01AI95-00370-01} {AI05-0264-1AI05-0264-1} If the
+ external execution environment supports environment variables
+ and an environment variable with the given name currently
+ exists, then Exists returns True; otherwise, it returns False.
+
+14/2
+ procedure Set (Name : in String; Value : in String);
+
+15/3
+ {AI95-00370-01AI95-00370-01} {AI05-0264-1AI05-0264-1} If the
+ external execution environment supports environment variables,
+ then Set first clears any existing environment variable with
+ the given name, and then defines a single new environment
+ variable with the given name and value. Otherwise,
+ Program_Error is propagated.
+
+16/2
+ If implementation-defined circumstances prohibit the
+ definition of an environment variable with the given name and
+ value, then Constraint_Error is propagated.
+
+16.a/2
+ Implementation defined: The circumstances where an environment
+ variable cannot be defined.
+
+17/2
+ It is implementation defined whether there exist values for
+ which the call Set(Name, Value) has the same effect as Clear
+ (Name).
+
+17.a/2
+ Implementation defined: Environment names for which Set has
+ the effect of Clear.
+
+18/2
+ procedure Clear (Name : in String);
+
+19/3
+ {AI95-00370-01AI95-00370-01} {AI05-0264-1AI05-0264-1}
+ {AI05-0269-1AI05-0269-1} If the external execution environment
+ supports environment variables, then Clear deletes all
+ existing environment variables with the given name.
+ Otherwise, Program_Error is propagated.
+
+20/2
+ procedure Clear;
+
+21/3
+ {AI95-00370-01AI95-00370-01} {AI05-0264-1AI05-0264-1} If the
+ external execution environment supports environment variables,
+ then Clear deletes all existing environment variables.
+ Otherwise, Program_Error is propagated.
+
+22/3
+ {AI05-0248-1AI05-0248-1} procedure Iterate
+ (Process : not null access procedure (Name, Value : in String));
+
+23/3
+ {AI95-00370-01AI95-00370-01} {AI05-0264-1AI05-0264-1} If the
+ external execution environment supports environment variables,
+ then Iterate calls the subprogram designated by Process for
+ each existing environment variable, passing the name and value
+ of that environment variable. Otherwise, Program_Error is
+ propagated.
+
+24/2
+ If several environment variables exist that have the same
+ name, Process is called once for each such variable.
+
+ _Bounded (Run-Time) Errors_
+
+25/2
+{AI95-00370-01AI95-00370-01} It is a bounded error to call Value if more
+than one environment variable exists with the given name; the possible
+outcomes are that:
+
+26/2
+ * one of the values is returned, and that same value is returned in
+ subsequent calls in the absence of changes to the environment; or
+
+27/2
+ * Program_Error is propagated.
+
+ _Erroneous Execution_
+
+28/2
+{AI95-00370-01AI95-00370-01} Making calls to the procedures Set or Clear
+concurrently with calls to any subprogram of package
+Environment_Variables, or to any instantiation of Iterate, results in
+erroneous execution.
+
+29/2
+Making calls to the procedures Set or Clear in the actual subprogram
+corresponding to the Process parameter of Iterate results in erroneous
+execution.
+
+ _Documentation Requirements_
+
+30/2
+{AI95-00370-01AI95-00370-01} An implementation shall document how the
+operations of this package behave if environment variables are changed
+by external mechanisms (for instance, calling operating system
+services).
+
+30.a/2
+ Documentation Requirement: The behavior of package
+ Environment_Variables when environment variables are changed
+ by external mechanisms.
+
+ _Implementation Permissions_
+
+31/2
+{AI95-00370-01AI95-00370-01} An implementation running on a system that
+does not support environment variables is permitted to define the
+operations of package Environment_Variables with the semantics
+corresponding to the case where the external execution environment does
+support environment variables. In this case, it shall provide a
+mechanism to initialize a nonempty set of environment variables prior to
+the execution of a partition.
+
+ _Implementation Advice_
+
+32/2
+{AI95-00370-01AI95-00370-01} If the execution environment supports
+subprocesses, the currently defined environment variables should be used
+to initialize the environment variables of a subprocess.
+
+32.a/2
+ Implementation Advice: If the execution environment supports
+ subprocesses, the current environment variables should be used
+ to initialize the environment variables of a subprocess.
+
+33/2
+Changes to the environment variables made outside the control of this
+package should be reflected immediately in the effect of the operations
+of this package. Changes to the environment variables made using this
+package should be reflected immediately in the external execution
+environment. This package should not perform any buffering of the
+environment variables.
+
+33.a/2
+ Implementation Advice: Changes to the environment variables
+ made outside the control of Environment_Variables should be
+ reflected immediately.
+
+ _Extensions to Ada 95_
+
+33.b/2
+ {AI95-00370-01AI95-00370-01} Package Environment_Variables is
+ new.
+
+ _Incompatibilities With Ada 2005_
+
+33.c/3
+ {AI05-0285-1AI05-0285-1} A new overloaded function Value is
+ added to Environment_Variables. If Environment_Variables is
+ referenced in a use_clause, and an entity E with the name
+ Value is defined in a package that is also referenced in a
+ use_clause, the entity E may no longer be use-visible,
+ resulting in errors. This should be rare and is easily fixed
+ if it does occur.
+
+\1f
+File: aarm2012.info, Node: A.18, Next: A.19, Prev: A.17, Up: Annex A
+
+A.18 Containers
+===============
+
+1/2
+{AI95-00302-03AI95-00302-03} This clause presents the specifications of
+the package Containers and several child packages, which provide
+facilities for storing collections of elements.
+
+1.a.1/3
+ Glossary entry: A container is an object that contain other
+ objects all of the same type, which could be class-wide.
+ Several predefined container types are provided by the
+ children of package Ada.Containers (see *note A.18.1::).
+
+2/2
+{AI95-00302-03AI95-00302-03} A variety of sequence and associative
+containers are provided. Each container includes a cursor type. A
+cursor is a reference to an element within a container. Many operations
+on cursors are common to all of the containers. A cursor referencing an
+element in a container is considered to be overlapping with the
+container object itself.
+
+2.a/2
+ Reason: The last sentence is intended to clarify that
+ operations that just use a cursor are on the same footing as
+ operations that use a container in terms of the reentrancy
+ rules of Annex A.
+
+3/2
+{AI95-00302-03AI95-00302-03} Within this clause we provide
+Implementation Advice for the desired average or worst case time
+complexity of certain operations on a container. This advice is
+expressed using the Landau symbol O(X). Presuming f is some function of
+a length parameter N and t(N) is the time the operation takes (on
+average or worst case, as specified) for the length N, a complexity of
+O(f(N)) means that there exists a finite A such that for any N,
+t(N)/f(N) < A.
+
+3.a/2
+ Discussion: Of course, an implementation can do better than a
+ specified O(f(N)): for example, O(1) meets the requirements
+ for O(log N).
+
+3.b/2
+ This concept seems to have as many names as there are authors.
+ We used "Landau symbol" because that's what our reference
+ does. But we'd also seen this referred as big-O notation
+ (sometimes written as big-oh), and as Bachmann notation.
+ Whatever the name, it always has the above definition.
+
+4/2
+If the advice suggests that the complexity should be less than O(f(N)),
+then for any arbitrarily small positive real D, there should exist a
+positive integer M such that for all N > M, t(N)/f(N) < D.
+
+5/3
+{AI05-0001-1AI05-0001-1} {AI05-0044-1AI05-0044-1} When a formal function
+is used to provide an ordering for a container, it is generally required
+to define a strict weak ordering. A function "<" defines a strict weak
+ordering if it is irreflexive, asymmetric, transitive, and in addition,
+if x < y for any values x and y, then for all other values z, (x < z) or
+(z < y).
+
+ _Language Design Principles_
+
+5.a/3
+ {AI95-00302-03AI95-00302-03} {AI05-0299-1AI05-0299-1} This
+ subclause provides a number of useful containers for Ada.
+ Only the most useful containers are provided. Ones that are
+ relatively easy to code, redundant, or rarely used are omitted
+ from this set, even if they are generally included in
+ containers libraries.
+
+5.b/2
+ The containers packages are modeled on the Standard Template
+ Library (STL), an algorithms and data structure library
+ popularized by Alexander Stepanov, and included in the C++
+ standard library. The structure and terminology differ from
+ the STL where that better maps to common Ada usage. For
+ instance, what the STL calls "iterators" are called "cursors"
+ here.
+
+5.c/2
+ The following major nonlimited containers are provided:
+
+5.d/2
+ * (Expandable) Vectors of any nonlimited type;
+
+5.e/2
+ * Doubly-linked Lists of any nonlimited type;
+
+5.f/2
+ * Hashed Maps keyed by any nonlimited hashable type, and
+ containing any nonlimited type;
+
+5.g/2
+ * Ordered Maps keyed by any nonlimited ordered type, and
+ containing any nonlimited type;
+
+5.h/3
+ * {AI05-0136-1AI05-0136-1} Hashed Sets of any nonlimited
+ hashable type;
+
+5.i/3
+ * {AI05-0136-1AI05-0136-1} Ordered Sets of any nonlimited
+ ordered type;
+
+5.i.1/3
+ * {AI05-0136-1AI05-0136-1} Multiway Trees of any nonlimited
+ type;
+
+5.i.2/3
+ * {AI05-0069-1AI05-0069-1} Holders of any (indefinite)
+ nonlimited type;
+
+5.i.3/3
+ * {AI05-0159-1AI05-0159-1} Synchronized queues of any
+ definite nonlimited type; and
+
+5.i.4/3
+ * {AI05-0159-1AI05-0159-1} Priority queues of any definite
+ nonlimited type.
+
+5.j/3
+ {AI05-0001-1AI05-0001-1} Separate versions for definite and
+ indefinite element types are provided, as those for definite
+ types can be implemented more efficiently. Similarly, a
+ separate bounded version is provided in order to give more
+ predictable memory usage.
+
+5.k/2
+ Each container includes a cursor, which is a reference to an
+ element within a container. Cursors generally remain valid as
+ long as the container exists and the element referenced is not
+ deleted. Many operations on cursors are common to all of the
+ containers. This makes it possible to write generic
+ algorithms that work on any kind of container.
+
+5.l/2
+ The containers packages are structured so that additional
+ packages can be added in the future. Indeed, we hope that
+ these packages provide the basis for a more extensive
+ secondary standard for containers.
+
+5.m/2
+ If containers with similar functionality (but different
+ performance characteristics) are provided (by the
+ implementation or by a secondary standard), we suggest that a
+ prefix be used to identify the class of the functionality:
+ "Ada.Containers.Bounded_Sets" (for a set with a maximum number
+ of elements); "Ada.Containers.Protected_Maps" (for a map which
+ can be accessed by multiple tasks at one time);
+ "Ada.Containers.Persistent_Vectors" (for a persistent vector
+ which continues to exist between executions of a program) and
+ so on.
+
+5.n/2
+ Note that the language already includes several requirements
+ that are important to the use of containers. These include:
+
+5.o/2
+ * Library packages must be reentrant - multiple tasks can
+ use the packages as long as they operate on separate
+ containers. Thus, it is only necessary for a user to
+ protect a container if a single container needs to be
+ used by multiple tasks.
+
+5.p/2
+ * Language-defined types must stream "properly". That
+ means that the stream attributes can be used to implement
+ persistence of containers when necessary, and containers
+ can be passed between partitions of a program.
+
+5.q/2
+ * Equality of language-defined types must compose
+ "properly". This means that the version of "=" directly
+ used by users is the same one that will be used in
+ generics and in predefined equality operators of types
+ with components of the containers and/or cursors. This
+ prevents the abstraction from breaking unexpectedly.
+
+5.q.1/3
+ * {AI05-0048-1AI05-0048-1} Redispatching is not allowed
+ (unless it is required). That means that overriding a
+ container operation will not change the behavior of any
+ other predefined container operation. This provides a
+ stable base for extensions.
+
+5.r/2
+ If a container's element type is controlled, the point at
+ which the element is finalized will depend on the
+ implementation of the container. We do not specify precisely
+ where this will happen (it will happen no later than the
+ finalization of the container, of course) in order to give
+ implementation's flexibility to cache, block, or split the
+ nodes of the container. In particular, Delete does not
+ necessarily finalize the element; the implementation may (or
+ may not) hold the space for reuse.
+
+5.s/2
+ This is not likely to be a hardship, as the element type has
+ to be nonlimited. Types used to manage scarce resources
+ generally need to be limited. Otherwise, the amount of
+ resources needed is hard to control, as the language allows a
+ lot of variation in the number or order of
+ adjusts/finalizations. For common uses of nonlimited
+ controlled types such as managing storage, the types already
+ have to manage arbitrary copies.
+
+5.t/2
+ The use of controlled types also brings up the possibility of
+ failure of finalization (and thus deallocation) of an element.
+ This is a "serious bug", as AI95-179 puts it, so we don't try
+ to specify what happens in that case. The implementation
+ should propagate the exception.
+
+5.u/2
+ Implementation Note: It is expected that exceptions propagated
+ from these operations do not damage containers. That is, if
+ Storage_Error is propagated because of an allocation failure,
+ or Constraint_Error is propagated by the assignment of
+ elements, the container can continue to be used without
+ further exceptions. The intent is that it should be possible
+ to recover from errors without losing data. We don't try to
+ state this formally in most cases, because it is hard to
+ define precisely what is and is not allowed behavior.
+
+5.v/2
+ Implementation Note: When this clause says that the behavior
+ of something is unspecified, we really mean that any result of
+ executing Ada code short of erroneous execution is allowed.
+ We do not mean that memory not belonging to the parameters of
+ the operation can be trashed. When we mean to allow erroneous
+ behavior, we specifically say that execution is erroneous.
+ All this means if the containers are written in Ada is that
+ checks should not be suppressed or removed assuming some
+ behavior of other code, and that the implementation should
+ take care to avoid creating internal dangling accesses by
+ assuming behavior from generic formals that can't be
+ guaranteed. We don't try to say this normatively because it
+ would be fairly complex, and implementers are unlikely to
+ increase their support costs by fielding implementations that
+ are unstable if given buggy hash functions, et al.
+
+ _Extensions to Ada 95_
+
+5.w/3
+ {AI95-00302-03AI95-00302-03} {AI05-0299-1AI05-0299-1} This
+ subclause is new. It just provides an introduction to the
+ following subclauses.
+
+ _Wording Changes from Ada 2005_
+
+5.x/3
+ {AI05-0044-1AI05-0044-1} Correction: Added a definition of
+ strict weak ordering.
+
+* Menu:
+
+* A.18.1 :: The Package Containers
+* A.18.2 :: The Generic Package Containers.Vectors
+* A.18.3 :: The Generic Package Containers.Doubly_Linked_Lists
+* A.18.4 :: Maps
+* A.18.5 :: The Generic Package Containers.Hashed_Maps
+* A.18.6 :: The Generic Package Containers.Ordered_Maps
+* A.18.7 :: Sets
+* A.18.8 :: The Generic Package Containers.Hashed_Sets
+* A.18.9 :: The Generic Package Containers.Ordered_Sets
+* A.18.10 :: The Generic Package Containers.Multiway_Trees
+* A.18.11 :: The Generic Package Containers.Indefinite_Vectors
+* A.18.12 :: The Generic Package Containers.Indefinite_Doubly_Linked_Lists
+* A.18.13 :: The Generic Package Containers.Indefinite_Hashed_Maps
+* A.18.14 :: The Generic Package Containers.Indefinite_Ordered_Maps
+* A.18.15 :: The Generic Package Containers.Indefinite_Hashed_Sets
+* A.18.16 :: The Generic Package Containers.Indefinite_Ordered_Sets
+* A.18.17 :: The Generic Package Containers.Indefinite_Multiway_Trees
+* A.18.18 :: The Generic Package Containers.Indefinite_Holders
+* A.18.19 :: The Generic Package Containers.Bounded_Vectors
+* A.18.20 :: The Generic Package Containers.Bounded_Doubly_Linked_Lists
+* A.18.21 :: The Generic Package Containers.Bounded_Hashed_Maps
+* A.18.22 :: The Generic Package Containers.Bounded_Ordered_Maps
+* A.18.23 :: The Generic Package Containers.Bounded_Hashed_Sets
+* A.18.24 :: The Generic Package Containers.Bounded_Ordered_Sets
+* A.18.25 :: The Generic Package Containers.Bounded_Multiway_Trees
+* A.18.26 :: Array Sorting
+* A.18.27 :: The Generic Package Containers.Synchronized_Queue_Interfaces
+* A.18.28 :: The Generic Package Containers.Unbounded_Synchronized_Queues
+* A.18.29 :: The Generic Package Containers.Bounded_Synchronized_Queues
+* A.18.30 :: The Generic Package Containers.Unbounded_Priority_Queues
+* A.18.31 :: The Generic Package Containers.Bounded_Priority_Queues
+* A.18.32 :: Example of Container Use
+
+\1f
+File: aarm2012.info, Node: A.18.1, Next: A.18.2, Up: A.18
+
+A.18.1 The Package Containers
+-----------------------------
+
+1/2
+{AI95-00302-03AI95-00302-03} The package Containers is the root of the
+containers subsystem.
+
+ _Static Semantics_
+
+2/2
+{AI95-00302-03AI95-00302-03} The library package Containers has the
+following declaration:
+
+3/2
+ package Ada.Containers is
+ pragma Pure(Containers);
+
+4/2
+ type Hash_Type is mod implementation-defined;
+
+5/2
+ type Count_Type is range 0 .. implementation-defined;
+
+5.1/3
+ {AI05-0001-1AI05-0001-1} Capacity_Error : exception;
+
+6/2
+ end Ada.Containers;
+
+7/2
+{AI95-00302-03AI95-00302-03} Hash_Type represents the range of the
+result of a hash function. Count_Type represents the (potential or
+actual) number of elements of a container.
+
+7.a/2
+ Implementation defined: The value of
+ Containers.Hash_Type'Modulus. The value of
+ Containers.Count_Type'Last.
+
+7.1/3
+{AI05-0262-1AI05-0262-1} Capacity_Error is raised when the capacity of a
+container is exceeded.
+
+ _Implementation Advice_
+
+8/2
+{AI95-00302-03AI95-00302-03} Hash_Type'Modulus should be at least 2**32.
+Count_Type'Last should be at least 2**31-1.
+
+8.a/2
+ Implementation Advice: Containers.Hash_Type'Modulus should be
+ at least 2**32. Containers.Count_Type'Last should be at least
+ 2**31-1.
+
+8.b/2
+ Discussion: This is not a requirement so that these types can
+ be declared properly on machines with native sizes that are
+ not 32 bits. For instance, a 24-bit target could use 2**24
+ for Hash_Type'Modulus.
+
+ _Extensions to Ada 95_
+
+8.c/2
+ {AI95-00302-03AI95-00302-03} The package Containers is new.
+
+ _Incompatibilities With Ada 2005_
+
+8.d/3
+ {AI05-0001-1AI05-0001-1} Exception Capacity_Error is added to
+ Containers. If Containers is referenced in a use_clause, and
+ an entity with the name Capacity_Error is defined in a package
+ that is also referenced in a use_clause, the entity
+ Capacity_Error may no longer be use-visible, resulting in
+ errors. This should be rare and is easily fixed if it does
+ occur.
+
+\1f
+File: aarm2012.info, Node: A.18.2, Next: A.18.3, Prev: A.18.1, Up: A.18
+
+A.18.2 The Generic Package Containers.Vectors
+---------------------------------------------
+
+1/2
+The language-defined generic package Containers.Vectors provides private
+types Vector and Cursor, and a set of operations for each type. A
+vector container allows insertion and deletion at any position, but it
+is specifically optimized for insertion and deletion at the high end
+(the end with the higher index) of the container. A vector container
+also provides random access to its elements.
+
+2/2
+A vector container behaves conceptually as an array that expands as
+necessary as items are inserted. The length of a vector is the number
+of elements that the vector contains. The capacity of a vector is the
+maximum number of elements that can be inserted into the vector prior to
+it being automatically expanded.
+
+3/2
+Elements in a vector container can be referred to by an index value of a
+generic formal type. The first element of a vector always has its index
+value equal to the lower bound of the formal type.
+
+4/2
+A vector container may contain empty elements. Empty elements do not
+have a specified value.
+
+4.a/2
+ Implementation Note: Vectors are not intended to be sparse
+ (that is, there are elements at all defined positions). Users
+ are expected to use other containers (like a Map) when they
+ need sparse structures (there is a Note to this effect at the
+ end of this subclause).
+
+4.b/2
+ The internal array is a conceptual model of a vector. There
+ is no requirement for an implementation to be a single
+ contiguous array.
+
+ _Static Semantics_
+
+5/2
+{AI95-00302-03AI95-00302-03} The generic library package
+Containers.Vectors has the following declaration:
+
+6/3
+ {AI05-0084-1AI05-0084-1} {AI05-0212-1AI05-0212-1} with Ada.Iterator_Interfaces;
+ generic
+ type Index_Type is range <>;
+ type Element_Type is private;
+ with function "=" (Left, Right : Element_Type)
+ return Boolean is <>;
+ package Ada.Containers.Vectors is
+ pragma Preelaborate(Vectors);
+ pragma Remote_Types(Vectors);
+
+7/2
+ subtype Extended_Index is
+ Index_Type'Base range
+ Index_Type'First-1 ..
+ Index_Type'Min (Index_Type'Base'Last - 1, Index_Type'Last) + 1;
+ No_Index : constant Extended_Index := Extended_Index'First;
+
+8/3
+ {AI05-0212-1AI05-0212-1} type Vector is tagged private
+ with Constant_Indexing => Constant_Reference,
+ Variable_Indexing => Reference,
+ Default_Iterator => Iterate,
+ Iterator_Element => Element_Type;
+ pragma Preelaborable_Initialization(Vector);
+
+9/2
+ type Cursor is private;
+ pragma Preelaborable_Initialization(Cursor);
+
+10/2
+ Empty_Vector : constant Vector;
+
+11/2
+ No_Element : constant Cursor;
+
+11.1/3
+ {AI05-0212-1AI05-0212-1} function Has_Element (Position : Cursor) return Boolean;
+
+11.2/3
+ {AI05-0212-1AI05-0212-1} package Vector_Iterator_Interfaces is new
+ Ada.Iterator_Interfaces (Cursor, Has_Element);
+
+12/2
+ function "=" (Left, Right : Vector) return Boolean;
+
+13/2
+ function To_Vector (Length : Count_Type) return Vector;
+
+14/2
+ function To_Vector
+ (New_Item : Element_Type;
+ Length : Count_Type) return Vector;
+
+15/2
+ function "&" (Left, Right : Vector) return Vector;
+
+16/2
+ function "&" (Left : Vector;
+ Right : Element_Type) return Vector;
+
+17/2
+ function "&" (Left : Element_Type;
+ Right : Vector) return Vector;
+
+18/2
+ function "&" (Left, Right : Element_Type) return Vector;
+
+19/2
+ function Capacity (Container : Vector) return Count_Type;
+
+20/2
+ procedure Reserve_Capacity (Container : in out Vector;
+ Capacity : in Count_Type);
+
+21/2
+ function Length (Container : Vector) return Count_Type;
+
+22/2
+ procedure Set_Length (Container : in out Vector;
+ Length : in Count_Type);
+
+23/2
+ function Is_Empty (Container : Vector) return Boolean;
+
+24/2
+ procedure Clear (Container : in out Vector);
+
+25/2
+ function To_Cursor (Container : Vector;
+ Index : Extended_Index) return Cursor;
+
+26/2
+ function To_Index (Position : Cursor) return Extended_Index;
+
+27/2
+ function Element (Container : Vector;
+ Index : Index_Type)
+ return Element_Type;
+
+28/2
+ function Element (Position : Cursor) return Element_Type;
+
+29/2
+ procedure Replace_Element (Container : in out Vector;
+ Index : in Index_Type;
+ New_Item : in Element_Type);
+
+30/2
+ procedure Replace_Element (Container : in out Vector;
+ Position : in Cursor;
+ New_item : in Element_Type);
+
+31/2
+ procedure Query_Element
+ (Container : in Vector;
+ Index : in Index_Type;
+ Process : not null access procedure (Element : in Element_Type));
+
+32/2
+ procedure Query_Element
+ (Position : in Cursor;
+ Process : not null access procedure (Element : in Element_Type));
+
+33/2
+ procedure Update_Element
+ (Container : in out Vector;
+ Index : in Index_Type;
+ Process : not null access procedure
+ (Element : in out Element_Type));
+
+34/2
+ procedure Update_Element
+ (Container : in out Vector;
+ Position : in Cursor;
+ Process : not null access procedure
+ (Element : in out Element_Type));
+
+34.1/3
+ {AI05-0212-1AI05-0212-1} type Constant_Reference_Type
+ (Element : not null access constant Element_Type) is private
+ with Implicit_Dereference => Element;
+
+34.2/3
+ {AI05-0212-1AI05-0212-1} type Reference_Type (Element : not null access Element_Type) is private
+ with Implicit_Dereference => Element;
+
+34.3/3
+ {AI05-0212-1AI05-0212-1} function Constant_Reference (Container : aliased in Vector;
+ Index : in Index_Type)
+ return Constant_Reference_Type;
+
+34.4/3
+ {AI05-0212-1AI05-0212-1} function Reference (Container : aliased in out Vector;
+ Index : in Index_Type)
+ return Reference_Type;
+
+34.5/3
+ {AI05-0212-1AI05-0212-1} function Constant_Reference (Container : aliased in Vector;
+ Position : in Cursor)
+ return Constant_Reference_Type;
+
+34.6/3
+ {AI05-0212-1AI05-0212-1} function Reference (Container : aliased in out Vector;
+ Position : in Cursor)
+ return Reference_Type;
+
+34.7/3
+ {AI05-0001-1AI05-0001-1} procedure Assign (Target : in out Vector; Source : in Vector);
+
+34.8/3
+ {AI05-0001-1AI05-0001-1} function Copy (Source : Vector; Capacity : Count_Type := 0)
+ return Vector;
+
+35/2
+ procedure Move (Target : in out Vector;
+ Source : in out Vector);
+
+36/2
+ procedure Insert (Container : in out Vector;
+ Before : in Extended_Index;
+ New_Item : in Vector);
+
+37/2
+ procedure Insert (Container : in out Vector;
+ Before : in Cursor;
+ New_Item : in Vector);
+
+38/2
+ procedure Insert (Container : in out Vector;
+ Before : in Cursor;
+ New_Item : in Vector;
+ Position : out Cursor);
+
+39/2
+ procedure Insert (Container : in out Vector;
+ Before : in Extended_Index;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+40/2
+ procedure Insert (Container : in out Vector;
+ Before : in Cursor;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+41/2
+ procedure Insert (Container : in out Vector;
+ Before : in Cursor;
+ New_Item : in Element_Type;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+42/2
+ procedure Insert (Container : in out Vector;
+ Before : in Extended_Index;
+ Count : in Count_Type := 1);
+
+43/2
+ procedure Insert (Container : in out Vector;
+ Before : in Cursor;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+44/2
+ procedure Prepend (Container : in out Vector;
+ New_Item : in Vector);
+
+45/2
+ procedure Prepend (Container : in out Vector;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+46/2
+ procedure Append (Container : in out Vector;
+ New_Item : in Vector);
+
+47/2
+ procedure Append (Container : in out Vector;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+48/2
+ procedure Insert_Space (Container : in out Vector;
+ Before : in Extended_Index;
+ Count : in Count_Type := 1);
+
+49/2
+ procedure Insert_Space (Container : in out Vector;
+ Before : in Cursor;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+50/2
+ procedure Delete (Container : in out Vector;
+ Index : in Extended_Index;
+ Count : in Count_Type := 1);
+
+51/2
+ procedure Delete (Container : in out Vector;
+ Position : in out Cursor;
+ Count : in Count_Type := 1);
+
+52/2
+ procedure Delete_First (Container : in out Vector;
+ Count : in Count_Type := 1);
+
+53/2
+ procedure Delete_Last (Container : in out Vector;
+ Count : in Count_Type := 1);
+
+54/2
+ procedure Reverse_Elements (Container : in out Vector);
+
+55/2
+ procedure Swap (Container : in out Vector;
+ I, J : in Index_Type);
+
+56/2
+ procedure Swap (Container : in out Vector;
+ I, J : in Cursor);
+
+57/2
+ function First_Index (Container : Vector) return Index_Type;
+
+58/2
+ function First (Container : Vector) return Cursor;
+
+59/2
+ function First_Element (Container : Vector)
+ return Element_Type;
+
+60/2
+ function Last_Index (Container : Vector) return Extended_Index;
+
+61/2
+ function Last (Container : Vector) return Cursor;
+
+62/2
+ function Last_Element (Container : Vector)
+ return Element_Type;
+
+63/2
+ function Next (Position : Cursor) return Cursor;
+
+64/2
+ procedure Next (Position : in out Cursor);
+
+65/2
+ function Previous (Position : Cursor) return Cursor;
+
+66/2
+ procedure Previous (Position : in out Cursor);
+
+67/2
+ function Find_Index (Container : Vector;
+ Item : Element_Type;
+ Index : Index_Type := Index_Type'First)
+ return Extended_Index;
+
+68/2
+ function Find (Container : Vector;
+ Item : Element_Type;
+ Position : Cursor := No_Element)
+ return Cursor;
+
+69/2
+ function Reverse_Find_Index (Container : Vector;
+ Item : Element_Type;
+ Index : Index_Type := Index_Type'Last)
+ return Extended_Index;
+
+70/2
+ function Reverse_Find (Container : Vector;
+ Item : Element_Type;
+ Position : Cursor := No_Element)
+ return Cursor;
+
+71/2
+ function Contains (Container : Vector;
+ Item : Element_Type) return Boolean;
+
+72/3
+ This paragraph was deleted.{AI05-0212-1AI05-0212-1}
+
+73/2
+ procedure Iterate
+ (Container : in Vector;
+ Process : not null access procedure (Position : in Cursor));
+
+74/2
+ procedure Reverse_Iterate
+ (Container : in Vector;
+ Process : not null access procedure (Position : in Cursor));
+
+74.1/3
+ {AI05-0212-1AI05-0212-1} function Iterate (Container : in Vector)
+ return Vector_Iterator_Interfaces.Reversible_Iterator'Class;
+
+74.2/3
+ {AI05-0212-1AI05-0212-1} function Iterate (Container : in Vector; Start : in Cursor)
+ return Vector_Iterator_Interfaces.Reversible_Iterator'Class;
+
+75/2
+ generic
+ with function "<" (Left, Right : Element_Type)
+ return Boolean is <>;
+ package Generic_Sorting is
+
+76/2
+ function Is_Sorted (Container : Vector) return Boolean;
+
+77/2
+ procedure Sort (Container : in out Vector);
+
+78/2
+ procedure Merge (Target : in out Vector;
+ Source : in out Vector);
+
+79/2
+ end Generic_Sorting;
+
+80/2
+ private
+
+81/2
+ ... -- not specified by the language
+
+82/2
+ end Ada.Containers.Vectors;
+
+83/2
+{AI95-00302-03AI95-00302-03} The actual function for the generic formal
+function "=" on Element_Type values is expected to define a reflexive
+and symmetric relationship and return the same result value each time it
+is called with a particular pair of values. If it behaves in some other
+manner, the functions defined to use it return an unspecified value.
+The exact arguments and number of calls of this generic formal function
+by the functions defined to use it are unspecified.
+
+83.a/2
+ Ramification: The "functions defined to use it" are Find,
+ Find_Index, Reverse_Find, Reverse_Find_Index, and "=" for
+ Vectors. This list is a bit too long to give explicitly.
+
+83.b/2
+ If the actual function for "=" is not symmetric and
+ consistent, the result returned by any of the functions
+ defined to use "=" cannot be predicted. The implementation is
+ not required to protect against "=" raising an exception, or
+ returning random results, or any other "bad" behavior. And it
+ can call "=" in whatever manner makes sense. But note that
+ only the results of the functions defined to use "=" are
+ unspecified; other subprograms are not allowed to break if "="
+ is bad.
+
+84/2
+{AI95-00302-03AI95-00302-03} The type Vector is used to represent
+vectors. The type Vector needs finalization (see *note 7.6::).
+
+85/2
+{AI95-00302-03AI95-00302-03} Empty_Vector represents the empty vector
+object. It has a length of 0. If an object of type Vector is not
+otherwise initialized, it is initialized to the same value as
+Empty_Vector.
+
+86/2
+{AI95-00302-03AI95-00302-03} No_Element represents a cursor that
+designates no element. If an object of type Cursor is not otherwise
+initialized, it is initialized to the same value as No_Element.
+
+87/2
+{AI95-00302-03AI95-00302-03} The predefined "=" operator for type Cursor
+returns True if both cursors are No_Element, or designate the same
+element in the same container.
+
+88/2
+{AI95-00302-03AI95-00302-03} Execution of the default implementation of
+the Input, Output, Read, or Write attribute of type Cursor raises
+Program_Error.
+
+88.a/2
+ Reason: A cursor will probably be implemented in terms of one
+ or more access values, and the effects of streaming access
+ values is unspecified. Rather than letting the user stream
+ junk by accident, we mandate that streaming of cursors raise
+ Program_Error by default. The attributes can always be
+ specified if there is a need to support streaming.
+
+88.1/3
+{AI05-0001-1AI05-0001-1} {AI05-0262-1AI05-0262-1} Vector'Write for a
+Vector object V writes Length(V) elements of the vector to the stream.
+It also may write additional information about the vector.
+
+88.2/3
+{AI05-0001-1AI05-0001-1} {AI05-0262-1AI05-0262-1} Vector'Read reads the
+representation of a vector from the stream, and assigns to Item a vector
+with the same length and elements as was written by Vector'Write.
+
+88.b/3
+ Implementation Note: The Standard requires streaming of all
+ language-defined nonlimited types (including containers) to
+ "work" (see *note 13.13.2::). In addition, we do not want all
+ of the elements that make up the capacity of the vector
+ streamed, as those beyond the length of the container have
+ undefined contents (and might cause bad things when read back
+ in). This will require a custom stream attribute
+ implementation; the language-defined default implementation
+ will not work (even for a bounded form, as that would most
+ likely stream the entire capacity of the vector). There is a
+ separate requirement that the unbounded and Bounded form use
+ the same streaming representation for the same element type,
+ see *note A.18.19::.
+
+89/2
+{AI95-00302-03AI95-00302-03} No_Index represents a position that does
+not correspond to any element. The subtype Extended_Index includes the
+indices covered by Index_Type plus the value No_Index and, if it exists,
+the successor to the Index_Type'Last.
+
+89.a/2
+ Discussion: We require the existence of Index_Type'First - 1,
+ so that No_Index and Last_Index of an empty vector is
+ well-defined. We don't require the existence of
+ Index_Type'Last + 1, as it is only used as the position of
+ insertions (and needs to be allowed only when inserting an
+ empty vector).
+
+89.1/3
+{AI05-0001-1AI05-0001-1} If an operation attempts to modify the vector
+such that the position of the last element would be greater than
+Index_Type'Last, then the operation propagates Constraint_Error.
+
+89.b/3
+ Reason: We don't want to require an implementation to go to
+ heroic efforts to handle index values larger than the base
+ type of the index subtype.
+
+90/2
+{AI95-00302-03AI95-00302-03} [Some operations of this generic package
+have access-to-subprogram parameters. To ensure such operations are
+well-defined, they guard against certain actions by the designated
+subprogram. In particular, some operations check for "tampering with
+cursors" of a container because they depend on the set of elements of
+the container remaining constant, and others check for "tampering with
+elements" of a container because they depend on elements of the
+container not being replaced.]
+
+91/2
+{AI95-00302-03AI95-00302-03} A subprogram is said to tamper with cursors
+of a vector object V if:
+
+92/2
+ * it inserts or deletes elements of V, that is, it calls the Insert,
+ Insert_Space, Clear, Delete, or Set_Length procedures with V as a
+ parameter; or
+
+92.a/2
+ To be honest: Operations which are defined to be equivalent to
+ a call on one of these operations also are included.
+ Similarly, operations which call one of these as part of their
+ definition are included.
+
+93/2
+ * it finalizes V; or
+
+93.1/3
+ * {AI05-0001-1AI05-0001-1} it calls the Assign procedure with V as
+ the Target parameter; or
+
+93.a.1/3
+ Ramification: We don't need to explicitly mention
+ assignment_statement, because that finalizes the target object
+ as part of the operation, and finalization of an object is
+ already defined as tampering with cursors.
+
+94/2
+ * it calls the Move procedure with V as a parameter.
+
+94.a/2
+ Discussion: Swap, Sort, and Merge copy elements rather than
+ reordering them, so they don't tamper with cursors.
+
+95/2
+{AI95-00302-03AI95-00302-03} A subprogram is said to tamper with
+elements of a vector object V if:
+
+96/2
+ * it tampers with cursors of V; or
+
+97/2
+ * it replaces one or more elements of V, that is, it calls the
+ Replace_Element, Reverse_Elements, or Swap procedures or the Sort
+ or Merge procedures of an instance of Generic_Sorting with V as a
+ parameter.
+
+97.a/2
+ Reason: Complete replacement of an element can cause its
+ memory to be deallocated while another operation is holding
+ onto a reference to it. That can't be allowed. However, a
+ simple modification of (part of) an element is not a problem,
+ so Update_Element does not cause a problem.
+
+97.1/3
+{AI05-0265-1AI05-0265-1} When tampering with cursors is prohibited for a
+particular vector object V, Program_Error is propagated by a call of any
+language-defined subprogram that is defined to tamper with the cursors
+of V, leaving V unmodified. Similarly, when tampering with elements is
+prohibited for a particular vector object V, Program_Error is propagated
+by a call of any language-defined subprogram that is defined to tamper
+with the elements of V [(or tamper with the cursors of V)], leaving V
+unmodified.
+
+97.b/3
+ Proof: Tampering with elements includes tampering with
+ cursors, so we mention it only from completeness in the second
+ sentence.
+
+97.2/3
+ function Has_Element (Position : Cursor) return Boolean;
+
+97.3/3
+ {AI05-0212-1AI05-0212-1} Returns True if Position designates
+ an element, and returns False otherwise.
+
+97.c/3
+ To be honest: {AI05-0005-1AI05-0005-1}
+ {AI05-0212-1AI05-0212-1} This function might not detect
+ cursors that designate deleted elements; such cursors are
+ invalid (see below) and the result of calling Has_Element with
+ an invalid cursor is unspecified (but not erroneous).
+
+98/2
+ function "=" (Left, Right : Vector) return Boolean;
+
+99/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If Left
+ and Right denote the same vector object, then the function
+ returns True. If Left and Right have different lengths, then
+ the function returns False. Otherwise, it compares each
+ element in Left to the corresponding element in Right using
+ the generic formal equality operator. If any such comparison
+ returns False, the function returns False; otherwise, it
+ returns True. Any exception raised during evaluation of
+ element equality is propagated.
+
+99.a/2
+ Implementation Note: This wording describes the canonical
+ semantics. However, the order and number of calls on the
+ formal equality function is unspecified for all of the
+ operations that use it in this package, so an implementation
+ can call it as many or as few times as it needs to get the
+ correct answer. Specifically, there is no requirement to call
+ the formal equality additional times once the answer has been
+ determined.
+
+100/2
+ function To_Vector (Length : Count_Type) return Vector;
+
+101/2
+ {AI95-00302-03AI95-00302-03} Returns a vector with a length of
+ Length, filled with empty elements.
+
+102/2
+ function To_Vector
+ (New_Item : Element_Type;
+ Length : Count_Type) return Vector;
+
+103/2
+ {AI95-00302-03AI95-00302-03} Returns a vector with a length of
+ Length, filled with elements initialized to the value
+ New_Item.
+
+104/2
+ function "&" (Left, Right : Vector) return Vector;
+
+105/2
+ {AI95-00302-03AI95-00302-03} Returns a vector comprising the
+ elements of Left followed by the elements of Right.
+
+106/2
+ function "&" (Left : Vector;
+ Right : Element_Type) return Vector;
+
+107/2
+ {AI95-00302-03AI95-00302-03} Returns a vector comprising the
+ elements of Left followed by the element Right.
+
+108/2
+ function "&" (Left : Element_Type;
+ Right : Vector) return Vector;
+
+109/2
+ {AI95-00302-03AI95-00302-03} Returns a vector comprising the
+ element Left followed by the elements of Right.
+
+110/2
+ function "&" (Left, Right : Element_Type) return Vector;
+
+111/2
+ {AI95-00302-03AI95-00302-03} Returns a vector comprising the
+ element Left followed by the element Right.
+
+112/2
+ function Capacity (Container : Vector) return Count_Type;
+
+113/2
+ {AI95-00302-03AI95-00302-03} Returns the capacity of
+ Container.
+
+114/2
+ procedure Reserve_Capacity (Container : in out Vector;
+ Capacity : in Count_Type);
+
+115/3
+ {AI95-00302-03AI95-00302-03} {AI05-0001-1AI05-0001-1}
+ {AI05-0264-1AI05-0264-1} If the capacity of Container is
+ already greater than or equal to Capacity, then
+ Reserve_Capacity has no effect. Otherwise, Reserve_Capacity
+ allocates additional storage as necessary to ensure that the
+ length of the resulting vector can become at least the value
+ Capacity without requiring an additional call to
+ Reserve_Capacity, and is large enough to hold the current
+ length of Container. Reserve_Capacity then, as necessary,
+ moves elements into the new storage and deallocates any
+ storage no longer needed. Any exception raised during
+ allocation is propagated and Container is not modified.
+
+115.a/2
+ Discussion: Expanding the internal array can be done by
+ allocating a new, longer array, copying the elements, and
+ deallocating the original array. This may raise
+ Storage_Error, or cause an exception from a controlled
+ subprogram. We require that a failed Reserve_Capacity does
+ not lose any elements if an exception occurs, but we do not
+ require a specific order of evaluations or copying.
+
+115.b/2
+ This routine is used to preallocate the internal array to the
+ specified capacity such that future Inserts do not require
+ memory allocation overhead. Therefore, the implementation
+ should allocate the needed memory to make that true at this
+ point, even though the visible semantics could be preserved by
+ waiting until the memory is needed. This doesn't apply to the
+ indefinite element container, because elements will have to be
+ allocated individually.
+
+115.c/2
+ The implementation does not have to contract the internal
+ array if the capacity is reduced, as any capacity greater than
+ or equal to the specified capacity is allowed.
+
+116/2
+ function Length (Container : Vector) return Count_Type;
+
+117/2
+ {AI95-00302-03AI95-00302-03} Returns the number of elements in
+ Container.
+
+118/2
+ procedure Set_Length (Container : in out Vector;
+ Length : in Count_Type);
+
+119/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Length is larger than the capacity of Container, Set_Length
+ calls Reserve_Capacity (Container, Length), then sets the
+ length of the Container to Length. If Length is greater than
+ the original length of Container, empty elements are added to
+ Container; otherwise, elements are removed from Container.
+
+119.a/2
+ Ramification: No elements are moved by this operation; any new
+ empty elements are added at the end. This follows from the
+ rules that a cursor continues to designate the same element
+ unless the routine is defined to make the cursor ambiguous or
+ invalid; this operation does not do that.
+
+120/2
+ function Is_Empty (Container : Vector) return Boolean;
+
+121/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Length (Container)
+ = 0.
+
+122/2
+ procedure Clear (Container : in out Vector);
+
+123/2
+ {AI95-00302-03AI95-00302-03} Removes all the elements from
+ Container. The capacity of Container does not change.
+
+124/2
+ function To_Cursor (Container : Vector;
+ Index : Extended_Index) return Cursor;
+
+125/2
+ {AI95-00302-03AI95-00302-03} If Index is not in the range
+ First_Index (Container) .. Last_Index (Container), then
+ No_Element is returned. Otherwise, a cursor designating the
+ element at position Index in Container is returned.
+
+126/2
+ function To_Index (Position : Cursor) return Extended_Index;
+
+127/2
+ {AI95-00302-03AI95-00302-03} If Position is No_Element,
+ No_Index is returned. Otherwise, the index (within its
+ containing vector) of the element designated by Position is
+ returned.
+
+127.a/2
+ Ramification: This implies that the index is determinable from
+ a bare cursor alone. The basic model is that a vector cursor
+ is implemented as a record containing an access to the vector
+ container and an index value. This does constrain
+ implementations, but it also allows all of the cursor
+ operations to be defined in terms of the corresponding index
+ operation (which should be primary for a vector).
+
+128/2
+ function Element (Container : Vector;
+ Index : Index_Type)
+ return Element_Type;
+
+129/2
+ {AI95-00302-03AI95-00302-03} If Index is not in the range
+ First_Index (Container) .. Last_Index (Container), then
+ Constraint_Error is propagated. Otherwise, Element returns
+ the element at position Index.
+
+130/2
+ function Element (Position : Cursor) return Element_Type;
+
+131/2
+ {AI95-00302-03AI95-00302-03} If Position equals No_Element,
+ then Constraint_Error is propagated. Otherwise, Element
+ returns the element designated by Position.
+
+132/2
+ procedure Replace_Element (Container : in out Vector;
+ Index : in Index_Type;
+ New_Item : in Element_Type);
+
+133/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If Index
+ is not in the range First_Index (Container) .. Last_Index
+ (Container), then Constraint_Error is propagated. Otherwise,
+ Replace_Element assigns the value New_Item to the element at
+ position Index. Any exception raised during the assignment is
+ propagated. The element at position Index is not an empty
+ element after successful call to Replace_Element.
+
+134/2
+ procedure Replace_Element (Container : in out Vector;
+ Position : in Cursor;
+ New_Item : in Element_Type);
+
+135/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Position equals No_Element, then Constraint_Error is
+ propagated; if Position does not designate an element in
+ Container, then Program_Error is propagated. Otherwise,
+ Replace_Element assigns New_Item to the element designated by
+ Position. Any exception raised during the assignment is
+ propagated. The element at Position is not an empty element
+ after successful call to Replace_Element.
+
+135.a/3
+ Ramification: {AI05-0212-1AI05-0212-1} Replace_Element,
+ Update_Element, and Reference are the only ways that an
+ element can change from empty to nonempty. Also see the note
+ following Update_Element.
+
+136/2
+ procedure Query_Element
+ (Container : in Vector;
+ Index : in Index_Type;
+ Process : not null access procedure (Element : in Element_Type));
+
+137/3
+ {AI95-00302-03AI95-00302-03} {AI05-0265-1AI05-0265-1} If Index
+ is not in the range First_Index (Container) .. Last_Index
+ (Container), then Constraint_Error is propagated. Otherwise,
+ Query_Element calls Process.all with the element at position
+ Index as the argument. Tampering with the elements of
+ Container is prohibited during the execution of the call on
+ Process.all. Any exception raised by Process.all is
+ propagated.
+
+137.a/2
+ Reason: {AI05-0005-1AI05-0005-1} The "tamper with the
+ elements" check is intended to prevent the Element parameter
+ of Process from being replaced or deleted outside of Process.
+ The check prevents data loss (if Element_Type is passed by
+ copy) or erroneous execution (if Element_Type is an
+ unconstrained type in an indefinite container).
+
+138/2
+ procedure Query_Element
+ (Position : in Cursor;
+ Process : not null access procedure (Element : in Element_Type));
+
+139/3
+ {AI95-00302-03AI95-00302-03} {AI05-0021-1AI05-0021-1}
+ {AI05-0265-1AI05-0265-1} If Position equals No_Element, then
+ Constraint_Error is propagated. Otherwise, Query_Element
+ calls Process.all with the element designated by Position as
+ the argument. Tampering with the elements of the vector that
+ contains the element designated by Position is prohibited
+ during the execution of the call on Process.all. Any
+ exception raised by Process.all is propagated.
+
+140/2
+ procedure Update_Element
+ (Container : in out Vector;
+ Index : in Index_Type;
+ Process : not null access procedure (Element : in out Element_Type));
+
+141/3
+ {AI95-00302-03AI95-00302-03} {AI05-0265-1AI05-0265-1} If Index
+ is not in the range First_Index (Container) .. Last_Index
+ (Container), then Constraint_Error is propagated. Otherwise,
+ Update_Element calls Process.all with the element at position
+ Index as the argument. Tampering with the elements of
+ Container is prohibited during the execution of the call on
+ Process.all. Any exception raised by Process.all is
+ propagated.
+
+142/2
+ If Element_Type is unconstrained and definite, then the actual
+ Element parameter of Process.all shall be unconstrained.
+
+142.a/2
+ Ramification: This means that the elements cannot be directly
+ allocated from the heap; it must be possible to change the
+ discriminants of the element in place.
+
+143/2
+ The element at position Index is not an empty element after
+ successful completion of this operation.
+
+143.a/2
+ Ramification: Since reading an empty element is a bounded
+ error, attempting to use this procedure to replace empty
+ elements may fail. Use Replace_Element to do that reliably.
+
+144/2
+ procedure Update_Element
+ (Container : in out Vector;
+ Position : in Cursor;
+ Process : not null access procedure (Element : in out Element_Type));
+
+145/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1}
+ {AI05-0265-1AI05-0265-1} If Position equals No_Element, then
+ Constraint_Error is propagated; if Position does not designate
+ an element in Container, then Program_Error is propagated.
+ Otherwise, Update_Element calls Process.all with the element
+ designated by Position as the argument. Tampering with the
+ elements of Container is prohibited during the execution of
+ the call on Process.all. Any exception raised by Process.all
+ is propagated.
+
+146/2
+ If Element_Type is unconstrained and definite, then the actual
+ Element parameter of Process.all shall be unconstrained.
+
+147/2
+ The element designated by Position is not an empty element
+ after successful completion of this operation.
+
+147.1/3
+ type Constant_Reference_Type
+ (Element : not null access constant Element_Type) is private
+ with Implicit_Dereference => Element;
+
+147.2/3
+ type Reference_Type (Element : not null access Element_Type) is private
+ with Implicit_Dereference => Element;
+
+147.3/3
+ {AI05-0212-1AI05-0212-1} The types Constant_Reference_Type and
+ Reference_Type need finalization.
+
+147.4/3
+ The default initialization of an object of type
+ Constant_Reference_Type or Reference_Type propagates
+ Program_Error.
+
+147.a/3
+ Reason: It is expected that Reference_Type (and
+ Constant_Reference_Type) will be a controlled type, for which
+ finalization will have some action to terminate the tampering
+ check for the associated container. If the object is created
+ by default, however, there is no associated container. Since
+ this is useless, and supporting this case would take extra
+ work, we define it to raise an exception.
+
+147.5/3
+ function Constant_Reference (Container : aliased in Vector;
+ Index : in Index_Type)
+ return Constant_Reference_Type;
+
+147.6/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Constant_Indexing and
+ Implicit_Dereference aspects) provides a convenient way to
+ gain read access to an individual element of a vector given an
+ index value.
+
+147.7/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1} If Index is
+ not in the range First_Index (Container) .. Last_Index
+ (Container), then Constraint_Error is propagated. Otherwise,
+ Constant_Reference returns an object whose discriminant is an
+ access value that designates the element at position Index.
+ Tampering with the elements of Container is prohibited while
+ the object returned by Constant_Reference exists and has not
+ been finalized.
+
+147.8/3
+ function Reference (Container : aliased in out Vector;
+ Index : in Index_Type)
+ return Reference_Type;
+
+147.9/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Variable_Indexing and
+ Implicit_Dereference aspects) provides a convenient way to
+ gain read and write access to an individual element of a
+ vector given an index value.
+
+147.10/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1} If Index is
+ not in the range First_Index (Container) .. Last_Index
+ (Container), then Constraint_Error is propagated. Otherwise,
+ Reference returns an object whose discriminant is an access
+ value that designates the element at position Index.
+ Tampering with the elements of Container is prohibited while
+ the object returned by Reference exists and has not been
+ finalized.
+
+147.11/3
+ The element at position Index is not an empty element after
+ successful completion of this operation.
+
+147.12/3
+ function Constant_Reference (Container : aliased in Vector;
+ Position : in Cursor)
+ return Constant_Reference_Type;
+
+147.13/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Constant_Indexing and
+ Implicit_Dereference aspects) provides a convenient way to
+ gain read access to an individual element of a vector given a
+ cursor.
+
+147.14/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1} If Position
+ equals No_Element, then Constraint_Error is propagated; if
+ Position does not designate an element in Container, then
+ Program_Error is propagated. Otherwise, Constant_Reference
+ returns an object whose discriminant is an access value that
+ designates the element designated by Position. Tampering with
+ the elements of Container is prohibited while the object
+ returned by Constant_Reference exists and has not been
+ finalized.
+
+147.15/3
+ function Reference (Container : aliased in out Vector;
+ Position : in Cursor)
+ return Reference_Type;
+
+147.16/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Variable_Indexing and
+ Implicit_Dereference aspects) provides a convenient way to
+ gain read and write access to an individual element of a
+ vector given a cursor.
+
+147.17/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1} If Position
+ equals No_Element, then Constraint_Error is propagated; if
+ Position does not designate an element in Container, then
+ Program_Error is propagated. Otherwise, Reference returns an
+ object whose discriminant is an access value that designates
+ the element designated by Position. Tampering with the
+ elements of Container is prohibited while the object returned
+ by Reference exists and has not been finalized.
+
+147.18/3
+ The element designated by Position is not an empty element
+ after successful completion of this operation.
+
+147.19/3
+ procedure Assign (Target : in out Vector; Source : in Vector);
+
+147.20/3
+ {AI05-0001-1AI05-0001-1} {AI05-0248-1AI05-0248-1}
+ {AI05-0262-1AI05-0262-1} If Target denotes the same object as
+ Source, the operation has no effect. If the length of Source
+ is greater than the capacity of Target, Reserve_Capacity
+ (Target, Length (Source)) is called. The elements of Source
+ are then copied to Target as for an assignment_statement
+ assigning Source to Target (this includes setting the length
+ of Target to be that of Source).
+
+147.b/3
+ Discussion: {AI05-0005-1AI05-0005-1} This routine exists for
+ compatibility with the bounded vector container. For an
+ unbounded vector, Assign(A, B) and A := B behave identically.
+ For a bounded vector, := will raise an exception if the
+ container capacities are different, while Assign will not
+ raise an exception if there is enough room in the target.
+
+147.21/3
+ function Copy (Source : Vector; Capacity : Count_Type := 0)
+ return Vector;
+
+147.22/3
+ {AI05-0001-1AI05-0001-1} Returns a vector whose elements are
+ initialized from the corresponding elements of Source. If
+ Capacity is 0, then the vector capacity is the length of
+ Source; if Capacity is equal to or greater than the length of
+ Source, the vector capacity is at least the specified value.
+ Otherwise, the operation propagates Capacity_Error.
+
+148/2
+ procedure Move (Target : in out Vector;
+ Source : in out Vector);
+
+149/3
+ {AI95-00302-03AI95-00302-03} {AI05-0001-1AI05-0001-1}
+ {AI05-0248-1AI05-0248-1} If Target denotes the same object as
+ Source, then the operation has no effect. Otherwise, Move
+ first calls Reserve_Capacity (Target, Length (Source)) and
+ then Clear (Target); then, each element from Source is removed
+ from Source and inserted into Target in the original order.
+ The length of Source is 0 after a successful call to Move.
+
+149.a/2
+ Discussion: The idea is that the internal array is removed
+ from Source and moved to Target. (See the Implementation
+ Advice for Move). If Capacity (Target) /= 0, the previous
+ internal array may need to be deallocated. We don't mention
+ this explicitly, because it is covered by the "no memory loss"
+ Implementation Requirement.
+
+150/2
+ procedure Insert (Container : in out Vector;
+ Before : in Extended_Index;
+ New_Item : in Vector);
+
+151/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Before is not in the range First_Index (Container) ..
+ Last_Index (Container) + 1, then Constraint_Error is
+ propagated. If Length(New_Item) is 0, then Insert does
+ nothing. Otherwise, it computes the new length NL as the sum
+ of the current length and Length (New_Item); if the value of
+ Last appropriate for length NL would be greater than
+ Index_Type'Last, then Constraint_Error is propagated.
+
+152/2
+ If the current vector capacity is less than NL,
+ Reserve_Capacity (Container, NL) is called to increase the
+ vector capacity. Then Insert slides the elements in the range
+ Before .. Last_Index (Container) up by Length(New_Item)
+ positions, and then copies the elements of New_Item to the
+ positions starting at Before. Any exception raised during the
+ copying is propagated.
+
+152.a/2
+ Ramification: Moving the elements does not necessarily involve
+ copying. Similarly, since Reserve_Capacity does not require
+ the copying of elements, it does not need to be explicitly
+ called (the implementation can combine the operations if it
+ wishes to).
+
+153/2
+ procedure Insert (Container : in out Vector;
+ Before : in Cursor;
+ New_Item : in Vector);
+
+154/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Before is not No_Element, and does not designate an element in
+ Container, then Program_Error is propagated. Otherwise, if
+ Length(New_Item) is 0, then Insert does nothing. If Before is
+ No_Element, then the call is equivalent to Insert (Container,
+ Last_Index (Container) + 1, New_Item); otherwise, the call is
+ equivalent to Insert (Container, To_Index (Before), New_Item);
+
+154.a/2
+ Ramification: The check on Before checks that the cursor does
+ not belong to some other Container. This check implies that a
+ reference to the container is included in the cursor value.
+ This wording is not meant to require detection of dangling
+ cursors; such cursors are defined to be invalid, which means
+ that execution is erroneous, and any result is allowed
+ (including not raising an exception).
+
+155/2
+ procedure Insert (Container : in out Vector;
+ Before : in Cursor;
+ New_Item : in Vector;
+ Position : out Cursor);
+
+156/2
+ {AI95-00302-03AI95-00302-03} If Before is not No_Element, and
+ does not designate an element in Container, then Program_Error
+ is propagated. If Before equals No_Element, then let T be
+ Last_Index (Container) + 1; otherwise, let T be To_Index
+ (Before). Insert (Container, T, New_Item) is called, and then
+ Position is set to To_Cursor (Container, T).
+
+156.a/2
+ Discussion: The messy wording is needed because Before is
+ invalidated by Insert, and we don't want Position to be
+ invalid after this call. An implementation probably only
+ needs to copy Before to Position.
+
+157/2
+ procedure Insert (Container : in out Vector;
+ Before : in Extended_Index;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+158/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Insert (Container,
+ Before, To_Vector (New_Item, Count));
+
+159/2
+ procedure Insert (Container : in out Vector;
+ Before : in Cursor;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+160/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Insert (Container,
+ Before, To_Vector (New_Item, Count));
+
+161/2
+ procedure Insert (Container : in out Vector;
+ Before : in Cursor;
+ New_Item : in Element_Type;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+162/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Insert (Container,
+ Before, To_Vector (New_Item, Count), Position);
+
+162.a/3
+ Ramification: {AI05-0257-1AI05-0257-1} If Count equals 0,
+ Position will designate the element designated by Before,
+ rather than a newly inserted element. Otherwise, Position
+ will designate the first newly inserted element.
+
+163/2
+ procedure Insert (Container : in out Vector;
+ Before : in Extended_Index;
+ Count : in Count_Type := 1);
+
+164/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Before is not in the range First_Index (Container) ..
+ Last_Index (Container) + 1, then Constraint_Error is
+ propagated. If Count is 0, then Insert does nothing.
+ Otherwise, it computes the new length NL as the sum of the
+ current length and Count; if the value of Last appropriate for
+ length NL would be greater than Index_Type'Last, then
+ Constraint_Error is propagated.
+
+165/2
+ If the current vector capacity is less than NL,
+ Reserve_Capacity (Container, NL) is called to increase the
+ vector capacity. Then Insert slides the elements in the range
+ Before .. Last_Index (Container) up by Count positions, and
+ then inserts elements that are initialized by default (see
+ *note 3.3.1::) in the positions starting at Before.
+
+166/2
+ procedure Insert (Container : in out Vector;
+ Before : in Cursor;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+167/2
+ {AI95-00302-03AI95-00302-03} If Before is not No_Element, and
+ does not designate an element in Container, then Program_Error
+ is propagated. If Before equals No_Element, then let T be
+ Last_Index (Container) + 1; otherwise, let T be To_Index
+ (Before). Insert (Container, T, Count) is called, and then
+ Position is set to To_Cursor (Container, T).
+
+167.a/2
+ Reason: This routine exists mainly to ease conversion between
+ Vector and List containers. Unlike Insert_Space, this routine
+ default initializes the elements it inserts, which can be more
+ expensive for some element types.
+
+168/2
+ procedure Prepend (Container : in out Vector;
+ New_Item : in Vector;
+ Count : in Count_Type := 1);
+
+169/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Insert (Container,
+ First_Index (Container), New_Item).
+
+170/2
+ procedure Prepend (Container : in out Vector;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+171/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Insert (Container,
+ First_Index (Container), New_Item, Count).
+
+172/2
+ procedure Append (Container : in out Vector;
+ New_Item : in Vector);
+
+173/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Insert (Container,
+ Last_Index (Container) + 1, New_Item).
+
+174/2
+ procedure Append (Container : in out Vector;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+175/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Insert (Container,
+ Last_Index (Container) + 1, New_Item, Count).
+
+176/2
+ procedure Insert_Space (Container : in out Vector;
+ Before : in Extended_Index;
+ Count : in Count_Type := 1);
+
+177/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Before is not in the range First_Index (Container) ..
+ Last_Index (Container) + 1, then Constraint_Error is
+ propagated. If Count is 0, then Insert_Space does nothing.
+ Otherwise, it computes the new length NL as the sum of the
+ current length and Count; if the value of Last appropriate for
+ length NL would be greater than Index_Type'Last, then
+ Constraint_Error is propagated.
+
+178/2
+ If the current vector capacity is less than NL,
+ Reserve_Capacity (Container, NL) is called to increase the
+ vector capacity. Then Insert_Space slides the elements in the
+ range Before .. Last_Index (Container) up by Count positions,
+ and then inserts empty elements in the positions starting at
+ Before.
+
+179/2
+ procedure Insert_Space (Container : in out Vector;
+ Before : in Cursor;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+180/2
+ {AI95-00302-03AI95-00302-03} If Before is not No_Element, and
+ does not designate an element in Container, then Program_Error
+ is propagated. If Before equals No_Element, then let T be
+ Last_Index (Container) + 1; otherwise, let T be To_Index
+ (Before). Insert_Space (Container, T, Count) is called, and
+ then Position is set to To_Cursor (Container, T).
+
+181/2
+ procedure Delete (Container : in out Vector;
+ Index : in Extended_Index;
+ Count : in Count_Type := 1);
+
+182/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If Index
+ is not in the range First_Index (Container) .. Last_Index
+ (Container) + 1, then Constraint_Error is propagated. If
+ Count is 0, Delete has no effect. Otherwise, Delete slides
+ the elements (if any) starting at position Index + Count down
+ to Index. Any exception raised during element assignment is
+ propagated.
+
+182.a/2
+ Ramification: If Index + Count >= Last_Index(Container), this
+ effectively truncates the vector (setting Last_Index to Index
+ - 1 and consequently sets Length to Index - Index_Type'First).
+
+183/2
+ procedure Delete (Container : in out Vector;
+ Position : in out Cursor;
+ Count : in Count_Type := 1);
+
+184/2
+ {AI95-00302-03AI95-00302-03} If Position equals No_Element,
+ then Constraint_Error is propagated. If Position does not
+ designate an element in Container, then Program_Error is
+ propagated. Otherwise, Delete (Container, To_Index
+ (Position), Count) is called, and then Position is set to
+ No_Element.
+
+185/2
+ procedure Delete_First (Container : in out Vector;
+ Count : in Count_Type := 1);
+
+186/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Delete (Container,
+ First_Index (Container), Count).
+
+187/2
+ procedure Delete_Last (Container : in out Vector;
+ Count : in Count_Type := 1);
+
+188/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Length (Container) <= Count, then Delete_Last is equivalent to
+ Clear (Container). Otherwise, it is equivalent to Delete
+ (Container, Index_Type'Val(Index_Type'Pos(Last_Index
+ (Container)) - Count + 1), Count).
+
+189/2
+ {AI05-0092-1AI05-0092-1} procedure Reverse_Elements (Container : in out Vector);
+
+190/2
+ {AI95-00302-03AI95-00302-03} Reorders the elements of
+ Container in reverse order.
+
+190.a/2
+ Discussion: This can copy the elements of the vector -- all
+ cursors referencing the vector are ambiguous afterwards and
+ may designate different elements afterwards.
+
+191/2
+ procedure Swap (Container : in out Vector;
+ I, J : in Index_Type);
+
+192/2
+ {AI95-00302-03AI95-00302-03} If either I or J is not in the
+ range First_Index (Container) .. Last_Index (Container), then
+ Constraint_Error is propagated. Otherwise, Swap exchanges the
+ values of the elements at positions I and J.
+
+192.a/2
+ To be honest: The implementation is not required to actually
+ copy the elements if it can do the swap some other way. But
+ it is allowed to copy the elements if needed.
+
+193/2
+ procedure Swap (Container : in out Vector;
+ I, J : in Cursor);
+
+194/2
+ {AI95-00302-03AI95-00302-03} If either I or J is No_Element,
+ then Constraint_Error is propagated. If either I or J do not
+ designate an element in Container, then Program_Error is
+ propagated. Otherwise, Swap exchanges the values of the
+ elements designated by I and J.
+
+194.a/2
+ Ramification: After a call to Swap, I designates the element
+ value previously designated by J, and J designates the element
+ value previously designated by I. The cursors do not become
+ ambiguous from this operation.
+
+194.b/2
+ To be honest: The implementation is not required to actually
+ copy the elements if it can do the swap some other way. But
+ it is allowed to copy the elements if needed.
+
+195/2
+ function First_Index (Container : Vector) return Index_Type;
+
+196/2
+ {AI95-00302-03AI95-00302-03} Returns the value
+ Index_Type'First.
+
+196.a/2
+ Discussion: We'd rather call this "First", but then calling
+ most routines in here with First (Some_Vect) would be
+ ambiguous.
+
+197/2
+ function First (Container : Vector) return Cursor;
+
+198/2
+ {AI95-00302-03AI95-00302-03} If Container is empty, First
+ returns No_Element. Otherwise, it returns a cursor that
+ designates the first element in Container.
+
+199/2
+ function First_Element (Container : Vector) return Element_Type;
+
+200/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Element (Container,
+ First_Index (Container)).
+
+201/2
+ function Last_Index (Container : Vector) return Extended_Index;
+
+202/2
+ {AI95-00302-03AI95-00302-03} If Container is empty, Last_Index
+ returns No_Index. Otherwise, it returns the position of the
+ last element in Container.
+
+203/2
+ function Last (Container : Vector) return Cursor;
+
+204/2
+ {AI95-00302-03AI95-00302-03} If Container is empty, Last
+ returns No_Element. Otherwise, it returns a cursor that
+ designates the last element in Container.
+
+205/2
+ function Last_Element (Container : Vector) return Element_Type;
+
+206/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Element (Container,
+ Last_Index (Container)).
+
+207/2
+ function Next (Position : Cursor) return Cursor;
+
+208/2
+ {AI95-00302-03AI95-00302-03} If Position equals No_Element or
+ designates the last element of the container, then Next
+ returns the value No_Element. Otherwise, it returns a cursor
+ that designates the element with index To_Index (Position) + 1
+ in the same vector as Position.
+
+209/2
+ procedure Next (Position : in out Cursor);
+
+210/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Position := Next
+ (Position).
+
+211/2
+ function Previous (Position : Cursor) return Cursor;
+
+212/2
+ {AI95-00302-03AI95-00302-03} If Position equals No_Element or
+ designates the first element of the container, then Previous
+ returns the value No_Element. Otherwise, it returns a cursor
+ that designates the element with index To_Index (Position) - 1
+ in the same vector as Position.
+
+213/2
+ procedure Previous (Position : in out Cursor);
+
+214/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Position :=
+ Previous (Position).
+
+215/2
+ function Find_Index (Container : Vector;
+ Item : Element_Type;
+ Index : Index_Type := Index_Type'First)
+ return Extended_Index;
+
+216/2
+ {AI95-00302-03AI95-00302-03} Searches the elements of
+ Container for an element equal to Item (using the generic
+ formal equality operator). The search starts at position
+ Index and proceeds towards Last_Index (Container). If no
+ equal element is found, then Find_Index returns No_Index.
+ Otherwise, it returns the index of the first equal element
+ encountered.
+
+217/2
+ function Find (Container : Vector;
+ Item : Element_Type;
+ Position : Cursor := No_Element)
+ return Cursor;
+
+218/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Position is not No_Element, and does not designate an element
+ in Container, then Program_Error is propagated. Otherwise,
+ Find searches the elements of Container for an element equal
+ to Item (using the generic formal equality operator). The
+ search starts at the first element if Position equals
+ No_Element, and at the element designated by Position
+ otherwise. It proceeds towards the last element of Container.
+ If no equal element is found, then Find returns No_Element.
+ Otherwise, it returns a cursor designating the first equal
+ element encountered.
+
+219/2
+ function Reverse_Find_Index (Container : Vector;
+ Item : Element_Type;
+ Index : Index_Type := Index_Type'Last)
+ return Extended_Index;
+
+220/2
+ {AI95-00302-03AI95-00302-03} Searches the elements of
+ Container for an element equal to Item (using the generic
+ formal equality operator). The search starts at position
+ Index or, if Index is greater than Last_Index (Container), at
+ position Last_Index (Container). It proceeds towards
+ First_Index (Container). If no equal element is found, then
+ Reverse_Find_Index returns No_Index. Otherwise, it returns
+ the index of the first equal element encountered.
+
+221/2
+ function Reverse_Find (Container : Vector;
+ Item : Element_Type;
+ Position : Cursor := No_Element)
+ return Cursor;
+
+222/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Position is not No_Element, and does not designate an element
+ in Container, then Program_Error is propagated. Otherwise,
+ Reverse_Find searches the elements of Container for an element
+ equal to Item (using the generic formal equality operator).
+ The search starts at the last element if Position equals
+ No_Element, and at the element designated by Position
+ otherwise. It proceeds towards the first element of
+ Container. If no equal element is found, then Reverse_Find
+ returns No_Element. Otherwise, it returns a cursor
+ designating the first equal element encountered.
+
+223/2
+ function Contains (Container : Vector;
+ Item : Element_Type) return Boolean;
+
+224/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Has_Element (Find
+ (Container, Item)).
+
+ Paragraphs 225 and 226 were moved above.
+
+227/2
+ procedure Iterate
+ (Container : in Vector;
+ Process : not null access procedure (Position : in Cursor));
+
+228/3
+ {AI95-00302-03AI95-00302-03} {AI05-0265-1AI05-0265-1} Invokes
+ Process.all with a cursor that designates each element in
+ Container, in index order. Tampering with the cursors of
+ Container is prohibited during the execution of a call on
+ Process.all. Any exception raised by Process.all is
+ propagated.
+
+228.a/2
+ Discussion: The purpose of the "tamper with the cursors" check
+ is to prevent erroneous execution from the Position parameter
+ of Process.all becoming invalid. This check takes place when
+ the operations that tamper with the cursors of the container
+ are called. The check cannot be made later (say in the body
+ of Iterate), because that could cause the Position cursor to
+ be invalid and potentially cause execution to become erroneous
+ -- defeating the purpose of the check.
+
+228.b/2
+ There is no check needed if an attempt is made to insert or
+ delete nothing (that is, Count = 0 or Length(Item) = 0).
+
+228.c/2
+ The check is easy to implement: each container needs a
+ counter. The counter is incremented when Iterate is called,
+ and decremented when Iterate completes. If the counter is
+ nonzero when an operation that inserts or deletes is called,
+ Finalize is called, or one of the other operations in the list
+ occurs, Program_Error is raised.
+
+229/2
+ procedure Reverse_Iterate
+ (Container : in Vector;
+ Process : not null access procedure (Position : in Cursor));
+
+230/3
+ {AI95-00302-03AI95-00302-03} {AI05-0212-1AI05-0212-1} Iterates
+ over the elements in Container as per procedure Iterate,
+ except that elements are traversed in reverse index order.
+
+230.1/3
+ function Iterate (Container : in Vector)
+ return Vector_Iterator_Interfaces.Reversible_Iterator'Class;
+
+230.2/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1}
+ {AI05-0269-1AI05-0269-1} Iterate returns a reversible iterator
+ object (see *note 5.5.1::) that will generate a value for a
+ loop parameter (see *note 5.5.2::) designating each node in
+ Container, starting with the first node and moving the cursor
+ as per the Next function when used as a forward iterator, and
+ starting with the last node and moving the cursor as per the
+ Previous function when used as a reverse iterator. Tampering
+ with the cursors of Container is prohibited while the iterator
+ object exists (in particular, in the sequence_of_statements of
+ the loop_statement whose iterator_specification denotes this
+ object). The iterator object needs finalization.
+
+230.3/3
+ function Iterate (Container : in Vector; Start : in Cursor)
+ return Vector_Iterator_Interfaces.Reversible_Iterator'Class;
+
+230.4/3
+ {AI05-0212-1AI05-0212-1} {AI05-0262-1AI05-0262-1}
+ {AI05-0265-1AI05-0265-1} {AI05-0269-1AI05-0269-1} If Start is
+ not No_Element and does not designate an item in Container,
+ then Program_Error is propagated. If Start is No_Element,
+ then Constraint_Error is propagated. Otherwise, Iterate
+ returns a reversible iterator object (see *note 5.5.1::) that
+ will generate a value for a loop parameter (see *note 5.5.2::)
+ designating each node in Container, starting with the node
+ designated by Start and moving the cursor as per the Next
+ function when used as a forward iterator, or moving the cursor
+ as per the Previous function when used as a reverse iterator.
+ Tampering with the cursors of Container is prohibited while
+ the iterator object exists (in particular, in the
+ sequence_of_statements of the loop_statement whose
+ iterator_specification denotes this object). The iterator
+ object needs finalization.
+
+230.a/3
+ Discussion: Exits are allowed from the loops created using the
+ iterator objects. In particular, to stop the iteration at a
+ particular cursor, just add
+
+230.b/3
+ exit when Cur = Stop;
+
+230.c/3
+ in the body of the loop (assuming that Cur is the loop
+ parameter and Stop is the cursor that you want to stop at).
+
+231/3
+{AI05-0044-1AI05-0044-1} {AI05-0262-1AI05-0262-1} The actual function
+for the generic formal function "<" of Generic_Sorting is expected to
+return the same value each time it is called with a particular pair of
+element values. It should define a strict weak ordering relationship
+(see *note A.18::); it should not modify Container. If the actual for
+"<" behaves in some other manner, the behavior of the subprograms of
+Generic_Sorting are unspecified. The number of times the subprograms of
+Generic_Sorting call "<" is unspecified.
+
+232/2
+ function Is_Sorted (Container : Vector) return Boolean;
+
+233/2
+ {AI95-00302-03AI95-00302-03} Returns True if the elements are
+ sorted smallest first as determined by the generic formal "<"
+ operator; otherwise, Is_Sorted returns False. Any exception
+ raised during evaluation of "<" is propagated.
+
+234/2
+ procedure Sort (Container : in out Vector);
+
+235/2
+ {AI95-00302-03AI95-00302-03} Reorders the elements of
+ Container such that the elements are sorted smallest first as
+ determined by the generic formal "<" operator provided. Any
+ exception raised during evaluation of "<" is propagated.
+
+235.a/2
+ Ramification: This implies swapping the elements, usually
+ including an intermediate copy. This means that the elements
+ will usually be copied. (As with Swap, if the implementation
+ can do this some other way, it is allowed to.) Since the
+ elements are nonlimited, this usually will not be a problem.
+ Note that there is Implementation Advice below that the
+ implementation should use a sort that minimizes copying of
+ elements.
+
+235.b/2
+ The sort is not required to be stable (and the fast algorithm
+ required will not be stable). If a stable sort is needed, the
+ user can include the original location of the element as an
+ extra "sort key". We considered requiring the implementation
+ to do that, but it is mostly extra overhead -- usually there
+ is something already in the element that provides the needed
+ stability.
+
+236/2
+ procedure Merge (Target : in out Vector;
+ Source : in out Vector);
+
+237/3
+ {AI95-00302-03AI95-00302-03} {AI05-0021-1AI05-0021-1} If
+ Source is empty, then Merge does nothing. If Source and
+ Target are the same nonempty container object, then
+ Program_Error is propagated. Otherwise, Merge removes
+ elements from Source and inserts them into Target; afterwards,
+ Target contains the union of the elements that were initially
+ in Source and Target; Source is left empty. If Target and
+ Source are initially sorted smallest first, then Target is
+ ordered smallest first as determined by the generic formal "<"
+ operator; otherwise, the order of elements in Target is
+ unspecified. Any exception raised during evaluation of "<" is
+ propagated.
+
+237.a/2
+ Discussion: It is a bounded error if either of the vectors is
+ unsorted, see below. The bounded error can be recovered by
+ sorting Target after the merge call, or the vectors can be
+ pretested with Is_Sorted.
+
+237.b/2
+ Implementation Note: The Merge operation will usually require
+ copying almost all of the elements. One implementation
+ strategy would be to extend Target to the appropriate length,
+ then copying elements from the back of the vectors working
+ towards the front. An alternative approach would be to
+ allocate a new internal data array of the appropriate length,
+ copy the elements into it in an appropriate order, and then
+ replacing the data array in Target with the temporary.
+
+ _Bounded (Run-Time) Errors_
+
+238/3
+{AI95-00302-03AI95-00302-03} {AI05-0212-1AI05-0212-1} Reading the value
+of an empty element by calling Element, Query_Element, Update_Element,
+Constant_Reference, Reference, Swap, Is_Sorted, Sort, Merge, "=", Find,
+or Reverse_Find is a bounded error. The implementation may treat the
+element as having any normal value (see *note 13.9.1::) of the element
+type, or raise Constraint_Error or Program_Error before modifying the
+vector.
+
+238.a/2
+ Ramification: For instance, a default initialized element
+ could be returned. Or some previous value of an element. But
+ returning random junk is not allowed if the type has default
+ initial value(s).
+
+238.b/2
+ Assignment and streaming of empty elements are not bounded
+ errors. This is consistent with regular composite types, for
+ which assignment and streaming of uninitialized components do
+ not cause a bounded error, but reading the uninitialized
+ component does cause a bounded error.
+
+238.c/2
+ There are other operations which are defined in terms of the
+ operations listed above.
+
+239/2
+{AI95-00302-03AI95-00302-03} Calling Merge in an instance of
+Generic_Sorting with either Source or Target not ordered smallest first
+using the provided generic formal "<" operator is a bounded error.
+Either Program_Error is raised after Target is updated as described for
+Merge, or the operation works as defined.
+
+239.1/3
+{AI05-0022-1AI05-0022-1} {AI05-0248-1AI05-0248-1} It is a bounded error
+for the actual function associated with a generic formal subprogram,
+when called as part of an operation of this package, to tamper with
+elements of any Vector parameter of the operation. Either Program_Error
+is raised, or the operation works as defined on the value of the Vector
+either prior to, or subsequent to, some or all of the modifications to
+the Vector.
+
+239.2/3
+{AI05-0027-1AI05-0027-1} It is a bounded error to call any subprogram
+declared in the visible part of Containers.Vectors when the associated
+container has been finalized. If the operation takes Container as an in
+out parameter, then it raises Constraint_Error or Program_Error.
+Otherwise, the operation either proceeds as it would for an empty
+container, or it raises Constraint_Error or Program_Error.
+
+240/2
+{AI95-00302-03AI95-00302-03} A Cursor value is ambiguous if any of the
+following have occurred since it was created:
+
+241/2
+ * Insert, Insert_Space, or Delete has been called on the vector that
+ contains the element the cursor designates with an index value (or
+ a cursor designating an element at such an index value) less than
+ or equal to the index value of the element designated by the
+ cursor; or
+
+242/2
+ * The vector that contains the element it designates has been passed
+ to the Sort or Merge procedures of an instance of Generic_Sorting,
+ or to the Reverse_Elements procedure.
+
+243/2
+{AI95-00302-03AI95-00302-03} It is a bounded error to call any
+subprogram other than "=" or Has_Element declared in Containers.Vectors
+with an ambiguous (but not invalid, see below) cursor parameter.
+Possible results are:
+
+244/2
+ * The cursor may be treated as if it were No_Element;
+
+245/2
+ * The cursor may designate some element in the vector (but not
+ necessarily the element that it originally designated);
+
+246/2
+ * Constraint_Error may be raised; or
+
+247/2
+ * Program_Error may be raised.
+
+247.a/2
+ Reason: Cursors are made ambiguous if an Insert or Delete
+ occurs that moves the elements in the internal array including
+ the designated ones. After such an operation, the cursor
+ probably still designates an element (although it might not
+ after a deletion), but it is a different element. That
+ violates the definition of cursor -- it designates a
+ particular element.
+
+247.b/2
+ For "=" or Has_Element, the cursor works normally (it would
+ not be No_Element). We don't want to trigger an exception
+ simply for comparing a bad cursor.
+
+247.c/2
+ While it is possible to check for these cases or ensure that
+ cursors survive such operations, in many cases the overhead
+ necessary to make the check (or ensure cursors continue to
+ designate the same element) is substantial in time or space.
+
+ _Erroneous Execution_
+
+248/2
+{AI95-00302-03AI95-00302-03} A Cursor value is invalid if any of the
+following have occurred since it was created:
+
+249/2
+ * The vector that contains the element it designates has been
+ finalized;
+
+249.1/3
+ * {AI05-0160-1AI05-0160-1} The vector that contains the element it
+ designates has been used as the Target of a call to Assign, or as
+ the target of an assignment_statement;
+
+250/2
+ * [The vector that contains the element it designates has been used
+ as the Source or Target of a call to Move;] or
+
+250.a/3
+ Proof: {AI05-0001-1AI05-0001-1} Move has been reworded in
+ terms of Assign and Clear, which are covered by other bullets,
+ so this text is redundant.
+
+251/3
+ * {AI05-0160-1AI05-0160-1} {AI05-0262-1AI05-0262-1} The element it
+ designates has been deleted or removed from the vector that
+ previously contained the element.
+
+251.a/3
+ Ramification: {AI05-0160-1AI05-0160-1} An element can be
+ removed via calls to Set_Length, Clear, and Merge; and
+ indirectly via calls to Assign and Move.
+
+252/2
+{AI95-00302-03AI95-00302-03} The result of "=" or Has_Element is
+unspecified if it is called with an invalid cursor parameter. Execution
+is erroneous if any other subprogram declared in Containers.Vectors is
+called with an invalid cursor parameter.
+
+252.a/2
+ Discussion: The list above (combined with the bounded error
+ cases) is intended to be exhaustive. In other cases, a cursor
+ value continues to designate its original element. For
+ instance, cursor values survive the appending of new elements.
+
+252.1/3
+{AI05-0212-1AI05-0212-1} Execution is erroneous if the vector associated
+with the result of a call to Reference or Constant_Reference is
+finalized before the result object returned by the call to Reference or
+Constant_Reference is finalized.
+
+252.b/3
+ Reason: Each object of Reference_Type and
+ Constant_Reference_Type probably contains some reference to
+ the originating container. If that container is prematurely
+ finalized (which is only possible via Unchecked_Deallocation,
+ as accessibility checks prevent passing a container to
+ Reference that will not live as long as the result), the
+ finalization of the object of Reference_Type will try to
+ access a nonexistent object. This is a normal case of a
+ dangling pointer created by Unchecked_Deallocation; we have to
+ explicitly mention it here as the pointer in question is not
+ visible in the specification of the type. (This is the same
+ reason we have to say this for invalid cursors.)
+
+ _Implementation Requirements_
+
+253/2
+{AI95-00302-03AI95-00302-03} No storage associated with a vector object
+shall be lost upon assignment or scope exit.
+
+254/3
+{AI95-00302-03AI95-00302-03} {AI05-0262-1AI05-0262-1} The execution of
+an assignment_statement for a vector shall have the effect of copying
+the elements from the source vector object to the target vector object
+and changing the length of the target object to that of the source
+object.
+
+254.a/3
+ Implementation Note: {AI05-0298-1AI05-0298-1} An assignment of
+ a Vector is a "deep" copy; that is the elements are copied as
+ well as the data structures. We say "effect of" in order to
+ allow the implementation to avoid copying elements immediately
+ if it wishes. For instance, an implementation that avoided
+ copying until one of the containers is modified would be
+ allowed. (Note that such an implementation would be require
+ care, as Query_Element and Constant_Reference both could be
+ used to access an element which later needs to be reallocated
+ while the parameter or reference still exists, potentially
+ leaving the parameter or reference pointing at the wrong
+ element.)
+
+ _Implementation Advice_
+
+255/2
+{AI95-00302-03AI95-00302-03} Containers.Vectors should be implemented
+similarly to an array. In particular, if the length of a vector is N,
+then
+
+256/2
+ * the worst-case time complexity of Element should be O(log N);
+
+256.a/2
+ Implementation Advice: The worst-case time complexity of
+ Element for Containers.Vector should be O(log N).
+
+257/2
+ * the worst-case time complexity of Append with Count=1 when N is
+ less than the capacity of the vector should be O(log N); and
+
+257.a/2
+ Implementation Advice: The worst-case time complexity of
+ Append with Count = 1 when N is less than the capacity for
+ Containers.Vector should be O(log N).
+
+258/2
+ * the worst-case time complexity of Prepend with Count=1 and
+ Delete_First with Count=1 should be O(N log N).
+
+258.a/2
+ Implementation Advice: The worst-case time complexity of
+ Prepend with Count = 1 and Delete_First with Count=1 for
+ Containers.Vectors should be O(N log N).
+
+258.b/2
+ Reason: We do not mean to overly constrain implementation
+ strategies here. However, it is important for portability
+ that the performance of large containers has roughly the same
+ factors on different implementations. If a program is moved
+ to an implementation that takes O(N) time to access elements,
+ that program could be unusable when the vectors are large. We
+ allow O(log N) access because the proportionality constant and
+ caching effects are likely to be larger than the log factor,
+ and we don't want to discourage innovative implementations.
+
+259/2
+{AI95-00302-03AI95-00302-03} The worst-case time complexity of a call on
+procedure Sort of an instance of Containers.Vectors.Generic_Sorting
+should be O(N**2), and the average time complexity should be better than
+O(N**2).
+
+259.a/2
+ Implementation Advice: The worst-case time complexity of a
+ call on procedure Sort of an instance of
+ Containers.Vectors.Generic_Sorting should be O(N**2), and the
+ average time complexity should be better than O(N**2).
+
+259.b/2
+ Ramification: In other words, we're requiring the use of a
+ better than O(N**2) sorting algorithm, such as Quicksort. No
+ bubble sorts allowed!
+
+260/2
+{AI95-00302-03AI95-00302-03} Containers.Vectors.Generic_Sorting.Sort and
+Containers.Vectors.Generic_Sorting.Merge should minimize copying of
+elements.
+
+260.a/2
+ Implementation Advice: Containers.Vectors.Generic_Sorting.Sort
+ and Containers.Vectors.Generic_Sorting.Merge should minimize
+ copying of elements.
+
+260.b/2
+ To be honest: We do not mean "absolutely minimize" here; we're
+ not intending to require a single copy for each element.
+ Rather, we want to suggest that the sorting algorithm chosen
+ is one that does not copy items unnecessarily. Bubble sort
+ would not meet this advice, for instance.
+
+261/2
+{AI95-00302-03AI95-00302-03} Move should not copy elements, and should
+minimize copying of internal data structures.
+
+261.a/2
+ Implementation Advice: Containers.Vectors.Move should not copy
+ elements, and should minimize copying of internal data
+ structures.
+
+261.b/2
+ Implementation Note: Usually that can be accomplished simply
+ by moving the pointer(s) to the internal data structures from
+ the Source vector to the Target vector.
+
+262/2
+{AI95-00302-03AI95-00302-03} If an exception is propagated from a vector
+operation, no storage should be lost, nor any elements removed from a
+vector unless specified by the operation.
+
+262.a/2
+ Implementation Advice: If an exception is propagated from a
+ vector operation, no storage should be lost, nor any elements
+ removed from a vector unless specified by the operation.
+
+262.b/2
+ Reason: This is important so that programs can recover from
+ errors. But we don't want to require heroic efforts, so we
+ just require documentation of cases where this can't be
+ accomplished.
+
+ NOTES
+
+263/2
+ 48 All elements of a vector occupy locations in the internal
+ array. If a sparse container is required, a Hashed_Map should be
+ used rather than a vector.
+
+264/2
+ 49 If Index_Type'Base'First = Index_Type'First an instance of
+ Ada.Containers.Vectors will raise Constraint_Error. A value below
+ Index_Type'First is required so that an empty vector has a
+ meaningful value of Last_Index.
+
+264.a/2
+ Discussion: This property is the main reason why only integer
+ types (as opposed to any discrete type) are allowed as the
+ index type of a vector. An enumeration or modular type would
+ require a subtype in order to meet this requirement.
+
+ _Extensions to Ada 95_
+
+264.b/2
+ {AI95-00302-03AI95-00302-03} The package Containers.Vectors is
+ new.
+
+ _Incompatibilities With Ada 2005_
+
+264.c/3
+ {AI05-0001-1AI05-0001-1} Subprograms Assign and Copy are added
+ to Containers.Vectors. If an instance of Containers.Vectors
+ is referenced in a use_clause, and an entity E with the same
+ defining_identifier as a new entity in Containers.Vectors is
+ defined in a package that is also referenced in a use_clause,
+ the entity E may no longer be use-visible, resulting in
+ errors. This should be rare and is easily fixed if it does
+ occur.
+
+ _Extensions to Ada 2005_
+
+264.d/3
+ {AI05-0212-1AI05-0212-1} Added iterator, reference, and
+ indexing support to make vector containers more convenient to
+ use.
+
+ _Wording Changes from Ada 2005_
+
+264.e/3
+ {AI05-0001-1AI05-0001-1} Generalized the definition of
+ Reserve_Capacity and Move. Specified which elements are
+ read/written by stream attributes.
+
+264.f/3
+ {AI05-0022-1AI05-0022-1} Correction: Added a Bounded
+ (Run-Time) Error to cover tampering by generic actual
+ subprograms.
+
+264.g/3
+ {AI05-0027-1AI05-0027-1} Correction: Added a Bounded
+ (Run-Time) Error to cover access to finalized vector
+ containers.
+
+264.h/3
+ {AI05-0044-1AI05-0044-1} Correction: Redefined "<" actuals to
+ require a strict weak ordering; the old definition allowed
+ indeterminant comparisons that would not have worked in a
+ container.
+
+264.i/3
+ {AI05-0084-1AI05-0084-1} Correction: Added a pragma
+ Remote_Types so that containers can be used in distributed
+ programs.
+
+264.j/3
+ {AI05-0160-1AI05-0160-1} Correction: Revised the definition of
+ invalid cursors to cover missing (and new) cases.
+
+264.k/3
+ {AI05-0265-1AI05-0265-1} Correction: Defined when a container
+ prohibits tampering in order to more clearly define where the
+ check is made and the exception raised.
+
+\1f
+File: aarm2012.info, Node: A.18.3, Next: A.18.4, Prev: A.18.2, Up: A.18
+
+A.18.3 The Generic Package Containers.Doubly_Linked_Lists
+---------------------------------------------------------
+
+1/2
+{AI95-00302-03AI95-00302-03} The language-defined generic package
+Containers.Doubly_Linked_Lists provides private types List and Cursor,
+and a set of operations for each type. A list container is optimized
+for insertion and deletion at any position.
+
+2/2
+{AI95-00302-03AI95-00302-03} A doubly-linked list container object
+manages a linked list of internal nodes, each of which contains an
+element and pointers to the next (successor) and previous (predecessor)
+internal nodes. A cursor designates a particular node within a list
+(and by extension the element contained in that node). A cursor keeps
+designating the same node (and element) as long as the node is part of
+the container, even if the node is moved in the container.
+
+3/2
+{AI95-00302-03AI95-00302-03} The length of a list is the number of
+elements it contains.
+
+ _Static Semantics_
+
+4/2
+{AI95-00302-03AI95-00302-03} The generic library package
+Containers.Doubly_Linked_Lists has the following declaration:
+
+5/3
+ {AI05-0084-1AI05-0084-1} {AI05-0212-1AI05-0212-1} with Ada.Iterator_Interfaces;
+ generic
+ type Element_Type is private;
+ with function "=" (Left, Right : Element_Type)
+ return Boolean is <>;
+ package Ada.Containers.Doubly_Linked_Lists is
+ pragma Preelaborate(Doubly_Linked_Lists);
+ pragma Remote_Types(Doubly_Linked_Lists);
+
+6/3
+ {AI05-0212-1AI05-0212-1} type List is tagged private
+ with Constant_Indexing => Constant_Reference,
+ Variable_Indexing => Reference,
+ Default_Iterator => Iterate,
+ Iterator_Element => Element_Type;
+ pragma Preelaborable_Initialization(List);
+
+7/2
+ type Cursor is private;
+ pragma Preelaborable_Initialization(Cursor);
+
+8/2
+ Empty_List : constant List;
+
+9/2
+ No_Element : constant Cursor;
+
+9.1/3
+ {AI05-0212-1AI05-0212-1} function Has_Element (Position : Cursor) return Boolean;
+
+9.2/3
+ {AI05-0212-1AI05-0212-1} package List_Iterator_Interfaces is new
+ Ada.Iterator_Interfaces (Cursor, Has_Element);
+
+10/2
+ function "=" (Left, Right : List) return Boolean;
+
+11/2
+ function Length (Container : List) return Count_Type;
+
+12/2
+ function Is_Empty (Container : List) return Boolean;
+
+13/2
+ procedure Clear (Container : in out List);
+
+14/2
+ function Element (Position : Cursor)
+ return Element_Type;
+
+15/2
+ procedure Replace_Element (Container : in out List;
+ Position : in Cursor;
+ New_Item : in Element_Type);
+
+16/2
+ procedure Query_Element
+ (Position : in Cursor;
+ Process : not null access procedure (Element : in Element_Type));
+
+17/2
+ procedure Update_Element
+ (Container : in out List;
+ Position : in Cursor;
+ Process : not null access procedure
+ (Element : in out Element_Type));
+
+17.1/3
+ {AI05-0212-1AI05-0212-1} type Constant_Reference_Type
+ (Element : not null access constant Element_Type) is private
+ with Implicit_Dereference => Element;
+
+17.2/3
+ {AI05-0212-1AI05-0212-1} type Reference_Type (Element : not null access Element_Type) is private
+ with Implicit_Dereference => Element;
+
+17.3/3
+ {AI05-0212-1AI05-0212-1} function Constant_Reference (Container : aliased in List;
+ Position : in Cursor)
+ return Constant_Reference_Type;
+
+17.4/3
+ {AI05-0212-1AI05-0212-1} function Reference (Container : aliased in out List;
+ Position : in Cursor)
+ return Reference_Type;
+
+17.5/3
+ {AI05-0001-1AI05-0001-1} procedure Assign (Target : in out List; Source : in List);
+
+17.6/3
+ {AI05-0001-1AI05-0001-1} function Copy (Source : List) return List;
+
+18/2
+ procedure Move (Target : in out List;
+ Source : in out List);
+
+19/2
+ procedure Insert (Container : in out List;
+ Before : in Cursor;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+20/2
+ procedure Insert (Container : in out List;
+ Before : in Cursor;
+ New_Item : in Element_Type;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+21/2
+ procedure Insert (Container : in out List;
+ Before : in Cursor;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+22/2
+ procedure Prepend (Container : in out List;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+23/2
+ procedure Append (Container : in out List;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+24/2
+ procedure Delete (Container : in out List;
+ Position : in out Cursor;
+ Count : in Count_Type := 1);
+
+25/2
+ procedure Delete_First (Container : in out List;
+ Count : in Count_Type := 1);
+
+26/2
+ procedure Delete_Last (Container : in out List;
+ Count : in Count_Type := 1);
+
+27/2
+ procedure Reverse_Elements (Container : in out List);
+
+28/2
+ procedure Swap (Container : in out List;
+ I, J : in Cursor);
+
+29/2
+ procedure Swap_Links (Container : in out List;
+ I, J : in Cursor);
+
+30/2
+ procedure Splice (Target : in out List;
+ Before : in Cursor;
+ Source : in out List);
+
+31/2
+ procedure Splice (Target : in out List;
+ Before : in Cursor;
+ Source : in out List;
+ Position : in out Cursor);
+
+32/2
+ procedure Splice (Container: in out List;
+ Before : in Cursor;
+ Position : in Cursor);
+
+33/2
+ function First (Container : List) return Cursor;
+
+34/2
+ function First_Element (Container : List)
+ return Element_Type;
+
+35/2
+ function Last (Container : List) return Cursor;
+
+36/2
+ function Last_Element (Container : List)
+ return Element_Type;
+
+37/2
+ function Next (Position : Cursor) return Cursor;
+
+38/2
+ function Previous (Position : Cursor) return Cursor;
+
+39/2
+ procedure Next (Position : in out Cursor);
+
+40/2
+ procedure Previous (Position : in out Cursor);
+
+41/2
+ function Find (Container : List;
+ Item : Element_Type;
+ Position : Cursor := No_Element)
+ return Cursor;
+
+42/2
+ function Reverse_Find (Container : List;
+ Item : Element_Type;
+ Position : Cursor := No_Element)
+ return Cursor;
+
+43/2
+ function Contains (Container : List;
+ Item : Element_Type) return Boolean;
+
+44/3
+ This paragraph was deleted.{AI05-0212-1AI05-0212-1}
+
+45/2
+ procedure Iterate
+ (Container : in List;
+ Process : not null access procedure (Position : in Cursor));
+
+46/2
+ procedure Reverse_Iterate
+ (Container : in List;
+ Process : not null access procedure (Position : in Cursor));
+
+46.1/3
+ {AI05-0212-1AI05-0212-1} function Iterate (Container : in List)
+ return List_Iterator_Interfaces.Reversible_Iterator'Class;
+
+46.2/3
+ {AI05-0212-1AI05-0212-1} function Iterate (Container : in List; Start : in Cursor)
+ return List_Iterator_Interfaces.Reversible_Iterator'Class;
+
+47/2
+ generic
+ with function "<" (Left, Right : Element_Type)
+ return Boolean is <>;
+ package Generic_Sorting is
+
+48/2
+ function Is_Sorted (Container : List) return Boolean;
+
+49/2
+ procedure Sort (Container : in out List);
+
+50/2
+ procedure Merge (Target : in out List;
+ Source : in out List);
+
+51/2
+ end Generic_Sorting;
+
+52/2
+ private
+
+53/2
+ ... -- not specified by the language
+
+54/2
+ end Ada.Containers.Doubly_Linked_Lists;
+
+55/2
+{AI95-00302-03AI95-00302-03} The actual function for the generic formal
+function "=" on Element_Type values is expected to define a reflexive
+and symmetric relationship and return the same result value each time it
+is called with a particular pair of values. If it behaves in some other
+manner, the functions Find, Reverse_Find, and "=" on list values return
+an unspecified value. The exact arguments and number of calls of this
+generic formal function by the functions Find, Reverse_Find, and "=" on
+list values are unspecified.
+
+55.a/2
+ Ramification: If the actual function for "=" is not symmetric
+ and consistent, the result returned by the listed functions
+ cannot be predicted. The implementation is not required to
+ protect against "=" raising an exception, or returning random
+ results, or any other "bad" behavior. And it can call "=" in
+ whatever manner makes sense. But note that only the results
+ of Find, Reverse_Find, and List "=" are unspecified; other
+ subprograms are not allowed to break if "=" is bad (they
+ aren't expected to use "=").
+
+56/2
+{AI95-00302-03AI95-00302-03} The type List is used to represent lists.
+The type List needs finalization (see *note 7.6::).
+
+57/2
+{AI95-00302-03AI95-00302-03} Empty_List represents the empty List
+object. It has a length of 0. If an object of type List is not
+otherwise initialized, it is initialized to the same value as
+Empty_List.
+
+58/2
+{AI95-00302-03AI95-00302-03} No_Element represents a cursor that
+designates no element. If an object of type Cursor is not otherwise
+initialized, it is initialized to the same value as No_Element.
+
+59/2
+{AI95-00302-03AI95-00302-03} The predefined "=" operator for type Cursor
+returns True if both cursors are No_Element, or designate the same
+element in the same container.
+
+60/2
+{AI95-00302-03AI95-00302-03} Execution of the default implementation of
+the Input, Output, Read, or Write attribute of type Cursor raises
+Program_Error.
+
+60.a/2
+ Reason: A cursor will probably be implemented in terms of one
+ or more access values, and the effects of streaming access
+ values is unspecified. Rather than letting the user stream
+ junk by accident, we mandate that streaming of cursors raise
+ Program_Error by default. The attributes can always be
+ specified if there is a need to support streaming.
+
+60.1/3
+{AI05-0001-1AI05-0001-1} {AI05-0262-1AI05-0262-1} List'Write for a List
+object L writes Length(L) elements of the list to the stream. It also
+may write additional information about the list.
+
+60.2/3
+{AI05-0001-1AI05-0001-1} {AI05-0262-1AI05-0262-1} List'Read reads the
+representation of a list from the stream, and assigns to Item a list
+with the same length and elements as was written by List'Write.
+
+60.b/3
+ Ramification: Streaming more elements than the container
+ length is wrong. For implementation implications of this
+ rule, see the Implementation Note in *note A.18.2::.
+
+61/2
+{AI95-00302-03AI95-00302-03} [Some operations of this generic package
+have access-to-subprogram parameters. To ensure such operations are
+well-defined, they guard against certain actions by the designated
+subprogram. In particular, some operations check for "tampering with
+cursors" of a container because they depend on the set of elements of
+the container remaining constant, and others check for "tampering with
+elements" of a container because they depend on elements of the
+container not being replaced.]
+
+62/2
+{AI95-00302-03AI95-00302-03} A subprogram is said to tamper with cursors
+of a list object L if:
+
+63/2
+ * it inserts or deletes elements of L, that is, it calls the Insert,
+ Clear, Delete, or Delete_Last procedures with L as a parameter; or
+
+63.a/2
+ To be honest: Operations which are defined to be equivalent to
+ a call on one of these operations also are included.
+ Similarly, operations which call one of these as part of their
+ definition are included.
+
+64/2
+ * it reorders the elements of L, that is, it calls the Splice,
+ Swap_Links, or Reverse_Elements procedures or the Sort or Merge
+ procedures of an instance of Generic_Sorting with L as a parameter;
+ or
+
+65/2
+ * it finalizes L; or
+
+65.1/3
+ * {AI05-0001-1AI05-0001-1} it calls the Assign procedure with L as
+ the Target parameter; or
+
+65.a.1/3
+ Ramification: We don't need to explicitly mention
+ assignment_statement, because that finalizes the target object
+ as part of the operation, and finalization of an object is
+ already defined as tampering with cursors.
+
+66/2
+ * it calls the Move procedure with L as a parameter.
+
+66.a/2
+ Reason: Swap copies elements rather than reordering them, so
+ it doesn't tamper with cursors.
+
+67/2
+{AI95-00302-03AI95-00302-03} A subprogram is said to tamper with
+elements of a list object L if:
+
+68/2
+ * it tampers with cursors of L; or
+
+69/2
+ * it replaces one or more elements of L, that is, it calls the
+ Replace_Element or Swap procedures with L as a parameter.
+
+69.a/2
+ Reason: Complete replacement of an element can cause its
+ memory to be deallocated while another operation is holding
+ onto a reference to it. That can't be allowed. However, a
+ simple modification of (part of) an element is not a problem,
+ so Update_Element does not cause a problem.
+
+69.1/3
+{AI05-0265-1AI05-0265-1} When tampering with cursors is prohibited for a
+particular list object L, Program_Error is propagated by a call of any
+language-defined subprogram that is defined to tamper with the cursors
+of L, leaving L unmodified. Similarly, when tampering with elements is
+prohibited for a particular list object L, Program_Error is propagated
+by a call of any language-defined subprogram that is defined to tamper
+with the elements of L [(or tamper with the cursors of L)], leaving L
+unmodified.
+
+69.b/3
+ Proof: Tampering with elements includes tampering with
+ cursors, so we mention it only from completeness in the second
+ sentence.
+
+69.2/3
+ function Has_Element (Position : Cursor) return Boolean;
+
+69.3/3
+ {AI05-0212-1AI05-0212-1} Returns True if Position designates
+ an element, and returns False otherwise.
+
+69.c/3
+ To be honest: {AI05-0005-1AI05-0005-1}
+ {AI05-0212-1AI05-0212-1} This function might not detect
+ cursors that designate deleted elements; such cursors are
+ invalid (see below) and the result of calling Has_Element with
+ an invalid cursor is unspecified (but not erroneous).
+
+70/2
+ function "=" (Left, Right : List) return Boolean;
+
+71/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If Left
+ and Right denote the same list object, then the function
+ returns True. If Left and Right have different lengths, then
+ the function returns False. Otherwise, it compares each
+ element in Left to the corresponding element in Right using
+ the generic formal equality operator. If any such comparison
+ returns False, the function returns False; otherwise, it
+ returns True. Any exception raised during evaluation of
+ element equality is propagated.
+
+71.a/2
+ Implementation Note: This wording describes the canonical
+ semantics. However, the order and number of calls on the
+ formal equality function is unspecified for all of the
+ operations that use it in this package, so an implementation
+ can call it as many or as few times as it needs to get the
+ correct answer. Specifically, there is no requirement to call
+ the formal equality additional times once the answer has been
+ determined.
+
+72/2
+ function Length (Container : List) return Count_Type;
+
+73/2
+ {AI95-00302-03AI95-00302-03} Returns the number of elements in
+ Container.
+
+74/2
+ function Is_Empty (Container : List) return Boolean;
+
+75/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Length (Container)
+ = 0.
+
+76/2
+ procedure Clear (Container : in out List);
+
+77/2
+ {AI95-00302-03AI95-00302-03} Removes all the elements from
+ Container.
+
+78/2
+ function Element (Position : Cursor) return Element_Type;
+
+79/2
+ {AI95-00302-03AI95-00302-03} If Position equals No_Element,
+ then Constraint_Error is propagated. Otherwise, Element
+ returns the element designated by Position.
+
+80/2
+ procedure Replace_Element (Container : in out List;
+ Position : in Cursor;
+ New_Item : in Element_Type);
+
+81/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Position equals No_Element, then Constraint_Error is
+ propagated; if Position does not designate an element in
+ Container, then Program_Error is propagated. Otherwise,
+ Replace_Element assigns the value New_Item to the element
+ designated by Position.
+
+82/2
+ procedure Query_Element
+ (Position : in Cursor;
+ Process : not null access procedure (Element : in Element_Type));
+
+83/3
+ {AI95-00302-03AI95-00302-03} {AI05-0021-1AI05-0021-1}
+ {AI05-0265-1AI05-0265-1} If Position equals No_Element, then
+ Constraint_Error is propagated. Otherwise, Query_Element
+ calls Process.all with the element designated by Position as
+ the argument. Tampering with the elements of the list that
+ contains the element designated by Position is prohibited
+ during the execution of the call on Process.all. Any
+ exception raised by Process.all is propagated.
+
+84/2
+ procedure Update_Element
+ (Container : in out List;
+ Position : in Cursor;
+ Process : not null access procedure (Element : in out Element_Type));
+
+85/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1}
+ {AI05-0265-1AI05-0265-1} If Position equals No_Element, then
+ Constraint_Error is propagated; if Position does not designate
+ an element in Container, then Program_Error is propagated.
+ Otherwise, Update_Element calls Process.all with the element
+ designated by Position as the argument. Tampering with the
+ elements of Container is prohibited during the execution of
+ the call on Process.all. Any exception raised by Process.all
+ is propagated.
+
+86/2
+ If Element_Type is unconstrained and definite, then the actual
+ Element parameter of Process.all shall be unconstrained.
+
+86.a/2
+ Ramification: This means that the elements cannot be directly
+ allocated from the heap; it must be possible to change the
+ discriminants of the element in place.
+
+86.1/3
+ type Constant_Reference_Type
+ (Element : not null access constant Element_Type) is private
+ with Implicit_Dereference => Element;
+
+86.2/3
+ type Reference_Type (Element : not null access Element_Type) is private
+ with Implicit_Dereference => Element;
+
+86.3/3
+ {AI05-0212-1AI05-0212-1} The types Constant_Reference_Type and
+ Reference_Type need finalization.
+
+86.4/3
+ The default initialization of an object of type
+ Constant_Reference_Type or Reference_Type propagates
+ Program_Error.
+
+86.b/3
+ Reason: It is expected that Reference_Type (and
+ Constant_Reference_Type) will be a controlled type, for which
+ finalization will have some action to terminate the tampering
+ check for the associated container. If the object is created
+ by default, however, there is no associated container. Since
+ this is useless, and supporting this case would take extra
+ work, we define it to raise an exception.
+
+86.5/3
+ function Constant_Reference (Container : aliased in List;
+ Position : in Cursor)
+ return Constant_Reference_Type;
+
+86.6/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Constant_Indexing and
+ Implicit_Dereference aspects) provides a convenient way to
+ gain read access to an individual element of a list given a
+ cursor.
+
+86.7/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1} If Position
+ equals No_Element, then Constraint_Error is propagated; if
+ Position does not designate an element in Container, then
+ Program_Error is propagated. Otherwise, Constant_Reference
+ returns an object whose discriminant is an access value that
+ designates the element designated by Position. Tampering with
+ the elements of Container is prohibited while the object
+ returned by Constant_Reference exists and has not been
+ finalized.
+
+86.8/3
+ function Reference (Container : aliased in out List;
+ Position : in Cursor)
+ return Reference_Type;
+
+86.9/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Variable_Indexing and
+ Implicit_Dereference aspects) provides a convenient way to
+ gain read and write access to an individual element of a list
+ given a cursor.
+
+86.10/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1} If Position
+ equals No_Element, then Constraint_Error is propagated; if
+ Position does not designate an element in Container, then
+ Program_Error is propagated. Otherwise, Reference returns an
+ object whose discriminant is an access value that designates
+ the element designated by Position. Tampering with the
+ elements of Container is prohibited while the object returned
+ by Reference exists and has not been finalized.
+
+86.11/3
+ procedure Assign (Target : in out List; Source : in List);
+
+86.12/3
+ {AI05-0001-1AI05-0001-1} {AI05-0248-1AI05-0248-1} If Target
+ denotes the same object as Source, the operation has no
+ effect. Otherwise, the elements of Source are copied to
+ Target as for an assignment_statement assigning Source to
+ Target.
+
+86.c/3
+ Discussion: {AI05-0005-1AI05-0005-1} This routine exists for
+ compatibility with the bounded list container. For an
+ unbounded list, Assign(A, B) and A := B behave identically.
+ For a bounded list, := will raise an exception if the
+ container capacities are different, while Assign will not
+ raise an exception if there is enough room in the target.
+
+86.13/3
+ function Copy (Source : List) return List;
+
+86.14/3
+ {AI05-0001-1AI05-0001-1} Returns a list whose elements match
+ the elements of Source.
+
+87/2
+ procedure Move (Target : in out List;
+ Source : in out List);
+
+88/3
+ {AI95-00302-03AI95-00302-03} {AI05-0001-1AI05-0001-1}
+ {AI05-0248-1AI05-0248-1} {AI05-0262-1AI05-0262-1} If Target
+ denotes the same object as Source, then the operation has no
+ effect. Otherwise, the operation is equivalent to Assign
+ (Target, Source) followed by Clear (Source).
+
+89/2
+ procedure Insert (Container : in out List;
+ Before : in Cursor;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+90/2
+ {AI95-00302-03AI95-00302-03} If Before is not No_Element, and
+ does not designate an element in Container, then Program_Error
+ is propagated. Otherwise, Insert inserts Count copies of
+ New_Item prior to the element designated by Before. If Before
+ equals No_Element, the new elements are inserted after the
+ last node (if any). Any exception raised during allocation of
+ internal storage is propagated, and Container is not modified.
+
+90.a/2
+ Ramification: The check on Before checks that the cursor does
+ not belong to some other Container. This check implies that a
+ reference to the container is included in the cursor value.
+ This wording is not meant to require detection of dangling
+ cursors; such cursors are defined to be invalid, which means
+ that execution is erroneous, and any result is allowed
+ (including not raising an exception).
+
+91/2
+ procedure Insert (Container : in out List;
+ Before : in Cursor;
+ New_Item : in Element_Type;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+92/3
+ {AI95-00302-03AI95-00302-03} {AI05-0257-1AI05-0257-1} If
+ Before is not No_Element, and does not designate an element in
+ Container, then Program_Error is propagated. Otherwise,
+ Insert allocates Count copies of New_Item, and inserts them
+ prior to the element designated by Before. If Before equals
+ No_Element, the new elements are inserted after the last
+ element (if any). Position designates the first
+ newly-inserted element, or if Count equals 0, then Position is
+ assigned the value of Before. Any exception raised during
+ allocation of internal storage is propagated, and Container is
+ not modified.
+
+93/2
+ procedure Insert (Container : in out List;
+ Before : in Cursor;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+94/3
+ {AI95-00302-03AI95-00302-03} {AI05-0257-1AI05-0257-1} If
+ Before is not No_Element, and does not designate an element in
+ Container, then Program_Error is propagated. Otherwise,
+ Insert inserts Count new elements prior to the element
+ designated by Before. If Before equals No_Element, the new
+ elements are inserted after the last node (if any). The new
+ elements are initialized by default (see *note 3.3.1::).
+ Position designates the first newly-inserted element, or if
+ Count equals 0, then Position is assigned the value of Before.
+ Any exception raised during allocation of internal storage is
+ propagated, and Container is not modified.
+
+95/2
+ procedure Prepend (Container : in out List;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+96/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Insert (Container,
+ First (Container), New_Item, Count).
+
+97/2
+ procedure Append (Container : in out List;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+98/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Insert (Container,
+ No_Element, New_Item, Count).
+
+99/2
+ procedure Delete (Container : in out List;
+ Position : in out Cursor;
+ Count : in Count_Type := 1);
+
+100/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Position equals No_Element, then Constraint_Error is
+ propagated. If Position does not designate an element in
+ Container, then Program_Error is propagated. Otherwise,
+ Delete removes (from Container) Count elements starting at the
+ element designated by Position (or all of the elements
+ starting at Position if there are fewer than Count elements
+ starting at Position). Finally, Position is set to
+ No_Element.
+
+101/2
+ procedure Delete_First (Container : in out List;
+ Count : in Count_Type := 1);
+
+102/3
+ {AI95-00302-03AI95-00302-03} {AI05-0021-1AI05-0021-1} If
+ Length (Container) <= Count, then Delete_First is equivalent
+ to Clear (Container). Otherwise, it removes the first Count
+ nodes from Container.
+
+103/2
+ procedure Delete_Last (Container : in out List;
+ Count : in Count_Type := 1);
+
+104/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Length (Container) <= Count, then Delete_Last is equivalent to
+ Clear (Container). Otherwise, it removes the last Count nodes
+ from Container.
+
+105/2
+ procedure Reverse_Elements (Container : in out List);
+
+106/2
+ {AI95-00302-03AI95-00302-03} Reorders the elements of
+ Container in reverse order.
+
+106.a/2
+ Discussion: Unlike the similar routine for a vector, elements
+ should not be copied; rather, the nodes should be exchanged.
+ Cursors are expected to reference the same elements
+ afterwards.
+
+107/2
+ procedure Swap (Container : in out List;
+ I, J : in Cursor);
+
+108/2
+ {AI95-00302-03AI95-00302-03} If either I or J is No_Element,
+ then Constraint_Error is propagated. If either I or J do not
+ designate an element in Container, then Program_Error is
+ propagated. Otherwise, Swap exchanges the values of the
+ elements designated by I and J.
+
+108.a/2
+ Ramification: After a call to Swap, I designates the element
+ value previously designated by J, and J designates the element
+ value previously designated by I. The cursors do not become
+ ambiguous from this operation.
+
+108.b/2
+ To be honest: The implementation is not required to actually
+ copy the elements if it can do the swap some other way. But
+ it is allowed to copy the elements if needed.
+
+109/2
+ procedure Swap_Links (Container : in out List;
+ I, J : in Cursor);
+
+110/2
+ {AI95-00302-03AI95-00302-03} If either I or J is No_Element,
+ then Constraint_Error is propagated. If either I or J do not
+ designate an element in Container, then Program_Error is
+ propagated. Otherwise, Swap_Links exchanges the nodes
+ designated by I and J.
+
+110.a/2
+ Ramification: Unlike Swap, this exchanges the nodes, not the
+ elements. No copying is performed. I and J designate the
+ same elements after this call as they did before it. This
+ operation can provide better performance than Swap if the
+ element size is large.
+
+111/2
+ procedure Splice (Target : in out List;
+ Before : in Cursor;
+ Source : in out List);
+
+112/2
+ {AI95-00302-03AI95-00302-03} If Before is not No_Element, and
+ does not designate an element in Target, then Program_Error is
+ propagated. Otherwise, if Source denotes the same object as
+ Target, the operation has no effect. Otherwise, Splice
+ reorders elements such that they are removed from Source and
+ moved to Target, immediately prior to Before. If Before
+ equals No_Element, the nodes of Source are spliced after the
+ last node of Target. The length of Target is incremented by
+ the number of nodes in Source, and the length of Source is set
+ to 0.
+
+113/2
+ procedure Splice (Target : in out List;
+ Before : in Cursor;
+ Source : in out List;
+ Position : in out Cursor);
+
+114/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Position is No_Element, then Constraint_Error is propagated.
+ If Before does not equal No_Element, and does not designate an
+ element in Target, then Program_Error is propagated. If
+ Position does not equal No_Element, and does not designate a
+ node in Source, then Program_Error is propagated. If Source
+ denotes the same object as Target, then there is no effect if
+ Position equals Before, else the element designated by
+ Position is moved immediately prior to Before, or, if Before
+ equals No_Element, after the last element. In both cases,
+ Position and the length of Target are unchanged. Otherwise,
+ the element designated by Position is removed from Source and
+ moved to Target, immediately prior to Before, or, if Before
+ equals No_Element, after the last element of Target. The
+ length of Target is incremented, the length of Source is
+ decremented, and Position is updated to represent an element
+ in Target.
+
+114.a/2
+ Ramification: If Source is the same as Target, and Position =
+ Before, or Next(Position) = Before, Splice has no effect, as
+ the element does not have to move to meet the postcondition.
+
+115/2
+ procedure Splice (Container: in out List;
+ Before : in Cursor;
+ Position : in Cursor);
+
+116/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Position is No_Element, then Constraint_Error is propagated.
+ If Before does not equal No_Element, and does not designate an
+ element in Container, then Program_Error is propagated. If
+ Position does not equal No_Element, and does not designate a
+ node in Container, then Program_Error is propagated. If
+ Position equals Before there is no effect. Otherwise, the
+ element designated by Position is moved immediately prior to
+ Before, or, if Before equals No_Element, after the last
+ element. The length of Container is unchanged.
+
+117/2
+ function First (Container : List) return Cursor;
+
+118/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Container is empty, First returns the value No_Element.
+ Otherwise, it returns a cursor that designates the first node
+ in Container.
+
+119/2
+ function First_Element (Container : List) return Element_Type;
+
+120/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Element (First
+ (Container)).
+
+121/2
+ function Last (Container : List) return Cursor;
+
+122/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Container is empty, Last returns the value No_Element.
+ Otherwise, it returns a cursor that designates the last node
+ in Container.
+
+123/2
+ function Last_Element (Container : List) return Element_Type;
+
+124/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Element (Last
+ (Container)).
+
+125/2
+ function Next (Position : Cursor) return Cursor;
+
+126/2
+ {AI95-00302-03AI95-00302-03} If Position equals No_Element or
+ designates the last element of the container, then Next
+ returns the value No_Element. Otherwise, it returns a cursor
+ that designates the successor of the element designated by
+ Position.
+
+127/2
+ function Previous (Position : Cursor) return Cursor;
+
+128/2
+ {AI95-00302-03AI95-00302-03} If Position equals No_Element or
+ designates the first element of the container, then Previous
+ returns the value No_Element. Otherwise, it returns a cursor
+ that designates the predecessor of the element designated by
+ Position.
+
+129/2
+ procedure Next (Position : in out Cursor);
+
+130/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Position := Next
+ (Position).
+
+131/2
+ procedure Previous (Position : in out Cursor);
+
+132/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Position :=
+ Previous (Position).
+
+133/2
+ function Find (Container : List;
+ Item : Element_Type;
+ Position : Cursor := No_Element)
+ return Cursor;
+
+134/2
+ {AI95-00302-03AI95-00302-03} If Position is not No_Element,
+ and does not designate an element in Container, then
+ Program_Error is propagated. Find searches the elements of
+ Container for an element equal to Item (using the generic
+ formal equality operator). The search starts at the element
+ designated by Position, or at the first element if Position
+ equals No_Element. It proceeds towards Last (Container). If
+ no equal element is found, then Find returns No_Element.
+ Otherwise, it returns a cursor designating the first equal
+ element encountered.
+
+135/2
+ function Reverse_Find (Container : List;
+ Item : Element_Type;
+ Position : Cursor := No_Element)
+ return Cursor;
+
+136/2
+ {AI95-00302-03AI95-00302-03} If Position is not No_Element,
+ and does not designate an element in Container, then
+ Program_Error is propagated. Find searches the elements of
+ Container for an element equal to Item (using the generic
+ formal equality operator). The search starts at the element
+ designated by Position, or at the last element if Position
+ equals No_Element. It proceeds towards First (Container). If
+ no equal element is found, then Reverse_Find returns
+ No_Element. Otherwise, it returns a cursor designating the
+ first equal element encountered.
+
+137/2
+ function Contains (Container : List;
+ Item : Element_Type) return Boolean;
+
+138/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Find (Container,
+ Item) /= No_Element.
+
+ Paragraphs 139 and 140 were moved above.
+
+141/2
+ procedure Iterate
+ (Container : in List;
+ Process : not null access procedure (Position : in Cursor));
+
+142/3
+ {AI95-00302-03AI95-00302-03} {AI05-0265-1AI05-0265-1} Iterate
+ calls Process.all with a cursor that designates each node in
+ Container, starting with the first node and moving the cursor
+ as per the Next function. Tampering with the cursors of
+ Container is prohibited during the execution of a call on
+ Process.all. Any exception raised by Process.all is
+ propagated.
+
+142.a/2
+ Implementation Note: The purpose of the tamper with cursors
+ check is to prevent erroneous execution from the Position
+ parameter of Process.all becoming invalid. This check takes
+ place when the operations that tamper with the cursors of the
+ container are called. The check cannot be made later (say in
+ the body of Iterate), because that could cause the Position
+ cursor to be invalid and potentially cause execution to become
+ erroneous -- defeating the purpose of the check.
+
+142.b/2
+ See Iterate for vectors (*note A.18.2::) for a suggested
+ implementation of the check.
+
+143/2
+ procedure Reverse_Iterate
+ (Container : in List;
+ Process : not null access procedure (Position : in Cursor));
+
+144/3
+ {AI95-00302-03AI95-00302-03} {AI05-0212-1AI05-0212-1} Iterates
+ over the nodes in Container as per procedure Iterate, except
+ that elements are traversed in reverse order, starting with
+ the last node and moving the cursor as per the Previous
+ function.
+
+144.1/3
+ function Iterate (Container : in List)
+ return List_Iterator_Interfaces.Reversible_Iterator'Class;
+
+144.2/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1}
+ {AI05-0269-1AI05-0269-1} Iterate returns a reversible iterator
+ object (see *note 5.5.1::) that will generate a value for a
+ loop parameter (see *note 5.5.2::) designating each node in
+ Container, starting with the first node and moving the cursor
+ as per the Next function when used as a forward iterator, and
+ starting with the last node and moving the cursor as per the
+ Previous function when used as a reverse iterator. Tampering
+ with the cursors of Container is prohibited while the iterator
+ object exists (in particular, in the sequence_of_statements of
+ the loop_statement whose iterator_specification denotes this
+ object). The iterator object needs finalization.
+
+144.3/3
+ function Iterate (Container : in List; Start : in Cursor)
+ return List_Iterator_Interfaces.Reversible_Iterator'Class;
+
+144.4/3
+ {AI05-0212-1AI05-0212-1} {AI05-0262-1AI05-0262-1}
+ {AI05-0265-1AI05-0265-1} {AI05-0269-1AI05-0269-1} If Start is
+ not No_Element and does not designate an item in Container,
+ then Program_Error is propagated. If Start is No_Element,
+ then Constraint_Error is propagated. Otherwise, Iterate
+ returns a reversible iterator object (see *note 5.5.1::) that
+ will generate a value for a loop parameter (see *note 5.5.2::)
+ designating each node in Container, starting with the node
+ designated by Start and moving the cursor as per the Next
+ function when used as a forward iterator, or moving the cursor
+ as per the Previous function when used as a reverse iterator.
+ Tampering with the cursors of Container is prohibited while
+ the iterator object exists (in particular, in the
+ sequence_of_statements of the loop_statement whose
+ iterator_specification denotes this object). The iterator
+ object needs finalization.
+
+144.a/3
+ Discussion: Exits are allowed from the loops created using the
+ iterator objects. In particular, to stop the iteration at a
+ particular cursor, just add
+
+144.b/3
+ exit when Cur = Stop;
+
+144.c/3
+ in the body of the loop (assuming that Cur is the loop
+ parameter and Stop is the cursor that you want to stop at).
+
+145/3
+{AI05-0044-1AI05-0044-1} {AI05-0262-1AI05-0262-1} The actual function
+for the generic formal function "<" of Generic_Sorting is expected to
+return the same value each time it is called with a particular pair of
+element values. It should define a strict weak ordering relationship
+(see *note A.18::); it should not modify Container. If the actual for
+"<" behaves in some other manner, the behavior of the subprograms of
+Generic_Sorting are unspecified. The number of times the subprograms of
+Generic_Sorting call "<" is unspecified.
+
+146/2
+ function Is_Sorted (Container : List) return Boolean;
+
+147/2
+ {AI95-00302-03AI95-00302-03} Returns True if the elements are
+ sorted smallest first as determined by the generic formal "<"
+ operator; otherwise, Is_Sorted returns False. Any exception
+ raised during evaluation of "<" is propagated.
+
+148/2
+ procedure Sort (Container : in out List);
+
+149/2
+ {AI95-00302-03AI95-00302-03} Reorders the nodes of Container
+ such that the elements are sorted smallest first as determined
+ by the generic formal "<" operator provided. The sort is
+ stable. Any exception raised during evaluation of "<" is
+ propagated.
+
+149.a/2
+ Ramification: Unlike array sorts, we do require stable sorts
+ here. That's because algorithms in the merge sort family (as
+ described by Knuth) can be both fast and stable. Such sorts
+ use the extra memory as offered by the links to provide better
+ performance.
+
+149.b/2
+ Note that list sorts never copy elements; it is the nodes, not
+ the elements, that are reordered.
+
+150/2
+ procedure Merge (Target : in out List;
+ Source : in out List);
+
+151/3
+ {AI95-00302-03AI95-00302-03} {AI05-0021-1AI05-0021-1} If
+ Source is empty, then Merge does nothing. If Source and
+ Target are the same nonempty container object, then
+ Program_Error is propagated. Otherwise, Merge removes
+ elements from Source and inserts them into Target; afterwards,
+ Target contains the union of the elements that were initially
+ in Source and Target; Source is left empty. If Target and
+ Source are initially sorted smallest first, then Target is
+ ordered smallest first as determined by the generic formal "<"
+ operator; otherwise, the order of elements in Target is
+ unspecified. Any exception raised during evaluation of "<" is
+ propagated.
+
+151.a/2
+ Ramification: It is a bounded error if either of the lists is
+ unsorted, see below. The bounded error can be recovered by
+ sorting Target after the merge call, or the lists can be
+ pretested with Is_Sorted.
+
+ _Bounded (Run-Time) Errors_
+
+152/2
+{AI95-00302-03AI95-00302-03} Calling Merge in an instance of
+Generic_Sorting with either Source or Target not ordered smallest first
+using the provided generic formal "<" operator is a bounded error.
+Either Program_Error is raised after Target is updated as described for
+Merge, or the operation works as defined.
+
+152.1/3
+{AI05-0022-1AI05-0022-1} {AI05-0248-1AI05-0248-1} It is a bounded error
+for the actual function associated with a generic formal subprogram,
+when called as part of an operation of this package, to tamper with
+elements of any List parameter of the operation. Either Program_Error
+is raised, or the operation works as defined on the value of the List
+either prior to, or subsequent to, some or all of the modifications to
+the List.
+
+152.2/3
+{AI05-0027-1AI05-0027-1} It is a bounded error to call any subprogram
+declared in the visible part of Containers.Doubly_Linked_Lists when the
+associated container has been finalized. If the operation takes
+Container as an in out parameter, then it raises Constraint_Error or
+Program_Error. Otherwise, the operation either proceeds as it would for
+an empty container, or it raises Constraint_Error or Program_Error.
+
+ _Erroneous Execution_
+
+153/2
+{AI95-00302-03AI95-00302-03} A Cursor value is invalid if any of the
+following have occurred since it was created:
+
+154/2
+ * The list that contains the element it designates has been
+ finalized;
+
+154.1/3
+ * {AI05-0160-1AI05-0160-1} The list that contains the element it
+ designates has been used as the Target of a call to Assign, or as
+ the target of an assignment_statement;
+
+155/2
+ * [The list that contains the element it designates has been used as
+ the Source or Target of a call to Move;] or
+
+155.a/3
+ Proof: {AI05-0001-1AI05-0001-1} Move has been reworded in
+ terms of Assign and Clear, which are covered by other bullets,
+ so this text is redundant.
+
+156/3
+ * {AI05-0160-1AI05-0160-1} {AI05-0262-1AI05-0262-1} The element it
+ designates has been removed from the list that previously contained
+ the element.
+
+156.a/3
+ To be honest: {AI05-0160-1AI05-0160-1} The cursor modified by
+ the four parameter Splice is not invalid, even though the
+ element it designates has been removed from the source list,
+ because that cursor has been modified to designate that
+ element in the target list - the cursor no longer designates
+ an element in the source list.
+
+156.b/3
+ Ramification: {AI05-0160-1AI05-0160-1} This can happen
+ directly via calls to Delete, Delete_Last, Clear, Splice with
+ a Source parameter, and Merge; and indirectly via calls to
+ Delete_First, Assign, and Move.
+
+157/2
+{AI95-00302-03AI95-00302-03} The result of "=" or Has_Element is
+unspecified if it is called with an invalid cursor parameter. Execution
+is erroneous if any other subprogram declared in
+Containers.Doubly_Linked_Lists is called with an invalid cursor
+parameter.
+
+157.a/2
+ Discussion: The list above is intended to be exhaustive. In
+ other cases, a cursor value continues to designate its
+ original element. For instance, cursor values survive the
+ insertion and deletion of other nodes.
+
+157.b/2
+ While it is possible to check for these cases, in many cases
+ the overhead necessary to make the check is substantial in
+ time or space. Implementations are encouraged to check for as
+ many of these cases as possible and raise Program_Error if
+ detected.
+
+157.1/3
+{AI05-0212-1AI05-0212-1} Execution is erroneous if the list associated
+with the result of a call to Reference or Constant_Reference is
+finalized before the result object returned by the call to Reference or
+Constant_Reference is finalized.
+
+157.c/3
+ Reason: Each object of Reference_Type and
+ Constant_Reference_Type probably contains some reference to
+ the originating container. If that container is prematurely
+ finalized (which is only possible via Unchecked_Deallocation,
+ as accessibility checks prevent passing a container to
+ Reference that will not live as long as the result), the
+ finalization of the object of Reference_Type will try to
+ access a nonexistent object. This is a normal case of a
+ dangling pointer created by Unchecked_Deallocation; we have to
+ explicitly mention it here as the pointer in question is not
+ visible in the specification of the type. (This is the same
+ reason we have to say this for invalid cursors.)
+
+ _Implementation Requirements_
+
+158/2
+{AI95-00302-03AI95-00302-03} No storage associated with a doubly-linked
+List object shall be lost upon assignment or scope exit.
+
+159/3
+{AI95-00302-03AI95-00302-03} {AI05-0262-1AI05-0262-1} The execution of
+an assignment_statement for a list shall have the effect of copying the
+elements from the source list object to the target list object and
+changing the length of the target object to that of the source object.
+
+159.a/3
+ Implementation Note: {AI05-0298-1AI05-0298-1} An assignment of
+ a List is a "deep" copy; that is the elements are copied as
+ well as the data structures. We say "effect of" in order to
+ allow the implementation to avoid copying elements immediately
+ if it wishes. For instance, an implementation that avoided
+ copying until one of the containers is modified would be
+ allowed. (Note that this implementation would require care,
+ see *note A.18.2:: for more.)
+
+ _Implementation Advice_
+
+160/2
+{AI95-00302-03AI95-00302-03} Containers.Doubly_Linked_Lists should be
+implemented similarly to a linked list. In particular, if N is the
+length of a list, then the worst-case time complexity of Element, Insert
+with Count=1, and Delete with Count=1 should be O(log N).
+
+160.a/2
+ Implementation Advice: The worst-case time complexity of
+ Element, Insert with Count=1, and Delete with Count=1 for
+ Containers.Doubly_Linked_Lists should be O(log N).
+
+160.b/2
+ Reason: We do not mean to overly constrain implementation
+ strategies here. However, it is important for portability
+ that the performance of large containers has roughly the same
+ factors on different implementations. If a program is moved
+ to an implementation that takes O(N) time to access elements,
+ that program could be unusable when the lists are large. We
+ allow O(log N) access because the proportionality constant and
+ caching effects are likely to be larger than the log factor,
+ and we don't want to discourage innovative implementations.
+
+161/2
+{AI95-00302-03AI95-00302-03} The worst-case time complexity of a call on
+procedure Sort of an instance of
+Containers.Doubly_Linked_Lists.Generic_Sorting should be O(N**2), and
+the average time complexity should be better than O(N**2).
+
+161.a/2
+ Implementation Advice: A call on procedure Sort of an instance
+ of Containers.Doubly_Linked_Lists.Generic_Sorting should have
+ an average time complexity better than O(N**2) and worst case
+ no worse than O(N**2).
+
+161.b/2
+ Ramification: In other words, we're requiring the use of a
+ better than O(N**2) sorting algorithm, such as Quicksort. No
+ bubble sorts allowed!
+
+162/2
+{AI95-00302-03AI95-00302-03} Move should not copy elements, and should
+minimize copying of internal data structures.
+
+162.a/2
+ Implementation Advice: Containers.Doubly_Linked_Lists.Move
+ should not copy elements, and should minimize copying of
+ internal data structures.
+
+162.b/2
+ Implementation Note: Usually that can be accomplished simply
+ by moving the pointer(s) to the internal data structures from
+ the Source container to the Target container.
+
+163/2
+{AI95-00302-03AI95-00302-03} If an exception is propagated from a list
+operation, no storage should be lost, nor any elements removed from a
+list unless specified by the operation.
+
+163.a/2
+ Implementation Advice: If an exception is propagated from a
+ list operation, no storage should be lost, nor any elements
+ removed from a list unless specified by the operation.
+
+163.b/2
+ Reason: This is important so that programs can recover from
+ errors. But we don't want to require heroic efforts, so we
+ just require documentation of cases where this can't be
+ accomplished.
+
+ NOTES
+
+164/2
+ 50 {AI95-00302-03AI95-00302-03} Sorting a list never copies
+ elements, and is a stable sort (equal elements remain in the
+ original order). This is different than sorting an array or
+ vector, which may need to copy elements, and is probably not a
+ stable sort.
+
+ _Extensions to Ada 95_
+
+164.a/2
+ {AI95-00302-03AI95-00302-03} The generic package
+ Containers.Doubly_Linked_Lists is new.
+
+ _Inconsistencies With Ada 2005_
+
+164.b/3
+ {AI05-0248-1AI05-0248-1} {AI05-0257-1AI05-0257-1} Correction:
+ The Insert versions that return a Position parameter are now
+ defined to return Position = Before if Count = 0. This was
+ unspecified for Ada 2005; so this will only be inconsistent if
+ an implementation did something else and a program depended on
+ that something else -- this should be very rare.
+
+ _Incompatibilities With Ada 2005_
+
+164.c/3
+ {AI05-0001-1AI05-0001-1} Subprograms Assign and Copy are added
+ to Containers.Doubly_Linked_Lists. If an instance of
+ Containers.Doubly_Linked_Lists is referenced in a use_clause,
+ and an entity E with the same defining_identifier as a new
+ entity in Containers.Doubly_Linked_Lists is defined in a
+ package that is also referenced in a use_clause, the entity E
+ may no longer be use-visible, resulting in errors. This
+ should be rare and is easily fixed if it does occur.
+
+ _Extensions to Ada 2005_
+
+164.d/3
+ {AI05-0212-1AI05-0212-1} Added iterator, reference, and
+ indexing support to make list containers more convenient to
+ use.
+
+ _Wording Changes from Ada 2005_
+
+164.e/3
+ {AI05-0001-1AI05-0001-1} Generalized the definition of Move.
+ Specified which elements are read/written by stream
+ attributes.
+
+164.f/3
+ {AI05-0022-1AI05-0022-1} Correction: Added a Bounded
+ (Run-Time) Error to cover tampering by generic actual
+ subprograms.
+
+164.g/3
+ {AI05-0027-1AI05-0027-1} Correction: Added a Bounded
+ (Run-Time) Error to cover access to finalized list containers.
+
+164.h/3
+ {AI05-0044-1AI05-0044-1} Correction: Redefined "<" actuals to
+ require a strict weak ordering; the old definition allowed
+ indeterminant comparisons that would not have worked in a
+ container.
+
+164.i/3
+ {AI05-0084-1AI05-0084-1} Correction: Added a pragma
+ Remote_Types so that containers can be used in distributed
+ programs.
+
+164.j/3
+ {AI05-0160-1AI05-0160-1} Correction: Revised the definition of
+ invalid cursors to cover missing (and new) cases.
+
+164.k/3
+ {AI05-0257-1AI05-0257-1} Correction: Added missing wording to
+ describe the Position after Inserting 0 elements.
+
+164.l/3
+ {AI05-0265-1AI05-0265-1} Correction: Defined when a container
+ prohibits tampering in order to more clearly define where the
+ check is made and the exception raised.
+
+\1f
+File: aarm2012.info, Node: A.18.4, Next: A.18.5, Prev: A.18.3, Up: A.18
+
+A.18.4 Maps
+-----------
+
+1/2
+{AI95-00302-03AI95-00302-03} The language-defined generic packages
+Containers.Hashed_Maps and Containers.Ordered_Maps provide private types
+Map and Cursor, and a set of operations for each type. A map container
+allows an arbitrary type to be used as a key to find the element
+associated with that key. A hashed map uses a hash function to organize
+the keys, while an ordered map orders the keys per a specified relation.
+
+2/3
+{AI95-00302-03AI95-00302-03} {AI05-0299-1AI05-0299-1} This subclause
+describes the declarations that are common to both kinds of maps. See
+*note A.18.5:: for a description of the semantics specific to
+Containers.Hashed_Maps and *note A.18.6:: for a description of the
+semantics specific to Containers.Ordered_Maps.
+
+ _Static Semantics_
+
+3/2
+{AI95-00302-03AI95-00302-03} The actual function for the generic formal
+function "=" on Element_Type values is expected to define a reflexive
+and symmetric relationship and return the same result value each time it
+is called with a particular pair of values. If it behaves in some other
+manner, the function "=" on map values returns an unspecified value.
+The exact arguments and number of calls of this generic formal function
+by the function "=" on map values are unspecified.
+
+3.a/2
+ Ramification: If the actual function for "=" is not symmetric
+ and consistent, the result returned by "=" for Map objects
+ cannot be predicted. The implementation is not required to
+ protect against "=" raising an exception, or returning random
+ results, or any other "bad" behavior. And it can call "=" in
+ whatever manner makes sense. But note that only the result of
+ "=" for Map objects is unspecified; other subprograms are not
+ allowed to break if "=" is bad (they aren't expected to use
+ "=").
+
+4/2
+{AI95-00302-03AI95-00302-03} The type Map is used to represent maps.
+The type Map needs finalization (see *note 7.6::).
+
+5/2
+{AI95-00302-03AI95-00302-03} A map contains pairs of keys and elements,
+called nodes. Map cursors designate nodes, but also can be thought of
+as designating an element (the element contained in the node) for
+consistency with the other containers. There exists an equivalence
+relation on keys, whose definition is different for hashed maps and
+ordered maps. A map never contains two or more nodes with equivalent
+keys. The length of a map is the number of nodes it contains.
+
+6/2
+{AI95-00302-03AI95-00302-03} Each nonempty map has two particular nodes
+called the first node and the last node (which may be the same). Each
+node except for the last node has a successor node. If there are no
+other intervening operations, starting with the first node and
+repeatedly going to the successor node will visit each node in the map
+exactly once until the last node is reached. The exact definition of
+these terms is different for hashed maps and ordered maps.
+
+7/2
+{AI95-00302-03AI95-00302-03} [Some operations of these generic packages
+have access-to-subprogram parameters. To ensure such operations are
+well-defined, they guard against certain actions by the designated
+subprogram. In particular, some operations check for "tampering with
+cursors" of a container because they depend on the set of elements of
+the container remaining constant, and others check for "tampering with
+elements" of a container because they depend on elements of the
+container not being replaced.]
+
+8/2
+{AI95-00302-03AI95-00302-03} A subprogram is said to tamper with cursors
+of a map object M if:
+
+9/2
+ * it inserts or deletes elements of M, that is, it calls the Insert,
+ Include, Clear, Delete, or Exclude procedures with M as a
+ parameter; or
+
+9.a/2
+ To be honest: Operations which are defined to be equivalent to
+ a call on one of these operations also are included.
+ Similarly, operations which call one of these as part of their
+ definition are included.
+
+10/2
+ * it finalizes M; or
+
+10.1/3
+ * {AI05-0001-1AI05-0001-1} it calls the Assign procedure with M as
+ the Target parameter; or
+
+10.a/3
+ Ramification: We don't need to explicitly mention
+ assignment_statement, because that finalizes the target object
+ as part of the operation, and finalization of an object is
+ already defined as tampering with cursors.
+
+11/2
+ * it calls the Move procedure with M as a parameter; or
+
+12/2
+ * it calls one of the operations defined to tamper with the cursors
+ of M.
+
+12.a/2
+ Ramification: Replace only modifies a key and element rather
+ than rehashing, so it does not tamper with cursors.
+
+13/2
+{AI95-00302-03AI95-00302-03} A subprogram is said to tamper with
+elements of a map object M if:
+
+14/2
+ * it tampers with cursors of M; or
+
+15/2
+ * it replaces one or more elements of M, that is, it calls the
+ Replace or Replace_Element procedures with M as a parameter.
+
+15.a/2
+ Reason: Complete replacement of an element can cause its
+ memory to be deallocated while another operation is holding
+ onto a reference to it. That can't be allowed. However, a
+ simple modification of (part of) an element is not a problem,
+ so Update_Element does not cause a problem.
+
+15.1/3
+{AI05-0265-1AI05-0265-1} When tampering with cursors is prohibited for a
+particular map object M, Program_Error is propagated by a call of any
+language-defined subprogram that is defined to tamper with the cursors
+of M, leaving M unmodified. Similarly, when tampering with elements is
+prohibited for a particular map object M, Program_Error is propagated by
+a call of any language-defined subprogram that is defined to tamper with
+the elements of M [(or tamper with the cursors of M)], leaving M
+unmodified.
+
+15.b/3
+ Proof: Tampering with elements includes tampering with
+ cursors, so we mention it only from completeness in the second
+ sentence.
+
+16/2
+{AI95-00302-03AI95-00302-03} Empty_Map represents the empty Map object.
+It has a length of 0. If an object of type Map is not otherwise
+initialized, it is initialized to the same value as Empty_Map.
+
+17/2
+{AI95-00302-03AI95-00302-03} No_Element represents a cursor that
+designates no node. If an object of type Cursor is not otherwise
+initialized, it is initialized to the same value as No_Element.
+
+18/2
+{AI95-00302-03AI95-00302-03} The predefined "=" operator for type Cursor
+returns True if both cursors are No_Element, or designate the same
+element in the same container.
+
+19/2
+{AI95-00302-03AI95-00302-03} Execution of the default implementation of
+the Input, Output, Read, or Write attribute of type Cursor raises
+Program_Error.
+
+19.a/2
+ Reason: A cursor will probably be implemented in terms of one
+ or more access values, and the effects of streaming access
+ values is unspecified. Rather than letting the user stream
+ junk by accident, we mandate that streaming of cursors raise
+ Program_Error by default. The attributes can always be
+ specified if there is a need to support streaming.
+
+19.1/3
+{AI05-0001-1AI05-0001-1} {AI05-0262-1AI05-0262-1} Map'Write for a Map
+object M writes Length(M) elements of the map to the stream. It also
+may write additional information about the map.
+
+19.2/3
+{AI05-0001-1AI05-0001-1} {AI05-0262-1AI05-0262-1} Map'Read reads the
+representation of a map from the stream, and assigns to Item a map with
+the same length and elements as was written by Map'Write.
+
+19.b/3
+ Ramification: Streaming more elements than the container
+ length is wrong. For implementation implications of this
+ rule, see the Implementation Note in *note A.18.2::.
+
+19.3/3
+ function Has_Element (Position : Cursor) return Boolean;
+
+19.4/3
+ {AI05-0212-1AI05-0212-1} Returns True if Position designates
+ an element, and returns False otherwise.
+
+19.c/3
+ To be honest: {AI05-0005-1AI05-0005-1}
+ {AI05-0212-1AI05-0212-1} This function might not detect
+ cursors that designate deleted elements; such cursors are
+ invalid (see below) and the result of calling Has_Element with
+ an invalid cursor is unspecified (but not erroneous).
+
+20/2
+ function "=" (Left, Right : Map) return Boolean;
+
+21/2
+ {AI95-00302-03AI95-00302-03} If Left and Right denote the same
+ map object, then the function returns True. If Left and Right
+ have different lengths, then the function returns False.
+ Otherwise, for each key K in Left, the function returns False
+ if:
+
+22/2
+ * a key equivalent to K is not present in Right; or
+
+23/2
+ * the element associated with K in Left is not equal to the
+ element associated with K in Right (using the generic
+ formal equality operator for elements).
+
+24/2
+ If the function has not returned a result after checking all
+ of the keys, it returns True. Any exception raised during
+ evaluation of key equivalence or element equality is
+ propagated.
+
+24.a/2
+ Implementation Note: This wording describes the canonical
+ semantics. However, the order and number of calls on the
+ formal equality function is unspecified for all of the
+ operations that use it in this package, so an implementation
+ can call it as many or as few times as it needs to get the
+ correct answer. Specifically, there is no requirement to call
+ the formal equality additional times once the answer has been
+ determined.
+
+25/2
+ function Length (Container : Map) return Count_Type;
+
+26/2
+ {AI95-00302-03AI95-00302-03} Returns the number of nodes in
+ Container.
+
+27/2
+ function Is_Empty (Container : Map) return Boolean;
+
+28/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Length (Container)
+ = 0.
+
+29/2
+ procedure Clear (Container : in out Map);
+
+30/2
+ {AI95-00302-03AI95-00302-03} Removes all the nodes from
+ Container.
+
+31/2
+ function Key (Position : Cursor) return Key_Type;
+
+32/2
+ {AI95-00302-03AI95-00302-03} If Position equals No_Element,
+ then Constraint_Error is propagated. Otherwise, Key returns
+ the key component of the node designated by Position.
+
+33/2
+ function Element (Position : Cursor) return Element_Type;
+
+34/2
+ {AI95-00302-03AI95-00302-03} If Position equals No_Element,
+ then Constraint_Error is propagated. Otherwise, Element
+ returns the element component of the node designated by
+ Position.
+
+35/2
+ procedure Replace_Element (Container : in out Map;
+ Position : in Cursor;
+ New_Item : in Element_Type);
+
+36/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Position equals No_Element, then Constraint_Error is
+ propagated; if Position does not designate an element in
+ Container, then Program_Error is propagated. Otherwise,
+ Replace_Element assigns New_Item to the element of the node
+ designated by Position.
+
+37/2
+ procedure Query_Element
+ (Position : in Cursor;
+ Process : not null access procedure (Key : in Key_Type;
+ Element : in Element_Type));
+
+38/3
+ {AI95-00302-03AI95-00302-03} {AI05-0021-1AI05-0021-1}
+ {AI05-0265-1AI05-0265-1} If Position equals No_Element, then
+ Constraint_Error is propagated. Otherwise, Query_Element
+ calls Process.all with the key and element from the node
+ designated by Position as the arguments. Tampering with the
+ elements of the map that contains the element designated by
+ Position is prohibited during the execution of the call on
+ Process.all. Any exception raised by Process.all is
+ propagated.
+
+39/2
+ procedure Update_Element
+ (Container : in out Map;
+ Position : in Cursor;
+ Process : not null access procedure (Key : in Key_Type;
+ Element : in out Element_Type));
+
+40/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1}
+ {AI05-0265-1AI05-0265-1} If Position equals No_Element, then
+ Constraint_Error is propagated; if Position does not designate
+ an element in Container, then Program_Error is propagated.
+ Otherwise, Update_Element calls Process.all with the key and
+ element from the node designated by Position as the arguments.
+ Tampering with the elements of Container is prohibited during
+ the execution of the call on Process.all. Any exception
+ raised by Process.all is propagated.
+
+41/2
+ If Element_Type is unconstrained and definite, then the actual
+ Element parameter of Process.all shall be unconstrained.
+
+41.a/2
+ Ramification: This means that the elements cannot be directly
+ allocated from the heap; it must be possible to change the
+ discriminants of the element in place.
+
+41.1/3
+ type Constant_Reference_Type
+ (Element : not null access constant Element_Type) is private
+ with Implicit_Dereference => Element;
+
+41.2/3
+ type Reference_Type (Element : not null access Element_Type) is private
+ with Implicit_Dereference => Element;
+
+41.3/3
+ {AI05-0212-1AI05-0212-1} The types Constant_Reference_Type and
+ Reference_Type need finalization.
+
+41.4/3
+ The default initialization of an object of type
+ Constant_Reference_Type or Reference_Type propagates
+ Program_Error.
+
+41.b/3
+ Reason: It is expected that Reference_Type (and
+ Constant_Reference_Type) will be a controlled type, for which
+ finalization will have some action to terminate the tampering
+ check for the associated container. If the object is created
+ by default, however, there is no associated container. Since
+ this is useless, and supporting this case would take extra
+ work, we define it to raise an exception.
+
+41.5/3
+ function Constant_Reference (Container : aliased in Map;
+ Position : in Cursor)
+ return Constant_Reference_Type;
+
+41.6/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Constant_Indexing and
+ Implicit_Dereference aspects) provides a convenient way to
+ gain read access to an individual element of a map given a
+ cursor.
+
+41.7/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1} If Position
+ equals No_Element, then Constraint_Error is propagated; if
+ Position does not designate an element in Container, then
+ Program_Error is propagated. Otherwise, Constant_Reference
+ returns an object whose discriminant is an access value that
+ designates the element designated by Position. Tampering with
+ the elements of Container is prohibited while the object
+ returned by Constant_Reference exists and has not been
+ finalized.
+
+41.8/3
+ function Reference (Container : aliased in out Map;
+ Position : in Cursor)
+ return Reference_Type;
+
+41.9/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Variable_Indexing and
+ Implicit_Dereference aspects) provides a convenient way to
+ gain read and write access to an individual element of a map
+ given a cursor.
+
+41.10/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1} If Position
+ equals No_Element, then Constraint_Error is propagated; if
+ Position does not designate an element in Container, then
+ Program_Error is propagated. Otherwise, Reference returns an
+ object whose discriminant is an access value that designates
+ the element designated by Position. Tampering with the
+ elements of Container is prohibited while the object returned
+ by Reference exists and has not been finalized.
+
+41.11/3
+ function Constant_Reference (Container : aliased in Map;
+ Key : in Key_Type)
+ return Constant_Reference_Type;
+
+41.12/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Constant_Indexing and
+ Implicit_Dereference aspects) provides a convenient way to
+ gain read access to an individual element of a map given a key
+ value.
+
+41.13/3
+ Equivalent to Constant_Reference (Container, Find (Container,
+ Key)).
+
+41.14/3
+ function Reference (Container : aliased in out Map;
+ Key : in Key_Type)
+ return Reference_Type;
+
+41.15/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Variable_Indexing and
+ Implicit_Dereference aspects) provides a convenient way to
+ gain read and write access to an individual element of a map
+ given a key value.
+
+41.16/3
+ Equivalent to Reference (Container, Find (Container, Key)).
+
+41.17/3
+ procedure Assign (Target : in out Map; Source : in Map);
+
+41.18/3
+ {AI05-0001-1AI05-0001-1} {AI05-0248-1AI05-0248-1} If Target
+ denotes the same object as Source, the operation has no
+ effect. Otherwise, the key/element pairs of Source are copied
+ to Target as for an assignment_statement assigning Source to
+ Target.
+
+41.c/3
+ Discussion: {AI05-0005-1AI05-0005-1} This routine exists for
+ compatibility with the bounded map containers. For an
+ unbounded map, Assign(A, B) and A := B behave identically.
+ For a bounded map, := will raise an exception if the container
+ capacities are different, while Assign will not raise an
+ exception if there is enough room in the target.
+
+42/2
+ procedure Move (Target : in out Map;
+ Source : in out Map);
+
+43/3
+ {AI95-00302-03AI95-00302-03} {AI05-0001-1AI05-0001-1}
+ {AI05-0248-1AI05-0248-1} {AI05-0262-1AI05-0262-1} If Target
+ denotes the same object as Source, then the operation has no
+ effect. Otherwise, the operation is equivalent to Assign
+ (Target, Source) followed by Clear (Source).
+
+44/2
+ procedure Insert (Container : in out Map;
+ Key : in Key_Type;
+ New_Item : in Element_Type;
+ Position : out Cursor;
+ Inserted : out Boolean);
+
+45/2
+ {AI95-00302-03AI95-00302-03} Insert checks if a node with a
+ key equivalent to Key is already present in Container. If a
+ match is found, Inserted is set to False and Position
+ designates the element with the matching key. Otherwise,
+ Insert allocates a new node, initializes it to Key and
+ New_Item, and adds it to Container; Inserted is set to True
+ and Position designates the newly-inserted node. Any
+ exception raised during allocation is propagated and Container
+ is not modified.
+
+46/2
+ procedure Insert (Container : in out Map;
+ Key : in Key_Type;
+ Position : out Cursor;
+ Inserted : out Boolean);
+
+47/2
+ {AI95-00302-03AI95-00302-03} Insert inserts Key into Container
+ as per the five-parameter Insert, with the difference that an
+ element initialized by default (see *note 3.3.1::) is
+ inserted.
+
+48/2
+ procedure Insert (Container : in out Map;
+ Key : in Key_Type;
+ New_Item : in Element_Type);
+
+49/2
+ {AI95-00302-03AI95-00302-03} Insert inserts Key and New_Item
+ into Container as per the five-parameter Insert, with the
+ difference that if a node with a key equivalent to Key is
+ already in the map, then Constraint_Error is propagated.
+
+49.a/2
+ Ramification: This is equivalent to:
+
+49.b/2
+ declare
+ Inserted : Boolean; C : Cursor;
+ begin
+ Insert (Container, Key, New_Item, C, Inserted);
+ if not Inserted then
+ raise Constraint_Error;
+ end if;
+ end;
+
+49.c/2
+ but doesn't require the hassle of out parameters.
+
+50/2
+ procedure Include (Container : in out Map;
+ Key : in Key_Type;
+ New_Item : in Element_Type);
+
+51/2
+ {AI95-00302-03AI95-00302-03} Include inserts Key and New_Item
+ into Container as per the five-parameter Insert, with the
+ difference that if a node with a key equivalent to Key is
+ already in the map, then this operation assigns Key and
+ New_Item to the matching node. Any exception raised during
+ assignment is propagated.
+
+51.a/2
+ Ramification: This is equivalent to:
+
+51.b/2
+ declare
+ C : Cursor := Find (Container, Key);
+ begin
+ if C = No_Element then
+ Insert (Container, Key, New_Item);
+ else
+ Replace (Container, Key, New_Item);
+ end if;
+ end;
+
+51.c/2
+ but this avoids doing the search twice.
+
+52/2
+ procedure Replace (Container : in out Map;
+ Key : in Key_Type;
+ New_Item : in Element_Type);
+
+53/2
+ {AI95-00302-03AI95-00302-03} Replace checks if a node with a
+ key equivalent to Key is present in Container. If a match is
+ found, Replace assigns Key and New_Item to the matching node;
+ otherwise, Constraint_Error is propagated.
+
+53.a/2
+ Discussion: We update the key as well as the element, as the
+ key might include additional information that does not
+ participate in equivalence. If only the element needs to be
+ updated, use Replace_Element (Find (Container, Key),
+ New_Element).
+
+54/2
+ procedure Exclude (Container : in out Map;
+ Key : in Key_Type);
+
+55/2
+ {AI95-00302-03AI95-00302-03} Exclude checks if a node with a
+ key equivalent to Key is present in Container. If a match is
+ found, Exclude removes the node from the map.
+
+55.a/2
+ Ramification: Exclude should work on an empty map; nothing
+ happens in that case.
+
+56/2
+ procedure Delete (Container : in out Map;
+ Key : in Key_Type);
+
+57/2
+ {AI95-00302-03AI95-00302-03} Delete checks if a node with a
+ key equivalent to Key is present in Container. If a match is
+ found, Delete removes the node from the map; otherwise,
+ Constraint_Error is propagated.
+
+58/2
+ procedure Delete (Container : in out Map;
+ Position : in out Cursor);
+
+59/2
+ {AI95-00302-03AI95-00302-03} If Position equals No_Element,
+ then Constraint_Error is propagated. If Position does not
+ designate an element in Container, then Program_Error is
+ propagated. Otherwise, Delete removes the node designated by
+ Position from the map. Position is set to No_Element on
+ return.
+
+59.a/2
+ Ramification: The check on Position checks that the cursor
+ does not belong to some other map. This check implies that a
+ reference to the map is included in the cursor value. This
+ wording is not meant to require detection of dangling cursors;
+ such cursors are defined to be invalid, which means that
+ execution is erroneous, and any result is allowed (including
+ not raising an exception).
+
+60/2
+ function First (Container : Map) return Cursor;
+
+61/2
+ {AI95-00302-03AI95-00302-03} If Length (Container) = 0, then
+ First returns No_Element. Otherwise, First returns a cursor
+ that designates the first node in Container.
+
+62/2
+ function Next (Position : Cursor) return Cursor;
+
+63/2
+ {AI95-00302-03AI95-00302-03} Returns a cursor that designates
+ the successor of the node designated by Position. If Position
+ designates the last node, then No_Element is returned. If
+ Position equals No_Element, then No_Element is returned.
+
+64/2
+ procedure Next (Position : in out Cursor);
+
+65/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Position := Next
+ (Position).
+
+66/2
+ function Find (Container : Map;
+ Key : Key_Type) return Cursor;
+
+67/2
+ {AI95-00302-03AI95-00302-03} If Length (Container) equals 0,
+ then Find returns No_Element. Otherwise, Find checks if a
+ node with a key equivalent to Key is present in Container. If
+ a match is found, a cursor designating the matching node is
+ returned; otherwise, No_Element is returned.
+
+68/2
+ function Element (Container : Map;
+ Key : Key_Type) return Element_Type;
+
+69/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Element (Find
+ (Container, Key)).
+
+70/2
+ function Contains (Container : Map;
+ Key : Key_Type) return Boolean;
+
+71/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Find (Container,
+ Key) /= No_Element.
+
+ Paragraphs 72 and 73 were moved above.
+
+74/2
+ procedure Iterate
+ (Container : in Map;
+ Process : not null access procedure (Position : in Cursor));
+
+75/3
+ {AI95-00302-03AI95-00302-03} {AI05-0265-1AI05-0265-1} Iterate
+ calls Process.all with a cursor that designates each node in
+ Container, starting with the first node and moving the cursor
+ according to the successor relation. Tampering with the
+ cursors of Container is prohibited during the execution of a
+ call on Process.all. Any exception raised by Process.all is
+ propagated.
+
+75.a/2
+ Implementation Note: The "tamper with cursors" check takes
+ place when the operations that insert or delete elements, and
+ so on, are called.
+
+75.b/2
+ See Iterate for vectors (*note A.18.2::) for a suggested
+ implementation of the check.
+
+ _Bounded (Run-Time) Errors_
+
+75.1/3
+{AI05-0022-1AI05-0022-1} {AI05-0248-1AI05-0248-1} It is a bounded error
+for the actual function associated with a generic formal subprogram,
+when called as part of an operation of a map package, to tamper with
+elements of any map parameter of the operation. Either Program_Error is
+raised, or the operation works as defined on the value of the map either
+prior to, or subsequent to, some or all of the modifications to the map.
+
+75.2/3
+{AI05-0027-1AI05-0027-1} It is a bounded error to call any subprogram
+declared in the visible part of a map package when the associated
+container has been finalized. If the operation takes Container as an in
+out parameter, then it raises Constraint_Error or Program_Error.
+Otherwise, the operation either proceeds as it would for an empty
+container, or it raises Constraint_Error or Program_Error.
+
+ _Erroneous Execution_
+
+76/2
+{AI95-00302-03AI95-00302-03} A Cursor value is invalid if any of the
+following have occurred since it was created:
+
+77/2
+ * The map that contains the node it designates has been finalized;
+
+77.1/3
+ * {AI05-0160-1AI05-0160-1} The map that contains the node it
+ designates has been used as the Target of a call to Assign, or as
+ the target of an assignment_statement;
+
+78/2
+ * The map that contains the node it designates has been used as the
+ Source or Target of a call to Move; or
+
+79/3
+ * {AI05-0160-1AI05-0160-1} {AI05-0262-1AI05-0262-1} The node it
+ designates has been removed from the map that previously contained
+ the node.
+
+79.a/3
+ Ramification: {AI05-0160-1AI05-0160-1} This can happen
+ directly via calls to Clear, Exclude, and Delete.
+
+80/2
+The result of "=" or Has_Element is unspecified if these functions are
+called with an invalid cursor parameter. Execution is erroneous if any
+other subprogram declared in Containers.Hashed_Maps or
+Containers.Ordered_Maps is called with an invalid cursor parameter.
+
+80.a/2
+ Discussion: The list above is intended to be exhaustive. In
+ other cases, a cursor value continues to designate its
+ original element. For instance, cursor values survive the
+ insertion and deletion of other nodes.
+
+80.b/2
+ While it is possible to check for these cases, in many cases
+ the overhead necessary to make the check is substantial in
+ time or space. Implementations are encouraged to check for as
+ many of these cases as possible and raise Program_Error if
+ detected.
+
+80.1/3
+{AI05-0212-1AI05-0212-1} Execution is erroneous if the map associated
+with the result of a call to Reference or Constant_Reference is
+finalized before the result object returned by the call to Reference or
+Constant_Reference is finalized.
+
+80.c/3
+ Reason: Each object of Reference_Type and
+ Constant_Reference_Type probably contains some reference to
+ the originating container. If that container is prematurely
+ finalized (which is only possible via Unchecked_Deallocation,
+ as accessibility checks prevent passing a container to
+ Reference that will not live as long as the result), the
+ finalization of the object of Reference_Type will try to
+ access a nonexistent object. This is a normal case of a
+ dangling pointer created by Unchecked_Deallocation; we have to
+ explicitly mention it here as the pointer in question is not
+ visible in the specification of the type. (This is the same
+ reason we have to say this for invalid cursors.)
+
+ _Implementation Requirements_
+
+81/2
+{AI95-00302-03AI95-00302-03} No storage associated with a Map object
+shall be lost upon assignment or scope exit.
+
+82/3
+{AI95-00302-03AI95-00302-03} {AI05-0262-1AI05-0262-1} The execution of
+an assignment_statement for a map shall have the effect of copying the
+elements from the source map object to the target map object and
+changing the length of the target object to that of the source object.
+
+82.a/3
+ Implementation Note: {AI05-0298-1AI05-0298-1} An assignment of
+ a Map is a "deep" copy; that is the elements are copied as
+ well as the data structures. We say "effect of" in order to
+ allow the implementation to avoid copying elements immediately
+ if it wishes. For instance, an implementation that avoided
+ copying until one of the containers is modified would be
+ allowed. (Note that this implementation would require care,
+ see *note A.18.2:: for more.)
+
+ _Implementation Advice_
+
+83/2
+{AI95-00302-03AI95-00302-03} Move should not copy elements, and should
+minimize copying of internal data structures.
+
+83.a/2
+ Implementation Advice: Move for a map should not copy
+ elements, and should minimize copying of internal data
+ structures.
+
+83.b/2
+ Implementation Note: Usually that can be accomplished simply
+ by moving the pointer(s) to the internal data structures from
+ the Source container to the Target container.
+
+84/2
+{AI95-00302-03AI95-00302-03} If an exception is propagated from a map
+operation, no storage should be lost, nor any elements removed from a
+map unless specified by the operation.
+
+84.a/2
+ Implementation Advice: If an exception is propagated from a
+ map operation, no storage should be lost, nor any elements
+ removed from a map unless specified by the operation.
+
+84.b/2
+ Reason: This is important so that programs can recover from
+ errors. But we don't want to require heroic efforts, so we
+ just require documentation of cases where this can't be
+ accomplished.
+
+ _Wording Changes from Ada 95_
+
+84.c/2
+ {AI95-00302-03AI95-00302-03} This description of maps is new;
+ the extensions are documented with the specific packages.
+
+ _Extensions to Ada 2005_
+
+84.d/3
+ {AI05-0212-1AI05-0212-1} Added reference support to make map
+ containers more convenient to use.
+
+ _Wording Changes from Ada 2005_
+
+84.e/3
+ {AI05-0001-1AI05-0001-1} Added procedure Assign; the extension
+ and incompatibility is documented with the specific packages.
+
+84.f/3
+ {AI05-0001-1AI05-0001-1} Generalized the definition of Move.
+ Specified which elements are read/written by stream
+ attributes.
+
+84.g/3
+ {AI05-0022-1AI05-0022-1} Correction: Added a Bounded
+ (Run-Time) Error to cover tampering by generic actual
+ subprograms.
+
+84.h/3
+ {AI05-0027-1AI05-0027-1} Correction: Added a Bounded
+ (Run-Time) Error to cover access to finalized map containers.
+
+84.i/3
+ {AI05-0160-1AI05-0160-1} Correction: Revised the definition of
+ invalid cursors to cover missing (and new) cases.
+
+84.j/3
+ {AI05-0265-1AI05-0265-1} Correction: Defined when a container
+ prohibits tampering in order to more clearly define where the
+ check is made and the exception raised.
+
+\1f
+File: aarm2012.info, Node: A.18.5, Next: A.18.6, Prev: A.18.4, Up: A.18
+
+A.18.5 The Generic Package Containers.Hashed_Maps
+-------------------------------------------------
+
+ _Static Semantics_
+
+1/2
+{AI95-00302-03AI95-00302-03} The generic library package
+Containers.Hashed_Maps has the following declaration:
+
+2/3
+ {AI05-0084-1AI05-0084-1} {AI05-0212-1AI05-0212-1} with Ada.Iterator_Interfaces;
+ generic
+ type Key_Type is private;
+ type Element_Type is private;
+ with function Hash (Key : Key_Type) return Hash_Type;
+ with function Equivalent_Keys (Left, Right : Key_Type)
+ return Boolean;
+ with function "=" (Left, Right : Element_Type)
+ return Boolean is <>;
+ package Ada.Containers.Hashed_Maps is
+ pragma Preelaborate(Hashed_Maps);
+ pragma Remote_Types(Hashed_Maps);
+
+3/3
+ {AI05-0212-1AI05-0212-1} type Map is tagged private
+ with Constant_Indexing => Constant_Reference,
+ Variable_Indexing => Reference,
+ Default_Iterator => Iterate,
+ Iterator_Element => Element_Type;
+ pragma Preelaborable_Initialization(Map);
+
+4/2
+ type Cursor is private;
+ pragma Preelaborable_Initialization(Cursor);
+
+5/2
+ Empty_Map : constant Map;
+
+6/2
+ No_Element : constant Cursor;
+
+6.1/3
+ {AI05-0212-1AI05-0212-1} function Has_Element (Position : Cursor) return Boolean;
+
+6.2/3
+ {AI05-0212-1AI05-0212-1} package Map_Iterator_Interfaces is new
+ Ada.Iterator_Interfaces (Cursor, Has_Element);
+
+7/2
+ function "=" (Left, Right : Map) return Boolean;
+
+8/2
+ function Capacity (Container : Map) return Count_Type;
+
+9/2
+ procedure Reserve_Capacity (Container : in out Map;
+ Capacity : in Count_Type);
+
+10/2
+ function Length (Container : Map) return Count_Type;
+
+11/2
+ function Is_Empty (Container : Map) return Boolean;
+
+12/2
+ procedure Clear (Container : in out Map);
+
+13/2
+ function Key (Position : Cursor) return Key_Type;
+
+14/2
+ function Element (Position : Cursor) return Element_Type;
+
+15/2
+ procedure Replace_Element (Container : in out Map;
+ Position : in Cursor;
+ New_Item : in Element_Type);
+
+16/2
+ procedure Query_Element
+ (Position : in Cursor;
+ Process : not null access procedure (Key : in Key_Type;
+ Element : in Element_Type));
+
+17/2
+ procedure Update_Element
+ (Container : in out Map;
+ Position : in Cursor;
+ Process : not null access procedure
+ (Key : in Key_Type;
+ Element : in out Element_Type));
+
+17.1/3
+ {AI05-0212-1AI05-0212-1} type Constant_Reference_Type
+ (Element : not null access constant Element_Type) is private
+ with Implicit_Dereference => Element;
+
+17.2/3
+ {AI05-0212-1AI05-0212-1} type Reference_Type (Element : not null access Element_Type) is private
+ with Implicit_Dereference => Element;
+
+17.3/3
+ {AI05-0212-1AI05-0212-1} function Constant_Reference (Container : aliased in Map;
+ Position : in Cursor)
+ return Constant_Reference_Type;
+
+17.4/3
+ {AI05-0212-1AI05-0212-1} function Reference (Container : aliased in out Map;
+ Position : in Cursor)
+ return Reference_Type;
+
+17.5/3
+ {AI05-0212-1AI05-0212-1} function Constant_Reference (Container : aliased in Map;
+ Key : in Key_Type)
+ return Constant_Reference_Type;
+
+17.6/3
+ {AI05-0212-1AI05-0212-1} function Reference (Container : aliased in out Map;
+ Key : in Key_Type)
+ return Reference_Type;
+
+17.7/3
+ {AI05-0001-1AI05-0001-1} procedure Assign (Target : in out Map; Source : in Map);
+
+17.8/3
+ {AI05-0001-1AI05-0001-1} function Copy (Source : Map; Capacity : Count_Type := 0) return Map;
+
+18/2
+ procedure Move (Target : in out Map;
+ Source : in out Map);
+
+19/2
+ procedure Insert (Container : in out Map;
+ Key : in Key_Type;
+ New_Item : in Element_Type;
+ Position : out Cursor;
+ Inserted : out Boolean);
+
+20/2
+ procedure Insert (Container : in out Map;
+ Key : in Key_Type;
+ Position : out Cursor;
+ Inserted : out Boolean);
+
+21/2
+ procedure Insert (Container : in out Map;
+ Key : in Key_Type;
+ New_Item : in Element_Type);
+
+22/2
+ procedure Include (Container : in out Map;
+ Key : in Key_Type;
+ New_Item : in Element_Type);
+
+23/2
+ procedure Replace (Container : in out Map;
+ Key : in Key_Type;
+ New_Item : in Element_Type);
+
+24/2
+ procedure Exclude (Container : in out Map;
+ Key : in Key_Type);
+
+25/2
+ procedure Delete (Container : in out Map;
+ Key : in Key_Type);
+
+26/2
+ procedure Delete (Container : in out Map;
+ Position : in out Cursor);
+
+27/2
+ function First (Container : Map)
+ return Cursor;
+
+28/2
+ function Next (Position : Cursor) return Cursor;
+
+29/2
+ procedure Next (Position : in out Cursor);
+
+30/2
+ function Find (Container : Map;
+ Key : Key_Type)
+ return Cursor;
+
+31/2
+ function Element (Container : Map;
+ Key : Key_Type)
+ return Element_Type;
+
+32/2
+ function Contains (Container : Map;
+ Key : Key_Type) return Boolean;
+
+33/3
+ This paragraph was deleted.{AI05-0212-1AI05-0212-1}
+
+34/2
+ function Equivalent_Keys (Left, Right : Cursor)
+ return Boolean;
+
+35/2
+ function Equivalent_Keys (Left : Cursor;
+ Right : Key_Type)
+ return Boolean;
+
+36/2
+ function Equivalent_Keys (Left : Key_Type;
+ Right : Cursor)
+ return Boolean;
+
+37/2
+ procedure Iterate
+ (Container : in Map;
+ Process : not null access procedure (Position : in Cursor));
+
+37.1/3
+ {AI05-0212-1AI05-0212-1} function Iterate (Container : in Map)
+ return Map_Iterator_Interfaces.Forward_Iterator'Class;
+
+38/2
+ private
+
+39/2
+ ... -- not specified by the language
+
+40/2
+ end Ada.Containers.Hashed_Maps;
+
+41/2
+{AI95-00302-03AI95-00302-03} An object of type Map contains an
+expandable hash table, which is used to provide direct access to nodes.
+The capacity of an object of type Map is the maximum number of nodes
+that can be inserted into the hash table prior to it being automatically
+expanded.
+
+41.a/2
+ Implementation Note: The expected implementation for a Map
+ uses a hash table which is grown when it is too small, with
+ linked lists hanging off of each bucket. Note that in that
+ implementation a cursor needs a back pointer to the Map object
+ to implement iteration; that could either be in the nodes, or
+ in the cursor object. To provide an average O(1) access time,
+ capacity would typically equal the number of buckets in such
+ an implementation, so that the average bucket linked list
+ length would be no more than 1.0.
+
+41.b/2
+ There is no defined relationship between elements in a hashed
+ map. Typically, iteration will return elements in the order
+ that they are hashed in.
+
+42/2
+{AI95-00302-03AI95-00302-03} Two keys K1 and K2 are defined to be
+equivalent if Equivalent_Keys (K1, K2) returns True.
+
+43/2
+{AI95-00302-03AI95-00302-03} The actual function for the generic formal
+function Hash is expected to return the same value each time it is
+called with a particular key value. For any two equivalent key values,
+the actual for Hash is expected to return the same value. If the actual
+for Hash behaves in some other manner, the behavior of this package is
+unspecified. Which subprograms of this package call Hash, and how many
+times they call it, is unspecified.
+
+43.a/2
+ Implementation Note: The implementation is not required to
+ protect against Hash raising an exception, or returning random
+ numbers, or any other "bad" behavior. It's not practical to
+ do so, and a broken Hash function makes the container
+ unusable.
+
+43.b/2
+ The implementation can call Hash whenever it is needed; we
+ don't want to specify how often that happens. The result must
+ remain the same (this is logically a pure function), or the
+ behavior is unspecified.
+
+44/2
+{AI95-00302-03AI95-00302-03} The actual function for the generic formal
+function Equivalent_Keys on Key_Type values is expected to return the
+same value each time it is called with a particular pair of key values.
+It should define an equivalence relationship, that is, be reflexive,
+symmetric, and transitive. If the actual for Equivalent_Keys behaves in
+some other manner, the behavior of this package is unspecified. Which
+subprograms of this package call Equivalent_Keys, and how many times
+they call it, is unspecified.
+
+44.a/2
+ Implementation Note: As with Hash, the implementation is not
+ required to protect against Equivalent_Keys raising an
+ exception or returning random results. Similarly, the
+ implementation can call this operation whenever it is needed.
+ The result must remain the same (this is a logically pure
+ function), or the behavior is unspecified.
+
+45/2
+{AI95-00302-03AI95-00302-03} If the value of a key stored in a node of a
+map is changed other than by an operation in this package such that at
+least one of Hash or Equivalent_Keys give different results, the
+behavior of this package is unspecified.
+
+45.a/2
+ Implementation Note: The implementation is not required to
+ protect against changes to key values other than via the
+ operations declared in the Hashed_Maps package.
+
+45.b/2
+ To see how this could happen, imagine an instance of
+ Hashed_Maps where the key type is an access-to-variable type
+ and Hash returns a value derived from the components of the
+ designated object. Then, any operation that has a key value
+ could modify those components and change the hash value:
+
+45.c/2
+ Key (Map).Some_Component := New_Value;
+
+45.d/2
+ This is really a design error on the part of the user of the
+ map; it shouldn't be possible to modify keys stored in a map.
+ But we can't prevent this error anymore than we can prevent
+ someone passing as Hash a random number generator.
+
+46/2
+{AI95-00302-03AI95-00302-03} Which nodes are the first node and the last
+node of a map, and which node is the successor of a given node, are
+unspecified, other than the general semantics described in *note
+A.18.4::.
+
+46.a/2
+ Implementation Note: Typically the first node will be the
+ first node in the first bucket, the last node will be the last
+ node in the last bucket, and the successor will be obtained by
+ following the collision list, and going to the next bucket at
+ the end of each bucket.
+
+47/2
+ function Capacity (Container : Map) return Count_Type;
+
+48/2
+ {AI95-00302-03AI95-00302-03} Returns the capacity of
+ Container.
+
+49/2
+ procedure Reserve_Capacity (Container : in out Map;
+ Capacity : in Count_Type);
+
+50/2
+ {AI95-00302-03AI95-00302-03} Reserve_Capacity allocates a new
+ hash table such that the length of the resulting map can
+ become at least the value Capacity without requiring an
+ additional call to Reserve_Capacity, and is large enough to
+ hold the current length of Container. Reserve_Capacity then
+ rehashes the nodes in Container onto the new hash table. It
+ replaces the old hash table with the new hash table, and then
+ deallocates the old hash table. Any exception raised during
+ allocation is propagated and Container is not modified.
+
+51/2
+ Reserve_Capacity tampers with the cursors of Container.
+
+51.a/2
+ Implementation Note: This routine is used to preallocate the
+ internal hash table to the specified capacity such that future
+ Inserts do not require expansion of the hash table.
+ Therefore, the implementation should allocate the needed
+ memory to make that true at this point, even though the
+ visible semantics could be preserved by waiting until enough
+ elements are inserted.
+
+51.b/3
+ {AI05-0005-1AI05-0005-1} While Reserve_Capacity can be used to
+ reduce the capacity of a map, we do not specify whether an
+ implementation actually supports reduction of the capacity.
+ Since the actual capacity can be anything greater than or
+ equal to Capacity, an implementation never has to reduce the
+ capacity.
+
+51.c/2
+ Reserve_Capacity tampers with the cursors, as rehashing
+ probably will change the order that elements are stored in the
+ map.
+
+52/2
+ procedure Clear (Container : in out Map);
+
+53/2
+ {AI95-00302-03AI95-00302-03} In addition to the semantics
+ described in *note A.18.4::, Clear does not affect the
+ capacity of Container.
+
+53.1/3
+ procedure Assign (Target : in out Map; Source : in Map);
+
+53.2/3
+ {AI05-0001-1AI05-0001-1} {AI05-0248-1AI05-0248-1} In addition
+ to the semantics described in *note A.18.4::, if the length of
+ Source is greater than the capacity of Target,
+ Reserve_Capacity (Target, Length (Source)) is called before
+ assigning any elements.
+
+53.3/3
+ function Copy (Source : Map; Capacity : Count_Type := 0) return Map;
+
+53.4/3
+ {AI05-0001-1AI05-0001-1} Returns a map whose keys and elements
+ are initialized from the keys and elements of Source. If
+ Capacity is 0, then the map capacity is the length of Source;
+ if Capacity is equal to or greater than the length of Source,
+ the map capacity is at least the specified value. Otherwise,
+ the operation propagates Capacity_Error.
+
+53.a/2
+ Implementation Note: In:
+
+53.b/2
+ procedure Move (Target : in out Map;
+ Source : in out Map);
+
+53.c/2
+ The intended implementation is that the internal hash table of
+ Target is first deallocated; then the internal hash table is
+ removed from Source and moved to Target.
+
+54/2
+ procedure Insert (Container : in out Map;
+ Key : in Key_Type;
+ New_Item : in Element_Type;
+ Position : out Cursor;
+ Inserted : out Boolean);
+
+55/2
+ {AI95-00302-03AI95-00302-03} In addition to the semantics
+ described in *note A.18.4::, if Length (Container) equals
+ Capacity (Container), then Insert first calls Reserve_Capacity
+ to increase the capacity of Container to some larger value.
+
+55.a/2
+ Implementation Note: Insert should only compare keys that hash
+ to the same bucket in the hash table.
+
+55.b/2
+ We specify when Reserve_Capacity is called to bound the
+ overhead of capacity expansion operations (which are
+ potentially expensive). Moreover, expansion can be predicted
+ by comparing Capacity(Map) to Length(Map). Since we don't
+ specify by how much the hash table is expanded, this only can
+ be used to predict the next expansion, not later ones.
+
+55.c/2
+ Implementation Note: In:
+
+55.d/2
+ procedure Exclude (Container : in out Map;
+ Key : in Key_Type);
+
+55.e/2
+ Exclude should only compare keys that hash to the same bucket
+ in the hash table.
+
+55.f/2
+ Implementation Note: In:
+
+55.g/2
+ procedure Delete (Container : in out Map;
+ Key : in Key_Type);
+
+55.h/2
+ Delete should only compare keys that hash to the same bucket
+ in the hash table. The node containing the element may be
+ deallocated now, or it may be saved and reused later.
+
+55.i/2
+ Implementation Note: In:
+
+55.j/2
+ function First (Container : Map) return Cursor;
+
+55.k/2
+ In a typical implementation, this will be the first node in
+ the lowest numbered hash bucket that contains a node.
+
+55.l/2
+ Implementation Note: In:
+
+55.m/2
+ function Next (Position : Cursor) return Cursor;
+
+55.n/2
+ In a typical implementation, this will return the next node in
+ a bucket; if Position is the last node in a bucket, this will
+ return the first node in the next nonempty bucket.
+
+55.o/2
+ A typical implementation will need to a keep a pointer at the
+ map container in the cursor in order to implement this
+ function.
+
+55.p/2
+ Implementation Note: In:
+
+55.q/2
+ function Find (Container : Map;
+ Key : Key_Type) return Cursor;
+
+55.r/2
+ Find should only compare keys that hash to the same bucket in
+ the hash table.
+
+56/2
+ function Equivalent_Keys (Left, Right : Cursor)
+ return Boolean;
+
+57/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Equivalent_Keys
+ (Key (Left), Key (Right)).
+
+58/2
+ function Equivalent_Keys (Left : Cursor;
+ Right : Key_Type) return Boolean;
+
+59/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Equivalent_Keys
+ (Key (Left), Right).
+
+60/2
+ function Equivalent_Keys (Left : Key_Type;
+ Right : Cursor) return Boolean;
+
+61/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Equivalent_Keys
+ (Left, Key (Right)).
+
+61.1/3
+ function Iterate (Container : in Map)
+ return Map_Iterator_Interfaces.Forward_Iterator'Class;
+
+61.2/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1}
+ {AI05-0269-1AI05-0269-1} Iterate returns an iterator object
+ (see *note 5.5.1::) that will generate a value for a loop
+ parameter (see *note 5.5.2::) designating each node in
+ Container, starting with the first node and moving the cursor
+ according to the successor relation. Tampering with the
+ cursors of Container is prohibited while the iterator object
+ exists (in particular, in the sequence_of_statements of the
+ loop_statement whose iterator_specification denotes this
+ object). The iterator object needs finalization.
+
+ _Implementation Advice_
+
+62/2
+{AI95-00302-03AI95-00302-03} If N is the length of a map, the average
+time complexity of the subprograms Element, Insert, Include, Replace,
+Delete, Exclude and Find that take a key parameter should be O(log N).
+The average time complexity of the subprograms that take a cursor
+parameter should be O(1). The average time complexity of
+Reserve_Capacity should be O(N).
+
+62.a/2
+ Implementation Advice: The average time complexity of Element,
+ Insert, Include, Replace, Delete, Exclude and Find operations
+ that take a key parameter for Containers.Hashed_Maps should be
+ O(log N). The average time complexity of the subprograms of
+ Containers.Hashed_Maps that take a cursor parameter should be
+ O(1). The average time complexity of
+ Containers.Hashed_Maps.Reserve_Capacity should be O(N).
+
+62.b/2
+ Reason: We do not mean to overly constrain implementation
+ strategies here. However, it is important for portability
+ that the performance of large containers has roughly the same
+ factors on different implementations. If a program is moved
+ to an implementation for which Find is O(N), that program
+ could be unusable when the maps are large. We allow O(log N)
+ access because the proportionality constant and caching
+ effects are likely to be larger than the log factor, and we
+ don't want to discourage innovative implementations.
+
+ _Extensions to Ada 95_
+
+62.c/2
+ {AI95-00302-03AI95-00302-03} The generic package
+ Containers.Hashed_Maps is new.
+
+ _Incompatibilities With Ada 2005_
+
+62.d/3
+ {AI05-0001-1AI05-0001-1} Subprograms Assign and Copy are added
+ to Containers.Hashed_Maps. If an instance of
+ Containers.Hashed_Maps is referenced in a use_clause, and an
+ entity E with the same defining_identifier as a new entity in
+ Containers.Hashed_Maps is defined in a package that is also
+ referenced in a use_clause, the entity E may no longer be
+ use-visible, resulting in errors. This should be rare and is
+ easily fixed if it does occur.
+
+ _Extensions to Ada 2005_
+
+62.e/3
+ {AI05-0212-1AI05-0212-1} Added iterator and indexing support
+ to make hashed map containers more convenient to use.
+
+ _Wording Changes from Ada 2005_
+
+62.f/3
+ {AI05-0084-1AI05-0084-1} Correction: Added a pragma
+ Remote_Types so that containers can be used in distributed
+ programs.
+
+\1f
+File: aarm2012.info, Node: A.18.6, Next: A.18.7, Prev: A.18.5, Up: A.18
+
+A.18.6 The Generic Package Containers.Ordered_Maps
+--------------------------------------------------
+
+ _Static Semantics_
+
+1/2
+{AI95-00302-03AI95-00302-03} The generic library package
+Containers.Ordered_Maps has the following declaration:
+
+2/3
+ {AI05-0084-1AI05-0084-1} {AI05-0212-1AI05-0212-1} with Ada.Iterator_Interfaces;
+ generic
+ type Key_Type is private;
+ type Element_Type is private;
+ with function "<" (Left, Right : Key_Type) return Boolean is <>;
+ with function "=" (Left, Right : Element_Type) return Boolean is <>;
+ package Ada.Containers.Ordered_Maps is
+ pragma Preelaborate(Ordered_Maps);
+ pragma Remote_Types(Ordered_Maps);
+
+3/2
+ function Equivalent_Keys (Left, Right : Key_Type) return Boolean;
+
+4/3
+ {AI05-0212-1AI05-0212-1} type Map is tagged private
+ with Constant_Indexing => Constant_Reference,
+ Variable_Indexing => Reference,
+ Default_Iterator => Iterate,
+ Iterator_Element => Element_Type;
+ pragma Preelaborable_Initialization(Map);
+
+5/2
+ type Cursor is private;
+ pragma Preelaborable_Initialization(Cursor);
+
+6/2
+ Empty_Map : constant Map;
+
+7/2
+ No_Element : constant Cursor;
+
+7.1/3
+ {AI05-0212-1AI05-0212-1} function Has_Element (Position : Cursor) return Boolean;
+
+7.2/3
+ {AI05-0212-1AI05-0212-1} package Map_Iterator_Interfaces is new
+ Ada.Iterator_Interfaces (Cursor, Has_Element);
+
+8/2
+ function "=" (Left, Right : Map) return Boolean;
+
+9/2
+ function Length (Container : Map) return Count_Type;
+
+10/2
+ function Is_Empty (Container : Map) return Boolean;
+
+11/2
+ procedure Clear (Container : in out Map);
+
+12/2
+ function Key (Position : Cursor) return Key_Type;
+
+13/2
+ function Element (Position : Cursor) return Element_Type;
+
+14/2
+ procedure Replace_Element (Container : in out Map;
+ Position : in Cursor;
+ New_Item : in Element_Type);
+
+15/2
+ procedure Query_Element
+ (Position : in Cursor;
+ Process : not null access procedure (Key : in Key_Type;
+ Element : in Element_Type));
+
+16/2
+ procedure Update_Element
+ (Container : in out Map;
+ Position : in Cursor;
+ Process : not null access procedure
+ (Key : in Key_Type;
+ Element : in out Element_Type));
+
+16.1/3
+ {AI05-0212-1AI05-0212-1} type Constant_Reference_Type
+ (Element : not null access constant Element_Type) is private
+ with Implicit_Dereference => Element;
+
+16.2/3
+ {AI05-0212-1AI05-0212-1} type Reference_Type (Element : not null access Element_Type) is private
+ with Implicit_Dereference => Element;
+
+16.3/3
+ {AI05-0212-1AI05-0212-1} function Constant_Reference (Container : aliased in Map;
+ Position : in Cursor)
+ return Constant_Reference_Type;
+
+16.4/3
+ {AI05-0212-1AI05-0212-1} function Reference (Container : aliased in out Map;
+ Position : in Cursor)
+ return Reference_Type;
+
+16.5/3
+ {AI05-0212-1AI05-0212-1} function Constant_Reference (Container : aliased in Map;
+ Key : in Key_Type)
+ return Constant_Reference_Type;
+
+16.6/3
+ {AI05-0212-1AI05-0212-1} function Reference (Container : aliased in out Map;
+ Key : in Key_Type)
+ return Reference_Type;
+
+16.7/3
+ {AI05-0001-1AI05-0001-1} procedure Assign (Target : in out Map; Source : in Map);
+
+16.8/3
+ {AI05-0001-1AI05-0001-1} function Copy (Source : Map) return Map;
+
+17/2
+ procedure Move (Target : in out Map;
+ Source : in out Map);
+
+18/2
+ procedure Insert (Container : in out Map;
+ Key : in Key_Type;
+ New_Item : in Element_Type;
+ Position : out Cursor;
+ Inserted : out Boolean);
+
+19/2
+ procedure Insert (Container : in out Map;
+ Key : in Key_Type;
+ Position : out Cursor;
+ Inserted : out Boolean);
+
+20/2
+ procedure Insert (Container : in out Map;
+ Key : in Key_Type;
+ New_Item : in Element_Type);
+
+21/2
+ procedure Include (Container : in out Map;
+ Key : in Key_Type;
+ New_Item : in Element_Type);
+
+22/2
+ procedure Replace (Container : in out Map;
+ Key : in Key_Type;
+ New_Item : in Element_Type);
+
+23/2
+ procedure Exclude (Container : in out Map;
+ Key : in Key_Type);
+
+24/2
+ procedure Delete (Container : in out Map;
+ Key : in Key_Type);
+
+25/2
+ procedure Delete (Container : in out Map;
+ Position : in out Cursor);
+
+26/2
+ procedure Delete_First (Container : in out Map);
+
+27/2
+ procedure Delete_Last (Container : in out Map);
+
+28/2
+ function First (Container : Map) return Cursor;
+
+29/2
+ function First_Element (Container : Map) return Element_Type;
+
+30/2
+ function First_Key (Container : Map) return Key_Type;
+
+31/2
+ function Last (Container : Map) return Cursor;
+
+32/2
+ function Last_Element (Container : Map) return Element_Type;
+
+33/2
+ function Last_Key (Container : Map) return Key_Type;
+
+34/2
+ function Next (Position : Cursor) return Cursor;
+
+35/2
+ procedure Next (Position : in out Cursor);
+
+36/2
+ function Previous (Position : Cursor) return Cursor;
+
+37/2
+ procedure Previous (Position : in out Cursor);
+
+38/2
+ function Find (Container : Map;
+ Key : Key_Type) return Cursor;
+
+39/2
+ function Element (Container : Map;
+ Key : Key_Type) return Element_Type;
+
+40/2
+ function Floor (Container : Map;
+ Key : Key_Type) return Cursor;
+
+41/2
+ function Ceiling (Container : Map;
+ Key : Key_Type) return Cursor;
+
+42/2
+ function Contains (Container : Map;
+ Key : Key_Type) return Boolean;
+
+43/3
+ This paragraph was deleted.{AI05-0212-1AI05-0212-1}
+
+44/2
+ function "<" (Left, Right : Cursor) return Boolean;
+
+45/2
+ function ">" (Left, Right : Cursor) return Boolean;
+
+46/2
+ function "<" (Left : Cursor; Right : Key_Type) return Boolean;
+
+47/2
+ function ">" (Left : Cursor; Right : Key_Type) return Boolean;
+
+48/2
+ function "<" (Left : Key_Type; Right : Cursor) return Boolean;
+
+49/2
+ function ">" (Left : Key_Type; Right : Cursor) return Boolean;
+
+50/2
+ procedure Iterate
+ (Container : in Map;
+ Process : not null access procedure (Position : in Cursor));
+
+51/2
+ procedure Reverse_Iterate
+ (Container : in Map;
+ Process : not null access procedure (Position : in Cursor));
+
+51.1/3
+ {AI05-0212-1AI05-0212-1} function Iterate (Container : in Map)
+ return Map_Iterator_Interfaces.Reversible_Iterator'Class;
+
+51.2/3
+ {AI05-0262-1AI05-0262-1} function Iterate (Container : in Map; Start : in Cursor)
+ return Map_Iterator_Interfaces.Reversible_Iterator'Class;
+
+52/2
+ private
+
+53/2
+ ... -- not specified by the language
+
+54/2
+ end Ada.Containers.Ordered_Maps;
+
+55/2
+{AI95-00302-03AI95-00302-03} Two keys K1 and K2 are equivalent if both
+K1 < K2 and K2 < K1 return False, using the generic formal "<" operator
+for keys. Function Equivalent_Keys returns True if Left and Right are
+equivalent, and False otherwise.
+
+56/3
+{AI95-00302-03AI95-00302-03} {AI05-0044-1AI05-0044-1} The actual
+function for the generic formal function "<" on Key_Type values is
+expected to return the same value each time it is called with a
+particular pair of key values. It should define a strict weak ordering
+relationship (see *note A.18::). If the actual for "<" behaves in some
+other manner, the behavior of this package is unspecified. Which
+subprograms of this package call "<" and how many times they call it, is
+unspecified.
+
+56.a/2
+ Implementation Note: The implementation is not required to
+ protect against "<" raising an exception, or returning random
+ results, or any other "bad" behavior. It's not practical to
+ do so, and a broken "<" function makes the container unusable.
+
+56.b/2
+ The implementation can call "<" whenever it is needed; we
+ don't want to specify how often that happens. The result must
+ remain the same (this is a logically pure function), or the
+ behavior is unspecified.
+
+57/2
+{AI95-00302-03AI95-00302-03} If the value of a key stored in a map is
+changed other than by an operation in this package such that at least
+one of "<" or "=" give different results, the behavior of this package
+is unspecified.
+
+57.a/2
+ Implementation Note: The implementation is not required to
+ protect against changes to key values other than via the
+ operations declared in the Ordered_Maps package.
+
+57.b/2
+ To see how this could happen, imagine an instance of
+ Ordered_Maps package where the key type is an
+ access-to-variable type and "<" returns a value derived from
+ comparing the components of the designated objects. Then, any
+ operation that has a key value (even if the key value is
+ constant) could modify those components and change the result
+ of "<":
+
+57.c/2
+ Key (Map).Some_Component := New_Value;
+
+57.d/2
+ This is really a design error on the part of the user of the
+ map; it shouldn't be possible to modify keys stored in a map
+ such that "<" changes. But we can't prevent this error
+ anymore than we can prevent someone passing as "<" a routine
+ that produces random answers.
+
+58/3
+{AI95-00302-03AI95-00302-03} {AI05-0262-1AI05-0262-1} The first node of
+a nonempty map is the one whose key is less than the key of all the
+other nodes in the map. The last node of a nonempty map is the one
+whose key is greater than the key of all the other elements in the map.
+The successor of a node is the node with the smallest key that is larger
+than the key of the given node. The predecessor of a node is the node
+with the largest key that is smaller than the key of the given node.
+All comparisons are done using the generic formal "<" operator for keys.
+
+58.1/3
+ function Copy (Source : Map) return Map;
+
+58.2/3
+ {AI05-0001-1AI05-0001-1} Returns a map whose keys and elements
+ are initialized from the corresponding keys and elements of
+ Source.
+
+59/2
+ procedure Delete_First (Container : in out Map);
+
+60/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Container is empty, Delete_First has no effect. Otherwise,
+ the node designated by First (Container) is removed from
+ Container. Delete_First tampers with the cursors of
+ Container.
+
+61/2
+ procedure Delete_Last (Container : in out Map);
+
+62/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Container is empty, Delete_Last has no effect. Otherwise, the
+ node designated by Last (Container) is removed from Container.
+ Delete_Last tampers with the cursors of Container.
+
+63/2
+ function First_Element (Container : Map) return Element_Type;
+
+64/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Element (First
+ (Container)).
+
+65/2
+ function First_Key (Container : Map) return Key_Type;
+
+66/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Key (First
+ (Container)).
+
+67/2
+ function Last (Container : Map) return Cursor;
+
+68/2
+ {AI95-00302-03AI95-00302-03} Returns a cursor that designates
+ the last node in Container. If Container is empty, returns
+ No_Element.
+
+69/2
+ function Last_Element (Container : Map) return Element_Type;
+
+70/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Element (Last
+ (Container)).
+
+71/2
+ function Last_Key (Container : Map) return Key_Type;
+
+72/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Key (Last
+ (Container)).
+
+73/2
+ function Previous (Position : Cursor) return Cursor;
+
+74/3
+ {AI95-00302-03AI95-00302-03} {AI05-0262-1AI05-0262-1} If
+ Position equals No_Element, then Previous returns No_Element.
+ Otherwise, Previous returns a cursor designating the
+ predecessor node of the one designated by Position. If
+ Position designates the first element, then Previous returns
+ No_Element.
+
+75/2
+ procedure Previous (Position : in out Cursor);
+
+76/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Position :=
+ Previous (Position).
+
+77/2
+ function Floor (Container : Map;
+ Key : Key_Type) return Cursor;
+
+78/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} Floor
+ searches for the last node whose key is not greater than Key,
+ using the generic formal "<" operator for keys. If such a
+ node is found, a cursor that designates it is returned.
+ Otherwise, No_Element is returned.
+
+79/2
+ function Ceiling (Container : Map;
+ Key : Key_Type) return Cursor;
+
+80/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} Ceiling
+ searches for the first node whose key is not less than Key,
+ using the generic formal "<" operator for keys. If such a
+ node is found, a cursor that designates it is returned.
+ Otherwise, No_Element is returned.
+
+81/2
+ function "<" (Left, Right : Cursor) return Boolean;
+
+82/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Key (Left) < Key
+ (Right).
+
+83/2
+ function ">" (Left, Right : Cursor) return Boolean;
+
+84/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Key (Right) < Key
+ (Left).
+
+85/2
+ function "<" (Left : Cursor; Right : Key_Type) return Boolean;
+
+86/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Key (Left) < Right.
+
+87/2
+ function ">" (Left : Cursor; Right : Key_Type) return Boolean;
+
+88/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Right < Key (Left).
+
+89/2
+ function "<" (Left : Key_Type; Right : Cursor) return Boolean;
+
+90/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Left < Key (Right).
+
+91/2
+ function ">" (Left : Key_Type; Right : Cursor) return Boolean;
+
+92/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Key (Right) < Left.
+
+93/2
+ procedure Reverse_Iterate
+ (Container : in Map;
+ Process : not null access procedure (Position : in Cursor));
+
+94/3
+ {AI95-00302-03AI95-00302-03} {AI05-0212-1AI05-0212-1} Iterates
+ over the nodes in Container as per procedure Iterate, with the
+ difference that the nodes are traversed in predecessor order,
+ starting with the last node.
+
+94.1/3
+ function Iterate (Container : in Map)
+ return Map_Iterator_Interfaces.Reversible_Iterator'Class;
+
+94.2/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1}
+ {AI05-0269-1AI05-0269-1} Iterate returns a reversible iterator
+ object (see *note 5.5.1::) that will generate a value for a
+ loop parameter (see *note 5.5.2::) designating each node in
+ Container, starting with the first node and moving the cursor
+ according to the successor relation when used as a forward
+ iterator, and starting with the last node and moving the
+ cursor according to the predecessor relation when used as a
+ reverse iterator. Tampering with the cursors of Container is
+ prohibited while the iterator object exists (in particular, in
+ the sequence_of_statements of the loop_statement whose
+ iterator_specification denotes this object). The iterator
+ object needs finalization.
+
+94.3/3
+ function Iterate (Container : in Map; Start : in Cursor)
+ return Map_Iterator_Interfaces.Reversible_Iterator'Class;
+
+94.4/3
+ {AI05-0262-1AI05-0262-1} {AI05-0265-1AI05-0265-1}
+ {AI05-0269-1AI05-0269-1} If Start is not No_Element and does
+ not designate an item in Container, then Program_Error is
+ propagated. If Start is No_Element, then Constraint_Error is
+ propagated. Otherwise, Iterate returns a reversible iterator
+ object (see *note 5.5.1::) that will generate a value for a
+ loop parameter (see *note 5.5.2::) designating each node in
+ Container, starting with the node designated by Start and
+ moving the cursor according to the successor relation when
+ used as a forward iterator, or moving the cursor according to
+ the predecessor relation when used as a reverse iterator.
+ Tampering with the cursors of Container is prohibited while
+ the iterator object exists (in particular, in the
+ sequence_of_statements of the loop_statement whose
+ iterator_specification denotes this object). The iterator
+ object needs finalization.
+
+94.a/3
+ Discussion: Exits are allowed from the loops created using the
+ iterator objects. In particular, to stop the iteration at a
+ particular cursor, just add
+
+94.b/3
+ exit when Cur = Stop;
+
+94.c/3
+ in the body of the loop (assuming that Cur is the loop
+ parameter and Stop is the cursor that you want to stop at).
+
+ _Implementation Advice_
+
+95/2
+{AI95-00302-03AI95-00302-03} If N is the length of a map, then the
+worst-case time complexity of the Element, Insert, Include, Replace,
+Delete, Exclude and Find operations that take a key parameter should be
+O((log N)**2) or better. The worst-case time complexity of the
+subprograms that take a cursor parameter should be O(1).
+
+95.a/2
+ Implementation Advice: The worst-case time complexity of
+ Element, Insert, Include, Replace, Delete, Exclude and Find
+ operations that take a key parameter for
+ Containers.Ordered_Maps should be O((log N)**2) or better.
+ The worst-case time complexity of the subprograms of
+ Containers.Ordered_Maps that take a cursor parameter should be
+ O(1).
+
+95.b/2
+ Implementation Note: A balanced (red-black) tree for keys has
+ O(log N) worst-case performance. Note that a O(N) worst-case
+ implementation (like a list) would be wrong.
+
+95.c/2
+ Reason: We do not mean to overly constrain implementation
+ strategies here. However, it is important for portability
+ that the performance of large containers has roughly the same
+ factors on different implementations. If a program is moved
+ to an implementation that takes O(N) to find elements, that
+ program could be unusable when the maps are large. We allow
+ the extra log N factors because the proportionality constant
+ and caching effects are likely to be larger than the log
+ factor, and we don't want to discourage innovative
+ implementations.
+
+ _Extensions to Ada 95_
+
+95.d/2
+ {AI95-00302-03AI95-00302-03} The generic package
+ Containers.Ordered_Maps is new.
+
+ _Incompatibilities With Ada 2005_
+
+95.e/3
+ {AI05-0001-1AI05-0001-1} Subprograms Assign and Copy are added
+ to Containers.Ordered_Maps. If an instance of
+ Containers.Ordered_Maps is referenced in a use_clause, and an
+ entity E with the same defining_identifier as a new entity in
+ Containers.Ordered_Maps is defined in a package that is also
+ referenced in a use_clause, the entity E may no longer be
+ use-visible, resulting in errors. This should be rare and is
+ easily fixed if it does occur.
+
+ _Extensions to Ada 2005_
+
+95.f/3
+ {AI05-0212-1AI05-0212-1} Added iterator and indexing support
+ to make ordered map containers more convenient to use.
+
+ _Wording Changes from Ada 2005_
+
+95.g/3
+ {AI05-0044-1AI05-0044-1} Correction: Redefined "<" actuals to
+ require a strict weak ordering; the old definition allowed
+ indeterminant comparisons that would not have worked in a
+ container.
+
+95.h/3
+ {AI05-0084-1AI05-0084-1} Correction: Added a pragma
+ Remote_Types so that containers can be used in distributed
+ programs.
+
+\1f
+File: aarm2012.info, Node: A.18.7, Next: A.18.8, Prev: A.18.6, Up: A.18
+
+A.18.7 Sets
+-----------
+
+1/2
+{AI95-00302-03AI95-00302-03} The language-defined generic packages
+Containers.Hashed_Sets and Containers.Ordered_Sets provide private types
+Set and Cursor, and a set of operations for each type. A set container
+allows elements of an arbitrary type to be stored without duplication.
+A hashed set uses a hash function to organize elements, while an ordered
+set orders its element per a specified relation.
+
+2/3
+{AI95-00302-03AI95-00302-03} {AI05-0299-1AI05-0299-1} This subclause
+describes the declarations that are common to both kinds of sets. See
+*note A.18.8:: for a description of the semantics specific to
+Containers.Hashed_Sets and *note A.18.9:: for a description of the
+semantics specific to Containers.Ordered_Sets.
+
+ _Static Semantics_
+
+3/2
+{AI95-00302-03AI95-00302-03} The actual function for the generic formal
+function "=" on Element_Type values is expected to define a reflexive
+and symmetric relationship and return the same result value each time it
+is called with a particular pair of values. If it behaves in some other
+manner, the function "=" on set values returns an unspecified value.
+The exact arguments and number of calls of this generic formal function
+by the function "=" on set values are unspecified.
+
+3.a/2
+ Ramification: If the actual function for "=" is not symmetric
+ and consistent, the result returned by the "=" for Set objects
+ cannot be predicted. The implementation is not required to
+ protect against "=" raising an exception, or returning random
+ results, or any other "bad" behavior. And it can call "=" in
+ whatever manner makes sense. But note that only the result of
+ "=" for Set objects is unspecified; other subprograms are not
+ allowed to break if "=" is bad (they aren't expected to use
+ "=").
+
+4/2
+{AI95-00302-03AI95-00302-03} The type Set is used to represent sets.
+The type Set needs finalization (see *note 7.6::).
+
+5/2
+{AI95-00302-03AI95-00302-03} A set contains elements. Set cursors
+designate elements. There exists an equivalence relation on elements,
+whose definition is different for hashed sets and ordered sets. A set
+never contains two or more equivalent elements. The length of a set is
+the number of elements it contains.
+
+6/2
+{AI95-00302-03AI95-00302-03} Each nonempty set has two particular
+elements called the first element and the last element (which may be the
+same). Each element except for the last element has a successor
+element. If there are no other intervening operations, starting with
+the first element and repeatedly going to the successor element will
+visit each element in the set exactly once until the last element is
+reached. The exact definition of these terms is different for hashed
+sets and ordered sets.
+
+7/2
+{AI95-00302-03AI95-00302-03} [Some operations of these generic packages
+have access-to-subprogram parameters. To ensure such operations are
+well-defined, they guard against certain actions by the designated
+subprogram. In particular, some operations check for "tampering with
+cursors" of a container because they depend on the set of elements of
+the container remaining constant, and others check for "tampering with
+elements" of a container because they depend on elements of the
+container not being replaced.]
+
+8/2
+{AI95-00302-03AI95-00302-03} A subprogram is said to tamper with cursors
+of a set object S if:
+
+9/2
+ * it inserts or deletes elements of S, that is, it calls the Insert,
+ Include, Clear, Delete, Exclude, or Replace_Element procedures with
+ S as a parameter; or
+
+9.a/2
+ To be honest: Operations which are defined to be equivalent to
+ a call on one of these operations also are included.
+ Similarly, operations which call one of these as part of their
+ definition are included.
+
+9.b/2
+ Discussion: We have to include Replace_Element here because it
+ might delete and reinsert the element if it moves in the set.
+ That could change the order of iteration, which is what this
+ check is designed to prevent. Replace is also included, as it
+ is defined in terms of Replace_Element.
+
+10/2
+ * it finalizes S; or
+
+10.1/3
+ * {AI05-0001-1AI05-0001-1} it calls the Assign procedure with S as
+ the Target parameter; or
+
+10.a/3
+ Ramification: We don't need to explicitly mention
+ assignment_statement, because that finalizes the target object
+ as part of the operation, and finalization of an object is
+ already defined as tampering with cursors.
+
+11/2
+ * it calls the Move procedure with S as a parameter; or
+
+12/2
+ * it calls one of the operations defined to tamper with cursors of S.
+
+13/2
+{AI95-00302-03AI95-00302-03} A subprogram is said to tamper with
+elements of a set object S if:
+
+14/2
+ * it tampers with cursors of S.
+
+14.a/2
+ Reason: Complete replacement of an element can cause its
+ memory to be deallocated while another operation is holding
+ onto a reference to it. That can't be allowed. However, a
+ simple modification of (part of) an element is not a problem,
+ so Update_Element_Preserving_Key does not cause a problem.
+
+14.b/2
+ We don't need to list Replace and Replace_Element here because
+ they are covered by "tamper with cursors". For Set, "tamper
+ with cursors" and "tamper with elements" are the same. We
+ leave both terms so that the rules for routines like Iterate
+ and Query_Element are consistent across all containers.
+
+14.1/3
+{AI05-0265-1AI05-0265-1} When tampering with cursors is prohibited for a
+particular set object S, Program_Error is propagated by a call of any
+language-defined subprogram that is defined to tamper with the cursors
+of S, leaving S unmodified. Similarly, when tampering with elements is
+prohibited for a particular set object S, Program_Error is propagated by
+a call of any language-defined subprogram that is defined to tamper with
+the elements of S [(or tamper with the cursors of S)], leaving S
+unmodified.
+
+14.c/3
+ Proof: Tampering with elements includes tampering with
+ cursors, so we mention it only from completeness in the second
+ sentence.
+
+15/2
+{AI95-00302-03AI95-00302-03} Empty_Set represents the empty Set object.
+It has a length of 0. If an object of type Set is not otherwise
+initialized, it is initialized to the same value as Empty_Set.
+
+16/2
+{AI95-00302-03AI95-00302-03} No_Element represents a cursor that
+designates no element. If an object of type Cursor is not otherwise
+initialized, it is initialized to the same value as No_Element.
+
+17/2
+{AI95-00302-03AI95-00302-03} The predefined "=" operator for type Cursor
+returns True if both cursors are No_Element, or designate the same
+element in the same container.
+
+18/2
+{AI95-00302-03AI95-00302-03} Execution of the default implementation of
+the Input, Output, Read, or Write attribute of type Cursor raises
+Program_Error.
+
+18.a/2
+ Reason: A cursor will probably be implemented in terms of one
+ or more access values, and the effects of streaming access
+ values is unspecified. Rather than letting the user stream
+ junk by accident, we mandate that streaming of cursors raise
+ Program_Error by default. The attributes can always be
+ specified if there is a need to support streaming.
+
+18.1/3
+{AI05-0001-1AI05-0001-1} {AI05-0262-1AI05-0262-1} Set'Write for a Set
+object S writes Length(S) elements of the set to the stream. It also
+may write additional information about the set.
+
+18.2/3
+{AI05-0001-1AI05-0001-1} {AI05-0262-1AI05-0262-1} Set'Read reads the
+representation of a set from the stream, and assigns to Item a set with
+the same length and elements as was written by Set'Write.
+
+18.b/3
+ Ramification: Streaming more elements than the container
+ length is wrong. For implementation implications of this
+ rule, see the Implementation Note in *note A.18.2::.
+
+18.3/3
+ function Has_Element (Position : Cursor) return Boolean;
+
+18.4/3
+ {AI05-0212-1AI05-0212-1} Returns True if Position designates
+ an element, and returns False otherwise.
+
+18.c/3
+ To be honest: {AI05-0005-1AI05-0005-1}
+ {AI05-0212-1AI05-0212-1} This function might not detect
+ cursors that designate deleted elements; such cursors are
+ invalid (see below) and the result of calling Has_Element with
+ an invalid cursor is unspecified (but not erroneous).
+
+19/2
+ function "=" (Left, Right : Set) return Boolean;
+
+20/2
+ {AI95-00302-03AI95-00302-03} If Left and Right denote the same
+ set object, then the function returns True. If Left and Right
+ have different lengths, then the function returns False.
+ Otherwise, for each element E in Left, the function returns
+ False if an element equal to E (using the generic formal
+ equality operator) is not present in Right. If the function
+ has not returned a result after checking all of the elements,
+ it returns True. Any exception raised during evaluation of
+ element equality is propagated.
+
+20.a/2
+ Implementation Note: This wording describes the canonical
+ semantics. However, the order and number of calls on the
+ formal equality function is unspecified for all of the
+ operations that use it in this package, so an implementation
+ can call it as many or as few times as it needs to get the
+ correct answer. Specifically, there is no requirement to call
+ the formal equality additional times once the answer has been
+ determined.
+
+21/2
+ function Equivalent_Sets (Left, Right : Set) return Boolean;
+
+22/2
+ {AI95-00302-03AI95-00302-03} If Left and Right denote the same
+ set object, then the function returns True. If Left and Right
+ have different lengths, then the function returns False.
+ Otherwise, for each element E in Left, the function returns
+ False if an element equivalent to E is not present in Right.
+ If the function has not returned a result after checking all
+ of the elements, it returns True. Any exception raised during
+ evaluation of element equivalence is propagated.
+
+23/2
+ function To_Set (New_Item : Element_Type) return Set;
+
+24/2
+ {AI95-00302-03AI95-00302-03} Returns a set containing the
+ single element New_Item.
+
+25/2
+ function Length (Container : Set) return Count_Type;
+
+26/2
+ {AI95-00302-03AI95-00302-03} Returns the number of elements in
+ Container.
+
+27/2
+ function Is_Empty (Container : Set) return Boolean;
+
+28/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Length (Container)
+ = 0.
+
+29/2
+ procedure Clear (Container : in out Set);
+
+30/2
+ {AI95-00302-03AI95-00302-03} Removes all the elements from
+ Container.
+
+31/2
+ function Element (Position : Cursor) return Element_Type;
+
+32/2
+ {AI95-00302-03AI95-00302-03} If Position equals No_Element,
+ then Constraint_Error is propagated. Otherwise, Element
+ returns the element designated by Position.
+
+33/2
+ procedure Replace_Element (Container : in out Set;
+ Position : in Cursor;
+ New_Item : in Element_Type);
+
+34/2
+ {AI95-00302-03AI95-00302-03} If Position equals No_Element,
+ then Constraint_Error is propagated; if Position does not
+ designate an element in Container, then Program_Error is
+ propagated. If an element equivalent to New_Item is already
+ present in Container at a position other than Position,
+ Program_Error is propagated. Otherwise, Replace_Element
+ assigns New_Item to the element designated by Position. Any
+ exception raised by the assignment is propagated.
+
+34.a/2
+ Implementation Note: The final assignment may require that the
+ node of the element be moved in the Set's data structures.
+ That could mean that implementing this operation exactly as
+ worded above could require the overhead of searching twice.
+ Implementations are encouraged to avoid this extra overhead
+ when possible, by prechecking if the old element is equivalent
+ to the new one, by inserting a placeholder node while checking
+ for an equivalent element, and similar optimizations.
+
+34.b/2
+ The cursor still designates the same element after this
+ operation; only the value of that element has changed.
+ Cursors cannot include information about the relative position
+ of an element in a Set (as they must survive insertions and
+ deletions of other elements), so this should not pose an
+ implementation hardship.
+
+35/2
+ procedure Query_Element
+ (Position : in Cursor;
+ Process : not null access procedure (Element : in Element_Type));
+
+36/3
+ {AI95-00302-03AI95-00302-03} {AI05-0021-1AI05-0021-1}
+ {AI05-0265-1AI05-0265-1} If Position equals No_Element, then
+ Constraint_Error is propagated. Otherwise, Query_Element
+ calls Process.all with the element designated by Position as
+ the argument. Tampering with the elements of the set that
+ contains the element designated by Position is prohibited
+ during the execution of the call on Process.all. Any
+ exception raised by Process.all is propagated.
+
+36.1/3
+ type Constant_Reference_Type
+ (Element : not null access constant Element_Type) is private
+ with Implicit_Dereference => Element;
+
+36.2/3
+ {AI05-0212-1AI05-0212-1} The type Constant_Reference_Type
+ needs finalization.
+
+36.3/3
+ The default initialization of an object of type
+ Constant_Reference_Type propagates Program_Error.
+
+36.a/3
+ Reason: It is expected that Constant_Reference_Type will be a
+ controlled type, for which finalization will have some action
+ to terminate the tampering check for the associated container.
+ If the object is created by default, however, there is no
+ associated container. Since this is useless, and supporting
+ this case would take extra work, we define it to raise an
+ exception.
+
+36.4/3
+ function Constant_Reference (Container : aliased in Set;
+ Position : in Cursor)
+ return Constant_Reference_Type;
+
+36.5/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Constant_Indexing and
+ Implicit_Dereference aspects) provides a convenient way to
+ gain read access to an individual element of a set given a
+ cursor.
+
+36.6/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1} If Position
+ equals No_Element, then Constraint_Error is propagated; if
+ Position does not designate an element in Container, then
+ Program_Error is propagated. Otherwise, Constant_Reference
+ returns an object whose discriminant is an access value that
+ designates the element designated by Position. Tampering with
+ the elements of Container is prohibited while the object
+ returned by Constant_Reference exists and has not been
+ finalized.
+
+36.7/3
+ procedure Assign (Target : in out Set; Source : in Set);
+
+36.8/3
+ {AI05-0001-1AI05-0001-1} {AI05-0248-1AI05-0248-1} If Target
+ denotes the same object as Source, the operation has no
+ effect. Otherwise, the elements of Source are copied to
+ Target as for an assignment_statement assigning Source to
+ Target.
+
+36.b/3
+ Discussion: {AI05-0005-1AI05-0005-1} This routine exists for
+ compatibility with the bounded set containers. For an
+ unbounded set, Assign(A, B) and A := B behave identically.
+ For a bounded set, := will raise an exception if the container
+ capacities are different, while Assign will not raise an
+ exception if there is enough room in the target.
+
+37/2
+ procedure Move (Target : in out Set;
+ Source : in out Set);
+
+38/3
+ {AI95-00302-03AI95-00302-03} {AI05-0001-1AI05-0001-1}
+ {AI05-0248-1AI05-0248-1} {AI05-0262-1AI05-0262-1} If Target
+ denotes the same object as Source, then the operation has no
+ effect. Otherwise, the operation is equivalent to Assign
+ (Target, Source) followed by Clear (Source).
+
+39/2
+ procedure Insert (Container : in out Set;
+ New_Item : in Element_Type;
+ Position : out Cursor;
+ Inserted : out Boolean);
+
+40/2
+ {AI95-00302-03AI95-00302-03} Insert checks if an element
+ equivalent to New_Item is already present in Container. If a
+ match is found, Inserted is set to False and Position
+ designates the matching element. Otherwise, Insert adds
+ New_Item to Container; Inserted is set to True and Position
+ designates the newly-inserted element. Any exception raised
+ during allocation is propagated and Container is not modified.
+
+41/2
+ procedure Insert (Container : in out Set;
+ New_Item : in Element_Type);
+
+42/2
+ {AI95-00302-03AI95-00302-03} Insert inserts New_Item into
+ Container as per the four-parameter Insert, with the
+ difference that if an element equivalent to New_Item is
+ already in the set, then Constraint_Error is propagated.
+
+42.a/2
+ Discussion: This is equivalent to:
+
+42.b/2
+ declare
+ Inserted : Boolean; C : Cursor;
+ begin
+ Insert (Container, New_Item, C, Inserted);
+ if not Inserted then
+ raise Constraint_Error;
+ end if;
+ end;
+
+42.c/2
+ but doesn't require the hassle of out parameters.
+
+43/2
+ procedure Include (Container : in out Set;
+ New_Item : in Element_Type);
+
+44/2
+ {AI95-00302-03AI95-00302-03} Include inserts New_Item into
+ Container as per the four-parameter Insert, with the
+ difference that if an element equivalent to New_Item is
+ already in the set, then it is replaced. Any exception raised
+ during assignment is propagated.
+
+45/2
+ procedure Replace (Container : in out Set;
+ New_Item : in Element_Type);
+
+46/2
+ {AI95-00302-03AI95-00302-03} Replace checks if an element
+ equivalent to New_Item is already in the set. If a match is
+ found, that element is replaced with New_Item; otherwise,
+ Constraint_Error is propagated.
+
+47/2
+ procedure Exclude (Container : in out Set;
+ Item : in Element_Type);
+
+48/2
+ {AI95-00302-03AI95-00302-03} Exclude checks if an element
+ equivalent to Item is present in Container. If a match is
+ found, Exclude removes the element from the set.
+
+49/2
+ procedure Delete (Container : in out Set;
+ Item : in Element_Type);
+
+50/2
+ {AI95-00302-03AI95-00302-03} Delete checks if an element
+ equivalent to Item is present in Container. If a match is
+ found, Delete removes the element from the set; otherwise,
+ Constraint_Error is propagated.
+
+51/2
+ procedure Delete (Container : in out Set;
+ Position : in out Cursor);
+
+52/2
+ {AI95-00302-03AI95-00302-03} If Position equals No_Element,
+ then Constraint_Error is propagated. If Position does not
+ designate an element in Container, then Program_Error is
+ propagated. Otherwise, Delete removes the element designated
+ by Position from the set. Position is set to No_Element on
+ return.
+
+52.a/2
+ Ramification: The check on Position checks that the cursor
+ does not belong to some other set. This check implies that a
+ reference to the set is included in the cursor value. This
+ wording is not meant to require detection of dangling cursors;
+ such cursors are defined to be invalid, which means that
+ execution is erroneous, and any result is allowed (including
+ not raising an exception).
+
+53/2
+ procedure Union (Target : in out Set;
+ Source : in Set);
+
+54/2
+ {AI95-00302-03AI95-00302-03} Union inserts into Target the
+ elements of Source that are not equivalent to some element
+ already in Target.
+
+54.a/2
+ Implementation Note: If the objects are the same, the result
+ is the same as the original object. The implementation needs
+ to take care so that aliasing effects do not make the result
+ trash; Union (S, S); must work.
+
+55/2
+ function Union (Left, Right : Set) return Set;
+
+56/2
+ {AI95-00302-03AI95-00302-03} Returns a set comprising all of
+ the elements of Left, and the elements of Right that are not
+ equivalent to some element of Left.
+
+57/2
+ procedure Intersection (Target : in out Set;
+ Source : in Set);
+
+58/3
+ {AI95-00302-03AI95-00302-03} {AI05-0004-1AI05-0004-1}
+ Intersection deletes from Target the elements of Target that
+ are not equivalent to some element of Source.
+
+58.a/2
+ Implementation Note: If the objects are the same, the result
+ is the same as the original object. The implementation needs
+ to take care so that aliasing effects do not make the result
+ trash; Intersection (S, S); must work.
+
+59/2
+ function Intersection (Left, Right : Set) return Set;
+
+60/2
+ {AI95-00302-03AI95-00302-03} Returns a set comprising all the
+ elements of Left that are equivalent to the some element of
+ Right.
+
+61/2
+ procedure Difference (Target : in out Set;
+ Source : in Set);
+
+62/2
+ {AI95-00302-03AI95-00302-03} If Target denotes the same object
+ as Source, then Difference clears Target. Otherwise, it
+ deletes from Target the elements that are equivalent to some
+ element of Source.
+
+63/2
+ function Difference (Left, Right : Set) return Set;
+
+64/2
+ {AI95-00302-03AI95-00302-03} Returns a set comprising the
+ elements of Left that are not equivalent to some element of
+ Right.
+
+65/2
+ procedure Symmetric_Difference (Target : in out Set;
+ Source : in Set);
+
+66/2
+ {AI95-00302-03AI95-00302-03} If Target denotes the same object
+ as Source, then Symmetric_Difference clears Target.
+ Otherwise, it deletes from Target the elements that are
+ equivalent to some element of Source, and inserts into Target
+ the elements of Source that are not equivalent to some element
+ of Target.
+
+67/2
+ function Symmetric_Difference (Left, Right : Set) return Set;
+
+68/2
+ {AI95-00302-03AI95-00302-03} Returns a set comprising the
+ elements of Left that are not equivalent to some element of
+ Right, and the elements of Right that are not equivalent to
+ some element of Left.
+
+69/2
+ function Overlap (Left, Right : Set) return Boolean;
+
+70/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If an
+ element of Left is equivalent to some element of Right, then
+ Overlap returns True. Otherwise, it returns False.
+
+70.a/2
+ Discussion: This operation is commutative. If Overlap returns
+ False, the two sets are disjoint.
+
+71/2
+ function Is_Subset (Subset : Set;
+ Of_Set : Set) return Boolean;
+
+72/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If an
+ element of Subset is not equivalent to some element of Of_Set,
+ then Is_Subset returns False. Otherwise, it returns True.
+
+72.a/2
+ Discussion: This operation is not commutative, so we use
+ parameter names that make it clear in named notation which set
+ is which.
+
+73/2
+ function First (Container : Set) return Cursor;
+
+74/2
+ {AI95-00302-03AI95-00302-03} If Length (Container) = 0, then
+ First returns No_Element. Otherwise, First returns a cursor
+ that designates the first element in Container.
+
+75/2
+ function Next (Position : Cursor) return Cursor;
+
+76/2
+ {AI95-00302-03AI95-00302-03} Returns a cursor that designates
+ the successor of the element designated by Position. If
+ Position designates the last element, then No_Element is
+ returned. If Position equals No_Element, then No_Element is
+ returned.
+
+77/2
+ procedure Next (Position : in out Cursor);
+
+78/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Position := Next
+ (Position).
+
+79/3
+ This paragraph was deleted.{AI95-00302-03AI95-00302-03}
+ {AI05-0004-1AI05-0004-1}
+
+80/2
+ function Find (Container : Set;
+ Item : Element_Type) return Cursor;
+
+81/2
+ {AI95-00302-03AI95-00302-03} If Length (Container) equals 0,
+ then Find returns No_Element. Otherwise, Find checks if an
+ element equivalent to Item is present in Container. If a
+ match is found, a cursor designating the matching element is
+ returned; otherwise, No_Element is returned.
+
+82/2
+ function Contains (Container : Set;
+ Item : Element_Type) return Boolean;
+
+82.1/3
+ {AI05-0004-1AI05-0004-1} Equivalent to Find (Container, Item)
+ /= No_Element.
+
+ Paragraphs 83 and 84 were moved above.
+
+85/2
+ procedure Iterate
+ (Container : in Set;
+ Process : not null access procedure (Position : in Cursor));
+
+86/3
+ {AI95-00302-03AI95-00302-03} {AI05-0265-1AI05-0265-1} Iterate
+ calls Process.all with a cursor that designates each element
+ in Container, starting with the first element and moving the
+ cursor according to the successor relation. Tampering with
+ the cursors of Container is prohibited during the execution of
+ a call on Process.all. Any exception raised by Process.all is
+ propagated.
+
+86.a/2
+ Implementation Note: The "tamper with cursors" check takes
+ place when the operations that insert or delete elements, and
+ so on are called.
+
+86.b/2
+ See Iterate for vectors (*note A.18.2::) for a suggested
+ implementation of the check.
+
+87/2
+{AI95-00302-03AI95-00302-03} Both Containers.Hashed_Set and
+Containers.Ordered_Set declare a nested generic package Generic_Keys,
+which provides operations that allow set manipulation in terms of a key
+(typically, a portion of an element) instead of a complete element. The
+formal function Key of Generic_Keys extracts a key value from an
+element. It is expected to return the same value each time it is called
+with a particular element. The behavior of Generic_Keys is unspecified
+if Key behaves in some other manner.
+
+88/2
+{AI95-00302-03AI95-00302-03} A key is expected to unambiguously
+determine a single equivalence class for elements. The behavior of
+Generic_Keys is unspecified if the formal parameters of this package
+behave in some other manner.
+
+89/2
+ function Key (Position : Cursor) return Key_Type;
+
+90/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Key (Element
+ (Position)).
+
+91/2
+{AI95-00302-03AI95-00302-03} The subprograms in package Generic_Keys
+named Contains, Find, Element, Delete, and Exclude, are equivalent to
+the corresponding subprograms in the parent package, with the difference
+that the Key parameter is used to locate an element in the set.
+
+92/2
+ procedure Replace (Container : in out Set;
+ Key : in Key_Type;
+ New_Item : in Element_Type);
+
+93/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Replace_Element
+ (Container, Find (Container, Key), New_Item).
+
+94/2
+ procedure Update_Element_Preserving_Key
+ (Container : in out Set;
+ Position : in Cursor;
+ Process : not null access procedure
+ (Element : in out Element_Type));
+
+95/3
+ {AI95-00302-03AI95-00302-03} {AI05-0265-1AI05-0265-1} If
+ Position equals No_Element, then Constraint_Error is
+ propagated; if Position does not designate an element in
+ Container, then Program_Error is propagated. Otherwise,
+ Update_Element_Preserving_Key uses Key to save the key value K
+ of the element designated by Position.
+ Update_Element_Preserving_Key then calls Process.all with that
+ element as the argument. Tampering with the elements of
+ Container is prohibited during the execution of the call on
+ Process.all. Any exception raised by Process.all is
+ propagated. After Process.all returns,
+ Update_Element_Preserving_Key checks if K determines the same
+ equivalence class as that for the new element; if not, the
+ element is removed from the set and Program_Error is
+ propagated.
+
+95.a/2
+ Reason: The key check ensures that the invariants of the set
+ are preserved by the modification. The "tampers with the
+ elements" check prevents data loss (if Element_Type is
+ by-copy) or erroneous execution (if element type is
+ unconstrained and indefinite).
+
+96/2
+ If Element_Type is unconstrained and definite, then the actual
+ Element parameter of Process.all shall be unconstrained.
+
+96.a/2
+ Ramification: This means that the elements cannot be directly
+ allocated from the heap; it must be possible to change the
+ discriminants of the element in place.
+
+96.1/3
+ type Reference_Type (Element : not null access Element_Type) is private
+ with Implicit_Dereference => Element;
+
+96.2/3
+ {AI05-0212-1AI05-0212-1} The type Reference_Type needs
+ finalization.
+
+96.3/3
+ The default initialization of an object of type Reference_Type
+ propagates Program_Error.
+
+96.4/3
+ function Reference_Preserving_Key (Container : aliased in out Set;
+ Position : in Cursor)
+ return Reference_Type;
+
+96.5/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Implicit_Dereference aspect)
+ provides a convenient way to gain read and write access to an
+ individual element of a set given a cursor.
+
+96.6/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1} If Position
+ equals No_Element, then Constraint_Error is propagated; if
+ Position does not designate an element in Container, then
+ Program_Error is propagated. Otherwise,
+ Reference_Preserving_Key uses Key to save the key value K;
+ then returns an object whose discriminant is an access value
+ that designates the element designated by Position. Tampering
+ with the elements of Container is prohibited while the object
+ returned by Reference_Preserving_Key exists and has not been
+ finalized. When the object returned by
+ Reference_Preserving_Key is finalized, a check is made if K
+ determines the same equivalence class as that for the new
+ element; if not, the element is removed from the set and
+ Program_Error is propagated.
+
+96.7/3
+ function Constant_Reference (Container : aliased in Set;
+ Key : in Key_Type)
+ return Constant_Reference_Type;
+
+96.8/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Implicit_Dereference aspect)
+ provides a convenient way to gain read access to an individual
+ element of a set given a key value.
+
+96.9/3
+ Equivalent to Constant_Reference (Container, Find (Container,
+ Key)).
+
+96.10/3
+ function Reference_Preserving_Key (Container : aliased in out Set;
+ Key : in Key_Type)
+ return Reference_Type;
+
+96.11/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Implicit_Dereference aspect)
+ provides a convenient way to gain read and write access to an
+ individual element of a set given a key value.
+
+96.12/3
+ Equivalent to Reference_Preserving_Key (Container, Find
+ (Container, Key)).
+
+ _Bounded (Run-Time) Errors_
+
+96.13/3
+{AI05-0022-1AI05-0022-1} {AI05-0248-1AI05-0248-1} It is a bounded error
+for the actual function associated with a generic formal subprogram,
+when called as part of an operation of a set package, to tamper with
+elements of any set parameter of the operation. Either Program_Error is
+raised, or the operation works as defined on the value of the set either
+prior to, or subsequent to, some or all of the modifications to the set.
+
+96.14/3
+{AI05-0027-1AI05-0027-1} It is a bounded error to call any subprogram
+declared in the visible part of a set package when the associated
+container has been finalized. If the operation takes Container as an in
+out parameter, then it raises Constraint_Error or Program_Error.
+Otherwise, the operation either proceeds as it would for an empty
+container, or it raises Constraint_Error or Program_Error.
+
+ _Erroneous Execution_
+
+97/2
+{AI95-00302-03AI95-00302-03} A Cursor value is invalid if any of the
+following have occurred since it was created:
+
+98/2
+ * The set that contains the element it designates has been finalized;
+
+98.1/3
+ * {AI05-0160-1AI05-0160-1} The set that contains the element it
+ designates has been used as the Target of a call to Assign, or as
+ the target of an assignment_statement;
+
+99/2
+ * The set that contains the element it designates has been used as
+ the Source or Target of a call to Move; or
+
+100/3
+ * {AI05-0160-1AI05-0160-1} {AI05-0262-1AI05-0262-1} The element it
+ designates has been removed from the set that previously contained
+ the element.
+
+100.a/3
+ Ramification: {AI05-0160-1AI05-0160-1} This can happen
+ directly via calls to Clear, Exclude, Delete, and
+ Update_Element_Preserving_Key, and indirectly via calls to
+ procedures Intersection, Difference, and Symmetric_Difference.
+
+101/2
+{AI95-00302-03AI95-00302-03} The result of "=" or Has_Element is
+unspecified if these functions are called with an invalid cursor
+parameter. Execution is erroneous if any other subprogram declared in
+Containers.Hashed_Sets or Containers.Ordered_Sets is called with an
+invalid cursor parameter.
+
+101.a/2
+ Discussion: The list above is intended to be exhaustive. In
+ other cases, a cursor value continues to designate its
+ original element. For instance, cursor values survive the
+ insertion and deletion of other elements.
+
+101.b/2
+ While it is possible to check for these cases, in many cases
+ the overhead necessary to make the check is substantial in
+ time or space. Implementations are encouraged to check for as
+ many of these cases as possible and raise Program_Error if
+ detected.
+
+101.1/3
+{AI05-0212-1AI05-0212-1} Execution is erroneous if the set associated
+with the result of a call to Reference or Constant_Reference is
+finalized before the result object returned by the call to Reference or
+Constant_Reference is finalized.
+
+101.c/3
+ Reason: Each object of Reference_Type and
+ Constant_Reference_Type probably contains some reference to
+ the originating container. If that container is prematurely
+ finalized (which is only possible via Unchecked_Deallocation,
+ as accessibility checks prevent passing a container to
+ Reference that will not live as long as the result), the
+ finalization of the object of Reference_Type will try to
+ access a nonexistent object. This is a normal case of a
+ dangling pointer created by Unchecked_Deallocation; we have to
+ explicitly mention it here as the pointer in question is not
+ visible in the specification of the type. (This is the same
+ reason we have to say this for invalid cursors.)
+
+ _Implementation Requirements_
+
+102/2
+{AI95-00302-03AI95-00302-03} No storage associated with a Set object
+shall be lost upon assignment or scope exit.
+
+103/3
+{AI95-00302-03AI95-00302-03} {AI05-0262-1AI05-0262-1} The execution of
+an assignment_statement for a set shall have the effect of copying the
+elements from the source set object to the target set object and
+changing the length of the target object to that of the source object.
+
+103.a/3
+ Implementation Note: {AI05-0298-1AI05-0298-1} An assignment of
+ a Set is a "deep" copy; that is the elements are copied as
+ well as the data structures. We say "effect of" in order to
+ allow the implementation to avoid copying elements immediately
+ if it wishes. For instance, an implementation that avoided
+ copying until one of the containers is modified would be
+ allowed. (Note that this implementation would require care,
+ see *note A.18.2:: for more.)
+
+ _Implementation Advice_
+
+104/2
+{AI95-00302-03AI95-00302-03} Move should not copy elements, and should
+minimize copying of internal data structures.
+
+104.a/2
+ Implementation Advice: Move for sets should not copy elements,
+ and should minimize copying of internal data structures.
+
+104.b/2
+ Implementation Note: Usually that can be accomplished simply
+ by moving the pointer(s) to the internal data structures from
+ the Source container to the Target container.
+
+105/2
+{AI95-00302-03AI95-00302-03} If an exception is propagated from a set
+operation, no storage should be lost, nor any elements removed from a
+set unless specified by the operation.
+
+105.a/2
+ Implementation Advice: If an exception is propagated from a
+ set operation, no storage should be lost, nor any elements
+ removed from a set unless specified by the operation.
+
+105.b/2
+ Reason: This is important so that programs can recover from
+ errors. But we don't want to require heroic efforts, so we
+ just require documentation of cases where this can't be
+ accomplished.
+
+ _Wording Changes from Ada 95_
+
+105.c/2
+ {AI95-00302-03AI95-00302-03} This description of sets is new;
+ the extensions are documented with the specific packages.
+
+ _Extensions to Ada 2005_
+
+105.d/3
+ {AI05-0212-1AI05-0212-1} Added reference support to make set
+ containers more convenient to use.
+
+ _Wording Changes from Ada 2005_
+
+105.e/3
+ {AI05-0001-1AI05-0001-1} Added procedure Assign; the extension
+ and incompatibility is documented with the specific packages.
+
+105.f/3
+ {AI05-0001-1AI05-0001-1} Generalized the definition of Move.
+ Specified which elements are read/written by stream
+ attributes.
+
+105.g/3
+ {AI05-0022-1AI05-0022-1} Correction: Added a Bounded
+ (Run-Time) Error to cover tampering by generic actual
+ subprograms.
+
+105.h/3
+ {AI05-0027-1AI05-0027-1} Correction: Added a Bounded
+ (Run-Time) Error to cover access to finalized set containers.
+
+105.i/3
+ {AI05-0160-1AI05-0160-1} Correction: Revised the definition of
+ invalid cursors to cover missing (and new) cases.
+
+105.j/3
+ {AI05-0265-1AI05-0265-1} Correction: Defined when a container
+ prohibits tampering in order to more clearly define where the
+ check is made and the exception raised.
+
+\1f
+File: aarm2012.info, Node: A.18.8, Next: A.18.9, Prev: A.18.7, Up: A.18
+
+A.18.8 The Generic Package Containers.Hashed_Sets
+-------------------------------------------------
+
+ _Static Semantics_
+
+1/2
+{AI95-00302-03AI95-00302-03} The generic library package
+Containers.Hashed_Sets has the following declaration:
+
+2/3
+ {AI05-0084-1AI05-0084-1} {AI05-0212-1AI05-0212-1} with Ada.Iterator_Interfaces;
+ generic
+ type Element_Type is private;
+ with function Hash (Element : Element_Type) return Hash_Type;
+ with function Equivalent_Elements (Left, Right : Element_Type)
+ return Boolean;
+ with function "=" (Left, Right : Element_Type) return Boolean is <>;
+ package Ada.Containers.Hashed_Sets is
+ pragma Preelaborate(Hashed_Sets);
+ pragma Remote_Types(Hashed_Sets);
+
+3/3
+ {AI05-0212-1AI05-0212-1} type Set is tagged private
+ with Constant_Indexing => Constant_Reference,
+ Default_Iterator => Iterate,
+ Iterator_Element => Element_Type;
+ pragma Preelaborable_Initialization(Set);
+
+4/2
+ type Cursor is private;
+ pragma Preelaborable_Initialization(Cursor);
+
+5/2
+ Empty_Set : constant Set;
+
+6/2
+ No_Element : constant Cursor;
+
+6.1/3
+ {AI05-0212-1AI05-0212-1} function Has_Element (Position : Cursor) return Boolean;
+
+6.2/3
+ {AI05-0212-1AI05-0212-1} package Set_Iterator_Interfaces is new
+ Ada.Iterator_Interfaces (Cursor, Has_Element);
+
+7/2
+ function "=" (Left, Right : Set) return Boolean;
+
+8/2
+ function Equivalent_Sets (Left, Right : Set) return Boolean;
+
+9/2
+ function To_Set (New_Item : Element_Type) return Set;
+
+10/2
+ function Capacity (Container : Set) return Count_Type;
+
+11/2
+ procedure Reserve_Capacity (Container : in out Set;
+ Capacity : in Count_Type);
+
+12/2
+ function Length (Container : Set) return Count_Type;
+
+13/2
+ function Is_Empty (Container : Set) return Boolean;
+
+14/2
+ procedure Clear (Container : in out Set);
+
+15/2
+ function Element (Position : Cursor) return Element_Type;
+
+16/2
+ procedure Replace_Element (Container : in out Set;
+ Position : in Cursor;
+ New_Item : in Element_Type);
+
+17/2
+ procedure Query_Element
+ (Position : in Cursor;
+ Process : not null access procedure (Element : in Element_Type));
+
+17.1/3
+ {AI05-0212-1AI05-0212-1} type Constant_Reference_Type
+ (Element : not null access constant Element_Type) is private
+ with Implicit_Dereference => Element;
+
+17.2/3
+ {AI05-0212-1AI05-0212-1} function Constant_Reference (Container : aliased in Set;
+ Position : in Cursor)
+ return Constant_Reference_Type;
+
+17.3/3
+ {AI05-0001-1AI05-0001-1} procedure Assign (Target : in out Set; Source : in Set);
+
+17.4/3
+ {AI05-0001-1AI05-0001-1} function Copy (Source : Set; Capacity : Count_Type := 0) return Set;
+
+18/2
+ procedure Move (Target : in out Set;
+ Source : in out Set);
+
+19/2
+ procedure Insert (Container : in out Set;
+ New_Item : in Element_Type;
+ Position : out Cursor;
+ Inserted : out Boolean);
+
+20/2
+ procedure Insert (Container : in out Set;
+ New_Item : in Element_Type);
+
+21/2
+ procedure Include (Container : in out Set;
+ New_Item : in Element_Type);
+
+22/2
+ procedure Replace (Container : in out Set;
+ New_Item : in Element_Type);
+
+23/2
+ procedure Exclude (Container : in out Set;
+ Item : in Element_Type);
+
+24/2
+ procedure Delete (Container : in out Set;
+ Item : in Element_Type);
+
+25/2
+ procedure Delete (Container : in out Set;
+ Position : in out Cursor);
+
+26/2
+ procedure Union (Target : in out Set;
+ Source : in Set);
+
+27/2
+ function Union (Left, Right : Set) return Set;
+
+28/2
+ function "or" (Left, Right : Set) return Set renames Union;
+
+29/2
+ procedure Intersection (Target : in out Set;
+ Source : in Set);
+
+30/2
+ function Intersection (Left, Right : Set) return Set;
+
+31/2
+ function "and" (Left, Right : Set) return Set renames Intersection;
+
+32/2
+ procedure Difference (Target : in out Set;
+ Source : in Set);
+
+33/2
+ function Difference (Left, Right : Set) return Set;
+
+34/2
+ function "-" (Left, Right : Set) return Set renames Difference;
+
+35/2
+ procedure Symmetric_Difference (Target : in out Set;
+ Source : in Set);
+
+36/2
+ function Symmetric_Difference (Left, Right : Set) return Set;
+
+37/2
+ function "xor" (Left, Right : Set) return Set
+ renames Symmetric_Difference;
+
+38/2
+ function Overlap (Left, Right : Set) return Boolean;
+
+39/2
+ function Is_Subset (Subset : Set;
+ Of_Set : Set) return Boolean;
+
+40/2
+ function First (Container : Set) return Cursor;
+
+41/2
+ function Next (Position : Cursor) return Cursor;
+
+42/2
+ procedure Next (Position : in out Cursor);
+
+43/2
+ function Find (Container : Set;
+ Item : Element_Type) return Cursor;
+
+44/2
+ function Contains (Container : Set;
+ Item : Element_Type) return Boolean;
+
+45/3
+ This paragraph was deleted.{AI05-0212-1AI05-0212-1}
+
+46/2
+ function Equivalent_Elements (Left, Right : Cursor)
+ return Boolean;
+
+47/2
+ function Equivalent_Elements (Left : Cursor;
+ Right : Element_Type)
+ return Boolean;
+
+48/2
+ function Equivalent_Elements (Left : Element_Type;
+ Right : Cursor)
+ return Boolean;
+
+49/2
+ procedure Iterate
+ (Container : in Set;
+ Process : not null access procedure (Position : in Cursor));
+
+49.1/3
+ {AI05-0212-1AI05-0212-1} function Iterate (Container : in Set)
+ return Set_Iterator_Interfaces.Forward_Iterator'Class;
+
+50/2
+ generic
+ type Key_Type (<>) is private;
+ with function Key (Element : Element_Type) return Key_Type;
+ with function Hash (Key : Key_Type) return Hash_Type;
+ with function Equivalent_Keys (Left, Right : Key_Type)
+ return Boolean;
+ package Generic_Keys is
+
+51/2
+ function Key (Position : Cursor) return Key_Type;
+
+52/2
+ function Element (Container : Set;
+ Key : Key_Type)
+ return Element_Type;
+
+53/2
+ procedure Replace (Container : in out Set;
+ Key : in Key_Type;
+ New_Item : in Element_Type);
+
+54/2
+ procedure Exclude (Container : in out Set;
+ Key : in Key_Type);
+
+55/2
+ procedure Delete (Container : in out Set;
+ Key : in Key_Type);
+
+56/2
+ function Find (Container : Set;
+ Key : Key_Type)
+ return Cursor;
+
+57/2
+ function Contains (Container : Set;
+ Key : Key_Type)
+ return Boolean;
+
+58/2
+ procedure Update_Element_Preserving_Key
+ (Container : in out Set;
+ Position : in Cursor;
+ Process : not null access procedure
+ (Element : in out Element_Type));
+
+58.1/3
+ {AI05-0212-1AI05-0212-1} type Reference_Type
+ (Element : not null access Element_Type) is private
+ with Implicit_Dereference => Element;
+
+58.2/3
+ {AI05-0212-1AI05-0212-1} function Reference_Preserving_Key (Container : aliased in out Set;
+ Position : in Cursor)
+ return Reference_Type;
+
+58.3/3
+ {AI05-0212-1AI05-0212-1} function Constant_Reference (Container : aliased in Set;
+ Key : in Key_Type)
+ return Constant_Reference_Type;
+
+58.4/3
+ {AI05-0212-1AI05-0212-1} function Reference_Preserving_Key (Container : aliased in out Set;
+ Key : in Key_Type)
+ return Reference_Type;
+
+59/2
+ end Generic_Keys;
+
+60/2
+ private
+
+61/2
+ ... -- not specified by the language
+
+62/2
+ end Ada.Containers.Hashed_Sets;
+
+63/2
+{AI95-00302-03AI95-00302-03} An object of type Set contains an
+expandable hash table, which is used to provide direct access to
+elements. The capacity of an object of type Set is the maximum number
+of elements that can be inserted into the hash table prior to it being
+automatically expanded.
+
+64/2
+{AI95-00302-03AI95-00302-03} Two elements E1 and E2 are defined to be
+equivalent if Equivalent_Elements (E1, E2) returns True.
+
+65/2
+{AI95-00302-03AI95-00302-03} The actual function for the generic formal
+function Hash is expected to return the same value each time it is
+called with a particular element value. For any two equivalent
+elements, the actual for Hash is expected to return the same value. If
+the actual for Hash behaves in some other manner, the behavior of this
+package is unspecified. Which subprograms of this package call Hash,
+and how many times they call it, is unspecified.
+
+66/2
+{AI95-00302-03AI95-00302-03} The actual function for the generic formal
+function Equivalent_Elements is expected to return the same value each
+time it is called with a particular pair of Element values. It should
+define an equivalence relationship, that is, be reflexive, symmetric,
+and transitive. If the actual for Equivalent_Elements behaves in some
+other manner, the behavior of this package is unspecified. Which
+subprograms of this package call Equivalent_Elements, and how many times
+they call it, is unspecified.
+
+66.1/3
+{AI05-0044-1AI05-0044-1} If the actual function for the generic formal
+function "=" returns True for any pair of nonequivalent elements, then
+the behavior of the container function "=" is unspecified.
+
+67/2
+{AI95-00302-03AI95-00302-03} If the value of an element stored in a set
+is changed other than by an operation in this package such that at least
+one of Hash or Equivalent_Elements give different results, the behavior
+of this package is unspecified.
+
+67.a/2
+ Discussion: See *note A.18.5::, "*note A.18.5:: The Generic
+ Package Containers.Hashed_Maps" for a suggested
+ implementation, and for justification of the restrictions
+ regarding Hash and Equivalent_Elements. Note that sets only
+ need to store elements, not key/element pairs.
+
+68/2
+{AI95-00302-03AI95-00302-03} Which elements are the first element and
+the last element of a set, and which element is the successor of a given
+element, are unspecified, other than the general semantics described in
+*note A.18.7::.
+
+69/2
+ function Capacity (Container : Set) return Count_Type;
+
+70/2
+ {AI95-00302-03AI95-00302-03} Returns the capacity of
+ Container.
+
+71/2
+ procedure Reserve_Capacity (Container : in out Set;
+ Capacity : in Count_Type);
+
+72/2
+ {AI95-00302-03AI95-00302-03} Reserve_Capacity allocates a new
+ hash table such that the length of the resulting set can
+ become at least the value Capacity without requiring an
+ additional call to Reserve_Capacity, and is large enough to
+ hold the current length of Container. Reserve_Capacity then
+ rehashes the elements in Container onto the new hash table.
+ It replaces the old hash table with the new hash table, and
+ then deallocates the old hash table. Any exception raised
+ during allocation is propagated and Container is not modified.
+
+73/2
+ Reserve_Capacity tampers with the cursors of Container.
+
+73.a/2
+ Reason: Reserve_Capacity tampers with the cursors, as
+ rehashing probably will change the relationships of the
+ elements in Container.
+
+74/2
+ procedure Clear (Container : in out Set);
+
+75/2
+ {AI95-00302-03AI95-00302-03} In addition to the semantics
+ described in *note A.18.7::, Clear does not affect the
+ capacity of Container.
+
+75.1/3
+ procedure Assign (Target : in out Set; Source : in Set);
+
+75.2/3
+ {AI05-0001-1AI05-0001-1} {AI05-0248-1AI05-0248-1} In addition
+ to the semantics described in *note A.18.7::, if the length of
+ Source is greater than the capacity of Target,
+ Reserve_Capacity (Target, Length (Source)) is called before
+ assigning any elements.
+
+75.3/3
+ function Copy (Source : Set; Capacity : Count_Type := 0) return Set;
+
+75.4/3
+ {AI05-0001-1AI05-0001-1} Returns a set whose elements are
+ initialized from the elements of Source. If Capacity is 0,
+ then the set capacity is the length of Source; if Capacity is
+ equal to or greater than the length of Source, the set
+ capacity is at least the specified value. Otherwise, the
+ operation propagates Capacity_Error.
+
+76/2
+ procedure Insert (Container : in out Set;
+ New_Item : in Element_Type;
+ Position : out Cursor;
+ Inserted : out Boolean);
+
+77/2
+ {AI95-00302-03AI95-00302-03} In addition to the semantics
+ described in *note A.18.7::, if Length (Container) equals
+ Capacity (Container), then Insert first calls Reserve_Capacity
+ to increase the capacity of Container to some larger value.
+
+78/2
+ function First (Container : Set) return Cursor;
+
+79/2
+ {AI95-00302-03AI95-00302-03} If Length (Container) = 0, then
+ First returns No_Element. Otherwise, First returns a cursor
+ that designates the first hashed element in Container.
+
+80/2
+ function Equivalent_Elements (Left, Right : Cursor)
+ return Boolean;
+
+81/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Equivalent_Elements
+ (Element (Left), Element (Right)).
+
+82/2
+ function Equivalent_Elements (Left : Cursor;
+ Right : Element_Type) return Boolean;
+
+83/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Equivalent_Elements
+ (Element (Left), Right).
+
+84/2
+ function Equivalent_Elements (Left : Element_Type;
+ Right : Cursor) return Boolean;
+
+85/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Equivalent_Elements
+ (Left, Element (Right)).
+
+85.1/3
+ function Iterate (Container : in Set)
+ return Set_Iterator_Interfaces.Forward_Iterator'Class;
+
+85.2/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1}
+ {AI05-0269-1AI05-0269-1} Iterate returns an iterator object
+ (see *note 5.5.1::) that will generate a value for a loop
+ parameter (see *note 5.5.2::) designating each element in
+ Container, starting with the first element and moving the
+ cursor according to the successor relation. Tampering with
+ the cursors of Container is prohibited while the iterator
+ object exists (in particular, in the sequence_of_statements of
+ the loop_statement whose iterator_specification denotes this
+ object). The iterator object needs finalization.
+
+86/2
+{AI95-00302-03AI95-00302-03} For any element E, the actual function for
+the generic formal function Generic_Keys.Hash is expected to be such
+that Hash (E) = Generic_Keys.Hash (Key (E)). If the actuals for Key or
+Generic_Keys.Hash behave in some other manner, the behavior of
+Generic_Keys is unspecified. Which subprograms of Generic_Keys call
+Generic_Keys.Hash, and how many times they call it, is unspecified.
+
+87/2
+{AI95-00302-03AI95-00302-03} For any two elements E1 and E2, the boolean
+values Equivalent_Elements (E1, E2) and Equivalent_Keys (Key (E1), Key
+(E2)) are expected to be equal. If the actuals for Key or
+Equivalent_Keys behave in some other manner, the behavior of
+Generic_Keys is unspecified. Which subprograms of Generic_Keys call
+Equivalent_Keys, and how many times they call it, is unspecified.
+
+ _Implementation Advice_
+
+88/2
+{AI95-00302-03AI95-00302-03} If N is the length of a set, the average
+time complexity of the subprograms Insert, Include, Replace, Delete,
+Exclude and Find that take an element parameter should be O(log N). The
+average time complexity of the subprograms that take a cursor parameter
+should be O(1). The average time complexity of Reserve_Capacity should
+be O(N).
+
+88.a/2
+ Implementation Advice: The average time complexity of the
+ Insert, Include, Replace, Delete, Exclude and Find operations
+ of Containers.Hashed_Sets that take an element parameter
+ should be O(log N). The average time complexity of the
+ subprograms of Containers.Hashed_Sets that take a cursor
+ parameter should be O(1). The average time complexity of
+ Containers.Hashed_Sets.Reserve_Capacity should be O(N).
+
+88.b/2
+ Implementation Note: {AI95-00302-03AI95-00302-03} See *note
+ A.18.5::, "*note A.18.5:: The Generic Package
+ Containers.Hashed_Maps" for implementation notes regarding
+ some of the operations of this package.
+
+ _Extensions to Ada 95_
+
+88.c/2
+ {AI95-00302-03AI95-00302-03} The generic package
+ Containers.Hashed_Sets is new.
+
+ _Incompatibilities With Ada 2005_
+
+88.d/3
+ {AI05-0001-1AI05-0001-1} Subprograms Assign and Copy are added
+ to Containers.Hashed_Sets. If an instance of
+ Containers.Hashed_Sets is referenced in a use_clause, and an
+ entity E with the same defining_identifier as a new entity in
+ Containers.Hashed_Sets is defined in a package that is also
+ referenced in a use_clause, the entity E may no longer be
+ use-visible, resulting in errors. This should be rare and is
+ easily fixed if it does occur.
+
+ _Extensions to Ada 2005_
+
+88.e/3
+ {AI05-0212-1AI05-0212-1} Added iterator and indexing support
+ to make hashed set containers more convenient to use.
+
+ _Wording Changes from Ada 2005_
+
+88.f/3
+ {AI05-0044-1AI05-0044-1} Correction: Added wording to require
+ the formal function be such that equal elements are also
+ equivalent.
+
+88.g/3
+ {AI05-0084-1AI05-0084-1} Correction: Added a pragma
+ Remote_Types so that containers can be used in distributed
+ programs.
+
+\1f
+File: aarm2012.info, Node: A.18.9, Next: A.18.10, Prev: A.18.8, Up: A.18
+
+A.18.9 The Generic Package Containers.Ordered_Sets
+--------------------------------------------------
+
+ _Static Semantics_
+
+1/2
+{AI95-00302-03AI95-00302-03} The generic library package
+Containers.Ordered_Sets has the following declaration:
+
+2/3
+ {AI05-0084-1AI05-0084-1} {AI05-0212-1AI05-0212-1} with Ada.Iterator_Interfaces;
+ generic
+ type Element_Type is private;
+ with function "<" (Left, Right : Element_Type) return Boolean is <>;
+ with function "=" (Left, Right : Element_Type) return Boolean is <>;
+ package Ada.Containers.Ordered_Sets is
+ pragma Preelaborate(Ordered_Sets);
+ pragma Remote_Types(Ordered_Sets);
+
+3/2
+ function Equivalent_Elements (Left, Right : Element_Type) return Boolean;
+
+4/3
+ {AI05-0212-1AI05-0212-1} type Set is tagged private
+ with Constant_Indexing => Constant_Reference,
+ Default_Iterator => Iterate,
+ Iterator_Element => Element_Type;
+ pragma Preelaborable_Initialization(Set);
+
+5/2
+ type Cursor is private;
+ pragma Preelaborable_Initialization(Cursor);
+
+6/2
+ Empty_Set : constant Set;
+
+7/2
+ No_Element : constant Cursor;
+
+7.1/3
+ {AI05-0212-1AI05-0212-1} function Has_Element (Position : Cursor) return Boolean;
+
+7.2/3
+ {AI05-0212-1AI05-0212-1} package Set_Iterator_Interfaces is new
+ Ada.Iterator_Interfaces (Cursor, Has_Element);
+
+8/2
+ function "=" (Left, Right : Set) return Boolean;
+
+9/2
+ function Equivalent_Sets (Left, Right : Set) return Boolean;
+
+10/2
+ function To_Set (New_Item : Element_Type) return Set;
+
+11/2
+ function Length (Container : Set) return Count_Type;
+
+12/2
+ function Is_Empty (Container : Set) return Boolean;
+
+13/2
+ procedure Clear (Container : in out Set);
+
+14/2
+ function Element (Position : Cursor) return Element_Type;
+
+15/2
+ procedure Replace_Element (Container : in out Set;
+ Position : in Cursor;
+ New_Item : in Element_Type);
+
+16/2
+ procedure Query_Element
+ (Position : in Cursor;
+ Process : not null access procedure (Element : in Element_Type));
+
+16.1/3
+ {AI05-0212-1AI05-0212-1} type Constant_Reference_Type
+ (Element : not null access constant Element_Type) is private
+ with Implicit_Dereference => Element;
+
+16.2/3
+ {AI05-0212-1AI05-0212-1} function Constant_Reference (Container : aliased in Set;
+ Position : in Cursor)
+ return Constant_Reference_Type;
+
+16.3/3
+ {AI05-0001-1AI05-0001-1} procedure Assign (Target : in out Set; Source : in Set);
+
+16.4/3
+ {AI05-0001-1AI05-0001-1} function Copy (Source : Set) return Set;
+
+17/2
+ procedure Move (Target : in out Set;
+ Source : in out Set);
+
+18/2
+ procedure Insert (Container : in out Set;
+ New_Item : in Element_Type;
+ Position : out Cursor;
+ Inserted : out Boolean);
+
+19/2
+ procedure Insert (Container : in out Set;
+ New_Item : in Element_Type);
+
+20/2
+ procedure Include (Container : in out Set;
+ New_Item : in Element_Type);
+
+21/2
+ procedure Replace (Container : in out Set;
+ New_Item : in Element_Type);
+
+22/2
+ procedure Exclude (Container : in out Set;
+ Item : in Element_Type);
+
+23/2
+ procedure Delete (Container : in out Set;
+ Item : in Element_Type);
+
+24/2
+ procedure Delete (Container : in out Set;
+ Position : in out Cursor);
+
+25/2
+ procedure Delete_First (Container : in out Set);
+
+26/2
+ procedure Delete_Last (Container : in out Set);
+
+27/2
+ procedure Union (Target : in out Set;
+ Source : in Set);
+
+28/2
+ function Union (Left, Right : Set) return Set;
+
+29/2
+ function "or" (Left, Right : Set) return Set renames Union;
+
+30/2
+ procedure Intersection (Target : in out Set;
+ Source : in Set);
+
+31/2
+ function Intersection (Left, Right : Set) return Set;
+
+32/2
+ function "and" (Left, Right : Set) return Set renames Intersection;
+
+33/2
+ procedure Difference (Target : in out Set;
+ Source : in Set);
+
+34/2
+ function Difference (Left, Right : Set) return Set;
+
+35/2
+ function "-" (Left, Right : Set) return Set renames Difference;
+
+36/2
+ procedure Symmetric_Difference (Target : in out Set;
+ Source : in Set);
+
+37/2
+ function Symmetric_Difference (Left, Right : Set) return Set;
+
+38/2
+ function "xor" (Left, Right : Set) return Set renames
+ Symmetric_Difference;
+
+39/2
+ function Overlap (Left, Right : Set) return Boolean;
+
+40/2
+ function Is_Subset (Subset : Set;
+ Of_Set : Set) return Boolean;
+
+41/2
+ function First (Container : Set) return Cursor;
+
+42/2
+ function First_Element (Container : Set) return Element_Type;
+
+43/2
+ function Last (Container : Set) return Cursor;
+
+44/2
+ function Last_Element (Container : Set) return Element_Type;
+
+45/2
+ function Next (Position : Cursor) return Cursor;
+
+46/2
+ procedure Next (Position : in out Cursor);
+
+47/2
+ function Previous (Position : Cursor) return Cursor;
+
+48/2
+ procedure Previous (Position : in out Cursor);
+
+49/2
+ function Find (Container : Set;
+ Item : Element_Type)
+ return Cursor;
+
+50/2
+ function Floor (Container : Set;
+ Item : Element_Type)
+ return Cursor;
+
+51/2
+ function Ceiling (Container : Set;
+ Item : Element_Type)
+ return Cursor;
+
+52/2
+ function Contains (Container : Set;
+ Item : Element_Type) return Boolean;
+
+53/3
+ This paragraph was deleted.{AI05-0212-1AI05-0212-1}
+
+54/2
+ function "<" (Left, Right : Cursor) return Boolean;
+
+55/2
+ function ">" (Left, Right : Cursor) return Boolean;
+
+56/2
+ function "<" (Left : Cursor; Right : Element_Type)
+ return Boolean;
+
+57/2
+ function ">" (Left : Cursor; Right : Element_Type)
+ return Boolean;
+
+58/2
+ function "<" (Left : Element_Type; Right : Cursor)
+ return Boolean;
+
+59/2
+ function ">" (Left : Element_Type; Right : Cursor)
+ return Boolean;
+
+60/2
+ procedure Iterate
+ (Container : in Set;
+ Process : not null access procedure (Position : in Cursor));
+
+61/2
+ procedure Reverse_Iterate
+ (Container : in Set;
+ Process : not null access procedure (Position : in Cursor));
+
+61.1/3
+ {AI05-0212-1AI05-0212-1} function Iterate (Container : in Set)
+ return Set_Iterator_Interfaces.Reversible_Iterator'Class;
+
+61.2/3
+ {AI05-0262-1AI05-0262-1} function Iterate (Container : in Set; Start : in Cursor)
+ return Set_Iterator_Interfaces.Reversible_Iterator'Class;
+
+62/2
+ generic
+ type Key_Type (<>) is private;
+ with function Key (Element : Element_Type) return Key_Type;
+ with function "<" (Left, Right : Key_Type)
+ return Boolean is <>;
+ package Generic_Keys is
+
+63/2
+ function Equivalent_Keys (Left, Right : Key_Type)
+ return Boolean;
+
+64/2
+ function Key (Position : Cursor) return Key_Type;
+
+65/2
+ function Element (Container : Set;
+ Key : Key_Type)
+ return Element_Type;
+
+66/2
+ procedure Replace (Container : in out Set;
+ Key : in Key_Type;
+ New_Item : in Element_Type);
+
+67/2
+ procedure Exclude (Container : in out Set;
+ Key : in Key_Type);
+
+68/2
+ procedure Delete (Container : in out Set;
+ Key : in Key_Type);
+
+69/2
+ function Find (Container : Set;
+ Key : Key_Type)
+ return Cursor;
+
+70/2
+ function Floor (Container : Set;
+ Key : Key_Type)
+ return Cursor;
+
+71/2
+ function Ceiling (Container : Set;
+ Key : Key_Type)
+ return Cursor;
+
+72/2
+ function Contains (Container : Set;
+ Key : Key_Type) return Boolean;
+
+73/2
+ procedure Update_Element_Preserving_Key
+ (Container : in out Set;
+ Position : in Cursor;
+ Process : not null access procedure
+ (Element : in out Element_Type));
+
+73.1/3
+ {AI05-0212-1AI05-0212-1} type Reference_Type
+ (Element : not null access Element_Type) is private
+ with Implicit_Dereference => Element;
+
+73.2/3
+ {AI05-0212-1AI05-0212-1} function Reference_Preserving_Key (Container : aliased in out Set;
+ Position : in Cursor)
+ return Reference_Type;
+
+73.3/3
+ {AI05-0212-1AI05-0212-1} function Constant_Reference (Container : aliased in Set;
+ Key : in Key_Type)
+ return Constant_Reference_Type;
+
+73.4/3
+ {AI05-0212-1AI05-0212-1} function Reference_Preserving_Key (Container : aliased in out Set;
+ Key : in Key_Type)
+ return Reference_Type;
+
+74/2
+ end Generic_Keys;
+
+75/2
+ private
+
+76/2
+ ... -- not specified by the language
+
+77/2
+ end Ada.Containers.Ordered_Sets;
+
+78/2
+{AI95-00302-03AI95-00302-03} Two elements E1 and E2 are equivalent if
+both E1 < E2 and E2 < E1 return False, using the generic formal "<"
+operator for elements. Function Equivalent_Elements returns True if
+Left and Right are equivalent, and False otherwise.
+
+79/3
+{AI95-00302-03AI95-00302-03} {AI05-0044-1AI05-0044-1} The actual
+function for the generic formal function "<" on Element_Type values is
+expected to return the same value each time it is called with a
+particular pair of key values. It should define a strict weak ordering
+relationship (see *note A.18::). If the actual for "<" behaves in some
+other manner, the behavior of this package is unspecified. Which
+subprograms of this package call "<" and how many times they call it, is
+unspecified.
+
+79.1/3
+{AI05-0044-1AI05-0044-1} If the actual function for the generic formal
+function "=" returns True for any pair of nonequivalent elements, then
+the behavior of the container function "=" is unspecified.
+
+80/2
+{AI95-00302-03AI95-00302-03} If the value of an element stored in a set
+is changed other than by an operation in this package such that at least
+one of "<" or "=" give different results, the behavior of this package
+is unspecified.
+
+80.a/2
+ Discussion: See *note A.18.6::, "*note A.18.6:: The Generic
+ Package Containers.Ordered_Maps" for a suggested
+ implementation, and for justification of the restrictions
+ regarding "<" and "=". Note that sets only need to store
+ elements, not key/element pairs.
+
+81/3
+{AI95-00302-03AI95-00302-03} {AI05-0262-1AI05-0262-1} The first element
+of a nonempty set is the one which is less than all the other elements
+in the set. The last element of a nonempty set is the one which is
+greater than all the other elements in the set. The successor of an
+element is the smallest element that is larger than the given element.
+The predecessor of an element is the largest element that is smaller
+than the given element. All comparisons are done using the generic
+formal "<" operator for elements.
+
+81.1/3
+ function Copy (Source : Set) return Set;
+
+81.2/3
+ {AI05-0001-1AI05-0001-1} Returns a set whose elements are
+ initialized from the corresponding elements of Source.
+
+82/2
+ procedure Delete_First (Container : in out Set);
+
+83/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Container is empty, Delete_First has no effect. Otherwise,
+ the element designated by First (Container) is removed from
+ Container. Delete_First tampers with the cursors of
+ Container.
+
+84/2
+ procedure Delete_Last (Container : in out Set);
+
+85/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} If
+ Container is empty, Delete_Last has no effect. Otherwise, the
+ element designated by Last (Container) is removed from
+ Container. Delete_Last tampers with the cursors of Container.
+
+86/2
+ function First_Element (Container : Set) return Element_Type;
+
+87/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Element (First
+ (Container)).
+
+88/2
+ function Last (Container : Set) return Cursor;
+
+89/2
+ {AI95-00302-03AI95-00302-03} Returns a cursor that designates
+ the last element in Container. If Container is empty, returns
+ No_Element.
+
+90/2
+ function Last_Element (Container : Set) return Element_Type;
+
+91/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Element (Last
+ (Container)).
+
+92/2
+ function Previous (Position : Cursor) return Cursor;
+
+93/3
+ {AI95-00302-03AI95-00302-03} {AI05-0262-1AI05-0262-1} If
+ Position equals No_Element, then Previous returns No_Element.
+ Otherwise, Previous returns a cursor designating the
+ predecessor element of the one designated by Position. If
+ Position designates the first element, then Previous returns
+ No_Element.
+
+94/2
+ procedure Previous (Position : in out Cursor);
+
+95/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Position :=
+ Previous (Position).
+
+96/2
+ function Floor (Container : Set;
+ Item : Element_Type) return Cursor;
+
+97/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} Floor
+ searches for the last element which is not greater than Item.
+ If such an element is found, a cursor that designates it is
+ returned. Otherwise, No_Element is returned.
+
+98/2
+ function Ceiling (Container : Set;
+ Item : Element_Type) return Cursor;
+
+99/3
+ {AI95-00302-03AI95-00302-03} {AI05-0264-1AI05-0264-1} Ceiling
+ searches for the first element which is not less than Item.
+ If such an element is found, a cursor that designates it is
+ returned. Otherwise, No_Element is returned.
+
+100/2
+ function "<" (Left, Right : Cursor) return Boolean;
+
+101/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Element (Left) <
+ Element (Right).
+
+102/2
+ function ">" (Left, Right : Cursor) return Boolean;
+
+103/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Element (Right) <
+ Element (Left).
+
+104/2
+ function "<" (Left : Cursor; Right : Element_Type) return Boolean;
+
+105/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Element (Left) <
+ Right.
+
+106/2
+ function ">" (Left : Cursor; Right : Element_Type) return Boolean;
+
+107/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Right < Element
+ (Left).
+
+108/2
+ function "<" (Left : Element_Type; Right : Cursor) return Boolean;
+
+109/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Left < Element
+ (Right).
+
+110/2
+ function ">" (Left : Element_Type; Right : Cursor) return Boolean;
+
+111/2
+ {AI95-00302-03AI95-00302-03} Equivalent to Element (Right) <
+ Left.
+
+112/2
+ procedure Reverse_Iterate
+ (Container : in Set;
+ Process : not null access procedure (Position : in Cursor));
+
+113/3
+ {AI95-00302-03AI95-00302-03} {AI05-0212-1AI05-0212-1} Iterates
+ over the elements in Container as per procedure Iterate, with
+ the difference that the elements are traversed in predecessor
+ order, starting with the last element.
+
+113.1/3
+ function Iterate (Container : in Set)
+ return Set_Iterator_Interfaces.Reversible_Iterator'Class;
+
+113.2/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1}
+ {AI05-0269-1AI05-0269-1} Iterate returns a reversible iterator
+ object (see *note 5.5.1::) that will generate a value for a
+ loop parameter (see *note 5.5.2::) designating each element in
+ Container, starting with the first element and moving the
+ cursor according to the successor relation when used as a
+ forward iterator, and starting with the last element and
+ moving the cursor according to the predecessor relation when
+ used as a reverse iterator. Tampering with the cursors of
+ Container is prohibited while the iterator object exists (in
+ particular, in the sequence_of_statements of the
+ loop_statement whose iterator_specification denotes this
+ object). The iterator object needs finalization.
+
+113.3/3
+ function Iterate (Container : in Set; Start : in Cursor)
+ return Set_Iterator_Interfaces.Reversible_Iterator'Class;
+
+113.4/3
+ {AI05-0262-1AI05-0262-1} {AI05-0265-1AI05-0265-1}
+ {AI05-0269-1AI05-0269-1} If Start is not No_Element and does
+ not designate an item in Container, then Program_Error is
+ propagated. If Start is No_Element, then Constraint_Error is
+ propagated. Otherwise, Iterate returns a reversible iterator
+ object (see *note 5.5.1::) that will generate a value for a
+ loop parameter (see *note 5.5.2::) designating each element in
+ Container, starting with the element designated by Start and
+ moving the cursor according to the successor relation when
+ used as a forward iterator, or moving the cursor according to
+ the predecessor relation when used as a reverse iterator.
+ Tampering with the cursors of Container is prohibited while
+ the iterator object exists (in particular, in the
+ sequence_of_statements of the loop_statement whose
+ iterator_specification denotes this object). The iterator
+ object needs finalization.
+
+113.a/3
+ Discussion: Exits are allowed from the loops created using the
+ iterator objects. In particular, to stop the iteration at a
+ particular cursor, just add
+
+113.b/3
+ exit when Cur = Stop;
+
+113.c/3
+ in the body of the loop (assuming that Cur is the loop
+ parameter and Stop is the cursor that you want to stop at).
+
+114/2
+{AI95-00302-03AI95-00302-03} For any two elements E1 and E2, the boolean
+values (E1 < E2) and (Key(E1) < Key(E2)) are expected to be equal. If
+the actuals for Key or Generic_Keys."<" behave in some other manner, the
+behavior of this package is unspecified. Which subprograms of this
+package call Key and Generic_Keys."<", and how many times the functions
+are called, is unspecified.
+
+115/2
+{AI95-00302-03AI95-00302-03} In addition to the semantics described in
+*note A.18.7::, the subprograms in package Generic_Keys named Floor and
+Ceiling, are equivalent to the corresponding subprograms in the parent
+package, with the difference that the Key subprogram parameter is
+compared to elements in the container using the Key and "<" generic
+formal functions. The function named Equivalent_Keys in package
+Generic_Keys returns True if both Left < Right and Right < Left return
+False using the generic formal "<" operator, and returns True otherwise.
+
+ _Implementation Advice_
+
+116/2
+{AI95-00302-03AI95-00302-03} If N is the length of a set, then the
+worst-case time complexity of the Insert, Include, Replace, Delete,
+Exclude and Find operations that take an element parameter should be
+O((log N)**2) or better. The worst-case time complexity of the
+subprograms that take a cursor parameter should be O(1).
+
+116.a/2
+ Implementation Advice: The worst-case time complexity of the
+ Insert, Include, Replace, Delete, Exclude and Find operations
+ of Containers.Ordered_Sets that take an element parameter
+ should be O((log N)**2). The worst-case time complexity of
+ the subprograms of Containers.Ordered_Sets that take a cursor
+ parameter should be O(1).
+
+116.b/2
+ Implementation Note: {AI95-00302-03AI95-00302-03} See *note
+ A.18.6::, "*note A.18.6:: The Generic Package
+ Containers.Ordered_Maps" for implementation notes regarding
+ some of the operations of this package.
+
+ _Extensions to Ada 95_
+
+116.c/2
+ {AI95-00302-03AI95-00302-03} The generic package
+ Containers.Ordered_Sets is new.
+
+ _Incompatibilities With Ada 2005_
+
+116.d/3
+ {AI05-0001-1AI05-0001-1} Subprograms Assign and Copy are added
+ to Containers.Ordered_Sets. If an instance of
+ Containers.Ordered_Sets is referenced in a use_clause, and an
+ entity E with the same defining_identifier as a new entity in
+ Containers.Ordered_Sets is defined in a package that is also
+ referenced in a use_clause, the entity E may no longer be
+ use-visible, resulting in errors. This should be rare and is
+ easily fixed if it does occur.
+
+ _Extensions to Ada 2005_
+
+116.e/3
+ {AI05-0212-1AI05-0212-1} Added iterator and indexing support
+ to make ordered set containers more convenient to use.
+
+ _Wording Changes from Ada 2005_
+
+116.f/3
+ {AI05-0044-1AI05-0044-1} Correction: Added wording to require
+ the formal function be such that equal elements are also
+ equivalent.
+
+116.g/3
+ {AI05-0044-1AI05-0044-1} Correction: Redefined "<" actuals to
+ require a strict weak ordering; the old definition allowed
+ indeterminant comparisons that would not have worked in a
+ container.
+
+116.h/3
+ {AI05-0084-1AI05-0084-1} Correction: Added a pragma
+ Remote_Types so that containers can be used in distributed
+ programs.
+
+\1f
+File: aarm2012.info, Node: A.18.10, Next: A.18.11, Prev: A.18.9, Up: A.18
+
+A.18.10 The Generic Package Containers.Multiway_Trees
+-----------------------------------------------------
+
+1/3
+{AI05-0136-1AI05-0136-1} The language-defined generic package
+Containers.Multiway_Trees provides private types Tree and Cursor, and a
+set of operations for each type. A multiway tree container is
+well-suited to represent nested structures.
+
+1.a/3
+ Discussion: {AI05-0136-1AI05-0136-1} This tree just provides a
+ basic structure, and make no promises about balancing or other
+ automatic organization. In this sense, it is different than
+ the indexed (Map, Set) forms. Rather, it provides a building
+ block on which to construct more complex and more specialized
+ tree containers.
+
+2/3
+{AI05-0136-1AI05-0136-1} A multiway tree container object manages a tree
+of internal nodes, each of which contains an element and pointers to the
+parent, first child, last child, next (successor) sibling, and previous
+(predecessor) sibling internal nodes. A cursor designates a particular
+node within a tree (and by extension the element contained in that node,
+if any). A cursor keeps designating the same node (and element) as long
+as the node is part of the container, even if the node is moved within
+the container.
+
+3/3
+{AI05-0136-1AI05-0136-1} {AI05-0269-1AI05-0269-1} A subtree is a
+particular node (which roots the subtree) and all of its child nodes
+(including all of the children of the child nodes, recursively). There
+is a special node, the root, which is always present and has neither an
+associated element value nor any parent node. The root node provides a
+place to add nodes to an otherwise empty tree and represents the base of
+the tree.
+
+4/3
+{AI05-0136-1AI05-0136-1} {AI05-0269-1AI05-0269-1} A node that has no
+children is called a leaf node. The ancestors of a node are the node
+itself, its parent node, the parent of the parent node, and so on until
+a node with no parent is reached. Similarly, the descendants of a node
+are the node itself, its child nodes, the children of each child node,
+and so on.
+
+5/3
+{AI05-0136-1AI05-0136-1} {AI05-0262-1AI05-0262-1}
+{AI05-0269-1AI05-0269-1} The nodes of a subtree can be visited in
+several different orders. For a depth-first order, after visiting a
+node, the nodes of its child list are each visited in depth-first order,
+with each child node visited in natural order (first child to last
+child).
+
+5.a/3
+ Ramification: For the depth-first order, when each child node
+ is visited, the child list of the child node is visited before
+ the next sibling of the child node is visited.
+
+ _Static Semantics_
+
+6/3
+{AI05-0136-1AI05-0136-1} The generic library package
+Containers.Multiway_Trees has the following declaration:
+
+7/3
+ {AI05-0136-1AI05-0136-1} {AI05-0212-1AI05-0212-1} with Ada.Iterator_Interfaces;
+ generic
+ type Element_Type is private;
+ with function "=" (Left, Right : Element_Type) return Boolean is <>;
+ package Ada.Containers.Multiway_Trees is
+ pragma Preelaborate(Multiway_Trees);
+ pragma Remote_Types(Multiway_Trees);
+
+8/3
+ {AI05-0136-1AI05-0136-1} {AI05-0212-1AI05-0212-1} type Tree is tagged private
+ with Constant_Indexing => Constant_Reference,
+ Variable_Indexing => Reference,
+ Default_Iterator => Iterate,
+ Iterator_Element => Element_Type;
+ pragma Preelaborable_Initialization(Tree);
+
+9/3
+ type Cursor is private;
+ pragma Preelaborable_Initialization(Cursor);
+
+10/3
+ Empty_Tree : constant Tree;
+
+11/3
+ No_Element : constant Cursor;
+
+12/3
+ function Has_Element (Position : Cursor) return Boolean;
+
+13/3
+ {AI05-0212-1AI05-0212-1} package Tree_Iterator_Interfaces is new
+ Ada.Iterator_Interfaces (Cursor, Has_Element);
+
+14/3
+ function Equal_Subtree (Left_Position : Cursor;
+ Right_Position: Cursor) return Boolean;
+
+15/3
+ function "=" (Left, Right : Tree) return Boolean;
+
+16/3
+ function Is_Empty (Container : Tree) return Boolean;
+
+17/3
+ function Node_Count (Container : Tree) return Count_Type;
+
+18/3
+ function Subtree_Node_Count (Position : Cursor) return Count_Type;
+
+19/3
+ function Depth (Position : Cursor) return Count_Type;
+
+20/3
+ function Is_Root (Position : Cursor) return Boolean;
+
+21/3
+ function Is_Leaf (Position : Cursor) return Boolean;
+
+22/3
+ function Root (Container : Tree) return Cursor;
+
+23/3
+ procedure Clear (Container : in out Tree);
+
+24/3
+ function Element (Position : Cursor) return Element_Type;
+
+25/3
+ procedure Replace_Element (Container : in out Tree;
+ Position : in Cursor;
+ New_Item : in Element_Type);
+
+26/3
+ procedure Query_Element
+ (Position : in Cursor;
+ Process : not null access procedure (Element : in Element_Type));
+
+27/3
+ procedure Update_Element
+ (Container : in out Tree;
+ Position : in Cursor;
+ Process : not null access procedure
+ (Element : in out Element_Type));
+
+28/3
+ {AI05-0212-1AI05-0212-1} type Constant_Reference_Type
+ (Element : not null access constant Element_Type) is private
+ with Implicit_Dereference => Element;
+
+29/3
+ {AI05-0212-1AI05-0212-1} type Reference_Type (Element : not null access Element_Type) is private
+ with Implicit_Dereference => Element;
+
+30/3
+ {AI05-0212-1AI05-0212-1} function Constant_Reference (Container : aliased in Tree;
+ Position : in Cursor)
+ return Constant_Reference_Type;
+
+31/3
+ {AI05-0212-1AI05-0212-1} function Reference (Container : aliased in out Tree;
+ Position : in Cursor)
+ return Reference_Type;
+
+32/3
+ procedure Assign (Target : in out Tree; Source : in Tree);
+
+33/3
+ function Copy (Source : Tree) return Tree;
+
+34/3
+ procedure Move (Target : in out Tree;
+ Source : in out Tree);
+
+35/3
+ procedure Delete_Leaf (Container : in out Tree;
+ Position : in out Cursor);
+
+36/3
+ procedure Delete_Subtree (Container : in out Tree;
+ Position : in out Cursor);
+
+37/3
+ procedure Swap (Container : in out Tree;
+ I, J : in Cursor);
+
+38/3
+ function Find (Container : Tree;
+ Item : Element_Type)
+ return Cursor;
+
+39/3
+ function Find_In_Subtree (Position : Cursor;
+ Item : Element_Type)
+ return Cursor;
+
+40/3
+ function Ancestor_Find (Position : Cursor;
+ Item : Element_Type)
+ return Cursor;
+
+41/3
+ function Contains (Container : Tree;
+ Item : Element_Type) return Boolean;
+
+42/3
+ procedure Iterate
+ (Container : in Tree;
+ Process : not null access procedure (Position : in Cursor));
+
+43/3
+ procedure Iterate_Subtree
+ (Position : in Cursor;
+ Process : not null access procedure (Position : in Cursor));
+
+44/3
+ {AI05-0212-1AI05-0212-1} function Iterate (Container : in Tree)
+ return Tree_Iterator_Interfaces.Forward_Iterator'Class;
+
+45/3
+ {AI05-0212-1AI05-0212-1} function Iterate_Subtree (Position : in Cursor)
+ return Tree_Iterator_Interfaces.Forward_Iterator'Class;
+
+46/3
+ function Child_Count (Parent : Cursor) return Count_Type;
+
+47/3
+ function Child_Depth (Parent, Child : Cursor) return Count_Type;
+
+48/3
+ procedure Insert_Child (Container : in out Tree;
+ Parent : in Cursor;
+ Before : in Cursor;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+49/3
+ procedure Insert_Child (Container : in out Tree;
+ Parent : in Cursor;
+ Before : in Cursor;
+ New_Item : in Element_Type;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+50/3
+ procedure Insert_Child (Container : in out Tree;
+ Parent : in Cursor;
+ Before : in Cursor;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+51/3
+ procedure Prepend_Child (Container : in out Tree;
+ Parent : in Cursor;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+52/3
+ procedure Append_Child (Container : in out Tree;
+ Parent : in Cursor;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+53/3
+ procedure Delete_Children (Container : in out Tree;
+ Parent : in Cursor);
+
+54/3
+ procedure Copy_Subtree (Target : in out Tree;
+ Parent : in Cursor;
+ Before : in Cursor;
+ Source : in Cursor);
+
+55/3
+ procedure Splice_Subtree (Target : in out Tree;
+ Parent : in Cursor;
+ Before : in Cursor;
+ Source : in out Tree;
+ Position : in out Cursor);
+
+56/3
+ procedure Splice_Subtree (Container: in out Tree;
+ Parent : in Cursor;
+ Before : in Cursor;
+ Position : in Cursor);
+
+57/3
+ procedure Splice_Children (Target : in out Tree;
+ Target_Parent : in Cursor;
+ Before : in Cursor;
+ Source : in out Tree;
+ Source_Parent : in Cursor);
+
+58/3
+ procedure Splice_Children (Container : in out Tree;
+ Target_Parent : in Cursor;
+ Before : in Cursor;
+ Source_Parent : in Cursor);
+
+59/3
+ function Parent (Position : Cursor) return Cursor;
+
+60/3
+ function First_Child (Parent : Cursor) return Cursor;
+
+61/3
+ function First_Child_Element (Parent : Cursor) return Element_Type;
+
+62/3
+ function Last_Child (Parent : Cursor) return Cursor;
+
+63/3
+ function Last_Child_Element (Parent : Cursor) return Element_Type;
+
+64/3
+ function Next_Sibling (Position : Cursor) return Cursor;
+
+65/3
+ function Previous_Sibling (Position : Cursor) return Cursor;
+
+66/3
+ procedure Next_Sibling (Position : in out Cursor);
+
+67/3
+ procedure Previous_Sibling (Position : in out Cursor);
+
+68/3
+ procedure Iterate_Children
+ (Parent : in Cursor;
+ Process : not null access procedure (Position : in Cursor));
+
+69/3
+ procedure Reverse_Iterate_Children
+ (Parent : in Cursor;
+ Process : not null access procedure (Position : in Cursor));
+
+70/3
+ {AI05-0212-1AI05-0212-1} function Iterate_Children (Container : in Tree; Parent : in Cursor)
+ return Tree_Iterator_Interfaces.Reversible_Iterator'Class;
+
+71/3
+ private
+ ... -- not specified by the language
+ end Ada.Containers.Multiway_Trees;
+
+72/3
+{AI05-0136-1AI05-0136-1} The actual function for the generic formal
+function "=" on Element_Type values is expected to define a reflexive
+and symmetric relationship and return the same result value each time it
+is called with a particular pair of values. If it behaves in some other
+manner, the functions Find, Reverse_Find, Equal_Subtree, and "=" on tree
+values return an unspecified value. The exact arguments and number of
+calls of this generic formal function by the functions Find,
+Reverse_Find, Equal_Subtree, and "=" on tree values are unspecified.
+
+73/3
+{AI05-0136-1AI05-0136-1} The type Tree is used to represent trees. The
+type Tree needs finalization (see *note 7.6::).
+
+74/3
+{AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1} Empty_Tree represents
+the empty Tree object. It contains only the root node (Node_Count
+(Empty_Tree) returns 1). If an object of type Tree is not otherwise
+initialized, it is initialized to the same value as Empty_Tree.
+
+75/3
+{AI05-0136-1AI05-0136-1} No_Element represents a cursor that designates
+no element. If an object of type Cursor is not otherwise initialized,
+it is initialized to the same value as No_Element.
+
+76/3
+{AI05-0136-1AI05-0136-1} The predefined "=" operator for type Cursor
+returns True if both cursors are No_Element, or designate the same
+element in the same container.
+
+77/3
+{AI05-0136-1AI05-0136-1} Execution of the default implementation of the
+Input, Output, Read, or Write attribute of type Cursor raises
+Program_Error.
+
+78/3
+{AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1}
+{AI05-0262-1AI05-0262-1} Tree'Write for a Tree object T writes
+Node_Count(T) - 1 elements of the tree to the stream. It also may write
+additional information about the tree.
+
+79/3
+{AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1}
+{AI05-0262-1AI05-0262-1} Tree'Read reads the representation of a tree
+from the stream, and assigns to Item a tree with the same elements and
+structure as was written by Tree'Write.
+
+79.a/3
+ Ramification: Streaming more elements than the container holds
+ is wrong. For implementation implications of this rule, see
+ the Implementation Note in *note A.18.2::.
+
+80/3
+{AI05-0136-1AI05-0136-1} [Some operations of this generic package have
+access-to-subprogram parameters. To ensure such operations are
+well-defined, they guard against certain actions by the designated
+subprogram. In particular, some operations check for "tampering with
+cursors" of a container because they depend on the set of elements of
+the container remaining constant, and others check for "tampering with
+elements" of a container because they depend on elements of the
+container not being replaced.]
+
+81/3
+{AI05-0136-1AI05-0136-1} A subprogram is said to tamper with cursors of
+a tree object T if:
+
+82/3
+ * it inserts or deletes elements of T, that is, it calls the Clear,
+ Delete_Leaf, Insert_Child, Delete_Children, Delete_Subtree, or
+ Copy_Subtree procedures with T as a parameter; or
+
+82.a/3
+ To be honest: Operations which are defined to be equivalent to
+ a call on one of these operations also are included.
+ Similarly, operations which call one of these as part of their
+ definition are included.
+
+83/3
+ * {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1} it reorders the
+ elements of T, that is, it calls the Splice_Subtree or
+ Splice_Children procedures with T as a parameter; or
+
+84/3
+ * it finalizes T; or
+
+85/3
+ * it calls Assign with T as the Target parameter; or
+
+85.a.1/3
+ Ramification: We don't need to explicitly mention
+ assignment_statement, because that finalizes the target object
+ as part of the operation, and finalization of an object is
+ already defined as tampering with cursors.
+
+86/3
+ * it calls the Move procedure with T as a parameter.
+
+86.a/3
+ Reason: Swap copies elements rather than reordering them, so
+ it doesn't tamper with cursors.
+
+87/3
+{AI05-0136-1AI05-0136-1} A subprogram is said to tamper with elements of
+a tree object T if:
+
+88/3
+ * it tampers with cursors of T; or
+
+89/3
+ * it replaces one or more elements of T, that is, it calls the
+ Replace_Element or Swap procedures with T as a parameter.
+
+89.a/3
+ Reason: Complete replacement of an element can cause its
+ memory to be deallocated while another operation is holding
+ onto a reference to it. That can't be allowed. However, a
+ simple modification of (part of) an element is not a problem,
+ so Update_Element does not cause a problem.
+
+89.a.1/3
+ Ramification: Assign is defined in terms of Clear and
+ Replace_Element, so we don't need to mention it explicitly.
+ Similarly, we don't need to explicitly mention
+ assignment_statement, because that finalizes the target object
+ as part of the operation, and finalization of an object is
+ already defined as tampering with the element.
+
+90/3
+{AI05-0265-1AI05-0265-1} When tampering with cursors is prohibited for a
+particular tree object T, Program_Error is propagated by a call of any
+language-defined subprogram that is defined to tamper with the cursors
+of T, leaving T unmodified. Similarly, when tampering with elements is
+prohibited for a particular tree object T, Program_Error is propagated
+by a call of any language-defined subprogram that is defined to tamper
+with the elements of T [(or tamper with the cursors of T)], leaving T
+unmodified.
+
+90.a/3
+ Proof: Tampering with elements includes tampering with
+ cursors, so we mention it only from completeness in the second
+ sentence.
+
+91/3
+ function Has_Element (Position : Cursor) return Boolean;
+
+92/3
+ Returns True if Position designates an element, and returns
+ False otherwise. [In particular, Has_Element returns False if
+ the cursor designates a root node or equals No_Element.]
+
+92.a/3
+ To be honest: {AI05-0005-1AI05-0005-1}
+ {AI05-0136-1AI05-0136-1} This function might not detect
+ cursors that designate deleted elements; such cursors are
+ invalid (see below) and the result of calling Has_Element with
+ an invalid cursor is unspecified (but not erroneous).
+
+93/3
+ function Equal_Subtree (Left_Position : Cursor;
+ Right_Position: Cursor) return Boolean;
+
+94/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1}
+ {AI05-0262-1AI05-0262-1} {AI05-0264-1AI05-0264-1} If
+ Left_Position or Right_Position equals No_Element, propagates
+ Constraint_Error. If the number of child nodes of the element
+ designated by Left_Position is different from the number of
+ child nodes of the element designated by Right_Position, the
+ function returns False. If Left_Position designates a root
+ node and Right_Position does not, the function returns False.
+ If Right_Position designates a root node and Left_Position
+ does not, the function returns False. Unless both cursors
+ designate a root node, the elements are compared using the
+ generic formal equality operator. If the result of the
+ element comparison is False, the function returns False.
+ Otherwise, it calls Equal_Subtree on a cursor designating each
+ child element of the element designated by Left_Position and a
+ cursor designating the corresponding child element of the
+ element designated by Right_Position. If any such call
+ returns False, the function returns False; otherwise, it
+ returns True. Any exception raised during the evaluation of
+ element equality is propagated.
+
+94.a/3
+ Ramification: Left_Position and Right_Position do not need to
+ be from the same tree.
+
+94.b/3
+ Implementation Note: This wording describes the canonical
+ semantics. However, the order and number of calls on the
+ formal equality function is unspecified for all of the
+ operations that use it in this package, so an implementation
+ can call it as many or as few times as it needs to get the
+ correct answer. Similarly, a global rule (see the
+ introduction of *note Annex A::) says that language-defined
+ routines are not affected by overriding of other
+ language-defined routines. This means that no reasonable
+ program can tell how many times Equal_Subtree is called, and
+ thus an implementation can call it as many or as few times as
+ it needs to get the correct answer. Specifically, there is no
+ requirement to call the formal equality or Equal_Subtree
+ additional times once the answer has been determined.
+
+95/3
+ function "=" (Left, Right : Tree) return Boolean;
+
+96/3
+ {AI05-0136-1AI05-0136-1} {AI05-0262-1AI05-0262-1} If Left and
+ Right denote the same tree object, then the function returns
+ True. Otherwise, it calls Equal_Subtree with cursors
+ designating the root nodes of Left and Right; the result is
+ returned. Any exception raised during the evaluation of
+ Equal_Subtree is propagated.
+
+96.a/3
+ Implementation Note: Similar considerations apply here as
+ apply to Equal_Subtree. The actual number of calls performed
+ is unspecified.
+
+97/3
+ function Node_Count (Container : Tree) return Count_Type;
+
+98/3
+ {AI05-0136-1AI05-0136-1} Node_Count returns the number of
+ nodes in Container.
+
+98.a/3
+ Ramification: Since all tree objects have a root node, this
+ can never return a value of 0. Node_Count (Some_Tree) should
+ always equal Subtree_Node_Count (Root (Some_Tree)).
+
+99/3
+ function Subtree_Node_Count (Position : Cursor) return Count_Type;
+
+100/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1} If Position
+ is No_Element, Subtree_Node_Count returns 0; otherwise,
+ Subtree_Node_Count returns the number of nodes in the subtree
+ that is rooted by Position.
+
+101/3
+ function Is_Empty (Container : Tree) return Boolean;
+
+102/3
+ {AI05-0136-1AI05-0136-1} Equivalent to Node_Count (Container)
+ = 1.
+
+102.a/3
+ Ramification: An empty tree contains just the root node.
+
+103/3
+ function Depth (Position : Cursor) return Count_Type;
+
+104/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1} If Position
+ equals No_Element, Depth returns 0; otherwise, Depth returns
+ the number of ancestor nodes of the node designated by
+ Position (including the node itself).
+
+104.a/3
+ Ramification: Depth (Root (Some_Tree)) = 1.
+
+105/3
+ function Is_Root (Position : Cursor) return Boolean;
+
+106/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1} Is_Root
+ returns True if the Position designates the root node of some
+ tree; and returns False otherwise.
+
+107/3
+ function Is_Leaf (Position : Cursor) return Boolean;
+
+108/3
+ {AI05-0136-1AI05-0136-1} Is_Leaf returns True if Position
+ designates a node that does not have any child nodes; and
+ returns False otherwise.
+
+108.a/3
+ Ramification: Is_Leaf returns False if passed No_Element,
+ since No_Element does not designate a node. Is_Leaf can be
+ passed a cursor that designates the root node; Is_Leaf will
+ return True if passed the root node of an empty tree.
+
+109/3
+ function Root (Container : Tree) return Cursor;
+
+110/3
+ {AI05-0136-1AI05-0136-1} Root returns a cursor that designates
+ the root node of Container.
+
+110.a/3
+ Ramification: There is always a root node, even in an empty
+ container, so this function never returns No_Element.
+
+111/3
+ procedure Clear (Container : in out Tree);
+
+112/3
+ {AI05-0136-1AI05-0136-1} Removes all the elements from
+ Container.
+
+112.a/3
+ Ramification: The root node is not removed; all trees have a
+ root node.
+
+113/3
+ function Element (Position : Cursor) return Element_Type;
+
+114/3
+ {AI05-0136-1AI05-0136-1} If Position equals No_Element, then
+ Constraint_Error is propagated; if Position designates the
+ root node of a tree, then Program_Error is propagated.
+ Otherwise, Element returns the element designated by Position.
+
+114.a/3
+ Ramification: The root node does not contain an element, so
+ that value cannot be read or written.
+
+115/3
+ procedure Replace_Element (Container : in out Tree;
+ Position : in Cursor;
+ New_Item : in Element_Type);
+
+116/3
+ {AI05-0136-1AI05-0136-1} {AI05-0264-1AI05-0264-1} If Position
+ equals No_Element, then Constraint_Error is propagated; if
+ Position does not designate an element in Container (including
+ if it designates the root node), then Program_Error is
+ propagated. Otherwise, Replace_Element assigns the value
+ New_Item to the element designated by Position.
+
+117/3
+ procedure Query_Element
+ (Position : in Cursor;
+ Process : not null access procedure (Element : in Element_Type));
+
+118/3
+ {AI05-0136-1AI05-0136-1} {AI05-0265-1AI05-0265-1} If Position
+ equals No_Element, then Constraint_Error is propagated; if
+ Position designates the root node of a tree, then
+ Program_Error is propagated. Otherwise, Query_Element calls
+ Process.all with the element designated by Position as the
+ argument. Tampering with the elements of the tree that
+ contains the element designated by Position is prohibited
+ during the execution of the call on Process.all. Any
+ exception raised by Process.all is propagated.
+
+119/3
+ procedure Update_Element
+ (Container : in out Tree;
+ Position : in Cursor;
+ Process : not null access procedure
+ (Element : in out Element_Type));
+
+120/3
+ {AI05-0136-1AI05-0136-1} {AI05-0264-1AI05-0264-1}
+ {AI05-0265-1AI05-0265-1} If Position equals No_Element, then
+ Constraint_Error is propagated; if Position does not designate
+ an element in Container (including if it designates the root
+ node), then Program_Error is propagated. Otherwise,
+ Update_Element calls Process.all with the element designated
+ by Position as the argument. Tampering with the elements of
+ Container is prohibited during the execution of the call on
+ Process.all. Any exception raised by Process.all is
+ propagated.
+
+121/3
+ If Element_Type is unconstrained and definite, then the actual
+ Element parameter of Process.all shall be unconstrained.
+
+121.a/3
+ Ramification: This means that the elements cannot be directly
+ allocated from the heap; it must be possible to change the
+ discriminants of the element in place.
+
+122/3
+ type Constant_Reference_Type
+ (Element : not null access constant Element_Type) is private
+ with Implicit_Dereference => Element;
+
+123/3
+ type Reference_Type (Element : not null access Element_Type) is private
+ with Implicit_Dereference => Element;
+
+124/3
+ {AI05-0212-1AI05-0212-1} The types Constant_Reference_Type and
+ Reference_Type need finalization.
+
+125/3
+ The default initialization of an object of type
+ Constant_Reference_Type or Reference_Type propagates
+ Program_Error.
+
+125.a/3
+ Reason: It is expected that Reference_Type (and
+ Constant_Reference_Type) will be a controlled type, for which
+ finalization will have some action to terminate the tampering
+ check for the associated container. If the object is created
+ by default, however, there is no associated container. Since
+ this is useless, and supporting this case would take extra
+ work, we define it to raise an exception.
+
+126/3
+ function Constant_Reference (Container : aliased in Tree;
+ Position : in Cursor)
+ return Constant_Reference_Type;
+
+127/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Constant_Indexing and
+ Implicit_Dereference aspects) provides a convenient way to
+ gain read access to an individual element of a tree given a
+ cursor.
+
+128/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1} If Position
+ equals No_Element, then Constraint_Error is propagated; if
+ Position does not designate an element in Container, then
+ Program_Error is propagated. Otherwise, Constant_Reference
+ returns an object whose discriminant is an access value that
+ designates the element designated by Position. Tampering with
+ the elements of Container is prohibited while the object
+ returned by Constant_Reference exists and has not been
+ finalized.
+
+129/3
+ function Reference (Container : aliased in out Tree;
+ Position : in Cursor)
+ return Reference_Type;
+
+130/3
+ {AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} This
+ function (combined with the Variable_Indexing and
+ Implicit_Dereference aspects) provides a convenient way to
+ gain read and write access to an individual element of a tree
+ given a cursor.
+
+131/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1} If Position
+ equals No_Element, then Constraint_Error is propagated; if
+ Position does not designate an element in Container, then
+ Program_Error is propagated. Otherwise, Reference returns an
+ object whose discriminant is an access value that designates
+ the element designated by Position. Tampering with the
+ elements of Container is prohibited while the object returned
+ by Reference exists and has not been finalized.
+
+132/3
+ procedure Assign (Target : in out Tree; Source : in Tree);
+
+133/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1} If Target
+ denotes the same object as Source, the operation has no
+ effect. Otherwise, the elements of Source are copied to
+ Target as for an assignment_statement assigning Source to
+ Target.
+
+133.a/3
+ Ramification: Each element in Target has a parent element that
+ corresponds to the parent element of the Source element, and
+ has child elements that correspond to the child elements of
+ the Source element.
+
+133.b/3
+ Discussion: {AI05-0005-1AI05-0005-1} This routine exists for
+ compatibility with the bounded tree container. For an
+ unbounded tree, Assign(A, B) and A := B behave identically.
+ For a bounded tree, := will raise an exception if the
+ container capacities are different, while Assign will not
+ raise an exception if there is enough room in the target.
+
+134/3
+ function Copy (Source : Tree) return Tree;
+
+135/3
+ {AI05-0136-1AI05-0136-1} Returns a tree with the same
+ structure as Source and whose elements are initialized from
+ the corresponding elements of Source.
+
+136/3
+ procedure Move (Target : in out Tree;
+ Source : in out Tree);
+
+137/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1} If Target
+ denotes the same object as Source, then the operation has no
+ effect. Otherwise, Move first calls Clear (Target). Then,
+ the nodes other than the root node in Source are moved to
+ Target (in the same positions). After Move completes,
+ Node_Count (Target) is the number of nodes originally in
+ Source, and Node_Count (Source) is 1.
+
+138/3
+ procedure Delete_Leaf (Container : in out Tree;
+ Position : in out Cursor);
+
+139/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1} If Position
+ equals No_Element, then Constraint_Error is propagated; if
+ Position does not designate an element in Container (including
+ if it designates the root node), then Program_Error is
+ propagated. If the element designated by position has any
+ child elements, then Constraint_Error is propagated.
+ Otherwise, Delete_Leaf removes (from Container) the element
+ designated by Position. Finally, Position is set to
+ No_Element.
+
+139.a/3
+ Ramification: The check on Position checks that the cursor
+ does not belong to some other Container. This check implies
+ that a reference to the container is included in the cursor
+ value. This wording is not meant to require detection of
+ dangling cursors; such cursors are defined to be invalid,
+ which means that execution is erroneous, and any result is
+ allowed (including not raising an exception).
+
+139.b/3
+ The root node cannot be deleted.
+
+140/3
+ procedure Delete_Subtree (Container : in out Tree;
+ Position : in out Cursor);
+
+141/3
+ {AI05-0136-1AI05-0136-1} {AI05-0264-1AI05-0264-1}
+ {AI05-0269-1AI05-0269-1} If Position equals No_Element, then
+ Constraint_Error is propagated. If Position does not
+ designate an element in Container (including if it designates
+ the root node), then Program_Error is propagated. Otherwise,
+ Delete_Subtree removes (from Container) the subtree designated
+ by Position (that is, all descendants of the node designated
+ by Position including the node itself), and Position is set to
+ No_Element.
+
+141.a/3
+ Ramification: The root node cannot be deleted. To delete the
+ entire contents of the tree, call Clear(Container).
+
+142/3
+ procedure Swap (Container : in out Tree;
+ I, J : in Cursor);
+
+143/3
+ {AI05-0136-1AI05-0136-1} If either I or J equals No_Element,
+ then Constraint_Error is propagated. If either I or J do not
+ designate an element in Container (including if either
+ designates the root node), then Program_Error is propagated.
+ Otherwise, Swap exchanges the values of the elements
+ designated by I and J.
+
+143.a/3
+ Ramification: After a call to Swap, I designates the element
+ value previously designated by J, and J designates the element
+ value previously designated by I. The position of the elements
+ do not change; for instance, the parent node and the first
+ child node of I are unchanged by the operation.
+
+143.b/3
+ The root nodes do not contain element values, so they cannot
+ be swapped.
+
+143.c/3
+ To be honest: The implementation is not required to actually
+ copy the elements if it can do the swap some other way. But
+ it is allowed to copy the elements if needed.
+
+144/3
+ function Find (Container : Tree;
+ Item : Element_Type)
+ return Cursor;
+
+145/3
+ {AI05-0136-1AI05-0136-1} {AI05-0262-1AI05-0262-1} Find
+ searches the elements of Container for an element equal to
+ Item (using the generic formal equality operator). The search
+ starts at the root node. The search traverses the tree in a
+ depth-first order. If no equal element is found, then Find
+ returns No_Element. Otherwise, it returns a cursor
+ designating the first equal element encountered.
+
+146/3
+ function Find_In_Subtree (Position : Cursor;
+ Item : Element_Type)
+ return Cursor;
+
+147/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1}
+ {AI05-0262-1AI05-0262-1} If Position equals No_Element, then
+ Constraint_Error is propagated. Find_In_Subtree searches the
+ subtree rooted by Position for an element equal to Item (using
+ the generic formal equality operator). The search starts at
+ the element designated by Position. The search traverses the
+ subtree in a depth-first order. If no equal element is found,
+ then Find returns No_Element. Otherwise, it returns a cursor
+ designating the first equal element encountered.
+
+147.a/3
+ Ramification: Find_In_Subtree does not check any siblings of
+ the element designated by Position. The root node does not
+ contain an element, and therefore it can never be returned,
+ but it can be explicitly passed to Position.
+
+148/3
+ function Ancestor_Find (Position : Cursor;
+ Item : Element_Type)
+ return Cursor;
+
+149/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1} If Position
+ equals No_Element, then Constraint_Error is propagated.
+ Otherwise, Ancestor_Find searches for an element equal to Item
+ (using the generic formal equality operator). The search
+ starts at the node designated by Position, and checks each
+ ancestor proceeding toward the root of the subtree. If no
+ equal element is found, then Ancestor_Find returns No_Element.
+ Otherwise, it returns a cursor designating the first equal
+ element encountered.
+
+149.a/3
+ Ramification: {AI05-0248-1AI05-0248-1} No_Element is returned
+ if Position is the root node.
+
+150/3
+ function Contains (Container : Tree;
+ Item : Element_Type) return Boolean;
+
+151/3
+ {AI05-0136-1AI05-0136-1} Equivalent to Find (Container, Item)
+ /= No_Element.
+
+152/3
+ procedure Iterate
+ (Container : in Tree;
+ Process : not null access procedure (Position : in Cursor));
+
+153/3
+ {AI05-0136-1AI05-0136-1} {AI05-0265-1AI05-0265-1} Iterate
+ calls Process.all with a cursor that designates each element
+ in Container, starting with the root node and proceeding in a
+ depth-first order. Tampering with the cursors of Container is
+ prohibited during the execution of a call on Process.all. Any
+ exception raised by Process.all is propagated.
+
+153.a/3
+ Ramification: Process is not called with the root node, which
+ does not have an associated element.
+
+153.b/3
+ Implementation Note: The purpose of the tamper with cursors
+ check is to prevent erroneous execution from the Position
+ parameter of Process.all becoming invalid. This check takes
+ place when the operations that tamper with the cursors of the
+ container are called. The check cannot be made later (say in
+ the body of Iterate), because that could cause the Position
+ cursor to be invalid and potentially cause execution to become
+ erroneous -- defeating the purpose of the check.
+
+153.c/3
+ See Iterate for vectors (*note A.18.2::) for a suggested
+ implementation of the check.
+
+154/3
+ procedure Iterate_Subtree
+ (Position : in Cursor;
+ Process : not null access procedure (Position : in Cursor));
+
+155/3
+ {AI05-0136-1AI05-0136-1} {AI05-0265-1AI05-0265-1} If Position
+ equals No_Element, then Constraint_Error is propagated.
+ Otherwise, Iterate_Subtree calls Process.all with a cursor
+ that designates each element in the subtree rooted by the node
+ designated by Position, starting with the node designated by
+ Position and proceeding in a depth-first order. Tampering
+ with the cursors of the tree that contains the element
+ designated by Position is prohibited during the execution of a
+ call on Process.all. Any exception raised by Process.all is
+ propagated.
+
+155.a/3
+ Ramification: Position can be passed a cursor designating the
+ root node; in that case, Process is not called with the root
+ node, which does not have an associated element.
+
+156/3
+ function Iterate (Container : in Tree)
+ return Tree_Iterator_Interfaces.Forward_Iterator'Class;
+
+157/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1}
+ {AI05-0269-1AI05-0269-1} Iterate returns an iterator object
+ (see *note 5.5.1::) that will generate a value for a loop
+ parameter (see *note 5.5.2::) designating each node in
+ Container, starting with the root node and proceeding in a
+ depth-first order. Tampering with the cursors of Container is
+ prohibited while the iterator object exists (in particular, in
+ the sequence_of_statements of the loop_statement whose
+ iterator_specification denotes this object). The iterator
+ object needs finalization.
+
+157.a/3
+ Discussion: Exits are allowed from the loops created using the
+ iterator objects. In particular, to stop the iteration at a
+ particular cursor, just add
+
+157.b/3
+ exit when Cur = Stop;
+
+157.c/3
+ in the body of the loop (assuming that Cur is the loop
+ parameter and Stop is the cursor that you want to stop at).
+
+158/3
+ function Iterate_Subtree (Position : in Cursor)
+ return Tree_Iterator_Interfaces.Forward_Iterator'Class;
+
+159/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1}
+ {AI05-0269-1AI05-0269-1} If Position equals No_Element, then
+ Constraint_Error is propagated. Otherwise, Iterate_Subtree
+ returns an iterator object (see *note 5.5.1::) that will
+ generate a value for a loop parameter (see *note 5.5.2::)
+ designating each element in the subtree rooted by the node
+ designated by Position, starting with the node designated by
+ Position and proceeding in a depth-first order. If Position
+ equals No_Element, then Constraint_Error is propagated.
+ Tampering with the cursors of the container that contains the
+ node designated by Position is prohibited while the iterator
+ object exists (in particular, in the sequence_of_statements of
+ the loop_statement whose iterator_specification denotes this
+ object). The iterator object needs finalization.
+
+160/3
+ function Child_Count (Parent : Cursor) return Count_Type;
+
+161/3
+ {AI05-0136-1AI05-0136-1} Child_Count returns the number of
+ child nodes of the node designated by Parent.
+
+162/3
+ function Child_Depth (Parent, Child : Cursor) return Count_Type;
+
+163/3
+ {AI05-0136-1AI05-0136-1} {AI05-0262-1AI05-0262-1} If Child or
+ Parent is equal to No_Element, then Constraint_Error is
+ propagated. Otherwise, Child_Depth returns the number of
+ ancestor nodes of Child (including Child itself), up to but
+ not including Parent; Program_Error is propagated if Parent is
+ not an ancestor of Child.
+
+163.a/3
+ Ramification: Program_Error is propagated if Parent and Child
+ are nodes in different containers.
+
+163.b/3
+ Child_Depth (Root (Some_Tree), Child) + 1 = Depth (Child) as
+ the root is not counted.
+
+164/3
+ procedure Insert_Child (Container : in out Tree;
+ Parent : in Cursor;
+ Before : in Cursor;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+165/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1}
+ {AI05-0262-1AI05-0262-1} If Parent equals No_Element, then
+ Constraint_Error is propagated. If Parent does not designate
+ a node in Container, then Program_Error is propagated. If
+ Before is not equal to No_Element, and does not designate a
+ node in Container, then Program_Error is propagated. If
+ Before is not equal to No_Element, and Parent does not
+ designate the parent node of the node designated by Before,
+ then Constraint_Error is propagated. Otherwise, Insert_Child
+ allocates Count nodes containing copies of New_Item and
+ inserts them as children of Parent. If Parent already has
+ child nodes, then the new nodes are inserted prior to the node
+ designated by Before, or, if Before equals No_Element, the new
+ nodes are inserted after the last existing child node of
+ Parent. Any exception raised during allocation of internal
+ storage is propagated, and Container is not modified.
+
+166/3
+ procedure Insert_Child (Container : in out Tree;
+ Parent : in Cursor;
+ Before : in Cursor;
+ New_Item : in Element_Type;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+167/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1}
+ {AI05-0257-1AI05-0257-1} {AI05-0262-1AI05-0262-1} If Parent
+ equals No_Element, then Constraint_Error is propagated. If
+ Parent does not designate a node in Container, then
+ Program_Error is propagated. If Before is not equal to
+ No_Element, and does not designate a node in Container, then
+ Program_Error is propagated. If Before is not equal to
+ No_Element, and Parent does not designate the parent node of
+ the node designated by Before, then Constraint_Error is
+ propagated. Otherwise, Insert_Child allocates Count nodes
+ containing copies of New_Item and inserts them as children of
+ Parent. If Parent already has child nodes, then the new nodes
+ are inserted prior to the node designated by Before, or, if
+ Before equals No_Element, the new nodes are inserted after the
+ last existing child node of Parent. Position designates the
+ first newly-inserted node, or if Count equals 0, then Position
+ is assigned the value of Before. Any exception raised during
+ allocation of internal storage is propagated, and Container is
+ not modified.
+
+168/3
+ procedure Insert_Child (Container : in out Tree;
+ Parent : in Cursor;
+ Before : in Cursor;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+169/3
+ {AI05-0136-1AI05-0136-1} {AI05-0257-1AI05-0257-1}
+ {AI05-0262-1AI05-0262-1} {AI05-0264-1AI05-0264-1} If Parent
+ equals No_Element, then Constraint_Error is propagated. If
+ Parent does not designate a node in Container, then
+ Program_Error is propagated. If Before is not equal to
+ No_Element, and does not designate a node in Container, then
+ Program_Error is propagated. If Before is not equal to
+ No_Element, and Parent does not designate the parent node of
+ the node designated by Before, then Constraint_Error is
+ propagated. Otherwise, Insert_Child allocates Count nodes,
+ the elements contained in the new nodes are initialized by
+ default (see *note 3.3.1::), and the new nodes are inserted as
+ children of Parent. If Parent already has child nodes, then
+ the new nodes are inserted prior to the node designated by
+ Before, or, if Before equals No_Element, the new nodes are
+ inserted after the last existing child node of Parent.
+ Position designates the first newly-inserted node, or if Count
+ equals 0, then Position is assigned the value of Before. Any
+ exception raised during allocation of internal storage is
+ propagated, and Container is not modified.
+
+170/3
+ procedure Prepend_Child (Container : in out Tree;
+ Parent : in Cursor;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+171/3
+ {AI05-0136-1AI05-0136-1} Equivalent to Insert_Child
+ (Container, Parent, First_Child (Container, Parent), New_Item,
+ Count).
+
+172/3
+ procedure Append_Child (Container : in out Tree;
+ Parent : in Cursor;
+ New_Item : in Element_Type;
+ Count : in Count_Type := 1);
+
+173/3
+ {AI05-0136-1AI05-0136-1} {AI05-0269-1AI05-0269-1} Equivalent
+ to Insert_Child (Container, Parent, No_Element, New_Item,
+ Count).
+
+174/3
+ procedure Delete_Children (Container : in out Tree;
+ Parent : in Cursor);
+
+175/3
+ {AI05-0136-1AI05-0136-1} If Parent equals No_Element, then
+ Constraint_Error is propagated. If Parent does not designate
+ a node in Container, Program_Error is propagated. Otherwise,
+ Delete_Children removes (from Container) all of the
+ descendants of Parent other than Parent itself.
+
+175.a/3
+ Discussion: This routine deletes all of the child subtrees of
+ Parent at once. Use Delete_Subtree to delete an individual
+ subtree.
+
+176/3
+ procedure Copy_Subtree (Target : in out Tree;
+ Parent : in Cursor;
+ Before : in Cursor;
+ Source : in Cursor);
+
+177/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1}
+ {AI05-0262-1AI05-0262-1} If Parent equals No_Element, then
+ Constraint_Error is propagated. If Parent does not designate
+ a node in Target, then Program_Error is propagated. If Before
+ is not equal to No_Element, and does not designate a node in
+ Target, then Program_Error is propagated. If Before is not
+ equal to No_Element, and Parent does not designate the parent
+ node of the node designated by Before, then Constraint_Error
+ is propagated. If Source designates a root node, then
+ Constraint_Error is propagated. If Source is equal to
+ No_Element, then the operation has no effect. Otherwise, the
+ subtree rooted by Source (which can be from any tree; it does
+ not have to be a subtree of Target) is copied (new nodes are
+ allocated to create a new subtree with the same structure as
+ the Source subtree, with each element initialized from the
+ corresponding element of the Source subtree) and inserted into
+ Target as a child of Parent. If Parent already has child
+ nodes, then the new nodes are inserted prior to the node
+ designated by Before, or, if Before equals No_Element, the new
+ nodes are inserted after the last existing child node of
+ Parent. The parent of the newly created subtree is set to
+ Parent, and the overall count of Target is incremented by
+ Subtree_Node_Count (Source). Any exception raised during
+ allocation of internal storage is propagated, and Container is
+ not modified.
+
+177.a/3
+ Discussion: We only need one routine here, as the source
+ object is not modified, so we can use the same routine for
+ both copying within and between containers.
+
+177.b/3
+ Ramification: We do not allow copying a subtree that includes
+ a root node, as that would require inserting a node with no
+ value in the middle of the target tree. To copy an entire
+ tree to another tree object, use Copy.
+
+178/3
+ procedure Splice_Subtree (Target : in out Tree;
+ Parent : in Cursor;
+ Before : in Cursor;
+ Source : in out Tree;
+ Position : in out Cursor);
+
+179/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1}
+ {AI05-0262-1AI05-0262-1} {AI05-0269-1AI05-0269-1} If Parent
+ equals No_Element, then Constraint_Error is propagated. If
+ Parent does not designate a node in Target, then Program_Error
+ is propagated. If Before is not equal to No_Element, and does
+ not designate a node in Target, then Program_Error is
+ propagated. If Before is not equal to No_Element, and Parent
+ does not designate the parent node of the node designated by
+ Before, then Constraint_Error is propagated. If Position
+ equals No_Element, Constraint_Error is propagated. If
+ Position does not designate a node in Source or designates a
+ root node, then Program_Error is propagated. If Source
+ denotes the same object as Target, then: if Position equals
+ Before there is no effect; if Position designates an ancestor
+ of Parent (including Parent itself), Constraint_Error is
+ propagated; otherwise, the subtree rooted by the element
+ designated by Position is moved to be a child of Parent. If
+ Parent already has child nodes, then the moved nodes are
+ inserted prior to the node designated by Before, or, if Before
+ equals No_Element, the moved nodes are inserted after the last
+ existing child node of Parent. In each of these cases,
+ Position and the count of Target are unchanged, and the parent
+ of the element designated by Position is set to Parent.
+
+179.a/3
+ Reason: We can't allow moving the subtree of Position to a
+ proper descendant node of the subtree, as the descendant node
+ will be part of the subtree being moved. The result would be
+ a circularly linked tree, or one with inaccessible nodes.
+ Thus we have to check Position against Parent, even though
+ such a check is O(Depth(Source)).
+
+180/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1} Otherwise
+ (if Source does not denote the same object as Target), the
+ subtree designated by Position is removed from Source and
+ moved to Target. The subtree is inserted as a child of
+ Parent. If Parent already has child nodes, then the moved
+ nodes are inserted prior to the node designated by Before, or,
+ if Before equals No_Element, the moved nodes are inserted
+ after the last existing child node of Parent. In each of
+ these cases, the count of Target is incremented by
+ Subtree_Node_Count (Position), and the count of Source is
+ decremented by Subtree_Node_Count (Position), Position is
+ updated to represent an element in Target.
+
+180.a/3
+ Ramification: If Source is the same as Target, and Position =
+ Before, or Next_Sibling(Position) = Before, Splice_Subtree has
+ no effect, as the subtree does not have to move to meet the
+ postcondition.
+
+180.b/3
+ We do not allow splicing a subtree that includes a root node,
+ as that would require inserting a node with no value in the
+ middle of the target tree. Splice the children of the root
+ node instead.
+
+180.c/3
+ For this reason there is no operation to splice an entire
+ tree, as that would necessarily involve splicing a root node.
+
+181/3
+ procedure Splice_Subtree (Container: in out Tree;
+ Parent : in Cursor;
+ Before : in Cursor;
+ Position : in Cursor);
+
+182/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1}
+ {AI05-0262-1AI05-0262-1} {AI05-0269-1AI05-0269-1} If Parent
+ equals No_Element, then Constraint_Error is propagated. If
+ Parent does not designate a node in Container, then
+ Program_Error is propagated. If Before is not equal to
+ No_Element, and does not designate a node in Container, then
+ Program_Error is propagated. If Before is not equal to
+ No_Element, and Parent does not designate the parent node of
+ the node designated by Before, then Constraint_Error is
+ propagated. If Position equals No_Element, Constraint_Error
+ is propagated. If Position does not designate a node in
+ Container or designates a root node, then Program_Error is
+ propagated. If Position equals Before, there is no effect.
+ If Position designates an ancestor of Parent (including Parent
+ itself), Constraint_Error is propagated. Otherwise, the
+ subtree rooted by the element designated by Position is moved
+ to be a child of Parent. If Parent already has child nodes,
+ then the moved nodes are inserted prior to the node designated
+ by Before, or, if Before equals No_Element, the moved nodes
+ are inserted after the last existing child node of Parent.
+ The parent of the element designated by Position is set to
+ Parent.
+
+182.a/3
+ Reason: We can't allow moving the subtree of Position to a
+ proper descendant node of the subtree, as the descendant node
+ will be part of the subtree being moved.
+
+183/3
+ procedure Splice_Children (Target : in out Tree;
+ Target_Parent : in Cursor;
+ Before : in Cursor;
+ Source : in out Tree;
+ Source_Parent : in Cursor);
+
+184/3
+ {AI05-0136-1AI05-0136-1} {AI05-0262-1AI05-0262-1} If
+ Target_Parent equals No_Element, then Constraint_Error is
+ propagated. If Target_Parent does not designate a node in
+ Target, then Program_Error is propagated. If Before is not
+ equal to No_Element, and does not designate an element in
+ Target, then Program_Error is propagated. If Source_Parent
+ equals No_Element, then Constraint_Error is propagated. If
+ Source_Parent does not designate a node in Source, then
+ Program_Error is propagated. If Before is not equal to
+ No_Element, and Target_Parent does not designate the parent
+ node of the node designated by Before, then Constraint_Error
+ is propagated.
+
+185/3
+ If Source denotes the same object as Target, then:
+
+186/3
+ * if Target_Parent equals Source_Parent there is no effect;
+ else
+
+187/3
+ * {AI05-0136-1AI05-0136-1} {AI05-0269-1AI05-0269-1} if
+ Source_Parent is an ancestor of Target_Parent other than
+ Target_Parent itself, then Constraint_Error is
+ propagated; else
+
+188/3
+ * {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1}
+ {AI05-0269-1AI05-0269-1} the child elements (and the
+ further descendants) of Source_Parent are moved to be
+ child elements of Target_Parent. If Target_Parent
+ already has child elements, then the moved elements are
+ inserted prior to the node designated by Before, or, if
+ Before equals No_Element, the moved elements are inserted
+ after the last existing child node of Target_Parent. The
+ parent of each moved child element is set to
+ Target_Parent.
+
+188.a/3
+ Reason: We can't allow moving the children of Source_Parent to
+ a proper descendant node, as the descendant node will be part
+ of one of the subtrees being moved.
+
+189/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1}
+ {AI05-0269-1AI05-0269-1} Otherwise (if Source does not denote
+ the same object as Target), the child elements (and the
+ further descendants) of Source_Parent are removed from Source
+ and moved to Target. The child elements are inserted as
+ children of Target_Parent. If Target_Parent already has child
+ elements, then the moved elements are inserted prior to the
+ node designated by Before, or, if Before equals No_Element,
+ the moved elements are inserted after the last existing child
+ node of Target_Parent. In each of these cases, the overall
+ count of Target is incremented by Subtree_Node_Count
+ (Source_Parent)-1, and the overall count of Source is
+ decremented by Subtree_Node_Count (Source_Parent)-1.
+
+189.a/3
+ Ramification: The node designated by Source_Parent is not
+ moved, thus we never need to update Source_Parent.
+
+189.b/3
+ Move (Target, Source) could be written Splice_Children
+ (Target, Target.Root, No_Element, Source, Source.Root);
+
+190/3
+ procedure Splice_Children (Container : in out Tree;
+ Target_Parent : in Cursor;
+ Before : in Cursor;
+ Source_Parent : in Cursor);
+
+191/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1}
+ {AI05-0262-1AI05-0262-1} {AI05-0264-1AI05-0264-1}
+ {AI05-0269-1AI05-0269-1} If Target_Parent equals No_Element,
+ then Constraint_Error is propagated. If Target_Parent does
+ not designate a node in Container, then Program_Error is
+ propagated. If Before is not equal to No_Element, and does
+ not designate an element in Container, then Program_Error is
+ propagated. If Source_Parent equals No_Element, then
+ Constraint_Error is propagated. If Source_Parent does not
+ designate a node in Container, then Program_Error is
+ propagated. If Before is not equal to No_Element, and
+ Target_Parent does not designate the parent node of the node
+ designated by Before, then Constraint_Error is propagated. If
+ Target_Parent equals Source_Parent there is no effect. If
+ Source_Parent is an ancestor of Target_Parent other than
+ Target_Parent itself, then Constraint_Error is propagated.
+ Otherwise, the child elements (and the further descendants) of
+ Source_Parent are moved to be child elements of Target_Parent.
+ If Target_Parent already has child elements, then the moved
+ elements are inserted prior to the node designated by Before,
+ or, if Before equals No_Element, the moved elements are
+ inserted after the last existing child node of Target_Parent.
+ The parent of each moved child element is set to
+ Target_Parent.
+
+192/3
+ function Parent (Position : Cursor) return Cursor;
+
+193/3
+ {AI05-0136-1AI05-0136-1} If Position is equal to No_Element or
+ designates a root node, No_Element is returned. Otherwise, a
+ cursor designating the parent node of the node designated by
+ Position is returned.
+
+194/3
+ function First_Child (Parent : Cursor) return Cursor;
+
+195/3
+ {AI05-0136-1AI05-0136-1} If Parent is equal to No_Element,
+ then Constraint_Error is propagated. Otherwise, First_Child
+ returns a cursor designating the first child node of the node
+ designated by Parent; if there is no such node, No_Element is
+ returned.
+
+196/3
+ function First_Child_Element (Parent : Cursor) return Element_Type;
+
+197/3
+ {AI05-0136-1AI05-0136-1} Equivalent to Element (First_Child
+ (Parent)).
+
+198/3
+ function Last_Child (Parent : Cursor) return Cursor;
+
+199/3
+ {AI05-0136-1AI05-0136-1} If Parent is equal to No_Element,
+ then Constraint_Error is propagated. Otherwise, Last_Child
+ returns a cursor designating the last child node of the node
+ designated by Parent; if there is no such node, No_Element is
+ returned.
+
+200/3
+ function Last_Child_Element (Parent : Cursor) return Element_Type;
+
+201/3
+ {AI05-0136-1AI05-0136-1} Equivalent to Element (Last_Child
+ (Parent)).
+
+202/3
+ function Next_Sibling (Position : Cursor) return Cursor;
+
+203/3
+ {AI05-0136-1AI05-0136-1} If Position equals No_Element or
+ designates the last child node of its parent, then
+ Next_Sibling returns the value No_Element. Otherwise, it
+ returns a cursor that designates the successor (with the same
+ parent) of the node designated by Position.
+
+204/3
+ function Previous_Sibling (Position : Cursor) return Cursor;
+
+205/3
+ {AI05-0136-1AI05-0136-1} If Position equals No_Element or
+ designates the first child node of its parent, then
+ Previous_Sibling returns the value No_Element. Otherwise, it
+ returns a cursor that designates the predecessor (with the
+ same parent) of the node designated by Position.
+
+206/3
+ procedure Next_Sibling (Position : in out Cursor);
+
+207/3
+ {AI05-0136-1AI05-0136-1} Equivalent to Position :=
+ Next_Sibling (Position);
+
+208/3
+ procedure Previous_Sibling (Position : in out Cursor);
+
+209/3
+ {AI05-0136-1AI05-0136-1} Equivalent to Position :=
+ Previous_Sibling (Position);
+
+210/3
+ procedure Iterate_Children
+ (Parent : in Cursor;
+ Process : not null access procedure (Position : in Cursor));
+
+211/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1} If Parent
+ equals No_Element, then Constraint_Error is propagated.
+
+212/3
+ Iterate_Children calls Process.all with a cursor that
+ designates each child node of Parent, starting with the first
+ child node and moving the cursor as per the Next_Sibling
+ function.
+
+213/3
+ {AI05-0265-1AI05-0265-1} Tampering with the cursors of the
+ tree containing Parent is prohibited during the execution of a
+ call on Process.all. Any exception raised by Process.all is
+ propagated.
+
+214/3
+ procedure Reverse_Iterate_Children
+ (Parent : in Cursor;
+ Process : not null access procedure (Position : in Cursor));
+
+215/3
+ {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1} If Parent
+ equals No_Element, then Constraint_Error is propagated.
+
+216/3
+ Reverse_Iterate_Children calls Process.all with a cursor that
+ designates each child node of Parent, starting with the last
+ child node and moving the cursor as per the Previous_Sibling
+ function.
+
+217/3
+ {AI05-0265-1AI05-0265-1} Tampering with the cursors of the
+ tree containing Parent is prohibited during the execution of a
+ call on Process.all. Any exception raised by Process.all is
+ propagated.
+
+218/3
+ function Iterate_Children (Container : in Tree; Parent : in Cursor)
+ return Tree_Iterator_Interfaces.Reversible_Iterator'Class;
+
+219/3
+ {AI05-0212-1AI05-0212-1} {AI05-0265-1AI05-0265-1}
+ Iterate_Children returns a reversible iterator object (see
+ *note 5.5.1::) that will generate a value for a loop parameter
+ (see *note 5.5.2::) designating each child node of Parent. If
+ Parent equals No_Element, then Constraint_Error is propagated.
+ If Parent does not designate a node in Container, then
+ Program_Error is propagated. Otherwise, when used as a
+ forward iterator, the nodes are designated starting with the
+ first child node and moving the cursor as per the function
+ Next_Sibling; when used as a reverse iterator, the nodes are
+ designated starting with the last child node and moving the
+ cursor as per the function Previous_Sibling. Tampering with
+ the cursors of Container is prohibited while the iterator
+ object exists (in particular, in the sequence_of_statements of
+ the loop_statement whose iterator_specification denotes this
+ object). The iterator object needs finalization.
+
+ _Bounded (Run-Time) Errors_
+
+220/3
+{AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1} It is a bounded error
+for the actual function associated with a generic formal subprogram,
+when called as part of an operation of this package, to tamper with
+elements of any Tree parameter of the operation. Either Program_Error
+is raised, or the operation works as defined on the value of the Tree
+either prior to, or subsequent to, some or all of the modifications to
+the Tree.
+
+221/3
+{AI05-0136-1AI05-0136-1} It is a bounded error to call any subprogram
+declared in the visible part of Containers.Multiway_Trees when the
+associated container has been finalized. If the operation takes
+Container as an in out parameter, then it raises Constraint_Error or
+Program_Error. Otherwise, the operation either proceeds as it would for
+an empty container, or it raises Constraint_Error or Program_Error.
+
+ _Erroneous Execution_
+
+222/3
+{AI05-0136-1AI05-0136-1} A Cursor value is invalid if any of the
+following have occurred since it was created:
+
+223/3
+ * The tree that contains the element it designates has been
+ finalized;
+
+224/3
+ * The tree that contains the element it designates has been used as
+ the Source or Target of a call to Move;
+
+225/3
+ * The tree that contains the element it designates has been used as
+ the Target of a call to Assign or the target of an
+ assignment_statement;
+
+226/3
+ * The element it designates has been removed from the tree that
+ previously contained the element.
+
+226.a/3
+ Reason: We talk about which tree the element was removed from
+ in order to handle splicing nodes from one tree to another.
+ The node still exists, but any cursors that designate it in
+ the original tree are now invalid. This bullet covers
+ removals caused by calls to Clear, Delete_Leaf,
+ Delete_Subtree, Delete_Children, Splice_Children, and
+ Splice_Subtree.
+
+227/3
+The result of "=" or Has_Element is unspecified if it is called with an
+invalid cursor parameter. Execution is erroneous if any other
+subprogram declared in Containers.Multiway_Trees is called with an
+invalid cursor parameter.
+
+227.a/3
+ Discussion: The list above is intended to be exhaustive. In
+ other cases, a cursor value continues to designate its
+ original element (or the root node). For instance, cursor
+ values survive the insertion and deletion of other nodes.
+
+227.b/3
+ While it is possible to check for these cases, in many cases
+ the overhead necessary to make the check is substantial in
+ time or space. Implementations are encouraged to check for as
+ many of these cases as possible and raise Program_Error if
+ detected.
+
+228/3
+{AI05-0212-1AI05-0212-1} Execution is erroneous if the tree associated
+with the result of a call to Reference or Constant_Reference is
+finalized before the result object returned by the call to Reference or
+Constant_Reference is finalized.
+
+228.a/3
+ Reason: Each object of Reference_Type and
+ Constant_Reference_Type probably contains some reference to
+ the originating container. If that container is prematurely
+ finalized (which is only possible via Unchecked_Deallocation,
+ as accessibility checks prevent passing a container to
+ Reference that will not live as long as the result), the
+ finalization of the object of Reference_Type will try to
+ access a nonexistent object. This is a normal case of a
+ dangling pointer created by Unchecked_Deallocation; we have to
+ explicitly mention it here as the pointer in question is not
+ visible in the specification of the type. (This is the same
+ reason we have to say this for invalid cursors.)
+
+ _Implementation Requirements_
+
+229/3
+{AI05-0136-1AI05-0136-1} No storage associated with a multiway tree
+object shall be lost upon assignment or scope exit.
+
+230/3
+{AI05-0136-1AI05-0136-1} {AI05-0262-1AI05-0262-1} The execution of an
+assignment_statement for a tree shall have the effect of copying the
+elements from the source tree object to the target tree object and
+changing the node count of the target object to that of the source
+object.
+
+230.a/3
+ Implementation Note: {AI05-0298-1AI05-0298-1} An assignment of
+ a Tree is a "deep" copy; that is the elements are copied as
+ well the data structures. We say "effect of" in order to
+ allow the implementation to avoid copying elements immediately
+ if it wishes. For instance, an implementation that avoided
+ copying until one of the containers is modified would be
+ allowed. (Note that this implementation would require care,
+ see *note A.18.2:: for more.)
+
+ _Implementation Advice_
+
+231/3
+{AI05-0136-1AI05-0136-1} Containers.Multiway_Trees should be implemented
+similarly to a multiway tree. In particular, if N is the overall number
+of nodes for a particular tree, then the worst-case time complexity of
+Element, Parent, First_Child, Last_Child, Next_Sibling,
+Previous_Sibling, Insert_Child with Count=1, and Delete should be O(log
+N).
+
+231.a/3
+ Implementation Advice: The worst-case time complexity of the
+ Element, Parent, First_Child, Last_Child, Next_Sibling,
+ Previous_Sibling, Insert_Child with Count=1, and Delete
+ operations of Containers.Multiway_Trees should be O(log N).
+
+231.b/3
+ Reason: We do not mean to overly constrain implementation
+ strategies here. However, it is important for portability
+ that the performance of large containers has roughly the same
+ factors on different implementations. If a program is moved
+ to an implementation that takes O(N) time to access elements,
+ that program could be unusable when the trees are large. We
+ allow O(log N) access because the proportionality constant and
+ caching effects are likely to be larger than the log factor,
+ and we don't want to discourage innovative implementations.
+
+232/3
+{AI05-0136-1AI05-0136-1} Move should not copy elements, and should
+minimize copying of internal data structures.
+
+232.a/3
+ Implementation Advice: Containers.Multiway_Trees.Move should
+ not copy elements, and should minimize copying of internal
+ data structures.
+
+232.b/3
+ Implementation Note: Usually that can be accomplished simply
+ by moving the pointer(s) to the internal data structures from
+ the Source container to the Target container.
+
+233/3
+{AI05-0136-1AI05-0136-1} If an exception is propagated from a tree
+operation, no storage should be lost, nor any elements removed from a
+tree unless specified by the operation.
+
+233.a/3
+ Implementation Advice: If an exception is propagated from a
+ tree operation, no storage should be lost, nor any elements
+ removed from a tree unless specified by the operation.
+
+233.b/3
+ Reason: This is important so that programs can recover from
+ errors. But we don't want to require heroic efforts, so we
+ just require documentation of cases where this can't be
+ accomplished.
+
+ _Extensions to Ada 2005_
+
+233.c/3
+ {AI05-0136-1AI05-0136-1} {AI05-0257-1AI05-0257-1}
+ {AI05-0265-1AI05-0265-1} {AI05-0269-1AI05-0269-1} The generic
+ package Containers.Multiway_Trees is new.
+
+\1f
+File: aarm2012.info, Node: A.18.11, Next: A.18.12, Prev: A.18.10, Up: A.18
+
+A.18.11 The Generic Package Containers.Indefinite_Vectors
+---------------------------------------------------------
+
+1/2
+{AI95-00302-03AI95-00302-03} The language-defined generic package
+Containers.Indefinite_Vectors provides a private type Vector and a set
+of operations. It provides the same operations as the package
+Containers.Vectors (see *note A.18.2::), with the difference that the
+generic formal Element_Type is indefinite.
+
+ _Static Semantics_
+
+2/3
+{AI95-00302-03AI95-00302-03} {AI05-0092-1AI05-0092-1} The declaration of
+the generic library package Containers.Indefinite_Vectors has the same
+contents and semantics as Containers.Vectors except:
+
+3/2
+ * The generic formal Element_Type is indefinite.
+
+4/2
+ * The procedures with the profiles:
+
+5/2
+ procedure Insert (Container : in out Vector;
+ Before : in Extended_Index;
+ Count : in Count_Type := 1);
+
+6/2
+ procedure Insert (Container : in out Vector;
+ Before : in Cursor;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+7/2
+ are omitted.
+
+7.a/2
+ Discussion: These procedures are omitted because there is no
+ way to create a default-initialized object of an indefinite
+ type. Note that Insert_Space can be used instead of this
+ routine in most cases. Omitting the routine completely allows
+ any problems to be diagnosed by the compiler when converting
+ from a definite to indefinite vector.
+
+8/2
+ * The actual Element parameter of access subprogram Process of
+ Update_Element may be constrained even if Element_Type is
+ unconstrained.
+
+ _Extensions to Ada 95_
+
+8.a/2
+ {AI95-00302-03AI95-00302-03} The generic package
+ Containers.Indefinite_Vectors is new.
+
+\1f
+File: aarm2012.info, Node: A.18.12, Next: A.18.13, Prev: A.18.11, Up: A.18
+
+A.18.12 The Generic Package Containers.Indefinite_Doubly_Linked_Lists
+---------------------------------------------------------------------
+
+1/2
+{AI95-00302-03AI95-00302-03} The language-defined generic package
+Containers.Indefinite_Doubly_Linked_Lists provides private types List
+and Cursor, and a set of operations for each type. It provides the same
+operations as the package Containers.Doubly_Linked_Lists (see *note
+A.18.3::), with the difference that the generic formal Element_Type is
+indefinite.
+
+ _Static Semantics_
+
+2/3
+{AI95-00302-03AI95-00302-03} {AI05-0092-1AI05-0092-1} The declaration of
+the generic library package Containers.Indefinite_Doubly_Linked_Lists
+has the same contents and semantics as Containers.Doubly_Linked_Lists
+except:
+
+3/2
+ * The generic formal Element_Type is indefinite.
+
+4/2
+ * The procedure with the profile:
+
+5/2
+ procedure Insert (Container : in out List;
+ Before : in Cursor;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+6/2
+ is omitted.
+
+6.a/2
+ Discussion: This procedure is omitted because there is no way
+ to create a default-initialized object of an indefinite type.
+ We considered having this routine insert an empty element
+ similar to the empty elements of a vector, but rejected this
+ possibility because the semantics are fairly complex and very
+ different from the existing definite container. That would
+ make it more error-prone to convert a container from a
+ definite type to an indefinite type; by omitting the routine
+ completely, any problems will be diagnosed by the compiler.
+
+7/2
+ * The actual Element parameter of access subprogram Process of
+ Update_Element may be constrained even if Element_Type is
+ unconstrained.
+
+ _Extensions to Ada 95_
+
+7.a/2
+ {AI95-00302-03AI95-00302-03} The generic package
+ Containers.Indefinite_Doubly_Linked_Lists is new.
+
+\1f
+File: aarm2012.info, Node: A.18.13, Next: A.18.14, Prev: A.18.12, Up: A.18
+
+A.18.13 The Generic Package Containers.Indefinite_Hashed_Maps
+-------------------------------------------------------------
+
+1/2
+{AI95-00302-03AI95-00302-03} The language-defined generic package
+Containers.Indefinite_Hashed_Maps provides a map with the same
+operations as the package Containers.Hashed_Maps (see *note A.18.5::),
+with the difference that the generic formal types Key_Type and
+Element_Type are indefinite.
+
+ _Static Semantics_
+
+2/3
+{AI95-00302-03AI95-00302-03} {AI05-0092-1AI05-0092-1} The declaration of
+the generic library package Containers.Indefinite_Hashed_Maps has the
+same contents and semantics as Containers.Hashed_Maps except:
+
+3/2
+ * The generic formal Key_Type is indefinite.
+
+4/2
+ * The generic formal Element_Type is indefinite.
+
+5/2
+ * The procedure with the profile:
+
+6/2
+ procedure Insert (Container : in out Map;
+ Key : in Key_Type;
+ Position : out Cursor;
+ Inserted : out Boolean);
+
+7/2
+ is omitted.
+
+7.a/2
+ Discussion: This procedure is omitted because there is no way
+ to create a default-initialized object of an indefinite type.
+ We considered having this routine insert an empty element
+ similar to the empty elements of a vector, but rejected this
+ possibility because the semantics are fairly complex and very
+ different from the existing case. That would make it more
+ error-prone to convert a container from a definite type to an
+ indefinite type; by omitting the routine completely, any
+ problems will be diagnosed by the compiler.
+
+8/2
+ * The actual Element parameter of access subprogram Process of
+ Update_Element may be constrained even if Element_Type is
+ unconstrained.
+
+ _Extensions to Ada 95_
+
+8.a/2
+ {AI95-00302-03AI95-00302-03} The generic package
+ Containers.Indefinite_Hashed_Maps is new.
+
+\1f
+File: aarm2012.info, Node: A.18.14, Next: A.18.15, Prev: A.18.13, Up: A.18
+
+A.18.14 The Generic Package Containers.Indefinite_Ordered_Maps
+--------------------------------------------------------------
+
+1/2
+{AI95-00302-03AI95-00302-03} The language-defined generic package
+Containers.Indefinite_Ordered_Maps provides a map with the same
+operations as the package Containers.Ordered_Maps (see *note A.18.6::),
+with the difference that the generic formal types Key_Type and
+Element_Type are indefinite.
+
+ _Static Semantics_
+
+2/3
+{AI95-00302-03AI95-00302-03} {AI05-0092-1AI05-0092-1} The declaration of
+the generic library package Containers.Indefinite_Ordered_Maps has the
+same contents and semantics as Containers.Ordered_Maps except:
+
+3/2
+ * The generic formal Key_Type is indefinite.
+
+4/2
+ * The generic formal Element_Type is indefinite.
+
+5/2
+ * The procedure with the profile:
+
+6/2
+ procedure Insert (Container : in out Map;
+ Key : in Key_Type;
+ Position : out Cursor;
+ Inserted : out Boolean);
+
+7/2
+ is omitted.
+
+7.a/2
+ Discussion: This procedure is omitted because there is no way
+ to create a default-initialized object of an indefinite type.
+ We considered having this routine insert an empty element
+ similar to the empty elements of a vector, but rejected this
+ possibility because the semantics are fairly complex and very
+ different from the existing case. That would make it more
+ error-prone to convert a container from a definite type to an
+ indefinite type; by omitting the routine completely, any
+ problems will be diagnosed by the compiler.
+
+8/2
+ * The actual Element parameter of access subprogram Process of
+ Update_Element may be constrained even if Element_Type is
+ unconstrained.
+
+ _Extensions to Ada 95_
+
+8.a/2
+ {AI95-00302-03AI95-00302-03} The generic package
+ Containers.Indefinite_Ordered_Maps is new.
+
+\1f
+File: aarm2012.info, Node: A.18.15, Next: A.18.16, Prev: A.18.14, Up: A.18
+
+A.18.15 The Generic Package Containers.Indefinite_Hashed_Sets
+-------------------------------------------------------------
+
+1/2
+{AI95-00302-03AI95-00302-03} The language-defined generic package
+Containers.Indefinite_Hashed_Sets provides a set with the same
+operations as the package Containers.Hashed_Sets (see *note A.18.8::),
+with the difference that the generic formal type Element_Type is
+indefinite.
+
+ _Static Semantics_
+
+2/3
+{AI95-00302-03AI95-00302-03} {AI05-0092-1AI05-0092-1} The declaration of
+the generic library package Containers.Indefinite_Hashed_Sets has the
+same contents and semantics as Containers.Hashed_Sets except:
+
+3/2
+ * The generic formal Element_Type is indefinite.
+
+4/2
+ * The actual Element parameter of access subprogram Process of
+ Update_Element_Preserving_Key may be constrained even if
+ Element_Type is unconstrained.
+
+ _Extensions to Ada 95_
+
+4.a/2
+ {AI95-00302-03AI95-00302-03} The generic package
+ Containers.Indefinite_Hashed_Sets is new.
+
+\1f
+File: aarm2012.info, Node: A.18.16, Next: A.18.17, Prev: A.18.15, Up: A.18
+
+A.18.16 The Generic Package Containers.Indefinite_Ordered_Sets
+--------------------------------------------------------------
+
+1/2
+{AI95-00302-03AI95-00302-03} The language-defined generic package
+Containers.Indefinite_Ordered_Sets provides a set with the same
+operations as the package Containers.Ordered_Sets (see *note A.18.9::),
+with the difference that the generic formal type Element_Type is
+indefinite.
+
+ _Static Semantics_
+
+2/3
+{AI95-00302-03AI95-00302-03} {AI05-0092-1AI05-0092-1} The declaration of
+the generic library package Containers.Indefinite_Ordered_Sets has the
+same contents and semantics as Containers.Ordered_Sets except:
+
+3/2
+ * The generic formal Element_Type is indefinite.
+
+4/2
+ * The actual Element parameter of access subprogram Process of
+ Update_Element_Preserving_Key may be constrained even if
+ Element_Type is unconstrained.
+
+ _Extensions to Ada 95_
+
+4.a/2
+ {AI95-00302-03AI95-00302-03} The generic package
+ Containers.Indefinite_Ordered_Sets is new.
+
+\1f
+File: aarm2012.info, Node: A.18.17, Next: A.18.18, Prev: A.18.16, Up: A.18
+
+A.18.17 The Generic Package Containers.Indefinite_Multiway_Trees
+----------------------------------------------------------------
+
+1/3
+{AI05-0136-1AI05-0136-1} The language-defined generic package
+Containers.Indefinite_Multiway_Trees provides a multiway tree with the
+same operations as the package Containers.Multiway_Trees (see *note
+A.18.10::), with the difference that the generic formal Element_Type is
+indefinite.
+
+ _Static Semantics_
+
+2/3
+{AI05-0136-1AI05-0136-1} The declaration of the generic library package
+Containers.Indefinite_Multiway_Trees has the same contents and semantics
+as Containers.Multiway_Trees except:
+
+3/3
+ * The generic formal Element_Type is indefinite.
+
+4/3
+ * The procedure with the profile:
+
+5/3
+ procedure Insert_Child (Container : in out Tree;
+ Parent : in Cursor;
+ Before : in Cursor;
+ Position : out Cursor;
+ Count : in Count_Type := 1);
+
+6/3
+ is omitted.
+
+6.a/3
+ Discussion: This procedure is omitted because there is no way
+ to create a default-initialized object of an indefinite type.
+ We considered having this routine insert an empty element
+ similar to the empty elements of a vector, but rejected this
+ possibility because the semantics are fairly complex and very
+ different from the existing case. That would make it more
+ error-prone to convert a container from a definite type to an
+ indefinite type; by omitting the routine completely, any
+ problems will be diagnosed by the compiler.
+
+7/3
+ * The actual Element parameter of access subprogram Process of
+ Update_Element may be constrained even if Element_Type is
+ unconstrained.
+
+ _Extensions to Ada 2005_
+
+7.a/3
+ {AI05-0136-1AI05-0136-1} The generic package
+ Containers.Indefinite_Multiway_Trees is new.
+
+\1f
+File: aarm2012.info, Node: A.18.18, Next: A.18.19, Prev: A.18.17, Up: A.18
+
+A.18.18 The Generic Package Containers.Indefinite_Holders
+---------------------------------------------------------
+
+1/3
+{AI05-0069-1AI05-0069-1} The language-defined generic package
+Containers.Indefinite_Holders provides a private type Holder and a set
+of operations for that type. A holder container holds a single element
+of an indefinite type.
+
+2/3
+{AI05-0069-1AI05-0069-1} A holder container allows the declaration of an
+object that can be used like an uninitialized variable or component of
+an indefinite type.
+
+3/3
+{AI05-0069-1AI05-0069-1} A holder container may be empty. An empty
+holder does not contain an element.
+
+ _Static Semantics_
+
+4/3
+{AI05-0069-1AI05-0069-1} The generic library package
+Containers.Indefinite_Holders has the following declaration:
+
+5/3
+ {AI05-0069-1AI05-0069-1} {AI05-0084-1AI05-0084-1} generic
+ type Element_Type (<>) is private;
+ with function "=" (Left, Right : Element_Type) return Boolean is <>;
+ package Ada.Containers.Indefinite_Holders is
+ pragma Preelaborate(Indefinite_Holders);
+ pragma Remote_Types(Indefinite_Holders);
+
+6/3
+ type Holder is tagged private;
+ pragma Preelaborable_Initialization (Holder);
+
+7/3
+ Empty_Holder : constant Holder;
+
+8/3
+ function "=" (Left, Right : Holder) return Boolean;
+
+9/3
+ function To_Holder (New_Item : Element_Type) return Holder;
+
+10/3
+ function Is_Empty (Container : Holder) return Boolean;
+
+11/3
+ procedure Clear (Container : in out Holder);
+
+12/3
+ function Element (Container : Holder) return Element_Type;
+
+13/3
+ procedure Replace_Element (Container : in out Holder;
+ New_Item : in Element_Type);
+
+14/3
+ procedure Query_Element
+ (Container : in Holder;
+ Process : not null access procedure (Element : in Element_Type));
+
+15/3
+ {AI05-0069-1AI05-0069-1} {AI05-0248-1AI05-0248-1} procedure Update_Element
+ (Container : in out Holder;
+ Process : not null access procedure (Element : in out Element_Type));
+
+16/3
+ {AI05-0212-1AI05-0212-1} type Constant_Reference_Type
+ (Element : not null access constant Element_Type) is private
+ with Implicit_Dereference => Element;
+
+17/3
+ {AI05-0212-1AI05-0212-1} type Reference_Type (Element : not null access Element_Type) is private
+ with Implicit_Dereference => Element;
+
+18/3
+ {AI05-0212-1AI05-0212-1} function Constant_Reference (Container : aliased in Holder)
+ return Constant_Reference_Type;
+
+19/3
+ {AI05-0212-1AI05-0212-1} function Reference (Container : aliased in out Holder)
+ return Reference_Type;
+
+20/3
+ {AI05-0001-1AI05-0001-1} procedure Assign (Target : in out Holder; Source : in Holder);
+
+21/3
+ {AI05-0001-1AI05-0001-1} function Copy (Source : Holder) return Holder;
+
+22/3
+ procedure Move (Target : in out Holder; Source : in out Holder);
+
+23/3
+ private
+
+24/3
+ ... -- not specified by the language
+
+25/3
+ end Ada.Containers.Indefinite_Holders;
+
+26/3
+{AI05-0069-1AI05-0069-1} The actual function for the generic formal
+function "=" on Element_Type values is expected to define a reflexive
+and symmetric relationship and return the same result value each time it
+is called with a particular pair of values. If it behaves in some other
+manner, the function "=" on holder values returns an unspecified value.
+The exact arguments and number of calls of this generic formal function
+by the function "=" on holder values are unspecified.
+
+26.a/3
+ Ramification: If the actual function for "=" is not symmetric
+ and consistent, the result returned by any of the functions
+ defined to use "=" cannot be predicted. The implementation is
+ not required to protect against "=" raising an exception, or
+ returning random results, or any other "bad" behavior. And it
+ can call "=" in whatever manner makes sense. But note that
+ only the results of the function "=" is unspecified; other
+ subprograms are not allowed to break if "=" is bad.
+
+27/3
+{AI05-0069-1AI05-0069-1} The type Holder is used to represent holder
+containers. The type Holder needs finalization (see *note 7.6::).
+
+28/3
+{AI05-0069-1AI05-0069-1} Empty_Holder represents an empty holder object.
+If an object of type Holder is not otherwise initialized, it is
+initialized to the same value as Empty_Holder.
+
+29/3
+{AI05-0069-1AI05-0069-1} {AI05-0262-1AI05-0262-1} [Some operations of
+this generic package have access-to-subprogram parameters. To ensure
+such operations are well-defined, they guard against certain actions by
+the designated subprogram. In particular, some operations check for
+"tampering with the element" of a container because they depend on the
+element of the container not being replaced.]
+
+30/3
+{AI05-0069-1AI05-0069-1} {AI05-0262-1AI05-0262-1} A subprogram is said
+to tamper with the element of a holder object H if:
+
+31/3
+ * It clears the element contained by H, that is, it calls the Clear
+ procedure with H as a parameter;
+
+32/3
+ * It replaces the element contained by H, that is, it calls the
+ Replace_Element procedure with H as a parameter;
+
+33/3
+ * It calls the Move procedure with H as a parameter;
+
+34/3
+ * It finalizes H.
+
+34.a/3
+ Reason: Complete replacement of an element can cause its
+ memory to be deallocated while another operation is holding
+ onto a reference to it. That can't be allowed. However, a
+ simple modification of (part of) an element is not a problem,
+ so Update_Element does not cause a problem.
+
+35/3
+{AI05-0265-1AI05-0265-1} When tampering with the element is prohibited
+for a particular holder object H, Program_Error is propagated by a call
+of any language-defined subprogram that is defined to tamper with the
+element of H, leaving H unmodified.
+
+36/3
+ function "=" (Left, Right : Holder) return Boolean;
+
+37/3
+ {AI05-0069-1AI05-0069-1} If Left and Right denote the same
+ holder object, then the function returns True. Otherwise, it
+ compares the element contained in Left to the element
+ contained in Right using the generic formal equality operator,
+ returning the result of that operation. Any exception raised
+ during the evaluation of element equality is propagated.
+
+37.a/3
+ Implementation Note: This wording describes the canonical
+ semantics. However, the order and number of calls on the
+ formal equality function is unspecified, so an implementation
+ need not call the equality function if the correct answer can
+ be determined without doing so.
+
+38/3
+ function To_Holder (New_Item : Element_Type) return Holder;
+
+39/3
+ {AI05-0069-1AI05-0069-1} Returns a nonempty holder containing
+ an element initialized to New_Item.
+
+40/3
+ function Is_Empty (Container : Holder) return Boolean;
+
+41/3
+ {AI05-0069-1AI05-0069-1} Returns True if Container is empty,
+ and False if it contains an element.
+
+42/3
+ procedure Clear (Container : in out Holder);
+
+43/3
+ {AI05-0069-1AI05-0069-1} Removes the element from Container.
+ Container is empty after a successful Clear operation.
+
+44/3
+ function Element (Container : Holder) return Element_Type;
+
+45/3
+ {AI05-0069-1AI05-0069-1} If Container is empty,
+ Constraint_Error is propagated. Otherwise, returns the
+ element stored in Container.
+
+46/3
+ procedure Replace_Element (Container : in out Holder;
+ New_Item : in Element_Type);
+
+47/3
+ {AI05-0069-1AI05-0069-1} Replace_Element assigns the value
+ New_Item into Container, replacing any preexisting content of
+ Container. Container is not empty after a successful call to
+ Replace_Element.
+
+48/3
+ procedure Query_Element
+ (Container : in Holder;
+ Process : not null access procedure (Element : in Element_Type));
+
+49/3
+ {AI05-0069-1AI05-0069-1} {AI05-0262-1AI05-0262-1}
+ {AI05-0265-1AI05-0265-1} If Container is empty,
+ Constraint_Error is propagated. Otherwise, Query_Element
+ calls Process.all with the contained element as the argument.
+ Tampering with the element of Container is prohibited during
+ the execution of the call on Process.all. Any exception
+ raised by Process.all is propagated.
+
+49.a/3
+ Implementation Note: {AI05-0005-1AI05-0005-1} The "tamper with
+ the element" check is intended to prevent the Element
+ parameter of Process from being replaced or deleted outside of
+ Process. The check prevents data loss (if Element_Type is
+ passed by copy) or erroneous execution (if Element_Type is an
+ unconstrained type).
+
+50/3
+ {AI05-0069-1AI05-0069-1} {AI05-0248-1AI05-0248-1} procedure Update_Element
+ (Container : in out Holder;
+ Process : not null access procedure (Element : in out Element_Type));
+
+51/3
+ {AI05-0069-1AI05-0069-1} {AI05-0262-1AI05-0262-1}
+ {AI05-0265-1AI05-0265-1} If Container is empty,
+ Constraint_Error is propagated. Otherwise, Update_Element
+ calls Process.all with the contained element as the argument.
+ Tampering with the element of Container is prohibited during
+ the execution of the call on Process.all. Any exception
+ raised by Process.all is propagated.
+
+51.a/3
+ Implementation Note: The Element parameter of Process.all may
+ be constrained even if Element_Type is unconstrained.
+
+52/3
+ {AI05-0212-1AI05-0212-1} type Constant_Reference_Type
+ (Element : not null access constant Element_Type) is private
+ with Implicit_Dereference => Element;
+
+53/3
+ {AI05-0212-1AI05-0212-1} type Reference_Type (Element : not null access Element_Type) is private
+ with Implicit_Dereference => Element;
+
+54/3
+ {AI05-0212-1AI05-0212-1} The types Constant_Reference_Type and
+ Reference_Type need finalization.
+
+55/3
+ {AI05-0212-1AI05-0212-1} The default initialization of an
+ object of type Constant_Reference_Type or Reference_Type
+ propagates Program_Error.
+
+55.a/3
+ Reason: It is expected that Reference_Type (and
+ Constant_Reference_Type) will be a controlled type, for which
+ finalization will have some action to terminate the tampering
+ check for the associated container. If the object is created
+ by default, however, there is no associated container. Since
+ this is useless, and supporting this case would take extra
+ work, we define it to raise an exception.
+
+56/3
+ {AI05-0212-1AI05-0212-1} function Constant_Reference (Container : aliased in Holder)
+ return Constant_Reference_Type;
+
+57/3
+ {AI05-0212-1AI05-0212-1} This function (combined with the
+ Implicit_Dereference aspect) provides a convenient way to gain
+ read access to the contained element of a holder container.
+
+58/3
+ {AI05-0212-1AI05-0212-1} {AI05-0262-1AI05-0262-1}
+ {AI05-0265-1AI05-0265-1} If Container is empty,
+ Constraint_Error is propagated. Otherwise, Constant_Reference
+ returns an object whose discriminant is an access value that
+ designates the contained element. Tampering with the elements
+ of Container is prohibited while the object returned by
+ Constant_Reference exists and has not been finalized.
+
+59/3
+ {AI05-0212-1AI05-0212-1} function Reference (Container : aliased in out Holder)
+ return Reference_Type;
+
+60/3
+ {AI05-0212-1AI05-0212-1} This function (combined with the
+ Implicit_Dereference aspects) provides a convenient way to
+ gain read and write access to the contained element of a
+ holder container.
+
+61/3
+ {AI05-0212-1AI05-0212-1} {AI05-0262-1AI05-0262-1}
+ {AI05-0265-1AI05-0265-1} If Container is empty,
+ Constraint_Error is propagated. Otherwise, Reference returns
+ an object whose discriminant is an access value that
+ designates the contained element. Tampering with the elements
+ of Container is prohibited while the object returned by
+ Reference exists and has not been finalized.
+
+62/3
+ procedure Assign (Target : in out Holder; Source : in Holder);
+
+63/3
+ {AI05-0001-1AI05-0001-1} If Target denotes the same object as
+ Source, the operation has no effect. If Source is empty,
+ Clear (Target) is called. Otherwise, Replace_Element (Target,
+ Element (Source)) is called.
+
+63.a/3
+ Discussion: {AI05-0005-1AI05-0005-1} This routine exists for
+ compatibility with the other containers. For a holder,
+ Assign(A, B) and A := B behave effectively the same. (Assign
+ Clears the Target, while := finalizes the Target, but these
+ should have similar effects.)
+
+64/3
+ function Copy (Source : Holder) return Holder;
+
+65/3
+ {AI05-0001-1AI05-0001-1} If Source is empty, returns an empty
+ holder container; otherwise, returns To_Holder (Element
+ (Source)).
+
+66/3
+ procedure Move (Target : in out Holder; Source : in out Holder);
+
+67/3
+ {AI05-0069-1AI05-0069-1} {AI05-0248-1AI05-0248-1} If Target
+ denotes the same object as Source, then the operation has no
+ effect. Otherwise, the element contained by Source (if any)
+ is removed from Source and inserted into Target, replacing any
+ preexisting content. Source is empty after a successful call
+ to Move.
+
+ _Bounded (Run-Time) Errors_
+
+68/3
+{AI05-0022-1AI05-0022-1} {AI05-0069-1AI05-0069-1}
+{AI05-0248-1AI05-0248-1} {AI05-0262-1AI05-0262-1} It is a bounded error
+for the actual function associated with a generic formal subprogram,
+when called as part of an operation of this package, to tamper with the
+element of any Holder parameter of the operation. Either Program_Error
+is raised, or the operation works as defined on the value of the Holder
+either prior to, or subsequent to, some or all of the modifications to
+the Holder.
+
+69/3
+{AI05-0027-1AI05-0027-1} {AI05-0069-1AI05-0069-1} It is a bounded error
+to call any subprogram declared in the visible part of
+Containers.Indefinite_Holders when the associated container has been
+finalized. If the operation takes Container as an in out parameter,
+then it raises Constraint_Error or Program_Error. Otherwise, the
+operation either proceeds as it would for an empty container, or it
+raises Constraint_Error or Program_Error.
+
+ _Erroneous Execution_
+
+70/3
+{AI05-0212-1AI05-0212-1} {AI05-0269-1AI05-0269-1} Execution is erroneous
+if the holder container associated with the result of a call to
+Reference or Constant_Reference is finalized before the result object
+returned by the call to Reference or Constant_Reference is finalized.
+
+70.a/3
+ Reason: {AI05-0212-1AI05-0212-1} Each object of Reference_Type
+ and Constant_Reference_Type probably contains some reference
+ to the originating container. If that container is
+ prematurely finalized (which is only possible via
+ Unchecked_Deallocation, as accessibility checks prevent
+ passing a container to Reference that will not live as long as
+ the result), the finalization of the object of Reference_Type
+ will try to access a nonexistent object. This is a normal
+ case of a dangling pointer created by Unchecked_Deallocation;
+ we have to explicitly mention it here as the pointer in
+ question is not visible in the specification of the type.
+ (This is the same reason we have to say this for invalid
+ cursors.)
+
+ _Implementation Requirements_
+
+71/3
+{AI05-0069-1AI05-0069-1} No storage associated with a holder object
+shall be lost upon assignment or scope exit.
+
+72/3
+{AI05-0069-1AI05-0069-1} {AI05-0269-1AI05-0269-1} The execution of an
+assignment_statement for a holder container shall have the effect of
+copying the element (if any) from the source holder object to the target
+holder object.
+
+72.a/3
+ Implementation Note: {AI05-0298-1AI05-0298-1} An assignment of
+ a holder container is a "deep" copy; that is the element is
+ copied as well as any data structures. We say "effect of" in
+ order to allow the implementation to avoid copying the element
+ immediately if it wishes. For instance, an implementation
+ that avoided copying until one of the containers is modified
+ would be allowed. (Note that this implementation would
+ require care, see *note A.18.2:: for more.)
+
+ _Implementation Advice_
+
+73/3
+{AI05-0069-1AI05-0069-1} {AI05-0269-1AI05-0269-1} Move should not copy
+the element, and should minimize copying of internal data structures.
+
+73.a.1/3
+ Implementation Advice: Containers.Indefinite_Holders.Move
+ should not copy the element, and should minimize copying of
+ internal data structures.
+
+73.a/3
+ Implementation Note: Usually that can be accomplished simply
+ by moving the pointer(s) to the internal data structures from
+ the Source holder to the Target holder.
+
+74/3
+{AI05-0069-1AI05-0069-1} {AI05-0269-1AI05-0269-1} If an exception is
+propagated from a holder operation, no storage should be lost, nor
+should the element be removed from a holder container unless specified
+by the operation.
+
+74.a.1/3
+ Implementation Advice: If an exception is propagated from a
+ holder operation, no storage should be lost, nor should the
+ element be removed from a holder container unless specified by
+ the operation.
+
+74.a/3
+ Reason: This is important so that programs can recover from
+ errors. But we don't want to require heroic efforts, so we
+ just require documentation of cases where this can't be
+ accomplished.
+
+ _Extensions to Ada 2005_
+
+74.b/3
+ {AI05-0069-1AI05-0069-1} {AI05-0084-1AI05-0084-1}
+ {AI05-0265-1AI05-0265-1} The generic package
+ Containers.Indefinite_Holders is new.
+
+\1f
+File: aarm2012.info, Node: A.18.19, Next: A.18.20, Prev: A.18.18, Up: A.18
+
+A.18.19 The Generic Package Containers.Bounded_Vectors
+------------------------------------------------------
+
+1/3
+{AI05-0001-1AI05-0001-1} The language-defined generic package
+Containers.Bounded_Vectors provides a private type Vector and a set of
+operations. It provides the same operations as the package
+Containers.Vectors (see *note A.18.2::), with the difference that the
+maximum storage is bounded.
+
+ _Static Semantics_
+
+2/3
+{AI05-0001-1AI05-0001-1} The declaration of the generic library package
+Containers.Bounded_Vectors has the same contents and semantics as
+Containers.Vectors except:
+
+3/3
+ * The pragma Preelaborate is replaced with pragma Pure.
+
+4/3
+ * The type Vector is declared with a discriminant that specifies the
+ capacity:
+
+5/3
+ type Vector (Capacity : Count_Type) is tagged private;
+
+6/3
+ * The type Vector needs finalization if and only if type Element_Type
+ needs finalization.
+
+6.a/3
+ Implementation Note: {AI05-0212-1AI05-0212-1} The type Vector
+ cannot depend on package Ada.Finalization unless the element
+ type depends on that package. The objects returned from the
+ Iterator and Reference functions probably do depend on package
+ Ada.Finalization. Restricted environments may need to avoid
+ use of those functions and their associated types.
+
+7/3
+ * In function Copy, if the Capacity parameter is equal to or greater
+ than the length of Source, the vector capacity exactly equals the
+ value of the Capacity parameter.
+
+8/3
+ * The description of Reserve_Capacity is replaced with:
+
+9/3
+ If the specified Capacity is larger than the capacity of
+ Container, then Reserve_Capacity propagates Capacity_Error.
+ Otherwise, the operation has no effect.
+
+ _Bounded (Run-Time) Errors_
+
+10/3
+{AI05-0160-1AI05-0160-1} {AI05-0265-1AI05-0265-1} It is a bounded error
+to assign from a bounded vector object while tampering with elements [or
+cursors] of that object is prohibited. Either Program_Error is raised
+by the assignment, execution proceeds with the target object prohibiting
+tampering with elements [or cursors], or execution proceeds normally.
+
+10.a/3
+ Proof: Tampering with elements includes tampering with
+ cursors, so we only really need to talk about tampering with
+ elements here; we mention cursors for clarity.
+
+ _Erroneous Execution_
+
+11/3
+{AI05-0265-1AI05-0265-1} When a bounded vector object V is finalized, if
+tampering with cursors is prohibited for V other than due to an
+assignment from another vector, then execution is erroneous.
+
+11.a/3
+ Reason: This is a tampering event, but since the
+ implementation is not allowed to use Ada.Finalization, it is
+ not possible in a pure Ada implementation to detect this
+ error. (There is no Finalize routine that will be called that
+ could make the check.) Since the check probably cannot be
+ made, the bad effects that could occur (such as an iterator
+ going into an infinite loop or accessing a nonexistent
+ element) cannot be prevented and we have to allow anything.
+ We do allow re-assigning an object that only prohibits
+ tampering because it was copied from another object as that
+ cannot cause any negative effects.
+
+ _Implementation Requirements_
+
+12/3
+{AI05-0184-1AI05-0184-1} {AI05-0264-1AI05-0264-1} For each instance of
+Containers.Vectors and each instance of Containers.Bounded_Vectors, if
+the two instances meet the following conditions, then the output
+generated by the Vector'Output or Vector'Write subprograms of either
+instance shall be readable by the Vector'Input or Vector'Read of the
+other instance, respectively:
+
+13/3
+ * {AI05-0184-1AI05-0184-1} {AI05-0248-1AI05-0248-1} the Element_Type
+ parameters of the two instances are statically matching subtypes of
+ the same type; and
+
+14/3
+ * {AI05-0184-1AI05-0184-1} the output generated by
+ Element_Type'Output or Element_Type'Write is readable by
+ Element_Type'Input or Element_Type'Read, respectively (where
+ Element_Type denotes the type of the two actual Element_Type
+ parameters); and
+
+15/3
+ * {AI05-0184-1AI05-0184-1} the preceding two conditions also hold for
+ the Index_Type parameters of the instances.
+
+ _Implementation Advice_
+
+16/3
+{AI05-0001-1AI05-0001-1} Bounded vector objects should be implemented
+without implicit pointers or dynamic allocation.
+
+16.a.1/3
+ Implementation Advice: Bounded vector objects should be
+ implemented without implicit pointers or dynamic allocation.
+
+17/3
+{AI05-0001-1AI05-0001-1} The implementation advice for procedure Move to
+minimize copying does not apply.
+
+17.a.1/3
+ Implementation Advice: The implementation advice for procedure
+ Move to minimize copying does not apply to bounded vectors.
+
+ _Extensions to Ada 2005_
+
+17.a/3
+ {AI05-0001-1AI05-0001-1} {AI05-0160-1AI05-0160-1}
+ {AI05-0184-1AI05-0184-1} The generic package
+ Containers.Bounded_Vectors is new.
+
+\1f
+File: aarm2012.info, Node: A.18.20, Next: A.18.21, Prev: A.18.19, Up: A.18
+
+A.18.20 The Generic Package Containers.Bounded_Doubly_Linked_Lists
+------------------------------------------------------------------
+
+1/3
+{AI05-0001-1AI05-0001-1} The language-defined generic package
+Containers.Bounded_Doubly_Linked_Lists provides a private type List and
+a set of operations. It provides the same operations as the package
+Containers.Doubly_Linked_Lists (see *note A.18.3::), with the difference
+that the maximum storage is bounded.
+
+ _Static Semantics_
+
+2/3
+{AI05-0001-1AI05-0001-1} The declaration of the generic library package
+Containers.Bounded_Doubly_Linked_Lists has the same contents and
+semantics as Containers.Doubly_Linked_Lists except:
+
+3/3
+ * The pragma Preelaborate is replaced with pragma Pure.
+
+4/3
+ * The type List is declared with a discriminant that specifies the
+ capacity (maximum number of elements) as follows:
+
+5/3
+ type List (Capacity : Count_Type) is tagged private;
+
+6/3
+ * The type List needs finalization if and only if type Element_Type
+ needs finalization.
+
+6.a/3
+ Implementation Note: {AI05-0212-1AI05-0212-1} The type List
+ cannot depend on package Ada.Finalization unless the element
+ type depends on that package. The objects returned from the
+ Iterator and Reference functions probably do depend on package
+ Ada.Finalization. Restricted environments may need to avoid
+ use of those functions and their associated types.
+
+7/3
+ * The allocation of internal storage includes a check that the
+ capacity is not exceeded, and Capacity_Error is raised if this
+ check fails.
+
+8/3
+ * In procedure Assign, if Source length is greater than Target
+ capacity, then Capacity_Error is propagated.
+
+9/3
+ * The function Copy is replaced with:
+
+10/3
+ function Copy (Source : List; Capacity : Count_Type := 0)
+ return List;
+
+11/3
+ If Capacity is 0, then the list capacity is the length of
+ Source; if Capacity is equal to or greater than the length of
+ Source, the list capacity equals the value of the Capacity
+ parameter; otherwise, the operation propagates Capacity_Error.
+
+12/3
+ * In the three-parameter procedure Splice whose Source has type List,
+ if the sum of the length of Target and the length of Source is
+ greater than the capacity of Target, then Splice propagates
+ Capacity_Error.
+
+13/3
+ * In the four-parameter procedure Splice, if the length of Target
+ equals the capacity of Target, then Splice propagates
+ Capacity_Error.
+
+ _Bounded (Run-Time) Errors_
+
+14/3
+{AI05-0160-1AI05-0160-1} {AI05-0265-1AI05-0265-1} It is a bounded error
+to assign from a bounded list object while tampering with elements [or
+cursors] of that object is prohibited. Either Program_Error is raised
+by the assignment, execution proceeds with the target object prohibiting
+tampering with elements [or cursors], or execution proceeds normally.
+
+14.a/3
+ Proof: Tampering with elements includes tampering with
+ cursors, so we only really need to talk about tampering with
+ elements here; we mention cursors for clarity.
+
+ _Erroneous Execution_
+
+15/3
+{AI05-0265-1AI05-0265-1} When a bounded list object L is finalized, if
+tampering with cursors is prohibited for L other than due to an
+assignment from another list, then execution is erroneous.
+
+15.a/3
+ Reason: This is a tampering event, but since the
+ implementation is not allowed to use Ada.Finalization, it is
+ not possible in a pure Ada implementation to detect this
+ error. (There is no Finalize routine that will be called that
+ could make the check.) Since the check probably cannot be
+ made, the bad effects that could occur (such as an iterator
+ going into an infinite loop or accessing a nonexistent
+ element) cannot be prevented and we have to allow anything.
+ We do allow re-assigning an object that only prohibits
+ tampering because it was copied from another object as that
+ cannot cause any negative effects.
+
+ _Implementation Requirements_
+
+16/3
+{AI05-0184-1AI05-0184-1} {AI05-0264-1AI05-0264-1} For each instance of
+Containers.Doubly_Linked_Lists and each instance of
+Containers.Bounded_Doubly_Linked_Lists, if the two instances meet the
+following conditions, then the output generated by the List'Output or
+List'Write subprograms of either instance shall be readable by the
+List'Input or List'Read of the other instance, respectively:
+
+17/3
+ * {AI05-0184-1AI05-0184-1} {AI05-0248-1AI05-0248-1} the Element_Type
+ parameters of the two instances are statically matching subtypes of
+ the same type; and
+
+18/3
+ * {AI05-0184-1AI05-0184-1} the output generated by
+ Element_Type'Output or Element_Type'Write is readable by
+ Element_Type'Input or Element_Type'Read, respectively (where
+ Element_Type denotes the type of the two actual Element_Type
+ parameters).
+
+ _Implementation Advice_
+
+19/3
+{AI05-0001-1AI05-0001-1} Bounded list objects should be implemented
+without implicit pointers or dynamic allocation.
+
+19.a.1/3
+ Implementation Advice: Bounded list objects should be
+ implemented without implicit pointers or dynamic allocation.
+
+20/3
+{AI05-0001-1AI05-0001-1} The implementation advice for procedure Move to
+minimize copying does not apply.
+
+20.a.1/3
+ Implementation Advice: The implementation advice for procedure
+ Move to minimize copying does not apply to bounded lists.
+
+ _Extensions to Ada 2005_
+
+20.a/3
+ {AI05-0001-1AI05-0001-1} {AI05-0160-1AI05-0160-1}
+ {AI05-0184-1AI05-0184-1} The generic package
+ Containers.Bounded_Doubly_Linked_Lists is new.
+
+\1f
+File: aarm2012.info, Node: A.18.21, Next: A.18.22, Prev: A.18.20, Up: A.18
+
+A.18.21 The Generic Package Containers.Bounded_Hashed_Maps
+----------------------------------------------------------
+
+1/3
+{AI05-0001-1AI05-0001-1} The language-defined generic package
+Containers.Bounded_Hashed_Maps provides a private type Map and a set of
+operations. It provides the same operations as the package
+Containers.Hashed_Maps (see *note A.18.5::), with the difference that
+the maximum storage is bounded.
+
+ _Static Semantics_
+
+2/3
+{AI05-0001-1AI05-0001-1} The declaration of the generic library package
+Containers.Bounded_Hashed_Maps has the same contents and semantics as
+Containers.Hashed_Maps except:
+
+3/3
+ * The pragma Preelaborate is replaced with pragma Pure.
+
+4/3
+ * The type Map is declared with discriminants that specify both the
+ capacity (number of elements) and modulus (number of distinct hash
+ values) of the hash table as follows:
+
+5/3
+ type Map (Capacity : Count_Type;
+ Modulus : Hash_Type) is tagged private;
+
+6/3
+ * The type Map needs finalization if and only if type Key_Type or
+ type Element_Type needs finalization.
+
+6.a/3
+ Implementation Note: {AI05-0212-1AI05-0212-1} The type Map
+ cannot depend on package Ada.Finalization unless the element
+ or key type depends on that package. The objects returned
+ from the Iterator and Reference functions probably do depend
+ on package Ada.Finalization. Restricted environments may need
+ to avoid use of those functions and their associated types.
+
+7/3
+ * The description of Reserve_Capacity is replaced with:
+
+8/3
+ If the specified Capacity is larger than the capacity of
+ Container, then Reserve_Capacity propagates Capacity_Error.
+ Otherwise, the operation has no effect.
+
+9/3
+ * An additional operation is added immediately following
+ Reserve_Capacity:
+
+10/3
+ function Default_Modulus (Capacity : Count_Type) return Hash_Type;
+
+11/3
+ Default_Modulus returns an implementation-defined value for
+ the number of distinct hash values to be used for the given
+ capacity (maximum number of elements).
+
+12/3
+ * The function Copy is replaced with:
+
+13/3
+ function Copy (Source : Map;
+ Capacity : Count_Type := 0;
+ Modulus : Hash_Type := 0) return Map;
+
+14/3
+ {AI05-0264-1AI05-0264-1} Returns a map with key/element pairs
+ initialized from the values in Source. If Capacity is 0, then
+ the map capacity is the length of Source; if Capacity is equal
+ to or greater than the length of Source, the map capacity is
+ the value of the Capacity parameter; otherwise, the operation
+ propagates Capacity_Error. If the Modulus argument is 0, then
+ the map modulus is the value returned by a call to
+ Default_Modulus with the map capacity as its argument;
+ otherwise, the map modulus is the value of the Modulus
+ parameter.
+
+ _Bounded (Run-Time) Errors_
+
+15/3
+{AI05-0160-1AI05-0160-1} {AI05-0265-1AI05-0265-1} It is a bounded error
+to assign from a bounded map object while tampering with elements [or
+cursors] of that object is prohibited. Either Program_Error is raised
+by the assignment, execution proceeds with the target object prohibiting
+tampering with elements [or cursors], or execution proceeds normally.
+
+15.a/3
+ Proof: Tampering with elements includes tampering with
+ cursors, so we only really need to talk about tampering with
+ elements here; we mention cursors for clarity.
+
+ _Erroneous Execution_
+
+16/3
+{AI05-0265-1AI05-0265-1} When a bounded map object M is finalized, if
+tampering with cursors is prohibited for M other than due to an
+assignment from another map, then execution is erroneous.
+
+16.a/3
+ Reason: This is a tampering event, but since the
+ implementation is not allowed to use Ada.Finalization, it is
+ not possible in a pure Ada implementation to detect this
+ error. (There is no Finalize routine that will be called that
+ could make the check.) Since the check probably cannot be
+ made, the bad effects that could occur (such as an iterator
+ going into an infinite loop or accessing a nonexistent
+ element) cannot be prevented and we have to allow anything.
+ We do allow re-assigning an object that only prohibits
+ tampering because it was copied from another object as that
+ cannot cause any negative effects.
+
+ _Implementation Requirements_
+
+17/3
+{AI05-0184-1AI05-0184-1} {AI05-0264-1AI05-0264-1} For each instance of
+Containers.Hashed_Maps and each instance of
+Containers.Bounded_Hashed_Maps, if the two instances meet the following
+conditions, then the output generated by the Map'Output or Map'Write
+subprograms of either instance shall be readable by the Map'Input or
+Map'Read of the other instance, respectively:
+
+18/3
+ * {AI05-0184-1AI05-0184-1} {AI05-0248-1AI05-0248-1} the Element_Type
+ parameters of the two instances are statically matching subtypes of
+ the same type; and
+
+19/3
+ * {AI05-0184-1AI05-0184-1} the output generated by
+ Element_Type'Output or Element_Type'Write is readable by
+ Element_Type'Input or Element_Type'Read, respectively (where
+ Element_Type denotes the type of the two actual Element_Type
+ parameters); and
+
+20/3
+ * {AI05-0184-1AI05-0184-1} the preceding two conditions also hold for
+ the Key_Type parameters of the instances.
+
+ _Implementation Advice_
+
+21/3
+{AI05-0001-1AI05-0001-1} {AI05-0269-1AI05-0269-1} Bounded hashed map
+objects should be implemented without implicit pointers or dynamic
+allocation.
+
+21.a.1/3
+ Implementation Advice: Bounded hashed map objects should be
+ implemented without implicit pointers or dynamic allocation.
+
+22/3
+{AI05-0001-1AI05-0001-1} The implementation advice for procedure Move to
+minimize copying does not apply.
+
+22.a.1/3
+ Implementation Advice: The implementation advice for procedure
+ Move to minimize copying does not apply to bounded hashed
+ maps.
+
+ _Extensions to Ada 2005_
+
+22.a/3
+ {AI05-0001-1AI05-0001-1} {AI05-0160-1AI05-0160-1}
+ {AI05-0184-1AI05-0184-1} The generic package
+ Containers.Bounded_Hashed_Maps is new.
+
+\1f
+File: aarm2012.info, Node: A.18.22, Next: A.18.23, Prev: A.18.21, Up: A.18
+
+A.18.22 The Generic Package Containers.Bounded_Ordered_Maps
+-----------------------------------------------------------
+
+1/3
+{AI05-0001-1AI05-0001-1} The language-defined generic package
+Containers.Bounded_Ordered_Maps provides a private type Map and a set of
+operations. It provides the same operations as the package
+Containers.Ordered_Maps (see *note A.18.6::), with the difference that
+the maximum storage is bounded.
+
+ _Static Semantics_
+
+2/3
+{AI05-0001-1AI05-0001-1} The declaration of the generic library package
+Containers.Bounded_Ordered_Maps has the same contents and semantics as
+Containers.Ordered_Maps except:
+
+3/3
+ * The pragma Preelaborate is replaced with pragma Pure.
+
+4/3
+ * The type Map is declared with a discriminant that specifies the
+ capacity (maximum number of elements) as follows:
+
+5/3
+ type Map (Capacity : Count_Type) is tagged private;
+
+6/3
+ * The type Map needs finalization if and only if type Key_Type or
+ type Element_Type needs finalization.
+
+6.a/3
+ Implementation Note: {AI05-0212-1AI05-0212-1} The type Map
+ cannot depend on package Ada.Finalization unless the element
+ type depends on that package. The objects returned from the
+ Iterator and Reference functions probably do depend on package
+ Ada.Finalization. Restricted environments may need to avoid
+ use of those functions and their associated types.
+
+7/3
+ * The allocation of a new node includes a check that the capacity is
+ not exceeded, and Capacity_Error is raised if this check fails.
+
+8/3
+ * In procedure Assign, if Source length is greater than Target
+ capacity, then Capacity_Error is propagated.
+
+9/3
+ * The function Copy is replaced with:
+
+10/3
+ function Copy (Source : Map;
+ Capacity : Count_Type := 0) return Map;
+
+11/3
+ Returns a map with key/element pairs initialized from the
+ values in Source. If Capacity is 0, then the map capacity is
+ the length of Source; if Capacity is equal to or greater than
+ the length of Source, the map capacity is the specified value;
+ otherwise, the operation propagates Capacity_Error.
+
+ _Bounded (Run-Time) Errors_
+
+12/3
+{AI05-0160-1AI05-0160-1} {AI05-0265-1AI05-0265-1} It is a bounded error
+to assign from a bounded map object while tampering with elements [or
+cursors] of that object is prohibited. Either Program_Error is raised
+by the assignment, execution proceeds with the target object prohibiting
+tampering with elements [or cursors], or execution proceeds normally.
+
+12.a/3
+ Proof: Tampering with elements includes tampering with
+ cursors, so we only really need to talk about tampering with
+ elements here; we mention cursors for clarity.
+
+ _Erroneous Execution_
+
+13/3
+{AI05-0265-1AI05-0265-1} When a bounded map object M is finalized, if
+tampering with cursors is prohibited for M other than due to an
+assignment from another map, then execution is erroneous.
+
+13.a/3
+ Reason: This is a tampering event, but since the
+ implementation is not allowed to use Ada.Finalization, it is
+ not possible in a pure Ada implementation to detect this
+ error. (There is no Finalize routine that will be called that
+ could make the check.) Since the check probably cannot be
+ made, the bad effects that could occur (such as an iterator
+ going into an infinite loop or accessing a nonexistent
+ element) cannot be prevented and we have to allow anything.
+ We do allow re-assigning an object that only prohibits
+ tampering because it was copied from another object as that
+ cannot cause any negative effects.
+
+ _Implementation Requirements_
+
+14/3
+{AI05-0184-1AI05-0184-1} {AI05-0264-1AI05-0264-1} For each instance of
+Containers.Ordered_Maps and each instance of
+Containers.Bounded_Ordered_Maps, if the two instances meet the following
+conditions, then the output generated by the Map'Output or Map'Write
+subprograms of either instance shall be readable by the Map'Input or
+Map'Read of the other instance, respectively:
+
+15/3
+ * {AI05-0184-1AI05-0184-1} {AI05-0248-1AI05-0248-1} the Element_Type
+ parameters of the two instances are statically matching subtypes of
+ the same type; and
+
+16/3
+ * {AI05-0184-1AI05-0184-1} the output generated by
+ Element_Type'Output or Element_Type'Write is readable by
+ Element_Type'Input or Element_Type'Read, respectively (where
+ Element_Type denotes the type of the two actual Element_Type
+ parameters); and
+
+17/3
+ * {AI05-0184-1AI05-0184-1} the preceding two conditions also hold for
+ the Key_Type parameters of the instances.
+
+ _Implementation Advice_
+
+18/3
+{AI05-0001-1AI05-0001-1} {AI05-0269-1AI05-0269-1} Bounded ordered map
+objects should be implemented without implicit pointers or dynamic
+allocation.
+
+18.a.1/3
+ Implementation Advice: Bounded ordered map objects should be
+ implemented without implicit pointers or dynamic allocation.
+
+19/3
+{AI05-0001-1AI05-0001-1} The implementation advice for procedure Move to
+minimize copying does not apply.
+
+19.a.1/3
+ Implementation Advice: The implementation advice for procedure
+ Move to minimize copying does not apply to bounded ordered
+ maps.
+
+ _Extensions to Ada 2005_
+
+19.a/3
+ {AI05-0001-1AI05-0001-1} {AI05-0160-1AI05-0160-1}
+ {AI05-0184-1AI05-0184-1} The generic package
+ Containers.Bounded_Ordered_Maps is new.
+
+\1f
+File: aarm2012.info, Node: A.18.23, Next: A.18.24, Prev: A.18.22, Up: A.18
+
+A.18.23 The Generic Package Containers.Bounded_Hashed_Sets
+----------------------------------------------------------
+
+1/3
+{AI05-0001-1AI05-0001-1} The language-defined generic package
+Containers.Bounded_Hashed_Sets provides a private type Set and a set of
+operations. It provides the same operations as the package
+Containers.Hashed_Sets (see *note A.18.8::), with the difference that
+the maximum storage is bounded.
+
+ _Static Semantics_
+
+2/3
+{AI05-0001-1AI05-0001-1} The declaration of the generic library package
+Containers.Bounded_Hashed_Sets has the same contents and semantics as
+Containers.Hashed_Sets except:
+
+3/3
+ * The pragma Preelaborate is replaced with pragma Pure.
+
+4/3
+ * The type Set is declared with discriminants that specify both the
+ capacity (number of elements) and modulus (number of distinct hash
+ values) of the hash table as follows:
+
+5/3
+ type Set (Capacity : Count_Type;
+ Modulus : Hash_Type) is tagged private;
+
+6/3
+ * The type Set needs finalization if and only if type Element_Type
+ needs finalization.
+
+6.a/3
+ Implementation Note: {AI05-0212-1AI05-0212-1} The type Set
+ cannot depend on package Ada.Finalization unless the element
+ or key type depends on that package. The objects returned
+ from the Iterator and Reference functions probably do depend
+ on package Ada.Finalization. Restricted environments may need
+ to avoid use of those functions and their associated types.
+
+7/3
+ * The description of Reserve_Capacity is replaced with:
+
+8/3
+ If the specified Capacity is larger than the capacity of
+ Container, then Reserve_Capacity propagates Capacity_Error.
+ Otherwise, the operation has no effect.
+
+9/3
+ * An additional operation is added immediately following
+ Reserve_Capacity:
+
+10/3
+ function Default_Modulus (Capacity : Count_Type) return Hash_Type;
+
+11/3
+ Default_Modulus returns an implementation-defined value for
+ the number of distinct hash values to be used for the given
+ capacity (maximum number of elements).
+
+12/3
+ * The function Copy is replaced with:
+
+13/3
+ function Copy (Source : Set;
+ Capacity : Count_Type := 0;
+ Modulus : Hash_Type := 0) return Set;
+
+14/3
+ {AI05-0264-1AI05-0264-1} Returns a set whose elements are
+ initialized from the values in Source. If Capacity is 0, then
+ the set capacity is the length of Source; if Capacity is equal
+ to or greater than the length of Source, the set capacity is
+ the value of the Capacity parameter; otherwise, the operation
+ propagates Capacity_Error. If the Modulus argument is 0, then
+ the set modulus is the value returned by a call to
+ Default_Modulus with the set capacity as its argument;
+ otherwise, the set modulus is the value of the Modulus
+ parameter.
+
+ _Bounded (Run-Time) Errors_
+
+15/3
+{AI05-0160-1AI05-0160-1} {AI05-0265-1AI05-0265-1} It is a bounded error
+to assign from a bounded set object while tampering with elements [or
+cursors] of that object is prohibited. Either Program_Error is raised
+by the assignment, execution proceeds with the target object prohibiting
+tampering with elements [or cursors], or execution proceeds normally.
+
+15.a/3
+ Proof: Tampering with elements includes tampering with
+ cursors, so we only really need to talk about tampering with
+ elements here; we mention cursors for clarity.
+
+ _Erroneous Execution_
+
+16/3
+{AI05-0265-1AI05-0265-1} When a bounded set object S is finalized, if
+tampering with cursors is prohibited for S other than due to an
+assignment from another set, then execution is erroneous.
+
+16.a/3
+ Reason: This is a tampering event, but since the
+ implementation is not allowed to use Ada.Finalization, it is
+ not possible in a pure Ada implementation to detect this
+ error. (There is no Finalize routine that will be called that
+ could make the check.) Since the check probably cannot be
+ made, the bad effects that could occur (such as an iterator
+ going into an infinite loop or accessing a nonexistent
+ element) cannot be prevented and we have to allow anything.
+ We do allow re-assigning an object that only prohibits
+ tampering because it was copied from another object as that
+ cannot cause any negative effects.
+
+ _Implementation Requirements_
+
+17/3
+{AI05-0184-1AI05-0184-1} {AI05-0264-1AI05-0264-1} For each instance of
+Containers.Hashed_Sets and each instance of
+Containers.Bounded_Hashed_Sets, if the two instances meet the following
+conditions, then the output generated by the Set'Output or Set'Write
+subprograms of either instance shall be readable by the Set'Input or
+Set'Read of the other instance, respectively:
+
+18/3
+ * {AI05-0184-1AI05-0184-1} {AI05-0248-1AI05-0248-1} the Element_Type
+ parameters of the two instances are statically matching subtypes of
+ the same type; and
+
+19/3
+ * {AI05-0184-1AI05-0184-1} the output generated by
+ Element_Type'Output or Element_Type'Write is readable by
+ Element_Type'Input or Element_Type'Read, respectively (where
+ Element_Type denotes the type of the two actual Element_Type
+ parameters).
+
+ _Implementation Advice_
+
+20/3
+{AI05-0001-1AI05-0001-1} {AI05-0269-1AI05-0269-1} Bounded hashed set
+objects should be implemented without implicit pointers or dynamic
+allocation.
+
+20.a.1/3
+ Implementation Advice: Bounded hashed set objects should be
+ implemented without implicit pointers or dynamic allocation.
+
+21/3
+{AI05-0001-1AI05-0001-1} The implementation advice for procedure Move to
+minimize copying does not apply.
+
+21.a.1/3
+ Implementation Advice: The implementation advice for procedure
+ Move to minimize copying does not apply to bounded hashed
+ sets.
+
+ _Extensions to Ada 2005_
+
+21.a/3
+ {AI05-0001-1AI05-0001-1} {AI05-0160-1AI05-0160-1}
+ {AI05-0184-1AI05-0184-1} The generic package
+ Containers.Bounded_Hashed_Sets is new.
+
+\1f
+File: aarm2012.info, Node: A.18.24, Next: A.18.25, Prev: A.18.23, Up: A.18
+
+A.18.24 The Generic Package Containers.Bounded_Ordered_Sets
+-----------------------------------------------------------
+
+1/3
+{AI05-0001-1AI05-0001-1} The language-defined generic package
+Containers.Bounded_Ordered_Sets provides a private type Set and a set of
+operations. It provides the same operations as the package
+Containers.Ordered_Sets (see *note A.18.9::), with the difference that
+the maximum storage is bounded.
+
+ _Static Semantics_
+
+2/3
+{AI05-0001-1AI05-0001-1} The declaration of the generic library package
+Containers.Bounded_Ordered_Sets has the same contents and semantics as
+Containers.Ordered_Sets except:
+
+3/3
+ * The pragma Preelaborate is replaced with pragma Pure.
+
+4/3
+ * The type Set is declared with a discriminant that specifies the
+ capacity (maximum number of elements) as follows:
+
+5/3
+ type Set (Capacity : Count_Type) is tagged private;
+
+6/3
+ * The type Set needs finalization if and only if type Element_Type
+ needs finalization.
+
+6.a/3
+ Implementation Note: {AI05-0212-1AI05-0212-1} The type Set
+ cannot depend on package Ada.Finalization unless the element
+ type depends on that package. The objects returned from the
+ Iterator and Reference functions probably do depend on package
+ Ada.Finalization. Restricted environments may need to avoid
+ use of those functions and their associated types.
+
+7/3
+ * If Insert (or Include) adds an element, a check is made that the
+ capacity is not exceeded, and Capacity_Error is raised if this
+ check fails.
+
+8/3
+ * In procedure Assign, if Source length is greater than Target
+ capacity, then Capacity_Error is propagated.
+
+9/3
+ * The function Copy is replaced with:
+
+10/3
+ function Copy (Source : Set;
+ Capacity : Count_Type := 0) return Set;
+
+11/3
+ Returns a set whose elements are initialized from the values
+ in Source. If Capacity is 0, then the set capacity is the
+ length of Source; if Capacity is equal to or greater than the
+ length of Source, the set capacity is the specified value;
+ otherwise, the operation propagates Capacity_Error.
+
+ _Bounded (Run-Time) Errors_
+
+12/3
+{AI05-0160-1AI05-0160-1} {AI05-0265-1AI05-0265-1} It is a bounded error
+to assign from a bounded set object while tampering with elements [or
+cursors] of that object is prohibited. Either Program_Error is raised
+by the assignment, execution proceeds with the target object prohibiting
+tampering with elements [or cursors], or execution proceeds normally.
+
+12.a/3
+ Proof: Tampering with elements includes tampering with
+ cursors, so we only really need to talk about tampering with
+ elements here; we mention cursors for clarity.
+
+ _Erroneous Execution_
+
+13/3
+{AI05-0265-1AI05-0265-1} When a bounded set object S is finalized, if
+tampering with cursors is prohibited for S other than due to an
+assignment from another set, then execution is erroneous.
+
+13.a/3
+ Reason: This is a tampering event, but since the
+ implementation is not allowed to use Ada.Finalization, it is
+ not possible in a pure Ada implementation to detect this
+ error. (There is no Finalize routine that will be called that
+ could make the check.) Since the check probably cannot be
+ made, the bad effects that could occur (such as an iterator
+ going into an infinite loop or accessing a nonexistent
+ element) cannot be prevented and we have to allow anything.
+ We do allow re-assigning an object that only prohibits
+ tampering because it was copied from another object as that
+ cannot cause any negative effects.
+
+ _Implementation Requirements_
+
+14/3
+{AI05-0184-1AI05-0184-1} {AI05-0264-1AI05-0264-1} For each instance of
+Containers.Ordered_Sets and each instance of
+Containers.Bounded_Ordered_Sets, if the two instances meet the following
+conditions, then the output generated by the Set'Output or Set'Write
+subprograms of either instance shall be readable by the Set'Input or
+Set'Read of the other instance, respectively:
+
+15/3
+ * {AI05-0184-1AI05-0184-1} {AI05-0248-1AI05-0248-1} the Element_Type
+ parameters of the two instances are statically matching subtypes of
+ the same type; and
+
+16/3
+ * {AI05-0184-1AI05-0184-1} the output generated by
+ Element_Type'Output or Element_Type'Write is readable by
+ Element_Type'Input or Element_Type'Read, respectively (where
+ Element_Type denotes the type of the two actual Element_Type
+ parameters).
+
+ _Implementation Advice_
+
+17/3
+{AI05-0001-1AI05-0001-1} {AI05-0269-1AI05-0269-1} Bounded ordered set
+objects should be implemented without implicit pointers or dynamic
+allocation.
+
+17.a.1/3
+ Implementation Advice: Bounded ordered set objects should be
+ implemented without implicit pointers or dynamic allocation.
+
+18/3
+{AI05-0001-1AI05-0001-1} The implementation advice for procedure Move to
+minimize copying does not apply.
+
+18.a.1/3
+ Implementation Advice: The implementation advice for procedure
+ Move to minimize copying does not apply to bounded ordered
+ sets.
+
+ _Extensions to Ada 2005_
+
+18.a/3
+ {AI05-0001-1AI05-0001-1} {AI05-0160-1AI05-0160-1}
+ {AI05-0184-1AI05-0184-1} The generic package
+ Containers.Bounded_Ordered_Sets is new.
+
+\1f
+File: aarm2012.info, Node: A.18.25, Next: A.18.26, Prev: A.18.24, Up: A.18
+
+A.18.25 The Generic Package Containers.Bounded_Multiway_Trees
+-------------------------------------------------------------
+
+1/3
+{AI05-0136-1AI05-0136-1} The language-defined generic package
+Containers.Bounded_Multiway_Trees provides a private type Tree and a set
+of operations. It provides the same operations as the package
+Containers.Multiway_Trees (see *note A.18.10::), with the difference
+that the maximum storage is bounded.
+
+ _Static Semantics_
+
+2/3
+{AI05-0136-1AI05-0136-1} The declaration of the generic library package
+Containers.Bounded_Multiway_Trees has the same contents and semantics as
+Containers.Multiway_Trees except:
+
+3/3
+ * The pragma Preelaborate is replaced with pragma Pure.
+
+4/3
+ * The type Tree is declared with a discriminant that specifies the
+ capacity (maximum number of elements) as follows:
+
+5/3
+ type Tree (Capacity : Count_Type) is tagged private;
+
+6/3
+ * The type Tree needs finalization if and only if type Element_Type
+ needs finalization.
+
+6.a/3
+ Implementation Note: {AI05-0212-1AI05-0212-1} The type Tree
+ cannot depend on package Ada.Finalization unless the element
+ type depends on that package. The objects returned from the
+ Iterator and Reference functions probably do depend on package
+ Ada.Finalization. Restricted environments may need to avoid
+ use of those functions and their associated types.
+
+7/3
+ * The allocation of internal storage includes a check that the
+ capacity is not exceeded, and Capacity_Error is raised if this
+ check fails.
+
+8/3
+ * In procedure Assign, if Source length is greater than Target
+ capacity, then Capacity_Error is propagated.
+
+9/3
+ * Function Copy is declared as follows:
+
+10/3
+ function Copy (Source : Tree; Capacity : Count_Type := 0)
+ return List;
+
+11/3
+ If Capacity is 0, then the tree capacity is the count of Source; if
+ Capacity is equal to or greater than Source.Count, the tree
+ capacity equals the value of the Capacity parameter; otherwise, the
+ operation propagates Capacity_Error.
+
+12/3
+ * {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1} In the
+ five-parameter procedure Splice_Subtree, if Source is not the same
+ object as Target, and if the sum of Target.Count and
+ Subtree_Node_Count (Position) is greater than Target.Capacity, then
+ Splice_Subtree propagates Capacity_Error.
+
+13/3
+ * {AI05-0136-1AI05-0136-1} {AI05-0248-1AI05-0248-1} In the
+ five-parameter procedure Splice_Children, if Source is not the same
+ object as Target, and if the sum of Target.Count and
+ Subtree_Node_Count (Source_Parent)-1 is greater than
+ Target.Capacity, then Splice_Children propagates Capacity_Error.
+
+ _Bounded (Run-Time) Errors_
+
+14/3
+{AI05-0160-1AI05-0160-1} {AI05-0265-1AI05-0265-1} It is a bounded error
+to assign from a bounded tree object while tampering with elements [or
+cursors] of that object is prohibited. Either Program_Error is raised
+by the assignment, execution proceeds with the target object prohibiting
+tampering with elements [or cursors], or execution proceeds normally.
+
+14.a/3
+ Proof: Tampering with elements includes tampering with
+ cursors, so we only really need to talk about tampering with
+ elements here; we mention cursors for clarity.
+
+ _Erroneous Execution_
+
+15/3
+{AI05-0265-1AI05-0265-1} When a bounded tree object T is finalized, if
+tampering with cursors is prohibited for T other than due to an
+assignment from another tree, then execution is erroneous.
+
+15.a/3
+ Reason: This is a tampering event, but since the
+ implementation is not allowed to use Ada.Finalization, it is
+ not possible in a pure Ada implementation to detect this
+ error. (There is no Finalize routine that will be called that
+ could make the check.) Since the check probably cannot be
+ made, the bad effects that could occur (such as an iterator
+ going into an infinite loop or accessing a nonexistent
+ element) cannot be prevented and we have to allow anything.
+ We do allow re-assigning an object that only prohibits
+ tampering because it was copied from another object as that
+ cannot cause any negative effects.
+
+ _Implementation Requirements_
+
+16/3
+{AI05-0184-1AI05-0184-1} {AI05-0264-1AI05-0264-1} For each instance of
+Containers.Multiway_Trees and each instance of
+Containers.Bounded_Multiway_Trees, if the two instances meet the
+following conditions, then the output generated by the Tree'Output or
+Tree'Write subprograms of either instance shall be readable by the
+Tree'Input or Tree'Read of the other instance, respectively:
+
+17/3
+ * {AI05-0184-1AI05-0184-1} {AI05-0248-1AI05-0248-1} the Element_Type
+ parameters of the two instances are statically matching subtypes of
+ the same type; and
+
+18/3
+ * {AI05-0184-1AI05-0184-1} the output generated by
+ Element_Type'Output or Element_Type'Write is readable by
+ Element_Type'Input or Element_Type'Read, respectively (where
+ Element_Type denotes the type of the two actual Element_Type
+ parameters).
+
+ _Implementation Advice_
+
+19/3
+{AI05-0136-1AI05-0136-1} Bounded tree objects should be implemented
+without implicit pointers or dynamic allocation.
+
+19.a.1/3
+ Implementation Advice: Bounded tree objects should be
+ implemented without implicit pointers or dynamic allocation.
+
+20/3
+{AI05-0136-1AI05-0136-1} The implementation advice for procedure Move to
+minimize copying does not apply.
+
+20.a.1/3
+ Implementation Advice: The implementation advice for procedure
+ Move to minimize copying does not apply to bounded trees.
+
+ _Extensions to Ada 2005_
+
+20.a/3
+ {AI05-0136-1AI05-0136-1} {AI05-0184-1AI05-0184-1} The generic
+ package Containers.Bounded_Multiway_Trees is new.
+
+\1f
+File: aarm2012.info, Node: A.18.26, Next: A.18.27, Prev: A.18.25, Up: A.18
+
+A.18.26 Array Sorting
+---------------------
+
+1/3
+{AI95-00302-03AI95-00302-03} {AI05-0001-1AI05-0001-1} The
+language-defined generic procedures Containers.Generic_Array_Sort,
+Containers.Generic_Constrained_Array_Sort, and Containers.Generic_Sort
+provide sorting on arbitrary array types.
+
+ _Static Semantics_
+
+2/2
+{AI95-00302-03AI95-00302-03} The generic library procedure
+Containers.Generic_Array_Sort has the following declaration:
+
+3/2
+ generic
+ type Index_Type is (<>);
+ type Element_Type is private;
+ type Array_Type is array (Index_Type range <>) of Element_Type;
+ with function "<" (Left, Right : Element_Type)
+ return Boolean is <>;
+ procedure Ada.Containers.Generic_Array_Sort (Container : in out Array_Type);
+ pragma Pure(Ada.Containers.Generic_Array_Sort);
+
+4/2
+ Reorders the elements of Container such that the elements are
+ sorted smallest first as determined by the generic formal "<"
+ operator provided. Any exception raised during evaluation of
+ "<" is propagated.
+
+5/3
+ {AI05-0044-1AI05-0044-1} {AI05-0262-1AI05-0262-1} The actual
+ function for the generic formal function "<" of
+ Generic_Array_Sort is expected to return the same value each
+ time it is called with a particular pair of element values.
+ It should define a strict weak ordering relationship (see
+ *note A.18::); it should not modify Container. If the actual
+ for "<" behaves in some other manner, the behavior of the
+ instance of Generic_Array_Sort is unspecified. The number of
+ times Generic_Array_Sort calls "<" is unspecified.
+
+5.a/2
+ Ramification: This implies swapping the elements, usually
+ including an intermediate copy. This of course means that the
+ elements will be copied. Since the elements are nonlimited,
+ this usually will not be a problem. Note that there is
+ Implementation Advice below that the implementation should use
+ a sort that minimizes copying of elements.
+
+5.b/2
+ The sort is not required to be stable (and the fast algorithm
+ required will not be stable). If a stable sort is needed, the
+ user can include the original location of the element as an
+ extra "sort key". We considered requiring the implementation
+ to do that, but it is mostly extra overhead -- usually there
+ is something already in the element that provides the needed
+ stability.
+
+6/2
+{AI95-00302-03AI95-00302-03} The generic library procedure
+Containers.Generic_Constrained_Array_Sort has the following declaration:
+
+7/2
+ generic
+ type Index_Type is (<>);
+ type Element_Type is private;
+ type Array_Type is array (Index_Type) of Element_Type;
+ with function "<" (Left, Right : Element_Type)
+ return Boolean is <>;
+ procedure Ada.Containers.Generic_Constrained_Array_Sort
+ (Container : in out Array_Type);
+ pragma Pure(Ada.Containers.Generic_Constrained_Array_Sort);
+
+8/2
+ Reorders the elements of Container such that the elements are
+ sorted smallest first as determined by the generic formal "<"
+ operator provided. Any exception raised during evaluation of
+ "<" is propagated.
+
+9/3
+ {AI05-0044-1AI05-0044-1} {AI05-0262-1AI05-0262-1} The actual
+ function for the generic formal function "<" of
+ Generic_Constrained_Array_Sort is expected to return the same
+ value each time it is called with a particular pair of element
+ values. It should define a strict weak ordering relationship
+ (see *note A.18::); it should not modify Container. If the
+ actual for "<" behaves in some other manner, the behavior of
+ the instance of Generic_Constrained_Array_Sort is unspecified.
+ The number of times Generic_Constrained_Array_Sort calls "<"
+ is unspecified.
+
+9.1/3
+{AI05-0001-1AI05-0001-1} The generic library procedure
+Containers.Generic_Sort has the following declaration:
+
+9.2/3
+ generic
+ type Index_Type is (<>);
+ with function Before (Left, Right : Index_Type) return Boolean;
+ with procedure Swap (Left, Right : Index_Type);
+ procedure Ada.Containers.Generic_Sort
+ (First, Last : Index_Type'Base);
+ pragma Pure(Ada.Containers.Generic_Sort);
+
+9.3/3
+ {AI05-0001-1AI05-0001-1} {AI05-0248-1AI05-0248-1} Reorders the
+ elements of an indexable structure, over the range First ..
+ Last, such that the elements are sorted in the ordering
+ determined by the generic formal function Before; Before
+ should return True if Left is to be sorted before Right. The
+ generic formal Before compares the elements having the given
+ indices, and the generic formal Swap exchanges the values of
+ the indicated elements. Any exception raised during
+ evaluation of Before or Swap is propagated.
+
+9.4/3
+ The actual function for the generic formal function Before of
+ Generic_Sort is expected to return the same value each time it
+ is called with index values that identify a particular pair of
+ element values. It should define a strict weak ordering
+ relationship (see *note A.18::); it should not modify the
+ elements. The actual function for the generic formal Swap
+ should exchange the values of the indicated elements. If the
+ actual for either Before or Swap behaves in some other manner,
+ the behavior of Generic_Sort is unspecified. The number of
+ times the Generic_Sort calls Before or Swap is unspecified.
+
+ _Implementation Advice_
+
+10/2
+{AI95-00302-03AI95-00302-03} The worst-case time complexity of a call on
+an instance of Containers.Generic_Array_Sort or
+Containers.Generic_Constrained_Array_Sort should be O(N**2) or better,
+and the average time complexity should be better than O(N**2), where N
+is the length of the Container parameter.
+
+10.a/2
+ Implementation Advice: Containers.Generic_Array_Sort and
+ Containers.Generic_Constrained_Array_Sort should have an
+ average time complexity better than O(N**2) and worst case no
+ worse than O(N**2).
+
+10.b/2
+ Discussion: In other words, we're requiring the use of a
+ sorting algorithm better than O(N**2), such as Quicksort. No
+ bubble sorts allowed!
+
+11/2
+{AI95-00302-03AI95-00302-03} Containers.Generic_Array_Sort and
+Containers.Generic_Constrained_Array_Sort should minimize copying of
+elements.
+
+11.a/2
+ Implementation Advice: Containers.Generic_Array_Sort and
+ Containers.Generic_Constrained_Array_Sort should minimize
+ copying of elements.
+
+11.b/2
+ To be honest: We do not mean "absolutely minimize" here; we're
+ not intending to require a single copy for each element.
+ Rather, we want to suggest that the sorting algorithm chosen
+ is one that does not copy items unnecessarily. Bubble sort
+ would not meet this advice, for instance.
+
+12/3
+{AI05-0248-1AI05-0248-1} The worst-case time complexity of a call on an
+instance of Containers.Generic_Sort should be O(N**2) or better, and the
+average time complexity should be better than O(N**2), where N is the
+difference between the Last and First parameters plus 1.
+
+12.a.1/3
+ Implementation Advice: Containers.Generic_Sort should have an
+ average time complexity better than O(N**2) and worst case no
+ worse than O(N**2).
+
+13/3
+{AI05-0248-1AI05-0248-1} Containers.Generic_Sort should minimize calls
+to the generic formal Swap.
+
+13.a.1/3
+ Implementation Advice: Containers.Generic_Sort should minimize
+ calls to the generic formal Swap.
+
+ _Extensions to Ada 95_
+
+13.a/2
+ {AI95-00302-03AI95-00302-03} The generic procedures
+ Containers.Generic_Array_Sort and
+ Containers.Generic_Constrained_Array_Sort are new.
+
+ _Extensions to Ada 2005_
+
+13.b/3
+ {AI05-0001-1AI05-0001-1} {AI05-0248-1AI05-0248-1} The generic
+ procedure Containers.Generic_Sort is new.
+
+ _Wording Changes from Ada 2005_
+
+13.c/3
+ {AI05-0044-1AI05-0044-1} Correction: Redefined "<" actuals to
+ require a strict weak ordering; the old definition allowed
+ indeterminant comparisons that would not have worked in a
+ sort.
+
+\1f
+File: aarm2012.info, Node: A.18.27, Next: A.18.28, Prev: A.18.26, Up: A.18
+
+A.18.27 The Generic Package Containers.Synchronized_Queue_Interfaces
+--------------------------------------------------------------------
+
+1/3
+{AI05-0159-1AI05-0159-1} The language-defined generic package
+Containers.Synchronized_Queue_Interfaces provides interface type Queue,
+and a set of operations for that type. Interface Queue specifies a
+first-in, first-out queue.
+
+ _Static Semantics_
+
+2/3
+{AI05-0159-1AI05-0159-1} The generic library package
+Containers.Synchronized_Queue_Interfaces has the following declaration:
+
+3/3
+ generic
+ type Element_Type is private;
+ package Ada.Containers.Synchronized_Queue_Interfaces is
+ pragma Pure(Synchronized_Queue_Interfaces);
+
+4/3
+ type Queue is synchronized interface;
+
+5/3
+ procedure Enqueue
+ (Container : in out Queue;
+ New_Item : in Element_Type) is abstract
+ with Synchronization => By_Entry;
+
+6/3
+ procedure Dequeue
+ (Container : in out Queue;
+ Element : out Element_Type) is abstract
+ with Synchronization => By_Entry;
+
+7/3
+ function Current_Use (Container : Queue) return Count_Type is abstract;
+ function Peak_Use (Container : Queue) return Count_Type is abstract;
+
+8/3
+ end Ada.Containers.Synchronized_Queue_Interfaces;
+
+9/3
+ procedure Enqueue
+ (Container : in out Queue;
+ New_Item : in Element_Type) is abstract;
+
+10/3
+ {AI05-0159-1AI05-0159-1} {AI05-0262-1AI05-0262-1}
+ {AI05-0264-1AI05-0264-1} A queue type that implements this
+ interface is allowed to have a bounded capacity. If the queue
+ object has a bounded capacity, and the number of existing
+ elements equals the capacity, then Enqueue blocks until
+ storage becomes available; otherwise, Enqueue does not block.
+ In any case, it then copies New_Item onto the queue.
+
+11/3
+ procedure Dequeue
+ (Container : in out Queue;
+ Element : out Element_Type) is abstract;
+
+12/3
+ {AI05-0159-1AI05-0159-1} {AI05-0251-1AI05-0251-1} If the queue
+ is empty, then Dequeue blocks until an item becomes available.
+ In any case, it then assigns the element at the head of the
+ queue to Element, and removes it from the queue.
+
+13/3
+ function Current_Use (Container : Queue) return Count_Type is abstract;
+
+14/3
+ {AI05-0159-1AI05-0159-1} Returns the number of elements
+ currently in the queue.
+
+15/3
+ function Peak_Use (Container : Queue) return Count_Type is abstract;
+
+16/3
+ {AI05-0159-1AI05-0159-1} Returns the maximum number of
+ elements that have been in the queue at any one time.
+
+ NOTES
+
+17/3
+ 51 {AI05-0251-1AI05-0251-1} Unlike other language-defined
+ containers, there are no queues whose element types are indefinite.
+ Elements of an indefinite type can be handled by defining the
+ element of the queue to be a holder container (see *note A.18.18::)
+ of the indefinite type, or to be an explicit access type that
+ designates the indefinite type.
+
+17.a/3
+ Reason: There are no indefinite queues, as a useful definition
+ for Dequeue is not possible. Dequeue cannot be a function, as
+ Ada does not have entries that are functions (thus conditional
+ and timed calls would not be possible). Moreover, protected
+ functions do not allow modifying the queue object (thus it
+ doesn't work even if we decided we didn't care about
+ conditional and timed calls). If Dequeue is an entry, then
+ the dequeued object would have to be an out parameter and that
+ would require the queue client to guess the tag and
+ constraints of the value that will be dequeued (otherwise
+ Constraint_Error would be raised), and that is rarely going to
+ be possible.
+
+ _Extensions to Ada 2005_
+
+17.b/3
+ {AI05-0159-1AI05-0159-1} {AI05-0251-1AI05-0251-1} The generic
+ package Containers.Synchronized_Queue_Interfaces is new.
+
+\1f
+File: aarm2012.info, Node: A.18.28, Next: A.18.29, Prev: A.18.27, Up: A.18
+
+A.18.28 The Generic Package Containers.Unbounded_Synchronized_Queues
+--------------------------------------------------------------------
+
+ _Static Semantics_
+
+1/3
+{AI05-0159-1AI05-0159-1} The language-defined generic package
+Containers.Unbounded_Synchronized_Queues provides type Queue, which
+implements the interface type
+Containers.Synchronized_Queue_Interfaces.Queue.
+
+2/3
+ with System;
+ with Ada.Containers.Synchronized_Queue_Interfaces;
+ generic
+ with package Queue_Interfaces is new Ada.Containers.Synchronized_Queue_Interfaces (<>);
+ Default_Ceiling : System.Any_Priority := System.Priority'Last;
+ package Ada.Containers.Unbounded_Synchronized_Queues is
+ pragma Preelaborate(Unbounded_Synchronized_Queues);
+
+3/3
+ package Implementation is
+ ... -- not specified by the language
+ end Implementation;
+
+4/3
+ protected type Queue
+ (Ceiling : System.Any_Priority := Default_Ceiling)
+ with Priority => Ceiling is
+ new Queue_Interfaces.Queue with
+
+5/3
+ overriding
+ entry Enqueue (New_Item : in Queue_Interfaces.Element_Type);
+ overriding
+ entry Dequeue (Element : out Queue_Interfaces.Element_Type);
+
+6/3
+ overriding
+ function Current_Use return Count_Type;
+ overriding
+ function Peak_Use return Count_Type;
+
+7/3
+ private
+ ... -- not specified by the language
+ end Queue;
+
+8/3
+ private
+
+9/3
+ ... -- not specified by the language
+
+10/3
+ end Ada.Containers.Unbounded_Synchronized_Queues;
+
+11/3
+{AI05-0159-1AI05-0159-1} The type Queue is used to represent task-safe
+queues.
+
+12/3
+{AI05-0159-1AI05-0159-1} The capacity for instances of type Queue is
+unbounded.
+
+12.a/3
+ Ramification: Enqueue never blocks; if more storage is needed
+ for a new element, it is allocated dynamically. We don't need
+ to explicitly specify that Queue needs finalization, because
+ it is visibly protected.
+
+12.b/3
+ Discussion: Nested package Implementation can be used to
+ declare the types needed to implement the protected type
+ Queue. This nested package is necessary as types cannot be
+ declared in the private part of a protected type, and the
+ types have to be declared within the generic unit in order to
+ depend on the types imported with package Queue_Interfaces.
+ Clients should never depend on the contents of nested package
+ Implementation.
+
+ _Extensions to Ada 2005_
+
+12.c/3
+ {AI05-0159-1AI05-0159-1} The generic package
+ Containers.Unbounded_Synchronized_Queues is new.
+
+\1f
+File: aarm2012.info, Node: A.18.29, Next: A.18.30, Prev: A.18.28, Up: A.18
+
+A.18.29 The Generic Package Containers.Bounded_Synchronized_Queues
+------------------------------------------------------------------
+
+ _Static Semantics_
+
+1/3
+{AI05-0159-1AI05-0159-1} The language-defined generic package
+Containers.Bounded_Synchronized_Queues provides type Queue, which
+implements the interface type
+Containers.Synchronized_Queue_Interfaces.Queue.
+
+2/3
+ with System;
+ with Ada.Containers.Synchronized_Queue_Interfaces;
+ generic
+ with package Queue_Interfaces is new Ada.Containers.Synchronized_Queue_Interfaces (<>);
+ Default_Capacity : Count_Type;
+ Default_Ceiling : System.Any_Priority := System.Priority'Last;
+ package Ada.Containers.Bounded_Synchronized_Queues is
+ pragma Preelaborate(Bounded_Synchronized_Queues);
+
+3/3
+ package Implementation is
+ ... -- not specified by the language
+ end Implementation;
+
+4/3
+ protected type Queue
+ (Capacity : Count_Type := Default_Capacity;
+ Ceiling : System.Any_Priority := Default_Ceiling)
+ with Priority => Ceiling is
+ new Queue_Interfaces.Queue with
+
+5/3
+ overriding
+ entry Enqueue (New_Item : in Queue_Interfaces.Element_Type);
+ overriding
+ entry Dequeue (Element : out Queue_Interfaces.Element_Type);
+
+6/3
+ overriding
+ function Current_Use return Count_Type;
+ overriding
+ function Peak_Use return Count_Type;
+
+7/3
+ private
+ ... -- not specified by the language
+ end Queue;
+
+8/3
+ private
+
+9/3
+ ... -- not specified by the language
+
+10/3
+ end Ada.Containers.Bounded_Synchronized_Queues;
+
+11/3
+{AI05-0159-1AI05-0159-1} The semantics are the same as for
+Unbounded_Synchronized_Queues, except:
+
+12/3
+ * The capacity for instances of type Queue is bounded and specified
+ by the discriminant Capacity.
+
+12.a/3
+ Ramification: Since this type has a bounded capacity, Enqueue
+ might block if the queue is full.
+
+ _Implementation Advice_
+
+13/3
+{AI05-0159-1AI05-0159-1} Bounded queue objects should be implemented
+without implicit pointers or dynamic allocation.
+
+13.a.1/3
+ Implementation Advice: Bounded queue objects should be
+ implemented without implicit pointers or dynamic allocation.
+
+ _Extensions to Ada 2005_
+
+13.a/3
+ {AI05-0159-1AI05-0159-1} The generic package
+ Containers.Bounded_Synchronized_Queues is new.
+
+\1f
+File: aarm2012.info, Node: A.18.30, Next: A.18.31, Prev: A.18.29, Up: A.18
+
+A.18.30 The Generic Package Containers.Unbounded_Priority_Queues
+----------------------------------------------------------------
+
+ _Static Semantics_
+
+1/3
+{AI05-0159-1AI05-0159-1} The language-defined generic package
+Containers.Unbounded_Priority_Queues provides type Queue, which
+implements the interface type
+Containers.Synchronized_Queue_Interfaces.Queue.
+
+2/3
+ with System;
+ with Ada.Containers.Synchronized_Queue_Interfaces;
+ generic
+ with package Queue_Interfaces is new Ada.Containers.Synchronized_Queue_Interfaces (<>);
+ type Queue_Priority is private;
+ with function Get_Priority
+ (Element : Queue_Interfaces.Element_Type) return Queue_Priority is <>;
+ with function Before
+ (Left, Right : Queue_Priority) return Boolean is <>;
+ Default_Ceiling : System.Any_Priority := System.Priority'Last;
+ package Ada.Containers.Unbounded_Priority_Queues is
+ pragma Preelaborate(Unbounded_Priority_Queues);
+
+3/3
+ package Implementation is
+ ... -- not specified by the language
+ end Implementation;
+
+4/3
+ protected type Queue
+ (Ceiling : System.Any_Priority := Default_Ceiling)
+ with Priority => Ceiling is
+ new Queue_Interfaces.Queue with
+
+5/3
+ overriding
+ entry Enqueue (New_Item : in Queue_Interfaces.Element_Type);
+ overriding
+ entry Dequeue (Element : out Queue_Interfaces.Element_Type);
+
+6/3
+ {AI05-0159-1AI05-0159-1} {AI05-0251-1AI05-0251-1} not overriding
+ procedure Dequeue_Only_High_Priority
+ (At_Least : in Queue_Priority;
+ Element : in out Queue_Interfaces.Element_Type;
+ Success : out Boolean);
+
+7/3
+ overriding
+ function Current_Use return Count_Type;
+ overriding
+ function Peak_Use return Count_Type;
+
+8/3
+ private
+ ... -- not specified by the language
+ end Queue;
+
+9/3
+ private
+
+10/3
+ ... -- not specified by the language
+
+11/3
+ end Ada.Containers.Unbounded_Priority_Queues;
+
+12/3
+{AI05-0159-1AI05-0159-1} The type Queue is used to represent task-safe
+priority queues.
+
+13/3
+{AI05-0159-1AI05-0159-1} The capacity for instances of type Queue is
+unbounded.
+
+14/3
+{AI05-0159-1AI05-0159-1} Two elements E1 and E2 are equivalent if
+Before(Get_Priority(E1), Get_Priority(E2)) and Before(Get_Priority(E2),
+Get_Priority(E1)) both return False.
+
+15/3
+{AI05-0159-1AI05-0159-1} {AI05-0248-1AI05-0248-1} The actual functions
+for Get_Priority and Before are expected to return the same value each
+time they are called with the same actuals, and should not modify their
+actuals. Before should define a strict weak ordering relationship (see
+*note A.18::). If the actual functions behave in some other manner, the
+behavior of Unbounded_Priority_Queues is unspecified.
+
+16/3
+{AI05-0159-1AI05-0159-1} Enqueue inserts an item according to the order
+specified by the Before function on the result of Get_Priority on the
+elements; Before should return True if Left is to be inserted before
+Right. If the queue already contains elements equivalent to New_Item,
+then it is inserted after the existing equivalent elements.
+
+16.a/3
+ Ramification: Enqueue never blocks; if more storage is needed
+ for a new element, it is allocated dynamically. We don't need
+ to explicitly specify that Queue needs finalization, because
+ it is visibly protected.
+
+17/3
+{AI05-0159-1AI05-0159-1} {AI05-0251-1AI05-0251-1}
+{AI05-0262-1AI05-0262-1} For a call on Dequeue_Only_High_Priority, if
+the head of the nonempty queue is E, and the function Before(At_Least,
+Get_Priority(E)) returns False, then E is assigned to Element and then
+removed from the queue, and Success is set to True; otherwise, Success
+is set to False and Element is unchanged.
+
+17.a/3
+ Ramification: {AI05-0251-1AI05-0251-1} Unlike Dequeue,
+ Dequeue_Only_High_Priority is not blocking; it always returns
+ immediately.
+
+17.b/3
+ Reason: {AI05-0251-1AI05-0251-1} The use of Before is
+ "backwards" so that it acts like ">=" (it is defined similarly
+ to ">"); thus we dequeue only when it is False.
+
+ _Extensions to Ada 2005_
+
+17.c/3
+ {AI05-0159-1AI05-0159-1} {AI05-0251-1AI05-0251-1} The generic
+ package Containers.Unbounded_Priority_Queues is new.
+
+\1f
+File: aarm2012.info, Node: A.18.31, Next: A.18.32, Prev: A.18.30, Up: A.18
+
+A.18.31 The Generic Package Containers.Bounded_Priority_Queues
+--------------------------------------------------------------
+
+ _Static Semantics_
+
+1/3
+{AI05-0159-1AI05-0159-1} The language-defined generic package
+Containers.Bounded_Priority_Queues provides type Queue, which implements
+the interface type Containers.Synchronized_Queue_Interfaces.Queue.
+
+2/3
+ with System;
+ with Ada.Containers.Synchronized_Queue_Interfaces;
+ generic
+ with package Queue_Interfaces is new Ada.Containers.Synchronized_Queue_Interfaces (<>);
+ type Queue_Priority is private;
+ with function Get_Priority
+ (Element : Queue_Interfaces.Element_Type) return Queue_Priority is <>;
+ with function Before
+ (Left, Right : Queue_Priority) return Boolean is <>;
+ Default_Capacity : Count_Type;
+ Default_Ceiling : System.Any_Priority := System.Priority'Last;
+ package Ada.Containers.Bounded_Priority_Queues is
+ pragma Preelaborate(Bounded_Priority_Queues);
+
+3/3
+ package Implementation is
+ ... -- not specified by the language
+ end Implementation;
+
+4/3
+ protected type Queue
+ (Capacity : Count_Type := Default_Capacity;
+ Ceiling : System.Any_Priority := Default_Ceiling)
+ with Priority => Ceiling is
+ new Queue_Interfaces.Queue with
+
+5/3
+ overriding
+ entry Enqueue (New_Item : in Queue_Interfaces.Element_Type);
+ overriding
+ entry Dequeue (Element : out Queue_Interfaces.Element_Type);
+
+6/3
+ {AI05-0159-1AI05-0159-1} {AI05-0251-1AI05-0251-1} not overriding
+ procedure Dequeue_Only_High_Priority
+ (At_Least : in Queue_Priority;
+ Element : in out Queue_Interfaces.Element_Type;
+ Success : out Boolean);
+
+7/3
+ overriding
+ function Current_Use return Count_Type;
+ overriding
+ function Peak_Use return Count_Type;
+
+8/3
+ private
+ ... -- not specified by the language
+ end Queue;
+
+9/3
+ private
+
+10/3
+ ... -- not specified by the language
+
+11/3
+ end Ada.Containers.Bounded_Priority_Queues;
+
+12/3
+{AI05-0159-1AI05-0159-1} The semantics are the same as for
+Unbounded_Priority_Queues, except:
+
+13/3
+ * The capacity for instances of type Queue is bounded and specified
+ by the discriminant Capacity.
+
+13.a/3
+ Ramification: Since this type has a bounded capacity, Enqueue
+ might block if the queue is full.
+
+ _Implementation Advice_
+
+14/3
+{AI05-0159-1AI05-0159-1} Bounded priority queue objects should be
+implemented without implicit pointers or dynamic allocation.
+
+14.a.1/3
+ Implementation Advice: Bounded priority queue objects should
+ be implemented without implicit pointers or dynamic
+ allocation.
+
+ _Extensions to Ada 2005_
+
+14.a/3
+ {AI05-0159-1AI05-0159-1} {AI05-0251-1AI05-0251-1} The generic
+ package Containers.Bounded_Priority_Queues is new.
+
+\1f
+File: aarm2012.info, Node: A.18.32, Prev: A.18.31, Up: A.18
+
+A.18.32 Example of Container Use
+--------------------------------
+
+ _Examples_
+
+1/3
+{AI05-0212-1AI05-0212-1} The following example is an implementation of
+Dijkstra's shortest path algorithm in a directed graph with positive
+distances. The graph is represented by a map from nodes to sets of
+edges.
+
+2/3
+ with Ada.Containers.Vectors;
+ with Ada.Containers.Doubly_Linked_Lists;
+ use Ada.Containers;
+ generic
+ type Node is range <>;
+ package Shortest_Paths is
+ type Distance is new Float range 0.0 .. Float'Last;
+ type Edge is record
+ To, From : Node;
+ Length : Distance;
+ end record;
+
+3/3
+ package Node_Maps is new Vectors (Node, Node);
+ -- The algorithm builds a map to indicate the node used to reach a given
+ -- node in the shortest distance.
+
+4/3
+ package Adjacency_Lists is new Doubly_Linked_Lists (Edge);
+ use Adjacency_Lists;
+
+5/3
+ package Graphs is new Vectors (Node, Adjacency_Lists.List);
+
+6/3
+ package Paths is new Doubly_Linked_Lists (Node);
+
+7/3
+ function Shortest_Path
+ (G : Graphs.Vector; Source : Node; Target : Node) return Paths.List
+ with Pre => G (Source) /= Adjacency_Lists.Empty_List;
+
+8/3
+ end Shortest_Paths;
+
+9/3
+ package body Shortest_Paths is
+ function Shortest_Path
+ (G : Graphs.Vector; Source : Node; Target : Node) return Paths.List
+ is
+ use Adjacency_Lists, Node_Maps, Paths, Graphs;
+ Reached : array (Node) of Boolean := (others => False);
+ -- The set of nodes whose shortest distance to the source is known.
+
+10/3
+ {AI05-0299-1AI05-0299-1} Reached_From : array (Node) of Node;
+ So_Far : array (Node) of Distance := (others => Distance'Last);
+ The_Path : Paths.List := Paths.Empty_List;
+ Nearest_Distance : Distance;
+ Next : Node;
+ begin
+ So_Far(Source) := 0.0;
+
+11/3
+ while not Reached(Target) loop
+ Nearest_Distance := Distance'Last;
+
+12/3
+ -- Find closest node not reached yet, by iterating over all nodes.
+ -- A more efficient algorithm uses a priority queue for this step.
+
+13/3
+ Next := Source;
+ for N in Node'First .. Node'Last loop
+ if not Reached(N)
+ and then So_Far(N) < Nearest_Distance then
+ Next := N;
+ Nearest_Distance := So_Far(N);
+ end if;
+ end loop;
+
+14/3
+ {AI05-0299-1AI05-0299-1} if Nearest_Distance = Distance'Last then
+ -- No next node found, graph is not connected
+ return Paths.Empty_List;
+
+15/3
+ else
+ Reached(Next) := True;
+ end if;
+
+16/3
+ -- Update minimum distance to newly reachable nodes.
+
+17/3
+ {AI05-0299-1AI05-0299-1} for E of G (Next) loop
+ if not Reached(E.To) then
+ Nearest_Distance := E.Length + So_Far(Next);
+
+18/3
+ if Nearest_Distance < So_Far(E.To) then
+ Reached_From(E.To) := Next;
+ So_Far(E.To) := Nearest_Distance;
+ end if;
+ end if;
+ end loop;
+ end loop;
+
+19/3
+ -- Rebuild path from target to source.
+
+20/3
+ declare
+ N : Node := Target;
+ begin
+ while N /= Source loop
+ N := Reached_From(N);
+ Prepend (The_Path, N);
+ end loop;
+ end;
+
+21/3
+ return The_Path;
+ end;
+ end Shortest_Paths;
+
+22/3
+{AI05-0212-1AI05-0212-1} Note that the effect of the Constant_Indexing
+aspect (on type Vector) and the Implicit_Dereference aspect (on type
+Reference_Type) is that
+
+23/3
+ G (Next)
+
+24/3
+{AI05-0212-1AI05-0212-1} is a convenient short hand for
+
+25/3
+ G.Constant_Reference (Next).Element.all
+
+26/3
+{AI05-0212-1AI05-0212-1} Similarly, the effect of the loop:
+
+27/3
+ for E of G (Next) loop
+ if not Reached(E.To) then
+ ...
+ end if;
+ end loop;
+
+28/3
+{AI05-0212-1AI05-0212-1} is the same as:
+
+29/3
+ for C in G (Next).Iterate loop
+ declare
+ E : Edge renames G (Next)(C).all;
+ begin
+ if not Reached(E.To) then
+ ...
+ end if;
+ end;
+ end loop;
+
+30/3
+{AI05-0212-1AI05-0212-1} which is the same as:
+
+31/3
+ declare
+ L : Adjacency_Lists.List renames G (Next);
+ C : Adjacency_Lists.Cursor := L.First;
+ begin
+ while Has_Element (C) loop
+ declare
+ E : Edge renames L(C).all;
+ begin
+ if not Reached(E.To) then
+ ...
+ end if;
+ end;
+ C := L.Next (C);
+ end loop;
+ end;
+
+ _Wording Changes from Ada 2005_
+
+31.a/3
+ {AI05-0212-1AI05-0212-1} This example of container use is new.
+
+\1f
+File: aarm2012.info, Node: A.19, Prev: A.18, Up: Annex A
+
+A.19 The Package Locales
+========================
+
+1/3
+{AI05-0127-2AI05-0127-2} {AI05-0248-1AI05-0248-1} A locale identifies a
+geopolitical place or region and its associated language, which can be
+used to determine other internationalization-related characteristics.
+
+ _Static Semantics_
+
+2/3
+{AI05-0127-2AI05-0127-2} The library package Locales has the following
+declaration:
+
+3/3
+ package Ada.Locales is
+ pragma Preelaborate(Locales);
+ pragma Remote_Types(Locales);
+
+4/3
+ type Language_Code is array (1 .. 3) of Character range 'a' .. 'z';
+ type Country_Code is array (1 .. 2) of Character range 'A' .. 'Z';
+
+5/3
+ Language_Unknown : constant Language_Code := "und";
+ Country_Unknown : constant Country_Code := "ZZ";
+
+6/3
+ function Language return Language_Code;
+ function Country return Country_Code;
+
+7/3
+ end Ada.Locales;
+
+8/3
+{AI05-0127-2AI05-0127-2} {AI05-0233-1AI05-0233-1} The active locale is
+the locale associated with the partition of the current task.
+
+8.a/3
+ Implementation Note: {AI05-0233-1AI05-0233-1} Some
+ environments define both a system locale and the locale of the
+ current user. For such environments, the active locale is
+ that of current user if any; otherwise (as in a partition
+ running on a server without a user), the system locale should
+ be used.
+
+9/3
+{AI05-0127-2AI05-0127-2} Language_Code is a lower-case string
+representation of an ISO 639-3 alpha-3 code that identifies a language.
+
+9.a/3
+ Discussion: Some common language codes are: "eng" - English;
+ "fra" - French; "deu" - German; "zho" - Chinese. These are
+ the same codes as used by POSIX systems. We considered
+ including constants for the most common languages, but that
+ was rejected as the likely source of continual arguments about
+ the constant names and which languages are important enough to
+ include.
+
+10/3
+{AI05-0127-2AI05-0127-2} Country_Code is an upper-case string
+representation of an ISO 3166-1 alpha-2 code that identifies a country.
+
+10.a/3
+ Discussion: Some common country codes are: "CA" - Canada; "FR"
+ - France; "DE" - Germany; "IT" - Italy; "ES" - Spain; "GB" -
+ United Kingdom; "US" - United States. These are the same
+ codes as used by POSIX systems. We didn't include any country
+ constants for the same reasons that we didn't include any
+ language constants.
+
+11/3
+{AI05-0127-2AI05-0127-2} {AI05-0248-1AI05-0248-1} Function Language
+returns the code of the language associated with the active locale. If
+the Language_Code associated with the active locale cannot be determined
+from the environment, then Language returns Language_Unknown.
+
+12/3
+{AI05-0127-2AI05-0127-2} {AI05-0248-1AI05-0248-1} Function Country
+returns the code of the country associated with the active locale. If
+the Country_Code associated with the active locale cannot be determined
+from the environment, then Country returns Country_Unknown.
+
+ _Extensions to Ada 2005_
+
+12.a/3
+ {AI05-0127-2AI05-0127-2} {AI05-0233-1AI05-0233-1} Package
+ Locales is new.
+
+\1f
+File: aarm2012.info, Node: Annex B, Next: Annex C, Prev: Annex A, Up: Top
+
+Annex B Interface to Other Languages
+************************************
+
+1
+This Annex describes features for writing mixed-language programs.
+General interface support is presented first; then specific support for
+C, COBOL, and Fortran is defined, in terms of language interface
+packages for each of these languages.
+
+1.a
+ Ramification: This Annex is not a "Specialized Needs" annex.
+ Every implementation must support all nonoptional features
+ defined here (mainly the package Interfaces).
+
+ _Language Design Principles_
+
+1.b
+ Ada should have strong support for mixed-language programming.
+
+ _Implementation Requirements_
+
+2/3
+{AI05-0229-1AI05-0229-1} {AI05-0262-1AI05-0262-1}
+{AI05-0299-1AI05-0299-1} Support for interfacing to any foreign language
+is optional. However, an implementation shall not provide any optional
+aspect, attribute, library unit, or pragma having the same name as an
+aspect, attribute, library unit, or pragma (respectively) specified in
+the subclauses of this Annex unless the provided construct is either as
+specified in those subclauses or is more limited in capability than that
+required by those subclauses. A program that attempts to use an
+unsupported capability of this Annex shall either be identified by the
+implementation before run time or shall raise an exception at run time.
+
+2.a/3
+ Discussion: The intent is that the same rules apply for the
+ optional parts of language interfacing as apply for
+ Specialized Needs Annexes. See *note 1.1.3:: for a discussion
+ of the purpose of these rules.
+
+ _Extensions to Ada 83_
+
+2.b
+ Much of the functionality in this Annex is new to Ada 95.
+
+ _Wording Changes from Ada 83_
+
+2.c
+ This Annex contains what used to be RM83-13.8.
+
+ _Wording Changes from Ada 2005_
+
+2.d/3
+ {AI05-0262-1AI05-0262-1} Moved the clarification that
+ interfacing to foreign languages is optional and has the same
+ restrictions as a Specialized Needs Annex here.
+
+* Menu:
+
+* B.1 :: Interfacing Aspects
+* B.2 :: The Package Interfaces
+* B.3 :: Interfacing with C and C++
+* B.4 :: Interfacing with COBOL
+* B.5 :: Interfacing with Fortran
+
+\1f
+File: aarm2012.info, Node: B.1, Next: B.2, Up: Annex B
+
+B.1 Interfacing Aspects
+=======================
+
+0.1/3
+{AI05-0229-1AI05-0229-1} An interfacing aspect is a representation
+aspect that is one of the aspects Import, Export, Link_Name,
+External_Name, or Convention.
+
+1/3
+{AI05-0229-1AI05-0229-1} {AI05-0269-1AI05-0269-1} Specifying the Import
+aspect to have the value True is used to import an entity defined in a
+foreign language into an Ada program, thus allowing a foreign-language
+subprogram to be called from Ada, or a foreign-language variable to be
+accessed from Ada. In contrast, specifying the Export aspect to have
+the value True is used to export an Ada entity to a foreign language,
+thus allowing an Ada subprogram to be called from a foreign language, or
+an Ada object to be accessed from a foreign language. The Import and
+Export aspects are intended primarily for objects and subprograms,
+although implementations are allowed to support other entities. The
+Link_Name and External_Name aspects are used to specify the link name
+and external name, respectively, to be used to identify imported or
+exported entities in the external environment.
+
+1.a/3
+ Aspect Description for Import: Entity is imported from another
+ language.
+
+1.b/3
+ Aspect Description for Export: Entity is exported to another
+ language.
+
+1.c/3
+ Aspect Description for External_Name: Name used to identify an
+ imported or exported entity.
+
+1.d/3
+ Aspect Description for Link_Name: Linker symbol used to
+ identify an imported or exported entity.
+
+2/3
+{AI05-0229-1AI05-0229-1} The Convention aspect is used to indicate that
+an Ada entity should use the conventions of another language. It is
+intended primarily for types and "callback" subprograms. For example,
+"with Convention => Fortran" on the declaration of an array type Matrix
+implies that Matrix should be represented according to the conventions
+of the supported Fortran implementation, namely column-major order.
+
+2.a/3
+ Aspect Description for Convention: Calling convention or other
+ convention used for interfacing to other languages.
+
+3
+A pragma Linker_Options is used to specify the system linker parameters
+needed when a given compilation unit is included in a partition.
+
+ _Syntax_
+
+4/3
+ {AI05-0229-1AI05-0229-1} The form of a pragma Linker_Options is as
+ follows:
+
+ Paragraphs 5 through 7 were moved to *note Annex J::, "*note Annex
+ J:: Obsolescent Features".
+
+8
+ pragma Linker_Options(string_expression);
+
+9
+ A pragma Linker_Options is allowed only at the place of a
+ declarative_item.
+
+9.1/3
+ This paragraph was deleted.{8652/00588652/0058}
+ {AI95-00036-01AI95-00036-01} {AI05-0229-1AI05-0229-1}
+
+ _Name Resolution Rules_
+
+9.2/3
+{AI05-0229-1AI05-0229-1} The Import and Export aspects are of type
+Boolean.
+
+10/3
+{AI05-0229-1AI05-0229-1} The Link_Name and External_Name aspects are of
+type String.
+
+10.a/3
+ Ramification: There is no language-defined support for
+ external or link names of type Wide_String, or of other string
+ types. Implementations may, of course, have additional
+ aspects for that purpose. Note that allowing both String and
+ Wide_String in the same aspect_definition would cause
+ ambiguities.
+
+10.1/3
+{AI05-0229-1AI05-0229-1} The expected type for the string_expression in
+pragma Linker_Options is String.
+
+ _Legality Rules_
+
+11/3
+{AI05-0229-1AI05-0229-1} The aspect Convention shall be specified by a
+convention_identifier which shall be the name of a convention. The
+convention names are implementation defined, except for certain
+language-defined ones, such as Ada and Intrinsic, as explained in *note
+6.3.1::, "*note 6.3.1:: Conformance Rules". [Additional convention
+names generally represent the calling conventions of foreign languages,
+language implementations, or specific run-time models.] The convention
+of a callable entity is its calling convention.
+
+11.a
+ Implementation defined: Implementation-defined convention
+ names.
+
+11.b
+ Discussion: We considered representing the convention names
+ using an enumeration type declared in System. Then,
+ convention_identifier would be changed to convention_name, and
+ we would make its expected type be the enumeration type. We
+ didn't do this because it seems to introduce extra complexity,
+ and because the list of available languages is better
+ represented as the list of children of package Interfaces -- a
+ more open-ended sort of list.
+
+12
+If L is a convention_identifier for a language, then a type T is said to
+be compatible with convention L, (alternatively, is said to be an
+L-compatible type) if any of the following conditions are met:
+
+13
+ * T is declared in a language interface package corresponding to L
+ and is defined to be L-compatible (see *note B.3::, *note B.3.1::,
+ *note B.3.2::, *note B.4::, *note B.5::),
+
+14/3
+ * {AI05-0229-1AI05-0229-1} Convention L has been specified for T, and
+ T is eligible for convention L; that is:
+
+15
+ * T is an array type with either an unconstrained or
+ statically-constrained first subtype, and its component
+ type is L-compatible,
+
+16
+ * T is a record type that has no discriminants and that
+ only has components with statically-constrained subtypes,
+ and each component type is L-compatible,
+
+17/3
+ * {AI05-0002-1AI05-0002-1} T is an access-to-object type,
+ its designated type is L-compatible, and its designated
+ subtype is not an unconstrained array subtype,
+
+18
+ * T is an access-to-subprogram type, and its designated
+ profile's parameter and result types are all
+ L-compatible.
+
+19
+ * T is derived from an L-compatible type,
+
+20
+ * The implementation permits T as an L-compatible type.
+
+20.a
+ Discussion: For example, an implementation might permit
+ Integer as a C-compatible type, though the C type to which it
+ corresponds might be different in different environments.
+
+21/3
+{AI05-0229-1AI05-0229-1} If the Convention aspect is specified for a
+type, then the type shall either be compatible with or eligible for the
+specified convention.
+
+21.a/3
+ Ramification: {AI05-0229-1AI05-0229-1} If a type is derived
+ from an L-compatible type, the derived type is by default
+ L-compatible, but it is also permitted to specify the
+ Convention aspect for the derived type.
+
+21.b/3
+ {AI05-0229-1AI05-0229-1} It is permitted to specify the
+ Convention aspect for an incomplete type, but in the complete
+ declaration each component must be L-compatible.
+
+21.c/3
+ {AI05-0229-1AI05-0229-1} If each component of a record type is
+ L-compatible, then the record type itself is only L-compatible
+ if it has a specified Convention.
+
+22/3
+{AI05-0229-1AI05-0229-1} Notwithstanding any rule to the contrary, a
+declaration with a True Import aspect shall not have a completion.
+
+22.a/3
+ Discussion: {AI05-0229-1AI05-0229-1} For declarations of
+ deferred constants and subprograms, we explicitly mention that
+ no completion is allowed when aspect Import is True. For
+ other declarations that require completions, we ignore the
+ possibility of the aspect Import being True. Nevertheless, if
+ an implementation chooses to allow specifying aspect Import to
+ be True for the declaration of a task, protected type,
+ incomplete type, private type, etc., it may do so, and the
+ normal completion is then not allowed for that declaration.
+
+23/3
+{AI05-0229-1AI05-0229-1} An entity with a True Import aspect (or Export
+aspect) is said to be imported (respectively, exported). An entity
+shall not be both imported and exported.
+
+24
+The declaration of an imported object shall not include an explicit
+initialization expression. [Default initializations are not performed.]
+
+24.a
+ Proof: This follows from the "Notwithstanding ..." wording in
+ the Dynamics Semantics paragraphs below.
+
+25/3
+{AI05-0229-1AI05-0229-1} The type of an imported or exported object
+shall be compatible with the specified Convention aspect, if any.
+
+25.a
+ Ramification: This implies, for example, that importing an
+ Integer object might be illegal, whereas importing an object
+ of type Interfaces.C.int would be permitted.
+
+26/3
+{AI05-0229-1AI05-0229-1} For an imported or exported subprogram, the
+result and parameter types shall each be compatible with the specified
+Convention aspect, if any.
+
+27/3
+{AI05-0229-1AI05-0229-1} The aspect_definition (if any) used to directly
+specify an Import, Export, External_Name, or Link_Name aspect shall be a
+static expression. The string_expression of a pragma Linker_Options
+shall be static. An External_Name or Link_Name aspect shall be
+specified only for an entity that is either imported or exported.
+
+ _Static Semantics_
+
+Paragraphs 28 and 29 were deleted.
+
+30/3
+{AI05-0229-1AI05-0229-1} The Convention aspect represents the calling
+convention or representation convention of the entity. For an
+access-to-subprogram type, it represents the calling convention of
+designated subprograms. In addition:
+
+31/3
+ * A True Import aspect indicates that the entity is defined
+ externally (that is, outside the Ada program). This aspect is
+ never inherited; if not directly specified, the Import aspect is
+ False.
+
+32/3
+ * A True Export aspect indicates that the entity is used externally.
+ This aspect is never inherited; if not directly specified, the
+ Export aspect is False.
+
+33/3
+ * For an entity with a True Import or Export aspect, an external
+ name, link name, or both may also be specified.
+
+34
+An external name is a string value for the name used by a foreign
+language program either for an entity that an Ada program imports, or
+for referring to an entity that an Ada program exports.
+
+35
+A link name is a string value for the name of an exported or imported
+entity, based on the conventions of the foreign language's compiler in
+interfacing with the system's linker tool.
+
+36
+The meaning of link names is implementation defined. If neither a link
+name nor the Address attribute of an imported or exported entity is
+specified, then a link name is chosen in an implementation-defined
+manner, based on the external name if one is specified.
+
+36.a
+ Implementation defined: The meaning of link names.
+
+36.b
+ Ramification: For example, an implementation might always
+ prepend "_", and then pass it to the system linker.
+
+36.c
+ Implementation defined: The manner of choosing link names when
+ neither the link name nor the address of an imported or
+ exported entity is specified.
+
+36.d
+ Ramification: Normally, this will be the entity's defining
+ name, or some simple transformation thereof.
+
+37
+Pragma Linker_Options has the effect of passing its string argument as a
+parameter to the system linker (if one exists), if the immediately
+enclosing compilation unit is included in the partition being linked.
+The interpretation of the string argument, and the way in which the
+string arguments from multiple Linker_Options pragmas are combined, is
+implementation defined.
+
+37.a
+ Implementation defined: The effect of pragma Linker_Options.
+
+ _Dynamic Semantics_
+
+38/3
+{AI05-0229-1AI05-0229-1} Notwithstanding what this International
+Standard says elsewhere, the elaboration of a declaration with a True
+Import aspect does not create the entity. Such an elaboration has no
+other effect than to allow the defining name to denote the external
+entity.
+
+38.a
+ Ramification: This implies that default initializations are
+ skipped. (Explicit initializations are illegal.) For
+ example, an imported access object is not initialized to null.
+
+38.b/3
+ This paragraph was deleted.{AI05-0229-1AI05-0229-1}
+
+38.c/3
+ Discussion: {AI05-0229-1AI05-0229-1} This "notwithstanding"
+ wording is better than saying "unless aspect Import is True"
+ on every definition of elaboration. It says we recognize the
+ contradiction, and this rule takes precedence.
+
+ _Erroneous Execution_
+
+38.1/3
+{AI95-00320-01AI95-00320-01} {AI05-0229-1AI05-0229-1} It is the
+programmer's responsibility to ensure that the use of interfacing
+aspects does not violate Ada semantics; otherwise, program execution is
+erroneous.
+
+ _Implementation Advice_
+
+39/3
+{AI05-0229-1AI05-0229-1} If an implementation supports Export for a
+given language, then it should also allow the main subprogram to be
+written in that language. It should support some mechanism for invoking
+the elaboration of the Ada library units included in the system, and for
+invoking the finalization of the environment task. On typical systems,
+the recommended mechanism is to provide two subprograms whose link names
+are "adainit" and "adafinal". Adainit should contain the elaboration
+code for library units. Adafinal should contain the finalization code.
+These subprograms should have no effect the second and subsequent time
+they are called.
+
+39.a.1/3
+ Implementation Advice: If Export is supported for a language,
+ the main program should be able to be written in that
+ language. Subprograms named "adainit" and "adafinal" should
+ be provided for elaboration and finalization of the
+ environment task.
+
+39.a
+ Ramification: For example, if the main subprogram is written
+ in C, it can call adainit before the first call to an Ada
+ subprogram, and adafinal after the last.
+
+40/3
+{AI05-0229-1AI05-0229-1} {AI05-0269-1AI05-0269-1} Automatic elaboration
+of preelaborated packages should be provided when specifying the Export
+aspect as True is supported.
+
+40.a.1/3
+ Implementation Advice: Automatic elaboration of preelaborated
+ packages should be provided when specifying the Export aspect
+ as True is supported.
+
+41/3
+{AI05-0229-1AI05-0229-1} For each supported convention L other than
+Intrinsic, an implementation should support specifying the Import and
+Export aspects for objects of L-compatible types and for subprograms,
+and the Convention aspect for L-eligible types and for subprograms,
+presuming the other language has corresponding features. Specifying the
+Convention aspect need not be supported for scalar types.
+
+41.a.1/3
+ Implementation Advice: For each supported convention L other
+ than Intrinsic, specifying the aspects Import and Export
+ should be supported for objects of L-compatible types and for
+ subprograms, and aspect Convention should be supported for
+ L-eligible types and for subprograms.
+
+41.a/3
+ Reason: {AI05-0229-1AI05-0229-1} Specifying aspect Convention
+ is not necessary for scalar types, since the language
+ interface packages declare scalar types corresponding to those
+ provided by the respective foreign languages.
+
+41.b/2
+ Implementation Note: {AI95-00114-01AI95-00114-01} If an
+ implementation supports interfacing to the C++ entities not
+ supported by *note B.3::, it should do so via the convention
+ identifier C_Plus_Plus (in additional to any
+ C++-implementation-specific ones).
+
+41.c/2
+ Reason: {AI95-00114-01AI95-00114-01} The reason for giving the
+ advice about C++ is to encourage uniformity among
+ implementations, given that the name of the language is not
+ syntactically legal as an identifier.
+
+ NOTES
+
+42/3
+ 1 {AI05-0229-1AI05-0229-1} Implementations may place restrictions
+ on interfacing aspects; for example, requiring each exported entity
+ to be declared at the library level.
+
+42.a
+ Proof: Arbitrary restrictions are allowed by *note 13.1::.
+
+42.b
+ Ramification: Such a restriction might be to disallow them
+ altogether. Alternatively, the implementation might allow
+ them only for certain kinds of entities, or only for certain
+ conventions.
+
+43/3
+ 2 {AI05-0229-1AI05-0229-1} The Convention aspect in combination
+ with the Import aspect indicates the conventions for accessing
+ external entities. It is possible that the actual entity is
+ written in assembly language, but reflects the conventions of a
+ particular language. For example, with Convention => Ada can be
+ used to interface to an assembly language routine that obeys the
+ Ada compiler's calling conventions.
+
+44/3
+ 3 {AI05-0229-1AI05-0229-1} To obtain "call-back" to an Ada
+ subprogram from a foreign language environment, the Convention
+ aspect should be specified both for the access-to-subprogram type
+ and the specific subprogram(s) to which 'Access is applied.
+
+ Paragraphs 45 and 46 were deleted.
+
+47
+ 4 See also *note 13.8::, "*note 13.8:: Machine Code Insertions".
+
+47.a/3
+ Ramification: {AI05-0229-1AI05-0229-1} The Intrinsic
+ convention (see *note 6.3.1::) implies that the entity is
+ somehow "built in" to the implementation. Thus, it generally
+ does not make sense for users to specify Intrinsic along with
+ specifying that the entity is imported. The intention is that
+ only implementations will specify Intrinsic for an imported
+ entity. The language also defines certain subprograms to be
+ Intrinsic.
+
+47.b/3
+ Discussion: {AI05-0229-1AI05-0229-1} There are many imaginable
+ interfacing aspects that don't make any sense. For example,
+ setting the Convention of a protected procedure to Ada is
+ probably wrong. Rather than enumerating all such cases,
+ however, we leave it up to implementations to decide what is
+ sensible.
+
+48/3
+ 5 {AI05-0229-1AI05-0229-1} If both External_Name and Link_Name are
+ specified for a given entity, then the External_Name is ignored.
+
+49/2
+ This paragraph was deleted.{AI95-00320-01AI95-00320-01}
+
+ _Examples_
+
+50
+Example of interfacing pragmas:
+
+51/3
+ {AI05-0229-1AI05-0229-1} {AI05-0269-1AI05-0269-1} package Fortran_Library is
+ function Sqrt (X : Float) return Float
+ with Import => True, Convention => Fortran;
+ type Matrix is array (Natural range <>, Natural range <>) of Float
+ with Convention => Fortran;
+ function Invert (M : Matrix) return Matrix
+ with Import => True, Convention => Fortran;
+ end Fortran_Library;
+
+ _Extensions to Ada 83_
+
+51.a
+ Interfacing pragmas are new to Ada 95. Pragma Import replaces
+ Ada 83's pragma Interface. Existing implementations can
+ continue to support pragma Interface for upward compatibility.
+
+ _Wording Changes from Ada 95_
+
+51.b/2
+ {8652/00588652/0058} {AI95-00036-01AI95-00036-01} Corrigendum:
+ Clarified that pragmas Import and Export work like a
+ subprogram call; parameters cannot be omitted unless named
+ notation is used. (Reordering is still not permitted,
+ however.)
+
+51.c/2
+ {AI95-00320-01AI95-00320-01} Added wording to say all bets are
+ off if foreign code doesn't follow the semantics promised by
+ the Ada specifications.
+
+ _Incompatibilities With Ada 2005_
+
+51.d/3
+ {AI05-0002-1AI05-0002-1} Correction: Access types that
+ designate unconstrained arrays are no longer defined to be
+ L-compatible. Such access-to-arrays require bounds
+ information, which is likely to be incompatible with a foreign
+ language. The change will allow (but not require) compilers
+ to reject bad uses, which probably will not work anyway. Note
+ that implementations can still support any type that it wants
+ as L-compatible; such uses will not be portable, however. As
+ such, there should be little existing code that will be
+ impacted (compilers probably already rejected cases that could
+ not be translated, whether or not the language allowed doing
+ so formally).
+
+ _Extensions to Ada 2005_
+
+51.e/3
+ {AI05-0229-1AI05-0229-1} Aspects Convention, Import, Export,
+ Link_Name, and External_Name are new; pragmas Convention,
+ Import, and Export are now obsolescent.
+
+\1f
+File: aarm2012.info, Node: B.2, Next: B.3, Prev: B.1, Up: Annex B
+
+B.2 The Package Interfaces
+==========================
+
+1
+Package Interfaces is the parent of several library packages that
+declare types and other entities useful for interfacing to foreign
+languages. It also contains some implementation-defined types that are
+useful across more than one language (in particular for interfacing to
+assembly language).
+
+1.a
+ Implementation defined: The contents of the visible part of
+ package Interfaces and its language-defined descendants.
+
+ _Static Semantics_
+
+2
+The library package Interfaces has the following skeletal declaration:
+
+3
+
+ package Interfaces is
+ pragma Pure(Interfaces);
+
+4
+ type Integer_n is range -2**(n-1) .. 2**(n-1) - 1; --2's complement
+
+5
+ type Unsigned_n is mod 2**n;
+
+6
+ function Shift_Left (Value : Unsigned_n; Amount : Natural)
+ return Unsigned_n;
+ function Shift_Right (Value : Unsigned_n; Amount : Natural)
+ return Unsigned_n;
+ function Shift_Right_Arithmetic (Value : Unsigned_n; Amount : Natural)
+ return Unsigned_n;
+ function Rotate_Left (Value : Unsigned_n; Amount : Natural)
+ return Unsigned_n;
+ function Rotate_Right (Value : Unsigned_n; Amount : Natural)
+ return Unsigned_n;
+ ...
+ end Interfaces;
+
+ _Implementation Requirements_
+
+7
+An implementation shall provide the following declarations in the
+visible part of package Interfaces:
+
+8
+ * Signed and modular integer types of n bits, if supported by the
+ target architecture, for each n that is at least the size of a
+ storage element and that is a factor of the word size. The names
+ of these types are of the form Integer_n for the signed types, and
+ Unsigned_n for the modular types;
+
+8.a
+ Ramification: For example, for a typical 32-bit machine the
+ corresponding types might be Integer_8, Unsigned_8,
+ Integer_16, Unsigned_16, Integer_32, and Unsigned_32.
+
+8.b
+ The wording above implies, for example, that Integer_16'Size =
+ Unsigned_16'Size = 16. Unchecked conversions between
+ same-Sized types will work as expected.
+
+9
+ * For each such modular type in Interfaces, shifting and rotating
+ subprograms as specified in the declaration of Interfaces above.
+ These subprograms are Intrinsic. They operate on a bit-by-bit
+ basis, using the binary representation of the value of the operands
+ to yield a binary representation for the result. The Amount
+ parameter gives the number of bits by which to shift or rotate.
+ For shifting, zero bits are shifted in, except in the case of
+ Shift_Right_Arithmetic, where one bits are shifted in if Value is
+ at least half the modulus.
+
+9.a
+ Reason: We considered making shifting and rotating be
+ primitive operations of all modular types. However, it is a
+ design principle of Ada that all predefined operations should
+ be operators (not functions named by identifiers). (Note that
+ an early version of Ada had "abs" as an identifier, but it was
+ changed to a reserved word operator before standardization of
+ Ada 83.) This is important because the implicit declarations
+ would hide nonoverloadable declarations with the same name,
+ whereas operators are always overloadable. Therefore, we
+ would have had to make shift and rotate into reserved words,
+ which would have been upward incompatible, or else invent new
+ operator symbols, which seemed like too much mechanism.
+
+10
+ * Floating point types corresponding to each floating point format
+ fully supported by the hardware.
+
+10.a
+ Implementation Note: The names for these floating point types
+ are not specified. However, if IEEE arithmetic is supported,
+ then the names should be IEEE_Float_32 and IEEE_Float_64 for
+ single and double precision, respectively.
+
+ _Implementation Permissions_
+
+11
+An implementation may provide implementation-defined library units that
+are children of Interfaces, and may add declarations to the visible part
+of Interfaces in addition to the ones defined above.
+
+11.a/2
+ Implementation defined: Implementation-defined children of
+ package Interfaces.
+
+11.1/3
+{AI95-00204-01AI95-00204-01} {AI05-0229-1AI05-0229-1} A child package of
+package Interfaces with the name of a convention may be provided
+independently of whether the convention is supported by the Convention
+aspect and vice versa. Such a child package should contain any
+declarations that would be useful for interfacing to the language
+(implementation) represented by the convention. Any declarations useful
+for interfacing to any language on the given hardware architecture
+should be provided directly in Interfaces.
+
+11.b/2
+ Ramification: For example, package Interfaces.XYZ_Pascal might
+ contain declarations of types that match the data types
+ provided by the XYZ implementation of Pascal, so that it will
+ be more convenient to pass parameters to a subprogram whose
+ convention is XYZ_Pascal.
+
+ _Implementation Advice_
+
+12/2
+This paragraph was deleted.{AI95-00204-01AI95-00204-01}
+
+12.a/2
+ This paragraph was deleted.
+
+13/3
+{AI05-0299-1AI05-0299-1} An implementation supporting an interface to C,
+COBOL, or Fortran should provide the corresponding package or packages
+described in the following subclauses.
+
+13.a.1/2
+ Implementation Advice: If an interface to C, COBOL, or Fortran
+ is provided, the corresponding package or packages described
+ in *note Annex B::, "*note Annex B:: Interface to Other
+ Languages" should also be provided.
+
+13.a
+ Implementation Note: The intention is that an implementation
+ might support several implementations of the foreign language:
+ Interfaces.This_Fortran and Interfaces.That_Fortran might both
+ exist. The "default" implementation, overridable by the user,
+ should be declared as a renaming:
+
+13.b
+ package Interfaces.Fortran renames Interfaces.This_Fortran;
+
+ _Wording Changes from Ada 95_
+
+13.c/2
+ {AI95-00204-01AI95-00204-01} Clarified that interfacing to
+ foreign languages is optional and has the same restrictions as
+ a Specialized Needs Annex.
+
+ _Wording Changes from Ada 2005_
+
+13.d/3
+ {AI05-0262-1AI05-0262-1} Move the restrictions on
+ implementations of optional features to the start of this
+ Annex.
+
+\1f
+File: aarm2012.info, Node: B.3, Next: B.4, Prev: B.2, Up: Annex B
+
+B.3 Interfacing with C and C++
+==============================
+
+1/3
+{8652/00598652/0059} {AI95-00131-01AI95-00131-01}
+{AI95-00376-01AI95-00376-01} {AI05-0229-1AI05-0229-1} The facilities
+relevant to interfacing with the C language and the corresponding subset
+of the C++ language are the package Interfaces.C and its children, and
+support for specifying the Convention aspect with convention_identifiers
+C and C_Pass_By_Copy.
+
+2/3
+{AI95-00376-01AI95-00376-01} {AI95-0262-1AI95-0262-1}
+{AI95-0299-1AI95-0299-1} The package Interfaces.C contains the basic
+types, constants, and subprograms that allow an Ada program to pass
+scalars and strings to C and C++ functions. When this subclause
+mentions a C entity, the reference also applies to the corresponding
+entity in C++.
+
+ _Static Semantics_
+
+3
+The library package Interfaces.C has the following declaration:
+
+4
+ package Interfaces.C is
+ pragma Pure(C);
+
+5
+ -- Declarations based on C's <limits.h>
+
+6
+ CHAR_BIT : constant := implementation-defined; -- typically 8
+ SCHAR_MIN : constant := implementation-defined; -- typically -128
+ SCHAR_MAX : constant := implementation-defined; -- typically 127
+ UCHAR_MAX : constant := implementation-defined; -- typically 255
+
+7
+ -- Signed and Unsigned Integers
+ type int is range implementation-defined;
+ type short is range implementation-defined;
+ type long is range implementation-defined;
+
+8
+ type signed_char is range SCHAR_MIN .. SCHAR_MAX;
+ for signed_char'Size use CHAR_BIT;
+
+9
+ type unsigned is mod implementation-defined;
+ type unsigned_short is mod implementation-defined;
+ type unsigned_long is mod implementation-defined;
+
+10
+ type unsigned_char is mod (UCHAR_MAX+1);
+ for unsigned_char'Size use CHAR_BIT;
+
+11
+ subtype plain_char is implementation-defined;
+
+12
+ type ptrdiff_t is range implementation-defined;
+
+13
+ type size_t is mod implementation-defined;
+
+14
+ -- Floating Point
+
+15
+ type C_float is digits implementation-defined;
+
+16
+ type double is digits implementation-defined;
+
+17
+ type long_double is digits implementation-defined;
+
+18
+ -- Characters and Strings
+
+19
+ type char is <implementation-defined character type>;
+
+20/1
+ {8652/00608652/0060} {AI95-00037-01AI95-00037-01} nul : constant char := implementation-defined;
+
+21
+ function To_C (Item : in Character) return char;
+
+22
+ function To_Ada (Item : in char) return Character;
+
+23/3
+ {AI05-0229-1AI05-0229-1} {AI05-0269-1AI05-0269-1} type char_array is array (size_t range <>) of aliased char
+ with Pack;
+ for char_array'Component_Size use CHAR_BIT;
+
+24
+ function Is_Nul_Terminated (Item : in char_array) return Boolean;
+
+25
+ function To_C (Item : in String;
+ Append_Nul : in Boolean := True)
+ return char_array;
+
+26
+ function To_Ada (Item : in char_array;
+ Trim_Nul : in Boolean := True)
+ return String;
+
+27
+ procedure To_C (Item : in String;
+ Target : out char_array;
+ Count : out size_t;
+ Append_Nul : in Boolean := True);
+
+28
+ procedure To_Ada (Item : in char_array;
+ Target : out String;
+ Count : out Natural;
+ Trim_Nul : in Boolean := True);
+
+29
+ -- Wide Character and Wide String
+
+30/1
+ {8652/00608652/0060} {AI95-00037-01AI95-00037-01} type wchar_t is <implementation-defined character type>;
+
+31/1
+ {8652/00608652/0060} {AI95-00037-01AI95-00037-01} wide_nul : constant wchar_t := implementation-defined;
+
+32
+ function To_C (Item : in Wide_Character) return wchar_t;
+ function To_Ada (Item : in wchar_t ) return Wide_Character;
+
+33/3
+ {AI05-0229-1AI05-0229-1} type wchar_array is array (size_t range <>) of aliased wchar_t
+ with Pack;
+
+34/3
+ This paragraph was deleted.{AI05-0229-1AI05-0229-1}
+
+35
+ function Is_Nul_Terminated (Item : in wchar_array) return Boolean;
+
+36
+ function To_C (Item : in Wide_String;
+ Append_Nul : in Boolean := True)
+ return wchar_array;
+
+37
+ function To_Ada (Item : in wchar_array;
+ Trim_Nul : in Boolean := True)
+ return Wide_String;
+
+38
+ procedure To_C (Item : in Wide_String;
+ Target : out wchar_array;
+ Count : out size_t;
+ Append_Nul : in Boolean := True);
+
+39
+ procedure To_Ada (Item : in wchar_array;
+ Target : out Wide_String;
+ Count : out Natural;
+ Trim_Nul : in Boolean := True);
+
+39.1/2
+ {AI95-00285-01AI95-00285-01} -- ISO/IEC 10646:2003 compatible types defined by ISO/IEC TR 19769:2004.
+
+39.2/2
+ {AI95-00285-01AI95-00285-01} type char16_t is <implementation-defined character type>;
+
+39.3/2
+ char16_nul : constant char16_t := implementation-defined;
+
+39.4/2
+ function To_C (Item : in Wide_Character) return char16_t;
+ function To_Ada (Item : in char16_t) return Wide_Character;
+
+39.5/3
+ {AI05-0229-1AI05-0229-1} type char16_array is array (size_t range <>) of aliased char16_t
+ with Pack;
+
+39.6/3
+ This paragraph was deleted.{AI05-0229-1AI05-0229-1}
+
+39.7/2
+ function Is_Nul_Terminated (Item : in char16_array) return Boolean;
+ function To_C (Item : in Wide_String;
+ Append_Nul : in Boolean := True)
+ return char16_array;
+
+39.8/2
+ function To_Ada (Item : in char16_array;
+ Trim_Nul : in Boolean := True)
+ return Wide_String;
+
+39.9/2
+ procedure To_C (Item : in Wide_String;
+ Target : out char16_array;
+ Count : out size_t;
+ Append_Nul : in Boolean := True);
+
+39.10/2
+ procedure To_Ada (Item : in char16_array;
+ Target : out Wide_String;
+ Count : out Natural;
+ Trim_Nul : in Boolean := True);
+
+39.11/2
+ {AI95-00285-01AI95-00285-01} type char32_t is <implementation-defined character type>;
+
+39.12/2
+ char32_nul : constant char32_t := implementation-defined;
+
+39.13/2
+ function To_C (Item : in Wide_Wide_Character) return char32_t;
+ function To_Ada (Item : in char32_t) return Wide_Wide_Character;
+
+39.14/3
+ {AI05-0229-1AI05-0229-1} type char32_array is array (size_t range <>) of aliased char32_t
+ with Pack;
+
+39.15/3
+ This paragraph was deleted.{AI05-0229-1AI05-0229-1}
+
+39.16/2
+ function Is_Nul_Terminated (Item : in char32_array) return Boolean;
+ function To_C (Item : in Wide_Wide_String;
+ Append_Nul : in Boolean := True)
+ return char32_array;
+
+39.17/2
+ function To_Ada (Item : in char32_array;
+ Trim_Nul : in Boolean := True)
+ return Wide_Wide_String;
+
+39.18/2
+ procedure To_C (Item : in Wide_Wide_String;
+ Target : out char32_array;
+ Count : out size_t;
+ Append_Nul : in Boolean := True);
+
+39.19/2
+ procedure To_Ada (Item : in char32_array;
+ Target : out Wide_Wide_String;
+ Count : out Natural;
+ Trim_Nul : in Boolean := True);
+
+40
+ Terminator_Error : exception;
+
+41
+ end Interfaces.C;
+
+41.a.1/2
+ Implementation defined: The definitions of certain types and
+ constants in Interfaces.C.
+
+42
+Each of the types declared in Interfaces.C is C-compatible.
+
+43/2
+{AI95-00285-01AI95-00285-01} The types int, short, long, unsigned,
+ptrdiff_t, size_t, double, char, wchar_t, char16_t, and char32_t
+correspond respectively to the C types having the same names. The types
+signed_char, unsigned_short, unsigned_long, unsigned_char, C_float, and
+long_double correspond respectively to the C types signed char, unsigned
+short, unsigned long, unsigned char, float, and long double.
+
+43.a/2
+ Discussion: The C types wchar_t and char16_t seem to be the
+ same. However, wchar_t has an implementation-defined size,
+ whereas char16_t is guaranteed to be an unsigned type of at
+ least 16 bits. Also, char16_t and char32_t are encouraged to
+ have UTF-16 and UTF-32 representations; that means that they
+ are not directly the same as the Ada types, which most likely
+ don't use any UTF encoding.
+
+44
+The type of the subtype plain_char is either signed_char or
+unsigned_char, depending on the C implementation.
+
+45
+ function To_C (Item : in Character) return char;
+ function To_Ada (Item : in char ) return Character;
+
+46
+ The functions To_C and To_Ada map between the Ada type
+ Character and the C type char.
+
+46.a.1/1
+ Implementation Note: {8652/01148652/0114}
+ {AI95-00038-01AI95-00038-01} The To_C and To_Ada functions map
+ between corresponding characters, not necessarily between
+ characters with the same internal representation.
+ Corresponding characters are characters defined by the same
+ enumeration literal, if such exist; otherwise, the
+ correspondence is unspecified.
+
+46.a.2/1
+ The following definition is equivalent to the above summary:
+
+46.a.3/1
+ To_C (Latin_1_Char) =
+ char'Value(Character'Image(Latin_1_Char))
+ provided that char'Value does not raise an exception;
+ otherwise the result is unspecified.
+
+46.a.4/1
+ To_Ada (Native_C_Char) =
+ Character'Value(char'Image(Native_C_Char))
+ provided that Character'Value does not raise an exception;
+ otherwise the result is unspecified.
+
+47
+ function Is_Nul_Terminated (Item : in char_array) return Boolean;
+
+48
+ The result of Is_Nul_Terminated is True if Item contains nul,
+ and is False otherwise.
+
+49
+ function To_C (Item : in String; Append_Nul : in Boolean := True)
+ return char_array;
+
+ function To_Ada (Item : in char_array; Trim_Nul : in Boolean := True)
+ return String;
+
+50/2
+ {AI95-00258-01AI95-00258-01} The result of To_C is a
+ char_array value of length Item'Length (if Append_Nul is
+ False) or Item'Length+1 (if Append_Nul is True). The lower
+ bound is 0. For each component Item(I), the corresponding
+ component in the result is To_C applied to Item(I). The value
+ nul is appended if Append_Nul is True. If Append_Nul is False
+ and Item'Length is 0, then To_C propagates Constraint_Error.
+
+51
+ The result of To_Ada is a String whose length is Item'Length
+ (if Trim_Nul is False) or the length of the slice of Item
+ preceding the first nul (if Trim_Nul is True). The lower
+ bound of the result is 1. If Trim_Nul is False, then for each
+ component Item(I) the corresponding component in the result is
+ To_Ada applied to Item(I). If Trim_Nul is True, then for each
+ component Item(I) before the first nul the corresponding
+ component in the result is To_Ada applied to Item(I). The
+ function propagates Terminator_Error if Trim_Nul is True and
+ Item does not contain nul.
+
+52
+ procedure To_C (Item : in String;
+ Target : out char_array;
+ Count : out size_t;
+ Append_Nul : in Boolean := True);
+
+ procedure To_Ada (Item : in char_array;
+ Target : out String;
+ Count : out Natural;
+ Trim_Nul : in Boolean := True);
+
+53
+ For procedure To_C, each element of Item is converted (via the
+ To_C function) to a char, which is assigned to the
+ corresponding element of Target. If Append_Nul is True, nul
+ is then assigned to the next element of Target. In either
+ case, Count is set to the number of Target elements assigned.
+ If Target is not long enough, Constraint_Error is propagated.
+
+54
+ For procedure To_Ada, each element of Item (if Trim_Nul is
+ False) or each element of Item preceding the first nul (if
+ Trim_Nul is True) is converted (via the To_Ada function) to a
+ Character, which is assigned to the corresponding element of
+ Target. Count is set to the number of Target elements
+ assigned. If Target is not long enough, Constraint_Error is
+ propagated. If Trim_Nul is True and Item does not contain
+ nul, then Terminator_Error is propagated.
+
+55
+ function Is_Nul_Terminated (Item : in wchar_array) return Boolean;
+
+56
+ The result of Is_Nul_Terminated is True if Item contains
+ wide_nul, and is False otherwise.
+
+57
+ function To_C (Item : in Wide_Character) return wchar_t;
+ function To_Ada (Item : in wchar_t ) return Wide_Character;
+
+58
+ To_C and To_Ada provide the mappings between the Ada and C
+ wide character types.
+
+59
+ function To_C (Item : in Wide_String;
+ Append_Nul : in Boolean := True)
+ return wchar_array;
+
+ function To_Ada (Item : in wchar_array;
+ Trim_Nul : in Boolean := True)
+ return Wide_String;
+
+ procedure To_C (Item : in Wide_String;
+ Target : out wchar_array;
+ Count : out size_t;
+ Append_Nul : in Boolean := True);
+
+ procedure To_Ada (Item : in wchar_array;
+ Target : out Wide_String;
+ Count : out Natural;
+ Trim_Nul : in Boolean := True);
+
+60
+ The To_C and To_Ada subprograms that convert between
+ Wide_String and wchar_array have analogous effects to the To_C
+ and To_Ada subprograms that convert between String and
+ char_array, except that wide_nul is used instead of nul.
+
+60.1/2
+ function Is_Nul_Terminated (Item : in char16_array) return Boolean;
+
+60.2/2
+ {AI95-00285-01AI95-00285-01} The result of Is_Nul_Terminated
+ is True if Item contains char16_nul, and is False otherwise.
+
+60.3/2
+ function To_C (Item : in Wide_Character) return char16_t;
+ function To_Ada (Item : in char16_t ) return Wide_Character;
+
+60.4/2
+ {AI95-00285-01AI95-00285-01} To_C and To_Ada provide mappings
+ between the Ada and C 16-bit character types.
+
+60.5/2
+ function To_C (Item : in Wide_String;
+ Append_Nul : in Boolean := True)
+ return char16_array;
+
+ function To_Ada (Item : in char16_array;
+ Trim_Nul : in Boolean := True)
+ return Wide_String;
+
+ procedure To_C (Item : in Wide_String;
+ Target : out char16_array;
+ Count : out size_t;
+ Append_Nul : in Boolean := True);
+
+ procedure To_Ada (Item : in char16_array;
+ Target : out Wide_String;
+ Count : out Natural;
+ Trim_Nul : in Boolean := True);
+
+60.6/2
+ {AI95-00285-01AI95-00285-01} The To_C and To_Ada subprograms
+ that convert between Wide_String and char16_array have
+ analogous effects to the To_C and To_Ada subprograms that
+ convert between String and char_array, except that char16_nul
+ is used instead of nul.
+
+60.7/2
+ function Is_Nul_Terminated (Item : in char32_array) return Boolean;
+
+60.8/2
+ {AI95-00285-01AI95-00285-01} The result of Is_Nul_Terminated
+ is True if Item contains char16_nul, and is False otherwise.
+
+60.9/2
+ function To_C (Item : in Wide_Wide_Character) return char32_t;
+ function To_Ada (Item : in char32_t ) return Wide_Wide_Character;
+
+60.10/2
+ {AI95-00285-01AI95-00285-01} To_C and To_Ada provide mappings
+ between the Ada and C 32-bit character types.
+
+60.11/2
+ function To_C (Item : in Wide_Wide_String;
+ Append_Nul : in Boolean := True)
+ return char32_array;
+
+ function To_Ada (Item : in char32_array;
+ Trim_Nul : in Boolean := True)
+ return Wide_Wide_String;
+
+ procedure To_C (Item : in Wide_Wide_String;
+ Target : out char32_array;
+ Count : out size_t;
+ Append_Nul : in Boolean := True);
+
+ procedure To_Ada (Item : in char32_array;
+ Target : out Wide_Wide_String;
+ Count : out Natural;
+ Trim_Nul : in Boolean := True);
+
+60.12/2
+ {AI95-00285-01AI95-00285-01} The To_C and To_Ada subprograms
+ that convert between Wide_Wide_String and char32_array have
+ analogous effects to the To_C and To_Ada subprograms that
+ convert between String and char_array, except that char32_nul
+ is used instead of nul.
+
+60.a
+ Discussion: The Interfaces.C package provides an
+ implementation-defined character type, char, designed to model
+ the C run-time character set, and mappings between the types
+ char and Character.
+
+60.b
+ One application of the C interface package is to compose a C
+ string and pass it to a C function. One way to do this is for
+ the programmer to declare an object that will hold the C
+ array, and then pass this array to the C function. This is
+ realized via the type char_array:
+
+60.c
+ type char_array is array (size_t range <>) of Char;
+
+60.d
+ The programmer can declare an Ada String, convert it to a
+ char_array, and pass the char_array as actual parameter to the
+ C function that is expecting a char *.
+
+60.e
+ An alternative approach is for the programmer to obtain a C
+ char pointer from an Ada String (or from a char_array) by
+ invoking an allocation function. The package
+ Interfaces.C.Strings (see below) supplies the needed
+ facilities, including a private type chars_ptr that
+ corresponds to C's char *, and two allocation functions. To
+ avoid storage leakage, a Free procedure releases the storage
+ that was allocated by one of these allocate functions.
+
+60.f
+ It is typical for a C function that deals with strings to
+ adopt the convention that the string is delimited by a nul
+ char. The C interface packages support this convention. A
+ constant nul of type Char is declared, and the function
+ Value(Chars_Ptr) in Interfaces.C.Strings returns a char_array
+ up to and including the first nul in the array that the
+ chars_ptr points to. The Allocate_Chars function allocates an
+ array that is nul terminated.
+
+60.g
+ Some C functions that deal with strings take an explicit
+ length as a parameter, thus allowing strings to be passed that
+ contain nul as a data element. Other C functions take an
+ explicit length that is an upper bound: the prefix of the
+ string up to the char before nul, or the prefix of the given
+ length, is used by the function, whichever is shorter. The C
+ Interface packages support calling such functions.
+
+60.13/3
+{8652/00598652/0059} {AI95-00131-01AI95-00131-01}
+{AI05-0229-1AI05-0229-1} The Convention aspect with
+convention_identifier C_Pass_By_Copy shall only be specified for a type.
+
+60.14/2
+{8652/00598652/0059} {AI95-00131-01AI95-00131-01}
+{AI95-00216-01AI95-00216-01} The eligibility rules in *note B.1:: do not
+apply to convention C_Pass_By_Copy. Instead, a type T is eligible for
+convention C_Pass_By_Copy if T is an unchecked union type or if T is a
+record type that has no discriminants and that only has components with
+statically constrained subtypes, and each component is C-compatible.
+
+60.15/3
+{8652/00598652/0059} {AI95-00131-01AI95-00131-01}
+{AI05-0264-1AI05-0264-1} If a type is C_Pass_By_Copy-compatible, then it
+is also C-compatible.
+
+ _Implementation Requirements_
+
+61/3
+{8652/00598652/0059} {AI95-00131-01AI95-00131-01}
+{AI05-0229-1AI05-0229-1} An implementation shall support specifying
+aspect Convention with a C convention_identifier for a C-eligible type
+(see *note B.1::). An implementation shall support specifying aspect
+Convention with a C_Pass_By_Copy convention_identifier for a
+C_Pass_By_Copy-eligible type.
+
+ _Implementation Permissions_
+
+62
+An implementation may provide additional declarations in the C interface
+packages.
+
+62.1/3
+{AI05-0002-1AI05-0002-1} {AI05-0229-1AI05-0229-1} An implementation need
+not support specifying the Convention aspect with convention_identifier
+C in the following cases:
+
+62.2/3
+ * {AI05-0248-1AI05-0248-1} for a subprogram that has a parameter of
+ an unconstrained array subtype, unless the Import aspect has the
+ value True for the subprogram;
+
+62.3/3
+ * for a function with an unconstrained array result subtype;
+
+62.4/3
+ * for an object whose nominal subtype is an unconstrained array
+ subtype.
+
+62.a/3
+ Implementation Note: {AI05-0002-1AI05-0002-1} These rules
+ ensure that an implementation never needs to create bounds for
+ an unconstrained array that originates in C (and thus does not
+ have bounds). An implementation can do so if it wishes, of
+ course. Note that these permissions do not extend to passing
+ an unconstrained array as a parameter to a C function; in this
+ case, the bounds can simply be dropped and thus support is
+ required.
+
+ _Implementation Advice_
+
+62.5/3
+{8652/00608652/0060} {AI95-00037-01AI95-00037-01}
+{AI95-00285-01AI95-00285-01} The constants nul, wide_nul, char16_nul,
+and char32_nul should have a representation of zero.
+
+62.b/2
+ Implementation Advice: The constants nul, wide_nul,
+ char16_nul, and char32_nul in package Interfaces.C should have
+ a representation of zero.
+
+63
+An implementation should support the following interface correspondences
+between Ada and C.
+
+64
+ * An Ada procedure corresponds to a void-returning C function.
+
+64.a
+ Discussion: The programmer can also choose an Ada procedure
+ when the C function returns an int that is to be discarded.
+
+65
+ * An Ada function corresponds to a non-void C function.
+
+66
+ * An Ada in scalar parameter is passed as a scalar argument to a C
+ function.
+
+67
+ * An Ada in parameter of an access-to-object type with designated
+ type T is passed as a t* argument to a C function, where t is the C
+ type corresponding to the Ada type T.
+
+68
+ * An Ada access T parameter, or an Ada out or in out parameter of an
+ elementary type T, is passed as a t* argument to a C function,
+ where t is the C type corresponding to the Ada type T. In the case
+ of an elementary out or in out parameter, a pointer to a temporary
+ copy is used to preserve by-copy semantics.
+
+68.1/2
+ * {8652/00598652/0059} {AI95-00131-01AI95-00131-01}
+ {AI95-00343-01AI95-00343-01} An Ada parameter of a (record) type T
+ of convention C_Pass_By_Copy, of mode in, is passed as a t argument
+ to a C function, where t is the C struct corresponding to the Ada
+ type T.
+
+69/2
+ * {8652/00598652/0059} {AI95-00131-01AI95-00131-01}
+ {AI95-00343-01AI95-00343-01} An Ada parameter of a record type T,
+ of any mode, other than an in parameter of a type of convention
+ C_Pass_By_Copy, is passed as a t* argument to a C function, where t
+ is the C struct corresponding to the Ada type T.
+
+70
+ * An Ada parameter of an array type with component type T, of any
+ mode, is passed as a t* argument to a C function, where t is the C
+ type corresponding to the Ada type T.
+
+71
+ * An Ada parameter of an access-to-subprogram type is passed as a
+ pointer to a C function whose prototype corresponds to the
+ designated subprogram's specification.
+
+71.1/3
+ * {AI05-0002-1AI05-0002-1} An Ada parameter of a private type is
+ passed as specified for the full view of the type.
+
+71.2/3
+ * {AI05-0002-1AI05-0002-1} The rules of correspondence given above
+ for parameters of mode in also apply to the return object of a
+ function.
+
+71.3/3
+This paragraph was deleted.{AI95-00337-01AI95-00337-01}
+{AI05-0002-1AI05-0002-1}
+
+71.a/2
+ Implementation Advice: If C interfacing is supported, the
+ interface correspondences between Ada and C should be
+ supported.
+
+ NOTES
+
+72
+ 6 Values of type char_array are not implicitly terminated with
+ nul. If a char_array is to be passed as a parameter to an imported
+ C function requiring nul termination, it is the programmer's
+ responsibility to obtain this effect.
+
+73
+ 7 To obtain the effect of C's sizeof(item_type), where Item_Type
+ is the corresponding Ada type, evaluate the expression:
+ size_t(Item_Type'Size/CHAR_BIT).
+
+74/2
+ This paragraph was deleted.{AI95-00216-01AI95-00216-01}
+
+75
+ 8 A C function that takes a variable number of arguments can
+ correspond to several Ada subprograms, taking various specific
+ numbers and types of parameters.
+
+ _Examples_
+
+76
+Example of using the Interfaces.C package:
+
+77
+ --Calling the C Library Function strcpy
+ with Interfaces.C;
+ procedure Test is
+ package C renames Interfaces.C;
+ use type C.char_array;
+ -- Call <string.h>strcpy:
+ -- C definition of strcpy: char *strcpy(char *s1, const char *s2);
+ -- This function copies the string pointed to by s2 (including the terminating null character)
+ -- into the array pointed to by s1. If copying takes place between objects that overlap,
+ -- the behavior is undefined. The strcpy function returns the value of s1.
+
+78/3
+ {AI05-0229-1AI05-0229-1} -- Note: since the C function's return value is of no interest, the Ada interface is a procedure
+ procedure Strcpy (Target : out C.char_array;
+ Source : in C.char_array)
+ with Import => True, Convention => C, External_Name => "strcpy";
+
+79/3
+ This paragraph was deleted.{AI05-0229-1AI05-0229-1}
+
+80
+ Chars1 : C.char_array(1..20);
+ Chars2 : C.char_array(1..20);
+
+81
+ begin
+ Chars2(1..6) := "qwert" & C.nul;
+
+82
+ Strcpy(Chars1, Chars2);
+
+83
+ -- Now Chars1(1..6) = "qwert" & C.Nul
+
+84
+ end Test;
+
+ _Incompatibilities With Ada 95_
+
+84.a/3
+ {AI95-00285-01AI95-00285-01} {AI05-0005-1AI05-0005-1} Types
+ char16_t and char32_t and their related types and operations
+ are added to Interfaces.C. If Interfaces.C is referenced in a
+ use_clause, and an entity E with the same defining_identifier
+ as a new entity in Interfaces.C is defined in a package that
+ is also referenced in a use_clause, the entity E may no longer
+ be use-visible, resulting in errors. This should be rare and
+ is easily fixed if it does occur.
+
+ _Extensions to Ada 95_
+
+84.b/2
+ {8652/00598652/0059} {AI95-00131-01AI95-00131-01} Corrigendum:
+ Convention C_Pass_By_Copy is new.
+
+ _Wording Changes from Ada 95_
+
+84.c/2
+ {8652/00608652/0060} {AI95-00037-01AI95-00037-01} Corrigendum:
+ Clarified the intent for Nul and Wide_Nul.
+
+84.d/2
+ {AI95-00216-01AI95-00216-01} Specified that an unchecked union
+ type (see *note B.3.3::) is eligible for convention
+ C_Pass_By_Copy.
+
+84.e/2
+ {AI95-00258-01AI95-00258-01} Specified what happens if the
+ To_C function tries to return a null string.
+
+84.f/2
+ {AI95-00337-01AI95-00337-01} Clarified that the interface
+ correspondences also apply to private types whose full types
+ have the specified characteristics.
+
+84.g/2
+ {AI95-00343-01AI95-00343-01} Clarified that a type must have
+ convention C_Pass_By_Copy in order to be passed by copy (not
+ just a type that could have that convention).
+
+84.h/2
+ {AI95-00376-01AI95-00376-01} Added wording to make it clear
+ that these facilities can also be used with C++.
+
+ _Incompatibilities With Ada 2005_
+
+84.i/3
+ {AI05-0002-1AI05-0002-1} Correction: Added a definition of
+ correspondences for function results. Also added wording to
+ make it clear that we do not expect the implementation to
+ conjure bounds for unconstrained arrays out of thin air.
+ These changes allow (but don't require) compilers to reject
+ unreasonable uses of array types. Such uses probably didn't
+ work anyway (and probably were rejected, no matter what the
+ language definition said), so little existing code should be
+ impacted.
+
+* Menu:
+
+* B.3.1 :: The Package Interfaces.C.Strings
+* B.3.2 :: The Generic Package Interfaces.C.Pointers
+* B.3.3 :: Unchecked Union Types
+
+\1f
+File: aarm2012.info, Node: B.3.1, Next: B.3.2, Up: B.3
+
+B.3.1 The Package Interfaces.C.Strings
+--------------------------------------
+
+1/3
+{AI05-0229-1AI05-0229-1} The package Interfaces.C.Strings declares types
+and subprograms allowing an Ada program to allocate, reference, update,
+and free C-style strings. In particular, the private type chars_ptr
+corresponds to a common use of "char *" in C programs, and an object of
+this type can be passed to a subprogram to which with Import => True,
+Convention => C has been specified, and for which "char *" is the type
+of the argument of the C function.
+
+ _Static Semantics_
+
+2
+The library package Interfaces.C.Strings has the following declaration:
+
+3
+ package Interfaces.C.Strings is
+ pragma Preelaborate(Strings);
+
+4
+ type char_array_access is access all char_array;
+
+5/2
+ {AI95-00161-01AI95-00161-01} type chars_ptr is private;
+ pragma Preelaborable_Initialization(chars_ptr);
+
+6/2
+ {AI95-00276-01AI95-00276-01} type chars_ptr_array is array (size_t range <>) of aliased chars_ptr;
+
+7
+ Null_Ptr : constant chars_ptr;
+
+8
+ function To_Chars_Ptr (Item : in char_array_access;
+ Nul_Check : in Boolean := False)
+ return chars_ptr;
+
+9
+ function New_Char_Array (Chars : in char_array) return chars_ptr;
+
+10
+ function New_String (Str : in String) return chars_ptr;
+
+11
+ procedure Free (Item : in out chars_ptr);
+
+12
+ Dereference_Error : exception;
+
+13
+ function Value (Item : in chars_ptr) return char_array;
+
+14
+ function Value (Item : in chars_ptr; Length : in size_t)
+ return char_array;
+
+15
+ function Value (Item : in chars_ptr) return String;
+
+16
+ function Value (Item : in chars_ptr; Length : in size_t)
+ return String;
+
+17
+ function Strlen (Item : in chars_ptr) return size_t;
+
+18
+ procedure Update (Item : in chars_ptr;
+ Offset : in size_t;
+ Chars : in char_array;
+ Check : in Boolean := True);
+
+19
+ procedure Update (Item : in chars_ptr;
+ Offset : in size_t;
+ Str : in String;
+ Check : in Boolean := True);
+
+20
+ Update_Error : exception;
+
+21
+ private
+ ... -- not specified by the language
+ end Interfaces.C.Strings;
+
+21.a
+ Discussion: The string manipulation types and subprograms
+ appear in a child of Interfaces.C versus being there directly,
+ since it is useful to have Interfaces.C specified as pragma
+ Pure.
+
+21.b
+ Differently named functions New_String and New_Char_Array are
+ declared, since if there were a single overloaded function a
+ call with a string literal as actual parameter would be
+ ambiguous.
+
+22
+The type chars_ptr is C-compatible and corresponds to the use of C's
+"char *" for a pointer to the first char in a char array terminated by
+nul. When an object of type chars_ptr is declared, its value is by
+default set to Null_Ptr, unless the object is imported (see *note
+B.1::).
+
+22.a
+ Discussion: The type char_array_access is not necessarily
+ C-compatible, since an object of this type may carry "dope"
+ information. The programmer should convert from
+ char_array_access to chars_ptr for objects imported from,
+ exported to, or passed to C.
+
+23
+ function To_Chars_Ptr (Item : in char_array_access;
+ Nul_Check : in Boolean := False)
+ return chars_ptr;
+
+24/3
+ {8652/00618652/0061} {AI95-00140-01AI95-00140-01}
+ {AI05-0264-1AI05-0264-1} If Item is null, then To_Chars_Ptr
+ returns Null_Ptr. If Item is not null, Nul_Check is True, and
+ Item.all does not contain nul, then the function propagates
+ Terminator_Error; otherwise, To_Chars_Ptr performs a pointer
+ conversion with no allocation of memory.
+
+25
+ function New_Char_Array (Chars : in char_array) return chars_ptr;
+
+26
+ This function returns a pointer to an allocated object
+ initialized to Chars(Chars'First .. Index) & nul, where
+
+27
+ * Index = Chars'Last if Chars does not contain nul, or
+
+28
+ * Index is the smallest size_t value I such that Chars(I+1)
+ = nul.
+
+28.1
+ Storage_Error is propagated if the allocation fails.
+
+29
+ function New_String (Str : in String) return chars_ptr;
+
+30
+ This function is equivalent to New_Char_Array(To_C(Str)).
+
+31
+ procedure Free (Item : in out chars_ptr);
+
+32
+ If Item is Null_Ptr, then Free has no effect. Otherwise, Free
+ releases the storage occupied by Value(Item), and resets Item
+ to Null_Ptr.
+
+33
+ function Value (Item : in chars_ptr) return char_array;
+
+34/3
+ {AI05-0264-1AI05-0264-1} If Item = Null_Ptr, then Value
+ propagates Dereference_Error. Otherwise, Value returns the
+ prefix of the array of chars pointed to by Item, up to and
+ including the first nul. The lower bound of the result is 0.
+ If Item does not point to a nul-terminated string, then
+ execution of Value is erroneous.
+
+35
+ function Value (Item : in chars_ptr; Length : in size_t)
+ return char_array;
+
+36/3
+ {8652/00628652/0062} {AI95-00139-01AI95-00139-01}
+ {AI05-0264-1AI05-0264-1} If Item = Null_Ptr, then Value
+ propagates Dereference_Error. Otherwise, Value returns the
+ shorter of two arrays, either the first Length chars pointed
+ to by Item, or Value(Item). The lower bound of the result is
+ 0. If Length is 0, then Value propagates Constraint_Error.
+
+36.a
+ Ramification: Value(New_Char_Array(Chars)) = Chars if Chars
+ does not contain nul; else Value(New_Char_Array( Chars)) is
+ the prefix of Chars up to and including the first nul.
+
+37
+ function Value (Item : in chars_ptr) return String;
+
+38
+ Equivalent to To_Ada(Value(Item), Trim_Nul=>True).
+
+39
+ function Value (Item : in chars_ptr; Length : in size_t)
+ return String;
+
+40/1
+ {8652/00638652/0063} {AI95-00177-01AI95-00177-01} Equivalent
+ to To_Ada(Value(Item, Length) & nul, Trim_Nul=>True).
+
+41
+ function Strlen (Item : in chars_ptr) return size_t;
+
+42
+ Returns Val'Length-1 where Val = Value(Item); propagates
+ Dereference_Error if Item = Null_Ptr.
+
+42.a
+ Ramification: Strlen returns the number of chars in the array
+ pointed to by Item, up to and including the char immediately
+ before the first nul.
+
+42.b
+ Strlen has the same possibility for erroneous execution as
+ Value, in cases where the string has not been nul-terminated.
+
+42.c
+ Strlen has the effect of C's strlen function.
+
+43
+ procedure Update (Item : in chars_ptr;
+ Offset : in size_t;
+ Chars : in char_array;
+ Check : Boolean := True);
+
+44/1
+ {8652/00648652/0064} {AI95-00039-01AI95-00039-01} If Item =
+ Null_Ptr, then Update propagates Dereference_Error.
+ Otherwise, this procedure updates the value pointed to by
+ Item, starting at position Offset, using Chars as the data to
+ be copied into the array. Overwriting the nul terminator, and
+ skipping with the Offset past the nul terminator, are both
+ prevented if Check is True, as follows:
+
+45
+ * Let N = Strlen(Item). If Check is True, then:
+
+46
+ * If Offset+Chars'Length>N, propagate
+ Update_Error.
+
+47
+ * Otherwise, overwrite the data in the array
+ pointed to by Item, starting at the char at
+ position Offset, with the data in Chars.
+
+48
+ * If Check is False, then processing is as above, but with
+ no check that Offset+Chars'Length>N.
+
+48.a
+ Ramification: If Chars contains nul, Update's effect may be to
+ "shorten" the pointed-to char array.
+
+49
+ procedure Update (Item : in chars_ptr;
+ Offset : in size_t;
+ Str : in String;
+ Check : in Boolean := True);
+
+50/2
+ {AI95-00242-01AI95-00242-01} Equivalent to Update(Item,
+ Offset, To_C(Str, Append_Nul => False), Check).
+
+50.a/2
+ Discussion: {AI95-00242-01AI95-00242-01} To truncate the Item
+ to the length of Str, use Update(Item, Offset, To_C(Str),
+ Check) instead of Update(Item, Offset, Str, Check). Note that
+ when truncating Item, Item must be longer than Str.
+
+ _Erroneous Execution_
+
+51
+Execution of any of the following is erroneous if the Item parameter is
+not null_ptr and Item does not point to a nul-terminated array of chars.
+
+52
+ * a Value function not taking a Length parameter,
+
+53
+ * the Free procedure,
+
+54
+ * the Strlen function.
+
+55
+Execution of Free(X) is also erroneous if the chars_ptr X was not
+returned by New_Char_Array or New_String.
+
+56
+Reading or updating a freed char_array is erroneous.
+
+57
+Execution of Update is erroneous if Check is False and a call with Check
+equal to True would have propagated Update_Error.
+
+ NOTES
+
+58
+ 9 New_Char_Array and New_String might be implemented either
+ through the allocation function from the C environment ("malloc")
+ or through Ada dynamic memory allocation ("new"). The key points
+ are
+
+59
+ * the returned value (a chars_ptr) is represented as a C "char
+ *" so that it may be passed to C functions;
+
+60
+ * the allocated object should be freed by the programmer via a
+ call of Free, not by a called C function.
+
+ _Inconsistencies With Ada 95_
+
+60.a/2
+ {AI95-00242-01AI95-00242-01} Amendment Correction: Update for
+ a String parameter is now defined to not add a nul character.
+ It did add a nul in Ada 95. This means that programs that
+ used this behavior of Update to truncate a string will no
+ longer work (the string will not be truncated). This change
+ makes Update for a string consistent with Update for a
+ char_array (no implicit nul is added to the end of a
+ char_array).
+
+ _Extensions to Ada 95_
+
+60.b/2
+ {AI95-00161-01AI95-00161-01} Amendment Correction: Added
+ pragma Preelaborable_Initialization to type chars_ptr, so that
+ it can be used in preelaborated units.
+
+60.c/2
+ {AI95-00276-01AI95-00276-01} Amendment Correction: The
+ components of chars_ptr_array are aliased so that it can be
+ used to instantiate Interfaces.C.Pointers (that is its
+ intended purpose, which is otherwise mysterious as it has no
+ operations).
+
+ _Wording Changes from Ada 95_
+
+60.d/2
+ {8652/00618652/0061} {AI95-00140-01AI95-00140-01} Corrigendum:
+ Fixed the missing semantics of To_Char_Ptr when Nul_Check is
+ False.
+
+60.e/2
+ {8652/00628652/0062} {AI95-00139-01AI95-00139-01} Corrigendum:
+ Fixed the missing semantics of Value when the Length is 0.
+
+60.f/2
+ {8652/00638652/0063} {AI95-00177-01AI95-00177-01} Corrigendum:
+ Corrected the definition of Value to avoid raising
+ Terminator_Error.
+
+60.g/2
+ {8652/00648652/0064} {AI95-00039-01AI95-00039-01} Corrigendum:
+ Fixed the missing semantics of Update when Item is Null_Ptr.
+
+\1f
+File: aarm2012.info, Node: B.3.2, Next: B.3.3, Prev: B.3.1, Up: B.3
+
+B.3.2 The Generic Package Interfaces.C.Pointers
+-----------------------------------------------
+
+1
+The generic package Interfaces.C.Pointers allows the Ada programmer to
+perform C-style operations on pointers. It includes an access type
+Pointer, Value functions that dereference a Pointer and deliver the
+designated array, several pointer arithmetic operations, and "copy"
+procedures that copy the contents of a source pointer into the array
+designated by a destination pointer. As in C, it treats an object Ptr
+of type Pointer as a pointer to the first element of an array, so that
+for example, adding 1 to Ptr yields a pointer to the second element of
+the array.
+
+2
+The generic allows two styles of usage: one in which the array is
+terminated by a special terminator element; and another in which the
+programmer needs to keep track of the length.
+
+ _Static Semantics_
+
+3
+The generic library package Interfaces.C.Pointers has the following
+declaration:
+
+4
+ generic
+ type Index is (<>);
+ type Element is private;
+ type Element_Array is array (Index range <>) of aliased Element;
+ Default_Terminator : Element;
+ package Interfaces.C.Pointers is
+ pragma Preelaborate(Pointers);
+
+5
+ type Pointer is access all Element;
+
+6
+ function Value(Ref : in Pointer;
+ Terminator : in Element := Default_Terminator)
+ return Element_Array;
+
+7
+ function Value(Ref : in Pointer;
+ Length : in ptrdiff_t)
+ return Element_Array;
+
+8
+ Pointer_Error : exception;
+
+9
+ -- C-style Pointer arithmetic
+
+10/3
+ {AI05-0229-1AI05-0229-1} function "+" (Left : in Pointer; Right : in ptrdiff_t) return Pointer
+ with Convention => Intrinsic;
+ function "+" (Left : in ptrdiff_t; Right : in Pointer) return Pointer
+ with Convention => Intrinsic;
+ function "-" (Left : in Pointer; Right : in ptrdiff_t) return Pointer
+ with Convention => Intrinsic;
+ function "-" (Left : in Pointer; Right : in Pointer) return ptrdiff_t
+ with Convention => Intrinsic;
+
+11/3
+ {AI05-0229-1AI05-0229-1} procedure Increment (Ref : in out Pointer)
+ with Convention => Intrinsic;
+ procedure Decrement (Ref : in out Pointer)
+ with Convention => Intrinsic;
+
+12/3
+ This paragraph was deleted.{AI05-0229-1AI05-0229-1}
+
+13
+ function Virtual_Length (Ref : in Pointer;
+ Terminator : in Element := Default_Terminator)
+ return ptrdiff_t;
+
+14
+ procedure Copy_Terminated_Array
+ (Source : in Pointer;
+ Target : in Pointer;
+ Limit : in ptrdiff_t := ptrdiff_t'Last;
+ Terminator : in Element := Default_Terminator);
+
+15
+ procedure Copy_Array (Source : in Pointer;
+ Target : in Pointer;
+ Length : in ptrdiff_t);
+
+16
+ end Interfaces.C.Pointers;
+
+17
+The type Pointer is C-compatible and corresponds to one use of C's
+"Element *". An object of type Pointer is interpreted as a pointer to
+the initial Element in an Element_Array. Two styles are supported:
+
+18
+ * Explicit termination of an array value with Default_Terminator (a
+ special terminator value);
+
+19
+ * Programmer-managed length, with Default_Terminator treated simply
+ as a data element.
+
+20
+ function Value(Ref : in Pointer;
+ Terminator : in Element := Default_Terminator)
+ return Element_Array;
+
+21
+ This function returns an Element_Array whose value is the
+ array pointed to by Ref, up to and including the first
+ Terminator; the lower bound of the array is Index'First.
+ Interfaces.C.Strings.Dereference_Error is propagated if Ref is
+ null.
+
+22
+ function Value(Ref : in Pointer;
+ Length : in ptrdiff_t)
+ return Element_Array;
+
+23
+ This function returns an Element_Array comprising the first
+ Length elements pointed to by Ref. The exception
+ Interfaces.C.Strings.Dereference_Error is propagated if Ref is
+ null.
+
+24
+The "+" and "-" functions perform arithmetic on Pointer values, based on
+the Size of the array elements. In each of these functions,
+Pointer_Error is propagated if a Pointer parameter is null.
+
+25
+ procedure Increment (Ref : in out Pointer);
+
+26
+ Equivalent to Ref := Ref+1.
+
+27
+ procedure Decrement (Ref : in out Pointer);
+
+28
+ Equivalent to Ref := Ref-1.
+
+29
+ function Virtual_Length (Ref : in Pointer;
+ Terminator : in Element := Default_Terminator)
+ return ptrdiff_t;
+
+30
+ Returns the number of Elements, up to the one just before the
+ first Terminator, in Value(Ref, Terminator).
+
+31
+ procedure Copy_Terminated_Array
+ (Source : in Pointer;
+ Target : in Pointer;
+ Limit : in ptrdiff_t := ptrdiff_t'Last;
+ Terminator : in Element := Default_Terminator);
+
+32
+ This procedure copies Value(Source, Terminator) into the array
+ pointed to by Target; it stops either after Terminator has
+ been copied, or the number of elements copied is Limit,
+ whichever occurs first. Dereference_Error is propagated if
+ either Source or Target is null.
+
+32.a
+ Ramification: It is the programmer's responsibility to ensure
+ that elements are not copied beyond the logical length of the
+ target array.
+
+32.b
+ Implementation Note: The implementation has to take care to
+ check the Limit first.
+
+33
+ procedure Copy_Array (Source : in Pointer;
+ Target : in Pointer;
+ Length : in ptrdiff_t);
+
+34
+ This procedure copies the first Length elements from the array
+ pointed to by Source, into the array pointed to by Target.
+ Dereference_Error is propagated if either Source or Target is
+ null.
+
+ _Erroneous Execution_
+
+35
+It is erroneous to dereference a Pointer that does not designate an
+aliased Element.
+
+35.a
+ Discussion: Such a Pointer could arise via "+", "-",
+ Increment, or Decrement.
+
+36
+Execution of Value(Ref, Terminator) is erroneous if Ref does not
+designate an aliased Element in an Element_Array terminated by
+Terminator.
+
+37
+Execution of Value(Ref, Length) is erroneous if Ref does not designate
+an aliased Element in an Element_Array containing at least Length
+Elements between the designated Element and the end of the array,
+inclusive.
+
+38
+Execution of Virtual_Length(Ref, Terminator) is erroneous if Ref does
+not designate an aliased Element in an Element_Array terminated by
+Terminator.
+
+39
+Execution of Copy_Terminated_Array(Source, Target, Limit, Terminator) is
+erroneous in either of the following situations:
+
+40
+ * Execution of both Value(Source, Terminator) and Value(Source,
+ Limit) are erroneous, or
+
+41
+ * Copying writes past the end of the array containing the Element
+ designated by Target.
+
+42
+Execution of Copy_Array(Source, Target, Length) is erroneous if either
+Value(Source, Length) is erroneous, or copying writes past the end of
+the array containing the Element designated by Target.
+
+ NOTES
+
+43
+ 10 To compose a Pointer from an Element_Array, use 'Access on the
+ first element. For example (assuming appropriate instantiations):
+
+44
+ Some_Array : Element_Array(0..5) ;
+ Some_Pointer : Pointer := Some_Array(0)'Access;
+
+ _Examples_
+
+45
+Example of Interfaces.C.Pointers:
+
+46
+ with Interfaces.C.Pointers;
+ with Interfaces.C.Strings;
+ procedure Test_Pointers is
+ package C renames Interfaces.C;
+ package Char_Ptrs is
+ new C.Pointers (Index => C.size_t,
+ Element => C.char,
+ Element_Array => C.char_array,
+ Default_Terminator => C.nul);
+
+47
+ use type Char_Ptrs.Pointer;
+ subtype Char_Star is Char_Ptrs.Pointer;
+
+48
+ procedure Strcpy (Target_Ptr, Source_Ptr : Char_Star) is
+ Target_Temp_Ptr : Char_Star := Target_Ptr;
+ Source_Temp_Ptr : Char_Star := Source_Ptr;
+ Element : C.char;
+ begin
+ if Target_Temp_Ptr = null or Source_Temp_Ptr = null then
+ raise C.Strings.Dereference_Error;
+ end if;
+
+49/1
+ {8652/00658652/0065} {AI95-00142-01AI95-00142-01} loop
+ Element := Source_Temp_Ptr.all;
+ Target_Temp_Ptr.all := Element;
+ exit when C."="(Element, C.nul);
+ Char_Ptrs.Increment(Target_Temp_Ptr);
+ Char_Ptrs.Increment(Source_Temp_Ptr);
+ end loop;
+ end Strcpy;
+ begin
+ ...
+ end Test_Pointers;
+
+\1f
+File: aarm2012.info, Node: B.3.3, Prev: B.3.2, Up: B.3
+
+B.3.3 Unchecked Union Types
+---------------------------
+
+1/3
+{AI95-00216-01AI95-00216-01} {AI05-0229-1AI05-0229-1}
+{AI05-0269-1AI05-0269-1} [Specifying aspect Unchecked_Union to have the
+value True defines an interface correspondence between a given
+discriminated type and some C union. The aspect requires that the
+associated type shall be given a representation that allocates no space
+for its discriminant(s).]
+
+Paragraphs 2 through 3 were moved to *note Annex J::, "*note Annex J::
+Obsolescent Features".
+
+ _Static Semantics_
+
+3.1/3
+{AI05-0229-1AI05-0229-1} For a discriminated record type having a
+variant_part, the following language-defined representation aspect may
+be specified:
+
+3.2/3
+Unchecked_Union
+ The type of aspect Unchecked_Union is Boolean. If
+ directly specified, the aspect_definition shall be a
+ static expression. If not specified (including by
+ inheritance), the aspect is False.
+
+3.a/3
+ Aspect Description for Unchecked_Union: Type is used to
+ interface to a C union type.
+
+ _Legality Rules_
+
+Paragraphs 4 and 5 were deleted.
+
+6/3
+{AI95-00216-01AI95-00216-01} {AI05-0229-1AI05-0229-1} A type for which
+aspect Unchecked_Union is True is called an unchecked union type. A
+subtype of an unchecked union type is defined to be an unchecked union
+subtype. An object of an unchecked union type is defined to be an
+unchecked union object.
+
+7/2
+{AI95-00216-01AI95-00216-01} All component subtypes of an unchecked
+union type shall be C-compatible.
+
+8/2
+{AI95-00216-01AI95-00216-01} If a component subtype of an unchecked
+union type is subject to a per-object constraint, then the component
+subtype shall be an unchecked union subtype.
+
+9/3
+{AI95-00216-01AI95-00216-01} {AI05-0026-1AI05-0026-1} Any name that
+denotes a discriminant of an object of an unchecked union type shall
+occur within the declarative region of the type, and shall not occur
+within a record_representation_clause.
+
+10/3
+{AI95-00216-01AI95-00216-01} {AI05-0026-1AI05-0026-1} The type of a
+component declared in a variant_part of an unchecked union type shall
+not need finalization. In addition to the places where Legality Rules
+normally apply (see *note 12.3::), this rule also applies in the private
+part of an instance of a generic unit. For an unchecked union type
+declared within the body of a generic unit, or within the body of any of
+its descendant library units, no part of the type of a component
+declared in a variant_part of the unchecked union type shall be of a
+formal private type or formal private extension declared within the
+formal part of the generic unit.
+
+10.a/3
+ Reason: {AI05-0026-1AI05-0026-1} The last part is a classic
+ assume-the-worst rule that avoids dependence on the actuals in
+ a generic body. We did not include this in the definition of
+ "needs finalization" as it has a bad interaction with the use
+ of that term for the No_Nested_Finalization restriction.
+
+11/2
+{AI95-00216-01AI95-00216-01} The completion of an incomplete or private
+type declaration having a known_discriminant_part shall not be an
+unchecked union type.
+
+12/2
+{AI95-00216-01AI95-00216-01} An unchecked union subtype shall only be
+passed as a generic actual parameter if the corresponding formal type
+has no known discriminants or is an unchecked union type.
+
+12.a/2
+ Ramification: This includes formal private types without a
+ known_discriminant_part, formal derived types that do not
+ inherit any discriminants (formal derived types do not have
+ known_discriminant_parts), and formal derived types that are
+ unchecked union types.
+
+ _Static Semantics_
+
+13/2
+{AI95-00216-01AI95-00216-01} An unchecked union type is eligible for
+convention C.
+
+14/2
+{AI95-00216-01AI95-00216-01} All objects of an unchecked union type have
+the same size.
+
+15/2
+{AI95-00216-01AI95-00216-01} Discriminants of objects of an unchecked
+union type are of size zero.
+
+16/2
+{AI95-00216-01AI95-00216-01} Any check which would require reading a
+discriminant of an unchecked union object is suppressed (see *note
+11.5::). These checks include:
+
+17/2
+ * The check performed when addressing a variant component (i.e., a
+ component that was declared in a variant part) of an unchecked
+ union object that the object has this component (see *note
+ 4.1.3::).
+
+18/2
+ * Any checks associated with a type or subtype conversion of a value
+ of an unchecked union type (see *note 4.6::). This includes, for
+ example, the check associated with the implicit subtype conversion
+ of an assignment statement.
+
+19/2
+ * The subtype membership check associated with the evaluation of a
+ qualified expression (see *note 4.7::) or an uninitialized
+ allocator (see *note 4.8::).
+
+19.a/2
+ Discussion: If a suppressed check would have failed, execution
+ is erroneous (see *note 11.5::). An implementation is always
+ allowed to make a suppressed check if it can somehow determine
+ the discriminant value.
+
+ _Dynamic Semantics_
+
+20/2
+{AI95-00216-01AI95-00216-01} A view of an unchecked union object
+(including a type conversion or function call) has inferable
+discriminants if it has a constrained nominal subtype, unless the object
+is a component of an enclosing unchecked union object that is subject to
+a per-object constraint and the enclosing object lacks inferable
+discriminants.
+
+21/2
+{AI95-00216-01AI95-00216-01} An expression of an unchecked union type
+has inferable discriminants if it is either a name of an object with
+inferable discriminants or a qualified expression whose subtype_mark
+denotes a constrained subtype.
+
+22/2
+{AI95-00216-01AI95-00216-01} Program_Error is raised in the following
+cases:
+
+23/2
+ * Evaluation of the predefined equality operator for an unchecked
+ union type if either of the operands lacks inferable discriminants.
+
+24/2
+ * Evaluation of the predefined equality operator for a type which has
+ a subcomponent of an unchecked union type whose nominal subtype is
+ unconstrained.
+
+25/2
+ * Evaluation of a membership test if the subtype_mark denotes a
+ constrained unchecked union subtype and the expression lacks
+ inferable discriminants.
+
+26/2
+ * Conversion from a derived unchecked union type to an unconstrained
+ non-unchecked-union type if the operand of the conversion lacks
+ inferable discriminants.
+
+27/2
+ * Execution of the default implementation of the Write or Read
+ attribute of an unchecked union type.
+
+28/2
+ * Execution of the default implementation of the Output or Input
+ attribute of an unchecked union type if the type lacks default
+ discriminant values.
+
+Paragraph 29 was deleted.
+
+ NOTES
+
+30/2
+ 11 {AI95-00216-01AI95-00216-01} The use of an unchecked union to
+ obtain the effect of an unchecked conversion results in erroneous
+ execution (see *note 11.5::). Execution of the following example
+ is erroneous even if Float'Size = Integer'Size:
+
+31/3
+ {AI05-0229-1AI05-0229-1} type T (Flag : Boolean := False) is
+ record
+ case Flag is
+ when False =>
+ F1 : Float := 0.0;
+ when True =>
+ F2 : Integer := 0;
+ end case;
+ end record
+ with Unchecked_Union;
+
+32/2
+ X : T;
+ Y : Integer := X.F2; -- erroneous
+
+ _Extensions to Ada 95_
+
+32.a/2
+ {AI95-00216-01AI95-00216-01} Pragma Unchecked_Union is new.
+
+ _Incompatibilities With Ada 2005_
+
+32.b/3
+ {AI05-0026-1AI05-0026-1} Correction: The use of discriminants
+ on Unchecked_Union types is now illegal in
+ record_representation_clauses, as it makes no sense to specify
+ a position for something that is not supposed to exist. It is
+ very unlikely that this change will have any impact on
+ existing code.
+
+ _Extensions to Ada 2005_
+
+32.c/3
+ {AI05-0229-1AI05-0229-1} Aspect Unchecked_Union is new; pragma
+ Unchecked_Union is now obsolescent.
+
+ _Wording Changes from Ada 2005_
+
+32.d/3
+ {AI05-0026-1AI05-0026-1} Correction: Revised the rules to use
+ the "needs finalization" definition, and eliminated generic
+ contract issues.
+
+\1f
+File: aarm2012.info, Node: B.4, Next: B.5, Prev: B.3, Up: Annex B
+
+B.4 Interfacing with COBOL
+==========================
+
+1/3
+{AI05-0229-1AI05-0229-1} The facilities relevant to interfacing with the
+COBOL language are the package Interfaces.COBOL and support for
+specifying the Convention aspect with convention_identifier COBOL.
+
+2
+The COBOL interface package supplies several sets of facilities:
+
+3
+ * A set of types corresponding to the native COBOL types of the
+ supported COBOL implementation (so-called "internal COBOL
+ representations"), allowing Ada data to be passed as parameters to
+ COBOL programs
+
+4
+ * A set of types and constants reflecting external data
+ representations such as might be found in files or databases,
+ allowing COBOL-generated data to be read by an Ada program, and
+ Ada-generated data to be read by COBOL programs
+
+5
+ * A generic package for converting between an Ada decimal type value
+ and either an internal or external COBOL representation
+
+ _Static Semantics_
+
+6
+The library package Interfaces.COBOL has the following declaration:
+
+7
+ package Interfaces.COBOL is
+ pragma Preelaborate(COBOL);
+
+8
+ -- Types and operations for internal data representations
+
+9
+ type Floating is digits implementation-defined;
+ type Long_Floating is digits implementation-defined;
+
+10
+ type Binary is range implementation-defined;
+ type Long_Binary is range implementation-defined;
+
+11
+ Max_Digits_Binary : constant := implementation-defined;
+ Max_Digits_Long_Binary : constant := implementation-defined;
+
+12/3
+ {AI05-0229-1AI05-0229-1} type Decimal_Element is mod implementation-defined;
+ type Packed_Decimal is array (Positive range <>) of Decimal_Element
+ with Pack;
+
+13
+ type COBOL_Character is implementation-defined character type;
+
+14
+ Ada_To_COBOL : array (Character) of COBOL_Character := implementation-defined;
+
+15
+ COBOL_To_Ada : array (COBOL_Character) of Character := implementation-defined;
+
+16/3
+ {AI05-0229-1AI05-0229-1} type Alphanumeric is array (Positive range <>) of COBOL_Character
+ with Pack;
+
+17
+ function To_COBOL (Item : in String) return Alphanumeric;
+ function To_Ada (Item : in Alphanumeric) return String;
+
+18
+ procedure To_COBOL (Item : in String;
+ Target : out Alphanumeric;
+ Last : out Natural);
+
+19
+ procedure To_Ada (Item : in Alphanumeric;
+ Target : out String;
+ Last : out Natural);
+
+20/3
+ {AI05-0229-1AI05-0229-1} type Numeric is array (Positive range <>) of COBOL_Character
+ with Pack;
+
+21
+ -- Formats for COBOL data representations
+
+22
+ type Display_Format is private;
+
+23
+ Unsigned : constant Display_Format;
+ Leading_Separate : constant Display_Format;
+ Trailing_Separate : constant Display_Format;
+ Leading_Nonseparate : constant Display_Format;
+ Trailing_Nonseparate : constant Display_Format;
+
+24
+ type Binary_Format is private;
+
+25
+ High_Order_First : constant Binary_Format;
+ Low_Order_First : constant Binary_Format;
+ Native_Binary : constant Binary_Format;
+
+26
+ type Packed_Format is private;
+
+27
+ Packed_Unsigned : constant Packed_Format;
+ Packed_Signed : constant Packed_Format;
+
+28
+ -- Types for external representation of COBOL binary data
+
+29/3
+ {AI05-0229-1AI05-0229-1} type Byte is mod 2**COBOL_Character'Size;
+ type Byte_Array is array (Positive range <>) of Byte
+ with Pack;
+
+30
+ Conversion_Error : exception;
+
+31
+ generic
+ type Num is delta <> digits <>;
+ package Decimal_Conversions is
+
+32
+ -- Display Formats: data values are represented as Numeric
+
+33
+ function Valid (Item : in Numeric;
+ Format : in Display_Format) return Boolean;
+
+34
+ function Length (Format : in Display_Format) return Natural;
+
+35
+ function To_Decimal (Item : in Numeric;
+ Format : in Display_Format) return Num;
+
+36
+ function To_Display (Item : in Num;
+ Format : in Display_Format) return Numeric;
+
+37
+ -- Packed Formats: data values are represented as Packed_Decimal
+
+38
+ function Valid (Item : in Packed_Decimal;
+ Format : in Packed_Format) return Boolean;
+
+39
+ function Length (Format : in Packed_Format) return Natural;
+
+40
+ function To_Decimal (Item : in Packed_Decimal;
+ Format : in Packed_Format) return Num;
+
+41
+ function To_Packed (Item : in Num;
+ Format : in Packed_Format) return Packed_Decimal;
+
+42
+ -- Binary Formats: external data values are represented as Byte_Array
+
+43
+ function Valid (Item : in Byte_Array;
+ Format : in Binary_Format) return Boolean;
+
+44
+ function Length (Format : in Binary_Format) return Natural;
+ function To_Decimal (Item : in Byte_Array;
+ Format : in Binary_Format) return Num;
+
+45
+ function To_Binary (Item : in Num;
+ Format : in Binary_Format) return Byte_Array;
+
+46
+ -- Internal Binary formats: data values are of type Binary or Long_Binary
+
+47
+ function To_Decimal (Item : in Binary) return Num;
+ function To_Decimal (Item : in Long_Binary) return Num;
+
+48
+ function To_Binary (Item : in Num) return Binary;
+ function To_Long_Binary (Item : in Num) return Long_Binary;
+
+49
+ end Decimal_Conversions;
+
+50
+ private
+ ... -- not specified by the language
+ end Interfaces.COBOL;
+
+50.a/1
+ Implementation defined: The types Floating, Long_Floating,
+ Binary, Long_Binary, Decimal_Element, and COBOL_Character; and
+ the initializations of the variables Ada_To_COBOL and
+ COBOL_To_Ada, in Interfaces.COBOL.
+
+51
+Each of the types in Interfaces.COBOL is COBOL-compatible.
+
+52
+The types Floating and Long_Floating correspond to the native types in
+COBOL for data items with computational usage implemented by floating
+point. The types Binary and Long_Binary correspond to the native types
+in COBOL for data items with binary usage, or with computational usage
+implemented by binary.
+
+53
+Max_Digits_Binary is the largest number of decimal digits in a numeric
+value that is represented as Binary. Max_Digits_Long_Binary is the
+largest number of decimal digits in a numeric value that is represented
+as Long_Binary.
+
+54
+The type Packed_Decimal corresponds to COBOL's packed-decimal usage.
+
+55
+The type COBOL_Character defines the run-time character set used in the
+COBOL implementation. Ada_To_COBOL and COBOL_To_Ada are the mappings
+between the Ada and COBOL run-time character sets.
+
+55.a
+ Reason: The character mappings are visible variables, since
+ the user needs the ability to modify them at run time.
+
+56
+Type Alphanumeric corresponds to COBOL's alphanumeric data category.
+
+57
+Each of the functions To_COBOL and To_Ada converts its parameter based
+on the mappings Ada_To_COBOL and COBOL_To_Ada, respectively. The length
+of the result for each is the length of the parameter, and the lower
+bound of the result is 1. Each component of the result is obtained by
+applying the relevant mapping to the corresponding component of the
+parameter.
+
+58
+Each of the procedures To_COBOL and To_Ada copies converted elements
+from Item to Target, using the appropriate mapping (Ada_To_COBOL or
+COBOL_To_Ada, respectively). The index in Target of the last element
+assigned is returned in Last (0 if Item is a null array). If
+Item'Length exceeds Target'Length, Constraint_Error is propagated.
+
+59
+Type Numeric corresponds to COBOL's numeric data category with display
+usage.
+
+60
+The types Display_Format, Binary_Format, and Packed_Format are used in
+conversions between Ada decimal type values and COBOL internal or
+external data representations. The value of the constant Native_Binary
+is either High_Order_First or Low_Order_First, depending on the
+implementation.
+
+61
+ function Valid (Item : in Numeric;
+ Format : in Display_Format) return Boolean;
+
+62
+ The function Valid checks that the Item parameter has a value
+ consistent with the value of Format. If the value of Format
+ is other than Unsigned, Leading_Separate, and
+ Trailing_Separate, the effect is implementation defined. If
+ Format does have one of these values, the following rules
+ apply:
+
+63/3
+ * {8652/00668652/0066} {AI95-00071-01AI95-00071-01}
+ {AI05-0264-1AI05-0264-1} Format=Unsigned: if Item
+ comprises one or more decimal digit characters, then
+ Valid returns True, else it returns False.
+
+64/1
+ * {8652/00668652/0066} {AI95-00071-01AI95-00071-01}
+ Format=Leading_Separate: if Item comprises a single
+ occurrence of the plus or minus sign character, and then
+ one or more decimal digit characters, then Valid returns
+ True, else it returns False.
+
+65/1
+ * {8652/00668652/0066} {AI95-00071-01AI95-00071-01}
+ Format=Trailing_Separate: if Item comprises one or more
+ decimal digit characters and finally a plus or minus sign
+ character, then Valid returns True, else it returns
+ False.
+
+66
+ function Length (Format : in Display_Format) return Natural;
+
+67
+ The Length function returns the minimal length of a Numeric
+ value sufficient to hold any value of type Num when
+ represented as Format.
+
+68
+ function To_Decimal (Item : in Numeric;
+ Format : in Display_Format) return Num;
+
+69
+ Produces a value of type Num corresponding to Item as
+ represented by Format. The number of digits after the assumed
+ radix point in Item is Num'Scale. Conversion_Error is
+ propagated if the value represented by Item is outside the
+ range of Num.
+
+69.a
+ Discussion: There is no issue of truncation versus rounding,
+ since the number of decimal places is established by
+ Num'Scale.
+
+70
+ function To_Display (Item : in Num;
+ Format : in Display_Format) return Numeric;
+
+71/1
+ {8652/00678652/0067} {AI95-00072-01AI95-00072-01} This
+ function returns the Numeric value for Item, represented in
+ accordance with Format. The length of the returned value is
+ Length(Format), and the lower bound is 1. Conversion_Error is
+ propagated if Num is negative and Format is Unsigned.
+
+72
+ function Valid (Item : in Packed_Decimal;
+ Format : in Packed_Format) return Boolean;
+
+73
+ This function returns True if Item has a value consistent with
+ Format, and False otherwise. The rules for the formation of
+ Packed_Decimal values are implementation defined.
+
+74
+ function Length (Format : in Packed_Format) return Natural;
+
+75
+ This function returns the minimal length of a Packed_Decimal
+ value sufficient to hold any value of type Num when
+ represented as Format.
+
+76
+ function To_Decimal (Item : in Packed_Decimal;
+ Format : in Packed_Format) return Num;
+
+77
+ Produces a value of type Num corresponding to Item as
+ represented by Format. Num'Scale is the number of digits
+ after the assumed radix point in Item. Conversion_Error is
+ propagated if the value represented by Item is outside the
+ range of Num.
+
+78
+ function To_Packed (Item : in Num;
+ Format : in Packed_Format) return Packed_Decimal;
+
+79/1
+ {8652/00678652/0067} {AI95-00072-01AI95-00072-01} This
+ function returns the Packed_Decimal value for Item,
+ represented in accordance with Format. The length of the
+ returned value is Length(Format), and the lower bound is 1.
+ Conversion_Error is propagated if Num is negative and Format
+ is Packed_Unsigned.
+
+80
+ function Valid (Item : in Byte_Array;
+ Format : in Binary_Format) return Boolean;
+
+81
+ This function returns True if Item has a value consistent with
+ Format, and False otherwise.
+
+81.a
+ Ramification: This function returns False only when the
+ represented value is outside the range of Num.
+
+82
+ function Length (Format : in Binary_Format) return Natural;
+
+83
+ This function returns the minimal length of a Byte_Array value
+ sufficient to hold any value of type Num when represented as
+ Format.
+
+84
+ function To_Decimal (Item : in Byte_Array;
+ Format : in Binary_Format) return Num;
+
+85
+ Produces a value of type Num corresponding to Item as
+ represented by Format. Num'Scale is the number of digits
+ after the assumed radix point in Item. Conversion_Error is
+ propagated if the value represented by Item is outside the
+ range of Num.
+
+86
+ function To_Binary (Item : in Num;
+ Format : in Binary_Format) return Byte_Array;
+
+87/1
+ {8652/00678652/0067} {AI95-00072-01AI95-00072-01} This
+ function returns the Byte_Array value for Item, represented in
+ accordance with Format. The length of the returned value is
+ Length(Format), and the lower bound is 1.
+
+88
+ function To_Decimal (Item : in Binary) return Num;
+
+ function To_Decimal (Item : in Long_Binary) return Num;
+
+89
+ These functions convert from COBOL binary format to a
+ corresponding value of the decimal type Num. Conversion_Error
+ is propagated if Item is too large for Num.
+
+89.a
+ Ramification: There is no rescaling performed on the
+ conversion. That is, the returned value in each case is a
+ "bit copy" if Num has a binary radix. The programmer is
+ responsible for maintaining the correct scale.
+
+90
+ function To_Binary (Item : in Num) return Binary;
+
+ function To_Long_Binary (Item : in Num) return Long_Binary;
+
+91
+ These functions convert from Ada decimal to COBOL binary
+ format. Conversion_Error is propagated if the value of Item
+ is too large to be represented in the result type.
+
+91.a
+ Discussion: One style of interface supported for COBOL,
+ similar to what is provided for C, is the ability to call and
+ pass parameters to an existing COBOL program. Thus the
+ interface package supplies types that can be used in an Ada
+ program as parameters to subprograms whose bodies will be in
+ COBOL. These types map to COBOL's alphanumeric and numeric
+ data categories.
+
+91.b
+ Several types are provided for support of alphanumeric data.
+ Since COBOL's run-time character set is not necessarily the
+ same as Ada's, Interfaces.COBOL declares an
+ implementation-defined character type COBOL_Character, and
+ mappings between Character and COBOL_Character. These
+ mappings are visible variables (rather than, say, functions or
+ constant arrays), since in the situation where COBOL_Character
+ is EBCDIC, the flexibility of dynamically modifying the
+ mappings is needed. Corresponding to COBOL's alphanumeric
+ data is the string type Alphanumeric.
+
+91.c
+ Numeric data may have either a "display" or "computational"
+ representation in COBOL. On the Ada side, the data is of a
+ decimal fixed point type. Passing an Ada decimal data item to
+ a COBOL program requires conversion from the Ada decimal type
+ to some type that reflects the representation expected on the
+ COBOL side.
+
+91.d
+ * Computational Representation
+
+91.e
+ Floating point representation is modeled by Ada floating
+ point types, Floating and Long_Floating. Conversion
+ between these types and Ada decimal types is obtained
+ directly, since the type name serves as a conversion
+ function.
+
+91.f
+ Binary representation is modeled by an Ada integer type,
+ Binary, and possibly other types such as Long_Binary.
+ Conversion between, say, Binary and a decimal type is
+ through functions from an instantiation of the generic
+ package Decimal_Conversions.
+
+91.g
+ Packed decimal representation is modeled by the Ada array
+ type Packed_Decimal. Conversion between packed decimal
+ and a decimal type is through functions from an
+ instantiation of the generic package Decimal_Conversions.
+
+91.h
+ * Display Representation
+
+91.i
+ Display representation for numeric data is modeled by the
+ array type Numeric. Conversion between display
+ representation and a decimal type is through functions
+ from an instantiation of the generic package
+ Decimal_Conversions. A parameter to the conversion
+ function indicates the desired interpretation of the data
+ (e.g., signed leading separate, etc.)
+
+91.j/3
+ {AI05-0229-1AI05-0229-1} The Convention of a record type may
+ be specified as COBOL to direct the compiler to choose a
+ COBOL-compatible representation for objects of the type.
+
+91.k
+ The package Interfaces.COBOL allows the Ada programmer to deal
+ with data from files (or databases) created by a COBOL
+ program. For data that is alphanumeric, or in display or
+ packed decimal format, the approach is the same as for passing
+ parameters (instantiate Decimal_Conversions to obtain the
+ needed conversion functions). For binary data, the external
+ representation is treated as a Byte array, and an
+ instantiation of Decimal_IO produces a package that declares
+ the needed conversion functions. A parameter to the
+ conversion function indicates the desired interpretation of
+ the data (e.g., high- versus low-order byte first).
+
+ _Implementation Requirements_
+
+92/3
+{AI05-0229-1AI05-0229-1} An implementation shall support specifying
+aspect Convention with a COBOL convention_identifier for a
+COBOL-eligible type (see *note B.1::).
+
+92.a
+ Ramification: An implementation supporting this package shall
+ ensure that if the bounds of a Packed_Decimal, Alphanumeric,
+ or Numeric variable are static, then the representation of the
+ object comprises solely the array components (that is, there
+ is no implicit run-time "descriptor" that is part of the
+ object).
+
+ _Implementation Permissions_
+
+93
+An implementation may provide additional constants of the private types
+Display_Format, Binary_Format, or Packed_Format.
+
+93.a
+ Reason: This is to allow exploitation of other external
+ formats that may be available in the COBOL implementation.
+
+94
+An implementation may provide further floating point and integer types
+in Interfaces.COBOL to match additional native COBOL types, and may also
+supply corresponding conversion functions in the generic package
+Decimal_Conversions.
+
+ _Implementation Advice_
+
+95
+An Ada implementation should support the following interface
+correspondences between Ada and COBOL.
+
+96
+ * An Ada access T parameter is passed as a "BY REFERENCE" data item
+ of the COBOL type corresponding to T.
+
+97
+ * An Ada in scalar parameter is passed as a "BY CONTENT" data item of
+ the corresponding COBOL type.
+
+98
+ * Any other Ada parameter is passed as a "BY REFERENCE" data item of
+ the COBOL type corresponding to the Ada parameter type; for
+ scalars, a local copy is used if necessary to ensure by-copy
+ semantics.
+
+98.a/2
+ Implementation Advice: If COBOL interfacing is supported, the
+ interface correspondences between Ada and COBOL should be
+ supported.
+
+ NOTES
+
+99/3
+ 12 {AI05-0229-1AI05-0229-1} An implementation is not required to
+ support specifying aspect Convention for access types, nor is it
+ required to support specifying aspects Import, Export, or
+ Convention for functions.
+
+99.a
+ Reason: COBOL does not have a pointer facility, and a COBOL
+ program does not return a value.
+
+100
+ 13 If an Ada subprogram is exported to COBOL, then a call from
+ COBOL call may specify either "BY CONTENT" or "BY REFERENCE".
+
+ _Examples_
+
+101
+Examples of Interfaces.COBOL:
+
+102
+ with Interfaces.COBOL;
+ procedure Test_Call is
+
+103
+ -- Calling a foreign COBOL program
+ -- Assume that a COBOL program PROG has the following declaration
+ -- in its LINKAGE section:
+ -- 01 Parameter-Area
+ -- 05 NAME PIC X(20).
+ -- 05 SSN PIC X(9).
+ -- 05 SALARY PIC 99999V99 USAGE COMP.
+ -- The effect of PROG is to update SALARY based on some algorithm
+
+104
+ package COBOL renames Interfaces.COBOL;
+
+105
+ type Salary_Type is delta 0.01 digits 7;
+
+106/3
+ {AI05-0229-1AI05-0229-1} type COBOL_Record is
+ record
+ Name : COBOL.Numeric(1..20);
+ SSN : COBOL.Numeric(1..9);
+ Salary : COBOL.Binary; -- Assume Binary = 32 bits
+ end record
+ with Convention => COBOL;
+
+107/3
+ {AI05-0229-1AI05-0229-1} procedure Prog (Item : in out COBOL_Record)
+ with Import => True, Convention => COBOL;
+
+108
+ package Salary_Conversions is
+ new COBOL.Decimal_Conversions(Salary_Type);
+
+109
+ Some_Salary : Salary_Type := 12_345.67;
+ Some_Record : COBOL_Record :=
+ (Name => "Johnson, John ",
+ SSN => "111223333",
+ Salary => Salary_Conversions.To_Binary(Some_Salary));
+
+110
+ begin
+ Prog (Some_Record);
+ ...
+ end Test_Call;
+
+111
+ with Interfaces.COBOL;
+ with COBOL_Sequential_IO; -- Assumed to be supplied by implementation
+ procedure Test_External_Formats is
+
+112
+ -- Using data created by a COBOL program
+ -- Assume that a COBOL program has created a sequential file with
+ -- the following record structure, and that we need to
+ -- process the records in an Ada program
+ -- 01 EMPLOYEE-RECORD
+ -- 05 NAME PIC X(20).
+ -- 05 SSN PIC X(9).
+ -- 05 SALARY PIC 99999V99 USAGE COMP.
+ -- 05 ADJUST PIC S999V999 SIGN LEADING SEPARATE.
+ -- The COMP data is binary (32 bits), high-order byte first
+
+113
+ package COBOL renames Interfaces.COBOL;
+
+114
+ type Salary_Type is delta 0.01 digits 7;
+ type Adjustments_Type is delta 0.001 digits 6;
+
+115/3
+ {AI05-0229-1AI05-0229-1} type COBOL_Employee_Record_Type is -- External representation
+ record
+ Name : COBOL.Alphanumeric(1..20);
+ SSN : COBOL.Alphanumeric(1..9);
+ Salary : COBOL.Byte_Array(1..4);
+ Adjust : COBOL.Numeric(1..7); -- Sign and 6 digits
+ end record
+ with Convention => COBOL;
+
+116
+ package COBOL_Employee_IO is
+ new COBOL_Sequential_IO(COBOL_Employee_Record_Type);
+ use COBOL_Employee_IO;
+
+117
+ COBOL_File : File_Type;
+
+118
+ type Ada_Employee_Record_Type is -- Internal representation
+ record
+ Name : String(1..20);
+ SSN : String(1..9);
+ Salary : Salary_Type;
+ Adjust : Adjustments_Type;
+ end record;
+
+119
+ COBOL_Record : COBOL_Employee_Record_Type;
+ Ada_Record : Ada_Employee_Record_Type;
+
+120
+ package Salary_Conversions is
+ new COBOL.Decimal_Conversions(Salary_Type);
+ use Salary_Conversions;
+
+121
+ package Adjustments_Conversions is
+ new COBOL.Decimal_Conversions(Adjustments_Type);
+ use Adjustments_Conversions;
+
+122
+ begin
+ Open (COBOL_File, Name => "Some_File");
+
+123
+ loop
+ Read (COBOL_File, COBOL_Record);
+
+124
+ Ada_Record.Name := To_Ada(COBOL_Record.Name);
+ Ada_Record.SSN := To_Ada(COBOL_Record.SSN);
+ Ada_Record.Salary :=
+ To_Decimal(COBOL_Record.Salary, COBOL.High_Order_First);
+ Ada_Record.Adjust :=
+ To_Decimal(COBOL_Record.Adjust, COBOL.Leading_Separate);
+ ... -- Process Ada_Record
+ end loop;
+ exception
+ when End_Error => ...
+ end Test_External_Formats;
+
+ _Wording Changes from Ada 95_
+
+124.a/2
+ {8652/00668652/0066} {AI95-00071-01AI95-00071-01} Corrigendum:
+ Corrected the definition of Valid to match COBOL.
+
+124.b/2
+ {8652/00678652/0067} {AI95-00072-01AI95-00072-01} Corrigendum:
+ Specified the bounds of the results of To_Display, To_Packed,
+ and To_Binary.
+
+\1f
+File: aarm2012.info, Node: B.5, Prev: B.4, Up: Annex B
+
+B.5 Interfacing with Fortran
+============================
+
+1/3
+{AI05-0229-1AI05-0229-1} The facilities relevant to interfacing with the
+Fortran language are the package Interfaces.Fortran and support for
+specifying the Convention aspect with convention_identifier Fortran.
+
+2
+The package Interfaces.Fortran defines Ada types whose representations
+are identical to the default representations of the Fortran intrinsic
+types Integer, Real, Double Precision, Complex, Logical, and Character
+in a supported Fortran implementation. These Ada types can therefore be
+used to pass objects between Ada and Fortran programs.
+
+ _Static Semantics_
+
+3
+The library package Interfaces.Fortran has the following declaration:
+
+4
+ with Ada.Numerics.Generic_Complex_Types; -- see *note G.1.1::
+ pragma Elaborate_All(Ada.Numerics.Generic_Complex_Types);
+ package Interfaces.Fortran is
+ pragma Pure(Fortran);
+
+5
+ type Fortran_Integer is range implementation-defined;
+
+6
+ type Real is digits implementation-defined;
+ type Double_Precision is digits implementation-defined;
+
+7
+ type Logical is new Boolean;
+
+8
+ package Single_Precision_Complex_Types is
+ new Ada.Numerics.Generic_Complex_Types (Real);
+
+9
+ type Complex is new Single_Precision_Complex_Types.Complex;
+
+10
+ subtype Imaginary is Single_Precision_Complex_Types.Imaginary;
+ i : Imaginary renames Single_Precision_Complex_Types.i;
+ j : Imaginary renames Single_Precision_Complex_Types.j;
+
+11
+ type Character_Set is implementation-defined character type;
+
+12/3
+ {AI05-0229-1AI05-0229-1} type Fortran_Character is array (Positive range <>) of Character_Set
+ with Pack;
+
+13
+ function To_Fortran (Item : in Character) return Character_Set;
+ function To_Ada (Item : in Character_Set) return Character;
+
+14
+ function To_Fortran (Item : in String) return Fortran_Character;
+ function To_Ada (Item : in Fortran_Character) return String;
+
+15
+ procedure To_Fortran (Item : in String;
+ Target : out Fortran_Character;
+ Last : out Natural);
+
+16
+ procedure To_Ada (Item : in Fortran_Character;
+ Target : out String;
+ Last : out Natural);
+
+17
+ end Interfaces.Fortran;
+
+17.a.1/1
+ Implementation defined: The types Fortran_Integer, Real,
+ Double_Precision, and Character_Set in Interfaces.Fortran.
+
+17.a
+ Ramification: The means by which the Complex type is provided
+ in Interfaces.Fortran creates a dependence of
+ Interfaces.Fortran on Numerics.Generic_Complex_Types (see
+ *note G.1.1::). This dependence is intentional and
+ unavoidable, if the Fortran-compatible Complex type is to be
+ useful in Ada code without duplicating facilities defined
+ elsewhere.
+
+18
+The types Fortran_Integer, Real, Double_Precision, Logical, Complex, and
+Fortran_Character are Fortran-compatible.
+
+19
+The To_Fortran and To_Ada functions map between the Ada type Character
+and the Fortran type Character_Set, and also between the Ada type String
+and the Fortran type Fortran_Character. The To_Fortran and To_Ada
+procedures have analogous effects to the string conversion subprograms
+found in Interfaces.COBOL.
+
+ _Implementation Requirements_
+
+20/3
+{AI05-0229-1AI05-0229-1} An implementation shall support specifying
+aspect Convention with a Fortran convention_identifier for a
+Fortran-eligible type (see *note B.1::).
+
+ _Implementation Permissions_
+
+21
+An implementation may add additional declarations to the Fortran
+interface packages. For example, the Fortran interface package for an
+implementation of Fortran 77 (ANSI X3.9-1978) that defines types like
+Integer*n, Real*n, Logical*n, and Complex*n may contain the declarations
+of types named Integer_Star_n, Real_Star_n, Logical_Star_n, and
+Complex_Star_n. (This convention should not apply to Character*n, for
+which the Ada analog is the constrained array subtype Fortran_Character
+(1..n).) Similarly, the Fortran interface package for an implementation
+of Fortran 90 that provides multiple kinds of intrinsic types, e.g.
+Integer (Kind=n), Real (Kind=n), Logical (Kind=n), Complex (Kind=n), and
+Character (Kind=n), may contain the declarations of types with the
+recommended names Integer_Kind_n, Real_Kind_n, Logical_Kind_n,
+Complex_Kind_n, and Character_Kind_n.
+
+21.a
+ Discussion: Implementations may add auxiliary declarations as
+ needed to assist in the declarations of additional
+ Fortran-compatible types. For example, if a double precision
+ complex type is defined, then Numerics.Generic_Complex_Types
+ may be instantiated for the double precision type. Similarly,
+ if a wide character type is defined to match a Fortran 90 wide
+ character type (accessible in Fortran 90 with the Kind
+ modifier), then an auxiliary character set may be declared to
+ serve as its component type.
+
+ _Implementation Advice_
+
+22
+An Ada implementation should support the following interface
+correspondences between Ada and Fortran:
+
+23
+ * An Ada procedure corresponds to a Fortran subroutine.
+
+24
+ * An Ada function corresponds to a Fortran function.
+
+25
+ * An Ada parameter of an elementary, array, or record type T is
+ passed as a TF argument to a Fortran procedure, where TF is the
+ Fortran type corresponding to the Ada type T, and where the INTENT
+ attribute of the corresponding dummy argument matches the Ada
+ formal parameter mode; the Fortran implementation's parameter
+ passing conventions are used. For elementary types, a local copy
+ is used if necessary to ensure by-copy semantics.
+
+26
+ * An Ada parameter of an access-to-subprogram type is passed as a
+ reference to a Fortran procedure whose interface corresponds to the
+ designated subprogram's specification.
+
+26.a/2
+ Implementation Advice: If Fortran interfacing is supported,
+ the interface correspondences between Ada and Fortran should
+ be supported.
+
+ NOTES
+
+27
+ 14 An object of a Fortran-compatible record type, declared in a
+ library package or subprogram, can correspond to a Fortran common
+ block; the type also corresponds to a Fortran "derived type".
+
+ _Examples_
+
+28
+Example of Interfaces.Fortran:
+
+29
+ with Interfaces.Fortran;
+ use Interfaces.Fortran;
+ procedure Ada_Application is
+
+30/3
+ {AI05-0229-1AI05-0229-1} type Fortran_Matrix is array (Integer range <>,
+ Integer range <>) of Double_Precision
+ with Convention => Fortran; -- stored in Fortran's
+ -- column-major order
+ procedure Invert (Rank : in Fortran_Integer; X : in out Fortran_Matrix)
+ with Import => True, Convention => Fortran; -- a Fortran subroutine
+
+31
+ Rank : constant Fortran_Integer := 100;
+ My_Matrix : Fortran_Matrix (1 .. Rank, 1 .. Rank);
+
+32
+ begin
+
+33
+ ...
+ My_Matrix := ...;
+ ...
+ Invert (Rank, My_Matrix);
+ ...
+
+34
+ end Ada_Application;
+
+\1f
+File: aarm2012.info, Node: Annex C, Next: Annex D, Prev: Annex B, Up: Top
+
+Annex C Systems Programming
+***************************
+
+1
+[ The Systems Programming Annex specifies additional capabilities
+provided for low-level programming. These capabilities are also
+required in many real-time, embedded, distributed, and information
+systems.]
+
+ _Extensions to Ada 83_
+
+1.a
+ This Annex is new to Ada 95.
+
+* Menu:
+
+* C.1 :: Access to Machine Operations
+* C.2 :: Required Representation Support
+* C.3 :: Interrupt Support
+* C.4 :: Preelaboration Requirements
+* C.5 :: Pragma Discard_Names
+* C.6 :: Shared Variable Control
+* C.7 :: Task Information
+
+\1f
+File: aarm2012.info, Node: C.1, Next: C.2, Up: Annex C
+
+C.1 Access to Machine Operations
+================================
+
+1/3
+{AI05-0299-1AI05-0299-1} [This subclause specifies rules regarding
+access to machine instructions from within an Ada program.]
+
+1.a/2
+ Implementation defined: Implementation-defined intrinsic
+ subprograms.
+
+ _Implementation Requirements_
+
+2
+The implementation shall support machine code insertions (see *note
+13.8::) or intrinsic subprograms (see *note 6.3.1::) (or both).
+Implementation-defined attributes shall be provided to allow the use of
+Ada entities as operands.
+
+ _Implementation Advice_
+
+3
+The machine code or intrinsics support should allow access to all
+operations normally available to assembly language programmers for the
+target environment, including privileged instructions, if any.
+
+3.a.1/2
+ Implementation Advice: The machine code or intrinsics support
+ should allow access to all operations normally available to
+ assembly language programmers for the target environment.
+
+3.a
+ Ramification: Of course, on a machine with protection, an
+ attempt to execute a privileged instruction in user mode will
+ probably trap. Nonetheless, we want implementations to
+ provide access to them so that Ada can be used to write
+ systems programs that run in privileged mode.
+
+4/3
+{AI05-0229-1AI05-0229-1} The support for interfacing aspects (see *note
+Annex B::) should include interface to assembler; the default assembler
+should be associated with the convention identifier Assembler.
+
+4.a/2
+ Implementation Advice: Interface to assembler should be
+ supported; the default assembler should be associated with the
+ convention identifier Assembler.
+
+5
+If an entity is exported to assembly language, then the implementation
+should allocate it at an addressable location, and should ensure that it
+is retained by the linking process, even if not otherwise referenced
+from the Ada code. The implementation should assume that any call to a
+machine code or assembler subprogram is allowed to read or update every
+object that is specified as exported.
+
+5.a/2
+ Implementation Advice: If an entity is exported to assembly
+ language, then the implementation should allocate it at an
+ addressable location even if not otherwise referenced from the
+ Ada code. A call to a machine code or assembler subprogram
+ should be treated as if it could read or update every object
+ that is specified as exported.
+
+ _Documentation Requirements_
+
+6
+The implementation shall document the overhead associated with calling
+machine-code or intrinsic subprograms, as compared to a fully-inlined
+call, and to a regular out-of-line call.
+
+6.a/2
+ Documentation Requirement: The overhead of calling
+ machine-code or intrinsic subprograms.
+
+7
+The implementation shall document the types of the package
+System.Machine_Code usable for machine code insertions, and the
+attributes to be used in machine code insertions for references to Ada
+entities.
+
+7.a/2
+ Documentation Requirement: The types and attributes used in
+ machine code insertions.
+
+8/3
+{AI05-0229-1AI05-0229-1} The implementation shall document the
+subprogram calling conventions associated with the convention
+identifiers available for use with the Convention aspect (Ada and
+Assembler, at a minimum), including register saving, exception
+propagation, parameter passing, and function value returning.
+
+8.a/2
+ Documentation Requirement: The subprogram calling conventions
+ for all supported convention identifiers.
+
+9
+For exported and imported subprograms, the implementation shall document
+the mapping between the Link_Name string, if specified, or the Ada
+designator, if not, and the external link name used for such a
+subprogram.
+
+9.a/2
+ This paragraph was deleted.
+
+9.b/2
+ Documentation Requirement: The mapping between the Link_Name
+ or Ada designator and the external link name.
+
+ _Implementation Advice_
+
+10
+The implementation should ensure that little or no overhead is
+associated with calling intrinsic and machine-code subprograms.
+
+10.a/2
+ Implementation Advice: Little or no overhead should be
+ associated with calling intrinsic and machine-code
+ subprograms.
+
+11
+It is recommended that intrinsic subprograms be provided for convenient
+access to any machine operations that provide special capabilities or
+efficiency and that are not otherwise available through the language
+constructs. Examples of such instructions include:
+
+12
+ * Atomic read-modify-write operations -- e.g., test and set, compare
+ and swap, decrement and test, enqueue/dequeue.
+
+13
+ * Standard numeric functions -- e.g., sin, log.
+
+14
+ * String manipulation operations -- e.g., translate and test.
+
+15
+ * Vector operations -- e.g., compare vector against thresholds.
+
+16
+ * Direct operations on I/O ports.
+
+16.a/2
+ Implementation Advice: Intrinsic subprograms should be
+ provided to access any machine operations that provide special
+ capabilities or efficiency not normally available.
+
+\1f
+File: aarm2012.info, Node: C.2, Next: C.3, Prev: C.1, Up: Annex C
+
+C.2 Required Representation Support
+===================================
+
+1/3
+{AI95-00434-01AI95-00434-01} {AI05-0299-1AI05-0299-1} This subclause
+specifies minimal requirements on the support for representation items
+and related features.
+
+ _Implementation Requirements_
+
+2/3
+{AI05-0299-1AI05-0299-1} The implementation shall support at least the
+functionality defined by the recommended levels of support in Clause
+*note 13::.
+
+\1f
+File: aarm2012.info, Node: C.3, Next: C.4, Prev: C.2, Up: Annex C
+
+C.3 Interrupt Support
+=====================
+
+1/3
+{AI05-0299-1AI05-0299-1} [This subclause specifies the language-defined
+model for hardware interrupts in addition to mechanisms for handling
+interrupts.]
+
+ _Dynamic Semantics_
+
+2
+[An interrupt represents a class of events that are detected by the
+hardware or the system software.] Interrupts are said to occur. An
+occurrence of an interrupt is separable into generation and delivery.
+Generation of an interrupt is the event in the underlying hardware or
+system that makes the interrupt available to the program. Delivery is
+the action that invokes part of the program as response to the interrupt
+occurrence. Between generation and delivery, the interrupt occurrence
+[(or interrupt)] is pending. Some or all interrupts may be blocked.
+When an interrupt is blocked, all occurrences of that interrupt are
+prevented from being delivered. Certain interrupts are reserved. The
+set of reserved interrupts is implementation defined. A reserved
+interrupt is either an interrupt for which user-defined handlers are not
+supported, or one which already has an attached handler by some other
+implementation-defined means. Program units can be connected to
+nonreserved interrupts. While connected, the program unit is said to be
+attached to that interrupt. The execution of that program unit, the
+interrupt handler, is invoked upon delivery of the interrupt occurrence.
+
+2.a/2
+ This paragraph was deleted.
+
+2.b
+ To be honest: As an obsolescent feature, interrupts may be
+ attached to task entries by an address clause. See *note
+ J.7.1::.
+
+3
+While a handler is attached to an interrupt, it is called once for each
+delivered occurrence of that interrupt. While the handler executes, the
+corresponding interrupt is blocked.
+
+4
+While an interrupt is blocked, all occurrences of that interrupt are
+prevented from being delivered. Whether such occurrences remain pending
+or are lost is implementation defined.
+
+5
+Each interrupt has a default treatment which determines the system's
+response to an occurrence of that interrupt when no user-defined handler
+is attached. The set of possible default treatments is implementation
+defined, as is the method (if one exists) for configuring the default
+treatments for interrupts.
+
+6
+An interrupt is delivered to the handler (or default treatment) that is
+in effect for that interrupt at the time of delivery.
+
+7
+An exception propagated from a handler that is invoked by an interrupt
+has no effect.
+
+8
+[If the Ceiling_Locking policy (see *note D.3::) is in effect, the
+interrupt handler executes with the active priority that is the ceiling
+priority of the corresponding protected object.]
+
+ _Implementation Requirements_
+
+9
+The implementation shall provide a mechanism to determine the minimum
+stack space that is needed for each interrupt handler and to reserve
+that space for the execution of the handler. [This space should
+accommodate nested invocations of the handler where the system permits
+this.]
+
+10
+If the hardware or the underlying system holds pending interrupt
+occurrences, the implementation shall provide for later delivery of
+these occurrences to the program.
+
+11
+If the Ceiling_Locking policy is not in effect, the implementation shall
+provide means for the application to specify whether interrupts are to
+be blocked during protected actions.
+
+ _Documentation Requirements_
+
+12
+The implementation shall document the following items:
+
+12.a
+ Discussion: This information may be different for different
+ forms of interrupt handlers.
+
+13
+ 1. For each interrupt, which interrupts are blocked from delivery
+ when a handler attached to that interrupt executes (either as a
+ result of an interrupt delivery or of an ordinary call on a
+ procedure of the corresponding protected object).
+
+14
+ 2. Any interrupts that cannot be blocked, and the effect of
+ attaching handlers to such interrupts, if this is permitted.
+
+15
+ 3. Which run-time stack an interrupt handler uses when it executes
+ as a result of an interrupt delivery; if this is configurable, what
+ is the mechanism to do so; how to specify how much space to reserve
+ on that stack.
+
+16
+ 4. Any implementation- or hardware-specific activity that happens
+ before a user-defined interrupt handler gets control (e.g., reading
+ device registers, acknowledging devices).
+
+17
+ 5. Any timing or other limitations imposed on the execution of
+ interrupt handlers.
+
+18
+ 6. The state (blocked/unblocked) of the nonreserved interrupts
+ when the program starts; if some interrupts are unblocked, what is
+ the mechanism a program can use to protect itself before it can
+ attach the corresponding handlers.
+
+19
+ 7. Whether the interrupted task is allowed to resume execution
+ before the interrupt handler returns.
+
+20
+ 8. The treatment of interrupt occurrences that are generated while
+ the interrupt is blocked; i.e., whether one or more occurrences are
+ held for later delivery, or all are lost.
+
+21
+ 9. Whether predefined or implementation-defined exceptions are
+ raised as a result of the occurrence of any interrupt, and the
+ mapping between the machine interrupts (or traps) and the
+ predefined exceptions.
+
+22
+ 10. On a multi-processor, the rules governing the delivery of an
+ interrupt to a particular processor.
+
+22.a/2
+ Documentation Requirement: The treatment of interrupts.
+
+ _Implementation Permissions_
+
+23/2
+{AI95-00434-01AI95-00434-01} If the underlying system or hardware does
+not allow interrupts to be blocked, then no blocking is required [as
+part of the execution of subprograms of a protected object for which one
+of its subprograms is an interrupt handler].
+
+24
+In a multi-processor with more than one interrupt subsystem, it is
+implementation defined whether (and how) interrupt sources from separate
+subsystems share the same Interrupt_Id type (see *note C.3.2::). In
+particular, the meaning of a blocked or pending interrupt may then be
+applicable to one processor only.
+
+24.a
+ Discussion: This issue is tightly related to the issue of
+ scheduling on a multi-processor. In a sense, if a particular
+ interrupt source is not available to all processors, the
+ system is not truly homogeneous.
+
+24.b
+ One way to approach this problem is to assign sub-ranges
+ within Interrupt_Id to each interrupt subsystem, such that
+ "similar" interrupt sources (e.g. a timer) in different
+ subsystems get a distinct id.
+
+25
+Implementations are allowed to impose timing or other limitations on the
+execution of interrupt handlers.
+
+25.a
+ Reason: These limitations are often necessary to ensure proper
+ behavior of the implementation.
+
+26/3
+{AI95-00434-01AI95-00434-01} {AI05-0299-1AI05-0299-1} Other forms of
+handlers are allowed to be supported, in which case the rules of this
+subclause should be adhered to.
+
+27
+The active priority of the execution of an interrupt handler is allowed
+to vary from one occurrence of the same interrupt to another.
+
+ _Implementation Advice_
+
+28/2
+{AI95-00434-01AI95-00434-01} If the Ceiling_Locking policy is not in
+effect, the implementation should provide means for the application to
+specify which interrupts are to be blocked during protected actions, if
+the underlying system allows for finer-grained control of interrupt
+blocking.
+
+28.a/2
+ Implementation Advice: If the Ceiling_Locking policy is not in
+ effect and the target system allows for finer-grained control
+ of interrupt blocking, a means for the application to specify
+ which interrupts are to be blocked during protected actions
+ should be provided.
+
+ NOTES
+
+29
+ 1 The default treatment for an interrupt can be to keep the
+ interrupt pending or to deliver it to an implementation-defined
+ handler. Examples of actions that an implementation-defined
+ handler is allowed to perform include aborting the partition,
+ ignoring (i.e., discarding occurrences of) the interrupt, or
+ queuing one or more occurrences of the interrupt for possible later
+ delivery when a user-defined handler is attached to that interrupt.
+
+30
+ 2 It is a bounded error to call Task_Identification.Current_Task
+ (see *note C.7.1::) from an interrupt handler.
+
+31
+ 3 The rule that an exception propagated from an interrupt handler
+ has no effect is modeled after the rule about exceptions propagated
+ out of task bodies.
+
+* Menu:
+
+* C.3.1 :: Protected Procedure Handlers
+* C.3.2 :: The Package Interrupts
+
+\1f
+File: aarm2012.info, Node: C.3.1, Next: C.3.2, Up: C.3
+
+C.3.1 Protected Procedure Handlers
+----------------------------------
+
+Paragraphs 1 through 6 were moved to *note Annex J::, "*note Annex J::
+Obsolescent Features".
+
+ _Static Semantics_
+
+6.1/3
+{AI05-0229-1AI05-0229-1} For a parameterless protected procedure, the
+following language-defined representation aspects may be specified:
+
+6.2/3
+Interrupt_Handler
+ The type of aspect Interrupt_Handler is Boolean. If
+ directly specified, the aspect_definition shall be a
+ static expression. [This aspect is never inherited;] if
+ not directly specified, the aspect is False.
+
+6.a/3
+ Aspect Description for Interrupt_Handler: Protected procedure
+ may be attached to interrupts.
+
+6.3/3
+Attach_Handler
+ The aspect Attach_Handler is an expression, which shall
+ be of type Interrupts.Interrupt_Id. [This aspect is
+ never inherited.]
+
+6.b/3
+ Aspect Description for Attach_Handler: Protected procedure is
+ attached to an interrupt.
+
+ _Legality Rules_
+
+7/3
+{AI95-00434-01AI95-00434-01} {AI05-0033-1AI05-0033-1}
+{AI05-0229-1AI05-0229-1} If either the Attach_Handler or
+Interrupt_Handler aspect are specified for a protected procedure, the
+corresponding protected_type_declaration (*note 9.4: S0210.) or
+single_protected_declaration (*note 9.4: S0211.) shall be a
+library-level declaration and shall not be declared within a generic
+body. In addition to the places where Legality Rules normally apply
+(see *note 12.3::), this rule also applies in the private part of an
+instance of a generic unit.
+
+7.a
+ Discussion: In the case of a protected_type_declaration, an
+ object_declaration of an object of that type need not be at
+ library level.
+
+7.b/3
+ {AI05-0033-1AI05-0033-1} {AI05-0229-1AI05-0229-1} We cannot
+ allow these aspects in protected declarations in a generic
+ body, because legality rules are not checked for instance
+ bodies, and these should not be allowed if the instance is not
+ at the library level. The protected types can be declared in
+ the private part if this is desired. Note that while the
+ 'Access to use the handler would provide the check in the case
+ of Interrupt_Handler, there is no other check for
+ Attach_Handler. Since these aspects are so similar, we want
+ the rules to be the same.
+
+8/3
+This paragraph was deleted.{AI95-00253-01AI95-00253-01}
+{AI95-00303-01AI95-00303-01} {AI05-0033-1AI05-0033-1}
+
+ _Dynamic Semantics_
+
+9/3
+{AI05-0229-1AI05-0229-1} If the Interrupt_Handler aspect of a protected
+procedure is True, then the procedure may be attached dynamically, as a
+handler, to interrupts (see *note C.3.2::). [Such procedures are
+allowed to be attached to multiple interrupts.]
+
+10/3
+{AI05-0229-1AI05-0229-1} The expression specified for the Attach_Handler
+aspect of a protected procedure P is evaluated as part of the creation
+of the protected object that contains P. The value of the expression
+identifies an interrupt. As part of the initialization of that object,
+P (the handler procedure) is attached to the identified interrupt. A
+check is made that the corresponding interrupt is not reserved.
+Program_Error is raised if the check fails, and the existing treatment
+for the interrupt is not affected.
+
+11/3
+{AI95-00434-01AI95-00434-01} {AI05-0229-1AI05-0229-1} If the
+Ceiling_Locking policy (see *note D.3::) is in effect, then upon the
+initialization of a protected object that contains a protected procedure
+for which either the Attach_Handler aspect is specified or the
+Interrupt_Handler aspect is True, a check is made that the initial
+ceiling priority of the object is in the range of
+System.Interrupt_Priority. If the check fails, Program_Error is raised.
+
+12/3
+{8652/00688652/0068} {AI95-00121-01AI95-00121-01}
+{AI05-0229-1AI05-0229-1} When a protected object is finalized, for any
+of its procedures that are attached to interrupts, the handler is
+detached. If the handler was attached by a procedure in the Interrupts
+package or if no user handler was previously attached to the interrupt,
+the default treatment is restored. If the Attach_Handler aspect was
+specified and the most recently attached handler for the same interrupt
+is the same as the one that was attached at the time the protected
+object was initialized, the previous handler is restored.
+
+12.a/3
+ Discussion: {8652/00688652/0068} {AI95-00121-01AI95-00121-01}
+ {AI95-00303-01AI95-00303-01} {AI05-0229-1AI05-0229-1} If all
+ protected objects for interrupt handlers are declared at the
+ library level, the finalization discussed above occurs only as
+ part of the finalization of all library-level packages in a
+ partition. However, objects of a protected type containing
+ procedures with an Attach_Handler aspect specified need not be
+ at the library level. Thus, an implementation needs to be
+ able to restore handlers during the execution of the program.
+ (An object with an Interrupt_Handler aspect also need not be
+ at the library level, but such a handler cannot be attached to
+ an interrupt using the Interrupts package.)
+
+13
+When a handler is attached to an interrupt, the interrupt is blocked
+[(subject to the Implementation Permission in *note C.3::)] during the
+execution of every protected action on the protected object containing
+the handler.
+
+ _Erroneous Execution_
+
+14
+If the Ceiling_Locking policy (see *note D.3::) is in effect and an
+interrupt is delivered to a handler, and the interrupt hardware priority
+is higher than the ceiling priority of the corresponding protected
+object, the execution of the program is erroneous.
+
+14.1/3
+{8652/00688652/0068} {AI95-00121-01AI95-00121-01}
+{AI05-0229-1AI05-0229-1} If the handlers for a given interrupt attached
+via aspect Attach_Handler are not attached and detached in a stack-like
+(LIFO) order, program execution is erroneous. In particular, when a
+protected object is finalized, the execution is erroneous if any of the
+procedures of the protected object are attached to interrupts via aspect
+Attach_Handler and the most recently attached handler for the same
+interrupt is not the same as the one that was attached at the time the
+protected object was initialized.
+
+14.a/3
+ Discussion: {8652/00688652/0068} {AI95-00121-01AI95-00121-01}
+ {AI05-0229-1AI05-0229-1} This simplifies implementation of the
+ Attach_Handler aspect by not requiring a check that the
+ current handler is the same as the one attached by the
+ initialization of a protected object.
+
+ _Metrics_
+
+15
+The following metric shall be documented by the implementation:
+
+16/2
+ * {AI95-00434-01AI95-00434-01} The worst-case overhead for an
+ interrupt handler that is a parameterless protected procedure, in
+ clock cycles. This is the execution time not directly attributable
+ to the handler procedure or the interrupted execution. It is
+ estimated as C - (A+B), where A is how long it takes to complete a
+ given sequence of instructions without any interrupt, B is how long
+ it takes to complete a normal call to a given protected procedure,
+ and C is how long it takes to complete the same sequence of
+ instructions when it is interrupted by one execution of the same
+ procedure called via an interrupt.
+
+16.a
+ Implementation Note: The instruction sequence and interrupt
+ handler used to measure interrupt handling overhead should be
+ chosen so as to maximize the execution time cost due to cache
+ misses. For example, if the processor has cache memory and
+ the activity of an interrupt handler could invalidate the
+ contents of cache memory, the handler should be written such
+ that it invalidates all of the cache memory.
+
+16.b/2
+ Documentation Requirement: The metrics for interrupt handlers.
+
+ _Implementation Permissions_
+
+17/3
+{AI05-0229-1AI05-0229-1} When the aspects Attach_Handler or
+Interrupt_Handler are specified for a protected procedure, the
+implementation is allowed to impose implementation-defined restrictions
+on the corresponding protected_type_declaration (*note 9.4: S0210.) and
+protected_body (*note 9.4: S0215.).
+
+17.a
+ Ramification: The restrictions may be on the constructs that
+ are allowed within them, and on ordinary calls (i.e. not via
+ interrupts) on protected operations in these protected
+ objects.
+
+17.b/3
+ Implementation defined: Any restrictions on a protected
+ procedure or its containing type when an aspect Attach_handler
+ or Interrupt_Handler is specified.
+
+18
+An implementation may use a different mechanism for invoking a protected
+procedure in response to a hardware interrupt than is used for a call to
+that protected procedure from a task.
+
+18.a
+ Discussion: This is despite the fact that the priority of an
+ interrupt handler (see *note D.1::) is modeled after a
+ hardware task calling the handler.
+
+19/3
+{AI05-0229-1AI05-0229-1} Notwithstanding what this subclause says
+elsewhere, the Attach_Handler and Interrupt_Handler aspects are allowed
+to be used for other, implementation defined, forms of interrupt
+handlers.
+
+19.a/3
+ Ramification: {AI05-0229-1AI05-0229-1} For example, if an
+ implementation wishes to allow interrupt handlers to have
+ parameters, it is allowed to do so via these aspects; it need
+ not invent implementation-defined aspects for the purpose.
+
+19.b/3
+ Implementation defined: Any other forms of interrupt handler
+ supported by the Attach_Handler and Interrupt_Handler aspects.
+
+ _Implementation Advice_
+
+20
+Whenever possible, the implementation should allow interrupt handlers to
+be called directly by the hardware.
+
+20.a/2
+ Implementation Advice: Interrupt handlers should be called
+ directly by the hardware.
+
+21
+Whenever practical, the implementation should detect violations of any
+implementation-defined restrictions before run time.
+
+21.a/2
+ Implementation Advice: Violations of any
+ implementation-defined restrictions on interrupt handlers
+ should be detected before run time.
+
+ NOTES
+
+22/3
+ 4 {AI05-0229-1AI05-0229-1} The Attach_Handler aspect may provide
+ static attachment of handlers to interrupts if the implementation
+ supports preelaboration of protected objects. (See *note C.4::.)
+
+23/2
+ 5 {AI95-00434-01AI95-00434-01} A protected object that has a
+ (protected) procedure attached to an interrupt should have a
+ ceiling priority at least as high as the highest processor priority
+ at which that interrupt will ever be delivered.
+
+24
+ 6 Protected procedures can also be attached dynamically to
+ interrupts via operations declared in the predefined package
+ Interrupts.
+
+25
+ 7 An example of a possible implementation-defined restriction is
+ disallowing the use of the standard storage pools within the body
+ of a protected procedure that is an interrupt handler.
+
+ _Incompatibilities With Ada 95_
+
+25.a/2
+ {AI95-00253-01AI95-00253-01} Amendment Correction: Corrected
+ the wording so that the rules for the use of Attach_Handler
+ and Interrupt_Handler are identical. This means that uses of
+ pragma Interrupt_Handler outside of the target protected type
+ or single protected object are now illegal.
+
+ _Wording Changes from Ada 95_
+
+25.b/2
+ {8652/00688652/0068} {AI95-00121-01AI95-00121-01} Corrigendum:
+ Clarified the meaning of "the previous handler" when
+ finalizing protected objects containing interrupt handlers.
+
+25.c/2
+ {AI95-00303-01AI95-00303-01} Dropped the requirement that an
+ object of a type containing an Interrupt_Handler pragma must
+ be declared at the library level. This was a generic contract
+ model violation. This change is not an extension, as an
+ attempt to attach such a handler with a routine in package
+ Interrupts will fail an accessibility check anyway. Moreover,
+ implementations can retain the rule as an
+ implementation-defined restriction on the use of the type, as
+ permitted by the Implementation Permissions above.
+
+ _Extensions to Ada 2005_
+
+25.d/3
+ {AI05-0229-1AI05-0229-1} Aspects Interrupt_Handler and
+ Attach_Handler are new; pragmas Interrupt_Handler and
+ Attach_Handler are now obsolescent.
+
+ _Wording Changes from Ada 2005_
+
+25.e/3
+ {AI05-0033-1AI05-0033-1} Correction: Added missing generic
+ contract wording for the aspects Attach_Handler and
+ Interrupt_Handler.
+
+\1f
+File: aarm2012.info, Node: C.3.2, Prev: C.3.1, Up: C.3
+
+C.3.2 The Package Interrupts
+----------------------------
+
+ _Static Semantics_
+
+1
+The following language-defined packages exist:
+
+2/3
+ {AI05-0167-1AI05-0167-1} with System;
+ with System.Multiprocessors;
+ package Ada.Interrupts is
+ type Interrupt_Id is implementation-defined;
+ type Parameterless_Handler is
+ access protected procedure;
+
+3/1
+ This paragraph was deleted.
+
+4
+ function Is_Reserved (Interrupt : Interrupt_Id)
+ return Boolean;
+
+5
+ function Is_Attached (Interrupt : Interrupt_Id)
+ return Boolean;
+
+6
+ function Current_Handler (Interrupt : Interrupt_Id)
+ return Parameterless_Handler;
+
+7
+ procedure Attach_Handler
+ (New_Handler : in Parameterless_Handler;
+ Interrupt : in Interrupt_Id);
+
+8
+ procedure Exchange_Handler
+ (Old_Handler : out Parameterless_Handler;
+ New_Handler : in Parameterless_Handler;
+ Interrupt : in Interrupt_Id);
+
+9
+ procedure Detach_Handler
+ (Interrupt : in Interrupt_Id);
+
+10
+ function Reference (Interrupt : Interrupt_Id)
+ return System.Address;
+
+10.1/3
+ {AI05-0167-1AI05-0167-1} function Get_CPU (Interrupt : Interrupt_Id)
+ return System.Multiprocessors.CPU_Range;
+
+11
+ private
+ ... -- not specified by the language
+ end Ada.Interrupts;
+
+12
+ package Ada.Interrupts.Names is
+ implementation-defined : constant Interrupt_Id :=
+ implementation-defined;
+ . . .
+ implementation-defined : constant Interrupt_Id :=
+ implementation-defined;
+ end Ada.Interrupts.Names;
+
+ _Dynamic Semantics_
+
+13
+The Interrupt_Id type is an implementation-defined discrete type used to
+identify interrupts.
+
+14
+The Is_Reserved function returns True if and only if the specified
+interrupt is reserved.
+
+15
+The Is_Attached function returns True if and only if a user-specified
+interrupt handler is attached to the interrupt.
+
+16/1
+{8652/00698652/0069} {AI95-00166-01AI95-00166-01} The Current_Handler
+function returns a value that represents the attached handler of the
+interrupt. If no user-defined handler is attached to the interrupt,
+Current_Handler returns null.
+
+17/3
+{AI05-0229-1AI05-0229-1} The Attach_Handler procedure attaches the
+specified handler to the interrupt, overriding any existing treatment
+(including a user handler) in effect for that interrupt. If New_Handler
+is null, the default treatment is restored. If New_Handler designates a
+protected procedure for which the aspect Interrupt_Handler is False,
+Program_Error is raised. In this case, the operation does not modify
+the existing interrupt treatment.
+
+18/1
+{8652/00698652/0069} {AI95-00166-01AI95-00166-01} The Exchange_Handler
+procedure operates in the same manner as Attach_Handler with the
+addition that the value returned in Old_Handler designates the previous
+treatment for the specified interrupt. If the previous treatment is not
+a user-defined handler, null is returned.
+
+18.a
+ Ramification: Calling Attach_Handler or Exchange_Handler with
+ this value for New_Handler restores the previous handler.
+
+18.a.1/1
+ {8652/00698652/0069} {AI95-00166-01AI95-00166-01} If the
+ application uses only parameterless procedures as handlers
+ (other types of handlers may be provided by the
+ implementation, but are not required by the standard), then if
+ Old_Handler is not null, it may be called to execute the
+ previous handler. This provides a way to cascade application
+ interrupt handlers. However, the default handler cannot be
+ cascaded this way (Old_Handler must be null for the default
+ handler).
+
+19
+The Detach_Handler procedure restores the default treatment for the
+specified interrupt.
+
+20
+For all operations defined in this package that take a parameter of type
+Interrupt_Id, with the exception of Is_Reserved and Reference, a check
+is made that the specified interrupt is not reserved. Program_Error is
+raised if this check fails.
+
+21/3
+{AI05-0229-1AI05-0229-1} If, by using the Attach_Handler,
+Detach_Handler, or Exchange_Handler procedures, an attempt is made to
+detach a handler that was attached statically (using the aspect
+Attach_Handler), the handler is not detached and Program_Error is
+raised.
+
+22/2
+{AI95-00434-01AI95-00434-01} The Reference function returns a value of
+type System.Address that can be used to attach a task entry via an
+address clause (see *note J.7.1::) to the interrupt specified by
+Interrupt. This function raises Program_Error if attaching task entries
+to interrupts (or to this particular interrupt) is not supported.
+
+22.1/3
+{AI05-0153-3AI05-0153-3} The function Get_CPU returns the processor on
+which the handler for Interrupt is executed. If the handler can execute
+on more than one processor the value
+System.Multiprocessors.Not_A_Specific_CPU is returned.
+
+ _Implementation Requirements_
+
+23
+At no time during attachment or exchange of handlers shall the current
+handler of the corresponding interrupt be undefined.
+
+ _Documentation Requirements_
+
+24/3
+{AI95-00434-01AI95-00434-01} {AI05-0229-1AI05-0229-1} If the
+Ceiling_Locking policy (see *note D.3::) is in effect, the
+implementation shall document the default ceiling priority assigned to a
+protected object that contains a protected procedure that specifies
+either the Attach_Handler or Interrupt_Handler aspects, but does not
+specify the Interrupt_Priority aspect. [This default need not be the
+same for all interrupts.]
+
+24.a.1/3
+ Documentation Requirement: If the Ceiling_Locking policy is in
+ effect, the default ceiling priority for a protected object
+ that specifies an interrupt handler aspect.
+
+ _Implementation Advice_
+
+25
+If implementation-defined forms of interrupt handler procedures are
+supported, such as protected procedures with parameters, then for each
+such form of a handler, a type analogous to Parameterless_Handler should
+be specified in a child package of Interrupts, with the same operations
+as in the predefined package Interrupts.
+
+25.a/2
+ Implementation Advice: If implementation-defined forms of
+ interrupt handler procedures are supported, then for each such
+ form of a handler, a type analogous to Parameterless_Handler
+ should be specified in a child package of Interrupts, with the
+ same operations as in the predefined package Interrupts.
+
+ NOTES
+
+26
+ 8 The package Interrupts.Names contains implementation-defined
+ names (and constant values) for the interrupts that are supported
+ by the implementation.
+
+ _Examples_
+
+27
+Example of interrupt handlers:
+
+28/3
+ {AI05-0229-1AI05-0229-1} Device_Priority : constant
+ array (1..5) of System.Interrupt_Priority := ( ... );
+ protected type Device_Interface
+ (Int_Id : Ada.Interrupts.Interrupt_Id)
+ with Interrupt_Priority => Device_Priority(Int_Id) is
+ procedure Handler
+ with Attach_Handler => Int_Id;
+ ...
+ end Device_Interface;
+ ...
+ Device_1_Driver : Device_Interface(1);
+ ...
+ Device_5_Driver : Device_Interface(5);
+ ...
+
+ _Wording Changes from Ada 95_
+
+28.a/2
+ {8652/00698652/0069} {AI95-00166-01AI95-00166-01} Corrigendum:
+ Clarified that the value returned by Current_Handler and
+ Exchange_Handler for the default treatment is null.
+
+ _Incompatibilities With Ada 2005_
+
+28.b/3
+ {AI05-0167-1AI05-0167-1} Functions Get_CPU is added to
+ Interrupts. If Interrupts is referenced in a use_clause, and
+ an entity E with a defining_identifier of Get_CPU is defined
+ in a package that is also referenced in a use_clause, the
+ entity E may no longer be use-visible, resulting in errors.
+ This should be rare and is easily fixed if it does occur.
+
+\1f
+File: aarm2012.info, Node: C.4, Next: C.5, Prev: C.3, Up: Annex C
+
+C.4 Preelaboration Requirements
+===============================
+
+1/3
+{AI05-0299-1AI05-0299-1} [This subclause specifies additional
+implementation and documentation requirements for the Preelaborate
+pragma (see *note 10.2.1::).]
+
+ _Implementation Requirements_
+
+2
+The implementation shall not incur any run-time overhead for the
+elaboration checks of subprograms and protected_bodies declared in
+preelaborated library units.
+
+3
+The implementation shall not execute any memory write operations after
+load time for the elaboration of constant objects declared immediately
+within the declarative region of a preelaborated library package, so
+long as the subtype and initial expression (or default initial
+expressions if initialized by default) of the object_declaration satisfy
+the following restrictions. The meaning of load time is implementation
+defined.
+
+3.a
+ Discussion: On systems where the image of the partition is
+ initially copied from disk to RAM, or from ROM to RAM, prior
+ to starting execution of the partition, the intention is that
+ "load time" consist of this initial copying step. On other
+ systems, load time and run time might actually be
+ interspersed.
+
+4
+ * Any subtype_mark denotes a statically constrained subtype, with
+ statically constrained subcomponents, if any;
+
+4.1/2
+ * {AI95-00161-01AI95-00161-01} no subtype_mark denotes a controlled
+ type, a private type, a private extension, a generic formal private
+ type, a generic formal derived type, or a descendant of such a
+ type;
+
+4.a.1/2
+ Reason: For an implementation that uses the registration
+ method of finalization, a controlled object will require some
+ code executed to register the object at the appropriate point.
+ The other types are those that might have a controlled
+ component. None of these types were allowed in preelaborated
+ units in Ada 95. These types are covered by the
+ Implementation Advice, of course, so they should still execute
+ as little code as possible.
+
+5
+ * any constraint is a static constraint;
+
+6
+ * any allocator is for an access-to-constant type;
+
+7
+ * any uses of predefined operators appear only within static
+ expressions;
+
+8
+ * any primaries that are names, other than attribute_references for
+ the Access or Address attributes, appear only within static
+ expressions;
+
+8.a
+ Ramification: This cuts out attribute_references that are not
+ static, except for Access and Address.
+
+9
+ * any name that is not part of a static expression is an expanded
+ name or direct_name that statically denotes some entity;
+
+9.a
+ Ramification: This cuts out function_calls and
+ type_conversions that are not static, including calls on
+ attribute functions like 'Image and 'Value.
+
+10
+ * any discrete_choice of an array_aggregate is static;
+
+11
+ * no language-defined check associated with the elaboration of the
+ object_declaration can fail.
+
+11.a/2
+ Reason: {AI95-00114-01AI95-00114-01} The intent is that
+ aggregates all of whose scalar subcomponents are static and
+ all of whose access subcomponents are null, allocators for
+ access-to-constant types, or X'Access, will be supported with
+ no run-time code generated.
+
+ _Documentation Requirements_
+
+12
+The implementation shall document any circumstances under which the
+elaboration of a preelaborated package causes code to be executed at run
+time.
+
+12.a/2
+ Documentation Requirement: Any circumstances when the
+ elaboration of a preelaborated package causes code to be
+ executed.
+
+13
+The implementation shall document whether the method used for
+initialization of preelaborated variables allows a partition to be
+restarted without reloading.
+
+13.a.1/2
+ Documentation Requirement: Whether a partition can be
+ restarted without reloading.
+
+13.a/2
+ This paragraph was deleted.
+
+13.b/2
+ Discussion: {AI95-00114-01AI95-00114-01} This covers the issue
+ of the run-time system itself being restartable, so that need
+ not be a separate Documentation Requirement.
+
+ _Implementation Advice_
+
+14
+It is recommended that preelaborated packages be implemented in such a
+way that there should be little or no code executed at run time for the
+elaboration of entities not already covered by the Implementation
+Requirements.
+
+14.a/2
+ Implementation Advice: Preelaborated packages should be
+ implemented such that little or no code is executed at run
+ time for the elaboration of entities.
+
+ _Wording Changes from Ada 95_
+
+14.b/2
+ {AI95-00161-01AI95-00161-01} Added wording to exclude the
+ additional kinds of types allowed in preelaborated units from
+ the Implementation Requirements.
+
+\1f
+File: aarm2012.info, Node: C.5, Next: C.6, Prev: C.4, Up: Annex C
+
+C.5 Pragma Discard_Names
+========================
+
+1
+[A pragma Discard_Names may be used to request a reduction in storage
+used for the names of certain entities.]
+
+ _Syntax_
+
+2
+ The form of a pragma Discard_Names is as follows:
+
+3
+ pragma Discard_Names[([On => ] local_name)];
+
+4
+ A pragma Discard_Names is allowed only immediately within a
+ declarative_part, immediately within a package_specification, or as
+ a configuration pragma.
+
+ _Legality Rules_
+
+5
+The local_name (if present) shall denote a nonderived enumeration
+[first] subtype, a tagged [first] subtype, or an exception. The pragma
+applies to the type or exception. Without a local_name, the pragma
+applies to all such entities declared after the pragma, within the same
+declarative region. Alternatively, the pragma can be used as a
+configuration pragma. If the pragma applies to a type, then it applies
+also to all descendants of the type.
+
+ _Static Semantics_
+
+6
+If a local_name is given, then a pragma Discard_Names is a
+representation pragma.
+
+6.a/3
+ Ramification: {AI05-0229-1AI05-0229-1} Representation pragmas
+ automatically specify aspects of the same name, so
+ Discard_Names can be used as an aspect_mark in an
+ aspect_specification instead of using the pragma on individual
+ entities.
+
+7/2
+{AI95-00285-01AI95-00285-01} {AI95-00400-01AI95-00400-01} If the pragma
+applies to an enumeration type, then the semantics of the
+Wide_Wide_Image and Wide_Wide_Value attributes are implementation
+defined for that type[; the semantics of Image, Wide_Image, Value, and
+Wide_Value are still defined in terms of Wide_Wide_Image and
+Wide_Wide_Value]. In addition, the semantics of Text_IO.Enumeration_IO
+are implementation defined. If the pragma applies to a tagged type,
+then the semantics of the Tags.Wide_Wide_Expanded_Name function are
+implementation defined for that type[; the semantics of
+Tags.Expanded_Name and Tags.Wide_Expanded_Name are still defined in
+terms of Tags.Wide_Wide_Expanded_Name]. If the pragma applies to an
+exception, then the semantics of the Exceptions.Wide_Wide_Exception_Name
+function are implementation defined for that exception[; the semantics
+of Exceptions.Exception_Name and Exceptions.Wide_Exception_Name are
+still defined in terms of Exceptions.Wide_Wide_Exception_Name].
+
+7.a
+ Implementation defined: The semantics of pragma Discard_Names.
+
+7.b
+ Ramification: The Width attribute is still defined in terms of
+ Image.
+
+7.c/2
+ {AI95-00285-01AI95-00285-01} The semantics of
+ S'Wide_Wide_Image and S'Wide_Wide_Value are implementation
+ defined for any subtype of an enumeration type to which the
+ pragma applies. (The pragma actually names the first subtype,
+ of course.)
+
+ _Implementation Advice_
+
+8
+If the pragma applies to an entity, then the implementation should
+reduce the amount of storage used for storing names associated with that
+entity.
+
+8.a/2
+ Implementation Advice: If pragma Discard_Names applies to an
+ entity, then the amount of storage used for storing names
+ associated with that entity should be reduced.
+
+8.b
+ Reason: A typical implementation of the Image attribute for
+ enumeration types is to store a table containing the names of
+ all the enumeration literals. Pragma Discard_Names allows the
+ implementation to avoid storing such a table without having to
+ prove that the Image attribute is never used (which can be
+ difficult in the presence of separate compilation).
+
+8.c
+ We did not specify the semantics of the Image attribute in the
+ presence of this pragma because different semantics might be
+ desirable in different situations. In some cases, it might
+ make sense to use the Image attribute to print out a useful
+ value that can be used to identify the entity given
+ information in compiler-generated listings. In other cases,
+ it might make sense to get an error at compile time or at run
+ time. In cases where memory is plentiful, the simplest
+ implementation makes sense: ignore the pragma.
+ Implementations that are capable of avoiding the extra storage
+ in cases where the Image attribute is never used might also
+ wish to ignore the pragma.
+
+8.d
+ The same applies to the Tags.Expanded_Name and
+ Exceptions.Exception_Name functions.
+
+ _Wording Changes from Ada 95_
+
+8.e/2
+ {AI95-00285-01AI95-00285-01} {AI95-00400-01AI95-00400-01}
+ Updated the wording to reflect that the double wide image and
+ value functions are now the master versions that the others
+ are defined from.
+
+\1f
+File: aarm2012.info, Node: C.6, Next: C.7, Prev: C.5, Up: Annex C
+
+C.6 Shared Variable Control
+===========================
+
+1/3
+{AI05-0229-1AI05-0229-1} {AI05-0299-1AI05-0299-1} [This subclause
+defines representation aspects that control the use of shared
+variables.]
+
+Paragraphs 2 through 6 were moved to *note Annex J::, "*note Annex J::
+Obsolescent Features".
+
+ _Static Semantics_
+
+6.1/3
+{AI05-0229-1AI05-0229-1} For an object_declaration, a
+component_declaration, or a full_type_declaration, the following
+representation aspects may be specified:
+
+6.2/3
+Atomic
+ The type of aspect Atomic is Boolean.
+
+6.a/3
+ Aspect Description for Atomic: Declare that a type, object, or
+ component is atomic.
+
+6.3/3
+Independent
+ The type of aspect Independent is Boolean.
+
+6.b/3
+ Aspect Description for Independent: Declare that a type,
+ object, or component is independently addressable.
+
+6.4/3
+Volatile
+ The type of aspect Volatile is Boolean.
+
+6.c/3
+ Aspect Description for Volatile: Declare that a type, object,
+ or component is volatile.
+
+6.5/3
+{AI05-0229-1AI05-0229-1} For a full_type_declaration of an array type
+(including the anonymous type of an object_declaration of an anonymous
+array object), the following representation aspects may be specified:
+
+6.6/3
+Atomic_Components
+ The type of aspect Atomic_Components is Boolean.
+
+6.d/3
+ Aspect Description for Atomic_Components: Declare that the
+ components of an array type or object are atomic.
+
+6.7/3
+Volatile_Components
+ The type of aspect Volatile_Components is Boolean.
+
+6.e/3
+ Aspect Description for Volatile_Components: Declare that the
+ components of an array type or object are volatile.
+
+6.8/3
+{AI05-0229-1AI05-0229-1} For a full_type_declaration (including the
+anonymous type of an object_declaration of an anonymous array object),
+the following representation aspect may be specified:
+
+6.9/3
+Independent_Components
+ The type of aspect Independent_Components is Boolean.
+
+6.f/3
+ Aspect Description for Independent_Components: Declare that
+ the components of an array or record type, or an array object,
+ are independently addressable.
+
+6.10/3
+{AI05-0229-1AI05-0229-1} If any of these aspects are directly specified,
+the aspect_definition shall be a static expression. If not specified
+(including by inheritance), each of these aspects is False.
+
+7/3
+{AI95-00272-01AI95-00272-01} {AI05-0229-1AI05-0229-1} An atomic type is
+one for which the aspect Atomic is True. An atomic object (including a
+component) is one for which the aspect Atomic is True, or a component of
+an array for which the aspect Atomic_Components is True for the
+associated type, or any object of an atomic type, other than objects
+obtained by evaluating a slice.
+
+7.a/2
+ Ramification: {AI95-00272-01AI95-00272-01} A slice of an
+ atomic array object is not itself atomic. That's necessary as
+ executing a read or write of a dynamic number of components in
+ a single instruction is not possible on many targets.
+
+8/3
+{AI05-0229-1AI05-0229-1} A volatile type is one for which the aspect
+Volatile is True. A volatile object (including a component) is one for
+which the aspect Volatile is True, or a component of an array for which
+the aspect Volatile_Components is True for the associated type, or any
+object of a volatile type. In addition, every atomic type or object is
+also defined to be volatile. Finally, if an object is volatile, then so
+are all of its subcomponents [(the same does not apply to atomic)].
+
+8.1/3
+{AI05-0009-1AI05-0009-1} {AI05-0229-1AI05-0229-1} When True, the aspects
+Independent and Independent_Components specify as independently
+addressable the named object or component(s), or in the case of a type,
+all objects or components of that type. All atomic objects are
+considered to be specified as independently addressable.
+
+8.a/3
+ Ramification: If the compiler cannot guarantee that an object
+ (including a component) for which aspect Independent or aspect
+ Independent_Components is True is independently addressable
+ from any other nonoverlapping object, then the aspect
+ specification must be rejected.
+
+8.b/3
+ Similarly, an atomic object (including atomic components) is
+ always independently addressable from any other nonoverlapping
+ object. Any representation item which would prevent this from
+ being true should be rejected, notwithstanding what this
+ Standard says elsewhere (specifically, in the Recommended
+ Level of Support).
+
+Paragraph 9 was moved to *note Annex J::, "*note Annex J:: Obsolescent
+Features".
+
+ _Legality Rules_
+
+9.1/3
+{AI05-0229-1AI05-0229-1} If aspect Independent_Components is specified
+for a full_type_declaration, the declaration shall be that of an array
+or record type.
+
+10/3
+{AI05-0229-1AI05-0229-1} It is illegal to specify either of the aspects
+Atomic or Atomic_Components to have the value True for an object or type
+if the implementation cannot support the indivisible reads and updates
+required by the aspect (see below).
+
+11
+It is illegal to specify the Size attribute of an atomic object, the
+Component_Size attribute for an array type with atomic components, or
+the layout attributes of an atomic component, in a way that prevents the
+implementation from performing the required indivisible reads and
+updates.
+
+12/3
+{AI05-0142-4AI05-0142-4} {AI05-0218-1AI05-0218-1} If an atomic object is
+passed as a parameter, then the formal parameter shall either have an
+atomic type or allow pass by copy. If an atomic object is used as an
+actual for a generic formal object of mode in out, then the type of the
+generic formal object shall be atomic. If the prefix of an
+attribute_reference for an Access attribute denotes an atomic object
+[(including a component)], then the designated type of the resulting
+access type shall be atomic. If an atomic type is used as an actual for
+a generic formal derived type, then the ancestor of the formal type
+shall be atomic. Corresponding rules apply to volatile objects and
+types.
+
+12.a/3
+ Ramification: {AI05-0142-4AI05-0142-4} A formal parameter
+ allows pass by copy if it is not aliased and it is of a type
+ that allows pass by copy (that is, is not a by-reference
+ type).
+
+12.1/3
+{AI05-0218-1AI05-0218-1} If a volatile type is used as an actual for a
+generic formal array type, then the element type of the formal type
+shall be volatile.
+
+13/3
+{AI05-0229-1AI05-0229-1} If an aspect Volatile, Volatile_Components,
+Atomic, or Atomic_Components is directly specified to have the value
+True for a stand-alone constant object, then the aspect Import shall
+also be specified as True for it.
+
+13.a
+ Ramification: Hence, no initialization expression is allowed
+ for such a constant. Note that a constant that is atomic or
+ volatile because of its type is allowed.
+
+13.b
+ Reason: Stand-alone constants that are explicitly specified as
+ Atomic or Volatile only make sense if they are being
+ manipulated outside the Ada program. From the Ada perspective
+ the object is read-only. Nevertheless, if imported and atomic
+ or volatile, the implementation should presume it might be
+ altered externally. For an imported stand-alone constant that
+ is not atomic or volatile, the implementation can assume that
+ it will not be altered.
+
+13.c/3
+ To be honest: {AI05-0218-1AI05-0218-1} Volatile_Components and
+ Atomic_Components actually are aspects of the anonymous array
+ type; this rule only applies when the aspect is specified
+ directly on the constant object and not when the (named) array
+ type has the aspect.
+
+13.1/3
+{AI05-0009-1AI05-0009-1} {AI05-0229-1AI05-0229-1} It is illegal to
+specify the aspect Independent or Independent_Components as True for a
+component, object or type if the implementation cannot provide the
+independent addressability required by the aspect (see *note 9.10::).
+
+13.2/3
+{AI05-0009-1AI05-0009-1} {AI05-0229-1AI05-0229-1} It is illegal to
+specify a representation aspect for a component, object or type for
+which the aspect Independent or Independent_Components is True, in a way
+that prevents the implementation from providing the independent
+addressability required by the aspect.
+
+Paragraph 14 was moved to *note Annex J::, "*note Annex J:: Obsolescent
+Features".
+
+ _Dynamic Semantics_
+
+15
+For an atomic object (including an atomic component) all reads and
+updates of the object as a whole are indivisible.
+
+16/3
+{AI05-0117-1AI05-0117-1} {AI05-0275-1AI05-0275-1} All tasks of the
+program (on all processors) that read or update volatile variables see
+the same order of updates to the variables. A use of an atomic variable
+or other mechanism may be necessary to avoid erroneous execution and to
+ensure that access to nonatomic volatile variables is sequential (see
+*note 9.10::).
+
+16.a/3
+ Implementation Note: {AI05-0117-1AI05-0117-1}
+ {AI05-0275-1AI05-0275-1} To ensure this, on a multiprocessor,
+ any read or update of an atomic object may require the use of
+ an appropriate memory barrier.
+
+16.b/3
+ Discussion: {AI05-0275-1AI05-0275-1} From *note 9.10:: it
+ follows that (in non-erroneous programs) accesses to
+ variables, including those shared by multiple tasks, are
+ always sequential. This guarantees that no task will ever see
+ partial updates of any variable. For volatile variables
+ (including atomic variables), the above rule additionally
+ specifies that all tasks see the same order of updates.
+
+16.c/3
+ {AI05-0275-1AI05-0275-1} If for a shared variable X, a read of
+ X occurs sequentially after an update of X, then the read will
+ return the updated value if X is volatile or atomic, but may
+ or or may not return the updated value if X is nonvolatile.
+ For nonvolatile accesses, a signaling action is needed in
+ order to share the updated value.
+
+16.d/3
+ {AI05-0275-1AI05-0275-1} Because accesses to the same atomic
+ variable by different tasks establish a sequential order
+ between the actions of those tasks, implementations may be
+ required to emit memory barriers around such updates or use
+ atomic instructions that imply such barriers.
+
+17
+Two actions are sequential (see *note 9.10::) if each is the read or
+update of the same atomic object.
+
+18
+If a type is atomic or volatile and it is not a by-copy type, then the
+type is defined to be a by-reference type. If any subcomponent of a
+type is atomic or volatile, then the type is defined to be a
+by-reference type.
+
+19
+If an actual parameter is atomic or volatile, and the corresponding
+formal parameter is not, then the parameter is passed by copy.
+
+19.a
+ Implementation Note: Note that in the case where such a
+ parameter is normally passed by reference, a copy of the
+ actual will have to be produced at the call-site, and a
+ pointer to the copy passed to the formal parameter. If the
+ actual is atomic, any copying has to use indivisible read on
+ the way in, and indivisible write on the way out.
+
+19.b
+ Reason: It has to be known at compile time whether an atomic
+ or a volatile parameter is to be passed by copy or by
+ reference. For some types, it is unspecified whether
+ parameters are passed by copy or by reference. The above
+ rules further specify the parameter passing rules involving
+ atomic and volatile types and objects.
+
+ _Implementation Requirements_
+
+20
+The external effect of a program (see *note 1.1.3::) is defined to
+include each read and update of a volatile or atomic object. The
+implementation shall not generate any memory reads or updates of atomic
+or volatile objects other than those specified by the program.
+
+20.a
+ Discussion: The presumption is that volatile or atomic objects
+ might reside in an "active" part of the address space where
+ each read has a potential side effect, and at the very least
+ might deliver a different value.
+
+20.b
+ The rule above and the definition of external effect are
+ intended to prevent (at least) the following incorrect
+ optimizations, where V is a volatile variable:
+
+20.c
+ * X:= V; Y:=V; cannot be allowed to be translated as Y:=V;
+ X:=V;
+
+20.d
+ * Deleting redundant loads: X:= V; X:= V; shall read the
+ value of V from memory twice.
+
+20.e
+ * Deleting redundant stores: V:= X; V:= X; shall write into
+ V twice.
+
+20.f
+ * Extra stores: V:= X+Y; should not translate to something
+ like V:= X; V:= V+Y;
+
+20.g
+ * Extra loads: X:= V; Y:= X+Z; X:=X+B; should not translate
+ to something like Y:= V+Z; X:= V+B;
+
+20.h
+ * Reordering of loads from volatile variables: X:= V1; Y:=
+ V2; (whether or not V1 = V2) should not translate to Y:=
+ V2; X:= V1;
+
+20.i
+ * Reordering of stores to volatile variables: V1:= X; V2:=
+ X; should not translate to V2:=X; V1:= X;
+
+21/3
+{AI05-0229-1AI05-0229-1} If the Pack aspect is True for a type any of
+whose subcomponents are atomic, the implementation shall not pack the
+atomic subcomponents more tightly than that for which it can support
+indivisible reads and updates.
+
+21.a/3
+ Implementation Note: {AI05-0009-1AI05-0009-1} Usually,
+ specifying aspect Pack for such a type will be illegal as the
+ Recommended Level of Support cannot be achieved; otherwise, a
+ warning might be appropriate if no packing whatsoever can be
+ achieved.
+
+ _Implementation Advice_
+
+22/2
+{AI95-00259-01AI95-00259-01} A load or store of a volatile object whose
+size is a multiple of System.Storage_Unit and whose alignment is
+nonzero, should be implemented by accessing exactly the bits of the
+object and no others.
+
+22.a/2
+ Implementation Advice: A load or store of a volatile object
+ whose size is a multiple of System.Storage_Unit and whose
+ alignment is nonzero, should be implemented by accessing
+ exactly the bits of the object and no others.
+
+22.b/2
+ Reason: Since any object can be a volatile object, including
+ packed array components and bit-mapped record components, we
+ require the above only when it is reasonable to assume that
+ the machine can avoid accessing bits outside of the object.
+
+22.c/2
+ Ramification: This implies that the load or store of a
+ volatile object that meets the above requirement should not be
+ combined with that of any other object, nor should it access
+ any bits not belonging to any other object. This means that
+ the suitability of the implementation for memory-mapped I/O
+ can be determined from its documentation, as any cases where
+ the implementation does not follow Implementation Advice must
+ be documented.
+
+23/2
+{AI95-00259-01AI95-00259-01} A load or store of an atomic object should,
+where possible, be implemented by a single load or store instruction.
+
+23.a/2
+ Implementation Advice: A load or store of an atomic object
+ should be implemented by a single load or store instruction.
+
+ NOTES
+
+24
+ 9 An imported volatile or atomic constant behaves as a constant
+ (i.e. read-only) with respect to other parts of the Ada program,
+ but can still be modified by an "external source."
+
+ _Incompatibilities With Ada 83_
+
+24.a
+ Pragma Atomic replaces Ada 83's pragma Shared. The name
+ "Shared" was confusing, because the pragma was not used to
+ mark variables as shared.
+
+ _Wording Changes from Ada 95_
+
+24.b/2
+ {AI95-00259-01AI95-00259-01} Added Implementation Advice to
+ clarify the meaning of Atomic and Volatile in machine terms.
+ The documentation that this advice applies will make the use
+ of Ada implementations more predictable for low-level (such as
+ device register) programming.
+
+24.c/2
+ {AI95-00272-01AI95-00272-01} Added wording to clarify that a
+ slice of an object of an atomic type is not atomic, just like
+ a component of an atomic type is not (necessarily) atomic.
+
+ _Incompatibilities With Ada 2005_
+
+24.d/3
+ {AI05-0218-1AI05-0218-1} Correction: Plugged a hole involving
+ volatile components of formal types when the formal type's
+ component has a nonvolatile type. This was done by making
+ certain actual types illegal for formal derived and formal
+ array types; these types were allowed for Ada 95 and Ada 2005.
+
+ _Extensions to Ada 2005_
+
+24.e/3
+ {AI05-0009-1AI05-0009-1} {AI05-0229-1AI05-0229-1} Aspects
+ Independent and Independent_Components are new; they eliminate
+ ambiguity about independent addressability.
+
+24.f/3
+ {AI05-0229-1AI05-0229-1} Aspects Atomic, Atomic_Components,
+ Volatile, and Volatile_Components are new; pragmas Atomic,
+ Atomic_Components, Volatile, and Volatile_Components are now
+ obsolescent.
+
+ _Wording Changes from Ada 2005_
+
+24.g/3
+ {AI05-0117-1AI05-0117-1} {AI05-0275-1AI05-0275-1} Revised the
+ definition of volatile to eliminate overspecification and
+ simply focus on the root requirement (that all tasks see the
+ same view of volatile objects). This is not an inconsistency;
+ "memory" arguably includes on-chip caches so long as those are
+ kept consistent. Moreover, it is difficult to imagine a
+ program that could tell the difference.
+
+24.h/3
+ {AI05-0142-4AI05-0142-4} Added wording to take explicitly
+ aliased parameters (see *note 6.1::) into account when
+ determining the legality of parameter passing of volatile and
+ atomic objects.
+
+\1f
+File: aarm2012.info, Node: C.7, Prev: C.6, Up: Annex C
+
+C.7 Task Information
+====================
+
+1/3
+{AI95-00266-02AI95-00266-02} {AI05-0299-1AI05-0299-1} [This subclause
+describes operations and attributes that can be used to obtain the
+identity of a task. In addition, a package that associates user-defined
+information with a task is defined. Finally, a package that associates
+termination procedures with a task or set of tasks is defined.]
+
+ _Wording Changes from Ada 95_
+
+1.a/3
+ {AI95-00266-02AI95-00266-02} {AI05-0299-1AI05-0299-1} The
+ title and text here were updated to reflect the addition of
+ task termination procedures to this subclause.
+
+* Menu:
+
+* C.7.1 :: The Package Task_Identification
+* C.7.2 :: The Package Task_Attributes
+* C.7.3 :: The Package Task_Termination
+
+\1f
+File: aarm2012.info, Node: C.7.1, Next: C.7.2, Up: C.7
+
+C.7.1 The Package Task_Identification
+-------------------------------------
+
+ _Static Semantics_
+
+1
+The following language-defined library package exists:
+
+2/2
+ {AI95-00362-01AI95-00362-01} package Ada.Task_Identification is
+ pragma Preelaborate(Task_Identification);
+ type Task_Id is private;
+ pragma Preelaborable_Initialization (Task_Id);
+ Null_Task_Id : constant Task_Id;
+ function "=" (Left, Right : Task_Id) return Boolean;
+
+3/3
+ {8652/00708652/0070} {AI95-00101-01AI95-00101-01} {AI05-0189-1AI05-0189-1} function Image (T : Task_Id) return String;
+ function Current_Task return Task_Id;
+ function Environment_Task return Task_Id;
+ procedure Abort_Task (T : in Task_Id);
+
+4/3
+ {AI05-0189-1AI05-0189-1} function Is_Terminated (T : Task_Id) return Boolean;
+ function Is_Callable (T : Task_Id) return Boolean;
+ function Activation_Is_Complete (T : Task_Id) return Boolean;
+ private
+ ... -- not specified by the language
+ end Ada.Task_Identification;
+
+ _Dynamic Semantics_
+
+5
+A value of the type Task_Id identifies an existent task. The constant
+Null_Task_Id does not identify any task. Each object of the type
+Task_Id is default initialized to the value of Null_Task_Id.
+
+6
+The function "=" returns True if and only if Left and Right identify the
+same task or both have the value Null_Task_Id.
+
+7
+The function Image returns an implementation-defined string that
+identifies T. If T equals Null_Task_Id, Image returns an empty string.
+
+7.a
+ Implementation defined: The result of the
+ Task_Identification.Image attribute.
+
+8
+The function Current_Task returns a value that identifies the calling
+task.
+
+8.1/3
+{AI05-0189-1AI05-0189-1} The function Environment_Task returns a value
+that identifies the environment task.
+
+9
+The effect of Abort_Task is the same as the abort_statement for the task
+identified by T. [In addition, if T identifies the environment task, the
+entire partition is aborted, See *note E.1::.]
+
+10
+The functions Is_Terminated and Is_Callable return the value of the
+corresponding attribute of the task identified by T.
+
+10.a.1/1
+ Ramification: {8652/01158652/0115}
+ {AI95-00206-01AI95-00206-01} These routines can be called with
+ an argument identifying the environment task. Is_Terminated
+ will always be False for such a call, but Is_Callable (usually
+ True) could be False if the environment task is waiting for
+ the termination of dependent tasks. Thus, a dependent task
+ can use Is_Callable to determine if the main subprogram has
+ completed.
+
+10.1/3
+{AI05-0189-1AI05-0189-1} The function Activation_Is_Complete returns
+True if the task identified by T has completed its activation (whether
+successfully or not). It returns False otherwise. If T identifies the
+environment task, Activation_Is_Complete returns True after the
+elaboration of the library_items of the partition has completed.
+
+11
+For a prefix T that is of a task type [(after any implicit
+dereference)], the following attribute is defined:
+
+12
+T'Identity
+ Yields a value of the type Task_Id that identifies the
+ task denoted by T.
+
+13
+For a prefix E that denotes an entry_declaration, the following
+attribute is defined:
+
+14/3
+E'Caller
+ {AI05-0262-1AI05-0262-1} Yields a value of the type
+ Task_Id that identifies the task whose call is now being
+ serviced. Use of this attribute is allowed only inside
+ an accept_statement, or entry_body after the
+ entry_barrier, corresponding to the entry_declaration
+ denoted by E.
+
+15
+Program_Error is raised if a value of Null_Task_Id is passed as a
+parameter to Abort_Task, Is_Terminated, and Is_Callable.
+
+16
+Abort_Task is a potentially blocking operation (see *note 9.5.1::).
+
+ _Bounded (Run-Time) Errors_
+
+17/3
+{AI95-00237-01AI95-00237-01} {AI05-0004-1AI05-0004-1} It is a bounded
+error to call the Current_Task function from an entry_body, interrupt
+handler, or finalization of a task attribute. Program_Error is raised,
+or an implementation-defined value of the type Task_Id is returned.
+
+17.a/2
+ Implementation defined: The value of Current_Task when in a
+ protected entry, interrupt handler, or finalization of a task
+ attribute.
+
+17.b
+ Implementation Note: This value could be Null_Task_Id, or the
+ ID of some user task, or that of an internal task created by
+ the implementation.
+
+17.c/2
+ Ramification: {AI95-00237-01AI95-00237-01} An entry barrier is
+ syntactically part of an entry_body, so a call to Current_Task
+ from an entry barrier is also covered by this rule.
+
+ _Erroneous Execution_
+
+18
+If a value of Task_Id is passed as a parameter to any of the operations
+declared in this package (or any language-defined child of this
+package), and the corresponding task object no longer exists, the
+execution of the program is erroneous.
+
+ _Documentation Requirements_
+
+19
+The implementation shall document the effect of calling Current_Task
+from an entry body or interrupt handler.
+
+19.a/2
+ This paragraph was deleted.
+
+19.b/2
+ Documentation Requirement: The effect of calling Current_Task
+ from an entry body or interrupt handler.
+
+ NOTES
+
+20
+ 10 This package is intended for use in writing user-defined task
+ scheduling packages and constructing server tasks. Current_Task
+ can be used in conjunction with other operations requiring a task
+ as an argument such as Set_Priority (see *note D.5::).
+
+21
+ 11 The function Current_Task and the attribute Caller can return a
+ Task_Id value that identifies the environment task.
+
+ _Extensions to Ada 95_
+
+21.a/2
+ {AI95-00362-01AI95-00362-01} Task_Identification is now
+ preelaborated, so it can be used in preelaborated units.
+
+ _Wording Changes from Ada 95_
+
+21.b/2
+ {8652/00708652/0070} {AI95-00101-01AI95-00101-01} Corrigendum:
+ Corrected the mode of the parameter to Abort_Task to in.
+
+21.c/2
+ {AI95-00237-01AI95-00237-01} Corrected the wording to include
+ finalization of a task attribute in the bounded error case; we
+ don't want to specify which task does these operations.
+
+ _Incompatibilities With Ada 2005_
+
+21.d/3
+ {AI05-0189-1AI05-0189-1} Functions Environment_Task and
+ Activation_Is_Complete are added to Task_Identification. If
+ Task_Identification is referenced in a use_clause, and an
+ entity E with a defining_identifier of Environment_Task or
+ Activation_Is_Complete is defined in a package that is also
+ referenced in a use_clause, the entity E may no longer be
+ use-visible, resulting in errors. This should be rare and is
+ easily fixed if it does occur.
+
+\1f
+File: aarm2012.info, Node: C.7.2, Next: C.7.3, Prev: C.7.1, Up: C.7
+
+C.7.2 The Package Task_Attributes
+---------------------------------
+
+ _Static Semantics_
+
+1
+The following language-defined generic library package exists:
+
+2
+ with Ada.Task_Identification; use Ada.Task_Identification;
+ generic
+ type Attribute is private;
+ Initial_Value : in Attribute;
+ package Ada.Task_Attributes is
+
+3
+ type Attribute_Handle is access all Attribute;
+
+4
+ function Value(T : Task_Id := Current_Task)
+ return Attribute;
+
+5
+ function Reference(T : Task_Id := Current_Task)
+ return Attribute_Handle;
+
+6
+ procedure Set_Value(Val : in Attribute;
+ T : in Task_Id := Current_Task);
+ procedure Reinitialize(T : in Task_Id := Current_Task);
+
+7
+ end Ada.Task_Attributes;
+
+ _Dynamic Semantics_
+
+8
+When an instance of Task_Attributes is elaborated in a given active
+partition, an object of the actual type corresponding to the formal type
+Attribute is implicitly created for each task (of that partition) that
+exists and is not yet terminated. This object acts as a user-defined
+attribute of the task. A task created previously in the partition and
+not yet terminated has this attribute from that point on. Each task
+subsequently created in the partition will have this attribute when
+created. In all these cases, the initial value of the given attribute
+is Initial_Value.
+
+9
+The Value operation returns the value of the corresponding attribute of
+T.
+
+10
+The Reference operation returns an access value that designates the
+corresponding attribute of T.
+
+11
+The Set_Value operation performs any finalization on the old value of
+the attribute of T and assigns Val to that attribute (see *note 5.2::
+and *note 7.6::).
+
+12
+The effect of the Reinitialize operation is the same as Set_Value where
+the Val parameter is replaced with Initial_Value.
+
+12.a
+ Implementation Note: In most cases, the attribute memory can
+ be reclaimed at this point.
+
+13
+For all the operations declared in this package, Tasking_Error is raised
+if the task identified by T is terminated. Program_Error is raised if
+the value of T is Null_Task_Id.
+
+13.1/2
+{AI95-00237-01AI95-00237-01} After a task has terminated, all of its
+attributes are finalized, unless they have been finalized earlier. When
+the master of an instantiation of Ada.Task_Attributes is finalized, the
+corresponding attribute of each task is finalized, unless it has been
+finalized earlier.
+
+13.a/2
+ Reason: This is necessary so that a task attribute does not
+ outlive its type. For instance, that's possible if the
+ instantiation is nested, and the attribute is on a
+ library-level task.
+
+13.b/2
+ Ramification: The task owning an attribute cannot, in general,
+ finalize that attribute. That's because the attributes are
+ finalized after the task is terminated; moreover, a task may
+ have attributes as soon as it is created; the task may never
+ even have been activated.
+
+ _Bounded (Run-Time) Errors_
+
+13.2/1
+{8652/00718652/0071} {AI95-00165-01AI95-00165-01} If the package
+Ada.Task_Attributes is instantiated with a controlled type and the
+controlled type has user-defined Adjust or Finalize operations that in
+turn access task attributes by any of the above operations, then a call
+of Set_Value of the instantiated package constitutes a bounded error.
+The call may perform as expected or may result in forever blocking the
+calling task and subsequently some or all tasks of the partition.
+
+ _Erroneous Execution_
+
+14
+It is erroneous to dereference the access value returned by a given call
+on Reference after a subsequent call on Reinitialize for the same task
+attribute, or after the associated task terminates.
+
+14.a
+ Reason: This allows the storage to be reclaimed for the object
+ associated with an attribute upon Reinitialize or task
+ termination.
+
+15
+If a value of Task_Id is passed as a parameter to any of the operations
+declared in this package and the corresponding task object no longer
+exists, the execution of the program is erroneous.
+
+15.1/2
+{8652/00718652/0071} {AI95-00165-01AI95-00165-01}
+{AI95-00237-01AI95-00237-01} An access to a task attribute via a value
+of type Attribute_Handle is erroneous if executed concurrently with
+another such access or a call of any of the operations declared in
+package Task_Attributes. An access to a task attribute is erroneous if
+executed concurrently with or after the finalization of the task
+attribute.
+
+15.a.1/1
+ Reason: There is no requirement of atomicity on accesses via a
+ value of type Attribute_Handle.
+
+15.a.2/2
+ Ramification: A task attribute can only be accessed after
+ finalization through a value of type Attribute_Handle.
+ Operations in package Task_Attributes cannot be used to access
+ a task attribute after finalization, because either the master
+ of the instance has been or is in the process of being left
+ (in which case the instance is out of scope and thus cannot be
+ called), or the associated task is already terminated (in
+ which case Tasking_Error is raised for any attempt to call a
+ task attribute operation).
+
+ _Implementation Requirements_
+
+16/1
+{8652/00718652/0071} {AI95-00165-01AI95-00165-01} For a given attribute
+of a given task, the implementation shall perform the operations
+declared in this package atomically with respect to any of these
+operations of the same attribute of the same task. The granularity of
+any locking mechanism necessary to achieve such atomicity is
+implementation defined.
+
+16.a.1/1
+ Implementation defined: Granularity of locking for
+ Task_Attributes.
+
+16.a
+ Ramification: Hence, other than by dereferencing an access
+ value returned by Reference, an attribute of a given task can
+ be safely read and updated concurrently by multiple tasks.
+
+17/2
+{AI95-00237-01AI95-00237-01} After task attributes are finalized, the
+implementation shall reclaim any storage associated with the attributes.
+
+ _Documentation Requirements_
+
+18
+The implementation shall document the limit on the number of attributes
+per task, if any, and the limit on the total storage for attribute
+values per task, if such a limit exists.
+
+19
+In addition, if these limits can be configured, the implementation shall
+document how to configure them.
+
+19.a/2
+ This paragraph was deleted.
+
+19.b/2
+ Documentation Requirement: For package Task_Attributes, limits
+ on the number and size of task attributes, and how to
+ configure any limits.
+
+ _Metrics_
+
+20/2
+{AI95-00434-01AI95-00434-01} The implementation shall document the
+following metrics: A task calling the following subprograms shall
+execute at a sufficiently high priority as to not be preempted during
+the measurement period. This period shall start just before issuing the
+call and end just after the call completes. If the attributes of task T
+are accessed by the measurement tests, no other task shall access
+attributes of that task during the measurement period. For all
+measurements described here, the Attribute type shall be a scalar type
+whose size is equal to the size of the predefined type Integer. For
+each measurement, two cases shall be documented: one where the accessed
+attributes are of the calling task [(that is, the default value for the
+T parameter is used)], and the other, where T identifies another,
+nonterminated, task.
+
+21
+The following calls (to subprograms in the Task_Attributes package)
+shall be measured:
+
+22
+ * a call to Value, where the return value is Initial_Value;
+
+23
+ * a call to Value, where the return value is not equal to
+ Initial_Value;
+
+24
+ * a call to Reference, where the return value designates a value
+ equal to Initial_Value;
+
+25
+ * a call to Reference, where the return value designates a value not
+ equal to Initial_Value;
+
+26/2
+ * {AI95-00434-01AI95-00434-01} a call to Set_Value where the Val
+ parameter is not equal to Initial_Value and the old attribute value
+ is equal to Initial_Value;
+
+27
+ * a call to Set_Value where the Val parameter is not equal to
+ Initial_Value and the old attribute value is not equal to
+ Initial_Value.
+
+27.a/2
+ Documentation Requirement: The metrics for the Task_Attributes
+ package.
+
+ _Implementation Permissions_
+
+28
+An implementation need not actually create the object corresponding to a
+task attribute until its value is set to something other than that of
+Initial_Value, or until Reference is called for the task attribute.
+Similarly, when the value of the attribute is to be reinitialized to
+that of Initial_Value, the object may instead be finalized and its
+storage reclaimed, to be recreated when needed later. While the object
+does not exist, the function Value may simply return Initial_Value,
+rather than implicitly creating the object.
+
+28.a
+ Discussion: The effect of this permission can only be observed
+ if the assignment operation for the corresponding type has
+ side effects.
+
+28.b/2
+ Implementation Note: {AI95-00114-01AI95-00114-01} This
+ permission means that even though every task has every
+ attribute, storage need only be allocated for those attributes
+ for which function Reference has been invoked or set to a
+ value other than that of Initial_Value.
+
+29
+An implementation is allowed to place restrictions on the maximum number
+of attributes a task may have, the maximum size of each attribute, and
+the total storage size allocated for all the attributes of a task.
+
+ _Implementation Advice_
+
+30/2
+{AI95-00434-01AI95-00434-01} Some implementations are targeted to
+domains in which memory use at run time must be completely
+deterministic. For such implementations, it is recommended that the
+storage for task attributes will be pre-allocated statically and not
+from the heap. This can be accomplished by either placing restrictions
+on the number and the size of the attributes of a task, or by using the
+pre-allocated storage for the first N attribute objects, and the heap
+for the others. In the latter case, N should be documented.
+
+30.a/2
+ Implementation Advice: If the target domain requires
+ deterministic memory use at run time, storage for task
+ attributes should be pre-allocated statically and the number
+ of attributes pre-allocated should be documented.
+
+30.b/2
+ Discussion: We don't mention "restrictions on the size and
+ number" (that is, limits) in the text for the Annex, because
+ it is covered by the Documentation Requirement above, and we
+ try not to repeat requirements in the Annex (they're enough
+ work to meet without having to do things twice).
+
+30.1/2
+{AI95-00237-01AI95-00237-01} Finalization of task attributes and
+reclamation of associated storage should be performed as soon as
+possible after task termination.
+
+30.c/2
+ Implementation Advice: Finalization of task attributes and
+ reclamation of associated storage should be performed as soon
+ as possible after task termination.
+
+30.d/2
+ Reason: {AI95-00237-01AI95-00237-01} This is necessary because
+ the normative wording only says that attributes are finalized
+ "after" task termination. Without this advice, waiting until
+ the instance is finalized would meet the requirements (it is
+ after termination, but may be a very long time after
+ termination). We can't say anything more specific than this,
+ as we do not want to require the overhead of an interaction
+ with the tasking system to be done at a specific point.
+
+ NOTES
+
+31
+ 12 An attribute always exists (after instantiation), and has the
+ initial value. It need not occupy memory until the first operation
+ that potentially changes the attribute value. The same holds true
+ after Reinitialize.
+
+32
+ 13 The result of the Reference function should be used with care;
+ it is always safe to use that result in the task body whose
+ attribute is being accessed. However, when the result is being
+ used by another task, the programmer must make sure that the task
+ whose attribute is being accessed is not yet terminated. Failing
+ to do so could make the program execution erroneous.
+
+ _Wording Changes from Ada 95_
+
+33.a/2
+ {8652/00718652/0071} {AI95-00165-01AI95-00165-01} Corrigendum:
+ Clarified that use of task attribute operations from within a
+ task attribute operation (by an Adjust or Finalize call) is a
+ bounded error, and that concurrent use of attribute handles is
+ erroneous.
+
+33.b/2
+ {AI95-00237-01AI95-00237-01} Clarified the wording so that the
+ finalization takes place after the termination of the task or
+ when the instance is finalized (whichever is sooner).
+
+\1f
+File: aarm2012.info, Node: C.7.3, Prev: C.7.2, Up: C.7
+
+C.7.3 The Package Task_Termination
+----------------------------------
+
+ _Static Semantics_
+
+1/2
+{AI95-00266-02AI95-00266-02} The following language-defined library
+package exists:
+
+2/2
+ with Ada.Task_Identification;
+ with Ada.Exceptions;
+ package Ada.Task_Termination is
+ pragma Preelaborate(Task_Termination);
+
+3/2
+ type Cause_Of_Termination is (Normal, Abnormal, Unhandled_Exception);
+
+4/2
+ type Termination_Handler is access protected procedure
+ (Cause : in Cause_Of_Termination;
+ T : in Ada.Task_Identification.Task_Id;
+ X : in Ada.Exceptions.Exception_Occurrence);
+
+5/2
+ procedure Set_Dependents_Fallback_Handler
+ (Handler: in Termination_Handler);
+ function Current_Task_Fallback_Handler return Termination_Handler;
+
+6/2
+ procedure Set_Specific_Handler
+ (T : in Ada.Task_Identification.Task_Id;
+ Handler : in Termination_Handler);
+ function Specific_Handler (T : Ada.Task_Identification.Task_Id)
+ return Termination_Handler;
+
+7/2
+ end Ada.Task_Termination;
+
+ _Dynamic Semantics_
+
+8/3
+{AI95-00266-02AI95-00266-02} {AI05-0202-1AI05-0202-1} The type
+Termination_Handler identifies a protected procedure to be executed by
+the implementation when a task terminates. Such a protected procedure
+is called a handler. In all cases T identifies the task that is
+terminating. If the task terminates due to completing the last
+statement of its body, or as a result of waiting on a terminate
+alternative, and the finalization of the task completes normally, then
+Cause is set to Normal and X is set to Null_Occurrence. If the task
+terminates because it is being aborted, then Cause is set to Abnormal; X
+is set to Null_Occurrence if the finalization of the task completes
+normally. If the task terminates because of an exception raised by the
+execution of its task_body, then Cause is set to Unhandled_Exception; X
+is set to the associated exception occurrence if the finalization of the
+task completes normally. Independent of how the task completes, if
+finalization of the task propagates an exception, then Cause is either
+Unhandled_Exception or Abnormal, and X is an exception occurrence that
+identifies the Program_Error exception.
+
+9/2
+{AI95-00266-02AI95-00266-02} Each task has two termination handlers, a
+fall-back handler and a specific handler. The specific handler applies
+only to the task itself, while the fall-back handler applies only to the
+dependent tasks of the task. A handler is said to be set if it is
+associated with a nonnull value of type Termination_Handler, and cleared
+otherwise. When a task is created, its specific handler and fall-back
+handler are cleared.
+
+10/3
+{AI95-00266-02AI95-00266-02} {AI05-0264-1AI05-0264-1} The procedure
+Set_Dependents_Fallback_Handler changes the fall-back handler for the
+calling task: if Handler is null, that fall-back handler is cleared;
+otherwise, it is set to be Handler.all. If a fall-back handler had
+previously been set it is replaced.
+
+11/3
+{AI95-00266-02AI95-00266-02} {AI05-0264-1AI05-0264-1} The function
+Current_Task_Fallback_Handler returns the fall-back handler that is
+currently set for the calling task, if one is set; otherwise, it returns
+null.
+
+12/3
+{AI95-00266-02AI95-00266-02} {AI05-0264-1AI05-0264-1} The procedure
+Set_Specific_Handler changes the specific handler for the task
+identified by T: if Handler is null, that specific handler is cleared;
+otherwise, it is set to be Handler.all. If a specific handler had
+previously been set it is replaced.
+
+12.a/3
+ Ramification: {AI05-0005-1AI05-0005-1} This package cannot
+ portably be used to set a handler on the program as a whole.
+ It is possible to call Set_Specific_Handler with the
+ environment task's ID. But any call to the handler would
+ necessarily be a Bounded (Run-Time) Error, as the handler is
+ called after the task's finalization has completed. In the
+ case of the environment task, that includes any possible
+ protected objects, and calling a protected object after it is
+ finalized is a Bounded (Run-Time) Error (see *note 9.4::).
+ This might work in a particular implementation, but it cannot
+ be depended upon.
+
+13/3
+{AI95-00266-02AI95-00266-02} {AI05-0264-1AI05-0264-1} The function
+Specific_Handler returns the specific handler that is currently set for
+the task identified by T, if one is set; otherwise, it returns null.
+
+14/2
+{AI95-00266-02AI95-00266-02} As part of the finalization of a task_body,
+after performing the actions specified in *note 7.6:: for finalization
+of a master, the specific handler for the task, if one is set, is
+executed. If the specific handler is cleared, a search for a fall-back
+handler proceeds by recursively following the master relationship for
+the task. If a task is found whose fall-back handler is set, that
+handler is executed; otherwise, no handler is executed.
+
+15/2
+{AI95-00266-02AI95-00266-02} For Set_Specific_Handler or
+Specific_Handler, Tasking_Error is raised if the task identified by T
+has already terminated. Program_Error is raised if the value of T is
+Ada.Task_Identification.Null_Task_Id.
+
+16/2
+{AI95-00266-02AI95-00266-02} An exception propagated from a handler that
+is invoked as part of the termination of a task has no effect.
+
+ _Erroneous Execution_
+
+17/2
+{AI95-00266-02AI95-00266-02} For a call of Set_Specific_Handler or
+Specific_Handler, if the task identified by T no longer exists, the
+execution of the program is erroneous.
+
+ _Extensions to Ada 95_
+
+17.a/2
+ {AI95-00266-02AI95-00266-02} Package Task_Termination is new.
+
+ _Wording Changes from Ada 2005_
+
+17.b/3
+ {AI05-0202-1AI05-0202-1} Correction: Specified what is passed
+ to the handler if the finalization of the task fails after it
+ is completed. This was not specified at all in Ada 2005, so
+ there is a possibility that some program depended on some
+ other behavior of an implementation. But as this case is very
+ unlikely (and only occurs when there is already a significant
+ bug in the program - so should not occur in fielded systems),
+ we're not listing this as an inconsistency.
+
+\1f
+File: aarm2012.info, Node: Annex D, Next: Annex E, Prev: Annex C, Up: Top
+
+Annex D Real-Time Systems
+*************************
+
+1
+This Annex specifies additional characteristics of Ada implementations
+intended for real-time systems software. To conform to this Annex, an
+implementation shall also conform to the Systems Programming Annex.
+
+ _Metrics_
+
+2
+The metrics are documentation requirements; an implementation shall
+document the values of the language-defined metrics for at least one
+configuration [of hardware or an underlying system] supported by the
+implementation, and shall document the details of that configuration.
+
+2.a/2
+ This paragraph was deleted.
+
+2.a.1/2
+ Documentation Requirement: The details of the configuration
+ used to generate the values of all metrics.
+
+2.b
+ Reason: The actual values of the metrics are likely to depend
+ on hardware configuration details that are variable and
+ generally outside the control of a compiler vendor.
+
+3
+The metrics do not necessarily yield a simple number. [For some, a
+range is more suitable, for others a formula dependent on some parameter
+is appropriate, and for others, it may be more suitable to break the
+metric into several cases.] Unless specified otherwise, the metrics in
+this annex are expressed in processor clock cycles. For metrics that
+require documentation of an upper bound, if there is no upper bound, the
+implementation shall report that the metric is unbounded.
+
+3.a
+ Discussion: There are several good reasons to specify metrics
+ in seconds; there are however equally good reasons to specify
+ them in processor clock cycles. In defining the metrics, we
+ have tried to strike a balance on a case-by-case basis.
+
+3.b
+ It has been suggested that all metrics should be given names,
+ so that "data-sheets" could be formulated and published by
+ vendors. However the paragraph number can serve that purpose.
+
+ NOTES
+
+4
+ 1 The specification of the metrics makes a distinction between
+ upper bounds and simple execution times. Where something is just
+ specified as "the execution time of" a piece of code, this leaves
+ one the freedom to choose a nonpathological case. This kind of
+ metric is of the form "there exists a program such that the value
+ of the metric is V". Conversely, the meaning of upper bounds is
+ "there is no program such that the value of the metric is greater
+ than V". This kind of metric can only be partially tested, by
+ finding the value of V for one or more test programs.
+
+5
+ 2 The metrics do not cover the whole language; they are limited to
+ features that are specified in *note Annex C::, "*note Annex C::
+ Systems Programming" and in this Annex. The metrics are intended
+ to provide guidance to potential users as to whether a particular
+ implementation of such a feature is going to be adequate for a
+ particular real-time application. As such, the metrics are aimed
+ at known implementation choices that can result in significant
+ performance differences.
+
+6
+ 3 The purpose of the metrics is not necessarily to provide
+ fine-grained quantitative results or to serve as a comparison
+ between different implementations on the same or different
+ platforms. Instead, their goal is rather qualitative; to define a
+ standard set of approximate values that can be measured and used to
+ estimate the general suitability of an implementation, or to
+ evaluate the comparative utility of certain features of an
+ implementation for a particular real-time application.
+
+ _Extensions to Ada 83_
+
+6.a
+ This Annex is new to Ada 95.
+
+* Menu:
+
+* D.1 :: Task Priorities
+* D.2 :: Priority Scheduling
+* D.3 :: Priority Ceiling Locking
+* D.4 :: Entry Queuing Policies
+* D.5 :: Dynamic Priorities
+* D.6 :: Preemptive Abort
+* D.7 :: Tasking Restrictions
+* D.8 :: Monotonic Time
+* D.9 :: Delay Accuracy
+* D.10 :: Synchronous Task Control
+* D.11 :: Asynchronous Task Control
+* D.12 :: Other Optimizations and Determinism Rules
+* D.13 :: The Ravenscar Profile
+* D.14 :: Execution Time
+* D.15 :: Timing Events
+* D.16 :: Multiprocessor Implementation
+
+\1f
+File: aarm2012.info, Node: D.1, Next: D.2, Up: Annex D
+
+D.1 Task Priorities
+===================
+
+1/3
+{AI05-0299-1AI05-0299-1} [This subclause specifies the priority model
+for real-time systems. In addition, the methods for specifying
+priorities are defined.]
+
+Paragraphs 2 through 6 were moved to *note Annex J::, "*note Annex J::
+Obsolescent Features".
+
+ _Static Semantics_
+
+6.1/3
+{AI05-0229-1AI05-0229-1} For a task type (including the anonymous type
+of a single_task_declaration), protected type (including the anonymous
+type of a single_protected_declaration), or subprogram, the following
+language-defined representation aspects may be specified:
+
+6.2/3
+Priority
+ The aspect Priority is an expression, which shall be of
+ type Integer.
+
+6.a/3
+ Aspect Description for Priority: Priority of a task object or
+ type, or priority of a protected object or type; the priority
+ is not in the interrupt range.
+
+6.3/3
+Interrupt_Priority
+ The aspect Interrupt_Priority is an expression, which
+ shall be of type Integer.
+
+6.b/3
+ Aspect Description for Interrupt_Priority: Priority of a task
+ object or type, or priority of a protected object or type; the
+ priority is in the interrupt range.
+
+ _Legality Rules_
+
+7/3
+This paragraph was deleted.{AI05-0229-1AI05-0229-1}
+
+8/3
+{AI05-0229-1AI05-0229-1} If the Priority aspect is specified for a
+subprogram, the expression shall be static, and its value shall be in
+the range of System.Priority.
+
+8.a
+ Reason: This value is needed before it gets elaborated, when
+ the environment task starts executing.
+
+8.1/3
+{AI05-0229-1AI05-0229-1} At most one of the Priority and
+Interrupt_Priority aspects may be specified for a given entity.
+
+8.b/3
+ Ramification: This includes specifying via pragmas (see *note
+ J.15.11::). Note that *note 13.1:: prevents multiple
+ specifications of a single representation aspect by any means.
+
+8.2/3
+{AI05-0229-1AI05-0229-1} Neither of the Priority or Interrupt_Priority
+aspects shall be specified for a synchronized interface type.
+
+ _Static Semantics_
+
+9
+The following declarations exist in package System:
+
+10
+ subtype Any_Priority is Integer range implementation-defined;
+ subtype Priority is Any_Priority
+ range Any_Priority'First .. implementation-defined;
+ subtype Interrupt_Priority is Any_Priority
+ range Priority'Last+1 .. Any_Priority'Last;
+
+11
+ Default_Priority : constant Priority := (Priority'First + Priority'Last)/2;
+
+11.a
+ Implementation defined: The declarations of Any_Priority and
+ Priority.
+
+12
+The full range of priority values supported by an implementation is
+specified by the subtype Any_Priority. The subrange of priority values
+that are high enough to require the blocking of one or more interrupts
+is specified by the subtype Interrupt_Priority. [The subrange of
+priority values below System.Interrupt_Priority'First is specified by
+the subtype System.Priority.]
+
+13/3
+This paragraph was deleted.{AI05-0229-1AI05-0229-1}
+
+ _Dynamic Semantics_
+
+14/3
+{AI05-0229-1AI05-0229-1} The Priority aspect has no effect if it is
+specified for a subprogram other than the main subprogram; the Priority
+value is not associated with any task.
+
+15
+A task priority is an integer value that indicates a degree of urgency
+and is the basis for resolving competing demands of tasks for resources.
+Unless otherwise specified, whenever tasks compete for processors or
+other implementation-defined resources, the resources are allocated to
+the task with the highest priority value. The base priority of a task
+is the priority with which it was created, or to which it was later set
+by Dynamic_Priorities.Set_Priority (see *note D.5::). At all times, a
+task also has an active priority, which generally reflects its base
+priority as well as any priority it inherits from other sources.
+Priority inheritance is the process by which the priority of a task or
+other entity (e.g. a protected object; see *note D.3::) is used in the
+evaluation of another task's active priority.
+
+15.a
+ Implementation defined: Implementation-defined execution
+ resources.
+
+16/3
+{AI05-0229-1AI05-0229-1} The effect of specifying a Priority or
+Interrupt_Priority aspect for a protected type or
+single_protected_declaration is discussed in *note D.3::.
+
+17/3
+{AI05-0229-1AI05-0229-1} The expression specified for the Priority or
+Interrupt_Priority aspect of a task is evaluated for each task object
+(see *note 9.1::). For the Priority aspect, the value of the expression
+is converted to the subtype Priority; for the Interrupt_Priority aspect,
+this value is converted to the subtype Any_Priority. The priority value
+is then associated with the task object whose task declaration specifies
+the aspect.
+
+18/3
+{AI05-0229-1AI05-0229-1} Likewise, the priority value is associated with
+the environment task if the aspect is specified for the main subprogram.
+
+19/3
+{AI05-0229-1AI05-0229-1} The initial value of a task's base priority is
+specified by default or by means of a Priority or Interrupt_Priority
+aspect. [After a task is created, its base priority can be changed only
+by a call to Dynamic_Priorities.Set_Priority (see *note D.5::).] The
+initial base priority of a task in the absence of an aspect is the base
+priority of the task that creates it at the time of creation (see *note
+9.1::). If the aspect Priority is not specified for the main
+subprogram, the initial base priority of the environment task is
+System.Default_Priority. [The task's active priority is used when the
+task competes for processors. Similarly, the task's active priority is
+used to determine the task's position in any queue when Priority_Queuing
+is specified (see *note D.4::).]
+
+20/2
+{AI95-00357-01AI95-00357-01} At any time, the active priority of a task
+is the maximum of all the priorities the task is inheriting at that
+instant. For a task that is not held (see *note D.11::), its base
+priority is a source of priority inheritance unless otherwise specified
+for a particular task dispatching policy. Other sources of priority
+inheritance are specified under the following conditions:
+
+20.a
+ Discussion: Other parts of the annex, e.g. *note D.11::,
+ define other sources of priority inheritance.
+
+21/1
+ * {8652/00728652/0072} {AI95-00092-01AI95-00092-01} During
+ activation, a task being activated inherits the active priority
+ that its activator (see *note 9.2::) had at the time the activation
+ was initiated.
+
+22/1
+ * {8652/00728652/0072} {AI95-00092-01AI95-00092-01} During
+ rendezvous, the task accepting the entry call inherits the priority
+ of the entry call (see *note 9.5.3:: and *note D.4::).
+
+23
+ * During a protected action on a protected object, a task inherits
+ the ceiling priority of the protected object (see *note 9.5:: and
+ *note D.3::).
+
+24
+In all of these cases, the priority ceases to be inherited as soon as
+the condition calling for the inheritance no longer exists.
+
+ _Implementation Requirements_
+
+25
+The range of System.Interrupt_Priority shall include at least one value.
+
+26
+The range of System.Priority shall include at least 30 values.
+
+ NOTES
+
+27
+ 4 The priority expression can include references to discriminants
+ of the enclosing type.
+
+28
+ 5 It is a consequence of the active priority rules that at the
+ point when a task stops inheriting a priority from another source,
+ its active priority is re-evaluated. This is in addition to other
+ instances described in this Annex for such re-evaluation.
+
+29/3
+ 6 {AI05-0248-1AI05-0248-1} An implementation may provide a
+ nonstandard mode in which tasks inherit priorities under conditions
+ other than those specified above.
+
+29.a/3
+ Ramification: {AI05-0229-1AI05-0229-1} The use of a Priority
+ or Interrupt_Priority aspect does not require the package
+ System to be named in a with_clause for the enclosing
+ compilation_unit.
+
+ _Extensions to Ada 83_
+
+29.b
+ The priority of a task is per-object and not per-type.
+
+29.c
+ Priorities need not be static anymore (except for the main
+ subprogram).
+
+ _Wording Changes from Ada 83_
+
+29.d
+ The description of the Priority pragma has been moved to this
+ annex.
+
+ _Wording Changes from Ada 95_
+
+29.e/2
+ {8652/00728652/0072} {AI95-00092-01AI95-00092-01} Corrigendum:
+ Clarified that dynamic priority changes are not transitive -
+ that is, they don't apply to tasks that are being activated by
+ or in rendezvous with the task that had its priority changed.
+
+29.f/2
+ {AI95-00357-01AI95-00357-01} Generalized the definition of
+ priority inheritance to take into account the differences
+ between the existing and new dispatching policies.
+
+ _Extensions to Ada 2005_
+
+29.g/3
+ {AI05-0229-1AI05-0229-1} Aspects Priority and
+ Interrupt_Priority are new; pragmas Priority and
+ Interrupt_Priority are now obsolescent.
+
+\1f
+File: aarm2012.info, Node: D.2, Next: D.3, Prev: D.1, Up: Annex D
+
+D.2 Priority Scheduling
+=======================
+
+1/3
+{AI95-00321-01AI95-00321-01} {AI05-0299-1AI05-0299-1} [This subclause
+describes the rules that determine which task is selected for execution
+when more than one task is ready (see *note 9::).]
+
+ _Wording Changes from Ada 95_
+
+1.a/3
+ {AI95-00321-01AI95-00321-01} {AI05-0299-1AI05-0299-1} This
+ introduction is simplified in order to reflect the
+ rearrangement and expansion of this subclause.
+
+* Menu:
+
+* D.2.1 :: The Task Dispatching Model
+* D.2.2 :: Task Dispatching Pragmas
+* D.2.3 :: Preemptive Dispatching
+* D.2.4 :: Non-Preemptive Dispatching
+* D.2.5 :: Round Robin Dispatching
+* D.2.6 :: Earliest Deadline First Dispatching
+
+\1f
+File: aarm2012.info, Node: D.2.1, Next: D.2.2, Up: D.2
+
+D.2.1 The Task Dispatching Model
+--------------------------------
+
+1/2
+{AI95-00321-01AI95-00321-01} [The task dispatching model specifies task
+scheduling, based on conceptual priority-ordered ready queues.]
+
+ _Static Semantics_
+
+1.1/2
+{AI95-00355-01AI95-00355-01} The following language-defined library
+package exists:
+
+1.2/3
+ {AI05-0166-1AI05-0166-1} package Ada.Dispatching is
+ pragma Preelaborate(Dispatching);
+
+1.3/3
+ {AI05-0166-1AI05-0166-1} procedure Yield;
+
+1.4/3
+ {AI05-0166-1AI05-0166-1} Dispatching_Policy_Error : exception;
+ end Ada.Dispatching;
+
+1.5/2
+Dispatching serves as the parent of other language-defined library units
+concerned with task dispatching.
+
+ _Dynamic Semantics_
+
+2/2
+{AI95-00321-01AI95-00321-01} A task can become a running task only if it
+is ready (see *note 9::) and the execution resources required by that
+task are available. Processors are allocated to tasks based on each
+task's active priority.
+
+3
+It is implementation defined whether, on a multiprocessor, a task that
+is waiting for access to a protected object keeps its processor busy.
+
+3.a
+ Implementation defined: Whether, on a multiprocessor, a task
+ that is waiting for access to a protected object keeps its
+ processor busy.
+
+4/2
+{AI95-00321-01AI95-00321-01} Task dispatching is the process by which
+one ready task is selected for execution on a processor. This selection
+is done at certain points during the execution of a task called task
+dispatching points. A task reaches a task dispatching point whenever it
+becomes blocked, and when it terminates. [Other task dispatching points
+are defined throughout this Annex for specific policies.]
+
+4.a
+ Ramification: On multiprocessor systems, more than one task
+ can be chosen, at the same time, for execution on more than
+ one processor, as explained below.
+
+5/2
+{AI95-00321-01AI95-00321-01} Task dispatching policies are specified in
+terms of conceptual ready queues and task states. A ready queue is an
+ordered list of ready tasks. The first position in a queue is called
+the head of the queue, and the last position is called the tail of the
+queue. A task is ready if it is in a ready queue, or if it is running.
+Each processor has one ready queue for each priority value. At any
+instant, each ready queue of a processor contains exactly the set of
+tasks of that priority that are ready for execution on that processor,
+but are not running on any processor; that is, those tasks that are
+ready, are not running on any processor, and can be executed using that
+processor and other available resources. A task can be on the ready
+queues of more than one processor.
+
+5.a
+ Discussion: The core language defines a ready task as one that
+ is not blocked. Here we refine this definition and talk about
+ ready queues.
+
+6/2
+{AI95-00321-01AI95-00321-01} Each processor also has one running task,
+which is the task currently being executed by that processor. Whenever
+a task running on a processor reaches a task dispatching point it goes
+back to one or more ready queues; a task (possibly the same task) is
+then selected to run on that processor. The task selected is the one at
+the head of the highest priority nonempty ready queue; this task is then
+removed from all ready queues to which it belongs.
+
+6.a
+ Discussion: There is always at least one task to run, if we
+ count the idle task.
+
+7/3
+{AI95-00321-01AI95-00321-01} {AI05-0166-1AI05-0166-1} A call of Yield is
+a task dispatching point. Yield is a potentially blocking operation
+(see *note 9.5.1::).
+
+7.a/2
+ This paragraph was deleted.
+
+8/2
+This paragraph was deleted.{AI95-00321-01AI95-00321-01}
+
+8.a/2
+ This paragraph was deleted.
+
+ _Implementation Permissions_
+
+9/2
+{AI95-00321-01AI95-00321-01} An implementation is allowed to define
+additional resources as execution resources, and to define the
+corresponding allocation policies for them. Such resources may have an
+implementation-defined effect on task dispatching.
+
+9.a/2
+ Implementation defined: The effect of implementation-defined
+ execution resources on task dispatching.
+
+10
+An implementation may place implementation-defined restrictions on tasks
+whose active priority is in the Interrupt_Priority range.
+
+10.a/3
+ Ramification: {AI05-0229-1AI05-0229-1} For example, on some
+ operating systems, it might be necessary to disallow them
+ altogether. This permission applies to tasks whose priority
+ is set to interrupt level for any reason: via an aspect, via a
+ call to Dynamic_Priorities.Set_Priority, or via priority
+ inheritance.
+
+10.1/2
+{AI95-00321-01AI95-00321-01} [For optimization purposes,] an
+implementation may alter the points at which task dispatching occurs, in
+an implementation-defined manner. However, a delay_statement always
+corresponds to at least one task dispatching point.
+
+ NOTES
+
+11/3
+ 7 {AI05-0299-1AI05-0299-1} Clause *note 9:: specifies under which
+ circumstances a task becomes ready. The ready state is affected by
+ the rules for task activation and termination, delay statements,
+ and entry calls. When a task is not ready, it is said to be
+ blocked.
+
+12
+ 8 An example of a possible implementation-defined execution
+ resource is a page of physical memory, which needs to be loaded
+ with a particular page of virtual memory before a task can continue
+ execution.
+
+13
+ 9 The ready queues are purely conceptual; there is no requirement
+ that such lists physically exist in an implementation.
+
+14
+ 10 While a task is running, it is not on any ready queue. Any
+ time the task that is running on a processor is added to a ready
+ queue, a new running task is selected for that processor.
+
+15
+ 11 In a multiprocessor system, a task can be on the ready queues
+ of more than one processor. At the extreme, if several processors
+ share the same set of ready tasks, the contents of their ready
+ queues is identical, and so they can be viewed as sharing one ready
+ queue, and can be implemented that way. [Thus, the dispatching
+ model covers multiprocessors where dispatching is implemented using
+ a single ready queue, as well as those with separate dispatching
+ domains.]
+
+16
+ 12 The priority of a task is determined by rules specified in this
+ subclause, and under *note D.1::, "*note D.1:: Task Priorities",
+ *note D.3::, "*note D.3:: Priority Ceiling Locking", and *note
+ D.5::, "*note D.5:: Dynamic Priorities".
+
+17/2
+ 13 {AI95-00321-01AI95-00321-01} The setting of a task's base
+ priority as a result of a call to Set_Priority does not always take
+ effect immediately when Set_Priority is called. The effect of
+ setting the task's base priority is deferred while the affected
+ task performs a protected action.
+
+ _Wording Changes from Ada 95_
+
+17.a/3
+ {AI95-00321-01AI95-00321-01} {AI05-0005-1AI05-0005-1} This
+ description is simplified to describe only the parts of the
+ dispatching model common to all policies. In particular,
+ rules about preemption are moved elsewhere. This makes it
+ easier to add other policies (which might not involve
+ preemption).
+
+ _Incompatibilities With Ada 2005_
+
+17.b/3
+ {AI05-0166-1AI05-0166-1} Procedure Yield is added to
+ Dispatching. If Dispatching is referenced in a use_clause,
+ and an entity E with a defining_identifier of Yield is defined
+ in a package that is also referenced in a use_clause, the
+ entity E may no longer be use-visible, resulting in errors.
+ This should be rare and is easily fixed if it does occur.
+
+\1f
+File: aarm2012.info, Node: D.2.2, Next: D.2.3, Prev: D.2.1, Up: D.2
+
+D.2.2 Task Dispatching Pragmas
+------------------------------
+
+1/3
+{AI95-00355-01AI95-00355-01} {AI05-0299-1AI05-0299-1} [This subclause
+allows a single task dispatching policy to be defined for all
+priorities, or the range of priorities to be split into subranges that
+are assigned individual dispatching policies.]
+
+ _Syntax_
+
+2
+ The form of a pragma Task_Dispatching_Policy is as follows:
+
+3
+ pragma Task_Dispatching_Policy(policy_identifier);
+
+3.1/2
+ {AI95-00355-01AI95-00355-01} The form of a pragma
+ Priority_Specific_Dispatching is as follows:
+
+3.2/2
+ pragma Priority_Specific_Dispatching (
+ policy_identifier, first_priority_expression, last_priority_
+ expression);
+
+ _Name Resolution Rules_
+
+3.3/2
+{AI95-00355-01AI95-00355-01} The expected type for
+first_priority_expression and last_priority_expression is Integer.
+
+ _Legality Rules_
+
+4/2
+{AI95-00321-01AI95-00321-01} {AI95-00355-01AI95-00355-01} The
+policy_identifier used in a pragma Task_Dispatching_Policy shall be the
+name of a task dispatching policy.
+
+4.a/2
+ This paragraph was deleted.
+
+4.1/2
+{AI95-00355-01AI95-00355-01} The policy_identifier used in a pragma
+Priority_Specific_Dispatching shall be the name of a task dispatching
+policy.
+
+4.2/2
+{AI95-00355-01AI95-00355-01} Both first_priority_expression and
+last_priority_expression shall be static expressions in the range of
+System.Any_Priority; last_priority_expression shall have a value greater
+than or equal to first_priority_expression.
+
+ _Static Semantics_
+
+4.3/2
+{AI95-00355-01AI95-00355-01} Pragma Task_Dispatching_Policy specifies
+the single task dispatching policy.
+
+4.4/2
+{AI95-00355-01AI95-00355-01} Pragma Priority_Specific_Dispatching
+specifies the task dispatching policy for the specified range of
+priorities. Tasks with base priorities within the range of priorities
+specified in a Priority_Specific_Dispatching pragma have their active
+priorities determined according to the specified dispatching policy.
+Tasks with active priorities within the range of priorities specified in
+a Priority_Specific_Dispatching pragma are dispatched according to the
+specified dispatching policy.
+
+4.b/2
+ Reason: {AI95-00355-01AI95-00355-01} Each ready queue is
+ managed by exactly one policy. Anything else would be chaos.
+ The ready queue is determined by the active priority.
+ However, how the active priority is calculated is determined
+ by the policy; in order to break out of this circle, we have
+ to say that the active priority is calculated by the method
+ determined by the policy of the base priority.
+
+4.5/3
+{AI95-00355-01AI95-00355-01} {AI05-0262-1AI05-0262-1} If a partition
+contains one or more Priority_Specific_Dispatching pragmas, the
+dispatching policy for priorities not covered by any
+Priority_Specific_Dispatching pragmas is FIFO_Within_Priorities.
+
+ _Post-Compilation Rules_
+
+5/2
+{AI95-00355-01AI95-00355-01} A Task_Dispatching_Policy pragma is a
+configuration pragma. A Priority_Specific_Dispatching pragma is a
+configuration pragma.
+
+5.1/2
+{AI95-00355-01AI95-00355-01} The priority ranges specified in more than
+one Priority_Specific_Dispatching pragma within the same partition shall
+not be overlapping.
+
+5.2/2
+{AI95-00355-01AI95-00355-01} If a partition contains one or more
+Priority_Specific_Dispatching pragmas it shall not contain a
+Task_Dispatching_Policy pragma.
+
+6/2
+This paragraph was deleted.{AI95-00333-01AI95-00333-01}
+
+ _Dynamic Semantics_
+
+7/2
+{AI95-00355-01AI95-00355-01} [A task dispatching policy specifies the
+details of task dispatching that are not covered by the basic task
+dispatching model. These rules govern when tasks are inserted into and
+deleted from the ready queues.] A single task dispatching policy is
+specified by a Task_Dispatching_Policy pragma. Pragma
+Priority_Specific_Dispatching assigns distinct dispatching policies to
+subranges of System.Any_Priority.
+
+7.1/2
+{AI95-00355-01AI95-00355-01} If neither pragma applies to any of the
+program units comprising a partition, the task dispatching policy for
+that partition is unspecified.
+
+7.2/3
+{AI95-00355-01AI95-00355-01} {AI05-0262-1AI05-0262-1} If a partition
+contains one or more Priority_Specific_Dispatching pragmas, a task
+dispatching point occurs for the currently running task of a processor
+whenever there is a nonempty ready queue for that processor with a
+higher priority than the priority of the running task.
+
+7.a/3
+ Discussion: {AI05-0005-1AI05-0005-1} If we have priority
+ specific dispatching then we want preemption across the entire
+ range of priorities. That prevents higher priority tasks from
+ being blocked by lower priority tasks that have a different
+ policy. On the other hand, if we have a single policy for the
+ entire partition, we want the characteristics of that policy
+ to apply for preemption; specifically, we might not require
+ any preemption. Note that policy
+ Non_Preemptive_FIFO_Within_Priorities is not allowed in a
+ priority specific dispatching pragma.
+
+7.3/2
+{AI95-00355-01AI95-00355-01} A task that has its base priority changed
+may move from one dispatching policy to another. It is immediately
+subject to the new dispatching policy.
+
+7.b/2
+ Ramification: Once subject to the new dispatching policy, it
+ may be immediately preempted or dispatched, according the
+ rules of the new policy.
+
+Paragraphs 7 through 13 were moved to D.2.3.
+
+ _Implementation Requirements_
+
+14.1/2
+{AI95-00333-01AI95-00333-01} {AI95-00355-01AI95-00355-01} An
+implementation shall allow, for a single partition, both the locking
+policy (see *note D.3::) to be specified as Ceiling_Locking and also one
+or more Priority_Specific_Dispatching pragmas to be given.
+
+ _Documentation Requirements_
+
+Paragraphs 14 through 16 were moved to D.2.3.
+
+17.a/2
+ This paragraph was deleted.
+
+ _Implementation Permissions_
+
+18/2
+{AI95-00256-01AI95-00256-01} Implementations are allowed to define other
+task dispatching policies, but need not support more than one task
+dispatching policy per partition.
+
+19/2
+{AI95-00355-01AI95-00355-01} An implementation need not support pragma
+Priority_Specific_Dispatching if it is infeasible to support it in the
+target environment.
+
+19.a/2
+ Implementation defined: Implementation defined task
+ dispatching policies.
+
+ NOTES
+
+ Paragraphs 19 through 21 were deleted.
+
+ _Extensions to Ada 95_
+
+22.a/2
+ {AI95-00333-01AI95-00333-01} Amendment Correction: It is no
+ longer required to specify Ceiling_Locking with the
+ language-defined task dispatching policies; we only require
+ that implementations allow them to be used together.
+
+22.b/3
+ {AI95-00355-01AI95-00355-01} {AI05-0005-1AI05-0005-1} Pragma
+ Priority_Specific_Dispatching is new; it allows the
+ specification of different policies for different priorities.
+
+ _Wording Changes from Ada 95_
+
+22.c/2
+ {AI95-00256-01AI95-00256-01} Clarified that an implementation
+ need support only one task dispatching policy (of any kind,
+ language-defined or otherwise) per partition.
+
+22.d/3
+ {AI95-00321-01AI95-00321-01} {AI05-0005-1AI05-0005-1} This
+ description is simplified to describe only the rules for the
+ Task_Dispatching_Policy pragma that are common to all
+ policies. In particular, rules about preemption are moved
+ elsewhere. This makes it easier to add other policies (which
+ might not involve preemption).
+
+\1f
+File: aarm2012.info, Node: D.2.3, Next: D.2.4, Prev: D.2.2, Up: D.2
+
+D.2.3 Preemptive Dispatching
+----------------------------
+
+1/3
+{AI95-00321-01AI95-00321-01} {AI05-0299-1AI05-0299-1} [This subclause
+defines a preemptive task dispatching policy.]
+
+ _Static Semantics_
+
+2/2
+{AI95-00355-01AI95-00355-01} The policy_identifier
+FIFO_Within_Priorities is a task dispatching policy.
+
+ _Dynamic Semantics_
+
+3/2
+{AI95-00321-01AI95-00321-01} When FIFO_Within_Priorities is in effect,
+modifications to the ready queues occur only as follows:
+
+4/2
+ * {AI95-00321-01AI95-00321-01} When a blocked task becomes ready, it
+ is added at the tail of the ready queue for its active priority.
+
+5/2
+ * When the active priority of a ready task that is not running
+ changes, or the setting of its base priority takes effect, the task
+ is removed from the ready queue for its old active priority and is
+ added at the tail of the ready queue for its new active priority,
+ except in the case where the active priority is lowered due to the
+ loss of inherited priority, in which case the task is added at the
+ head of the ready queue for its new active priority.
+
+6/2
+ * When the setting of the base priority of a running task takes
+ effect, the task is added to the tail of the ready queue for its
+ active priority.
+
+7/2
+ * When a task executes a delay_statement that does not result in
+ blocking, it is added to the tail of the ready queue for its active
+ priority.
+
+7.a/2
+ Ramification: If the delay does result in blocking, the task
+ moves to the "delay queue", not to the ready queue.
+
+8/2
+{AI95-00321-01AI95-00321-01} Each of the events specified above is a
+task dispatching point (see *note D.2.1::).
+
+9/2
+{AI95-00321-01AI95-00321-01} A task dispatching point occurs for the
+currently running task of a processor whenever there is a nonempty ready
+queue for that processor with a higher priority than the priority of the
+running task. The currently running task is said to be preempted and it
+is added at the head of the ready queue for its active priority.
+
+ _Implementation Requirements_
+
+10/2
+{AI95-00333-01AI95-00333-01} An implementation shall allow, for a single
+partition, both the task dispatching policy to be specified as
+FIFO_Within_Priorities and also the locking policy (see *note D.3::) to
+be specified as Ceiling_Locking.
+
+10.a/2
+ Reason: This is the preferred combination of the
+ FIFO_Within_Priorities policy with a locking policy, and we
+ want that combination to be portable.
+
+ _Documentation Requirements_
+
+11/2
+{AI95-00321-01AI95-00321-01} Priority inversion is the duration for
+which a task remains at the head of the highest priority nonempty ready
+queue while the processor executes a lower priority task. The
+implementation shall document:
+
+12/2
+ * The maximum priority inversion a user task can experience due to
+ activity of the implementation (on behalf of lower priority tasks),
+ and
+
+12.a/2
+ Documentation Requirement: The maximum priority inversion a
+ user task can experience from the implementation.
+
+13/2
+ * whether execution of a task can be preempted by the implementation
+ processing of delay expirations for lower priority tasks, and if
+ so, for how long.
+
+13.a/2
+ Documentation Requirement: The amount of time that a task can
+ be preempted for processing on behalf of lower-priority tasks.
+
+ NOTES
+
+14/2
+ 14 {AI95-00321-01AI95-00321-01} If the active priority of a
+ running task is lowered due to loss of inherited priority (as it is
+ on completion of a protected operation) and there is a ready task
+ of the same active priority that is not running, the running task
+ continues to run (provided that there is no higher priority task).
+
+15/2
+ 15 {AI95-00321-01AI95-00321-01} Setting the base priority of a
+ ready task causes the task to move to the tail of the queue for its
+ active priority, regardless of whether the active priority of the
+ task actually changes.
+
+ _Wording Changes from Ada 95_
+
+15.a/2
+ {AI95-00321-01AI95-00321-01} This subclause is new; it mainly
+ consists of text that was found in *note D.2.1:: and *note
+ D.2.2:: in Ada 95. This was separated out so the definition
+ of additional policies was easier.
+
+15.b/2
+ {AI95-00333-01AI95-00333-01} We require that implementations
+ allow this policy and Ceiling_Locking together.
+
+15.c/2
+ {AI95-00355-01AI95-00355-01} We explicitly defined
+ FIFO_Within_Priorities to be a task dispatching policy.
+
+\1f
+File: aarm2012.info, Node: D.2.4, Next: D.2.5, Prev: D.2.3, Up: D.2
+
+D.2.4 Non-Preemptive Dispatching
+--------------------------------
+
+1/3
+{AI95-00298-01AI95-00298-01} {AI05-0299-1AI05-0299-1} [This subclause
+defines a non-preemptive task dispatching policy.]
+
+ _Static Semantics_
+
+2/2
+{AI95-00298-01AI95-00298-01} {AI95-00355-01AI95-00355-01} The
+policy_identifier Non_Preemptive_FIFO_Within_Priorities is a task
+dispatching policy.
+
+2.1/3
+{AI05-0166-1AI05-0166-1} The following language-defined library package
+exists:
+
+2.2/3
+ package Ada.Dispatching.Non_Preemptive is
+ pragma Preelaborate(Non_Preemptive);
+ procedure Yield_To_Higher;
+ procedure Yield_To_Same_Or_Higher renames Yield;
+ end Ada.Dispatching.Non_Preemptive;
+
+2.3/3
+{AI05-0166-1AI05-0166-1} {AI05-0264-1AI05-0264-1} A call of
+Yield_To_Higher is a task dispatching point for this policy. If the
+task at the head of the highest priority ready queue has a higher active
+priority than the calling task, then the calling task is preempted.
+
+2.a/3
+ Ramification: For language-defined policies other than
+ Non_Preemptive_FIFO_Within_Priorities, a higher priority task
+ should never be on a ready queue while a lower priority task
+ is executed. Thus, for such policies, Yield_To_Higher does
+ nothing.
+
+2.b/3
+ Yield_To_Higher is not a potentially blocking operation; it
+ can be used during a protected operation. That is allowed, as
+ under the predefined Ceiling_Locking policy any task with a
+ higher priority than the protected operation cannot call the
+ operation (that would violate the locking policy). An
+ implementation-defined locking policy may need to define the
+ semantics of Yield_To_Higher differently.
+
+ _Legality Rules_
+
+3/2
+{AI95-00355-01AI95-00355-01} Non_Preemptive_FIFO_Within_Priorities shall
+not be specified as the policy_identifier of pragma
+Priority_Specific_Dispatching (see *note D.2.2::).
+
+3.a/2
+ Reason: The non-preemptive nature of this policy could cause
+ the policies of higher priority tasks to malfunction, missing
+ deadlines and having unlimited priority inversion. That would
+ render the use of such policies impotent and misleading. As
+ such, this policy only makes sense for a complete system.
+
+ _Dynamic Semantics_
+
+4/2
+{AI95-00298-01AI95-00298-01} When Non_Preemptive_FIFO_Within_Priorities
+is in effect, modifications to the ready queues occur only as follows:
+
+5/2
+ * {AI95-00298-01AI95-00298-01} When a blocked task becomes ready, it
+ is added at the tail of the ready queue for its active priority.
+
+6/2
+ * When the active priority of a ready task that is not running
+ changes, or the setting of its base priority takes effect, the task
+ is removed from the ready queue for its old active priority and is
+ added at the tail of the ready queue for its new active priority.
+
+7/2
+ * When the setting of the base priority of a running task takes
+ effect, the task is added to the tail of the ready queue for its
+ active priority.
+
+8/2
+ * When a task executes a delay_statement that does not result in
+ blocking, it is added to the tail of the ready queue for its active
+ priority.
+
+8.a/2
+ Ramification: If the delay does result in blocking, the task
+ moves to the "delay queue", not to the ready queue.
+
+9/3
+{AI05-0166-1AI05-0166-1} For this policy, blocking or termination of a
+task, a delay_statement, a call to Yield_To_Higher, and a call to
+Yield_To_Same_Or_Higher or Yield are the only task dispatching points
+(see *note D.2.1::).
+
+9.a/3
+ Ramification: {AI05-0166-1AI05-0166-1} A delay_statement is
+ always a task dispatching point even if it is not blocking.
+ Similarly, a call to Yield_To_Higher is never blocking, but it
+ is a task dispatching point In each of these cases, they can
+ cause the current task to stop running (it is still ready).
+ Otherwise, the running task continues to run until it is
+ blocked.
+
+ _Implementation Requirements_
+
+10/2
+{AI95-00333-01AI95-00333-01} An implementation shall allow, for a single
+partition, both the task dispatching policy to be specified as
+Non_Preemptive_FIFO_Within_Priorities and also the locking policy (see
+*note D.3::) to be specified as Ceiling_Locking.
+
+10.a/2
+ Reason: This is the preferred combination of the
+ Non_Preemptive_FIFO_Within_Priorities policy with a locking
+ policy, and we want that combination to be portable.
+
+ _Implementation Permissions_
+
+11/3
+{AI95-00298-01AI95-00298-01} {AI05-0229-1AI05-0229-1}
+{AI05-0269-1AI05-0269-1} Since implementations are allowed to round all
+ceiling priorities in subrange System.Priority to System.Priority'Last
+(see *note D.3::), an implementation may allow a task of a partition
+using the Non_Premptive_FIFO_Within_Priorities policy to execute within
+a protected object without raising its active priority provided the
+associated protected unit does not contain any subprograms with aspects
+Interrupt_Handler or Attach_Handler specified, nor does the unit have
+aspect Interrupt_Priority specified. When the locking policy (see *note
+D.3::) is Ceiling_Locking, an implementation taking advantage of this
+permission shall ensure that a call to Yield_to_Higher that occurs
+within a protected action uses the ceiling priority of the protected
+object (rather than the active priority of the task) when determining
+whether to preempt the task.
+
+11.a.1/3
+ Reason: {AI05-0269-1AI05-0269-1} We explicitly require that
+ the ceiling priority be used in calls to Yield_to_Higher in
+ order to prevent a risk of priority inversion and consequent
+ loss of mutual exclusion when Yield_to_Higher is used in a
+ protected object. This requirement might lessen the value of
+ the permission (as the current Ceiling_Priority will have to
+ be maintained in the TCB), but loss of mutual exclusion cannot
+ be tolerated. The primary benefit of the permission
+ (eliminating the need for preemption at the end of a protected
+ action) is still available. As noted above, an
+ implementation-defined locking policy will need to specify the
+ semantics of Yield_to_Higher, including this case.
+
+ _Extensions to Ada 95_
+
+11.a/2
+ {AI95-00298-01AI95-00298-01} {AI95-00355-01AI95-00355-01}
+ Policy Non_Preemptive_FIFO_Within_Priorities is new.
+
+ _Extensions to Ada 2005_
+
+11.b/3
+ {AI05-0166-1AI05-0166-1} Package Dispatching.Non_Preemptive is
+ new.
+
+\1f
+File: aarm2012.info, Node: D.2.5, Next: D.2.6, Prev: D.2.4, Up: D.2
+
+D.2.5 Round Robin Dispatching
+-----------------------------
+
+1/3
+{AI95-00355-01AI95-00355-01} {AI05-0299-1AI05-0299-1} [This subclause
+defines the task dispatching policy Round_Robin_Within_Priorities and
+the package Round_Robin.]
+
+ _Static Semantics_
+
+2/2
+{AI95-00355-01AI95-00355-01} The policy_identifier
+Round_Robin_Within_Priorities is a task dispatching policy.
+
+3/2
+{AI95-00355-01AI95-00355-01} The following language-defined library
+package exists:
+
+4/2
+ with System;
+ with Ada.Real_Time;
+ package Ada.Dispatching.Round_Robin is
+ Default_Quantum : constant Ada.Real_Time.Time_Span :=
+ implementation-defined;
+ procedure Set_Quantum (Pri : in System.Priority;
+ Quantum : in Ada.Real_Time.Time_Span);
+ procedure Set_Quantum (Low, High : in System.Priority;
+ Quantum : in Ada.Real_Time.Time_Span);
+ function Actual_Quantum (Pri : System.Priority)
+ return Ada.Real_Time.Time_Span;
+ function Is_Round_Robin (Pri : System.Priority) return Boolean;
+ end Ada.Dispatching.Round_Robin;
+
+4.a.1/2
+ Implementation defined: The value of Default_Quantum in
+ Dispatching.Round_Robin.
+
+5/2
+{AI95-00355-01AI95-00355-01} When task dispatching policy
+Round_Robin_Within_Priorities is the single policy in effect for a
+partition, each task with priority in the range of
+System.Interrupt_Priority is dispatched according to policy
+FIFO_Within_Priorities.
+
+ _Dynamic Semantics_
+
+6/2
+{AI95-00355-01AI95-00355-01} The procedures Set_Quantum set the required
+Quantum value for a single priority level Pri or a range of priority
+levels Low .. High. If no quantum is set for a Round Robin priority
+level, Default_Quantum is used.
+
+7/2
+{AI95-00355-01AI95-00355-01} The function Actual_Quantum returns the
+actual quantum used by the implementation for the priority level Pri.
+
+8/3
+{AI95-00355-01AI95-00355-01} {AI05-0264-1AI05-0264-1} The function
+Is_Round_Robin returns True if priority Pri is covered by task
+dispatching policy Round_Robin_Within_Priorities; otherwise, it returns
+False.
+
+9/2
+{AI95-00355-01AI95-00355-01} A call of Actual_Quantum or Set_Quantum
+raises exception Dispatching.Dispatching_Policy_Error if a predefined
+policy other than Round_Robin_Within_Priorities applies to the specified
+priority or any of the priorities in the specified range.
+
+10/2
+{AI95-00355-01AI95-00355-01} For Round_Robin_Within_Priorities, the
+dispatching rules for FIFO_Within_Priorities apply with the following
+additional rules:
+
+11/2
+ * When a task is added or moved to the tail of the ready queue for
+ its base priority, it has an execution time budget equal to the
+ quantum for that priority level. This will also occur when a
+ blocked task becomes executable again.
+
+12/2
+ * When a task is preempted (by a higher priority task) and is added
+ to the head of the ready queue for its priority level, it retains
+ its remaining budget.
+
+13/2
+ * While a task is executing, its budget is decreased by the amount of
+ execution time it uses. The accuracy of this accounting is the
+ same as that for execution time clocks (see *note D.14::).
+
+13.a/2
+ Ramification: Note that this happens even when the task is
+ executing at a higher, inherited priority, and even if that
+ higher priority is dispatched by a different policy than round
+ robin.
+
+14/2
+ * When a task has exhausted its budget and is without an inherited
+ priority (and is not executing within a protected operation), it is
+ moved to the tail of the ready queue for its priority level. This
+ is a task dispatching point.
+
+14.a/2
+ Ramification: In this case, it will be given a budget as
+ described in the first bullet.
+
+14.b/2
+ The rules for FIFO_Within_Priority (to which these bullets are
+ added) say that a task that has its base priority set to a
+ Round Robin priority is moved to the tail of the ready queue
+ for its new priority level, and then will be given a budget as
+ described in the first bullet. That happens whether or not
+ the task's original base priority was a Round Robin priority.
+
+ _Implementation Requirements_
+
+15/2
+{AI95-00333-01AI95-00333-01} {AI95-00355-01AI95-00355-01} An
+implementation shall allow, for a single partition, both the task
+dispatching policy to be specified as Round_Robin_Within_Priorities and
+also the locking policy (see *note D.3::) to be specified as
+Ceiling_Locking.
+
+15.a/2
+ Reason: This is the preferred combination of the
+ Round_Robin_Within_Priorities policy with a locking policy,
+ and we want that combination to be portable.
+
+ _Documentation Requirements_
+
+16/2
+{AI95-00355-01AI95-00355-01} An implementation shall document the
+quantum values supported.
+
+16.a.1/2
+ Documentation Requirement: The quantum values supported for
+ round robin dispatching.
+
+17/2
+{AI95-00355-01AI95-00355-01} An implementation shall document the
+accuracy with which it detects the exhaustion of the budget of a task.
+
+17.a.1/2
+ Documentation Requirement: The accuracy of the detection of
+ the exhaustion of the budget of a task for round robin
+ dispatching.
+
+ NOTES
+
+18/2
+ 16 {AI95-00355-01AI95-00355-01} Due to implementation constraints,
+ the quantum value returned by Actual_Quantum might not be identical
+ to that set with Set_Quantum.
+
+19/2
+ 17 {AI95-00355-01AI95-00355-01} A task that executes continuously
+ with an inherited priority will not be subject to round robin
+ dispatching.
+
+ _Extensions to Ada 95_
+
+19.a/2
+ {AI95-00355-01AI95-00355-01} Policy
+ Round_Robin_Within_Priorities and package
+ Dispatching.Round_Robin are new.
+
+\1f
+File: aarm2012.info, Node: D.2.6, Prev: D.2.5, Up: D.2
+
+D.2.6 Earliest Deadline First Dispatching
+-----------------------------------------
+
+1/2
+{AI95-00357-01AI95-00357-01} The deadline of a task is an indication of
+the urgency of the task; it represents a point on an ideal physical time
+line. The deadline might affect how resources are allocated to the
+task.
+
+2/3
+{AI95-00357-01AI95-00357-01} {AI05-0229-1AI05-0229-1}
+{AI05-0299-1AI05-0299-1} This subclause defines a package for
+representing the deadline of a task and a dispatching policy that
+defines Earliest Deadline First (EDF) dispatching. An aspect is defined
+to assign an initial deadline to a task.
+
+2.a/3
+ Discussion: {AI05-0229-1AI05-0229-1} This aspect is the only
+ way of assigning an initial deadline to a task so that its
+ activation can be controlled by EDF scheduling. This is
+ similar to the way aspect Priority is used to give an initial
+ priority to a task.
+
+ _Language Design Principles_
+
+2.b/3
+ {AI95-00357-01AI95-00357-01} {AI05-0299-1AI05-0299-1} To
+ predict the behavior of a multi-tasking program it is
+ necessary to control access to the processor which is
+ preemptive, and shared objects which are usually
+ non-preemptive and embodied in protected objects. Two common
+ dispatching policies for the processor are fixed priority and
+ EDF. The most effective control over shared objects is via
+ preemption levels. With a pure priority scheme a single
+ notion of priority is used for processor dispatching and
+ preemption levels. With EDF and similar schemes priority is
+ used for preemption levels (only), with another measure used
+ for dispatching. T.P. Baker showed (Real-Time Systems, March
+ 1991, vol. 3, num. 1, Stack-Based Scheduling of Realtime
+ Processes) that for EDF a newly released task should only
+ preempt the currently running task if it has an earlier
+ deadline and a higher preemption level than any currently
+ "locked" protected object. The rules of this subclause
+ implement this scheme including the case where the newly
+ released task should execute before some existing tasks but
+ not preempt the currently executing task.
+
+Paragraphs 3 through 6 were moved to *note Annex J::, "*note Annex J::
+Obsolescent Features".
+
+ _Static Semantics_
+
+7/2
+{AI95-00357-01AI95-00357-01} The policy_identifier EDF_Across_Priorities
+is a task dispatching policy.
+
+8/2
+{AI95-00357-01AI95-00357-01} The following language-defined library
+package exists:
+
+9/2
+ with Ada.Real_Time;
+ with Ada.Task_Identification;
+ package Ada.Dispatching.EDF is
+ subtype Deadline is Ada.Real_Time.Time;
+ Default_Deadline : constant Deadline :=
+ Ada.Real_Time.Time_Last;
+ procedure Set_Deadline (D : in Deadline;
+ T : in Ada.Task_Identification.Task_Id :=
+ Ada.Task_Identification.Current_Task);
+ procedure Delay_Until_And_Set_Deadline (
+ Delay_Until_Time : in Ada.Real_Time.Time;
+ Deadline_Offset : in Ada.Real_Time.Time_Span);
+ function Get_Deadline (T : Ada.Task_Identification.Task_Id :=
+ Ada.Task_Identification.Current_Task) return Deadline;
+ end Ada.Dispatching.EDF;
+
+9.1/3
+{AI05-0229-1AI05-0229-1} For a task type (including the anonymous type
+of a single_task_declaration) or subprogram, the following
+language-defined representation aspect may be specified:
+
+9.2/3
+Relative_Deadline
+ The aspect Relative_Deadline is an expression, which
+ shall be of type Real_Time.Time_Span.
+
+9.a/3
+ Aspect Description for Relative_Deadline: Task parameter used
+ in Earliest Deadline First Dispatching.
+
+ _Legality Rules_
+
+9.3/3
+{AI05-0229-1AI05-0229-1} The Relative_Deadline aspect shall not be
+specified on a task interface type.
+
+ _Post-Compilation Rules_
+
+10/2
+{AI95-00357-01AI95-00357-01} If the EDF_Across_Priorities policy is
+specified for a partition, then the Ceiling_Locking policy (see *note
+D.3::) shall also be specified for the partition.
+
+11/2
+{AI95-00357-01AI95-00357-01} If the EDF_Across_Priorities policy appears
+in a Priority_Specific_Dispatching pragma (see *note D.2.2::) in a
+partition, then the Ceiling_Locking policy (see *note D.3::) shall also
+be specified for the partition.
+
+11.a/2
+ Reason: Unlike the other language-defined dispatching
+ policies, the semantic description of EDF_Across_Priorities
+ assumes Ceiling_Locking (and a ceiling priority) in order to
+ make the mapping between deadlines and priorities work. Thus,
+ we require both policies to be specified if EDF is used in the
+ partition.
+
+ _Dynamic Semantics_
+
+12/3
+{AI95-00357-01AI95-00357-01} {AI05-0229-1AI05-0229-1} The
+Relative_Deadline aspect has no effect if it is specified for a
+subprogram other than the main subprogram.
+
+13/3
+{AI95-00357-01AI95-00357-01} {AI05-0229-1AI05-0229-1} The initial
+absolute deadline of a task for which aspect Relative_Deadline is
+specified is the value of Real_Time.Clock + the expression that is the
+value of the aspect, where this entire expression, including the call of
+Real_Time.Clock, is evaluated between task creation and the start of its
+activation. If the aspect Relative_Deadline is not specified, then the
+initial absolute deadline of a task is the value of Default_Deadline.
+The environment task is also given an initial deadline by this rule,
+using the value of the Relative_Deadline aspect of the main subprogram
+(if any).
+
+13.a/2
+ Proof: The environment task is a normal task by *note 10.2::,
+ so of course this rule applies to it.
+
+14/2
+{AI95-00357-01AI95-00357-01} The procedure Set_Deadline changes the
+absolute deadline of the task to D. The function Get_Deadline returns
+the absolute deadline of the task.
+
+15/2
+{AI95-00357-01AI95-00357-01} The procedure Delay_Until_And_Set_Deadline
+delays the calling task until time Delay_Until_Time. When the task
+becomes runnable again it will have deadline Delay_Until_Time +
+Deadline_Offset.
+
+16/2
+{AI95-00357-01AI95-00357-01} On a system with a single processor, the
+setting of the deadline of a task to the new value occurs immediately at
+the first point that is outside the execution of a protected action. If
+the task is currently on a ready queue it is removed and re-entered on
+to the ready queue determined by the rules defined below.
+
+17/2
+{AI95-00357-01AI95-00357-01} When EDF_Across_Priorities is specified for
+priority range Low..High all ready queues in this range are ordered by
+deadline. The task at the head of a queue is the one with the earliest
+deadline.
+
+18/2
+{AI95-00357-01AI95-00357-01} A task dispatching point occurs for the
+currently running task T to which policy EDF_Across_Priorities applies:
+
+19/2
+ * when a change to the deadline of T occurs;
+
+20/2
+ * there is a task on the ready queue for the active priority of T
+ with a deadline earlier than the deadline of T; or
+
+21/2
+ * there is a nonempty ready queue for that processor with a higher
+ priority than the active priority of the running task.
+
+22/2
+In these cases, the currently running task is said to be preempted and
+is returned to the ready queue for its active priority.
+
+23/2
+{AI95-00357-01AI95-00357-01} For a task T to which policy
+EDF_Across_Priorities applies, the base priority is not a source of
+priority inheritance; the active priority when first activated or while
+it is blocked is defined as the maximum of the following:
+
+24/2
+ * the lowest priority in the range specified as EDF_Across_Priorities
+ that includes the base priority of T;
+
+25/2
+ * the priorities, if any, currently inherited by T;
+
+26/3
+ * {AI05-0055-1AI05-0055-1} the highest priority P, if any, less than
+ the base priority of T such that one or more tasks are executing
+ within a protected object with ceiling priority P and task T has an
+ earlier deadline than all such tasks; and furthermore T has an
+ earlier deadline than all other tasks on ready queues with
+ priorities in the given EDF_Across_Priorities range that are
+ strictly less than P.
+
+26.a/2
+ Ramification: The active priority of T might be lower than its
+ base priority.
+
+27/2
+{AI95-00357-01AI95-00357-01} When a task T is first activated or becomes
+unblocked, it is added to the ready queue corresponding to this active
+priority. Until it becomes blocked again, the active priority of T
+remains no less than this value; it will exceed this value only while it
+is inheriting a higher priority.
+
+27.a/2
+ Discussion: These rules ensure that a task executing in a
+ protected object is preempted only by a task with a shorter
+ deadline and a higher base priority. This matches the
+ traditional preemption level description without the need to
+ define a new kind of protected object locking.
+
+28/2
+{AI95-00357-01AI95-00357-01} When the setting of the base priority of a
+ready task takes effect and the new priority is in a range specified as
+EDF_Across_Priorities, the task is added to the ready queue
+corresponding to its new active priority, as determined above.
+
+29/2
+{AI95-00357-01AI95-00357-01} For all the operations defined in
+Dispatching.EDF, Tasking_Error is raised if the task identified by T has
+terminated. Program_Error is raised if the value of T is Null_Task_Id.
+
+ _Bounded (Run-Time) Errors_
+
+30/2
+{AI95-00357-01AI95-00357-01} If EDF_Across_Priorities is specified for
+priority range Low..High, it is a bounded error to declare a protected
+object with ceiling priority Low or to assign the value Low to attribute
+'Priority. In either case either Program_Error is raised or the ceiling
+of the protected object is assigned the value Low+1.
+
+ _Erroneous Execution_
+
+31/2
+{AI95-00357-01AI95-00357-01} If a value of Task_Id is passed as a
+parameter to any of the subprograms of this package and the
+corresponding task object no longer exists, the execution of the program
+is erroneous.
+
+ _Documentation Requirements_
+
+32/2
+{AI95-00357-01AI95-00357-01} On a multiprocessor, the implementation
+shall document any conditions that cause the completion of the setting
+of the deadline of a task to be delayed later than what is specified for
+a single processor.
+
+32.a.1/2
+ Documentation Requirement: Any conditions that cause the
+ completion of the setting of the deadline of a task to be
+ delayed for a multiprocessor.
+
+ NOTES
+
+33/3
+ 18 {AI95-00357-01AI95-00357-01} {AI05-0264-1AI05-0264-1} If two
+ adjacent priority ranges, A..B and B+1..C are specified to have
+ policy EDF_Across_Priorities, then this is not equivalent to this
+ policy being specified for the single range, A..C.
+
+34/2
+ 19 {AI95-00357-01AI95-00357-01} The above rules implement the
+ preemption-level protocol (also called Stack Resource Policy
+ protocol) for resource sharing under EDF dispatching. The
+ preemption-level for a task is denoted by its base priority. The
+ definition of a ceiling preemption-level for a protected object
+ follows the existing rules for ceiling locking.
+
+34.a/2
+ Implementation Note: {AI95-00357-01AI95-00357-01} An
+ implementation may support additional dispatching policies by
+ replacing absolute deadline with an alternative measure of
+ urgency.
+
+ _Extensions to Ada 95_
+
+34.b/2
+ {AI95-00357-01AI95-00357-01} Policy EDF_Across_Priorities and
+ package Dispatching.EDF are new.
+
+ _Extensions to Ada 2005_
+
+34.c/3
+ {AI05-0229-1AI05-0229-1} Aspect Relative_Deadline is new;
+ pragma Relative_Deadline is now obsolescent.
+
+ _Wording Changes from Ada 2005_
+
+34.d/3
+ {AI05-0055-1AI05-0055-1} Correction: Corrected definition of
+ active priority to avoid deadline inversion in an unusual
+ case.
+
+\1f
+File: aarm2012.info, Node: D.3, Next: D.4, Prev: D.2, Up: Annex D
+
+D.3 Priority Ceiling Locking
+============================
+
+1/3
+{AI05-0299-1AI05-0299-1} [This subclause specifies the interactions
+between priority task scheduling and protected object ceilings. This
+interaction is based on the concept of the ceiling priority of a
+protected object.]
+
+ _Syntax_
+
+2
+ The form of a pragma Locking_Policy is as follows:
+
+3
+ pragma Locking_Policy(policy_identifier);
+
+ _Legality Rules_
+
+4
+The policy_identifier shall either be Ceiling_Locking or an
+implementation-defined identifier.
+
+4.a
+ Implementation defined: Implementation-defined policy_
+ identifiers allowed in a pragma Locking_Policy.
+
+ _Post-Compilation Rules_
+
+5
+A Locking_Policy pragma is a configuration pragma.
+
+ _Dynamic Semantics_
+
+6/2
+{8652/00738652/0073} {AI95-00091-01AI95-00091-01}
+{AI95-00327-01AI95-00327-01} [A locking policy specifies the details of
+protected object locking. All protected objects have a priority. The
+locking policy specifies the meaning of the priority of a protected
+object, and the relationships between these priorities and task
+priorities. In addition, the policy specifies the state of a task when
+it executes a protected action, and how its active priority is affected
+by the locking.] The locking policy is specified by a Locking_Policy
+pragma. For implementation-defined locking policies, the meaning of the
+priority of a protected object is implementation defined. If no
+Locking_Policy pragma applies to any of the program units comprising a
+partition, the locking policy for that partition, as well as the meaning
+of the priority of a protected object, are implementation defined.
+
+6.a/2
+ Implementation defined: The locking policy if no
+ Locking_Policy pragma applies to any unit of a partition.
+
+6.1/3
+{AI95-00327-01AI95-00327-01} {AI05-0229-1AI05-0229-1} The expression
+specified for the Priority or Interrupt_Priority aspect (see *note
+D.1::) is evaluated as part of the creation of the corresponding
+protected object and converted to the subtype System.Any_Priority or
+System.Interrupt_Priority, respectively. The value of the expression is
+the initial priority of the corresponding protected object. If no
+Priority or Interrupt_Priority aspect is specified for a protected
+object, the initial priority is specified by the locking policy.
+
+7
+There is one predefined locking policy, Ceiling_Locking; this policy is
+defined as follows:
+
+8/3
+ * {AI95-00327-01AI95-00327-01} {AI05-0229-1AI05-0229-1} Every
+ protected object has a ceiling priority, which is determined by
+ either a Priority or Interrupt_Priority aspect as defined in *note
+ D.1::, or by assignment to the Priority attribute as described in
+ *note D.5.2::. The ceiling priority of a protected object (or
+ ceiling, for short) is an upper bound on the active priority a task
+ can have when it calls protected operations of that protected
+ object.
+
+9/2
+ * {AI95-00327-01AI95-00327-01} The initial ceiling priority of a
+ protected object is equal to the initial priority for that object.
+
+10/3
+ * {AI95-00327-01AI95-00327-01} {AI05-0229-1AI05-0229-1} If an
+ Interrupt_Handler or Attach_Handler aspect (see *note C.3.1::) is
+ specified for a protected subprogram of a protected type that does
+ not have the Interrupt_Priority aspect specified, the initial
+ priority of protected objects of that type is implementation
+ defined, but in the range of the subtype System.Interrupt_Priority.
+
+10.a
+ Implementation defined: Default ceiling priorities.
+
+11/3
+ * {AI95-00327-01AI95-00327-01} {AI05-0229-1AI05-0229-1} If neither
+ aspect Priority nor Interrupt_Priority is specified for a protected
+ type, and no protected subprogram of the type has aspect
+ Interrupt_Handler or Attach_Handler specified, then the initial
+ priority of the corresponding protected object is
+ System.Priority'Last.
+
+12
+ * While a task executes a protected action, it inherits the ceiling
+ priority of the corresponding protected object.
+
+13
+ * When a task calls a protected operation, a check is made that its
+ active priority is not higher than the ceiling of the corresponding
+ protected object; Program_Error is raised if this check fails.
+
+ _Bounded (Run-Time) Errors_
+
+13.1/2
+{AI95-00327-01AI95-00327-01} Following any change of priority, it is a
+bounded error for the active priority of any task with a call queued on
+an entry of a protected object to be higher than the ceiling priority of
+the protected object. In this case one of the following applies:
+
+13.2/2
+ * at any time prior to executing the entry body Program_Error is
+ raised in the calling task;
+
+13.3/2
+ * when the entry is open the entry body is executed at the ceiling
+ priority of the protected object;
+
+13.4/2
+ * when the entry is open the entry body is executed at the ceiling
+ priority of the protected object and then Program_Error is raised
+ in the calling task; or
+
+13.5/2
+ * when the entry is open the entry body is executed at the ceiling
+ priority of the protected object that was in effect when the entry
+ call was queued.
+
+13.a.1/2
+ Ramification: Note that the error is "blamed" on the task that
+ did the entry call, not the task that changed the priority of
+ the task or protected object. This seems to make sense for
+ the case of changing the priority of a task blocked on a call,
+ since if the Set_Priority had happened a little bit sooner,
+ before the task queued a call, the entry-calling task would
+ get the error. Similarly, there is no reason not to raise the
+ priority of a task that is executing in an abortable_part, so
+ long as its priority is lowered before it gets to the end and
+ needs to cancel the call. The priority might need to be
+ lowered to allow it to remove the call from the entry queue,
+ in order to avoid violating the ceiling. This seems
+ relatively harmless, since there is an error, and the task is
+ about to start raising an exception anyway.
+
+ _Implementation Permissions_
+
+14
+The implementation is allowed to round all ceilings in a certain
+subrange of System.Priority or System.Interrupt_Priority up to the top
+of that subrange, uniformly.
+
+14.a
+ Discussion: For example, an implementation might use
+ Priority'Last for all ceilings in Priority, and
+ Interrupt_Priority'Last for all ceilings in
+ Interrupt_Priority. This would be equivalent to having two
+ ceiling priorities for protected objects, "nonpreemptible" and
+ "noninterruptible", and is an allowed behavior.
+
+14.b
+ Note that the implementation cannot choose a subrange that
+ crosses the boundary between normal and interrupt priorities.
+
+15/2
+{AI95-00256-01AI95-00256-01} Implementations are allowed to define other
+locking policies, but need not support more than one locking policy per
+partition.
+
+16
+[Since implementations are allowed to place restrictions on code that
+runs at an interrupt-level active priority (see *note C.3.1:: and *note
+D.2.1::), the implementation may implement a language feature in terms
+of a protected object with an implementation-defined ceiling, but the
+ceiling shall be no less than Priority'Last.]
+
+16.a
+ Implementation defined: The ceiling of any protected object
+ used internally by the implementation.
+
+16.b
+ Proof: This permission follows from the fact that the
+ implementation can place restrictions on interrupt handlers
+ and on any other code that runs at an interrupt-level active
+ priority.
+
+16.c
+ The implementation might protect a storage pool with a
+ protected object whose ceiling is Priority'Last, which would
+ cause allocators to fail when evaluated at interrupt priority.
+ Note that the ceiling of such an object has to be at least
+ Priority'Last, since there is no permission for allocators to
+ fail when evaluated at a noninterrupt priority.
+
+ _Implementation Advice_
+
+17
+The implementation should use names that end with "_Locking" for
+implementation-defined locking policies.
+
+17.a/2
+ Implementation Advice: Names that end with "_Locking" should
+ be used for implementation-defined locking policies.
+
+ NOTES
+
+18
+ 20 While a task executes in a protected action, it can be
+ preempted only by tasks whose active priorities are higher than the
+ ceiling priority of the protected object.
+
+19
+ 21 If a protected object has a ceiling priority in the range of
+ Interrupt_Priority, certain interrupts are blocked while protected
+ actions of that object execute. In the extreme, if the ceiling is
+ Interrupt_Priority'Last, all blockable interrupts are blocked
+ during that time.
+
+20
+ 22 The ceiling priority of a protected object has to be in the
+ Interrupt_Priority range if one of its procedures is to be used as
+ an interrupt handler (see *note C.3::).
+
+21
+ 23 When specifying the ceiling of a protected object, one should
+ choose a value that is at least as high as the highest active
+ priority at which tasks can be executing when they call protected
+ operations of that object. In determining this value the following
+ factors, which can affect active priority, should be considered:
+ the effect of Set_Priority, nested protected operations, entry
+ calls, task activation, and other implementation-defined factors.
+
+22
+ 24 Attaching a protected procedure whose ceiling is below the
+ interrupt hardware priority to an interrupt causes the execution of
+ the program to be erroneous (see *note C.3.1::).
+
+23
+ 25 On a single processor implementation, the ceiling priority
+ rules guarantee that there is no possibility of deadlock involving
+ only protected subprograms (excluding the case where a protected
+ operation calls another protected operation on the same protected
+ object).
+
+ _Extensions to Ada 95_
+
+23.a/2
+ {AI95-00327-01AI95-00327-01} All protected objects now have a
+ priority, which is the value of the Priority attribute of
+ *note D.5.2::. How this value is interpreted depends on the
+ locking policy; for instance, the ceiling priority is derived
+ from this value when the locking policy is Ceiling_Locking.
+
+ _Wording Changes from Ada 95_
+
+23.b/2
+ {8652/00738652/0073} {AI95-00091-01AI95-00091-01} Corrigendum:
+ Corrected the wording to reflect that pragma Locking_Policy
+ cannot be inside of a program unit.
+
+23.c/2
+ {AI95-00256-01AI95-00256-01} Clarified that an implementation
+ need support only one locking policy (of any kind,
+ language-defined or otherwise) per partition.
+
+23.d/2
+ {AI95-00327-01AI95-00327-01} The bounded error for the
+ priority of a task being higher than the ceiling of an object
+ it is currently in was moved here from *note D.5::, so that it
+ applies no matter how the situation arises.
+
+ _Wording Changes from Ada 2005_
+
+23.e/3
+ {AI05-0229-1AI05-0229-1} Revised to use aspects Priority and
+ Interrupt_Priority as pragmas Priority and Interrupt_Priority
+ are now obsolescent.
+
+\1f
+File: aarm2012.info, Node: D.4, Next: D.5, Prev: D.3, Up: Annex D
+
+D.4 Entry Queuing Policies
+==========================
+
+1/3
+{8652/00748652/0074} {AI95-00068-01AI95-00068-01}
+{AI05-0299-1AI05-0299-1} [ This subclause specifies a mechanism for a
+user to choose an entry queuing policy. It also defines two such
+policies. Other policies are implementation defined.]
+
+1.a
+ Implementation defined: Implementation-defined queuing
+ policies.
+
+ _Syntax_
+
+2
+ The form of a pragma Queuing_Policy is as follows:
+
+3
+ pragma Queuing_Policy(policy_identifier);
+
+ _Legality Rules_
+
+4
+The policy_identifier shall be either FIFO_Queuing, Priority_Queuing or
+an implementation-defined identifier.
+
+ _Post-Compilation Rules_
+
+5
+A Queuing_Policy pragma is a configuration pragma.
+
+ _Dynamic Semantics_
+
+6
+[A queuing policy governs the order in which tasks are queued for entry
+service, and the order in which different entry queues are considered
+for service.] The queuing policy is specified by a Queuing_Policy
+pragma.
+
+6.a
+ Ramification: The queuing policy includes entry queuing order,
+ the choice among open alternatives of a selective_accept, and
+ the choice among queued entry calls of a protected object when
+ more than one entry_barrier condition is True.
+
+7/2
+{AI95-00355-01AI95-00355-01} Two queuing policies, FIFO_Queuing and
+Priority_Queuing, are language defined. If no Queuing_Policy pragma
+applies to any of the program units comprising the partition, the
+queuing policy for that partition is FIFO_Queuing. The rules for this
+policy are specified in *note 9.5.3:: and *note 9.7.1::.
+
+8
+The Priority_Queuing policy is defined as follows:
+
+9
+ * The calls to an entry [(including a member of an entry family)] are
+ queued in an order consistent with the priorities of the calls.
+ The priority of an entry call is initialized from the active
+ priority of the calling task at the time the call is made, but can
+ change later. Within the same priority, the order is consistent
+ with the calling (or requeuing, or priority setting) time (that is,
+ a FIFO order).
+
+10/1
+ * {8652/00758652/0075} {AI95-00205-01AI95-00205-01} After a call is
+ first queued, changes to the active priority of a task do not
+ affect the priority of the call, unless the base priority of the
+ task is set while the task is blocked on an entry call.
+
+11
+ * When the base priority of a task is set (see *note D.5::), if the
+ task is blocked on an entry call, and the call is queued, the
+ priority of the call is updated to the new active priority of the
+ calling task. This causes the call to be removed from and then
+ reinserted in the queue at the new active priority.
+
+11.a
+ Reason: A task is blocked on an entry call if the entry call
+ is simple, conditional, or timed. If the call came from the
+ triggering_statement of an asynchronous_select, or a requeue
+ thereof, then the task is not blocked on that call; such calls
+ do not have their priority updated. Thus, there can exist
+ many queued calls from a given task (caused by many nested
+ ATC's), but a task can be blocked on only one call at a time.
+
+11.b
+ A previous version of Ada 9X required queue reordering in the
+ asynchronous_select case as well. If the call corresponds to
+ a "synchronous" entry call, then the task is blocked while
+ queued, and it makes good sense to move it up in the queue if
+ its priority is raised.
+
+11.c
+ However, if the entry call is "asynchronous," that is, it is
+ due to an asynchronous_select whose triggering_statement is an
+ entry call, then the task is not waiting for this entry call,
+ so the placement of the entry call on the queue is irrelevant
+ to the rate at which the task proceeds.
+
+11.d
+ Furthermore, when an entry is used for asynchronous_selects,
+ it is almost certain to be a "broadcast" entry or have only
+ one caller at a time. For example, if the entry is used to
+ notify tasks of a mode switch, then all tasks on the entry
+ queue would be signaled when the mode changes. Similarly, if
+ it is indicating some interrupting event such as a control-C,
+ all tasks sensitive to the interrupt will want to be informed
+ that the event occurred. Hence, the order on such a queue is
+ essentially irrelevant.
+
+11.e
+ Given the above, it seems an unnecessary semantic and
+ implementation complexity to specify that asynchronous queued
+ calls are moved in response to dynamic priority changes.
+ Furthermore, it is somewhat inconsistent, since the call was
+ originally queued based on the active priority of the task,
+ but dynamic priority changes are changing the base priority of
+ the task, and only indirectly the active priority. We say
+ explicitly that asynchronous queued calls are not affected by
+ normal changes in active priority during the execution of an
+ abortable_part. Saying that, if a change in the base priority
+ affects the active priority, then we do want the calls
+ reordered, would be inconsistent. It would also require the
+ implementation to maintain a readily accessible list of all
+ queued calls which would not otherwise be necessary.
+
+11.f
+ Several rules were removed or simplified when we changed the
+ rules so that calls due to asynchronous_selects are never
+ moved due to intervening changes in active priority, be they
+ due to protected actions, some other priority inheritance, or
+ changes in the base priority.
+
+12
+ * When more than one condition of an entry_barrier of a protected
+ object becomes True, and more than one of the respective queues is
+ nonempty, the call with the highest priority is selected. If more
+ than one such call has the same priority, the call that is queued
+ on the entry whose declaration is first in textual order in the
+ protected_definition is selected. For members of the same entry
+ family, the one with the lower family index is selected.
+
+13
+ * If the expiration time of two or more open delay_alternatives is
+ the same and no other accept_alternatives are open, the
+ sequence_of_statements of the delay_alternative that is first in
+ textual order in the selective_accept is executed.
+
+14
+ * When more than one alternative of a selective_accept is open and
+ has queued calls, an alternative whose queue has the
+ highest-priority call at its head is selected. If two or more open
+ alternatives have equal-priority queued calls, then a call on the
+ entry in the accept_alternative that is first in textual order in
+ the selective_accept is selected.
+
+ _Implementation Permissions_
+
+15/2
+{AI95-00256-01AI95-00256-01} Implementations are allowed to define other
+queuing policies, but need not support more than one queuing policy per
+partition.
+
+15.a.1/2
+ Discussion: {8652/01168652/0116} {AI95-00069-01AI95-00069-01}
+ {AI95-00256-01AI95-00256-01} This rule is really redundant, as
+ *note 10.1.5:: allows an implementation to limit the use of
+ configuration pragmas to an empty environment. In that case,
+ there would be no way to have multiple policies in a
+ partition.
+
+15.1/2
+{AI95-00188-02AI95-00188-02} Implementations are allowed to defer the
+reordering of entry queues following a change of base priority of a task
+blocked on the entry call if it is not practical to reorder the queue
+immediately.
+
+15.a.2/2
+ Reason: Priority change is immediate, but the effect of the
+ change on entry queues can be deferred. That is necessary in
+ order to implement priority changes on top of a non-Ada
+ kernel.
+
+15.a.3/2
+ Discussion: The reordering should occur as soon as the blocked
+ task can itself perform the reinsertion into the entry queue.
+
+ _Implementation Advice_
+
+16
+The implementation should use names that end with "_Queuing" for
+implementation-defined queuing policies.
+
+16.a/2
+ Implementation Advice: Names that end with "_Queuing" should
+ be used for implementation-defined queuing policies.
+
+ _Wording Changes from Ada 95_
+
+16.b/2
+ {8652/00748652/0074} {AI95-00068-01AI95-00068-01} Corrigendum:
+ Corrected the number of queuing policies defined.
+
+16.c/2
+ {8652/00758652/0075} {AI95-00205-01AI95-00205-01} Corrigendum:
+ Corrected so that a call of Set_Priority in an abortable part
+ does not change the priority of the triggering entry call.
+
+16.d/2
+ {AI95-00188-02AI95-00188-02} Added a permission to defer queue
+ reordering when the base priority of a task is changed. This
+ is a counterpart to stronger requirements on the
+ implementation of priority change.
+
+16.e/2
+ {AI95-00256-01AI95-00256-01} Clarified that an implementation
+ need support only one queuing policy (of any kind,
+ language-defined or otherwise) per partition.
+
+16.f/2
+ {AI95-00355-01AI95-00355-01} Fixed wording to make clear that
+ pragma never appears inside of a unit; rather it "applies to"
+ the unit.
+
+\1f
+File: aarm2012.info, Node: D.5, Next: D.6, Prev: D.4, Up: Annex D
+
+D.5 Dynamic Priorities
+======================
+
+1/3
+{AI95-00327-01AI95-00327-01} {AI05-0299-1AI05-0299-1} [This subclause
+describes how the priority of an entity can be modified or queried at
+run time.]
+
+ _Wording Changes from Ada 95_
+
+1.a/3
+ {AI95-00327-01AI95-00327-01} {AI05-0299-1AI05-0299-1} This
+ subclause is turned into two subclauses. This subclause
+ introduction is new.
+
+* Menu:
+
+* D.5.1 :: Dynamic Priorities for Tasks
+* D.5.2 :: Dynamic Priorities for Protected Objects
+
+\1f
+File: aarm2012.info, Node: D.5.1, Next: D.5.2, Up: D.5
+
+D.5.1 Dynamic Priorities for Tasks
+----------------------------------
+
+1/3
+{AI05-0299-1AI05-0299-1} [This subclause describes how the base priority
+of a task can be modified or queried at run time.]
+
+ _Static Semantics_
+
+2
+The following language-defined library package exists:
+
+3/2
+ {AI95-00362-01AI95-00362-01} with System;
+ with Ada.Task_Identification; -- See *note C.7.1::
+ package Ada.Dynamic_Priorities is
+ pragma Preelaborate(Dynamic_Priorities);
+
+4
+ procedure Set_Priority(Priority : in System.Any_Priority;
+ T : in Ada.Task_Identification.Task_Id :=
+ Ada.Task_Identification.Current_Task);
+
+5
+ function Get_Priority (T : Ada.Task_Identification.Task_Id :=
+ Ada.Task_Identification.Current_Task)
+ return System.Any_Priority;
+
+6
+ end Ada.Dynamic_Priorities;
+
+ _Dynamic Semantics_
+
+7
+The procedure Set_Priority sets the base priority of the specified task
+to the specified Priority value. Set_Priority has no effect if the task
+is terminated.
+
+8
+The function Get_Priority returns T's current base priority.
+Tasking_Error is raised if the task is terminated.
+
+8.a
+ Reason: There is no harm in setting the priority of a
+ terminated task. A previous version of Ada 9X made this a
+ run-time error. However, there is little difference between
+ setting the priority of a terminated task, and setting the
+ priority of a task that is about to terminate very soon;
+ neither case should be an error. Furthermore, the run-time
+ check is not necessarily feasible to implement on all systems,
+ since priority changes might be deferred due to
+ inter-processor communication overhead, so the error might not
+ be detected until after Set_Priority has returned.
+
+8.b
+ However, we wish to allow implementations to avoid storing
+ "extra" information about terminated tasks. Therefore, we
+ make Get_Priority of a terminated task raise an exception; the
+ implementation need not continue to store the priority of a
+ task that has terminated.
+
+9
+Program_Error is raised by Set_Priority and Get_Priority if T is equal
+to Null_Task_Id.
+
+10/2
+{AI95-00188-02AI95-00188-02} On a system with a single processor, the
+setting of the base priority of a task T to the new value occurs
+immediately at the first point when T is outside the execution of a
+protected action.
+
+10.a/2
+ Implementation Note: {AI95-00188-02AI95-00188-02} The priority
+ change is immediate if the target task is on a delay queue or
+ a ready queue outside of a protected action. However,
+ consider when Set_Priority is called by a task T1 to set the
+ priority of T2, if T2 is blocked, waiting on an entry call
+ queued on a protected object, the entry queue needs to be
+ reordered. Since T1 might have a priority that is higher than
+ the ceiling of the protected object, T1 cannot, in general, do
+ the reordering. One way to implement this is to wake T2 up
+ and have T2 do the work. This is similar to the disentangling
+ of queues that needs to happen when a high-priority task
+ aborts a lower-priority task, which might have a call queued
+ on a protected object with a low ceiling. We have an
+ Implementation Permission in *note D.4:: to allow this
+ implementation. We could have required an immediate priority
+ change if on a ready queue during a protected action, but that
+ would have required extra checks for ceiling violations to
+ meet Bounded (Run-Time) Error requirements of *note D.3:: and
+ potentially could cause a protected action to be abandoned in
+ the middle (by raising Program_Error). That seems bad.
+
+10.b
+ Reason: A previous version of Ada 9X made it a run-time error
+ for a high-priority task to set the priority of a
+ lower-priority task that has a queued call on a protected
+ object with a low ceiling. This was changed because:
+
+10.c
+ * The check was not feasible to implement on all systems,
+ since priority changes might be deferred due to
+ inter-processor communication overhead. The calling task
+ would continue to execute without finding out whether the
+ operation succeeded or not.
+
+10.d
+ * The run-time check would tend to cause intermittent
+ system failures -- how is the caller supposed to know
+ whether the other task happens to have a queued call at
+ any given time? Consider for example an interrupt that
+ needs to trigger a priority change in some task. The
+ interrupt handler could not safely call Set_Priority
+ without knowing exactly what the other task is doing, or
+ without severely restricting the ceilings used in the
+ system. If the interrupt handler wants to hand the job
+ off to a third task whose job is to call Set_Priority,
+ this won't help, because one would normally want the
+ third task to have high priority.
+
+Paragraph 11 was deleted.
+
+ _Erroneous Execution_
+
+12
+If any subprogram in this package is called with a parameter T that
+specifies a task object that no longer exists, the execution of the
+program is erroneous.
+
+12.a
+ Ramification: Note that this rule overrides the above rule
+ saying that Program_Error is raised on Get_Priority of a
+ terminated task. If the task object still exists, and the
+ task is terminated, Get_Priority raises Program_Error.
+ However, if the task object no longer exists, calling
+ Get_Priority causes erroneous execution.
+
+ _Documentation Requirements_
+
+12.1/2
+{AI95-00188-02AI95-00188-02} On a multiprocessor, the implementation
+shall document any conditions that cause the completion of the setting
+of the priority of a task to be delayed later than what is specified for
+a single processor.
+
+12.a.1/2
+ Documentation Requirement: Any conditions that cause the
+ completion of the setting of the priority of a task to be
+ delayed for a multiprocessor.
+
+ _Metrics_
+
+13
+The implementation shall document the following metric:
+
+14
+ * The execution time of a call to Set_Priority, for the nonpreempting
+ case, in processor clock cycles. This is measured for a call that
+ modifies the priority of a ready task that is not running (which
+ cannot be the calling one), where the new base priority of the
+ affected task is lower than the active priority of the calling
+ task, and the affected task is not on any entry queue and is not
+ executing a protected operation.
+
+14.a/2
+ Documentation Requirement: The metrics for Set_Priority.
+
+ NOTES
+
+15/2
+ 26 {AI95-00321-01AI95-00321-01} Setting a task's base priority
+ affects task dispatching. First, it can change the task's active
+ priority. Second, under the FIFO_Within_Priorities policy it
+ always causes the task to move to the tail of the ready queue
+ corresponding to its active priority, even if the new base priority
+ is unchanged.
+
+16
+ 27 Under the priority queuing policy, setting a task's base
+ priority has an effect on a queued entry call if the task is
+ blocked waiting for the call. That is, setting the base priority
+ of a task causes the priority of a queued entry call from that task
+ to be updated and the call to be removed and then reinserted in the
+ entry queue at the new priority (see *note D.4::), unless the call
+ originated from the triggering_statement of an asynchronous_select.
+
+17
+ 28 The effect of two or more Set_Priority calls executed in
+ parallel on the same task is defined as executing these calls in
+ some serial order.
+
+17.a
+ Proof: This follows from the general reentrancy requirements
+ stated near the beginning of *note Annex A::, "*note Annex A::
+ Predefined Language Environment".
+
+18/3
+ 29 {AI05-0092-1AI05-0092-1} The rule for when Tasking_Error is
+ raised for Set_Priority or Get_Priority is different from the rule
+ for when Tasking_Error is raised on an entry call (see *note
+ 9.5.3::). In particular, querying the priority of a completed or
+ an abnormal task is allowed, so long as the task is not yet
+ terminated, and setting the priority of a task is allowed for any
+ task state (including for terminated tasks).
+
+19
+ 30 Changing the priorities of a set of tasks can be performed by a
+ series of calls to Set_Priority for each task separately. For this
+ to work reliably, it should be done within a protected operation
+ that has high enough ceiling priority to guarantee that the
+ operation completes without being preempted by any of the affected
+ tasks.
+
+ _Extensions to Ada 95_
+
+19.a/2
+ {AI95-00188-02AI95-00188-02} Amendment Correction: Priority
+ changes are now required to be done immediately so long as the
+ target task is not on an entry queue.
+
+19.b/2
+ {AI95-00362-01AI95-00362-01} Dynamic_Priorities is now
+ Preelaborated, so it can be used in preelaborated units.
+
+ _Wording Changes from Ada 95_
+
+19.c/3
+ {AI95-00327-01AI95-00327-01} {AI05-0299-1AI05-0299-1} This Ada
+ 95 subclause was moved down a level. The paragraph numbers
+ are the same as those for *note D.5:: in Ada 95.
+
+19.d/2
+ {AI95-00321-01AI95-00321-01} There is no "standard" policy
+ anymore, so that phrase was replaced by the name of a specific
+ policy in the notes.
+
+19.e/2
+ {AI95-00327-01AI95-00327-01} The bounded error for the
+ priority of a task being higher than the ceiling of an object
+ it is currently in was moved to *note D.3::, so that it
+ applies no matter how the situation arises.
+
+\1f
+File: aarm2012.info, Node: D.5.2, Prev: D.5.1, Up: D.5
+
+D.5.2 Dynamic Priorities for Protected Objects
+----------------------------------------------
+
+1/3
+{AI95-00327-01AI95-00327-01} {AI05-0299-1AI05-0299-1} This subclause
+specifies how the priority of a protected object can be modified or
+queried at run time.
+
+ _Static Semantics_
+
+2/2
+{AI95-00327-01AI95-00327-01} The following attribute is defined for a
+prefix P that denotes a protected object:
+
+3/2
+P'Priority
+ {AI95-00327-01AI95-00327-01} Denotes a non-aliased
+ component of the protected object P. This component is of
+ type System.Any_Priority and its value is the priority of
+ P. P'Priority denotes a variable if and only if P denotes
+ a variable. A reference to this attribute shall appear
+ only within the body of P.
+
+4/2
+{AI95-00327-01AI95-00327-01} The initial value of this attribute is the
+initial value of the priority of the protected object[, and can be
+changed by an assignment].
+
+ _Dynamic Semantics_
+
+5/3
+{AI95-00327-01AI95-00327-01} {AI05-0264-1AI05-0264-1} If the locking
+policy Ceiling_Locking (see *note D.3::) is in effect, then the ceiling
+priority of a protected object P is set to the value of P'Priority at
+the end of each protected action of P.
+
+6/3
+{AI95-00445-01AI95-00445-01} {AI05-0229-1AI05-0229-1} If the locking
+policy Ceiling_Locking is in effect, then for a protected object P with
+either an Attach_Handler or Interrupt_Handler aspect specified for one
+of its procedures, a check is made that the value to be assigned to
+P'Priority is in the range System.Interrupt_Priority. If the check
+fails, Program_Error is raised.
+
+ _Metrics_
+
+7/2
+{AI95-00327-01AI95-00327-01} The implementation shall document the
+following metric:
+
+8/2
+ * The difference in execution time of calls to the following
+ procedures in protected object P:
+
+9/2
+ protected P is
+ procedure Do_Not_Set_Ceiling (Pr : System.Any_Priority);
+ procedure Set_Ceiling (Pr : System.Any_Priority);
+ end P;
+
+10/2
+ protected body P is
+ procedure Do_Not_Set_Ceiling (Pr : System.Any_Priority) is
+ begin
+ null;
+ end;
+ procedure Set_Ceiling (Pr : System.Any_Priority) is
+ begin
+ P'Priority := Pr;
+ end;
+ end P;
+
+10.a/2
+ Documentation Requirement: The metrics for setting the
+ priority of a protected object.
+
+ NOTES
+
+11/2
+ 31 {AI95-00327-01AI95-00327-01} Since P'Priority is a normal
+ variable, the value following an assignment to the attribute
+ immediately reflects the new value even though its impact on the
+ ceiling priority of P is postponed until completion of the
+ protected action in which it is executed.
+
+ _Extensions to Ada 95_
+
+11.a/2
+ {AI95-00327-01AI95-00327-01} {AI95-00445-01AI95-00445-01} The
+ ability to dynamically change and query the priority of a
+ protected object is new.
+
+\1f
+File: aarm2012.info, Node: D.6, Next: D.7, Prev: D.5, Up: Annex D
+
+D.6 Preemptive Abort
+====================
+
+1/3
+{AI05-0299-1AI05-0299-1} [This subclause specifies requirements on the
+immediacy with which an aborted construct is completed.]
+
+ _Dynamic Semantics_
+
+2
+On a system with a single processor, an aborted construct is completed
+immediately at the first point that is outside the execution of an
+abort-deferred operation.
+
+ _Documentation Requirements_
+
+3
+On a multiprocessor, the implementation shall document any conditions
+that cause the completion of an aborted construct to be delayed later
+than what is specified for a single processor.
+
+3.a/2
+ This paragraph was deleted.
+
+3.b/2
+ Documentation Requirement: On a multiprocessor, any conditions
+ that cause the completion of an aborted construct to be
+ delayed later than what is specified for a single processor.
+
+ _Metrics_
+
+4
+The implementation shall document the following metrics:
+
+5
+ * The execution time, in processor clock cycles, that it takes for an
+ abort_statement to cause the completion of the aborted task. This
+ is measured in a situation where a task T2 preempts task T1 and
+ aborts T1. T1 does not have any finalization code. T2 shall
+ verify that T1 has terminated, by means of the Terminated
+ attribute.
+
+6
+ * On a multiprocessor, an upper bound in seconds, on the time that
+ the completion of an aborted task can be delayed beyond the point
+ that it is required for a single processor.
+
+7/2
+ * {AI95-00114-01AI95-00114-01} An upper bound on the execution time
+ of an asynchronous_select, in processor clock cycles. This is
+ measured between a point immediately before a task T1 executes a
+ protected operation Pr.Set that makes the condition of an
+ entry_barrier Pr.Wait True, and the point where task T2 resumes
+ execution immediately after an entry call to Pr.Wait in an
+ asynchronous_select. T1 preempts T2 while T2 is executing the
+ abortable part, and then blocks itself so that T2 can execute. The
+ execution time of T1 is measured separately, and subtracted.
+
+8
+ * An upper bound on the execution time of an asynchronous_select, in
+ the case that no asynchronous transfer of control takes place.
+ This is measured between a point immediately before a task executes
+ the asynchronous_select with a nonnull abortable part, and the
+ point where the task continues execution immediately after it. The
+ execution time of the abortable part is subtracted.
+
+8.a/2
+ Documentation Requirement: The metrics for aborts.
+
+ _Implementation Advice_
+
+9
+Even though the abort_statement is included in the list of potentially
+blocking operations (see *note 9.5.1::), it is recommended that this
+statement be implemented in a way that never requires the task executing
+the abort_statement to block.
+
+9.a/2
+ Implementation Advice: The abort_statement should not require
+ the task executing the statement to block.
+
+10
+On a multi-processor, the delay associated with aborting a task on
+another processor should be bounded; the implementation should use
+periodic polling, if necessary, to achieve this.
+
+10.a/2
+ Implementation Advice: On a multi-processor, the delay
+ associated with aborting a task on another processor should be
+ bounded.
+
+ NOTES
+
+11
+ 32 Abortion does not change the active or base priority of the
+ aborted task.
+
+12
+ 33 Abortion cannot be more immediate than is allowed by the rules
+ for deferral of abortion during finalization and in protected
+ actions.
+
+\1f
+File: aarm2012.info, Node: D.7, Next: D.8, Prev: D.6, Up: Annex D
+
+D.7 Tasking Restrictions
+========================
+
+1/3
+{AI05-0299-1AI05-0299-1} [This subclause defines restrictions that can
+be used with a pragma Restrictions (see *note 13.12::) to facilitate the
+construction of highly efficient tasking run-time systems.]
+
+ _Static Semantics_
+
+2
+The following restriction_identifiers are language defined:
+
+3/3
+{AI05-0013-1AI05-0013-1} {AI05-0216-1AI05-0216-1} No_Task_Hierarchy
+ No task depends on a master other than the library-level
+ master.
+
+3.a/3
+ Ramification: {AI05-0216-1AI05-0216-1} This is equivalent to
+ saying "no task depends on a master other than the master that
+ is the execution of the body of the environment task of the
+ partition", but it is much easier to understand. This is a
+ post-compilation check, which can be checked at compile-time.
+
+3.b/3
+ {AI05-0013-1AI05-0013-1} This disallows any function returning
+ an object with a task part or coextension, even if called at
+ the library level, as such a task would temporarily depend on
+ a nested master (the master of the return statement), which is
+ disallowed by this restriction.
+
+4/3
+{8652/00428652/0042} {AI95-00130-01AI95-00130-01}
+{AI95-00360-01AI95-00360-01} {AI05-0013-1AI05-0013-1}
+No_Nested_Finalization
+ Objects of a type that needs finalization (see *note
+ 7.6::) are declared only at library level. If an access
+ type does not have library-level accessibility, then
+ there are no allocators of the type where the type
+ determined by the subtype_mark of the subtype_indication
+ or qualified_expression needs finalization.
+
+4.a/1
+ This paragraph was deleted.{8652/00428652/0042}
+ {AI95-00130-01AI95-00130-01}
+
+4.b/3
+ Ramification: {AI05-0013-1AI05-0013-1} The second sentence
+ prevents the declaration of objects of access types which
+ would require nested finalization. It also prevents the
+ declarations of coextensions that need finalization in a
+ nested scope. The latter cannot be done by preventing the
+ declaration of the objects, as it is not necessarily known if
+ the coextension type needs finalization (it could be a limited
+ view).
+
+5/3
+{AI05-0211-1AI05-0211-1} No_Abort_Statements
+ There are no abort_statements, and there is no use of a
+ name denoting Task_Identification.Abort_Task.
+
+6
+No_Terminate_Alternatives
+ There are no selective_accepts with
+ terminate_alternatives.
+
+7
+No_Task_Allocators
+ There are no allocators for task types or types
+ containing task subcomponents.
+
+7.1/3
+ {AI05-0224-1AI05-0224-1} In the case of an initialized
+ allocator of an access type whose designated type is
+ class-wide and limited, a check is made that the specific
+ type of the allocated object has no task subcomponents.
+ Program_Error is raised if this check fails.
+
+8
+No_Implicit_Heap_Allocations
+ There are no operations that implicitly require heap
+ storage allocation to be performed by the implementation.
+ The operations that implicitly require heap storage
+ allocation are implementation defined.
+
+8.a
+ Implementation defined: Any operations that implicitly require
+ heap storage allocation.
+
+9/2
+{AI95-00327-01AI95-00327-01} No_Dynamic_Priorities
+ There are no semantic dependences on the package
+ Dynamic_Priorities, and no occurrences of the attribute
+ Priority.
+
+10/3
+{AI95-00305-01AI95-00305-01} {AI95-00394-01AI95-00394-01}
+{AI05-0013-1AI05-0013-1} {AI05-0211-1AI05-0211-1} No_Dynamic_Attachment
+ There is no use of a name denoting any of the operations
+ defined in package Interrupts (Is_Reserved, Is_Attached,
+ Current_Handler, Attach_Handler, Exchange_Handler,
+ Detach_Handler, and Reference).
+
+10.a/3
+ Ramification: {AI05-0013-1AI05-0013-1} This includes 'Access
+ and 'Address of any of these operations, as well as inherited
+ versions of these operations.
+
+10.1/3
+{AI95-00305-01AI95-00305-01} {AI05-0013-1AI05-0013-1}
+No_Local_Protected_Objects
+ Protected objects are declared only at library level.
+
+10.2/3
+{AI95-00297-01AI95-00297-01} {AI05-0013-1AI05-0013-1}
+No_Local_Timing_Events
+ Timing_Events are declared only at library level.
+
+10.3/2
+{AI95-00305-01AI95-00305-01} No_Protected_Type_Allocators
+ There are no allocators for protected types or types
+ containing protected type subcomponents.
+
+10.4/3
+ {AI05-0224-1AI05-0224-1} In the case of an initialized
+ allocator of an access type whose designated type is
+ class-wide and limited, a check is made that the specific
+ type of the allocated object has no protected
+ subcomponents. Program_Error is raised if this check
+ fails.
+
+10.5/3
+{AI95-00305-01AI95-00305-01} {AI05-0211-1AI05-0211-1} No_Relative_Delay
+ There are no delay_relative_statements, and there is no
+ use of a name that denotes the Timing_Events.Set_Handler
+ subprogram that has a Time_Span parameter.
+
+10.6/3
+{AI95-00305-01AI95-00305-01} No_Requeue_Statements
+ There are no requeue_statements.
+
+10.7/3
+{AI95-00305-01AI95-00305-01} No_Select_Statements
+ There are no select_statements.
+
+10.8/3
+{AI95-00394-01AI95-00394-01} {AI05-0211-1AI05-0211-1}
+No_Specific_Termination_Handlers
+ There is no use of a name denoting the
+ Set_Specific_Handler and Specific_Handler subprograms in
+ Task_Termination.
+
+10.9/3
+{AI95-00305-01AI95-00305-01} {AI05-0013-1AI05-0013-1} Simple_Barriers
+ The Boolean expression in each entry barrier is either a
+ static expression or a name that statically denotes a
+ component of the enclosing protected object.
+
+11
+The following restriction_parameter_identifiers are language defined:
+
+12
+Max_Select_Alternatives
+ Specifies the maximum number of alternatives in a
+ selective_accept.
+
+13
+Max_Task_Entries
+ Specifies the maximum number of entries per task. The
+ bounds of every entry family of a task unit shall be
+ static, or shall be defined by a discriminant of a
+ subtype whose corresponding bound is static. [A value of
+ zero indicates that no rendezvous are possible.]
+
+14
+Max_Protected_Entries
+ Specifies the maximum number of entries per protected
+ type. The bounds of every entry family of a protected
+ unit shall be static, or shall be defined by a
+ discriminant of a subtype whose corresponding bound is
+ static.
+
+ _Dynamic Semantics_
+
+15/2
+{8652/00768652/0076} {AI95-00067-01AI95-00067-01}
+{AI95-00305-01AI95-00305-01} The following restriction_identifier is
+language defined:
+
+15.1/2
+{AI95-00305-01AI95-00305-01} {AI95-00394-01AI95-00394-01}
+No_Task_Termination
+ All tasks are nonterminating. It is
+ implementation-defined what happens if a task attempts to
+ terminate. If there is a fall-back handler (see C.7.3)
+ set for the partition it should be called when the first
+ task attempts to terminate.
+
+15.a.1/2
+ Implementation defined: When restriction No_Task_Termination
+ applies to a partition, what happens when a task terminates.
+
+16
+The following restriction_parameter_identifiers are language defined:
+
+17/1
+{8652/00768652/0076} {AI95-00067-01AI95-00067-01}
+Max_Storage_At_Blocking
+ Specifies the maximum portion [(in storage elements)] of
+ a task's Storage_Size that can be retained by a blocked
+ task. If an implementation chooses to detect a violation
+ of this restriction, Storage_Error should be raised;
+ otherwise, the behavior is implementation defined.
+
+17.a.1/2
+ Implementation defined: The behavior when restriction
+ Max_Storage_At_Blocking is violated.
+
+18/1
+{8652/00768652/0076} {AI95-00067-01AI95-00067-01}
+Max_Asynchronous_Select_Nesting
+ Specifies the maximum dynamic nesting level of
+ asynchronous_selects. A value of zero prevents the use
+ of any asynchronous_select (*note 9.7.4: S0241.) and, if
+ a program contains an asynchronous_select (*note 9.7.4:
+ S0241.), it is illegal. If an implementation chooses to
+ detect a violation of this restriction for values other
+ than zero, Storage_Error should be raised; otherwise, the
+ behavior is implementation defined.
+
+18.a.1/2
+ Implementation defined: The behavior when restriction
+ Max_Asynchronous_Select_Nesting is violated.
+
+19/1
+{8652/00768652/0076} {AI95-00067-01AI95-00067-01} Max_Tasks
+ Specifies the maximum number of task creations that may
+ be executed over the lifetime of a partition, not
+ counting the creation of the environment task. A value
+ of zero prevents any task creation and, if a program
+ contains a task creation, it is illegal. If an
+ implementation chooses to detect a violation of this
+ restriction, Storage_Error should be raised; otherwise,
+ the behavior is implementation defined.
+
+19.a
+ Ramification: Note that this is not a limit on the number of
+ tasks active at a given time; it is a limit on the total
+ number of task creations that occur.
+
+19.b
+ Implementation Note: We envision an implementation approach
+ that places TCBs or pointers to them in a fixed-size table,
+ and never reuses table elements.
+
+19.b.1/2
+ Implementation defined: The behavior when restriction
+ Max_Tasks is violated.
+
+19.1/2
+{AI95-00305-01AI95-00305-01} Max_Entry_Queue_Length
+ Max_Entry_Queue_Length defines the maximum number of
+ calls that are queued on an entry. Violation of this
+ restriction results in the raising of Program_Error at
+ the point of the call or requeue.
+
+19.2/3
+{AI05-0189-1AI05-0189-1} No_Standard_Allocators_After_Elaboration
+ Specifies that an allocator using a standard storage pool
+ (see *note 13.11::) shall not occur within a
+ parameterless library subprogram, nor within the
+ handled_sequence_of_statements of a task body. For the
+ purposes of this rule, an allocator of a type derived
+ from a formal access type does not use a standard storage
+ pool.
+
+19.3/3
+ {AI05-0189-1AI05-0189-1} {AI05-0262-1AI05-0262-1} At run
+ time, Storage_Error is raised if an allocator using a
+ standard storage pool is evaluated after the elaboration
+ of the library_items of the partition has completed.
+
+20
+It is implementation defined whether the use of pragma Restrictions
+results in a reduction in executable program size, storage requirements,
+or execution time. If possible, the implementation should provide
+quantitative descriptions of such effects for each restriction.
+
+20.a/2
+ Implementation defined: Whether the use of pragma Restrictions
+ results in a reduction in program code or data size or
+ execution time.
+
+ _Implementation Advice_
+
+21
+When feasible, the implementation should take advantage of the specified
+restrictions to produce a more efficient implementation.
+
+21.a/2
+ Implementation Advice: When feasible, specified restrictions
+ should be used to produce a more efficient implementation.
+
+ NOTES
+
+22
+ 34 The above Storage_Checks can be suppressed with pragma
+ Suppress.
+
+ _Incompatibilities With Ada 95_
+
+22.a/2
+ {AI95-00360-01AI95-00360-01} Amendment Correction: The
+ No_Nested_Finalization is now defined in terms of types that
+ need finalization. These types include a variety of
+ language-defined types that might be implemented with a
+ controlled type. If the restriction No_Nested_Finalization
+ (see *note D.7::) applies to the partition, and one of these
+ language-defined types does not have a controlled part, it
+ will not be allowed in local objects in Ada 2005 whereas it
+ would be allowed in original Ada 95. Such code is not
+ portable, as other Ada compilers may have had a controlled
+ part, and thus would be illegal under the restriction.
+
+ _Extensions to Ada 95_
+
+22.b/2
+ {AI95-00297-01AI95-00297-01} {AI95-00305-01AI95-00305-01}
+ {AI95-00394-01AI95-00394-01} Restrictions
+ No_Dynamic_Attachment, No_Local_Protected_Objects,
+ No_Protected_Type_Allocators, No_Local_Timing_Events,
+ No_Relative_Delay, No_Requeue_Statement, No_Select_Statements,
+ No_Specific_Termination_Handlers, No_Task_Termination,
+ Max_Entry_Queue_Length, and Simple_Barriers are newly added to
+ Ada.
+
+ _Wording Changes from Ada 95_
+
+22.c/2
+ {8652/00428652/0042} {AI95-00130-01AI95-00130-01} Corrigendum:
+ Clarified that No_Nested_Finalization covered task and
+ protected parts as well.
+
+22.d/2
+ {8652/00768652/0076} {AI95-00067-01AI95-00067-01} Corrigendum:
+ Changed the description of Max_Tasks and
+ Max_Asynchronous_Select_Nested to eliminate conflicts with the
+ High Integrity Annex (see *note H.4::).
+
+22.e/2
+ {AI95-00327-01AI95-00327-01} Added using of the new Priority
+ attribute to the restriction No_Dynamic_Priorities.
+
+22.f/2
+ {AI95-00394-01AI95-00394-01} Restriction
+ No_Asynchronous_Control is now obsolescent.
+
+ _Incompatibilities With Ada 2005_
+
+22.g/3
+ {AI05-0013-1AI05-0013-1} Correction: Changed so that
+ coextensions of types that require nested finalization are
+ also prohibited; this is done by prohibiting allocators rather
+ than objects of specific access types. It seems unlikely that
+ any program depending on this restriction would violate it in
+ this blatant manner, so it is expected that very few programs
+ will be affected by this change.
+
+22.h/3
+ {AI05-0211-1AI05-0211-1} Correction: The restriction
+ No_Relative_Delay was changed to include the Timing_Events
+ routine that uses a relative delay. This means that a program
+ that uses that routine and this restriction will now be
+ rejected. However, such a program violates the spirit and
+ intent of the restriction and as such the program should never
+ have been allowed. Moreover, it is unlikely that any program
+ depending on this restriction would violate it in such an
+ obvious manner, so it is expected that very few programs will
+ be affected by this change.
+
+22.i/3
+ {AI05-0211-1AI05-0211-1} Correction: A number of restrictions
+ were changed from "no calls" on some subprogram to "no use of
+ a name that denotes" that subprogram. This closes a hole
+ where renames, uses as the prefix of 'Access, and the like,
+ would not be rejected by the restriction, possibly allowing
+ backdoor access to the prohibited subprogram. A program that
+ uses one of these restrictions and using such backdoor access
+ will now be rejected; however, it is extremely unlikely that
+ any program that relies on these restrictions would also use
+ an end-run around the restriction, so it is expected that very
+ few programs will be affected by this change.
+
+ _Extensions to Ada 2005_
+
+22.j/3
+ {AI05-0189-1AI05-0189-1} Restriction
+ No_Standard_Allocators_After_Elaboration is newly added to
+ Ada.
+
+ _Wording Changes from Ada 2005_
+
+22.k/3
+ {AI05-0013-1AI05-0013-1} {AI05-0216-1AI05-0216-1} Correction:
+ Improved the wording of various restrictions to make it
+ clearer that they prohibit things that would otherwise be
+ legal, and to word them as definitions, not Legality Rules;.
+
+22.l/3
+ {AI05-0192-1AI05-0192-1} Correction: Added wording to explain
+ how No_Task_Allocators and No_Protected_Type_Allocators are
+ checked for class-wide types. This might be an extension if
+ the compiler assumed the worst in the past (it is now a
+ runtime check).
+
+\1f
+File: aarm2012.info, Node: D.8, Next: D.9, Prev: D.7, Up: Annex D
+
+D.8 Monotonic Time
+==================
+
+1/3
+{AI05-0299-1AI05-0299-1} [This subclause specifies a high-resolution,
+monotonic clock package.]
+
+ _Static Semantics_
+
+2
+The following language-defined library package exists:
+
+3
+ package Ada.Real_Time is
+
+4
+ type Time is private;
+ Time_First : constant Time;
+ Time_Last : constant Time;
+ Time_Unit : constant := implementation-defined-real-number;
+
+5
+ type Time_Span is private;
+ Time_Span_First : constant Time_Span;
+ Time_Span_Last : constant Time_Span;
+ Time_Span_Zero : constant Time_Span;
+ Time_Span_Unit : constant Time_Span;
+
+6
+ Tick : constant Time_Span;
+ function Clock return Time;
+
+7
+ function "+" (Left : Time; Right : Time_Span) return Time;
+ function "+" (Left : Time_Span; Right : Time) return Time;
+ function "-" (Left : Time; Right : Time_Span) return Time;
+ function "-" (Left : Time; Right : Time) return Time_Span;
+
+8
+ function "<" (Left, Right : Time) return Boolean;
+ function "<="(Left, Right : Time) return Boolean;
+ function ">" (Left, Right : Time) return Boolean;
+ function ">="(Left, Right : Time) return Boolean;
+
+9
+ function "+" (Left, Right : Time_Span) return Time_Span;
+ function "-" (Left, Right : Time_Span) return Time_Span;
+ function "-" (Right : Time_Span) return Time_Span;
+ function "*" (Left : Time_Span; Right : Integer) return Time_Span;
+ function "*" (Left : Integer; Right : Time_Span) return Time_Span;
+ function "/" (Left, Right : Time_Span) return Integer;
+ function "/" (Left : Time_Span; Right : Integer) return Time_Span;
+
+10
+ function "abs"(Right : Time_Span) return Time_Span;
+
+11/1
+ This paragraph was deleted.
+
+12
+ function "<" (Left, Right : Time_Span) return Boolean;
+ function "<="(Left, Right : Time_Span) return Boolean;
+ function ">" (Left, Right : Time_Span) return Boolean;
+ function ">="(Left, Right : Time_Span) return Boolean;
+
+13
+ function To_Duration (TS : Time_Span) return Duration;
+ function To_Time_Span (D : Duration) return Time_Span;
+
+14/2
+ {AI95-00386-01AI95-00386-01} function Nanoseconds (NS : Integer) return Time_Span;
+ function Microseconds (US : Integer) return Time_Span;
+ function Milliseconds (MS : Integer) return Time_Span;
+ function Seconds (S : Integer) return Time_Span;
+ function Minutes (M : Integer) return Time_Span;
+
+15
+ type Seconds_Count is range implementation-defined;
+
+16
+ procedure Split(T : in Time; SC : out Seconds_Count; TS : out Time_Span);
+ function Time_Of(SC : Seconds_Count; TS : Time_Span) return Time;
+
+17
+ private
+ ... -- not specified by the language
+ end Ada.Real_Time;
+
+17.a/2
+ This paragraph was deleted.
+
+18
+In this Annex, real time is defined to be the physical time as observed
+in the external environment. The type Time is a time type as defined by
+*note 9.6::; [values of this type may be used in a
+delay_until_statement.] Values of this type represent segments of an
+ideal time line. The set of values of the type Time corresponds
+one-to-one with an implementation-defined range of mathematical
+integers.
+
+18.a
+ Discussion: Informally, real time is defined to be the
+ International Atomic Time (TAI) which is monotonic and
+ nondecreasing. We use it here for the purpose of discussing
+ rate of change and monotonic behavior only. It does not imply
+ anything about the absolute value of Real_Time.Clock, or about
+ Real_Time.Time being synchronized with TAI. It is also used
+ for real time in the metrics, for comparison purposes.
+
+18.b
+ Implementation Note: The specification of TAI as "real time"
+ does not preclude the use of a simulated TAI clock for
+ simulated execution environments.
+
+19
+The Time value I represents the half-open real time interval that starts
+with E+I*Time_Unit and is limited by E+(I+1)*Time_Unit, where Time_Unit
+is an implementation-defined real number and E is an unspecified origin
+point, the epoch, that is the same for all values of the type Time. It
+is not specified by the language whether the time values are
+synchronized with any standard time reference. [For example, E can
+correspond to the time of system initialization or it can correspond to
+the epoch of some time standard.]
+
+19.a
+ Discussion: E itself does not have to be a proper time value.
+
+19.b
+ This half-open interval I consists of all real numbers R such
+ that E+I*Time_Unit <= R < E+(I+1)*Time_Unit.
+
+20
+Values of the type Time_Span represent length of real time duration.
+The set of values of this type corresponds one-to-one with an
+implementation-defined range of mathematical integers. The Time_Span
+value corresponding to the integer I represents the real-time duration
+I*Time_Unit.
+
+20.a
+ Reason: The purpose of this type is similar to
+ Standard.Duration; the idea is to have a type with a higher
+ resolution.
+
+20.b
+ Discussion: We looked at many possible names for this type:
+ Real_Time.Duration, Fine_Duration, Interval,
+ Time_Interval_Length, Time_Measure, and more. Each of these
+ names had some problems, and we've finally settled for
+ Time_Span.
+
+21
+Time_First and Time_Last are the smallest and largest values of the Time
+type, respectively. Similarly, Time_Span_First and Time_Span_Last are
+the smallest and largest values of the Time_Span type, respectively.
+
+22
+A value of type Seconds_Count represents an elapsed time, measured in
+seconds, since the epoch.
+
+ _Dynamic Semantics_
+
+23
+Time_Unit is the smallest amount of real time representable by the Time
+type; it is expressed in seconds. Time_Span_Unit is the difference
+between two successive values of the Time type. It is also the smallest
+positive value of type Time_Span. Time_Unit and Time_Span_Unit
+represent the same real time duration. A clock tick is a real time
+interval during which the clock value (as observed by calling the Clock
+function) remains constant. Tick is the average length of such
+intervals.
+
+24/2
+{AI95-00432-01AI95-00432-01} The function To_Duration converts the value
+TS to a value of type Duration. Similarly, the function To_Time_Span
+converts the value D to a value of type Time_Span. For To_Duration, the
+result is rounded to the nearest value of type Duration (away from zero
+if exactly halfway between two values). If the result is outside the
+range of Duration, Constraint_Error is raised. For To_Time_Span, the
+value of D is first rounded to the nearest integral multiple of
+Time_Unit, away from zero if exactly halfway between two multiples. If
+the rounded value is outside the range of Time_Span, Constraint_Error is
+raised. Otherwise, the value is converted to the type Time_Span.
+
+25
+To_Duration(Time_Span_Zero) returns 0.0, and To_Time_Span(0.0) returns
+Time_Span_Zero.
+
+26/2
+{AI95-00386-01AI95-00386-01} {AI95-00432-01AI95-00432-01} The functions
+Nanoseconds, Microseconds, Milliseconds, Seconds, and Minutes convert
+the input parameter to a value of the type Time_Span. NS, US, MS, S,
+and M are interpreted as a number of nanoseconds, microseconds,
+milliseconds, seconds, and minutes respectively. The input parameter is
+first converted to seconds and rounded to the nearest integral multiple
+of Time_Unit, away from zero if exactly halfway between two multiples.
+If the rounded value is outside the range of Time_Span, Constraint_Error
+is raised. Otherwise, the rounded value is converted to the type
+Time_Span.
+
+26.a/2
+ This paragraph was deleted.{AI95-00432-01AI95-00432-01}
+
+27
+The effects of the operators on Time and Time_Span are as for the
+operators defined for integer types.
+
+27.a
+ Implementation Note: Though time values are modeled by
+ integers, the types Time and Time_Span need not be implemented
+ as integers.
+
+28
+The function Clock returns the amount of time since the epoch.
+
+29
+The effects of the Split and Time_Of operations are defined as follows,
+treating values of type Time, Time_Span, and Seconds_Count as
+mathematical integers. The effect of Split(T,SC,TS) is to set SC and TS
+to values such that T*Time_Unit = SC*1.0 + TS*Time_Unit, and 0.0 <=
+TS*Time_Unit < 1.0. The value returned by Time_Of(SC,TS) is the value T
+such that T*Time_Unit = SC*1.0 + TS*Time_Unit.
+
+ _Implementation Requirements_
+
+30
+The range of Time values shall be sufficient to uniquely represent the
+range of real times from program start-up to 50 years later. Tick shall
+be no greater than 1 millisecond. Time_Unit shall be less than or equal
+to 20 microseconds.
+
+30.a
+ Implementation Note: The required range and accuracy of Time
+ are such that 32-bits worth of seconds and 32-bits worth of
+ ticks in a second could be used as the representation.
+
+31
+Time_Span_First shall be no greater than -3600 seconds, and
+Time_Span_Last shall be no less than 3600 seconds.
+
+31.a
+ Reason: This is equivalent to ± one hour and there is still
+ room for a two-microsecond resolution.
+
+32
+A clock jump is the difference between two successive distinct values of
+the clock (as observed by calling the Clock function). There shall be
+no backward clock jumps.
+
+ _Documentation Requirements_
+
+33
+The implementation shall document the values of Time_First, Time_Last,
+Time_Span_First, Time_Span_Last, Time_Span_Unit, and Tick.
+
+33.a/2
+ Documentation Requirement: The values of Time_First,
+ Time_Last, Time_Span_First, Time_Span_Last, Time_Span_Unit,
+ and Tick for package Real_Time.
+
+34
+The implementation shall document the properties of the underlying time
+base used for the clock and for type Time, such as the range of values
+supported and any relevant aspects of the underlying hardware or
+operating system facilities used.
+
+34.a.1/2
+ Documentation Requirement: The properties of the underlying
+ time base used in package Real_Time.
+
+34.a
+ Discussion: If there is an underlying operating system, this
+ might include information about which system call is used to
+ implement the clock. Otherwise, it might include information
+ about which hardware clock is used.
+
+35
+The implementation shall document whether or not there is any
+synchronization with external time references, and if such
+synchronization exists, the sources of synchronization information, the
+frequency of synchronization, and the synchronization method applied.
+
+35.a.1/2
+ Documentation Requirement: Any synchronization of package
+ Real_Time with external time references.
+
+36/3
+{AI05-0299-1AI05-0299-1} The implementation shall document any aspects
+of the external environment that could interfere with the clock behavior
+as defined in this subclause.
+
+36.a.1/2
+ Documentation Requirement: Any aspects of the external
+ environment that could interfere with package Real_Time.
+
+36.a
+ Discussion: For example, the implementation is allowed to rely
+ on the time services of an underlying operating system, and
+ this operating system clock can implement time zones or allow
+ the clock to be reset by an operator. This dependence has to
+ be documented.
+
+ _Metrics_
+
+37/3
+{AI05-0299-1AI05-0299-1} For the purpose of the metrics defined in this
+subclause, real time is defined to be the International Atomic Time
+(TAI).
+
+38
+The implementation shall document the following metrics:
+
+39
+ * An upper bound on the real-time duration of a clock tick. This is
+ a value D such that if t1 and t2 are any real times such that t1 <
+ t2 and Clockt1 = Clockt2 then t2 - t1 <= D.
+
+40
+ * An upper bound on the size of a clock jump.
+
+41
+ * An upper bound on the drift rate of Clock with respect to real
+ time. This is a real number D such that
+
+42
+ E*(1-D) <= (Clockt+E - Clockt) <= E*(1+D)
+ provided that: Clockt + E*(1+D) <= Time_Last.
+
+43
+ * where Clockt is the value of Clock at time t, and E is a real time
+ duration not less than 24 hours. The value of E used for this
+ metric shall be reported.
+
+43.a
+ Reason: This metric is intended to provide a measurement of
+ the long term (cumulative) deviation; therefore, 24 hours is
+ the lower bound on the measurement period. On some
+ implementations, this is also the maximum period, since the
+ language does not require that the range of the type Duration
+ be more than 24 hours. On those implementations that support
+ longer-range Duration, longer measurements should be
+ performed.
+
+44
+ * An upper bound on the execution time of a call to the Clock
+ function, in processor clock cycles.
+
+45
+ * Upper bounds on the execution times of the operators of the types
+ Time and Time_Span, in processor clock cycles.
+
+45.a
+ Implementation Note: A fast implementation of the Clock
+ function involves repeated reading until you get the same
+ value twice. It is highly improbable that more than three
+ reads will be necessary. Arithmetic on time values should not
+ be significantly slower than 64-bit arithmetic in the
+ underlying machine instruction set.
+
+45.a.1/2
+ Documentation Requirement: The metrics for package Real_Time.
+
+ _Implementation Permissions_
+
+46
+Implementations targeted to machines with word size smaller than 32 bits
+need not support the full range and granularity of the Time and
+Time_Span types.
+
+46.a
+ Discussion: These requirements are based on machines with a
+ word size of 32 bits.
+
+46.b
+ Since the range and granularity are implementation defined,
+ the supported values need to be documented.
+
+ _Implementation Advice_
+
+47
+When appropriate, implementations should provide configuration
+mechanisms to change the value of Tick.
+
+47.a.1/2
+ Implementation Advice: When appropriate, mechanisms to change
+ the value of Tick should be provided.
+
+47.a
+ Reason: This is often needed when the compilation system was
+ originally targeted to a particular processor with a
+ particular interval timer, but the customer uses the same
+ processor with a different interval timer.
+
+47.b
+ Discussion: Tick is a deferred constant and not a named number
+ specifically for this purpose.
+
+47.c
+ Implementation Note: This can be achieved either by
+ pre-run-time configuration tools, or by having Tick be
+ initialized (in the package private part) by a function call
+ residing in a board specific module.
+
+48
+It is recommended that Calendar.Clock and Real_Time.Clock be implemented
+as transformations of the same time base.
+
+48.a.1/2
+ Implementation Advice: Calendar.Clock and Real_Time.Clock
+ should be transformations of the same time base.
+
+49
+It is recommended that the "best" time base which exists in the
+underlying system be available to the application through Clock. "Best"
+may mean highest accuracy or largest range.
+
+49.a.1/2
+ Implementation Advice: The "best" time base which exists in
+ the underlying system should be available to the application
+ through Real_Time.Clock.
+
+ NOTES
+
+50/3
+ 35 {AI05-0299-1AI05-0299-1} The rules in this subclause do not
+ imply that the implementation can protect the user from operator or
+ installation errors which could result in the clock being set
+ incorrectly.
+
+51
+ 36 Time_Unit is the granularity of the Time type. In contrast,
+ Tick represents the granularity of Real_Time.Clock. There is no
+ requirement that these be the same.
+
+ _Incompatibilities With Ada 95_
+
+51.a/3
+ {AI95-00386-01AI95-00386-01} {AI05-0005-1AI05-0005-1}
+ Functions Seconds and Minutes are added to Real_Time. If
+ Real_Time is referenced in a use_clause, and an entity E with
+ a defining_identifier of Seconds or Minutes is defined in a
+ package that is also referenced in a use_clause, the entity E
+ may no longer be use-visible, resulting in errors. This
+ should be rare and is easily fixed if it does occur.
+
+ _Wording Changes from Ada 95_
+
+51.b/2
+ {AI95-00432-01AI95-00432-01} Added wording explaining how and
+ when many of these functions can raise Constraint_Error.
+ While there always was an intent to raise Constraint_Error if
+ the values did not fit, there never was any wording to that
+ effect, and since Time_Span was a private type, the normal
+ numeric type rules do not apply to it.
+
+\1f
+File: aarm2012.info, Node: D.9, Next: D.10, Prev: D.8, Up: Annex D
+
+D.9 Delay Accuracy
+==================
+
+1/3
+{AI05-0299-1AI05-0299-1} [This subclause specifies performance
+requirements for the delay_statement. The rules apply both to
+delay_relative_statement (*note 9.6: S0229.) and to
+delay_until_statement (*note 9.6: S0228.). Similarly, they apply
+equally to a simple delay_statement (*note 9.6: S0227.) and to one which
+appears in a delay_alternative (*note 9.7.1: S0235.).]
+
+ _Dynamic Semantics_
+
+2
+The effect of the delay_statement for Real_Time.Time is defined in terms
+of Real_Time.Clock:
+
+3
+ * If C1 is a value of Clock read before a task executes a
+ delay_relative_statement with duration D, and C2 is a value of
+ Clock read after the task resumes execution following that
+ delay_statement, then C2 - C1 >= D.
+
+4
+ * If C is a value of Clock read after a task resumes execution
+ following a delay_until_statement with Real_Time.Time value T, then
+ C >= T.
+
+5
+A simple delay_statement with a negative or zero value for the
+expiration time does not cause the calling task to be blocked; it is
+nevertheless a potentially blocking operation (see *note 9.5.1::).
+
+6/3
+{AI05-0004-1AI05-0004-1} When a delay_statement appears in a
+delay_alternative of a timed_entry_call the selection of the entry call
+is attempted, regardless of the specified expiration time. When a
+delay_statement appears in a select_alternative, and a call is queued on
+one of the open entries, the selection of that entry call proceeds,
+regardless of the value of the delay expression.
+
+6.a
+ Ramification: The effect of these requirements is that one has
+ to always attempt a rendezvous, regardless of the value of the
+ delay expression. This can be tested by issuing a
+ timed_entry_call with an expiration time of zero, to an open
+ entry.
+
+ _Documentation Requirements_
+
+7
+The implementation shall document the minimum value of the delay
+expression of a delay_relative_statement that causes the task to
+actually be blocked.
+
+7.a/2
+ Documentation Requirement: The minimum value of the delay
+ expression of a delay_relative_statement that causes a task to
+ actually be blocked.
+
+8
+The implementation shall document the minimum difference between the
+value of the delay expression of a delay_until_statement and the value
+of Real_Time.Clock, that causes the task to actually be blocked.
+
+8.a/2
+ This paragraph was deleted.
+
+8.b/2
+ Documentation Requirement: The minimum difference between the
+ value of the delay expression of a delay_until_statement and
+ the value of Real_Time.Clock, that causes the task to actually
+ be blocked.
+
+ _Metrics_
+
+9
+The implementation shall document the following metrics:
+
+10
+ * An upper bound on the execution time, in processor clock cycles, of
+ a delay_relative_statement whose requested value of the delay
+ expression is less than or equal to zero.
+
+11
+ * An upper bound on the execution time, in processor clock cycles, of
+ a delay_until_statement whose requested value of the delay
+ expression is less than or equal to the value of Real_Time.Clock at
+ the time of executing the statement. Similarly, for
+ Calendar.Clock.
+
+12
+ * An upper bound on the lateness of a delay_relative_statement, for a
+ positive value of the delay expression, in a situation where the
+ task has sufficient priority to preempt the processor as soon as it
+ becomes ready, and does not need to wait for any other execution
+ resources. The upper bound is expressed as a function of the value
+ of the delay expression. The lateness is obtained by subtracting
+ the value of the delay expression from the actual duration. The
+ actual duration is measured from a point immediately before a task
+ executes the delay_statement to a point immediately after the task
+ resumes execution following this statement.
+
+13
+ * An upper bound on the lateness of a delay_until_statement, in a
+ situation where the value of the requested expiration time is after
+ the time the task begins executing the statement, the task has
+ sufficient priority to preempt the processor as soon as it becomes
+ ready, and it does not need to wait for any other execution
+ resources. The upper bound is expressed as a function of the
+ difference between the requested expiration time and the clock
+ value at the time the statement begins execution. The lateness of
+ a delay_until_statement is obtained by subtracting the requested
+ expiration time from the real time that the task resumes execution
+ following this statement.
+
+13.a/2
+ Documentation Requirement: The metrics for delay statements.
+
+ _Wording Changes from Ada 83_
+
+14.a
+ The rules regarding a timed_entry_call with a very small
+ positive Duration value, have been tightened to always require
+ the check whether the rendezvous is immediately possible.
+
+ _Wording Changes from Ada 95_
+
+14.b/2
+ {AI95-00355-01AI95-00355-01} The note about "voluntary
+ round-robin', while still true, has been deleted as
+ potentially confusing as it is describing a different kind of
+ round-robin than is defined by the round-robin dispatching
+ policy.
+
+\1f
+File: aarm2012.info, Node: D.10, Next: D.11, Prev: D.9, Up: Annex D
+
+D.10 Synchronous Task Control
+=============================
+
+1/3
+{AI05-0299-1AI05-0299-1} [This subclause describes a language-defined
+private semaphore (suspension object), which can be used for two-stage
+suspend operations and as a simple building block for implementing
+higher-level queues.]
+
+ _Static Semantics_
+
+2
+The following language-defined package exists:
+
+3/2
+ {AI95-00362-01AI95-00362-01} package Ada.Synchronous_Task_Control is
+ pragma Preelaborate(Synchronous_Task_Control);
+
+4
+ type Suspension_Object is limited private;
+ procedure Set_True(S : in out Suspension_Object);
+ procedure Set_False(S : in out Suspension_Object);
+ function Current_State(S : Suspension_Object) return Boolean;
+ procedure Suspend_Until_True(S : in out Suspension_Object);
+ private
+ ... -- not specified by the language
+ end Ada.Synchronous_Task_Control;
+
+5
+The type Suspension_Object is a by-reference type.
+
+5.a/2
+ Implementation Note: {AI95-00318-02AI95-00318-02} The
+ implementation can ensure this by, for example, making the
+ full view an explicitly limited record type.
+
+5.1/3
+{AI05-0168-1AI05-0168-1} The following language-defined package exists:
+
+5.2/3
+ {AI05-0168-1AI05-0168-1} package Ada.Synchronous_Task_Control.EDF is
+ procedure Suspend_Until_True_And_Set_Deadline
+ (S : in out Suspension_Object;
+ TS : in Ada.Real_Time.Time_Span);
+ end Ada.Synchronous_Task_Control.EDF;
+
+ _Dynamic Semantics_
+
+6/2
+{AI95-00114-01AI95-00114-01} An object of the type Suspension_Object has
+two visible states: True and False. Upon initialization, its value is
+set to False.
+
+6.a
+ Discussion: This object is assumed to be private to the
+ declaring task, i.e. only that task will call
+ Suspend_Until_True on this object, and the count of callers is
+ at most one. Other tasks can, of course, change and query the
+ state of this object.
+
+7/2
+{AI95-00114-01AI95-00114-01} The operations Set_True and Set_False are
+atomic with respect to each other and with respect to
+Suspend_Until_True; they set the state to True and False respectively.
+
+8
+Current_State returns the current state of the object.
+
+8.a
+ Discussion: This state can change immediately after the
+ operation returns.
+
+9/2
+{AI95-00114-01AI95-00114-01} The procedure Suspend_Until_True blocks the
+calling task until the state of the object S is True; at that point the
+task becomes ready and the state of the object becomes False.
+
+10
+Program_Error is raised upon calling Suspend_Until_True if another task
+is already waiting on that suspension object. Suspend_Until_True is a
+potentially blocking operation (see *note 9.5.1::).
+
+10.1/3
+{AI05-0168-1AI05-0168-1} {AI05-0269-1AI05-0269-1} The procedure
+Suspend_Until_True_And_Set_Deadline blocks the calling task until the
+state of the object S is True; at that point the task becomes ready with
+a deadline of Ada.Real_Time.Clock + TS, and the state of the object
+becomes False. Program_Error is raised upon calling
+Suspend_Until_True_And_Set_Deadline if another task is already waiting
+on that suspension object. Suspend_Until_True_And_Set_Deadline is a
+potentially blocking operation.
+
+ _Implementation Requirements_
+
+11
+The implementation is required to allow the calling of Set_False and
+Set_True during any protected action, even one that has its ceiling
+priority in the Interrupt_Priority range.
+
+ NOTES
+
+12/3
+ 37 {AI05-0168-1AI05-0168-1} More complex schemes, such as setting
+ the deadline relative to when Set_True is called, can be programmed
+ using a protected object.
+
+ _Extensions to Ada 95_
+
+12.a/2
+ {AI95-00362-01AI95-00362-01} Synchronous_Task_Control is now
+ Preelaborated, so it can be used in preelaborated units.
+
+ _Extensions to Ada 2005_
+
+12.b/3
+ {AI05-0168-1AI05-0168-1} Child package
+ Ada.Synchronous_Task_Control.EDF is new.
+
+* Menu:
+
+* D.10.1 :: Synchronous Barriers
+
+\1f
+File: aarm2012.info, Node: D.10.1, Up: D.10
+
+D.10.1 Synchronous Barriers
+---------------------------
+
+1/3
+{AI05-0174-1AI05-0174-1} {AI05-0299-1AI05-0299-1} This subclause
+introduces a language-defined package to synchronously release a group
+of tasks after the number of blocked tasks reaches a specified count
+value.
+
+ _Static Semantics_
+
+2/3
+{AI05-0174-1AI05-0174-1} The following language-defined library package
+exists:
+
+3/3
+ package Ada.Synchronous_Barriers is
+ pragma Preelaborate(Synchronous_Barriers);
+
+4/3
+ subtype Barrier_Limit is Positive range 1 .. implementation-defined;
+
+4.a.1/3
+ Implementation defined: The value of Barrier_Limit'Last in
+ Synchronous_Barriers.
+
+5/3
+ type Synchronous_Barrier (Release_Threshold : Barrier_Limit) is limited private;
+
+6/3
+ procedure Wait_For_Release (The_Barrier : in out Synchronous_Barrier;
+ Notified : out Boolean);
+
+7/3
+ private
+ -- not specified by the language
+ end Ada.Synchronous_Barriers;
+
+8/3
+{AI05-0174-1AI05-0174-1} Type Synchronous_Barrier needs finalization
+(see *note 7.6::).
+
+ _Dynamic Semantics_
+
+9/3
+{AI05-0174-1AI05-0174-1} Each call to Wait_For_Release blocks the
+calling task until the number of blocked tasks associated with the
+Synchronous_Barrier object is equal to Release_Threshold, at which time
+all blocked tasks are released. Notified is set to True for one of the
+released tasks, and set to False for all other released tasks.
+
+10/3
+{AI05-0174-1AI05-0174-1} The mechanism for determining which task sets
+Notified to True is implementation defined.
+
+11/3
+{AI05-0174-1AI05-0174-1} Once all tasks have been released, a
+Synchronous_Barrier object may be reused to block another
+Release_Threshold number of tasks.
+
+12/3
+{AI05-0174-1AI05-0174-1} As the first step of the finalization of a
+Synchronous_Barrier, each blocked task is unblocked and Program_Error is
+raised at the place of the call to Wait_For_Release.
+
+13/3
+{AI05-0174-1AI05-0174-1} It is implementation defined whether an
+abnormal task which is waiting on a Synchronous_Barrier object is
+aborted immediately or aborted when the tasks waiting on the object are
+released.
+
+13.a.1/3
+ Implementation defined: When an aborted task that is waiting
+ on a Synchronous_Barrier is aborted.
+
+14/3
+{AI05-0174-1AI05-0174-1} Wait_For_Release is a potentially blocking
+operation (see *note 9.5.1::).
+
+ _Bounded (Run-Time) Errors_
+
+15/3
+{AI05-0174-1AI05-0174-1} It is a bounded error to call Wait_For_Release
+on a Synchronous_Barrier object after that object is finalized. If the
+error is detected, Program_Error is raised. Otherwise, the call
+proceeds normally, which may leave a task blocked forever.
+
+ _Extensions to Ada 2005_
+
+15.a/3
+ {AI05-0174-1AI05-0174-1} The package Ada.Synchronous_Barriers
+ is new.
+
+\1f
+File: aarm2012.info, Node: D.11, Next: D.12, Prev: D.10, Up: Annex D
+
+D.11 Asynchronous Task Control
+==============================
+
+1/3
+{AI05-0299-1AI05-0299-1} [This subclause introduces a language-defined
+package to do asynchronous suspend/resume on tasks. It uses a
+conceptual held priority value to represent the task's held state.]
+
+ _Static Semantics_
+
+2
+The following language-defined library package exists:
+
+3/2
+ {AI95-00362-01AI95-00362-01} with Ada.Task_Identification;
+ package Ada.Asynchronous_Task_Control is
+ pragma Preelaborate(Asynchronous_Task_Control);
+ procedure Hold(T : in Ada.Task_Identification.Task_Id);
+ procedure Continue(T : in Ada.Task_Identification.Task_Id);
+ function Is_Held(T : Ada.Task_Identification.Task_Id)
+ return Boolean;
+ end Ada.Asynchronous_Task_Control;
+
+ _Dynamic Semantics_
+
+4/2
+{AI95-00357-01AI95-00357-01} After the Hold operation has been applied
+to a task, the task becomes held. For each processor there is a
+conceptual idle task, which is always ready. The base priority of the
+idle task is below System.Any_Priority'First. The held priority is a
+constant of the type Integer whose value is below the base priority of
+the idle task.
+
+4.a
+ Discussion: The held state should not be confused with the
+ blocked state as defined in *note 9.2::; the task is still
+ ready.
+
+4.1/2
+{AI95-00357-01AI95-00357-01} For any priority below
+System.Any_Priority'First, the task dispatching policy is
+FIFO_Within_Priorities.
+
+4.b/2
+ To be honest: This applies even if a Task_Dispatching_Policy
+ specifies the policy for all of the priorities of the
+ partition.
+
+4.c/2
+ Ramification: A task at the held priority never runs, so it is
+ not necessary to implement FIFO_Within_Priorities for systems
+ that have only one policy (such as EDF_Across_Priorities).
+
+5/2
+{AI95-00357-01AI95-00357-01} The Hold operation sets the state of T to
+held. For a held task, the active priority is reevaluated as if the
+base priority of the task were the held priority.
+
+5.a
+ Ramification: For example, if T is currently inheriting
+ priorities from other sources (e.g. it is executing in a
+ protected action), its active priority does not change, and it
+ continues to execute until it leaves the protected action.
+
+6/2
+{AI95-00357-01AI95-00357-01} The Continue operation resets the state of
+T to not-held; its active priority is then reevaluated as determined by
+the task dispatching policy associated with its base priority.
+
+7
+The Is_Held function returns True if and only if T is in the held state.
+
+7.a
+ Discussion: Note that the state of T can be changed
+ immediately after Is_Held returns.
+
+8
+As part of these operations, a check is made that the task identified by
+T is not terminated. Tasking_Error is raised if the check fails.
+Program_Error is raised if the value of T is Null_Task_Id.
+
+ _Erroneous Execution_
+
+9
+If any operation in this package is called with a parameter T that
+specifies a task object that no longer exists, the execution of the
+program is erroneous.
+
+ _Implementation Permissions_
+
+10
+An implementation need not support Asynchronous_Task_Control if it is
+infeasible to support it in the target environment.
+
+10.a
+ Reason: A direct implementation of the
+ Asynchronous_Task_Control semantics using priorities is not
+ necessarily efficient enough. Thus, we envision
+ implementations that use some other mechanism to set the
+ "held" state. If there is no other such mechanism, support
+ for Asynchronous_Task_Control might be infeasible, because an
+ implementation in terms of priority would require one idle
+ task per processor. On some systems, programs are not
+ supposed to know how many processors are available, so
+ creating enough idle tasks would be problematic.
+
+ NOTES
+
+11
+ 38 It is a consequence of the priority rules that held tasks
+ cannot be dispatched on any processor in a partition (unless they
+ are inheriting priorities) since their priorities are defined to be
+ below the priority of any idle task.
+
+12
+ 39 The effect of calling Get_Priority and Set_Priority on a Held
+ task is the same as on any other task.
+
+13
+ 40 Calling Hold on a held task or Continue on a non-held task has
+ no effect.
+
+14
+ 41 The rules affecting queuing are derived from the above rules,
+ in addition to the normal priority rules:
+
+15
+ * When a held task is on the ready queue, its priority is so low
+ as to never reach the top of the queue as long as there are
+ other tasks on that queue.
+
+16
+ * If a task is executing in a protected action, inside a
+ rendezvous, or is inheriting priorities from other sources
+ (e.g. when activated), it continues to execute until it is no
+ longer executing the corresponding construct.
+
+17
+ * If a task becomes held while waiting (as a caller) for a
+ rendezvous to complete, the active priority of the accepting
+ task is not affected.
+
+18/1
+ * {8652/00778652/0077} {AI95-00111-01AI95-00111-01} If a task
+ becomes held while waiting in a selective_accept, and an entry
+ call is issued to one of the open entries, the corresponding
+ accept_alternative (*note 9.7.1: S0234.) executes. When the
+ rendezvous completes, the active priority of the accepting
+ task is lowered to the held priority (unless it is still
+ inheriting from other sources), and the task does not execute
+ until another Continue.
+
+19
+ * The same holds if the held task is the only task on a
+ protected entry queue whose barrier becomes open. The
+ corresponding entry body executes.
+
+ _Extensions to Ada 95_
+
+19.a/2
+ {AI95-00362-01AI95-00362-01} Asynchronous_Task_Control is now
+ Preelaborated, so it can be used in preelaborated units.
+
+ _Wording Changes from Ada 95_
+
+19.b/2
+ {8652/00778652/0077} {AI95-00111-01AI95-00111-01} Corrigendum:
+ Corrected to eliminate the use of the undefined term "accept
+ body".
+
+19.c/2
+ {AI95-00357-01AI95-00357-01} The description of held tasks was
+ changed to reflect that the calculation of active priorities
+ depends on the dispatching policy of the base priority. Thus,
+ the policy of the held priority was specified in order to
+ avoid surprises (especially when using the EDF policy).
+
+\1f
+File: aarm2012.info, Node: D.12, Next: D.13, Prev: D.11, Up: Annex D
+
+D.12 Other Optimizations and Determinism Rules
+==============================================
+
+1/3
+{AI05-0299-1AI05-0299-1} [This subclause describes various requirements
+for improving the response and determinism in a real-time system.]
+
+ _Implementation Requirements_
+
+2
+If the implementation blocks interrupts (see *note C.3::) not as a
+result of direct user action (e.g. an execution of a protected action)
+there shall be an upper bound on the duration of this blocking.
+
+2.a
+ Ramification: The implementation shall not allow itself to be
+ interrupted when it is in a state where it is unable to
+ support all the language-defined operations permitted in the
+ execution of interrupt handlers. (see *note 9.5.1::).
+
+3
+The implementation shall recognize entry-less protected types. The
+overhead of acquiring the execution resource of an object of such a type
+(see *note 9.5.1::) shall be minimized. In particular, there should not
+be any overhead due to evaluating entry_barrier conditions.
+
+3.a
+ Implementation Note: Ideally the overhead should just be a
+ spin-lock.
+
+4
+Unchecked_Deallocation shall be supported for terminated tasks that are
+designated by access types, and shall have the effect of releasing all
+the storage associated with the task. This includes any run-time system
+or heap storage that has been implicitly allocated for the task by the
+implementation.
+
+ _Documentation Requirements_
+
+5
+The implementation shall document the upper bound on the duration of
+interrupt blocking caused by the implementation. If this is different
+for different interrupts or interrupt priority levels, it should be
+documented for each case.
+
+5.a/2
+ This paragraph was deleted.
+
+5.b/2
+ Documentation Requirement: The upper bound on the duration of
+ interrupt blocking caused by the implementation.
+
+ _Metrics_
+
+6
+The implementation shall document the following metric:
+
+7
+ * The overhead associated with obtaining a mutual-exclusive access to
+ an entry-less protected object. This shall be measured in the
+ following way:
+
+8
+ For a protected object of the form:
+
+9
+ protected Lock is
+ procedure Set;
+ function Read return Boolean;
+ private
+ Flag : Boolean := False;
+ end Lock;
+
+10
+ protected body Lock is
+ procedure Set is
+ begin
+ Flag := True;
+ end Set;
+ function Read return Boolean
+ Begin
+ return Flag;
+ end Read;
+ end Lock;
+
+11
+ The execution time, in processor clock cycles, of a call to Set.
+ This shall be measured between the point just before issuing the
+ call, and the point just after the call completes. The function
+ Read shall be called later to verify that Set was indeed called
+ (and not optimized away). The calling task shall have sufficiently
+ high priority as to not be preempted during the measurement period.
+ The protected object shall have sufficiently high ceiling priority
+ to allow the task to call Set.
+
+12
+ For a multiprocessor, if supported, the metric shall be reported
+ for the case where no contention (on the execution resource) exists
+ [from tasks executing on other processors].
+
+12.a/2
+ Documentation Requirement: The metrics for entry-less
+ protected objects.
+
+\1f
+File: aarm2012.info, Node: D.13, Next: D.14, Prev: D.12, Up: Annex D
+
+D.13 The Ravenscar Profile
+==========================
+
+1/3
+{AI95-00249-01AI95-00249-01} {AI05-0246-1AI05-0246-1}
+{AI05-0299-1AI05-0299-1} [This subclause defines the Ravenscar profile.]
+
+Paragraphs 2 and 3 were moved to *note 13.12::, "*note 13.12:: Pragma
+Restrictions and Pragma Profile".
+
+ _Legality Rules_
+
+4/3
+{AI95-00249-01AI95-00249-01} {AI05-0246-1AI05-0246-1} The
+profile_identifier Ravenscar is a usage profile (see *note 13.12::).
+For usage profile Ravenscar, there shall be no
+profile_pragma_argument_association (*note 2.8: S0020.)s.
+
+ _Static Semantics_
+
+5/3
+{AI95-00249-01AI95-00249-01} {AI05-0246-1AI05-0246-1} The usage profile
+Ravenscar is equivalent to the following set of pragmas:
+
+6/3
+ {AI95-00249-01AI95-00249-01} {AI95-00297-01AI95-00297-01} {AI95-00394-01AI95-00394-01} {AI05-0171-1AI05-0171-1} {AI05-0246-1AI05-0246-1} pragma Task_Dispatching_Policy (FIFO_Within_Priorities);
+ pragma Locking_Policy (Ceiling_Locking);
+ pragma Detect_Blocking;
+ pragma Restrictions (
+ No_Abort_Statements,
+ No_Dynamic_Attachment,
+ No_Dynamic_Priorities,
+ No_Implicit_Heap_Allocations,
+ No_Local_Protected_Objects,
+ No_Local_Timing_Events,
+ No_Protected_Type_Allocators,
+ No_Relative_Delay,
+ No_Requeue_Statements,
+ No_Select_Statements,
+ No_Specific_Termination_Handlers,
+ No_Task_Allocators,
+ No_Task_Hierarchy,
+ No_Task_Termination,
+ Simple_Barriers,
+ Max_Entry_Queue_Length => 1,
+ Max_Protected_Entries => 1,
+ Max_Task_Entries => 0,
+ No_Dependence => Ada.Asynchronous_Task_Control,
+ No_Dependence => Ada.Calendar,
+ No_Dependence => Ada.Execution_Time.Group_Budgets,
+ No_Dependence => Ada.Execution_Time.Timers,
+ No_Dependence => Ada.Task_Attributes,
+ No_Dependence => System.Multiprocessors.Dispatching_Domains);
+
+6.a/3
+ Discussion: The Ravenscar profile is named for the location of
+ the meeting that defined its initial version. The name is now
+ in widespread use, so we stick with existing practice, rather
+ than using a more descriptive name.
+
+Paragraph 7 was deleted.
+
+ _Implementation Requirements_
+
+8/3
+{AI05-0171-1AI05-0171-1} {AI05-0229-1AI05-0229-1} A task shall only be
+on the ready queues of one processor, and the processor to which a task
+belongs shall be defined statically. Whenever a task running on a
+processor reaches a task dispatching point, it goes back to the ready
+queues of the same processor. A task with a CPU value of
+Not_A_Specific_CPU will execute on an implementation defined processor.
+[A task without a CPU aspect will activate and execute on the same
+processor as its activating task.]
+
+8.a/3
+ Proof: The processor of a task without a CPU aspect is defined
+ in *note D.16::.
+
+8.a.1/3
+ Implementation defined: The processor on which a task with a
+ CPU value of a Not_A_Specific_CPU will execute when the
+ Ravenscar profile is in effect.
+
+ _Implementation Advice_
+
+9/3
+{AI05-0171-1AI05-0171-1} On a multiprocessor system, an implementation
+should support a fully partitioned approach. Each processor should have
+separate and disjoint ready queues.
+
+9.a.1/3
+ Implementation Advice: On a multiprocessor system, each
+ processor should have a separate and disjoint ready queue.
+
+ NOTES
+
+10/3
+ 42 {AI95-00249-01AI95-00249-01} {AI05-0246-1AI05-0246-1} The
+ effect of the Max_Entry_Queue_Length => 1 restriction applies only
+ to protected entry queues due to the accompanying restriction of
+ Max_Task_Entries => 0.
+
+ _Extensions to Ada 95_
+
+10.a/3
+ {AI95-00249-01AI95-00249-01} {AI05-0246-1AI05-0246-1} The
+ Ravenscar profile is new; it was moved here by Ada 2012.
+
+ _Wording Changes from Ada 2005_
+
+10.b/3
+ {AI05-0171-1AI05-0171-1} How Ravenscar behaves on a
+ multiprocessor system is now defined.
+
+\1f
+File: aarm2012.info, Node: D.14, Next: D.15, Prev: D.13, Up: Annex D
+
+D.14 Execution Time
+===================
+
+1/3
+{AI95-00307-01AI95-00307-01} {AI05-0299-1AI05-0299-1} This subclause
+describes a language-defined package to measure execution time.
+
+ _Static Semantics_
+
+2/2
+{AI95-00307-01AI95-00307-01} The following language-defined library
+package exists:
+
+3/2
+ with Ada.Task_Identification;
+ with Ada.Real_Time; use Ada.Real_Time;
+ package Ada.Execution_Time is
+
+4/2
+ type CPU_Time is private;
+ CPU_Time_First : constant CPU_Time;
+ CPU_Time_Last : constant CPU_Time;
+ CPU_Time_Unit : constant := implementation-defined-real-number;
+ CPU_Tick : constant Time_Span;
+
+5/2
+ function Clock
+ (T : Ada.Task_Identification.Task_Id
+ := Ada.Task_Identification.Current_Task)
+ return CPU_Time;
+
+6/2
+ function "+" (Left : CPU_Time; Right : Time_Span) return CPU_Time;
+ function "+" (Left : Time_Span; Right : CPU_Time) return CPU_Time;
+ function "-" (Left : CPU_Time; Right : Time_Span) return CPU_Time;
+ function "-" (Left : CPU_Time; Right : CPU_Time) return Time_Span;
+
+7/2
+ function "<" (Left, Right : CPU_Time) return Boolean;
+ function "<=" (Left, Right : CPU_Time) return Boolean;
+ function ">" (Left, Right : CPU_Time) return Boolean;
+ function ">=" (Left, Right : CPU_Time) return Boolean;
+
+8/2
+ procedure Split
+ (T : in CPU_Time; SC : out Seconds_Count; TS : out Time_Span);
+
+9/2
+ function Time_Of (SC : Seconds_Count;
+ TS : Time_Span := Time_Span_Zero) return CPU_Time;
+
+9.1/3
+ {AI05-0170-1AI05-0170-1} Interrupt_Clocks_Supported : constant Boolean := implementation-defined;
+
+9.2/3
+ {AI05-0170-1AI05-0170-1} Separate_Interrupt_Clocks_Supported : constant Boolean :=
+ implementation-defined;
+
+9.3/3
+ {AI05-0170-1AI05-0170-1} function Clock_For_Interrupts return CPU_Time;
+
+10/2
+ private
+ ... -- not specified by the language
+ end Ada.Execution_Time;
+
+11/3
+{AI95-00307-01AI95-00307-01} {AI05-0170-1AI05-0170-1}
+{AI05-0269-1AI05-0269-1} The execution time or CPU time of a given task
+is defined as the time spent by the system executing that task,
+including the time spent executing run-time or system services on its
+behalf. The mechanism used to measure execution time is implementation
+defined. The Boolean constant Interrupt_Clocks_Supported is set to True
+if the implementation separately accounts for the execution time of
+interrupt handlers. If it is set to False it is implementation defined
+which task, if any, is charged the execution time that is consumed by
+interrupt handlers. The Boolean constant
+Separate_Interrupt_Clocks_Supported is set to True if the implementation
+separately accounts for the execution time of individual interrupt
+handlers (see *note D.14.3::).
+
+11.a/2
+ Discussion: The implementation-defined properties above and of
+ the values declared in the package are repeated in
+ Documentation Requirements, so we don't mark them as
+ implementation-defined.
+
+12/2
+{AI95-00307-01AI95-00307-01} The type CPU_Time represents the execution
+time of a task. The set of values of this type corresponds one-to-one
+with an implementation-defined range of mathematical integers.
+
+13/2
+{AI95-00307-01AI95-00307-01} The CPU_Time value I represents the
+half-open execution-time interval that starts with I*CPU_Time_Unit and
+is limited by (I+1)*CPU_Time_Unit, where CPU_Time_Unit is an
+implementation-defined real number. For each task, the execution time
+value is set to zero at the creation of the task.
+
+13.a/2
+ Ramification: Since it is implementation-defined which task is
+ charged execution time for system services, the execution time
+ value may become nonzero even before the start of the
+ activation of the task.
+
+14/2
+{AI95-00307-01AI95-00307-01} CPU_Time_First and CPU_Time_Last are the
+smallest and largest values of the CPU_Time type, respectively.
+
+14.1/3
+{AI05-0170-1AI05-0170-1} The execution time value for the function
+Clock_For_Interrupts is initialized to zero.
+
+ _Dynamic Semantics_
+
+15/2
+{AI95-00307-01AI95-00307-01} CPU_Time_Unit is the smallest amount of
+execution time representable by the CPU_Time type; it is expressed in
+seconds. A CPU clock tick is an execution time interval during which
+the clock value (as observed by calling the Clock function) remains
+constant. CPU_Tick is the average length of such intervals.
+
+16/2
+{AI95-00307-01AI95-00307-01} The effects of the operators on CPU_Time
+and Time_Span are as for the operators defined for integer types.
+
+17/2
+{AI95-00307-01AI95-00307-01} The function Clock returns the current
+execution time of the task identified by T; Tasking_Error is raised if
+that task has terminated; Program_Error is raised if the value of T is
+Task_Identification.Null_Task_Id.
+
+18/2
+{AI95-00307-01AI95-00307-01} The effects of the Split and Time_Of
+operations are defined as follows, treating values of type CPU_Time,
+Time_Span, and Seconds_Count as mathematical integers. The effect of
+Split (T, SC, TS) is to set SC and TS to values such that
+T*CPU_Time_Unit = SC*1.0 + TS*CPU_Time_Unit, and 0.0 <= TS*CPU_Time_Unit
+< 1.0. The value returned by Time_Of(SC,TS) is the execution-time value
+T such that T*CPU_Time_Unit=SC*1.0 + TS*CPU_Time_Unit.
+
+18.1/3
+{AI05-0170-1AI05-0170-1} The function Clock_For_Interrupts returns the
+total cumulative time spent executing within all interrupt handlers.
+This time is not allocated to any task execution time clock. If
+Interrupt_Clocks_Supported is set to False the function raises
+Program_Error.
+
+ _Erroneous Execution_
+
+19/2
+{AI95-00307-01AI95-00307-01} For a call of Clock, if the task identified
+by T no longer exists, the execution of the program is erroneous.
+
+ _Implementation Requirements_
+
+20/2
+{AI95-00307-01AI95-00307-01} The range of CPU_Time values shall be
+sufficient to uniquely represent the range of execution times from the
+task start-up to 50 years of execution time later. CPU_Tick shall be no
+greater than 1 millisecond.
+
+ _Documentation Requirements_
+
+21/2
+{AI95-00307-01AI95-00307-01} The implementation shall document the
+values of CPU_Time_First, CPU_Time_Last, CPU_Time_Unit, and CPU_Tick.
+
+21.a/2
+ Documentation Requirement: The values of CPU_Time_First,
+ CPU_Time_Last, CPU_Time_Unit, and CPU_Tick of package
+ Execution_Time.
+
+22/2
+{AI95-00307-01AI95-00307-01} The implementation shall document the
+properties of the underlying mechanism used to measure execution times,
+such as the range of values supported and any relevant aspects of the
+underlying hardware or operating system facilities used.
+
+22.a/3
+ Documentation Requirement: The properties of the mechanism
+ used to implement package Execution_Time, including the values
+ of the constants defined in the package.
+
+ _Metrics_
+
+23/2
+{AI95-00307-01AI95-00307-01} The implementation shall document the
+following metrics:
+
+24/2
+ * An upper bound on the execution-time duration of a clock tick.
+ This is a value D such that if t1 and t2 are any execution times of
+ a given task such that t1 < t2 and Clockt1 = Clockt2 then t2 - t1
+ <= D.
+
+25/2
+ * An upper bound on the size of a clock jump. A clock jump is the
+ difference between two successive distinct values of an
+ execution-time clock (as observed by calling the Clock function
+ with the same Task_Id).
+
+26/2
+ * An upper bound on the execution time of a call to the Clock
+ function, in processor clock cycles.
+
+27/2
+ * Upper bounds on the execution times of the operators of the type
+ CPU_Time, in processor clock cycles.
+
+27.a/2
+ Documentation Requirement: The metrics for execution time.
+
+ _Implementation Permissions_
+
+28/2
+{AI95-00307-01AI95-00307-01} Implementations targeted to machines with
+word size smaller than 32 bits need not support the full range and
+granularity of the CPU_Time type.
+
+ _Implementation Advice_
+
+29/2
+{AI95-00307-01AI95-00307-01} When appropriate, implementations should
+provide configuration mechanisms to change the value of CPU_Tick.
+
+29.a/2
+ Implementation Advice: When appropriate, implementations
+ should provide configuration mechanisms to change the value of
+ Execution_Time.CPU_Tick.
+
+ _Extensions to Ada 95_
+
+29.b/2
+ {AI95-00307-01AI95-00307-01} The package Execution_Time is
+ new.
+
+ _Incompatibilities With Ada 2005_
+
+29.c/3
+ {AI05-0170-1AI05-0170-1} Function Clock_For_Interrupts, and
+ constants Interrupt_Clocks_Supported and
+ Separate_Interrupt_Clocks_Supported are added to
+ Execution_Time. If Execution_Time is referenced in a
+ use_clause, and an entity E with a defining_identifier of one
+ of the added entities is defined in a package that is also
+ referenced in a use_clause, the entity E may no longer be
+ use-visible, resulting in errors. This should be rare and is
+ easily fixed if it does occur.
+
+ _Wording Changes from Ada 2005_
+
+29.d/3
+ {AI05-0170-1AI05-0170-1} If Interrupt_Clocks_Supported is
+ True, it is now possible to determine the execution time of
+ interrupt handlers. This is not an inconsistency, as not
+ charging any task for such time was a legitimate
+ implementation for Ada 2005.
+
+* Menu:
+
+* D.14.1 :: Execution Time Timers
+* D.14.2 :: Group Execution Time Budgets
+* D.14.3 :: Execution Time of Interrupt Handlers
+
+\1f
+File: aarm2012.info, Node: D.14.1, Next: D.14.2, Up: D.14
+
+D.14.1 Execution Time Timers
+----------------------------
+
+1/3
+{AI95-00307-01AI95-00307-01} {AI05-0299-1AI05-0299-1} This subclause
+describes a language-defined package that provides a facility for
+calling a handler when a task has used a defined amount of CPU time.
+
+ _Static Semantics_
+
+2/2
+{AI95-00307-01AI95-00307-01} The following language-defined library
+package exists:
+
+3/2
+ with System;
+ package Ada.Execution_Time.Timers is
+
+4/2
+ type Timer (T : not null access constant
+ Ada.Task_Identification.Task_Id) is
+ tagged limited private;
+
+5/2
+ type Timer_Handler is
+ access protected procedure (TM : in out Timer);
+
+6/2
+ Min_Handler_Ceiling : constant System.Any_Priority :=
+ implementation-defined;
+
+7/2
+ procedure Set_Handler (TM : in out Timer;
+ In_Time : in Time_Span;
+ Handler : in Timer_Handler);
+ procedure Set_Handler (TM : in out Timer;
+ At_Time : in CPU_Time;
+ Handler : in Timer_Handler);
+ function Current_Handler (TM : Timer) return Timer_Handler;
+ procedure Cancel_Handler (TM : in out Timer;
+ Cancelled : out Boolean);
+
+8/2
+ function Time_Remaining (TM : Timer) return Time_Span;
+
+9/2
+ Timer_Resource_Error : exception;
+
+10/2
+ private
+ ... -- not specified by the language
+ end Ada.Execution_Time.Timers;
+
+11/2
+{AI95-00307-01AI95-00307-01} The type Timer represents an execution-time
+event for a single task and is capable of detecting execution-time
+overruns. The access discriminant T identifies the task concerned. The
+type Timer needs finalization (see *note 7.6::).
+
+12/2
+{AI95-00307-01AI95-00307-01} An object of type Timer is said to be set
+if it is associated with a nonnull value of type Timer_Handler and
+cleared otherwise. All Timer objects are initially cleared.
+
+13/2
+{AI95-00307-01AI95-00307-01} The type Timer_Handler identifies a
+protected procedure to be executed by the implementation when the timer
+expires. Such a protected procedure is called a handler.
+
+13.a/2
+ Discussion: Type Timer is tagged. This makes it possible to
+ share a handler between several events. In simple cases,
+ 'Access can be used to compare the parameter with a specific
+ timer object (this works because a tagged type is a
+ by-reference type). In more complex cases, a type extension
+ of type Timer can be declared; a double type conversion can be
+ used to access the extension data. An example of how this can
+ be done can be found for the similar type Timing_Event, see
+ *note D.15::.
+
+ _Dynamic Semantics_
+
+14/2
+{AI95-00307-01AI95-00307-01} When a Timer object is created, or upon the
+first call of a Set_Handler procedure with the timer as parameter, the
+resources required to operate an execution-time timer based on the
+associated execution-time clock are allocated and initialized. If this
+operation would exceed the available resources, Timer_Resource_Error is
+raised.
+
+15/3
+{AI95-00307-01AI95-00307-01} {AI05-0264-1AI05-0264-1} The procedures
+Set_Handler associate the handler Handler with the timer TM: if Handler
+is null, the timer is cleared; otherwise, it is set. The first
+procedure Set_Handler loads the timer TM with an interval specified by
+the Time_Span parameter. In this mode, the timer TM expires when the
+execution time of the task identified by TM.T.all has increased by
+In_Time; if In_Time is less than or equal to zero, the timer expires
+immediately. The second procedure Set_Handler loads the timer TM with
+the absolute value specified by At_Time. In this mode, the timer TM
+expires when the execution time of the task identified by TM.T.all
+reaches At_Time; if the value of At_Time has already been reached when
+Set_Handler is called, the timer expires immediately.
+
+15.a/2
+ Implementation Note: Since an access-to-constant can designate
+ a variable, the Task_Id value designated by the discriminant
+ of a Timer object can be changed after the object is created.
+ Thus, an implementation cannot use the value of the Task_Id
+ other than where this Standard specifies. For instance, the
+ Task_Id should be read when the timer is set, but it should
+ not be used when the timer expires (as it may designate a
+ different task at that point).
+
+16/2
+{AI95-00307-01AI95-00307-01} A call of a procedure Set_Handler for a
+timer that is already set replaces the handler and the (absolute or
+relative) execution time; if Handler is not null, the timer remains set.
+
+17/2
+{AI95-00307-01AI95-00307-01} When a timer expires, the associated
+handler is executed, passing the timer as parameter. The initial action
+of the execution of the handler is to clear the event.
+
+18/3
+{AI95-00307-01AI95-00307-01} {AI05-0264-1AI05-0264-1} The function
+Current_Handler returns the handler associated with the timer TM if that
+timer is set; otherwise, it returns null.
+
+19/3
+{AI95-00307-01AI95-00307-01} {AI05-0264-1AI05-0264-1} The procedure
+Cancel_Handler clears the timer if it is set. Cancelled is assigned
+True if the timer was set prior to it being cleared; otherwise, it is
+assigned False.
+
+20/3
+{AI95-00307-01AI95-00307-01} {AI05-0264-1AI05-0264-1} The function
+Time_Remaining returns the execution time interval that remains until
+the timer TM would expire, if that timer is set; otherwise, it returns
+Time_Span_Zero.
+
+21/2
+{AI95-00307-01AI95-00307-01} The constant Min_Handler_Ceiling is the
+minimum ceiling priority required for a protected object with a handler
+to ensure that no ceiling violation will occur when that handler is
+invoked.
+
+22/2
+{AI95-00307-01AI95-00307-01} As part of the finalization of an object of
+type Timer, the timer is cleared.
+
+23/2
+{AI95-00307-01AI95-00307-01} For all the subprograms defined in this
+package, Tasking_Error is raised if the task identified by TM.T.all has
+terminated, and Program_Error is raised if the value of TM.T.all is
+Task_Identification.Null_Task_Id.
+
+24/2
+{AI95-00307-01AI95-00307-01} An exception propagated from a handler
+invoked as part of the expiration of a timer has no effect.
+
+ _Erroneous Execution_
+
+25/2
+{AI95-00307-01AI95-00307-01} For a call of any of the subprograms
+defined in this package, if the task identified by TM.T.all no longer
+exists, the execution of the program is erroneous.
+
+ _Implementation Requirements_
+
+26/2
+{AI95-00307-01AI95-00307-01} For a given Timer object, the
+implementation shall perform the operations declared in this package
+atomically with respect to any of these operations on the same Timer
+object. The replacement of a handler by a call of Set_Handler shall be
+performed atomically with respect to the execution of the handler.
+
+26.a/2
+ Reason: This prevents various race conditions. In particular
+ it ensures that if an event occurs when Set_Handler is
+ changing the handler then either the new or old handler is
+ executed in response to the appropriate event. It is never
+ possible for a new handler to be executed in response to an
+ old event
+
+27/2
+{AI95-00307-01AI95-00307-01} When an object of type Timer is finalized,
+the system resources used by the timer shall be deallocated.
+
+ _Implementation Permissions_
+
+28/3
+{AI95-00307-01AI95-00307-01} {AI05-0264-1AI05-0264-1} Implementations
+may limit the number of timers that can be defined for each task. If
+this limit is exceeded, then Timer_Resource_Error is raised.
+
+ NOTES
+
+29/2
+ 43 {AI95-00307-01AI95-00307-01} A Timer_Handler can be associated
+ with several Timer objects.
+
+ _Extensions to Ada 95_
+
+29.a/2
+ {AI95-00307-01AI95-00307-01} The package Execution_Time.Timers
+ is new.
+
+\1f
+File: aarm2012.info, Node: D.14.2, Next: D.14.3, Prev: D.14.1, Up: D.14
+
+D.14.2 Group Execution Time Budgets
+-----------------------------------
+
+1/3
+{AI95-00354-01AI95-00354-01} {AI05-0299-1AI05-0299-1} This subclause
+describes a language-defined package to assign execution time budgets to
+groups of tasks.
+
+ _Static Semantics_
+
+2/2
+{AI95-00354-01AI95-00354-01} The following language-defined library
+package exists:
+
+3/3
+ {AI05-0169-1AI05-0169-1} with System;
+ with System.Multiprocessors;
+ package Ada.Execution_Time.Group_Budgets is
+
+4/3
+ {AI05-0092-1AI05-0092-1} {AI05-0169-1AI05-0169-1} type Group_Budget(CPU : System.Multiprocessors.CPU :=
+ System.Multiprocessors.CPU'First)
+ is tagged limited private;
+
+5/2
+ type Group_Budget_Handler is access
+ protected procedure (GB : in out Group_Budget);
+
+6/2
+ type Task_Array is array (Positive range <>) of
+ Ada.Task_Identification.Task_Id;
+
+7/2
+ Min_Handler_Ceiling : constant System.Any_Priority :=
+ implementation-defined;
+
+7.a.1/3
+ Implementation defined: The value of Min_Handler_Ceiling in
+ Execution_Time.Group_Budgets.
+
+8/2
+ procedure Add_Task (GB : in out Group_Budget;
+ T : in Ada.Task_Identification.Task_Id);
+ procedure Remove_Task (GB: in out Group_Budget;
+ T : in Ada.Task_Identification.Task_Id);
+ function Is_Member (GB : Group_Budget;
+ T : Ada.Task_Identification.Task_Id) return Boolean;
+ function Is_A_Group_Member
+ (T : Ada.Task_Identification.Task_Id) return Boolean;
+ function Members (GB : Group_Budget) return Task_Array;
+
+9/2
+ procedure Replenish (GB : in out Group_Budget; To : in Time_Span);
+ procedure Add (GB : in out Group_Budget; Interval : in Time_Span);
+ function Budget_Has_Expired (GB : Group_Budget) return Boolean;
+ function Budget_Remaining (GB : Group_Budget) return Time_Span;
+
+10/2
+ procedure Set_Handler (GB : in out Group_Budget;
+ Handler : in Group_Budget_Handler);
+ function Current_Handler (GB : Group_Budget)
+ return Group_Budget_Handler;
+ procedure Cancel_Handler (GB : in out Group_Budget;
+ Cancelled : out Boolean);
+
+11/2
+ Group_Budget_Error : exception;
+
+12/2
+ private
+ -- not specified by the language
+ end Ada.Execution_Time.Group_Budgets;
+
+13/2
+{AI95-00354-01AI95-00354-01} The type Group_Budget represents an
+execution time budget to be used by a group of tasks. The type
+Group_Budget needs finalization (see *note 7.6::). A task can belong to
+at most one group. Tasks of any priority can be added to a group.
+
+14/2
+{AI95-00354-01AI95-00354-01} An object of type Group_Budget has an
+associated nonnegative value of type Time_Span known as its budget,
+which is initially Time_Span_Zero. The type Group_Budget_Handler
+identifies a protected procedure to be executed by the implementation
+when the budget is exhausted, that is, reaches zero. Such a protected
+procedure is called a handler.
+
+15/2
+{AI95-00354-01AI95-00354-01} An object of type Group_Budget also
+includes a handler, which is a value of type Group_Budget_Handler. The
+handler of the object is said to be set if it is not null and cleared
+otherwise. The handler of all Group_Budget objects is initially
+cleared.
+
+15.a/2
+ Discussion: Type Group_Budget is tagged. This makes it
+ possible to share a handler between several events. In simple
+ cases, 'Access can be used to compare the parameter with a
+ specific group budget object (this works because a tagged type
+ is a by-reference type). In more complex cases, a type
+ extension of type Group_Budget can be declared; a double type
+ conversion can be used to access the extension data. An
+ example of how this can be done can be found for the similar
+ type Timing_Event, see *note D.15::.
+
+ _Dynamic Semantics_
+
+16/2
+{AI95-00354-01AI95-00354-01} The procedure Add_Task adds the task
+identified by T to the group GB; if that task is already a member of
+some other group, Group_Budget_Error is raised.
+
+17/2
+{AI95-00354-01AI95-00354-01} The procedure Remove_Task removes the task
+identified by T from the group GB; if that task is not a member of the
+group GB, Group_Budget_Error is raised. After successful execution of
+this procedure, the task is no longer a member of any group.
+
+18/3
+{AI95-00354-01AI95-00354-01} {AI05-0264-1AI05-0264-1} The function
+Is_Member returns True if the task identified by T is a member of the
+group GB; otherwise, it returns False.
+
+19/3
+{AI95-00354-01AI95-00354-01} {AI05-0264-1AI05-0264-1} The function
+Is_A_Group_Member returns True if the task identified by T is a member
+of some group; otherwise, it returns False.
+
+20/2
+{AI95-00354-01AI95-00354-01} The function Members returns an array of
+values of type Task_Identification.Task_Id identifying the members of
+the group GB. The order of the components of the array is unspecified.
+
+21/3
+{AI95-00354-01AI95-00354-01} {AI05-0092-1AI05-0092-1}
+{AI05-0169-1AI05-0169-1} The procedure Replenish loads the group budget
+GB with To as the Time_Span value. The exception Group_Budget_Error is
+raised if the Time_Span value To is nonpositive. Any execution on CPU
+of any member of the group of tasks results in the budget counting down,
+unless exhausted. When the budget becomes exhausted (reaches
+Time_Span_Zero), the associated handler is executed if the handler of
+group budget GB is set. Nevertheless, the tasks continue to execute.
+
+22/2
+{AI95-00354-01AI95-00354-01} The procedure Add modifies the budget of
+the group GB. A positive value for Interval increases the budget. A
+negative value for Interval reduces the budget, but never below
+Time_Span_Zero. A zero value for Interval has no effect. A call of
+procedure Add that results in the value of the budget going to
+Time_Span_Zero causes the associated handler to be executed if the
+handler of the group budget GB is set.
+
+23/3
+{AI95-00354-01AI95-00354-01} {AI05-0264-1AI05-0264-1} The function
+Budget_Has_Expired returns True if the budget of group GB is exhausted
+(equal to Time_Span_Zero); otherwise, it returns False.
+
+24/2
+{AI95-00354-01AI95-00354-01} The function Budget_Remaining returns the
+remaining budget for the group GB. If the budget is exhausted it returns
+Time_Span_Zero. This is the minimum value for a budget.
+
+25/3
+{AI95-00354-01AI95-00354-01} {AI05-0264-1AI05-0264-1} The procedure
+Set_Handler associates the handler Handler with the Group_Budget GB: if
+Handler is null, the handler of Group_Budget is cleared; otherwise, it
+is set.
+
+26/2
+{AI95-00354-01AI95-00354-01} A call of Set_Handler for a Group_Budget
+that already has a handler set replaces the handler; if Handler is not
+null, the handler for Group_Budget remains set.
+
+27/3
+{AI95-00354-01AI95-00354-01} {AI05-0264-1AI05-0264-1} The function
+Current_Handler returns the handler associated with the group budget GB
+if the handler for that group budget is set; otherwise, it returns null.
+
+28/3
+{AI95-00354-01AI95-00354-01} {AI05-0264-1AI05-0264-1} The procedure
+Cancel_Handler clears the handler for the group budget if it is set.
+Cancelled is assigned True if the handler for the group budget was set
+prior to it being cleared; otherwise, it is assigned False.
+
+29/2
+{AI95-00354-01AI95-00354-01} The constant Min_Handler_Ceiling is the
+minimum ceiling priority required for a protected object with a handler
+to ensure that no ceiling violation will occur when that handler is
+invoked.
+
+30/2
+{AI95-00354-01AI95-00354-01} The precision of the accounting of task
+execution time to a Group_Budget is the same as that defined for
+execution-time clocks from the parent package.
+
+31/2
+{AI95-00354-01AI95-00354-01} As part of the finalization of an object of
+type Group_Budget all member tasks are removed from the group identified
+by that object.
+
+32/3
+{AI95-00354-01AI95-00354-01} {AI05-0264-1AI05-0264-1} If a task is a
+member of a Group_Budget when it terminates, then as part of the
+finalization of the task it is removed from the group.
+
+33/2
+{AI95-00354-01AI95-00354-01} For all the operations defined in this
+package, Tasking_Error is raised if the task identified by T has
+terminated, and Program_Error is raised if the value of T is
+Task_Identification.Null_Task_Id.
+
+34/2
+{AI95-00354-01AI95-00354-01} An exception propagated from a handler
+invoked when the budget of a group of tasks becomes exhausted has no
+effect.
+
+ _Erroneous Execution_
+
+35/2
+{AI95-00354-01AI95-00354-01} For a call of any of the subprograms
+defined in this package, if the task identified by T no longer exists,
+the execution of the program is erroneous.
+
+ _Implementation Requirements_
+
+36/2
+{AI95-00354-01AI95-00354-01} For a given Group_Budget object, the
+implementation shall perform the operations declared in this package
+atomically with respect to any of these operations on the same
+Group_Budget object. The replacement of a handler, by a call of
+Set_Handler, shall be performed atomically with respect to the execution
+of the handler.
+
+36.a/2
+ Reason: This prevents various race conditions. In particular
+ it ensures that if the budget is exhausted when Set_Handler is
+ changing the handler then either the new or old handler is
+ executed and the exhausting event is not lost.
+
+ NOTES
+
+37/2
+ 44 {AI95-00354-01AI95-00354-01} Clearing or setting of the handler
+ of a group budget does not change the current value of the budget.
+ Exhaustion or loading of a budget does not change whether the
+ handler of the group budget is set or cleared.
+
+38/2
+ 45 {AI95-00354-01AI95-00354-01} A Group_Budget_Handler can be
+ associated with several Group_Budget objects.
+
+ _Extensions to Ada 95_
+
+38.a/2
+ {AI95-00354-01AI95-00354-01} The package
+ Execution_Time.Group_Budgets is new.
+
+ _Inconsistencies With Ada 2005_
+
+38.b/3
+ {AI05-0169-1AI05-0169-1} A Group_Budget is now defined to work
+ on a single processor. If an implementation managed to make
+ this package work for programs running on a multiprocessor
+ system, and a program depends on that fact, it could fail when
+ ported to Ada 2012. We believe it is unlikely that such an
+ implementation exists because of the difficulty of signalling
+ other processors when the time reaches zero; in any case,
+ depending on such an implementation is not portable.
+
+\1f
+File: aarm2012.info, Node: D.14.3, Prev: D.14.2, Up: D.14
+
+D.14.3 Execution Time of Interrupt Handlers
+-------------------------------------------
+
+1/3
+{AI05-0170-1AI05-0170-1} {AI05-0299-1AI05-0299-1} This subclause
+describes a language-defined package to measure the execution time of
+interrupt handlers.
+
+ _Static Semantics_
+
+2/3
+{AI05-0170-1AI05-0170-1} The following language-defined library package
+exists:
+
+3/3
+ with Ada.Interrupts;
+ package Ada.Execution_Time.Interrupts is
+ function Clock (Interrupt : Ada.Interrupts.Interrupt_Id)
+ return CPU_Time;
+ function Supported (Interrupt : Ada.Interrupts.Interrupt_Id)
+ return Boolean;
+ end Ada.Execution_Time.Interrupts;
+
+4/3
+{AI05-0170-1AI05-0170-1} The execution time or CPU time of a given
+interrupt Interrupt is defined as the time spent by the system executing
+interrupt handlers identified by Interrupt, including the time spent
+executing run-time or system services on its behalf. The mechanism used
+to measure execution time is implementation defined. Time spent
+executing interrupt handlers is distinct from time spent executing any
+task.
+
+4.a/3
+ Discussion: The implementation-defined mechanism here is the
+ same as that covered by the Documentation Requirements of
+ *note D.14::, so we don't repeat that requirement here.
+
+5/3
+{AI05-0170-1AI05-0170-1} For each interrupt, the execution time value is
+initially set to zero.
+
+ _Dynamic Semantics_
+
+6/3
+{AI05-0170-1AI05-0170-1} The function Clock returns the current
+cumulative execution time of the interrupt identified by Interrupt. If
+Separate_Interrupt_Clocks_Supported is set to False the function raises
+Program_Error.
+
+7/3
+{AI05-0170-1AI05-0170-1} {AI05-0264-1AI05-0264-1} The function Supported
+returns True if the implementation is monitoring the execution time of
+the interrupt identified by Interrupt; otherwise, it returns False. For
+any Interrupt_Id Interrupt for which Supported(Interrupt) returns False,
+the function Clock(Interrupt) will return a value equal to
+Ada.Execution_Time.Time_Of(0).
+
+ _Extensions to Ada 2005_
+
+7.a/3
+ {AI05-0170-1AI05-0170-1} The package Execution_Time.Interrupts
+ is new.
+
+\1f
+File: aarm2012.info, Node: D.15, Next: D.16, Prev: D.14, Up: Annex D
+
+D.15 Timing Events
+==================
+
+1/3
+{AI95-00297-01AI95-00297-01} {AI05-0299-1AI05-0299-1} This subclause
+describes a language-defined package to allow user-defined protected
+procedures to be executed at a specified time without the need for a
+task or a delay statement.
+
+ _Static Semantics_
+
+2/2
+{AI95-00297-01AI95-00297-01} The following language-defined library
+package exists:
+
+3/2
+ package Ada.Real_Time.Timing_Events is
+
+4/2
+ type Timing_Event is tagged limited private;
+ type Timing_Event_Handler
+ is access protected procedure (Event : in out Timing_Event);
+
+5/2
+ procedure Set_Handler (Event : in out Timing_Event;
+ At_Time : in Time;
+ Handler : in Timing_Event_Handler);
+ procedure Set_Handler (Event : in out Timing_Event;
+ In_Time : in Time_Span;
+ Handler : in Timing_Event_Handler);
+ function Current_Handler (Event : Timing_Event)
+ return Timing_Event_Handler;
+ procedure Cancel_Handler (Event : in out Timing_Event;
+ Cancelled : out Boolean);
+
+6/2
+ function Time_Of_Event (Event : Timing_Event) return Time;
+
+7/2
+ private
+ ... -- not specified by the language
+ end Ada.Real_Time.Timing_Events;
+
+8/2
+{AI95-00297-01AI95-00297-01} The type Timing_Event represents a time in
+the future when an event is to occur. The type Timing_Event needs
+finalization (see *note 7.6::).
+
+9/2
+{AI95-00297-01AI95-00297-01} An object of type Timing_Event is said to
+be set if it is associated with a nonnull value of type
+Timing_Event_Handler and cleared otherwise. All Timing_Event objects
+are initially cleared.
+
+10/2
+{AI95-00297-01AI95-00297-01} The type Timing_Event_Handler identifies a
+protected procedure to be executed by the implementation when the timing
+event occurs. Such a protected procedure is called a handler.
+
+10.a/2
+ Discussion: Type Timing_Event is tagged. This makes it
+ possible to share a handler between several events. In simple
+ cases, 'Access can be used to compare the parameter with a
+ specific timing event object (this works because a tagged type
+ is a by-reference type). In more complex cases, a type
+ extension of type Timing_Event can be declared; a double type
+ conversion can be used to access the extension data. For
+ example:
+
+10.b/2
+ type Toaster_Timing_Event is new Timing_Event with record
+ Slot : Natural;
+ end record;
+
+10.c/2
+ ...
+
+10.d/2
+ protected body Toaster is
+
+10.e/2
+ procedure Timer (Event : in out Timing_Event) is
+ begin
+ Pop_Up_Toast (Toaster_Timing_Event(Timing_Event'Class(Event)).Slot);
+ end Timer;
+
+10.f/2
+ ...
+ end Toaster;
+
+10.g/2
+ The extra conversion to the class-wide type is necessary to
+ make the conversions legal. While this usage is clearly ugly,
+ we think that the need for this sort of usage will be rare, so
+ we can live with it. It's certainly better than having no way
+ to associate data with an event.
+
+ _Dynamic Semantics_
+
+11/3
+{AI95-00297-01AI95-00297-01} {AI05-0264-1AI05-0264-1} The procedures
+Set_Handler associate the handler Handler with the event Event: if
+Handler is null, the event is cleared; otherwise, it is set. The first
+procedure Set_Handler sets the execution time for the event to be
+At_Time. The second procedure Set_Handler sets the execution time for
+the event to be Real_Time.Clock + In_Time.
+
+12/2
+{AI95-00297-01AI95-00297-01} A call of a procedure Set_Handler for an
+event that is already set replaces the handler and the time of
+execution; if Handler is not null, the event remains set.
+
+13/2
+{AI95-00297-01AI95-00297-01} As soon as possible after the time set for
+the event, the handler is executed, passing the event as parameter. The
+handler is only executed if the timing event is in the set state at the
+time of execution. The initial action of the execution of the handler
+is to clear the event.
+
+13.a/2
+ Reason: The second sentence of this paragraph is because of a
+ potential race condition. The time might expire and yet
+ before the handler is executed, some task could call
+ Cancel_Handler (or equivalently call Set_Handler with a null
+ parameter) and thus clear the handler.
+
+14/2
+{AI95-00297-01AI95-00297-01} If the Ceiling_Locking policy (see *note
+D.3::) is in effect when a procedure Set_Handler is called, a check is
+made that the ceiling priority of Handler.all is
+Interrupt_Priority'Last. If the check fails, Program_Error is raised.
+
+15/3
+{AI95-00297-01AI95-00297-01} {AI05-0094-1AI05-0094-1}
+{AI05-0264-1AI05-0264-1} If a procedure Set_Handler is called with zero
+or negative In_Time or with At_Time indicating a time in the past, then
+the handler is executed as soon as possible after the completion of the
+call of Set_Handler.
+
+15.a/3
+ Ramification: {AI05-0094-1AI05-0094-1} The handler will still
+ be executed. Under no circumstances is a scheduled call of a
+ handler lost.
+
+15.b/3
+ Discussion: {AI05-0094-1AI05-0094-1} We say "as soon as
+ possible" so that we do not deadlock if we are executing the
+ handler when Set_Handler is called. In that case, the current
+ invocation of the handler must complete before the new handler
+ can start executing.
+
+16/3
+{AI95-00297-01AI95-00297-01} {AI05-0264-1AI05-0264-1} The function
+Current_Handler returns the handler associated with the event Event if
+that event is set; otherwise, it returns null.
+
+17/3
+{AI95-00297-01AI95-00297-01} {AI05-0264-1AI05-0264-1} The procedure
+Cancel_Handler clears the event if it is set. Cancelled is assigned
+True if the event was set prior to it being cleared; otherwise, it is
+assigned False.
+
+18/3
+{AI95-00297-01AI95-00297-01} {AI05-0264-1AI05-0264-1} The function
+Time_Of_Event returns the time of the event if the event is set;
+otherwise, it returns Real_Time.Time_First.
+
+19/2
+{AI95-00297-01AI95-00297-01} As part of the finalization of an object of
+type Timing_Event, the Timing_Event is cleared.
+
+19.a/2
+ Implementation Note: This is the only finalization defined by
+ the language that has a visible effect; but an implementation
+ may have other finalization that it needs to perform.
+ Implementations need to ensure that the event is cleared
+ before anything else is finalized that would prevent a set
+ event from being triggered.
+
+20/2
+{AI95-00297-01AI95-00297-01} If several timing events are set for the
+same time, they are executed in FIFO order of being set.
+
+21/2
+{AI95-00297-01AI95-00297-01} An exception propagated from a handler
+invoked by a timing event has no effect.
+
+ _Implementation Requirements_
+
+22/2
+{AI95-00297-01AI95-00297-01} For a given Timing_Event object, the
+implementation shall perform the operations declared in this package
+atomically with respect to any of these operations on the same
+Timing_Event object. The replacement of a handler by a call of
+Set_Handler shall be performed atomically with respect to the execution
+of the handler.
+
+22.a/2
+ Reason: This prevents various race conditions. In particular
+ it ensures that if an event occurs when Set_Handler is
+ changing the handler then either the new or old handler is
+ executed in response to the appropriate event. It is never
+ possible for a new handler to be executed in response to an
+ old event.
+
+ _Metrics_
+
+23/2
+{AI95-00297-01AI95-00297-01} The implementation shall document the
+following metric:
+
+24/3
+ * {AI05-0210-1AI05-0210-1} An upper bound on the lateness of the
+ execution of a handler. That is, the maximum time between the time
+ specified for the event and when a handler is actually invoked
+ assuming no other handler or task is executing during this
+ interval.
+
+24.a/2
+ Documentation Requirement: The metrics for timing events.
+
+ _Implementation Advice_
+
+25/2
+{AI95-00297-01AI95-00297-01} The protected handler procedure should be
+executed directly by the real-time clock interrupt mechanism.
+
+25.a/2
+ Implementation Advice: For a timing event, the handler should
+ be executed directly by the real-time clock interrupt
+ mechanism.
+
+ NOTES
+
+26/2
+ 46 {AI95-00297-01AI95-00297-01} Since a call of Set_Handler is not
+ a potentially blocking operation, it can be called from within a
+ handler.
+
+27/2
+ 47 {AI95-00297-01AI95-00297-01} A Timing_Event_Handler can be
+ associated with several Timing_Event objects.
+
+ _Extensions to Ada 95_
+
+27.a/2
+ {AI95-00297-01AI95-00297-01} The package
+ Real_Time.Timing_Events is new.
+
+ _Wording Changes from Ada 2005_
+
+27.b/3
+ {AI05-0094-1AI05-0094-1} Correction: Reworded to eliminate a
+ deadlock condition if the event time is in the past and a
+ handler is currently executing. This is technically an
+ inconsistency, but only if a program is depending on
+ deadlocking; since it is impossible to imagine how that could
+ be useful, we have not documented this as an inconsistency.
+
+27.c/3
+ {AI05-0210-1AI05-0210-1} Correction: Clarified the metric for
+ lateness of a timing event to exclude interference from other
+ handlers and tasks. This change might change the
+ documentation of an implementation, but not the implementation
+ itself, so there is no inconsistency.
+
+\1f
+File: aarm2012.info, Node: D.16, Prev: D.15, Up: Annex D
+
+D.16 Multiprocessor Implementation
+==================================
+
+1/3
+{AI05-0171-1AI05-0171-1} {AI05-0299-1AI05-0299-1} This subclause allows
+implementations on multiprocessor platforms to be configured.
+
+ _Static Semantics_
+
+2/3
+{AI05-0171-1AI05-0171-1} The following language-defined library package
+exists:
+
+3/3
+ package System.Multiprocessors is
+ pragma Preelaborate(Multiprocessors);
+
+4/3
+ type CPU_Range is range 0 .. implementation-defined;
+ Not_A_Specific_CPU : constant CPU_Range := 0;
+ subtype CPU is CPU_Range range 1 .. CPU_Range'Last;
+
+4.a.1/3
+ Implementation defined: The value of CPU_Range'Last in
+ System.Multiprocessors.
+
+5/3
+ function Number_Of_CPUs return CPU;
+ end System.Multiprocessors;
+
+6/3
+{AI05-0171-1AI05-0171-1} A call of Number_Of_CPUs returns the number of
+processors available to the program. Within a given partition, each
+call on Number_Of_CPUs will return the same value.
+
+7/3
+{AI05-0229-1AI05-0229-1} For a task type (including the anonymous type
+of a single_task_declaration) or subprogram, the following
+language-defined representation aspect may be specified:
+
+8/3
+CPU
+ The aspect CPU is an expression, which shall be of type
+ System.Multiprocessors.CPU_Range.
+
+8.a/3
+ Aspect Description for CPU: Processor on which a given task
+ should run.
+
+ _Legality Rules_
+
+9/3
+{AI05-0171-1AI05-0171-1} {AI05-0229-1AI05-0229-1} If the CPU aspect is
+specified for a subprogram, the expression shall be static.
+
+10/3
+{AI05-0229-1AI05-0229-1} The CPU aspect shall not be specified on a task
+interface type.
+
+ _Dynamic Semantics_
+
+11/3
+{AI05-0171-1AI05-0171-1} {AI05-0229-1AI05-0229-1} The expression
+specified for the CPU aspect of a task is evaluated for each task object
+(see *note 9.1::). The CPU value is then associated with the task
+object whose task declaration specifies the aspect.
+
+12/3
+{AI05-0171-1AI05-0171-1} {AI05-0229-1AI05-0229-1} The CPU aspect has no
+effect if it is specified for a subprogram other than the main
+subprogram; the CPU value is not associated with any task.
+
+13/3
+{AI05-0171-1AI05-0171-1} {AI05-0229-1AI05-0229-1} The CPU value is
+associated with the environment task if the CPU aspect is specified for
+the main subprogram. If the CPU aspect is not specified for the main
+subprogram it is implementation defined on which processor the
+environment task executes.
+
+13.a.1/3
+ Implementation defined: The processor on which the environment
+ task executes in the absence of a value for the aspect CPU.
+
+14/3
+{AI05-0171-1AI05-0171-1} {AI05-0264-1AI05-0264-1} The CPU value
+determines the processor on which the task will activate and execute;
+the task is said to be assigned to that processor. If the CPU value is
+Not_A_Specific_CPU, then the task is not assigned to a processor. A
+task without a CPU aspect specified will activate and execute on the
+same processor as its activating task if the activating task is assigned
+a processor. If the CPU value is not in the range of
+System.Multiprocessors.CPU_Range or is greater than Number_Of_CPUs the
+task is defined to have failed, and it becomes a completed task (see
+*note 9.2::).
+
+ _Extensions to Ada 2005_
+
+14.a/3
+ {AI05-0171-1AI05-0171-1} {AI05-0229-1AI05-0229-1} The package
+ System.Multiprocessors and the CPU aspect are new.
+
+* Menu:
+
+* D.16.1 :: Multiprocessor Dispatching Domains
+
+\1f
+File: aarm2012.info, Node: D.16.1, Up: D.16
+
+D.16.1 Multiprocessor Dispatching Domains
+-----------------------------------------
+
+1/3
+{AI05-0167-1AI05-0167-1} {AI05-0299-1AI05-0299-1} This subclause allows
+implementations on multiprocessor platforms to be partitioned into
+distinct dispatching domains during program startup.
+
+ _Static Semantics_
+
+2/3
+{AI05-0167-1AI05-0167-1} The following language-defined library package
+exists:
+
+3/3
+ with Ada.Real_Time;
+ with Ada.Task_Identification;
+ package System.Multiprocessors.Dispatching_Domains is
+
+4/3
+ Dispatching_Domain_Error : exception;
+
+5/3
+ type Dispatching_Domain (<>) is limited private;
+
+6/3
+ System_Dispatching_Domain : constant Dispatching_Domain;
+
+7/3
+ function Create (First, Last : CPU) return Dispatching_Domain;
+
+8/3
+ function Get_First_CPU (Domain : Dispatching_Domain) return CPU;
+
+9/3
+ function Get_Last_CPU (Domain : Dispatching_Domain) return CPU;
+
+10/3
+ function Get_Dispatching_Domain
+ (T : Ada.Task_Identification.Task_Id :=
+ Ada.Task_Identification.Current_Task)
+ return Dispatching_Domain;
+
+11/3
+ procedure Assign_Task
+ (Domain : in out Dispatching_Domain;
+ CPU : in CPU_Range := Not_A_Specific_CPU;
+ T : in Ada.Task_Identification.Task_Id :=
+ Ada.Task_Identification.Current_Task);
+
+12/3
+ procedure Set_CPU
+ (CPU : in CPU_Range;
+ T : in Ada.Task_Identification.Task_Id :=
+ Ada.Task_Identification.Current_Task);
+
+13/3
+ function Get_CPU
+ (T : Ada.Task_Identification.Task_Id :=
+ Ada.Task_Identification.Current_Task)
+ return CPU_Range;
+
+14/3
+ procedure Delay_Until_And_Set_CPU
+ (Delay_Until_Time : in Ada.Real_Time.Time; CPU : in CPU_Range);
+
+15/3
+ private
+ ... -- not specified by the language
+ end System.Multiprocessors.Dispatching_Domains;
+
+16/3
+{AI05-0167-1AI05-0167-1} The type Dispatching_Domain represents a series
+of processors on which a task may execute. Each processor is contained
+within exactly one Dispatching_Domain. System_Dispatching_Domain
+contains the processor or processors on which the environment task
+executes. At program start-up all processors are contained within
+System_Dispatching_Domain.
+
+17/3
+{AI05-0167-1AI05-0167-1} For a task type (including the anonymous type
+of a single_task_declaration), the following language-defined
+representation aspect may be specified:
+
+18/3
+Dispatching_Domain
+ The value of aspect Dispatching_Domain is an expression,
+ which shall be of type
+ Dispatching_Domains.Dispatching_Domain. This aspect is
+ the domain to which the task (or all objects of the task
+ type) are assigned.
+
+18.a/3
+ Aspect Description for Dispatching_Domain: Domain (group of
+ processors) on which a given task should run.
+
+ _Legality Rules_
+
+19/3
+{AI05-0167-1AI05-0167-1} The Dispatching_Domain aspect shall not be
+specified for a task interface.
+
+ _Dynamic Semantics_
+
+20/3
+{AI05-0167-1AI05-0167-1} The expression specified for the
+Dispatching_Domain aspect of a task is evaluated for each task object
+(see *note 9.1::). The Dispatching_Domain value is then associated with
+the task object whose task declaration specifies the aspect.
+
+21/3
+{AI05-0167-1AI05-0167-1} If a task is not explicitly assigned to any
+domain, it is assigned to that of the activating task. A task always
+executes on some CPU in its domain.
+
+22/3
+{AI05-0167-1AI05-0167-1} If both Dispatching_Domain and CPU are
+specified for a task, and the CPU value is not contained within the
+range of processors for the domain (and is not Not_A_Specific_CPU), the
+activation of the task is defined to have failed, and it becomes a
+completed task (see *note 9.2::).
+
+23/3
+{AI05-0167-1AI05-0167-1} The function Create creates and returns a
+Dispatching_Domain containing all the processors in the range First ..
+Last. These processors are removed from System_Dispatching_Domain. A
+call of Create will raise Dispatching_Domain_Error if any designated
+processor is not currently in System_Dispatching_Domain, or if the
+system cannot support a distinct domain over the processors identified,
+or if a processor has a task assigned to it, or if the allocation would
+leave System_Dispatching_Domain empty. A call of Create will raise
+Dispatching_Domain_Error if the calling task is not the environment
+task, or if Create is called after the call to the main subprogram.
+
+24/3
+{AI05-0167-1AI05-0167-1} The function Get_First_CPU returns the first
+CPU in Domain; Get_Last_CPU returns the last one.
+
+25/3
+{AI05-0167-1AI05-0167-1} The function Get_Dispatching_Domain returns the
+Dispatching_Domain on which the task is assigned.
+
+26/3
+{AI05-0167-1AI05-0167-1} {AI05-0278-1AI05-0278-1} A call of the
+procedure Assign_Task assigns task T to the CPU within
+Dispatching_Domain Domain. Task T can now execute only on CPU unless
+CPU designates Not_A_Specific_CPU, in which case it can execute on any
+processor within Domain. The exception Dispatching_Domain_Error is
+propagated if T is already assigned to a Dispatching_Domain other than
+System_Dispatching_Domain, or if CPU is not one of the processors of
+Domain (and is not Not_A_Specific_CPU). A call of Assign_Task is a task
+dispatching point for task T unless T is inside of a protected action,
+in which case the effect on task T is delayed until its next task
+dispatching point. If T is the Current_Task the effect is immediate if
+T is not inside a protected action, otherwise the effect is as soon as
+practical. Assigning a task to System_Dispatching_Domain that is
+already assigned to that domain has no effect.
+
+27/3
+{AI05-0167-1AI05-0167-1} {AI05-0278-1AI05-0278-1} A call of procedure
+Set_CPU assigns task T to the CPU. Task T can now execute only on CPU,
+unless CPU designates Not_A_Specific_CPU, in which case it can execute
+on any processor within its Dispatching_Domain. The exception
+Dispatching_Domain_Error is propagated if CPU is not one of the
+processors of the Dispatching_Domain on which T is assigned (and is not
+Not_A_Specific_CPU). A call of Set_CPU is a task dispatching point for
+task T unless T is inside of a protected action, in which case the
+effect on task T is delayed until its next task dispatching point. If T
+is the Current_Task the effect is immediate if T is not inside a
+protected action, otherwise the effect is as soon as practical.
+
+28/3
+{AI05-0167-1AI05-0167-1} The function Get_CPU returns the processor
+assigned to task T, or Not_A_Specific_CPU if the task is not assigned to
+a processor.
+
+29/3
+{AI05-0167-1AI05-0167-1} A call of Delay_Until_And_Set_CPU delays the
+calling task for the designated time and then assigns the task to the
+specified processor when the delay expires. The exception
+Dispatching_Domain_Error is propagated if P is not one of the processors
+of the calling task's Dispatching_Domain (and is not
+Not_A_Specific_CPU).
+
+ _Implementation Requirements_
+
+30/3
+{AI05-0167-1AI05-0167-1} The implementation shall perform the operations
+Assign_Task, Set_CPU, Get_CPU and Delay_Until_And_Set_CPU atomically
+with respect to any of these operations on the same dispatching_domain,
+processor or task.
+
+ _Implementation Advice_
+
+31/3
+{AI05-0167-1AI05-0167-1} Each dispatching domain should have separate
+and disjoint ready queues.
+
+31.a/3
+ Implementation Advice: Each dispatching domain should have
+ separate and disjoint ready queues.
+
+ _Documentation Requirements_
+
+32/3
+{AI05-0167-1AI05-0167-1} The implementation shall document the
+processor(s) on which the clock interrupt is handled and hence where
+delay queue and ready queue manipulations occur. For any Interrupt_Id
+whose handler can execute on more than one processor the implementation
+shall also document this set of processors.
+
+32.a/3
+ Documentation Requirement: The processor(s) on which the clock
+ interrupt is handled; the processors on which each
+ Interrupt_Id can be handled.
+
+ _Implementation Permissions_
+
+33/3
+{AI05-0167-1AI05-0167-1} An implementation may limit the number of
+dispatching domains that can be created and raise
+Dispatching_Domain_Error if an attempt is made to exceed this number.
+
+ _Extensions to Ada 2005_
+
+33.a/3
+ {AI05-0167-1AI05-0167-1} {AI05-0278-1AI05-0278-1} The package
+ System.Multiprocessors.Dispatching_Domains and the aspect
+ Dispatching_Domains are new.
+
+\1f
+File: aarm2012.info, Node: Annex E, Next: Annex F, Prev: Annex D, Up: Top
+
+Annex E Distributed Systems
+***************************
+
+1
+[This Annex defines facilities for supporting the implementation of
+distributed systems using multiple partitions working cooperatively as
+part of a single Ada program.]
+
+ _Extensions to Ada 83_
+
+1.a
+ This Annex is new to Ada 95.
+
+ _Post-Compilation Rules_
+
+2
+A distributed system is an interconnection of one or more processing
+nodes (a system resource that has both computational and storage
+capabilities), and zero or more storage nodes (a system resource that
+has only storage capabilities, with the storage addressable by one or
+more processing nodes).
+
+3
+A distributed program comprises one or more partitions that execute
+independently (except when they communicate) in a distributed system.
+
+4
+The process of mapping the partitions of a program to the nodes in a
+distributed system is called configuring the partitions of the program.
+
+ _Implementation Requirements_
+
+5
+The implementation shall provide means for explicitly assigning library
+units to a partition and for the configuring and execution of a program
+consisting of multiple partitions on a distributed system; the means are
+implementation defined.
+
+5.a
+ Implementation defined: The means for creating and executing
+ distributed programs.
+
+ _Implementation Permissions_
+
+6
+An implementation may require that the set of processing nodes of a
+distributed system be homogeneous.
+
+ NOTES
+
+7
+ 1 The partitions comprising a program may be executed on
+ differently configured distributed systems or on a nondistributed
+ system without requiring recompilation. A distributed program may
+ be partitioned differently from the same set of library units
+ without recompilation. The resulting execution is semantically
+ equivalent.
+
+8
+ 2 A distributed program retains the same type safety as the
+ equivalent single partition program.
+
+* Menu:
+
+* E.1 :: Partitions
+* E.2 :: Categorization of Library Units
+* E.3 :: Consistency of a Distributed System
+* E.4 :: Remote Subprogram Calls
+* E.5 :: Partition Communication Subsystem
+
+\1f
+File: aarm2012.info, Node: E.1, Next: E.2, Up: Annex E
+
+E.1 Partitions
+==============
+
+1
+[The partitions of a distributed program are classified as either active
+or passive.]
+
+ _Post-Compilation Rules_
+
+2
+An active partition is a partition as defined in *note 10.2::. A
+passive partition is a partition that has no thread of control of its
+own, whose library units are all preelaborated, and whose data and
+subprograms are accessible to one or more active partitions.
+
+2.a
+ Discussion: In most situations, a passive partition does not
+ execute, and does not have a "real" environment task. Any
+ execution involved in its elaboration and initialization
+ occurs before it comes into existence in a distributed program
+ (like most preelaborated entities). Likewise, there is no
+ concrete meaning to passive partition termination.
+
+3
+A passive partition shall include only library_items that either are
+declared pure or are shared passive (see *note 10.2.1:: and *note
+E.2.1::).
+
+4
+An active partition shall be configured on a processing node. A passive
+partition shall be configured either on a storage node or on a
+processing node.
+
+5
+The configuration of the partitions of a program onto a distributed
+system shall be consistent with the possibility for data references or
+calls between the partitions implied by their semantic dependences. Any
+reference to data or call of a subprogram across partitions is called a
+remote access.
+
+5.a
+ Discussion: For example, an active partition that includes a
+ unit with a semantic dependence on the declaration of another
+ RCI package of some other active partition has to be connected
+ to that other partition by some sort of a message passing
+ mechanism.
+
+5.b
+ A passive partition that is accessible to an active partition
+ should have its storage addressable to the processor(s) of the
+ active partition. The processor(s) should be able to read and
+ write from/to that storage, as well as to perform
+ "read-modify-write" operations (in order to support entry-less
+ protected objects).
+
+ _Dynamic Semantics_
+
+6
+A library_item is elaborated as part of the elaboration of each
+partition that includes it. If a normal library unit (see *note E.2::)
+has state, then a separate copy of the state exists in each active
+partition that elaborates it. [The state evolves independently in each
+such partition.]
+
+6.a
+ Ramification: Normal library units cannot be included in
+ passive partitions.
+
+7
+[An active partition terminates when its environment task terminates.]
+A partition becomes inaccessible if it terminates or if it is aborted.
+An active partition is aborted when its environment task is aborted. In
+addition, if a partition fails during its elaboration, it becomes
+inaccessible to other partitions. Other implementation-defined events
+can also result in a partition becoming inaccessible.
+
+7.a
+ Implementation defined: Any events that can result in a
+ partition becoming inaccessible.
+
+8/1
+For a prefix D that denotes a library-level declaration, excepting a
+declaration of or within a declared-pure library unit, the following
+attribute is defined:
+
+9
+D'Partition_Id
+ Denotes a value of the type universal_integer that
+ identifies the partition in which D was elaborated. If D
+ denotes the declaration of a remote call interface
+ library unit (see *note E.2.3::) the given partition is
+ the one where the body of D was elaborated.
+
+ _Bounded (Run-Time) Errors_
+
+10/2
+{AI95-00226-01AI95-00226-01} It is a bounded error for there to be
+cyclic elaboration dependences between the active partitions of a single
+distributed program. The possible effects, in each of the partitions
+involved, are deadlock during elaboration, or the raising of
+Communication_Error or Program_Error.
+
+ _Implementation Permissions_
+
+11
+An implementation may allow multiple active or passive partitions to be
+configured on a single processing node, and multiple passive partitions
+to be configured on a single storage node. In these cases, the
+scheduling policies, treatment of priorities, and management of shared
+resources between these partitions are implementation defined.
+
+11.a
+ Implementation defined: The scheduling policies, treatment of
+ priorities, and management of shared resources between
+ partitions in certain cases.
+
+12
+An implementation may allow separate copies of an active partition to be
+configured on different processing nodes, and to provide appropriate
+interactions between the copies to present a consistent state of the
+partition to other active partitions.
+
+12.a
+ Ramification: The language does not specify the nature of
+ these interactions, nor the actual level of consistency
+ preserved.
+
+13
+In an implementation, the partitions of a distributed program need not
+be loaded and elaborated all at the same time; they may be loaded and
+elaborated one at a time over an extended period of time. An
+implementation may provide facilities to abort and reload a partition
+during the execution of a distributed program.
+
+14
+An implementation may allow the state of some of the partitions of a
+distributed program to persist while other partitions of the program
+terminate and are later reinvoked.
+
+ NOTES
+
+15
+ 3 Library units are grouped into partitions after compile time,
+ but before run time. At compile time, only the relevant library
+ unit properties are identified using categorization pragmas.
+
+16
+ 4 The value returned by the Partition_Id attribute can be used as
+ a parameter to implementation-provided subprograms in order to
+ query information about the partition.
+
+ _Wording Changes from Ada 95_
+
+16.a/2
+ {AI95-00226-01AI95-00226-01} Corrected wording so that a
+ partition that has an elaboration problem will either deadlock
+ or raise an exception. While an Ada 95 implementation could
+ allow some partitions to continue to execute, they could be
+ accessing unelaborated data, which is very bad (and erroneous
+ in a practical sense). Therefore, this isn't listed as an
+ inconsistency.
+
+\1f
+File: aarm2012.info, Node: E.2, Next: E.3, Prev: E.1, Up: Annex E
+
+E.2 Categorization of Library Units
+===================================
+
+1
+[Library units can be categorized according to the role they play in a
+distributed program. Certain restrictions are associated with each
+category to ensure that the semantics of a distributed program remain
+close to the semantics for a nondistributed program.]
+
+2/3
+{AI05-0243-1AI05-0243-1} A categorization pragma is a library unit
+pragma (see *note 10.1.5::) that specifies a corresponding
+categorization aspect. A categorization aspect restricts the
+declarations, child units, or semantic dependences of the library unit
+to which it applies. A categorized library unit is a library unit that
+has a categorization aspect that is True.
+
+3/3
+{AI05-0243-1AI05-0243-1} The pragmas Shared_Passive, Remote_Types, and
+Remote_Call_Interface are categorization pragmas, and the associated
+aspects are categorization aspects. In addition, for the purposes of
+this Annex, the aspect Pure (see *note 10.2.1::) is considered a
+categorization aspect and the pragma Pure is considered a categorization
+pragma.
+
+4/3
+{8652/00788652/0078} {AI95-00048-01AI95-00048-01}
+{AI05-0243-1AI05-0243-1} [ A library package or generic library package
+is called a shared passive library unit if the Shared_Passive aspect of
+the unit is True. A library package or generic library package is
+called a remote types library unit if the Remote_Types aspect of the
+unit is True. A library unit is called a remote call interface if the
+Remote_Call_Interface aspect of the unit is True.] A normal library
+unit is one for which no categorization aspect is True.
+
+4.a/3
+ Proof: {AI05-0243-1AI05-0243-1} {AI05-0299-1AI05-0299-1} These
+ terms (other than "normal library unit") are really defined in
+ the following subclauses.
+
+4.a.1/1
+ Ramification: {8652/00788652/0078}
+ {AI95-00048-01AI95-00048-01} A library subprogram can be a
+ remote call interface, but it cannot be a remote types or
+ shared passive library unit.
+
+5/3
+{AI05-0206-1AI05-0206-1} {AI05-0243-1AI05-0243-1}
+{AI05-0269-1AI05-0269-1} {AI05-0299-1AI05-0299-1} [The various
+categories of library units and the associated restrictions are
+described in this and the following subclauses. The categories are
+related hierarchically in that the library units of one category can
+depend semantically only on library units of that category or an earlier
+one in the hierarchy, except that the body of a remote types or remote
+call interface library unit is unrestricted, the declaration of a remote
+types or remote call interface library unit may depend on preelaborated
+normal library units that are mentioned only in private with clauses,
+and all categories can depend on limited views.
+
+6/3
+{AI05-0243-1AI05-0243-1} {AI05-0269-1AI05-0269-1} The overall hierarchy
+(including declared pure) is as follows, with a lower-numbered category
+being "earlier in the hierarchy" in the sense of the previous paragraph:
+
+6.1/3
+ 1. Declared Pure
+
+6.2/3
+ 2. Shared Passive
+
+6.3/3
+ 3. Remote Types
+
+6.4/3
+ 4. Remote Call Interface
+
+6.5/3
+ 5. Normal (no restrictions)
+
+Paragraphs 7 through 11 were deleted.
+
+12
+Declared pure and shared passive library units are preelaborated. The
+declaration of a remote types or remote call interface library unit is
+required to be preelaborable. ]
+
+Paragraph 13 was deleted.
+
+ _Implementation Permissions_
+
+14
+Implementations are allowed to define other categorization pragmas.
+
+ _Wording Changes from Ada 95_
+
+14.a/2
+ {8652/00788652/0078} {AI95-00048-01AI95-00048-01} Corrigendum:
+ Clarified that a library subprogram can be a remote call
+ interface unit.
+
+14.b/2
+ {8652/00798652/0079} {AI95-00208-01AI95-00208-01} Corrigendum:
+ Removed the requirement that types be represented the same in
+ all partitions, because it prevents the definition of
+ heterogeneous distributed systems and goes much further than
+ required.
+
+ _Wording Changes from Ada 2005_
+
+14.c/3
+ {AI05-0206-1AI05-0206-1} {AI05-0299-1AI05-0299-1} We now allow
+ private withs of preelaborated units in Remote Types and
+ Remote Call Interface units; this is documented as an
+ extension in the subclauses where this is defined normatively.
+
+14.d/3
+ {AI05-0243-1AI05-0243-1} {AI05-0299-1AI05-0299-1} We have
+ introduced categorization aspects; these are documented as
+ extensions in the subclauses where they actually are defined.
+
+* Menu:
+
+* E.2.1 :: Shared Passive Library Units
+* E.2.2 :: Remote Types Library Units
+* E.2.3 :: Remote Call Interface Library Units
+
+\1f
+File: aarm2012.info, Node: E.2.1, Next: E.2.2, Up: E.2
+
+E.2.1 Shared Passive Library Units
+----------------------------------
+
+1
+[A shared passive library unit is used for managing global data shared
+between active partitions. The restrictions on shared passive library
+units prevent the data or tasks of one active partition from being
+accessible to another active partition through references implicit in
+objects declared in the shared passive library unit.]
+
+ _Language Design Principles_
+
+1.a
+ The restrictions governing a shared passive library unit are
+ designed to ensure that objects and subprograms declared in
+ the package can be used safely from multiple active
+ partitions, even though the active partitions live in
+ different address spaces, and have separate run-time systems.
+
+ _Syntax_
+
+2
+ The form of a pragma Shared_Passive is as follows:
+
+3
+ pragma Shared_Passive[(library_unit_name)];
+
+ _Legality Rules_
+
+4/3
+{AI05-0243-1AI05-0243-1} A pragma Shared_Passive is used to specify that
+a library unit is a shared passive library unit, namely that the
+Shared_Passive aspect of the library unit is True. The following
+restrictions apply to such a library unit:
+
+4.a/3
+ Aspect Description for Shared_Passive: A given package is used
+ to represent shared memory in a distributed system.
+
+5
+ * [it shall be preelaborable (see *note 10.2.1::);]
+
+5.a
+ Ramification: It cannot contain library-level declarations of
+ protected objects with entries, nor of task objects. Task
+ objects are disallowed because passive partitions don't have
+ any threads of control of their own, nor any run-time system
+ of their own. Protected objects with entries are disallowed
+ because an entry queue contains references to calling tasks,
+ and that would require in effect a pointer from a passive
+ partition back to a task in some active partition.
+
+6/3
+ * {AI05-0243-1AI05-0243-1} it shall depend semantically only upon
+ declared pure or shared passive library_items;
+
+6.a
+ Reason: Shared passive packages cannot depend semantically
+ upon remote types packages because the values of an access
+ type declared in a remote types package refer to the local
+ heap of the active partition including the remote types
+ package.
+
+6.b/3
+ Ramification: {AI05-0243-1AI05-0243-1} We say library_item
+ here, so that limited views are allowed; those are not library
+ units, but they are library_item.
+
+7/1
+ * {8652/00808652/0080} {AI95-00003-01AI95-00003-01} it shall not
+ contain a library-level declaration of an access type that
+ designates a class-wide type, task type, or protected type with
+ entry_declarations.
+
+7.a
+ Reason: These kinds of access types are disallowed because the
+ object designated by an access value of such a type could
+ contain an implicit reference back to the active partition on
+ whose behalf the designated object was created.
+
+8
+Notwithstanding the definition of accessibility given in *note 3.10.2::,
+the declaration of a library unit P1 is not accessible from within the
+declarative region of a shared passive library unit P2, unless the
+shared passive library unit P2 depends semantically on P1.
+
+8.a
+ Discussion: We considered a more complex rule, but dropped it.
+ This is the simplest rule that recognizes that a shared
+ passive package may outlive some other library package, unless
+ it depends semantically on that package. In a nondistributed
+ program, all library packages are presumed to have the same
+ lifetime.
+
+8.b
+ Implementations may define additional pragmas that force two
+ library packages to be in the same partition, or to have the
+ same lifetime, which would allow this rule to be relaxed in
+ the presence of such pragmas.
+
+ _Static Semantics_
+
+9
+A shared passive library unit is preelaborated.
+
+ _Post-Compilation Rules_
+
+10
+A shared passive library unit shall be assigned to at most one partition
+within a given program.
+
+11
+Notwithstanding the rule given in *note 10.2::, a compilation unit in a
+given partition does not need (in the sense of *note 10.2::) the shared
+passive library units on which it depends semantically to be included in
+that same partition; they will typically reside in separate passive
+partitions.
+
+ _Wording Changes from Ada 95_
+
+11.a/2
+ {8652/00808652/0080} {AI95-00003-01AI95-00003-01} Corrigendum:
+ Corrected the wording to allow access types in blocks in
+ shared passive generic packages.
+
+ _Extensions to Ada 2005_
+
+11.b/3
+ {AI05-0243-1AI05-0243-1} Shared_Passive is now a
+ categorization aspect, so it can be specified by an
+ aspect_specification -- although the pragma is still preferred
+ by the Standard.
+
+\1f
+File: aarm2012.info, Node: E.2.2, Next: E.2.3, Prev: E.2.1, Up: E.2
+
+E.2.2 Remote Types Library Units
+--------------------------------
+
+1
+[A remote types library unit supports the definition of types intended
+for use in communication between active partitions.]
+
+ _Language Design Principles_
+
+1.a
+ The restrictions governing a remote types package are similar
+ to those for a declared pure package. However, the
+ restrictions are relaxed deliberately to allow such a package
+ to contain declarations that violate the stateless property of
+ pure packages, though it is presumed that any state-dependent
+ properties are essentially invisible outside the package.
+
+ _Syntax_
+
+2
+ The form of a pragma Remote_Types is as follows:
+
+3
+ pragma Remote_Types[(library_unit_name)];
+
+ _Legality Rules_
+
+4/3
+{AI05-0243-1AI05-0243-1} A pragma Remote_Types is used to specify that a
+library unit is a remote types library unit, namely that the
+Remote_Types aspect of the library unit is True. The following
+restrictions apply to the declaration of such a library unit:
+
+4.a/3
+ Aspect Description for Remote_Types: Types in a given package
+ may be used in remote procedure calls.
+
+5
+ * [it shall be preelaborable;]
+
+6/3
+ * {AI05-0206-1AI05-0206-1} {AI05-0243-1AI05-0243-1} it shall depend
+ semantically only on declared pure library_items, shared passive
+ library units, other remote types library units, or preelaborated
+ normal library units that are mentioned only in private with
+ clauses;
+
+6.a/3
+ Ramification: {AI05-0243-1AI05-0243-1} We say declared pure
+ library_item here, so that (all) limited views are allowed;
+ those are not library units, but they are declared pure
+ library_items.
+
+7
+ * it shall not contain the declaration of any variable within the
+ visible part of the library unit;
+
+7.a
+ Reason: This is essentially a "methodological" restriction. A
+ separate copy of a remote types package is included in each
+ partition that references it, just like a normal package.
+ Nevertheless, a remote types package is thought of as an
+ "essentially pure" package for defining types to be used for
+ interpartition communication, and it could be misleading to
+ declare visible objects when no remote data access is actually
+ being provided.
+
+8/2
+ * {AI95-00240-01AI95-00240-01} {AI95-00366-01AI95-00366-01} the full
+ view of each type declared in the visible part of the library unit
+ that has any available stream attributes shall support external
+ streaming (see *note 13.13.2::).
+
+8.a
+ Reason: This is to prevent the use of the predefined Read and
+ Write attributes of an access type as part of the Read and
+ Write attributes of a visible type.
+
+8.b/2
+ Ramification: {AI95-00366-01AI95-00366-01} Types that do not
+ have available stream attributes are excluded from this rule;
+ that means that attributes do not need to be specified for
+ most limited types. It is only necessary to specify
+ attributes for nonlimited types that have a part that is of
+ any access type, and for extensions of limited types with
+ available stream attributes where the record_extension_part
+ includes a subcomponent of an access type, where the access
+ type does not have specified attributes.
+
+9/3
+{8652/00828652/0082} {AI95-00164-01AI95-00164-01}
+{AI05-0060-1AI05-0060-1} A named access type declared in the visible
+part of a remote types or remote call interface library unit is called a
+remote access type. Such a type shall be:
+
+9.1/1
+ * {8652/00828652/0082} {AI95-00164-01AI95-00164-01} an
+ access-to-subprogram type, or
+
+9.2/3
+ * {8652/00828652/0082} {AI95-00164-01AI95-00164-01}
+ {AI05-0060-1AI05-0060-1} a general access type that designates a
+ class-wide limited private type, a class-wide limited interface
+ type, or a class-wide private extension all of whose ancestors are
+ either private extensions, limited interface types, or limited
+ private types.
+
+9.3/1
+{8652/00818652/0081} {AI95-00004-01AI95-00004-01} A type that is derived
+from a remote access type is also a remote access type.
+
+10
+The following restrictions apply to the use of a remote
+access-to-subprogram type:
+
+11/2
+ * {AI95-00431-01AI95-00431-01} A value of a remote
+ access-to-subprogram type shall be converted only to or from
+ another (subtype-conformant) remote access-to-subprogram type;
+
+12
+ * The prefix of an Access attribute_reference that yields a value of
+ a remote access-to-subprogram type shall statically denote a
+ (subtype-conformant) remote subprogram.
+
+13
+The following restrictions apply to the use of a remote
+access-to-class-wide type:
+
+14/3
+ * {8652/00838652/0083} {AI95-00047-01AI95-00047-01}
+ {AI95-00240-01AI95-00240-01} {AI95-00366-01AI95-00366-01}
+ {AI05-0060-1AI05-0060-1} {AI05-0101-1AI05-0101-1} The primitive
+ subprograms of the corresponding specific type shall only have
+ access parameters if they are controlling formal parameters. The
+ primitive functions of the corresponding specific type shall only
+ have an access result if it is a controlling access result. Each
+ noncontrolling formal parameter and noncontrolling result type
+ shall support external streaming (see *note 13.13.2::);
+
+14.1/3
+ * {AI05-0060-1AI05-0060-1} {AI05-0215-1AI05-0215-1}
+ {AI05-0269-1AI05-0269-1} The corresponding specific type shall not
+ have a primitive procedure with the Synchronization aspect
+ specified unless the synchronization_kind is Optional (see *note
+ 9.5::);
+
+15
+ * A value of a remote access-to-class-wide type shall be explicitly
+ converted only to another remote access-to-class-wide type;
+
+16
+ * A value of a remote access-to-class-wide type shall be dereferenced
+ (or implicitly converted to an anonymous access type) only as part
+ of a dispatching call where the value designates a controlling
+ operand of the call (see *note E.4::, "*note E.4:: Remote
+ Subprogram Calls");
+
+16.1/3
+ * {AI05-0101-1AI05-0101-1} A controlling access result value for a
+ primitive function with any controlling operands of the
+ corresponding specific type shall either be explicitly converted to
+ a remote access-to-class-wide type or be part of a dispatching call
+ where the value designates a controlling operand of the call;
+
+17/2
+ * {AI95-00366-01AI95-00366-01} The Storage_Pool attribute is not
+ defined for a remote access-to-class-wide type; the expected type
+ for an allocator shall not be a remote access-to-class-wide type.
+ A remote access-to-class-wide type shall not be an actual parameter
+ for a generic formal access type. The Storage_Size attribute of a
+ remote access-to-class-wide type yields 0; it is not allowed in an
+ attribute_definition_clause.
+
+17.a/3
+ Reason: {AI05-0005-1AI05-0005-1} All three of these
+ restrictions are because there is no storage pool associated
+ with a remote access-to-class-wide type. The Storage_Size is
+ defined to be 0 so that there is no conflict with the rules
+ for pure units.
+
+ NOTES
+
+18
+ 5 A remote types library unit need not be pure, and the types it
+ defines may include levels of indirection implemented by using
+ access types. User-specified Read and Write attributes (see *note
+ 13.13.2::) provide for sending values of such a type between active
+ partitions, with Write marshalling the representation, and Read
+ unmarshalling any levels of indirection.
+
+19/3
+ 6 {AI05-0060-1AI05-0060-1} The value of a remote
+ access-to-class-wide limited interface can designate an object of a
+ nonlimited type derived from the interface.
+
+20/3
+ 7 {AI05-0060-1AI05-0060-1} A remote access type may designate a
+ class-wide synchronized, protected, or task interface type.
+
+20.a/3
+ Proof: Synchronized, protected, and task interfaces are all
+ considered limited interfaces, see *note 3.9.4::.
+
+ _Incompatibilities With Ada 95_
+
+20.b/3
+ {AI95-00240-01AI95-00240-01} {AI05-0248-1AI05-0248-1}
+ Amendment Correction: The wording was changed from
+ "user-specified" to "available" read and write attributes.
+ (This was then further changed, see below.) This means that
+ an access type with the attributes specified in the private
+ part would originally have been sufficient to allow the access
+ type to be used in a remote type, but that is no longer
+ allowed. Similarly, the attributes of a remote type that has
+ access components have to be specified in the visible part.
+ These changes were made so that the rules were consistent with
+ the rules introduced for the Corrigendum for stream
+ attributes; moreover, legality should not depend on the
+ contents of the private part.
+
+ _Extensions to Ada 95_
+
+20.c/3
+ {AI95-00366-01AI95-00366-01} {AI05-0005-1AI05-0005-1} Remote
+ types that cannot be streamed (that is, have no available
+ stream attributes) do not require the specification of stream
+ attributes. This is necessary so that most extensions of
+ Limited_Controlled do not need stream attributes defined
+ (otherwise there would be a significant incompatibility, as
+ Limited_Controlled would need stream attributes, and then all
+ extensions of it also would need stream attributes).
+
+ _Wording Changes from Ada 95_
+
+20.d/2
+ {8652/00818652/0081} {AI95-00004-01AI95-00004-01} Corrigendum:
+ Added missing wording so that a type derived from a remote
+ access type is also a remote access type.
+
+20.e/2
+ {8652/00838652/0083} {AI95-00047-01AI95-00047-01} Corrigendum:
+ Clarified that user-defined Read and Write attributes are
+ required for the primitive subprograms corresponding to a
+ remote access-to-class-wide type.
+
+20.f/2
+ {8652/00828652/0082} {AI95-00164-01AI95-00164-01} Corrigendum:
+ Added missing wording so that a remote access type can
+ designate an appropriate private extension.
+
+20.g/2
+ {AI95-00366-01AI95-00366-01} Changed the wording to use the
+ newly defined term type that supports external streaming, so
+ that various issues with access types in pure units and
+ implicitly declared attributes for type extensions are
+ properly handled.
+
+20.h/2
+ {AI95-00366-01AI95-00366-01} Defined Storage_Size to be 0 for
+ remote access-to-class-wide types, rather than having it
+ undefined. This eliminates issues with pure units requiring a
+ defined storage size.
+
+20.i/2
+ {AI95-00431-01AI95-00431-01} Corrected the wording so that a
+ value of a local access-to-subprogram type cannot be converted
+ to a remote access-to-subprogram type, as intended (and
+ required by the ACATS).
+
+ _Incompatibilities With Ada 2005_
+
+20.j/3
+ {AI05-0101-1AI05-0101-1} Correction: Added rules for returning
+ of remote access-to-classwide types; this had been missed in
+ the past. While programs that returned unstreamable types
+ from RCI functions were legal, it is not clear what they could
+ have done (as the results could not be marshalled).
+ Similarly, RCI functions that return remote controlling access
+ types could try to save those values, but it is unlikely that
+ a compiler would know how to do that usefully. Thus, it seems
+ unlikely that any real programs will be impacted by these
+ changes.
+
+ _Extensions to Ada 2005_
+
+20.k/3
+ {AI05-0060-1AI05-0060-1} Correction: Clarified that anonymous
+ access types are never remote access types (and can be used in
+ remote types units subject to the normal restrictions). Added
+ wording to allow limited class-wide interfaces to be
+ designated by remote access types.
+
+20.l/3
+ {AI05-0206-1AI05-0206-1} Added wording to allow private withs
+ of preelaborated normal units in the specification of a remote
+ types unit.
+
+20.m/3
+ {AI05-0243-1AI05-0243-1} Remote_Types is now a categorization
+ aspect, so it can be specified by an aspect_specification --
+ although the pragma is still preferred by the Standard.
+
+\1f
+File: aarm2012.info, Node: E.2.3, Prev: E.2.2, Up: E.2
+
+E.2.3 Remote Call Interface Library Units
+-----------------------------------------
+
+1
+[A remote call interface library unit can be used as an interface for
+remote procedure calls (RPCs) (or remote function calls) between active
+partitions.]
+
+ _Language Design Principles_
+
+1.a
+ The restrictions governing a remote call interface library
+ unit are intended to ensure that the values of the actual
+ parameters in a remote call can be meaningfully sent between
+ two active partitions.
+
+ _Syntax_
+
+2
+ The form of a pragma Remote_Call_Interface is as follows:
+
+3
+ pragma Remote_Call_Interface[(library_unit_name)];
+
+4
+ The form of a pragma All_Calls_Remote is as follows:
+
+5
+ pragma All_Calls_Remote[(library_unit_name)];
+
+6
+ A pragma All_Calls_Remote is a library unit pragma.
+
+ _Legality Rules_
+
+7/3
+{8652/00788652/0078} {AI95-00048-01AI95-00048-01}
+{AI05-0243-1AI05-0243-1} A pragma Remote_Call_Interface is used to
+specify that a library unit is a remote call interface (RCI), namely
+that the Remote_Call_Interface aspect of the library unit is True. A
+subprogram declared in the visible part of such a library unit, or
+declared by such a library unit, is called a remote subprogram.
+
+7.a/3
+ Aspect Description for Remote_Call_Interface: Subprograms in a
+ given package may be used in remote procedure calls.
+
+8/3
+{AI05-0206-1AI05-0206-1} {AI05-0243-1AI05-0243-1} The declaration of an
+RCI library unit shall be preelaborable (see *note 10.2.1::), and shall
+depend semantically only upon declared pure library_items, shared
+passive library units, remote types library units, other remote call
+interface library units, or preelaborated normal library units that are
+mentioned only in private with clauses.
+
+8.a/3
+ Ramification: {AI05-0243-1AI05-0243-1} We say declared pure
+ library_item here, so that (all) limited views are allowed;
+ those are not library units, but they are declared pure
+ library_items.
+
+9/1
+{8652/00788652/0078} {AI95-00048-01AI95-00048-01} In addition, the
+following restrictions apply to an RCI library unit:
+
+10/1
+ * {8652/00788652/0078} {AI95-00048-01AI95-00048-01} its visible part
+ shall not contain the declaration of a variable;
+
+10.a/1
+ Reason: {8652/00788652/0078} {AI95-00048-01AI95-00048-01}
+ Remote call interface units do not provide remote data access.
+ A shared passive package has to be used for that.
+
+11/1
+ * {8652/00788652/0078} {AI95-00048-01AI95-00048-01} its visible part
+ shall not contain the declaration of a limited type;
+
+11.a/2
+ Reason: {AI95-00240-01AI95-00240-01}
+ {AI95-00366-01AI95-00366-01} We disallow the declaration of
+ task and protected types, since calling an entry or a
+ protected subprogram implicitly passes an object of a limited
+ type (the target task or protected object). We disallow other
+ limited types since we require that such types have available
+ Read and Write attributes, but we certainly don't want the
+ Read and Write attributes themselves to involve remote calls
+ (thereby defeating their purpose of marshalling the value for
+ remote calls).
+
+12/1
+ * {8652/00788652/0078} {AI95-00048-01AI95-00048-01} its visible part
+ shall not contain a nested generic_declaration;
+
+12.a
+ Reason: This is disallowed because the body of the nested
+ generic would presumably have access to data inside the body
+ of the RCI package, and if instantiated in a different
+ partition, remote data access might result, which is not
+ supported.
+
+13/3
+ * {8652/00788652/0078} {AI95-00048-01AI95-00048-01}
+ {AI05-0229-1AI05-0229-1} it shall not be, nor shall its visible
+ part contain, the declaration of a subprogram for which aspect
+ Inline is True;
+
+14/3
+ * {8652/00788652/0078} {AI95-00048-01AI95-00048-01}
+ {AI95-00240-01AI95-00240-01} {AI95-00366-01AI95-00366-01}
+ {AI05-0101-1AI05-0101-1} it shall not be, nor shall its visible
+ part contain, a subprogram (or access-to-subprogram) declaration
+ whose profile has a parameter or result of a type that does not
+ support external streaming (see *note 13.13.2::);
+
+14.a/3
+ Ramification: {AI05-0101-1AI05-0101-1} No anonymous access
+ types support external streaming, so they are never allowed as
+ parameters or results of RCI subprograms.
+
+15
+ * any public child of the library unit shall be a remote call
+ interface library unit.
+
+15.a
+ Reason: No restrictions apply to the private part of an RCI
+ package, and since a public child can "see" the private part
+ of its parent, such a child must itself have a
+ Remote_Call_Interface pragma, and be assigned to the same
+ partition (see below).
+
+15.b
+ Discussion: We considered making the public child of an RCI
+ package implicitly RCI, but it seemed better to require an
+ explicit pragma to avoid any confusion.
+
+15.c
+ Note that there is no need for a private child to be an RCI
+ package, since it can only be seen from the body of its parent
+ or its siblings, all of which are required to be in the same
+ active partition.
+
+16/3
+{AI05-0229-1AI05-0229-1} A pragma All_Calls_Remote sets the
+All_Calls_Remote representation aspect of the library unit to which the
+pragma applies to the value True. If the All_Calls_Remote aspect of a
+library unit is True, the library unit shall be a remote call interface.
+
+16.a/3
+ Aspect Description for All_Calls_Remote: All remote procedure
+ calls should use the Partition Communication Subsystem, even
+ if they are local.
+
+ _Post-Compilation Rules_
+
+17
+A remote call interface library unit shall be assigned to at most one
+partition of a given program. A remote call interface library unit
+whose parent is also an RCI library unit shall be assigned only to the
+same partition as its parent.
+
+17.a/1
+ Implementation Note: {8652/00788652/0078}
+ {AI95-00048-01AI95-00048-01} The declaration of an RCI unit,
+ with a calling-stub body, is automatically included in all
+ active partitions with compilation units that depend on it.
+ However the whole RCI library unit, including its (non-stub)
+ body, will only be in one of the active partitions.
+
+18
+Notwithstanding the rule given in *note 10.2::, a compilation unit in a
+given partition that semantically depends on the declaration of an RCI
+library unit, needs (in the sense of *note 10.2::) only the declaration
+of the RCI library unit, not the body, to be included in that same
+partition. [Therefore, the body of an RCI library unit is included only
+in the partition to which the RCI library unit is explicitly assigned.]
+
+ _Implementation Requirements_
+
+19/3
+{8652/00788652/0078} {AI95-00048-01AI95-00048-01}
+{AI05-0229-1AI05-0229-1} If aspect All_Calls_Remote is True for a given
+RCI library unit, then the implementation shall route any call to a
+subprogram of the RCI unit from outside the declarative region of the
+unit through the Partition Communication Subsystem (PCS); see *note
+E.5::. Calls to such subprograms from within the declarative region of
+the unit are defined to be local and shall not go through the PCS.
+
+19.a/3
+ Discussion: {8652/00788652/0078} {AI95-00048-01AI95-00048-01}
+ {AI05-0229-1AI05-0229-1} When this aspect is False (or not
+ used), it is presumed that most implementations will make
+ direct calls if the call originates in the same partition as
+ that of the RCI unit. When this aspect is True, all calls
+ from outside the subsystem rooted at the RCI unit are treated
+ like calls from outside the partition, ensuring that the PCS
+ is involved in all such calls (for debugging, redundancy,
+ etc.).
+
+19.b
+ Reason: There is no point to force local calls (or calls from
+ children) to go through the PCS, since on the target system,
+ these calls are always local, and all the units are in the
+ same active partition.
+
+ _Implementation Permissions_
+
+20/3
+{AI05-0243-1AI05-0243-1} An implementation need not support the
+Remote_Call_Interface pragma or aspect nor the All_Calls_Remote pragma.
+[Explicit message-based communication between active partitions can be
+supported as an alternative to RPC.]
+
+20.a
+ Ramification: Of course, it is pointless to support the
+ All_Calls_Remote pragma if the Remote_Call_Interface pragma
+ (or some approximate equivalent) is not supported.
+
+ _Incompatibilities With Ada 95_
+
+20.b/3
+ {AI95-00240-01AI95-00240-01} {AI05-0248-1AI05-0248-1}
+ Amendment Correction: The wording was changed from
+ "user-specified" to "available" read and write attributes.
+ (This was then further changed, see below.) This means that a
+ type with the attributes specified in the private part would
+ originally have been allowed as a formal parameter of an RCI
+ subprogram, but that is no longer allowed. This change was
+ made so that the rules were consistent with the rules
+ introduced for the Corrigendum for stream attributes;
+ moreover, legality should not depend on the contents of the
+ private part.
+
+ _Wording Changes from Ada 95_
+
+20.c/2
+ {8652/00788652/0078} {AI95-00048-01AI95-00048-01} Corrigendum:
+ Changed the wording to allow a library subprogram to be a
+ remote call interface unit.
+
+20.d/2
+ {AI95-00366-01AI95-00366-01} Changed the wording to use the
+ newly defined term type that supports external streaming, so
+ that various issues with access types in pure units and
+ implicitly declared attributes for type extensions are
+ properly handled.
+
+ _Incompatibilities With Ada 2005_
+
+20.e/3
+ {AI05-0101-1AI05-0101-1} Correction: Added a rule to ensure
+ that function results are streamable; this was missing in
+ previous versions of Ada. While programs that returned
+ unstreamable types from RCI functions were legal, it is not
+ clear what they could have done (as the results could not be
+ marshalled). Thus, it seems unlikely that any real programs
+ will be impacted by this change.
+
+ _Extensions to Ada 2005_
+
+20.f/3
+ {AI05-0206-1AI05-0206-1} Added wording to allow private withs
+ of preelaborated normal units in the specification of a remote
+ call interface unit.
+
+20.g/3
+ {AI05-0229-1AI05-0229-1} All_Calls_Remote is now a
+ representation aspect, so it can be specified by an
+ aspect_specification -- although the pragma is still preferred
+ by the Standard.
+
+20.h/3
+ {AI05-0243-1AI05-0243-1} Remote_Call_Interface is now a
+ categorization aspect, so it can be specified by an
+ aspect_specification -- although the pragma is still preferred
+ by the Standard.
+
+\1f
+File: aarm2012.info, Node: E.3, Next: E.4, Prev: E.2, Up: Annex E
+
+E.3 Consistency of a Distributed System
+=======================================
+
+1/3
+{AI05-0299-1AI05-0299-1} [This subclause defines attributes and rules
+associated with verifying the consistency of a distributed program.]
+
+ _Language Design Principles_
+
+1.a/3
+ {AI05-0248-1AI05-0248-1} The rules guarantee that remote call
+ interface and shared passive library units are consistent
+ among all partitions prior to the execution of a distributed
+ program, so that the semantics of the distributed program are
+ well defined.
+
+ _Static Semantics_
+
+2/1
+For a prefix P that statically denotes a program unit, the following
+attributes are defined:
+
+3
+P'Version
+ Yields a value of the predefined type String that
+ identifies the version of the compilation unit that
+ contains the declaration of the program unit.
+
+4
+P'Body_Version
+ Yields a value of the predefined type String that
+ identifies the version of the compilation unit that
+ contains the body (but not any subunits) of the program
+ unit.
+
+5/1
+{8652/00848652/0084} {AI95-00104-01AI95-00104-01} The version of a
+compilation unit changes whenever the compilation unit changes in a
+semantically significant way. This International Standard does not
+define the exact meaning of "semantically significant". It is
+unspecified whether there are other events (such as recompilation) that
+result in the version of a compilation unit changing.
+
+5.a/1
+ This paragraph was deleted.
+
+5.1/1
+{8652/00848652/0084} {AI95-00104-01AI95-00104-01} If P is not a library
+unit, and P has no completion, then P'Body_Version returns the
+Body_Version of the innermost program unit enclosing the declaration of
+P. If P is a library unit, and P has no completion, then P'Body_Version
+returns a value that is different from Body_Version of any version of P
+that has a completion.
+
+ _Bounded (Run-Time) Errors_
+
+6
+In a distributed program, a library unit is consistent if the same
+version of its declaration is used throughout. It is a bounded error to
+elaborate a partition of a distributed program that contains a
+compilation unit that depends on a different version of the declaration
+of a shared passive or RCI library unit than that included in the
+partition to which the shared passive or RCI library unit was assigned.
+As a result of this error, Program_Error can be raised in one or both
+partitions during elaboration; in any case, the partitions become
+inaccessible to one another.
+
+6.a
+ Ramification: Because a version changes if anything on which
+ it depends undergoes a version change, requiring consistency
+ for shared passive and remote call interface library units is
+ sufficient to ensure consistency for the declared pure and
+ remote types library units that define the types used for the
+ objects and parameters through which interpartition
+ communication takes place.
+
+6.b
+ Note that we do not require matching Body_Versions; it is
+ irrelevant for shared passive and remote call interface
+ packages, since only one copy of their body exists in a
+ distributed program (in the absence of implicit replication),
+ and we allow the bodies to differ for declared pure and remote
+ types packages from partition to partition, presuming that the
+ differences are due to required error corrections that took
+ place during the execution of a long-running distributed
+ program. The Body_Version attribute provides a means for
+ performing stricter consistency checks.
+
+ _Wording Changes from Ada 95_
+
+6.c/2
+ {8652/00848652/0084} {AI95-00104-01AI95-00104-01} Corrigendum:
+ Clarified the meaning of 'Version and 'Body_Version.
+
+\1f
+File: aarm2012.info, Node: E.4, Next: E.5, Prev: E.3, Up: Annex E
+
+E.4 Remote Subprogram Calls
+===========================
+
+1
+A remote subprogram call is a subprogram call that invokes the execution
+of a subprogram in another partition. The partition that originates the
+remote subprogram call is the calling partition, and the partition that
+executes the corresponding subprogram body is the called partition.
+Some remote procedure calls are allowed to return prior to the
+completion of subprogram execution. These are called asynchronous
+remote procedure calls.
+
+2
+There are three different ways of performing a remote subprogram call:
+
+3
+ * As a direct call on a (remote) subprogram explicitly declared in a
+ remote call interface;
+
+4
+ * As an indirect call through a value of a remote
+ access-to-subprogram type;
+
+5
+ * As a dispatching call with a controlling operand designated by a
+ value of a remote access-to-class-wide type.
+
+6
+The first way of calling corresponds to a static binding between the
+calling and the called partition. The latter two ways correspond to a
+dynamic binding between the calling and the called partition.
+
+7/3
+{AI05-0101-1AI05-0101-1} Remote types library units (see *note E.2.2::)
+and remote call interface library units (see *note E.2.3::) define the
+remote subprograms or remote access types used for remote subprogram
+calls.
+
+ _Language Design Principles_
+
+7.a
+ Remote subprogram calls are standardized since the RPC
+ paradigm is widely-used, and establishing an interface to it
+ in the annex will increase the portability and reusability of
+ distributed programs.
+
+ _Legality Rules_
+
+8
+In a dispatching call with two or more controlling operands, if one
+controlling operand is designated by a value of a remote
+access-to-class-wide type, then all shall be.
+
+ _Dynamic Semantics_
+
+9
+For the execution of a remote subprogram call, subprogram parameters
+(and later the results, if any) are passed using a stream-oriented
+representation (see *note 13.13.1::) [which is suitable for transmission
+between partitions]. This action is called marshalling. Unmarshalling
+is the reverse action of reconstructing the parameters or results from
+the stream-oriented representation. [Marshalling is performed initially
+as part of the remote subprogram call in the calling partition;
+unmarshalling is done in the called partition. After the remote
+subprogram completes, marshalling is performed in the called partition,
+and finally unmarshalling is done in the calling partition.]
+
+10
+A calling stub is the sequence of code that replaces the subprogram body
+of a remotely called subprogram in the calling partition. A receiving
+stub is the sequence of code (the "wrapper") that receives a remote
+subprogram call on the called partition and invokes the appropriate
+subprogram body.
+
+10.a
+ Discussion: The use of the term stub in this annex should not
+ be confused with body_stub as defined in *note 10.1.3::. The
+ term stub is used here because it is a commonly understood
+ term when talking about the RPC paradigm.
+
+11
+Remote subprogram calls are executed at most once, that is, if the
+subprogram call returns normally, then the called subprogram's body was
+executed exactly once.
+
+12
+The task executing a remote subprogram call blocks until the subprogram
+in the called partition returns, unless the call is asynchronous. For
+an asynchronous remote procedure call, the calling task can become ready
+before the procedure in the called partition returns.
+
+13
+If a construct containing a remote call is aborted, the remote
+subprogram call is cancelled. Whether the execution of the remote
+subprogram is immediately aborted as a result of the cancellation is
+implementation defined.
+
+13.a
+ Implementation defined: Whether the execution of the remote
+ subprogram is immediately aborted as a result of cancellation.
+
+14
+If a remote subprogram call is received by a called partition before the
+partition has completed its elaboration, the call is kept pending until
+the called partition completes its elaboration (unless the call is
+cancelled by the calling partition prior to that).
+
+15
+If an exception is propagated by a remotely called subprogram, and the
+call is not an asynchronous call, the corresponding exception is
+reraised at the point of the remote subprogram call. For an
+asynchronous call, if the remote procedure call returns prior to the
+completion of the remotely called subprogram, any exception is lost.
+
+16
+The exception Communication_Error (see *note E.5::) is raised if a
+remote call cannot be completed due to difficulties in communicating
+with the called partition.
+
+17
+All forms of remote subprogram calls are potentially blocking operations
+(see *note 9.5.1::).
+
+17.a
+ Reason: Asynchronous remote procedure calls are potentially
+ blocking since the implementation may require waiting for the
+ availability of shared resources to initiate the remote call.
+
+18/1
+{8652/00858652/0085} {AI95-00215-01AI95-00215-01} In a remote subprogram
+call with a formal parameter of a class-wide type, a check is made that
+the tag of the actual parameter identifies a tagged type declared in a
+declared-pure or shared passive library unit, or in the visible part of
+a remote types or remote call interface library unit. Program_Error is
+raised if this check fails. In a remote function call which returns a
+class-wide type, the same check is made on the function result.
+
+18.a/1
+ Discussion: {8652/00858652/0085} {AI95-00215-01AI95-00215-01}
+ This check makes certain that the specific type passed or
+ returned in an RPC satisfies the rules for a "communicable"
+ type. Normally this is guaranteed by the compile-time
+ restrictions on remote call interfaces. However, with
+ class-wide types, it is possible to pass an object whose tag
+ identifies a type declared outside the "safe" packages.
+
+18.b
+ This is considered an accessibility_check since only the types
+ declared in "safe" packages are considered truly "global"
+ (cross-partition). Other types are local to a single
+ partition. This is analogous to the "accessibility" of global
+ vs. local declarations in a single-partition program.
+
+18.c
+ This rule replaces a rule from an early version of Ada 9X
+ which was given in the subclause on Remote Types Library Units
+ (now *note E.2.2::, "*note E.2.2:: Remote Types Library
+ Units"). That rule tried to prevent "bad" types from being
+ sent by arranging for their tags to mismatch between
+ partitions. However, that interfered with other uses of tags.
+ The new rule allows tags to agree in all partitions, even for
+ those types which are not "safe" to pass in an RPC.
+
+19
+In a dispatching call with two or more controlling operands that are
+designated by values of a remote access-to-class-wide type, a check is
+made [(in addition to the normal Tag_Check -- see *note 11.5::)] that
+all the remote access-to-class-wide values originated from Access
+attribute_references that were evaluated by tasks of the same active
+partition. Constraint_Error is raised if this check fails.
+
+19.a
+ Implementation Note: When a remote access-to-class-wide value
+ is created by an Access attribute_reference, the identity of
+ the active partition that evaluated the attribute_reference
+ should be recorded in the representation of the remote access
+ value.
+
+ _Implementation Requirements_
+
+20
+The implementation of remote subprogram calls shall conform to the PCS
+interface as defined by the specification of the language-defined
+package System.RPC (see *note E.5::). The calling stub shall use the
+Do_RPC procedure unless the remote procedure call is asynchronous in
+which case Do_APC shall be used. On the receiving side, the
+corresponding receiving stub shall be invoked by the RPC-receiver.
+
+20.a
+ Implementation Note: One possible implementation model is as
+ follows:
+
+20.b
+ The code for calls to subprograms declared in an RCI package
+ is generated normally, that is, the call-site is the same as
+ for a local subprogram call. The code for the remotely
+ callable subprogram bodies is also generated normally.
+ Subprogram's prologue and epilogue are the same as for a local
+ call.
+
+20.c
+ When compiling the specification of an RCI package, the
+ compiler generates calling stubs for each visible subprogram.
+ Similarly, when compiling the body of an RCI package, the
+ compiler generates receiving stubs for each visible subprogram
+ together with the appropriate tables to allow the RPC-receiver
+ to locate the correct receiving stub.
+
+20.d
+ For the statically bound remote calls, the identity of the
+ remote partition is statically determined (it is resolved at
+ configuration/link time).
+
+20.e
+ The calling stub operates as follows:
+
+20.f
+ * It allocates (or reuses) a stream of Params_Stream_Type
+ of Initial_Size, and initializes it by repeatedly calling
+ Write operations, first to identify which remote
+ subprogram in the receiving partition is being called,
+ and then to pass the incoming value of each of the in and
+ in out parameters of the call.
+
+20.g/3
+ * {AI05-0229-1AI05-0229-1} It allocates (or reuses) a
+ stream for the Result, unless an aspect Asynchronous is
+ specified as True for the procedure.
+
+20.h/3
+ * {AI05-0229-1AI05-0229-1} It calls Do_RPC unless an aspect
+ Asynchronous is specified as True for the procedure in
+ which case it calls Do_APC. An access value designating
+ the message stream allocated and initialized above is
+ passed as the Params parameter. An access value
+ designating the Result stream is passed as the Result
+ parameter.
+
+20.i/3
+ * {AI05-0229-1AI05-0229-1} If the aspect Asynchronous is
+ not specified for the procedure, Do_RPC blocks until a
+ reply message arrives, and then returns to the calling
+ stub. The stub returns after extracting from the Result
+ stream, using Read operations, the in out and out
+ parameters or the function result. If the reply message
+ indicates that the execution of the remote subprogram
+ propagated an exception, the exception is propagated from
+ Do_RPC to the calling stub, and thence to the point of
+ the original remote subprogram call. If Do_RPC detects
+ that communication with the remote partition has failed,
+ it propagates Communication_Error.
+
+20.j
+ On the receiving side, the RPC-receiver procedure operates as
+ follows:
+
+20.k
+ * It is called from the PCS when a remote-subprogram-call
+ message is received. The call originates in some remote
+ call receiver task executed and managed in the context of
+ the PCS.
+
+20.l
+ * It extracts information from the stream to identify the
+ appropriate receiving stub.
+
+20.m
+ * The receiving stub extracts the in and in out parameters
+ using Read from the stream designated by the Params
+ parameter.
+
+20.n
+ * The receiving stub calls the actual subprogram body and,
+ upon completion of the subprogram, uses Write to insert
+ the results into the stream pointed to by the Result
+ parameter. The receiving stub returns to the
+ RPC-receiver procedure which in turn returns to the PCS.
+ If the actual subprogram body propagates an exception, it
+ is propagated by the RPC-receiver to the PCS, which
+ handles the exception, and indicates in the reply message
+ that the execution of the subprogram body propagated an
+ exception. The exception occurrence can be represented
+ in the reply message using the Write attribute of
+ Ada.Exceptions.Exception_Occurrence.
+
+20.o
+ For remote access-to-subprogram types:
+
+20.p
+ A value of a remote access-to-subprogram type can be
+ represented by the following components: a reference to the
+ remote partition, an index to the package containing the
+ remote subprogram, and an index to the subprogram within the
+ package. The values of these components are determined at run
+ time when the remote access value is created. These three
+ components serve the same purpose when calling Do_APC/RPC, as
+ in the statically bound remote calls; the only difference is
+ that they are evaluated dynamically.
+
+20.q
+ For remote access-to-class-wide types:
+
+20.r
+ For each remote access-to-class-wide type, a calling stub is
+ generated for each dispatching operation of the designated
+ type. In addition, receiving stubs are generated to perform
+ the remote dispatching operations in the called partition.
+ The appropriate subprogram_body is determined as for a local
+ dispatching call once the receiving stub has been reached.
+
+20.s
+ A value of a remote access-to-class-wide type can be
+ represented with the following components: a reference to the
+ remote partition, an index to a table (created one per each
+ such access type) containing addresses of all the dispatching
+ operations of the designated type, and an access value
+ designating the actual remote object.
+
+20.t
+ Alternatively, a remote access-to-class-wide value can be
+ represented as a normal access value, pointing to a "stub"
+ object which in turn contains the information mentioned above.
+ A call on any dispatching operation of such a stub object does
+ the remote call, if necessary, using the information in the
+ stub object to locate the target partition, etc. This
+ approach has the advantage that less special-casing is
+ required in the compiler. All access values can remain just a
+ simple address.
+
+20.u
+ For a call to Do_RPC or Do_APC: The partition ID of all
+ controlling operands are checked for equality (a
+ Constraint_Error is raised if this check fails). The
+ partition ID value is used for the Partition parameter. An
+ index into the tagged-type-descriptor is created. This index
+ points to the receiving stub of the class-wide operation.
+ This index and the index to the table (described above) are
+ written to the stream. Then, the actual parameters are
+ marshalled into the message stream. For a controlling
+ operand, only the access value designating the remote object
+ is required (the other two components are already present in
+ the other parameters).
+
+20.v
+ On the called partition (after the RPC-receiver has
+ transferred control to the appropriate receiving stub) the
+ parameters are first unmarshalled. Then, the tags of the
+ controlling operands (obtained by dereferencing the pointer to
+ the object) are checked for equality. If the check fails
+ Constraint_Error is raised and propagated back to the calling
+ partition, unless it is a result of an asynchronous call.
+ Finally, a dispatching call to the specific subprogram (based
+ on the controlling object's tag) is made. Note that since
+ this subprogram is not in an RCI package, no specific stub is
+ generated for it, it is called normally from the dispatching
+ stub.
+
+20.1/1
+{8652/00868652/0086} {AI95-00159-01AI95-00159-01} With respect to shared
+variables in shared passive library units, the execution of the
+corresponding subprogram body of a synchronous remote procedure call is
+considered to be part of the execution of the calling task. The
+execution of the corresponding subprogram body of an asynchronous remote
+procedure call proceeds in parallel with the calling task and does not
+signal the next action of the calling task (see *note 9.10::).
+
+ NOTES
+
+21
+ 8 A given active partition can both make and receive remote
+ subprogram calls. Thus, an active partition can act as both a
+ client and a server.
+
+22
+ 9 If a given exception is propagated by a remote subprogram call,
+ but the exception does not exist in the calling partition, the
+ exception can be handled by an others choice or be propagated to
+ and handled by a third partition.
+
+22.a
+ Discussion: This situation can happen in a case of dynamically
+ nested remote subprogram calls, where an intermediate call
+ executes in a partition that does not include the library unit
+ that defines the exception.
+
+ _Wording Changes from Ada 95_
+
+22.b/2
+ {8652/00868652/0086} {AI95-00159-01AI95-00159-01} Corrigendum:
+ Added rules so that tasks can safely access shared passive
+ objects.
+
+22.c/2
+ {8652/00858652/0085} {AI95-00215-01AI95-00215-01} Corrigendum:
+ Clarified that the check on class-wide types also applies to
+ values returned from remote subprogram call functions.
+
+ _Wording Changes from Ada 2005_
+
+22.d/3
+ {AI05-0101-1AI05-0101-1} Correction: Corrected the text to
+ note that remote access types can be defined in remote types
+ units.
+
+* Menu:
+
+* E.4.1 :: Asynchronous Remote Calls
+* E.4.2 :: Example of Use of a Remote Access-to-Class-Wide Type
+
+\1f
+File: aarm2012.info, Node: E.4.1, Next: E.4.2, Up: E.4
+
+E.4.1 Asynchronous Remote Calls
+-------------------------------
+
+1/3
+{AI05-0229-1AI05-0229-1} [This subclause introduces the aspect
+Asynchronous which can be specified to allow a remote subprogram call to
+return prior to completion of the execution of the corresponding remote
+subprogram body.]
+
+Paragraphs 2 through 7 were deleted.
+
+ _Static Semantics_
+
+8/3
+{AI05-0229-1AI05-0229-1} For a remote procedure, the following
+language-defined representation aspect may be specified:
+
+8.1/3
+Asynchronous
+ The type of aspect Asynchronous is Boolean. If directly
+ specified, the aspect_definition shall be a static
+ expression. If not specified, the aspect is False.
+
+8.a/3
+ Aspect Description for Asynchronous: Remote procedure calls
+ are asynchronous; the caller continues without waiting for the
+ call to return.
+
+8.2/3
+{AI05-0229-1AI05-0229-1} For a remote access type, the following
+language-defined representation aspect may be specified:
+
+8.3/3
+Asynchronous
+ The type of aspect Asynchronous is Boolean. If directly
+ specified, the aspect_definition shall be a static
+ expression. If not specified (including by inheritance),
+ the aspect is False.
+
+ _Legality Rules_
+
+8.4/3
+{AI05-0229-1AI05-0229-1} If aspect Asynchronous is specified for a
+remote procedure, the formal parameters of the procedure shall all be of
+mode in.
+
+8.5/3
+{AI05-0229-1AI05-0229-1} If aspect Asynchronous is specified for a
+remote access type, the type shall be a remote access-to-class-wide
+type, or the type shall be a remote access-to-procedure type with the
+formal parameters of the designated profile of the type all of mode in.
+
+ _Dynamic Semantics_
+
+9/3
+{AI05-0229-1AI05-0229-1} A remote call is asynchronous if it is a call
+to a procedure, or a call through a value of an access-to-procedure
+type, for which aspect Asynchronous is True. In addition, if aspect
+Asynchronous is True for a remote access-to-class-wide type, then a
+dispatching call on a procedure with a controlling operand designated by
+a value of the type is asynchronous if the formal parameters of the
+procedure are all of mode in.
+
+ _Implementation Requirements_
+
+10
+Asynchronous remote procedure calls shall be implemented such that the
+corresponding body executes at most once as a result of the call.
+
+10.a
+ To be honest: It is not clear that this rule can be tested or
+ even defined formally.
+
+ _Extensions to Ada 2005_
+
+10.b/3
+ {AI05-0229-1AI05-0229-1} Aspect Asynchronous is new; pragma
+ Asynchronous is now obsolescent.
+
+\1f
+File: aarm2012.info, Node: E.4.2, Prev: E.4.1, Up: E.4
+
+E.4.2 Example of Use of a Remote Access-to-Class-Wide Type
+----------------------------------------------------------
+
+ _Examples_
+
+1
+Example of using a remote access-to-class-wide type to achieve dynamic
+binding across active partitions:
+
+2
+ package Tapes is
+ pragma Pure(Tapes);
+ type Tape is abstract tagged limited private;
+ -- Primitive dispatching operations where
+ -- Tape is controlling operand
+ procedure Copy (From, To : access Tape; Num_Recs : in Natural) is abstract;
+ procedure Rewind (T : access Tape) is abstract;
+ -- More operations
+ private
+ type Tape is ...
+ end Tapes;
+
+3
+ with Tapes;
+ package Name_Server is
+ pragma Remote_Call_Interface;
+ -- Dynamic binding to remote operations is achieved
+ -- using the access-to-limited-class-wide type Tape_Ptr
+ type Tape_Ptr is access all Tapes.Tape'Class;
+ -- The following statically bound remote operations
+ -- allow for a name-server capability in this example
+ function Find (Name : String) return Tape_Ptr;
+ procedure Register (Name : in String; T : in Tape_Ptr);
+ procedure Remove (T : in Tape_Ptr);
+ -- More operations
+ end Name_Server;
+
+4
+ package Tape_Driver is
+ -- Declarations are not shown, they are irrelevant here
+ end Tape_Driver;
+
+5
+ with Tapes, Name_Server;
+ package body Tape_Driver is
+ type New_Tape is new Tapes.Tape with ...
+ procedure Copy
+ (From, To : access New_Tape; Num_Recs: in Natural) is
+ begin
+ . . .
+ end Copy;
+ procedure Rewind (T : access New_Tape) is
+ begin
+ . . .
+ end Rewind;
+ -- Objects remotely accessible through use
+ -- of Name_Server operations
+ Tape1, Tape2 : aliased New_Tape;
+ begin
+ Name_Server.Register ("NINE-TRACK", Tape1'Access);
+ Name_Server.Register ("SEVEN-TRACK", Tape2'Access);
+ end Tape_Driver;
+
+6
+ with Tapes, Name_Server;
+ -- Tape_Driver is not needed and thus not mentioned in the with_clause
+ procedure Tape_Client is
+ T1, T2 : Name_Server.Tape_Ptr;
+ begin
+ T1 := Name_Server.Find ("NINE-TRACK");
+ T2 := Name_Server.Find ("SEVEN-TRACK");
+ Tapes.Rewind (T1);
+ Tapes.Rewind (T2);
+ Tapes.Copy (T1, T2, 3);
+ end Tape_Client;
+
+7
+Notes on the example:
+
+7.a
+ Discussion: The example does not show the case where tapes are
+ removed from or added to the system. In the former case, an
+ appropriate exception needs to be defined to instruct the
+ client to use another tape. In the latter, the Name_Server
+ should have a query function visible to the clients to inform
+ them about the availability of the tapes in the system.
+
+8/1
+This paragraph was deleted.
+
+9
+ * The package Tapes provides the necessary declarations of the type
+ and its primitive operations.
+
+10
+ * Name_Server is a remote call interface package and is elaborated in
+ a separate active partition to provide the necessary naming
+ services (such as Register and Find) to the entire distributed
+ program through remote subprogram calls.
+
+11
+ * Tape_Driver is a normal package that is elaborated in a partition
+ configured on the processing node that is connected to the tape
+ device(s). The abstract operations are overridden to support the
+ locally declared tape devices (Tape1, Tape2). The package is not
+ visible to its clients, but it exports the tape devices (as remote
+ objects) through the services of the Name_Server. This allows for
+ tape devices to be dynamically added, removed or replaced without
+ requiring the modification of the clients' code.
+
+12
+ * The Tape_Client procedure references only declarations in the Tapes
+ and Name_Server packages. Before using a tape for the first time,
+ it needs to query the Name_Server for a system-wide identity for
+ that tape. From then on, it can use that identity to access the
+ tape device.
+
+13
+ * Values of remote access type Tape_Ptr include the necessary
+ information to complete the remote dispatching operations that
+ result from dereferencing the controlling operands T1 and T2.
+
+\1f
+File: aarm2012.info, Node: E.5, Prev: E.4, Up: Annex E
+
+E.5 Partition Communication Subsystem
+=====================================
+
+1/2
+{AI95-00273-01AI95-00273-01} [The Partition Communication Subsystem
+(PCS) provides facilities for supporting communication between the
+active partitions of a distributed program. The package System.RPC is a
+language-defined interface to the PCS.]
+
+1.a
+ Reason: The prefix RPC is used rather than RSC because the
+ term remote procedure call and its acronym are more familiar.
+
+ _Static Semantics_
+
+2
+The following language-defined library package exists:
+
+3
+ with Ada.Streams; -- see *note 13.13.1::
+ package System.RPC is
+
+4
+ type Partition_Id is range 0 .. implementation-defined;
+
+5
+ Communication_Error : exception;
+
+6
+ type Params_Stream_Type (
+ Initial_Size : Ada.Streams.Stream_Element_Count) is new
+ Ada.Streams.Root_Stream_Type with private;
+
+7
+ procedure Read(
+ Stream : in out Params_Stream_Type;
+ Item : out Ada.Streams.Stream_Element_Array;
+ Last : out Ada.Streams.Stream_Element_Offset);
+
+8
+ procedure Write(
+ Stream : in out Params_Stream_Type;
+ Item : in Ada.Streams.Stream_Element_Array);
+
+9
+ -- Synchronous call
+ procedure Do_RPC(
+ Partition : in Partition_Id;
+ Params : access Params_Stream_Type;
+ Result : access Params_Stream_Type);
+
+10
+ -- Asynchronous call
+ procedure Do_APC(
+ Partition : in Partition_Id;
+ Params : access Params_Stream_Type);
+
+11
+ -- The handler for incoming RPCs
+ type RPC_Receiver is access procedure(
+ Params : access Params_Stream_Type;
+ Result : access Params_Stream_Type);
+
+12
+ procedure Establish_RPC_Receiver(
+ Partition : in Partition_Id;
+ Receiver : in RPC_Receiver);
+
+13
+ private
+ ... -- not specified by the language
+ end System.RPC;
+
+14
+A value of the type Partition_Id is used to identify a partition.
+
+14.a/2
+ Implementation defined: The range of type
+ System.RPC.Partition_Id.
+
+15
+An object of the type Params_Stream_Type is used for identifying the
+particular remote subprogram that is being called, as well as
+marshalling and unmarshalling the parameters or result of a remote
+subprogram call, as part of sending them between partitions.
+
+16
+[The Read and Write procedures override the corresponding abstract
+operations for the type Params_Stream_Type.]
+
+ _Dynamic Semantics_
+
+17
+The Do_RPC and Do_APC procedures send a message to the active partition
+identified by the Partition parameter.
+
+17.a
+ Implementation Note: It is assumed that the RPC interface is
+ above the message-passing layer of the network protocol stack
+ and is implemented in terms of it.
+
+18
+After sending the message, Do_RPC blocks the calling task until a reply
+message comes back from the called partition or some error is detected
+by the underlying communication system in which case Communication_Error
+is raised at the point of the call to Do_RPC.
+
+18.a
+ Reason: Only one exception is defined in System.RPC, although
+ many sources of errors might exist. This is so because it is
+ not always possible to distinguish among these errors. In
+ particular, it is often impossible to tell the difference
+ between a failing communication link and a failing processing
+ node. Additional information might be associated with a
+ particular Exception_Occurrence for a Communication_Error.
+
+19
+Do_APC operates in the same way as Do_RPC except that it is allowed to
+return immediately after sending the message.
+
+20
+Upon normal return, the stream designated by the Result parameter of
+Do_RPC contains the reply message.
+
+21
+The procedure System.RPC.Establish_RPC_Receiver is called once,
+immediately after elaborating the library units of an active partition
+(that is, right after the elaboration of the partition) if the partition
+includes an RCI library unit, but prior to invoking the main subprogram,
+if any. The Partition parameter is the Partition_Id of the active
+partition being elaborated. The Receiver parameter designates an
+implementation-provided procedure called the RPC-receiver which will
+handle all RPCs received by the partition from the PCS.
+Establish_RPC_Receiver saves a reference to the RPC-receiver; when a
+message is received at the called partition, the RPC-receiver is called
+with the Params stream containing the message. When the RPC-receiver
+returns, the contents of the stream designated by Result is placed in a
+message and sent back to the calling partition.
+
+21.a
+ Implementation Note: It is defined by the PCS implementation
+ whether one or more threads of control should be available to
+ process incoming messages and to wait for their completion.
+
+21.b
+ Implementation Note: At link-time, the linker provides the
+ RPC-receiver and the necessary tables to support it. A call
+ on Establish_RPC_Receiver is inserted just before the call on
+ the main subprogram.
+
+21.c
+ Reason: The interface between the PCS (the System.RPC package)
+ and the RPC-receiver is defined to be dynamic in order to
+ allow the elaboration sequence to notify the PCS that all
+ packages have been elaborated and that it is safe to call the
+ receiving stubs. It is not guaranteed that the PCS units will
+ be the last to be elaborated, so some other indication that
+ elaboration is complete is needed.
+
+22
+If a call on Do_RPC is aborted, a cancellation message is sent to the
+called partition, to request that the execution of the remotely called
+subprogram be aborted.
+
+22.a
+ To be honest: The full effects of this message are dependent
+ on the implementation of the PCS.
+
+23
+The subprograms declared in System.RPC are potentially blocking
+operations.
+
+ _Implementation Requirements_
+
+24
+The implementation of the RPC-receiver shall be reentrant[, thereby
+allowing concurrent calls on it from the PCS to service concurrent
+remote subprogram calls into the partition].
+
+24.a
+ Reason: There seems no reason to allow the implementation of
+ RPC-receiver to be nonreentrant, even though we don't require
+ that every implementation of the PCS actually perform
+ concurrent calls on the RPC-receiver.
+
+24.1/1
+{8652/00878652/0087} {AI95-00082-01AI95-00082-01} An implementation
+shall not restrict the replacement of the body of System.RPC. An
+implementation shall not restrict children of System.RPC. [The related
+implementation permissions in the introduction to Annex A do not apply.]
+
+24.a.1/1
+ Reason: The point of System.RPC is to let the user tailor the
+ communications mechanism without requiring changes to or other
+ cooperation from the compiler. However, implementations can
+ restrict the replacement of language-defined units. This
+ requirement overrides that permission for System.RPC.
+
+24.2/1
+{8652/00878652/0087} {AI95-00082-01AI95-00082-01} If the implementation
+of System.RPC is provided by the user, an implementation shall support
+remote subprogram calls as specified.
+
+24.b/2
+ Discussion: {AI95-00273-01AI95-00273-01} If the implementation
+ takes advantage of the implementation permission to use a
+ different specification for System.RPC, it still needs to use
+ it for remote subprogram calls, and allow the user to replace
+ the body of System.RPC. It just isn't guaranteed to be
+ portable to do so in Ada 2005 - an advantage which was more
+ theoretical than real anyway.
+
+ _Documentation Requirements_
+
+25
+The implementation of the PCS shall document whether the RPC-receiver is
+invoked from concurrent tasks. If there is an upper limit on the number
+of such tasks, this limit shall be documented as well, together with the
+mechanisms to configure it (if this is supported).
+
+25.a/2
+ This paragraph was deleted.
+
+25.a.1/2
+ Documentation Requirement: Whether the RPC-receiver is invoked
+ from concurrent tasks, and if so, the number of such tasks.
+
+ _Implementation Permissions_
+
+26
+The PCS is allowed to contain implementation-defined interfaces for
+explicit message passing, broadcasting, etc. Similarly, it is allowed
+to provide additional interfaces to query the state of some remote
+partition (given its partition ID) or of the PCS itself, to set timeouts
+and retry parameters, to get more detailed error status, etc. These
+additional interfaces should be provided in child packages of
+System.RPC.
+
+26.a
+ Implementation defined: Implementation-defined interfaces in
+ the PCS.
+
+27
+A body for the package System.RPC need not be supplied by the
+implementation.
+
+27.a
+ Reason: It is presumed that a body for the package System.RPC
+ might be extremely environment specific. Therefore, we do not
+ require that a body be provided by the (compiler)
+ implementation. The user will have to write a body, or
+ acquire one, appropriate for the target environment.
+
+27.1/3
+{AI95-00273-01AI95-00273-01} {AI05-0299-1AI05-0299-1} An alternative
+declaration is allowed for package System.RPC as long as it provides a
+set of operations that is substantially equivalent to the specification
+defined in this subclause.
+
+27.b/2
+ Reason: Experience has proved that the definition of
+ System.RPC given here is inadequate for interfacing to
+ existing distribution mechanisms (such as CORBA), especially
+ on heterogeneous systems. Rather than mandate a change in the
+ mechanism (which would break existing systems), require
+ implementations to support multiple mechanisms (which is
+ impractical), or prevent the use of Annex E facilities with
+ existing systems (which would be silly), we simply make this
+ facility optional.
+
+27.c/2
+ One of the purposes behind System.RPC was that knowledgeable
+ users, rather than compiler vendors, could create this package
+ tailored to their networks. Experience has shown that users
+ get their RPC from vendors anyway; users have not taken
+ advantage of the flexibility provided by this defined
+ interface. Moreover, one could compare this defined interface
+ to requiring Ada compilers to use a defined interface to
+ implement tasking. No one thinks that the latter is a good
+ idea, why should anyone believe that the former is?
+
+27.d/3
+ {AI05-0299-1AI05-0299-1} Therefore, this subclause is made
+ optional. We considered deleting the subclause outright, but
+ we still require that users may replace the package (whatever
+ its interface). Also, it still provides a useful guide to the
+ implementation of this feature.
+
+ _Implementation Advice_
+
+28
+Whenever possible, the PCS on the called partition should allow for
+multiple tasks to call the RPC-receiver with different messages and
+should allow them to block until the corresponding subprogram body
+returns.
+
+28.a/2
+ Implementation Advice: The PCS should allow for multiple tasks
+ to call the RPC-receiver.
+
+29
+The Write operation on a stream of type Params_Stream_Type should raise
+Storage_Error if it runs out of space trying to write the Item into the
+stream.
+
+29.a.1/2
+ Implementation Advice: The System.RPC.Write operation should
+ raise Storage_Error if it runs out of space when writing an
+ item.
+
+29.a
+ Implementation Note: An implementation could also dynamically
+ allocate more space as needed, only propagating Storage_Error
+ if the allocator it calls raises Storage_Error. This storage
+ could be managed through a controlled component of the stream
+ object, to ensure that it is reclaimed when the stream object
+ is finalized.
+
+ NOTES
+
+30
+ 10 The package System.RPC is not designed for direct calls by user
+ programs. It is instead designed for use in the implementation of
+ remote subprograms calls, being called by the calling stubs
+ generated for a remote call interface library unit to initiate a
+ remote call, and in turn calling back to an RPC-receiver that
+ dispatches to the receiving stubs generated for the body of a
+ remote call interface, to handle a remote call received from
+ elsewhere.
+
+ _Incompatibilities With Ada 95_
+
+30.a/2
+ {AI95-00273-01AI95-00273-01} The specification of System.RPC
+ can now be tailored for an implementation. If a program
+ replaces the body of System.RPC with a user-defined body, it
+ might not compile in a given implementation of Ada 2005 (if
+ the specification of System.RPC has been changed).
+
+ _Wording Changes from Ada 95_
+
+30.b/2
+ {8652/00878652/0087} {AI95-00082-01AI95-00082-01} Corrigendum:
+ Clarified that the user can replace System.RPC.
+
+\1f
+File: aarm2012.info, Node: Annex F, Next: Annex G, Prev: Annex E, Up: Top
+
+Annex F Information Systems
+***************************
+
+1
+This Annex provides a set of facilities relevant to Information Systems
+programming. These fall into several categories:
+
+2
+ * an attribute definition clause specifying Machine_Radix for a
+ decimal subtype;
+
+3
+ * the package Decimal, which declares a set of constants defining the
+ implementation's capacity for decimal types, and a generic
+ procedure for decimal division; and
+
+4/2
+ * {AI95-00285-01AI95-00285-01} the child packages Text_IO.Editing,
+ Wide_Text_IO.Editing, and Wide_Wide_Text_IO.Editing, which support
+ formatted and localized output of decimal data, based on "picture
+ String" values.
+
+5/2
+{AI95-00434-01AI95-00434-01} See also: *note 3.5.9::, "*note 3.5.9::
+Fixed Point Types"; *note 3.5.10::, "*note 3.5.10:: Operations of Fixed
+Point Types"; *note 4.6::, "*note 4.6:: Type Conversions"; *note 13.3::,
+"*note 13.3:: Operational and Representation Attributes"; *note
+A.10.9::, "*note A.10.9:: Input-Output for Real Types"; *note B.3::,
+"*note B.3:: Interfacing with C and C++"; *note B.4::, "*note B.4::
+Interfacing with COBOL"; *note Annex G::, "*note Annex G:: Numerics".
+
+6
+The character and string handling packages in *note Annex A::, "*note
+Annex A:: Predefined Language Environment" are also relevant for
+Information Systems.
+
+ _Implementation Advice_
+
+7/3
+{AI05-0229-1AI05-0229-1} If COBOL (respectively, C) is widely supported
+in the target environment, implementations supporting the Information
+Systems Annex should provide the child package Interfaces.COBOL
+(respectively, Interfaces.C) specified in *note Annex B:: and should
+support a convention_identifier of COBOL (respectively, C) for the
+Convention aspect (see *note Annex B::), thus allowing Ada programs to
+interface with programs written in that language.
+
+7.a/2
+ Implementation Advice: If COBOL (respectively, C) is supported
+ in the target environment, then interfacing to COBOL
+ (respectively, C) should be supported as specified in *note
+ Annex B::.
+
+ _Extensions to Ada 83_
+
+7.b
+ This Annex is new to Ada 95.
+
+ _Wording Changes from Ada 95_
+
+7.c/2
+ {AI95-00285-01AI95-00285-01} Added a mention of
+ Wide_Wide_Text_IO.Editing, part of the support for 32-bit
+ characters.
+
+* Menu:
+
+* F.1 :: Machine_Radix Attribute Definition Clause
+* F.2 :: The Package Decimal
+* F.3 :: Edited Output for Decimal Types
+
+\1f
+File: aarm2012.info, Node: F.1, Next: F.2, Up: Annex F
+
+F.1 Machine_Radix Attribute Definition Clause
+=============================================
+
+ _Static Semantics_
+
+1
+Machine_Radix may be specified for a decimal first subtype (see *note
+3.5.9::) via an attribute_definition_clause; the expression of such a
+clause shall be static, and its value shall be 2 or 10. A value of 2
+implies a binary base range; a value of 10 implies a decimal base range.
+
+1.a
+ Ramification: In the absence of a Machine_Radix clause, the
+ choice of 2 versus 10 for S'Machine_Radix is not specified.
+
+1.b/3
+ Aspect Description for Machine_Radix: Radix (2 or 10) that is
+ used to represent a decimal fixed point type.
+
+ _Implementation Advice_
+
+2
+Packed decimal should be used as the internal representation for objects
+of subtype S when S'Machine_Radix = 10.
+
+2.a/2
+ Implementation Advice: Packed decimal should be used as the
+ internal representation for objects of subtype S when
+ S'Machine_Radix = 10.
+
+2.b/3
+ Discussion: {AI05-0229-1AI05-0229-1} The intent of a decimal
+ Machine_Radix attribute definition clause is to allow the
+ programmer to declare an Ada decimal data object whose
+ representation matches a particular COBOL implementation's
+ representation of packed decimal items. The Ada object may
+ then be passed to an interfaced COBOL program that takes a
+ packed decimal data item as a parameter, assuming that
+ convention COBOL has been specified for the Ada object's type
+ with an aspect Convention.
+
+2.c
+ Additionally, the Ada compiler may choose to generate
+ arithmetic instructions that exploit the packed decimal
+ representation.
+
+ _Examples_
+
+3
+Example of Machine_Radix attribute definition clause:
+
+4
+ type Money is delta 0.01 digits 15;
+ for Money'Machine_Radix use 10;
+
+\1f
+File: aarm2012.info, Node: F.2, Next: F.3, Prev: F.1, Up: Annex F
+
+F.2 The Package Decimal
+=======================
+
+ _Static Semantics_
+
+1
+The library package Decimal has the following declaration:
+
+2
+ package Ada.Decimal is
+ pragma Pure(Decimal);
+
+3
+ Max_Scale : constant := implementation-defined;
+ Min_Scale : constant := implementation-defined;
+
+4
+ Min_Delta : constant := 10.0**(-Max_Scale);
+ Max_Delta : constant := 10.0**(-Min_Scale);
+
+5
+ Max_Decimal_Digits : constant := implementation-defined;
+
+6/3
+ {AI05-0229-1AI05-0229-1} generic
+ type Dividend_Type is delta <> digits <>;
+ type Divisor_Type is delta <> digits <>;
+ type Quotient_Type is delta <> digits <>;
+ type Remainder_Type is delta <> digits <>;
+ procedure Divide (Dividend : in Dividend_Type;
+ Divisor : in Divisor_Type;
+ Quotient : out Quotient_Type;
+ Remainder : out Remainder_Type)
+ with Convention => Intrinsic;
+
+7
+ end Ada.Decimal;
+
+7.a
+ Implementation defined: The values of named numbers in the
+ package Decimal.
+
+8
+Max_Scale is the largest N such that 10.0**(-N) is allowed as a decimal
+type's delta. Its type is universal_integer.
+
+9
+Min_Scale is the smallest N such that 10.0**(-N) is allowed as a decimal
+type's delta. Its type is universal_integer.
+
+10
+Min_Delta is the smallest value allowed for delta in a
+decimal_fixed_point_definition. Its type is universal_real.
+
+11
+Max_Delta is the largest value allowed for delta in a
+decimal_fixed_point_definition. Its type is universal_real.
+
+12
+Max_Decimal_Digits is the largest value allowed for digits in a
+decimal_fixed_point_definition. Its type is universal_integer.
+
+12.a
+ Reason: The name is Max_Decimal_Digits versus Max_Digits, in
+ order to avoid confusion with the named number
+ System.Max_Digits relevant to floating point.
+
+ _Static Semantics_
+
+13
+The effect of Divide is as follows. The value of Quotient is
+Quotient_Type(Dividend/Divisor). The value of Remainder is
+Remainder_Type(Intermediate), where Intermediate is the difference
+between Dividend and the product of Divisor and Quotient; this result is
+computed exactly.
+
+ _Implementation Requirements_
+
+14
+Decimal.Max_Decimal_Digits shall be at least 18.
+
+15
+Decimal.Max_Scale shall be at least 18.
+
+16
+Decimal.Min_Scale shall be at most 0.
+
+ NOTES
+
+17
+ 1 The effect of division yielding a quotient with control over
+ rounding versus truncation is obtained by applying either the
+ function attribute Quotient_Type'Round or the conversion
+ Quotient_Type to the expression Dividend/Divisor.
+
+\1f
+File: aarm2012.info, Node: F.3, Prev: F.2, Up: Annex F
+
+F.3 Edited Output for Decimal Types
+===================================
+
+1/2
+{AI95-00285-01AI95-00285-01} The child packages Text_IO.Editing,
+Wide_Text_IO.Editing, and Wide_Wide_Text_IO.Editing provide localizable
+formatted text output, known as edited output, for decimal types. An
+edited output string is a function of a numeric value,
+program-specifiable locale elements, and a format control value. The
+numeric value is of some decimal type. The locale elements are:
+
+2
+ * the currency string;
+
+3
+ * the digits group separator character;
+
+4
+ * the radix mark character; and
+
+5
+ * the fill character that replaces leading zeros of the numeric
+ value.
+
+6/2
+{AI95-00285-01AI95-00285-01} For Text_IO.Editing the edited output and
+currency strings are of type String, and the locale characters are of
+type Character. For Wide_Text_IO.Editing their types are Wide_String
+and Wide_Character, respectively. For Wide_Wide_Text_IO.Editing their
+types are Wide_Wide_String and Wide_Wide_Character, respectively.
+
+7
+Each of the locale elements has a default value that can be replaced or
+explicitly overridden.
+
+8
+A format-control value is of the private type Picture; it determines the
+composition of the edited output string and controls the form and
+placement of the sign, the position of the locale elements and the
+decimal digits, the presence or absence of a radix mark, suppression of
+leading zeros, and insertion of particular character values.
+
+9
+A Picture object is composed from a String value, known as a picture
+String, that serves as a template for the edited output string, and a
+Boolean value that controls whether a string of all space characters is
+produced when the number's value is zero. A picture String comprises a
+sequence of one- or two-Character symbols, each serving as a placeholder
+for a character or string at a corresponding position in the edited
+output string. The picture String symbols fall into several categories
+based on their effect on the edited output string:
+
+10
+ Decimal Digit: '9'
+ Radix Control: '.' 'V'
+ Sign Control: '+' '-' '<' '>' "CR" "DB"
+ Currency Control: '$' '#'
+ Zero Suppression: 'Z' '*'
+ Simple Insertion: '_' 'B' '0' '/'
+
+11
+The entries are not case-sensitive. Mixed- or lower-case forms for "CR"
+and "DB", and lower-case forms for 'V', 'Z', and 'B', have the same
+effect as the upper-case symbols shown.
+
+12
+An occurrence of a '9' Character in the picture String represents a
+decimal digit position in the edited output string.
+
+13
+A radix control Character in the picture String indicates the position
+of the radix mark in the edited output string: an actual character
+position for '.', or an assumed position for 'V'.
+
+14
+A sign control Character in the picture String affects the form of the
+sign in the edited output string. The '<' and '>' Character values
+indicate parentheses for negative values. A Character '+', '-', or '<'
+appears either singly, signifying a fixed-position sign in the edited
+output, or repeated, signifying a floating-position sign that is
+preceded by zero or more space characters and that replaces a leading 0.
+
+15
+A currency control Character in the picture String indicates an
+occurrence of the currency string in the edited output string. The '$'
+Character represents the complete currency string; the '#' Character
+represents one character of the currency string. A '$' Character
+appears either singly, indicating a fixed-position currency string in
+the edited output, or repeated, indicating a floating-position currency
+string that occurs in place of a leading 0. A sequence of '#' Character
+values indicates either a fixed- or floating-position currency string,
+depending on context.
+
+16
+A zero suppression Character in the picture String allows a leading zero
+to be replaced by either the space character (for 'Z') or the fill
+character (for '*').
+
+17
+A simple insertion Character in the picture String represents, in
+general, either itself (if '/' or '0'), the space character (if 'B'), or
+the digits group separator character (if '_'). In some contexts it is
+treated as part of a floating sign, floating currency, or zero
+suppression string.
+
+18/2
+{AI95-00434-01AI95-00434-01} An example of a picture String is
+"<###Z_ZZ9.99>". If the currency string is "kr", the separator
+character is ',', and the radix mark is '.' then the edited output
+string values for the decimal values 32.10 and -5432.10 are
+"bbkrbbb32.10b" and "(bkr5,432.10)", respectively, where 'b' indicates
+the space character.
+
+19/2
+{AI95-00285-01AI95-00285-01} The generic packages Text_IO.Decimal_IO,
+Wide_Text_IO.Decimal_IO, and Wide_Wide_Text_IO.Decimal_IO (see *note
+A.10.9::, "*note A.10.9:: Input-Output for Real Types") provide text
+input and nonedited text output for decimal types.
+
+ NOTES
+
+20/2
+ 2 {AI95-00285-01AI95-00285-01} A picture String is of type
+ Standard.String, for all of Text_IO.Editing, Wide_Text_IO.Editing,
+ and Wide_Wide_Text_IO.Editing.
+
+ _Wording Changes from Ada 95_
+
+20.a/2
+ {AI95-00285-01AI95-00285-01} Added descriptions of
+ Wide_Wide_Text_IO.Editing; see *note F.3.5::.
+
+* Menu:
+
+* F.3.1 :: Picture String Formation
+* F.3.2 :: Edited Output Generation
+* F.3.3 :: The Package Text_IO.Editing
+* F.3.4 :: The Package Wide_Text_IO.Editing
+* F.3.5 :: The Package Wide_Wide_Text_IO.Editing
+
+\1f
+File: aarm2012.info, Node: F.3.1, Next: F.3.2, Up: F.3
+
+F.3.1 Picture String Formation
+------------------------------
+
+1/3
+{AI05-0299-1AI05-0299-1} A well-formed picture String, or simply picture
+String, is a String value that conforms to the syntactic rules,
+composition constraints, and character replication conventions specified
+in this subclause.
+
+ _Dynamic Semantics_
+
+2/1
+This paragraph was deleted.
+
+3
+ picture_string ::=
+ fixed_$_picture_string
+ | fixed_#_picture_string
+ | floating_currency_picture_string
+ | non_currency_picture_string
+
+4
+ fixed_$_picture_string ::=
+ [fixed_LHS_sign] fixed_$_char {direct_insertion} [zero_suppression]
+ number [RHS_sign]
+
+ | [fixed_LHS_sign {direct_insertion}] [zero_suppression]
+ number fixed_$_char {direct_insertion} [RHS_sign]
+
+ | floating_LHS_sign number fixed_$_char {direct_insertion} [RHS_sign]
+
+ | [fixed_LHS_sign] fixed_$_char {direct_insertion}
+ all_zero_suppression_number {direct_insertion} [RHS_sign]
+
+ | [fixed_LHS_sign {direct_insertion}] all_zero_suppression_number {direct_insertion}
+ fixed_$_char {direct_insertion} [RHS_sign]
+
+ | all_sign_number {direct_insertion} fixed_$_char {direct_insertion} [RHS_sign]
+
+5
+ fixed_#_picture_string ::=
+ [fixed_LHS_sign] single_#_currency {direct_insertion}
+ [zero_suppression] number [RHS_sign]
+
+ | [fixed_LHS_sign] multiple_#_currency {direct_insertion}
+ zero_suppression number [RHS_sign]
+
+ | [fixed_LHS_sign {direct_insertion}] [zero_suppression]
+ number fixed_#_currency {direct_insertion} [RHS_sign]
+
+ | floating_LHS_sign number fixed_#_currency {direct_insertion} [RHS_sign]
+
+ | [fixed_LHS_sign] single_#_currency {direct_insertion}
+ all_zero_suppression_number {direct_insertion} [RHS_sign]
+
+ | [fixed_LHS_sign] multiple_#_currency {direct_insertion}
+ all_zero_suppression_number {direct_insertion} [RHS_sign]
+
+ | [fixed_LHS_sign {direct_insertion}] all_zero_suppression_number {direct_insertion}
+ fixed_#_currency {direct_insertion} [RHS_sign]
+
+ | all_sign_number {direct_insertion} fixed_#_currency {direct_insertion} [RHS_sign]
+
+6
+ floating_currency_picture_string ::=
+ [fixed_LHS_sign] {direct_insertion} floating_$_currency number [RHS_sign]
+ | [fixed_LHS_sign] {direct_insertion} floating_#_currency number [RHS_sign]
+ | [fixed_LHS_sign] {direct_insertion} all_currency_number {direct_insertion} [RHS_sign]
+
+7
+ non_currency_picture_string ::=
+ [fixed_LHS_sign {direct_insertion}] zero_suppression number [RHS_sign]
+ | [floating_LHS_sign] number [RHS_sign]
+ | [fixed_LHS_sign {direct_insertion}] all_zero_suppression_number {direct_insertion}
+ [RHS_sign]
+ | all_sign_number {direct_insertion}
+ | fixed_LHS_sign direct_insertion {direct_insertion} number [RHS_sign]
+
+8
+ fixed_LHS_sign ::= LHS_Sign
+
+9
+ LHS_Sign ::= + | - | <
+
+10
+ fixed_$_char ::= $
+
+11
+ direct_insertion ::= simple_insertion
+
+12
+ simple_insertion ::= _ | B | 0 | /
+
+13
+ zero_suppression ::= Z {Z | context_sensitive_insertion} | fill_string
+
+14
+ context_sensitive_insertion ::= simple_insertion
+
+15
+ fill_string ::= * {* | context_sensitive_insertion}
+
+16
+ number ::=
+ fore_digits [radix [aft_digits] {direct_insertion}]
+ | radix aft_digits {direct_insertion}
+
+17
+ fore_digits ::= 9 {9 | direct_insertion}
+
+18
+ aft_digits ::= {9 | direct_insertion} 9
+
+19
+ radix ::= . | V
+
+20
+ RHS_sign ::= + | - | > | CR | DB
+
+21
+ floating_LHS_sign ::=
+ LHS_Sign {context_sensitive_insertion} LHS_Sign {LHS_Sign | context_sensitive_insertion}
+
+22
+ single_#_currency ::= #
+
+23
+ multiple_#_currency ::= ## {#}
+
+24
+ fixed_#_currency ::= single_#_currency | multiple_#_currency
+
+25
+ floating_$_currency ::=
+ $ {context_sensitive_insertion} $ {$ | context_sensitive_insertion}
+
+26
+ floating_#_currency ::=
+ # {context_sensitive_insertion} # {# | context_sensitive_insertion}
+
+27
+ all_sign_number ::= all_sign_fore [radix [all_sign_aft]] [>]
+
+28
+ all_sign_fore ::=
+ sign_char {context_sensitive_insertion} sign_char {sign_char | context_sensitive_insertion}
+
+29
+ all_sign_aft ::= {all_sign_aft_char} sign_char
+
+ all_sign_aft_char ::= sign_char | context_sensitive_insertion
+
+30
+ sign_char ::= + | - | <
+
+31
+ all_currency_number ::= all_currency_fore [radix [all_currency_aft]]
+
+32
+ all_currency_fore ::=
+ currency_char {context_sensitive_insertion}
+ currency_char {currency_char | context_sensitive_insertion}
+
+33
+ all_currency_aft ::= {all_currency_aft_char} currency_char
+
+ all_currency_aft_char ::= currency_char | context_sensitive_insertion
+
+34
+ currency_char ::= $ | #
+
+35
+ all_zero_suppression_number ::= all_zero_suppression_fore [ radix [all_zero_suppression_aft]]
+
+36
+ all_zero_suppression_fore ::=
+ zero_suppression_char {zero_suppression_char | context_sensitive_insertion}
+
+37
+ all_zero_suppression_aft ::= {all_zero_suppression_aft_char} zero_suppression_char
+
+ all_zero_suppression_aft_char ::= zero_suppression_char | context_sensitive_insertion
+
+38
+ zero_suppression_char ::= Z | *
+
+39
+The following composition constraints apply to a picture String:
+
+40
+ * A floating_LHS_sign does not have occurrences of different LHS_Sign
+ Character values.
+
+41
+ * If a picture String has '<' as fixed_LHS_sign, then it has '>' as
+ RHS_sign.
+
+42
+ * If a picture String has '<' in a floating_LHS_sign or in an
+ all_sign_number, then it has an occurrence of '>'.
+
+43/1
+ * {8652/00888652/0088} {AI95-00153AI95-00153} If a picture String has
+ '+' or '-' as fixed_LHS_sign, in a floating_LHS_sign, or in an
+ all_sign_number, then it has no RHS_sign or '>' character.
+
+44
+ * An instance of all_sign_number does not have occurrences of
+ different sign_char Character values.
+
+45
+ * An instance of all_currency_number does not have occurrences of
+ different currency_char Character values.
+
+46
+ * An instance of all_zero_suppression_number does not have
+ occurrences of different zero_suppression_char Character values,
+ except for possible case differences between 'Z' and 'z'.
+
+47
+A replicable Character is a Character that, by the above rules, can
+occur in two consecutive positions in a picture String.
+
+48
+A Character replication is a String
+
+49
+ char & '(' & spaces & count_string & ')'
+
+50
+where char is a replicable Character, spaces is a String (possibly
+empty) comprising only space Character values, and count_string is a
+String of one or more decimal digit Character values. A Character
+replication in a picture String has the same effect as (and is said to
+be equivalent to) a String comprising n consecutive occurrences of char,
+where n=Integer'Value(count_string).
+
+51
+An expanded picture String is a picture String containing no Character
+replications.
+
+51.a
+ Discussion: Since 'B' is not allowed after a RHS sign, there
+ is no need for a special rule to disallow "9.99DB(2)" as an
+ abbreviation for "9.99DBB"
+
+ NOTES
+
+52
+ 3 Although a sign to the left of the number can float, a sign to
+ the right of the number is in a fixed position.
+
+ _Wording Changes from Ada 95_
+
+52.a/2
+ {8652/00888652/0088} {AI95-00153-01AI95-00153-01} Corrigendum:
+ The picture string rules for numbers were tightened.
+
+\1f
+File: aarm2012.info, Node: F.3.2, Next: F.3.3, Prev: F.3.1, Up: F.3
+
+F.3.2 Edited Output Generation
+------------------------------
+
+ _Dynamic Semantics_
+
+1
+The contents of an edited output string are based on:
+
+2
+ * A value, Item, of some decimal type Num,
+
+3
+ * An expanded picture String Pic_String,
+
+4
+ * A Boolean value, Blank_When_Zero,
+
+5
+ * A Currency string,
+
+6
+ * A Fill character,
+
+7
+ * A Separator character, and
+
+8
+ * A Radix_Mark character.
+
+9
+The combination of a True value for Blank_When_Zero and a '*' character
+in Pic_String is inconsistent; no edited output string is defined.
+
+9.a/2
+ Reason: {AI95-00114-01AI95-00114-01} Such a Pic_String is
+ invalid, and any attempt to use such a string will raise
+ Picture_Error.
+
+10
+A layout error is identified in the rules below if leading nonzero
+digits of Item, character values of the Currency string, or a negative
+sign would be truncated; in such cases no edited output string is
+defined.
+
+11
+The edited output string has lower bound 1 and upper bound N where N =
+Pic_String'Length + Currency_Length_Adjustment - Radix_Adjustment, and
+
+12
+ * Currency_Length_Adjustment = Currency'Length - 1 if there is some
+ occurrence of '$' in Pic_String, and 0 otherwise.
+
+13
+ * Radix_Adjustment = 1 if there is an occurrence of 'V' or 'v' in
+ Pic_Str, and 0 otherwise.
+
+14
+Let the magnitude of Item be expressed as a base-10 number
+Ip···I1.F1···Fq, called the displayed magnitude of Item, where:
+
+15
+ * q = Min(Max(Num'Scale, 0), n) where n is 0 if Pic_String has no
+ radix and is otherwise the number of digit positions following
+ radix in Pic_String, where a digit position corresponds to an
+ occurrence of '9', a zero_suppression_char (for an
+ all_zero_suppression_number), a currency_char (for an
+ all_currency_number), or a sign_char (for an all_sign_number).
+
+16
+ * Ip /= 0 if p>0.
+
+17
+If n < Num'Scale, then the above number is the result of rounding (away
+from 0 if exactly midway between values).
+
+18
+If Blank_When_Zero = True and the displayed magnitude of Item is zero,
+then the edited output string comprises all space character values.
+Otherwise, the picture String is treated as a sequence of instances of
+syntactic categories based on the rules in *note F.3.1::, and the edited
+output string is the concatenation of string values derived from these
+categories according to the following mapping rules.
+
+19
+Table F-1 shows the mapping from a sign control symbol to a
+corresponding character or string in the edited output. In the columns
+showing the edited output, a lower-case 'b' represents the space
+character. If there is no sign control symbol but the value of Item is
+negative, a layout error occurs and no edited output string is produced.
+
+Table F-1: Edited Output for Sign Control Symbols
+Sign Control Symbol Edited Output for Edited Output for
+ Nonnegative Number Negative Number
+'+' '+' '-'
+'-' 'b' '-'
+'<' 'b' '('
+'>' 'b' ')'
+"CR" "bb" "CR"
+"DB" "bb" "DB"
+20
+An instance of fixed_LHS_sign maps to a character as shown in Table F-1.
+
+21
+An instance of fixed_$_char maps to Currency.
+
+22
+An instance of direct_insertion maps to Separator if direct_insertion =
+'_', and to the direct_insertion Character otherwise.
+
+23
+An instance of number maps to a string integer_part & radix_part &
+fraction_part where:
+
+24
+ * The string for integer_part is obtained as follows:
+
+25
+ 1. Occurrences of '9' in fore_digits of number are replaced
+ from right to left with the decimal digit character values for
+ I1, ..., Ip, respectively.
+
+26
+ 2. Each occurrence of '9' in fore_digits to the left of the
+ leftmost '9' replaced according to rule 1 is replaced with
+ '0'.
+
+27
+ 3. If p exceeds the number of occurrences of '9' in
+ fore_digits of number, then the excess leftmost digits are
+ eligible for use in the mapping of an instance of
+ zero_suppression, floating_LHS_sign, floating_$_currency, or
+ floating_#_currency to the left of number; if there is no such
+ instance, then a layout error occurs and no edited output
+ string is produced.
+
+28
+ * The radix_part is:
+
+29
+ * "" if number does not include a radix, if radix = 'V', or
+ if radix = 'v'
+
+30
+ * Radix_Mark if number includes '.' as radix
+
+31
+ * The string for fraction_part is obtained as follows:
+
+32
+ 1. Occurrences of '9' in aft_digits of number are replaced
+ from left to right with the decimal digit character values for
+ F1, ... Fq.
+
+33
+ 2. Each occurrence of '9' in aft_digits to the right of the
+ rightmost '9' replaced according to rule 1 is replaced by '0'.
+
+34
+An instance of zero_suppression maps to the string obtained as follows:
+
+35
+ 1. The rightmost 'Z', 'z', or '*' Character values are replaced
+ with the excess digits (if any) from the integer_part of the
+ mapping of the number to the right of the zero_suppression
+ instance,
+
+36
+ 2. A context_sensitive_insertion Character is replaced as though
+ it were a direct_insertion Character, if it occurs to the right of
+ some 'Z', 'z', or '*' in zero_suppression that has been mapped to
+ an excess digit,
+
+37
+ 3. Each Character to the left of the leftmost Character replaced
+ according to rule 1 above is replaced by:
+
+38
+ * the space character if the zero suppression Character is
+ 'Z' or 'z', or
+
+39
+ * the Fill character if the zero suppression Character is
+ '*'.
+
+40
+ 4. A layout error occurs if some excess digits remain after all
+ 'Z', 'z', and '*' Character values in zero_suppression have been
+ replaced via rule 1; no edited output string is produced.
+
+41
+An instance of RHS_sign maps to a character or string as shown in Table
+F-1.
+
+42
+An instance of floating_LHS_sign maps to the string obtained as follows.
+
+43
+ 1. Up to all but one of the rightmost LHS_Sign Character values
+ are replaced by the excess digits (if any) from the integer_part of
+ the mapping of the number to the right of the floating_LHS_sign
+ instance.
+
+44
+ 2. The next Character to the left is replaced with the character
+ given by the entry in Table F-1 corresponding to the LHS_Sign
+ Character.
+
+45
+ 3. A context_sensitive_insertion Character is replaced as though
+ it were a direct_insertion Character, if it occurs to the right of
+ the leftmost LHS_Sign character replaced according to rule 1.
+
+46
+ 4. Any other Character is replaced by the space character..
+
+47
+ 5. A layout error occurs if some excess digits remain after
+ replacement via rule 1; no edited output string is produced.
+
+48
+An instance of fixed_#_currency maps to the Currency string with n space
+character values concatenated on the left (if the instance does not
+follow a radix) or on the right (if the instance does follow a radix),
+where n is the difference between the length of the fixed_#_currency
+instance and Currency'Length. A layout error occurs if Currency'Length
+exceeds the length of the fixed_#_currency instance; no edited output
+string is produced.
+
+49
+An instance of floating_$_currency maps to the string obtained as
+follows:
+
+50
+ 1. Up to all but one of the rightmost '$' Character values are
+ replaced with the excess digits (if any) from the integer_part of
+ the mapping of the number to the right of the floating_$_currency
+ instance.
+
+51
+ 2. The next Character to the left is replaced by the Currency
+ string.
+
+52
+ 3. A context_sensitive_insertion Character is replaced as though
+ it were a direct_insertion Character, if it occurs to the right of
+ the leftmost '$' Character replaced via rule 1.
+
+53
+ 4. Each other Character is replaced by the space character.
+
+54
+ 5. A layout error occurs if some excess digits remain after
+ replacement by rule 1; no edited output string is produced.
+
+55
+An instance of floating_#_currency maps to the string obtained as
+follows:
+
+56
+ 1. Up to all but one of the rightmost '#' Character values are
+ replaced with the excess digits (if any) from the integer_part of
+ the mapping of the number to the right of the floating_#_currency
+ instance.
+
+57
+ 2. The substring whose last Character occurs at the position
+ immediately preceding the leftmost Character replaced via rule 1,
+ and whose length is Currency'Length, is replaced by the Currency
+ string.
+
+58
+ 3. A context_sensitive_insertion Character is replaced as though
+ it were a direct_insertion Character, if it occurs to the right of
+ the leftmost '#' replaced via rule 1.
+
+59
+ 4. Any other Character is replaced by the space character.
+
+60
+ 5. A layout error occurs if some excess digits remain after
+ replacement rule 1, or if there is no substring with the required
+ length for replacement rule 2; no edited output string is produced.
+
+61
+An instance of all_zero_suppression_number maps to:
+
+62
+ * a string of all spaces if the displayed magnitude of Item is zero,
+ the zero_suppression_char is 'Z' or 'z', and the instance of
+ all_zero_suppression_number does not have a radix at its last
+ character position;
+
+63
+ * a string containing the Fill character in each position except for
+ the character (if any) corresponding to radix, if
+ zero_suppression_char = '*' and the displayed magnitude of Item is
+ zero;
+
+64
+ * otherwise, the same result as if each zero_suppression_char in
+ all_zero_suppression_aft were '9', interpreting the instance of
+ all_zero_suppression_number as either zero_suppression number (if a
+ radix and all_zero_suppression_aft are present), or as
+ zero_suppression otherwise.
+
+65
+An instance of all_sign_number maps to:
+
+66
+ * a string of all spaces if the displayed magnitude of Item is zero
+ and the instance of all_sign_number does not have a radix at its
+ last character position;
+
+67
+ * otherwise, the same result as if each sign_char in
+ all_sign_number_aft were '9', interpreting the instance of
+ all_sign_number as either floating_LHS_sign number (if a radix and
+ all_sign_number_aft are present), or as floating_LHS_sign
+ otherwise.
+
+68
+An instance of all_currency_number maps to:
+
+69
+ * a string of all spaces if the displayed magnitude of Item is zero
+ and the instance of all_currency_number does not have a radix at
+ its last character position;
+
+70
+ * otherwise, the same result as if each currency_char in
+ all_currency_number_aft were '9', interpreting the instance of
+ all_currency_number as floating_$_currency number or
+ floating_#_currency number (if a radix and all_currency_number_aft
+ are present), or as floating_$_currency or floating_#_currency
+ otherwise.
+
+ _Examples_
+
+71
+In the result string values shown below, 'b' represents the space
+character.
+
+72
+ Item: Picture and Result Strings:
+
+73/3
+ {AI05-0248-1AI05-0248-1} 123456.78 Picture: "-###**_***_**9.99"
+ Result: "bbb$***123,456.78"
+ "bbFF***123.456,78" (currency = "FF",
+ separator = '.',
+ radix mark = ',')
+
+74/1
+ {8652/00898652/0089} {AI95-00070AI95-00070} 123456.78 Picture: "-$**_***_**9.99"
+ Result: "b$***123,456.78"
+ "bFF***123.456,78" (currency = "FF",
+ separator = '.',
+ radix mark = ',')
+
+75
+ 0.0 Picture: "-$$$$$$.$$"
+ Result: "bbbbbbbbbb"
+
+76
+ 0.20 Picture: "-$$$$$$.$$"
+ Result: "bbbbbb$.20"
+
+77
+ -1234.565 Picture: "<<<<_<<<.<<###>"
+ Result: "bb(1,234.57DMb)" (currency = "DM")
+
+78
+ 12345.67 Picture: "###_###_##9.99"
+ Result: "bbCHF12,345.67" (currency = "CHF")
+
+ _Wording Changes from Ada 95_
+
+78.a/2
+ {8652/00898652/0089} {AI95-00070-01AI95-00070-01} Corrigendum:
+ Corrected the picture string example.
+
+\1f
+File: aarm2012.info, Node: F.3.3, Next: F.3.4, Prev: F.3.2, Up: F.3
+
+F.3.3 The Package Text_IO.Editing
+---------------------------------
+
+1
+The package Text_IO.Editing provides a private type Picture with
+associated operations, and a generic package Decimal_Output. An object
+of type Picture is composed from a well-formed picture String (see *note
+F.3.1::) and a Boolean item indicating whether a zero numeric value will
+result in an edited output string of all space characters. The package
+Decimal_Output contains edited output subprograms implementing the
+effects defined in *note F.3.2::.
+
+ _Static Semantics_
+
+2
+The library package Text_IO.Editing has the following declaration:
+
+3
+ package Ada.Text_IO.Editing is
+
+4
+ type Picture is private;
+
+5
+ function Valid (Pic_String : in String;
+ Blank_When_Zero : in Boolean := False) return Boolean;
+
+6
+ function To_Picture (Pic_String : in String;
+ Blank_When_Zero : in Boolean := False)
+ return Picture;
+
+7
+ function Pic_String (Pic : in Picture) return String;
+ function Blank_When_Zero (Pic : in Picture) return Boolean;
+
+8
+ Max_Picture_Length : constant := implementation_defined;
+
+9
+ Picture_Error : exception;
+
+10
+ Default_Currency : constant String := "$";
+ Default_Fill : constant Character := '*';
+ Default_Separator : constant Character := ',';
+ Default_Radix_Mark : constant Character := '.';
+
+11
+ generic
+ type Num is delta <> digits <>;
+ Default_Currency : in String := Text_IO.Editing.Default_Currency;
+ Default_Fill : in Character := Text_IO.Editing.Default_Fill;
+ Default_Separator : in Character :=
+ Text_IO.Editing.Default_Separator;
+ Default_Radix_Mark : in Character :=
+ Text_IO.Editing.Default_Radix_Mark;
+ package Decimal_Output is
+ function Length (Pic : in Picture;
+ Currency : in String := Default_Currency)
+ return Natural;
+
+12
+ function Valid (Item : in Num;
+ Pic : in Picture;
+ Currency : in String := Default_Currency)
+ return Boolean;
+
+13
+ function Image (Item : in Num;
+ Pic : in Picture;
+ Currency : in String := Default_Currency;
+ Fill : in Character := Default_Fill;
+ Separator : in Character := Default_Separator;
+ Radix_Mark : in Character := Default_Radix_Mark)
+ return String;
+
+14
+ procedure Put (File : in File_Type;
+ Item : in Num;
+ Pic : in Picture;
+ Currency : in String := Default_Currency;
+ Fill : in Character := Default_Fill;
+ Separator : in Character := Default_Separator;
+ Radix_Mark : in Character := Default_Radix_Mark);
+
+15
+ procedure Put (Item : in Num;
+ Pic : in Picture;
+ Currency : in String := Default_Currency;
+ Fill : in Character := Default_Fill;
+ Separator : in Character := Default_Separator;
+ Radix_Mark : in Character := Default_Radix_Mark);
+
+16
+ procedure Put (To : out String;
+ Item : in Num;
+ Pic : in Picture;
+ Currency : in String := Default_Currency;
+ Fill : in Character := Default_Fill;
+ Separator : in Character := Default_Separator;
+ Radix_Mark : in Character := Default_Radix_Mark);
+ end Decimal_Output;
+ private
+ ... -- not specified by the language
+ end Ada.Text_IO.Editing;
+
+16.a
+ Implementation defined: The value of Max_Picture_Length in the
+ package Text_IO.Editing
+
+17
+The exception Constraint_Error is raised if the Image function or any of
+the Put procedures is invoked with a null string for Currency.
+
+18
+ function Valid (Pic_String : in String;
+ Blank_When_Zero : in Boolean := False) return Boolean;
+
+19
+ Valid returns True if Pic_String is a well-formed picture
+ String (see *note F.3.1::) the length of whose expansion does
+ not exceed Max_Picture_Length, and if either Blank_When_Zero
+ is False or Pic_String contains no '*'.
+
+20
+ function To_Picture (Pic_String : in String;
+ Blank_When_Zero : in Boolean := False)
+ return Picture;
+
+21
+ To_Picture returns a result Picture such that the application
+ of the function Pic_String to this result yields an expanded
+ picture String equivalent to Pic_String, and such that
+ Blank_When_Zero applied to the result Picture is the same
+ value as the parameter Blank_When_Zero. Picture_Error is
+ raised if not Valid(Pic_String, Blank_When_Zero).
+
+22
+ function Pic_String (Pic : in Picture) return String;
+
+ function Blank_When_Zero (Pic : in Picture) return Boolean;
+
+23
+ If Pic is To_Picture(String_Item, Boolean_Item) for some
+ String_Item and Boolean_Item, then:
+
+24
+ * Pic_String(Pic) returns an expanded picture String
+ equivalent to String_Item and with any lower-case letter
+ replaced with its corresponding upper-case form, and
+
+25
+ * Blank_When_Zero(Pic) returns Boolean_Item.
+
+26
+ If Pic_1 and Pic_2 are objects of type Picture, then
+ "="(Pic_1, Pic_2) is True when
+
+27
+ * Pic_String(Pic_1) = Pic_String(Pic_2), and
+
+28
+ * Blank_When_Zero(Pic_1) = Blank_When_Zero(Pic_2).
+
+29
+ function Length (Pic : in Picture;
+ Currency : in String := Default_Currency)
+ return Natural;
+
+30
+ Length returns Pic_String(Pic)'Length +
+ Currency_Length_Adjustment - Radix_Adjustment where
+
+31
+ * Currency_Length_Adjustment =
+
+32
+ * Currency'Length - 1 if there is some occurrence
+ of '$' in Pic_String(Pic), and
+
+33
+ * 0 otherwise.
+
+34
+ * Radix_Adjustment =
+
+35
+ * 1 if there is an occurrence of 'V' or 'v' in
+ Pic_Str(Pic), and
+
+36
+ * 0 otherwise.
+
+37
+ function Valid (Item : in Num;
+ Pic : in Picture;
+ Currency : in String := Default_Currency)
+ return Boolean;
+
+38
+ Valid returns True if Image(Item, Pic, Currency) does not
+ raise Layout_Error, and returns False otherwise.
+
+39
+ function Image (Item : in Num;
+ Pic : in Picture;
+ Currency : in String := Default_Currency;
+ Fill : in Character := Default_Fill;
+ Separator : in Character := Default_Separator;
+ Radix_Mark : in Character := Default_Radix_Mark)
+ return String;
+
+40
+ Image returns the edited output String as defined in *note
+ F.3.2:: for Item, Pic_String(Pic), Blank_When_Zero(Pic),
+ Currency, Fill, Separator, and Radix_Mark. If these rules
+ identify a layout error, then Image raises the exception
+ Layout_Error.
+
+41
+ procedure Put (File : in File_Type;
+ Item : in Num;
+ Pic : in Picture;
+ Currency : in String := Default_Currency;
+ Fill : in Character := Default_Fill;
+ Separator : in Character := Default_Separator;
+ Radix_Mark : in Character := Default_Radix_Mark);
+
+ procedure Put (Item : in Num;
+ Pic : in Picture;
+ Currency : in String := Default_Currency;
+ Fill : in Character := Default_Fill;
+ Separator : in Character := Default_Separator;
+ Radix_Mark : in Character := Default_Radix_Mark);
+
+42
+ Each of these Put procedures outputs Image(Item, Pic,
+ Currency, Fill, Separator, Radix_Mark) consistent with the
+ conventions for Put for other real types in case of bounded
+ line length (see *note A.10.6::, "*note A.10.6:: Get and Put
+ Procedures").
+
+43
+ procedure Put (To : out String;
+ Item : in Num;
+ Pic : in Picture;
+ Currency : in String := Default_Currency;
+ Fill : in Character := Default_Fill;
+ Separator : in Character := Default_Separator;
+ Radix_Mark : in Character := Default_Radix_Mark);
+
+44/3
+ {AI05-0264-1AI05-0264-1} Put copies Image(Item, Pic, Currency,
+ Fill, Separator, Radix_Mark) to the given string, right
+ justified. Otherwise, unassigned Character values in To are
+ assigned the space character. If To'Length is less than the
+ length of the string resulting from Image, then Layout_Error
+ is raised.
+
+ _Implementation Requirements_
+
+45
+Max_Picture_Length shall be at least 30. The implementation shall
+support currency strings of length up to at least 10, both for
+Default_Currency in an instantiation of Decimal_Output, and for Currency
+in an invocation of Image or any of the Put procedures.
+
+45.a
+ Discussion: This implies that a picture string with character
+ replications need not be supported (i.e., To_Picture will
+ raise Picture_Error) if its expanded form exceeds 30
+ characters.
+
+ NOTES
+
+46
+ 4 The rules for edited output are based on COBOL (ANSI X3.23:1985,
+ endorsed by ISO as ISO 1989-1985), with the following differences:
+
+47
+ * The COBOL provisions for picture string localization and for
+ 'P' format are absent from Ada.
+
+48
+ * The following Ada facilities are not in COBOL:
+
+49
+ * currency symbol placement after the number,
+
+50
+ * localization of edited output string for
+ multi-character currency string values, including
+ support for both length-preserving and
+ length-expanding currency symbols in picture strings
+
+51
+ * localization of the radix mark, digits separator,
+ and fill character, and
+
+52
+ * parenthesization of negative values.
+
+52.1
+ The value of 30 for Max_Picture_Length is the same limit as in
+ COBOL.
+
+52.a
+ Reason: There are several reasons we have not adopted the
+ COBOL-style permission to provide a single-character
+ replacement in the picture string for the '$' as currency
+ symbol, or to interchange the roles of '.' and ',' in picture
+ strings
+
+52.b
+ * It would have introduced considerable complexity into
+ Ada, as well as confusion between run-time and
+ compile-time character interpretation, since picture
+ Strings are dynamically computable in Ada, in contrast
+ with COBOL
+
+52.c
+ * Ada's rules for real literals provide a natural
+ interpretation of '_' as digits separator and '.' for
+ radix mark; it is not essential to allow these to be
+ localized in picture strings, since Ada does not allow
+ them to be localized in real literals.
+
+52.d
+ * The COBOL restriction for the currency symbol in a
+ picture string to be replaced by a single character
+ currency symbol is a compromise solution. For general
+ international usage a mechanism is needed to localize the
+ edited output to be a multi-character currency string.
+ Allowing a single-Character localization for the picture
+ Character, and a multiple-character localization for the
+ currency string, would be an unnecessary complication.
+
+\1f
+File: aarm2012.info, Node: F.3.4, Next: F.3.5, Prev: F.3.3, Up: F.3
+
+F.3.4 The Package Wide_Text_IO.Editing
+--------------------------------------
+
+ _Static Semantics_
+
+1
+The child package Wide_Text_IO.Editing has the same contents as
+Text_IO.Editing, except that:
+
+2
+ * each occurrence of Character is replaced by Wide_Character,
+
+3
+ * each occurrence of Text_IO is replaced by Wide_Text_IO,
+
+4
+ * the subtype of Default_Currency is Wide_String rather than String,
+ and
+
+5
+ * each occurrence of String in the generic package Decimal_Output is
+ replaced by Wide_String.
+
+5.a
+ Implementation defined: The value of Max_Picture_Length in the
+ package Wide_Text_IO.Editing
+
+ NOTES
+
+6
+ 5 Each of the functions Wide_Text_IO.Editing.Valid, To_Picture,
+ and Pic_String has String (versus Wide_String) as its parameter or
+ result subtype, since a picture String is not localizable.
+
+\1f
+File: aarm2012.info, Node: F.3.5, Prev: F.3.4, Up: F.3
+
+F.3.5 The Package Wide_Wide_Text_IO.Editing
+-------------------------------------------
+
+ _Static Semantics_
+
+1/2
+{AI95-00285-01AI95-00285-01} The child package Wide_Wide_Text_IO.Editing
+has the same contents as Text_IO.Editing, except that:
+
+2/2
+ * each occurrence of Character is replaced by Wide_Wide_Character,
+
+3/2
+ * each occurrence of Text_IO is replaced by Wide_Wide_Text_IO,
+
+4/2
+ * the subtype of Default_Currency is Wide_Wide_String rather than
+ String, and
+
+5/2
+ * each occurrence of String in the generic package Decimal_Output is
+ replaced by Wide_Wide_String.
+
+5.a/2
+ Implementation defined: The value of Max_Picture_Length in the
+ package Wide_Wide_Text_IO.Editing
+
+ NOTES
+
+6/2
+ 6 {AI95-00285-01AI95-00285-01} Each of the functions
+ Wide_Wide_Text_IO.Editing.Valid, To_Picture, and Pic_String has
+ String (versus Wide_Wide_String) as its parameter or result
+ subtype, since a picture String is not localizable.
+
+ _Extensions to Ada 95_
+
+6.a/2
+ {AI95-00285-01AI95-00285-01} Package Wide_Wide_Text_IO.Editing
+ is new; it supports 32-bit character strings. (Shouldn't it
+ have been "Widest_Text_IO.Editing"? :-)
+
+\1f
+File: aarm2012.info, Node: Annex G, Next: Annex H, Prev: Annex F, Up: Top
+
+Annex G Numerics
+****************
+
+1
+The Numerics Annex specifies
+
+2
+ * features for complex arithmetic, including complex I/O;
+
+3
+ * a mode ("strict mode"), in which the predefined arithmetic
+ operations of floating point and fixed point types and the
+ functions and operations of various predefined packages have to
+ provide guaranteed accuracy or conform to other numeric performance
+ requirements, which the Numerics Annex also specifies;
+
+4
+ * a mode ("relaxed mode"), in which no accuracy or other numeric
+ performance requirements need be satisfied, as for implementations
+ not conforming to the Numerics Annex;
+
+5/2
+ * {AI95-00296-01AI95-00296-01} models of floating point and fixed
+ point arithmetic on which the accuracy requirements of strict mode
+ are based;
+
+6/2
+ * {AI95-00296-01AI95-00296-01} the definitions of the model-oriented
+ attributes of floating point types that apply in the strict mode;
+ and
+
+6.1/2
+ * {AI95-00296-01AI95-00296-01} features for the manipulation of real
+ and complex vectors and matrices.
+
+ _Implementation Advice_
+
+7/3
+{AI05-0229-1AI05-0229-1} If Fortran (respectively, C) is widely
+supported in the target environment, implementations supporting the
+Numerics Annex should provide the child package Interfaces.Fortran
+(respectively, Interfaces.C) specified in *note Annex B:: and should
+support a convention_identifier of Fortran (respectively, C) for the
+Convention aspect (see *note Annex B::), thus allowing Ada programs to
+interface with programs written in that language.
+
+7.a.1/2
+ Implementation Advice: If Fortran (respectively, C) is
+ supported in the target environment, then interfacing to
+ Fortran (respectively, C) should be supported as specified in
+ *note Annex B::.
+
+ _Extensions to Ada 83_
+
+7.a
+ This Annex is new to Ada 95.
+
+* Menu:
+
+* G.1 :: Complex Arithmetic
+* G.2 :: Numeric Performance Requirements
+* G.3 :: Vector and Matrix Manipulation
+
+\1f
+File: aarm2012.info, Node: G.1, Next: G.2, Up: Annex G
+
+G.1 Complex Arithmetic
+======================
+
+1
+Types and arithmetic operations for complex arithmetic are provided in
+Generic_Complex_Types, which is defined in *note G.1.1::.
+Implementation-defined approximations to the complex analogs of the
+mathematical functions known as the "elementary functions" are provided
+by the subprograms in Generic_Complex_Elementary_Functions, which is
+defined in *note G.1.2::. Both of these library units are generic
+children of the predefined package Numerics (see *note A.5::).
+Nongeneric equivalents of these generic packages for each of the
+predefined floating point types are also provided as children of
+Numerics.
+
+1.a
+ Implementation defined: The accuracy actually achieved by the
+ complex elementary functions and by other complex arithmetic
+ operations.
+
+1.b
+ Discussion: Complex arithmetic is defined in the Numerics
+ Annex, rather than in the core, because it is considered to be
+ a specialized need of (some) numeric applications.
+
+* Menu:
+
+* G.1.1 :: Complex Types
+* G.1.2 :: Complex Elementary Functions
+* G.1.3 :: Complex Input-Output
+* G.1.4 :: The Package Wide_Text_IO.Complex_IO
+* G.1.5 :: The Package Wide_Wide_Text_IO.Complex_IO
+
+\1f
+File: aarm2012.info, Node: G.1.1, Next: G.1.2, Up: G.1
+
+G.1.1 Complex Types
+-------------------
+
+ _Static Semantics_
+
+1
+The generic library package Numerics.Generic_Complex_Types has the
+following declaration:
+
+2/1
+ {8652/00208652/0020} {AI95-00126-01AI95-00126-01} generic
+ type Real is digits <>;
+ package Ada.Numerics.Generic_Complex_Types is
+ pragma Pure(Generic_Complex_Types);
+
+3
+ type Complex is
+ record
+ Re, Im : Real'Base;
+ end record;
+
+4/2
+ {AI95-00161-01AI95-00161-01} type Imaginary is private;
+ pragma Preelaborable_Initialization(Imaginary);
+
+5
+ i : constant Imaginary;
+ j : constant Imaginary;
+
+6
+ function Re (X : Complex) return Real'Base;
+ function Im (X : Complex) return Real'Base;
+ function Im (X : Imaginary) return Real'Base;
+
+7
+ procedure Set_Re (X : in out Complex;
+ Re : in Real'Base);
+ procedure Set_Im (X : in out Complex;
+ Im : in Real'Base);
+ procedure Set_Im (X : out Imaginary;
+ Im : in Real'Base);
+
+8
+ function Compose_From_Cartesian (Re, Im : Real'Base) return Complex;
+ function Compose_From_Cartesian (Re : Real'Base) return Complex;
+ function Compose_From_Cartesian (Im : Imaginary) return Complex;
+
+9
+ function Modulus (X : Complex) return Real'Base;
+ function "abs" (Right : Complex) return Real'Base renames Modulus;
+
+10
+ function Argument (X : Complex) return Real'Base;
+ function Argument (X : Complex;
+ Cycle : Real'Base) return Real'Base;
+
+11
+ function Compose_From_Polar (Modulus, Argument : Real'Base)
+ return Complex;
+ function Compose_From_Polar (Modulus, Argument, Cycle : Real'Base)
+ return Complex;
+
+12
+ function "+" (Right : Complex) return Complex;
+ function "-" (Right : Complex) return Complex;
+ function Conjugate (X : Complex) return Complex;
+
+13
+ function "+" (Left, Right : Complex) return Complex;
+ function "-" (Left, Right : Complex) return Complex;
+ function "*" (Left, Right : Complex) return Complex;
+ function "/" (Left, Right : Complex) return Complex;
+
+14
+ function "**" (Left : Complex; Right : Integer) return Complex;
+
+15
+ function "+" (Right : Imaginary) return Imaginary;
+ function "-" (Right : Imaginary) return Imaginary;
+ function Conjugate (X : Imaginary) return Imaginary renames "-";
+ function "abs" (Right : Imaginary) return Real'Base;
+
+16
+ function "+" (Left, Right : Imaginary) return Imaginary;
+ function "-" (Left, Right : Imaginary) return Imaginary;
+ function "*" (Left, Right : Imaginary) return Real'Base;
+ function "/" (Left, Right : Imaginary) return Real'Base;
+
+17
+ function "**" (Left : Imaginary; Right : Integer) return Complex;
+
+18
+ function "<" (Left, Right : Imaginary) return Boolean;
+ function "<=" (Left, Right : Imaginary) return Boolean;
+ function ">" (Left, Right : Imaginary) return Boolean;
+ function ">=" (Left, Right : Imaginary) return Boolean;
+
+19
+ function "+" (Left : Complex; Right : Real'Base) return Complex;
+ function "+" (Left : Real'Base; Right : Complex) return Complex;
+ function "-" (Left : Complex; Right : Real'Base) return Complex;
+ function "-" (Left : Real'Base; Right : Complex) return Complex;
+ function "*" (Left : Complex; Right : Real'Base) return Complex;
+ function "*" (Left : Real'Base; Right : Complex) return Complex;
+ function "/" (Left : Complex; Right : Real'Base) return Complex;
+ function "/" (Left : Real'Base; Right : Complex) return Complex;
+
+20
+ function "+" (Left : Complex; Right : Imaginary) return Complex;
+ function "+" (Left : Imaginary; Right : Complex) return Complex;
+ function "-" (Left : Complex; Right : Imaginary) return Complex;
+ function "-" (Left : Imaginary; Right : Complex) return Complex;
+ function "*" (Left : Complex; Right : Imaginary) return Complex;
+ function "*" (Left : Imaginary; Right : Complex) return Complex;
+ function "/" (Left : Complex; Right : Imaginary) return Complex;
+ function "/" (Left : Imaginary; Right : Complex) return Complex;
+
+21
+ function "+" (Left : Imaginary; Right : Real'Base) return Complex;
+ function "+" (Left : Real'Base; Right : Imaginary) return Complex;
+ function "-" (Left : Imaginary; Right : Real'Base) return Complex;
+ function "-" (Left : Real'Base; Right : Imaginary) return Complex;
+ function "*" (Left : Imaginary; Right : Real'Base) return Imaginary;
+ function "*" (Left : Real'Base; Right : Imaginary) return Imaginary;
+ function "/" (Left : Imaginary; Right : Real'Base) return Imaginary;
+ function "/" (Left : Real'Base; Right : Imaginary) return Imaginary;
+
+22
+ private
+
+23
+ type Imaginary is new Real'Base;
+ i : constant Imaginary := 1.0;
+ j : constant Imaginary := 1.0;
+
+24
+ end Ada.Numerics.Generic_Complex_Types;
+
+25/1
+{8652/00208652/0020} {AI95-00126-01AI95-00126-01} The library package
+Numerics.Complex_Types is declared pure and defines the same types,
+constants, and subprograms as Numerics.Generic_Complex_Types, except
+that the predefined type Float is systematically substituted for
+Real'Base throughout. Nongeneric equivalents of
+Numerics.Generic_Complex_Types for each of the other predefined floating
+point types are defined similarly, with the names
+Numerics.Short_Complex_Types, Numerics.Long_Complex_Types, etc.
+
+25.a
+ Reason: The nongeneric equivalents are provided to allow the
+ programmer to construct simple mathematical applications
+ without being required to understand and use generics.
+
+25.b
+ Reason: The nongeneric equivalents all export the types
+ Complex and Imaginary and the constants i and j (rather than
+ uniquely named types and constants, such as Short_Complex,
+ Long_Complex, etc.) to preserve their equivalence to actual
+ instantiations of the generic package and to allow the
+ programmer to change the precision of an application globally
+ by changing a single context clause.
+
+26/2
+{AI95-00434-01AI95-00434-01} [Complex is a visible type with Cartesian
+components.]
+
+26.a
+ Reason: The Cartesian representation is far more common than
+ the polar representation, in practice. The accuracy of the
+ results of the complex arithmetic operations and of the
+ complex elementary functions is dependent on the
+ representation; thus, implementers need to know that
+ representation. The type is visible so that complex
+ "literals" can be written in aggregate notation, if desired.
+
+27
+[Imaginary is a private type; its full type is derived from Real'Base.]
+
+27.a
+ Reason: The Imaginary type and the constants i and j are
+ provided for two reasons:
+
+27.b
+ * They allow complex "literals" to be written in the
+ alternate form of a + b*i (or a + b*j), if desired. Of
+ course, in some contexts the sum will need to be
+ parenthesized.
+
+27.c
+ * When an Ada binding to IEC 559:1989 that provides
+ (signed) infinities as the result of operations that
+ overflow becomes available, it will be important to allow
+ arithmetic between pure-imaginary and complex operands
+ without requiring the former to be represented as (or
+ promoted to) complex values with a real component of
+ zero. For example, the multiplication of a + b*i by d*i
+ should yield -b· d + a· d*i, but if one cannot avoid
+ representing the pure-imaginary value d*i as the complex
+ value 0.0 + d*i, then a NaN ("Not-a-Number") could be
+ produced as the result of multiplying a by 0.0 (e.g.,
+ when a is infinite); the NaN could later trigger an
+ exception. Providing the Imaginary type and overloadings
+ of the arithmetic operators for mixtures of Imaginary and
+ Complex operands gives the programmer the same control
+ over avoiding premature coercion of pure-imaginary values
+ to complex as is already provided for pure-real values.
+
+27.d
+ Reason: The Imaginary type is private, rather than being
+ visibly derived from Real'Base, for two reasons:
+
+27.e
+ * to preclude implicit conversions of real literals to the
+ Imaginary type (such implicit conversions would make many
+ common arithmetic expressions ambiguous); and
+
+27.f
+ * to suppress the implicit derivation of the
+ multiplication, division, and absolute value operators
+ with Imaginary operands and an Imaginary result (the
+ result type would be incorrect).
+
+27.g
+ Reason: The base subtype Real'Base is used for the component
+ type of Complex, the parent type of Imaginary, and the
+ parameter and result types of some of the subprograms to
+ maximize the chances of being able to pass meaningful values
+ into the subprograms and receive meaningful results back. The
+ generic formal parameter Real therefore plays only one role,
+ that of providing the precision to be maintained in complex
+ arithmetic calculations. Thus, the subprograms in
+ Numerics.Generic_Complex_Types share with those in
+ Numerics.Generic_Elementary_Functions, and indeed even with
+ the predefined arithmetic operations (see *note 4.5::), the
+ property of being free of range checks on input and output,
+ i.e., of being able to exploit the base range of the relevant
+ floating point type fully. As a result, the user loses the
+ ability to impose application-oriented bounds on the range of
+ values that the components of a complex variable can acquire;
+ however, it can be argued that few, if any, applications have
+ a naturally square domain (as opposed to a circular domain)
+ anyway.
+
+28
+The arithmetic operations and the Re, Im, Modulus, Argument, and
+Conjugate functions have their usual mathematical meanings. When
+applied to a parameter of pure-imaginary type, the "imaginary-part"
+function Im yields the value of its parameter, as the corresponding real
+value. The remaining subprograms have the following meanings:
+
+28.a
+ Reason: The middle case can be understood by considering the
+ parameter of pure-imaginary type to represent a complex value
+ with a zero real part.
+
+29
+ * The Set_Re and Set_Im procedures replace the designated component
+ of a complex parameter with the given real value; applied to a
+ parameter of pure-imaginary type, the Set_Im procedure replaces the
+ value of that parameter with the imaginary value corresponding to
+ the given real value.
+
+30
+ * The Compose_From_Cartesian function constructs a complex value from
+ the given real and imaginary components. If only one component is
+ given, the other component is implicitly zero.
+
+31
+ * The Compose_From_Polar function constructs a complex value from the
+ given modulus (radius) and argument (angle). When the value of the
+ parameter Modulus is positive (resp., negative), the result is the
+ complex value represented by the point in the complex plane lying
+ at a distance from the origin given by the absolute value of
+ Modulus and forming an angle measured counterclockwise from the
+ positive (resp., negative) real axis given by the value of the
+ parameter Argument.
+
+32
+When the Cycle parameter is specified, the result of the Argument
+function and the parameter Argument of the Compose_From_Polar function
+are measured in units such that a full cycle of revolution has the given
+value; otherwise, they are measured in radians.
+
+33
+The computed results of the mathematically multivalued functions are
+rendered single-valued by the following conventions, which are meant to
+imply the principal branch:
+
+34
+ * The result of the Modulus function is nonnegative.
+
+35
+ * The result of the Argument function is in the quadrant containing
+ the point in the complex plane represented by the parameter X. This
+ may be any quadrant (I through IV); thus, the range of the Argument
+ function is approximately -PI to PI (-Cycle/2.0 to Cycle/2.0, if
+ the parameter Cycle is specified). When the point represented by
+ the parameter X lies on the negative real axis, the result
+ approximates
+
+36
+ * PI (resp., -PI) when the sign of the imaginary component
+ of X is positive (resp., negative), if Real'Signed_Zeros
+ is True;
+
+37
+ * PI, if Real'Signed_Zeros is False.
+
+38
+ * Because a result lying on or near one of the axes may not be
+ exactly representable, the approximation inherent in computing the
+ result may place it in an adjacent quadrant, close to but on the
+ wrong side of the axis.
+
+ _Dynamic Semantics_
+
+39
+The exception Numerics.Argument_Error is raised by the Argument and
+Compose_From_Polar functions with specified cycle, signaling a parameter
+value outside the domain of the corresponding mathematical function,
+when the value of the parameter Cycle is zero or negative.
+
+40
+The exception Constraint_Error is raised by the division operator when
+the value of the right operand is zero, and by the exponentiation
+operator when the value of the left operand is zero and the value of the
+exponent is negative, provided that Real'Machine_Overflows is True; when
+Real'Machine_Overflows is False, the result is unspecified.
+[Constraint_Error can also be raised when a finite result overflows (see
+*note G.2.6::).]
+
+40.a
+ Discussion: It is anticipated that an Ada binding to IEC
+ 559:1989 will be developed in the future. As part of such a
+ binding, the Machine_Overflows attribute of a conformant
+ floating point type will be specified to yield False, which
+ will permit implementations of the complex arithmetic
+ operations to deliver results with an infinite component (and
+ set the overflow flag defined by the binding) instead of
+ raising Constraint_Error in overflow situations, when traps
+ are disabled. Similarly, it is appropriate for the complex
+ arithmetic operations to deliver results with infinite
+ components (and set the zero-divide flag defined by the
+ binding) instead of raising Constraint_Error in the situations
+ defined above, when traps are disabled. Finally, such a
+ binding should also specify the behavior of the complex
+ arithmetic operations, when sensible, given operands with
+ infinite components.
+
+ _Implementation Requirements_
+
+41
+In the implementation of Numerics.Generic_Complex_Types, the range of
+intermediate values allowed during the calculation of a final result
+shall not be affected by any range constraint of the subtype Real.
+
+41.a
+ Implementation Note: Implementations of
+ Numerics.Generic_Complex_Types written in Ada should therefore
+ avoid declaring local variables of subtype Real; the subtype
+ Real'Base should be used instead.
+
+42
+In the following cases, evaluation of a complex arithmetic operation
+shall yield the prescribed result, provided that the preceding rules do
+not call for an exception to be raised:
+
+43
+ * The results of the Re, Im, and Compose_From_Cartesian functions are
+ exact.
+
+44
+ * The real (resp., imaginary) component of the result of a binary
+ addition operator that yields a result of complex type is exact
+ when either of its operands is of pure-imaginary (resp., real)
+ type.
+
+44.a
+ Ramification: The result of the addition operator is exact
+ when one of its operands is of real type and the other is of
+ pure-imaginary type. In this particular case, the operator is
+ analogous to the Compose_From_Cartesian function; it performs
+ no arithmetic.
+
+45
+ * The real (resp., imaginary) component of the result of a binary
+ subtraction operator that yields a result of complex type is exact
+ when its right operand is of pure-imaginary (resp., real) type.
+
+46
+ * The real component of the result of the Conjugate function for the
+ complex type is exact.
+
+47
+ * When the point in the complex plane represented by the parameter X
+ lies on the nonnegative real axis, the Argument function yields a
+ result of zero.
+
+47.a
+ Discussion: Argument(X + i*Y) is analogous to EF.Arctan(Y, X),
+ where EF is an appropriate instance of
+ Numerics.Generic_Elementary_Functions, except when X and Y are
+ both zero, in which case the former yields the value zero
+ while the latter raises Numerics.Argument_Error.
+
+48
+ * When the value of the parameter Modulus is zero, the
+ Compose_From_Polar function yields a result of zero.
+
+49
+ * When the value of the parameter Argument is equal to a multiple of
+ the quarter cycle, the result of the Compose_From_Polar function
+ with specified cycle lies on one of the axes. In this case, one of
+ its components is zero, and the other has the magnitude of the
+ parameter Modulus.
+
+50
+ * Exponentiation by a zero exponent yields the value one.
+ Exponentiation by a unit exponent yields the value of the left
+ operand. Exponentiation of the value one yields the value one.
+ Exponentiation of the value zero yields the value zero, provided
+ that the exponent is nonzero. When the left operand is of
+ pure-imaginary type, one component of the result of the
+ exponentiation operator is zero.
+
+51
+When the result, or a result component, of any operator of
+Numerics.Generic_Complex_Types has a mathematical definition in terms of
+a single arithmetic or relational operation, that result or result
+component exhibits the accuracy of the corresponding operation of the
+type Real.
+
+52
+Other accuracy requirements for the Modulus, Argument, and
+Compose_From_Polar functions, and accuracy requirements for the
+multiplication of a pair of complex operands or for division by a
+complex operand, all of which apply only in the strict mode, are given
+in *note G.2.6::.
+
+53
+The sign of a zero result or zero result component yielded by a complex
+arithmetic operation or function is implementation defined when
+Real'Signed_Zeros is True.
+
+53.a
+ Implementation defined: The sign of a zero result (or a
+ component thereof) from any operator or function in
+ Numerics.Generic_Complex_Types, when Real'Signed_Zeros is
+ True.
+
+ _Implementation Permissions_
+
+54
+The nongeneric equivalent packages may, but need not, be actual
+instantiations of the generic package for the appropriate predefined
+type.
+
+55/2
+{8652/00918652/0091} {AI95-00434-01AI95-00434-01} Implementations may
+obtain the result of exponentiation of a complex or pure-imaginary
+operand by repeated complex multiplication, with arbitrary association
+of the factors and with a possible final complex reciprocation (when the
+exponent is negative). Implementations are also permitted to obtain the
+result of exponentiation of a complex operand, but not of a
+pure-imaginary operand, by converting the left operand to a polar
+representation; exponentiating the modulus by the given exponent;
+multiplying the argument by the given exponent; and reconverting to a
+Cartesian representation. Because of this implementation freedom, no
+accuracy requirement is imposed on complex exponentiation (except for
+the prescribed results given above, which apply regardless of the
+implementation method chosen).
+
+ _Implementation Advice_
+
+56
+Because the usual mathematical meaning of multiplication of a complex
+operand and a real operand is that of the scaling of both components of
+the former by the latter, an implementation should not perform this
+operation by first promoting the real operand to complex type and then
+performing a full complex multiplication. In systems that, in the
+future, support an Ada binding to IEC 559:1989, the latter technique
+will not generate the required result when one of the components of the
+complex operand is infinite. (Explicit multiplication of the infinite
+component by the zero component obtained during promotion yields a NaN
+that propagates into the final result.) Analogous advice applies in the
+case of multiplication of a complex operand and a pure-imaginary
+operand, and in the case of division of a complex operand by a real or
+pure-imaginary operand.
+
+56.a/2
+ Implementation Advice: Mixed real and complex operations (as
+ well as pure-imaginary and complex operations) should not be
+ performed by converting the real (resp. pure-imaginary)
+ operand to complex.
+
+57
+Likewise, because the usual mathematical meaning of addition of a
+complex operand and a real operand is that the imaginary operand remains
+unchanged, an implementation should not perform this operation by first
+promoting the real operand to complex type and then performing a full
+complex addition. In implementations in which the Signed_Zeros
+attribute of the component type is True (and which therefore conform to
+IEC 559:1989 in regard to the handling of the sign of zero in predefined
+arithmetic operations), the latter technique will not generate the
+required result when the imaginary component of the complex operand is a
+negatively signed zero. (Explicit addition of the negative zero to the
+zero obtained during promotion yields a positive zero.) Analogous
+advice applies in the case of addition of a complex operand and a
+pure-imaginary operand, and in the case of subtraction of a complex
+operand and a real or pure-imaginary operand.
+
+58
+Implementations in which Real'Signed_Zeros is True should attempt to
+provide a rational treatment of the signs of zero results and result
+components. As one example, the result of the Argument function should
+have the sign of the imaginary component of the parameter X when the
+point represented by that parameter lies on the positive real axis; as
+another, the sign of the imaginary component of the Compose_From_Polar
+function should be the same as (resp., the opposite of) that of the
+Argument parameter when that parameter has a value of zero and the
+Modulus parameter has a nonnegative (resp., negative) value.
+
+58.a.1/3
+ Implementation Advice: If Real'Signed_Zeros is True for
+ Numerics.Generic_Complex_Types, a rational treatment of the
+ signs of zero results and result components should be
+ provided.
+
+ _Wording Changes from Ada 83_
+
+58.a
+ The semantics of Numerics.Generic_Complex_Types differs from
+ Generic_Complex_Types as defined in ISO/IEC CD 13813 (for Ada
+ 83) in the following ways:
+
+58.b
+ * The generic package is a child of the package defining
+ the Argument_Error exception.
+
+58.c
+ * The nongeneric equivalents export types and constants
+ with the same names as those exported by the generic
+ package, rather than with names unique to the package.
+
+58.d
+ * Implementations are not allowed to impose an optional
+ restriction that the generic actual parameter associated
+ with Real be unconstrained. (In view of the ability to
+ declare variables of subtype Real'Base in implementations
+ of Numerics.Generic_Complex_Types, this flexibility is no
+ longer needed.)
+
+58.e
+ * The dependence of the Argument function on the sign of a
+ zero parameter component is tied to the value of
+ Real'Signed_Zeros.
+
+58.f
+ * Conformance to accuracy requirements is conditional.
+
+ _Extensions to Ada 95_
+
+58.g/2
+ {AI95-00161-01AI95-00161-01} Amendment Correction: Added a
+ pragma Preelaborable_Initialization to type Imaginary, so that
+ it can be used in preelaborated units.
+
+ _Wording Changes from Ada 95_
+
+58.h/2
+ {8652/00208652/0020} {AI95-00126-01AI95-00126-01} Corrigendum:
+ Explicitly stated that the nongeneric equivalents of
+ Generic_Complex_Types are pure.
+
+\1f
+File: aarm2012.info, Node: G.1.2, Next: G.1.3, Prev: G.1.1, Up: G.1
+
+G.1.2 Complex Elementary Functions
+----------------------------------
+
+ _Static Semantics_
+
+1
+The generic library package
+Numerics.Generic_Complex_Elementary_Functions has the following
+declaration:
+
+2/2
+ {AI95-00434-01AI95-00434-01} with Ada.Numerics.Generic_Complex_Types;
+ generic
+ with package Complex_Types is
+ new Ada.Numerics.Generic_Complex_Types (<>);
+ use Complex_Types;
+ package Ada.Numerics.Generic_Complex_Elementary_Functions is
+ pragma Pure(Generic_Complex_Elementary_Functions);
+
+3
+ function Sqrt (X : Complex) return Complex;
+ function Log (X : Complex) return Complex;
+ function Exp (X : Complex) return Complex;
+ function Exp (X : Imaginary) return Complex;
+ function "**" (Left : Complex; Right : Complex) return Complex;
+ function "**" (Left : Complex; Right : Real'Base) return Complex;
+ function "**" (Left : Real'Base; Right : Complex) return Complex;
+
+4
+ function Sin (X : Complex) return Complex;
+ function Cos (X : Complex) return Complex;
+ function Tan (X : Complex) return Complex;
+ function Cot (X : Complex) return Complex;
+
+5
+ function Arcsin (X : Complex) return Complex;
+ function Arccos (X : Complex) return Complex;
+ function Arctan (X : Complex) return Complex;
+ function Arccot (X : Complex) return Complex;
+
+6
+ function Sinh (X : Complex) return Complex;
+ function Cosh (X : Complex) return Complex;
+ function Tanh (X : Complex) return Complex;
+ function Coth (X : Complex) return Complex;
+
+7
+ function Arcsinh (X : Complex) return Complex;
+ function Arccosh (X : Complex) return Complex;
+ function Arctanh (X : Complex) return Complex;
+ function Arccoth (X : Complex) return Complex;
+
+8
+ end Ada.Numerics.Generic_Complex_Elementary_Functions;
+
+9/1
+{8652/00208652/0020} {AI95-00126-01AI95-00126-01} The library package
+Numerics.Complex_Elementary_Functions is declared pure and defines the
+same subprograms as Numerics.Generic_Complex_Elementary_Functions,
+except that the predefined type Float is systematically substituted for
+Real'Base, and the Complex and Imaginary types exported by
+Numerics.Complex_Types are systematically substituted for Complex and
+Imaginary, throughout. Nongeneric equivalents of
+Numerics.Generic_Complex_Elementary_Functions corresponding to each of
+the other predefined floating point types are defined similarly, with
+the names Numerics.Short_Complex_Elementary_Functions,
+Numerics.Long_Complex_Elementary_Functions, etc.
+
+9.a
+ Reason: The nongeneric equivalents are provided to allow the
+ programmer to construct simple mathematical applications
+ without being required to understand and use generics.
+
+10
+The overloading of the Exp function for the pure-imaginary type is
+provided to give the user an alternate way to compose a complex value
+from a given modulus and argument. In addition to
+Compose_From_Polar(Rho, Theta) (see *note G.1.1::), the programmer may
+write Rho * Exp(i * Theta).
+
+11
+The imaginary (resp., real) component of the parameter X of the forward
+hyperbolic (resp., trigonometric) functions and of the Exp function (and
+the parameter X, itself, in the case of the overloading of the Exp
+function for the pure-imaginary type) represents an angle measured in
+radians, as does the imaginary (resp., real) component of the result of
+the Log and inverse hyperbolic (resp., trigonometric) functions.
+
+12
+The functions have their usual mathematical meanings. However, the
+arbitrariness inherent in the placement of branch cuts, across which
+some of the complex elementary functions exhibit discontinuities, is
+eliminated by the following conventions:
+
+13
+ * The imaginary component of the result of the Sqrt and Log functions
+ is discontinuous as the parameter X crosses the negative real axis.
+
+14
+ * The result of the exponentiation operator when the left operand is
+ of complex type is discontinuous as that operand crosses the
+ negative real axis.
+
+15/2
+ * {AI95-00185-01AI95-00185-01} The imaginary component of the result
+ of the Arcsin, Arccos, and Arctanh functions is discontinuous as
+ the parameter X crosses the real axis to the left of -1.0 or the
+ right of 1.0.
+
+16/2
+ * {AI95-00185-01AI95-00185-01} The real component of the result of
+ the Arctan and Arcsinh functions is discontinuous as the parameter
+ X crosses the imaginary axis below -i or above i.
+
+17/2
+ * {AI95-00185-01AI95-00185-01} The real component of the result of
+ the Arccot function is discontinuous as the parameter X crosses the
+ imaginary axis below -i or above i.
+
+18
+ * The imaginary component of the Arccosh function is discontinuous as
+ the parameter X crosses the real axis to the left of 1.0.
+
+19
+ * The imaginary component of the result of the Arccoth function is
+ discontinuous as the parameter X crosses the real axis between -1.0
+ and 1.0.
+
+19.a/2
+ Discussion: {AI95-00185-01AI95-00185-01} The branch cuts come
+ from the fact that the functions in question are really
+ multi-valued in the complex domain, and that we have to pick
+ one principal value to be the result of the function.
+ Evidently we have much freedom in choosing where the branch
+ cuts lie. However, we are adhering to the following
+ principles which seem to lead to the more natural definitions:
+
+19.b/2
+ * A branch cut should not intersect the real axis at a
+ place where the corresponding real function is
+ well-defined (in other words, the complex function should
+ be an extension of the corresponding real function).
+
+19.c/2
+ * Because all the functions in question are analytic, to
+ ensure power series validity for the principal value, the
+ branch cuts should be invariant by complex conjugation.
+
+19.d/2
+ * For odd functions, to ensure that the principal value
+ remains an odd function, the branch cuts should be
+ invariant by reflection in the origin.
+
+20/2
+{AI95-00185-01AI95-00185-01} The computed results of the mathematically
+multivalued functions are rendered single-valued by the following
+conventions, which are meant to imply that the principal branch is an
+analytic continuation of the corresponding real-valued function in
+Numerics.Generic_Elementary_Functions. (For Arctan and Arccot, the
+single-argument function in question is that obtained from the
+two-argument version by fixing the second argument to be its default
+value.)
+
+21
+ * The real component of the result of the Sqrt and Arccosh functions
+ is nonnegative.
+
+22
+ * The same convention applies to the imaginary component of the
+ result of the Log function as applies to the result of the
+ natural-cycle version of the Argument function of
+ Numerics.Generic_Complex_Types (see *note G.1.1::).
+
+23
+ * The range of the real (resp., imaginary) component of the result of
+ the Arcsin and Arctan (resp., Arcsinh and Arctanh) functions is
+ approximately -PI/2.0 to PI/2.0.
+
+24
+ * The real (resp., imaginary) component of the result of the Arccos
+ and Arccot (resp., Arccoth) functions ranges from 0.0 to
+ approximately PI.
+
+25
+ * The range of the imaginary component of the result of the Arccosh
+ function is approximately -PI to PI.
+
+26
+In addition, the exponentiation operator inherits the single-valuedness
+of the Log function.
+
+ _Dynamic Semantics_
+
+27
+The exception Numerics.Argument_Error is raised by the exponentiation
+operator, signaling a parameter value outside the domain of the
+corresponding mathematical function, when the value of the left operand
+is zero and the real component of the exponent (or the exponent itself,
+when it is of real type) is zero.
+
+28
+The exception Constraint_Error is raised, signaling a pole of the
+mathematical function (analogous to dividing by zero), in the following
+cases, provided that Complex_Types.Real'Machine_Overflows is True:
+
+29
+ * by the Log, Cot, and Coth functions, when the value of the
+ parameter X is zero;
+
+30
+ * by the exponentiation operator, when the value of the left operand
+ is zero and the real component of the exponent (or the exponent
+ itself, when it is of real type) is negative;
+
+31
+ * by the Arctan and Arccot functions, when the value of the parameter
+ X is ± i;
+
+32
+ * by the Arctanh and Arccoth functions, when the value of the
+ parameter X is ± 1.0.
+
+33
+[Constraint_Error can also be raised when a finite result overflows (see
+*note G.2.6::); this may occur for parameter values sufficiently near
+poles, and, in the case of some of the functions, for parameter values
+having components of sufficiently large magnitude.] When
+Complex_Types.Real'Machine_Overflows is False, the result at poles is
+unspecified.
+
+33.a
+ Reason: The purpose of raising Constraint_Error (rather than
+ Numerics.Argument_Error) at the poles of a function, when
+ Float_Type'Machine_Overflows is True, is to provide continuous
+ behavior as the actual parameters of the function approach the
+ pole and finally reach it.
+
+33.b
+ Discussion: It is anticipated that an Ada binding to IEC
+ 559:1989 will be developed in the future. As part of such a
+ binding, the Machine_Overflows attribute of a conformant
+ floating point type will be specified to yield False, which
+ will permit implementations of the complex elementary
+ functions to deliver results with an infinite component (and
+ set the overflow flag defined by the binding) instead of
+ raising Constraint_Error in overflow situations, when traps
+ are disabled. Similarly, it is appropriate for the complex
+ elementary functions to deliver results with an infinite
+ component (and set the zero-divide flag defined by the
+ binding) instead of raising Constraint_Error at poles, when
+ traps are disabled. Finally, such a binding should also
+ specify the behavior of the complex elementary functions, when
+ sensible, given parameters with infinite components.
+
+ _Implementation Requirements_
+
+34
+In the implementation of Numerics.Generic_Complex_Elementary_Functions,
+the range of intermediate values allowed during the calculation of a
+final result shall not be affected by any range constraint of the
+subtype Complex_Types.Real.
+
+34.a
+ Implementation Note: Implementations of
+ Numerics.Generic_Complex_Elementary_Functions written in Ada
+ should therefore avoid declaring local variables of subtype
+ Complex_Types.Real; the subtype Complex_Types.Real'Base should
+ be used instead.
+
+35
+In the following cases, evaluation of a complex elementary function
+shall yield the prescribed result (or a result having the prescribed
+component), provided that the preceding rules do not call for an
+exception to be raised:
+
+36
+ * When the parameter X has the value zero, the Sqrt, Sin, Arcsin,
+ Tan, Arctan, Sinh, Arcsinh, Tanh, and Arctanh functions yield a
+ result of zero; the Exp, Cos, and Cosh functions yield a result of
+ one; the Arccos and Arccot functions yield a real result; and the
+ Arccoth function yields an imaginary result.
+
+37
+ * When the parameter X has the value one, the Sqrt function yields a
+ result of one; the Log, Arccos, and Arccosh functions yield a
+ result of zero; and the Arcsin function yields a real result.
+
+38
+ * When the parameter X has the value -1.0, the Sqrt function yields
+ the result
+
+39
+ * i (resp., -i), when the sign of the imaginary component
+ of X is positive (resp., negative), if
+ Complex_Types.Real'Signed_Zeros is True;
+
+40
+ * i, if Complex_Types.Real'Signed_Zeros is False;
+
+41/2
+ * {AI95-00434-01AI95-00434-01} When the parameter X has the value
+ -1.0, the Log function yields an imaginary result; and the Arcsin
+ and Arccos functions yield a real result.
+
+42
+ * When the parameter X has the value ± i, the Log function yields an
+ imaginary result.
+
+43
+ * Exponentiation by a zero exponent yields the value one.
+ Exponentiation by a unit exponent yields the value of the left
+ operand (as a complex value). Exponentiation of the value one
+ yields the value one. Exponentiation of the value zero yields the
+ value zero.
+
+43.a
+ Discussion: It is possible to give many other prescribed
+ results restricting the result to the real or imaginary axis
+ when the parameter X is appropriately restricted to easily
+ testable portions of the domain. We follow the proposed
+ ISO/IEC standard for Generic_Complex_Elementary_Functions (for
+ Ada 83), CD 13813, in not doing so, however.
+
+44
+Other accuracy requirements for the complex elementary functions, which
+apply only in the strict mode, are given in *note G.2.6::.
+
+45
+The sign of a zero result or zero result component yielded by a complex
+elementary function is implementation defined when
+Complex_Types.Real'Signed_Zeros is True.
+
+45.a
+ Implementation defined: The sign of a zero result (or a
+ component thereof) from any operator or function in
+ Numerics.Generic_Complex_Elementary_Functions, when
+ Complex_Types.Real'Signed_Zeros is True.
+
+ _Implementation Permissions_
+
+46
+The nongeneric equivalent packages may, but need not, be actual
+instantiations of the generic package with the appropriate predefined
+nongeneric equivalent of Numerics.Generic_Complex_Types; if they are,
+then the latter shall have been obtained by actual instantiation of
+Numerics.Generic_Complex_Types.
+
+47
+The exponentiation operator may be implemented in terms of the Exp and
+Log functions. Because this implementation yields poor accuracy in some
+parts of the domain, no accuracy requirement is imposed on complex
+exponentiation.
+
+48
+The implementation of the Exp function of a complex parameter X is
+allowed to raise the exception Constraint_Error, signaling overflow,
+when the real component of X exceeds an unspecified threshold that is
+approximately log(Complex_Types.Real'Safe_Last). This permission
+recognizes the impracticality of avoiding overflow in the marginal case
+that the exponential of the real component of X exceeds the safe range
+of Complex_Types.Real but both components of the final result do not.
+Similarly, the Sin and Cos (resp., Sinh and Cosh) functions are allowed
+to raise the exception Constraint_Error, signaling overflow, when the
+absolute value of the imaginary (resp., real) component of the parameter
+X exceeds an unspecified threshold that is approximately
+log(Complex_Types.Real'Safe_Last) + log(2.0). This permission
+recognizes the impracticality of avoiding overflow in the marginal case
+that the hyperbolic sine or cosine of the imaginary (resp., real)
+component of X exceeds the safe range of Complex_Types.Real but both
+components of the final result do not.
+
+ _Implementation Advice_
+
+49
+Implementations in which Complex_Types.Real'Signed_Zeros is True should
+attempt to provide a rational treatment of the signs of zero results and
+result components. For example, many of the complex elementary
+functions have components that are odd functions of one of the parameter
+components; in these cases, the result component should have the sign of
+the parameter component at the origin. Other complex elementary
+functions have zero components whose sign is opposite that of a
+parameter component at the origin, or is always positive or always
+negative.
+
+49.a.1/3
+ Implementation Advice: If Complex_Types.Real'Signed_Zeros is
+ True for Numerics.Generic_Complex_Elementary_Functions, a
+ rational treatment of the signs of zero results and result
+ components should be provided.
+
+ _Wording Changes from Ada 83_
+
+49.a
+ The semantics of Numerics.Generic_Complex_Elementary_Functions
+ differs from Generic_Complex_Elementary_Functions as defined
+ in ISO/IEC CD 13814 (for Ada 83) in the following ways:
+
+49.b
+ * The generic package is a child unit of the package
+ defining the Argument_Error exception.
+
+49.c
+ * The proposed Generic_Complex_Elementary_Functions
+ standard (for Ada 83) specified names for the nongeneric
+ equivalents, if provided. Here, those nongeneric
+ equivalents are required.
+
+49.d
+ * The generic package imports an instance of
+ Numerics.Generic_Complex_Types rather than a long list of
+ individual types and operations exported by such an
+ instance.
+
+49.e
+ * The dependence of the imaginary component of the Sqrt and
+ Log functions on the sign of a zero parameter component
+ is tied to the value of Complex_Types.Real'Signed_Zeros.
+
+49.f
+ * Conformance to accuracy requirements is conditional.
+
+ _Wording Changes from Ada 95_
+
+49.g/2
+ {8652/00208652/0020} {AI95-00126-01AI95-00126-01} Corrigendum:
+ Explicitly stated that the nongeneric equivalents of
+ Generic_Complex_Elementary_Functions are pure.
+
+49.h/2
+ {AI95-00185-01AI95-00185-01} Corrected various inconsistencies
+ in the definition of the branch cuts.
+
+\1f
+File: aarm2012.info, Node: G.1.3, Next: G.1.4, Prev: G.1.2, Up: G.1
+
+G.1.3 Complex Input-Output
+--------------------------
+
+1
+The generic package Text_IO.Complex_IO defines procedures for the
+formatted input and output of complex values. The generic actual
+parameter in an instantiation of Text_IO.Complex_IO is an instance of
+Numerics.Generic_Complex_Types for some floating point subtype.
+Exceptional conditions are reported by raising the appropriate exception
+defined in Text_IO.
+
+1.a
+ Implementation Note: An implementation of Text_IO.Complex_IO
+ can be built around an instance of Text_IO.Float_IO for the
+ base subtype of Complex_Types.Real, where Complex_Types is the
+ generic formal package parameter of Text_IO.Complex_IO. There
+ is no need for an implementation of Text_IO.Complex_IO to
+ parse real values.
+
+ _Static Semantics_
+
+2
+The generic library package Text_IO.Complex_IO has the following
+declaration:
+
+2.a
+ Ramification: Because this is a child of Text_IO, the
+ declarations of the visible part of Text_IO are directly
+ visible within it.
+
+3
+ with Ada.Numerics.Generic_Complex_Types;
+ generic
+ with package Complex_Types is
+ new Ada.Numerics.Generic_Complex_Types (<>);
+ package Ada.Text_IO.Complex_IO is
+
+4
+ use Complex_Types;
+
+5
+ Default_Fore : Field := 2;
+ Default_Aft : Field := Real'Digits - 1;
+ Default_Exp : Field := 3;
+
+6
+ procedure Get (File : in File_Type;
+ Item : out Complex;
+ Width : in Field := 0);
+ procedure Get (Item : out Complex;
+ Width : in Field := 0);
+
+7
+ procedure Put (File : in File_Type;
+ Item : in Complex;
+ Fore : in Field := Default_Fore;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+ procedure Put (Item : in Complex;
+ Fore : in Field := Default_Fore;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+
+8
+ procedure Get (From : in String;
+ Item : out Complex;
+ Last : out Positive);
+ procedure Put (To : out String;
+ Item : in Complex;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+
+9
+ end Ada.Text_IO.Complex_IO;
+
+9.1/2
+{AI95-00328-01AI95-00328-01} The library package Complex_Text_IO defines
+the same subprograms as Text_IO.Complex_IO, except that the predefined
+type Float is systematically substituted for Real, and the type
+Numerics.Complex_Types.Complex is systematically substituted for Complex
+throughout. Nongeneric equivalents of Text_IO.Complex_IO corresponding
+to each of the other predefined floating point types are defined
+similarly, with the names Short_Complex_Text_IO, Long_Complex_Text_IO,
+etc.
+
+9.a/2
+ Reason: The nongeneric equivalents are provided to allow the
+ programmer to construct simple mathematical applications
+ without being required to understand and use generics.
+
+10
+The semantics of the Get and Put procedures are as follows:
+
+11
+ procedure Get (File : in File_Type;
+ Item : out Complex;
+ Width : in Field := 0);
+ procedure Get (Item : out Complex;
+ Width : in Field := 0);
+
+12/1
+ {8652/00928652/0092} {AI95-00029-01AI95-00029-01} The input
+ sequence is a pair of optionally signed real literals
+ representing the real and imaginary components of a complex
+ value. These components have the format defined for the
+ corresponding Get procedure of an instance of Text_IO.Float_IO
+ (see *note A.10.9::) for the base subtype of
+ Complex_Types.Real. The pair of components may be separated
+ by a comma or surrounded by a pair of parentheses or both.
+ Blanks are freely allowed before each of the components and
+ before the parentheses and comma, if either is used. If the
+ value of the parameter Width is zero, then
+
+13
+ * line and page terminators are also allowed in these
+ places;
+
+14
+ * the components shall be separated by at least one blank
+ or line terminator if the comma is omitted; and
+
+15
+ * reading stops when the right parenthesis has been read,
+ if the input sequence includes a left parenthesis, or
+ when the imaginary component has been read, otherwise.
+
+15.1
+ If a nonzero value of Width is supplied, then
+
+16
+ * the components shall be separated by at least one blank
+ if the comma is omitted; and
+
+17
+ * exactly Width characters are read, or the characters
+ (possibly none) up to a line terminator, whichever comes
+ first (blanks are included in the count).
+
+17.a
+ Reason: The parenthesized and comma-separated form is the form
+ produced by Put on output (see below), and also by
+ list-directed output in Fortran. The other allowed forms
+ match several common styles of edit-directed output in
+ Fortran, allowing most preexisting Fortran data files
+ containing complex data to be read easily. When such files
+ contain complex values with no separation between the real and
+ imaginary components, the user will have to read those
+ components separately, using an instance of Text_IO.Float_IO.
+
+18
+ Returns, in the parameter Item, the value of type Complex that
+ corresponds to the input sequence.
+
+19
+ The exception Text_IO.Data_Error is raised if the input
+ sequence does not have the required syntax or if the
+ components of the complex value obtained are not of the base
+ subtype of Complex_Types.Real.
+
+20
+ procedure Put (File : in File_Type;
+ Item : in Complex;
+ Fore : in Field := Default_Fore;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+ procedure Put (Item : in Complex;
+ Fore : in Field := Default_Fore;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+
+21
+ Outputs the value of the parameter Item as a pair of decimal
+ literals representing the real and imaginary components of the
+ complex value, using the syntax of an aggregate. More
+ specifically,
+
+22
+ * outputs a left parenthesis;
+
+23
+ * outputs the value of the real component of the parameter
+ Item with the format defined by the corresponding Put
+ procedure of an instance of Text_IO.Float_IO for the base
+ subtype of Complex_Types.Real, using the given values of
+ Fore, Aft, and Exp;
+
+24
+ * outputs a comma;
+
+25
+ * outputs the value of the imaginary component of the
+ parameter Item with the format defined by the
+ corresponding Put procedure of an instance of
+ Text_IO.Float_IO for the base subtype of
+ Complex_Types.Real, using the given values of Fore, Aft,
+ and Exp;
+
+26
+ * outputs a right parenthesis.
+
+26.a
+ Discussion: If the file has a bounded line length, a line
+ terminator may be output implicitly before any element of the
+ sequence itemized above.
+
+26.b
+ Discussion: The option of outputting the complex value as a
+ pair of reals without additional punctuation is not provided,
+ since it can be accomplished by outputting the real and
+ imaginary components of the complex value separately.
+
+27
+ procedure Get (From : in String;
+ Item : out Complex;
+ Last : out Positive);
+
+28/2
+ {AI95-00434-01AI95-00434-01} Reads a complex value from the
+ beginning of the given string, following the same rule as the
+ Get procedure that reads a complex value from a file, but
+ treating the end of the string as a file terminator. Returns,
+ in the parameter Item, the value of type Complex that
+ corresponds to the input sequence. Returns in Last the index
+ value such that From(Last) is the last character read.
+
+29
+ The exception Text_IO.Data_Error is raised if the input
+ sequence does not have the required syntax or if the
+ components of the complex value obtained are not of the base
+ subtype of Complex_Types.Real.
+
+30
+ procedure Put (To : out String;
+ Item : in Complex;
+ Aft : in Field := Default_Aft;
+ Exp : in Field := Default_Exp);
+
+31
+ Outputs the value of the parameter Item to the given string as
+ a pair of decimal literals representing the real and imaginary
+ components of the complex value, using the syntax of an
+ aggregate. More specifically,
+
+32
+ * a left parenthesis, the real component, and a comma are
+ left justified in the given string, with the real
+ component having the format defined by the Put procedure
+ (for output to a file) of an instance of Text_IO.Float_IO
+ for the base subtype of Complex_Types.Real, using a value
+ of zero for Fore and the given values of Aft and Exp;
+
+33
+ * the imaginary component and a right parenthesis are right
+ justified in the given string, with the imaginary
+ component having the format defined by the Put procedure
+ (for output to a file) of an instance of Text_IO.Float_IO
+ for the base subtype of Complex_Types.Real, using a value
+ for Fore that completely fills the remainder of the
+ string, together with the given values of Aft and Exp.
+
+33.a
+ Reason: This rule is the one proposed in LSN-1051. Other
+ rules were considered, including one that would have read
+ "Outputs the value of the parameter Item to the given string,
+ following the same rule as for output to a file, using a value
+ for Fore such that the sequence of characters output exactly
+ fills, or comes closest to filling, the string; in the latter
+ case, the string is filled by inserting one extra blank
+ immediately after the comma." While this latter rule might be
+ considered the closest analogue to the rule for output to a
+ string in Text_IO.Float_IO, it requires a more difficult and
+ inefficient implementation involving special cases when the
+ integer part of one component is substantially longer than
+ that of the other and the string is too short to allow both to
+ be preceded by blanks. Unless such a special case applies,
+ the latter rule might produce better columnar output if
+ several such strings are ultimately output to a file, but very
+ nearly the same output can be produced by outputting to the
+ file directly, with the appropriate value of Fore; in any
+ case, it might validly be assumed that output to a string is
+ intended for further computation rather than for display, so
+ that the precise formatting of the string to achieve a
+ particular appearance is not the major concern.
+
+34
+ The exception Text_IO.Layout_Error is raised if the given
+ string is too short to hold the formatted output.
+
+ _Implementation Permissions_
+
+35
+Other exceptions declared (by renaming) in Text_IO may be raised by the
+preceding procedures in the appropriate circumstances, as for the
+corresponding procedures of Text_IO.Float_IO.
+
+ _Extensions to Ada 95_
+
+35.a/2
+ {AI95-00328-01AI95-00328-01} Nongeneric equivalents for
+ Text_IO.Complex_IO are added, to be consistent with all other
+ language-defined Numerics generic packages.
+
+ _Wording Changes from Ada 95_
+
+35.b/2
+ {8652/00928652/0092} {AI95-00029-01AI95-00029-01} Corrigendum:
+ Clarified that the syntax of values read by Complex_IO is the
+ same as that read by Text_IO.Float_IO.
+
+\1f
+File: aarm2012.info, Node: G.1.4, Next: G.1.5, Prev: G.1.3, Up: G.1
+
+G.1.4 The Package Wide_Text_IO.Complex_IO
+-----------------------------------------
+
+ _Static Semantics_
+
+1
+Implementations shall also provide the generic library package
+Wide_Text_IO.Complex_IO. Its declaration is obtained from that of
+Text_IO.Complex_IO by systematically replacing Text_IO by Wide_Text_IO
+and String by Wide_String; the description of its behavior is obtained
+by additionally replacing references to particular characters (commas,
+parentheses, etc.) by those for the corresponding wide characters.
+
+\1f
+File: aarm2012.info, Node: G.1.5, Prev: G.1.4, Up: G.1
+
+G.1.5 The Package Wide_Wide_Text_IO.Complex_IO
+----------------------------------------------
+
+ _Static Semantics_
+
+1/2
+{AI95-00285-01AI95-00285-01} Implementations shall also provide the
+generic library package Wide_Wide_Text_IO.Complex_IO. Its declaration is
+obtained from that of Text_IO.Complex_IO by systematically replacing
+Text_IO by Wide_Wide_Text_IO and String by Wide_Wide_String; the
+description of its behavior is obtained by additionally replacing
+references to particular characters (commas, parentheses, etc.) by
+those for the corresponding wide wide characters.
+
+ _Extensions to Ada 95_
+
+1.a/2
+ {AI95-00285-01AI95-00285-01} Package
+ Wide_Wide_Text_IO.Complex_IO is new. (At least it wasn't
+ called Incredibly_Wide_Text_IO.Complex_IO; maybe next time.)
+
+\1f
+File: aarm2012.info, Node: G.2, Next: G.3, Prev: G.1, Up: Annex G
+
+G.2 Numeric Performance Requirements
+====================================
+
+ _Implementation Requirements_
+
+1
+Implementations shall provide a user-selectable mode in which the
+accuracy and other numeric performance requirements detailed in the
+following subclauses are observed. This mode, referred to as the strict
+mode, may or may not be the default mode; it directly affects the
+results of the predefined arithmetic operations of real types and the
+results of the subprograms in children of the Numerics package, and
+indirectly affects the operations in other language defined packages.
+Implementations shall also provide the opposing mode, which is known as
+the relaxed mode.
+
+1.a
+ Reason: On the assumption that the users of an implementation
+ that does not support the Numerics Annex have no particular
+ need for numerical performance, such an implementation has no
+ obligation to meet any particular requirements in this area.
+ On the other hand, users of an implementation that does
+ support the Numerics Annex are provided with a way of ensuring
+ that their programs achieve a known level of numerical
+ performance and that the performance is portable to other such
+ implementations. The relaxed mode is provided to allow
+ implementers to offer an efficient but not fully accurate
+ alternative in the case that the strict mode entails a time
+ overhead that some users may find excessive. In some of its
+ areas of impact, the relaxed mode may be fully equivalent to
+ the strict mode.
+
+1.b
+ Implementation Note: The relaxed mode may, for example, be
+ used to exploit the implementation of (some of) the elementary
+ functions in hardware, when available. Such implementations
+ often do not meet the accuracy requirements of the strict
+ mode, or do not meet them over the specified range of
+ parameter values, but compensate in other ways that may be
+ important to the user, such as their extreme speed.
+
+1.c
+ Ramification: For implementations supporting the Numerics
+ Annex, the choice of mode has no effect on the selection of a
+ representation for a real type or on the values of attributes
+ of a real type.
+
+ _Implementation Permissions_
+
+2
+Either mode may be the default mode.
+
+2.a
+ Implementation defined: Whether the strict mode or the relaxed
+ mode is the default.
+
+3
+The two modes need not actually be different.
+
+ _Extensions to Ada 83_
+
+3.a
+ The choice between strict and relaxed numeric performance was
+ not available in Ada 83.
+
+* Menu:
+
+* G.2.1 :: Model of Floating Point Arithmetic
+* G.2.2 :: Model-Oriented Attributes of Floating Point Types
+* G.2.3 :: Model of Fixed Point Arithmetic
+* G.2.4 :: Accuracy Requirements for the Elementary Functions
+* G.2.5 :: Performance Requirements for Random Number Generation
+* G.2.6 :: Accuracy Requirements for Complex Arithmetic
+
+\1f
+File: aarm2012.info, Node: G.2.1, Next: G.2.2, Up: G.2
+
+G.2.1 Model of Floating Point Arithmetic
+----------------------------------------
+
+1
+In the strict mode, the predefined operations of a floating point type
+shall satisfy the accuracy requirements specified here and shall avoid
+or signal overflow in the situations described. This behavior is
+presented in terms of a model of floating point arithmetic that builds
+on the concept of the canonical form (see *note A.5.3::).
+
+ _Static Semantics_
+
+2
+Associated with each floating point type is an infinite set of model
+numbers. The model numbers of a type are used to define the accuracy
+requirements that have to be satisfied by certain predefined operations
+of the type; through certain attributes of the model numbers, they are
+also used to explain the meaning of a user-declared floating point type
+declaration. The model numbers of a derived type are those of the
+parent type; the model numbers of a subtype are those of its type.
+
+3
+The model numbers of a floating point type T are zero and all the values
+expressible in the canonical form (for the type T), in which mantissa
+has T'Model_Mantissa digits and exponent has a value greater than or
+equal to T'Model_Emin. (These attributes are defined in *note G.2.2::.)
+
+3.a
+ Discussion: The model is capable of describing the behavior of
+ most existing hardware that has a mantissa-exponent
+ representation. As applied to a type T, it is parameterized
+ by the values of T'Machine_Radix, T'Model_Mantissa,
+ T'Model_Emin, T'Safe_First, and T'Safe_Last. The values of
+ these attributes are determined by how, and how well, the
+ hardware behaves. They in turn determine the set of model
+ numbers and the safe range of the type, which figure in the
+ accuracy and range (overflow avoidance) requirements.
+
+3.b
+ In hardware that is free of arithmetic anomalies,
+ T'Model_Mantissa, T'Model_Emin, T'Safe_First, and T'Safe_Last
+ will yield the same values as T'Machine_Mantissa,
+ T'Machine_Emin, T'Base'First, and T'Base'Last, respectively,
+ and the model numbers in the safe range of the type T will
+ coincide with the machine numbers of the type T. In less
+ perfect hardware, it is not possible for the model-oriented
+ attributes to have these optimal values, since the hardware,
+ by definition, and therefore the implementation, cannot
+ conform to the stringencies of the resulting model; in this
+ case, the values yielded by the model-oriented parameters have
+ to be made more conservative (i.e., have to be penalized),
+ with the result that the model numbers are more widely
+ separated than the machine numbers, and the safe range is a
+ subrange of the base range. The implementation will then be
+ able to conform to the requirements of the weaker model
+ defined by the sparser set of model numbers and the smaller
+ safe range.
+
+4
+A model interval of a floating point type is any interval whose bounds
+are model numbers of the type. The model interval of a type T
+associated with a value v is the smallest model interval of T that
+includes v. (The model interval associated with a model number of a
+type consists of that number only.)
+
+ _Implementation Requirements_
+
+5
+The accuracy requirements for the evaluation of certain predefined
+operations of floating point types are as follows.
+
+5.a
+ Discussion: This subclause does not cover the accuracy of an
+ operation of a static expression; such operations have to be
+ evaluated exactly (see *note 4.9::). It also does not cover
+ the accuracy of the predefined attributes of a floating point
+ subtype that yield a value of the type; such operations also
+ yield exact results (see *note 3.5.8:: and *note A.5.3::).
+
+6
+An operand interval is the model interval, of the type specified for the
+operand of an operation, associated with the value of the operand.
+
+7
+For any predefined arithmetic operation that yields a result of a
+floating point type T, the required bounds on the result are given by a
+model interval of T (called the result interval) defined in terms of the
+operand values as follows:
+
+8
+ * The result interval is the smallest model interval of T that
+ includes the minimum and the maximum of all the values obtained by
+ applying the (exact) mathematical operation to values arbitrarily
+ selected from the respective operand intervals.
+
+9
+The result interval of an exponentiation is obtained by applying the
+above rule to the sequence of multiplications defined by the exponent,
+assuming arbitrary association of the factors, and to the final division
+in the case of a negative exponent.
+
+10
+The result interval of a conversion of a numeric value to a floating
+point type T is the model interval of T associated with the operand
+value, except when the source expression is of a fixed point type with a
+small that is not a power of T'Machine_Radix or is a fixed point
+multiplication or division either of whose operands has a small that is
+not a power of T'Machine_Radix; in these cases, the result interval is
+implementation defined.
+
+10.a
+ Implementation defined: The result interval in certain cases
+ of fixed-to-float conversion.
+
+11
+For any of the foregoing operations, the implementation shall deliver a
+value that belongs to the result interval when both bounds of the result
+interval are in the safe range of the result type T, as determined by
+the values of T'Safe_First and T'Safe_Last; otherwise,
+
+12
+ * if T'Machine_Overflows is True, the implementation shall either
+ deliver a value that belongs to the result interval or raise
+ Constraint_Error;
+
+13
+ * if T'Machine_Overflows is False, the result is implementation
+ defined.
+
+13.a
+ Implementation defined: The result of a floating point
+ arithmetic operation in overflow situations, when the
+ Machine_Overflows attribute of the result type is False.
+
+14
+For any predefined relation on operands of a floating point type T, the
+implementation may deliver any value (i.e., either True or False)
+obtained by applying the (exact) mathematical comparison to values
+arbitrarily chosen from the respective operand intervals.
+
+15
+The result of a membership test is defined in terms of comparisons of
+the operand value with the lower and upper bounds of the given range or
+type mark (the usual rules apply to these comparisons).
+
+ _Implementation Permissions_
+
+16
+If the underlying floating point hardware implements division as
+multiplication by a reciprocal, the result interval for division (and
+exponentiation by a negative exponent) is implementation defined.
+
+16.a
+ Implementation defined: The result interval for division (or
+ exponentiation by a negative exponent), when the floating
+ point hardware implements division as multiplication by a
+ reciprocal.
+
+ _Wording Changes from Ada 83_
+
+16.b
+ The Ada 95 model numbers of a floating point type that are in
+ the safe range of the type are comparable to the Ada 83 safe
+ numbers of the type. There is no analog of the Ada 83 model
+ numbers. The Ada 95 model numbers, when not restricted to the
+ safe range, are an infinite set.
+
+ _Inconsistencies With Ada 83_
+
+16.c
+ Giving the model numbers the hardware radix, instead of always
+ a radix of two, allows (in conjunction with other changes)
+ some borderline declared types to be represented with less
+ precision than in Ada 83 (i.e., with single precision, whereas
+ Ada 83 would have used double precision). Because the lower
+ precision satisfies the requirements of the model (and did so
+ in Ada 83 as well), this change is viewed as a desirable
+ correction of an anomaly, rather than a worrisome
+ inconsistency. (Of course, the wider representation chosen in
+ Ada 83 also remains eligible for selection in Ada 95.)
+
+16.d
+ As an example of this phenomenon, assume that Float is
+ represented in single precision and that a double precision
+ type is also available. Also assume hexadecimal hardware with
+ clean properties, for example certain IBM hardware. Then,
+
+16.e
+ type T is digits Float'Digits range -Float'Last .. Float'Last;
+
+16.f
+ results in T being represented in double precision in Ada 83
+ and in single precision in Ada 95. The latter is intuitively
+ correct; the former is counterintuitive. The reason why the
+ double precision type is used in Ada 83 is that Float has
+ model and safe numbers (in Ada 83) with 21 binary digits in
+ their mantissas, as is required to model the hypothesized
+ hexadecimal hardware using a binary radix; thus Float'Last,
+ which is not a model number, is slightly outside the range of
+ safe numbers of the single precision type, making that type
+ ineligible for selection as the representation of T even
+ though it provides adequate precision. In Ada 95, Float'Last
+ (the same value as before) is a model number and is in the
+ safe range of Float on the hypothesized hardware, making Float
+ eligible for the representation of T.
+
+ _Extensions to Ada 83_
+
+16.g
+ Giving the model numbers the hardware radix allows for
+ practical implementations on decimal hardware.
+
+ _Wording Changes from Ada 83_
+
+16.h
+ The wording of the model of floating point arithmetic has been
+ simplified to a large extent.
+
+\1f
+File: aarm2012.info, Node: G.2.2, Next: G.2.3, Prev: G.2.1, Up: G.2
+
+G.2.2 Model-Oriented Attributes of Floating Point Types
+-------------------------------------------------------
+
+1
+In implementations that support the Numerics Annex, the model-oriented
+attributes of floating point types shall yield the values defined here,
+in both the strict and the relaxed modes. These definitions add
+conditions to those in *note A.5.3::.
+
+ _Static Semantics_
+
+2
+For every subtype S of a floating point type T:
+
+3/2
+{AI95-00256-01AI95-00256-01} S'Model_Mantissa
+ Yields the number of digits in the mantissa of the
+ canonical form of the model numbers of T (see *note
+ A.5.3::). The value of this attribute shall be greater
+ than or equal to
+
+3.1/2
+ 'ceiling(d · log(10) / log(T'Machine_Radix))' + g
+
+3.2/2
+ where d is the requested decimal precision of T, and g is
+ 0 if T'Machine_Radix is a positive power of 10 and 1
+ otherwise. In addition, T'Model_Mantissa shall be less
+ than or equal to the value of T'Machine_Mantissa. This
+ attribute yields a value of the type universal_integer.
+
+3.a
+ Ramification: S'Model_Epsilon, which is defined in terms of
+ S'Model_Mantissa (see *note A.5.3::), yields the absolute
+ value of the difference between one and the next model number
+ of the type T above one. It is equal to or larger than the
+ absolute value of the difference between one and the next
+ machine number of the type T above one.
+
+4
+S'Model_Emin
+ Yields the minimum exponent of the canonical form of the
+ model numbers of T (see *note A.5.3::). The value of
+ this attribute shall be greater than or equal to the
+ value of T'Machine_Emin. This attribute yields a value
+ of the type universal_integer.
+
+4.a
+ Ramification: S'Model_Small, which is defined in terms of
+ S'Model_Emin (see *note A.5.3::), yields the smallest positive
+ (nonzero) model number of the type T.
+
+5
+S'Safe_First
+ Yields the lower bound of the safe range of T. The value
+ of this attribute shall be a model number of T and
+ greater than or equal to the lower bound of the base
+ range of T. In addition, if T is declared by a
+ floating_point_definition or is derived from such a type,
+ and the floating_point_definition includes a
+ real_range_specification specifying a lower bound of lb,
+ then the value of this attribute shall be less than or
+ equal to lb; otherwise, it shall be less than or equal to
+ -10.0 4 · d, where d is the requested decimal precision
+ of T. This attribute yields a value of the type
+ universal_real.
+
+6
+S'Safe_Last
+ Yields the upper bound of the safe range of T. The value
+ of this attribute shall be a model number of T and less
+ than or equal to the upper bound of the base range of T.
+ In addition, if T is declared by a
+ floating_point_definition or is derived from such a type,
+ and the floating_point_definition includes a
+ real_range_specification specifying an upper bound of ub,
+ then the value of this attribute shall be greater than or
+ equal to ub; otherwise, it shall be greater than or equal
+ to 10.0 4 · d, where d is the requested decimal precision
+ of T. This attribute yields a value of the type
+ universal_real.
+
+7
+S'Model
+ Denotes a function (of a parameter X) whose specification
+ is given in *note A.5.3::. If X is a model number of T,
+ the function yields X; otherwise, it yields the value
+ obtained by rounding or truncating X to either one of the
+ adjacent model numbers of T. Constraint_Error is raised
+ if the resulting model number is outside the safe range
+ of S. A zero result has the sign of X when S'Signed_Zeros
+ is True.
+
+8
+Subject to the constraints given above, the values of S'Model_Mantissa
+and S'Safe_Last are to be maximized, and the values of S'Model_Emin and
+S'Safe_First minimized, by the implementation as follows:
+
+9
+ * First, S'Model_Mantissa is set to the largest value for which
+ values of S'Model_Emin, S'Safe_First, and S'Safe_Last can be chosen
+ so that the implementation satisfies the strict-mode requirements
+ of *note G.2.1:: in terms of the model numbers and safe range
+ induced by these attributes.
+
+10
+ * Next, S'Model_Emin is set to the smallest value for which values of
+ S'Safe_First and S'Safe_Last can be chosen so that the
+ implementation satisfies the strict-mode requirements of *note
+ G.2.1:: in terms of the model numbers and safe range induced by
+ these attributes and the previously determined value of
+ S'Model_Mantissa.
+
+11/3
+ * {AI05-0092-1AI05-0092-1} Finally, S'Safe_First and S'Safe_Last are
+ set (in either order) to the smallest and largest values,
+ respectively, for which the implementation satisfies the
+ strict-mode requirements of *note G.2.1:: in terms of the model
+ numbers and safe range induced by these attributes and the
+ previously determined values of S'Model_Mantissa and S'Model_Emin.
+
+11.a
+ Ramification: The following table shows appropriate attribute
+ values for IEEE basic single and double precision types
+ (ANSI/IEEE Std 754-1985, IEC 559:1989). Here, we use the
+ names IEEE_Float_32 and IEEE_Float_64, the names that would
+ typically be declared in package Interfaces, in an
+ implementation that supports IEEE arithmetic. In such an
+ implementation, the attributes would typically be the same for
+ Standard.Float and Long_Float, respectively.
+
+11.b
+ Attribute IEEE_Float_32 IEEE_Float_64
+
+11.c
+ 'Machine_Radix 2 2
+ 'Machine_Mantissa 24 53
+ 'Machine_Emin -125 -1021
+ 'Machine_Emax 128 1024
+ 'Denorm True True
+ 'Machine_Rounds True True
+ 'Machine_Overflows True/False True/False
+ 'Signed_Zeros should be True should be True
+
+11.d
+ 'Model_Mantissa (same as 'Machine_Mantissa) (same as 'Machine_Mantissa)
+ 'Model_Emin (same as 'Machine_Emin) (same as 'Machine_Emin)
+ 'Model_Epsilon 2.0**(-23) 2.0**(-52)
+ 'Model_Small 2.0**(-126) 2.0**(-1022)
+ 'Safe_First -2.0**128*(1.0-2.0**(-24)) -2.0**1024*(1.0-2.0**(-53))
+ 'Safe_Last 2.0**128*(1.0-2.0**(-24)) 2.0**1024*(1.0-2.0**(-53))
+
+11.e
+ 'Digits 6 15
+ 'Base'Digits (same as 'Digits) (same as 'Digits)
+
+11.f
+ 'First (same as 'Safe_First) (same as 'Safe_First)
+ 'Last (same as 'Safe_Last) (same as 'Safe_Last)
+ 'Size 32 64
+
+11.g
+ Note: 'Machine_Overflows can be True or False, depending on
+ whether the Ada implementation raises Constraint_Error or
+ delivers a signed infinity in overflow and zerodivide
+ situations (and at poles of the elementary functions).
+
+ _Wording Changes from Ada 95_
+
+11.h/2
+ {AI95-00256-01AI95-00256-01} Corrected the definition of
+ Model_Mantissa to match that given in *note 3.5.8::.
+
+\1f
+File: aarm2012.info, Node: G.2.3, Next: G.2.4, Prev: G.2.2, Up: G.2
+
+G.2.3 Model of Fixed Point Arithmetic
+-------------------------------------
+
+1
+In the strict mode, the predefined arithmetic operations of a fixed
+point type shall satisfy the accuracy requirements specified here and
+shall avoid or signal overflow in the situations described.
+
+ _Implementation Requirements_
+
+2
+The accuracy requirements for the predefined fixed point arithmetic
+operations and conversions, and the results of relations on fixed point
+operands, are given below.
+
+2.a
+ Discussion: This subclause does not cover the accuracy of an
+ operation of a static expression; such operations have to be
+ evaluated exactly (see *note 4.9::).
+
+3
+The operands of the fixed point adding operators, absolute value, and
+comparisons have the same type. These operations are required to yield
+exact results, unless they overflow.
+
+4
+Multiplications and divisions are allowed between operands of any two
+fixed point types; the result has to be (implicitly or explicitly)
+converted to some other numeric type. For purposes of defining the
+accuracy rules, the multiplication or division and the conversion are
+treated as a single operation whose accuracy depends on three types
+(those of the operands and the result). For decimal fixed point types,
+the attribute T'Round may be used to imply explicit conversion with
+rounding (see *note 3.5.10::).
+
+5
+When the result type is a floating point type, the accuracy is as given
+in *note G.2.1::. For some combinations of the operand and result types
+in the remaining cases, the result is required to belong to a small set
+of values called the perfect result set; for other combinations, it is
+required merely to belong to a generally larger and
+implementation-defined set of values called the close result set. When
+the result type is a decimal fixed point type, the perfect result set
+contains a single value; thus, operations on decimal types are always
+fully specified.
+
+5.a
+ Implementation defined: The definition of close result set,
+ which determines the accuracy of certain fixed point
+ multiplications and divisions.
+
+6
+When one operand of a fixed-fixed multiplication or division is of type
+universal_real, that operand is not implicitly converted in the usual
+sense, since the context does not determine a unique target type, but
+the accuracy of the result of the multiplication or division (i.e.,
+whether the result has to belong to the perfect result set or merely the
+close result set) depends on the value of the operand of type
+universal_real and on the types of the other operand and of the result.
+
+6.a
+ Discussion: We need not consider here the multiplication or
+ division of two such operands, since in that case either the
+ operation is evaluated exactly (i.e., it is an operation of a
+ static expression all of whose operators are of a root numeric
+ type) or it is considered to be an operation of a floating
+ point type.
+
+7
+For a fixed point multiplication or division whose (exact) mathematical
+result is v, and for the conversion of a value v to a fixed point type,
+the perfect result set and close result set are defined as follows:
+
+8
+ * If the result type is an ordinary fixed point type with a small of
+ s,
+
+9
+ * if v is an integer multiple of s, then the perfect result
+ set contains only the value v;
+
+10
+ * otherwise, it contains the integer multiple of s just
+ below v and the integer multiple of s just above v.
+
+11
+ The close result set is an implementation-defined set of
+ consecutive integer multiples of s containing the perfect result
+ set as a subset.
+
+12
+ * If the result type is a decimal type with a small of s,
+
+13
+ * if v is an integer multiple of s, then the perfect result
+ set contains only the value v;
+
+14/3
+ * {AI05-0264-1AI05-0264-1} otherwise, if truncation
+ applies, then it contains only the integer multiple of s
+ in the direction toward zero, whereas if rounding
+ applies, then it contains only the nearest integer
+ multiple of s (with ties broken by rounding away from
+ zero).
+
+15
+ The close result set is an implementation-defined set of
+ consecutive integer multiples of s containing the perfect result
+ set as a subset.
+
+15.a
+ Ramification: As a consequence of subsequent rules, this case
+ does not arise when the operand types are also decimal types.
+
+16
+ * If the result type is an integer type,
+
+17
+ * if v is an integer, then the perfect result set contains
+ only the value v;
+
+18
+ * otherwise, it contains the integer nearest to the value v
+ (if v lies equally distant from two consecutive integers,
+ the perfect result set contains the one that is further
+ from zero).
+
+19
+ The close result set is an implementation-defined set of
+ consecutive integers containing the perfect result set as a subset.
+
+20
+The result of a fixed point multiplication or division shall belong
+either to the perfect result set or to the close result set, as
+described below, if overflow does not occur. In the following cases, if
+the result type is a fixed point type, let s be its small; otherwise,
+i.e. when the result type is an integer type, let s be 1.0.
+
+21
+ * For a multiplication or division neither of whose operands is of
+ type universal_real, let l and r be the smalls of the left and
+ right operands. For a multiplication, if (l · r) / s is an integer
+ or the reciprocal of an integer (the smalls are said to be
+ "compatible" in this case), the result shall belong to the perfect
+ result set; otherwise, it belongs to the close result set. For a
+ division, if l / (r · s) is an integer or the reciprocal of an
+ integer (i.e., the smalls are compatible), the result shall belong
+ to the perfect result set; otherwise, it belongs to the close
+ result set.
+
+21.a
+ Ramification: When the operand and result types are all
+ decimal types, their smalls are necessarily compatible; the
+ same is true when they are all ordinary fixed point types with
+ binary smalls.
+
+22
+ * For a multiplication or division having one universal_real operand
+ with a value of v, note that it is always possible to factor v as
+ an integer multiple of a "compatible" small, but the integer
+ multiple may be "too big." If there exists a factorization in
+ which that multiple is less than some implementation-defined limit,
+ the result shall belong to the perfect result set; otherwise, it
+ belongs to the close result set.
+
+22.a
+ Implementation defined: Conditions on a universal_real operand
+ of a fixed point multiplication or division for which the
+ result shall be in the perfect result set.
+
+23
+A multiplication P * Q of an operand of a fixed point type F by an
+operand of an integer type I, or vice-versa, and a division P / Q of an
+operand of a fixed point type F by an operand of an integer type I, are
+also allowed. In these cases, the result has a type of F; explicit
+conversion of the result is never required. The accuracy required in
+these cases is the same as that required for a multiplication F(P * Q)
+or a division F(P / Q) obtained by interpreting the operand of the
+integer type to have a fixed point type with a small of 1.0.
+
+24
+The accuracy of the result of a conversion from an integer or fixed
+point type to a fixed point type, or from a fixed point type to an
+integer type, is the same as that of a fixed point multiplication of the
+source value by a fixed point operand having a small of 1.0 and a value
+of 1.0, as given by the foregoing rules. The result of a conversion
+from a floating point type to a fixed point type shall belong to the
+close result set. The result of a conversion of a universal_real
+operand to a fixed point type shall belong to the perfect result set.
+
+25
+The possibility of overflow in the result of a predefined arithmetic
+operation or conversion yielding a result of a fixed point type T is
+analogous to that for floating point types, except for being related to
+the base range instead of the safe range. If all of the permitted
+results belong to the base range of T, then the implementation shall
+deliver one of the permitted results; otherwise,
+
+26
+ * if T'Machine_Overflows is True, the implementation shall either
+ deliver one of the permitted results or raise Constraint_Error;
+
+27
+ * if T'Machine_Overflows is False, the result is implementation
+ defined.
+
+27.a
+ Implementation defined: The result of a fixed point arithmetic
+ operation in overflow situations, when the Machine_Overflows
+ attribute of the result type is False.
+
+ _Inconsistencies With Ada 83_
+
+27.b
+ Since the values of a fixed point type are now just the
+ integer multiples of its small, the possibility of using extra
+ bits available in the chosen representation for extra accuracy
+ rather than for increasing the base range would appear to be
+ removed, raising the possibility that some fixed point
+ expressions will yield less accurate results than in Ada 83.
+ However, this is partially offset by the ability of an
+ implementation to choose a smaller default small than before.
+ Of course, if it does so for a type T then T'Small will have a
+ different value than it previously had.
+
+27.c
+ The accuracy requirements in the case of incompatible smalls
+ are relaxed to foster wider support for nonbinary smalls. If
+ this relaxation is exploited for a type that was previously
+ supported, lower accuracy could result; however, there is no
+ particular incentive to exploit the relaxation in such a case.
+
+ _Wording Changes from Ada 83_
+
+27.d
+ The fixed point accuracy requirements are now expressed
+ without reference to model or safe numbers, largely because
+ the full generality of the former model was never exploited in
+ the case of fixed point types (particularly in regard to
+ operand perturbation). Although the new formulation in terms
+ of perfect result sets and close result sets is still verbose,
+ it can be seen to distill down to two cases:
+
+27.e
+ * a case where the result must be the exact result, if the
+ exact result is representable, or, if not, then either
+ one of the adjacent values of the type (in some subcases
+ only one of those adjacent values is allowed);
+
+27.f
+ * a case where the accuracy is not specified by the
+ language.
+
+\1f
+File: aarm2012.info, Node: G.2.4, Next: G.2.5, Prev: G.2.3, Up: G.2
+
+G.2.4 Accuracy Requirements for the Elementary Functions
+--------------------------------------------------------
+
+1
+In the strict mode, the performance of
+Numerics.Generic_Elementary_Functions shall be as specified here.
+
+ _Implementation Requirements_
+
+2
+When an exception is not raised, the result of evaluating a function in
+an instance EF of Numerics.Generic_Elementary_Functions belongs to a
+result interval, defined as the smallest model interval of EF.Float_Type
+that contains all the values of the form f · (1.0 + d), where f is the
+exact value of the corresponding mathematical function at the given
+parameter values, d is a real number, and |d| is less than or equal to
+the function's maximum relative error. The function delivers a value
+that belongs to the result interval when both of its bounds belong to
+the safe range of EF.Float_Type; otherwise,
+
+3
+ * if EF.Float_Type'Machine_Overflows is True, the function either
+ delivers a value that belongs to the result interval or raises
+ Constraint_Error, signaling overflow;
+
+4
+ * if EF.Float_Type'Machine_Overflows is False, the result is
+ implementation defined.
+
+4.a
+ Implementation defined: The result of an elementary function
+ reference in overflow situations, when the Machine_Overflows
+ attribute of the result type is False.
+
+5
+The maximum relative error exhibited by each function is as follows:
+
+6
+ * 2.0 · EF.Float_Type'Model_Epsilon, in the case of the Sqrt, Sin,
+ and Cos functions;
+
+7
+ * 4.0 · EF.Float_Type'Model_Epsilon, in the case of the Log, Exp,
+ Tan, Cot, and inverse trigonometric functions; and
+
+8
+ * 8.0 · EF.Float_Type'Model_Epsilon, in the case of the forward and
+ inverse hyperbolic functions.
+
+9
+The maximum relative error exhibited by the exponentiation operator,
+which depends on the values of the operands, is (4.0 + |Right ·
+log(Left)| / 32.0) · EF.Float_Type'Model_Epsilon.
+
+10
+The maximum relative error given above applies throughout the domain of
+the forward trigonometric functions when the Cycle parameter is
+specified. When the Cycle parameter is omitted, the maximum relative
+error given above applies only when the absolute value of the angle
+parameter X is less than or equal to some implementation-defined angle
+threshold, which shall be at least EF.Float_Type'Machine_Radix
+'floor(EF.Float_Type'Machine_Mantissa/2)'. Beyond the angle threshold,
+the accuracy of the forward trigonometric functions is implementation
+defined.
+
+10.a
+ Implementation defined: The value of the angle threshold,
+ within which certain elementary functions, complex arithmetic
+ operations, and complex elementary functions yield results
+ conforming to a maximum relative error bound.
+
+10.b
+ Implementation defined: The accuracy of certain elementary
+ functions for parameters beyond the angle threshold.
+
+10.c
+ Implementation Note: The angle threshold indirectly determines
+ the amount of precision that the implementation has to
+ maintain during argument reduction.
+
+11/2
+{AI95-00434-01AI95-00434-01} The prescribed results specified in *note
+A.5.1:: for certain functions at particular parameter values take
+precedence over the maximum relative error bounds; effectively, they
+narrow to a single value the result interval allowed by the maximum
+relative error bounds. Additional rules with a similar effect are given
+by table G-1 for the inverse trigonometric functions, at particular
+parameter values for which the mathematical result is possibly not a
+model number of EF.Float_Type (or is, indeed, even transcendental). In
+each table entry, the values of the parameters are such that the result
+lies on the axis between two quadrants; the corresponding accuracy rule,
+which takes precedence over the maximum relative error bounds, is that
+the result interval is the model interval of EF.Float_Type associated
+with the exact mathematical result given in the table.
+
+12/1
+This paragraph was deleted.
+
+13
+The last line of the table is meant to apply when
+EF.Float_Type'Signed_Zeros is False; the two lines just above it, when
+EF.Float_Type'Signed_Zeros is True and the parameter Y has a zero value
+with the indicated sign.
+
+Table G-1: Tightly Approximated Elementary Function Results
+Function Value of X Value of Y Exact Result Exact Result
+ when Cycle when Cycle
+ Specified Omitted
+Arcsin 1.0 n.a. Cycle/4.0 PI/2.0
+Arcsin -1.0 n.a. -Cycle/4.0 -PI/2.0
+Arccos 0.0 n.a. Cycle/4.0 PI/2.0
+Arccos -1.0 n.a. Cycle/2.0 PI
+Arctan 0.0 positive Cycle/4.0 PI/2.0
+and
+Arccot
+Arctan 0.0 negative -Cycle/4.0 -PI/2.0
+and
+Arccot
+Arctan negative +0.0 Cycle/2.0 PI
+and
+Arccot
+Arctan negative -0.0 -Cycle/2.0 -PI
+and
+Arccot
+Arctan negative 0.0 Cycle/2.0 PI
+and
+Arccot
+14
+The amount by which the result of an inverse trigonometric function is
+allowed to spill over into a quadrant adjacent to the one corresponding
+to the principal branch, as given in *note A.5.1::, is limited. The
+rule is that the result belongs to the smallest model interval of
+EF.Float_Type that contains both boundaries of the quadrant
+corresponding to the principal branch. This rule also takes precedence
+over the maximum relative error bounds, effectively narrowing the result
+interval allowed by them.
+
+15
+Finally, the following specifications also take precedence over the
+maximum relative error bounds:
+
+16
+ * The absolute value of the result of the Sin, Cos, and Tanh
+ functions never exceeds one.
+
+17
+ * The absolute value of the result of the Coth function is never less
+ than one.
+
+18
+ * The result of the Cosh function is never less than one.
+
+ _Implementation Advice_
+
+19
+The versions of the forward trigonometric functions without a Cycle
+parameter should not be implemented by calling the corresponding version
+with a Cycle parameter of 2.0*Numerics.Pi, since this will not provide
+the required accuracy in some portions of the domain. For the same
+reason, the version of Log without a Base parameter should not be
+implemented by calling the corresponding version with a Base parameter
+of Numerics.e.
+
+19.a.1/2
+ Implementation Advice: For elementary functions, the forward
+ trigonometric functions without a Cycle parameter should not
+ be implemented by calling the corresponding version with a
+ Cycle parameter. Log without a Base parameter should not be
+ implemented by calling Log with a Base parameter.
+
+ _Wording Changes from Ada 83_
+
+19.a
+ The semantics of Numerics.Generic_Elementary_Functions differs
+ from Generic_Elementary_Functions as defined in ISO/IEC DIS
+ 11430 (for Ada 83) in the following ways related to the
+ accuracy specified for strict mode:
+
+19.b
+ * The maximum relative error bounds use the Model_Epsilon
+ attribute instead of the Base'Epsilon attribute.
+
+19.c
+ * The accuracy requirements are expressed in terms of
+ result intervals that are model intervals. On the one
+ hand, this facilitates the description of the required
+ results in the presence of underflow; on the other hand,
+ it slightly relaxes the requirements expressed in ISO/IEC
+ DIS 11430.
+
+\1f
+File: aarm2012.info, Node: G.2.5, Next: G.2.6, Prev: G.2.4, Up: G.2
+
+G.2.5 Performance Requirements for Random Number Generation
+-----------------------------------------------------------
+
+1
+In the strict mode, the performance of Numerics.Float_Random and
+Numerics.Discrete_Random shall be as specified here.
+
+ _Implementation Requirements_
+
+2
+Two different calls to the time-dependent Reset procedure shall reset
+the generator to different states, provided that the calls are separated
+in time by at least one second and not more than fifty years.
+
+3
+The implementation's representations of generator states and its
+algorithms for generating random numbers shall yield a period of at
+least 231-2; much longer periods are desirable but not required.
+
+4
+The implementations of Numerics.Float_Random.Random and
+Numerics.Discrete_Random.Random shall pass at least 85% of the
+individual trials in a suite of statistical tests. For
+Numerics.Float_Random, the tests are applied directly to the floating
+point values generated (i.e., they are not converted to integers first),
+while for Numerics.Discrete_Random they are applied to the generated
+values of various discrete types. Each test suite performs 6 different
+tests, with each test repeated 10 times, yielding a total of 60
+individual trials. An individual trial is deemed to pass if the
+chi-square value (or other statistic) calculated for the observed counts
+or distribution falls within the range of values corresponding to the
+2.5 and 97.5 percentage points for the relevant degrees of freedom
+(i.e., it shall be neither too high nor too low). For the purpose of
+determining the degrees of freedom, measurement categories are combined
+whenever the expected counts are fewer than 5.
+
+4.a
+ Implementation Note: In the floating point random number test
+ suite, the generator is reset to a time-dependent state at the
+ beginning of the run. The test suite incorporates the
+ following tests, adapted from D. E. Knuth, The Art of Computer
+ Programming, vol. 2: Seminumerical Algorithms. In the
+ descriptions below, the given number of degrees of freedom is
+ the number before reduction due to any necessary combination
+ of measurement categories with small expected counts; it is
+ one less than the number of measurement categories.
+
+4.b
+ * Proportional Distribution Test (a variant of the
+ Equidistribution Test). The interval 0.0 .. 1.0 is
+ partitioned into K subintervals. K is chosen randomly
+ between 4 and 25 for each repetition of the test, along
+ with the boundaries of the subintervals (subject to the
+ constraint that at least 2 of the subintervals have a
+ width of 0.001 or more). 5000 random floating point
+ numbers are generated. The counts of random numbers
+ falling into each subinterval are tallied and compared
+ with the expected counts, which are proportional to the
+ widths of the subintervals. The number of degrees of
+ freedom for the chi-square test is K-1.
+
+4.c
+ * Gap Test. The bounds of a range A .. B, with 0.0 <= A <
+ B <= 1.0, are chosen randomly for each repetition of the
+ test, subject to the constraint that 0.2 <= B-A <= 0.6.
+ Random floating point numbers are generated until 5000
+ falling into the range A .. B have been encountered.
+ Each of these 5000 is preceded by a "gap" (of length
+ greater than or equal to 0) of consecutive random numbers
+ not falling into the range A .. B. The counts of gaps of
+ each length from 0 to 15, and of all lengths greater than
+ 15 lumped together, are tallied and compared with the
+ expected counts. Let P = B-A. The probability that a gap
+ has a length of L is (1-P) L · P for L <= 15, while the
+ probability that a gap has a length of 16 or more is
+ (1-P) 16. The number of degrees of freedom for the
+ chi-square test is 16.
+
+4.d
+ * Permutation Test. 5000 tuples of 4 different random
+ floating point numbers are generated. (An entire 4-tuple
+ is discarded in the unlikely event that it contains any
+ two exactly equal components.) The counts of each of the
+ 4! = 24 possible relative orderings of the components of
+ the 4-tuples are tallied and compared with the expected
+ counts. Each of the possible relative orderings has an
+ equal probability. The number of degrees of freedom for
+ the chi-square test is 23.
+
+4.e
+ * Increasing-Runs Test. Random floating point numbers are
+ generated until 5000 increasing runs have been observed.
+ An "increasing run" is a sequence of random numbers in
+ strictly increasing order; it is followed by a random
+ number that is strictly smaller than the preceding random
+ number. (A run under construction is entirely discarded
+ in the unlikely event that one random number is followed
+ immediately by an exactly equal random number.) The
+ decreasing random number that follows an increasing run
+ is discarded and not included with the next increasing
+ run. The counts of increasing runs of each length from 1
+ to 4, and of all lengths greater than 4 lumped together,
+ are tallied and compared with the expected counts. The
+ probability that an increasing run has a length of L is
+ 1/L! - 1/(L+1)! for L <= 4, while the probability that
+ an increasing run has a length of 5 or more is 1/5!. The
+ number of degrees of freedom for the chi-square test is
+ 4.
+
+4.f
+ * Decreasing-Runs Test. The test is similar to the
+ Increasing Runs Test, but with decreasing runs.
+
+4.g
+ * Maximum-of-t Test (with t = 5). 5000 tuples of 5 random
+ floating point numbers are generated. The maximum of the
+ components of each 5-tuple is determined and raised to
+ the 5th power. The uniformity of the resulting values
+ over the range 0.0 .. 1.0 is tested as in the
+ Proportional Distribution Test.
+
+4.h
+ Implementation Note: In the discrete random number test suite,
+ Numerics.Discrete_Random is instantiated as described below.
+ The generator is reset to a time-dependent state after each
+ instantiation. The test suite incorporates the following
+ tests, adapted from D. E. Knuth (op. cit.) and other
+ sources. The given number of degrees of freedom for the
+ chi-square test is reduced by any necessary combination of
+ measurement categories with small expected counts, as
+ described above.
+
+4.i
+ * Equidistribution Test. In each repetition of the test, a
+ number R between 2 and 30 is chosen randomly, and
+ Numerics.Discrete_Random is instantiated with an integer
+ subtype whose range is 1 .. R. 5000 integers are
+ generated randomly from this range. The counts of
+ occurrences of each integer in the range are tallied and
+ compared with the expected counts, which have equal
+ probabilities. The number of degrees of freedom for the
+ chi-square test is R-1.
+
+4.j
+ * Simplified Poker Test. Numerics.Discrete_Random is
+ instantiated once with an enumeration subtype
+ representing the 13 denominations (Two through Ten, Jack,
+ Queen, King, and Ace) of an infinite deck of playing
+ cards. 2000 "poker" hands (5-tuples of values of this
+ subtype) are generated randomly. The counts of hands
+ containing exactly K different denominations (1 <= K <=
+ 5) are tallied and compared with the expected counts.
+ The probability that a hand contains exactly K different
+ denominations is given by a formula in Knuth. The number
+ of degrees of freedom for the chi-square test is 4.
+
+4.k
+ * Coupon Collector's Test. Numerics.Discrete_Random is
+ instantiated in each repetition of the test with an
+ integer subtype whose range is 1 .. R, where R varies
+ systematically from 2 to 11. Integers are generated
+ randomly from this range until each value in the range
+ has occurred, and the number K of integers generated is
+ recorded. This constitutes a "coupon collector's
+ segment" of length K. 2000 such segments are generated.
+ The counts of segments of each length from R to R+29, and
+ of all lengths greater than R+29 lumped together, are
+ tallied and compared with the expected counts. The
+ probability that a segment has any given length is given
+ by formulas in Knuth. The number of degrees of freedom
+ for the chi-square test is 30.
+
+4.l
+ * Craps Test (Lengths of Games). Numerics.Discrete_Random
+ is instantiated once with an integer subtype whose range
+ is 1 .. 6 (representing the six numbers on a die). 5000
+ craps games are played, and their lengths are recorded.
+ (The length of a craps game is the number of rolls of the
+ pair of dice required to produce a win or a loss. A game
+ is won on the first roll if the dice show 7 or 11; it is
+ lost if they show 2, 3, or 12. If the dice show some
+ other sum on the first roll, it is called the point, and
+ the game is won if and only if the point is rolled again
+ before a 7 is rolled.) The counts of games of each
+ length from 1 to 18, and of all lengths greater than 18
+ lumped together, are tallied and compared with the
+ expected counts. For 2 <= S <= 12, let D S be the
+ probability that a roll of a pair of dice shows the sum
+ S, and let Q S(L) = D S · (1 - (D S + D 7)) L-2 · (D S +
+ D 7). Then, the probability that a game has a length of
+ 1 is D 7 + D 11 + D 2 + D 3 + D 12 and, for L > 1, the
+ probability that a game has a length of L is Q 4(L) + Q
+ 5(L) + Q 6(L) + Q 8(L) + Q 9(L) + Q 10(L). The number of
+ degrees of freedom for the chi-square test is 18.
+
+4.m
+ * Craps Test (Lengths of Passes). This test is similar to
+ the last, but enough craps games are played for 3000
+ losses to occur. A string of wins followed by a loss is
+ called a pass, and its length is the number of wins
+ preceding the loss. The counts of passes of each length
+ from 0 to 7, and of all lengths greater than 7 lumped
+ together, are tallied and compared with the expected
+ counts. For L >= 0, the probability that a pass has a
+ length of L is W L · (1-W), where W, the probability that
+ a game ends in a win, is 244.0/495.0. The number of
+ degrees of freedom for the chi-square test is 8.
+
+4.n
+ * Collision Test. Numerics.Discrete_Random is instantiated
+ once with an integer or enumeration type representing
+ binary bits. 15 successive calls on the Random function
+ are used to obtain the bits of a 15-bit binary integer
+ between 0 and 32767. 3000 such integers are generated,
+ and the number of collisions (integers previously
+ generated) is counted and compared with the expected
+ count. A chi-square test is not used to assess the
+ number of collisions; rather, the limits on the number of
+ collisions, corresponding to the 2.5 and 97.5 percentage
+ points, are (from formulas in Knuth) 112 and 154. The
+ test passes if and only if the number of collisions is in
+ this range.
+
+\1f
+File: aarm2012.info, Node: G.2.6, Prev: G.2.5, Up: G.2
+
+G.2.6 Accuracy Requirements for Complex Arithmetic
+--------------------------------------------------
+
+1
+In the strict mode, the performance of Numerics.Generic_Complex_Types
+and Numerics.Generic_Complex_Elementary_Functions shall be as specified
+here.
+
+ _Implementation Requirements_
+
+2
+When an exception is not raised, the result of evaluating a real
+function of an instance CT of Numerics.Generic_Complex_Types (i.e., a
+function that yields a value of subtype CT.Real'Base or CT.Imaginary)
+belongs to a result interval defined as for a real elementary function
+(see *note G.2.4::).
+
+3
+When an exception is not raised, each component of the result of
+evaluating a complex function of such an instance, or of an instance of
+Numerics.Generic_Complex_Elementary_Functions obtained by instantiating
+the latter with CT (i.e., a function that yields a value of subtype
+CT.Complex), also belongs to a result interval. The result intervals
+for the components of the result are either defined by a maximum
+relative error bound or by a maximum box error bound. When the result
+interval for the real (resp., imaginary) component is defined by maximum
+relative error, it is defined as for that of a real function, relative
+to the exact value of the real (resp., imaginary) part of the result of
+the corresponding mathematical function. When defined by maximum box
+error, the result interval for a component of the result is the smallest
+model interval of CT.Real that contains all the values of the
+corresponding part of f · (1.0 + d), where f is the exact complex value
+of the corresponding mathematical function at the given parameter
+values, d is complex, and |d| is less than or equal to the given maximum
+box error. The function delivers a value that belongs to the result
+interval (or a value both of whose components belong to their respective
+result intervals) when both bounds of the result interval(s) belong to
+the safe range of CT.Real; otherwise,
+
+3.a
+ Discussion: The maximum relative error could be specified
+ separately for each component, but we do not take advantage of
+ that freedom here.
+
+3.b
+ Discussion: Note that f · (1.0 + d) defines a small circular
+ region of the complex plane centered at f, and the result
+ intervals for the real and imaginary components of the result
+ define a small rectangular box containing that circle.
+
+3.c
+ Reason: Box error is used when the computation of the result
+ risks loss of significance in a component due to cancellation.
+
+3.d
+ Ramification: The components of a complex function that
+ exhibits bounded relative error in each component have to have
+ the correct sign. In contrast, one of the components of a
+ complex function that exhibits bounded box error may have the
+ wrong sign, since the dimensions of the box containing the
+ result are proportional to the modulus of the mathematical
+ result and not to either component of the mathematical result
+ individually. Thus, for example, the box containing the
+ computed result of a complex function whose mathematical
+ result has a large modulus but lies very close to the
+ imaginary axis might well straddle that axis, allowing the
+ real component of the computed result to have the wrong sign.
+ In this case, the distance between the computed result and the
+ mathematical result is, nevertheless, a small fraction of the
+ modulus of the mathematical result.
+
+4
+ * if CT.Real'Machine_Overflows is True, the function either delivers
+ a value that belongs to the result interval (or a value both of
+ whose components belong to their respective result intervals) or
+ raises Constraint_Error, signaling overflow;
+
+5
+ * if CT.Real'Machine_Overflows is False, the result is implementation
+ defined.
+
+5.a
+ Implementation defined: The result of a complex arithmetic
+ operation or complex elementary function reference in overflow
+ situations, when the Machine_Overflows attribute of the
+ corresponding real type is False.
+
+6/2
+{AI95-00434-01AI95-00434-01} The error bounds for particular complex
+functions are tabulated in table G-2. In the table, the error bound is
+given as the coefficient of CT.Real'Model_Epsilon.
+
+7/1
+This paragraph was deleted.
+
+Table G-2: Error Bounds for Particular Complex Functions
+Function or Operator Nature of Nature of Error Bound
+ Result Bound
+Modulus real max. 3.0
+ rel.
+ error
+Argument real max. 4.0
+ rel.
+ error
+Compose_From_Polar complex max. 3.0
+ rel.
+ error
+"*" (both operands complex max. 5.0
+complex) box
+ error
+"/" (right operand complex max. 13.0
+complex) box
+ error
+Sqrt complex max. 6.0
+ rel.
+ error
+Log complex max. 13.0
+ box
+ error
+Exp (complex complex max. 7.0
+parameter) rel.
+ error
+Exp (imaginary complex max. 2.0
+parameter) rel.
+ error
+Sin, Cos, Sinh, and complex max. 11.0
+Cosh rel.
+ error
+Tan, Cot, Tanh, and complex max. 35.0
+Coth rel.
+ error
+inverse complex max. 14.0
+trigonometric rel.
+ error
+inverse hyperbolic complex max. 14.0
+ rel.
+ error
+8
+The maximum relative error given above applies throughout the domain of
+the Compose_From_Polar function when the Cycle parameter is specified.
+When the Cycle parameter is omitted, the maximum relative error applies
+only when the absolute value of the parameter Argument is less than or
+equal to the angle threshold (see *note G.2.4::). For the Exp function,
+and for the forward hyperbolic (resp., trigonometric) functions, the
+maximum relative error given above likewise applies only when the
+absolute value of the imaginary (resp., real) component of the parameter
+X (or the absolute value of the parameter itself, in the case of the Exp
+function with a parameter of pure-imaginary type) is less than or equal
+to the angle threshold. For larger angles, the accuracy is
+implementation defined.
+
+8.a
+ Implementation defined: The accuracy of certain complex
+ arithmetic operations and certain complex elementary functions
+ for parameters (or components thereof) beyond the angle
+ threshold.
+
+9
+The prescribed results specified in *note G.1.2:: for certain functions
+at particular parameter values take precedence over the error bounds;
+effectively, they narrow to a single value the result interval allowed
+by the error bounds for a component of the result. Additional rules
+with a similar effect are given below for certain inverse trigonometric
+and inverse hyperbolic functions, at particular parameter values for
+which a component of the mathematical result is transcendental. In each
+case, the accuracy rule, which takes precedence over the error bounds,
+is that the result interval for the stated result component is the model
+interval of CT.Real associated with the component's exact mathematical
+value. The cases in question are as follows:
+
+10
+ * When the parameter X has the value zero, the real (resp.,
+ imaginary) component of the result of the Arccot (resp., Arccoth)
+ function is in the model interval of CT.Real associated with the
+ value PI/2.0.
+
+11
+ * When the parameter X has the value one, the real component of the
+ result of the Arcsin function is in the model interval of CT.Real
+ associated with the value PI/2.0.
+
+12
+ * When the parameter X has the value -1.0, the real component of the
+ result of the Arcsin (resp., Arccos) function is in the model
+ interval of CT.Real associated with the value -PI/2.0 (resp., PI).
+
+12.a
+ Discussion: It is possible to give many other prescribed
+ results in which a component of the parameter is restricted to
+ a similar model interval when the parameter X is appropriately
+ restricted to an easily testable portion of the domain. We
+ follow the proposed ISO/IEC standard for
+ Generic_Complex_Elementary_Functions (for Ada 83) in not doing
+ so, however.
+
+13/2
+{AI95-00434-01AI95-00434-01} The amount by which a component of the
+result of an inverse trigonometric or inverse hyperbolic function is
+allowed to spill over into a quadrant adjacent to the one corresponding
+to the principal branch, as given in *note G.1.2::, is limited. The
+rule is that the result belongs to the smallest model interval of
+CT.Real that contains both boundaries of the quadrant corresponding to
+the principal branch. This rule also takes precedence over the maximum
+error bounds, effectively narrowing the result interval allowed by them.
+
+14
+Finally, the results allowed by the error bounds are narrowed by one
+further rule: The absolute value of each component of the result of the
+Exp function, for a pure-imaginary parameter, never exceeds one.
+
+ _Implementation Advice_
+
+15
+The version of the Compose_From_Polar function without a Cycle parameter
+should not be implemented by calling the corresponding version with a
+Cycle parameter of 2.0*Numerics.Pi, since this will not provide the
+required accuracy in some portions of the domain.
+
+15.a.1/2
+ Implementation Advice: For complex arithmetic, the
+ Compose_From_Polar function without a Cycle parameter should
+ not be implemented by calling Compose_From_Polar with a Cycle
+ parameter.
+
+ _Wording Changes from Ada 83_
+
+15.a
+ The semantics of Numerics.Generic_Complex_Types and
+ Numerics.Generic_Complex_Elementary_Functions differs from
+ Generic_Complex_Types and Generic_Complex_Elementary_Functions
+ as defined in ISO/IEC CDs 13813 and 13814 (for Ada 83) in ways
+ analogous to those identified for the elementary functions in
+ *note G.2.4::. In addition, we do not generally specify the
+ signs of zero results (or result components), although those
+ proposed standards do.
+
+\1f
+File: aarm2012.info, Node: G.3, Prev: G.2, Up: Annex G
+
+G.3 Vector and Matrix Manipulation
+==================================
+
+1/2
+{AI95-00296-01AI95-00296-01} Types and operations for the manipulation
+of real vectors and matrices are provided in Generic_Real_Arrays, which
+is defined in *note G.3.1::. Types and operations for the manipulation
+of complex vectors and matrices are provided in Generic_Complex_Arrays,
+which is defined in *note G.3.2::. Both of these library units are
+generic children of the predefined package Numerics (see *note A.5::).
+Nongeneric equivalents of these packages for each of the predefined
+floating point types are also provided as children of Numerics.
+
+1.a/2
+ Discussion: Vector and matrix manipulation is defined in the
+ Numerics Annex, rather than in the core, because it is
+ considered to be a specialized need of (some) numeric
+ applications.
+
+1.b/2
+ These packages provide facilities that are similar to and
+ replace those found in ISO/IEC 13813:1998 Information
+ technology -- Programming languages -- Generic packages of
+ real and complex type declarations and basic operations for
+ Ada (including vector and matrix types). (The other
+ facilities provided by that Standard were already provided in
+ Ada 95.) In addition to the main facilities of that Standard,
+ these packages also include subprograms for the solution of
+ linear equations, matrix inversion, determinants, and the
+ determination of the eigenvalues and eigenvectors of real
+ symmetric matrices and Hermitian matrices.
+
+ _Extensions to Ada 95_
+
+1.c/3
+ {AI95-00296-01AI95-00296-01} {AI05-0299-1AI05-0299-1} This
+ subclause It just provides an introduction to the following
+ subclauses.
+
+* Menu:
+
+* G.3.1 :: Real Vectors and Matrices
+* G.3.2 :: Complex Vectors and Matrices
+
+\1f
+File: aarm2012.info, Node: G.3.1, Next: G.3.2, Up: G.3
+
+G.3.1 Real Vectors and Matrices
+-------------------------------
+
+ _Static Semantics_
+
+1/2
+{AI95-00296-01AI95-00296-01} {AI95-00418-01AI95-00418-01} The generic
+library package Numerics.Generic_Real_Arrays has the following
+declaration:
+
+2/2
+ generic
+ type Real is digits <>;
+ package Ada.Numerics.Generic_Real_Arrays is
+ pragma Pure(Generic_Real_Arrays);
+
+3/2
+ -- Types
+
+4/2
+ type Real_Vector is array (Integer range <>) of Real'Base;
+ type Real_Matrix is array (Integer range <>, Integer range <>)
+ of Real'Base;
+
+5/2
+ -- Subprograms for Real_Vector types
+
+6/2
+ -- Real_Vector arithmetic operations
+
+7/2
+ function "+" (Right : Real_Vector) return Real_Vector;
+ function "-" (Right : Real_Vector) return Real_Vector;
+ function "abs" (Right : Real_Vector) return Real_Vector;
+
+8/2
+ function "+" (Left, Right : Real_Vector) return Real_Vector;
+ function "-" (Left, Right : Real_Vector) return Real_Vector;
+
+9/2
+ function "*" (Left, Right : Real_Vector) return Real'Base;
+
+10/2
+ function "abs" (Right : Real_Vector) return Real'Base;
+
+11/2
+ -- Real_Vector scaling operations
+
+12/2
+ function "*" (Left : Real'Base; Right : Real_Vector)
+ return Real_Vector;
+ function "*" (Left : Real_Vector; Right : Real'Base)
+ return Real_Vector;
+ function "/" (Left : Real_Vector; Right : Real'Base)
+ return Real_Vector;
+
+13/2
+ -- Other Real_Vector operations
+
+14/2
+ function Unit_Vector (Index : Integer;
+ Order : Positive;
+ First : Integer := 1) return Real_Vector;
+
+15/2
+ -- Subprograms for Real_Matrix types
+
+16/2
+ -- Real_Matrix arithmetic operations
+
+17/2
+ function "+" (Right : Real_Matrix) return Real_Matrix;
+ function "-" (Right : Real_Matrix) return Real_Matrix;
+ function "abs" (Right : Real_Matrix) return Real_Matrix;
+ function Transpose (X : Real_Matrix) return Real_Matrix;
+
+18/2
+ function "+" (Left, Right : Real_Matrix) return Real_Matrix;
+ function "-" (Left, Right : Real_Matrix) return Real_Matrix;
+ function "*" (Left, Right : Real_Matrix) return Real_Matrix;
+
+19/2
+ function "*" (Left, Right : Real_Vector) return Real_Matrix;
+
+20/2
+ function "*" (Left : Real_Vector; Right : Real_Matrix)
+ return Real_Vector;
+ function "*" (Left : Real_Matrix; Right : Real_Vector)
+ return Real_Vector;
+
+21/2
+ -- Real_Matrix scaling operations
+
+22/2
+ function "*" (Left : Real'Base; Right : Real_Matrix)
+ return Real_Matrix;
+ function "*" (Left : Real_Matrix; Right : Real'Base)
+ return Real_Matrix;
+ function "/" (Left : Real_Matrix; Right : Real'Base)
+ return Real_Matrix;
+
+23/2
+ -- Real_Matrix inversion and related operations
+
+24/2
+ function Solve (A : Real_Matrix; X : Real_Vector) return Real_Vector;
+ function Solve (A, X : Real_Matrix) return Real_Matrix;
+ function Inverse (A : Real_Matrix) return Real_Matrix;
+ function Determinant (A : Real_Matrix) return Real'Base;
+
+25/2
+ -- Eigenvalues and vectors of a real symmetric matrix
+
+26/2
+ function Eigenvalues (A : Real_Matrix) return Real_Vector;
+
+27/2
+ procedure Eigensystem (A : in Real_Matrix;
+ Values : out Real_Vector;
+ Vectors : out Real_Matrix);
+
+28/2
+ -- Other Real_Matrix operations
+
+29/2
+ function Unit_Matrix (Order : Positive;
+ First_1, First_2 : Integer := 1)
+ return Real_Matrix;
+
+30/2
+ end Ada.Numerics.Generic_Real_Arrays;
+
+31/2
+{AI95-00296-01AI95-00296-01} The library package Numerics.Real_Arrays is
+declared pure and defines the same types and subprograms as
+Numerics.Generic_Real_Arrays, except that the predefined type Float is
+systematically substituted for Real'Base throughout. Nongeneric
+equivalents for each of the other predefined floating point types are
+defined similarly, with the names Numerics.Short_Real_Arrays,
+Numerics.Long_Real_Arrays, etc.
+
+31.a/2
+ Reason: The nongeneric equivalents are provided to allow the
+ programmer to construct simple mathematical applications
+ without being required to understand and use generics, and to
+ be consistent with other Numerics packages.
+
+32/2
+{AI95-00296-01AI95-00296-01} Two types are defined and exported by
+Numerics.Generic_Real_Arrays. The composite type Real_Vector is
+provided to represent a vector with components of type Real; it is
+defined as an unconstrained, one-dimensional array with an index of type
+Integer. The composite type Real_Matrix is provided to represent a
+matrix with components of type Real; it is defined as an unconstrained,
+two-dimensional array with indices of type Integer.
+
+33/2
+{AI95-00296-01AI95-00296-01} The effect of the various subprograms is as
+described below. In most cases the subprograms are described in terms
+of corresponding scalar operations of the type Real; any exception
+raised by those operations is propagated by the array operation.
+Moreover, the accuracy of the result for each individual component is as
+defined for the scalar operation unless stated otherwise.
+
+34/2
+{AI95-00296-01AI95-00296-01} In the case of those operations which are
+defined to involve an inner product, Constraint_Error may be raised if
+an intermediate result is outside the range of Real'Base even though the
+mathematical final result would not be.
+
+35/2
+ function "+" (Right : Real_Vector) return Real_Vector;
+ function "-" (Right : Real_Vector) return Real_Vector;
+ function "abs" (Right : Real_Vector) return Real_Vector;
+
+36/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation of the type Real to
+ each component of Right. The index range of the result is
+ Right'Range.
+
+37/2
+ function "+" (Left, Right : Real_Vector) return Real_Vector;
+ function "-" (Left, Right : Real_Vector) return Real_Vector;
+
+38/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation of the type Real to
+ each component of Left and the matching component of Right.
+ The index range of the result is Left'Range. Constraint_Error
+ is raised if Left'Length is not equal to Right'Length.
+
+39/2
+ function "*" (Left, Right : Real_Vector) return Real'Base;
+
+40/2
+ {AI95-00296-01AI95-00296-01} This operation returns the inner
+ product of Left and Right. Constraint_Error is raised if
+ Left'Length is not equal to Right'Length. This operation
+ involves an inner product.
+
+41/2
+ function "abs" (Right : Real_Vector) return Real'Base;
+
+42/2
+ {AI95-00418-01AI95-00418-01} This operation returns the
+ L2-norm of Right (the square root of the inner product of the
+ vector with itself).
+
+42.a/2
+ Discussion: Normalization of vectors is a frequent enough
+ operation that it is useful to provide the norm as a basic
+ operation. Furthermore, implementing the norm is not entirely
+ straightforward, because the inner product might overflow
+ while the final norm does not. An implementation cannot
+ merely return Sqrt (X * X), it has to cope with a possible
+ overflow of the inner product.
+
+42.b/2
+ Implementation Note: While the definition is given in terms of
+ an inner product, the norm doesn't "involve an inner product"
+ in the technical sense. The reason is that it has accuracy
+ requirements substantially different from those applicable to
+ inner products; and that cancellations cannot occur, because
+ all the terms are positive, so there is no possibility of
+ intermediate overflow.
+
+43/2
+ function "*" (Left : Real'Base; Right : Real_Vector) return Real_Vector;
+
+44/2
+ {AI95-00296-01AI95-00296-01} This operation returns the result
+ of multiplying each component of Right by the scalar Left
+ using the "*" operation of the type Real. The index range of
+ the result is Right'Range.
+
+45/2
+ function "*" (Left : Real_Vector; Right : Real'Base) return Real_Vector;
+ function "/" (Left : Real_Vector; Right : Real'Base) return Real_Vector;
+
+46/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation of the type Real to
+ each component of Left and to the scalar Right. The index
+ range of the result is Left'Range.
+
+47/2
+ function Unit_Vector (Index : Integer;
+ Order : Positive;
+ First : Integer := 1) return Real_Vector;
+
+48/2
+ {AI95-00296-01AI95-00296-01} This function returns a unit
+ vector with Order components and a lower bound of First. All
+ components are set to 0.0 except for the Index component which
+ is set to 1.0. Constraint_Error is raised if Index < First,
+ Index > First + Order - 1 or if First + Order - 1 >
+ Integer'Last.
+
+49/2
+ function "+" (Right : Real_Matrix) return Real_Matrix;
+ function "-" (Right : Real_Matrix) return Real_Matrix;
+ function "abs" (Right : Real_Matrix) return Real_Matrix;
+
+50/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation of the type Real to
+ each component of Right. The index ranges of the result are
+ those of Right.
+
+51/2
+ function Transpose (X : Real_Matrix) return Real_Matrix;
+
+52/2
+ {AI95-00296-01AI95-00296-01} This function returns the
+ transpose of a matrix X. The first and second index ranges of
+ the result are X'Range(2) and X'Range(1) respectively.
+
+53/2
+ function "+" (Left, Right : Real_Matrix) return Real_Matrix;
+ function "-" (Left, Right : Real_Matrix) return Real_Matrix;
+
+54/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation of the type Real to
+ each component of Left and the matching component of Right.
+ The index ranges of the result are those of Left.
+ Constraint_Error is raised if Left'Length(1) is not equal to
+ Right'Length(1) or Left'Length(2) is not equal to
+ Right'Length(2).
+
+55/2
+ function "*" (Left, Right : Real_Matrix) return Real_Matrix;
+
+56/2
+ {AI95-00296-01AI95-00296-01} This operation provides the
+ standard mathematical operation for matrix multiplication.
+ The first and second index ranges of the result are
+ Left'Range(1) and Right'Range(2) respectively.
+ Constraint_Error is raised if Left'Length(2) is not equal to
+ Right'Length(1). This operation involves inner products.
+
+57/2
+ function "*" (Left, Right : Real_Vector) return Real_Matrix;
+
+58/2
+ {AI95-00296-01AI95-00296-01} This operation returns the outer
+ product of a (column) vector Left by a (row) vector Right
+ using the operation "*" of the type Real for computing the
+ individual components. The first and second index ranges of
+ the result are Left'Range and Right'Range respectively.
+
+59/2
+ function "*" (Left : Real_Vector; Right : Real_Matrix) return Real_Vector;
+
+60/2
+ {AI95-00296-01AI95-00296-01} This operation provides the
+ standard mathematical operation for multiplication of a (row)
+ vector Left by a matrix Right. The index range of the (row)
+ vector result is Right'Range(2). Constraint_Error is raised
+ if Left'Length is not equal to Right'Length(1). This
+ operation involves inner products.
+
+61/2
+ function "*" (Left : Real_Matrix; Right : Real_Vector) return Real_Vector;
+
+62/2
+ {AI95-00296-01AI95-00296-01} This operation provides the
+ standard mathematical operation for multiplication of a matrix
+ Left by a (column) vector Right. The index range of the
+ (column) vector result is Left'Range(1). Constraint_Error is
+ raised if Left'Length(2) is not equal to Right'Length. This
+ operation involves inner products.
+
+63/2
+ function "*" (Left : Real'Base; Right : Real_Matrix) return Real_Matrix;
+
+64/2
+ {AI95-00296-01AI95-00296-01} This operation returns the result
+ of multiplying each component of Right by the scalar Left
+ using the "*" operation of the type Real. The index ranges of
+ the result are those of Right.
+
+65/2
+ function "*" (Left : Real_Matrix; Right : Real'Base) return Real_Matrix;
+ function "/" (Left : Real_Matrix; Right : Real'Base) return Real_Matrix;
+
+66/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation of the type Real to
+ each component of Left and to the scalar Right. The index
+ ranges of the result are those of Left.
+
+67/2
+ function Solve (A : Real_Matrix; X : Real_Vector) return Real_Vector;
+
+68/2
+ {AI95-00296-01AI95-00296-01} This function returns a vector Y
+ such that X is (nearly) equal to A * Y. This is the standard
+ mathematical operation for solving a single set of linear
+ equations. The index range of the result is A'Range(2).
+ Constraint_Error is raised if A'Length(1), A'Length(2), and
+ X'Length are not equal. Constraint_Error is raised if the
+ matrix A is ill-conditioned.
+
+68.a/2
+ Discussion: The text says that Y is such that "X is (nearly)
+ equal to A * Y" rather than "X is equal to A * Y" because
+ rounding errors may mean that there is no value of Y such that
+ X is exactly equal to A * Y. On the other hand it does not
+ mean that any old rough value will do. The algorithm given
+ under Implementation Advice should be followed.
+
+68.b/2
+ The requirement to raise Constraint_Error if the matrix is
+ ill-conditioned is really a reflection of what will happen if
+ the matrix is ill-conditioned. See Implementation Advice. We
+ do not make any attempt to define ill-conditioned formally.
+
+68.c/2
+ These remarks apply to all versions of Solve and Inverse.
+
+69/2
+ function Solve (A, X : Real_Matrix) return Real_Matrix;
+
+70/2
+ {AI95-00296-01AI95-00296-01} This function returns a matrix Y
+ such that X is (nearly) equal to A * Y. This is the standard
+ mathematical operation for solving several sets of linear
+ equations. The index ranges of the result are A'Range(2) and
+ X'Range(2). Constraint_Error is raised if A'Length(1),
+ A'Length(2), and X'Length(1) are not equal. Constraint_Error
+ is raised if the matrix A is ill-conditioned.
+
+71/2
+ function Inverse (A : Real_Matrix) return Real_Matrix;
+
+72/2
+ {AI95-00296-01AI95-00296-01} This function returns a matrix B
+ such that A * B is (nearly) equal to the unit matrix. The
+ index ranges of the result are A'Range(2) and A'Range(1).
+ Constraint_Error is raised if A'Length(1) is not equal to
+ A'Length(2). Constraint_Error is raised if the matrix A is
+ ill-conditioned.
+
+73/2
+ function Determinant (A : Real_Matrix) return Real'Base;
+
+74/2
+ {AI95-00296-01AI95-00296-01} This function returns the
+ determinant of the matrix A. Constraint_Error is raised if
+ A'Length(1) is not equal to A'Length(2).
+
+75/2
+ function Eigenvalues(A : Real_Matrix) return Real_Vector;
+
+76/2
+ {AI95-00296-01AI95-00296-01} This function returns the
+ eigenvalues of the symmetric matrix A as a vector sorted into
+ order with the largest first. Constraint_Error is raised if
+ A'Length(1) is not equal to A'Length(2). The index range of
+ the result is A'Range(1). Argument_Error is raised if the
+ matrix A is not symmetric.
+
+77/2
+ procedure Eigensystem(A : in Real_Matrix;
+ Values : out Real_Vector;
+ Vectors : out Real_Matrix);
+
+78/3
+ {AI95-00296-01AI95-00296-01} {AI05-0047-1AI05-0047-1} This
+ procedure computes both the eigenvalues and eigenvectors of
+ the symmetric matrix A. The out parameter Values is the same
+ as that obtained by calling the function Eigenvalues. The out
+ parameter Vectors is a matrix whose columns are the
+ eigenvectors of the matrix A. The order of the columns
+ corresponds to the order of the eigenvalues. The eigenvectors
+ are normalized and mutually orthogonal (they are orthonormal),
+ including when there are repeated eigenvalues.
+ Constraint_Error is raised if A'Length(1) is not equal to
+ A'Length(2), or if Values'Range is not equal to A'Range(1), or
+ if the index ranges of the parameter Vectors are not equal to
+ those of A. Argument_Error is raised if the matrix A is not
+ symmetric. Constraint_Error is also raised in
+ implementation-defined circumstances if the algorithm used
+ does not converge quickly enough.
+
+78.a/3
+ Ramification: {AI05-0047-1AI05-0047-1} There is no requirement
+ on the absolute direction of the returned eigenvectors. Thus
+ they might be multiplied by -1. It is only the ratios of the
+ components that matter. This is standard practice.
+
+79/2
+ function Unit_Matrix (Order : Positive;
+ First_1, First_2 : Integer := 1) return Real_Matrix;
+
+80/2
+ {AI95-00296-01AI95-00296-01} This function returns a square
+ unit matrix with Order**2 components and lower bounds of
+ First_1 and First_2 (for the first and second index ranges
+ respectively). All components are set to 0.0 except for the
+ main diagonal, whose components are set to 1.0.
+ Constraint_Error is raised if First_1 + Order - 1 >
+ Integer'Last or First_2 + Order - 1 > Integer'Last.
+
+ _Implementation Requirements_
+
+81/2
+{AI95-00296-01AI95-00296-01} Accuracy requirements for the subprograms
+Solve, Inverse, Determinant, Eigenvalues and Eigensystem are
+implementation defined.
+
+81.a/2
+ Implementation defined: The accuracy requirements for the
+ subprograms Solve, Inverse, Determinant, Eigenvalues and
+ Eigensystem for type Real_Matrix.
+
+82/2
+For operations not involving an inner product, the accuracy requirements
+are those of the corresponding operations of the type Real in both the
+strict mode and the relaxed mode (see *note G.2::).
+
+83/2
+For operations involving an inner product, no requirements are specified
+in the relaxed mode. In the strict mode the modulus of the absolute
+error of the inner product X*Y shall not exceed g*abs(X)*abs(Y) where g
+is defined as
+
+84/2
+ g = X'Length * Real'Machine_Radix**(1 - Real'Model_Mantissa)
+
+85/2
+{AI95-00418-01AI95-00418-01} For the L2-norm, no accuracy requirements
+are specified in the relaxed mode. In the strict mode the relative
+error on the norm shall not exceed g / 2.0 + 3.0 * Real'Model_Epsilon
+where g is defined as above.
+
+85.a/2
+ Reason: This is simply the combination of the error on the
+ inner product with the error on Sqrt. A first order
+ computation would lead to 2.0 * Real'Model_Epsilon above, but
+ we are adding an extra Real'Model_Epsilon to account for
+ higher order effects.
+
+ _Documentation Requirements_
+
+86/2
+{AI95-00296-01AI95-00296-01} Implementations shall document any
+techniques used to reduce cancellation errors such as extended precision
+arithmetic.
+
+86.a/2
+ Documentation Requirement: Any techniques used to reduce
+ cancellation errors in Numerics.Generic_Real_Arrays shall be
+ documented.
+
+86.b/2
+ Implementation Note: The above accuracy requirement is met by
+ the canonical implementation of the inner product by
+ multiplication and addition using the corresponding operations
+ of type Real'Base and performing the cumulative addition using
+ ascending indices. Note however, that some hardware provides
+ special operations for the computation of the inner product
+ and although these may be fast they may not meet the accuracy
+ requirement specified. See Accuracy and Stability of
+ Numerical Algorithms By N J Higham (ISBN 0-89871-355-2),
+ Section 3.1.
+
+86.c/3
+ {AI05-0047-1AI05-0047-1} Note moreover that the componentwise
+ accuracy requirements are not met by subcubic methods for
+ matrix multiplication such as that devised by Strassen. These
+ methods, which are typically used for the fast multiplication
+ of very large matrices (e.g. order more than a few
+ thousands), have normwise accuracy properties. If it is
+ desired to use such methods, then distinct subprograms should
+ be provided (perhaps in a child package). See Section 22.2.2
+ in the above reference.
+
+ _Implementation Permissions_
+
+87/2
+{AI95-00296-01AI95-00296-01} The nongeneric equivalent packages may, but
+need not, be actual instantiations of the generic package for the
+appropriate predefined type.
+
+ _Implementation Advice_
+
+88/3
+{AI95-00296-01AI95-00296-01} {AI05-0264-1AI05-0264-1} Implementations
+should implement the Solve and Inverse functions using established
+techniques such as LU decomposition with row interchanges followed by
+back and forward substitution. Implementations are recommended to
+refine the result by performing an iteration on the residuals; if this
+is done, then it should be documented.
+
+88.a/2
+ Implementation Advice: Solve and Inverse for
+ Numerics.Generic_Real_Arrays should be implemented using
+ established techniques such as LU decomposition and the result
+ should be refined by an iteration on the residuals.
+
+89/2
+It is not the intention that any special provision should be made to
+determine whether a matrix is ill-conditioned or not. The naturally
+occurring overflow (including division by zero) which will result from
+executing these functions with an ill-conditioned matrix and thus raise
+Constraint_Error is sufficient.
+
+89.a/2
+ Discussion: There isn't any advice for the implementation to
+ document with this paragraph.
+
+90/2
+The test that a matrix is symmetric should be performed by using the
+equality operator to compare the relevant components.
+
+90.a/2
+ Implementation Advice: The equality operator should be used to
+ test that a matrix in Numerics.Generic_Real_Arrays is
+ symmetric.
+
+91/3
+{AI05-0047-1AI05-0047-1} An implementation should minimize the
+circumstances under which the algorithm used for Eigenvalues and
+Eigensystem fails to converge.
+
+91.a.1/3
+ Implementation Advice: An implementation should minimize the
+ circumstances under which the algorithm used for
+ Numerics.Generic_Real_Arrays.Eigenvalues and
+ Numerics.Generic_Real_Arrays.Eigensystem fails to converge.
+
+91.a/3
+ Implementation Note: J. H. Wilkinson is the acknowledged
+ expert in this area. See for example Wilkinson, J. H., and
+ Reinsch, C. , Linear Algebra , vol II of Handbook for
+ Automatic Computation, Springer-Verlag, or Wilkinson, J. H.,
+ The Algebraic Eigenvalue Problem, Oxford University Press.
+
+ _Extensions to Ada 95_
+
+91.b/2
+ {AI95-00296-01AI95-00296-01} The package
+ Numerics.Generic_Real_Arrays and its nongeneric equivalents
+ are new.
+
+ _Wording Changes from Ada 2005_
+
+91.c/3
+ {AI05-0047-1AI05-0047-1} Correction: Corrected various
+ accuracy and definition issues.
+
+\1f
+File: aarm2012.info, Node: G.3.2, Prev: G.3.1, Up: G.3
+
+G.3.2 Complex Vectors and Matrices
+----------------------------------
+
+ _Static Semantics_
+
+1/2
+{AI95-00296-01AI95-00296-01} The generic library package
+Numerics.Generic_Complex_Arrays has the following declaration:
+
+2/2
+ with Ada.Numerics.Generic_Real_Arrays, Ada.Numerics.Generic_Complex_Types;
+ generic
+ with package Real_Arrays is new
+ Ada.Numerics.Generic_Real_Arrays (<>);
+ use Real_Arrays;
+ with package Complex_Types is new
+ Ada.Numerics.Generic_Complex_Types (Real);
+ use Complex_Types;
+ package Ada.Numerics.Generic_Complex_Arrays is
+ pragma Pure(Generic_Complex_Arrays);
+
+3/2
+ -- Types
+
+4/2
+ type Complex_Vector is array (Integer range <>) of Complex;
+ type Complex_Matrix is array (Integer range <>,
+ Integer range <>) of Complex;
+
+5/2
+ -- Subprograms for Complex_Vector types
+
+6/2
+ -- Complex_Vector selection, conversion and composition operations
+
+7/2
+ function Re (X : Complex_Vector) return Real_Vector;
+ function Im (X : Complex_Vector) return Real_Vector;
+
+8/2
+ procedure Set_Re (X : in out Complex_Vector;
+ Re : in Real_Vector);
+ procedure Set_Im (X : in out Complex_Vector;
+ Im : in Real_Vector);
+
+9/2
+ function Compose_From_Cartesian (Re : Real_Vector)
+ return Complex_Vector;
+ function Compose_From_Cartesian (Re, Im : Real_Vector)
+ return Complex_Vector;
+
+10/2
+ function Modulus (X : Complex_Vector) return Real_Vector;
+ function "abs" (Right : Complex_Vector) return Real_Vector
+ renames Modulus;
+ function Argument (X : Complex_Vector) return Real_Vector;
+ function Argument (X : Complex_Vector;
+ Cycle : Real'Base) return Real_Vector;
+
+11/2
+ function Compose_From_Polar (Modulus, Argument : Real_Vector)
+ return Complex_Vector;
+ function Compose_From_Polar (Modulus, Argument : Real_Vector;
+ Cycle : Real'Base)
+ return Complex_Vector;
+
+12/2
+ -- Complex_Vector arithmetic operations
+
+13/2
+ function "+" (Right : Complex_Vector) return Complex_Vector;
+ function "-" (Right : Complex_Vector) return Complex_Vector;
+ function Conjugate (X : Complex_Vector) return Complex_Vector;
+
+14/2
+ function "+" (Left, Right : Complex_Vector) return Complex_Vector;
+ function "-" (Left, Right : Complex_Vector) return Complex_Vector;
+
+15/2
+ function "*" (Left, Right : Complex_Vector) return Complex;
+
+16/3
+ {AI05-0047-1AI05-0047-1} function "abs" (Right : Complex_Vector) return Real'Base;
+
+17/2
+ -- Mixed Real_Vector and Complex_Vector arithmetic operations
+
+18/2
+ function "+" (Left : Real_Vector;
+ Right : Complex_Vector) return Complex_Vector;
+ function "+" (Left : Complex_Vector;
+ Right : Real_Vector) return Complex_Vector;
+ function "-" (Left : Real_Vector;
+ Right : Complex_Vector) return Complex_Vector;
+ function "-" (Left : Complex_Vector;
+ Right : Real_Vector) return Complex_Vector;
+
+19/2
+ function "*" (Left : Real_Vector; Right : Complex_Vector)
+ return Complex;
+ function "*" (Left : Complex_Vector; Right : Real_Vector)
+ return Complex;
+
+20/2
+ -- Complex_Vector scaling operations
+
+21/2
+ function "*" (Left : Complex;
+ Right : Complex_Vector) return Complex_Vector;
+ function "*" (Left : Complex_Vector;
+ Right : Complex) return Complex_Vector;
+ function "/" (Left : Complex_Vector;
+ Right : Complex) return Complex_Vector;
+
+22/2
+ function "*" (Left : Real'Base;
+ Right : Complex_Vector) return Complex_Vector;
+ function "*" (Left : Complex_Vector;
+ Right : Real'Base) return Complex_Vector;
+ function "/" (Left : Complex_Vector;
+ Right : Real'Base) return Complex_Vector;
+
+23/2
+ -- Other Complex_Vector operations
+
+24/2
+ function Unit_Vector (Index : Integer;
+ Order : Positive;
+ First : Integer := 1) return Complex_Vector;
+
+25/2
+ -- Subprograms for Complex_Matrix types
+
+26/2
+ -- Complex_Matrix selection, conversion and composition operations
+
+27/2
+ function Re (X : Complex_Matrix) return Real_Matrix;
+ function Im (X : Complex_Matrix) return Real_Matrix;
+
+28/2
+ procedure Set_Re (X : in out Complex_Matrix;
+ Re : in Real_Matrix);
+ procedure Set_Im (X : in out Complex_Matrix;
+ Im : in Real_Matrix);
+
+29/2
+ function Compose_From_Cartesian (Re : Real_Matrix)
+ return Complex_Matrix;
+ function Compose_From_Cartesian (Re, Im : Real_Matrix)
+ return Complex_Matrix;
+
+30/2
+ function Modulus (X : Complex_Matrix) return Real_Matrix;
+ function "abs" (Right : Complex_Matrix) return Real_Matrix
+ renames Modulus;
+
+31/2
+ function Argument (X : Complex_Matrix) return Real_Matrix;
+ function Argument (X : Complex_Matrix;
+ Cycle : Real'Base) return Real_Matrix;
+
+32/2
+ function Compose_From_Polar (Modulus, Argument : Real_Matrix)
+ return Complex_Matrix;
+ function Compose_From_Polar (Modulus, Argument : Real_Matrix;
+ Cycle : Real'Base)
+ return Complex_Matrix;
+
+33/2
+ -- Complex_Matrix arithmetic operations
+
+34/2
+ function "+" (Right : Complex_Matrix) return Complex_Matrix;
+ function "-" (Right : Complex_Matrix) return Complex_Matrix;
+ function Conjugate (X : Complex_Matrix) return Complex_Matrix;
+ function Transpose (X : Complex_Matrix) return Complex_Matrix;
+
+35/2
+ function "+" (Left, Right : Complex_Matrix) return Complex_Matrix;
+ function "-" (Left, Right : Complex_Matrix) return Complex_Matrix;
+ function "*" (Left, Right : Complex_Matrix) return Complex_Matrix;
+
+36/2
+ function "*" (Left, Right : Complex_Vector) return Complex_Matrix;
+
+37/2
+ function "*" (Left : Complex_Vector;
+ Right : Complex_Matrix) return Complex_Vector;
+ function "*" (Left : Complex_Matrix;
+ Right : Complex_Vector) return Complex_Vector;
+
+38/2
+ -- Mixed Real_Matrix and Complex_Matrix arithmetic operations
+
+39/2
+ function "+" (Left : Real_Matrix;
+ Right : Complex_Matrix) return Complex_Matrix;
+ function "+" (Left : Complex_Matrix;
+ Right : Real_Matrix) return Complex_Matrix;
+ function "-" (Left : Real_Matrix;
+ Right : Complex_Matrix) return Complex_Matrix;
+ function "-" (Left : Complex_Matrix;
+ Right : Real_Matrix) return Complex_Matrix;
+ function "*" (Left : Real_Matrix;
+ Right : Complex_Matrix) return Complex_Matrix;
+ function "*" (Left : Complex_Matrix;
+ Right : Real_Matrix) return Complex_Matrix;
+
+40/2
+ function "*" (Left : Real_Vector;
+ Right : Complex_Vector) return Complex_Matrix;
+ function "*" (Left : Complex_Vector;
+ Right : Real_Vector) return Complex_Matrix;
+
+41/2
+ function "*" (Left : Real_Vector;
+ Right : Complex_Matrix) return Complex_Vector;
+ function "*" (Left : Complex_Vector;
+ Right : Real_Matrix) return Complex_Vector;
+ function "*" (Left : Real_Matrix;
+ Right : Complex_Vector) return Complex_Vector;
+ function "*" (Left : Complex_Matrix;
+ Right : Real_Vector) return Complex_Vector;
+
+42/2
+ -- Complex_Matrix scaling operations
+
+43/2
+ function "*" (Left : Complex;
+ Right : Complex_Matrix) return Complex_Matrix;
+ function "*" (Left : Complex_Matrix;
+ Right : Complex) return Complex_Matrix;
+ function "/" (Left : Complex_Matrix;
+ Right : Complex) return Complex_Matrix;
+
+44/2
+ function "*" (Left : Real'Base;
+ Right : Complex_Matrix) return Complex_Matrix;
+ function "*" (Left : Complex_Matrix;
+ Right : Real'Base) return Complex_Matrix;
+ function "/" (Left : Complex_Matrix;
+ Right : Real'Base) return Complex_Matrix;
+
+45/2
+ -- Complex_Matrix inversion and related operations
+
+46/2
+ function Solve (A : Complex_Matrix; X : Complex_Vector)
+ return Complex_Vector;
+ function Solve (A, X : Complex_Matrix) return Complex_Matrix;
+ function Inverse (A : Complex_Matrix) return Complex_Matrix;
+ function Determinant (A : Complex_Matrix) return Complex;
+
+47/2
+ -- Eigenvalues and vectors of a Hermitian matrix
+
+48/2
+ function Eigenvalues(A : Complex_Matrix) return Real_Vector;
+
+49/2
+ procedure Eigensystem(A : in Complex_Matrix;
+ Values : out Real_Vector;
+ Vectors : out Complex_Matrix);
+
+50/2
+ -- Other Complex_Matrix operations
+
+51/2
+ function Unit_Matrix (Order : Positive;
+ First_1, First_2 : Integer := 1)
+ return Complex_Matrix;
+
+52/2
+ end Ada.Numerics.Generic_Complex_Arrays;
+
+53/2
+{AI95-00296-01AI95-00296-01} The library package Numerics.Complex_Arrays
+is declared pure and defines the same types and subprograms as
+Numerics.Generic_Complex_Arrays, except that the predefined type Float
+is systematically substituted for Real'Base, and the Real_Vector and
+Real_Matrix types exported by Numerics.Real_Arrays are systematically
+substituted for Real_Vector and Real_Matrix, and the Complex type
+exported by Numerics.Complex_Types is systematically substituted for
+Complex, throughout. Nongeneric equivalents for each of the other
+predefined floating point types are defined similarly, with the names
+Numerics.Short_Complex_Arrays, Numerics.Long_Complex_Arrays, etc.
+
+54/2
+{AI95-00296-01AI95-00296-01} Two types are defined and exported by
+Numerics.Generic_Complex_Arrays. The composite type Complex_Vector is
+provided to represent a vector with components of type Complex; it is
+defined as an unconstrained one-dimensional array with an index of type
+Integer. The composite type Complex_Matrix is provided to represent a
+matrix with components of type Complex; it is defined as an
+unconstrained, two-dimensional array with indices of type Integer.
+
+55/2
+{AI95-00296-01AI95-00296-01} The effect of the various subprograms is as
+described below. In many cases they are described in terms of
+corresponding scalar operations in Numerics.Generic_Complex_Types. Any
+exception raised by those operations is propagated by the array
+subprogram. Moreover, any constraints on the parameters and the
+accuracy of the result for each individual component are as defined for
+the scalar operation.
+
+56/2
+{AI95-00296-01AI95-00296-01} In the case of those operations which are
+defined to involve an inner product, Constraint_Error may be raised if
+an intermediate result has a component outside the range of Real'Base
+even though the final mathematical result would not.
+
+56.a/3
+ Discussion: {AI05-0047-1AI05-0047-1} An inner product never
+ involves implicit complex conjugation. If the product of a
+ vector with the conjugate of another (or the same) vector is
+ required, then this has to be stated explicitly by writing for
+ example X * Conjugate(Y). This mimics the usual mathematical
+ notation.
+
+57/2
+ function Re (X : Complex_Vector) return Real_Vector;
+ function Im (X : Complex_Vector) return Real_Vector;
+
+58/2
+ {AI95-00296-01AI95-00296-01} Each function returns a vector of
+ the specified Cartesian components of X. The index range of
+ the result is X'Range.
+
+59/2
+ procedure Set_Re (X : in out Complex_Vector; Re : in Real_Vector);
+ procedure Set_Im (X : in out Complex_Vector; Im : in Real_Vector);
+
+60/2
+ {AI95-00296-01AI95-00296-01} Each procedure replaces the
+ specified (Cartesian) component of each of the components of X
+ by the value of the matching component of Re or Im; the other
+ (Cartesian) component of each of the components is unchanged.
+ Constraint_Error is raised if X'Length is not equal to
+ Re'Length or Im'Length.
+
+61/2
+ function Compose_From_Cartesian (Re : Real_Vector)
+ return Complex_Vector;
+ function Compose_From_Cartesian (Re, Im : Real_Vector)
+ return Complex_Vector;
+
+62/2
+ {AI95-00296-01AI95-00296-01} Each function constructs a vector
+ of Complex results (in Cartesian representation) formed from
+ given vectors of Cartesian components; when only the real
+ components are given, imaginary components of zero are
+ assumed. The index range of the result is Re'Range.
+ Constraint_Error is raised if Re'Length is not equal to
+ Im'Length.
+
+63/2
+ function Modulus (X : Complex_Vector) return Real_Vector;
+ function "abs" (Right : Complex_Vector) return Real_Vector
+ renames Modulus;
+ function Argument (X : Complex_Vector) return Real_Vector;
+ function Argument (X : Complex_Vector;
+ Cycle : Real'Base) return Real_Vector;
+
+64/2
+ {AI95-00296-01AI95-00296-01} Each function calculates and
+ returns a vector of the specified polar components of X or
+ Right using the corresponding function in
+ numerics.generic_complex_types. The index range of the result
+ is X'Range or Right'Range.
+
+65/2
+ function Compose_From_Polar (Modulus, Argument : Real_Vector)
+ return Complex_Vector;
+ function Compose_From_Polar (Modulus, Argument : Real_Vector;
+ Cycle : Real'Base)
+ return Complex_Vector;
+
+66/2
+ {AI95-00296-01AI95-00296-01} Each function constructs a vector
+ of Complex results (in Cartesian representation) formed from
+ given vectors of polar components using the corresponding
+ function in numerics.generic_complex_types on matching
+ components of Modulus and Argument. The index range of the
+ result is Modulus'Range. Constraint_Error is raised if
+ Modulus'Length is not equal to Argument'Length.
+
+67/2
+ function "+" (Right : Complex_Vector) return Complex_Vector;
+ function "-" (Right : Complex_Vector) return Complex_Vector;
+
+68/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation in
+ numerics.generic_complex_types to each component of Right.
+ The index range of the result is Right'Range.
+
+69/2
+ function Conjugate (X : Complex_Vector) return Complex_Vector;
+
+70/2
+ {AI95-00296-01AI95-00296-01} This function returns the result
+ of applying the appropriate function Conjugate in
+ numerics.generic_complex_types to each component of X. The
+ index range of the result is X'Range.
+
+71/2
+ function "+" (Left, Right : Complex_Vector) return Complex_Vector;
+ function "-" (Left, Right : Complex_Vector) return Complex_Vector;
+
+72/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation in
+ numerics.generic_complex_types to each component of Left and
+ the matching component of Right. The index range of the
+ result is Left'Range. Constraint_Error is raised if
+ Left'Length is not equal to Right'Length.
+
+73/2
+ function "*" (Left, Right : Complex_Vector) return Complex;
+
+74/2
+ {AI95-00296-01AI95-00296-01} This operation returns the inner
+ product of Left and Right. Constraint_Error is raised if
+ Left'Length is not equal to Right'Length. This operation
+ involves an inner product.
+
+75/3
+ {AI05-0047-1AI05-0047-1} function "abs" (Right : Complex_Vector) return Real'Base;
+
+76/2
+ {AI95-00418-01AI95-00418-01} This operation returns the
+ Hermitian L2-norm of Right (the square root of the inner
+ product of the vector with its conjugate).
+
+76.a/2
+ Implementation Note: While the definition is given in terms of
+ an inner product, the norm doesn't "involve an inner product"
+ in the technical sense. The reason is that it has accuracy
+ requirements substantially different from those applicable to
+ inner products; and that cancellations cannot occur, because
+ all the terms are positive, so there is no possibility of
+ intermediate overflow.
+
+77/2
+ function "+" (Left : Real_Vector;
+ Right : Complex_Vector) return Complex_Vector;
+ function "+" (Left : Complex_Vector;
+ Right : Real_Vector) return Complex_Vector;
+ function "-" (Left : Real_Vector;
+ Right : Complex_Vector) return Complex_Vector;
+ function "-" (Left : Complex_Vector;
+ Right : Real_Vector) return Complex_Vector;
+
+78/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation in
+ numerics.generic_complex_types to each component of Left and
+ the matching component of Right. The index range of the
+ result is Left'Range. Constraint_Error is raised if
+ Left'Length is not equal to Right'Length.
+
+79/2
+ function "*" (Left : Real_Vector; Right : Complex_Vector) return Complex;
+ function "*" (Left : Complex_Vector; Right : Real_Vector) return Complex;
+
+80/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the inner
+ product of Left and Right. Constraint_Error is raised if
+ Left'Length is not equal to Right'Length. These operations
+ involve an inner product.
+
+81/2
+ function "*" (Left : Complex; Right : Complex_Vector) return Complex_Vector;
+
+82/2
+ {AI95-00296-01AI95-00296-01} This operation returns the result
+ of multiplying each component of Right by the complex number
+ Left using the appropriate operation "*" in
+ numerics.generic_complex_types. The index range of the result
+ is Right'Range.
+
+83/2
+ function "*" (Left : Complex_Vector; Right : Complex) return Complex_Vector;
+ function "/" (Left : Complex_Vector; Right : Complex) return Complex_Vector;
+
+84/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation in
+ numerics.generic_complex_types to each component of the vector
+ Left and the complex number Right. The index range of the
+ result is Left'Range.
+
+85/2
+ function "*" (Left : Real'Base;
+ Right : Complex_Vector) return Complex_Vector;
+
+86/2
+ {AI95-00296-01AI95-00296-01} This operation returns the result
+ of multiplying each component of Right by the real number Left
+ using the appropriate operation "*" in
+ numerics.generic_complex_types. The index range of the result
+ is Right'Range.
+
+87/2
+ function "*" (Left : Complex_Vector;
+ Right : Real'Base) return Complex_Vector;
+ function "/" (Left : Complex_Vector;
+ Right : Real'Base) return Complex_Vector;
+
+88/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation in
+ numerics.generic_complex_types to each component of the vector
+ Left and the real number Right. The index range of the result
+ is Left'Range.
+
+89/2
+ function Unit_Vector (Index : Integer;
+ Order : Positive;
+ First : Integer := 1) return Complex_Vector;
+
+90/2
+ {AI95-00296-01AI95-00296-01} This function returns a unit
+ vector with Order components and a lower bound of First. All
+ components are set to (0.0, 0.0) except for the Index
+ component which is set to (1.0, 0.0). Constraint_Error is
+ raised if Index < First, Index > First + Order - 1, or if
+ First + Order - 1 > Integer'Last.
+
+91/2
+ function Re (X : Complex_Matrix) return Real_Matrix;
+ function Im (X : Complex_Matrix) return Real_Matrix;
+
+92/2
+ {AI95-00296-01AI95-00296-01} Each function returns a matrix of
+ the specified Cartesian components of X. The index ranges of
+ the result are those of X.
+
+93/2
+ procedure Set_Re (X : in out Complex_Matrix; Re : in Real_Matrix);
+ procedure Set_Im (X : in out Complex_Matrix; Im : in Real_Matrix);
+
+94/2
+ {AI95-00296-01AI95-00296-01} Each procedure replaces the
+ specified (Cartesian) component of each of the components of X
+ by the value of the matching component of Re or Im; the other
+ (Cartesian) component of each of the components is unchanged.
+ Constraint_Error is raised if X'Length(1) is not equal to
+ Re'Length(1) or Im'Length(1) or if X'Length(2) is not equal to
+ Re'Length(2) or Im'Length(2).
+
+95/2
+ function Compose_From_Cartesian (Re : Real_Matrix)
+ return Complex_Matrix;
+ function Compose_From_Cartesian (Re, Im : Real_Matrix)
+ return Complex_Matrix;
+
+96/2
+ {AI95-00296-01AI95-00296-01} Each function constructs a matrix
+ of Complex results (in Cartesian representation) formed from
+ given matrices of Cartesian components; when only the real
+ components are given, imaginary components of zero are
+ assumed. The index ranges of the result are those of Re.
+ Constraint_Error is raised if Re'Length(1) is not equal to
+ Im'Length(1) or Re'Length(2) is not equal to Im'Length(2).
+
+97/2
+ function Modulus (X : Complex_Matrix) return Real_Matrix;
+ function "abs" (Right : Complex_Matrix) return Real_Matrix
+ renames Modulus;
+ function Argument (X : Complex_Matrix) return Real_Matrix;
+ function Argument (X : Complex_Matrix;
+ Cycle : Real'Base) return Real_Matrix;
+
+98/2
+ {AI95-00296-01AI95-00296-01} Each function calculates and
+ returns a matrix of the specified polar components of X or
+ Right using the corresponding function in
+ numerics.generic_complex_types. The index ranges of the
+ result are those of X or Right.
+
+99/2
+ function Compose_From_Polar (Modulus, Argument : Real_Matrix)
+ return Complex_Matrix;
+ function Compose_From_Polar (Modulus, Argument : Real_Matrix;
+ Cycle : Real'Base)
+ return Complex_Matrix;
+
+100/2
+ {AI95-00296-01AI95-00296-01} Each function constructs a matrix
+ of Complex results (in Cartesian representation) formed from
+ given matrices of polar components using the corresponding
+ function in numerics.generic_complex_types on matching
+ components of Modulus and Argument. The index ranges of the
+ result are those of Modulus. Constraint_Error is raised if
+ Modulus'Length(1) is not equal to Argument'Length(1) or
+ Modulus'Length(2) is not equal to Argument'Length(2).
+
+101/2
+ function "+" (Right : Complex_Matrix) return Complex_Matrix;
+ function "-" (Right : Complex_Matrix) return Complex_Matrix;
+
+102/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation in
+ numerics.generic_complex_types to each component of Right.
+ The index ranges of the result are those of Right.
+
+103/2
+ function Conjugate (X : Complex_Matrix) return Complex_Matrix;
+
+104/2
+ {AI95-00296-01AI95-00296-01} This function returns the result
+ of applying the appropriate function Conjugate in
+ numerics.generic_complex_types to each component of X. The
+ index ranges of the result are those of X.
+
+105/2
+ function Transpose (X : Complex_Matrix) return Complex_Matrix;
+
+106/2
+ {AI95-00296-01AI95-00296-01} This function returns the
+ transpose of a matrix X. The first and second index ranges of
+ the result are X'Range(2) and X'Range(1) respectively.
+
+107/2
+ function "+" (Left, Right : Complex_Matrix) return Complex_Matrix;
+ function "-" (Left, Right : Complex_Matrix) return Complex_Matrix;
+
+108/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation in
+ numerics.generic_complex_types to each component of Left and
+ the matching component of Right. The index ranges of the
+ result are those of Left. Constraint_Error is raised if
+ Left'Length(1) is not equal to Right'Length(1) or
+ Left'Length(2) is not equal to Right'Length(2).
+
+109/2
+ function "*" (Left, Right : Complex_Matrix) return Complex_Matrix;
+
+110/2
+ {AI95-00296-01AI95-00296-01} This operation provides the
+ standard mathematical operation for matrix multiplication.
+ The first and second index ranges of the result are
+ Left'Range(1) and Right'Range(2) respectively.
+ Constraint_Error is raised if Left'Length(2) is not equal to
+ Right'Length(1). This operation involves inner products.
+
+111/2
+ function "*" (Left, Right : Complex_Vector) return Complex_Matrix;
+
+112/2
+ {AI95-00296-01AI95-00296-01} This operation returns the outer
+ product of a (column) vector Left by a (row) vector Right
+ using the appropriate operation "*" in
+ numerics.generic_complex_types for computing the individual
+ components. The first and second index ranges of the result
+ are Left'Range and Right'Range respectively.
+
+113/2
+ function "*" (Left : Complex_Vector;
+ Right : Complex_Matrix) return Complex_Vector;
+
+114/2
+ {AI95-00296-01AI95-00296-01} This operation provides the
+ standard mathematical operation for multiplication of a (row)
+ vector Left by a matrix Right. The index range of the (row)
+ vector result is Right'Range(2). Constraint_Error is raised
+ if Left'Length is not equal to Right'Length(1). This
+ operation involves inner products.
+
+115/2
+ function "*" (Left : Complex_Matrix;
+ Right : Complex_Vector) return Complex_Vector;
+
+116/2
+ {AI95-00296-01AI95-00296-01} This operation provides the
+ standard mathematical operation for multiplication of a matrix
+ Left by a (column) vector Right. The index range of the
+ (column) vector result is Left'Range(1). Constraint_Error is
+ raised if Left'Length(2) is not equal to Right'Length. This
+ operation involves inner products.
+
+117/2
+ function "+" (Left : Real_Matrix;
+ Right : Complex_Matrix) return Complex_Matrix;
+ function "+" (Left : Complex_Matrix;
+ Right : Real_Matrix) return Complex_Matrix;
+ function "-" (Left : Real_Matrix;
+ Right : Complex_Matrix) return Complex_Matrix;
+ function "-" (Left : Complex_Matrix;
+ Right : Real_Matrix) return Complex_Matrix;
+
+118/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation in
+ numerics.generic_complex_types to each component of Left and
+ the matching component of Right. The index ranges of the
+ result are those of Left. Constraint_Error is raised if
+ Left'Length(1) is not equal to Right'Length(1) or
+ Left'Length(2) is not equal to Right'Length(2).
+
+119/2
+ function "*" (Left : Real_Matrix;
+ Right : Complex_Matrix) return Complex_Matrix;
+ function "*" (Left : Complex_Matrix;
+ Right : Real_Matrix) return Complex_Matrix;
+
+120/2
+ {AI95-00296-01AI95-00296-01} Each operation provides the
+ standard mathematical operation for matrix multiplication.
+ The first and second index ranges of the result are
+ Left'Range(1) and Right'Range(2) respectively.
+ Constraint_Error is raised if Left'Length(2) is not equal to
+ Right'Length(1). These operations involve inner products.
+
+121/2
+ function "*" (Left : Real_Vector;
+ Right : Complex_Vector) return Complex_Matrix;
+ function "*" (Left : Complex_Vector;
+ Right : Real_Vector) return Complex_Matrix;
+
+122/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the outer
+ product of a (column) vector Left by a (row) vector Right
+ using the appropriate operation "*" in
+ numerics.generic_complex_types for computing the individual
+ components. The first and second index ranges of the result
+ are Left'Range and Right'Range respectively.
+
+123/2
+ function "*" (Left : Real_Vector;
+ Right : Complex_Matrix) return Complex_Vector;
+ function "*" (Left : Complex_Vector;
+ Right : Real_Matrix) return Complex_Vector;
+
+124/2
+ {AI95-00296-01AI95-00296-01} Each operation provides the
+ standard mathematical operation for multiplication of a (row)
+ vector Left by a matrix Right. The index range of the (row)
+ vector result is Right'Range(2). Constraint_Error is raised
+ if Left'Length is not equal to Right'Length(1). These
+ operations involve inner products.
+
+125/2
+ function "*" (Left : Real_Matrix;
+ Right : Complex_Vector) return Complex_Vector;
+ function "*" (Left : Complex_Matrix;
+ Right : Real_Vector) return Complex_Vector;
+
+126/2
+ {AI95-00296-01AI95-00296-01} Each operation provides the
+ standard mathematical operation for multiplication of a matrix
+ Left by a (column) vector Right. The index range of the
+ (column) vector result is Left'Range(1). Constraint_Error is
+ raised if Left'Length(2) is not equal to Right'Length. These
+ operations involve inner products.
+
+127/2
+ function "*" (Left : Complex; Right : Complex_Matrix) return Complex_Matrix;
+
+128/2
+ {AI95-00296-01AI95-00296-01} This operation returns the result
+ of multiplying each component of Right by the complex number
+ Left using the appropriate operation "*" in
+ numerics.generic_complex_types. The index ranges of the
+ result are those of Right.
+
+129/2
+ function "*" (Left : Complex_Matrix; Right : Complex) return Complex_Matrix;
+ function "/" (Left : Complex_Matrix; Right : Complex) return Complex_Matrix;
+
+130/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation in
+ numerics.generic_complex_types to each component of the matrix
+ Left and the complex number Right. The index ranges of the
+ result are those of Left.
+
+131/2
+ function "*" (Left : Real'Base;
+ Right : Complex_Matrix) return Complex_Matrix;
+
+132/2
+ {AI95-00296-01AI95-00296-01} This operation returns the result
+ of multiplying each component of Right by the real number Left
+ using the appropriate operation "*" in
+ numerics.generic_complex_types. The index ranges of the
+ result are those of Right.
+
+133/2
+ function "*" (Left : Complex_Matrix;
+ Right : Real'Base) return Complex_Matrix;
+ function "/" (Left : Complex_Matrix;
+ Right : Real'Base) return Complex_Matrix;
+
+134/2
+ {AI95-00296-01AI95-00296-01} Each operation returns the result
+ of applying the corresponding operation in
+ numerics.generic_complex_types to each component of the matrix
+ Left and the real number Right. The index ranges of the
+ result are those of Left.
+
+135/2
+ function Solve (A : Complex_Matrix; X : Complex_Vector) return Complex_Vector;
+
+136/2
+ {AI95-00296-01AI95-00296-01} This function returns a vector Y
+ such that X is (nearly) equal to A * Y. This is the standard
+ mathematical operation for solving a single set of linear
+ equations. The index range of the result is A'Range(2).
+ Constraint_Error is raised if A'Length(1), A'Length(2), and
+ X'Length are not equal. Constraint_Error is raised if the
+ matrix A is ill-conditioned.
+
+136.a/2
+ Discussion: The text says that Y is such that "X is (nearly)
+ equal to A * Y" rather than "X is equal to A * Y" because
+ rounding errors may mean that there is no value of Y such that
+ X is exactly equal to A * Y. On the other hand it does not
+ mean that any old rough value will do. The algorithm given
+ under Implementation Advice should be followed.
+
+136.b/2
+ The requirement to raise Constraint_Error if the matrix is
+ ill-conditioned is really a reflection of what will happen if
+ the matrix is ill-conditioned. See Implementation Advice. We
+ do not make any attempt to define ill-conditioned formally.
+
+136.c/2
+ These remarks apply to all versions of Solve and Inverse.
+
+137/2
+ function Solve (A, X : Complex_Matrix) return Complex_Matrix;
+
+138/2
+ {AI95-00296-01AI95-00296-01} This function returns a matrix Y
+ such that X is (nearly) equal to A * Y. This is the standard
+ mathematical operation for solving several sets of linear
+ equations. The index ranges of the result are A'Range(2) and
+ X'Range(2). Constraint_Error is raised if A'Length(1),
+ A'Length(2), and X'Length(1) are not equal. Constraint_Error
+ is raised if the matrix A is ill-conditioned.
+
+139/2
+ function Inverse (A : Complex_Matrix) return Complex_Matrix;
+
+140/2
+ {AI95-00296-01AI95-00296-01} This function returns a matrix B
+ such that A * B is (nearly) equal to the unit matrix. The
+ index ranges of the result are A'Range(2) and A'Range(1).
+ Constraint_Error is raised if A'Length(1) is not equal to
+ A'Length(2). Constraint_Error is raised if the matrix A is
+ ill-conditioned.
+
+141/2
+ function Determinant (A : Complex_Matrix) return Complex;
+
+142/2
+ {AI95-00296-01AI95-00296-01} This function returns the
+ determinant of the matrix A. Constraint_Error is raised if
+ A'Length(1) is not equal to A'Length(2).
+
+143/2
+ function Eigenvalues(A : Complex_Matrix) return Real_Vector;
+
+144/2
+ {AI95-00296-01AI95-00296-01} This function returns the
+ eigenvalues of the Hermitian matrix A as a vector sorted into
+ order with the largest first. Constraint_Error is raised if
+ A'Length(1) is not equal to A'Length(2). The index range of
+ the result is A'Range(1). Argument_Error is raised if the
+ matrix A is not Hermitian.
+
+144.a/2
+ Discussion: A Hermitian matrix is one whose transpose is equal
+ to its complex conjugate. The eigenvalues of a Hermitian
+ matrix are always real. We only support this case because
+ algorithms for solving the general case are inherently
+ unstable.
+
+145/2
+ procedure Eigensystem(A : in Complex_Matrix;
+ Values : out Real_Vector;
+ Vectors : out Complex_Matrix);
+
+146/3
+ {AI95-00296-01AI95-00296-01} {AI05-0047-1AI05-0047-1} This
+ procedure computes both the eigenvalues and eigenvectors of
+ the Hermitian matrix A. The out parameter Values is the same
+ as that obtained by calling the function Eigenvalues. The out
+ parameter Vectors is a matrix whose columns are the
+ eigenvectors of the matrix A. The order of the columns
+ corresponds to the order of the eigenvalues. The eigenvectors
+ are mutually orthonormal, including when there are repeated
+ eigenvalues. Constraint_Error is raised if A'Length(1) is not
+ equal to A'Length(2), or if Values'Range is not equal to
+ A'Range(1), or if the index ranges of the parameter Vectors
+ are not equal to those of A. Argument_Error is raised if the
+ matrix A is not Hermitian. Constraint_Error is also raised in
+ implementation-defined circumstances if the algorithm used
+ does not converge quickly enough.
+
+146.a/3
+ Ramification: {AI05-0047-1AI05-0047-1} There is no requirement
+ on the absolute direction of the returned eigenvectors. Thus
+ they might be multiplied by any complex number whose modulus
+ is 1. It is only the ratios of the components that matter.
+ This is standard practice.
+
+147/2
+ function Unit_Matrix (Order : Positive;
+ First_1, First_2 : Integer := 1)
+ return Complex_Matrix;
+
+148/2
+ {AI95-00296-01AI95-00296-01} This function returns a square
+ unit matrix with Order**2 components and lower bounds of
+ First_1 and First_2 (for the first and second index ranges
+ respectively). All components are set to (0.0, 0.0) except
+ for the main diagonal, whose components are set to (1.0, 0.0).
+ Constraint_Error is raised if First_1 + Order - 1 >
+ Integer'Last or First_2 + Order - 1 > Integer'Last.
+
+ _Implementation Requirements_
+
+149/2
+{AI95-00296-01AI95-00296-01} Accuracy requirements for the subprograms
+Solve, Inverse, Determinant, Eigenvalues and Eigensystem are
+implementation defined.
+
+149.a/2
+ Implementation defined: The accuracy requirements for the
+ subprograms Solve, Inverse, Determinant, Eigenvalues and
+ Eigensystem for type Complex_Matrix.
+
+150/2
+{AI95-00296-01AI95-00296-01} For operations not involving an inner
+product, the accuracy requirements are those of the corresponding
+operations of the type Real'Base and Complex in both the strict mode and
+the relaxed mode (see *note G.2::).
+
+151/2
+{AI95-00296-01AI95-00296-01} For operations involving an inner product,
+no requirements are specified in the relaxed mode. In the strict mode
+the modulus of the absolute error of the inner product X*Y shall not
+exceed g*abs(X)*abs(Y) where g is defined as
+
+152/2
+ g = X'Length * Real'Machine_Radix**(1 - Real'Model_Mantissa)
+ for mixed complex and real operands
+
+153/2
+ g = sqrt(2.0) * X'Length * Real'Machine_Radix**(1 - Real'Model_Mantissa)
+ for two complex operands
+
+154/2
+{AI95-00418-01AI95-00418-01} For the L2-norm, no accuracy requirements
+are specified in the relaxed mode. In the strict mode the relative
+error on the norm shall not exceed g / 2.0 + 3.0 * Real'Model_Epsilon
+where g has the definition appropriate for two complex operands.
+
+ _Documentation Requirements_
+
+155/2
+{AI95-00296-01AI95-00296-01} Implementations shall document any
+techniques used to reduce cancellation errors such as extended precision
+arithmetic.
+
+155.a/2
+ Documentation Requirement: Any techniques used to reduce
+ cancellation errors in Numerics.Generic_Complex_Arrays shall
+ be documented.
+
+155.b/2
+ Implementation Note: The above accuracy requirement is met by
+ the canonical implementation of the inner product by
+ multiplication and addition using the corresponding operations
+ of type Complex and performing the cumulative addition using
+ ascending indices. Note however, that some hardware provides
+ special operations for the computation of the inner product
+ and although these may be fast they may not meet the accuracy
+ requirement specified. See Accuracy and Stability of
+ Numerical Algorithms by N J Higham (ISBN 0-89871-355-2),
+ Sections 3.1 and 3.6.
+
+ _Implementation Permissions_
+
+156/2
+{AI95-00296-01AI95-00296-01} The nongeneric equivalent packages may, but
+need not, be actual instantiations of the generic package for the
+appropriate predefined type.
+
+157/2
+{AI95-00296-01AI95-00296-01} Although many operations are defined in
+terms of operations from numerics.generic_complex_types, they need not
+be implemented by calling those operations provided that the effect is
+the same.
+
+ _Implementation Advice_
+
+158/3
+{AI95-00296-01AI95-00296-01} {AI05-0264-1AI05-0264-1} Implementations
+should implement the Solve and Inverse functions using established
+techniques. Implementations are recommended to refine the result by
+performing an iteration on the residuals; if this is done, then it
+should be documented.
+
+158.a/2
+ Implementation Advice: Solve and Inverse for
+ Numerics.Generic_Complex_Arrays should be implemented using
+ established techniques and the result should be refined by an
+ iteration on the residuals.
+
+159/2
+{AI95-00296-01AI95-00296-01} It is not the intention that any special
+provision should be made to determine whether a matrix is
+ill-conditioned or not. The naturally occurring overflow (including
+division by zero) which will result from executing these functions with
+an ill-conditioned matrix and thus raise Constraint_Error is sufficient.
+
+159.a/2
+ Discussion: There isn't any advice for the implementation to
+ document with this paragraph.
+
+160/2
+{AI95-00296-01AI95-00296-01} The test that a matrix is Hermitian should
+use the equality operator to compare the real components and negation
+followed by equality to compare the imaginary components (see *note
+G.2.1::).
+
+160.a/2
+ Implementation Advice: The equality and negation operators
+ should be used to test that a matrix is Hermitian.
+
+160.1/3
+An implementation should minimize the circumstances under which the
+algorithm used for Eigenvalues and Eigensystem fails to converge.
+
+160.a.1/3
+ Implementation Advice: An implementation should minimize the
+ circumstances under which the algorithm used for
+ Numerics.Generic_Complex_Arrays.Eigenvalues and
+ Numerics.Generic_Complex_Arrays.Eigensystem fails to converge.
+
+160.b/3
+ Implementation Note: J. H. Wilkinson is the acknowledged
+ expert in this area. See for example Wilkinson, J. H., and
+ Reinsch, C. , Linear Algebra , vol II of Handbook for
+ Automatic Computation, Springer-Verlag, or Wilkinson, J. H.,
+ The Algebraic Eigenvalue Problem, Oxford University Press.
+
+161/2
+{AI95-00296-01AI95-00296-01} Implementations should not perform
+operations on mixed complex and real operands by first converting the
+real operand to complex. See *note G.1.1::.
+
+161.a/2
+ Implementation Advice: Mixed real and complex operations
+ should not be performed by converting the real operand to
+ complex.
+
+ _Extensions to Ada 95_
+
+161.b/2
+ {AI95-00296-01AI95-00296-01} The package
+ Numerics.Generic_Complex_Arrays and its nongeneric equivalents
+ are new.
+
+ _Wording Changes from Ada 2005_
+
+161.c/3
+ {AI05-0047-1AI05-0047-1} Correction: Corrected various
+ accuracy and definition issues.
+
+\1f
+File: aarm2012.info, Node: Annex H, Next: Annex J, Prev: Annex G, Up: Top
+
+Annex H High Integrity Systems
+******************************
+
+1/2
+{AI95-00347-01AI95-00347-01} This Annex addresses requirements for high
+integrity systems (including safety-critical systems and
+security-critical systems). It provides facilities and specifies
+documentation requirements that relate to several needs:
+
+2
+ * Understanding program execution;
+
+3
+ * Reviewing object code;
+
+4
+ * Restricting language constructs whose usage might complicate the
+ demonstration of program correctness
+
+4.1
+Execution understandability is supported by pragma Normalize_Scalars,
+and also by requirements for the implementation to document the effect
+of a program in the presence of a bounded error or where the language
+rules leave the effect unspecified.
+
+5
+The pragmas Reviewable and Restrictions relate to the other requirements
+addressed by this Annex.
+
+ NOTES
+
+6
+ 1 The Valid attribute (see *note 13.9.2::) is also useful in
+ addressing these needs, to avoid problems that could otherwise
+ arise from scalars that have values outside their declared range
+ constraints.
+
+6.a
+ Discussion: The Annex tries to provide high assurance rather
+ than language features. However, it is not possible, in
+ general, to test for high assurance. For any specific
+ language feature, it is possible to demonstrate its presence
+ by a functional test, as in the ACVC. One can also check for
+ the presence of some documentation requirements, but it is not
+ easy to determine objectively that the documentation is
+ "adequate".
+
+ _Extensions to Ada 83_
+
+6.b
+ This Annex is new to Ada 95.
+
+ _Wording Changes from Ada 95_
+
+6.c/2
+ {AI95-00347-01AI95-00347-01} The title of this annex was
+ changed to better reflect its purpose and scope. High
+ integrity systems has become the standard way of identifying
+ systems that have high reliability requirements; it subsumes
+ terms such as safety and security. Moreover, the annex does
+ not include any security specific features and as such the
+ previous title is somewhat misleading.
+
+* Menu:
+
+* H.1 :: Pragma Normalize_Scalars
+* H.2 :: Documentation of Implementation Decisions
+* H.3 :: Reviewable Object Code
+* H.4 :: High Integrity Restrictions
+* H.5 :: Pragma Detect_Blocking
+* H.6 :: Pragma Partition_Elaboration_Policy
+
+\1f
+File: aarm2012.info, Node: H.1, Next: H.2, Up: Annex H
+
+H.1 Pragma Normalize_Scalars
+============================
+
+1
+This pragma ensures that an otherwise uninitialized scalar object is set
+to a predictable value, but out of range if possible.
+
+1.a
+ Discussion: The goal of the pragma is to reduce the impact of
+ a bounded error that results from a reference to an
+ uninitialized scalar object, by having such a reference
+ violate a range check and thus raise Constraint_Error.
+
+ _Syntax_
+
+2
+ The form of a pragma Normalize_Scalars is as follows:
+
+3
+ pragma Normalize_Scalars;
+
+ _Post-Compilation Rules_
+
+4
+Pragma Normalize_Scalars is a configuration pragma. It applies to all
+compilation_units included in a partition.
+
+ _Documentation Requirements_
+
+5/2
+{AI95-00434-01AI95-00434-01} If a pragma Normalize_Scalars applies, the
+implementation shall document the implicit initial values for scalar
+subtypes, and shall identify each case in which such a value is used and
+is not an invalid representation.
+
+5.a/2
+ Documentation Requirement: If a pragma Normalize_Scalars
+ applies, the implicit initial values of scalar subtypes shall
+ be documented. Such a value should be an invalid
+ representation when possible; any cases when is it not shall
+ be documented.
+
+5.b
+ To be honest: It's slightly inaccurate to say that the value
+ is a representation, but the point should be clear anyway.
+
+5.c
+ Discussion: By providing a type with a size specification so
+ that spare bits are present, it is possible to force an
+ implementation of Normalize_Scalars to use an out of range
+ value. This can be tested for by ensuring that
+ Constraint_Error is raised. Similarly, for an unconstrained
+ integer type, in which no spare bit is surely present, one can
+ check that the initialization takes place to the value
+ specified in the documentation of the implementation. For a
+ floating point type, spare bits might not be available, but a
+ range constraint can provide the ability to use an out of
+ range value.
+
+5.d
+ If it is difficult to document the general rule for the
+ implicit initial value, the implementation might choose
+ instead to record the value on the object code listing or
+ similar output produced during compilation.
+
+ _Implementation Advice_
+
+6/2
+{AI95-00434-01AI95-00434-01} Whenever possible, the implicit initial
+values for a scalar subtype should be an invalid representation (see
+*note 13.9.1::).
+
+6.a
+ Discussion: When an out of range value is used for the
+ initialization, it is likely that constraint checks will
+ detect it. In addition, it can be detected by the Valid
+ attribute.
+
+6.b/2
+ This rule is included in the documentation requirements, and
+ thus does not need a separate summary item.
+
+ NOTES
+
+7
+ 2 The initialization requirement applies to uninitialized scalar
+ objects that are subcomponents of composite objects, to allocated
+ objects, and to stand-alone objects. It also applies to scalar out
+ parameters. Scalar subcomponents of composite out parameters are
+ initialized to the corresponding part of the actual, by virtue of
+ *note 6.4.1::.
+
+8
+ 3 The initialization requirement does not apply to a scalar for
+ which pragma Import has been specified, since initialization of an
+ imported object is performed solely by the foreign language
+ environment (see *note B.1::).
+
+9
+ 4 The use of pragma Normalize_Scalars in conjunction with Pragma
+ Restrictions(No_Exceptions) may result in erroneous execution (see
+ *note H.4::).
+
+9.a
+ Discussion: Since the effect of an access to an out of range
+ value will often be to raise Constraint_Error, it is clear
+ that suppressing the exception mechanism could result in
+ erroneous execution. In particular, the assignment to an
+ array, with the array index out of range, will result in a
+ write to an arbitrary store location, having unpredictable
+ effects.
+
+\1f
+File: aarm2012.info, Node: H.2, Next: H.3, Prev: H.1, Up: Annex H
+
+H.2 Documentation of Implementation Decisions
+=============================================
+
+ _Documentation Requirements_
+
+1
+The implementation shall document the range of effects for each
+situation that the language rules identify as either a bounded error or
+as having an unspecified effect. If the implementation can constrain
+the effects of erroneous execution for a given construct, then it shall
+document such constraints. [The documentation might be provided either
+independently of any compilation unit or partition, or as part of an
+annotated listing for a given unit or partition. See also *note
+1.1.3::, and *note 1.1.2::.]
+
+1.a/2
+ This paragraph was deleted.
+
+1.b/2
+ Documentation Requirement: The range of effects for each
+ bounded error and each unspecified effect. If the effects of
+ a given erroneous construct are constrained, the constraints
+ shall be documented.
+
+ NOTES
+
+2
+ 5 Among the situations to be documented are the conventions chosen
+ for parameter passing, the methods used for the management of
+ run-time storage, and the method used to evaluate numeric
+ expressions if this involves extended range or extra precision.
+
+2.a
+ Discussion: Look up "unspecified" and "erroneous execution" in
+ the index for a list of the cases.
+
+2.b
+ The management of run-time storage is particularly important.
+ For safety applications, it is often necessary to show that a
+ program cannot raise Storage_Error, and for security
+ applications that information cannot leak via the run-time
+ system. Users are likely to prefer a simple storage model
+ that can be easily validated.
+
+2.c
+ The documentation could helpfully take into account that users
+ may well adopt a subset to avoid some forms of erroneous
+ execution, for instance, not using the abort statement, so
+ that the effects of a partly completed assignment_statement do
+ not have to be considered in the validation of a program (see
+ *note 9.8::). For this reason documentation linked to an
+ actual compilation may be most useful. Similarly, an
+ implementation may be able to take into account use of the
+ Restrictions pragma.
+
+\1f
+File: aarm2012.info, Node: H.3, Next: H.4, Prev: H.2, Up: Annex H
+
+H.3 Reviewable Object Code
+==========================
+
+1
+Object code review and validation are supported by pragmas Reviewable
+and Inspection_Point.
+
+* Menu:
+
+* H.3.1 :: Pragma Reviewable
+* H.3.2 :: Pragma Inspection_Point
+
+\1f
+File: aarm2012.info, Node: H.3.1, Next: H.3.2, Up: H.3
+
+H.3.1 Pragma Reviewable
+-----------------------
+
+1
+This pragma directs the implementation to provide information to
+facilitate analysis and review of a program's object code, in particular
+to allow determination of execution time and storage usage and to
+identify the correspondence between the source and object programs.
+
+1.a
+ Discussion: Since the purpose of this pragma is to provide
+ information to the user, it is hard to objectively test for
+ conformity. In practice, users want the information in an
+ easily understood and convenient form, but neither of these
+ properties can be easily measured.
+
+ _Syntax_
+
+2
+ The form of a pragma Reviewable is as follows:
+
+3
+ pragma Reviewable;
+
+ _Post-Compilation Rules_
+
+4
+Pragma Reviewable is a configuration pragma. It applies to all
+compilation_units included in a partition.
+
+ _Implementation Requirements_
+
+5
+The implementation shall provide the following information for any
+compilation unit to which such a pragma applies:
+
+5.a
+ Discussion: The list of requirements can be checked for, even
+ if issues like intelligibility are not addressed.
+
+6
+ * Where compiler-generated run-time checks remain;
+
+6.a
+ Discussion: A constraint check which is implemented via a
+ check on the upper and lower bound should clearly be
+ indicated. If a check is implicit in the form of machine
+ instructions used (such an overflow checking), this should
+ also be covered by the documentation. It is particularly
+ important to cover those checks which are not obvious from the
+ source code, such as that for stack overflow.
+
+7
+ * An identification of any construct with a language-defined check
+ that is recognized prior to run time as certain to fail if executed
+ (even if the generation of run-time checks has been suppressed);
+
+7.a
+ Discussion: In this case, if the compiler determines that a
+ check must fail, the user should be informed of this.
+ However, since it is not in general possible to know what the
+ compiler will detect, it is not easy to test for this. In
+ practice, it is thought that compilers claiming conformity to
+ this Annex will perform significant optimizations and
+ therefore will detect such situations. Of course, such events
+ could well indicate a programmer error.
+
+8/2
+ * {AI95-00209-01AI95-00209-01} For each read of a scalar object, an
+ identification of the read as either "known to be initialized," or
+ "possibly uninitialized," independent of whether pragma
+ Normalize_Scalars applies;
+
+8.a
+ Discussion: This issue again raises the question as to what
+ the compiler has determined. A lazy implementation could
+ clearly mark all scalars as "possibly uninitialized", but this
+ would be very unhelpful to the user. It should be possible to
+ analyze a range of scalar uses and note the percentage in each
+ class. Note that an access marked "known to be initialized"
+ does not imply that the value is in range, since the
+ initialization could be from an (erroneous) call of unchecked
+ conversion, or by means external to the Ada program.
+
+9
+ * Where run-time support routines are implicitly invoked;
+
+9.a
+ Discussion: Validators will need to know the calls invoked in
+ order to check for the correct functionality. For instance,
+ for some safety applications, it may be necessary to ensure
+ that certain sections of code can execute in a particular
+ time.
+
+10
+ * An object code listing, including:
+
+11
+ * Machine instructions, with relative offsets;
+
+11.a
+ Discussion: The machine instructions should be in a format
+ that is easily understood, such as the symbolic format of the
+ assembler. The relative offsets are needed in numeric format,
+ to check any alignment restrictions that the architecture
+ might impose.
+
+12
+ * Where each data object is stored during its lifetime;
+
+12.a
+ Discussion: This requirement implies that if the optimizer
+ assigns a variable to a register, this needs to be evident.
+
+13
+ * Correspondence with the source program, including an
+ identification of the code produced per declaration and
+ per statement.
+
+13.a
+ Discussion: This correspondence will be quite complex when
+ extensive optimization is performed. In particular, address
+ calculation to access some data structures could be moved from
+ the actual access. However, when all the machine code arising
+ from a statement or declaration is in one basic block, this
+ must be indicated by the implementation.
+
+14
+ * An identification of each construct for which the implementation
+ detects the possibility of erroneous execution;
+
+14.a
+ Discussion: This requirement is quite vague. In general, it
+ is hard for compilers to detect erroneous execution and
+ therefore the requirement will be rarely invoked. However, if
+ the pragma Suppress is used and the compiler can show that a
+ predefined exception will be raised, then such an
+ identification would be useful.
+
+15
+ * For each subprogram, block, task, or other construct implemented by
+ reserving and subsequently freeing an area on a run-time stack, an
+ identification of the length of the fixed-size portion of the area
+ and an indication of whether the non-fixed size portion is reserved
+ on the stack or in a dynamically-managed storage region.
+
+15.a
+ Discussion: This requirement is vital for those requiring to
+ show that the storage available to a program is sufficient.
+ This is crucial in those cases in which the internal checks
+ for stack overflow are suppressed (perhaps by pragma
+ Restrictions(No_Exceptions)).
+
+16
+The implementation shall provide the following information for any
+partition to which the pragma applies:
+
+17
+ * An object code listing of the entire partition, including
+ initialization and finalization code as well as run-time system
+ components, and with an identification of those instructions and
+ data that will be relocated at load time;
+
+17.a
+ Discussion: The object code listing should enable a validator
+ to estimate upper bounds for the time taken by critical parts
+ of a program. Similarly, by an analysis of the entire
+ partition, it should be possible to ensure that the storage
+ requirements are suitably bounded, assuming that the partition
+ was written in an appropriate manner.
+
+18
+ * A description of the run-time model relevant to the partition.
+
+18.a
+ Discussion: For example, a description of the storage model is
+ vital, since the Ada language does not explicitly define such
+ a model.
+
+18.1
+The implementation shall provide control- and data-flow information,
+both within each compilation unit and across the compilation units of
+the partition.
+
+18.b
+ Discussion: This requirement is quite vague, since it is
+ unclear what control and data flow information the compiler
+ has produced. It is really a plea not to throw away
+ information that could be useful to the validator. Note that
+ the data flow information is relevant to the detection of
+ "possibly uninitialized" objects referred to above.
+
+ _Implementation Advice_
+
+19
+The implementation should provide the above information in both a
+human-readable and machine-readable form, and should document the latter
+so as to ease further processing by automated tools.
+
+19.a/2
+ Implementation Advice: The information produced by pragma
+ Reviewable should be provided in both a human-readable and
+ machine-readable form, and the latter form should be
+ documented.
+
+20
+Object code listings should be provided both in a symbolic format and
+also in an appropriate numeric format (such as hexadecimal or octal).
+
+20.a/2
+ Implementation Advice: Object code listings should be provided
+ both in a symbolic format and in a numeric format.
+
+20.b
+ Reason: This is to enable other tools to perform any analysis
+ that the user needed to aid validation. The format should be
+ in some agreed form.
+
+ NOTES
+
+21
+ 6 The order of elaboration of library units will be documented
+ even in the absence of pragma Reviewable (see *note 10.2::).
+
+21.a
+ Discussion: There might be some interactions between pragma
+ Reviewable and compiler optimizations. For example, an
+ implementation may disable some optimizations when pragma
+ Reviewable is in force if it would be overly complicated to
+ provide the detailed information to allow review of the
+ optimized object code. See also pragma Optimize (*note
+ 2.8::).
+
+ _Wording Changes from Ada 95_
+
+21.b/2
+ {AI95-00209-01AI95-00209-01} The wording was clarified that
+ pragma Reviewable applies to each read of an object, as it
+ makes no sense to talk about the state of an object that will
+ immediately be overwritten.
+
+\1f
+File: aarm2012.info, Node: H.3.2, Prev: H.3.1, Up: H.3
+
+H.3.2 Pragma Inspection_Point
+-----------------------------
+
+1
+An occurrence of a pragma Inspection_Point identifies a set of objects
+each of whose values is to be available at the point(s) during program
+execution corresponding to the position of the pragma in the compilation
+unit. The purpose of such a pragma is to facilitate code validation.
+
+1.a
+ Discussion: Inspection points are a high level equivalent of
+ break points used by debuggers.
+
+ _Syntax_
+
+2
+ The form of a pragma Inspection_Point is as follows:
+
+3
+ pragma Inspection_Point[(object_name {, object_name})];
+
+ _Legality Rules_
+
+4
+A pragma Inspection_Point is allowed wherever a declarative_item or
+statement is allowed. Each object_name shall statically denote the
+declaration of an object.
+
+4.a
+ Discussion: The static denotation is required, since no
+ dynamic evaluation of a name is involved in this pragma.
+
+ _Static Semantics_
+
+5/2
+{8652/00938652/0093} {AI95-00207-01AI95-00207-01}
+{AI95-00434-01AI95-00434-01} An inspection point is a point in the
+object code corresponding to the occurrence of a pragma Inspection_Point
+in the compilation unit. An object is inspectable at an inspection
+point if the corresponding pragma Inspection_Point either has an
+argument denoting that object, or has no arguments and the declaration
+of the object is visible at the inspection point.
+
+5.a
+ Ramification: If a pragma Inspection_Point is in an in-lined
+ subprogram, there might be numerous inspection points in the
+ object code corresponding to the single occurrence of the
+ pragma in the source; similar considerations apply if such a
+ pragma is in a generic, or in a loop that has been "unrolled"
+ by an optimizer.
+
+5.a.1/1
+ {8652/00938652/0093} {AI95-00207-01AI95-00207-01} The short
+ form of the pragma is a convenient shorthand for listing all
+ objects which could be explicitly made inspectable by the long
+ form of the pragma; thus only visible objects are made
+ inspectable by it. Objects that are not visible at the point
+ of the pragma are not made inspectable by the short form
+ pragma. This is necessary so that implementations need not
+ keep information about (or prevent optimizations on) a unit
+ simply because some other unit might contain a short form
+ Inspection_Point pragma.
+
+5.b/1
+ Discussion: {8652/00938652/0093} {AI95-00207-01AI95-00207-01}
+ If the short form of the pragma is used, then all visible
+ objects are inspectable. This implies that global objects
+ from other compilation units are inspectable. A good
+ interactive debugging system could provide information similar
+ to a post-mortem dump at such inspection points. The annex
+ does not require that any inspection facility is provided,
+ merely that the information is available to understand the
+ state of the machine at those points.
+
+ _Dynamic Semantics_
+
+6
+Execution of a pragma Inspection_Point has no effect.
+
+6.a/2
+ Discussion: {AI95-00114-01AI95-00114-01} Although an
+ inspection point has no (semantic) effect, the removal or
+ adding of a new point could change the machine code generated
+ by the compiler.
+
+ _Implementation Requirements_
+
+7
+Reaching an inspection point is an external interaction with respect to
+the values of the inspectable objects at that point (see *note 1.1.3::).
+
+7.a
+ Ramification: The compiler is inhibited from moving an
+ assignment to an inspectable variable past an inspection point
+ for that variable. On the other hand, the evaluation of an
+ expression that might raise an exception may be moved past an
+ inspection point (see *note 11.6::).
+
+ _Documentation Requirements_
+
+8
+For each inspection point, the implementation shall identify a mapping
+between each inspectable object and the machine resources (such as
+memory locations or registers) from which the object's value can be
+obtained.
+
+8.a/2
+ This paragraph was deleted.
+
+8.b/2
+ Documentation Requirement: For each inspection point, a
+ mapping between each inspectable object and the machine
+ resources where the object's value can be obtained shall be
+ provided.
+
+ NOTES
+
+9/2
+ 7 {AI95-00209-01AI95-00209-01} The implementation is not allowed
+ to perform "dead store elimination" on the last assignment to a
+ variable prior to a point where the variable is inspectable. Thus
+ an inspection point has the effect of an implicit read of each of
+ its inspectable objects.
+
+10
+ 8 Inspection points are useful in maintaining a correspondence
+ between the state of the program in source code terms, and the
+ machine state during the program's execution. Assertions about the
+ values of program objects can be tested in machine terms at
+ inspection points. Object code between inspection points can be
+ processed by automated tools to verify programs mechanically.
+
+10.a
+ Discussion: Although it is not a requirement of the annex, it
+ would be useful if the state of the stack and heap could be
+ interrogated. This would allow users to check that a program
+ did not have a 'storage leak'.
+
+11
+ 9 The identification of the mapping from source program objects to
+ machine resources is allowed to be in the form of an annotated
+ object listing, in human-readable or tool-processable form.
+
+11.a
+ Discussion: In principle, it is easy to check an
+ implementation for this pragma, since one merely needs to
+ check the content of objects against those values known from
+ the source listing. In practice, one needs a tool similar to
+ an interactive debugger to perform the check.
+
+ _Wording Changes from Ada 95_
+
+11.b/2
+ {8652/00938652/0093} {AI95-00207-01AI95-00207-01} Corrigendum:
+ Corrected the definition of the Inspection_Point pragma to
+ apply to only variables visible at the point of the pragma.
+ Otherwise, the compiler would have to assume that some other
+ code somewhere could have a pragma Inspection_Point,
+ preventing many optimizations (such as unused object
+ elimination).
+
+\1f
+File: aarm2012.info, Node: H.4, Next: H.5, Prev: H.3, Up: Annex H
+
+H.4 High Integrity Restrictions
+===============================
+
+1/3
+{AI05-0299-1AI05-0299-1} This subclause defines restrictions that can be
+used with pragma Restrictions (see *note 13.12::); these facilitate the
+demonstration of program correctness by allowing tailored versions of
+the run-time system.
+
+1.a/3
+ Discussion: {AI05-0005-1AI05-0005-1} Note that the
+ restrictions are absolute. If a partition has 100 library
+ units and just one needs Unchecked_Conversion, then the pragma
+ cannot be used to ensure the other 99 units do not use
+ Unchecked_Conversion. Note also that these are restrictions
+ on all Ada code within a partition, and therefore it might not
+ be evident from the specification of a package whether a
+ restriction can be imposed.
+
+ _Static Semantics_
+
+2/2
+This paragraph was deleted.{AI95-00347-01AI95-00347-01}
+{AI95-00394-01AI95-00394-01}
+
+3/2
+{AI95-00394-01AI95-00394-01} The following restriction_identifiers are
+language defined:
+
+4
+Tasking-related restriction:
+
+5
+No_Protected_Types
+ There are no declarations of protected types or protected
+ objects.
+
+6
+Memory-management related restrictions:
+
+7
+No_Allocators
+ There are no occurrences of an allocator.
+
+8/1
+{8652/00428652/0042} {AI95-00130AI95-00130} No_Local_Allocators
+ Allocators are prohibited in subprograms, generic
+ subprograms, tasks, and entry bodies.
+
+8.a
+ Ramification: Thus allocators are permitted only in
+ expressions whose evaluation can only be performed before the
+ main subprogram is invoked.
+
+8.b/1
+ This paragraph was deleted.{8652/00428652/0042}
+ {AI95-00130AI95-00130}
+
+8.1/3
+{AI05-0152-1AI05-0152-1} {AI05-0262-1AI05-0262-1}
+No_Anonymous_Allocators
+ There are no allocators of anonymous access types.
+
+8.2/3
+{AI05-0190-1AI05-0190-1} No_Coextensions
+ There are no coextensions. See *note 3.10.2::.
+
+8.3/3
+{AI05-0190-1AI05-0190-1} No_Access_Parameter_Allocators
+ Allocators are not permitted as the actual parameter to
+ an access parameter. See *note 6.1::.
+
+9/2
+
+ This paragraph was deleted.{AI95-00394-01AI95-00394-01}
+
+10
+Immediate_Reclamation
+ Except for storage occupied by objects created by
+ allocators and not deallocated via unchecked
+ deallocation, any storage reserved at run time for an
+ object is immediately reclaimed when the object no longer
+ exists.
+
+10.a
+ Discussion: Immediate reclamation would apply to storage
+ created by the compiler, such as for a return value from a
+ function whose size is not known at the call site.
+
+11
+Exception-related restriction:
+
+12
+No_Exceptions
+ Raise_statements and exception_handlers are not allowed.
+ No language-defined run-time checks are generated;
+ however, a run-time check performed automatically by the
+ hardware is permitted.
+
+12.a
+ Discussion: This restriction mirrors a method of working that
+ is quite common in the safety area. The programmer is
+ required to show that exceptions cannot be raised. Then a
+ simplified run-time system is used without exception handling.
+ However, some hardware checks may still be enforced. If the
+ software check would have failed, or if the hardware check
+ actually fails, then the execution of the program is
+ unpredictable. There are obvious dangers in this approach,
+ but it is similar to programming at the assembler level.
+
+13
+Other restrictions:
+
+14
+No_Floating_Point
+ Uses of predefined floating point types and operations,
+ and declarations of new floating point types, are not
+ allowed.
+
+14.a/2
+ Discussion: {AI95-00114-01AI95-00114-01} The intention is to
+ avoid the use of floating point hardware at run time, but this
+ is expressed in language terms. It is conceivable that
+ floating point is used implicitly in some contexts, say fixed
+ point type conversions of high accuracy. However, the
+ Implementation Requirements below make it clear that the
+ restriction would apply to the "run-time system" and hence not
+ be allowed. This restriction could be used to inform a
+ compiler that a variant of the architecture is being used
+ which does not have floating point instructions.
+
+15
+No_Fixed_Point
+ Uses of predefined fixed point types and operations, and
+ declarations of new fixed point types, are not allowed.
+
+15.a
+ Discussion: This restriction would have the side effect of
+ prohibiting the delay_relative_statement. As with the
+ No_Floating_Point restriction, this might be used to avoid any
+ question of rounding errors. Unless an Ada run-time is
+ written in Ada, it seems hard to rule out implicit use of
+ fixed point, since at the machine level, fixed point is
+ virtually the same as integer arithmetic.
+
+16/2
+
+ This paragraph was deleted.{AI95-00394-01AI95-00394-01}
+
+17
+No_Access_Subprograms
+ The declaration of access-to-subprogram types is not
+ allowed.
+
+17.a.1/2
+ Discussion: Most critical applications would require some
+ restrictions or additional validation checks on uses of
+ access-to-subprogram types. If the application does not
+ require the functionality, then this restriction provides a
+ means of ensuring the design requirement has been satisfied.
+ The same applies to several of the following restrictions, and
+ to restriction No_Dependence => Ada.Unchecked_Conversion.
+
+18
+No_Unchecked_Access
+ The Unchecked_Access attribute is not allowed.
+
+19
+No_Dispatch
+ Occurrences of T'Class are not allowed, for any (tagged)
+ subtype T.
+
+20/2
+{AI95-00285-01AI95-00285-01} No_IO
+ Semantic dependence on any of the library units
+ Sequential_IO, Direct_IO, Text_IO, Wide_Text_IO,
+ Wide_Wide_Text_IO, or Stream_IO is not allowed.
+
+20.a
+ Discussion: Excluding the input-output facilities of an
+ implementation may be needed in those environments which
+ cannot support the supplied functionality. A program in such
+ an environment is likely to require some low level facilities
+ or a call on a non-Ada feature.
+
+21
+No_Delay
+ Delay_Statements and semantic dependence on package
+ Calendar are not allowed.
+
+21.a
+ Ramification: This implies that delay_alternatives in a
+ select_statement are prohibited.
+
+21.b
+ The purpose of this restriction is to avoid the need for
+ timing facilities within the run-time system.
+
+22
+No_Recursion
+ As part of the execution of a subprogram, the same
+ subprogram is not invoked.
+
+23
+No_Reentrancy
+ During the execution of a subprogram by a task, no other
+ task invokes the same subprogram.
+
+ _Implementation Requirements_
+
+23.1/2
+{AI95-00394-01AI95-00394-01} An implementation of this Annex shall
+support:
+
+23.2/2
+ * the restrictions defined in this subclause; and
+
+23.3/3
+ * {AI05-0189-1AI05-0189-1} the following restrictions defined in
+ *note D.7::: No_Task_Hierarchy, No_Abort_Statement,
+ No_Implicit_Heap_Allocation,
+ No_Standard_Allocators_After_Elaboration; and
+
+23.4/2
+ * {AI95-00347-01AI95-00347-01} the pragma Profile(Ravenscar); and
+
+23.a/2
+ Discussion: {AI95-00347-01AI95-00347-01} The reference to
+ pragma Profile(Ravenscar) is intended to show that properly
+ restricted tasking is appropriate for use in high integrity
+ systems. The Ada 95 Annex seemed to suggest that tasking was
+ inappropriate for such systems.
+
+23.5/2
+ * the following uses of restriction_parameter_identifiers defined in
+ *note D.7::[, which are checked prior to program execution]:
+
+23.6/2
+ * Max_Task_Entries => 0,
+
+23.7/2
+ * Max_Asynchronous_Select_Nesting => 0, and
+
+23.8/2
+ * Max_Tasks => 0.
+
+24/3
+{AI05-0263-1AI05-0263-1} {AI05-0272-1AI05-0272-1} If an implementation
+supports pragma Restrictions for a particular argument, then except for
+the restrictions No_Unchecked_Deallocation, No_Unchecked_Conversion,
+No_Access_Subprograms, No_Unchecked_Access, No_Specification_of_Aspect,
+No_Use_of_Attribute, No_Use_of_Pragma, and the equivalent use of
+No_Dependence, the associated restriction applies to the run-time
+system.
+
+24.a
+ Reason: Permission is granted for the run-time system to use
+ the specified otherwise-restricted features, since the use of
+ these features may simplify the run-time system by allowing
+ more of it to be written in Ada.
+
+24.b
+ Discussion: The restrictions that are applied to the partition
+ are also applied to the run-time system. For example, if
+ No_Floating_Point is specified, then an implementation that
+ uses floating point for implementing the delay statement (say)
+ would require that No_Floating_Point is only used in
+ conjunction with No_Delay. It is clearly important that
+ restrictions are effective so that Max_Tasks=0 does imply that
+ tasking is not used, even implicitly (for input-output, say).
+
+24.c
+ An implementation of tasking could be produced based upon a
+ run-time system written in Ada in which the rendezvous was
+ controlled by protected types. In this case,
+ No_Protected_Types could only be used in conjunction with
+ Max_Task_Entries=0. Other implementation dependencies could
+ be envisaged.
+
+24.d
+ If the run-time system is not written in Ada, then the wording
+ needs to be applied in an appropriate fashion.
+
+24.e/3
+ {AI05-0263-1AI05-0263-1} "the equivalent use of No_Dependence"
+ refers to No_Dependence => Ada.Unchecked_Conversion and the
+ like, not all uses of No_Dependence.
+
+ _Documentation Requirements_
+
+25
+If a pragma Restrictions(No_Exceptions) is specified, the implementation
+shall document the effects of all constructs where language-defined
+checks are still performed automatically (for example, an overflow check
+performed by the processor).
+
+25.a/2
+ This paragraph was deleted.
+
+25.b/2
+ Documentation Requirement: If a pragma
+ Restrictions(No_Exceptions) is specified, the effects of all
+ constructs where language-defined checks are still performed.
+
+25.c/2
+ Discussion: {AI95-00114-01AI95-00114-01} The documentation
+ requirements here are quite difficult to satisfy. One method
+ is to review the object code generated and determine the
+ checks that are still present, either explicitly, or
+ implicitly within the architecture. As another example from
+ that of overflow, consider the question of dereferencing a
+ null pointer. This could be undertaken by a memory access
+ trap when checks are performed. When checks are suppressed
+ via the argument No_Exceptions, it would not be necessary to
+ have the memory access trap mechanism enabled.
+
+ _Erroneous Execution_
+
+26
+Program execution is erroneous if pragma Restrictions(No_Exceptions) has
+been specified and the conditions arise under which a generated
+language-defined run-time check would fail.
+
+26.a
+ Discussion: The situation here is very similar to the
+ application of pragma Suppress. Since users are removing some
+ of the protection the language provides, they had better be
+ careful!
+
+27
+Program execution is erroneous if pragma Restrictions(No_Recursion) has
+been specified and a subprogram is invoked as part of its own execution,
+or if pragma Restrictions(No_Reentrancy) has been specified and during
+the execution of a subprogram by a task, another task invokes the same
+subprogram.
+
+27.a/3
+ Discussion: {AI05-0005-1AI05-0005-1} In practice, many
+ implementations might not exploit the absence of recursion or
+ need for reentrancy, in which case the program execution would
+ be unaffected by the use of recursion or reentrancy, even
+ though the program is still formally erroneous.
+
+27.b/2
+ This paragraph was deleted.
+
+ NOTES
+
+28/2
+ 10 {AI95-00394-01AI95-00394-01} Uses of
+ restriction_parameter_identifier No_Dependence defined in *note
+ 13.12.1::: No_Dependence => Ada.Unchecked_Deallocation and
+ No_Dependence => Ada.Unchecked_Conversion may be appropriate for
+ high-integrity systems. Other uses of No_Dependence can also be
+ appropriate for high-integrity systems.
+
+28.a/2
+ Discussion: The specific mention of these two uses is meant to
+ replace the identifiers now banished to *note J.13::, "*note
+ J.13:: Dependence Restriction Identifiers".
+
+28.b/2
+ Restriction No_Dependence => Ada.Unchecked_Deallocation would
+ be useful in those contexts in which heap storage is needed on
+ program start-up, but need not be increased subsequently. The
+ danger of a dangling pointer can therefore be avoided.
+
+ _Extensions to Ada 95_
+
+28.c/2
+ {8652/00428652/0042} {AI95-00130-01AI95-00130-01}
+ No_Local_Allocators no longer prohibits generic
+ instantiations.
+
+ _Wording Changes from Ada 95_
+
+28.d/2
+ {AI95-00285-01AI95-00285-01} Wide_Wide_Text_IO (which is new)
+ is added to the No_IO restriction.
+
+28.e/3
+ {AI95-00347-01AI95-00347-01} {AI05-0299-1AI05-0299-1} The
+ title of this subclause was changed to match the change to the
+ Annex title. Pragma Profile(Ravenscar) is part of this annex.
+
+28.f/2
+ {AI95-00394-01AI95-00394-01} Restriction No_Dependence is used
+ instead of special restriction_identifiers. The old names are
+ banished to Obsolescent Features (see *note J.13::).
+
+28.g/2
+ {AI95-00394-01AI95-00394-01} The bizarre wording "apply in
+ this Annex" (which no one quite can explain the meaning of) is
+ banished.
+
+ _Extensions to Ada 2005_
+
+28.h/3
+ {AI05-0152-1AI05-0152-1} {AI05-0190-1AI05-0190-1} Restrictions
+ No_Anonymous_Allocators, No_Coextensions, and
+ No_Access_Parameter_Allocators are new.
+
+ _Wording Changes from Ada 2005_
+
+28.i/3
+ {AI05-0189-1AI05-0189-1} New restriction
+ No_Standard_Allocators_After_Elaboration is added to the list
+ of restrictions that are required by this annex.
+
+28.j/3
+ {AI05-0263-1AI05-0263-1} Correction: Ada 2005 restriction
+ No_Dependence is added where needed (this was missed in Ada
+ 2005).
+
+28.k/3
+ {AI05-0272-1AI05-0272-1} Restrictions against individual
+ aspects, pragmas, and attributes do not apply to the run-time
+ system, in order that an implementation can use whatever
+ aspects, pragmas, and attributes are needed to do the job.
+ For instance, attempting to write a run-time system for Linux
+ that does not use the Import aspect would be very difficult
+ and probably is not what the user is trying to prevent anyway.
+
+\1f
+File: aarm2012.info, Node: H.5, Next: H.6, Prev: H.4, Up: Annex H
+
+H.5 Pragma Detect_Blocking
+==========================
+
+1/2
+{AI95-00305-01AI95-00305-01} The following pragma forces an
+implementation to detect potentially blocking operations within a
+protected operation.
+
+ _Syntax_
+
+2/2
+ {AI95-00305-01AI95-00305-01} The form of a pragma Detect_Blocking
+ is as follows:
+
+3/2
+ pragma Detect_Blocking;
+
+ _Post-Compilation Rules_
+
+4/2
+{AI95-00305-01AI95-00305-01} A pragma Detect_Blocking is a configuration
+pragma.
+
+ _Dynamic Semantics_
+
+5/2
+{AI95-00305-01AI95-00305-01} An implementation is required to detect a
+potentially blocking operation within a protected operation, and to
+raise Program_Error (see *note 9.5.1::).
+
+ _Implementation Permissions_
+
+6/2
+{AI95-00305-01AI95-00305-01} An implementation is allowed to reject a
+compilation_unit if a potentially blocking operation is present directly
+within an entry_body or the body of a protected subprogram.
+
+ NOTES
+
+7/2
+ 11 {AI95-00305-01AI95-00305-01} An operation that causes a task to
+ be blocked within a foreign language domain is not defined to be
+ potentially blocking, and need not be detected.
+
+ _Extensions to Ada 95_
+
+7.a/2
+ {AI95-00305-01AI95-00305-01} Pragma Detect_Blocking is new.
+
+\1f
+File: aarm2012.info, Node: H.6, Prev: H.5, Up: Annex H
+
+H.6 Pragma Partition_Elaboration_Policy
+=======================================
+
+1/3
+{AI95-00265-01AI95-00265-01} {AI05-0299-1AI05-0299-1} This subclause
+defines a pragma for user control over elaboration policy.
+
+ _Syntax_
+
+2/2
+ {AI95-00265-01AI95-00265-01} The form of a pragma
+ Partition_Elaboration_Policy is as follows:
+
+3/2
+ pragma Partition_Elaboration_Policy (policy_identifier);
+
+4/2
+ The policy_identifier shall be either Sequential, Concurrent or an
+ implementation-defined identifier.
+
+4.a/2
+ Implementation defined: Implementation-defined
+ policy_identifiers allowed in a pragma
+ Partition_Elaboration_Policy.
+
+4.b/3
+ Ramification: Note that the Ravenscar profile (see *note
+ D.13::) has nothing to say about which
+ Partition_Elaboration_Policy is used. This was intentionally
+ omitted from the profile, as there was no agreement as to
+ whether the Sequential policy should be required for Ravenscar
+ programs. As such it was defined separately.
+
+ _Post-Compilation Rules_
+
+5/2
+{AI95-00265-01AI95-00265-01} A pragma Partition_Elaboration_Policy is a
+configuration pragma. It specifies the elaboration policy for a
+partition. At most one elaboration policy shall be specified for a
+partition.
+
+6/3
+{AI95-00265-01AI95-00265-01} {AI05-0264-1AI05-0264-1} If the Sequential
+policy is specified for a partition, then pragma Restrictions
+(No_Task_Hierarchy) shall also be specified for the partition.
+
+ _Dynamic Semantics_
+
+7/2
+{AI95-00265-01AI95-00265-01} Notwithstanding what this International
+Standard says elsewhere, this pragma allows partition elaboration rules
+concerning task activation and interrupt attachment to be changed. If
+the policy_identifier is Concurrent, or if there is no pragma
+Partition_Elaboration_Policy defined for the partition, then the rules
+defined elsewhere in this Standard apply.
+
+8/2
+{AI95-00265-01AI95-00265-01} {AI95-00421-01AI95-00421-01} If the
+partition elaboration policy is Sequential, then task activation and
+interrupt attachment are performed in the following sequence of steps:
+
+9/2
+ * The activation of all library-level tasks and the attachment of
+ interrupt handlers are deferred until all library units are
+ elaborated.
+
+10/2
+ * The interrupt handlers are attached by the environment task.
+
+11/2
+ * The environment task is suspended while the library-level tasks are
+ activated.
+
+12/2
+ * The environment task executes the main subprogram (if any)
+ concurrently with these executing tasks.
+
+13/2
+{AI95-00265-01AI95-00265-01} {AI95-00421-01AI95-00421-01} If several
+dynamic interrupt handler attachments for the same interrupt are
+deferred, then the most recent call of Attach_Handler or
+Exchange_Handler determines which handler is attached.
+
+14/2
+{AI95-00265-01AI95-00265-01} {AI95-00421-01AI95-00421-01} If any
+deferred task activation fails, Tasking_Error is raised at the beginning
+of the sequence of statements of the body of the environment task prior
+to calling the main subprogram.
+
+ _Implementation Advice_
+
+15/3
+{AI95-00265-01AI95-00265-01} {AI05-0264-1AI05-0264-1} If the partition
+elaboration policy is Sequential and the Environment task becomes
+permanently blocked during elaboration, then the partition is deadlocked
+and it is recommended that the partition be immediately terminated.
+
+15.a/3
+ Implementation Advice: If the partition elaboration policy is
+ Sequential and the Environment task becomes permanently
+ blocked during elaboration, then the partition should be
+ immediately terminated.
+
+ _Implementation Permissions_
+
+16/3
+{AI95-00265-01AI95-00265-01} {AI05-0264-1AI05-0264-1} If the partition
+elaboration policy is Sequential and any task activation fails, then an
+implementation may immediately terminate the active partition to
+mitigate the hazard posed by continuing to execute with a subset of the
+tasks being active.
+
+ NOTES
+
+17/2
+ 12 {AI95-00421-01AI95-00421-01} If any deferred task activation
+ fails, the environment task is unable to handle the Tasking_Error
+ exception and completes immediately. By contrast, if the partition
+ elaboration policy is Concurrent, then this exception could be
+ handled within a library unit.
+
+ _Extensions to Ada 95_
+
+17.a/2
+ {AI95-00265-01AI95-00265-01} {AI95-00421-01AI95-00421-01}
+ Pragma Partition_Elaboration_Policy is new.
+
+\1f
+File: aarm2012.info, Node: Annex J, Next: Annex K, Prev: Annex H, Up: Top
+
+Annex J Obsolescent Features
+****************************
+
+1/2
+{AI95-00368-01AI95-00368-01} [ This Annex contains descriptions of
+features of the language whose functionality is largely redundant with
+other features defined by this International Standard. Use of these
+features is not recommended in newly written programs. Use of these
+features can be prevented by using pragma Restrictions
+(No_Obsolescent_Features), see *note 13.12.1::.]
+
+1.a
+ Ramification: These features are still part of the language,
+ and have to be implemented by conforming implementations. The
+ primary reason for putting these descriptions here is to get
+ redundant features out of the way of most readers. The
+ designers of the next version of Ada will have to assess
+ whether or not it makes sense to drop these features from the
+ language.
+
+ _Wording Changes from Ada 83_
+
+1.b
+ The following features have been removed from the language,
+ rather than declared to be obsolescent:
+
+1.c
+ * The package Low_Level_IO (see *note A.6::).
+
+1.d
+ * The Epsilon, Mantissa, Emax, Small, Large, Safe_Emax,
+ Safe_Small, and Safe_Large attributes of floating point
+ types (see *note A.5.3::).
+
+1.e/2
+ * This paragraph was deleted.{AI95-00284-02AI95-00284-02}
+
+1.f
+ * The pragmas System_Name, Storage_Unit, and Memory_Size
+ (see *note 13.7::).
+
+1.g
+ * The pragma Shared (see *note C.6::).
+
+1.h
+ Implementations can continue to support the above features for
+ upward compatibility.
+
+ _Wording Changes from Ada 95_
+
+1.i/2
+ {AI95-00368-01AI95-00368-01} A mention of the
+ No_Obsolescent_Features restriction was added.
+
+ _Wording Changes from Ada 2005_
+
+1.j/3
+ {AI05-0229-1AI05-0229-1} Pragma Controlled has been removed
+ from the language, rather than declared to be obsolescent. No
+ existing implementation gives it any effect. An
+ implementation could continue to support the pragma as an
+ implementation-defined pragma for upward compatibility.
+
+* Menu:
+
+* J.1 :: Renamings of Library Units
+* J.2 :: Allowed Replacements of Characters
+* J.3 :: Reduced Accuracy Subtypes
+* J.4 :: The Constrained Attribute
+* J.5 :: ASCII
+* J.6 :: Numeric_Error
+* J.7 :: At Clauses
+* J.8 :: Mod Clauses
+* J.9 :: The Storage_Size Attribute
+* J.10 :: Specific Suppression of Checks
+* J.11 :: The Class Attribute of Untagged Incomplete Types
+* J.12 :: Pragma Interface
+* J.13 :: Dependence Restriction Identifiers
+* J.14 :: Character and Wide_Character Conversion Functions
+* J.15 :: Aspect-related Pragmas
+
+\1f
+File: aarm2012.info, Node: J.1, Next: J.2, Up: Annex J
+
+J.1 Renamings of Library Units
+==============================
+
+ _Static Semantics_
+
+1
+The following library_unit_renaming_declarations exist:
+
+2
+ with Ada.Unchecked_Conversion;
+ generic function Unchecked_Conversion renames Ada.Unchecked_Conversion;
+
+3
+ with Ada.Unchecked_Deallocation;
+ generic procedure Unchecked_Deallocation renames Ada.Unchecked_Deallocation;
+
+4
+ with Ada.Sequential_IO;
+ generic package Sequential_IO renames Ada.Sequential_IO;
+
+5
+ with Ada.Direct_IO;
+ generic package Direct_IO renames Ada.Direct_IO;
+
+6
+ with Ada.Text_IO;
+ package Text_IO renames Ada.Text_IO;
+
+7
+ with Ada.IO_Exceptions;
+ package IO_Exceptions renames Ada.IO_Exceptions;
+
+8
+ with Ada.Calendar;
+ package Calendar renames Ada.Calendar;
+
+9
+ with System.Machine_Code;
+ package Machine_Code renames System.Machine_Code; -- If supported.
+
+9.a/3
+ Discussion: {AI05-0004-1AI05-0004-1} These library units
+ correspond to those declared in Ada 83, which did not have the
+ child unit concept or the parent package Ada.
+
+ _Implementation Requirements_
+
+10
+The implementation shall allow the user to replace these renamings.
+
+\1f
+File: aarm2012.info, Node: J.2, Next: J.3, Prev: J.1, Up: Annex J
+
+J.2 Allowed Replacements of Characters
+======================================
+
+ _Syntax_
+
+1
+ The following replacements are allowed for the vertical line,
+ number sign, and quotation mark characters:
+
+2
+ * A vertical line character (|) can be replaced by an
+ exclamation mark (!) where used as a delimiter.
+
+3
+ * The number sign characters (#) of a based_literal can be
+ replaced by colons (:) provided that the replacement is done
+ for both occurrences.
+
+3.a/2
+ To be honest: {AI95-00285-01AI95-00285-01} The intent is that
+ such a replacement works in the Value, Wide_Value, and
+ Wide_Wide_Value attributes, and in the Get procedures of
+ Text_IO (and Wide_Text_IO and Wide_Wide_Text_IO as well)}, so
+ that things like "16:.123:" is acceptable.
+
+4
+ * The quotation marks (") used as string brackets at both ends
+ of a string literal can be replaced by percent signs (%)
+ provided that the enclosed sequence of characters contains no
+ quotation mark, and provided that both string brackets are
+ replaced. Any percent sign within the sequence of characters
+ shall then be doubled and each such doubled percent sign is
+ interpreted as a single percent sign character value.
+
+5
+ These replacements do not change the meaning of the program.
+
+5.a
+ Reason: The original purpose of this feature was to support
+ hardware (for example, teletype machines) that has long been
+ obsolete. The feature is no longer necessary for that reason.
+ Another use of the feature has been to replace the vertical
+ line character (|) when using certain hardware that treats
+ that character as a (non-English) letter. The feature is no
+ longer necessary for that reason, either, since Ada 95 has
+ full support for international character sets. Therefore, we
+ believe this feature is no longer necessary.
+
+5.b
+ Users of equipment that still uses | to represent a letter
+ will continue to do so. Perhaps by next the time Ada is
+ revised, such equipment will no longer be in use.
+
+5.c
+ Note that it was never legal to use this feature as a
+ convenient method of including double quotes in a string
+ without doubling them -- the string literal:
+
+5.d
+ %"This is quoted."%
+
+5.e/3
+ {AI05-0248-1AI05-0248-1} is not legal in Ada (and never was
+ legal). One has to write:
+
+5.f
+ """This is quoted."""
+
+\1f
+File: aarm2012.info, Node: J.3, Next: J.4, Prev: J.2, Up: Annex J
+
+J.3 Reduced Accuracy Subtypes
+=============================
+
+1
+A digits_constraint may be used to define a floating point subtype with
+a new value for its requested decimal precision, as reflected by its
+Digits attribute. Similarly, a delta_constraint may be used to define
+an ordinary fixed point subtype with a new value for its delta, as
+reflected by its Delta attribute.
+
+1.a
+ Discussion: It might be more direct to make these attributes
+ specifiable via an attribute_definition_clause, and eliminate
+ the syntax for these _constraints.
+
+ _Syntax_
+
+2
+ delta_constraint ::= delta static_expression [range_constraint]
+
+ _Name Resolution Rules_
+
+3
+The expression of a delta_constraint is expected to be of any real type.
+
+ _Legality Rules_
+
+4
+The expression of a delta_constraint shall be static.
+
+5
+For a subtype_indication with a delta_constraint, the subtype_mark shall
+denote an ordinary fixed point subtype.
+
+6
+For a subtype_indication with a digits_constraint, the subtype_mark
+shall denote either a decimal fixed point subtype or a floating point
+subtype (notwithstanding the rule given in *note 3.5.9:: that only
+allows a decimal fixed point subtype).
+
+6.a/2
+ This paragraph was deleted.{AI95-00114-01AI95-00114-01}
+
+ _Static Semantics_
+
+7
+A subtype_indication with a subtype_mark that denotes an ordinary fixed
+point subtype and a delta_constraint defines an ordinary fixed point
+subtype with a delta given by the value of the expression of the
+delta_constraint. If the delta_constraint includes a range_constraint
+(*note 3.5: S0036.), then the ordinary fixed point subtype is
+constrained by the range_constraint (*note 3.5: S0036.).
+
+8
+A subtype_indication with a subtype_mark that denotes a floating point
+subtype and a digits_constraint defines a floating point subtype with a
+requested decimal precision (as reflected by its Digits attribute) given
+by the value of the expression of the digits_constraint. If the
+digits_constraint includes a range_constraint (*note 3.5: S0036.), then
+the floating point subtype is constrained by the range_constraint (*note
+3.5: S0036.).
+
+ _Dynamic Semantics_
+
+9
+A delta_constraint is compatible with an ordinary fixed point subtype if
+the value of the expression is no less than the delta of the subtype,
+and the range_constraint, if any, is compatible with the subtype.
+
+10
+A digits_constraint is compatible with a floating point subtype if the
+value of the expression is no greater than the requested decimal
+precision of the subtype, and the range_constraint, if any, is
+compatible with the subtype.
+
+11
+The elaboration of a delta_constraint consists of the elaboration of the
+range_constraint, if any.
+
+11.a
+ Reason: A numeric subtype is considered "constrained" only if
+ a range constraint applies to it. The only effect of a
+ digits_constraint or a delta_constraint without a
+ range_constraint is to specify the value of the corresponding
+ Digits or Delta attribute in the new subtype. The set of
+ values of the subtype is not "constrained" in any way by such
+ _constraints.
+
+ _Wording Changes from Ada 83_
+
+11.b
+ In Ada 83, a delta_constraint is called a
+ fixed_point_constraint, and a digits_constraint is called a
+ floating_point_constraint. We have adopted other terms
+ because digits_constraints apply primarily to decimal fixed
+ point types now (they apply to floating point types only as an
+ obsolescent feature).
+
+\1f
+File: aarm2012.info, Node: J.4, Next: J.5, Prev: J.3, Up: Annex J
+
+J.4 The Constrained Attribute
+=============================
+
+ _Static Semantics_
+
+1
+For every private subtype S, the following attribute is defined:
+
+1.a
+ Discussion: This includes generic formal private subtypes.
+
+2
+S'Constrained
+ Yields the value False if S denotes an unconstrained
+ nonformal private subtype with discriminants; also yields
+ the value False if S denotes a generic formal private
+ subtype, and the associated actual subtype is either an
+ unconstrained subtype with discriminants or an
+ unconstrained array subtype; yields the value True
+ otherwise. The value of this attribute is of the
+ predefined subtype Boolean.
+
+2.a
+ Reason: Because Ada 95 has unknown_discriminant_parts, the
+ Constrained attribute of private subtypes is obsolete. This
+ is fortunate, since its Ada 83 definition was confusing, as
+ explained below. Because this attribute is obsolete, we do
+ not bother to extend its definition to private extensions.
+
+2.b
+ The Constrained attribute of an object is not obsolete.
+
+2.c
+ Note well: S'Constrained matches the Ada 95 definition of
+ "constrained" only for composite subtypes. For elementary
+ subtypes, S'Constrained is always true, whether or not S is
+ constrained. (The Constrained attribute of an object does not
+ have this problem, as it is only defined for objects of a
+ discriminated type.) So one should think of its designator as
+ being 'Constrained_Or_Elementary.
+
+\1f
+File: aarm2012.info, Node: J.5, Next: J.6, Prev: J.4, Up: Annex J
+
+J.5 ASCII
+=========
+
+ _Static Semantics_
+
+1
+The following declaration exists in the declaration of package Standard:
+
+2
+ package ASCII is
+
+3
+ -- Control characters:
+
+4
+ NUL : constant Character := nul; SOH : constant Character := soh;
+ STX : constant Character := stx; ETX : constant Character := etx;
+ EOT : constant Character := eot; ENQ : constant Character := enq;
+ ACK : constant Character := ack; BEL : constant Character := bel;
+ BS : constant Character := bs; HT : constant Character := ht;
+ LF : constant Character := lf; VT : constant Character := vt;
+ FF : constant Character := ff; CR : constant Character := cr;
+ SO : constant Character := so; SI : constant Character := si;
+ DLE : constant Character := dle; DC1 : constant Character := dc1;
+ DC2 : constant Character := dc2; DC3 : constant Character := dc3;
+ DC4 : constant Character := dc4; NAK : constant Character := nak;
+ SYN : constant Character := syn; ETB : constant Character := etb;
+ CAN : constant Character := can; EM : constant Character := em;
+ SUB : constant Character := sub; ESC : constant Character := esc;
+ FS : constant Character := fs; GS : constant Character := gs;
+ RS : constant Character := rs; US : constant Character := us;
+ DEL : constant Character := del;
+
+5
+ -- Other characters:
+
+6
+ Exclam : constant Character:= '!'; Quotation : constant Character:= '"';
+ Sharp : constant Character:= '#'; Dollar : constant Character:= '$';
+ Percent : constant Character:= '%'; Ampersand : constant Character:= '&';
+ Colon : constant Character:= ':'; Semicolon : constant Character:= ';';
+ Query : constant Character:= '?'; At_Sign : constant Character:= '@';
+ L_Bracket: constant Character:= '['; Back_Slash: constant Character:= '\';
+ R_Bracket: constant Character:= ']'; Circumflex: constant Character:= '^';
+ Underline: constant Character:= '_'; Grave : constant Character:= '`';
+ L_Brace : constant Character:= '{'; Bar : constant Character:= '|';
+ R_Brace : constant Character:= '}'; Tilde : constant Character:= '~';
+
+7
+ -- Lower case letters:
+
+8
+ LC_A: constant Character:= 'a';
+ ...
+ LC_Z: constant Character:= 'z';
+
+9
+ end ASCII;
+
+\1f
+File: aarm2012.info, Node: J.6, Next: J.7, Prev: J.5, Up: Annex J
+
+J.6 Numeric_Error
+=================
+
+ _Static Semantics_
+
+1
+The following declaration exists in the declaration of package Standard:
+
+2
+ Numeric_Error : exception renames Constraint_Error;
+
+2.a
+ Discussion: This is true even though it is not shown in *note
+ A.1::.
+
+2.b
+ Reason: In Ada 83, it was unclear which situations should
+ raise Numeric_Error, and which should raise Constraint_Error.
+ The permissions of RM83-11.6 could often be used to allow the
+ implementation to raise Constraint_Error in a situation where
+ one would normally expect Numeric_Error. To avoid this
+ confusion, all situations that raise Numeric_Error in Ada 83
+ are changed to raise Constraint_Error in Ada 95.
+ Numeric_Error is changed to be a renaming of Constraint_Error
+ to avoid most of the upward compatibilities associated with
+ this change.
+
+2.c
+ In new code, Constraint_Error should be used instead of
+ Numeric_Error.
+
+\1f
+File: aarm2012.info, Node: J.7, Next: J.8, Prev: J.6, Up: Annex J
+
+J.7 At Clauses
+==============
+
+ _Syntax_
+
+1
+ at_clause ::= for direct_name use at expression;
+
+ _Static Semantics_
+
+2
+An at_clause of the form "for x use at y;" is equivalent to an
+attribute_definition_clause of the form "for x'Address use y;".
+
+2.a
+ Reason: The preferred syntax for specifying the address of an
+ entity is an attribute_definition_clause specifying the
+ Address attribute. Therefore, the special-purpose at_clause
+ syntax is now obsolete.
+
+2.b
+ The above equivalence implies, for example, that only one
+ at_clause is allowed for a given entity. Similarly, it is
+ illegal to give both an at_clause and an
+ attribute_definition_clause specifying the Address attribute.
+
+ _Extensions to Ada 83_
+
+2.c
+ We now allow to define the address of an entity using an
+ attribute_definition_clause. This is because Ada 83's
+ at_clause is so hard to remember: programmers often tend to
+ write "for X'Address use...;".
+
+ _Wording Changes from Ada 83_
+
+2.d
+ Ada 83's address_clause is now called an at_clause to avoid
+ confusion with the new term "Address clause" (that is, an
+ attribute_definition_clause for the Address attribute).
+
+* Menu:
+
+* J.7.1 :: Interrupt Entries
+
+\1f
+File: aarm2012.info, Node: J.7.1, Up: J.7
+
+J.7.1 Interrupt Entries
+-----------------------
+
+1
+[Implementations are permitted to allow the attachment of task entries
+to interrupts via the address clause. Such an entry is referred to as
+an interrupt entry.
+
+2
+The address of the task entry corresponds to a hardware interrupt in an
+implementation-defined manner. (See Ada.Interrupts.Reference in *note
+C.3.2::.)]
+
+ _Static Semantics_
+
+3
+The following attribute is defined:
+
+4
+For any task entry X:
+
+5
+X'Address
+ For a task entry whose address is specified (an interrupt
+ entry), the value refers to the corresponding hardware
+ interrupt. For such an entry, as for any other task
+ entry, the meaning of this value is implementation
+ defined. The value of this attribute is of the type of
+ the subtype System.Address.
+
+6
+ Address may be specified for single entries via an
+ attribute_definition_clause.
+
+6.a
+ Reason: Because of the equivalence of at_clauses and
+ attribute_definition_clauses, an interrupt entry may be
+ specified via either notation.
+
+ _Dynamic Semantics_
+
+7
+As part of the initialization of a task object, the address clause for
+an interrupt entry is elaborated[, which evaluates the expression of the
+address clause]. A check is made that the address specified is
+associated with some interrupt to which a task entry may be attached.
+If this check fails, Program_Error is raised. Otherwise, the interrupt
+entry is attached to the interrupt associated with the specified
+address.
+
+8
+Upon finalization of the task object, the interrupt entry, if any, is
+detached from the corresponding interrupt and the default treatment is
+restored.
+
+9
+While an interrupt entry is attached to an interrupt, the interrupt is
+reserved (see *note C.3::).
+
+10
+An interrupt delivered to a task entry acts as a call to the entry
+issued by a hardware task whose priority is in the
+System.Interrupt_Priority range. It is implementation defined whether
+the call is performed as an ordinary entry call, a timed entry call, or
+a conditional entry call; which kind of call is performed can depend on
+the specific interrupt.
+
+ _Bounded (Run-Time) Errors_
+
+11
+It is a bounded error to evaluate E'Caller (see *note C.7.1::) in an
+accept_statement for an interrupt entry. The possible effects are the
+same as for calling Current_Task from an entry body.
+
+ _Documentation Requirements_
+
+12
+The implementation shall document to which interrupts a task entry may
+be attached.
+
+12.a/2
+ Documentation Requirement: The interrupts to which a task
+ entry may be attached.
+
+13
+The implementation shall document whether the invocation of an interrupt
+entry has the effect of an ordinary entry call, conditional call, or a
+timed call, and whether the effect varies in the presence of pending
+interrupts.
+
+13.a/2
+ Documentation Requirement: The type of entry call invoked for
+ an interrupt entry.
+
+ _Implementation Permissions_
+
+14
+The support for this subclause is optional.
+
+15
+Interrupts to which the implementation allows a task entry to be
+attached may be designated as reserved for the entire duration of
+program execution[; that is, not just when they have an interrupt entry
+attached to them].
+
+16/1
+{8652/00778652/0077} {AI95-00111-01AI95-00111-01} Interrupt entry calls
+may be implemented by having the hardware execute directly the
+appropriate accept_statement. Alternatively, the implementation is
+allowed to provide an internal interrupt handler to simulate the effect
+of a normal task calling the entry.
+
+17
+The implementation is allowed to impose restrictions on the
+specifications and bodies of tasks that have interrupt entries.
+
+18
+It is implementation defined whether direct calls (from the program) to
+interrupt entries are allowed.
+
+19
+If a select_statement contains both a terminate_alternative and an
+accept_alternative for an interrupt entry, then an implementation is
+allowed to impose further requirements for the selection of the
+terminate_alternative in addition to those given in *note 9.3::.
+
+ NOTES
+
+20/1
+ 1 {8652/00778652/0077} {AI95-00111-01AI95-00111-01} Queued
+ interrupts correspond to ordinary entry calls. Interrupts that are
+ lost if not immediately processed correspond to conditional entry
+ calls. It is a consequence of the priority rules that an
+ accept_statement executed in response to an interrupt can be
+ executed with the active priority at which the hardware generates
+ the interrupt, taking precedence over lower priority tasks, without
+ a scheduling action.
+
+21
+ 2 Control information that is supplied upon an interrupt can be
+ passed to an associated interrupt entry as one or more parameters
+ of mode in.
+
+ _Examples_
+
+22
+Example of an interrupt entry:
+
+23
+ task Interrupt_Handler is
+ entry Done;
+ for Done'Address use Ada.Interrupts.Reference(Ada.Interrupts.Names.Device_Done);
+ end Interrupt_Handler;
+
+ _Wording Changes from Ada 83_
+
+23.a/2
+ {AI95-00114-01AI95-00114-01} RM83-13.5.1 did not adequately
+ address the problems associated with interrupts. This feature
+ is now obsolescent and is replaced by the Ada 95 interrupt
+ model as specified in the Systems Programming Annex.
+
+ _Wording Changes from Ada 95_
+
+23.b/2
+ {8652/00778652/0077} {AI95-00111-01AI95-00111-01} Corrigendum:
+ The undefined term accept body was replaced by
+ accept_statement.
+
+\1f
+File: aarm2012.info, Node: J.8, Next: J.9, Prev: J.7, Up: Annex J
+
+J.8 Mod Clauses
+===============
+
+ _Syntax_
+
+1
+ mod_clause ::= at mod static_expression;
+
+ _Static Semantics_
+
+2
+A record_representation_clause of the form:
+
+3/3
+ {AI05-0092-1AI05-0092-1} for r use
+ record at mod a;
+ ...
+ end record;
+
+4
+is equivalent to:
+
+5
+ for r'Alignment use a;
+ for r use
+ record
+ ...
+ end record;
+
+5.a
+ Reason: The preferred syntax for specifying the alignment of
+ an entity is an attribute_definition_clause specifying the
+ Alignment attribute. Therefore, the special-purpose
+ mod_clause syntax is now obsolete.
+
+5.b
+ The above equivalence implies, for example, that it is illegal
+ to give both a mod_clause and an attribute_definition_clause
+ specifying the Alignment attribute for the same type.
+
+ _Wording Changes from Ada 83_
+
+5.c
+ Ada 83's alignment_clause is now called a mod_clause to avoid
+ confusion with the new term "Alignment clause" (that is, an
+ attribute_definition_clause for the Alignment attribute).
+
+\1f
+File: aarm2012.info, Node: J.9, Next: J.10, Prev: J.8, Up: Annex J
+
+J.9 The Storage_Size Attribute
+==============================
+
+ _Static Semantics_
+
+1
+For any task subtype T, the following attribute is defined:
+
+2
+T'Storage_Size
+ Denotes an implementation-defined value of type
+ universal_integer representing the number of storage
+ elements reserved for a task of the subtype T.
+
+2.a/3
+ To be honest: {AI05-0229-1AI05-0229-1} T'Storage_Size cannot
+ be particularly meaningful in the presence of the
+ specification of the aspect Storage_Size, especially when the
+ expression is dynamic, or depends on a discriminant of the
+ task, because the Storage_Size will be different for different
+ objects of the type. Even without such a specification, the
+ Storage_Size can be different for different objects of the
+ type, and in any case, the value is implementation defined.
+ Hence, it is always implementation defined.
+
+3/3
+ {AI95-00345-01AI95-00345-01} {AI05-0229-1AI05-0229-1}
+ Storage_Size may be specified for a task first subtype
+ that is not an interface via an
+ attribute_definition_clause. When the attribute is
+ specified, the Storage_Size aspect is specified to be the
+ value of the given expression.
+
+3.a/3
+ Ramification: {AI05-0229-1AI05-0229-1} When this attribute is
+ specified with an attribute_definition_clause, the associated
+ aspect is set to the value of the expression given in the
+ attribute_definition_clause, rather than the expression
+ itself. This value is therefore the same for all objects of
+ the type; in particular, it is not re-evaluated when objects
+ are created. This is different than when the aspect is
+ specified with an aspect_specification (see *note 13.3::).
+
+ _Wording Changes from Ada 95_
+
+3.b/2
+ {AI95-00345-01AI95-00345-01} We don't allow specifying
+ Storage_Size on task interfaces. We don't need to mention
+ class-wide task types, because these cannot be a first
+ subtype.
+
+\1f
+File: aarm2012.info, Node: J.10, Next: J.11, Prev: J.9, Up: Annex J
+
+J.10 Specific Suppression of Checks
+===================================
+
+1/2
+{AI95-00224-01AI95-00224-01} Pragma Suppress can be used to suppress
+checks on specific entities.
+
+ _Syntax_
+
+2/2
+ {AI95-00224-01AI95-00224-01} The form of a specific Suppress pragma
+ is as follows:
+
+3/2
+ pragma Suppress(identifier, [On =>] name);
+
+ _Legality Rules_
+
+4/2
+{AI95-00224-01AI95-00224-01} The identifier shall be the name of a check
+(see *note 11.5::). The name shall statically denote some entity.
+
+5/2
+{AI95-00224-01AI95-00224-01} For a specific Suppress pragma that is
+immediately within a package_specification, the name shall denote an
+entity (or several overloaded subprograms) declared immediately within
+the package_specification (*note 7.1: S0191.).
+
+ _Static Semantics_
+
+6/2
+{AI95-00224-01AI95-00224-01} A specific Suppress pragma applies to the
+named check from the place of the pragma to the end of the innermost
+enclosing declarative region, or, if the pragma is given in a
+package_specification, to the end of the scope of the named entity. The
+pragma applies only to the named entity, or, for a subtype, on objects
+and values of its type. A specific Suppress pragma suppresses the named
+check for any entities to which it applies (see *note 11.5::). Which
+checks are associated with a specific entity is not defined by this
+International Standard.
+
+6.a/2
+ Discussion: The language doesn't specify exactly which
+ entities control whether a check is performed. For example,
+ in
+
+6.b
+ pragma Suppress (Range_Check, On => A);
+ A := B;
+
+6.c
+ whether or not the range check is performed is not specified.
+ The compiler may require that checks are suppressed on B or on
+ the type of A in order to omit the range check.
+
+ _Implementation Permissions_
+
+7/2
+{AI95-00224-01AI95-00224-01} An implementation is allowed to place
+restrictions on specific Suppress pragmas.
+
+ NOTES
+
+8/2
+ 3 {AI95-00224-01AI95-00224-01} An implementation may support a
+ similar On parameter on pragma Unsuppress (see *note 11.5::).
+
+ _Wording Changes from Ada 95_
+
+8.a/3
+ {AI95-00224-01AI95-00224-01} {AI05-0299-1AI05-0299-1} This
+ subclause is new. This feature was moved here because it is
+ important for pragma Unsuppress that there be an unambiguous
+ meaning for each checking pragma. For instance, in the
+ example
+
+8.b
+ pragma Suppress (Range_Check);
+ pragma Unsuppress (Range_Check, On => A);
+ A := B;
+
+8.c
+ the user needs to be able to depend on the range check being
+ made on the assignment. But a compiler survey showed that the
+ interpretation of this feature varied widely; trying to define
+ this carefully was likely to cause a lot of user and
+ implementer pain. Thus the feature was moved here, to
+ emphasize that its use is not portable.
+
+\1f
+File: aarm2012.info, Node: J.11, Next: J.12, Prev: J.10, Up: Annex J
+
+J.11 The Class Attribute of Untagged Incomplete Types
+=====================================================
+
+ _Static Semantics_
+
+1/2
+{AI95-00326-01AI95-00326-01} For the first subtype S of a type T
+declared by an incomplete_type_declaration that is not tagged, the
+following attribute is defined:
+
+2/2
+{AI95-00326-01AI95-00326-01} S'Class
+ Denotes the first subtype of the incomplete class-wide
+ type rooted at T. The completion of T shall declare a
+ tagged type. Such an attribute reference shall occur in
+ the same library unit as the incomplete_type_declaration.
+
+2.a/2
+ Reason: {AI95-00326-01AI95-00326-01} This must occur in the
+ same unit to prevent children from imposing requirements on
+ their ancestor library units for deferred incomplete types.
+
+ _Wording Changes from Ada 95_
+
+2.b/3
+ {AI95-00326-01AI95-00326-01} {AI05-0299-1AI05-0299-1} This
+ subclause is new. This feature was moved here because the
+ tagged incomplete type provides a better way to provide this
+ capability (it doesn't put requirements on the completion
+ based on uses that could be anywhere). Pity we didn't think
+ of it in 1994.
+
+\1f
+File: aarm2012.info, Node: J.12, Next: J.13, Prev: J.11, Up: Annex J
+
+J.12 Pragma Interface
+=====================
+
+ _Syntax_
+
+1/2
+ {AI95-00284-02AI95-00284-02} In addition to an identifier, the
+ reserved word interface is allowed as a pragma name, to provide
+ compatibility with a prior edition of this International Standard.
+
+1.a/2
+ Implementation Note: {AI95-00284-02AI95-00284-02} All
+ implementations need to at least recognize and ignore this
+ pragma. A syntax error is not an acceptable implementation of
+ this pragma.
+
+ _Wording Changes from Ada 95_
+
+1.b/3
+ {AI95-00326-01AI95-00326-01} {AI05-0299-1AI05-0299-1} This
+ subclause is new. This is necessary as interface is now a
+ reserved word, which would prevent pragma Interface from being
+ an implementation-defined pragma. We don't define any
+ semantics for this pragma, as we expect that implementations
+ will continue to use whatever they currently implement -
+ requiring any changes would be counter-productive.
+
+\1f
+File: aarm2012.info, Node: J.13, Next: J.14, Prev: J.12, Up: Annex J
+
+J.13 Dependence Restriction Identifiers
+=======================================
+
+1/2
+{AI95-00394-01AI95-00394-01} The following restrictions involve
+dependence on specific language-defined units. The more general
+restriction No_Dependence (see *note 13.12.1::) should be used for this
+purpose.
+
+ _Static Semantics_
+
+2/2
+{AI95-00394-01AI95-00394-01} The following restriction_identifiers
+exist:
+
+3/2
+{AI95-00394-01AI95-00394-01} No_Asynchronous_Control
+ Semantic dependence on the predefined package
+ Asynchronous_Task_Control is not allowed.
+
+4/2
+{AI95-00394-01AI95-00394-01} No_Unchecked_Conversion
+ Semantic dependence on the predefined generic function
+ Unchecked_Conversion is not allowed.
+
+5/2
+{AI95-00394-01AI95-00394-01} No_Unchecked_Deallocation
+ Semantic dependence on the predefined generic procedure
+ Unchecked_Deallocation is not allowed.
+
+ _Wording Changes from Ada 95_
+
+5.a/3
+ {AI95-00394-01AI95-00394-01} {AI05-0299-1AI05-0299-1} This
+ subclause is new. These restrictions are replaced by the more
+ general No_Dependence (see *note 13.12.1::).
+
+\1f
+File: aarm2012.info, Node: J.14, Next: J.15, Prev: J.13, Up: Annex J
+
+J.14 Character and Wide_Character Conversion Functions
+======================================================
+
+ _Static Semantics_
+
+1/2
+{AI95-00395-01AI95-00395-01} The following declarations exist in the
+declaration of package Ada.Characters.Handling:
+
+2/2
+ function Is_Character (Item : in Wide_Character) return Boolean
+ renames Conversions.Is_Character;
+ function Is_String (Item : in Wide_String) return Boolean
+ renames Conversions.Is_String;
+
+3/2
+ function To_Character (Item : in Wide_Character;
+ Substitute : in Character := ' ')
+ return Character
+ renames Conversions.To_Character;
+
+4/2
+ function To_String (Item : in Wide_String;
+ Substitute : in Character := ' ')
+ return String
+ renames Conversions.To_String;
+
+5/2
+ function To_Wide_Character (Item : in Character) return Wide_Character
+ renames Conversions.To_Wide_Character;
+
+6/2
+ function To_Wide_String (Item : in String) return Wide_String
+ renames Conversions.To_Wide_String;
+
+ _Wording Changes from Ada 95_
+
+6.a/3
+ {AI95-00394-01AI95-00394-01} {AI05-0299-1AI05-0299-1} This
+ subclause is new. These subprograms were moved to
+ Characters.Conversions (see *note A.3.4::).
+
+\1f
+File: aarm2012.info, Node: J.15, Prev: J.14, Up: Annex J
+
+J.15 Aspect-related Pragmas
+===========================
+
+1/3
+{AI05-0229-1AI05-0229-1} Pragmas can be used as an alternative to
+aspect_specifications to specify certain aspects.
+
+ _Wording Changes from Ada 2005_
+
+1.a/3
+ {AI05-0229-1AI05-0229-1} {AI05-0299-1AI05-0299-1} This
+ subclause is new. Many existing pragmas have been converted
+ into aspects; the pragmas have moved here.
+
+* Menu:
+
+* J.15.1 :: Pragma Inline
+* J.15.2 :: Pragma No_Return
+* J.15.3 :: Pragma Pack
+* J.15.4 :: Pragma Storage_Size
+* J.15.5 :: Interfacing Pragmas
+* J.15.6 :: Pragma Unchecked_Union
+* J.15.7 :: Pragmas Interrupt_Handler and Attach_Handler
+* J.15.8 :: Shared Variable Pragmas
+* J.15.9 :: Pragma CPU
+* J.15.10 :: Pragma Dispatching_Domain
+* J.15.11 :: Pragmas Priority and Interrupt_Priority
+* J.15.12 :: Pragma Relative_Deadline
+* J.15.13 :: Pragma Asynchronous
+
+\1f
+File: aarm2012.info, Node: J.15.1, Next: J.15.2, Up: J.15
+
+J.15.1 Pragma Inline
+--------------------
+
+ _Syntax_
+
+1/3
+ {AI05-0229-1AI05-0229-1} The form of a pragma Inline, which is a
+ program unit pragma (see *note 10.1.5::), is as follows:
+
+2/3
+ pragma Inline (name{, name});
+
+ _Legality Rules_
+
+3/3
+{AI05-0229-1AI05-0229-1} The pragma shall apply to one or more callable
+entities or generic subprograms.
+
+ _Static Semantics_
+
+4/3
+{AI05-0229-1AI05-0229-1} Pragma Inline specifies that the Inline aspect
+(see *note 6.3.2::) for each entity denoted by each name given in the
+pragma has the value True.
+
+4.a/3
+ Ramification: Note that inline expansion is desired no matter
+ what name is used in the call. This allows one to request
+ inlining for only one of several overloaded subprograms as
+ follows:
+
+4.b/3
+ package IO is
+ procedure Put(X : in Integer);
+ procedure Put(X : in String);
+ procedure Put(X : in Character);
+ private
+ procedure Character_Put(X : in Character) renames Put;
+ pragma Inline(Character_Put);
+ end IO;
+
+4.c/3
+ with IO; use IO;
+ procedure Main is
+ I : Integer;
+ C : Character;
+ begin
+ ...
+ Put(C); -- Inline expansion is desired.
+ Put(I); -- Inline expansion is NOT desired.
+ end Main;
+
+ _Implementation Permissions_
+
+5/3
+{AI05-0229-1AI05-0229-1} An implementation may allow a pragma Inline
+that has an argument which is a direct_name denoting a subprogram_body
+of the same declarative_part.
+
+5.a/3
+ Reason: This is allowed for Ada 83 compatibility. This is
+ only a permission as this usage was considered obsolescent
+ even for Ada 95.
+
+5.b/3
+ Discussion: We only need to allow this in declarative_parts,
+ because a body is only allowed in another body, and these all
+ have declarative_parts.
+
+ NOTES
+
+6/3
+ 4 {AI05-0229-1AI05-0229-1} The name in a pragma Inline may denote
+ more than one entity in the case of overloading. Such a pragma
+ applies to all of the denoted entities.
+
+ _Incompatibilities With Ada 83_
+
+6.a/3
+ {AI95-00309-01AI95-00309-01} {AI05-0229-1AI05-0229-1} A pragma
+ Inline cannot refer to a subprogram_body outside of that body.
+ The pragma can be given inside of the subprogram body. Ada
+ 2005 adds an Implementation Permission to allow this usage for
+ compatibility (and Ada 95 implementations also can use this
+ permission), but implementations do not have to allow such
+ pragmas.
+
+ _Extensions to Ada 83_
+
+6.b/3
+ {AI05-0229-1AI05-0229-1} A pragma Inline is allowed inside a
+ subprogram_body if there is no corresponding
+ subprogram_declaration. This is for uniformity with other
+ program unit pragmas.
+
+ _Extensions to Ada 95_
+
+6.c/3
+ {AI95-00309-01AI95-00309-01} {AI05-0229-1AI05-0229-1}
+ Amendment Correction: Implementations are allowed to let
+ Pragma Inline apply to a subprogram_body.
+
+ _Wording Changes from Ada 2005_
+
+6.d/3
+ {AI05-0229-1AI05-0229-1} {AI05-0299-1AI05-0299-1} This
+ subclause is new. Pragma Inline was moved here from *note
+ 6.3.2::; aspect Inline lives there now.
+
+\1f
+File: aarm2012.info, Node: J.15.2, Next: J.15.3, Prev: J.15.1, Up: J.15
+
+J.15.2 Pragma No_Return
+-----------------------
+
+ _Syntax_
+
+1/3
+ {AI05-0229-1AI05-0229-1} The form of a pragma No_Return, which is a
+ representation pragma (see *note 13.1::), is as follows:
+
+2/3
+ pragma No_Return (procedure_local_name{, procedure_local_name});
+
+ _Legality Rules_
+
+3/3
+{AI05-0229-1AI05-0229-1} Each procedure_local_name shall denote one or
+more procedures or generic procedures. [The procedure_local_name shall
+not denote a null procedure nor an instance of a generic unit.]
+
+ _Static Semantics_
+
+4/3
+{AI05-0229-1AI05-0229-1} Pragma No_Return specifies that the No_Return
+aspect (see *note 6.5.1::) for each procedure denoted by each local_name
+given in the pragma has the value True.
+
+ _Wording Changes from Ada 2005_
+
+4.a/3
+ {AI05-0229-1AI05-0229-1} {AI05-0299-1AI05-0299-1} This
+ subclause is new. Pragma No_Return was moved here from *note
+ 6.5.1::; aspect No_Return lives there now.
+
+\1f
+File: aarm2012.info, Node: J.15.3, Next: J.15.4, Prev: J.15.2, Up: J.15
+
+J.15.3 Pragma Pack
+------------------
+
+ _Syntax_
+
+1/3
+ {AI05-0229-1AI05-0229-1} The form of a pragma Pack, which is a
+ representation pragma (see *note 13.1::), is as follows:
+
+2/3
+ pragma Pack (first_subtype_local_name);
+
+ _Legality Rules_
+
+3/3
+{AI05-0229-1AI05-0229-1} The first_subtype_local_name of a pragma Pack
+shall denote a composite subtype.
+
+ _Static Semantics_
+
+4/3
+{AI05-0229-1AI05-0229-1} Pragma Pack specifies that the Pack aspect (see
+*note 13.2::) for the type denoted by first_subtype_local_name has the
+value True.
+
+ _Wording Changes from Ada 2005_
+
+4.a/3
+ {AI05-0229-1AI05-0229-1} {AI05-0299-1AI05-0299-1} This
+ subclause is new. Pragma Pack was moved here from *note
+ 13.2::; aspect Pack lives there now.
+
+\1f
+File: aarm2012.info, Node: J.15.4, Next: J.15.5, Prev: J.15.3, Up: J.15
+
+J.15.4 Pragma Storage_Size
+--------------------------
+
+ _Syntax_
+
+1/3
+ {AI05-0229-1AI05-0229-1} The form of a pragma Storage_Size is as
+ follows:
+
+2/3
+ pragma Storage_Size (expression);
+
+3/3
+ {AI05-0229-1AI05-0229-1} A pragma Storage_Size is allowed only
+ immediately within a task_definition.
+
+ _Name Resolution Rules_
+
+4/3
+{AI05-0229-1AI05-0229-1} The expression of a pragma Storage_Size is
+expected to be of any integer type.
+
+ _Static Semantics_
+
+5/3
+{AI05-0229-1AI05-0229-1} The pragma Storage_Size sets the Storage_Size
+aspect (see *note 13.3::) of the type defined by the immediately
+enclosing task_definition to the value of the expression of the pragma.
+
+ _Wording Changes from Ada 2005_
+
+5.a/3
+ {AI05-0229-1AI05-0229-1} {AI05-0299-1AI05-0299-1} This
+ subclause is new. Pragma Storage_Size was moved here from
+ *note 13.3::; aspect Storage_Size lives there now.
+
+\1f
+File: aarm2012.info, Node: J.15.5, Next: J.15.6, Prev: J.15.4, Up: J.15
+
+J.15.5 Interfacing Pragmas
+--------------------------
+
+ _Syntax_
+
+1/3
+ {AI05-0229-1AI05-0229-1} An interfacing pragma is a representation
+ pragma that is one of the pragmas Import, Export, or Convention.
+ Their forms are as follows:
+
+2/3
+ pragma Import(
+ [Convention =>] convention_identifier, [Entity =>] local_name
+ [, [External_Name =>] external_name_string_expression]
+ [, [Link_Name =>] link_name_string_expression]);
+
+3/3
+ pragma Export(
+ [Convention =>] convention_identifier, [Entity =>] local_name
+ [, [External_Name =>] external_name_string_expression]
+ [, [Link_Name =>] link_name_string_expression]);
+
+4/3
+ pragma Convention([Convention =>] convention_identifier,[Entity
+ =>] local_name);
+
+5/3
+ {AI05-0229-1AI05-0229-1} For pragmas Import and Export, the
+ argument for Link_Name shall not be given without the
+ pragma_argument_identifier unless the argument for External_Name is
+ given.
+
+ _Name Resolution Rules_
+
+6/3
+{AI05-0229-1AI05-0229-1} The expected type for an
+external_name_string_expression and a link_name_string_expression in an
+interfacing pragma is String.
+
+ _Legality Rules_
+
+7/3
+{AI05-0229-1AI05-0229-1} The convention_identifier of an interfacing
+pragma shall be the name of a convention (see *note B.1::).
+
+8/3
+{AI05-0229-1AI05-0229-1} A pragma Import shall be the completion of a
+declaration. Notwithstanding any rule to the contrary, a pragma Import
+may serve as the completion of any kind of (explicit) declaration if
+supported by an implementation for that kind of declaration. If a
+completion is a pragma Import, then it shall appear in the same
+declarative_part, package_specification, task_definition, or
+protected_definition as the declaration. For a library unit, it shall
+appear in the same compilation, before any subsequent compilation_units
+other than pragmas. If the local_name denotes more than one entity,
+then the pragma Import is the completion of all of them.
+
+9/3
+{AI05-0229-1AI05-0229-1} The external_name_string_expression and
+link_name_string_expression of a pragma Import or Export shall be
+static.
+
+10/3
+{AI05-0229-1AI05-0229-1} The local_name of each of these pragmas shall
+denote a declaration that may have the similarly named aspect specified.
+
+ _Static Semantics_
+
+11/3
+{AI05-0229-1AI05-0229-1} An interfacing pragma specifies various aspects
+of the entity denoted by the local_name as follows:
+
+12/3
+ * The Convention aspect (see *note B.1::) is convention_identifier.
+
+13/3
+ * A pragma Import specifies that the Import aspect (see *note B.1::)
+ is True.
+
+14/3
+ * A pragma Export specifies that the Export aspect (see *note B.1::)
+ is True.
+
+15/3
+ * For both pragma Import and Export, if an external name is given in
+ the pragma, the External_Name aspect (see *note B.1::) is specified
+ to be external_name_string_expression. If a link name is given in
+ the pragma, the Link_Name aspect (see *note B.1::) is specified to
+ be the link_name_string_expression.
+
+ _Wording Changes from Ada 2005_
+
+15.a/3
+ {AI05-0229-1AI05-0229-1} {AI05-0299-1AI05-0299-1} This
+ subclause is new. Pragmas Import, Export, and Convention were
+ moved here from *note B.1::; aspects Import, Export,
+ Convention, Link_Name, and External_Name live there now.
+
+\1f
+File: aarm2012.info, Node: J.15.6, Next: J.15.7, Prev: J.15.5, Up: J.15
+
+J.15.6 Pragma Unchecked_Union
+-----------------------------
+
+ _Syntax_
+
+1/3
+ {AI05-0229-1AI05-0229-1} The form of a pragma Unchecked_Union,
+ which is a representation pragma (see *note 13.1::), is as follows:
+
+
+2/3
+ pragma Unchecked_Union (first_subtype_local_name);
+
+ _Legality Rules_
+
+3/3
+{AI05-0229-1AI05-0229-1} The first_subtype_local_name of a pragma
+Unchecked_Union shall denote an unconstrained discriminated record
+subtype having a variant_part.
+
+ _Static Semantics_
+
+4/3
+{AI05-0229-1AI05-0229-1} A pragma Unchecked_Union specifies that the
+Unchecked_Union aspect (see *note B.3.3::) for the type denoted by
+first_subtype_local_name has the value True.
+
+ _Wording Changes from Ada 2005_
+
+4.a/3
+ {AI05-0229-1AI05-0229-1} {AI05-0299-1AI05-0299-1} This
+ subclause is new. Pragma Unchecked_Union was moved here from
+ *note B.3.3::; aspect Unchecked_Union lives there now.
+
+\1f
+File: aarm2012.info, Node: J.15.7, Next: J.15.8, Prev: J.15.6, Up: J.15
+
+J.15.7 Pragmas Interrupt_Handler and Attach_Handler
+---------------------------------------------------
+
+ _Syntax_
+
+1/3
+ {AI05-0229-1AI05-0229-1} The form of a pragma Interrupt_Handler is
+ as follows:
+
+2/3
+ pragma Interrupt_Handler (handler_name);
+
+3/3
+ {AI05-0229-1AI05-0229-1} The form of a pragma Attach_Handler is as
+ follows:
+
+4/3
+ pragma Attach_Handler (handler_name, expression);
+
+ _Name Resolution Rules_
+
+5/3
+{AI05-0229-1AI05-0229-1} For the Interrupt_Handler and Attach_Handler
+pragmas, the handler_name shall resolve to denote a protected procedure
+with a parameterless profile.
+
+6/3
+{AI05-0229-1AI05-0229-1} For the Attach_Handler pragma, the expected
+type for the expression is Interrupts.Interrupt_Id (see *note C.3.2::).
+
+ _Legality Rules_
+
+7/3
+{AI05-0033-1AI05-0033-1} {AI05-0229-1AI05-0229-1} The Attach_Handler and
+Interrupt_Handler pragmas are only allowed immediately within the
+protected_definition where the corresponding subprogram is declared.
+The corresponding protected_type_declaration or
+single_protected_declaration shall be a library-level declaration, and
+shall not be declared within a generic body. In addition to the places
+where Legality Rules normally apply (see *note 12.3::), these rules also
+apply in the private part of an instance of a generic unit.
+
+7.a/3
+ Discussion: In the case of a protected_type_declaration, an
+ object_declaration of an object of that type need not be at
+ library level.
+
+7.b/3
+ {AI05-0033-1AI05-0033-1} We cannot allow these pragmas in a
+ generic body, because legality rules are not checked for
+ instance bodies, and these should not be allowed if the
+ instance is not at the library level. The protected types can
+ be declared in the private part if this is desired. Note that
+ while the 'Access to use the handler would provide the check
+ in the case of Interrupt_Handler, there is no other check for
+ Attach_Handler. Since these pragmas are so similar, we want
+ the rules to be the same.
+
+ _Static Semantics_
+
+8/3
+{AI05-0229-1AI05-0229-1} For an implementation that supports Annex C, a
+pragma Interrupt_Handler specifies the Interrupt_Handler aspect (see
+*note C.3.1::) for the protected procedure handler_name to have the
+value True. For an implementation that supports Annex C, a pragma
+Attach_Handler specifies the Attach_Handler aspect (see *note C.3.1::)
+for the protected procedure handler_name to have the value of the given
+expression[ as evaluated at object creation time].
+
+ _Incompatibilities With Ada 2005_
+
+8.a/3
+ {AI05-0033-1AI05-0033-1} Correction: Added missing generic
+ contract wording for the pragma Attach_Handler and
+ Interrupt_Handler. This means that nested instances with
+ these pragmas in the private part are now illegal. This is
+ not likely to occur in practice.
+
+ _Wording Changes from Ada 2005_
+
+8.b/3
+ {AI05-0229-1AI05-0229-1} {AI05-0299-1AI05-0299-1} This
+ subclause is new. Pragmas Interrupt_Handler and
+ Attach_Handler were moved here from *note C.3.1::; aspects
+ Interrupt_Handler and Attach_Handler live there now.
+
+\1f
+File: aarm2012.info, Node: J.15.8, Next: J.15.9, Prev: J.15.7, Up: J.15
+
+J.15.8 Shared Variable Pragmas
+------------------------------
+
+ _Syntax_
+
+1/3
+ {AI05-0229-1AI05-0229-1} The form for pragmas Atomic, Volatile,
+ Independent, Atomic_Components, and Volatile_Components, and
+ Independent_Components is as follows:
+
+2/3
+ pragma Atomic (local_name);
+
+3/3
+ pragma Volatile (local_name);
+
+4/3
+ {AI05-0009-1AI05-0009-1} pragma Independent (component_
+ local_name);
+
+5/3
+ pragma Atomic_Components (array_local_name);
+
+6/3
+ pragma Volatile_Components (array_local_name);
+
+7/3
+ {AI05-0009-1AI05-0009-1} pragma Independent_Components (
+ local_name);
+
+7.a/3
+ Discussion: {AI05-0009-1AI05-0009-1} {AI05-0229-1AI05-0229-1}
+ Pragmas Independent and Independent_Components are born
+ obsolescent; they are defined to provide consistency with the
+ existing shared variable pragmas. As with all obsolescent
+ features, these pragmas are not optional; all Ada
+ implementations need to implement them. Also note that these
+ pragmas were defined as a Correction; as such, they are
+ expected to be implemented as part of Ada 2005 implementations
+ (and they would not be obsolescent there).
+
+ _Name Resolution Rules_
+
+8/3
+{AI05-0009-1AI05-0009-1} {AI05-0229-1AI05-0229-1} The local_name in an
+Atomic or Volatile pragma shall resolve to denote either an
+object_declaration, a noninherited component_declaration, or a
+full_type_declaration. The component_local_name in an Independent
+pragma shall resolve to denote a noninherited component_declaration.
+The array_local_name in an Atomic_Components or Volatile_Components
+pragma shall resolve to denote the declaration of an array type or an
+array object of an anonymous type. The local_name in an
+Independent_Components pragma shall resolve to denote the declaration of
+an array or record type or an array object of an anonymous type.
+
+ _Static Semantics_
+
+9/3
+{AI05-0229-1AI05-0229-1} These pragmas are representation pragmas (see
+*note 13.1::). Each of these pragmas specifies that the similarly named
+aspect (see *note C.6::) of the type, object, or component denoted by
+its argument is True.
+
+ _Legality Rules_
+
+10/3
+{AI05-0229-1AI05-0229-1} The local_name of each of these pragmas shall
+denote a declaration that may have the similarly named aspect specified.
+
+ _Wording Changes from Ada 2005_
+
+10.a/3
+ {AI05-0229-1AI05-0229-1} {AI05-0299-1AI05-0299-1} This
+ subclause is new. These pragmas were moved here from *note
+ C.6::; various aspects live there now.
+
+\1f
+File: aarm2012.info, Node: J.15.9, Next: J.15.10, Prev: J.15.8, Up: J.15
+
+J.15.9 Pragma CPU
+-----------------
+
+0.a/3
+ Discussion: {AI05-0229-1AI05-0229-1} This pragma is born
+ obsolescent; it is defined to provide consistency with
+ existing real-time pragmas. As with all obsolescent features,
+ this pragma is not optional; all Ada implementations need to
+ implement it.
+
+ _Syntax_
+
+1/3
+ {AI05-0229-1AI05-0229-1} The form of a pragma CPU is as follows:
+
+2/3
+ pragma CPU (expression);
+
+ _Name Resolution Rules_
+
+3/3
+{AI05-0229-1AI05-0229-1} The expected type for the expression of a
+pragma CPU is System.Multiprocessors.CPU_Range.
+
+ _Legality Rules_
+
+4/3
+{AI05-0229-1AI05-0229-1} A CPU pragma is allowed only immediately within
+a task_definition, or the declarative_part of a subprogram_body.
+
+5/3
+{AI05-0229-1AI05-0229-1} For a CPU pragma that appears in the
+declarative_part of a subprogram_body, the expression shall be static.
+
+ _Static Semantics_
+
+6/3
+{AI05-0229-1AI05-0229-1} For an implementation that supports Annex D, a
+pragma CPU specifies the value of the CPU aspect (see *note D.16::). If
+the pragma appears in a task_definition, the expression is associated
+with the aspect for the task type or single_task_declaration that
+contains the pragma; otherwise, the expression is associated with the
+aspect for the subprogram that contains the pragma.
+
+ _Extensions to Ada 2005_
+
+6.a/3
+ {AI05-0009-1AI05-0009-1} Pragma CPU is new.
+
+\1f
+File: aarm2012.info, Node: J.15.10, Next: J.15.11, Prev: J.15.9, Up: J.15
+
+J.15.10 Pragma Dispatching_Domain
+---------------------------------
+
+0.a/3
+ Discussion: {AI05-0167-1AI05-0167-1} This pragma is born
+ obsolescent; it is defined to provide consistency with
+ existing real-time pragmas. As with all obsolescent features,
+ this pragma is not optional; all Ada implementations need to
+ implement it.
+
+ _Syntax_
+
+1/3
+ {AI05-0167-1AI05-0167-1} The form of a pragma Dispatching_Domain is
+ as follows:
+
+2/3
+ pragma Dispatching_Domain (expression);
+
+ _Name Resolution Rules_
+
+3/3
+{AI05-0167-1AI05-0167-1} The expected type for the expression is
+System.Multiprocessors.Dispatching_Domains.Dispatching_Domain.
+
+ _Legality Rules_
+
+4/3
+{AI05-0167-1AI05-0167-1} A Dispatching_Domain pragma is allowed only
+immediately within a task_definition.
+
+ _Static Semantics_
+
+5/3
+{AI05-0167-1AI05-0167-1} For an implementation that supports Annex D, a
+pragma Dispatching_Domain specifies the value of the Dispatching_Domain
+aspect (see *note D.16.1::). The expression is associated with the
+aspect for the task type or single_task_declaration that contains the
+pragma.
+
+ _Extensions to Ada 2005_
+
+5.a/3
+ {AI05-0009-1AI05-0009-1} Pragma Dispatching_Domain is new.
+
+\1f
+File: aarm2012.info, Node: J.15.11, Next: J.15.12, Prev: J.15.10, Up: J.15
+
+J.15.11 Pragmas Priority and Interrupt_Priority
+-----------------------------------------------
+
+ _Syntax_
+
+1/3
+ {AI05-0229-1AI05-0229-1} The form of a pragma Priority is as
+ follows:
+
+2/3
+ pragma Priority (expression);
+
+3/3
+ {AI05-0229-1AI05-0229-1} The form of a pragma Interrupt_Priority is
+ as follows:
+
+4/3
+ pragma Interrupt_Priority [(expression);]
+
+ _Name Resolution Rules_
+
+5/3
+{AI05-0229-1AI05-0229-1} The expected type for the expression in a
+Priority or Interrupt_Priority pragma is Integer.
+
+ _Legality Rules_
+
+6/3
+{AI05-0229-1AI05-0229-1} A Priority pragma is allowed only immediately
+within a task_definition, a protected_definition, or the
+declarative_part of a subprogram_body. An Interrupt_Priority pragma is
+allowed only immediately within a task_definition or a
+protected_definition.
+
+7/3
+{AI05-0229-1AI05-0229-1} For a Priority pragma that appears in the
+declarative_part of a subprogram_body, the expression shall be static,
+and its value shall be in the range of System.Priority.
+
+ _Static Semantics_
+
+8/3
+{AI05-0229-1AI05-0229-1} For an implementation that supports Annex D, a
+pragma Priority specifies the value of the Priority aspect (see *note
+D.1::) and a pragma Interrupt_Priority specifies the value of the
+Interrupt_Priority aspect as follows:
+
+9/3
+ * If the pragma appears in a task_definition, the expression is
+ associated with the aspect for the task type or
+ single_task_declaration that contains the pragma;
+
+10/3
+ * If the pragma appears in a protected_definition, the expression is
+ associated with the aspect for the protected type or
+ single_protected_declaration that contains the pragma;
+
+11/3
+ * If the pragma appears in the declarative_part of a subprogram_body,
+ the expression is associated with the aspect for the subprogram
+ that contains the pragma.
+
+12/3
+{AI05-0229-1AI05-0229-1} If there is no expression in an
+Interrupt_Priority pragma, the Interrupt_Priority aspect has the value
+Interrupt_Priority'Last.
+
+ _Wording Changes from Ada 2005_
+
+12.a/3
+ {AI05-0229-1AI05-0229-1} {AI05-0299-1AI05-0299-1} This
+ subclause is new. Pragmas Interrupt_Priority and Priority
+ were moved here from *note D.1::; aspects Interrupt_Priority
+ and Priority live there now.
+
+\1f
+File: aarm2012.info, Node: J.15.12, Next: J.15.13, Prev: J.15.11, Up: J.15
+
+J.15.12 Pragma Relative_Deadline
+--------------------------------
+
+ _Syntax_
+
+1/3
+ {AI05-0229-1AI05-0229-1} The form of a pragma Relative_Deadline is
+ as follows:
+
+2/3
+ pragma Relative_Deadline (relative_deadline_expression);
+
+ _Name Resolution Rules_
+
+3/3
+{AI05-0229-1AI05-0229-1} The expected type for a
+relative_deadline_expression is Real_Time.Time_Span.
+
+ _Legality Rules_
+
+4/3
+{AI05-0229-1AI05-0229-1} A Relative_Deadline pragma is allowed only
+immediately within a task_definition or the declarative_part of a
+subprogram_body.
+
+ _Static Semantics_
+
+5/3
+{AI05-0229-1AI05-0229-1} For an implementation that supports Annex D, a
+pragma Relative_Deadline specifies the value of the Relative_Deadline
+aspect (see *note D.2.6::). If the pragma appears in a task_definition,
+the expression is associated with the aspect for the task type or
+single_task_declaration that contains the pragma; otherwise, the
+expression is associated with the aspect for the subprogram that
+contains the pragma.
+
+ _Wording Changes from Ada 2005_
+
+5.a/3
+ {AI05-0229-1AI05-0229-1} {AI05-0299-1AI05-0299-1} This
+ subclause is new. Pragma Relative_Deadline was moved here
+ from *note D.2.6::; aspect Relative_Deadline lives there now.
+
+\1f
+File: aarm2012.info, Node: J.15.13, Prev: J.15.12, Up: J.15
+
+J.15.13 Pragma Asynchronous
+---------------------------
+
+ _Syntax_
+
+1/3
+ {AI05-0229-1AI05-0229-1} The form of a pragma Asynchronous, which
+ is a representation pragma (see *note 13.1::), is as follows:
+
+2/3
+ pragma Asynchronous (local_name);
+
+ _Static Semantics_
+
+3/3
+{AI05-0229-1AI05-0229-1} For an implementation that supports Annex E, a
+pragma Asynchronous specifies that the Asynchronous aspect (see *note
+E.4.1::) for the procedure or type denoted by local_name has the value
+True.
+
+ _Legality Rules_
+
+4/3
+{AI05-0229-1AI05-0229-1} The local_name of a pragma Asynchronous shall
+denote a declaration that may have aspect Asynchronous specified.
+
+ _Wording Changes from Ada 2005_
+
+4.a/3
+ {AI05-0229-1AI05-0229-1} {AI05-0299-1AI05-0299-1} This
+ subclause is new. Pragma Asynchronous was moved here from
+ *note E.4.1::; aspect Asynchronous lives there now.
+
+\1f
+File: aarm2012.info, Node: Annex K, Next: Annex L, Prev: Annex J, Up: Top
+
+Annex K Language-Defined Aspects and Attributes
+***********************************************
+
+1/3
+{AI05-0229-1AI05-0229-1} This annex summarizes the definitions given
+elsewhere of the language-defined aspects and attributes. Some aspects
+have corresponding attributes, as noted.
+
+* Menu:
+
+* K.1 :: Language-Defined Aspects
+* K.2 :: Language-Defined Attributes
+
+\1f
+File: aarm2012.info, Node: K.1, Next: K.2, Up: Annex K
+
+K.1 Language-Defined Aspects
+============================
+
+1/3
+{AI05-0229-1AI05-0229-1} {AI05-0299-1AI05-0299-1} This subclause
+summarizes the definitions given elsewhere of the language-defined
+aspects. Aspects are properties of entities that can be specified by
+the Ada program; unless otherwise specified below, aspects can be
+specified using an aspect_specification.
+
+2/3
+Address
+ Machine address of an entity. See *note 13.3::.
+
+3/3
+Alignment (object)
+ Alignment of an object. See *note 13.3::.
+
+4/3
+Alignment (subtype)
+ Alignment of a subtype. See *note 13.3::.
+
+5/3
+All_Calls_Remote
+ All remote procedure calls should use the Partition
+ Communication Subsystem, even if they are local. See
+ *note E.2.3::.
+
+6/3
+Asynchronous
+ Remote procedure calls are asynchronous; the caller
+ continues without waiting for the call to return. See
+ *note E.4.1::.
+
+7/3
+Atomic
+ Declare that a type, object, or component is atomic. See
+ *note C.6::.
+
+8/3
+Atomic_Components
+ Declare that the components of an array type or object
+ are atomic. See *note C.6::.
+
+9/3
+Attach_Handler
+ Protected procedure is attached to an interrupt. See
+ *note C.3.1::.
+
+10/3
+Bit_Order
+ Order of bit numbering in a record_representation_clause.
+ See *note 13.5.3::.
+
+11/3
+Coding
+ Internal representation of enumeration literals.
+ Specified by an enumeration_representation_clause, not by
+ an aspect_specification. See *note 13.4::.
+
+12/3
+Component_Size
+ Size in bits of a component of an array type. See *note
+ 13.3::.
+
+13/3
+Constant_Indexing
+ Defines function(s) to implement user-defined
+ indexed_components. See *note 4.1.6::.
+
+14/3
+Convention
+ Calling convention or other convention used for
+ interfacing to other languages. See *note B.1::.
+
+15/3
+CPU
+ Processor on which a given task should run. See *note
+ D.16::.
+
+16/3
+Default_Component_Value
+ Default value for the components of an array-of-scalar
+ subtype. See *note 3.6::.
+
+17/3
+Default_Iterator
+ Default iterator to be used in for loops. See *note
+ 5.5.1::.
+
+18/3
+Default_Storage_Pool
+ Default storage pool for a generic instance. See *note
+ 13.11.3::.
+
+19/3
+Default_Value
+ Default value for a scalar subtype. See *note 3.5::.
+
+20/3
+Dispatching_Domain
+ Domain (group of processors) on which a given task should
+ run. See *note D.16.1::.
+
+21/3
+Dynamic_Predicate
+ Condition that must hold true for objects of a given
+ subtype; the subtype is not static. See *note 3.2.4::.
+
+22/3
+Elaborate_Body
+ A given package must have a body, and that body is
+ elaborated immediately after the declaration. See *note
+ 10.2.1::.
+
+23/3
+Export
+ Entity is exported to another language. See *note B.1::.
+
+24/3
+External_Name
+ Name used to identify an imported or exported entity.
+ See *note B.1::.
+
+25/3
+External_Tag
+ Unique identifier for a tagged type in streams. See
+ *note 13.3::.
+
+26/3
+Implicit_Dereference
+ Mechanism for user-defined implicit .all. See *note
+ 4.1.5::.
+
+27/3
+Import
+ Entity is imported from another language. See *note
+ B.1::.
+
+28/3
+Independent
+ Declare that a type, object, or component is
+ independently addressable. See *note C.6::.
+
+29/3
+Independent_Components
+ Declare that the components of an array or record type,
+ or an array object, are independently addressable. See
+ *note C.6::.
+
+30/3
+Inline
+ For efficiency, Inline calls are requested for a
+ subprogram. See *note 6.3.2::.
+
+31/3
+Input
+ Function to read a value from a stream for a given type,
+ including any bounds and discriminants. See *note
+ 13.13.2::.
+
+32/3
+Interrupt_Handler
+ Protected procedure may be attached to interrupts. See
+ *note C.3.1::.
+
+33/3
+Interrupt_Priority
+ Priority of a task object or type, or priority of a
+ protected object or type; the priority is in the
+ interrupt range. See *note D.1::.
+
+34/3
+Iterator_Element
+ Element type to be used for user-defined iterators. See
+ *note 5.5.1::.
+
+35/3
+Layout (record)
+ Layout of record components. Specified by a
+ record_representation_clause, not by an
+ aspect_specification. See *note 13.5.1::.
+
+36/3
+Link_Name
+ Linker symbol used to identify an imported or exported
+ entity. See *note B.1::.
+
+37/3
+Machine_Radix
+ Radix (2 or 10) that is used to represent a decimal fixed
+ point type. See *note F.1::.
+
+38/3
+No_Return
+ A procedure will not return normally. See *note 6.5.1::.
+
+39/3
+Output
+ Procedure to write a value to a stream for a given type,
+ including any bounds and discriminants. See *note
+ 13.13.2::.
+
+40/3
+Pack
+ Minimize storage when laying out records and arrays. See
+ *note 13.2::.
+
+41/3
+Post
+ Postcondition; a condition that must hold true after a
+ call. See *note 6.1.1::.
+
+42/3
+Post'Class
+ Postcondition inherited on type derivation. See *note
+ 6.1.1::.
+
+43/3
+Pre
+ Precondition; a condition that must hold true before a
+ call. See *note 6.1.1::.
+
+44/3
+Pre'Class
+ Precondition inherited on type derivation. See *note
+ 6.1.1::.
+
+45/3
+Preelaborate
+ Code execution during elaboration is avoided for a given
+ package. See *note 10.2.1::.
+
+46/3
+Priority
+ Priority of a task object or type, or priority of a
+ protected object or type; the priority is not in the
+ interrupt range. See *note D.1::.
+
+47/3
+Pure
+ Side effects are avoided in the subprograms of a given
+ package. See *note 10.2.1::.
+
+48/3
+Read
+ Procedure to read a value from a stream for a given type.
+ See *note 13.13.2::.
+
+49/3
+Record layout
+ See Layout. See *note 13.5.1::.
+
+50/3
+Relative_Deadline
+ Task parameter used in Earliest Deadline First
+ Dispatching. See *note D.2.6::.
+
+51/3
+Remote_Call_Interface
+ Subprograms in a given package may be used in remote
+ procedure calls. See *note E.2.3::.
+
+52/3
+Remote_Types
+ Types in a given package may be used in remote procedure
+ calls. See *note E.2.2::.
+
+53/3
+Shared_Passive
+ A given package is used to represent shared memory in a
+ distributed system. See *note E.2.1::.
+
+54/3
+Size (object)
+ Size in bits of an object. See *note 13.3::.
+
+55/3
+Size (subtype)
+ Size in bits of a subtype. See *note 13.3::.
+
+56/3
+Small
+ Scale factor for a fixed point type. See *note 3.5.10::.
+
+57/3
+Static_Predicate
+ Condition that must hold true for objects of a given
+ subtype; the subtype may be static. See *note 3.2.4::.
+
+58/3
+Storage_Pool
+ Pool of memory from which new will allocate for a given
+ access type. See *note 13.11::.
+
+59/3
+Storage_Size (access)
+ Sets memory size for allocations for an access type. See
+ *note 13.11::.
+
+60/3
+Storage_Size (task)
+ Size in storage elements reserved for a task type or
+ single task object. See *note 13.3::.
+
+61/3
+Stream_Size
+ Size in bits used to represent elementary objects in a
+ stream. See *note 13.13.2::.
+
+62/3
+Synchronization
+ Defines whether a given primitive operation of a
+ synchronized interface must be implemented by an entry or
+ protected procedure. See *note 9.5::.
+
+63/3
+Type_Invariant
+ A condition that must hold true for all objects of a
+ type. See *note 7.3.2::.
+
+64/3
+Type_Invariant'Class
+ A condition that must hold true for all objects in a
+ class of types. See *note 7.3.2::.
+
+65/3
+Unchecked_Union
+ Type is used to interface to a C union type. See *note
+ B.3.3::.
+
+66/3
+Variable_Indexing
+ Defines function(s) to implement user-defined
+ indexed_components. See *note 4.1.6::.
+
+67/3
+Volatile
+ Declare that a type, object, or component is volatile.
+ See *note C.6::.
+
+68/3
+Volatile_Components
+ Declare that the components of an array type or object
+ are volatile. See *note C.6::.
+
+69/3
+Write
+ Procedure to write a value to a stream for a given type.
+ See *note 13.13.2::.
+
+\1f
+File: aarm2012.info, Node: K.2, Prev: K.1, Up: Annex K
+
+K.2 Language-Defined Attributes
+===============================
+
+1/3
+{AI05-0229-1AI05-0229-1} {AI05-0299-1AI05-0299-1} This subclause
+summarizes the definitions given elsewhere of the language-defined
+attributes. Attributes are properties of entities that can be queried
+by an Ada program.
+
+2
+P'Access
+ For a prefix P that denotes a subprogram:
+
+3
+ P'Access yields an access value that designates the
+ subprogram denoted by P. The type of P'Access is an
+ access-to-subprogram type (S), as determined by the
+ expected type. See *note 3.10.2::.
+
+4
+X'Access
+ For a prefix X that denotes an aliased view of an object:
+
+5
+ X'Access yields an access value that designates the
+ object denoted by X. The type of X'Access is an
+ access-to-object type, as determined by the expected
+ type. The expected type shall be a general access type.
+ See *note 3.10.2::.
+
+6/1
+X'Address
+ For a prefix X that denotes an object, program unit, or
+ label:
+
+7
+ Denotes the address of the first of the storage elements
+ allocated to X. For a program unit or label, this value
+ refers to the machine code associated with the
+ corresponding body or statement. The value of this
+ attribute is of type System.Address. See *note 13.3::.
+
+8
+S'Adjacent
+ For every subtype S of a floating point type T:
+
+9
+ S'Adjacent denotes a function with the following
+ specification:
+
+10
+ function S'Adjacent (X, Towards : T)
+ return T
+
+11
+ If Towards = X, the function yields X; otherwise, it
+ yields the machine number of the type T adjacent to X in
+ the direction of Towards, if that machine number exists.
+ If the result would be outside the base range of S,
+ Constraint_Error is raised. When T'Signed_Zeros is True,
+ a zero result has the sign of X. When Towards is zero,
+ its sign has no bearing on the result. See *note
+ A.5.3::.
+
+12
+S'Aft
+ For every fixed point subtype S:
+
+13
+ S'Aft yields the number of decimal digits needed after
+ the decimal point to accommodate the delta of the subtype
+ S, unless the delta of the subtype S is greater than 0.1,
+ in which case the attribute yields the value one. (S'Aft
+ is the smallest positive integer N for which
+ (10**N)*S'Delta is greater than or equal to one.) The
+ value of this attribute is of the type universal_integer.
+ See *note 3.5.10::.
+
+13.1/2
+S'Alignment
+ For every subtype S:
+
+13.2/2
+ The value of this attribute is of type universal_integer,
+ and nonnegative.
+
+13.3/2
+ For an object X of subtype S, if S'Alignment is not zero,
+ then X'Alignment is a nonzero integral multiple of
+ S'Alignment unless specified otherwise by a
+ representation item. See *note 13.3::.
+
+14/1
+X'Alignment
+ For a prefix X that denotes an object:
+
+15
+ The value of this attribute is of type universal_integer,
+ and nonnegative; zero means that the object is not
+ necessarily aligned on a storage element boundary. If
+ X'Alignment is not zero, then X is aligned on a storage
+ unit boundary and X'Address is an integral multiple of
+ X'Alignment (that is, the Address modulo the Alignment is
+ zero).
+
+16/2
+
+ This paragraph was deleted. See *note 13.3::.
+
+17
+S'Base
+ For every scalar subtype S:
+
+18
+ S'Base denotes an unconstrained subtype of the type of S.
+ This unconstrained subtype is called the base subtype of
+ the type. See *note 3.5::.
+
+19
+S'Bit_Order
+ For every specific record subtype S:
+
+20
+ Denotes the bit ordering for the type of S. The value of
+ this attribute is of type System.Bit_Order. See *note
+ 13.5.3::.
+
+21/1
+P'Body_Version
+ For a prefix P that statically denotes a program unit:
+
+22
+ Yields a value of the predefined type String that
+ identifies the version of the compilation unit that
+ contains the body (but not any subunits) of the program
+ unit. See *note E.3::.
+
+23
+T'Callable
+ For a prefix T that is of a task type (after any implicit
+ dereference):
+
+24
+ Yields the value True when the task denoted by T is
+ callable, and False otherwise; See *note 9.9::.
+
+25
+E'Caller
+ For a prefix E that denotes an entry_declaration:
+
+26/3
+ Yields a value of the type Task_Id that identifies the
+ task whose call is now being serviced. Use of this
+ attribute is allowed only inside an accept_statement, or
+ entry_body after the entry_barrier, corresponding to the
+ entry_declaration denoted by E. See *note C.7.1::.
+
+27
+S'Ceiling
+ For every subtype S of a floating point type T:
+
+28
+ S'Ceiling denotes a function with the following
+ specification:
+
+29
+ function S'Ceiling (X : T)
+ return T
+
+30
+ The function yields the value 'ceiling(X)', i.e., the
+ smallest (most negative) integral value greater than or
+ equal to X. When X is zero, the result has the sign of X;
+ a zero result otherwise has a negative sign when
+ S'Signed_Zeros is True. See *note A.5.3::.
+
+31
+S'Class
+ For every subtype S of a tagged type T (specific or
+ class-wide):
+
+32
+ S'Class denotes a subtype of the class-wide type (called
+ T'Class in this International Standard) for the class
+ rooted at T (or if S already denotes a class-wide
+ subtype, then S'Class is the same as S).
+
+33
+ S'Class is unconstrained. However, if S is constrained,
+ then the values of S'Class are only those that when
+ converted to the type T belong to S. See *note 3.9::.
+
+34
+S'Class
+ For every subtype S of an untagged private type whose
+ full view is tagged:
+
+35
+ Denotes the class-wide subtype corresponding to the full
+ view of S. This attribute is allowed only from the
+ beginning of the private part in which the full view is
+ declared, until the declaration of the full view. After
+ the full view, the Class attribute of the full view can
+ be used. See *note 7.3.1::.
+
+36/1
+X'Component_Size
+ For a prefix X that denotes an array subtype or array
+ object (after any implicit dereference):
+
+37
+ Denotes the size in bits of components of the type of X.
+ The value of this attribute is of type universal_integer.
+ See *note 13.3::.
+
+38
+S'Compose
+ For every subtype S of a floating point type T:
+
+39
+ S'Compose denotes a function with the following
+ specification:
+
+40
+ function S'Compose (Fraction : T;
+ Exponent : universal_integer)
+ return T
+
+41
+ Let v be the value Fraction · T'Machine_RadixExponent-k,
+ where k is the normalized exponent of Fraction. If v is
+ a machine number of the type T, or if |v| >=
+ T'Model_Small, the function yields v; otherwise, it
+ yields either one of the machine numbers of the type T
+ adjacent to v. Constraint_Error is optionally raised if
+ v is outside the base range of S. A zero result has the
+ sign of Fraction when S'Signed_Zeros is True. See *note
+ A.5.3::.
+
+42
+A'Constrained
+ For a prefix A that is of a discriminated type (after any
+ implicit dereference):
+
+43/3
+ Yields the value True if A denotes a constant, a value, a
+ tagged object, or a constrained variable, and False
+ otherwise. See *note 3.7.2::.
+
+44
+S'Copy_Sign
+ For every subtype S of a floating point type T:
+
+45
+ S'Copy_Sign denotes a function with the following
+ specification:
+
+46
+ function S'Copy_Sign (Value, Sign : T)
+ return T
+
+47
+ If the value of Value is nonzero, the function yields a
+ result whose magnitude is that of Value and whose sign is
+ that of Sign; otherwise, it yields the value zero.
+ Constraint_Error is optionally raised if the result is
+ outside the base range of S. A zero result has the sign
+ of Sign when S'Signed_Zeros is True. See *note A.5.3::.
+
+48
+E'Count
+ For a prefix E that denotes an entry of a task or
+ protected unit:
+
+49
+ Yields the number of calls presently queued on the entry
+ E of the current instance of the unit. The value of this
+ attribute is of the type universal_integer. See *note
+ 9.9::.
+
+50/1
+S'Definite
+ For a prefix S that denotes a formal indefinite subtype:
+
+51/3
+ S'Definite yields True if the actual subtype
+ corresponding to S is definite; otherwise, it yields
+ False. The value of this attribute is of the predefined
+ type Boolean. See *note 12.5.1::.
+
+52
+S'Delta
+ For every fixed point subtype S:
+
+53
+ S'Delta denotes the delta of the fixed point subtype S.
+ The value of this attribute is of the type
+ universal_real. See *note 3.5.10::.
+
+54
+S'Denorm
+ For every subtype S of a floating point type T:
+
+55
+ Yields the value True if every value expressible in the
+ form
+ ± mantissa · T'Machine_RadixT'Machine_Emin
+ where mantissa is a nonzero T'Machine_Mantissa-digit
+ fraction in the number base T'Machine_Radix, the first
+ digit of which is zero, is a machine number (see *note
+ 3.5.7::) of the type T; yields the value False otherwise.
+ The value of this attribute is of the predefined type
+ Boolean. See *note A.5.3::.
+
+56
+S'Digits
+ For every floating point subtype S:
+
+57
+ S'Digits denotes the requested decimal precision for the
+ subtype S. The value of this attribute is of the type
+ universal_integer. See *note 3.5.8::.
+
+58
+S'Digits
+ For every decimal fixed point subtype S:
+
+59
+ S'Digits denotes the digits of the decimal fixed point
+ subtype S, which corresponds to the number of decimal
+ digits that are representable in objects of the subtype.
+ The value of this attribute is of the type
+ universal_integer. See *note 3.5.10::.
+
+60
+S'Exponent
+ For every subtype S of a floating point type T:
+
+61
+ S'Exponent denotes a function with the following
+ specification:
+
+62
+ function S'Exponent (X : T)
+ return universal_integer
+
+63
+ The function yields the normalized exponent of X. See
+ *note A.5.3::.
+
+64
+S'External_Tag
+ For every subtype S of a tagged type T (specific or
+ class-wide):
+
+65
+ S'External_Tag denotes an external string representation
+ for S'Tag; it is of the predefined type String.
+ External_Tag may be specified for a specific tagged type
+ via an attribute_definition_clause; the expression of
+ such a clause shall be static. The default external tag
+ representation is implementation defined. See *note
+ 13.13.2::. See *note 13.3::.
+
+66/1
+A'First
+ For a prefix A that is of an array type (after any
+ implicit dereference), or denotes a constrained array
+ subtype:
+
+67
+ A'First denotes the lower bound of the first index range;
+ its type is the corresponding index type. See *note
+ 3.6.2::.
+
+68
+S'First
+ For every scalar subtype S:
+
+69
+ S'First denotes the lower bound of the range of S. The
+ value of this attribute is of the type of S. See *note
+ 3.5::.
+
+70/1
+A'First(N)
+ For a prefix A that is of an array type (after any
+ implicit dereference), or denotes a constrained array
+ subtype:
+
+71
+ A'First(N) denotes the lower bound of the N-th index
+ range; its type is the corresponding index type. See
+ *note 3.6.2::.
+
+72
+R.C'First_Bit
+ For a component C of a composite, non-array object R:
+
+73/2
+ If the nondefault bit ordering applies to the composite
+ type, and if a component_clause specifies the placement
+ of C, denotes the value given for the first_bit of the
+ component_clause; otherwise, denotes the offset, from the
+ start of the first of the storage elements occupied by C,
+ of the first bit occupied by C. This offset is measured
+ in bits. The first bit of a storage element is numbered
+ zero. The value of this attribute is of the type
+ universal_integer. See *note 13.5.2::.
+
+73.1/3
+S'First_Valid
+ For every static discrete subtype S for which there
+ exists at least one value belonging to S that satisfies
+ any predicate of S:
+
+73.2/3
+ S'First_Valid denotes the smallest value that belongs to
+ S and satisfies the predicate of S. The value of this
+ attribute is of the type of S. See *note 3.5.5::.
+
+74
+S'Floor
+ For every subtype S of a floating point type T:
+
+75
+ S'Floor denotes a function with the following
+ specification:
+
+76
+ function S'Floor (X : T)
+ return T
+
+77
+ The function yields the value 'floor(X)', i.e., the
+ largest (most positive) integral value less than or equal
+ to X. When X is zero, the result has the sign of X; a
+ zero result otherwise has a positive sign. See *note
+ A.5.3::.
+
+78
+S'Fore
+ For every fixed point subtype S:
+
+79
+ S'Fore yields the minimum number of characters needed
+ before the decimal point for the decimal representation
+ of any value of the subtype S, assuming that the
+ representation does not include an exponent, but includes
+ a one-character prefix that is either a minus sign or a
+ space. (This minimum number does not include superfluous
+ zeros or underlines, and is at least 2.) The value of
+ this attribute is of the type universal_integer. See
+ *note 3.5.10::.
+
+80
+S'Fraction
+ For every subtype S of a floating point type T:
+
+81
+ S'Fraction denotes a function with the following
+ specification:
+
+82
+ function S'Fraction (X : T)
+ return T
+
+83
+ The function yields the value X · T'Machine_Radix-k,
+ where k is the normalized exponent of X. A zero result,
+ which can only occur when X is zero, has the sign of X.
+ See *note A.5.3::.
+
+83.1/3
+X'Has_Same_Storage
+ For a prefix X that denotes an object:
+
+83.2/3
+ X'Has_Same_Storage denotes a function with the following
+ specification:
+
+83.3/3
+ function X'Has_Same_Storage (Arg : any_type)
+ return Boolean
+
+83.4/3
+ The actual parameter shall be a name that denotes an
+ object. The object denoted by the actual parameter can
+ be of any type. This function evaluates the names of the
+ objects involved and returns True if the representation
+ of the object denoted by the actual parameter occupies
+ exactly the same bits as the representation of the object
+ denoted by X; otherwise, it returns False. See *note
+ 13.3::.
+
+84/1
+E'Identity
+ For a prefix E that denotes an exception:
+
+85
+ E'Identity returns the unique identity of the exception.
+ The type of this attribute is Exception_Id. See *note
+ 11.4.1::.
+
+86
+T'Identity
+ For a prefix T that is of a task type (after any implicit
+ dereference):
+
+87
+ Yields a value of the type Task_Id that identifies the
+ task denoted by T. See *note C.7.1::.
+
+88
+S'Image
+ For every scalar subtype S:
+
+89
+ S'Image denotes a function with the following
+ specification:
+
+90
+ function S'Image(Arg : S'Base)
+ return String
+
+91/3
+ The function returns an image of the value of Arg as a
+ String. See *note 3.5::.
+
+92
+S'Class'Input
+ For every subtype S'Class of a class-wide type T'Class:
+
+93
+ S'Class'Input denotes a function with the following
+ specification:
+
+94/2
+ function S'Class'Input(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class)
+ return T'Class
+
+95/3
+ First reads the external tag from Stream and determines
+ the corresponding internal tag (by calling
+ Tags.Descendant_Tag(String'Input(Stream), S'Tag) which
+ might raise Tag_Error -- see *note 3.9::) and then
+ dispatches to the subprogram denoted by the Input
+ attribute of the specific type identified by the internal
+ tag; returns that result. If the specific type
+ identified by the internal tag is abstract,
+ Constraint_Error is raised. See *note 13.13.2::.
+
+96
+S'Input
+ For every subtype S of a specific type T:
+
+97
+ S'Input denotes a function with the following
+ specification:
+
+98/2
+ function S'Input(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class)
+ return T
+
+99
+ S'Input reads and returns one value from Stream, using
+ any bounds or discriminants written by a corresponding
+ S'Output to determine how much to read. See *note
+ 13.13.2::.
+
+100/1
+A'Last
+ For a prefix A that is of an array type (after any
+ implicit dereference), or denotes a constrained array
+ subtype:
+
+101
+ A'Last denotes the upper bound of the first index range;
+ its type is the corresponding index type. See *note
+ 3.6.2::.
+
+102
+S'Last
+ For every scalar subtype S:
+
+103
+ S'Last denotes the upper bound of the range of S. The
+ value of this attribute is of the type of S. See *note
+ 3.5::.
+
+104/1
+A'Last(N)
+ For a prefix A that is of an array type (after any
+ implicit dereference), or denotes a constrained array
+ subtype:
+
+105
+ A'Last(N) denotes the upper bound of the N-th index
+ range; its type is the corresponding index type. See
+ *note 3.6.2::.
+
+106
+R.C'Last_Bit
+ For a component C of a composite, non-array object R:
+
+107/2
+ If the nondefault bit ordering applies to the composite
+ type, and if a component_clause specifies the placement
+ of C, denotes the value given for the last_bit of the
+ component_clause; otherwise, denotes the offset, from the
+ start of the first of the storage elements occupied by C,
+ of the last bit occupied by C. This offset is measured in
+ bits. The value of this attribute is of the type
+ universal_integer. See *note 13.5.2::.
+
+107.1/3
+S'Last_Valid
+ For every static discrete subtype S for which there
+ exists at least one value belonging to S that satisfies
+ any predicate of S:
+
+107.2/3
+ S'Last_Valid denotes the largest value that belongs to S
+ and satisfies the predicate of S. The value of this
+ attribute is of the type of S. See *note 3.5.5::.
+
+108
+S'Leading_Part
+ For every subtype S of a floating point type T:
+
+109
+ S'Leading_Part denotes a function with the following
+ specification:
+
+110
+ function S'Leading_Part (X : T;
+ Radix_Digits : universal_integer)
+ return T
+
+111
+ Let v be the value T'Machine_Radixk-Radix_Digits, where k
+ is the normalized exponent of X. The function yields the
+ value
+
+112
+ * 'floor(X/v)' · v, when X is nonnegative and
+ Radix_Digits is positive;
+
+113
+ * 'ceiling(X/v)' · v, when X is negative and
+ Radix_Digits is positive.
+
+114
+ Constraint_Error is raised when Radix_Digits is zero or
+ negative. A zero result, which can only occur when X is
+ zero, has the sign of X. See *note A.5.3::.
+
+115/1
+A'Length
+ For a prefix A that is of an array type (after any
+ implicit dereference), or denotes a constrained array
+ subtype:
+
+116
+ A'Length denotes the number of values of the first index
+ range (zero for a null range); its type is
+ universal_integer. See *note 3.6.2::.
+
+117/1
+A'Length(N)
+ For a prefix A that is of an array type (after any
+ implicit dereference), or denotes a constrained array
+ subtype:
+
+118
+ A'Length(N) denotes the number of values of the N-th
+ index range (zero for a null range); its type is
+ universal_integer. See *note 3.6.2::.
+
+119
+S'Machine
+ For every subtype S of a floating point type T:
+
+120
+ S'Machine denotes a function with the following
+ specification:
+
+121
+ function S'Machine (X : T)
+ return T
+
+122
+ If X is a machine number of the type T, the function
+ yields X; otherwise, it yields the value obtained by
+ rounding or truncating X to either one of the adjacent
+ machine numbers of the type T. Constraint_Error is raised
+ if rounding or truncating X to the precision of the
+ machine numbers results in a value outside the base range
+ of S. A zero result has the sign of X when S'Signed_Zeros
+ is True. See *note A.5.3::.
+
+123
+S'Machine_Emax
+ For every subtype S of a floating point type T:
+
+124
+ Yields the largest (most positive) value of exponent such
+ that every value expressible in the canonical form (for
+ the type T), having a mantissa of T'Machine_Mantissa
+ digits, is a machine number (see *note 3.5.7::) of the
+ type T. This attribute yields a value of the type
+ universal_integer. See *note A.5.3::.
+
+125
+S'Machine_Emin
+ For every subtype S of a floating point type T:
+
+126
+ Yields the smallest (most negative) value of exponent
+ such that every value expressible in the canonical form
+ (for the type T), having a mantissa of T'Machine_Mantissa
+ digits, is a machine number (see *note 3.5.7::) of the
+ type T. This attribute yields a value of the type
+ universal_integer. See *note A.5.3::.
+
+127
+S'Machine_Mantissa
+ For every subtype S of a floating point type T:
+
+128
+ Yields the largest value of p such that every value
+ expressible in the canonical form (for the type T),
+ having a p-digit mantissa and an exponent between
+ T'Machine_Emin and T'Machine_Emax, is a machine number
+ (see *note 3.5.7::) of the type T. This attribute yields
+ a value of the type universal_integer. See *note
+ A.5.3::.
+
+129
+S'Machine_Overflows
+ For every subtype S of a floating point type T:
+
+130
+ Yields the value True if overflow and divide-by-zero are
+ detected and reported by raising Constraint_Error for
+ every predefined operation that yields a result of the
+ type T; yields the value False otherwise. The value of
+ this attribute is of the predefined type Boolean. See
+ *note A.5.3::.
+
+131
+S'Machine_Overflows
+ For every subtype S of a fixed point type T:
+
+132
+ Yields the value True if overflow and divide-by-zero are
+ detected and reported by raising Constraint_Error for
+ every predefined operation that yields a result of the
+ type T; yields the value False otherwise. The value of
+ this attribute is of the predefined type Boolean. See
+ *note A.5.4::.
+
+133
+S'Machine_Radix
+ For every subtype S of a floating point type T:
+
+134
+ Yields the radix of the hardware representation of the
+ type T. The value of this attribute is of the type
+ universal_integer. See *note A.5.3::.
+
+135
+S'Machine_Radix
+ For every subtype S of a fixed point type T:
+
+136
+ Yields the radix of the hardware representation of the
+ type T. The value of this attribute is of the type
+ universal_integer. See *note A.5.4::.
+
+136.1/2
+S'Machine_Rounding
+ For every subtype S of a floating point type T:
+
+136.2/2
+ S'Machine_Rounding denotes a function with the following
+ specification:
+
+136.3/2
+ function S'Machine_Rounding (X : T)
+ return T
+
+136.4/2
+ The function yields the integral value nearest to X. If X
+ lies exactly halfway between two integers, one of those
+ integers is returned, but which of them is returned is
+ unspecified. A zero result has the sign of X when
+ S'Signed_Zeros is True. This function provides access to
+ the rounding behavior which is most efficient on the
+ target processor. See *note A.5.3::.
+
+137
+S'Machine_Rounds
+ For every subtype S of a floating point type T:
+
+138
+ Yields the value True if rounding is performed on inexact
+ results of every predefined operation that yields a
+ result of the type T; yields the value False otherwise.
+ The value of this attribute is of the predefined type
+ Boolean. See *note A.5.3::.
+
+139
+S'Machine_Rounds
+ For every subtype S of a fixed point type T:
+
+140
+ Yields the value True if rounding is performed on inexact
+ results of every predefined operation that yields a
+ result of the type T; yields the value False otherwise.
+ The value of this attribute is of the predefined type
+ Boolean. See *note A.5.4::.
+
+141
+S'Max
+ For every scalar subtype S:
+
+142
+ S'Max denotes a function with the following
+ specification:
+
+143
+ function S'Max(Left, Right : S'Base)
+ return S'Base
+
+144
+ The function returns the greater of the values of the two
+ parameters. See *note 3.5::.
+
+144.1/3
+S'Max_Alignment_For_Allocation
+ For every subtype S:
+
+144.2/3
+ Denotes the maximum value for Alignment that could be
+ requested by the implementation via Allocate for an
+ access type whose designated subtype is S. The value of
+ this attribute is of type universal_integer. See *note
+ 13.11.1::.
+
+145
+S'Max_Size_In_Storage_Elements
+ For every subtype S:
+
+146/3
+ Denotes the maximum value for Size_In_Storage_Elements
+ that could be requested by the implementation via
+ Allocate for an access type whose designated subtype is
+ S. The value of this attribute is of type
+ universal_integer. See *note 13.11.1::.
+
+147
+S'Min
+ For every scalar subtype S:
+
+148
+ S'Min denotes a function with the following
+ specification:
+
+149
+ function S'Min(Left, Right : S'Base)
+ return S'Base
+
+150
+ The function returns the lesser of the values of the two
+ parameters. See *note 3.5::.
+
+150.1/2
+S'Mod
+ For every modular subtype S:
+
+150.2/2
+ S'Mod denotes a function with the following
+ specification:
+
+150.3/2
+ function S'Mod (Arg : universal_integer)
+ return S'Base
+
+150.4/2
+ This function returns Arg mod S'Modulus, as a value of
+ the type of S. See *note 3.5.4::.
+
+151
+S'Model
+ For every subtype S of a floating point type T:
+
+152
+ S'Model denotes a function with the following
+ specification:
+
+153
+ function S'Model (X : T)
+ return T
+
+154
+ If the Numerics Annex is not supported, the meaning of
+ this attribute is implementation defined; see *note
+ G.2.2:: for the definition that applies to
+ implementations supporting the Numerics Annex. See *note
+ A.5.3::.
+
+155
+S'Model_Emin
+ For every subtype S of a floating point type T:
+
+156
+ If the Numerics Annex is not supported, this attribute
+ yields an implementation defined value that is greater
+ than or equal to the value of T'Machine_Emin. See *note
+ G.2.2:: for further requirements that apply to
+ implementations supporting the Numerics Annex. The value
+ of this attribute is of the type universal_integer. See
+ *note A.5.3::.
+
+157
+S'Model_Epsilon
+ For every subtype S of a floating point type T:
+
+158
+ Yields the value T'Machine_Radix1 - T'Model_Mantissa.
+ The value of this attribute is of the type
+ universal_real. See *note A.5.3::.
+
+159
+S'Model_Mantissa
+ For every subtype S of a floating point type T:
+
+160
+ If the Numerics Annex is not supported, this attribute
+ yields an implementation defined value that is greater
+ than or equal to 'ceiling(d · log(10) /
+ log(T'Machine_Radix))' + 1, where d is the requested
+ decimal precision of T, and less than or equal to the
+ value of T'Machine_Mantissa. See *note G.2.2:: for
+ further requirements that apply to implementations
+ supporting the Numerics Annex. The value of this
+ attribute is of the type universal_integer. See *note
+ A.5.3::.
+
+161
+S'Model_Small
+ For every subtype S of a floating point type T:
+
+162
+ Yields the value T'Machine_RadixT'Model_Emin - 1. The
+ value of this attribute is of the type universal_real.
+ See *note A.5.3::.
+
+163
+S'Modulus
+ For every modular subtype S:
+
+164
+ S'Modulus yields the modulus of the type of S, as a value
+ of the type universal_integer. See *note 3.5.4::.
+
+164.1/3
+X'Old
+ For a prefix X that denotes an object of a nonlimited
+ type:
+
+164.2/3
+ For each X'Old in a postcondition expression that is
+ enabled, a constant is implicitly declared at the
+ beginning of the subprogram or entry. The constant is of
+ the type of X and is initialized to the result of
+ evaluating X (as an expression) at the point of the
+ constant declaration. The value of X'Old in the
+ postcondition expression is the value of this constant;
+ the type of X'Old is the type of X. These implicit
+ constant declarations occur in an arbitrary order. See
+ *note 6.1.1::.
+
+165
+S'Class'Output
+ For every subtype S'Class of a class-wide type T'Class:
+
+166
+ S'Class'Output denotes a procedure with the following
+ specification:
+
+167/2
+ procedure S'Class'Output(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+ Item : in T'Class)
+
+168/2
+ First writes the external tag of Item to Stream (by
+ calling String'Output(Stream,
+ Tags.External_Tag(Item'Tag)) -- see *note 3.9::) and then
+ dispatches to the subprogram denoted by the Output
+ attribute of the specific type identified by the tag.
+ Tag_Error is raised if the tag of Item identifies a type
+ declared at an accessibility level deeper than that of S.
+ See *note 13.13.2::.
+
+169
+S'Output
+ For every subtype S of a specific type T:
+
+170
+ S'Output denotes a procedure with the following
+ specification:
+
+171/2
+ procedure S'Output(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+ Item : in T)
+
+172
+ S'Output writes the value of Item to Stream, including
+ any bounds or discriminants. See *note 13.13.2::.
+
+172.1/3
+X'Overlaps_Storage
+ For a prefix X that denotes an object:
+
+172.2/3
+ X'Overlaps_Storage denotes a function with the following
+ specification:
+
+172.3/3
+ function X'Overlaps_Storage (Arg : any_type)
+ return Boolean
+
+172.4/3
+ The actual parameter shall be a name that denotes an
+ object. The object denoted by the actual parameter can
+ be of any type. This function evaluates the names of the
+ objects involved and returns True if the representation
+ of the object denoted by the actual parameter shares at
+ least one bit with the representation of the object
+ denoted by X; otherwise, it returns False. See *note
+ 13.3::.
+
+173/1
+D'Partition_Id
+ For a prefix D that denotes a library-level declaration,
+ excepting a declaration of or within a declared-pure
+ library unit:
+
+174
+ Denotes a value of the type universal_integer that
+ identifies the partition in which D was elaborated. If D
+ denotes the declaration of a remote call interface
+ library unit (see *note E.2.3::) the given partition is
+ the one where the body of D was elaborated. See *note
+ E.1::.
+
+175
+S'Pos
+ For every discrete subtype S:
+
+176
+ S'Pos denotes a function with the following
+ specification:
+
+177
+ function S'Pos(Arg : S'Base)
+ return universal_integer
+
+178
+ This function returns the position number of the value of
+ Arg, as a value of type universal_integer. See *note
+ 3.5.5::.
+
+179
+R.C'Position
+ For a component C of a composite, non-array object R:
+
+180/2
+ If the nondefault bit ordering applies to the composite
+ type, and if a component_clause specifies the placement
+ of C, denotes the value given for the position of the
+ component_clause; otherwise, denotes the same value as
+ R.C'Address - R'Address. The value of this attribute is
+ of the type universal_integer. See *note 13.5.2::.
+
+181
+S'Pred
+ For every scalar subtype S:
+
+182
+ S'Pred denotes a function with the following
+ specification:
+
+183
+ function S'Pred(Arg : S'Base)
+ return S'Base
+
+184
+ For an enumeration type, the function returns the value
+ whose position number is one less than that of the value
+ of Arg; Constraint_Error is raised if there is no such
+ value of the type. For an integer type, the function
+ returns the result of subtracting one from the value of
+ Arg. For a fixed point type, the function returns the
+ result of subtracting small from the value of Arg. For a
+ floating point type, the function returns the machine
+ number (as defined in *note 3.5.7::) immediately below
+ the value of Arg; Constraint_Error is raised if there is
+ no such machine number. See *note 3.5::.
+
+184.1/2
+P'Priority
+ For a prefix P that denotes a protected object:
+
+184.2/2
+ Denotes a non-aliased component of the protected object
+ P. This component is of type System.Any_Priority and its
+ value is the priority of P. P'Priority denotes a variable
+ if and only if P denotes a variable. A reference to this
+ attribute shall appear only within the body of P. See
+ *note D.5.2::.
+
+185/1
+A'Range
+ For a prefix A that is of an array type (after any
+ implicit dereference), or denotes a constrained array
+ subtype:
+
+186
+ A'Range is equivalent to the range A'First .. A'Last,
+ except that the prefix A is only evaluated once. See
+ *note 3.6.2::.
+
+187
+S'Range
+ For every scalar subtype S:
+
+188
+ S'Range is equivalent to the range S'First .. S'Last.
+ See *note 3.5::.
+
+189/1
+A'Range(N)
+ For a prefix A that is of an array type (after any
+ implicit dereference), or denotes a constrained array
+ subtype:
+
+190
+ A'Range(N) is equivalent to the range A'First(N) ..
+ A'Last(N), except that the prefix A is only evaluated
+ once. See *note 3.6.2::.
+
+191
+S'Class'Read
+ For every subtype S'Class of a class-wide type T'Class:
+
+192
+ S'Class'Read denotes a procedure with the following
+ specification:
+
+193/2
+ procedure S'Class'Read(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+ Item : out T'Class)
+
+194
+ Dispatches to the subprogram denoted by the Read
+ attribute of the specific type identified by the tag of
+ Item. See *note 13.13.2::.
+
+195
+S'Read
+ For every subtype S of a specific type T:
+
+196
+ S'Read denotes a procedure with the following
+ specification:
+
+197/2
+ procedure S'Read(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+ Item : out T)
+
+198
+ S'Read reads the value of Item from Stream. See *note
+ 13.13.2::.
+
+199
+S'Remainder
+ For every subtype S of a floating point type T:
+
+200
+ S'Remainder denotes a function with the following
+ specification:
+
+201
+ function S'Remainder (X, Y : T)
+ return T
+
+202
+ For nonzero Y, let v be the value X - n · Y, where n is
+ the integer nearest to the exact value of X/Y; if |n -
+ X/Y| = 1/2, then n is chosen to be even. If v is a
+ machine number of the type T, the function yields v;
+ otherwise, it yields zero. Constraint_Error is raised if
+ Y is zero. A zero result has the sign of X when
+ S'Signed_Zeros is True. See *note A.5.3::.
+
+202.1/3
+F'Result
+ For a prefix F that denotes a function declaration:
+
+202.2/3
+ Within a postcondition expression for function F, denotes
+ the result object of the function. The type of this
+ attribute is that of the function result except within a
+ Post'Class postcondition expression for a function with a
+ controlling result or with a controlling access result.
+ For a controlling result, the type of the attribute is
+ T'Class, where T is the function result type. For a
+ controlling access result, the type of the attribute is
+ an anonymous access type whose designated type is
+ T'Class, where T is the designated type of the function
+ result type. See *note 6.1.1::.
+
+203
+S'Round
+ For every decimal fixed point subtype S:
+
+204
+ S'Round denotes a function with the following
+ specification:
+
+205
+ function S'Round(X : universal_real)
+ return S'Base
+
+206
+ The function returns the value obtained by rounding X
+ (away from 0, if X is midway between two values of the
+ type of S). See *note 3.5.10::.
+
+207
+S'Rounding
+ For every subtype S of a floating point type T:
+
+208
+ S'Rounding denotes a function with the following
+ specification:
+
+209
+ function S'Rounding (X : T)
+ return T
+
+210
+ The function yields the integral value nearest to X,
+ rounding away from zero if X lies exactly halfway between
+ two integers. A zero result has the sign of X when
+ S'Signed_Zeros is True. See *note A.5.3::.
+
+211
+S'Safe_First
+ For every subtype S of a floating point type T:
+
+212
+ Yields the lower bound of the safe range (see *note
+ 3.5.7::) of the type T. If the Numerics Annex is not
+ supported, the value of this attribute is implementation
+ defined; see *note G.2.2:: for the definition that
+ applies to implementations supporting the Numerics Annex.
+ The value of this attribute is of the type
+ universal_real. See *note A.5.3::.
+
+213
+S'Safe_Last
+ For every subtype S of a floating point type T:
+
+214
+ Yields the upper bound of the safe range (see *note
+ 3.5.7::) of the type T. If the Numerics Annex is not
+ supported, the value of this attribute is implementation
+ defined; see *note G.2.2:: for the definition that
+ applies to implementations supporting the Numerics Annex.
+ The value of this attribute is of the type
+ universal_real. See *note A.5.3::.
+
+215
+S'Scale
+ For every decimal fixed point subtype S:
+
+216
+ S'Scale denotes the scale of the subtype S, defined as
+ the value N such that S'Delta = 10.0**(-N). The scale
+ indicates the position of the point relative to the
+ rightmost significant digits of values of subtype S. The
+ value of this attribute is of the type universal_integer.
+ See *note 3.5.10::.
+
+217
+S'Scaling
+ For every subtype S of a floating point type T:
+
+218
+ S'Scaling denotes a function with the following
+ specification:
+
+219
+ function S'Scaling (X : T;
+ Adjustment : universal_integer)
+ return T
+
+220
+ Let v be the value X · T'Machine_RadixAdjustment. If v
+ is a machine number of the type T, or if |v| >=
+ T'Model_Small, the function yields v; otherwise, it
+ yields either one of the machine numbers of the type T
+ adjacent to v. Constraint_Error is optionally raised if
+ v is outside the base range of S. A zero result has the
+ sign of X when S'Signed_Zeros is True. See *note
+ A.5.3::.
+
+221
+S'Signed_Zeros
+ For every subtype S of a floating point type T:
+
+222
+ Yields the value True if the hardware representation for
+ the type T has the capability of representing both
+ positively and negatively signed zeros, these being
+ generated and used by the predefined operations of the
+ type T as specified in IEC 559:1989; yields the value
+ False otherwise. The value of this attribute is of the
+ predefined type Boolean. See *note A.5.3::.
+
+223
+S'Size
+ For every subtype S:
+
+224
+ If S is definite, denotes the size (in bits) that the
+ implementation would choose for the following objects of
+ subtype S:
+
+225
+ * A record component of subtype S when the record type
+ is packed.
+
+226
+ * The formal parameter of an instance of
+ Unchecked_Conversion that converts from subtype S to
+ some other subtype.
+
+227
+ If S is indefinite, the meaning is implementation
+ defined. The value of this attribute is of the type
+ universal_integer. See *note 13.3::.
+
+228/1
+X'Size
+ For a prefix X that denotes an object:
+
+229
+ Denotes the size in bits of the representation of the
+ object. The value of this attribute is of the type
+ universal_integer. See *note 13.3::.
+
+230
+S'Small
+ For every fixed point subtype S:
+
+231
+ S'Small denotes the small of the type of S. The value of
+ this attribute is of the type universal_real. See *note
+ 3.5.10::.
+
+232
+S'Storage_Pool
+ For every access-to-object subtype S:
+
+233
+ Denotes the storage pool of the type of S. The type of
+ this attribute is Root_Storage_Pool'Class. See *note
+ 13.11::.
+
+234
+S'Storage_Size
+ For every access-to-object subtype S:
+
+235
+ Yields the result of calling
+ Storage_Size(S'Storage_Pool), which is intended to be a
+ measure of the number of storage elements reserved for
+ the pool. The type of this attribute is
+ universal_integer. See *note 13.11::.
+
+236/1
+T'Storage_Size
+ For a prefix T that denotes a task object (after any
+ implicit dereference):
+
+237
+ Denotes the number of storage elements reserved for the
+ task. The value of this attribute is of the type
+ universal_integer. The Storage_Size includes the size of
+ the task's stack, if any. The language does not specify
+ whether or not it includes other storage associated with
+ the task (such as the "task control block" used by some
+ implementations.) See *note 13.3::.
+
+237.1/3
+S'Stream_Size
+ For every subtype S of an elementary type T:
+
+237.2/3
+ Denotes the number of bits read from or written to a
+ stream by the default implementations of S'Read and
+ S'Write. Hence, the number of stream elements required
+ per item of elementary type T is:
+
+237.3/2
+ T'Stream_Size / Ada.Streams.Stream_Element'Size
+
+237.4/2
+ The value of this attribute is of type universal_integer
+ and is a multiple of Stream_Element'Size. See *note
+ 13.13.2::.
+
+238
+S'Succ
+ For every scalar subtype S:
+
+239
+ S'Succ denotes a function with the following
+ specification:
+
+240
+ function S'Succ(Arg : S'Base)
+ return S'Base
+
+241
+ For an enumeration type, the function returns the value
+ whose position number is one more than that of the value
+ of Arg; Constraint_Error is raised if there is no such
+ value of the type. For an integer type, the function
+ returns the result of adding one to the value of Arg.
+ For a fixed point type, the function returns the result
+ of adding small to the value of Arg. For a floating
+ point type, the function returns the machine number (as
+ defined in *note 3.5.7::) immediately above the value of
+ Arg; Constraint_Error is raised if there is no such
+ machine number. See *note 3.5::.
+
+242
+S'Tag
+ For every subtype S of a tagged type T (specific or
+ class-wide):
+
+243
+ S'Tag denotes the tag of the type T (or if T is
+ class-wide, the tag of the root type of the corresponding
+ class). The value of this attribute is of type Tag. See
+ *note 3.9::.
+
+244
+X'Tag
+ For a prefix X that is of a class-wide tagged type (after
+ any implicit dereference):
+
+245
+ X'Tag denotes the tag of X. The value of this attribute
+ is of type Tag. See *note 3.9::.
+
+246
+T'Terminated
+ For a prefix T that is of a task type (after any implicit
+ dereference):
+
+247
+ Yields the value True if the task denoted by T is
+ terminated, and False otherwise. The value of this
+ attribute is of the predefined type Boolean. See *note
+ 9.9::.
+
+248
+S'Truncation
+ For every subtype S of a floating point type T:
+
+249
+ S'Truncation denotes a function with the following
+ specification:
+
+250
+ function S'Truncation (X : T)
+ return T
+
+251
+ The function yields the value 'ceiling(X)' when X is
+ negative, and 'floor(X)' otherwise. A zero result has
+ the sign of X when S'Signed_Zeros is True. See *note
+ A.5.3::.
+
+252
+S'Unbiased_Rounding
+ For every subtype S of a floating point type T:
+
+253
+ S'Unbiased_Rounding denotes a function with the following
+ specification:
+
+254
+ function S'Unbiased_Rounding (X : T)
+ return T
+
+255
+ The function yields the integral value nearest to X,
+ rounding toward the even integer if X lies exactly
+ halfway between two integers. A zero result has the sign
+ of X when S'Signed_Zeros is True. See *note A.5.3::.
+
+256
+X'Unchecked_Access
+ For a prefix X that denotes an aliased view of an object:
+
+257
+ All rules and semantics that apply to X'Access (see *note
+ 3.10.2::) apply also to X'Unchecked_Access, except that,
+ for the purposes of accessibility rules and checks, it is
+ as if X were declared immediately within a library
+ package. See *note 13.10::.
+
+258
+S'Val
+ For every discrete subtype S:
+
+259
+ S'Val denotes a function with the following
+ specification:
+
+260
+ function S'Val(Arg : universal_integer)
+ return S'Base
+
+261
+ This function returns a value of the type of S whose
+ position number equals the value of Arg. See *note
+ 3.5.5::.
+
+262
+X'Valid
+ For a prefix X that denotes a scalar object (after any
+ implicit dereference):
+
+263/3
+ Yields True if and only if the object denoted by X is
+ normal, has a valid representation, and the predicate of
+ the nominal subtype of X evaluates to True. The value of
+ this attribute is of the predefined type Boolean. See
+ *note 13.9.2::.
+
+264
+S'Value
+ For every scalar subtype S:
+
+265
+ S'Value denotes a function with the following
+ specification:
+
+266
+ function S'Value(Arg : String)
+ return S'Base
+
+267
+ This function returns a value given an image of the value
+ as a String, ignoring any leading or trailing spaces.
+ See *note 3.5::.
+
+268/1
+P'Version
+ For a prefix P that statically denotes a program unit:
+
+269
+ Yields a value of the predefined type String that
+ identifies the version of the compilation unit that
+ contains the declaration of the program unit. See *note
+ E.3::.
+
+270
+S'Wide_Image
+ For every scalar subtype S:
+
+271
+ S'Wide_Image denotes a function with the following
+ specification:
+
+272
+ function S'Wide_Image(Arg : S'Base)
+ return Wide_String
+
+273/3
+ The function returns an image of the value of Arg as a
+ Wide_String. See *note 3.5::.
+
+274
+S'Wide_Value
+ For every scalar subtype S:
+
+275
+ S'Wide_Value denotes a function with the following
+ specification:
+
+276
+ function S'Wide_Value(Arg : Wide_String)
+ return S'Base
+
+277
+ This function returns a value given an image of the value
+ as a Wide_String, ignoring any leading or trailing
+ spaces. See *note 3.5::.
+
+277.1/2
+S'Wide_Wide_Image
+ For every scalar subtype S:
+
+277.2/2
+ S'Wide_Wide_Image denotes a function with the following
+ specification:
+
+277.3/2
+ function S'Wide_Wide_Image(Arg : S'Base)
+ return Wide_Wide_String
+
+277.4/2
+ The function returns an image of the value of Arg, that
+ is, a sequence of characters representing the value in
+ display form. See *note 3.5::.
+
+277.5/2
+S'Wide_Wide_Value
+ For every scalar subtype S:
+
+277.6/2
+ S'Wide_Wide_Value denotes a function with the following
+ specification:
+
+277.7/2
+ function S'Wide_Wide_Value(Arg : Wide_Wide_String)
+ return S'Base
+
+277.8/2
+ This function returns a value given an image of the value
+ as a Wide_Wide_String, ignoring any leading or trailing
+ spaces. See *note 3.5::.
+
+277.9/2
+S'Wide_Wide_Width
+ For every scalar subtype S:
+
+277.10/2
+ S'Wide_Wide_Width denotes the maximum length of a
+ Wide_Wide_String returned by S'Wide_Wide_Image over all
+ values of the subtype S. It denotes zero for a subtype
+ that has a null range. Its type is universal_integer.
+ See *note 3.5::.
+
+278
+S'Wide_Width
+ For every scalar subtype S:
+
+279
+ S'Wide_Width denotes the maximum length of a Wide_String
+ returned by S'Wide_Image over all values of the subtype
+ S. It denotes zero for a subtype that has a null range.
+ Its type is universal_integer. See *note 3.5::.
+
+280
+S'Width
+ For every scalar subtype S:
+
+281
+ S'Width denotes the maximum length of a String returned
+ by S'Image over all values of the subtype S. It denotes
+ zero for a subtype that has a null range. Its type is
+ universal_integer. See *note 3.5::.
+
+282
+S'Class'Write
+ For every subtype S'Class of a class-wide type T'Class:
+
+283
+ S'Class'Write denotes a procedure with the following
+ specification:
+
+284/2
+ procedure S'Class'Write(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+ Item : in T'Class)
+
+285
+ Dispatches to the subprogram denoted by the Write
+ attribute of the specific type identified by the tag of
+ Item. See *note 13.13.2::.
+
+286
+S'Write
+ For every subtype S of a specific type T:
+
+287
+ S'Write denotes a procedure with the following
+ specification:
+
+288/2
+ procedure S'Write(
+ Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+ Item : in T)
+
+289
+ S'Write writes the value of Item to Stream. See *note
+ 13.13.2::.
+
+\1f
+File: aarm2012.info, Node: Annex L, Next: Annex M, Prev: Annex K, Up: Top
+
+Annex L Language-Defined Pragmas
+********************************
+
+1
+This Annex summarizes the definitions given elsewhere of the
+language-defined pragmas.
+
+2
+pragma All_Calls_Remote[(library_unit_name)]; -- See *note E.2.3::.
+
+2.1/2
+pragma Assert([Check =>] boolean_expression[, [Message =>] string_
+expression]); -- See *note 11.4.2::.
+
+2.2/2
+pragma Assertion_Policy(policy_identifier); -- See *note 11.4.2::.
+
+2.3/3
+pragma Assertion_Policy(
+ assertion_aspect_mark => policy_identifier
+ {, assertion_aspect_mark => policy_identifier}); -- See *note
+11.4.2::.
+
+3/3
+This paragraph was deleted.
+
+3.1/3
+pragma Asynchronous (local_name); -- See *note J.15.13::.
+
+4/3
+This paragraph was deleted.
+
+4.1/3
+pragma Atomic (local_name); -- See *note J.15.8::.
+
+5/3
+This paragraph was deleted.
+
+5.1/3
+pragma Atomic_Components (array_local_name); -- See *note J.15.8::.
+
+6/3
+This paragraph was deleted.
+
+6.1/3
+pragma Attach_Handler (handler_name, expression); -- See *note J.15.7::.
+
+7/3
+This paragraph was deleted.
+
+8/3
+This paragraph was deleted.
+
+8.1/3
+pragma Convention([Convention =>] convention_identifier,[Entity =>]
+local_name); -- See *note J.15.5::.
+
+8.2/3
+pragma CPU (expression); -- See *note J.15.9::.
+
+8.3/3
+pragma Default_Storage_Pool (storage_pool_indicator); -- See *note
+13.11.3::.
+
+8.4/2
+pragma Detect_Blocking; -- See *note H.5::.
+
+9
+pragma Discard_Names[([On => ] local_name)]; -- See *note C.5::.
+
+9.1/3
+pragma Dispatching_Domain (expression); -- See *note J.15.10::.
+
+10
+pragma Elaborate(library_unit_name{, library_unit_name}); -- See *note
+10.2.1::.
+
+11
+pragma Elaborate_All(library_unit_name{, library_unit_name}); -- See
+*note 10.2.1::.
+
+12
+pragma Elaborate_Body[(library_unit_name)]; -- See *note 10.2.1::.
+
+13/3
+This paragraph was deleted.
+
+13.1/3
+pragma Export(
+ [Convention =>] convention_identifier, [Entity =>] local_name
+ [, [External_Name =>] external_name_string_expression]
+ [, [Link_Name =>] link_name_string_expression]); -- See *note
+J.15.5::.
+
+14/3
+This paragraph was deleted.
+
+14.1/3
+pragma Import(
+ [Convention =>] convention_identifier, [Entity =>] local_name
+ [, [External_Name =>] external_name_string_expression]
+ [, [Link_Name =>] link_name_string_expression]); -- See *note
+J.15.5::.
+
+14.2/3
+pragma Independent (component_local_name); -- See *note J.15.8::.
+
+14.3/3
+pragma Independent_Components (local_name); -- See *note J.15.8::.
+
+15/3
+This paragraph was deleted.
+
+15.1/3
+pragma Inline (name{, name}); -- See *note J.15.1::.
+
+16
+pragma Inspection_Point[(object_name {, object_name})]; -- See *note
+H.3.2::.
+
+17/3
+This paragraph was deleted.
+
+17.1/3
+pragma Interrupt_Handler (handler_name); -- See *note J.15.7::.
+
+18/3
+This paragraph was deleted.
+
+18.1/3
+pragma Interrupt_Priority [(expression);] -- See *note J.15.11::.
+
+19
+pragma Linker_Options(string_expression); -- See *note B.1::.
+
+20
+pragma List(identifier); -- See *note 2.8::.
+
+21
+pragma Locking_Policy(policy_identifier); -- See *note D.3::.
+
+21.1/3
+This paragraph was deleted.
+
+21.2/3
+pragma No_Return (procedure_local_name{, procedure_local_name}); -- See
+*note J.15.2::.
+
+22
+pragma Normalize_Scalars; -- See *note H.1::.
+
+23
+pragma Optimize(identifier); -- See *note 2.8::.
+
+24/3
+This paragraph was deleted.
+
+24.1/3
+pragma Pack (first_subtype_local_name); -- See *note J.15.3::.
+
+25
+pragma Page; -- See *note 2.8::.
+
+25.1/2
+pragma Partition_Elaboration_Policy (policy_identifier); -- See *note
+H.6::.
+
+25.2/2
+pragma Preelaborable_Initialization(direct_name); -- See *note 10.2.1::.
+
+26
+pragma Preelaborate[(library_unit_name)]; -- See *note 10.2.1::.
+
+27/3
+This paragraph was deleted.
+
+27.1/3
+pragma Priority (expression); -- See *note J.15.11::.
+
+27.2/2
+pragma Priority_Specific_Dispatching (
+ policy_identifier, first_priority_expression, last_priority_
+expression); -- See *note D.2.2::.
+
+27.3/3
+pragma Profile (profile_identifier {, profile_
+pragma_argument_association}); -- See *note 13.12::.
+
+27.4/3
+This paragraph was deleted.
+
+28
+pragma Pure[(library_unit_name)]; -- See *note 10.2.1::.
+
+29
+pragma Queuing_Policy(policy_identifier); -- See *note D.4::.
+
+29.1/3
+This paragraph was deleted.
+
+29.2/3
+pragma Relative_Deadline (relative_deadline_expression); -- See *note
+J.15.12::.
+
+30
+pragma Remote_Call_Interface[(library_unit_name)]; -- See *note E.2.3::.
+
+31
+pragma Remote_Types[(library_unit_name)]; -- See *note E.2.2::.
+
+32
+pragma Restrictions(restriction{, restriction}); -- See *note 13.12::.
+
+33
+pragma Reviewable; -- See *note H.3.1::.
+
+34
+pragma Shared_Passive[(library_unit_name)]; -- See *note E.2.1::.
+
+35/3
+This paragraph was deleted.
+
+35.1/3
+pragma Storage_Size (expression); -- See *note J.15.4::.
+
+36
+pragma Suppress(identifier); -- See *note 11.5::.
+
+37
+pragma Task_Dispatching_Policy(policy_identifier); -- See *note D.2.2::.
+
+37.1/3
+This paragraph was deleted.
+
+37.2/3
+pragma Unchecked_Union (first_subtype_local_name); -- See *note
+J.15.6::.
+
+37.3/2
+pragma Unsuppress(identifier); -- See *note 11.5::.
+
+38/3
+This paragraph was deleted.
+
+38.1/3
+pragma Volatile (local_name); -- See *note J.15.8::.
+
+39/3
+This paragraph was deleted.
+
+39.1/3
+pragma Volatile_Components (array_local_name); -- See *note J.15.8::.
+
+ _Wording Changes from Ada 83_
+
+39.a
+ Pragmas List, Page, and Optimize are now officially defined in
+ *note 2.8::, "*note 2.8:: Pragmas".
+
+\1f
+File: aarm2012.info, Node: Annex M, Next: Annex N, Prev: Annex L, Up: Top
+
+Annex M Summary of Documentation Requirements
+*********************************************
+
+1/3
+{AI05-0299-1AI05-0299-1} The Ada language allows for certain target
+machine dependences in a controlled manner. Each Ada implementation
+must document many characteristics and properties of the target system.
+This International Standard contains specific documentation
+requirements. In addition, many characteristics that require
+documentation are identified throughout this International Standard as
+being implementation defined. Finally, this International Standard
+requires documentation of whether implementation advice is followed.
+The following subclauses provide summaries of these documentation
+requirements.
+
+* Menu:
+
+* M.1 :: Specific Documentation Requirements
+* M.2 :: Implementation-Defined Characteristics
+* M.3 :: Implementation Advice
+
+\1f
+File: aarm2012.info, Node: M.1, Next: M.2, Up: Annex M
+
+M.1 Specific Documentation Requirements
+=======================================
+
+1/2
+In addition to implementation-defined characteristics, each Ada
+implementation must document various properties of the implementation:
+
+1.a/2
+ Ramification: Most of the items in this list require
+ documentation only for implementations that conform to
+ Specialized Needs Annexes.
+
+2/2
+ * The behavior of implementations in implementation-defined
+ situations shall be documented -- see *note M.2::, "*note M.2::
+ Implementation-Defined Characteristics" for a listing. See *note
+ 1.1.3::(19).
+
+3/2
+ * The set of values that a user-defined Allocate procedure needs to
+ accept for the Alignment parameter. How the standard storage pool
+ is chosen, and how storage is allocated by standard storage pools.
+ See *note 13.11::(22).
+
+4/2
+ * The algorithm used for random number generation, including a
+ description of its period. See *note A.5.2::(44).
+
+5/2
+ * The minimum time interval between calls to the time-dependent Reset
+ procedure that is guaranteed to initiate different random number
+ sequences. See *note A.5.2::(45).
+
+6/2
+ * The conditions under which Io_Exceptions.Name_Error,
+ Io_Exceptions.Use_Error, and Io_Exceptions.Device_Error are
+ propagated. See *note A.13::(15).
+
+7/2
+ * The behavior of package Environment_Variables when environment
+ variables are changed by external mechanisms. See *note
+ A.17::(30/2).
+
+8/2
+ * The overhead of calling machine-code or intrinsic subprograms. See
+ *note C.1::(6).
+
+9/2
+ * The types and attributes used in machine code insertions. See
+ *note C.1::(7).
+
+10/2
+ * The subprogram calling conventions for all supported convention
+ identifiers. See *note C.1::(8/3).
+
+11/2
+ * The mapping between the Link_Name or Ada designator and the
+ external link name. See *note C.1::(9).
+
+12/2
+ * The treatment of interrupts. See *note C.3::(22).
+
+13/2
+ * The metrics for interrupt handlers. See *note C.3.1::(16).
+
+14/3
+ * If the Ceiling_Locking policy is in effect, the default ceiling
+ priority for a protected object that specifies an interrupt handler
+ aspect. See *note C.3.2::(24/3).
+
+15/2
+ * Any circumstances when the elaboration of a preelaborated package
+ causes code to be executed. See *note C.4::(12).
+
+16/2
+ * Whether a partition can be restarted without reloading. See *note
+ C.4::(13).
+
+17/2
+ * The effect of calling Current_Task from an entry body or interrupt
+ handler. See *note C.7.1::(19).
+
+18/2
+ * For package Task_Attributes, limits on the number and size of task
+ attributes, and how to configure any limits. See *note
+ C.7.2::(19).
+
+19/2
+ * The metrics for the Task_Attributes package. See *note
+ C.7.2::(27).
+
+20/2
+ * The details of the configuration used to generate the values of all
+ metrics. See *note D::(2).
+
+21/2
+ * The maximum priority inversion a user task can experience from the
+ implementation. See *note D.2.3::(12/2).
+
+22/2
+ * The amount of time that a task can be preempted for processing on
+ behalf of lower-priority tasks. See *note D.2.3::(13/2).
+
+23/2
+ * The quantum values supported for round robin dispatching. See
+ *note D.2.5::(16/2).
+
+24/2
+ * The accuracy of the detection of the exhaustion of the budget of a
+ task for round robin dispatching. See *note D.2.5::(17/2).
+
+25/2
+ * Any conditions that cause the completion of the setting of the
+ deadline of a task to be delayed for a multiprocessor. See *note
+ D.2.6::(32/2).
+
+26/2
+ * Any conditions that cause the completion of the setting of the
+ priority of a task to be delayed for a multiprocessor. See *note
+ D.5.1::(12.1/2).
+
+27/2
+ * The metrics for Set_Priority. See *note D.5.1::(14).
+
+28/2
+ * The metrics for setting the priority of a protected object. See
+ *note D.5.2::(10).
+
+29/2
+ * On a multiprocessor, any conditions that cause the completion of an
+ aborted construct to be delayed later than what is specified for a
+ single processor. See *note D.6::(3).
+
+30/2
+ * The metrics for aborts. See *note D.6::(8).
+
+31/2
+ * The values of Time_First, Time_Last, Time_Span_First,
+ Time_Span_Last, Time_Span_Unit, and Tick for package Real_Time.
+ See *note D.8::(33).
+
+32/2
+ * The properties of the underlying time base used in package
+ Real_Time. See *note D.8::(34).
+
+33/2
+ * Any synchronization of package Real_Time with external time
+ references. See *note D.8::(35).
+
+34/2
+ * Any aspects of the external environment that could interfere with
+ package Real_Time. See *note D.8::(36/3).
+
+35/2
+ * The metrics for package Real_Time. See *note D.8::(45).
+
+36/2
+ * The minimum value of the delay expression of a
+ delay_relative_statement that causes a task to actually be blocked.
+ See *note D.9::(7).
+
+37/2
+ * The minimum difference between the value of the delay expression of
+ a delay_until_statement and the value of Real_Time.Clock, that
+ causes the task to actually be blocked. See *note D.9::(8).
+
+38/2
+ * The metrics for delay statements. See *note D.9::(13).
+
+39/2
+ * The upper bound on the duration of interrupt blocking caused by the
+ implementation. See *note D.12::(5).
+
+40/2
+ * The metrics for entry-less protected objects. See *note
+ D.12::(12).
+
+41/2
+ * The values of CPU_Time_First, CPU_Time_Last, CPU_Time_Unit, and
+ CPU_Tick of package Execution_Time. See *note D.14::(21/2).
+
+42/3
+ * The properties of the mechanism used to implement package
+ Execution_Time, including the values of the constants defined in
+ the package. See *note D.14::(22/2).
+
+43/2
+ * The metrics for execution time. See *note D.14::(27).
+
+44/2
+ * The metrics for timing events. See *note D.15::(24).
+
+44.1/3
+ * The processor(s) on which the clock interrupt is handled; the
+ processors on which each Interrupt_Id can be handled. See *note
+ D.16.1::(32).
+
+45/2
+ * Whether the RPC-receiver is invoked from concurrent tasks, and if
+ so, the number of such tasks. See *note E.5::(25).
+
+46/2
+ * Any techniques used to reduce cancellation errors in
+ Numerics.Generic_Real_Arrays shall be documented. See *note
+ G.3.1::(86/2).
+
+47/2
+ * Any techniques used to reduce cancellation errors in
+ Numerics.Generic_Complex_Arrays shall be documented. See *note
+ G.3.2::(155/2).
+
+48/2
+ * If a pragma Normalize_Scalars applies, the implicit initial values
+ of scalar subtypes shall be documented. Such a value should be an
+ invalid representation when possible; any cases when is it not
+ shall be documented. See *note H.1::(5/2).
+
+49/2
+ * The range of effects for each bounded error and each unspecified
+ effect. If the effects of a given erroneous construct are
+ constrained, the constraints shall be documented. See *note
+ H.2::(1).
+
+50/2
+ * For each inspection point, a mapping between each inspectable
+ object and the machine resources where the object's value can be
+ obtained shall be provided. See *note H.3.2::(8).
+
+51/2
+ * If a pragma Restrictions(No_Exceptions) is specified, the effects
+ of all constructs where language-defined checks are still
+ performed. See *note H.4::(25).
+
+52/2
+ * The interrupts to which a task entry may be attached. See *note
+ J.7.1::(12).
+
+53/2
+ * The type of entry call invoked for an interrupt entry. See *note
+ J.7.1::(13).
+
+\1f
+File: aarm2012.info, Node: M.2, Next: M.3, Prev: M.1, Up: Annex M
+
+M.2 Implementation-Defined Characteristics
+==========================================
+
+1/2
+The Ada language allows for certain machine dependences in a controlled
+manner. Each Ada implementation must document all
+implementation-defined characteristics:
+
+1.a
+ Ramification: It need not document unspecified
+ characteristics.
+
+1.b
+ Some of the items in this list require documentation only for
+ implementations that conform to Specialized Needs Annexes.
+
+2/2
+ * Whether or not each recommendation given in Implementation Advice
+ is followed -- see *note M.3::, "*note M.3:: Implementation Advice"
+ for a listing. See *note 1.1.2::(37).
+
+3
+ * Capacity limitations of the implementation. See *note 1.1.3::(3).
+
+4
+ * Variations from the standard that are impractical to avoid given
+ the implementation's execution environment. See *note 1.1.3::(6).
+
+5
+ * Which code_statements cause external interactions. See *note
+ 1.1.3::(10).
+
+6
+ * The coded representation for the text of an Ada program. See *note
+ 2.1::(4/3).
+
+6.1/2
+ * The semantics of an Ada program whose text is not in Normalization
+ Form KC. See *note 2.1::(4.1/3).
+
+7/2
+ * This paragraph was deleted.
+
+8
+ * The representation for an end of line. See *note 2.2::(2/3).
+
+9
+ * Maximum supported line length and lexical element length. See
+ *note 2.2::(14).
+
+10
+ * Implementation-defined pragmas. See *note 2.8::(14).
+
+11
+ * Effect of pragma Optimize. See *note 2.8::(27).
+
+11.1/2
+ * The sequence of characters of the value returned by S'Wide_Image
+ when some of the graphic characters of S'Wide_Wide_Image are not
+ defined in Wide_Character. See *note 3.5::(30/3).
+
+12/2
+ * The sequence of characters of the value returned by S'Image when
+ some of the graphic characters of S'Wide_Wide_Image are not defined
+ in Character. See *note 3.5::(37/3).
+
+13
+ * The predefined integer types declared in Standard. See *note
+ 3.5.4::(25).
+
+14
+ * Any nonstandard integer types and the operators defined for them.
+ See *note 3.5.4::(26).
+
+15
+ * Any nonstandard real types and the operators defined for them. See
+ *note 3.5.6::(8).
+
+16
+ * What combinations of requested decimal precision and range are
+ supported for floating point types. See *note 3.5.7::(7).
+
+17
+ * The predefined floating point types declared in Standard. See
+ *note 3.5.7::(16).
+
+18
+ * The small of an ordinary fixed point type. See *note 3.5.9::(8/2).
+
+19
+ * What combinations of small, range, and digits are supported for
+ fixed point types. See *note 3.5.9::(10).
+
+20/2
+ * The result of Tags.Wide_Wide_Expanded_Name for types declared
+ within an unnamed block_statement. See *note 3.9::(10).
+
+20.1/2
+ * The sequence of characters of the value returned by
+ Tags.Expanded_Name (respectively, Tags.Wide_Expanded_Name) when
+ some of the graphic characters of Tags.Wide_Wide_Expanded_Name are
+ not defined in Character (respectively, Wide_Character). See *note
+ 3.9::(10.1/2).
+
+21
+ * Implementation-defined attributes. See *note 4.1.4::(12/1).
+
+21.1/2
+ * Rounding of real static expressions which are exactly half-way
+ between two machine numbers. See *note 4.9::(38/2).
+
+22
+ * Any implementation-defined time types. See *note 9.6::(6/3).
+
+23
+ * The time base associated with relative delays. See *note
+ 9.6::(20).
+
+24
+ * The time base of the type Calendar.Time. See *note 9.6::(23).
+
+25/2
+ * The time zone used for package Calendar operations. See *note
+ 9.6::(24/2).
+
+26
+ * Any limit on delay_until_statements of select_statements. See
+ *note 9.6::(29).
+
+26.1/2
+ * The result of Calendar.Formating.Image if its argument represents
+ more than 100 hours. See *note 9.6.1::(86/2).
+
+27/3
+ * This paragraph was deleted.
+
+28
+ * The representation for a compilation. See *note 10.1::(2).
+
+29
+ * Any restrictions on compilations that contain multiple
+ compilation_units. See *note 10.1::(4).
+
+30
+ * The mechanisms for creating an environment and for adding and
+ replacing compilation units. See *note 10.1.4::(3/2).
+
+30.1/2
+ * The mechanisms for adding a compilation unit mentioned in a
+ limited_with_clause to an environment. See *note 10.1.4::(3).
+
+31
+ * The manner of explicitly assigning library units to a partition.
+ See *note 10.2::(2).
+
+32
+ * The implementation-defined means, if any, of specifying which
+ compilation units are needed by a given compilation unit. See
+ *note 10.2::(2).
+
+33
+ * The manner of designating the main subprogram of a partition. See
+ *note 10.2::(7).
+
+34
+ * The order of elaboration of library_items. See *note 10.2::(18).
+
+35
+ * Parameter passing and function return for the main subprogram. See
+ *note 10.2::(21).
+
+36
+ * The mechanisms for building and running partitions. See *note
+ 10.2::(24).
+
+37
+ * The details of program execution, including program termination.
+ See *note 10.2::(25).
+
+38
+ * The semantics of any nonactive partitions supported by the
+ implementation. See *note 10.2::(28/3).
+
+39
+ * The information returned by Exception_Message. See *note
+ 11.4.1::(10.1/3).
+
+40/2
+ * The result of Exceptions.Wide_Wide_Exception_Name for exceptions
+ declared within an unnamed block_statement. See *note
+ 11.4.1::(12).
+
+40.1/2
+ * The sequence of characters of the value returned by
+ Exceptions.Exception_Name (respectively,
+ Exceptions.Wide_Exception_Name) when some of the graphic characters
+ of Exceptions.Wide_Wide_Exception_Name are not defined in Character
+ (respectively, Wide_Character). See *note 11.4.1::(12.1/2).
+
+41
+ * The information returned by Exception_Information. See *note
+ 11.4.1::(13/2).
+
+41.1/3
+ * Implementation-defined policy_identifiers and
+ assertion_aspect_marks allowed in a pragma Assertion_Policy. See
+ *note 11.4.2::(9/3).
+
+41.2/2
+ * The default assertion policy. See *note 11.4.2::(10).
+
+42
+ * Implementation-defined check names. See *note 11.5::(27).
+
+42.1/2
+ * Existence and meaning of second parameter of pragma Unsuppress.
+ See *note 11.5::(27.1/2).
+
+42.2/2
+ * The cases that cause conflicts between the representation of the
+ ancestors of a type_declaration. See *note 13.1::(13.1/3).
+
+43/3
+ * The interpretation of each representation aspect. See *note
+ 13.1::(20).
+
+44/3
+ * Any restrictions placed upon the specification of representation
+ aspects. See *note 13.1::(20).
+
+44.1/3
+ * Implementation-defined aspects, inluding the syntax for specifying
+ such aspects and the legality rules for such aspects. See *note
+ 13.1.1::(38).
+
+44.2/2
+ * The set of machine scalars. See *note 13.3::(8.1/3).
+
+45
+ * The meaning of Size for indefinite subtypes. See *note 13.3::(48).
+
+46
+ * The default external representation for a type tag. See *note
+ 13.3::(75/3).
+
+47
+ * What determines whether a compilation unit is the same in two
+ different partitions. See *note 13.3::(76).
+
+48
+ * Implementation-defined components. See *note 13.5.1::(15).
+
+49
+ * If Word_Size = Storage_Unit, the default bit ordering. See *note
+ 13.5.3::(5).
+
+50/2
+ * The contents of the visible part of package System. See *note
+ 13.7::(2).
+
+50.1/2
+ * The range of Storage_Elements.Storage_Offset, the modulus of
+ Storage_Elements.Storage_Element, and the declaration of
+ Storage_Elements.Integer_Address.. See *note 13.7.1::(11).
+
+51
+ * The contents of the visible part of package System.Machine_Code,
+ and the meaning of code_statements. See *note 13.8::(7).
+
+51.1/2
+ * The result of unchecked conversion for instances with scalar result
+ types whose result is not defined by the language. See *note
+ 13.9::(11).
+
+52/2
+ * The effect of unchecked conversion for instances with nonscalar
+ result types whose effect is not defined by the language. See
+ *note 13.9::(11).
+
+53/2
+ * This paragraph was deleted.
+
+54
+ * Whether or not the implementation provides user-accessible names
+ for the standard pool type(s). See *note 13.11::(17).
+
+55/2
+ * The meaning of Storage_Size when neither the Storage_Size nor the
+ Storage_Pool is specified for an access type. See *note
+ 13.11::(18).
+
+56/2
+ * This paragraph was deleted.
+
+57/3
+ * This paragraph was deleted.
+
+57.1/3
+ * Implementation-defined restrictions allowed in a pragma
+ Restrictions. See *note 13.12::(8.7/3).
+
+58
+ * The consequences of violating limitations on Restrictions pragmas.
+ See *note 13.12::(9).
+
+58.1/3
+ * Implementation-defined usage profiles allowed in a pragma Profile.
+ See *note 13.12::(15).
+
+59/2
+ * The contents of the stream elements read and written by the Read
+ and Write attributes of elementary types. See *note 13.13.2::(9).
+
+60
+ * The names and characteristics of the numeric subtypes declared in
+ the visible part of package Standard. See *note A.1::(3).
+
+60.1/2
+ * The values returned by Strings.Hash. See *note A.4.9::(3/2).
+
+61
+ * The accuracy actually achieved by the elementary functions. See
+ *note A.5.1::(1).
+
+62
+ * The sign of a zero result from some of the operators or functions
+ in Numerics.Generic_Elementary_Functions, when
+ Float_Type'Signed_Zeros is True. See *note A.5.1::(46).
+
+63
+ * The value of Numerics.Float_Random.Max_Image_Width. See *note
+ A.5.2::(27).
+
+64
+ * The value of Numerics.Discrete_Random.Max_Image_Width. See *note
+ A.5.2::(27).
+
+65/2
+ * This paragraph was deleted.
+
+66
+ * The string representation of a random number generator's state.
+ See *note A.5.2::(38).
+
+67/2
+ * This paragraph was deleted.
+
+68
+ * The values of the Model_Mantissa, Model_Emin, Model_Epsilon, Model,
+ Safe_First, and Safe_Last attributes, if the Numerics Annex is not
+ supported. See *note A.5.3::(72).
+
+69/2
+ * This paragraph was deleted.
+
+70
+ * The value of Buffer_Size in Storage_IO. See *note A.9::(10).
+
+71/2
+ * The external files associated with the standard input, standard
+ output, and standard error files. See *note A.10::(5).
+
+72
+ * The accuracy of the value produced by Put. See *note A.10.9::(36).
+
+72.1/1
+ * Current size for a stream file for which positioning is not
+ supported. See *note A.12.1::(1.1/1).
+
+73/2
+ * The meaning of Argument_Count, Argument, and Command_Name for
+ package Command_Line. The bounds of type Command_Line.Exit_Status.
+ See *note A.15::(1).
+
+73.1/2
+ * The interpretation of file names and directory names. See *note
+ A.16::(46/2).
+
+73.2/2
+ * The maximum value for a file size in Directories. See *note
+ A.16::(87/2).
+
+73.3/2
+ * The result for Directories.Size for a directory or special file See
+ *note A.16::(93/2).
+
+73.4/2
+ * The result for Directories.Modification_Time for a directory or
+ special file. See *note A.16::(95/2).
+
+73.5/2
+ * The interpretation of a nonnull search pattern in Directories. See
+ *note A.16::(104/3).
+
+73.6/2
+ * The results of a Directories search if the contents of the
+ directory are altered while a search is in progress. See *note
+ A.16::(110/3).
+
+73.7/2
+ * The definition and meaning of an environment variable. See *note
+ A.17::(1/2).
+
+73.8/2
+ * The circumstances where an environment variable cannot be defined.
+ See *note A.17::(16/2).
+
+73.9/2
+ * Environment names for which Set has the effect of Clear. See *note
+ A.17::(17/2).
+
+73.10/2
+ * The value of Containers.Hash_Type'Modulus. The value of
+ Containers.Count_Type'Last. See *note A.18.1::(7/2).
+
+74
+ * Implementation-defined convention names. See *note B.1::(11/3).
+
+75
+ * The meaning of link names. See *note B.1::(36).
+
+76
+ * The manner of choosing link names when neither the link name nor
+ the address of an imported or exported entity is specified. See
+ *note B.1::(36).
+
+77
+ * The effect of pragma Linker_Options. See *note B.1::(37).
+
+78
+ * The contents of the visible part of package Interfaces and its
+ language-defined descendants. See *note B.2::(1).
+
+79/2
+ * Implementation-defined children of package Interfaces. See *note
+ B.2::(11).
+
+79.1/2
+ * The definitions of certain types and constants in Interfaces.C. See
+ *note B.3::(41).
+
+80/1
+ * The types Floating, Long_Floating, Binary, Long_Binary,
+ Decimal_Element, and COBOL_Character; and the initializations of
+ the variables Ada_To_COBOL and COBOL_To_Ada, in Interfaces.COBOL.
+ See *note B.4::(50).
+
+80.1/1
+ * The types Fortran_Integer, Real, Double_Precision, and
+ Character_Set in Interfaces.Fortran. See *note B.5::(17).
+
+81/2
+ * Implementation-defined intrinsic subprograms. See *note
+ C.1::(1/3).
+
+82/2
+ * This paragraph was deleted.
+
+83/2
+ * This paragraph was deleted.
+
+83.1/3
+ * Any restrictions on a protected procedure or its containing type
+ when an aspect Attach_handler or Interrupt_Handler is specified.
+ See *note C.3.1::(17).
+
+83.2/3
+ * Any other forms of interrupt handler supported by the
+ Attach_Handler and Interrupt_Handler aspects. See *note
+ C.3.1::(19).
+
+84/2
+ * This paragraph was deleted.
+
+85
+ * The semantics of pragma Discard_Names. See *note C.5::(7).
+
+86
+ * The result of the Task_Identification.Image attribute. See *note
+ C.7.1::(7).
+
+87/2
+ * The value of Current_Task when in a protected entry, interrupt
+ handler, or finalization of a task attribute. See *note
+ C.7.1::(17/3).
+
+88/2
+ * This paragraph was deleted.
+
+88.1/1
+ * Granularity of locking for Task_Attributes. See *note
+ C.7.2::(16/1).
+
+89/2
+ * This paragraph was deleted.
+
+90/2
+ * This paragraph was deleted.
+
+91
+ * The declarations of Any_Priority and Priority. See *note
+ D.1::(11).
+
+92
+ * Implementation-defined execution resources. See *note D.1::(15).
+
+93
+ * Whether, on a multiprocessor, a task that is waiting for access to
+ a protected object keeps its processor busy. See *note D.2.1::(3).
+
+94/2
+ * The effect of implementation-defined execution resources on task
+ dispatching. See *note D.2.1::(9/2).
+
+95/2
+ * This paragraph was deleted.
+
+96/2
+ * This paragraph was deleted.
+
+97/2
+ * Implementation defined task dispatching policies. See *note
+ D.2.2::(19).
+
+97.1/2
+ * The value of Default_Quantum in Dispatching.Round_Robin. See *note
+ D.2.5::(4).
+
+98
+ * Implementation-defined policy_identifiers allowed in a pragma
+ Locking_Policy. See *note D.3::(4).
+
+98.1/2
+ * The locking policy if no Locking_Policy pragma applies to any unit
+ of a partition. See *note D.3::(6).
+
+99
+ * Default ceiling priorities. See *note D.3::(10/3).
+
+100
+ * The ceiling of any protected object used internally by the
+ implementation. See *note D.3::(16).
+
+101
+ * Implementation-defined queuing policies. See *note D.4::(1/3).
+
+102/2
+ * This paragraph was deleted.
+
+103
+ * Any operations that implicitly require heap storage allocation.
+ See *note D.7::(8).
+
+103.1/2
+ * When restriction No_Task_Termination applies to a partition, what
+ happens when a task terminates. See *note D.7::(15.1/2).
+
+103.2/2
+ * The behavior when restriction Max_Storage_At_Blocking is violated.
+ See *note D.7::(17/1).
+
+103.3/2
+ * The behavior when restriction Max_Asynchronous_Select_Nesting is
+ violated. See *note D.7::(18/1).
+
+103.4/2
+ * The behavior when restriction Max_Tasks is violated. See *note
+ D.7::(19).
+
+104/2
+ * Whether the use of pragma Restrictions results in a reduction in
+ program code or data size or execution time. See *note D.7::(20).
+
+105/2
+ * This paragraph was deleted.
+
+106/2
+ * This paragraph was deleted.
+
+106.1/3
+ * The value of Barrier_Limit'Last in Synchronous_Barriers. See *note
+ D.10.1::(4/3).
+
+106.2/3
+ * When an aborted task that is waiting on a Synchronous_Barrier is
+ aborted. See *note D.10.1::(13/3).
+
+107/2
+ * This paragraph was deleted.
+
+107.1/3
+ * The processor on which a task with a CPU value of a
+ Not_A_Specific_CPU will execute when the Ravenscar profile is in
+ effect. See *note D.13::(8).
+
+107.2/3
+ * The value of Min_Handler_Ceiling in Execution_Time.Group_Budgets.
+ See *note D.14.2::(7/2).
+
+107.3/3
+ * The value of CPU_Range'Last in System.Multiprocessors. See *note
+ D.16::(4/3).
+
+107.4/3
+ * The processor on which the environment task executes in the absence
+ of a value for the aspect CPU. See *note D.16::(13/3).
+
+108
+ * The means for creating and executing distributed programs. See
+ *note E::(5).
+
+109
+ * Any events that can result in a partition becoming inaccessible.
+ See *note E.1::(7).
+
+110
+ * The scheduling policies, treatment of priorities, and management of
+ shared resources between partitions in certain cases. See *note
+ E.1::(11).
+
+111/1
+ * This paragraph was deleted.
+
+112
+ * Whether the execution of the remote subprogram is immediately
+ aborted as a result of cancellation. See *note E.4::(13).
+
+112.1/2
+ * The range of type System.RPC.Partition_Id. See *note E.5::(14).
+
+113/2
+ * This paragraph was deleted.
+
+114
+ * Implementation-defined interfaces in the PCS. See *note E.5::(26).
+
+115
+ * The values of named numbers in the package Decimal. See *note
+ F.2::(7).
+
+116
+ * The value of Max_Picture_Length in the package Text_IO.Editing See
+ *note F.3.3::(16).
+
+117
+ * The value of Max_Picture_Length in the package Wide_Text_IO.Editing
+ See *note F.3.4::(5).
+
+117.1/2
+ * The value of Max_Picture_Length in the package
+ Wide_Wide_Text_IO.Editing See *note F.3.5::(5).
+
+118
+ * The accuracy actually achieved by the complex elementary functions
+ and by other complex arithmetic operations. See *note G.1::(1).
+
+119
+ * The sign of a zero result (or a component thereof) from any
+ operator or function in Numerics.Generic_Complex_Types, when
+ Real'Signed_Zeros is True. See *note G.1.1::(53).
+
+120
+ * The sign of a zero result (or a component thereof) from any
+ operator or function in
+ Numerics.Generic_Complex_Elementary_Functions, when
+ Complex_Types.Real'Signed_Zeros is True. See *note G.1.2::(45).
+
+121
+ * Whether the strict mode or the relaxed mode is the default. See
+ *note G.2::(2).
+
+122
+ * The result interval in certain cases of fixed-to-float conversion.
+ See *note G.2.1::(10).
+
+123
+ * The result of a floating point arithmetic operation in overflow
+ situations, when the Machine_Overflows attribute of the result type
+ is False. See *note G.2.1::(13).
+
+124
+ * The result interval for division (or exponentiation by a negative
+ exponent), when the floating point hardware implements division as
+ multiplication by a reciprocal. See *note G.2.1::(16).
+
+125
+ * The definition of close result set, which determines the accuracy
+ of certain fixed point multiplications and divisions. See *note
+ G.2.3::(5).
+
+126
+ * Conditions on a universal_real operand of a fixed point
+ multiplication or division for which the result shall be in the
+ perfect result set. See *note G.2.3::(22).
+
+127
+ * The result of a fixed point arithmetic operation in overflow
+ situations, when the Machine_Overflows attribute of the result type
+ is False. See *note G.2.3::(27).
+
+128
+ * The result of an elementary function reference in overflow
+ situations, when the Machine_Overflows attribute of the result type
+ is False. See *note G.2.4::(4).
+
+129
+ * The value of the angle threshold, within which certain elementary
+ functions, complex arithmetic operations, and complex elementary
+ functions yield results conforming to a maximum relative error
+ bound. See *note G.2.4::(10).
+
+130
+ * The accuracy of certain elementary functions for parameters beyond
+ the angle threshold. See *note G.2.4::(10).
+
+131
+ * The result of a complex arithmetic operation or complex elementary
+ function reference in overflow situations, when the
+ Machine_Overflows attribute of the corresponding real type is
+ False. See *note G.2.6::(5).
+
+132
+ * The accuracy of certain complex arithmetic operations and certain
+ complex elementary functions for parameters (or components thereof)
+ beyond the angle threshold. See *note G.2.6::(8).
+
+132.1/2
+ * The accuracy requirements for the subprograms Solve, Inverse,
+ Determinant, Eigenvalues and Eigensystem for type Real_Matrix. See
+ *note G.3.1::(81/2).
+
+132.2/2
+ * The accuracy requirements for the subprograms Solve, Inverse,
+ Determinant, Eigenvalues and Eigensystem for type Complex_Matrix.
+ See *note G.3.2::(149/2).
+
+133/2
+ * This paragraph was deleted.
+
+134/2
+ * This paragraph was deleted.
+
+135/2
+ * This paragraph was deleted.
+
+136/2
+ * This paragraph was deleted.
+
+136.1/2
+ * Implementation-defined policy_identifiers allowed in a pragma
+ Partition_Elaboration_Policy. See *note H.6::(4/2).
+
+\1f
+File: aarm2012.info, Node: M.3, Prev: M.2, Up: Annex M
+
+M.3 Implementation Advice
+=========================
+
+1/2
+This International Standard sometimes gives advice about handling
+certain target machine dependences. Each Ada implementation must
+document whether that advice is followed:
+
+1.a/2
+ Ramification: Some of the items in this list require
+ documentation only for implementations that conform to
+ Specialized Needs Annexes.
+
+2/2
+ * Program_Error should be raised when an unsupported Specialized
+ Needs Annex feature is used at run time. See *note 1.1.3::(20).
+
+3/2
+ * Implementation-defined extensions to the functionality of a
+ language-defined library unit should be provided by adding children
+ to the library unit. See *note 1.1.3::(21).
+
+4/2
+ * If a bounded error or erroneous execution is detected,
+ Program_Error should be raised. See *note 1.1.5::(12).
+
+5/2
+ * Implementation-defined pragmas should have no semantic effect for
+ error-free programs. See *note 2.8::(16/3).
+
+6/2
+ * Implementation-defined pragmas should not make an illegal program
+ legal, unless they complete a declaration or configure the
+ library_items in an environment. See *note 2.8::(19).
+
+7/2
+ * Long_Integer should be declared in Standard if the target supports
+ 32-bit arithmetic. No other named integer subtypes should be
+ declared in Standard. See *note 3.5.4::(28).
+
+8/2
+ * For a two's complement target, modular types with a binary modulus
+ up to System.Max_Int*2+2 should be supported. A nonbinary modulus
+ up to Integer'Last should be supported. See *note 3.5.4::(29).
+
+9/2
+ * Program_Error should be raised for the evaluation of S'Pos for an
+ enumeration type, if the value of the operand does not correspond
+ to the internal code for any enumeration literal of the type. See
+ *note 3.5.5::(8).
+
+10/2
+ * Long_Float should be declared in Standard if the target supports 11
+ or more digits of precision. No other named float subtypes should
+ be declared in Standard. See *note 3.5.7::(17).
+
+11/2
+ * Multidimensional arrays should be represented in row-major order,
+ unless the array has convention Fortran. See *note 3.6.2::(11/3).
+
+12/3
+ * Tags.Internal_Tag should return the tag of a type, if one exists,
+ whose innermost master is a master of the point of the function
+ call.. See *note 3.9::(26.1/3).
+
+13/2
+ * A real static expression with a nonformal type that is not part of
+ a larger static expression should be rounded the same as the target
+ system. See *note 4.9::(38.1/2).
+
+14/2
+ * The value of Duration'Small should be no greater than 100
+ microseconds. See *note 9.6::(30).
+
+15/2
+ * The time base for delay_relative_statements should be monotonic.
+ See *note 9.6::(31).
+
+16/2
+ * Leap seconds should be supported if the target system supports
+ them. Otherwise, operations in Calendar.Formatting should return
+ results consistent with no leap seconds. See *note 9.6.1::(89/2).
+
+17/2
+ * When applied to a generic unit, a program unit pragma that is not a
+ library unit pragma should apply to each instance of the generic
+ unit for which there is not an overriding pragma applied directly
+ to the instance. See *note 10.1.5::(10/1).
+
+18/2
+ * A type declared in a preelaborated package should have the same
+ representation in every elaboration of a given version of the
+ package. See *note 10.2.1::(12).
+
+19/2
+ * Exception_Information should provide information useful for
+ debugging, and should include the Exception_Name and
+ Exception_Message. See *note 11.4.1::(19).
+
+20/2
+ * Exception_Message by default should be short, provide information
+ useful for debugging, and should not include the Exception_Name.
+ See *note 11.4.1::(19).
+
+21/2
+ * Code executed for checks that have been suppressed should be
+ minimized. See *note 11.5::(28).
+
+22/2
+ * The recommended level of support for all representation items
+ should be followed. See *note 13.1::(28/3).
+
+23/2
+ * Storage allocated to objects of a packed type should be minimized.
+ See *note 13.2::(6).
+
+24/3
+ * The recommended level of support for the Pack aspect should be
+ followed. See *note 13.2::(9).
+
+25/2
+ * For an array X, X'Address should point at the first component of
+ the array rather than the array bounds. See *note 13.3::(14).
+
+26/2
+ * The recommended level of support for the Address attribute should
+ be followed. See *note 13.3::(19).
+
+26.1/3
+ * For any tagged specific subtype S, S'Class'Alignment should equal
+ S'Alignment. See *note 13.3::(28).
+
+27/2
+ * The recommended level of support for the Alignment attribute should
+ be followed. See *note 13.3::(35).
+
+28/2
+ * The Size of an array object should not include its bounds. See
+ *note 13.3::(41.1/2).
+
+29/2
+ * If the Size of a subtype allows for efficient independent
+ addressability, then the Size of most objects of the subtype should
+ equal the Size of the subtype. See *note 13.3::(52).
+
+30/2
+ * A Size clause on a composite subtype should not affect the internal
+ layout of components. See *note 13.3::(53).
+
+31/2
+ * The recommended level of support for the Size attribute should be
+ followed. See *note 13.3::(56).
+
+32/2
+ * The recommended level of support for the Component_Size attribute
+ should be followed. See *note 13.3::(73).
+
+33/2
+ * The recommended level of support for
+ enumeration_representation_clauses should be followed. See *note
+ 13.4::(10).
+
+34/2
+ * The recommended level of support for record_representation_clauses
+ should be followed. See *note 13.5.1::(22).
+
+35/2
+ * If a component is represented using a pointer to the actual data of
+ the component which is contiguous with the rest of the object, then
+ the storage place attributes should reflect the place of the actual
+ data. If a component is allocated discontiguously from the rest of
+ the object, then a warning should be generated upon reference to
+ one of its storage place attributes. See *note 13.5.2::(5).
+
+36/2
+ * The recommended level of support for the nondefault bit ordering
+ should be followed. See *note 13.5.3::(8).
+
+37/2
+ * Type System.Address should be a private type. See *note
+ 13.7::(37).
+
+38/2
+ * Operations in System and its children should reflect the target
+ environment; operations that do not make sense should raise
+ Program_Error. See *note 13.7.1::(16).
+
+39/2
+ * Since the Size of an array object generally does not include its
+ bounds, the bounds should not be part of the converted data in an
+ instance of Unchecked_Conversion. See *note 13.9::(14/2).
+
+40/2
+ * There should not be unnecessary run-time checks on the result of an
+ Unchecked_Conversion; the result should be returned by reference
+ when possible. Restrictions on Unchecked_Conversions should be
+ avoided. See *note 13.9::(15).
+
+41/2
+ * The recommended level of support for Unchecked_Conversion should be
+ followed. See *note 13.9::(17).
+
+42/2
+ * Any cases in which heap storage is dynamically allocated other than
+ as part of the evaluation of an allocator should be documented.
+ See *note 13.11::(23).
+
+43/2
+ * A default storage pool for an access-to-constant type should not
+ have overhead to support deallocation of individual objects. See
+ *note 13.11::(24).
+
+44/2
+ * Usually, a storage pool for an access discriminant or access
+ parameter should be created at the point of an allocator, and be
+ reclaimed when the designated object becomes inaccessible. For
+ other anonymous access types, the pool should be created at the
+ point where the type is elaborated and need not support
+ deallocation of individual objects. See *note 13.11::(25).
+
+45/2
+ * For a standard storage pool, an instance of Unchecked_Deallocation
+ should actually reclaim the storage. See *note 13.11.2::(17).
+
+45.1/3
+ * A call on an instance of Unchecked_Deallocation with a nonnull
+ access value should raise Program_Error if the actual access type
+ of the instance is a type for which the Storage_Size has been
+ specified to be zero or is defined by the language to be zero. See
+ *note 13.11.2::(17.1/3).
+
+46/2
+ * If not specified, the value of Stream_Size for an elementary type
+ should be the number of bits that corresponds to the minimum number
+ of stream elements required by the first subtype of the type,
+ rounded up to the nearest factor or multiple of the word size that
+ is also a multiple of the stream element size. See *note
+ 13.13.2::(1.6/2).
+
+47/2
+ * The recommended level of support for the Stream_Size attribute
+ should be followed. See *note 13.13.2::(1.8/2).
+
+48/2
+ * If an implementation provides additional named predefined integer
+ types, then the names should end with "Integer". If an
+ implementation provides additional named predefined floating point
+ types, then the names should end with "Float". See *note
+ A.1::(52).
+
+49/2
+ * Implementation-defined operations on Wide_Character, Wide_String,
+ Wide_Wide_Character, and Wide_Wide_String should be child units of
+ Wide_Characters or Wide_Wide_Characters. See *note A.3.1::(7/3).
+
+49.1/3
+ * The string returned by
+ Wide_Characters.Handling.Character_Set_Version should include
+ either "10646:" or "Unicode". See *note A.3.5::(62).
+
+50/2
+ * Bounded string objects should not be implemented by implicit
+ pointers and dynamic allocation. See *note A.4.4::(106).
+
+51/2
+ * Strings.Hash should be good a hash function, returning a wide
+ spread of values for different string values, and similar strings
+ should rarely return the same value. See *note A.4.9::(12/2).
+
+51.1/3
+ * If an implementation supports other string encoding schemes, a
+ child of Ada.Strings similar to UTF_Encoding should be defined.
+ See *note A.4.11::(107/3).
+
+52/2
+ * Any storage associated with an object of type Generator of the
+ random number packages should be reclaimed on exit from the scope
+ of the object. See *note A.5.2::(46).
+
+53/2
+ * Each value of Initiator passed to Reset for the random number
+ packages should initiate a distinct sequence of random numbers, or,
+ if that is not possible, be at least a rapidly varying function of
+ the initiator value. See *note A.5.2::(47).
+
+54/2
+ * Get_Immediate should be implemented with unbuffered input; input
+ should be available immediately; line-editing should be disabled.
+ See *note A.10.7::(23).
+
+55/2
+ * Package Directories.Information should be provided to retrieve
+ other information about a file. See *note A.16::(124/2).
+
+56/3
+ * Directories.Start_Search and Directories.Search should raise
+ Name_Error for malformed patterns. See *note A.16::(125).
+
+57/2
+ * Directories.Rename should be supported at least when both New_Name
+ and Old_Name are simple names and New_Name does not identify an
+ existing external file. See *note A.16::(126/2).
+
+57.1/3
+ * Directories.Hierarchical_File_Names should be provided for systems
+ with hierarchical file naming, and should not be provided on other
+ systems. See *note A.16.1::(36/3).
+
+58/2
+ * If the execution environment supports subprocesses, the current
+ environment variables should be used to initialize the environment
+ variables of a subprocess. See *note A.17::(32/2).
+
+59/2
+ * Changes to the environment variables made outside the control of
+ Environment_Variables should be reflected immediately. See *note
+ A.17::(33/2).
+
+60/2
+ * Containers.Hash_Type'Modulus should be at least 2**32.
+ Containers.Count_Type'Last should be at least 2**31-1. See *note
+ A.18.1::(8/2).
+
+61/2
+ * The worst-case time complexity of Element for Containers.Vector
+ should be O(log N). See *note A.18.2::(256/2).
+
+62/2
+ * The worst-case time complexity of Append with Count = 1 when N is
+ less than the capacity for Containers.Vector should be O(log N).
+ See *note A.18.2::(257/2).
+
+63/2
+ * The worst-case time complexity of Prepend with Count = 1 and
+ Delete_First with Count=1 for Containers.Vectors should be O(N log
+ N). See *note A.18.2::(258/2).
+
+64/2
+ * The worst-case time complexity of a call on procedure Sort of an
+ instance of Containers.Vectors.Generic_Sorting should be O(N**2),
+ and the average time complexity should be better than O(N**2). See
+ *note A.18.2::(259/2).
+
+65/2
+ * Containers.Vectors.Generic_Sorting.Sort and
+ Containers.Vectors.Generic_Sorting.Merge should minimize copying of
+ elements. See *note A.18.2::(260/2).
+
+66/2
+ * Containers.Vectors.Move should not copy elements, and should
+ minimize copying of internal data structures. See *note
+ A.18.2::(261/2).
+
+67/2
+ * If an exception is propagated from a vector operation, no storage
+ should be lost, nor any elements removed from a vector unless
+ specified by the operation. See *note A.18.2::(262/2).
+
+68/2
+ * The worst-case time complexity of Element, Insert with Count=1, and
+ Delete with Count=1 for Containers.Doubly_Linked_Lists should be
+ O(log N). See *note A.18.3::(160/2).
+
+69/2
+ * A call on procedure Sort of an instance of
+ Containers.Doubly_Linked_Lists.Generic_Sorting should have an
+ average time complexity better than O(N**2) and worst case no worse
+ than O(N**2). See *note A.18.3::(161/2).
+
+70/2
+ * Containers.Doubly_Linked_Lists.Move should not copy elements, and
+ should minimize copying of internal data structures. See *note
+ A.18.3::(162/2).
+
+71/2
+ * If an exception is propagated from a list operation, no storage
+ should be lost, nor any elements removed from a list unless
+ specified by the operation. See *note A.18.3::(163/2).
+
+72/2
+ * Move for a map should not copy elements, and should minimize
+ copying of internal data structures. See *note A.18.4::(83/2).
+
+73/2
+ * If an exception is propagated from a map operation, no storage
+ should be lost, nor any elements removed from a map unless
+ specified by the operation. See *note A.18.4::(84/2).
+
+74/2
+ * The average time complexity of Element, Insert, Include, Replace,
+ Delete, Exclude and Find operations that take a key parameter for
+ Containers.Hashed_Maps should be O(log N). The average time
+ complexity of the subprograms of Containers.Hashed_Maps that take a
+ cursor parameter should be O(1). The average time complexity of
+ Containers.Hashed_Maps.Reserve_Capacity should be O(N). See *note
+ A.18.5::(62/2).
+
+75/2
+ * The worst-case time complexity of Element, Insert, Include,
+ Replace, Delete, Exclude and Find operations that take a key
+ parameter for Containers.Ordered_Maps should be O((log N)**2) or
+ better. The worst-case time complexity of the subprograms of
+ Containers.Ordered_Maps that take a cursor parameter should be
+ O(1). See *note A.18.6::(95/2).
+
+76/2
+ * Move for sets should not copy elements, and should minimize copying
+ of internal data structures. See *note A.18.7::(104/2).
+
+77/2
+ * If an exception is propagated from a set operation, no storage
+ should be lost, nor any elements removed from a set unless
+ specified by the operation. See *note A.18.7::(105/2).
+
+78/2
+ * The average time complexity of the Insert, Include, Replace,
+ Delete, Exclude and Find operations of Containers.Hashed_Sets that
+ take an element parameter should be O(log N). The average time
+ complexity of the subprograms of Containers.Hashed_Sets that take a
+ cursor parameter should be O(1). The average time complexity of
+ Containers.Hashed_Sets.Reserve_Capacity should be O(N). See *note
+ A.18.8::(88/2).
+
+79/2
+ * The worst-case time complexity of the Insert, Include, Replace,
+ Delete, Exclude and Find operations of Containers.Ordered_Sets that
+ take an element parameter should be O((log N)**2). The worst-case
+ time complexity of the subprograms of Containers.Ordered_Sets that
+ take a cursor parameter should be O(1). See *note A.18.9::(116/2).
+
+79.1/3
+ * The worst-case time complexity of the Element, Parent, First_Child,
+ Last_Child, Next_Sibling, Previous_Sibling, Insert_Child with
+ Count=1, and Delete operations of Containers.Multiway_Trees should
+ be O(log N). See *note A.18.10::(231/3).
+
+79.2/3
+ * Containers.Multiway_Trees.Move should not copy elements, and should
+ minimize copying of internal data structures. See *note
+ A.18.10::(232/3).
+
+79.3/3
+ * If an exception is propagated from a tree operation, no storage
+ should be lost, nor any elements removed from a tree unless
+ specified by the operation. See *note A.18.10::(233/3).
+
+79.4/3
+ * Containers.Indefinite_Holders.Move should not copy the element, and
+ should minimize copying of internal data structures. See *note
+ A.18.18::(73/3).
+
+79.5/3
+ * If an exception is propagated from a holder operation, no storage
+ should be lost, nor should the element be removed from a holder
+ container unless specified by the operation. See *note
+ A.18.18::(74/3).
+
+79.6/3
+ * Bounded vector objects should be implemented without implicit
+ pointers or dynamic allocation. See *note A.18.19::(16/3).
+
+79.7/3
+ * The implementation advice for procedure Move to minimize copying
+ does not apply to bounded vectors. See *note A.18.19::(17/3).
+
+79.8/3
+ * Bounded list objects should be implemented without implicit
+ pointers or dynamic allocation. See *note A.18.20::(19/3).
+
+79.9/3
+ * The implementation advice for procedure Move to minimize copying
+ does not apply to bounded lists. See *note A.18.20::(20/3).
+
+79.10/3
+ * Bounded hashed map objects should be implemented without implicit
+ pointers or dynamic allocation. See *note A.18.21::(21/3).
+
+79.11/3
+ * The implementation advice for procedure Move to minimize copying
+ does not apply to bounded hashed maps. See *note A.18.21::(22/3).
+
+79.12/3
+ * Bounded ordered map objects should be implemented without implicit
+ pointers or dynamic allocation. See *note A.18.22::(18/3).
+
+79.13/3
+ * The implementation advice for procedure Move to minimize copying
+ does not apply to bounded ordered maps. See *note A.18.22::(19/3).
+
+79.14/3
+ * Bounded hashed set objects should be implemented without implicit
+ pointers or dynamic allocation. See *note A.18.23::(20/3).
+
+79.15/3
+ * The implementation advice for procedure Move to minimize copying
+ does not apply to bounded hashed sets. See *note A.18.23::(21/3).
+
+79.16/3
+ * Bounded ordered set objects should be implemented without implicit
+ pointers or dynamic allocation. See *note A.18.24::(17/3).
+
+79.17/3
+ * The implementation advice for procedure Move to minimize copying
+ does not apply to bounded ordered sets. See *note A.18.24::(18/3).
+
+79.18/3
+ * Bounded tree objects should be implemented without implicit
+ pointers or dynamic allocation. See *note A.18.25::(19/3).
+
+79.19/3
+ * The implementation advice for procedure Move to minimize copying
+ does not apply to bounded trees. See *note A.18.25::(20/3).
+
+80/2
+ * Containers.Generic_Array_Sort and
+ Containers.Generic_Constrained_Array_Sort should have an average
+ time complexity better than O(N**2) and worst case no worse than
+ O(N**2). See *note A.18.26::(10/2).
+
+81/2
+ * Containers.Generic_Array_Sort and
+ Containers.Generic_Constrained_Array_Sort should minimize copying
+ of elements. See *note A.18.26::(11/2).
+
+81.1/3
+ * Containers.Generic_Sort should have an average time complexity
+ better than O(N**2) and worst case no worse than O(N**2). See
+ *note A.18.26::(12/3).
+
+81.2/3
+ * Containers.Generic_Sort should minimize calls to the generic formal
+ Swap. See *note A.18.26::(13/3).
+
+81.3/3
+ * Bounded queue objects should be implemented without implicit
+ pointers or dynamic allocation. See *note A.18.29::(13/3).
+
+81.4/3
+ * Bounded priority queue objects should be implemented without
+ implicit pointers or dynamic allocation. See *note
+ A.18.31::(14/3).
+
+82/3
+ * If Export is supported for a language, the main program should be
+ able to be written in that language. Subprograms named "adainit"
+ and "adafinal" should be provided for elaboration and finalization
+ of the environment task. See *note B.1::(39/3).
+
+83/3
+ * Automatic elaboration of preelaborated packages should be provided
+ when specifying the Export aspect as True is supported. See *note
+ B.1::(40/3).
+
+84/3
+ * For each supported convention L other than Intrinsic, specifying
+ the aspects Import and Export should be supported for objects of
+ L-compatible types and for subprograms, and aspect Convention
+ should be supported for L-eligible types and for subprograms. See
+ *note B.1::(41/3).
+
+85/2
+ * If an interface to C, COBOL, or Fortran is provided, the
+ corresponding package or packages described in *note Annex B::,
+ "*note Annex B:: Interface to Other Languages" should also be
+ provided. See *note B.2::(13/3).
+
+86/2
+ * The constants nul, wide_nul, char16_nul, and char32_nul in package
+ Interfaces.C should have a representation of zero. See *note
+ B.3::(62.5/3).
+
+87/2
+ * If C interfacing is supported, the interface correspondences
+ between Ada and C should be supported. See *note B.3::(71).
+
+88/2
+ * If COBOL interfacing is supported, the interface correspondences
+ between Ada and COBOL should be supported. See *note B.4::(98).
+
+89/2
+ * If Fortran interfacing is supported, the interface correspondences
+ between Ada and Fortran should be supported. See *note B.5::(26).
+
+90/2
+ * The machine code or intrinsics support should allow access to all
+ operations normally available to assembly language programmers for
+ the target environment. See *note C.1::(3).
+
+91/2
+ * Interface to assembler should be supported; the default assembler
+ should be associated with the convention identifier Assembler. See
+ *note C.1::(4/3).
+
+92/2
+ * If an entity is exported to assembly language, then the
+ implementation should allocate it at an addressable location even
+ if not otherwise referenced from the Ada code. A call to a machine
+ code or assembler subprogram should be treated as if it could read
+ or update every object that is specified as exported. See *note
+ C.1::(5).
+
+93/2
+ * Little or no overhead should be associated with calling intrinsic
+ and machine-code subprograms. See *note C.1::(10).
+
+94/2
+ * Intrinsic subprograms should be provided to access any machine
+ operations that provide special capabilities or efficiency not
+ normally available. See *note C.1::(16).
+
+95/2
+ * If the Ceiling_Locking policy is not in effect and the target
+ system allows for finer-grained control of interrupt blocking, a
+ means for the application to specify which interrupts are to be
+ blocked during protected actions should be provided. See *note
+ C.3::(28/2).
+
+96/2
+ * Interrupt handlers should be called directly by the hardware. See
+ *note C.3.1::(20).
+
+97/2
+ * Violations of any implementation-defined restrictions on interrupt
+ handlers should be detected before run time. See *note
+ C.3.1::(21).
+
+98/2
+ * If implementation-defined forms of interrupt handler procedures are
+ supported, then for each such form of a handler, a type analogous
+ to Parameterless_Handler should be specified in a child package of
+ Interrupts, with the same operations as in the predefined package
+ Interrupts. See *note C.3.2::(25).
+
+99/2
+ * Preelaborated packages should be implemented such that little or no
+ code is executed at run time for the elaboration of entities. See
+ *note C.4::(14).
+
+100/2
+ * If pragma Discard_Names applies to an entity, then the amount of
+ storage used for storing names associated with that entity should
+ be reduced. See *note C.5::(8).
+
+101/2
+ * A load or store of a volatile object whose size is a multiple of
+ System.Storage_Unit and whose alignment is nonzero, should be
+ implemented by accessing exactly the bits of the object and no
+ others. See *note C.6::(22/2).
+
+102/2
+ * A load or store of an atomic object should be implemented by a
+ single load or store instruction. See *note C.6::(23/2).
+
+103/2
+ * If the target domain requires deterministic memory use at run time,
+ storage for task attributes should be pre-allocated statically and
+ the number of attributes pre-allocated should be documented. See
+ *note C.7.2::(30).
+
+104/2
+ * Finalization of task attributes and reclamation of associated
+ storage should be performed as soon as possible after task
+ termination. See *note C.7.2::(30.1/2).
+
+105/2
+ * Names that end with "_Locking" should be used for
+ implementation-defined locking policies. See *note D.3::(17).
+
+106/2
+ * Names that end with "_Queuing" should be used for
+ implementation-defined queuing policies. See *note D.4::(16).
+
+107/2
+ * The abort_statement should not require the task executing the
+ statement to block. See *note D.6::(9).
+
+108/2
+ * On a multi-processor, the delay associated with aborting a task on
+ another processor should be bounded. See *note D.6::(10).
+
+109/2
+ * When feasible, specified restrictions should be used to produce a
+ more efficient implementation. See *note D.7::(21).
+
+110/2
+ * When appropriate, mechanisms to change the value of Tick should be
+ provided. See *note D.8::(47).
+
+111/2
+ * Calendar.Clock and Real_Time.Clock should be transformations of the
+ same time base. See *note D.8::(48).
+
+112/2
+ * The "best" time base which exists in the underlying system should
+ be available to the application through Real_Time.Clock. See *note
+ D.8::(49).
+
+112.1/3
+ * On a multiprocessor system, each processor should have a separate
+ and disjoint ready queue. See *note D.13::(9).
+
+113/2
+ * When appropriate, implementations should provide configuration
+ mechanisms to change the value of Execution_Time.CPU_Tick. See
+ *note D.14::(29/2).
+
+114/2
+ * For a timing event, the handler should be executed directly by the
+ real-time clock interrupt mechanism. See *note D.15::(25).
+
+114.1/3
+ * Each dispatching domain should have separate and disjoint ready
+ queues. See *note D.16.1::(31).
+
+115/2
+ * The PCS should allow for multiple tasks to call the RPC-receiver.
+ See *note E.5::(28).
+
+116/2
+ * The System.RPC.Write operation should raise Storage_Error if it
+ runs out of space when writing an item. See *note E.5::(29).
+
+117/2
+ * If COBOL (respectively, C) is supported in the target environment,
+ then interfacing to COBOL (respectively, C) should be supported as
+ specified in *note Annex B::. See *note F::(7/3).
+
+118/2
+ * Packed decimal should be used as the internal representation for
+ objects of subtype S when S'Machine_Radix = 10. See *note
+ F.1::(2).
+
+119/2
+ * If Fortran (respectively, C) is supported in the target
+ environment, then interfacing to Fortran (respectively, C) should
+ be supported as specified in *note Annex B::. See *note G::(7/3).
+
+120/2
+ * Mixed real and complex operations (as well as pure-imaginary and
+ complex operations) should not be performed by converting the real
+ (resp. pure-imaginary) operand to complex. See *note G.1.1::(56).
+
+121/3
+ * If Real'Signed_Zeros is True for Numerics.Generic_Complex_Types, a
+ rational treatment of the signs of zero results and result
+ components should be provided. See *note G.1.1::(58).
+
+122/3
+ * If Complex_Types.Real'Signed_Zeros is True for
+ Numerics.Generic_Complex_Elementary_Functions, a rational treatment
+ of the signs of zero results and result components should be
+ provided. See *note G.1.2::(49).
+
+123/2
+ * For elementary functions, the forward trigonometric functions
+ without a Cycle parameter should not be implemented by calling the
+ corresponding version with a Cycle parameter. Log without a Base
+ parameter should not be implemented by calling Log with a Base
+ parameter. See *note G.2.4::(19).
+
+124/2
+ * For complex arithmetic, the Compose_From_Polar function without a
+ Cycle parameter should not be implemented by calling
+ Compose_From_Polar with a Cycle parameter. See *note G.2.6::(15).
+
+125/2
+ * Solve and Inverse for Numerics.Generic_Real_Arrays should be
+ implemented using established techniques such as LU decomposition
+ and the result should be refined by an iteration on the residuals.
+ See *note G.3.1::(88/3).
+
+126/2
+ * The equality operator should be used to test that a matrix in
+ Numerics.Generic_Real_Arrays is symmetric. See *note
+ G.3.1::(90/2).
+
+126.1/3
+ * An implementation should minimize the circumstances under which the
+ algorithm used for Numerics.Generic_Real_Arrays.Eigenvalues and
+ Numerics.Generic_Real_Arrays.Eigensystem fails to converge. See
+ *note G.3.1::(91/3).
+
+127/2
+ * Solve and Inverse for Numerics.Generic_Complex_Arrays should be
+ implemented using established techniques and the result should be
+ refined by an iteration on the residuals. See *note
+ G.3.2::(158/3).
+
+128/2
+ * The equality and negation operators should be used to test that a
+ matrix is Hermitian. See *note G.3.2::(160/2).
+
+128.1/3
+ * An implementation should minimize the circumstances under which the
+ algorithm used for Numerics.Generic_Complex_Arrays.Eigenvalues and
+ Numerics.Generic_Complex_Arrays.Eigensystem fails to converge. See
+ *note G.3.2::(160.1/3).
+
+129/2
+ * Mixed real and complex operations should not be performed by
+ converting the real operand to complex. See *note G.3.2::(161/2).
+
+130/2
+ * The information produced by pragma Reviewable should be provided in
+ both a human-readable and machine-readable form, and the latter
+ form should be documented. See *note H.3.1::(19).
+
+131/2
+ * Object code listings should be provided both in a symbolic format
+ and in a numeric format. See *note H.3.1::(20).
+
+132/3
+ * If the partition elaboration policy is Sequential and the
+ Environment task becomes permanently blocked during elaboration,
+ then the partition should be immediately terminated. See *note
+ H.6::(15/3).
+
+\1f
+File: aarm2012.info, Node: Annex N, Next: Annex P, Prev: Annex M, Up: Top
+
+Annex N Glossary
+****************
+
+1/2
+{AI95-00437-01AI95-00437-01} This Annex contains informal descriptions
+of some of the terms used in this International Standard. The index
+provides references to more formal definitions of all of the terms used
+in this International Standard.
+
+1.1/2
+Abstract type. An abstract type is a tagged type intended for use as an
+ancestor of other types, but which is not allowed to have objects of its
+own.
+
+2
+Access type. An access type has values that designate aliased objects.
+Access types correspond to "pointer types" or "reference types" in some
+other languages.
+
+3
+Aliased. An aliased view of an object is one that can be designated by
+an access value. Objects allocated by allocators are aliased. Objects
+can also be explicitly declared as aliased with the reserved word
+aliased. The Access attribute can be used to create an access value
+designating an aliased object.
+
+3.1/2
+Ancestor. An ancestor of a type is the type itself or, in the case of a
+type derived from other types, its parent type or one of its progenitor
+types or one of their ancestors. Note that ancestor and descendant are
+inverse relationships.
+
+4
+Array type. An array type is a composite type whose components are all
+of the same type. Components are selected by indexing.
+
+4.1/3
+Aspect. An aspect is a specifiable property of an entity. An aspect
+may be specified by an aspect_specification on the declaration of the
+entity. Some aspects may be queried via attributes.
+
+4.2/3
+Assertion. An assertion is a boolean expression that appears in any of
+the following: a pragma Assert, a predicate, a precondition, a
+postcondition, an invariant, a constraint, or a null exclusion. An
+assertion is expected to be True at run time at certain specified
+places.
+
+4.3/2
+Category (of types). A category of types is a set of types with one or
+more common properties, such as primitive operations. A category of
+types that is closed under derivation is also known as a class.
+
+5
+Character type. A character type is an enumeration type whose values
+include characters.
+
+6/2
+Class (of types). A class is a set of types that is closed under
+derivation, which means that if a given type is in the class, then all
+types derived from that type are also in the class. The set of types of
+a class share common properties, such as their primitive operations.
+
+7
+Compilation unit. The text of a program can be submitted to the
+compiler in one or more compilations. Each compilation is a succession
+of compilation_units. A compilation_unit contains either the
+declaration, the body, or a renaming of a program unit.
+
+8/2
+Composite type. A composite type may have components.
+
+9
+Construct. A construct is a piece of text (explicit or implicit) that
+is an instance of a syntactic category defined under "Syntax".
+
+9.1/3
+Container. A container is an object that contain other objects all of
+the same type, which could be class-wide. Several predefined container
+types are provided by the children of package Ada.Containers (see *note
+A.18.1::).
+
+10
+Controlled type. A controlled type supports user-defined assignment and
+finalization. Objects are always finalized before being destroyed.
+
+11
+Declaration. A declaration is a language construct that associates a
+name with (a view of) an entity. A declaration may appear explicitly in
+the program text (an explicit declaration), or may be supposed to occur
+at a given place in the text as a consequence of the semantics of
+another construct (an implicit declaration).
+
+12/2
+This paragraph was deleted.
+
+13/2
+Derived type. A derived type is a type defined in terms of one or more
+other types given in a derived type definition. The first of those
+types is the parent type of the derived type and any others are
+progenitor types. Each class containing the parent type or a progenitor
+type also contains the derived type. The derived type inherits
+properties such as components and primitive operations from the parent
+and progenitors. A type together with the types derived from it
+(directly or indirectly) form a derivation class.
+
+13.1/2
+Descendant. A type is a descendant of itself, its parent and progenitor
+types, and their ancestors. Note that descendant and ancestor are
+inverse relationships.
+
+14
+Discrete type. A discrete type is either an integer type or an
+enumeration type. Discrete types may be used, for example, in
+case_statements and as array indices.
+
+15/2
+Discriminant. A discriminant is a parameter for a composite type. It
+can control, for example, the bounds of a component of the type if the
+component is an array. A discriminant for a task type can be used to
+pass data to a task of the type upon creation.
+
+15.1/2
+Elaboration. The process by which a declaration achieves its run-time
+effect is called elaboration. Elaboration is one of the forms of
+execution.
+
+16
+Elementary type. An elementary type does not have components.
+
+17
+Enumeration type. An enumeration type is defined by an enumeration of
+its values, which may be named by identifiers or character literals.
+
+17.1/2
+Evaluation. The process by which an expression achieves its run-time
+effect is called evaluation. Evaluation is one of the forms of
+execution.
+
+18
+Exception. An exception represents a kind of exceptional situation; an
+occurrence of such a situation (at run time) is called an exception
+occurrence. To raise an exception is to abandon normal program
+execution so as to draw attention to the fact that the corresponding
+situation has arisen. Performing some actions in response to the
+arising of an exception is called handling the exception.
+
+19
+Execution. The process by which a construct achieves its run-time
+effect is called execution. Execution of a declaration is also called
+elaboration. Execution of an expression is also called evaluation.
+
+19.1/2
+Function. A function is a form of subprogram that returns a result and
+can be called as part of an expression.
+
+20
+Generic unit. A generic unit is a template for a (nongeneric) program
+unit; the template can be parameterized by objects, types, subprograms,
+and packages. An instance of a generic unit is created by a
+generic_instantiation. The rules of the language are enforced when a
+generic unit is compiled, using a generic contract model; additional
+checks are performed upon instantiation to verify the contract is met.
+That is, the declaration of a generic unit represents a contract between
+the body of the generic and instances of the generic. Generic units can
+be used to perform the role that macros sometimes play in other
+languages.
+
+20.1/2
+Incomplete type. An incomplete type gives a view of a type that reveals
+only some of its properties. The remaining properties are provided by
+the full view given elsewhere. Incomplete types can be used for
+defining recursive data structures.
+
+20.2/3
+Indexable container type. An indexable container type is one that has
+user-defined behavior for indexing, via the Constant_Indexing or
+Variable_Indexing aspects.
+
+21
+Integer type. Integer types comprise the signed integer types and the
+modular types. A signed integer type has a base range that includes
+both positive and negative numbers, and has operations that may raise an
+exception when the result is outside the base range. A modular type has
+a base range whose lower bound is zero, and has operations with
+"wraparound" semantics. Modular types subsume what are called "unsigned
+types" in some other languages.
+
+21.1/2
+Interface type. An interface type is a form of abstract tagged type
+which has no components or concrete operations except possibly null
+procedures. Interface types are used for composing other interfaces and
+tagged types and thereby provide multiple inheritance. Only an
+interface type can be used as a progenitor of another type.
+
+21.2/3
+Invariant. A invariant is an assertion that is expected to be True for
+all objects of a given private type when viewed from outside the
+defining package.
+
+21.3/3
+Iterable container type. An iterable container type is one that has
+user-defined behavior for iteration, via the Default_Iterator and
+Iterator_Element aspects.
+
+21.4/3
+Iterator. An iterator is a construct that is used to loop over the
+elements of an array or container. Iterators may be user defined, and
+may perform arbitrary computations to access elements from a container.
+
+22
+Library unit. A library unit is a separately compiled program unit, and
+is always a package, subprogram, or generic unit. Library units may
+have other (logically nested) library units as children, and may have
+other program units physically nested within them. A root library unit,
+together with its children and grandchildren and so on, form a
+subsystem.
+
+23/2
+Limited type. A limited type is a type for which copying (such as in an
+assignment_statement) is not allowed. A nonlimited type is a type for
+which copying is allowed.
+
+24
+Object. An object is either a constant or a variable. An object
+contains a value. An object is created by an object_declaration or by
+an allocator. A formal parameter is (a view of) an object. A
+subcomponent of an object is an object.
+
+24.1/2
+Overriding operation. An overriding operation is one that replaces an
+inherited primitive operation. Operations may be marked explicitly as
+overriding or not overriding.
+
+25
+Package. Packages are program units that allow the specification of
+groups of logically related entities. Typically, a package contains the
+declaration of a type (often a private type or private extension) along
+with the declarations of primitive subprograms of the type, which can be
+called from outside the package, while their inner workings remain
+hidden from outside users.
+
+25.1/2
+Parent. The parent of a derived type is the first type given in the
+definition of the derived type. The parent can be almost any kind of
+type, including an interface type.
+
+26
+Partition. A partition is a part of a program. Each partition consists
+of a set of library units. Each partition may run in a separate address
+space, possibly on a separate computer. A program may contain just one
+partition. A distributed program typically contains multiple
+partitions, which can execute concurrently.
+
+26.1/3
+Postcondition. A postcondition is an assertion that is expected to be
+True when a given subprogram returns normally.
+
+27
+Pragma. A pragma is a compiler directive. There are language-defined
+pragmas that give instructions for optimization, listing control, etc.
+An implementation may support additional (implementation-defined)
+pragmas.
+
+27.1/3
+Precondition. A precondition is an assertion that is expected to be
+True when a given subprogram is called.
+
+27.2/3
+Predicate. A predicate is an assertion that is expected to be True for
+all objects of a given subtype.
+
+28
+Primitive operations. The primitive operations of a type are the
+operations (such as subprograms) declared together with the type
+declaration. They are inherited by other types in the same class of
+types. For a tagged type, the primitive subprograms are dispatching
+subprograms, providing run-time polymorphism. A dispatching subprogram
+may be called with statically tagged operands, in which case the
+subprogram body invoked is determined at compile time. Alternatively, a
+dispatching subprogram may be called using a dispatching call, in which
+case the subprogram body invoked is determined at run time.
+
+29/2
+Private extension. A private extension is a type that extends another
+type, with the additional properties hidden from its clients.
+
+30/2
+Private type. A private type gives a view of a type that reveals only
+some of its properties. The remaining properties are provided by the
+full view given elsewhere. Private types can be used for defining
+abstractions that hide unnecessary details from their clients.
+
+30.1/2
+Procedure. A procedure is a form of subprogram that does not return a
+result and can only be called by a statement.
+
+30.2/2
+Progenitor. A progenitor of a derived type is one of the types given in
+the definition of the derived type other than the first. A progenitor
+is always an interface type. Interfaces, tasks, and protected types may
+also have progenitors.
+
+31
+Program. A program is a set of partitions, each of which may execute in
+a separate address space, possibly on a separate computer. A partition
+consists of a set of library units.
+
+32
+Program unit. A program unit is either a package, a task unit, a
+protected unit, a protected entry, a generic unit, or an explicitly
+declared subprogram other than an enumeration literal. Certain kinds of
+program units can be separately compiled. Alternatively, they can
+appear physically nested within other program units.
+
+33/2
+Protected type. A protected type is a composite type whose components
+are accessible only through one of its protected operations which
+synchronize concurrent access by multiple tasks.
+
+34
+Real type. A real type has values that are approximations of the real
+numbers. Floating point and fixed point types are real types.
+
+35
+Record extension. A record extension is a type that extends another
+type by adding additional components.
+
+36
+Record type. A record type is a composite type consisting of zero or
+more named components, possibly of different types.
+
+36.1/3
+Reference type. A reference type is one that has user-defined behavior
+for ".all", defined by the Implicit_Dereference aspect.
+
+36.2/2
+Renaming. A renaming_declaration is a declaration that does not define
+a new entity, but instead defines a view of an existing entity.
+
+37
+Scalar type. A scalar type is either a discrete type or a real type.
+
+37.1/3
+Storage pool. Each access-to-object type has an associated storage pool
+object. The storage for an object created by an allocator comes from
+the storage pool of the type of the allocator. Some storage pools may
+be partitioned into subpools in order to support finer-grained storage
+management.
+
+37.2/3
+Stream. A stream is a sequence of elements that can be used, along with
+the stream-oriented attributes, to support marshalling and unmarshalling
+of values of most types.
+
+37.3/2
+Subprogram. A subprogram is a section of a program that can be executed
+in various contexts. It is invoked by a subprogram call that may
+qualify the effect of the subprogram through the passing of parameters.
+There are two forms of subprograms: functions, which return values, and
+procedures, which do not.
+
+38/3
+Subtype. A subtype is a type together with optional constraints, null
+exclusions, and predicates, which constrain the values of the subtype to
+satisfy certain conditions. The values of a subtype are a subset of the
+values of its type.
+
+38.1/2
+Synchronized. A synchronized entity is one that will work safely with
+multiple tasks at one time. A synchronized interface can be an ancestor
+of a task or a protected type. Such a task or protected type is called
+a synchronized tagged type.
+
+39
+Tagged type. The objects of a tagged type have a run-time type tag,
+which indicates the specific type with which the object was originally
+created. An operand of a class-wide tagged type can be used in a
+dispatching call; the tag indicates which subprogram body to invoke.
+Nondispatching calls, in which the subprogram body to invoke is
+determined at compile time, are also allowed. Tagged types may be
+extended with additional components.
+
+40/2
+Task type. A task type is a composite type used to represent active
+entities which execute concurrently and which can communicate via queued
+task entries. The top-level task of a partition is called the
+environment task.
+
+41/2
+Type. Each object has a type. A type has an associated set of values,
+and a set of primitive operations which implement the fundamental
+aspects of its semantics. Types are grouped into categories. Most
+language-defined categories of types are also classes of types.
+
+42/2
+View. A view of an entity reveals some or all of the properties of the
+entity. A single entity may have multiple views.
+
+\1f
+File: aarm2012.info, Node: Annex P, Next: Annex Q, Prev: Annex N, Up: Top
+
+Annex P Syntax Summary
+**********************
+
+This Annex summarizes the complete syntax of the language. See *note
+1.1.4:: for a description of the notation used.
+
+ *note 2.3:::
+ identifier ::=
+ identifier_start {identifier_start | identifier_extend}
+
+ *note 2.3:::
+ identifier_start ::=
+ letter_uppercase
+ | letter_lowercase
+ | letter_titlecase
+ | letter_modifier
+ | letter_other
+ | number_letter
+
+ *note 2.3:::
+ identifier_extend ::=
+ mark_non_spacing
+ | mark_spacing_combining
+ | number_decimal
+ | punctuation_connector
+
+ *note 2.4:::
+ numeric_literal ::= decimal_literal | based_literal
+
+ *note 2.4.1:::
+ decimal_literal ::= numeral [.numeral] [exponent]
+
+ *note 2.4.1:::
+ numeral ::= digit {[underline] digit}
+
+ *note 2.4.1:::
+ exponent ::= E [+] numeral | E - numeral
+
+ *note 2.4.1:::
+ digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
+
+ *note 2.4.2:::
+ based_literal ::=
+ base # based_numeral [.based_numeral] # [exponent]
+
+ *note 2.4.2:::
+ base ::= numeral
+
+ *note 2.4.2:::
+ based_numeral ::=
+ extended_digit {[underline] extended_digit}
+
+ *note 2.4.2:::
+ extended_digit ::= digit | A | B | C | D | E | F
+
+ *note 2.5:::
+ character_literal ::= 'graphic_character'
+
+ *note 2.6:::
+ string_literal ::= "{string_element}"
+
+ *note 2.6:::
+ string_element ::= "" | non_quotation_mark_graphic_character
+
+ *note 2.7:::
+ comment ::= --{non_end_of_line_character}
+
+ *note 2.8:::
+ pragma ::=
+ pragma identifier [(pragma_argument_association {,
+ pragma_argument_association})];
+
+ *note 2.8:::
+ pragma_argument_association ::=
+ [pragma_argument_identifier =>] name
+ | [pragma_argument_identifier =>] expression
+ | pragma_argument_aspect_mark => name
+ | pragma_argument_aspect_mark => expression
+
+ *note 3.1:::
+ basic_declaration ::=
+ type_declaration | subtype_declaration
+ | object_declaration | number_declaration
+ | subprogram_declaration | abstract_subprogram_declaration
+ | null_procedure_declaration | expression_function_declaration
+ | package_declaration | renaming_declaration
+ | exception_declaration | generic_declaration
+ | generic_instantiation
+
+ *note 3.1:::
+ defining_identifier ::= identifier
+
+ *note 3.2.1:::
+ type_declaration ::= full_type_declaration
+ | incomplete_type_declaration
+ | private_type_declaration
+ | private_extension_declaration
+
+ *note 3.2.1:::
+ full_type_declaration ::=
+ type defining_identifier [known_discriminant_part] is
+ type_definition
+ [aspect_specification];
+ | task_type_declaration
+ | protected_type_declaration
+
+ *note 3.2.1:::
+ type_definition ::=
+ enumeration_type_definition | integer_type_definition
+ | real_type_definition | array_type_definition
+ | record_type_definition | access_type_definition
+ | derived_type_definition | interface_type_definition
+
+ *note 3.2.2:::
+ subtype_declaration ::=
+ subtype defining_identifier is subtype_indication
+ [aspect_specification];
+
+ *note 3.2.2:::
+ subtype_indication ::= [null_exclusion] subtype_mark [constraint]
+
+ *note 3.2.2:::
+ subtype_mark ::= subtype_name
+
+ *note 3.2.2:::
+ constraint ::= scalar_constraint | composite_constraint
+
+ *note 3.2.2:::
+ scalar_constraint ::=
+ range_constraint | digits_constraint | delta_constraint
+
+ *note 3.2.2:::
+ composite_constraint ::=
+ index_constraint | discriminant_constraint
+
+ *note 3.3.1:::
+ object_declaration ::=
+ defining_identifier_list : [aliased] [constant]
+ subtype_indication [:= expression]
+ [aspect_specification];
+ | defining_identifier_list : [aliased] [constant]
+ access_definition [:= expression]
+ [aspect_specification];
+ | defining_identifier_list : [aliased] [constant]
+ array_type_definition [:= expression]
+ [aspect_specification];
+ | single_task_declaration
+ | single_protected_declaration
+
+ *note 3.3.1:::
+ defining_identifier_list ::=
+ defining_identifier {, defining_identifier}
+
+ *note 3.3.2:::
+ number_declaration ::=
+ defining_identifier_list : constant := static_expression;
+
+ *note 3.4:::
+ derived_type_definition ::=
+ [abstract] [limited] new parent_subtype_indication [[and
+ interface_list] record_extension_part]
+
+ *note 3.5:::
+ range_constraint ::= range range
+
+ *note 3.5:::
+ range ::= range_attribute_reference
+ | simple_expression .. simple_expression
+
+ *note 3.5.1:::
+ enumeration_type_definition ::=
+ (enumeration_literal_specification {,
+ enumeration_literal_specification})
+
+ *note 3.5.1:::
+ enumeration_literal_specification ::= defining_identifier |
+ defining_character_literal
+
+ *note 3.5.1:::
+ defining_character_literal ::= character_literal
+
+ *note 3.5.4:::
+ integer_type_definition ::= signed_integer_type_definition |
+ modular_type_definition
+
+ *note 3.5.4:::
+ signed_integer_type_definition ::= range static_
+ simple_expression .. static_simple_expression
+
+ *note 3.5.4:::
+ modular_type_definition ::= mod static_expression
+
+ *note 3.5.6:::
+ real_type_definition ::=
+ floating_point_definition | fixed_point_definition
+
+ *note 3.5.7:::
+ floating_point_definition ::=
+ digits static_expression [real_range_specification]
+
+ *note 3.5.7:::
+ real_range_specification ::=
+ range static_simple_expression .. static_simple_expression
+
+ *note 3.5.9:::
+ fixed_point_definition ::= ordinary_fixed_point_definition |
+ decimal_fixed_point_definition
+
+ *note 3.5.9:::
+ ordinary_fixed_point_definition ::=
+ delta static_expression real_range_specification
+
+ *note 3.5.9:::
+ decimal_fixed_point_definition ::=
+ delta static_expression digits static_expression [
+ real_range_specification]
+
+ *note 3.5.9:::
+ digits_constraint ::=
+ digits static_expression [range_constraint]
+
+ *note 3.6:::
+ array_type_definition ::=
+ unconstrained_array_definition | constrained_array_definition
+
+ *note 3.6:::
+ unconstrained_array_definition ::=
+ array(index_subtype_definition {, index_subtype_definition}) of
+ component_definition
+
+ *note 3.6:::
+ index_subtype_definition ::= subtype_mark range <>
+
+ *note 3.6:::
+ constrained_array_definition ::=
+ array (discrete_subtype_definition {,
+ discrete_subtype_definition}) of component_definition
+
+ *note 3.6:::
+ discrete_subtype_definition ::= discrete_subtype_indication | range
+
+ *note 3.6:::
+ component_definition ::=
+ [aliased] subtype_indication
+ | [aliased] access_definition
+
+ *note 3.6.1:::
+ index_constraint ::= (discrete_range {, discrete_range})
+
+ *note 3.6.1:::
+ discrete_range ::= discrete_subtype_indication | range
+
+ *note 3.7:::
+ discriminant_part ::= unknown_discriminant_part |
+ known_discriminant_part
+
+ *note 3.7:::
+ unknown_discriminant_part ::= (<>)
+
+ *note 3.7:::
+ known_discriminant_part ::=
+ (discriminant_specification {; discriminant_specification})
+
+ *note 3.7:::
+ discriminant_specification ::=
+ defining_identifier_list : [null_exclusion] subtype_mark [:=
+ default_expression]
+ | defining_identifier_list : access_definition [:=
+ default_expression]
+
+ *note 3.7:::
+ default_expression ::= expression
+
+ *note 3.7.1:::
+ discriminant_constraint ::=
+ (discriminant_association {, discriminant_association})
+
+ *note 3.7.1:::
+ discriminant_association ::=
+ [discriminant_selector_name {| discriminant_selector_name} =>]
+ expression
+
+ *note 3.8:::
+ record_type_definition ::= [[abstract] tagged] [limited]
+ record_definition
+
+ *note 3.8:::
+ record_definition ::=
+ record
+ component_list
+ end record
+ | null record
+
+ *note 3.8:::
+ component_list ::=
+ component_item {component_item}
+ | {component_item} variant_part
+ | null;
+
+ *note 3.8:::
+ component_item ::= component_declaration | aspect_clause
+
+ *note 3.8:::
+ component_declaration ::=
+ defining_identifier_list : component_definition [:=
+ default_expression]
+ [aspect_specification];
+
+ *note 3.8.1:::
+ variant_part ::=
+ case discriminant_direct_name is
+ variant
+ {variant}
+ end case;
+
+ *note 3.8.1:::
+ variant ::=
+ when discrete_choice_list =>
+ component_list
+
+ *note 3.8.1:::
+ discrete_choice_list ::= discrete_choice {| discrete_choice}
+
+ *note 3.8.1:::
+ discrete_choice ::= choice_expression | discrete_
+ subtype_indication | range | others
+
+ *note 3.9.1:::
+ record_extension_part ::= with record_definition
+
+ *note 3.9.3:::
+ abstract_subprogram_declaration ::=
+ [overriding_indicator]
+ subprogram_specification is abstract
+ [aspect_specification];
+
+ *note 3.9.4:::
+ interface_type_definition ::=
+ [limited | task | protected | synchronized] interface [and
+ interface_list]
+
+ *note 3.9.4:::
+ interface_list ::= interface_subtype_mark {and interface_
+ subtype_mark}
+
+ *note 3.10:::
+ access_type_definition ::=
+ [null_exclusion] access_to_object_definition
+ | [null_exclusion] access_to_subprogram_definition
+
+ *note 3.10:::
+ access_to_object_definition ::=
+ access [general_access_modifier] subtype_indication
+
+ *note 3.10:::
+ general_access_modifier ::= all | constant
+
+ *note 3.10:::
+ access_to_subprogram_definition ::=
+ access [protected] procedure parameter_profile
+ | access [protected] function parameter_and_result_profile
+
+ *note 3.10:::
+ null_exclusion ::= not null
+
+ *note 3.10:::
+ access_definition ::=
+ [null_exclusion] access [constant] subtype_mark
+ | [null_exclusion] access [protected] procedure parameter_profile
+ | [null_exclusion] access [protected] function
+ parameter_and_result_profile
+
+ *note 3.10.1:::
+ incomplete_type_declaration ::= type defining_identifier [
+ discriminant_part] [is tagged];
+
+ *note 3.11:::
+ declarative_part ::= {declarative_item}
+
+ *note 3.11:::
+ declarative_item ::=
+ basic_declarative_item | body
+
+ *note 3.11:::
+ basic_declarative_item ::=
+ basic_declaration | aspect_clause | use_clause
+
+ *note 3.11:::
+ body ::= proper_body | body_stub
+
+ *note 3.11:::
+ proper_body ::=
+ subprogram_body | package_body | task_body | protected_body
+
+ *note 4.1:::
+ name ::=
+ direct_name | explicit_dereference
+ | indexed_component | slice
+ | selected_component | attribute_reference
+ | type_conversion | function_call
+ | character_literal | qualified_expression
+ | generalized_reference | generalized_indexing
+
+ *note 4.1:::
+ direct_name ::= identifier | operator_symbol
+
+ *note 4.1:::
+ prefix ::= name | implicit_dereference
+
+ *note 4.1:::
+ explicit_dereference ::= name.all
+
+ *note 4.1:::
+ implicit_dereference ::= name
+
+ *note 4.1.1:::
+ indexed_component ::= prefix(expression {, expression})
+
+ *note 4.1.2:::
+ slice ::= prefix(discrete_range)
+
+ *note 4.1.3:::
+ selected_component ::= prefix . selector_name
+
+ *note 4.1.3:::
+ selector_name ::= identifier | character_literal | operator_symbol
+
+ *note 4.1.4:::
+ attribute_reference ::= prefix'attribute_designator
+
+ *note 4.1.4:::
+ attribute_designator ::=
+ identifier[(static_expression)]
+ | Access | Delta | Digits | Mod
+
+ *note 4.1.4:::
+ range_attribute_reference ::= prefix'range_attribute_designator
+
+ *note 4.1.4:::
+ range_attribute_designator ::= Range[(static_expression)]
+
+ *note 4.1.5:::
+ generalized_reference ::= reference_object_name
+
+ *note 4.1.6:::
+ generalized_indexing ::= indexable_container_object_prefix
+ actual_parameter_part
+
+ *note 4.3:::
+ aggregate ::= record_aggregate | extension_aggregate |
+ array_aggregate
+
+ *note 4.3.1:::
+ record_aggregate ::= (record_component_association_list)
+
+ *note 4.3.1:::
+ record_component_association_list ::=
+ record_component_association {, record_component_association}
+ | null record
+
+ *note 4.3.1:::
+ record_component_association ::=
+ [component_choice_list =>] expression
+ | component_choice_list => <>
+
+ *note 4.3.1:::
+ component_choice_list ::=
+ component_selector_name {| component_selector_name}
+ | others
+
+ *note 4.3.2:::
+ extension_aggregate ::=
+ (ancestor_part with record_component_association_list)
+
+ *note 4.3.2:::
+ ancestor_part ::= expression | subtype_mark
+
+ *note 4.3.3:::
+ array_aggregate ::=
+ positional_array_aggregate | named_array_aggregate
+
+ *note 4.3.3:::
+ positional_array_aggregate ::=
+ (expression, expression {, expression})
+ | (expression {, expression}, others => expression)
+ | (expression {, expression}, others => <>)
+
+ *note 4.3.3:::
+ named_array_aggregate ::=
+ (array_component_association {, array_component_association})
+
+ *note 4.3.3:::
+ array_component_association ::=
+ discrete_choice_list => expression
+ | discrete_choice_list => <>
+
+ *note 4.4:::
+ expression ::=
+ relation {and relation} | relation {and then relation}
+ | relation {or relation} | relation {or else relation}
+ | relation {xor relation}
+
+ *note 4.4:::
+ choice_expression ::=
+ choice_relation {and choice_relation}
+ | choice_relation {or choice_relation}
+ | choice_relation {xor choice_relation}
+ | choice_relation {and then choice_relation}
+ | choice_relation {or else choice_relation}
+
+ *note 4.4:::
+ choice_relation ::=
+ simple_expression [relational_operator simple_expression]
+
+ *note 4.4:::
+ relation ::=
+ simple_expression [relational_operator simple_expression]
+ | simple_expression [not] in membership_choice_list
+
+ *note 4.4:::
+ membership_choice_list ::= membership_choice {| membership_choice}
+
+ *note 4.4:::
+ membership_choice ::= choice_expression | range | subtype_mark
+
+ *note 4.4:::
+ simple_expression ::= [unary_adding_operator] term {
+ binary_adding_operator term}
+
+ *note 4.4:::
+ term ::= factor {multiplying_operator factor}
+
+ *note 4.4:::
+ factor ::= primary [** primary] | abs primary | not primary
+
+ *note 4.4:::
+ primary ::=
+ numeric_literal | null | string_literal | aggregate
+ | name | allocator | (expression)
+ | (conditional_expression) | (quantified_expression)
+
+ *note 4.5:::
+ logical_operator ::= and | or | xor
+
+ *note 4.5:::
+ relational_operator ::= = | /= | < | <= | > | >=
+
+ *note 4.5:::
+ binary_adding_operator ::= + | - | &
+
+ *note 4.5:::
+ unary_adding_operator ::= + | -
+
+ *note 4.5:::
+ multiplying_operator ::= * | / | mod | rem
+
+ *note 4.5:::
+ highest_precedence_operator ::= ** | abs | not
+
+ *note 4.5.7:::
+ conditional_expression ::= if_expression | case_expression
+
+ *note 4.5.7:::
+ if_expression ::=
+ if condition then dependent_expression
+ {elsif condition then dependent_expression}
+ [else dependent_expression]
+
+ *note 4.5.7:::
+ condition ::= boolean_expression
+
+ *note 4.5.7:::
+ case_expression ::=
+ case selecting_expression is
+ case_expression_alternative {,
+ case_expression_alternative}
+
+ *note 4.5.7:::
+ case_expression_alternative ::=
+ when discrete_choice_list =>
+ dependent_expression
+
+ *note 4.5.8:::
+ quantified_expression ::= for quantifier
+ loop_parameter_specification => predicate
+ | for quantifier iterator_specification => predicate
+
+ *note 4.5.8:::
+ quantifier ::= all | some
+
+ *note 4.5.8:::
+ predicate ::= boolean_expression
+
+ *note 4.6:::
+ type_conversion ::=
+ subtype_mark(expression)
+ | subtype_mark(name)
+
+ *note 4.7:::
+ qualified_expression ::=
+ subtype_mark'(expression) | subtype_mark'aggregate
+
+ *note 4.8:::
+ allocator ::=
+ new [subpool_specification] subtype_indication
+ | new [subpool_specification] qualified_expression
+
+ *note 4.8:::
+ subpool_specification ::= (subpool_handle_name)
+
+ *note 5.1:::
+ sequence_of_statements ::= statement {statement} {label}
+
+ *note 5.1:::
+ statement ::=
+ {label} simple_statement | {label} compound_statement
+
+ *note 5.1:::
+ simple_statement ::= null_statement
+ | assignment_statement | exit_statement
+ | goto_statement | procedure_call_statement
+ | simple_return_statement | entry_call_statement
+ | requeue_statement | delay_statement
+ | abort_statement | raise_statement
+ | code_statement
+
+ *note 5.1:::
+ compound_statement ::=
+ if_statement | case_statement
+ | loop_statement | block_statement
+ | extended_return_statement
+ | accept_statement | select_statement
+
+ *note 5.1:::
+ null_statement ::= null;
+
+ *note 5.1:::
+ label ::= <<label_statement_identifier>>
+
+ *note 5.1:::
+ statement_identifier ::= direct_name
+
+ *note 5.2:::
+ assignment_statement ::=
+ variable_name := expression;
+
+ *note 5.3:::
+ if_statement ::=
+ if condition then
+ sequence_of_statements
+ {elsif condition then
+ sequence_of_statements}
+ [else
+ sequence_of_statements]
+ end if;
+
+ *note 5.4:::
+ case_statement ::=
+ case selecting_expression is
+ case_statement_alternative
+ {case_statement_alternative}
+ end case;
+
+ *note 5.4:::
+ case_statement_alternative ::=
+ when discrete_choice_list =>
+ sequence_of_statements
+
+ *note 5.5:::
+ loop_statement ::=
+ [loop_statement_identifier:]
+ [iteration_scheme] loop
+ sequence_of_statements
+ end loop [loop_identifier];
+
+ *note 5.5:::
+ iteration_scheme ::= while condition
+ | for loop_parameter_specification
+ | for iterator_specification
+
+ *note 5.5:::
+ loop_parameter_specification ::=
+ defining_identifier in [reverse] discrete_subtype_definition
+
+ *note 5.5.2:::
+ iterator_specification ::=
+ defining_identifier in [reverse] iterator_name
+ | defining_identifier [:
+ subtype_indication] of [reverse] iterable_name
+
+ *note 5.6:::
+ block_statement ::=
+ [block_statement_identifier:]
+ [declare
+ declarative_part]
+ begin
+ handled_sequence_of_statements
+ end [block_identifier];
+
+ *note 5.7:::
+ exit_statement ::=
+ exit [loop_name] [when condition];
+
+ *note 5.8:::
+ goto_statement ::= goto label_name;
+
+ *note 6.1:::
+ subprogram_declaration ::=
+ [overriding_indicator]
+ subprogram_specification
+ [aspect_specification];
+
+ *note 6.1:::
+ subprogram_specification ::=
+ procedure_specification
+ | function_specification
+
+ *note 6.1:::
+ procedure_specification ::= procedure defining_program_unit_name
+ parameter_profile
+
+ *note 6.1:::
+ function_specification ::= function defining_designator
+ parameter_and_result_profile
+
+ *note 6.1:::
+ designator ::= [parent_unit_name . ]identifier | operator_symbol
+
+ *note 6.1:::
+ defining_designator ::= defining_program_unit_name |
+ defining_operator_symbol
+
+ *note 6.1:::
+ defining_program_unit_name ::= [parent_unit_name . ]
+ defining_identifier
+
+ *note 6.1:::
+ operator_symbol ::= string_literal
+
+ *note 6.1:::
+ defining_operator_symbol ::= operator_symbol
+
+ *note 6.1:::
+ parameter_profile ::= [formal_part]
+
+ *note 6.1:::
+ parameter_and_result_profile ::=
+ [formal_part] return [null_exclusion] subtype_mark
+ | [formal_part] return access_definition
+
+ *note 6.1:::
+ formal_part ::=
+ (parameter_specification {; parameter_specification})
+
+ *note 6.1:::
+ parameter_specification ::=
+ defining_identifier_list : [aliased] mode [null_exclusion]
+ subtype_mark [:= default_expression]
+ | defining_identifier_list : access_definition [:=
+ default_expression]
+
+ *note 6.1:::
+ mode ::= [in] | in out | out
+
+ *note 6.3:::
+ subprogram_body ::=
+ [overriding_indicator]
+ subprogram_specification
+ [aspect_specification] is
+ declarative_part
+ begin
+ handled_sequence_of_statements
+ end [designator];
+
+ *note 6.4:::
+ procedure_call_statement ::=
+ procedure_name;
+ | procedure_prefix actual_parameter_part;
+
+ *note 6.4:::
+ function_call ::=
+ function_name
+ | function_prefix actual_parameter_part
+
+ *note 6.4:::
+ actual_parameter_part ::=
+ (parameter_association {, parameter_association})
+
+ *note 6.4:::
+ parameter_association ::=
+ [formal_parameter_selector_name =>] explicit_actual_parameter
+
+ *note 6.4:::
+ explicit_actual_parameter ::= expression | variable_name
+
+ *note 6.5:::
+ simple_return_statement ::= return [expression];
+
+ *note 6.5:::
+ extended_return_object_declaration ::=
+ defining_identifier : [aliased][constant]
+ return_subtype_indication [:= expression]
+
+ *note 6.5:::
+ extended_return_statement ::=
+ return extended_return_object_declaration [do
+ handled_sequence_of_statements
+ end return];
+
+ *note 6.5:::
+ return_subtype_indication ::= subtype_indication |
+ access_definition
+
+ *note 6.7:::
+ null_procedure_declaration ::=
+ [overriding_indicator]
+ procedure_specification is null
+ [aspect_specification];
+
+ *note 6.8:::
+ expression_function_declaration ::=
+ [overriding_indicator]
+ function_specification is
+ (expression)
+ [aspect_specification];
+
+ *note 7.1:::
+ package_declaration ::= package_specification;
+
+ *note 7.1:::
+ package_specification ::=
+ package defining_program_unit_name
+ [aspect_specification] is
+ {basic_declarative_item}
+ [private
+ {basic_declarative_item}]
+ end [[parent_unit_name.]identifier]
+
+ *note 7.2:::
+ package_body ::=
+ package body defining_program_unit_name
+ [aspect_specification] is
+ declarative_part
+ [begin
+ handled_sequence_of_statements]
+ end [[parent_unit_name.]identifier];
+
+ *note 7.3:::
+ private_type_declaration ::=
+ type defining_identifier [
+ discriminant_part] is [[abstract] tagged] [limited] private
+ [aspect_specification];
+
+ *note 7.3:::
+ private_extension_declaration ::=
+ type defining_identifier [discriminant_part] is
+ [abstract] [limited | synchronized] new ancestor_
+ subtype_indication
+ [and interface_list] with private
+ [aspect_specification];
+
+ *note 8.3.1:::
+ overriding_indicator ::= [not] overriding
+
+ *note 8.4:::
+ use_clause ::= use_package_clause | use_type_clause
+
+ *note 8.4:::
+ use_package_clause ::= use package_name {, package_name};
+
+ *note 8.4:::
+ use_type_clause ::= use [all] type subtype_mark {, subtype_mark};
+
+ *note 8.5:::
+ renaming_declaration ::=
+ object_renaming_declaration
+ | exception_renaming_declaration
+ | package_renaming_declaration
+ | subprogram_renaming_declaration
+ | generic_renaming_declaration
+
+ *note 8.5.1:::
+ object_renaming_declaration ::=
+ defining_identifier : [null_exclusion]
+ subtype_mark renames object_name
+ [aspect_specification];
+ | defining_identifier : access_definition renames object_name
+ [aspect_specification];
+
+ *note 8.5.2:::
+ exception_renaming_declaration ::=
+ defining_identifier : exception renames exception_name
+ [aspect_specification];
+
+ *note 8.5.3:::
+ package_renaming_declaration ::= package
+ defining_program_unit_name renames package_name
+ [aspect_specification];
+
+ *note 8.5.4:::
+ subprogram_renaming_declaration ::=
+ [overriding_indicator]
+ subprogram_specification renames callable_entity_name
+ [aspect_specification];
+
+ *note 8.5.5:::
+ generic_renaming_declaration ::=
+ generic package
+ defining_program_unit_name renames generic_package_name
+ [aspect_specification];
+ | generic procedure
+ defining_program_unit_name renames generic_procedure_name
+ [aspect_specification];
+ | generic function
+ defining_program_unit_name renames generic_function_name
+ [aspect_specification];
+
+ *note 9.1:::
+ task_type_declaration ::=
+ task type defining_identifier [known_discriminant_part]
+ [aspect_specification] [is
+ [new interface_list with]
+ task_definition];
+
+ *note 9.1:::
+ single_task_declaration ::=
+ task defining_identifier
+ [aspect_specification][is
+ [new interface_list with]
+ task_definition];
+
+ *note 9.1:::
+ task_definition ::=
+ {task_item}
+ [ private
+ {task_item}]
+ end [task_identifier]
+
+ *note 9.1:::
+ task_item ::= entry_declaration | aspect_clause
+
+ *note 9.1:::
+ task_body ::=
+ task body defining_identifier
+ [aspect_specification] is
+ declarative_part
+ begin
+ handled_sequence_of_statements
+ end [task_identifier];
+
+ *note 9.4:::
+ protected_type_declaration ::=
+ protected type defining_identifier [known_discriminant_part]
+ [aspect_specification] is
+ [new interface_list with]
+ protected_definition;
+
+ *note 9.4:::
+ single_protected_declaration ::=
+ protected defining_identifier
+ [aspect_specification] is
+ [new interface_list with]
+ protected_definition;
+
+ *note 9.4:::
+ protected_definition ::=
+ { protected_operation_declaration }
+ [ private
+ { protected_element_declaration } ]
+ end [protected_identifier]
+
+ *note 9.4:::
+ protected_operation_declaration ::= subprogram_declaration
+ | entry_declaration
+ | aspect_clause
+
+ *note 9.4:::
+ protected_element_declaration ::= protected_operation_declaration
+ | component_declaration
+
+ *note 9.4:::
+ protected_body ::=
+ protected body defining_identifier
+ [aspect_specification] is
+ { protected_operation_item }
+ end [protected_identifier];
+
+ *note 9.4:::
+ protected_operation_item ::= subprogram_declaration
+ | subprogram_body
+ | entry_body
+ | aspect_clause
+
+ *note 9.5:::
+ synchronization_kind ::= By_Entry | By_Protected_Procedure | Optional
+
+ *note 9.5.2:::
+ entry_declaration ::=
+ [overriding_indicator]
+ entry defining_identifier [(discrete_subtype_definition)]
+ parameter_profile
+ [aspect_specification];
+
+ *note 9.5.2:::
+ accept_statement ::=
+ accept entry_direct_name [(entry_index)] parameter_profile [do
+ handled_sequence_of_statements
+ end [entry_identifier]];
+
+ *note 9.5.2:::
+ entry_index ::= expression
+
+ *note 9.5.2:::
+ entry_body ::=
+ entry defining_identifier entry_body_formal_part
+ entry_barrier is
+ declarative_part
+ begin
+ handled_sequence_of_statements
+ end [entry_identifier];
+
+ *note 9.5.2:::
+ entry_body_formal_part ::= [(entry_index_specification)]
+ parameter_profile
+
+ *note 9.5.2:::
+ entry_barrier ::= when condition
+
+ *note 9.5.2:::
+ entry_index_specification ::= for defining_identifier in
+ discrete_subtype_definition
+
+ *note 9.5.3:::
+ entry_call_statement ::= entry_name [actual_parameter_part];
+
+ *note 9.5.4:::
+ requeue_statement ::= requeue procedure_or_entry_name [with abort];
+
+ *note 9.6:::
+ delay_statement ::= delay_until_statement |
+ delay_relative_statement
+
+ *note 9.6:::
+ delay_until_statement ::= delay until delay_expression;
+
+ *note 9.6:::
+ delay_relative_statement ::= delay delay_expression;
+
+ *note 9.7:::
+ select_statement ::=
+ selective_accept
+ | timed_entry_call
+ | conditional_entry_call
+ | asynchronous_select
+
+ *note 9.7.1:::
+ selective_accept ::=
+ select
+ [guard]
+ select_alternative
+ { or
+ [guard]
+ select_alternative }
+ [ else
+ sequence_of_statements ]
+ end select;
+
+ *note 9.7.1:::
+ guard ::= when condition =>
+
+ *note 9.7.1:::
+ select_alternative ::=
+ accept_alternative
+ | delay_alternative
+ | terminate_alternative
+
+ *note 9.7.1:::
+ accept_alternative ::=
+ accept_statement [sequence_of_statements]
+
+ *note 9.7.1:::
+ delay_alternative ::=
+ delay_statement [sequence_of_statements]
+
+ *note 9.7.1:::
+ terminate_alternative ::= terminate;
+
+ *note 9.7.2:::
+ timed_entry_call ::=
+ select
+ entry_call_alternative
+ or
+ delay_alternative
+ end select;
+
+ *note 9.7.2:::
+ entry_call_alternative ::=
+ procedure_or_entry_call [sequence_of_statements]
+
+ *note 9.7.2:::
+ procedure_or_entry_call ::=
+ procedure_call_statement | entry_call_statement
+
+ *note 9.7.3:::
+ conditional_entry_call ::=
+ select
+ entry_call_alternative
+ else
+ sequence_of_statements
+ end select;
+
+ *note 9.7.4:::
+ asynchronous_select ::=
+ select
+ triggering_alternative
+ then abort
+ abortable_part
+ end select;
+
+ *note 9.7.4:::
+ triggering_alternative ::= triggering_statement [
+ sequence_of_statements]
+
+ *note 9.7.4:::
+ triggering_statement ::= procedure_or_entry_call | delay_statement
+
+ *note 9.7.4:::
+ abortable_part ::= sequence_of_statements
+
+ *note 9.8:::
+ abort_statement ::= abort task_name {, task_name};
+
+ *note 10.1.1:::
+ compilation ::= {compilation_unit}
+
+ *note 10.1.1:::
+ compilation_unit ::=
+ context_clause library_item
+ | context_clause subunit
+
+ *note 10.1.1:::
+ library_item ::= [private] library_unit_declaration
+ | library_unit_body
+ | [private] library_unit_renaming_declaration
+
+ *note 10.1.1:::
+ library_unit_declaration ::=
+ subprogram_declaration | package_declaration
+ | generic_declaration | generic_instantiation
+
+ *note 10.1.1:::
+ library_unit_renaming_declaration ::=
+ package_renaming_declaration
+ | generic_renaming_declaration
+ | subprogram_renaming_declaration
+
+ *note 10.1.1:::
+ library_unit_body ::= subprogram_body | package_body
+
+ *note 10.1.1:::
+ parent_unit_name ::= name
+
+ *note 10.1.2:::
+ context_clause ::= {context_item}
+
+ *note 10.1.2:::
+ context_item ::= with_clause | use_clause
+
+ *note 10.1.2:::
+ with_clause ::= limited_with_clause | nonlimited_with_clause
+
+ *note 10.1.2:::
+ limited_with_clause ::= limited [private] with library_unit_
+ name {, library_unit_name};
+
+ *note 10.1.2:::
+ nonlimited_with_clause ::= [private] with library_unit_
+ name {, library_unit_name};
+
+ *note 10.1.3:::
+ body_stub ::= subprogram_body_stub | package_body_stub |
+ task_body_stub | protected_body_stub
+
+ *note 10.1.3:::
+ subprogram_body_stub ::=
+ [overriding_indicator]
+ subprogram_specification is separate
+ [aspect_specification];
+
+ *note 10.1.3:::
+ package_body_stub ::=
+ package body defining_identifier is separate
+ [aspect_specification];
+
+ *note 10.1.3:::
+ task_body_stub ::=
+ task body defining_identifier is separate
+ [aspect_specification];
+
+ *note 10.1.3:::
+ protected_body_stub ::=
+ protected body defining_identifier is separate
+ [aspect_specification];
+
+ *note 10.1.3:::
+ subunit ::= separate (parent_unit_name) proper_body
+
+ *note 11.1:::
+ exception_declaration ::= defining_identifier_list : exception
+ [aspect_specification];
+
+ *note 11.2:::
+ handled_sequence_of_statements ::=
+ sequence_of_statements
+ [exception
+ exception_handler
+ {exception_handler}]
+
+ *note 11.2:::
+ exception_handler ::=
+ when [choice_parameter_specification:] exception_choice {|
+ exception_choice} =>
+ sequence_of_statements
+
+ *note 11.2:::
+ choice_parameter_specification ::= defining_identifier
+
+ *note 11.2:::
+ exception_choice ::= exception_name | others
+
+ *note 11.3:::
+ raise_statement ::= raise;
+ | raise exception_name [with string_expression];
+
+ *note 12.1:::
+ generic_declaration ::= generic_subprogram_declaration |
+ generic_package_declaration
+
+ *note 12.1:::
+ generic_subprogram_declaration ::=
+ generic_formal_part subprogram_specification
+ [aspect_specification];
+
+ *note 12.1:::
+ generic_package_declaration ::=
+ generic_formal_part package_specification;
+
+ *note 12.1:::
+ generic_formal_part ::= generic {
+ generic_formal_parameter_declaration | use_clause}
+
+ *note 12.1:::
+ generic_formal_parameter_declaration ::=
+ formal_object_declaration
+ | formal_type_declaration
+ | formal_subprogram_declaration
+ | formal_package_declaration
+
+ *note 12.3:::
+ generic_instantiation ::=
+ package defining_program_unit_name is
+ new generic_package_name [generic_actual_part]
+ [aspect_specification];
+ | [overriding_indicator]
+ procedure defining_program_unit_name is
+ new generic_procedure_name [generic_actual_part]
+ [aspect_specification];
+ | [overriding_indicator]
+ function defining_designator is
+ new generic_function_name [generic_actual_part]
+ [aspect_specification];
+
+ *note 12.3:::
+ generic_actual_part ::=
+ (generic_association {, generic_association})
+
+ *note 12.3:::
+ generic_association ::=
+ [generic_formal_parameter_selector_name =>]
+ explicit_generic_actual_parameter
+
+ *note 12.3:::
+ explicit_generic_actual_parameter ::= expression | variable_name
+ | subprogram_name | entry_name | subtype_mark
+ | package_instance_name
+
+ *note 12.4:::
+ formal_object_declaration ::=
+ defining_identifier_list : mode [null_exclusion]
+ subtype_mark [:= default_expression]
+ [aspect_specification];
+ | defining_identifier_list : mode access_definition [:=
+ default_expression]
+ [aspect_specification];
+
+ *note 12.5:::
+ formal_type_declaration ::=
+ formal_complete_type_declaration
+ | formal_incomplete_type_declaration
+
+ *note 12.5:::
+ formal_complete_type_declaration ::=
+ type defining_identifier[discriminant_part] is
+ formal_type_definition
+ [aspect_specification];
+
+ *note 12.5:::
+ formal_incomplete_type_declaration ::=
+ type defining_identifier[discriminant_part] [is tagged];
+
+ *note 12.5:::
+ formal_type_definition ::=
+ formal_private_type_definition
+ | formal_derived_type_definition
+ | formal_discrete_type_definition
+ | formal_signed_integer_type_definition
+ | formal_modular_type_definition
+ | formal_floating_point_definition
+ | formal_ordinary_fixed_point_definition
+ | formal_decimal_fixed_point_definition
+ | formal_array_type_definition
+ | formal_access_type_definition
+ | formal_interface_type_definition
+
+ *note 12.5.1:::
+ formal_private_type_definition ::= [[abstract] tagged] [limited] private
+
+ *note 12.5.1:::
+ formal_derived_type_definition ::=
+ [abstract] [limited | synchronized] new subtype_mark [[and
+ interface_list]with private]
+
+ *note 12.5.2:::
+ formal_discrete_type_definition ::= (<>)
+
+ *note 12.5.2:::
+ formal_signed_integer_type_definition ::= range <>
+
+ *note 12.5.2:::
+ formal_modular_type_definition ::= mod <>
+
+ *note 12.5.2:::
+ formal_floating_point_definition ::= digits <>
+
+ *note 12.5.2:::
+ formal_ordinary_fixed_point_definition ::= delta <>
+
+ *note 12.5.2:::
+ formal_decimal_fixed_point_definition ::= delta <> digits <>
+
+ *note 12.5.3:::
+ formal_array_type_definition ::= array_type_definition
+
+ *note 12.5.4:::
+ formal_access_type_definition ::= access_type_definition
+
+ *note 12.5.5:::
+ formal_interface_type_definition ::= interface_type_definition
+
+ *note 12.6:::
+ formal_subprogram_declaration ::=
+ formal_concrete_subprogram_declaration
+ | formal_abstract_subprogram_declaration
+
+ *note 12.6:::
+ formal_concrete_subprogram_declaration ::=
+ with subprogram_specification [is subprogram_default]
+ [aspect_specification];
+
+ *note 12.6:::
+ formal_abstract_subprogram_declaration ::=
+ with subprogram_specification is abstract [subprogram_default]
+ [aspect_specification];
+
+ *note 12.6:::
+ subprogram_default ::= default_name | <> | null
+
+ *note 12.6:::
+ default_name ::= name
+
+ *note 12.7:::
+ formal_package_declaration ::=
+ with package defining_identifier is new generic_package_name
+ formal_package_actual_part
+ [aspect_specification];
+
+ *note 12.7:::
+ formal_package_actual_part ::=
+ ([others =>] <>)
+ | [generic_actual_part]
+ | (formal_package_association {,
+ formal_package_association} [, others => <>])
+
+ *note 12.7:::
+ formal_package_association ::=
+ generic_association
+ | generic_formal_parameter_selector_name => <>
+
+ *note 13.1:::
+ aspect_clause ::= attribute_definition_clause
+ | enumeration_representation_clause
+ | record_representation_clause
+ | at_clause
+
+ *note 13.1:::
+ local_name ::= direct_name
+ | direct_name'attribute_designator
+ | library_unit_name
+
+ *note 13.1.1:::
+ aspect_specification ::=
+ with aspect_mark [=> aspect_definition] {,
+ aspect_mark [=> aspect_definition] }
+
+ *note 13.1.1:::
+ aspect_mark ::= aspect_identifier['Class]
+
+ *note 13.1.1:::
+ aspect_definition ::= name | expression | identifier
+
+ *note 13.3:::
+ attribute_definition_clause ::=
+ for local_name'attribute_designator use expression;
+ | for local_name'attribute_designator use name;
+
+ *note 13.4:::
+ enumeration_representation_clause ::=
+ for first_subtype_local_name use enumeration_aggregate;
+
+ *note 13.4:::
+ enumeration_aggregate ::= array_aggregate
+
+ *note 13.5.1:::
+ record_representation_clause ::=
+ for first_subtype_local_name use
+ record [mod_clause]
+ {component_clause}
+ end record;
+
+ *note 13.5.1:::
+ component_clause ::=
+ component_local_name at position range first_bit .. last_bit;
+
+ *note 13.5.1:::
+ position ::= static_expression
+
+ *note 13.5.1:::
+ first_bit ::= static_simple_expression
+
+ *note 13.5.1:::
+ last_bit ::= static_simple_expression
+
+ *note 13.8:::
+ code_statement ::= qualified_expression;
+
+ *note 13.11.3:::
+ storage_pool_indicator ::= storage_pool_name | null
+
+ *note 13.12:::
+ restriction ::= restriction_identifier
+ | restriction_parameter_identifier =>
+ restriction_parameter_argument
+
+ *note 13.12:::
+ restriction_parameter_argument ::= name | expression
+
+ *note J.3:::
+ delta_constraint ::= delta static_expression [range_constraint]
+
+ *note J.7:::
+ at_clause ::= for direct_name use at expression;
+
+ *note J.8:::
+ mod_clause ::= at mod static_expression;
+
+Syntax Cross Reference
+
+
+1/3
+{AI05-0299-1AI05-0299-1} In the following syntax cross reference, each
+syntactic category is followed by the subclause number where it is
+defined. In addition, each syntactic category S is followed by a list
+of the categories that use S in their definitions. For example, the
+first listing below shows that abort_statement appears in the definition
+of simple_statement.
+
+ abort_statement *note 9.8::
+ simple_statement *note 5.1::
+
+ abortable_part *note 9.7.4::
+ asynchronous_select *note 9.7.4::
+
+ abstract_subprogram_declaration *note 3.9.3::
+ basic_declaration *note 3.1::
+
+ accept_alternative *note 9.7.1::
+ select_alternative *note 9.7.1::
+
+ accept_statement *note 9.5.2::
+ accept_alternative *note 9.7.1::
+ compound_statement *note 5.1::
+
+ access_definition *note 3.10::
+ component_definition *note 3.6::
+ discriminant_specification *note 3.7::
+ formal_object_declaration *note 12.4::
+ object_declaration *note 3.3.1::
+ object_renaming_declaration *note 8.5.1::
+ parameter_and_result_profile *note 6.1::
+ parameter_specification *note 6.1::
+ return_subtype_indication *note 6.5::
+
+ access_to_object_definition *note 3.10::
+ access_type_definition *note 3.10::
+
+ access_to_subprogram_definition *note 3.10::
+ access_type_definition *note 3.10::
+
+ access_type_definition *note 3.10::
+ formal_access_type_definition *note 12.5.4::
+ type_definition *note 3.2.1::
+
+ actual_parameter_part *note 6.4::
+ entry_call_statement *note 9.5.3::
+ function_call *note 6.4::
+ generalized_indexing *note 4.1.6::
+ procedure_call_statement *note 6.4::
+
+ aggregate *note 4.3::
+ primary *note 4.4::
+ qualified_expression *note 4.7::
+
+ allocator *note 4.8::
+ primary *note 4.4::
+
+ ancestor_part *note 4.3.2::
+ extension_aggregate *note 4.3.2::
+
+ array_aggregate *note 4.3.3::
+ aggregate *note 4.3::
+ enumeration_aggregate *note 13.4::
+
+ array_component_association *note 4.3.3::
+ named_array_aggregate *note 4.3.3::
+
+ array_type_definition *note 3.6::
+ formal_array_type_definition *note 12.5.3::
+ object_declaration *note 3.3.1::
+ type_definition *note 3.2.1::
+
+ aspect_clause *note 13.1::
+ basic_declarative_item *note 3.11::
+ component_item *note 3.8::
+ protected_operation_declaration *note 9.4::
+ protected_operation_item *note 9.4::
+ task_item *note 9.1::
+
+ aspect_definition *note 13.1.1::
+ aspect_specification *note 13.1.1::
+
+ aspect_mark *note 13.1.1::
+ aspect_specification *note 13.1.1::
+ pragma_argument_association *note 2.8::
+
+ aspect_specification *note 13.1.1::
+ abstract_subprogram_declaration *note 3.9.3::
+ component_declaration *note 3.8::
+ entry_declaration *note 9.5.2::
+ exception_declaration *note 11.1::
+ exception_renaming_declaration *note 8.5.2::
+ expression_function_declaration *note 6.8::
+ formal_abstract_subprogram_declaration *note 12.6::
+ formal_complete_type_declaration *note 12.5::
+ formal_concrete_subprogram_declaration *note 12.6::
+ formal_object_declaration *note 12.4::
+ formal_package_declaration *note 12.7::
+ full_type_declaration *note 3.2.1::
+ generic_instantiation *note 12.3::
+ generic_renaming_declaration *note 8.5.5::
+ generic_subprogram_declaration *note 12.1::
+ null_procedure_declaration *note 6.7::
+ object_declaration *note 3.3.1::
+ object_renaming_declaration *note 8.5.1::
+ package_body *note 7.2::
+ package_body_stub *note 10.1.3::
+ package_renaming_declaration *note 8.5.3::
+ package_specification *note 7.1::
+ private_extension_declaration *note 7.3::
+ private_type_declaration *note 7.3::
+ protected_body *note 9.4::
+ protected_body_stub *note 10.1.3::
+ protected_type_declaration *note 9.4::
+ single_protected_declaration *note 9.4::
+ single_task_declaration *note 9.1::
+ subprogram_body *note 6.3::
+ subprogram_body_stub *note 10.1.3::
+ subprogram_declaration *note 6.1::
+ subprogram_renaming_declaration *note 8.5.4::
+ subtype_declaration *note 3.2.2::
+ task_body *note 9.1::
+ task_body_stub *note 10.1.3::
+ task_type_declaration *note 9.1::
+
+ assignment_statement *note 5.2::
+ simple_statement *note 5.1::
+
+ asynchronous_select *note 9.7.4::
+ select_statement *note 9.7::
+
+ at_clause *note J.7::
+ aspect_clause *note 13.1::
+
+ attribute_definition_clause *note 13.3::
+ aspect_clause *note 13.1::
+
+ attribute_designator *note 4.1.4::
+ attribute_definition_clause *note 13.3::
+ attribute_reference *note 4.1.4::
+ local_name *note 13.1::
+
+ attribute_reference *note 4.1.4::
+ name *note 4.1::
+
+ base *note 2.4.2::
+ based_literal *note 2.4.2::
+
+ based_literal *note 2.4.2::
+ numeric_literal *note 2.4::
+
+ based_numeral *note 2.4.2::
+ based_literal *note 2.4.2::
+
+ basic_declaration *note 3.1::
+ basic_declarative_item *note 3.11::
+
+ basic_declarative_item *note 3.11::
+ declarative_item *note 3.11::
+ package_specification *note 7.1::
+
+ binary_adding_operator *note 4.5::
+ simple_expression *note 4.4::
+
+ block_statement *note 5.6::
+ compound_statement *note 5.1::
+
+ body *note 3.11::
+ declarative_item *note 3.11::
+
+ body_stub *note 10.1.3::
+ body *note 3.11::
+
+ case_expression *note 4.5.7::
+ conditional_expression *note 4.5.7::
+
+ case_expression_alternative *note 4.5.7::
+ case_expression *note 4.5.7::
+
+ case_statement *note 5.4::
+ compound_statement *note 5.1::
+
+ case_statement_alternative *note 5.4::
+ case_statement *note 5.4::
+
+ character *note 2.1::
+ comment *note 2.7::
+
+ character_literal *note 2.5::
+ defining_character_literal *note 3.5.1::
+ name *note 4.1::
+ selector_name *note 4.1.3::
+
+ choice_expression *note 4.4::
+ discrete_choice *note 3.8.1::
+ membership_choice *note 4.4::
+
+ choice_parameter_specification *note 11.2::
+ exception_handler *note 11.2::
+
+ choice_relation *note 4.4::
+ choice_expression *note 4.4::
+
+ code_statement *note 13.8::
+ simple_statement *note 5.1::
+
+ compilation_unit *note 10.1.1::
+ compilation *note 10.1.1::
+
+ component_choice_list *note 4.3.1::
+ record_component_association *note 4.3.1::
+
+ component_clause *note 13.5.1::
+ record_representation_clause *note 13.5.1::
+
+ component_declaration *note 3.8::
+ component_item *note 3.8::
+ protected_element_declaration *note 9.4::
+
+ component_definition *note 3.6::
+ component_declaration *note 3.8::
+ constrained_array_definition *note 3.6::
+ unconstrained_array_definition *note 3.6::
+
+ component_item *note 3.8::
+ component_list *note 3.8::
+
+ component_list *note 3.8::
+ record_definition *note 3.8::
+ variant *note 3.8.1::
+
+ composite_constraint *note 3.2.2::
+ constraint *note 3.2.2::
+
+ compound_statement *note 5.1::
+ statement *note 5.1::
+
+ condition *note 4.5.7::
+ entry_barrier *note 9.5.2::
+ exit_statement *note 5.7::
+ guard *note 9.7.1::
+ if_expression *note 4.5.7::
+ if_statement *note 5.3::
+ iteration_scheme *note 5.5::
+
+ conditional_entry_call *note 9.7.3::
+ select_statement *note 9.7::
+
+ conditional_expression *note 4.5.7::
+ primary *note 4.4::
+
+ constrained_array_definition *note 3.6::
+ array_type_definition *note 3.6::
+
+ constraint *note 3.2.2::
+ subtype_indication *note 3.2.2::
+
+ context_clause *note 10.1.2::
+ compilation_unit *note 10.1.1::
+
+ context_item *note 10.1.2::
+ context_clause *note 10.1.2::
+
+ decimal_fixed_point_definition *note 3.5.9::
+ fixed_point_definition *note 3.5.9::
+
+ decimal_literal *note 2.4.1::
+ numeric_literal *note 2.4::
+
+ declarative_item *note 3.11::
+ declarative_part *note 3.11::
+
+ declarative_part *note 3.11::
+ block_statement *note 5.6::
+ entry_body *note 9.5.2::
+ package_body *note 7.2::
+ subprogram_body *note 6.3::
+ task_body *note 9.1::
+
+ default_expression *note 3.7::
+ component_declaration *note 3.8::
+ discriminant_specification *note 3.7::
+ formal_object_declaration *note 12.4::
+ parameter_specification *note 6.1::
+
+ default_name *note 12.6::
+ subprogram_default *note 12.6::
+
+ defining_character_literal *note 3.5.1::
+ enumeration_literal_specification *note 3.5.1::
+
+ defining_designator *note 6.1::
+ function_specification *note 6.1::
+ generic_instantiation *note 12.3::
+
+ defining_identifier *note 3.1::
+ choice_parameter_specification *note 11.2::
+ defining_identifier_list *note 3.3.1::
+ defining_program_unit_name *note 6.1::
+ entry_body *note 9.5.2::
+ entry_declaration *note 9.5.2::
+ entry_index_specification *note 9.5.2::
+ enumeration_literal_specification *note 3.5.1::
+ exception_renaming_declaration *note 8.5.2::
+ extended_return_object_declaration *note 6.5::
+ formal_complete_type_declaration *note 12.5::
+ formal_incomplete_type_declaration *note 12.5::
+ formal_package_declaration *note 12.7::
+ full_type_declaration *note 3.2.1::
+ incomplete_type_declaration *note 3.10.1::
+ iterator_specification *note 5.5.2::
+ loop_parameter_specification *note 5.5::
+ object_renaming_declaration *note 8.5.1::
+ package_body_stub *note 10.1.3::
+ private_extension_declaration *note 7.3::
+ private_type_declaration *note 7.3::
+ protected_body *note 9.4::
+ protected_body_stub *note 10.1.3::
+ protected_type_declaration *note 9.4::
+ single_protected_declaration *note 9.4::
+ single_task_declaration *note 9.1::
+ subtype_declaration *note 3.2.2::
+ task_body *note 9.1::
+ task_body_stub *note 10.1.3::
+ task_type_declaration *note 9.1::
+
+ defining_identifier_list *note 3.3.1::
+ component_declaration *note 3.8::
+ discriminant_specification *note 3.7::
+ exception_declaration *note 11.1::
+ formal_object_declaration *note 12.4::
+ number_declaration *note 3.3.2::
+ object_declaration *note 3.3.1::
+ parameter_specification *note 6.1::
+
+ defining_operator_symbol *note 6.1::
+ defining_designator *note 6.1::
+
+ defining_program_unit_name *note 6.1::
+ defining_designator *note 6.1::
+ generic_instantiation *note 12.3::
+ generic_renaming_declaration *note 8.5.5::
+ package_body *note 7.2::
+ package_renaming_declaration *note 8.5.3::
+ package_specification *note 7.1::
+ procedure_specification *note 6.1::
+
+ delay_alternative *note 9.7.1::
+ select_alternative *note 9.7.1::
+ timed_entry_call *note 9.7.2::
+
+ delay_relative_statement *note 9.6::
+ delay_statement *note 9.6::
+
+ delay_statement *note 9.6::
+ delay_alternative *note 9.7.1::
+ simple_statement *note 5.1::
+ triggering_statement *note 9.7.4::
+
+ delay_until_statement *note 9.6::
+ delay_statement *note 9.6::
+
+ delta_constraint *note J.3::
+ scalar_constraint *note 3.2.2::
+
+ derived_type_definition *note 3.4::
+ type_definition *note 3.2.1::
+
+ designator *note 6.1::
+ subprogram_body *note 6.3::
+
+ digit *note 2.4.1::
+ extended_digit *note 2.4.2::
+ numeral *note 2.4.1::
+
+ digits_constraint *note 3.5.9::
+ scalar_constraint *note 3.2.2::
+
+ direct_name *note 4.1::
+ accept_statement *note 9.5.2::
+ at_clause *note J.7::
+ local_name *note 13.1::
+ name *note 4.1::
+ statement_identifier *note 5.1::
+ variant_part *note 3.8.1::
+
+ discrete_choice *note 3.8.1::
+ discrete_choice_list *note 3.8.1::
+
+ discrete_choice_list *note 3.8.1::
+ array_component_association *note 4.3.3::
+ case_expression_alternative *note 4.5.7::
+ case_statement_alternative *note 5.4::
+ variant *note 3.8.1::
+
+ discrete_range *note 3.6.1::
+ index_constraint *note 3.6.1::
+ slice *note 4.1.2::
+
+ discrete_subtype_definition *note 3.6::
+ constrained_array_definition *note 3.6::
+ entry_declaration *note 9.5.2::
+ entry_index_specification *note 9.5.2::
+ loop_parameter_specification *note 5.5::
+
+ discriminant_association *note 3.7.1::
+ discriminant_constraint *note 3.7.1::
+
+ discriminant_constraint *note 3.7.1::
+ composite_constraint *note 3.2.2::
+
+ discriminant_part *note 3.7::
+ formal_complete_type_declaration *note 12.5::
+ formal_incomplete_type_declaration *note 12.5::
+ incomplete_type_declaration *note 3.10.1::
+ private_extension_declaration *note 7.3::
+ private_type_declaration *note 7.3::
+
+ discriminant_specification *note 3.7::
+ known_discriminant_part *note 3.7::
+
+ entry_barrier *note 9.5.2::
+ entry_body *note 9.5.2::
+
+ entry_body *note 9.5.2::
+ protected_operation_item *note 9.4::
+
+ entry_body_formal_part *note 9.5.2::
+ entry_body *note 9.5.2::
+
+ entry_call_alternative *note 9.7.2::
+ conditional_entry_call *note 9.7.3::
+ timed_entry_call *note 9.7.2::
+
+ entry_call_statement *note 9.5.3::
+ procedure_or_entry_call *note 9.7.2::
+ simple_statement *note 5.1::
+
+ entry_declaration *note 9.5.2::
+ protected_operation_declaration *note 9.4::
+ task_item *note 9.1::
+
+ entry_index *note 9.5.2::
+ accept_statement *note 9.5.2::
+
+ entry_index_specification *note 9.5.2::
+ entry_body_formal_part *note 9.5.2::
+
+ enumeration_aggregate *note 13.4::
+ enumeration_representation_clause *note 13.4::
+
+ enumeration_literal_specification *note 3.5.1::
+ enumeration_type_definition *note 3.5.1::
+
+ enumeration_representation_clause *note 13.4::
+ aspect_clause *note 13.1::
+
+ enumeration_type_definition *note 3.5.1::
+ type_definition *note 3.2.1::
+
+ exception_choice *note 11.2::
+ exception_handler *note 11.2::
+
+ exception_declaration *note 11.1::
+ basic_declaration *note 3.1::
+
+ exception_handler *note 11.2::
+ handled_sequence_of_statements *note 11.2::
+
+ exception_renaming_declaration *note 8.5.2::
+ renaming_declaration *note 8.5::
+
+ exit_statement *note 5.7::
+ simple_statement *note 5.1::
+
+ explicit_actual_parameter *note 6.4::
+ parameter_association *note 6.4::
+
+ explicit_dereference *note 4.1::
+ name *note 4.1::
+
+ explicit_generic_actual_parameter *note 12.3::
+ generic_association *note 12.3::
+
+ exponent *note 2.4.1::
+ based_literal *note 2.4.2::
+ decimal_literal *note 2.4.1::
+
+ expression *note 4.4::
+ ancestor_part *note 4.3.2::
+ array_component_association *note 4.3.3::
+ aspect_definition *note 13.1.1::
+ assignment_statement *note 5.2::
+ at_clause *note J.7::
+ attribute_definition_clause *note 13.3::
+ attribute_designator *note 4.1.4::
+ case_expression *note 4.5.7::
+ case_expression_alternative *note 4.5.7::
+ case_statement *note 5.4::
+ condition *note 4.5.7::
+ decimal_fixed_point_definition *note 3.5.9::
+ default_expression *note 3.7::
+ delay_relative_statement *note 9.6::
+ delay_until_statement *note 9.6::
+ delta_constraint *note J.3::
+ digits_constraint *note 3.5.9::
+ discriminant_association *note 3.7.1::
+ entry_index *note 9.5.2::
+ explicit_actual_parameter *note 6.4::
+ explicit_generic_actual_parameter *note 12.3::
+ expression_function_declaration *note 6.8::
+ extended_return_object_declaration *note 6.5::
+ floating_point_definition *note 3.5.7::
+ if_expression *note 4.5.7::
+ indexed_component *note 4.1.1::
+ mod_clause *note J.8::
+ modular_type_definition *note 3.5.4::
+ number_declaration *note 3.3.2::
+ object_declaration *note 3.3.1::
+ ordinary_fixed_point_definition *note 3.5.9::
+ position *note 13.5.1::
+ positional_array_aggregate *note 4.3.3::
+ pragma_argument_association *note 2.8::
+ predicate *note 4.5.8::
+ primary *note 4.4::
+ qualified_expression *note 4.7::
+ raise_statement *note 11.3::
+ range_attribute_designator *note 4.1.4::
+ record_component_association *note 4.3.1::
+ restriction_parameter_argument *note 13.12::
+ simple_return_statement *note 6.5::
+ type_conversion *note 4.6::
+
+ expression_function_declaration *note 6.8::
+ basic_declaration *note 3.1::
+
+ extended_digit *note 2.4.2::
+ based_numeral *note 2.4.2::
+
+ extended_return_object_declaration *note 6.5::
+ extended_return_statement *note 6.5::
+
+ extended_return_statement *note 6.5::
+ compound_statement *note 5.1::
+
+ extension_aggregate *note 4.3.2::
+ aggregate *note 4.3::
+
+ factor *note 4.4::
+ term *note 4.4::
+
+ first_bit *note 13.5.1::
+ component_clause *note 13.5.1::
+
+ fixed_point_definition *note 3.5.9::
+ real_type_definition *note 3.5.6::
+
+ floating_point_definition *note 3.5.7::
+ real_type_definition *note 3.5.6::
+
+ formal_abstract_subprogram_declaration *note 12.6::
+ formal_subprogram_declaration *note 12.6::
+
+ formal_access_type_definition *note 12.5.4::
+ formal_type_definition *note 12.5::
+
+ formal_array_type_definition *note 12.5.3::
+ formal_type_definition *note 12.5::
+
+ formal_complete_type_declaration *note 12.5::
+ formal_type_declaration *note 12.5::
+
+ formal_concrete_subprogram_declaration *note 12.6::
+ formal_subprogram_declaration *note 12.6::
+
+ formal_decimal_fixed_point_definition *note 12.5.2::
+ formal_type_definition *note 12.5::
+
+ formal_derived_type_definition *note 12.5.1::
+ formal_type_definition *note 12.5::
+
+ formal_discrete_type_definition *note 12.5.2::
+ formal_type_definition *note 12.5::
+
+ formal_floating_point_definition *note 12.5.2::
+ formal_type_definition *note 12.5::
+
+ formal_incomplete_type_declaration *note 12.5::
+ formal_type_declaration *note 12.5::
+
+ formal_interface_type_definition *note 12.5.5::
+ formal_type_definition *note 12.5::
+
+ formal_modular_type_definition *note 12.5.2::
+ formal_type_definition *note 12.5::
+
+ formal_object_declaration *note 12.4::
+ generic_formal_parameter_declaration *note 12.1::
+
+ formal_ordinary_fixed_point_definition *note 12.5.2::
+ formal_type_definition *note 12.5::
+
+ formal_package_actual_part *note 12.7::
+ formal_package_declaration *note 12.7::
+
+ formal_package_association *note 12.7::
+ formal_package_actual_part *note 12.7::
+
+ formal_package_declaration *note 12.7::
+ generic_formal_parameter_declaration *note 12.1::
+
+ formal_part *note 6.1::
+ parameter_and_result_profile *note 6.1::
+ parameter_profile *note 6.1::
+
+ formal_private_type_definition *note 12.5.1::
+ formal_type_definition *note 12.5::
+
+ formal_signed_integer_type_definition *note 12.5.2::
+ formal_type_definition *note 12.5::
+
+ formal_subprogram_declaration *note 12.6::
+ generic_formal_parameter_declaration *note 12.1::
+
+ formal_type_declaration *note 12.5::
+ generic_formal_parameter_declaration *note 12.1::
+
+ formal_type_definition *note 12.5::
+ formal_complete_type_declaration *note 12.5::
+
+ full_type_declaration *note 3.2.1::
+ type_declaration *note 3.2.1::
+
+ function_call *note 6.4::
+ name *note 4.1::
+
+ function_specification *note 6.1::
+ expression_function_declaration *note 6.8::
+ subprogram_specification *note 6.1::
+
+ general_access_modifier *note 3.10::
+ access_to_object_definition *note 3.10::
+
+ generalized_indexing *note 4.1.6::
+ name *note 4.1::
+
+ generalized_reference *note 4.1.5::
+ name *note 4.1::
+
+ generic_actual_part *note 12.3::
+ formal_package_actual_part *note 12.7::
+ generic_instantiation *note 12.3::
+
+ generic_association *note 12.3::
+ formal_package_association *note 12.7::
+ generic_actual_part *note 12.3::
+
+ generic_declaration *note 12.1::
+ basic_declaration *note 3.1::
+ library_unit_declaration *note 10.1.1::
+
+ generic_formal_parameter_declaration *note 12.1::
+ generic_formal_part *note 12.1::
+
+ generic_formal_part *note 12.1::
+ generic_package_declaration *note 12.1::
+ generic_subprogram_declaration *note 12.1::
+
+ generic_instantiation *note 12.3::
+ basic_declaration *note 3.1::
+ library_unit_declaration *note 10.1.1::
+
+ generic_package_declaration *note 12.1::
+ generic_declaration *note 12.1::
+
+ generic_renaming_declaration *note 8.5.5::
+ library_unit_renaming_declaration *note 10.1.1::
+ renaming_declaration *note 8.5::
+
+ generic_subprogram_declaration *note 12.1::
+ generic_declaration *note 12.1::
+
+ goto_statement *note 5.8::
+ simple_statement *note 5.1::
+
+ graphic_character *note 2.1::
+ character_literal *note 2.5::
+ string_element *note 2.6::
+
+ guard *note 9.7.1::
+ selective_accept *note 9.7.1::
+
+ handled_sequence_of_statements *note 11.2::
+ accept_statement *note 9.5.2::
+ block_statement *note 5.6::
+ entry_body *note 9.5.2::
+ extended_return_statement *note 6.5::
+ package_body *note 7.2::
+ subprogram_body *note 6.3::
+ task_body *note 9.1::
+
+ identifier *note 2.3::
+ accept_statement *note 9.5.2::
+ aspect_definition *note 13.1.1::
+ aspect_mark *note 13.1.1::
+ attribute_designator *note 4.1.4::
+ block_statement *note 5.6::
+ defining_identifier *note 3.1::
+ designator *note 6.1::
+ direct_name *note 4.1::
+ entry_body *note 9.5.2::
+ loop_statement *note 5.5::
+ package_body *note 7.2::
+ package_specification *note 7.1::
+ pragma *note 2.8::
+ pragma_argument_association *note 2.8::
+ protected_body *note 9.4::
+ protected_definition *note 9.4::
+ restriction *note 13.12::
+ selector_name *note 4.1.3::
+ task_body *note 9.1::
+ task_definition *note 9.1::
+
+ identifier_extend *note 2.3::
+ identifier *note 2.3::
+
+ identifier_start *note 2.3::
+ identifier *note 2.3::
+
+ if_expression *note 4.5.7::
+ conditional_expression *note 4.5.7::
+
+ if_statement *note 5.3::
+ compound_statement *note 5.1::
+
+ implicit_dereference *note 4.1::
+ prefix *note 4.1::
+
+ incomplete_type_declaration *note 3.10.1::
+ type_declaration *note 3.2.1::
+
+ index_constraint *note 3.6.1::
+ composite_constraint *note 3.2.2::
+
+ index_subtype_definition *note 3.6::
+ unconstrained_array_definition *note 3.6::
+
+ indexed_component *note 4.1.1::
+ name *note 4.1::
+
+ integer_type_definition *note 3.5.4::
+ type_definition *note 3.2.1::
+
+ interface_list *note 3.9.4::
+ derived_type_definition *note 3.4::
+ formal_derived_type_definition *note 12.5.1::
+ interface_type_definition *note 3.9.4::
+ private_extension_declaration *note 7.3::
+ protected_type_declaration *note 9.4::
+ single_protected_declaration *note 9.4::
+ single_task_declaration *note 9.1::
+ task_type_declaration *note 9.1::
+
+ interface_type_definition *note 3.9.4::
+ formal_interface_type_definition *note 12.5.5::
+ type_definition *note 3.2.1::
+
+ iteration_scheme *note 5.5::
+ loop_statement *note 5.5::
+
+ iterator_specification *note 5.5.2::
+ iteration_scheme *note 5.5::
+ quantified_expression *note 4.5.8::
+
+ known_discriminant_part *note 3.7::
+ discriminant_part *note 3.7::
+ full_type_declaration *note 3.2.1::
+ protected_type_declaration *note 9.4::
+ task_type_declaration *note 9.1::
+
+ label *note 5.1::
+ sequence_of_statements *note 5.1::
+ statement *note 5.1::
+
+ last_bit *note 13.5.1::
+ component_clause *note 13.5.1::
+
+ letter_lowercase ...
+ identifier_start *note 2.3::
+
+ letter_modifier ...
+ identifier_start *note 2.3::
+
+ letter_other ...
+ identifier_start *note 2.3::
+
+ letter_titlecase ...
+ identifier_start *note 2.3::
+
+ letter_uppercase ...
+ identifier_start *note 2.3::
+
+ library_item *note 10.1.1::
+ compilation_unit *note 10.1.1::
+
+ library_unit_body *note 10.1.1::
+ library_item *note 10.1.1::
+
+ library_unit_declaration *note 10.1.1::
+ library_item *note 10.1.1::
+
+ library_unit_renaming_declaration *note 10.1.1::
+ library_item *note 10.1.1::
+
+ limited_with_clause *note 10.1.2::
+ with_clause *note 10.1.2::
+
+ local_name *note 13.1::
+ attribute_definition_clause *note 13.3::
+ component_clause *note 13.5.1::
+ enumeration_representation_clause *note 13.4::
+ record_representation_clause *note 13.5.1::
+
+ loop_parameter_specification *note 5.5::
+ iteration_scheme *note 5.5::
+ quantified_expression *note 4.5.8::
+
+ loop_statement *note 5.5::
+ compound_statement *note 5.1::
+
+ mark_non_spacing ...
+ identifier_extend *note 2.3::
+
+ mark_spacing_combining ...
+ identifier_extend *note 2.3::
+
+ membership_choice *note 4.4::
+ membership_choice_list *note 4.4::
+
+ membership_choice_list *note 4.4::
+ relation *note 4.4::
+
+ mod_clause *note J.8::
+ record_representation_clause *note 13.5.1::
+
+ mode *note 6.1::
+ formal_object_declaration *note 12.4::
+ parameter_specification *note 6.1::
+
+ modular_type_definition *note 3.5.4::
+ integer_type_definition *note 3.5.4::
+
+ multiplying_operator *note 4.5::
+ term *note 4.4::
+
+ name *note 4.1::
+ abort_statement *note 9.8::
+ aspect_definition *note 13.1.1::
+ assignment_statement *note 5.2::
+ attribute_definition_clause *note 13.3::
+ default_name *note 12.6::
+ entry_call_statement *note 9.5.3::
+ exception_choice *note 11.2::
+ exception_renaming_declaration *note 8.5.2::
+ exit_statement *note 5.7::
+ explicit_actual_parameter *note 6.4::
+ explicit_dereference *note 4.1::
+ explicit_generic_actual_parameter *note 12.3::
+ formal_package_declaration *note 12.7::
+ function_call *note 6.4::
+ generalized_reference *note 4.1.5::
+ generic_instantiation *note 12.3::
+ generic_renaming_declaration *note 8.5.5::
+ goto_statement *note 5.8::
+ implicit_dereference *note 4.1::
+ iterator_specification *note 5.5.2::
+ limited_with_clause *note 10.1.2::
+ local_name *note 13.1::
+ nonlimited_with_clause *note 10.1.2::
+ object_renaming_declaration *note 8.5.1::
+ package_renaming_declaration *note 8.5.3::
+ parent_unit_name *note 10.1.1::
+ pragma_argument_association *note 2.8::
+ prefix *note 4.1::
+ primary *note 4.4::
+ procedure_call_statement *note 6.4::
+ raise_statement *note 11.3::
+ requeue_statement *note 9.5.4::
+ restriction_parameter_argument *note 13.12::
+ storage_pool_indicator *note 13.11.3::
+ subpool_specification *note 4.8::
+ subprogram_renaming_declaration *note 8.5.4::
+ subtype_mark *note 3.2.2::
+ type_conversion *note 4.6::
+ use_package_clause *note 8.4::
+
+ named_array_aggregate *note 4.3.3::
+ array_aggregate *note 4.3.3::
+
+ nonlimited_with_clause *note 10.1.2::
+ with_clause *note 10.1.2::
+
+ null_exclusion *note 3.10::
+ access_definition *note 3.10::
+ access_type_definition *note 3.10::
+ discriminant_specification *note 3.7::
+ formal_object_declaration *note 12.4::
+ object_renaming_declaration *note 8.5.1::
+ parameter_and_result_profile *note 6.1::
+ parameter_specification *note 6.1::
+ subtype_indication *note 3.2.2::
+
+ null_procedure_declaration *note 6.7::
+ basic_declaration *note 3.1::
+
+ null_statement *note 5.1::
+ simple_statement *note 5.1::
+
+ number_decimal ...
+ identifier_extend *note 2.3::
+
+ number_declaration *note 3.3.2::
+ basic_declaration *note 3.1::
+
+ number_letter ...
+ identifier_start *note 2.3::
+
+ numeral *note 2.4.1::
+ base *note 2.4.2::
+ decimal_literal *note 2.4.1::
+ exponent *note 2.4.1::
+
+ numeric_literal *note 2.4::
+ primary *note 4.4::
+
+ object_declaration *note 3.3.1::
+ basic_declaration *note 3.1::
+
+ object_renaming_declaration *note 8.5.1::
+ renaming_declaration *note 8.5::
+
+ operator_symbol *note 6.1::
+ defining_operator_symbol *note 6.1::
+ designator *note 6.1::
+ direct_name *note 4.1::
+ selector_name *note 4.1.3::
+
+ ordinary_fixed_point_definition *note 3.5.9::
+ fixed_point_definition *note 3.5.9::
+
+ overriding_indicator *note 8.3.1::
+ abstract_subprogram_declaration *note 3.9.3::
+ entry_declaration *note 9.5.2::
+ expression_function_declaration *note 6.8::
+ generic_instantiation *note 12.3::
+ null_procedure_declaration *note 6.7::
+ subprogram_body *note 6.3::
+ subprogram_body_stub *note 10.1.3::
+ subprogram_declaration *note 6.1::
+ subprogram_renaming_declaration *note 8.5.4::
+
+ package_body *note 7.2::
+ library_unit_body *note 10.1.1::
+ proper_body *note 3.11::
+
+ package_body_stub *note 10.1.3::
+ body_stub *note 10.1.3::
+
+ package_declaration *note 7.1::
+ basic_declaration *note 3.1::
+ library_unit_declaration *note 10.1.1::
+
+ package_renaming_declaration *note 8.5.3::
+ library_unit_renaming_declaration *note 10.1.1::
+ renaming_declaration *note 8.5::
+
+ package_specification *note 7.1::
+ generic_package_declaration *note 12.1::
+ package_declaration *note 7.1::
+
+ parameter_and_result_profile *note 6.1::
+ access_definition *note 3.10::
+ access_to_subprogram_definition *note 3.10::
+ function_specification *note 6.1::
+
+ parameter_association *note 6.4::
+ actual_parameter_part *note 6.4::
+
+ parameter_profile *note 6.1::
+ accept_statement *note 9.5.2::
+ access_definition *note 3.10::
+ access_to_subprogram_definition *note 3.10::
+ entry_body_formal_part *note 9.5.2::
+ entry_declaration *note 9.5.2::
+ procedure_specification *note 6.1::
+
+ parameter_specification *note 6.1::
+ formal_part *note 6.1::
+
+ parent_unit_name *note 10.1.1::
+ defining_program_unit_name *note 6.1::
+ designator *note 6.1::
+ package_body *note 7.2::
+ package_specification *note 7.1::
+ subunit *note 10.1.3::
+
+ position *note 13.5.1::
+ component_clause *note 13.5.1::
+
+ positional_array_aggregate *note 4.3.3::
+ array_aggregate *note 4.3.3::
+
+ pragma_argument_association *note 2.8::
+ pragma *note 2.8::
+
+ predicate *note 4.5.8::
+ quantified_expression *note 4.5.8::
+
+ prefix *note 4.1::
+ attribute_reference *note 4.1.4::
+ function_call *note 6.4::
+ generalized_indexing *note 4.1.6::
+ indexed_component *note 4.1.1::
+ procedure_call_statement *note 6.4::
+ range_attribute_reference *note 4.1.4::
+ selected_component *note 4.1.3::
+ slice *note 4.1.2::
+
+ primary *note 4.4::
+ factor *note 4.4::
+
+ private_extension_declaration *note 7.3::
+ type_declaration *note 3.2.1::
+
+ private_type_declaration *note 7.3::
+ type_declaration *note 3.2.1::
+
+ procedure_call_statement *note 6.4::
+ procedure_or_entry_call *note 9.7.2::
+ simple_statement *note 5.1::
+
+ procedure_or_entry_call *note 9.7.2::
+ entry_call_alternative *note 9.7.2::
+ triggering_statement *note 9.7.4::
+
+ procedure_specification *note 6.1::
+ null_procedure_declaration *note 6.7::
+ subprogram_specification *note 6.1::
+
+ proper_body *note 3.11::
+ body *note 3.11::
+ subunit *note 10.1.3::
+
+ protected_body *note 9.4::
+ proper_body *note 3.11::
+
+ protected_body_stub *note 10.1.3::
+ body_stub *note 10.1.3::
+
+ protected_definition *note 9.4::
+ protected_type_declaration *note 9.4::
+ single_protected_declaration *note 9.4::
+
+ protected_element_declaration *note 9.4::
+ protected_definition *note 9.4::
+
+ protected_operation_declaration *note 9.4::
+ protected_definition *note 9.4::
+ protected_element_declaration *note 9.4::
+
+ protected_operation_item *note 9.4::
+ protected_body *note 9.4::
+
+ protected_type_declaration *note 9.4::
+ full_type_declaration *note 3.2.1::
+
+ punctuation_connector ...
+ identifier_extend *note 2.3::
+
+ qualified_expression *note 4.7::
+ allocator *note 4.8::
+ code_statement *note 13.8::
+ name *note 4.1::
+
+ quantified_expression *note 4.5.8::
+ primary *note 4.4::
+
+ quantifier *note 4.5.8::
+ quantified_expression *note 4.5.8::
+
+ raise_statement *note 11.3::
+ simple_statement *note 5.1::
+
+ range *note 3.5::
+ discrete_choice *note 3.8.1::
+ discrete_range *note 3.6.1::
+ discrete_subtype_definition *note 3.6::
+ membership_choice *note 4.4::
+ range_constraint *note 3.5::
+
+ range_attribute_designator *note 4.1.4::
+ range_attribute_reference *note 4.1.4::
+
+ range_attribute_reference *note 4.1.4::
+ range *note 3.5::
+
+ range_constraint *note 3.5::
+ delta_constraint *note J.3::
+ digits_constraint *note 3.5.9::
+ scalar_constraint *note 3.2.2::
+
+ real_range_specification *note 3.5.7::
+ decimal_fixed_point_definition *note 3.5.9::
+ floating_point_definition *note 3.5.7::
+ ordinary_fixed_point_definition *note 3.5.9::
+
+ real_type_definition *note 3.5.6::
+ type_definition *note 3.2.1::
+
+ record_aggregate *note 4.3.1::
+ aggregate *note 4.3::
+
+ record_component_association *note 4.3.1::
+ record_component_association_list *note 4.3.1::
+
+ record_component_association_list *note 4.3.1::
+ extension_aggregate *note 4.3.2::
+ record_aggregate *note 4.3.1::
+
+ record_definition *note 3.8::
+ record_extension_part *note 3.9.1::
+ record_type_definition *note 3.8::
+
+ record_extension_part *note 3.9.1::
+ derived_type_definition *note 3.4::
+
+ record_representation_clause *note 13.5.1::
+ aspect_clause *note 13.1::
+
+ record_type_definition *note 3.8::
+ type_definition *note 3.2.1::
+
+ relation *note 4.4::
+ expression *note 4.4::
+
+ relational_operator *note 4.5::
+ choice_relation *note 4.4::
+ relation *note 4.4::
+
+ renaming_declaration *note 8.5::
+ basic_declaration *note 3.1::
+
+ requeue_statement *note 9.5.4::
+ simple_statement *note 5.1::
+
+ restriction_parameter_argument *note 13.12::
+ restriction *note 13.12::
+
+ return_subtype_indication *note 6.5::
+ extended_return_object_declaration *note 6.5::
+
+ scalar_constraint *note 3.2.2::
+ constraint *note 3.2.2::
+
+ select_alternative *note 9.7.1::
+ selective_accept *note 9.7.1::
+
+ select_statement *note 9.7::
+ compound_statement *note 5.1::
+
+ selected_component *note 4.1.3::
+ name *note 4.1::
+
+ selective_accept *note 9.7.1::
+ select_statement *note 9.7::
+
+ selector_name *note 4.1.3::
+ component_choice_list *note 4.3.1::
+ discriminant_association *note 3.7.1::
+ formal_package_association *note 12.7::
+ generic_association *note 12.3::
+ parameter_association *note 6.4::
+ selected_component *note 4.1.3::
+
+ sequence_of_statements *note 5.1::
+ abortable_part *note 9.7.4::
+ accept_alternative *note 9.7.1::
+ case_statement_alternative *note 5.4::
+ conditional_entry_call *note 9.7.3::
+ delay_alternative *note 9.7.1::
+ entry_call_alternative *note 9.7.2::
+ exception_handler *note 11.2::
+ handled_sequence_of_statements *note 11.2::
+ if_statement *note 5.3::
+ loop_statement *note 5.5::
+ selective_accept *note 9.7.1::
+ triggering_alternative *note 9.7.4::
+
+ signed_integer_type_definition *note 3.5.4::
+ integer_type_definition *note 3.5.4::
+
+ simple_expression *note 4.4::
+ choice_relation *note 4.4::
+ first_bit *note 13.5.1::
+ last_bit *note 13.5.1::
+ range *note 3.5::
+ real_range_specification *note 3.5.7::
+ relation *note 4.4::
+ signed_integer_type_definition *note 3.5.4::
+
+ simple_return_statement *note 6.5::
+ simple_statement *note 5.1::
+
+ simple_statement *note 5.1::
+ statement *note 5.1::
+
+ single_protected_declaration *note 9.4::
+ object_declaration *note 3.3.1::
+
+ single_task_declaration *note 9.1::
+ object_declaration *note 3.3.1::
+
+ slice *note 4.1.2::
+ name *note 4.1::
+
+ statement *note 5.1::
+ sequence_of_statements *note 5.1::
+
+ statement_identifier *note 5.1::
+ block_statement *note 5.6::
+ label *note 5.1::
+ loop_statement *note 5.5::
+
+ string_element *note 2.6::
+ string_literal *note 2.6::
+
+ string_literal *note 2.6::
+ operator_symbol *note 6.1::
+ primary *note 4.4::
+
+ subpool_specification *note 4.8::
+ allocator *note 4.8::
+
+ subprogram_body *note 6.3::
+ library_unit_body *note 10.1.1::
+ proper_body *note 3.11::
+ protected_operation_item *note 9.4::
+
+ subprogram_body_stub *note 10.1.3::
+ body_stub *note 10.1.3::
+
+ subprogram_declaration *note 6.1::
+ basic_declaration *note 3.1::
+ library_unit_declaration *note 10.1.1::
+ protected_operation_declaration *note 9.4::
+ protected_operation_item *note 9.4::
+
+ subprogram_default *note 12.6::
+ formal_abstract_subprogram_declaration *note 12.6::
+ formal_concrete_subprogram_declaration *note 12.6::
+
+ subprogram_renaming_declaration *note 8.5.4::
+ library_unit_renaming_declaration *note 10.1.1::
+ renaming_declaration *note 8.5::
+
+ subprogram_specification *note 6.1::
+ abstract_subprogram_declaration *note 3.9.3::
+ formal_abstract_subprogram_declaration *note 12.6::
+ formal_concrete_subprogram_declaration *note 12.6::
+ generic_subprogram_declaration *note 12.1::
+ subprogram_body *note 6.3::
+ subprogram_body_stub *note 10.1.3::
+ subprogram_declaration *note 6.1::
+ subprogram_renaming_declaration *note 8.5.4::
+
+ subtype_declaration *note 3.2.2::
+ basic_declaration *note 3.1::
+
+ subtype_indication *note 3.2.2::
+ access_to_object_definition *note 3.10::
+ allocator *note 4.8::
+ component_definition *note 3.6::
+ derived_type_definition *note 3.4::
+ discrete_choice *note 3.8.1::
+ discrete_range *note 3.6.1::
+ discrete_subtype_definition *note 3.6::
+ iterator_specification *note 5.5.2::
+ object_declaration *note 3.3.1::
+ private_extension_declaration *note 7.3::
+ return_subtype_indication *note 6.5::
+ subtype_declaration *note 3.2.2::
+
+ subtype_mark *note 3.2.2::
+ access_definition *note 3.10::
+ ancestor_part *note 4.3.2::
+ discriminant_specification *note 3.7::
+ explicit_generic_actual_parameter *note 12.3::
+ formal_derived_type_definition *note 12.5.1::
+ formal_object_declaration *note 12.4::
+ index_subtype_definition *note 3.6::
+ interface_list *note 3.9.4::
+ membership_choice *note 4.4::
+ object_renaming_declaration *note 8.5.1::
+ parameter_and_result_profile *note 6.1::
+ parameter_specification *note 6.1::
+ qualified_expression *note 4.7::
+ subtype_indication *note 3.2.2::
+ type_conversion *note 4.6::
+ use_type_clause *note 8.4::
+
+ subunit *note 10.1.3::
+ compilation_unit *note 10.1.1::
+
+ task_body *note 9.1::
+ proper_body *note 3.11::
+
+ task_body_stub *note 10.1.3::
+ body_stub *note 10.1.3::
+
+ task_definition *note 9.1::
+ single_task_declaration *note 9.1::
+ task_type_declaration *note 9.1::
+
+ task_item *note 9.1::
+ task_definition *note 9.1::
+
+ task_type_declaration *note 9.1::
+ full_type_declaration *note 3.2.1::
+
+ term *note 4.4::
+ simple_expression *note 4.4::
+
+ terminate_alternative *note 9.7.1::
+ select_alternative *note 9.7.1::
+
+ timed_entry_call *note 9.7.2::
+ select_statement *note 9.7::
+
+ triggering_alternative *note 9.7.4::
+ asynchronous_select *note 9.7.4::
+
+ triggering_statement *note 9.7.4::
+ triggering_alternative *note 9.7.4::
+
+ type_conversion *note 4.6::
+ name *note 4.1::
+
+ type_declaration *note 3.2.1::
+ basic_declaration *note 3.1::
+
+ type_definition *note 3.2.1::
+ full_type_declaration *note 3.2.1::
+
+ unary_adding_operator *note 4.5::
+ simple_expression *note 4.4::
+
+ unconstrained_array_definition *note 3.6::
+ array_type_definition *note 3.6::
+
+ underline ...
+ based_numeral *note 2.4.2::
+ numeral *note 2.4.1::
+
+ unknown_discriminant_part *note 3.7::
+ discriminant_part *note 3.7::
+
+ use_clause *note 8.4::
+ basic_declarative_item *note 3.11::
+ context_item *note 10.1.2::
+ generic_formal_part *note 12.1::
+
+ use_package_clause *note 8.4::
+ use_clause *note 8.4::
+
+ use_type_clause *note 8.4::
+ use_clause *note 8.4::
+
+ variant *note 3.8.1::
+ variant_part *note 3.8.1::
+
+ variant_part *note 3.8.1::
+ component_list *note 3.8::
+
+ with_clause *note 10.1.2::
+ context_item *note 10.1.2::
+
+\1f
+File: aarm2012.info, Node: Annex Q, Next: Index, Prev: Annex P, Up: Top
+
+Annex Q Language-Defined Entities
+*********************************
+
+1/2
+{AI95-00440-01AI95-00440-01} This annex lists the language-defined
+entities of the language. A list of language-defined library units can
+be found in *note Annex A::, "*note Annex A:: Predefined Language
+Environment".
+
+* Menu:
+
+* Q.1 :: Language-Defined Packages
+* Q.2 :: Language-Defined Types and Subtypes
+* Q.3 :: Language-Defined Subprograms
+* Q.4 :: Language-Defined Exceptions
+* Q.5 :: Language-Defined Objects
+
+\1f
+File: aarm2012.info, Node: Q.1, Next: Q.2, Up: Annex Q
+
+Q.1 Language-Defined Packages
+=============================
+
+1/3
+{AI95-00440-01AI95-00440-01} {AI05-0299-1AI05-0299-1} This subclause
+lists all language-defined packages.
+
+
+
+Ada *note A.2(2): 5900.
+
+Address_To_Access_Conversions
+ child of System *note 13.7.2(2): 5572.
+
+Arithmetic
+ child of Ada.Calendar *note 9.6.1(8/2): 4489.
+
+ASCII
+ in Standard *note A.1(36.3/2): 5887.
+
+Assertions
+ child of Ada *note 11.4.2(12/2): 4971.
+
+Asynchronous_Task_Control
+ child of Ada *note D.11(3/2): 8572.
+
+Bounded
+ child of Ada.Strings *note A.4.4(3): 6300.
+
+Bounded_IO
+ child of Ada.Text_IO *note A.10.11(3/2): 7030.
+ child of Ada.Wide_Text_IO *note A.11(4/3): 7056.
+ child of Ada.Wide_Wide_Text_IO *note A.11(4/3): 7057.
+
+Bounded_Priority_Queues
+ child of Ada.Containers *note A.18.31(2/3): 7916.
+
+Bounded_Synchronized_Queues
+ child of Ada.Containers *note A.18.29(2/3): 7901.
+
+C
+ child of Interfaces *note B.3(4): 7986.
+
+Calendar
+ child of Ada *note 9.6(10): 4458.
+
+Characters
+ child of Ada *note A.3.1(2): 5903.
+
+COBOL
+ child of Interfaces *note B.4(7): 8106.
+
+Command_Line
+ child of Ada *note A.15(3): 7127.
+
+Complex_Arrays
+ child of Ada.Numerics *note G.3.2(53/2): 9041.
+
+Complex_Elementary_Functions
+ child of Ada.Numerics *note G.1.2(9/1): 8915.
+
+Complex_Text_IO
+ child of Ada *note G.1.3(9.1/2): 8933.
+
+Complex_Types
+ child of Ada.Numerics *note G.1.1(25/1): 8887.
+
+Complex_IO
+ child of Ada.Text_IO *note G.1.3(3): 8923.
+ child of Ada.Wide_Text_IO *note G.1.4(1): 8936.
+ child of Ada.Wide_Wide_Text_IO *note G.1.5(1/2): 8938.
+
+Constants
+ child of Ada.Strings.Maps *note A.4.6(3/2): 6417.
+
+Containers
+ child of Ada *note A.18.1(3/2): 7225.
+
+Conversions
+ child of Ada.Characters *note A.3.4(2/2): 6178.
+ child of Ada.Strings.UTF_Encoding *note A.4.11(15/3): 6547.
+
+Decimal
+ child of Ada *note F.2(2): 8829.
+
+Decimal_Conversions
+ in Interfaces.COBOL *note B.4(31): 8140.
+
+Decimal_IO
+ in Ada.Text_IO *note A.10.1(73): 6987.
+
+Decimal_Output
+ in Ada.Text_IO.Editing *note F.3.3(11): 8852.
+
+Direct_IO
+ child of Ada *note A.8.4(2): 6807.
+
+Directories
+ child of Ada *note A.16(3/2): 7137.
+
+Discrete_Random
+ child of Ada.Numerics *note A.5.2(17): 6635.
+
+Dispatching
+ child of Ada *note D.2.1(1.2/3): 8338.
+
+Dispatching_Domains
+ child of System.Multiprocessors *note D.16.1(3/3): 8671.
+
+Doubly_Linked_Lists
+ child of Ada.Containers *note A.18.3(5/3): 7337.
+
+Dynamic_Priorities
+ child of Ada *note D.5.1(3/2): 8443.
+
+EDF
+ child of Ada.Dispatching *note D.2.6(9/2): 8395.
+ child of Ada.Synchronous_Task_Control *note D.10(5.2/3): 8560.
+
+Editing
+ child of Ada.Text_IO *note F.3.3(3): 8840.
+ child of Ada.Wide_Text_IO *note F.3.4(1): 8860.
+ child of Ada.Wide_Wide_Text_IO *note F.3.5(1/2): 8862.
+
+Elementary_Functions
+ child of Ada.Numerics *note A.5.1(9/1): 6614.
+
+Enumeration_IO
+ in Ada.Text_IO *note A.10.1(79): 6997.
+
+Environment_Variables
+ child of Ada *note A.17(3/2): 7205.
+
+Exceptions
+ child of Ada *note 11.4.1(2/2): 4927.
+
+Execution_Time
+ child of Ada *note D.14(3/2): 8585.
+
+Finalization
+ child of Ada *note 7.6(4/3): 3927.
+
+Fixed
+ child of Ada.Strings *note A.4.3(5): 6262.
+
+Fixed_IO
+ in Ada.Text_IO *note A.10.1(68): 6977.
+
+Float_Random
+ child of Ada.Numerics *note A.5.2(5): 6622.
+
+Float_Text_IO
+ child of Ada *note A.10.9(33): 7029.
+
+Float_Wide_Text_IO
+ child of Ada *note A.11(2/2): 7052.
+
+Float_Wide_Wide_Text_IO
+ child of Ada *note A.11(3/2): 7055.
+
+Float_IO
+ in Ada.Text_IO *note A.10.1(63): 6967.
+
+Formatting
+ child of Ada.Calendar *note 9.6.1(15/2): 4493.
+
+Fortran
+ child of Interfaces *note B.5(4): 8160.
+
+Generic_Complex_Arrays
+ child of Ada.Numerics *note G.3.2(2/2): 9005.
+
+Generic_Complex_Elementary_Functions
+ child of Ada.Numerics *note G.1.2(2/2): 8894.
+
+Generic_Complex_Types
+ child of Ada.Numerics *note G.1.1(2/1): 8866.
+
+Generic_Dispatching_Constructor
+ child of Ada.Tags *note 3.9(18.2/3): 2254.
+
+Generic_Elementary_Functions
+ child of Ada.Numerics *note A.5.1(3): 6585.
+
+Generic_Bounded_Length
+ in Ada.Strings.Bounded *note A.4.4(4): 6301.
+
+Generic_Keys
+ in Ada.Containers.Hashed_Sets *note A.18.8(50/2): 7614.
+ in Ada.Containers.Ordered_Sets *note A.18.9(62/2): 7695.
+
+Generic_Real_Arrays
+ child of Ada.Numerics *note G.3.1(2/2): 8988.
+
+Generic_Sorting
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(47/2): 7384.
+ in Ada.Containers.Vectors *note A.18.2(75/2): 7309.
+
+Group_Budgets
+ child of Ada.Execution_Time *note D.14.2(3/3): 8619.
+
+Handling
+ child of Ada.Characters *note A.3.2(2/2): 5907.
+ child of Ada.Wide_Characters *note A.3.5(3/3): 6198.
+ child of Ada.Wide_Wide_Characters *note A.3.6(1/3): 6220.
+
+Hashed_Maps
+ child of Ada.Containers *note A.18.5(2/3): 7428.
+
+Hashed_Sets
+ child of Ada.Containers *note A.18.8(2/3): 7567.
+
+Hierarchical_File_Names
+ child of Ada.Directories *note A.16.1(3/3): 7191.
+
+Indefinite_Doubly_Linked_Lists
+ child of Ada.Containers *note A.18.12(2/3): 7811.
+
+Indefinite_Hashed_Maps
+ child of Ada.Containers *note A.18.13(2/3): 7813.
+
+Indefinite_Hashed_Sets
+ child of Ada.Containers *note A.18.15(2/3): 7817.
+
+Indefinite_Holders
+ child of Ada.Containers *note A.18.18(5/3): 7824.
+
+Indefinite_Multiway_Trees
+ child of Ada.Containers *note A.18.17(2/3): 7821.
+
+Indefinite_Ordered_Maps
+ child of Ada.Containers *note A.18.14(2/3): 7815.
+
+Indefinite_Ordered_Sets
+ child of Ada.Containers *note A.18.16(2/3): 7819.
+
+Indefinite_Vectors
+ child of Ada.Containers *note A.18.11(2/3): 7809.
+
+Information
+ child of Ada.Directories *note A.16(124/2): 7187.
+
+Integer_Text_IO
+ child of Ada *note A.10.8(21): 7027.
+
+Integer_Wide_Text_IO
+ child of Ada *note A.11(2/2): 7051.
+
+Integer_Wide_Wide_Text_IO
+ child of Ada *note A.11(3/2): 7054.
+
+Integer_IO
+ in Ada.Text_IO *note A.10.1(52): 6949.
+
+Interfaces *note B.2(3): 7980.
+
+Interrupts
+ child of Ada *note C.3.2(2/3): 8224.
+ child of Ada.Execution_Time *note D.14.3(3/3): 8646.
+
+IO_Exceptions
+ child of Ada *note A.13(3): 7114.
+
+Iterator_Interfaces
+ child of Ada *note 5.5.1(2/3): 3439.
+
+Latin_1
+ child of Ada.Characters *note A.3.3(3): 5947.
+
+List_Iterator_Interfaces
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(9.2/3): 7343.
+
+Locales
+ child of Ada *note A.19(3/3): 7925.
+
+Machine_Code
+ child of System *note 13.8(7): 5581.
+
+Map_Iterator_Interfaces
+ in Ada.Containers.Hashed_Maps *note A.18.5(6.2/3): 7434.
+ in Ada.Containers.Ordered_Maps *note A.18.6(7.2/3): 7490.
+
+Maps
+ child of Ada.Strings *note A.4.2(3/2): 6237.
+
+Modular_IO
+ in Ada.Text_IO *note A.10.1(57): 6958.
+
+Multiprocessors
+ child of System *note D.16(3/3): 8663.
+
+Multiway_Trees
+ child of Ada.Containers *note A.18.10(7/3): 7733.
+
+Names
+ child of Ada.Interrupts *note C.3.2(12): 8235.
+
+Non_Preemptive
+ child of Ada.Dispatching *note D.2.4(2.2/3): 8377.
+
+Numerics
+ child of Ada *note A.5(3/2): 6579.
+
+Ordered_Maps
+ child of Ada.Containers *note A.18.6(2/3): 7483.
+
+Ordered_Sets
+ child of Ada.Containers *note A.18.9(2/3): 7642.
+
+Pointers
+ child of Interfaces.C *note B.3.2(4): 8076.
+
+Real_Arrays
+ child of Ada.Numerics *note G.3.1(31/2): 9000.
+
+Real_Time
+ child of Ada *note D.8(3): 8521.
+
+Round_Robin
+ child of Ada.Dispatching *note D.2.5(4/2): 8386.
+
+RPC
+ child of System *note E.5(3): 8808.
+
+Sequential_IO
+ child of Ada *note A.8.1(2): 6781.
+
+Set_Iterator_Interfaces
+ in Ada.Containers.Hashed_Sets *note A.18.8(6.2/3): 7573.
+ in Ada.Containers.Ordered_Sets *note A.18.9(7.2/3): 7649.
+
+Single_Precision_Complex_Types
+ in Interfaces.Fortran *note B.5(8): 8165.
+
+Standard *note A.1(4): 5878.
+
+Storage_Elements
+ child of System *note 13.7.1(2/2): 5559.
+
+Storage_IO
+ child of Ada *note A.9(3): 6839.
+
+Storage_Pools
+ child of System *note 13.11(5): 5622.
+
+Stream_IO
+ child of Ada.Streams *note A.12.1(3/3): 7065.
+
+Streams
+ child of Ada *note 13.13.1(2): 5776.
+
+Strings
+ child of Ada *note A.4.1(3): 6223.
+ child of Ada.Strings.UTF_Encoding *note A.4.11(22/3): 6553.
+ child of Interfaces.C *note B.3.1(3): 8052.
+
+Subpools
+ child of System.Storage_Pools *note 13.11.4(3/3): 5694.
+
+Synchronized_Queue_Interfaces
+ child of Ada.Containers *note A.18.27(3/3): 7886.
+
+Synchronous_Barriers
+ child of Ada *note D.10.1(3/3): 8567.
+
+Synchronous_Task_Control
+ child of Ada *note D.10(3/2): 8554.
+
+System *note 13.7(3/2): 5530.
+
+Tags
+ child of Ada *note 3.9(6/2): 2229.
+
+Task_Attributes
+ child of Ada *note C.7.2(2): 8293.
+
+Task_Identification
+ child of Ada *note C.7.1(2/2): 8272.
+
+Task_Termination
+ child of Ada *note C.7.3(2/2): 8305.
+
+Text_Streams
+ child of Ada.Text_IO *note A.12.2(3): 7104.
+ child of Ada.Wide_Text_IO *note A.12.3(3): 7107.
+ child of Ada.Wide_Wide_Text_IO *note A.12.4(3/2): 7110.
+
+Text_IO
+ child of Ada *note A.10.1(2): 6860.
+
+Time_Zones
+ child of Ada.Calendar *note 9.6.1(2/2): 4485.
+
+Timers
+ child of Ada.Execution_Time *note D.14.1(3/2): 8603.
+
+Timing_Events
+ child of Ada.Real_Time *note D.15(3/2): 8650.
+
+Tree_Iterator_Interfaces
+ in Ada.Containers.Multiway_Trees *note A.18.10(13/3): 7739.
+
+Unbounded
+ child of Ada.Strings *note A.4.5(3): 6362.
+
+Unbounded_IO
+ child of Ada.Text_IO *note A.10.12(3/2): 7040.
+ child of Ada.Wide_Text_IO *note A.11(5/3): 7058.
+ child of Ada.Wide_Wide_Text_IO *note A.11(5/3): 7059.
+
+Unbounded_Priority_Queues
+ child of Ada.Containers *note A.18.30(2/3): 7908.
+
+Unbounded_Synchronized_Queues
+ child of Ada.Containers *note A.18.28(2/3): 7894.
+
+UTF_Encoding
+ child of Ada.Strings *note A.4.11(3/3): 6536.
+
+Vector_Iterator_Interfaces
+ in Ada.Containers.Vectors *note A.18.2(11.2/3): 7244.
+
+Vectors
+ child of Ada.Containers *note A.18.2(6/3): 7236.
+
+Wide_Bounded
+ child of Ada.Strings *note A.4.7(1/3): 6434.
+
+Wide_Constants
+ child of Ada.Strings.Wide_Maps *note A.4.7(1/3): 6448, *note
+A.4.8(28/2): 6512.
+
+Wide_Equal_Case_Insensitive
+ child of Ada.Strings *note A.4.7(1/3): 6440.
+
+Wide_Fixed
+ child of Ada.Strings *note A.4.7(1/3): 6433.
+
+Wide_Hash
+ child of Ada.Strings *note A.4.7(1/3): 6436.
+
+Wide_Hash_Case_Insensitive
+ child of Ada.Strings *note A.4.7(1/3): 6444.
+
+Wide_Maps
+ child of Ada.Strings *note A.4.7(3): 6449.
+
+Wide_Text_IO
+ child of Ada *note A.11(2/2): 7050.
+
+Wide_Unbounded
+ child of Ada.Strings *note A.4.7(1/3): 6435.
+
+Wide_Characters
+ child of Ada *note A.3.1(4/2): 5904.
+
+Wide_Strings
+ child of Ada.Strings.UTF_Encoding *note A.4.11(30/3): 6560.
+
+Wide_Wide_Constants
+ child of Ada.Strings.Wide_Wide_Maps *note A.4.8(1/3): 6490.
+
+Wide_Wide_Equal_Case_Insensitive
+ child of Ada.Strings *note A.4.8(1/3): 6482.
+
+Wide_Wide_Hash
+ child of Ada.Strings *note A.4.8(1/3): 6478.
+
+Wide_Wide_Hash_Case_Insensitive
+ child of Ada.Strings *note A.4.8(1/3): 6486.
+
+Wide_Wide_Text_IO
+ child of Ada *note A.11(3/2): 7053.
+
+Wide_Wide_Bounded
+ child of Ada.Strings *note A.4.8(1/3): 6476.
+
+Wide_Wide_Characters
+ child of Ada *note A.3.1(6/2): 5905.
+
+Wide_Wide_Fixed
+ child of Ada.Strings *note A.4.8(1/3): 6475.
+
+Wide_Wide_Maps
+ child of Ada.Strings *note A.4.8(3/2): 6491.
+
+Wide_Wide_Strings
+ child of Ada.Strings.UTF_Encoding *note A.4.11(38/3): 6567.
+
+Wide_Wide_Unbounded
+ child of Ada.Strings *note A.4.8(1/3): 6477.
+
+\1f
+File: aarm2012.info, Node: Q.2, Next: Q.3, Prev: Q.1, Up: Annex Q
+
+Q.2 Language-Defined Types and Subtypes
+=======================================
+
+1/3
+{AI95-00440-01AI95-00440-01} {AI05-0299-1AI05-0299-1} This subclause
+lists all language-defined types and subtypes.
+
+
+
+Address
+ in System *note 13.7(12): 5542.
+
+Alignment
+ in Ada.Strings *note A.4.1(6): 6231.
+
+Alphanumeric
+ in Interfaces.COBOL *note B.4(16/3): 8118.
+
+Any_Priority subtype of Integer
+ in System *note 13.7(16): 5552.
+
+Attribute_Handle
+ in Ada.Task_Attributes *note C.7.2(3): 8294.
+
+Barrier_Limit subtype of Positive
+ in Ada.Synchronous_Barriers *note D.10.1(4/3): 8568.
+
+Binary
+ in Interfaces.COBOL *note B.4(10): 8109.
+
+Binary_Format
+ in Interfaces.COBOL *note B.4(24): 8130.
+
+Bit_Order
+ in System *note 13.7(15/2): 5548.
+
+Boolean
+ in Standard *note A.1(5): 5879.
+
+Bounded_String
+ in Ada.Strings.Bounded *note A.4.4(6): 6303.
+
+Buffer_Type subtype of Storage_Array
+ in Ada.Storage_IO *note A.9(4): 6841.
+
+Byte
+ in Interfaces.COBOL *note B.4(29/3): 8137.
+
+Byte_Array
+ in Interfaces.COBOL *note B.4(29/3): 8138.
+
+C_float
+ in Interfaces.C *note B.3(15): 8002.
+
+Cause_Of_Termination
+ in Ada.Task_Termination *note C.7.3(3/2): 8306.
+
+char
+ in Interfaces.C *note B.3(19): 8005.
+
+char16_array
+ in Interfaces.C *note B.3(39.5/3): 8029.
+
+char16_t
+ in Interfaces.C *note B.3(39.2/2): 8025.
+
+char32_array
+ in Interfaces.C *note B.3(39.14/3): 8039.
+
+char32_t
+ in Interfaces.C *note B.3(39.11/2): 8035.
+
+char_array
+ in Interfaces.C *note B.3(23/3): 8009.
+
+char_array_access
+ in Interfaces.C.Strings *note B.3.1(4): 8053.
+
+Character
+ in Standard *note A.1(35/3): 5884.
+
+Character_Mapping
+ in Ada.Strings.Maps *note A.4.2(20/2): 6251.
+
+Character_Mapping_Function
+ in Ada.Strings.Maps *note A.4.2(25): 6257.
+
+Character_Range
+ in Ada.Strings.Maps *note A.4.2(6): 6240.
+
+Character_Ranges
+ in Ada.Strings.Maps *note A.4.2(7): 6241.
+
+Character_Sequence subtype of String
+ in Ada.Strings.Maps *note A.4.2(16): 6247.
+
+Character_Set
+ in Ada.Strings.Maps *note A.4.2(4/2): 6238.
+ in Interfaces.Fortran *note B.5(11): 8170.
+
+chars_ptr
+ in Interfaces.C.Strings *note B.3.1(5/2): 8054.
+
+chars_ptr_array
+ in Interfaces.C.Strings *note B.3.1(6/2): 8055.
+
+COBOL_Character
+ in Interfaces.COBOL *note B.4(13): 8115.
+
+Complex
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(3): 8867.
+ in Interfaces.Fortran *note B.5(9): 8166.
+
+Complex_Matrix
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(4/2): 9007.
+
+Complex_Vector
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(4/2): 9006.
+
+Constant_Reference_Type
+ in Ada.Containers.Indefinite_Holders *note A.18.18(16/3): 7834.
+ in Ada.Containers.Multiway_Trees *note A.18.10(28/3): 7753.
+
+Controlled
+ in Ada.Finalization *note 7.6(5/2): 3928.
+
+Count
+ in Ada.Direct_IO *note A.8.4(4): 6810.
+ in Ada.Streams.Stream_IO *note A.12.1(7): 7069.
+ in Ada.Text_IO *note A.10.1(5): 6863.
+
+Count_Type
+ in Ada.Containers *note A.18.1(5/2): 7227.
+
+Country_Code
+ in Ada.Locales *note A.19(4/3): 7927.
+
+CPU subtype of CPU_Range
+ in System.Multiprocessors *note D.16(4/3): 8666.
+
+CPU_Range
+ in System.Multiprocessors *note D.16(4/3): 8664.
+
+CPU_Time
+ in Ada.Execution_Time *note D.14(4/2): 8586.
+
+Cursor
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(7/2): 7339.
+ in Ada.Containers.Hashed_Maps *note A.18.5(4/2): 7430.
+ in Ada.Containers.Hashed_Sets *note A.18.8(4/2): 7569.
+ in Ada.Containers.Multiway_Trees *note A.18.10(9/3): 7735.
+ in Ada.Containers.Ordered_Maps *note A.18.6(5/2): 7486.
+ in Ada.Containers.Ordered_Sets *note A.18.9(5/2): 7645.
+ in Ada.Containers.Vectors *note A.18.2(9/2): 7240.
+
+Day_Count
+ in Ada.Calendar.Arithmetic *note 9.6.1(10/2): 4490.
+
+Day_Duration subtype of Duration
+ in Ada.Calendar *note 9.6(11/2): 4463.
+
+Day_Name
+ in Ada.Calendar.Formatting *note 9.6.1(17/2): 4494.
+
+Day_Number subtype of Integer
+ in Ada.Calendar *note 9.6(11/2): 4462.
+
+Deadline subtype of Time
+ in Ada.Dispatching.EDF *note D.2.6(9/2): 8396.
+
+Decimal_Element
+ in Interfaces.COBOL *note B.4(12/3): 8113.
+
+Direction
+ in Ada.Strings *note A.4.1(6): 6234.
+
+Directory_Entry_Type
+ in Ada.Directories *note A.16(29/2): 7161.
+
+Dispatching_Domain
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(5/3):
+8673.
+
+Display_Format
+ in Interfaces.COBOL *note B.4(22): 8124.
+
+double
+ in Interfaces.C *note B.3(16): 8003.
+
+Double_Precision
+ in Interfaces.Fortran *note B.5(6): 8163.
+
+Duration
+ in Standard *note A.1(43): 5892.
+
+Encoding_Scheme
+ in Ada.Strings.UTF_Encoding *note A.4.11(4/3): 6537.
+
+Exception_Id
+ in Ada.Exceptions *note 11.4.1(2/2): 4928.
+
+Exception_Occurrence
+ in Ada.Exceptions *note 11.4.1(3/2): 4933.
+
+Exception_Occurrence_Access
+ in Ada.Exceptions *note 11.4.1(3/2): 4934.
+
+Exit_Status
+ in Ada.Command_Line *note A.15(7): 7131.
+
+Extended_Index subtype of Index_Type'Base
+ in Ada.Containers.Vectors *note A.18.2(7/2): 7237.
+
+Field subtype of Integer
+ in Ada.Text_IO *note A.10.1(6): 6866.
+
+File_Access
+ in Ada.Text_IO *note A.10.1(18): 6888.
+
+File_Kind
+ in Ada.Directories *note A.16(22/2): 7155.
+
+File_Mode
+ in Ada.Direct_IO *note A.8.4(4): 6809.
+ in Ada.Sequential_IO *note A.8.1(4): 6783.
+ in Ada.Streams.Stream_IO *note A.12.1(6): 7068.
+ in Ada.Text_IO *note A.10.1(4): 6862.
+
+File_Size
+ in Ada.Directories *note A.16(23/2): 7156.
+
+File_Type
+ in Ada.Direct_IO *note A.8.4(3): 6808.
+ in Ada.Sequential_IO *note A.8.1(3): 6782.
+ in Ada.Streams.Stream_IO *note A.12.1(5): 7067.
+ in Ada.Text_IO *note A.10.1(3): 6861.
+
+Filter_Type
+ in Ada.Directories *note A.16(30/2): 7162.
+
+Float
+ in Standard *note A.1(21): 5883.
+
+Floating
+ in Interfaces.COBOL *note B.4(9): 8107.
+
+Fortran_Character
+ in Interfaces.Fortran *note B.5(12/3): 8171.
+
+Fortran_Integer
+ in Interfaces.Fortran *note B.5(5): 8161.
+
+Forward_Iterator
+ in Ada.Iterator_Interfaces *note 5.5.1(3/3): 3440.
+
+Generator
+ in Ada.Numerics.Discrete_Random *note A.5.2(19): 6636.
+ in Ada.Numerics.Float_Random *note A.5.2(7): 6623.
+
+Group_Budget
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(4/3): 8620.
+
+Group_Budget_Handler
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(5/2): 8621.
+
+Hash_Type
+ in Ada.Containers *note A.18.1(4/2): 7226.
+
+Holder
+ in Ada.Containers.Indefinite_Holders *note A.18.18(6/3): 7825.
+
+Hour_Number subtype of Natural
+ in Ada.Calendar.Formatting *note 9.6.1(20/2): 4503.
+
+Imaginary
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(4/2): 8868.
+
+Imaginary subtype of Imaginary
+ in Interfaces.Fortran *note B.5(10): 8167.
+
+int
+ in Interfaces.C *note B.3(7): 7991.
+
+Integer
+ in Standard *note A.1(12): 5880.
+
+Integer_Address
+ in System.Storage_Elements *note 13.7.1(10/3): 5565.
+
+Interrupt_Id
+ in Ada.Interrupts *note C.3.2(2/3): 8225.
+
+Interrupt_Priority subtype of Any_Priority
+ in System *note 13.7(16): 5554.
+
+ISO_646 subtype of Character
+ in Ada.Characters.Handling *note A.3.2(9): 5930.
+
+Language_Code
+ in Ada.Locales *note A.19(4/3): 7926.
+
+Leap_Seconds_Count subtype of Integer
+ in Ada.Calendar.Arithmetic *note 9.6.1(11/2): 4491.
+
+Length_Range subtype of Natural
+ in Ada.Strings.Bounded *note A.4.4(8): 6305.
+
+Limited_Controlled
+ in Ada.Finalization *note 7.6(7/2): 3932.
+
+List
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(6/3): 7338.
+
+Logical
+ in Interfaces.Fortran *note B.5(7): 8164.
+
+long
+ in Interfaces.C *note B.3(7): 7993.
+
+Long_Binary
+ in Interfaces.COBOL *note B.4(10): 8110.
+
+long_double
+ in Interfaces.C *note B.3(17): 8004.
+
+Long_Floating
+ in Interfaces.COBOL *note B.4(9): 8108.
+
+Map
+ in Ada.Containers.Hashed_Maps *note A.18.5(3/3): 7429.
+ in Ada.Containers.Ordered_Maps *note A.18.6(4/3): 7485.
+
+Membership
+ in Ada.Strings *note A.4.1(6): 6233.
+
+Minute_Number subtype of Natural
+ in Ada.Calendar.Formatting *note 9.6.1(20/2): 4504.
+
+Month_Number subtype of Integer
+ in Ada.Calendar *note 9.6(11/2): 4461.
+
+Name
+ in System *note 13.7(4): 5531.
+
+Name_Case_Kind
+ in Ada.Directories *note A.16(20.1/3): 7153.
+
+Natural subtype of Integer
+ in Standard *note A.1(13): 5881.
+
+Number_Base subtype of Integer
+ in Ada.Text_IO *note A.10.1(6): 6867.
+
+Numeric
+ in Interfaces.COBOL *note B.4(20/3): 8123.
+
+Packed_Decimal
+ in Interfaces.COBOL *note B.4(12/3): 8114.
+
+Packed_Format
+ in Interfaces.COBOL *note B.4(26): 8134.
+
+Parameterless_Handler
+ in Ada.Interrupts *note C.3.2(2/3): 8226.
+
+Params_Stream_Type
+ in System.RPC *note E.5(6): 8811.
+
+Partition_Id
+ in System.RPC *note E.5(4): 8809.
+
+Picture
+ in Ada.Text_IO.Editing *note F.3.3(4): 8841.
+
+plain_char
+ in Interfaces.C *note B.3(11): 7999.
+
+Pointer
+ in Interfaces.C.Pointers *note B.3.2(5): 8077.
+
+Positive subtype of Integer
+ in Standard *note A.1(13): 5882.
+
+Positive_Count subtype of Count
+ in Ada.Direct_IO *note A.8.4(4): 6811.
+ in Ada.Streams.Stream_IO *note A.12.1(7): 7070.
+ in Ada.Text_IO *note A.10.1(5): 6864.
+
+Priority subtype of Any_Priority
+ in System *note 13.7(16): 5553.
+
+ptrdiff_t
+ in Interfaces.C *note B.3(12): 8000.
+
+Queue
+ in Ada.Containers.Bounded_Priority_Queues *note A.18.31(4/3): 7917.
+ in Ada.Containers.Bounded_Synchronized_Queues *note A.18.29(4/3):
+7902.
+ in Ada.Containers.Synchronized_Queue_Interfaces *note A.18.27(4/3):
+7887.
+ in Ada.Containers.Unbounded_Priority_Queues *note A.18.30(4/3):
+7909.
+ in Ada.Containers.Unbounded_Synchronized_Queues *note A.18.28(4/3):
+7895.
+
+Real
+ in Interfaces.Fortran *note B.5(6): 8162.
+
+Real_Matrix
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(4/2): 8990.
+
+Real_Vector
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(4/2): 8989.
+
+Reference_Type
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(17.2/3): 7351.
+ in Ada.Containers.Hashed_Maps *note A.18.5(17.2/3): 7445.
+ in Ada.Containers.Hashed_Sets *note A.18.8(58.1/3): 7623.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(17/3): 7835.
+ in Ada.Containers.Multiway_Trees *note A.18.10(29/3): 7754.
+ in Ada.Containers.Ordered_Maps *note A.18.6(16.2/3): 7499.
+ in Ada.Containers.Ordered_Sets *note A.18.9(73.1/3): 7707.
+ in Ada.Containers.Vectors *note A.18.2(34.2/3): 7263.
+
+Reversible_Iterator
+ in Ada.Iterator_Interfaces *note 5.5.1(4/3): 3443.
+
+Root_Storage_Pool
+ in System.Storage_Pools *note 13.11(6/2): 5623.
+
+Root_Storage_Pool_With_Subpools
+ in System.Storage_Pools.Subpools *note 13.11.4(4/3): 5695.
+
+Root_Stream_Type
+ in Ada.Streams *note 13.13.1(3/2): 5778.
+
+Root_Subpool
+ in System.Storage_Pools.Subpools *note 13.11.4(5/3): 5696.
+
+RPC_Receiver
+ in System.RPC *note E.5(11): 8816.
+
+Search_Type
+ in Ada.Directories *note A.16(31/2): 7163.
+
+Second_Duration subtype of Day_Duration
+ in Ada.Calendar.Formatting *note 9.6.1(20/2): 4506.
+
+Second_Number subtype of Natural
+ in Ada.Calendar.Formatting *note 9.6.1(20/2): 4505.
+
+Seconds_Count
+ in Ada.Real_Time *note D.8(15): 8540.
+
+Set
+ in Ada.Containers.Hashed_Sets *note A.18.8(3/3): 7568.
+ in Ada.Containers.Ordered_Sets *note A.18.9(4/3): 7644.
+
+short
+ in Interfaces.C *note B.3(7): 7992.
+
+signed_char
+ in Interfaces.C *note B.3(8): 7994.
+
+size_t
+ in Interfaces.C *note B.3(13): 8001.
+
+State
+ in Ada.Numerics.Discrete_Random *note A.5.2(23): 6640.
+ in Ada.Numerics.Float_Random *note A.5.2(11): 6628.
+
+Storage_Array
+ in System.Storage_Elements *note 13.7.1(5): 5563.
+
+Storage_Count subtype of Storage_Offset
+ in System.Storage_Elements *note 13.7.1(4): 5561.
+
+Storage_Element
+ in System.Storage_Elements *note 13.7.1(5): 5562.
+
+Storage_Offset
+ in System.Storage_Elements *note 13.7.1(3): 5560.
+
+Stream_Access
+ in Ada.Streams.Stream_IO *note A.12.1(4): 7066.
+ in Ada.Text_IO.Text_Streams *note A.12.2(3): 7105.
+ in Ada.Wide_Text_IO.Text_Streams *note A.12.3(3): 7108.
+ in Ada.Wide_Wide_Text_IO.Text_Streams *note A.12.4(3/2): 7111.
+
+Stream_Element
+ in Ada.Streams *note 13.13.1(4/1): 5779.
+
+Stream_Element_Array
+ in Ada.Streams *note 13.13.1(4/1): 5782.
+
+Stream_Element_Count subtype of Stream_Element_Offset
+ in Ada.Streams *note 13.13.1(4/1): 5781.
+
+Stream_Element_Offset
+ in Ada.Streams *note 13.13.1(4/1): 5780.
+
+String
+ in Standard *note A.1(37/3): 5889.
+
+String_Access
+ in Ada.Strings.Unbounded *note A.4.5(7): 6366.
+
+Subpool_Handle
+ in System.Storage_Pools.Subpools *note 13.11.4(6/3): 5697.
+
+Suspension_Object
+ in Ada.Synchronous_Task_Control *note D.10(4): 8555.
+
+Synchronous_Barrier
+ in Ada.Synchronous_Barriers *note D.10.1(5/3): 8569.
+
+Tag
+ in Ada.Tags *note 3.9(6/2): 2230.
+
+Tag_Array
+ in Ada.Tags *note 3.9(7.3/2): 2240.
+
+Task_Array
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(6/2): 8622.
+
+Task_Id
+ in Ada.Task_Identification *note C.7.1(2/2): 8273.
+
+Termination_Handler
+ in Ada.Task_Termination *note C.7.3(4/2): 8307.
+
+Time
+ in Ada.Calendar *note 9.6(10): 4459.
+ in Ada.Real_Time *note D.8(4): 8522.
+
+Time_Offset
+ in Ada.Calendar.Time_Zones *note 9.6.1(4/2): 4486.
+
+Time_Span
+ in Ada.Real_Time *note D.8(5): 8526.
+
+Timer
+ in Ada.Execution_Time.Timers *note D.14.1(4/2): 8604.
+
+Timer_Handler
+ in Ada.Execution_Time.Timers *note D.14.1(5/2): 8605.
+
+Timing_Event
+ in Ada.Real_Time.Timing_Events *note D.15(4/2): 8651.
+
+Timing_Event_Handler
+ in Ada.Real_Time.Timing_Events *note D.15(4/2): 8652.
+
+Tree
+ in Ada.Containers.Multiway_Trees *note A.18.10(8/3): 7734.
+
+Trim_End
+ in Ada.Strings *note A.4.1(6): 6235.
+
+Truncation
+ in Ada.Strings *note A.4.1(6): 6232.
+
+Type_Set
+ in Ada.Text_IO *note A.10.1(7): 6868.
+
+Unbounded_String
+ in Ada.Strings.Unbounded *note A.4.5(4/2): 6363.
+
+Uniformly_Distributed subtype of Float
+ in Ada.Numerics.Float_Random *note A.5.2(8): 6624.
+
+unsigned
+ in Interfaces.C *note B.3(9): 7995.
+
+unsigned_char
+ in Interfaces.C *note B.3(10): 7998.
+
+unsigned_long
+ in Interfaces.C *note B.3(9): 7997.
+
+unsigned_short
+ in Interfaces.C *note B.3(9): 7996.
+
+UTF_16_Wide_String subtype of Wide_String
+ in Ada.Strings.UTF_Encoding *note A.4.11(7/3): 6540.
+
+UTF_8_String subtype of String
+ in Ada.Strings.UTF_Encoding *note A.4.11(6/3): 6539.
+
+UTF_String subtype of String
+ in Ada.Strings.UTF_Encoding *note A.4.11(5/3): 6538.
+
+Vector
+ in Ada.Containers.Vectors *note A.18.2(8/3): 7239.
+
+wchar_array
+ in Interfaces.C *note B.3(33/3): 8019.
+
+wchar_t
+ in Interfaces.C *note B.3(30/1): 8015.
+
+Wide_Character
+ in Standard *note A.1(36.1/3): 5885.
+
+Wide_Character_Mapping
+ in Ada.Strings.Wide_Maps *note A.4.7(20/2): 6463.
+
+Wide_Character_Mapping_Function
+ in Ada.Strings.Wide_Maps *note A.4.7(26): 6469.
+
+Wide_Character_Range
+ in Ada.Strings.Wide_Maps *note A.4.7(6): 6452.
+
+Wide_Character_Ranges
+ in Ada.Strings.Wide_Maps *note A.4.7(7): 6453.
+
+Wide_Character_Sequence subtype of Wide_String
+ in Ada.Strings.Wide_Maps *note A.4.7(16): 6459.
+
+Wide_Character_Set
+ in Ada.Strings.Wide_Maps *note A.4.7(4/2): 6450.
+
+Wide_String
+ in Standard *note A.1(41/3): 5890.
+
+Wide_Wide_Character
+ in Standard *note A.1(36.2/3): 5886.
+
+Wide_Wide_Character_Mapping
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(20/2): 6505.
+
+Wide_Wide_Character_Mapping_Function
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(26/2): 6511.
+
+Wide_Wide_Character_Range
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(6/2): 6494.
+
+Wide_Wide_Character_Ranges
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(7/2): 6495.
+
+Wide_Wide_Character_Sequence subtype of Wide_Wide_String
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(16/2): 6501.
+
+Wide_Wide_Character_Set
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(4/2): 6492.
+
+Wide_Wide_String
+ in Standard *note A.1(42.1/3): 5891.
+
+Year_Number subtype of Integer
+ in Ada.Calendar *note 9.6(11/2): 4460.
+
+\1f
+File: aarm2012.info, Node: Q.3, Next: Q.4, Prev: Q.2, Up: Annex Q
+
+Q.3 Language-Defined Subprograms
+================================
+
+1/3
+{AI95-00440-01AI95-00440-01} {AI05-0299-1AI05-0299-1} This subclause
+lists all language-defined subprograms.
+
+
+
+Abort_Task in Ada.Task_Identification *note C.7.1(3/3): 8278.
+
+Activation_Is_Complete
+ in Ada.Task_Identification *note C.7.1(4/3): 8281.
+
+Actual_Quantum
+ in Ada.Dispatching.Round_Robin *note D.2.5(4/2): 8390.
+
+Ada.Unchecked_Deallocate_Subpool
+ child of Ada *note 13.11.5(3/3): 5725.
+
+Add
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(9/2): 8630.
+
+Add_Task
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(8/2): 8624.
+
+Adjust in Ada.Finalization *note 7.6(6/2): 3930.
+
+Allocate
+ in System.Storage_Pools *note 13.11(7): 5624.
+ in System.Storage_Pools.Subpools *note 13.11.4(14/3): 5704.
+
+Allocate_From_Subpool
+ in System.Storage_Pools.Subpools *note 13.11.4(11/3): 5701.
+
+Ancestor_Find
+ in Ada.Containers.Multiway_Trees *note A.18.10(40/3): 7765.
+
+Append
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(23/2): 7361.
+ in Ada.Containers.Vectors *note A.18.2(46/2): 7281, *note
+A.18.2(47/2): 7282.
+ in Ada.Strings.Bounded *note A.4.4(13): 6310, *note A.4.4(14):
+6311, *note A.4.4(15): 6312, *note A.4.4(16): 6313, *note A.4.4(17):
+6314, *note A.4.4(18): 6315, *note A.4.4(19): 6316, *note A.4.4(20):
+6317.
+ in Ada.Strings.Unbounded *note A.4.5(12): 6372, *note A.4.5(13):
+6373, *note A.4.5(14): 6374.
+
+Append_Child
+ in Ada.Containers.Multiway_Trees *note A.18.10(52/3): 7777.
+
+Arccos
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(5): 8904.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(6): 6600.
+
+Arccosh
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(7): 8912.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6611.
+
+Arccot
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(5): 8906.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(6): 6605.
+
+Arccoth
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(7): 8914.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6613.
+
+Arcsin
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(5): 8903.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(6): 6599.
+
+Arcsinh
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(7): 8911.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6610.
+
+Arctan
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(5): 8905.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(6): 6602.
+
+Arctanh
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(7): 8913.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6612.
+
+Argument
+ in Ada.Command_Line *note A.15(5): 7129.
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(10/2): 9016,
+*note G.3.2(31/2): 9028.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(10): 8881.
+
+Argument_Count in Ada.Command_Line *note A.15(4): 7128.
+
+Assert in Ada.Assertions *note 11.4.2(14/2): 4974.
+
+Assign
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(17.5/3): 7354.
+ in Ada.Containers.Hashed_Maps *note A.18.5(17.7/3): 7450.
+ in Ada.Containers.Hashed_Sets *note A.18.8(17.3/3): 7585.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(20/3): 7838.
+ in Ada.Containers.Multiway_Trees *note A.18.10(32/3): 7757.
+ in Ada.Containers.Ordered_Maps *note A.18.6(16.7/3): 7504.
+ in Ada.Containers.Ordered_Sets *note A.18.9(16.3/3): 7659.
+ in Ada.Containers.Vectors *note A.18.2(34.7/3): 7268.
+
+Assign_Task
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(11/3):
+8679.
+
+Attach_Handler in Ada.Interrupts *note C.3.2(7): 8230.
+
+Base_Name in Ada.Directories *note A.16(19/2): 7151.
+
+Blank_When_Zero
+ in Ada.Text_IO.Editing *note F.3.3(7): 8845.
+
+Bounded_Slice in Ada.Strings.Bounded *note A.4.4(28.1/2): 6321, *note
+A.4.4(28.2/2): 6322.
+
+Budget_Has_Expired
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(9/2): 8631.
+
+Budget_Remaining
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(9/2): 8632.
+
+Cancel_Handler
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(10/2): 8635.
+ in Ada.Execution_Time.Timers *note D.14.1(7/2): 8610.
+ in Ada.Real_Time.Timing_Events *note D.15(5/2): 8656.
+
+Capacity
+ in Ada.Containers.Hashed_Maps *note A.18.5(8/2): 7435.
+ in Ada.Containers.Hashed_Sets *note A.18.8(10/2): 7576.
+ in Ada.Containers.Vectors *note A.18.2(19/2): 7247.
+
+Ceiling
+ in Ada.Containers.Ordered_Maps *note A.18.6(41/2): 7530.
+ in Ada.Containers.Ordered_Sets *note A.18.9(51/2): 7691, *note
+A.18.9(71/2): 7704.
+
+Character_Set_Version
+ in Ada.Wide_Characters.Handling *note A.3.5(4/3): 6199.
+
+Child_Count
+ in Ada.Containers.Multiway_Trees *note A.18.10(46/3): 7771.
+
+Child_Depth
+ in Ada.Containers.Multiway_Trees *note A.18.10(47/3): 7772.
+
+Clear
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(13/2): 7346.
+ in Ada.Containers.Hashed_Maps *note A.18.5(12/2): 7439.
+ in Ada.Containers.Hashed_Sets *note A.18.8(14/2): 7580.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(11/3): 7829.
+ in Ada.Containers.Multiway_Trees *note A.18.10(23/3): 7748.
+ in Ada.Containers.Ordered_Maps *note A.18.6(11/2): 7493.
+ in Ada.Containers.Ordered_Sets *note A.18.9(13/2): 7654.
+ in Ada.Containers.Vectors *note A.18.2(24/2): 7252.
+ in Ada.Environment_Variables *note A.17(7/2): 7211.
+
+Clock
+ in Ada.Calendar *note 9.6(12): 4464.
+ in Ada.Execution_Time *note D.14(5/2): 8591.
+ in Ada.Execution_Time.Interrupts *note D.14.3(3/3): 8647.
+ in Ada.Real_Time *note D.8(6): 8532.
+
+Clock_For_Interrupts
+ in Ada.Execution_Time *note D.14(9.3/3): 8596.
+
+Close
+ in Ada.Direct_IO *note A.8.4(8): 6814.
+ in Ada.Sequential_IO *note A.8.1(8): 6786.
+ in Ada.Streams.Stream_IO *note A.12.1(10): 7073.
+ in Ada.Text_IO *note A.10.1(11): 6871.
+
+Col in Ada.Text_IO *note A.10.1(37): 6924.
+
+Command_Name in Ada.Command_Line *note A.15(6): 7130.
+
+Compose
+ in Ada.Directories *note A.16(20/2): 7152.
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(14/3):
+7202.
+
+Compose_From_Cartesian
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(9/2): 9012,
+*note G.3.2(29/2): 9026.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(8): 8879.
+
+Compose_From_Polar
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(11/2): 9018,
+*note G.3.2(32/2): 9031.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(11): 8884.
+
+Conjugate
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(13/2): 9019,
+*note G.3.2(34/2): 9032.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(12): 8885, *note
+G.1.1(15): 8886.
+
+Constant_Reference
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(17.3/3): 7352.
+ in Ada.Containers.Hashed_Maps *note A.18.5(17.3/3): 7446, *note
+A.18.5(17.5/3): 7448.
+ in Ada.Containers.Hashed_Sets *note A.18.8(17.2/3): 7584, *note
+A.18.8(58.3/3): 7625.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(18/3): 7836.
+ in Ada.Containers.Multiway_Trees *note A.18.10(30/3): 7755.
+ in Ada.Containers.Ordered_Maps *note A.18.6(16.3/3): 7500, *note
+A.18.6(16.5/3): 7502.
+ in Ada.Containers.Ordered_Sets *note A.18.9(16.2/3): 7658, *note
+A.18.9(73.3/3): 7709.
+ in Ada.Containers.Vectors *note A.18.2(34.3/3): 7264, *note
+A.18.2(34.5/3): 7266.
+
+Containing_Directory
+ in Ada.Directories *note A.16(17/2): 7149.
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(11/3):
+7199.
+
+Contains
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(43/2): 7381.
+ in Ada.Containers.Hashed_Maps *note A.18.5(32/2): 7466.
+ in Ada.Containers.Hashed_Sets *note A.18.8(44/2): 7609, *note
+A.18.8(57/2): 7621.
+ in Ada.Containers.Multiway_Trees *note A.18.10(41/3): 7766.
+ in Ada.Containers.Ordered_Maps *note A.18.6(42/2): 7531.
+ in Ada.Containers.Ordered_Sets *note A.18.9(52/2): 7692, *note
+A.18.9(72/2): 7705.
+ in Ada.Containers.Vectors *note A.18.2(71/2): 7306.
+
+Continue
+ in Ada.Asynchronous_Task_Control *note D.11(3/2): 8574.
+
+Convert
+ in Ada.Strings.UTF_Encoding.Conversions *note A.4.11(16/3): 6548,
+*note A.4.11(17/3): 6549, *note A.4.11(18/3): 6550, *note A.4.11(19/3):
+6551, *note A.4.11(20/3): 6552.
+
+Copy
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(17.6/3): 7355.
+ in Ada.Containers.Hashed_Maps *note A.18.5(17.8/3): 7451.
+ in Ada.Containers.Hashed_Sets *note A.18.8(17.4/3): 7586.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(21/3): 7839,
+*note A.18.20(10/3): 7853, *note A.18.21(13/3): 7858, *note
+A.18.22(10/3): 7862, *note A.18.23(13/3): 7867, *note A.18.24(10/3):
+7871.
+ in Ada.Containers.Multiway_Trees *note A.18.10(33/3): 7758.
+ in Ada.Containers.Ordered_Maps *note A.18.6(16.8/3): 7505.
+ in Ada.Containers.Ordered_Sets *note A.18.9(16.4/3): 7660.
+ in Ada.Containers.Vectors *note A.18.2(34.8/3): 7269.
+
+Copy_Array in Interfaces.C.Pointers *note B.3.2(15): 8085.
+
+Copy_File in Ada.Directories *note A.16(13/2): 7146.
+
+Copy_Subtree
+ in Ada.Containers.Multiway_Trees *note A.18.10(54/3): 7779.
+
+Copy_Terminated_Array
+ in Interfaces.C.Pointers *note B.3.2(14): 8084.
+
+Cos
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(4): 8900.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(5): 6593.
+
+Cosh
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(6): 8908.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6607.
+
+Cot
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(4): 8902.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(5): 6597.
+
+Coth
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(6): 8910.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6609.
+
+Count
+ in Ada.Strings.Bounded *note A.4.4(48): 6331, *note A.4.4(49):
+6332, *note A.4.4(50): 6333.
+ in Ada.Strings.Fixed *note A.4.3(13): 6272, *note A.4.3(14): 6273,
+*note A.4.3(15): 6274.
+ in Ada.Strings.Unbounded *note A.4.5(43): 6388, *note A.4.5(44):
+6389, *note A.4.5(45): 6390.
+
+Country in Ada.Locales *note A.19(6/3): 7931.
+
+Create
+ in Ada.Direct_IO *note A.8.4(6): 6812.
+ in Ada.Sequential_IO *note A.8.1(6): 6784.
+ in Ada.Streams.Stream_IO *note A.12.1(8): 7071.
+ in Ada.Text_IO *note A.10.1(9): 6869.
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(7/3):
+8675.
+
+Create_Directory in Ada.Directories *note A.16(7/2): 7140.
+
+Create_Path in Ada.Directories *note A.16(9/2): 7142.
+
+Create_Subpool
+ in System.Storage_Pools.Subpools *note 13.11.4(7/3): 5698.
+
+Current_Directory in Ada.Directories *note A.16(5/2): 7138.
+
+Current_Error in Ada.Text_IO *note A.10.1(17): 6887, *note A.10.1(20):
+6894.
+
+Current_Handler
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(10/2): 8634.
+ in Ada.Execution_Time.Timers *note D.14.1(7/2): 8609.
+ in Ada.Interrupts *note C.3.2(6): 8229.
+ in Ada.Real_Time.Timing_Events *note D.15(5/2): 8655.
+
+Current_Input in Ada.Text_IO *note A.10.1(17): 6885, *note A.10.1(20):
+6892.
+
+Current_Output in Ada.Text_IO *note A.10.1(17): 6886, *note
+A.10.1(20): 6893.
+
+Current_State
+ in Ada.Synchronous_Task_Control *note D.10(4): 8558.
+
+Current_Task
+ in Ada.Task_Identification *note C.7.1(3/3): 8276.
+
+Current_Task_Fallback_Handler
+ in Ada.Task_Termination *note C.7.3(5/2): 8309.
+
+Current_Use
+ in Ada.Containers.Bounded_Priority_Queues *note A.18.31(7/3): 7921.
+ in Ada.Containers.Bounded_Synchronized_Queues *note A.18.29(6/3):
+7905.
+ in Ada.Containers.Synchronized_Queue_Interfaces *note A.18.27(7/3):
+7890.
+ in Ada.Containers.Unbounded_Priority_Queues *note A.18.30(7/3):
+7913.
+ in Ada.Containers.Unbounded_Synchronized_Queues *note A.18.28(6/3):
+7898.
+
+Day
+ in Ada.Calendar *note 9.6(13): 4467.
+ in Ada.Calendar.Formatting *note 9.6.1(23/2): 4509.
+
+Day_of_Week
+ in Ada.Calendar.Formatting *note 9.6.1(18/2): 4502.
+
+Deallocate
+ in System.Storage_Pools *note 13.11(8): 5625.
+ in System.Storage_Pools.Subpools *note 13.11.4(15/3): 5705.
+
+Deallocate_Subpool
+ in System.Storage_Pools.Subpools *note 13.11.4(12/3): 5702.
+
+Decode
+ in Ada.Strings.UTF_Encoding.Strings *note A.4.11(26/3): 6557, *note
+A.4.11(27/3): 6558, *note A.4.11(28/3): 6559.
+ in Ada.Strings.UTF_Encoding.Wide_Strings *note A.4.11(34/3): 6564,
+*note A.4.11(35/3): 6565, *note A.4.11(36/3): 6566.
+ in Ada.Strings.UTF_Encoding.Wide_Wide_Strings *note A.4.11(42/3):
+6571, *note A.4.11(43/3): 6572, *note A.4.11(44/3): 6573.
+
+Decrement in Interfaces.C.Pointers *note B.3.2(11/3): 8082.
+
+Default_Modulus
+ in Ada.Containers.Indefinite_Holders *note A.18.21(10/3): 7857,
+*note A.18.23(10/3): 7866.
+
+Default_Subpool_for_Pool
+ in System.Storage_Pools.Subpools *note 13.11.4(13/3): 5703.
+
+Delay_Until_And_Set_CPU
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(14/3):
+8682.
+
+Delay_Until_And_Set_Deadline
+ in Ada.Dispatching.EDF *note D.2.6(9/2): 8399.
+
+Delete
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(24/2): 7362.
+ in Ada.Containers.Hashed_Maps *note A.18.5(25/2): 7459, *note
+A.18.5(26/2): 7460.
+ in Ada.Containers.Hashed_Sets *note A.18.8(24/2): 7593, *note
+A.18.8(25/2): 7594, *note A.18.8(55/2): 7619.
+ in Ada.Containers.Ordered_Maps *note A.18.6(24/2): 7513, *note
+A.18.6(25/2): 7514.
+ in Ada.Containers.Ordered_Sets *note A.18.9(23/2): 7667, *note
+A.18.9(24/2): 7668, *note A.18.9(68/2): 7701.
+ in Ada.Containers.Vectors *note A.18.2(50/2): 7285, *note
+A.18.2(51/2): 7286.
+ in Ada.Direct_IO *note A.8.4(8): 6815.
+ in Ada.Sequential_IO *note A.8.1(8): 6787.
+ in Ada.Streams.Stream_IO *note A.12.1(10): 7074.
+ in Ada.Strings.Bounded *note A.4.4(64): 6346, *note A.4.4(65):
+6347.
+ in Ada.Strings.Fixed *note A.4.3(29): 6287, *note A.4.3(30): 6288.
+ in Ada.Strings.Unbounded *note A.4.5(59): 6403, *note A.4.5(60):
+6404.
+ in Ada.Text_IO *note A.10.1(11): 6872.
+
+Delete_Children
+ in Ada.Containers.Multiway_Trees *note A.18.10(53/3): 7778.
+
+Delete_Directory in Ada.Directories *note A.16(8/2): 7141.
+
+Delete_File in Ada.Directories *note A.16(11/2): 7144.
+
+Delete_First
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(25/2): 7363.
+ in Ada.Containers.Ordered_Maps *note A.18.6(26/2): 7515.
+ in Ada.Containers.Ordered_Sets *note A.18.9(25/2): 7669.
+ in Ada.Containers.Vectors *note A.18.2(52/2): 7287.
+
+Delete_Last
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(26/2): 7364.
+ in Ada.Containers.Ordered_Maps *note A.18.6(27/2): 7516.
+ in Ada.Containers.Ordered_Sets *note A.18.9(26/2): 7670.
+ in Ada.Containers.Vectors *note A.18.2(53/2): 7288.
+
+Delete_Leaf
+ in Ada.Containers.Multiway_Trees *note A.18.10(35/3): 7760.
+
+Delete_Subtree
+ in Ada.Containers.Multiway_Trees *note A.18.10(36/3): 7761.
+
+Delete_Tree in Ada.Directories *note A.16(10/2): 7143.
+
+Depth
+ in Ada.Containers.Multiway_Trees *note A.18.10(19/3): 7744.
+
+Dequeue
+ in Ada.Containers.Bounded_Priority_Queues *note A.18.31(5/3): 7919.
+ in Ada.Containers.Bounded_Synchronized_Queues *note A.18.29(5/3):
+7904.
+ in Ada.Containers.Synchronized_Queue_Interfaces *note A.18.27(6/3):
+7889.
+ in Ada.Containers.Unbounded_Priority_Queues *note A.18.30(5/3):
+7911.
+ in Ada.Containers.Unbounded_Synchronized_Queues *note A.18.28(5/3):
+7897.
+
+Dequeue_Only_High_Priority
+ in Ada.Containers.Bounded_Priority_Queues *note A.18.31(6/3): 7920.
+ in Ada.Containers.Unbounded_Priority_Queues *note A.18.30(6/3):
+7912.
+
+Dereference_Error
+ in Interfaces.C.Strings *note B.3.1(12): 8061.
+
+Descendant_Tag in Ada.Tags *note 3.9(7.1/2): 2237.
+
+Detach_Handler in Ada.Interrupts *note C.3.2(9): 8232.
+
+Determinant
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(46/2): 9037.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(24/2): 8996.
+
+Difference
+ in Ada.Calendar.Arithmetic *note 9.6.1(12/2): 4492.
+ in Ada.Containers.Hashed_Sets *note A.18.8(32/2): 7599, *note
+A.18.8(33/2): 7600.
+ in Ada.Containers.Ordered_Sets *note A.18.9(33/2): 7675, *note
+A.18.9(34/2): 7676.
+
+Divide in Ada.Decimal *note F.2(6/3): 8835.
+
+Do_APC in System.RPC *note E.5(10): 8815.
+
+Do_RPC in System.RPC *note E.5(9): 8814.
+
+Eigensystem
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(49/2): 9039.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(27/2): 8998.
+
+Eigenvalues
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(48/2): 9038.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(26/2): 8997.
+
+Element
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(14/2): 7347.
+ in Ada.Containers.Hashed_Maps *note A.18.5(14/2): 7441, *note
+A.18.5(31/2): 7465.
+ in Ada.Containers.Hashed_Sets *note A.18.8(15/2): 7581, *note
+A.18.8(52/2): 7616.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(12/3): 7830.
+ in Ada.Containers.Multiway_Trees *note A.18.10(24/3): 7749.
+ in Ada.Containers.Ordered_Maps *note A.18.6(13/2): 7495, *note
+A.18.6(39/2): 7528.
+ in Ada.Containers.Ordered_Sets *note A.18.9(14/2): 7655, *note
+A.18.9(65/2): 7698.
+ in Ada.Containers.Vectors *note A.18.2(27/2): 7255, *note
+A.18.2(28/2): 7256.
+ in Ada.Strings.Bounded *note A.4.4(26): 6318.
+ in Ada.Strings.Unbounded *note A.4.5(20): 6375.
+
+Encode
+ in Ada.Strings.UTF_Encoding.Strings *note A.4.11(23/3): 6554, *note
+A.4.11(24/3): 6555, *note A.4.11(25/3): 6556.
+ in Ada.Strings.UTF_Encoding.Wide_Strings *note A.4.11(31/3): 6561,
+*note A.4.11(32/3): 6562, *note A.4.11(33/3): 6563.
+ in Ada.Strings.UTF_Encoding.Wide_Wide_Strings *note A.4.11(39/3):
+6568, *note A.4.11(40/3): 6569, *note A.4.11(41/3): 6570.
+
+Encoding in Ada.Strings.UTF_Encoding *note A.4.11(13/3): 6546.
+
+End_Of_File
+ in Ada.Direct_IO *note A.8.4(16): 6829.
+ in Ada.Sequential_IO *note A.8.1(13): 6796.
+ in Ada.Streams.Stream_IO *note A.12.1(12): 7081.
+ in Ada.Text_IO *note A.10.1(34): 6917.
+
+End_Of_Line in Ada.Text_IO *note A.10.1(30): 6910.
+
+End_Of_Page in Ada.Text_IO *note A.10.1(33): 6915.
+
+End_Search in Ada.Directories *note A.16(33/2): 7165.
+
+Enqueue
+ in Ada.Containers.Bounded_Priority_Queues *note A.18.31(5/3): 7918.
+ in Ada.Containers.Bounded_Synchronized_Queues *note A.18.29(5/3):
+7903.
+ in Ada.Containers.Synchronized_Queue_Interfaces *note A.18.27(5/3):
+7888.
+ in Ada.Containers.Unbounded_Priority_Queues *note A.18.30(5/3):
+7910.
+ in Ada.Containers.Unbounded_Synchronized_Queues *note A.18.28(5/3):
+7896.
+
+Environment_Task
+ in Ada.Task_Identification *note C.7.1(3/3): 8277.
+
+Equal_Case_Insensitive
+ child of Ada.Strings *note A.4.10(2/3): 6527.
+ child of Ada.Strings.Bounded *note A.4.10(7/3): 6529.
+ child of Ada.Strings.Fixed *note A.4.10(5/3): 6528.
+ child of Ada.Strings.Unbounded *note A.4.10(10/3): 6530.
+
+Equal_Subtree
+ in Ada.Containers.Multiway_Trees *note A.18.10(14/3): 7740.
+
+Equivalent_Elements
+ in Ada.Containers.Hashed_Sets *note A.18.8(46/2): 7610, *note
+A.18.8(47/2): 7611, *note A.18.8(48/2): 7612.
+ in Ada.Containers.Ordered_Sets *note A.18.9(3/2): 7643.
+
+Equivalent_Keys
+ in Ada.Containers.Hashed_Maps *note A.18.5(34/2): 7467, *note
+A.18.5(35/2): 7468, *note A.18.5(36/2): 7469.
+ in Ada.Containers.Ordered_Maps *note A.18.6(3/2): 7484.
+ in Ada.Containers.Ordered_Sets *note A.18.9(63/2): 7696.
+
+Equivalent_Sets
+ in Ada.Containers.Hashed_Sets *note A.18.8(8/2): 7574.
+ in Ada.Containers.Ordered_Sets *note A.18.9(9/2): 7650.
+
+Establish_RPC_Receiver in System.RPC *note E.5(12): 8817.
+
+Exception_Identity in Ada.Exceptions *note 11.4.1(5/2): 4939.
+
+Exception_Information
+ in Ada.Exceptions *note 11.4.1(5/2): 4943.
+
+Exception_Message in Ada.Exceptions *note 11.4.1(4/3): 4937.
+
+Exception_Name in Ada.Exceptions *note 11.4.1(2/2): 4930, *note
+11.4.1(5/2): 4940.
+
+Exchange_Handler in Ada.Interrupts *note C.3.2(8): 8231.
+
+Exclude
+ in Ada.Containers.Hashed_Maps *note A.18.5(24/2): 7458.
+ in Ada.Containers.Hashed_Sets *note A.18.8(23/2): 7592, *note
+A.18.8(54/2): 7618.
+ in Ada.Containers.Ordered_Maps *note A.18.6(23/2): 7512.
+ in Ada.Containers.Ordered_Sets *note A.18.9(22/2): 7666, *note
+A.18.9(67/2): 7700.
+
+Exists
+ in Ada.Directories *note A.16(24/2): 7157.
+ in Ada.Environment_Variables *note A.17(5/2): 7208.
+
+Exp
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(3): 8898.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(4): 6589.
+
+Expanded_Name in Ada.Tags *note 3.9(7/2): 2232.
+
+Extension in Ada.Directories *note A.16(18/2): 7150.
+
+External_Tag in Ada.Tags *note 3.9(7/2): 2235.
+
+Finalize in Ada.Finalization *note 7.6(6/2): 3931, *note 7.6(8/2):
+3934.
+
+Find
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(41/2): 7379.
+ in Ada.Containers.Hashed_Maps *note A.18.5(30/2): 7464.
+ in Ada.Containers.Hashed_Sets *note A.18.8(43/2): 7608, *note
+A.18.8(56/2): 7620.
+ in Ada.Containers.Multiway_Trees *note A.18.10(38/3): 7763.
+ in Ada.Containers.Ordered_Maps *note A.18.6(38/2): 7527.
+ in Ada.Containers.Ordered_Sets *note A.18.9(49/2): 7689, *note
+A.18.9(69/2): 7702.
+ in Ada.Containers.Vectors *note A.18.2(68/2): 7303.
+
+Find_In_Subtree
+ in Ada.Containers.Multiway_Trees *note A.18.10(39/3): 7764.
+
+Find_Index in Ada.Containers.Vectors *note A.18.2(67/2): 7302.
+
+Find_Token
+ in Ada.Strings.Bounded *note A.4.4(50.1/3): 6334, *note A.4.4(51):
+6335.
+ in Ada.Strings.Fixed *note A.4.3(15.1/3): 6275, *note A.4.3(16):
+6276.
+ in Ada.Strings.Unbounded *note A.4.5(45.1/3): 6391, *note
+A.4.5(46): 6392.
+
+First
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(33/2): 7371.
+ in Ada.Containers.Hashed_Maps *note A.18.5(27/2): 7461.
+ in Ada.Containers.Hashed_Sets *note A.18.8(40/2): 7605.
+ in Ada.Containers.Ordered_Maps *note A.18.6(28/2): 7517.
+ in Ada.Containers.Ordered_Sets *note A.18.9(41/2): 7681.
+ in Ada.Containers.Vectors *note A.18.2(58/2): 7293.
+ in Ada.Iterator_Interfaces *note 5.5.1(3/3): 3441.
+
+First_Child
+ in Ada.Containers.Multiway_Trees *note A.18.10(60/3): 7785.
+
+First_Child_Element
+ in Ada.Containers.Multiway_Trees *note A.18.10(61/3): 7786.
+
+First_Element
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(34/2): 7372.
+ in Ada.Containers.Ordered_Maps *note A.18.6(29/2): 7518.
+ in Ada.Containers.Ordered_Sets *note A.18.9(42/2): 7682.
+ in Ada.Containers.Vectors *note A.18.2(59/2): 7294.
+
+First_Index in Ada.Containers.Vectors *note A.18.2(57/2): 7292.
+
+First_Key
+ in Ada.Containers.Ordered_Maps *note A.18.6(30/2): 7519.
+
+Floor
+ in Ada.Containers.Ordered_Maps *note A.18.6(40/2): 7529.
+ in Ada.Containers.Ordered_Sets *note A.18.9(50/2): 7690, *note
+A.18.9(70/2): 7703.
+
+Flush
+ in Ada.Streams.Stream_IO *note A.12.1(25/1): 7091.
+ in Ada.Text_IO *note A.10.1(21/1): 6896.
+
+Form
+ in Ada.Direct_IO *note A.8.4(9): 6820.
+ in Ada.Sequential_IO *note A.8.1(9): 6792.
+ in Ada.Streams.Stream_IO *note A.12.1(11): 7079.
+ in Ada.Text_IO *note A.10.1(12): 6877.
+
+Free
+ in Ada.Strings.Unbounded *note A.4.5(7): 6367.
+ in Interfaces.C.Strings *note B.3.1(11): 8060.
+
+Full_Name in Ada.Directories *note A.16(15/2): 7147, *note A.16(39/2):
+7169.
+
+Generic_Array_Sort
+ child of Ada.Containers *note A.18.26(3/2): 7878.
+
+Generic_Constrained_Array_Sort
+ child of Ada.Containers *note A.18.26(7/2): 7880.
+
+Generic_Sort
+ child of Ada.Containers *note A.18.26(9.2/3): 7882.
+
+Get
+ in Ada.Text_IO *note A.10.1(41): 6929, *note A.10.1(47): 6939,
+*note A.10.1(54): 6953, *note A.10.1(55): 6956, *note A.10.1(59): 6961,
+*note A.10.1(60): 6965, *note A.10.1(65): 6972, *note A.10.1(67): 6975,
+*note A.10.1(70): 6981, *note A.10.1(72): 6985, *note A.10.1(75): 6992,
+*note A.10.1(77): 6995, *note A.10.1(81): 7001, *note A.10.1(83): 7004.
+ in Ada.Text_IO.Complex_IO *note G.1.3(6): 8927, *note G.1.3(8):
+8931.
+
+Get_CPU
+ in Ada.Interrupts *note C.3.2(10.1/3): 8234.
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(13/3):
+8681.
+
+Get_Deadline in Ada.Dispatching.EDF *note D.2.6(9/2): 8400.
+
+Get_Dispatching_Domain
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(10/3):
+8678.
+
+Get_First_CPU
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(8/3):
+8676.
+
+Get_Immediate in Ada.Text_IO *note A.10.1(44): 6936, *note A.10.1(45):
+6937.
+
+Get_Last_CPU
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(9/3):
+8677.
+
+Get_Line
+ in Ada.Text_IO *note A.10.1(49): 6944, *note A.10.1(49.1/2): 6946.
+ in Ada.Text_IO.Bounded_IO *note A.10.11(8/2): 7035, *note
+A.10.11(9/2): 7036, *note A.10.11(10/2): 7037, *note A.10.11(11/2):
+7038.
+ in Ada.Text_IO.Unbounded_IO *note A.10.12(8/2): 7045, *note
+A.10.12(9/2): 7046, *note A.10.12(10/2): 7047, *note A.10.12(11/2):
+7048.
+
+Get_Next_Entry in Ada.Directories *note A.16(35/2): 7167.
+
+Get_Priority
+ in Ada.Dynamic_Priorities *note D.5.1(5): 8445.
+
+Has_Element
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(9.1/3): 7342.
+ in Ada.Containers.Hashed_Maps *note A.18.5(6.1/3): 7433.
+ in Ada.Containers.Hashed_Sets *note A.18.8(6.1/3): 7572.
+ in Ada.Containers.Multiway_Trees *note A.18.10(12/3): 7738.
+ in Ada.Containers.Ordered_Maps *note A.18.6(7.1/3): 7489.
+ in Ada.Containers.Ordered_Sets *note A.18.9(7.1/3): 7648.
+ in Ada.Containers.Vectors *note A.18.2(11.1/3): 7243.
+
+Hash
+ child of Ada.Strings *note A.4.9(2/3): 6518.
+ child of Ada.Strings.Bounded *note A.4.9(7/3): 6519.
+ child of Ada.Strings.Unbounded *note A.4.9(10/3): 6520.
+
+Hash_Case_Insensitive
+ child of Ada.Strings *note A.4.9(11.2/3): 6521.
+ child of Ada.Strings.Bounded *note A.4.9(11.7/3): 6523.
+ child of Ada.Strings.Fixed *note A.4.9(11.5/3): 6522.
+ child of Ada.Strings.Unbounded *note A.4.9(11.10/3): 6524.
+
+Head
+ in Ada.Strings.Bounded *note A.4.4(70): 6352, *note A.4.4(71):
+6353.
+ in Ada.Strings.Fixed *note A.4.3(35): 6293, *note A.4.3(36): 6294.
+ in Ada.Strings.Unbounded *note A.4.5(65): 6409, *note A.4.5(66):
+6410.
+
+Hold in Ada.Asynchronous_Task_Control *note D.11(3/2): 8573.
+
+Hour in Ada.Calendar.Formatting *note 9.6.1(24/2): 4510.
+
+Im
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(7/2): 9009,
+*note G.3.2(27/2): 9022.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(6): 8872.
+
+Image
+ in Ada.Calendar.Formatting *note 9.6.1(35/2): 4521, *note
+9.6.1(37/2): 4523.
+ in Ada.Numerics.Discrete_Random *note A.5.2(26): 6644.
+ in Ada.Numerics.Float_Random *note A.5.2(14): 6632.
+ in Ada.Task_Identification *note C.7.1(3/3): 8275.
+ in Ada.Text_IO.Editing *note F.3.3(13): 8855.
+
+Include
+ in Ada.Containers.Hashed_Maps *note A.18.5(22/2): 7456.
+ in Ada.Containers.Hashed_Sets *note A.18.8(21/2): 7590.
+ in Ada.Containers.Ordered_Maps *note A.18.6(21/2): 7510.
+ in Ada.Containers.Ordered_Sets *note A.18.9(20/2): 7664.
+
+Increment in Interfaces.C.Pointers *note B.3.2(11/3): 8081.
+
+Index
+ in Ada.Direct_IO *note A.8.4(15): 6827.
+ in Ada.Streams.Stream_IO *note A.12.1(23): 7088.
+ in Ada.Strings.Bounded *note A.4.4(43.1/2): 6323, *note
+A.4.4(43.2/2): 6324, *note A.4.4(44): 6325, *note A.4.4(45): 6326, *note
+A.4.4(45.1/2): 6327, *note A.4.4(46): 6328.
+ in Ada.Strings.Fixed *note A.4.3(8.1/2): 6264, *note A.4.3(8.2/2):
+6265, *note A.4.3(9): 6266, *note A.4.3(10): 6267, *note A.4.3(10.1/2):
+6268, *note A.4.3(11): 6269.
+ in Ada.Strings.Unbounded *note A.4.5(38.1/2): 6380, *note
+A.4.5(38.2/2): 6381, *note A.4.5(39): 6382, *note A.4.5(40): 6383, *note
+A.4.5(40.1/2): 6384, *note A.4.5(41): 6385.
+
+Index_Non_Blank
+ in Ada.Strings.Bounded *note A.4.4(46.1/2): 6329, *note A.4.4(47):
+6330.
+ in Ada.Strings.Fixed *note A.4.3(11.1/2): 6270, *note A.4.3(12):
+6271.
+ in Ada.Strings.Unbounded *note A.4.5(41.1/2): 6386, *note
+A.4.5(42): 6387.
+
+Initial_Directory
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(12/3):
+7200.
+
+Initialize in Ada.Finalization *note 7.6(6/2): 3929, *note 7.6(8/2):
+3933.
+
+Insert
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(19/2): 7357,
+*note A.18.3(20/2): 7358, *note A.18.3(21/2): 7359.
+ in Ada.Containers.Hashed_Maps *note A.18.5(19/2): 7453, *note
+A.18.5(20/2): 7454, *note A.18.5(21/2): 7455.
+ in Ada.Containers.Hashed_Sets *note A.18.8(19/2): 7588, *note
+A.18.8(20/2): 7589.
+ in Ada.Containers.Ordered_Maps *note A.18.6(18/2): 7507, *note
+A.18.6(19/2): 7508, *note A.18.6(20/2): 7509.
+ in Ada.Containers.Ordered_Sets *note A.18.9(18/2): 7662, *note
+A.18.9(19/2): 7663.
+ in Ada.Containers.Vectors *note A.18.2(36/2): 7271, *note
+A.18.2(37/2): 7272, *note A.18.2(38/2): 7273, *note A.18.2(39/2): 7274,
+*note A.18.2(40/2): 7275, *note A.18.2(41/2): 7276, *note A.18.2(42/2):
+7277, *note A.18.2(43/2): 7278.
+ in Ada.Strings.Bounded *note A.4.4(60): 6342, *note A.4.4(61):
+6343.
+ in Ada.Strings.Fixed *note A.4.3(25): 6283, *note A.4.3(26): 6284.
+ in Ada.Strings.Unbounded *note A.4.5(55): 6399, *note A.4.5(56):
+6400.
+
+Insert_Child
+ in Ada.Containers.Multiway_Trees *note A.18.10(48/3): 7773, *note
+A.18.10(49/3): 7774, *note A.18.10(50/3): 7775.
+
+Insert_Space
+ in Ada.Containers.Vectors *note A.18.2(48/2): 7283, *note
+A.18.2(49/2): 7284.
+
+Interface_Ancestor_Tags in Ada.Tags *note 3.9(7.4/2): 2241.
+
+Internal_Tag in Ada.Tags *note 3.9(7/2): 2236.
+
+Intersection
+ in Ada.Containers.Hashed_Sets *note A.18.8(29/2): 7597, *note
+A.18.8(30/2): 7598.
+ in Ada.Containers.Ordered_Sets *note A.18.9(30/2): 7673, *note
+A.18.9(31/2): 7674.
+
+Inverse
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(46/2): 9036.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(24/2): 8995.
+
+Is_A_Group_Member
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(8/2): 8627.
+
+Is_Abstract in Ada.Tags *note 3.9(7.5/3): 2242.
+
+Is_Alphanumeric
+ in Ada.Characters.Handling *note A.3.2(4/3): 5917.
+ in Ada.Wide_Characters.Handling *note A.3.5(12/3): 6207.
+
+Is_Attached in Ada.Interrupts *note C.3.2(5): 8228.
+
+Is_Basic in Ada.Characters.Handling *note A.3.2(4/3): 5913.
+
+Is_Callable
+ in Ada.Task_Identification *note C.7.1(4/3): 8280.
+
+Is_Character
+ in Ada.Characters.Conversions *note A.3.4(3/2): 6181.
+
+Is_Control
+ in Ada.Characters.Handling *note A.3.2(4/3): 5908.
+ in Ada.Wide_Characters.Handling *note A.3.5(5/3): 6200.
+
+Is_Current_Directory_Name
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(7/3): 7195.
+
+Is_Decimal_Digit
+ in Ada.Characters.Handling *note A.3.2(4/3): 5915.
+ in Ada.Wide_Characters.Handling *note A.3.5(10/3): 6205.
+
+Is_Descendant_At_Same_Level
+ in Ada.Tags *note 3.9(7.1/2): 2238.
+
+Is_Digit
+ in Ada.Characters.Handling *note A.3.2(4/3): 5914.
+ in Ada.Wide_Characters.Handling *note A.3.5(9/3): 6204.
+
+Is_Empty
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(12/2): 7345.
+ in Ada.Containers.Hashed_Maps *note A.18.5(11/2): 7438.
+ in Ada.Containers.Hashed_Sets *note A.18.8(13/2): 7579.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(10/3): 7828.
+ in Ada.Containers.Multiway_Trees *note A.18.10(16/3): 7741.
+ in Ada.Containers.Ordered_Maps *note A.18.6(10/2): 7492.
+ in Ada.Containers.Ordered_Sets *note A.18.9(12/2): 7653.
+ in Ada.Containers.Vectors *note A.18.2(23/2): 7251.
+
+Is_Full_Name
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(8/3): 7196.
+
+Is_Graphic
+ in Ada.Characters.Handling *note A.3.2(4/3): 5909.
+ in Ada.Wide_Characters.Handling *note A.3.5(19/3): 6214.
+
+Is_Held
+ in Ada.Asynchronous_Task_Control *note D.11(3/2): 8575.
+
+Is_Hexadecimal_Digit
+ in Ada.Characters.Handling *note A.3.2(4/3): 5916.
+ in Ada.Wide_Characters.Handling *note A.3.5(11/3): 6206.
+
+Is_In
+ in Ada.Strings.Maps *note A.4.2(13): 6245.
+ in Ada.Strings.Wide_Maps *note A.4.7(13): 6457.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(13/2): 6499.
+
+Is_ISO_646 in Ada.Characters.Handling *note A.3.2(10): 5932.
+
+Is_Leaf
+ in Ada.Containers.Multiway_Trees *note A.18.10(21/3): 7746.
+
+Is_Letter
+ in Ada.Characters.Handling *note A.3.2(4/3): 5910.
+ in Ada.Wide_Characters.Handling *note A.3.5(6/3): 6201.
+
+Is_Line_Terminator
+ in Ada.Characters.Handling *note A.3.2(4/3): 5919.
+ in Ada.Wide_Characters.Handling *note A.3.5(14/3): 6209.
+
+Is_Lower
+ in Ada.Characters.Handling *note A.3.2(4/3): 5911.
+ in Ada.Wide_Characters.Handling *note A.3.5(7/3): 6202.
+
+Is_Mark
+ in Ada.Characters.Handling *note A.3.2(4/3): 5920.
+ in Ada.Wide_Characters.Handling *note A.3.5(15/3): 6210.
+
+Is_Member
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(8/2): 8626.
+
+Is_Nul_Terminated in Interfaces.C *note B.3(24): 8010, *note B.3(35):
+8020, *note B.3(39.16/2): 8040, *note B.3(39.7/2): 8030.
+
+Is_Open
+ in Ada.Direct_IO *note A.8.4(10): 6821.
+ in Ada.Sequential_IO *note A.8.1(10): 6793.
+ in Ada.Streams.Stream_IO *note A.12.1(12): 7080.
+ in Ada.Text_IO *note A.10.1(13): 6878.
+
+Is_Other_Format
+ in Ada.Characters.Handling *note A.3.2(4/3): 5921.
+ in Ada.Wide_Characters.Handling *note A.3.5(16/3): 6211.
+
+Is_Parent_Directory_Name
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(6/3): 7194.
+
+Is_Punctuation_Connector
+ in Ada.Characters.Handling *note A.3.2(4/3): 5922.
+ in Ada.Wide_Characters.Handling *note A.3.5(17/3): 6212.
+
+Is_Relative_Name
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(9/3): 7197.
+
+Is_Reserved in Ada.Interrupts *note C.3.2(4): 8227.
+
+Is_Root
+ in Ada.Containers.Multiway_Trees *note A.18.10(20/3): 7745.
+
+Is_Root_Directory_Name
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(5/3): 7193.
+
+Is_Round_Robin
+ in Ada.Dispatching.Round_Robin *note D.2.5(4/2): 8391.
+
+Is_Simple_Name
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(4/3): 7192.
+
+Is_Sorted
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(48/2): 7385.
+ in Ada.Containers.Vectors *note A.18.2(76/2): 7310.
+
+Is_Space
+ in Ada.Characters.Handling *note A.3.2(4/3): 5923.
+ in Ada.Wide_Characters.Handling *note A.3.5(18/3): 6213.
+
+Is_Special
+ in Ada.Characters.Handling *note A.3.2(4/3): 5918.
+ in Ada.Wide_Characters.Handling *note A.3.5(13/3): 6208.
+
+Is_String
+ in Ada.Characters.Conversions *note A.3.4(3/2): 6182.
+
+Is_Subset
+ in Ada.Containers.Hashed_Sets *note A.18.8(39/2): 7604.
+ in Ada.Containers.Ordered_Sets *note A.18.9(40/2): 7680.
+ in Ada.Strings.Maps *note A.4.2(14): 6246.
+ in Ada.Strings.Wide_Maps *note A.4.7(14): 6458.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(14/2): 6500.
+
+Is_Terminated
+ in Ada.Task_Identification *note C.7.1(4/3): 8279.
+
+Is_Upper
+ in Ada.Characters.Handling *note A.3.2(4/3): 5912.
+ in Ada.Wide_Characters.Handling *note A.3.5(8/3): 6203.
+
+Is_Wide_Character
+ in Ada.Characters.Conversions *note A.3.4(3/2): 6183.
+
+Is_Wide_String
+ in Ada.Characters.Conversions *note A.3.4(3/2): 6184.
+
+Iterate
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(45/2): 7382.
+ in Ada.Containers.Hashed_Maps *note A.18.5(37/2): 7470.
+ in Ada.Containers.Hashed_Sets *note A.18.8(49/2): 7613.
+ in Ada.Containers.Multiway_Trees *note A.18.10(42/3): 7767, *note
+A.18.10(44/3): 7769.
+ in Ada.Containers.Ordered_Maps *note A.18.6(50/2): 7532.
+ in Ada.Containers.Ordered_Sets *note A.18.9(60/2): 7693.
+ in Ada.Containers.Vectors *note A.18.2(73/2): 7307.
+ in Ada.Environment_Variables *note A.17(8/3): 7212.
+
+Iterate_Children
+ in Ada.Containers.Multiway_Trees *note A.18.10(68/3): 7793, *note
+A.18.10(70/3): 7795.
+
+Iterate_Subtree
+ in Ada.Containers.Multiway_Trees *note A.18.10(43/3): 7768, *note
+A.18.10(45/3): 7770.
+
+Key
+ in Ada.Containers.Hashed_Maps *note A.18.5(13/2): 7440.
+ in Ada.Containers.Hashed_Sets *note A.18.8(51/2): 7615.
+ in Ada.Containers.Ordered_Maps *note A.18.6(12/2): 7494.
+ in Ada.Containers.Ordered_Sets *note A.18.9(64/2): 7697.
+
+Kind in Ada.Directories *note A.16(25/2): 7158, *note A.16(40/2):
+7170.
+
+Language in Ada.Locales *note A.19(6/3): 7930.
+
+Last
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(35/2): 7373.
+ in Ada.Containers.Ordered_Maps *note A.18.6(31/2): 7520.
+ in Ada.Containers.Ordered_Sets *note A.18.9(43/2): 7683.
+ in Ada.Containers.Vectors *note A.18.2(61/2): 7296.
+ in Ada.Iterator_Interfaces *note 5.5.1(4/3): 3444.
+
+Last_Child
+ in Ada.Containers.Multiway_Trees *note A.18.10(62/3): 7787.
+
+Last_Child_Element
+ in Ada.Containers.Multiway_Trees *note A.18.10(63/3): 7788.
+
+Last_Element
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(36/2): 7374.
+ in Ada.Containers.Ordered_Maps *note A.18.6(32/2): 7521.
+ in Ada.Containers.Ordered_Sets *note A.18.9(44/2): 7684.
+ in Ada.Containers.Vectors *note A.18.2(62/2): 7297.
+
+Last_Index in Ada.Containers.Vectors *note A.18.2(60/2): 7295.
+
+Last_Key
+ in Ada.Containers.Ordered_Maps *note A.18.6(33/2): 7522.
+
+Length
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(11/2): 7344.
+ in Ada.Containers.Hashed_Maps *note A.18.5(10/2): 7437.
+ in Ada.Containers.Hashed_Sets *note A.18.8(12/2): 7578.
+ in Ada.Containers.Ordered_Maps *note A.18.6(9/2): 7491.
+ in Ada.Containers.Ordered_Sets *note A.18.9(11/2): 7652.
+ in Ada.Containers.Vectors *note A.18.2(21/2): 7249.
+ in Ada.Strings.Bounded *note A.4.4(9): 6306.
+ in Ada.Strings.Unbounded *note A.4.5(6): 6365.
+ in Ada.Text_IO.Editing *note F.3.3(11): 8853.
+ in Interfaces.COBOL *note B.4(34): 8142, *note B.4(39): 8146, *note
+B.4(44): 8150.
+
+Less_Case_Insensitive
+ child of Ada.Strings *note A.4.10(13/3): 6531.
+ child of Ada.Strings.Bounded *note A.4.10(18/3): 6533.
+ child of Ada.Strings.Fixed *note A.4.10(16/3): 6532.
+ child of Ada.Strings.Unbounded *note A.4.10(21/3): 6534.
+
+Line in Ada.Text_IO *note A.10.1(38): 6926.
+
+Line_Length in Ada.Text_IO *note A.10.1(25): 6902.
+
+Log
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(3): 8896.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(4): 6587.
+
+Look_Ahead in Ada.Text_IO *note A.10.1(43): 6933.
+
+Members
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(8/2): 8628.
+
+Merge
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(50/2): 7387.
+ in Ada.Containers.Vectors *note A.18.2(78/2): 7312.
+
+Microseconds in Ada.Real_Time *note D.8(14/2): 8536.
+
+Milliseconds in Ada.Real_Time *note D.8(14/2): 8537.
+
+Minute in Ada.Calendar.Formatting *note 9.6.1(25/2): 4511.
+
+Minutes in Ada.Real_Time *note D.8(14/2): 8539.
+
+Mode
+ in Ada.Direct_IO *note A.8.4(9): 6818.
+ in Ada.Sequential_IO *note A.8.1(9): 6790.
+ in Ada.Streams.Stream_IO *note A.12.1(11): 7077.
+ in Ada.Text_IO *note A.10.1(12): 6875.
+
+Modification_Time in Ada.Directories *note A.16(27/2): 7160, *note
+A.16(42/2): 7172.
+
+Modulus
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(10/2): 9014,
+*note G.3.2(30/2): 9027.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(9): 8880.
+
+Month
+ in Ada.Calendar *note 9.6(13): 4466.
+ in Ada.Calendar.Formatting *note 9.6.1(22/2): 4508.
+
+More_Entries in Ada.Directories *note A.16(34/2): 7166.
+
+Move
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(18/2): 7356.
+ in Ada.Containers.Hashed_Maps *note A.18.5(18/2): 7452.
+ in Ada.Containers.Hashed_Sets *note A.18.8(18/2): 7587.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(22/3): 7840.
+ in Ada.Containers.Multiway_Trees *note A.18.10(34/3): 7759.
+ in Ada.Containers.Ordered_Maps *note A.18.6(17/2): 7506.
+ in Ada.Containers.Ordered_Sets *note A.18.9(17/2): 7661.
+ in Ada.Containers.Vectors *note A.18.2(35/2): 7270.
+ in Ada.Strings.Fixed *note A.4.3(7): 6263.
+
+Name
+ in Ada.Direct_IO *note A.8.4(9): 6819.
+ in Ada.Sequential_IO *note A.8.1(9): 6791.
+ in Ada.Streams.Stream_IO *note A.12.1(11): 7078.
+ in Ada.Text_IO *note A.10.1(12): 6876.
+
+Name_Case_Equivalence
+ in Ada.Directories *note A.16(20.2/3): 7154.
+
+Nanoseconds in Ada.Real_Time *note D.8(14/2): 8535.
+
+New_Char_Array
+ in Interfaces.C.Strings *note B.3.1(9): 8058.
+
+New_Line in Ada.Text_IO *note A.10.1(28): 6906.
+
+New_Page in Ada.Text_IO *note A.10.1(31): 6911.
+
+New_String in Interfaces.C.Strings *note B.3.1(10): 8059.
+
+Next
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(37/2): 7375,
+*note A.18.3(39/2): 7377.
+ in Ada.Containers.Hashed_Maps *note A.18.5(28/2): 7462, *note
+A.18.5(29/2): 7463.
+ in Ada.Containers.Hashed_Sets *note A.18.8(41/2): 7606, *note
+A.18.8(42/2): 7607.
+ in Ada.Containers.Ordered_Maps *note A.18.6(34/2): 7523, *note
+A.18.6(35/2): 7524.
+ in Ada.Containers.Ordered_Sets *note A.18.9(45/2): 7685, *note
+A.18.9(46/2): 7686.
+ in Ada.Containers.Vectors *note A.18.2(63/2): 7298, *note
+A.18.2(64/2): 7299.
+ in Ada.Iterator_Interfaces *note 5.5.1(3/3): 3442.
+
+Next_Sibling
+ in Ada.Containers.Multiway_Trees *note A.18.10(64/3): 7789, *note
+A.18.10(66/3): 7791.
+
+Node_Count
+ in Ada.Containers.Multiway_Trees *note A.18.10(17/3): 7742.
+
+Null_Task_Id
+ in Ada.Task_Identification *note C.7.1(2/2): 8274.
+
+Number_Of_CPUs
+ in System.Multiprocessors *note D.16(5/3): 8667.
+
+Open
+ in Ada.Direct_IO *note A.8.4(7): 6813.
+ in Ada.Sequential_IO *note A.8.1(7): 6785.
+ in Ada.Streams.Stream_IO *note A.12.1(9): 7072.
+ in Ada.Text_IO *note A.10.1(10): 6870.
+
+Overlap
+ in Ada.Containers.Hashed_Sets *note A.18.8(38/2): 7603.
+ in Ada.Containers.Ordered_Sets *note A.18.9(39/2): 7679.
+
+Overwrite
+ in Ada.Strings.Bounded *note A.4.4(62): 6344, *note A.4.4(63):
+6345.
+ in Ada.Strings.Fixed *note A.4.3(27): 6285, *note A.4.3(28): 6286.
+ in Ada.Strings.Unbounded *note A.4.5(57): 6401, *note A.4.5(58):
+6402.
+
+Page in Ada.Text_IO *note A.10.1(39): 6928.
+
+Page_Length in Ada.Text_IO *note A.10.1(26): 6903.
+
+Parent
+ in Ada.Containers.Multiway_Trees *note A.18.10(59/3): 7784.
+
+Parent_Tag in Ada.Tags *note 3.9(7.2/2): 2239.
+
+Peak_Use
+ in Ada.Containers.Bounded_Priority_Queues *note A.18.31(7/3): 7922.
+ in Ada.Containers.Bounded_Synchronized_Queues *note A.18.29(6/3):
+7906.
+ in Ada.Containers.Synchronized_Queue_Interfaces *note A.18.27(7/3):
+7891.
+ in Ada.Containers.Unbounded_Priority_Queues *note A.18.30(7/3):
+7914.
+ in Ada.Containers.Unbounded_Synchronized_Queues *note A.18.28(6/3):
+7899.
+
+Pic_String in Ada.Text_IO.Editing *note F.3.3(7): 8844.
+
+Pool_of_Subpool
+ in System.Storage_Pools.Subpools *note 13.11.4(9/3): 5699.
+
+Prepend
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(22/2): 7360.
+ in Ada.Containers.Vectors *note A.18.2(44/2): 7279, *note
+A.18.2(45/2): 7280.
+
+Prepend_Child
+ in Ada.Containers.Multiway_Trees *note A.18.10(51/3): 7776.
+
+Previous
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(38/2): 7376,
+*note A.18.3(40/2): 7378.
+ in Ada.Containers.Ordered_Maps *note A.18.6(36/2): 7525, *note
+A.18.6(37/2): 7526.
+ in Ada.Containers.Ordered_Sets *note A.18.9(47/2): 7687, *note
+A.18.9(48/2): 7688.
+ in Ada.Containers.Vectors *note A.18.2(65/2): 7300, *note
+A.18.2(66/2): 7301.
+ in Ada.Iterator_Interfaces *note 5.5.1(4/3): 3445.
+
+Previous_Sibling
+ in Ada.Containers.Multiway_Trees *note A.18.10(65/3): 7790, *note
+A.18.10(67/3): 7792.
+
+Put
+ in Ada.Text_IO *note A.10.1(42): 6931, *note A.10.1(48): 6941,
+*note A.10.1(55): 6957, *note A.10.1(60): 6963, *note A.10.1(66): 6973,
+*note A.10.1(67): 6976, *note A.10.1(71): 6984, *note A.10.1(72): 6986,
+*note A.10.1(76): 6994, *note A.10.1(77): 6996, *note A.10.1(82): 7002,
+*note A.10.1(83): 7005.
+ in Ada.Text_IO.Bounded_IO *note A.10.11(4/2): 7031, *note
+A.10.11(5/2): 7032.
+ in Ada.Text_IO.Complex_IO *note G.1.3(7): 8930, *note G.1.3(8):
+8932.
+ in Ada.Text_IO.Editing *note F.3.3(14): 8856, *note F.3.3(15):
+8857, *note F.3.3(16): 8858.
+ in Ada.Text_IO.Unbounded_IO *note A.10.12(4/2): 7041, *note
+A.10.12(5/2): 7042.
+
+Put_Line
+ in Ada.Text_IO *note A.10.1(50): 6948.
+ in Ada.Text_IO.Bounded_IO *note A.10.11(6/2): 7033, *note
+A.10.11(7/2): 7034.
+ in Ada.Text_IO.Unbounded_IO *note A.10.12(6/2): 7043, *note
+A.10.12(7/2): 7044.
+
+Query_Element
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(16/2): 7349.
+ in Ada.Containers.Hashed_Maps *note A.18.5(16/2): 7443.
+ in Ada.Containers.Hashed_Sets *note A.18.8(17/2): 7583.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(14/3): 7832.
+ in Ada.Containers.Multiway_Trees *note A.18.10(26/3): 7751.
+ in Ada.Containers.Ordered_Maps *note A.18.6(15/2): 7497.
+ in Ada.Containers.Ordered_Sets *note A.18.9(16/2): 7657.
+ in Ada.Containers.Vectors *note A.18.2(31/2): 7259, *note
+A.18.2(32/2): 7260.
+
+Raise_Exception in Ada.Exceptions *note 11.4.1(4/3): 4936.
+
+Random
+ in Ada.Numerics.Discrete_Random *note A.5.2(20): 6637.
+ in Ada.Numerics.Float_Random *note A.5.2(8): 6625.
+
+Re
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(7/2): 9008,
+*note G.3.2(27/2): 9021.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(6): 8871.
+
+Read
+ in Ada.Direct_IO *note A.8.4(12): 6822.
+ in Ada.Sequential_IO *note A.8.1(12): 6794.
+ in Ada.Storage_IO *note A.9(6): 6842.
+ in Ada.Streams *note 13.13.1(5): 5783.
+ in Ada.Streams.Stream_IO *note A.12.1(15): 7083, *note A.12.1(16):
+7084.
+ in System.RPC *note E.5(7): 8812.
+
+Reference
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(17.4/3): 7353.
+ in Ada.Containers.Hashed_Maps *note A.18.5(17.4/3): 7447, *note
+A.18.5(17.6/3): 7449.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(19/3): 7837.
+ in Ada.Containers.Multiway_Trees *note A.18.10(31/3): 7756.
+ in Ada.Containers.Ordered_Maps *note A.18.6(16.4/3): 7501, *note
+A.18.6(16.6/3): 7503.
+ in Ada.Containers.Vectors *note A.18.2(34.4/3): 7265, *note
+A.18.2(34.6/3): 7267.
+ in Ada.Interrupts *note C.3.2(10): 8233.
+ in Ada.Task_Attributes *note C.7.2(5): 8296.
+
+Reference_Preserving_Key
+ in Ada.Containers.Hashed_Sets *note A.18.8(58.2/3): 7624, *note
+A.18.8(58.4/3): 7626.
+ in Ada.Containers.Ordered_Sets *note A.18.9(73.2/3): 7708, *note
+A.18.9(73.4/3): 7710.
+
+Reinitialize in Ada.Task_Attributes *note C.7.2(6): 8298.
+
+Relative_Name
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(13/3):
+7201.
+
+Remove_Task
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(8/2): 8625.
+
+Rename in Ada.Directories *note A.16(12/2): 7145.
+
+Replace
+ in Ada.Containers.Hashed_Maps *note A.18.5(23/2): 7457.
+ in Ada.Containers.Hashed_Sets *note A.18.8(22/2): 7591, *note
+A.18.8(53/2): 7617.
+ in Ada.Containers.Ordered_Maps *note A.18.6(22/2): 7511.
+ in Ada.Containers.Ordered_Sets *note A.18.9(21/2): 7665, *note
+A.18.9(66/2): 7699.
+
+Replace_Element
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(15/2): 7348.
+ in Ada.Containers.Hashed_Maps *note A.18.5(15/2): 7442.
+ in Ada.Containers.Hashed_Sets *note A.18.8(16/2): 7582.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(13/3): 7831.
+ in Ada.Containers.Multiway_Trees *note A.18.10(25/3): 7750.
+ in Ada.Containers.Ordered_Maps *note A.18.6(14/2): 7496.
+ in Ada.Containers.Ordered_Sets *note A.18.9(15/2): 7656.
+ in Ada.Containers.Vectors *note A.18.2(29/2): 7257, *note
+A.18.2(30/2): 7258.
+ in Ada.Strings.Bounded *note A.4.4(27): 6319.
+ in Ada.Strings.Unbounded *note A.4.5(21): 6376.
+
+Replace_Slice
+ in Ada.Strings.Bounded *note A.4.4(58): 6340, *note A.4.4(59):
+6341.
+ in Ada.Strings.Fixed *note A.4.3(23): 6281, *note A.4.3(24): 6282.
+ in Ada.Strings.Unbounded *note A.4.5(53): 6397, *note A.4.5(54):
+6398.
+
+Replenish
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(9/2): 8629.
+
+Replicate in Ada.Strings.Bounded *note A.4.4(78): 6356, *note
+A.4.4(79): 6357, *note A.4.4(80): 6358.
+
+Reraise_Occurrence in Ada.Exceptions *note 11.4.1(4/3): 4938.
+
+Reserve_Capacity
+ in Ada.Containers.Hashed_Maps *note A.18.5(9/2): 7436.
+ in Ada.Containers.Hashed_Sets *note A.18.8(11/2): 7577.
+ in Ada.Containers.Vectors *note A.18.2(20/2): 7248.
+
+Reset
+ in Ada.Direct_IO *note A.8.4(8): 6817.
+ in Ada.Numerics.Discrete_Random *note A.5.2(21): 6639, *note
+A.5.2(24): 6642.
+ in Ada.Numerics.Float_Random *note A.5.2(9): 6627, *note A.5.2(12):
+6630.
+ in Ada.Sequential_IO *note A.8.1(8): 6788.
+ in Ada.Streams.Stream_IO *note A.12.1(10): 7076.
+ in Ada.Text_IO *note A.10.1(11): 6874.
+
+Reverse_Elements
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(27/2): 7365.
+ in Ada.Containers.Vectors *note A.18.2(54/2): 7289.
+
+Reverse_Find
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(42/2): 7380.
+ in Ada.Containers.Vectors *note A.18.2(70/2): 7305.
+
+Reverse_Find_Index
+ in Ada.Containers.Vectors *note A.18.2(69/2): 7304.
+
+Reverse_Iterate
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(46/2): 7383.
+ in Ada.Containers.Ordered_Maps *note A.18.6(51/2): 7533.
+ in Ada.Containers.Ordered_Sets *note A.18.9(61/2): 7694.
+ in Ada.Containers.Vectors *note A.18.2(74/2): 7308.
+
+Reverse_Iterate_Children
+ in Ada.Containers.Multiway_Trees *note A.18.10(69/3): 7794.
+
+Root in Ada.Containers.Multiway_Trees *note A.18.10(22/3): 7747.
+
+Save
+ in Ada.Numerics.Discrete_Random *note A.5.2(24): 6641.
+ in Ada.Numerics.Float_Random *note A.5.2(12): 6629.
+
+Save_Occurrence in Ada.Exceptions *note 11.4.1(6/2): 4944.
+
+Second in Ada.Calendar.Formatting *note 9.6.1(26/2): 4512.
+
+Seconds
+ in Ada.Calendar *note 9.6(13): 4468.
+ in Ada.Real_Time *note D.8(14/2): 8538.
+
+Seconds_Of in Ada.Calendar.Formatting *note 9.6.1(28/2): 4514.
+
+Set in Ada.Environment_Variables *note A.17(6/2): 7209.
+
+Set_Bounded_String
+ in Ada.Strings.Bounded *note A.4.4(12.1/2): 6309.
+
+Set_Col in Ada.Text_IO *note A.10.1(35): 6920.
+
+Set_CPU
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(12/3):
+8680.
+
+Set_Deadline in Ada.Dispatching.EDF *note D.2.6(9/2): 8398.
+
+Set_Dependents_Fallback_Handler
+ in Ada.Task_Termination *note C.7.3(5/2): 8308.
+
+Set_Directory in Ada.Directories *note A.16(6/2): 7139.
+
+Set_Error in Ada.Text_IO *note A.10.1(15): 6881.
+
+Set_Exit_Status in Ada.Command_Line *note A.15(9): 7134.
+
+Set_False
+ in Ada.Synchronous_Task_Control *note D.10(4): 8557.
+
+Set_Handler
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(10/2): 8633.
+ in Ada.Execution_Time.Timers *note D.14.1(7/2): 8607.
+ in Ada.Real_Time.Timing_Events *note D.15(5/2): 8654.
+
+Set_Im
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(8/2): 9011,
+*note G.3.2(28/2): 9024.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(7): 8876.
+
+Set_Index
+ in Ada.Direct_IO *note A.8.4(14): 6826.
+ in Ada.Streams.Stream_IO *note A.12.1(22): 7087.
+
+Set_Input in Ada.Text_IO *note A.10.1(15): 6879.
+
+Set_Length in Ada.Containers.Vectors *note A.18.2(22/2): 7250.
+
+Set_Line in Ada.Text_IO *note A.10.1(36): 6922.
+
+Set_Line_Length in Ada.Text_IO *note A.10.1(23): 6897.
+
+Set_Mode in Ada.Streams.Stream_IO *note A.12.1(24): 7090.
+
+Set_Output in Ada.Text_IO *note A.10.1(15): 6880.
+
+Set_Page_Length in Ada.Text_IO *note A.10.1(24): 6899.
+
+Set_Pool_of_Subpool
+ in System.Storage_Pools.Subpools *note 13.11.4(10/3): 5700.
+
+Set_Priority
+ in Ada.Dynamic_Priorities *note D.5.1(4): 8444.
+
+Set_Quantum
+ in Ada.Dispatching.Round_Robin *note D.2.5(4/2): 8388.
+
+Set_Re
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(8/2): 9010,
+*note G.3.2(28/2): 9023.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(7): 8874.
+
+Set_Specific_Handler
+ in Ada.Task_Termination *note C.7.3(6/2): 8310.
+
+Set_True
+ in Ada.Synchronous_Task_Control *note D.10(4): 8556.
+
+Set_Unbounded_String
+ in Ada.Strings.Unbounded *note A.4.5(11.1/2): 6371.
+
+Set_Value in Ada.Task_Attributes *note C.7.2(6): 8297.
+
+Simple_Name
+ in Ada.Directories *note A.16(16/2): 7148, *note A.16(38/2): 7168.
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(10/3):
+7198.
+
+Sin
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(4): 8899.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(5): 6590.
+
+Sinh
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(6): 8907.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6606.
+
+Size
+ in Ada.Direct_IO *note A.8.4(15): 6828.
+ in Ada.Directories *note A.16(26/2): 7159, *note A.16(41/2): 7171.
+ in Ada.Streams.Stream_IO *note A.12.1(23): 7089.
+
+Skip_Line in Ada.Text_IO *note A.10.1(29): 6908.
+
+Skip_Page in Ada.Text_IO *note A.10.1(32): 6914.
+
+Slice
+ in Ada.Strings.Bounded *note A.4.4(28): 6320.
+ in Ada.Strings.Unbounded *note A.4.5(22): 6377.
+
+Solve
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(46/2): 9035.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(24/2): 8994.
+
+Sort
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(49/2): 7386.
+ in Ada.Containers.Vectors *note A.18.2(77/2): 7311.
+
+Specific_Handler
+ in Ada.Task_Termination *note C.7.3(6/2): 8311.
+
+Splice
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(30/2): 7368,
+*note A.18.3(31/2): 7369, *note A.18.3(32/2): 7370.
+
+Splice_Children
+ in Ada.Containers.Multiway_Trees *note A.18.10(57/3): 7782, *note
+A.18.10(58/3): 7783.
+
+Splice_Subtree
+ in Ada.Containers.Multiway_Trees *note A.18.10(55/3): 7780, *note
+A.18.10(56/3): 7781.
+
+Split
+ in Ada.Calendar *note 9.6(14): 4469.
+ in Ada.Calendar.Formatting *note 9.6.1(29/2): 4515, *note
+9.6.1(32/2): 4518, *note 9.6.1(33/2): 4519, *note 9.6.1(34/2): 4520.
+ in Ada.Execution_Time *note D.14(8/2): 8592.
+ in Ada.Real_Time *note D.8(16): 8541.
+
+Sqrt
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(3): 8895.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(4): 6586.
+
+Standard_Error in Ada.Text_IO *note A.10.1(16): 6884, *note
+A.10.1(19): 6891.
+
+Standard_Input in Ada.Text_IO *note A.10.1(16): 6882, *note
+A.10.1(19): 6889.
+
+Standard_Output in Ada.Text_IO *note A.10.1(16): 6883, *note
+A.10.1(19): 6890.
+
+Start_Search in Ada.Directories *note A.16(32/2): 7164.
+
+Storage_Size
+ in System.Storage_Pools *note 13.11(9): 5626.
+ in System.Storage_Pools.Subpools *note 13.11.4(16/3): 5706.
+
+Stream
+ in Ada.Streams.Stream_IO *note A.12.1(13): 7082.
+ in Ada.Text_IO.Text_Streams *note A.12.2(4): 7106.
+ in Ada.Wide_Text_IO.Text_Streams *note A.12.3(4): 7109.
+ in Ada.Wide_Wide_Text_IO.Text_Streams *note A.12.4(4/2): 7112.
+
+Strlen in Interfaces.C.Strings *note B.3.1(17): 8066.
+
+Sub_Second in Ada.Calendar.Formatting *note 9.6.1(27/2): 4513.
+
+Subtree_Node_Count
+ in Ada.Containers.Multiway_Trees *note A.18.10(18/3): 7743.
+
+Supported
+ in Ada.Execution_Time.Interrupts *note D.14.3(3/3): 8648.
+
+Suspend_Until_True
+ in Ada.Synchronous_Task_Control *note D.10(4): 8559.
+
+Suspend_Until_True_And_Set_Deadline
+ in Ada.Synchronous_Task_Control.EDF *note D.10(5.2/3): 8561.
+
+Swap
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(28/2): 7366.
+ in Ada.Containers.Multiway_Trees *note A.18.10(37/3): 7762.
+ in Ada.Containers.Vectors *note A.18.2(55/2): 7290, *note
+A.18.2(56/2): 7291.
+
+Swap_Links
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(29/2): 7367.
+
+Symmetric_Difference
+ in Ada.Containers.Hashed_Sets *note A.18.8(35/2): 7601, *note
+A.18.8(36/2): 7602.
+ in Ada.Containers.Ordered_Sets *note A.18.9(36/2): 7677, *note
+A.18.9(37/2): 7678.
+
+Tail
+ in Ada.Strings.Bounded *note A.4.4(72): 6354, *note A.4.4(73):
+6355.
+ in Ada.Strings.Fixed *note A.4.3(37): 6295, *note A.4.3(38): 6296.
+ in Ada.Strings.Unbounded *note A.4.5(67): 6411, *note A.4.5(68):
+6412.
+
+Tan
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(4): 8901.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(5): 6594.
+
+Tanh
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(6): 8909.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6608.
+
+Time_Of
+ in Ada.Calendar *note 9.6(15): 4470.
+ in Ada.Calendar.Formatting *note 9.6.1(30/2): 4516, *note
+9.6.1(31/2): 4517.
+ in Ada.Execution_Time *note D.14(9/2): 8593.
+ in Ada.Real_Time *note D.8(16): 8542.
+
+Time_Of_Event
+ in Ada.Real_Time.Timing_Events *note D.15(6/2): 8657.
+
+Time_Remaining
+ in Ada.Execution_Time.Timers *note D.14.1(8/2): 8611.
+
+To_Ada
+ in Interfaces.C *note B.3(22): 8008, *note B.3(26): 8012, *note
+B.3(28): 8014, *note B.3(32): 8018, *note B.3(37): 8022, *note B.3(39):
+8024, *note B.3(39.10/2): 8034, *note B.3(39.13/2): 8038, *note
+B.3(39.17/2): 8042, *note B.3(39.19/2): 8044, *note B.3(39.4/2): 8028,
+*note B.3(39.8/2): 8032.
+ in Interfaces.COBOL *note B.4(17): 8120, *note B.4(19): 8122.
+ in Interfaces.Fortran *note B.5(13): 8173, *note B.5(14): 8175,
+*note B.5(16): 8177.
+
+To_Address
+ in System.Address_To_Access_Conversions *note 13.7.2(3/3): 5574.
+ in System.Storage_Elements *note 13.7.1(10/3): 5566.
+
+To_Basic in Ada.Characters.Handling *note A.3.2(6): 5926, *note
+A.3.2(7): 5929.
+
+To_Binary in Interfaces.COBOL *note B.4(45): 8152, *note B.4(48):
+8155.
+
+To_Bounded_String
+ in Ada.Strings.Bounded *note A.4.4(11): 6307.
+
+To_C in Interfaces.C *note B.3(21): 8007, *note B.3(25): 8011, *note
+B.3(27): 8013, *note B.3(32): 8017, *note B.3(36): 8021, *note B.3(38):
+8023, *note B.3(39.13/2): 8037, *note B.3(39.16/2): 8041, *note
+B.3(39.18/2): 8043, *note B.3(39.4/2): 8027, *note B.3(39.7/2): 8031,
+*note B.3(39.9/2): 8033.
+
+To_Character
+ in Ada.Characters.Conversions *note A.3.4(5/2): 6193.
+
+To_Chars_Ptr in Interfaces.C.Strings *note B.3.1(8): 8057.
+
+To_COBOL in Interfaces.COBOL *note B.4(17): 8119, *note B.4(18): 8121.
+
+To_Cursor in Ada.Containers.Vectors *note A.18.2(25/2): 7253.
+
+To_Decimal in Interfaces.COBOL *note B.4(35): 8143, *note B.4(40):
+8147, *note B.4(44): 8151, *note B.4(47): 8153.
+
+To_Display in Interfaces.COBOL *note B.4(36): 8144.
+
+To_Domain
+ in Ada.Strings.Maps *note A.4.2(24): 6255.
+ in Ada.Strings.Wide_Maps *note A.4.7(24): 6467.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(24/2): 6509.
+
+To_Duration in Ada.Real_Time *note D.8(13): 8533.
+
+To_Fortran in Interfaces.Fortran *note B.5(13): 8172, *note B.5(14):
+8174, *note B.5(15): 8176.
+
+To_Holder
+ in Ada.Containers.Indefinite_Holders *note A.18.18(9/3): 7827.
+
+To_Index in Ada.Containers.Vectors *note A.18.2(26/2): 7254.
+
+To_Integer in System.Storage_Elements *note 13.7.1(10/3): 5567.
+
+To_ISO_646 in Ada.Characters.Handling *note A.3.2(11): 5933, *note
+A.3.2(12): 5934.
+
+To_Long_Binary in Interfaces.COBOL *note B.4(48): 8156.
+
+To_Lower
+ in Ada.Characters.Handling *note A.3.2(6): 5924, *note A.3.2(7):
+5927.
+ in Ada.Wide_Characters.Handling *note A.3.5(20/3): 6215, *note
+A.3.5(21/3): 6217.
+
+To_Mapping
+ in Ada.Strings.Maps *note A.4.2(23): 6254.
+ in Ada.Strings.Wide_Maps *note A.4.7(23): 6466.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(23/2): 6508.
+
+To_Packed in Interfaces.COBOL *note B.4(41): 8148.
+
+To_Picture in Ada.Text_IO.Editing *note F.3.3(6): 8843.
+
+To_Pointer
+ in System.Address_To_Access_Conversions *note 13.7.2(3/3): 5573.
+
+To_Range
+ in Ada.Strings.Maps *note A.4.2(24): 6256.
+ in Ada.Strings.Wide_Maps *note A.4.7(25): 6468.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(25/2): 6510.
+
+To_Ranges
+ in Ada.Strings.Maps *note A.4.2(10): 6244.
+ in Ada.Strings.Wide_Maps *note A.4.7(10): 6456.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(10/2): 6498.
+
+To_Sequence
+ in Ada.Strings.Maps *note A.4.2(19): 6250.
+ in Ada.Strings.Wide_Maps *note A.4.7(19): 6462.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(19/2): 6504.
+
+To_Set
+ in Ada.Containers.Hashed_Sets *note A.18.8(9/2): 7575.
+ in Ada.Containers.Ordered_Sets *note A.18.9(10/2): 7651.
+ in Ada.Strings.Maps *note A.4.2(8): 6242, *note A.4.2(9): 6243,
+*note A.4.2(17): 6248, *note A.4.2(18): 6249.
+ in Ada.Strings.Wide_Maps *note A.4.7(8): 6454, *note A.4.7(9):
+6455, *note A.4.7(17): 6460, *note A.4.7(18): 6461.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(8/2): 6496, *note
+A.4.8(9/2): 6497, *note A.4.8(17/2): 6502, *note A.4.8(18/2): 6503.
+
+To_String
+ in Ada.Characters.Conversions *note A.3.4(5/2): 6192.
+ in Ada.Strings.Bounded *note A.4.4(12): 6308.
+ in Ada.Strings.Unbounded *note A.4.5(11): 6370.
+
+To_Time_Span in Ada.Real_Time *note D.8(13): 8534.
+
+To_Unbounded_String
+ in Ada.Strings.Unbounded *note A.4.5(9): 6368, *note A.4.5(10):
+6369.
+
+To_Upper
+ in Ada.Characters.Handling *note A.3.2(6): 5925, *note A.3.2(7):
+5928.
+ in Ada.Wide_Characters.Handling *note A.3.5(20/3): 6216, *note
+A.3.5(21/3): 6218.
+
+To_Vector in Ada.Containers.Vectors *note A.18.2(13/2): 7245, *note
+A.18.2(14/2): 7246.
+
+To_Wide_Character
+ in Ada.Characters.Conversions *note A.3.4(4/2): 6185, *note
+A.3.4(5/2): 6195.
+
+To_Wide_String
+ in Ada.Characters.Conversions *note A.3.4(4/2): 6186, *note
+A.3.4(5/2): 6196.
+
+To_Wide_Wide_Character
+ in Ada.Characters.Conversions *note A.3.4(4/2): 6189.
+
+To_Wide_Wide_String
+ in Ada.Characters.Conversions *note A.3.4(4/2): 6190.
+
+Translate
+ in Ada.Strings.Bounded *note A.4.4(53): 6336, *note A.4.4(54):
+6337, *note A.4.4(55): 6338, *note A.4.4(56): 6339.
+ in Ada.Strings.Fixed *note A.4.3(18): 6277, *note A.4.3(19): 6278,
+*note A.4.3(20): 6279, *note A.4.3(21): 6280.
+ in Ada.Strings.Unbounded *note A.4.5(48): 6393, *note A.4.5(49):
+6394, *note A.4.5(50): 6395, *note A.4.5(51): 6396.
+
+Transpose
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(34/2): 9033.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(17/2): 8992.
+
+Trim
+ in Ada.Strings.Bounded *note A.4.4(67): 6348, *note A.4.4(68):
+6350, *note A.4.4(69): 6351.
+ in Ada.Strings.Fixed *note A.4.3(31): 6289, *note A.4.3(32): 6290,
+*note A.4.3(33): 6291, *note A.4.3(34): 6292.
+ in Ada.Strings.Unbounded *note A.4.5(61): 6405, *note A.4.5(62):
+6406, *note A.4.5(63): 6407, *note A.4.5(64): 6408.
+
+Unbounded_Slice
+ in Ada.Strings.Unbounded *note A.4.5(22.1/2): 6378, *note
+A.4.5(22.2/2): 6379.
+
+Unchecked_Conversion
+ child of Ada *note 13.9(3/3): 5590.
+
+Unchecked_Deallocation
+ child of Ada *note 13.11.2(3/3): 5669.
+
+Union
+ in Ada.Containers.Hashed_Sets *note A.18.8(26/2): 7595, *note
+A.18.8(27/2): 7596.
+ in Ada.Containers.Ordered_Sets *note A.18.9(27/2): 7671, *note
+A.18.9(28/2): 7672.
+
+Unit_Matrix
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(51/2): 9040.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(29/2): 8999.
+
+Unit_Vector
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(24/2): 9020.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(14/2): 8991.
+
+Update in Interfaces.C.Strings *note B.3.1(18): 8067, *note B.3.1(19):
+8068.
+
+Update_Element
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(17/2): 7350.
+ in Ada.Containers.Hashed_Maps *note A.18.5(17/2): 7444.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(15/3): 7833.
+ in Ada.Containers.Multiway_Trees *note A.18.10(27/3): 7752.
+ in Ada.Containers.Ordered_Maps *note A.18.6(16/2): 7498.
+ in Ada.Containers.Vectors *note A.18.2(33/2): 7261, *note
+A.18.2(34/2): 7262.
+
+Update_Element_Preserving_Key
+ in Ada.Containers.Hashed_Sets *note A.18.8(58/2): 7622.
+ in Ada.Containers.Ordered_Sets *note A.18.9(73/2): 7706.
+
+Update_Error in Interfaces.C.Strings *note B.3.1(20): 8069.
+
+UTC_Time_Offset
+ in Ada.Calendar.Time_Zones *note 9.6.1(6/2): 4488.
+
+Valid
+ in Ada.Text_IO.Editing *note F.3.3(5): 8842, *note F.3.3(12): 8854.
+ in Interfaces.COBOL *note B.4(33): 8141, *note B.4(38): 8145, *note
+B.4(43): 8149.
+
+Value
+ in Ada.Calendar.Formatting *note 9.6.1(36/2): 4522, *note
+9.6.1(38/2): 4524.
+ in Ada.Environment_Variables *note A.17(4.1/3): 7207, *note
+A.17(4/2): 7206.
+ in Ada.Numerics.Discrete_Random *note A.5.2(26): 6645.
+ in Ada.Numerics.Float_Random *note A.5.2(14): 6633.
+ in Ada.Strings.Maps *note A.4.2(21): 6252.
+ in Ada.Strings.Wide_Maps *note A.4.7(21): 6464.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(21/2): 6506.
+ in Ada.Task_Attributes *note C.7.2(4): 8295.
+ in Interfaces.C.Pointers *note B.3.2(6): 8078, *note B.3.2(7):
+8079.
+ in Interfaces.C.Strings *note B.3.1(13): 8062, *note B.3.1(14):
+8063, *note B.3.1(15): 8064, *note B.3.1(16): 8065.
+
+Virtual_Length
+ in Interfaces.C.Pointers *note B.3.2(13): 8083.
+
+Wait_For_Release
+ in Ada.Synchronous_Barriers *note D.10.1(6/3): 8570.
+
+Wide_Equal_Case_Insensitive
+ child of Ada.Strings.Wide_Bounded *note A.4.7(1/3): 6442.
+ child of Ada.Strings.Wide_Fixed *note A.4.7(1/3): 6441.
+ child of Ada.Strings.Wide_Unbounded *note A.4.7(1/3): 6443.
+
+Wide_Hash
+ child of Ada.Strings.Wide_Bounded *note A.4.7(1/3): 6438.
+ child of Ada.Strings.Wide_Fixed *note A.4.7(1/3): 6437.
+ child of Ada.Strings.Wide_Unbounded *note A.4.7(1/3): 6439.
+
+Wide_Hash_Case_Insensitive
+ child of Ada.Strings.Wide_Bounded *note A.4.7(1/3): 6446.
+ child of Ada.Strings.Wide_Fixed *note A.4.7(1/3): 6445.
+ child of Ada.Strings.Wide_Unbounded *note A.4.7(1/3): 6447.
+
+Wide_Exception_Name in Ada.Exceptions *note 11.4.1(2/2): 4931, *note
+11.4.1(5/2): 4941.
+
+Wide_Expanded_Name in Ada.Tags *note 3.9(7/2): 2233.
+
+Wide_Wide_Equal_Case_Insensitive
+ child of Ada.Strings.Wide_Wide_Bounded *note A.4.8(1/3): 6484.
+ child of Ada.Strings.Wide_Wide_Fixed *note A.4.8(1/3): 6483.
+ child of Ada.Strings.Wide_Wide_Unbounded *note A.4.8(1/3): 6485.
+
+Wide_Wide_Hash
+ child of Ada.Strings.Wide_Wide_Bounded *note A.4.8(1/3): 6480.
+ child of Ada.Strings.Wide_Wide_Fixed *note A.4.8(1/3): 6479.
+ child of Ada.Strings.Wide_Wide_Unbounded *note A.4.8(1/3): 6481.
+
+Wide_Wide_Hash_Case_Insensitive
+ child of Ada.Strings.Wide_Wide_Bounded *note A.4.8(1/3): 6488.
+ child of Ada.Strings.Wide_Wide_Fixed *note A.4.8(1/3): 6487.
+ child of Ada.Strings.Wide_Wide_Unbounded *note A.4.8(1/3): 6489.
+
+Wide_Wide_Exception_Name
+ in Ada.Exceptions *note 11.4.1(2/2): 4932, *note 11.4.1(5/2): 4942.
+
+Wide_Wide_Expanded_Name in Ada.Tags *note 3.9(7/2): 2234.
+
+Write
+ in Ada.Direct_IO *note A.8.4(13): 6824.
+ in Ada.Sequential_IO *note A.8.1(12): 6795.
+ in Ada.Storage_IO *note A.9(7): 6843.
+ in Ada.Streams *note 13.13.1(6): 5784.
+ in Ada.Streams.Stream_IO *note A.12.1(18): 7085, *note A.12.1(19):
+7086.
+ in System.RPC *note E.5(8): 8813.
+
+Year
+ in Ada.Calendar *note 9.6(13): 4465.
+ in Ada.Calendar.Formatting *note 9.6.1(21/2): 4507.
+
+Yield in Ada.Dispatching *note D.2.1(1.3/3): 8339.
+
+Yield_To_Higher
+ in Ada.Dispatching.Non_Preemptive *note D.2.4(2.2/3): 8378.
+
+Yield_To_Same_Or_Higher
+ in Ada.Dispatching.Non_Preemptive *note D.2.4(2.2/3): 8379.
+
+\1f
+File: aarm2012.info, Node: Q.4, Next: Q.5, Prev: Q.3, Up: Annex Q
+
+Q.4 Language-Defined Exceptions
+===============================
+
+1/3
+{AI95-00440-01AI95-00440-01} {AI05-0299-1AI05-0299-1} This subclause
+lists all language-defined exceptions.
+
+
+
+Argument_Error
+ in Ada.Numerics *note A.5(3/2): 6580.
+
+Assertion_Error
+ in Ada.Assertions *note 11.4.2(13/2): 4972.
+
+Capacity_Error
+ in Ada.Containers *note A.18.1(5.1/3): 7228.
+
+Communication_Error
+ in System.RPC *note E.5(5): 8810.
+
+Constraint_Error
+ in Standard *note A.1(46): 5893.
+
+Conversion_Error
+ in Interfaces.COBOL *note B.4(30): 8139.
+
+Data_Error
+ in Ada.Direct_IO *note A.8.4(18): 6836.
+ in Ada.IO_Exceptions *note A.13(4): 7121.
+ in Ada.Sequential_IO *note A.8.1(15): 6803.
+ in Ada.Storage_IO *note A.9(9): 6844.
+ in Ada.Streams.Stream_IO *note A.12.1(26): 7098.
+ in Ada.Text_IO *note A.10.1(85): 7012.
+
+Device_Error
+ in Ada.Direct_IO *note A.8.4(18): 6834.
+ in Ada.Directories *note A.16(43/2): 7176.
+ in Ada.IO_Exceptions *note A.13(4): 7119.
+ in Ada.Sequential_IO *note A.8.1(15): 6801.
+ in Ada.Streams.Stream_IO *note A.12.1(26): 7096.
+ in Ada.Text_IO *note A.10.1(85): 7010.
+
+Dispatching_Domain_Error
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(4/3):
+8672.
+
+Dispatching_Policy_Error
+ in Ada.Dispatching *note D.2.1(1.4/3): 8340.
+
+Encoding_Error
+ in Ada.Strings.UTF_Encoding *note A.4.11(8/3): 6541.
+
+End_Error
+ in Ada.Direct_IO *note A.8.4(18): 6835.
+ in Ada.IO_Exceptions *note A.13(4): 7120.
+ in Ada.Sequential_IO *note A.8.1(15): 6802.
+ in Ada.Streams.Stream_IO *note A.12.1(26): 7097.
+ in Ada.Text_IO *note A.10.1(85): 7011.
+
+Group_Budget_Error
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(11/2): 8636.
+
+Index_Error
+ in Ada.Strings *note A.4.1(5): 6229.
+
+Layout_Error
+ in Ada.IO_Exceptions *note A.13(4): 7122.
+ in Ada.Text_IO *note A.10.1(85): 7013.
+
+Length_Error
+ in Ada.Strings *note A.4.1(5): 6227.
+
+Mode_Error
+ in Ada.Direct_IO *note A.8.4(18): 6831.
+ in Ada.IO_Exceptions *note A.13(4): 7116.
+ in Ada.Sequential_IO *note A.8.1(15): 6798.
+ in Ada.Streams.Stream_IO *note A.12.1(26): 7093.
+ in Ada.Text_IO *note A.10.1(85): 7007.
+
+Name_Error
+ in Ada.Direct_IO *note A.8.4(18): 6832.
+ in Ada.Directories *note A.16(43/2): 7174.
+ in Ada.IO_Exceptions *note A.13(4): 7117.
+ in Ada.Sequential_IO *note A.8.1(15): 6799.
+ in Ada.Streams.Stream_IO *note A.12.1(26): 7094.
+ in Ada.Text_IO *note A.10.1(85): 7008.
+
+Pattern_Error
+ in Ada.Strings *note A.4.1(5): 6228.
+
+Picture_Error
+ in Ada.Text_IO.Editing *note F.3.3(9): 8847.
+
+Pointer_Error
+ in Interfaces.C.Pointers *note B.3.2(8): 8080.
+
+Program_Error
+ in Standard *note A.1(46): 5894.
+
+Status_Error
+ in Ada.Direct_IO *note A.8.4(18): 6830.
+ in Ada.Directories *note A.16(43/2): 7173.
+ in Ada.IO_Exceptions *note A.13(4): 7115.
+ in Ada.Sequential_IO *note A.8.1(15): 6797.
+ in Ada.Streams.Stream_IO *note A.12.1(26): 7092.
+ in Ada.Text_IO *note A.10.1(85): 7006.
+
+Storage_Error
+ in Standard *note A.1(46): 5895.
+
+Tag_Error
+ in Ada.Tags *note 3.9(8): 2243.
+
+Tasking_Error
+ in Standard *note A.1(46): 5896.
+
+Terminator_Error
+ in Interfaces.C *note B.3(40): 8045.
+
+Time_Error
+ in Ada.Calendar *note 9.6(18): 4471.
+
+Timer_Resource_Error
+ in Ada.Execution_Time.Timers *note D.14.1(9/2): 8612.
+
+Translation_Error
+ in Ada.Strings *note A.4.1(5): 6230.
+
+Unknown_Zone_Error
+ in Ada.Calendar.Time_Zones *note 9.6.1(5/2): 4487.
+
+Use_Error
+ in Ada.Direct_IO *note A.8.4(18): 6833.
+ in Ada.Directories *note A.16(43/2): 7175.
+ in Ada.IO_Exceptions *note A.13(4): 7118.
+ in Ada.Sequential_IO *note A.8.1(15): 6800.
+ in Ada.Streams.Stream_IO *note A.12.1(26): 7095.
+ in Ada.Text_IO *note A.10.1(85): 7009.
+
+\1f
+File: aarm2012.info, Node: Q.5, Prev: Q.4, Up: Annex Q
+
+Q.5 Language-Defined Objects
+============================
+
+1/3
+{AI95-00440-01AI95-00440-01} {AI05-0299-1AI05-0299-1} This subclause
+lists all language-defined constants, variables, named numbers, and
+enumeration literals.
+
+1.a/2
+ To be honest: Formally, named numbers and enumeration literals
+ aren't objects, but it was thought to be too weird to say
+ "Language-Defined Objects and Values".
+
+
+
+ACK in Ada.Characters.Latin_1 *note A.3.3(5): 5955.
+
+Acute in Ada.Characters.Latin_1 *note A.3.3(22): 6101.
+
+Ada_To_COBOL in Interfaces.COBOL *note B.4(14): 8116.
+
+Alphanumeric_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6426.
+
+Ampersand in Ada.Characters.Latin_1 *note A.3.3(8): 5987.
+
+APC in Ada.Characters.Latin_1 *note A.3.3(19): 6078.
+
+Apostrophe in Ada.Characters.Latin_1 *note A.3.3(8): 5988.
+
+Asterisk in Ada.Characters.Latin_1 *note A.3.3(8): 5991.
+
+Basic_Map
+ in Ada.Strings.Maps.Constants *note A.4.6(5): 6431.
+
+Basic_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6423.
+
+BEL in Ada.Characters.Latin_1 *note A.3.3(5): 5956.
+
+BOM_16 in Ada.Strings.UTF_Encoding *note A.4.11(12/3): 6545.
+
+BOM_16BE in Ada.Strings.UTF_Encoding *note A.4.11(10/3): 6543.
+
+BOM_16LE in Ada.Strings.UTF_Encoding *note A.4.11(11/3): 6544.
+
+BOM_8 in Ada.Strings.UTF_Encoding *note A.4.11(9/3): 6542.
+
+BPH in Ada.Characters.Latin_1 *note A.3.3(17): 6049.
+
+Broken_Bar in Ada.Characters.Latin_1 *note A.3.3(21/3): 6086.
+
+BS in Ada.Characters.Latin_1 *note A.3.3(5): 5957.
+
+Buffer_Size in Ada.Storage_IO *note A.9(4): 6840.
+
+CAN in Ada.Characters.Latin_1 *note A.3.3(6): 5973.
+
+CCH in Ada.Characters.Latin_1 *note A.3.3(18): 6067.
+
+Cedilla in Ada.Characters.Latin_1 *note A.3.3(22): 6106.
+
+Cent_Sign in Ada.Characters.Latin_1 *note A.3.3(21/3): 6082.
+
+char16_nul in Interfaces.C *note B.3(39.3/2): 8026.
+
+char32_nul in Interfaces.C *note B.3(39.12/2): 8036.
+
+CHAR_BIT in Interfaces.C *note B.3(6): 7987.
+
+Character_Set
+ in Ada.Strings.Wide_Maps *note A.4.7(46/2): 6470.
+ in Ada.Strings.Wide_Maps.Wide_Constants *note A.4.8(48/2): 6513.
+
+Circumflex in Ada.Characters.Latin_1 *note A.3.3(12): 6008.
+
+COBOL_To_Ada in Interfaces.COBOL *note B.4(15): 8117.
+
+Colon in Ada.Characters.Latin_1 *note A.3.3(10): 5998.
+
+Comma in Ada.Characters.Latin_1 *note A.3.3(8): 5993.
+
+Commercial_At
+ in Ada.Characters.Latin_1 *note A.3.3(10): 6004.
+
+Control_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6418.
+
+Copyright_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6089.
+
+Country_Unknown in Ada.Locales *note A.19(5/3): 7929.
+
+CPU_Tick in Ada.Execution_Time *note D.14(4/2): 8590.
+
+CPU_Time_First in Ada.Execution_Time *note D.14(4/2): 8587.
+
+CPU_Time_Last in Ada.Execution_Time *note D.14(4/2): 8588.
+
+CPU_Time_Unit in Ada.Execution_Time *note D.14(4/2): 8589.
+
+CR in Ada.Characters.Latin_1 *note A.3.3(5): 5962.
+
+CSI in Ada.Characters.Latin_1 *note A.3.3(19): 6074.
+
+Currency_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6084.
+
+DC1 in Ada.Characters.Latin_1 *note A.3.3(6): 5966.
+
+DC2 in Ada.Characters.Latin_1 *note A.3.3(6): 5967.
+
+DC3 in Ada.Characters.Latin_1 *note A.3.3(6): 5968.
+
+DC4 in Ada.Characters.Latin_1 *note A.3.3(6): 5969.
+
+DCS in Ada.Characters.Latin_1 *note A.3.3(18): 6063.
+
+Decimal_Digit_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6424.
+
+Default_Aft
+ in Ada.Text_IO *note A.10.1(64): 6969, *note A.10.1(69): 6979,
+*note A.10.1(74): 6989.
+ in Ada.Text_IO.Complex_IO *note G.1.3(5): 8925.
+
+Default_Base in Ada.Text_IO *note A.10.1(53): 6951, *note A.10.1(58):
+6960.
+
+Default_Bit_Order in System *note 13.7(15/2): 5551.
+
+Default_Currency
+ in Ada.Text_IO.Editing *note F.3.3(10): 8848.
+
+Default_Deadline
+ in Ada.Dispatching.EDF *note D.2.6(9/2): 8397.
+
+Default_Exp
+ in Ada.Text_IO *note A.10.1(64): 6970, *note A.10.1(69): 6980,
+*note A.10.1(74): 6990.
+ in Ada.Text_IO.Complex_IO *note G.1.3(5): 8926.
+
+Default_Fill in Ada.Text_IO.Editing *note F.3.3(10): 8849.
+
+Default_Fore
+ in Ada.Text_IO *note A.10.1(64): 6968, *note A.10.1(69): 6978,
+*note A.10.1(74): 6988.
+ in Ada.Text_IO.Complex_IO *note G.1.3(5): 8924.
+
+Default_Priority in System *note 13.7(17): 5555.
+
+Default_Quantum
+ in Ada.Dispatching.Round_Robin *note D.2.5(4/2): 8387.
+
+Default_Radix_Mark
+ in Ada.Text_IO.Editing *note F.3.3(10): 8851.
+
+Default_Separator
+ in Ada.Text_IO.Editing *note F.3.3(10): 8850.
+
+Default_Setting in Ada.Text_IO *note A.10.1(80): 6999.
+
+Default_Width in Ada.Text_IO *note A.10.1(53): 6950, *note A.10.1(58):
+6959, *note A.10.1(80): 6998.
+
+Degree_Sign in Ada.Characters.Latin_1 *note A.3.3(22): 6096.
+
+DEL in Ada.Characters.Latin_1 *note A.3.3(14): 6041.
+
+Diaeresis in Ada.Characters.Latin_1 *note A.3.3(21/3): 6088.
+
+Division_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6169.
+
+DLE in Ada.Characters.Latin_1 *note A.3.3(6): 5965.
+
+Dollar_Sign in Ada.Characters.Latin_1 *note A.3.3(8): 5985.
+
+e in Ada.Numerics *note A.5(3/2): 6582.
+
+EM in Ada.Characters.Latin_1 *note A.3.3(6): 5974.
+
+Empty_Holder
+ in Ada.Containers.Indefinite_Holders *note A.18.18(7/3): 7826.
+
+Empty_List
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(8/2): 7340.
+
+Empty_Map
+ in Ada.Containers.Hashed_Maps *note A.18.5(5/2): 7431.
+ in Ada.Containers.Ordered_Maps *note A.18.6(6/2): 7487.
+
+Empty_Set
+ in Ada.Containers.Hashed_Sets *note A.18.8(5/2): 7570.
+ in Ada.Containers.Ordered_Sets *note A.18.9(6/2): 7646.
+
+Empty_Tree
+ in Ada.Containers.Multiway_Trees *note A.18.10(10/3): 7736.
+
+Empty_Vector
+ in Ada.Containers.Vectors *note A.18.2(10/2): 7241.
+
+ENQ in Ada.Characters.Latin_1 *note A.3.3(5): 5954.
+
+EOT in Ada.Characters.Latin_1 *note A.3.3(5): 5953.
+
+EPA in Ada.Characters.Latin_1 *note A.3.3(18): 6070.
+
+Equals_Sign in Ada.Characters.Latin_1 *note A.3.3(10): 6001.
+
+ESA in Ada.Characters.Latin_1 *note A.3.3(17): 6054.
+
+ESC in Ada.Characters.Latin_1 *note A.3.3(6): 5976.
+
+ETB in Ada.Characters.Latin_1 *note A.3.3(6): 5972.
+
+ETX in Ada.Characters.Latin_1 *note A.3.3(5): 5952.
+
+Exclamation in Ada.Characters.Latin_1 *note A.3.3(8): 5982.
+
+Failure in Ada.Command_Line *note A.15(8): 7133.
+
+Feminine_Ordinal_Indicator
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6090.
+
+FF in Ada.Characters.Latin_1 *note A.3.3(5): 5961.
+
+Fine_Delta in System *note 13.7(9): 5540.
+
+Fraction_One_Half
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6111.
+
+Fraction_One_Quarter
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6110.
+
+Fraction_Three_Quarters
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6112.
+
+Friday in Ada.Calendar.Formatting *note 9.6.1(17/2): 4499.
+
+FS in Ada.Characters.Latin_1 *note A.3.3(6): 5977.
+
+Full_Stop in Ada.Characters.Latin_1 *note A.3.3(8): 5996.
+
+Graphic_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6419.
+
+Grave in Ada.Characters.Latin_1 *note A.3.3(13): 6010.
+
+Greater_Than_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(10): 6002.
+
+GS in Ada.Characters.Latin_1 *note A.3.3(6): 5978.
+
+Hexadecimal_Digit_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6425.
+
+High_Order_First
+ in Interfaces.COBOL *note B.4(25): 8131.
+ in System *note 13.7(15/2): 5549.
+
+HT in Ada.Characters.Latin_1 *note A.3.3(5): 5958.
+
+HTJ in Ada.Characters.Latin_1 *note A.3.3(17): 6056.
+
+HTS in Ada.Characters.Latin_1 *note A.3.3(17): 6055.
+
+Hyphen in Ada.Characters.Latin_1 *note A.3.3(8): 5994.
+
+i
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(5): 8869.
+ in Interfaces.Fortran *note B.5(10): 8168.
+
+Identity
+ in Ada.Strings.Maps *note A.4.2(22): 6253.
+ in Ada.Strings.Wide_Maps *note A.4.7(22): 6465.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(22/2): 6507.
+
+Interrupt_Clocks_Supported
+ in Ada.Execution_Time *note D.14(9.1/3): 8594.
+
+Inverted_Exclamation
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6081.
+
+Inverted_Question
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6113.
+
+IS1 in Ada.Characters.Latin_1 *note A.3.3(16): 6046.
+
+IS2 in Ada.Characters.Latin_1 *note A.3.3(16): 6045.
+
+IS3 in Ada.Characters.Latin_1 *note A.3.3(16): 6044.
+
+IS4 in Ada.Characters.Latin_1 *note A.3.3(16): 6043.
+
+ISO_646_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6428.
+
+j
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(5): 8870.
+ in Interfaces.Fortran *note B.5(10): 8169.
+
+Language_Unknown in Ada.Locales *note A.19(5/3): 7928.
+
+LC_A in Ada.Characters.Latin_1 *note A.3.3(13): 6011.
+
+LC_A_Acute in Ada.Characters.Latin_1 *note A.3.3(25): 6147.
+
+LC_A_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6148.
+
+LC_A_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6150.
+
+LC_A_Grave in Ada.Characters.Latin_1 *note A.3.3(25): 6146.
+
+LC_A_Ring in Ada.Characters.Latin_1 *note A.3.3(25): 6151.
+
+LC_A_Tilde in Ada.Characters.Latin_1 *note A.3.3(25): 6149.
+
+LC_AE_Diphthong
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6152.
+
+LC_B in Ada.Characters.Latin_1 *note A.3.3(13): 6012.
+
+LC_C in Ada.Characters.Latin_1 *note A.3.3(13): 6013.
+
+LC_C_Cedilla
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6153.
+
+LC_D in Ada.Characters.Latin_1 *note A.3.3(13): 6014.
+
+LC_E in Ada.Characters.Latin_1 *note A.3.3(13): 6015.
+
+LC_E_Acute in Ada.Characters.Latin_1 *note A.3.3(25): 6155.
+
+LC_E_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6156.
+
+LC_E_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6157.
+
+LC_E_Grave in Ada.Characters.Latin_1 *note A.3.3(25): 6154.
+
+LC_F in Ada.Characters.Latin_1 *note A.3.3(13): 6016.
+
+LC_G in Ada.Characters.Latin_1 *note A.3.3(13): 6017.
+
+LC_German_Sharp_S
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6145.
+
+LC_H in Ada.Characters.Latin_1 *note A.3.3(13): 6018.
+
+LC_I in Ada.Characters.Latin_1 *note A.3.3(13): 6019.
+
+LC_I_Acute in Ada.Characters.Latin_1 *note A.3.3(25): 6159.
+
+LC_I_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6160.
+
+LC_I_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6161.
+
+LC_I_Grave in Ada.Characters.Latin_1 *note A.3.3(25): 6158.
+
+LC_Icelandic_Eth
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6162.
+
+LC_Icelandic_Thorn
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6176.
+
+LC_J in Ada.Characters.Latin_1 *note A.3.3(13): 6020.
+
+LC_K in Ada.Characters.Latin_1 *note A.3.3(13): 6021.
+
+LC_L in Ada.Characters.Latin_1 *note A.3.3(13): 6022.
+
+LC_M in Ada.Characters.Latin_1 *note A.3.3(13): 6023.
+
+LC_N in Ada.Characters.Latin_1 *note A.3.3(13): 6024.
+
+LC_N_Tilde in Ada.Characters.Latin_1 *note A.3.3(26): 6163.
+
+LC_O in Ada.Characters.Latin_1 *note A.3.3(13): 6025.
+
+LC_O_Acute in Ada.Characters.Latin_1 *note A.3.3(26): 6165.
+
+LC_O_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6166.
+
+LC_O_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6168.
+
+LC_O_Grave in Ada.Characters.Latin_1 *note A.3.3(26): 6164.
+
+LC_O_Oblique_Stroke
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6170.
+
+LC_O_Tilde in Ada.Characters.Latin_1 *note A.3.3(26): 6167.
+
+LC_P in Ada.Characters.Latin_1 *note A.3.3(14): 6026.
+
+LC_Q in Ada.Characters.Latin_1 *note A.3.3(14): 6027.
+
+LC_R in Ada.Characters.Latin_1 *note A.3.3(14): 6028.
+
+LC_S in Ada.Characters.Latin_1 *note A.3.3(14): 6029.
+
+LC_T in Ada.Characters.Latin_1 *note A.3.3(14): 6030.
+
+LC_U in Ada.Characters.Latin_1 *note A.3.3(14): 6031.
+
+LC_U_Acute in Ada.Characters.Latin_1 *note A.3.3(26): 6172.
+
+LC_U_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6173.
+
+LC_U_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6174.
+
+LC_U_Grave in Ada.Characters.Latin_1 *note A.3.3(26): 6171.
+
+LC_V in Ada.Characters.Latin_1 *note A.3.3(14): 6032.
+
+LC_W in Ada.Characters.Latin_1 *note A.3.3(14): 6033.
+
+LC_X in Ada.Characters.Latin_1 *note A.3.3(14): 6034.
+
+LC_Y in Ada.Characters.Latin_1 *note A.3.3(14): 6035.
+
+LC_Y_Acute in Ada.Characters.Latin_1 *note A.3.3(26): 6175.
+
+LC_Y_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6177.
+
+LC_Z in Ada.Characters.Latin_1 *note A.3.3(14): 6036.
+
+Leading_Nonseparate
+ in Interfaces.COBOL *note B.4(23): 8128.
+
+Leading_Separate in Interfaces.COBOL *note B.4(23): 8126.
+
+Left_Angle_Quotation
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6091.
+
+Left_Curly_Bracket
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6037.
+
+Left_Parenthesis
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5989.
+
+Left_Square_Bracket
+ in Ada.Characters.Latin_1 *note A.3.3(12): 6005.
+
+Less_Than_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(10): 6000.
+
+Letter_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6420.
+
+LF in Ada.Characters.Latin_1 *note A.3.3(5): 5959.
+
+Low_Line in Ada.Characters.Latin_1 *note A.3.3(12): 6009.
+
+Low_Order_First
+ in Interfaces.COBOL *note B.4(25): 8132.
+ in System *note 13.7(15/2): 5550.
+
+Lower_Case_Map
+ in Ada.Strings.Maps.Constants *note A.4.6(5): 6429.
+
+Lower_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6421.
+
+Macron in Ada.Characters.Latin_1 *note A.3.3(21/3): 6095.
+
+Masculine_Ordinal_Indicator
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6108.
+
+Max_Base_Digits in System *note 13.7(8): 5537.
+
+Max_Binary_Modulus in System *note 13.7(7): 5535.
+
+Max_Decimal_Digits in Ada.Decimal *note F.2(5): 8834.
+
+Max_Delta in Ada.Decimal *note F.2(4): 8833.
+
+Max_Digits in System *note 13.7(8): 5538.
+
+Max_Digits_Binary in Interfaces.COBOL *note B.4(11): 8111.
+
+Max_Digits_Long_Binary
+ in Interfaces.COBOL *note B.4(11): 8112.
+
+Max_Image_Width
+ in Ada.Numerics.Discrete_Random *note A.5.2(25): 6643.
+ in Ada.Numerics.Float_Random *note A.5.2(13): 6631.
+
+Max_Int in System *note 13.7(6): 5534.
+
+Max_Length in Ada.Strings.Bounded *note A.4.4(5): 6302.
+
+Max_Mantissa in System *note 13.7(9): 5539.
+
+Max_Nonbinary_Modulus in System *note 13.7(7): 5536.
+
+Max_Picture_Length
+ in Ada.Text_IO.Editing *note F.3.3(8): 8846.
+
+Max_Scale in Ada.Decimal *note F.2(3): 8830.
+
+Memory_Size in System *note 13.7(13): 5546.
+
+Micro_Sign in Ada.Characters.Latin_1 *note A.3.3(22): 6102.
+
+Middle_Dot in Ada.Characters.Latin_1 *note A.3.3(22): 6105.
+
+Min_Delta in Ada.Decimal *note F.2(4): 8832.
+
+Min_Handler_Ceiling
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(7/2): 8623.
+ in Ada.Execution_Time.Timers *note D.14.1(6/2): 8606.
+
+Min_Int in System *note 13.7(6): 5533.
+
+Min_Scale in Ada.Decimal *note F.2(3): 8831.
+
+Minus_Sign in Ada.Characters.Latin_1 *note A.3.3(8): 5995.
+
+Monday in Ada.Calendar.Formatting *note 9.6.1(17/2): 4495.
+
+Multiplication_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6137.
+
+MW in Ada.Characters.Latin_1 *note A.3.3(18): 6068.
+
+NAK in Ada.Characters.Latin_1 *note A.3.3(6): 5970.
+
+Native_Binary in Interfaces.COBOL *note B.4(25): 8133.
+
+NBH in Ada.Characters.Latin_1 *note A.3.3(17): 6050.
+
+NBSP in Ada.Characters.Latin_1 *note A.3.3(21/3): 6080.
+
+NEL in Ada.Characters.Latin_1 *note A.3.3(17): 6052.
+
+No_Break_Space
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6079.
+
+No_Element
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(9/2): 7341.
+ in Ada.Containers.Hashed_Maps *note A.18.5(6/2): 7432.
+ in Ada.Containers.Hashed_Sets *note A.18.8(6/2): 7571.
+ in Ada.Containers.Multiway_Trees *note A.18.10(11/3): 7737.
+ in Ada.Containers.Ordered_Maps *note A.18.6(7/2): 7488.
+ in Ada.Containers.Ordered_Sets *note A.18.9(7/2): 7647.
+ in Ada.Containers.Vectors *note A.18.2(11/2): 7242.
+
+No_Index in Ada.Containers.Vectors *note A.18.2(7/2): 7238.
+
+No_Tag in Ada.Tags *note 3.9(6.1/2): 2231.
+
+Not_A_Specific_CPU
+ in System.Multiprocessors *note D.16(4/3): 8665.
+
+Not_Sign in Ada.Characters.Latin_1 *note A.3.3(21/3): 6092.
+
+NUL
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5949.
+ in Interfaces.C *note B.3(20/1): 8006.
+
+Null_Address in System *note 13.7(12): 5543.
+
+Null_Bounded_String
+ in Ada.Strings.Bounded *note A.4.4(7): 6304.
+
+Null_Id in Ada.Exceptions *note 11.4.1(2/2): 4929.
+
+Null_Occurrence in Ada.Exceptions *note 11.4.1(3/2): 4935.
+
+Null_Ptr in Interfaces.C.Strings *note B.3.1(7): 8056.
+
+Null_Set
+ in Ada.Strings.Maps *note A.4.2(5): 6239.
+ in Ada.Strings.Wide_Maps *note A.4.7(5): 6451.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(5/2): 6493.
+
+Null_Unbounded_String
+ in Ada.Strings.Unbounded *note A.4.5(5): 6364.
+
+Number_Sign in Ada.Characters.Latin_1 *note A.3.3(8): 5984.
+
+OSC in Ada.Characters.Latin_1 *note A.3.3(19): 6076.
+
+Packed_Signed in Interfaces.COBOL *note B.4(27): 8136.
+
+Packed_Unsigned in Interfaces.COBOL *note B.4(27): 8135.
+
+Paragraph_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6104.
+
+Percent_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5986.
+
+Pi in Ada.Numerics *note A.5(3/2): 6581.
+
+Pilcrow_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6103.
+
+PLD in Ada.Characters.Latin_1 *note A.3.3(17): 6058.
+
+PLU in Ada.Characters.Latin_1 *note A.3.3(17): 6059.
+
+Plus_Minus_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6098.
+
+Plus_Sign in Ada.Characters.Latin_1 *note A.3.3(8): 5992.
+
+PM in Ada.Characters.Latin_1 *note A.3.3(19): 6077.
+
+Pound_Sign in Ada.Characters.Latin_1 *note A.3.3(21/3): 6083.
+
+PU1 in Ada.Characters.Latin_1 *note A.3.3(18): 6064.
+
+PU2 in Ada.Characters.Latin_1 *note A.3.3(18): 6065.
+
+Question in Ada.Characters.Latin_1 *note A.3.3(10): 6003.
+
+Quotation in Ada.Characters.Latin_1 *note A.3.3(8): 5983.
+
+Registered_Trade_Mark_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6094.
+
+Reserved_128
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6047.
+
+Reserved_129
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6048.
+
+Reserved_132
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6051.
+
+Reserved_153
+ in Ada.Characters.Latin_1 *note A.3.3(19): 6072.
+
+Reverse_Solidus
+ in Ada.Characters.Latin_1 *note A.3.3(12): 6006.
+
+RI in Ada.Characters.Latin_1 *note A.3.3(17): 6060.
+
+Right_Angle_Quotation
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6109.
+
+Right_Curly_Bracket
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6039.
+
+Right_Parenthesis
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5990.
+
+Right_Square_Bracket
+ in Ada.Characters.Latin_1 *note A.3.3(12): 6007.
+
+Ring_Above in Ada.Characters.Latin_1 *note A.3.3(22): 6097.
+
+RS in Ada.Characters.Latin_1 *note A.3.3(6): 5979.
+
+Saturday in Ada.Calendar.Formatting *note 9.6.1(17/2): 4500.
+
+SCHAR_MAX in Interfaces.C *note B.3(6): 7989.
+
+SCHAR_MIN in Interfaces.C *note B.3(6): 7988.
+
+SCI in Ada.Characters.Latin_1 *note A.3.3(19): 6073.
+
+Section_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6087.
+
+Semicolon in Ada.Characters.Latin_1 *note A.3.3(10): 5999.
+
+Separate_Interrupt_Clocks_Supported
+ in Ada.Execution_Time *note D.14(9.2/3): 8595.
+
+SI in Ada.Characters.Latin_1 *note A.3.3(5): 5964.
+
+SO in Ada.Characters.Latin_1 *note A.3.3(5): 5963.
+
+Soft_Hyphen in Ada.Characters.Latin_1 *note A.3.3(21/3): 6093.
+
+SOH in Ada.Characters.Latin_1 *note A.3.3(5): 5950.
+
+Solidus in Ada.Characters.Latin_1 *note A.3.3(8): 5997.
+
+SOS in Ada.Characters.Latin_1 *note A.3.3(19): 6071.
+
+SPA in Ada.Characters.Latin_1 *note A.3.3(18): 6069.
+
+Space
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5981.
+ in Ada.Strings *note A.4.1(4/2): 6224.
+
+Special_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6427.
+
+SS2 in Ada.Characters.Latin_1 *note A.3.3(17): 6061.
+
+SS3 in Ada.Characters.Latin_1 *note A.3.3(17): 6062.
+
+SSA in Ada.Characters.Latin_1 *note A.3.3(17): 6053.
+
+ST in Ada.Characters.Latin_1 *note A.3.3(19): 6075.
+
+Storage_Unit in System *note 13.7(13): 5544.
+
+STS in Ada.Characters.Latin_1 *note A.3.3(18): 6066.
+
+STX in Ada.Characters.Latin_1 *note A.3.3(5): 5951.
+
+SUB in Ada.Characters.Latin_1 *note A.3.3(6): 5975.
+
+Success in Ada.Command_Line *note A.15(8): 7132.
+
+Sunday in Ada.Calendar.Formatting *note 9.6.1(17/2): 4501.
+
+Superscript_One
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6107.
+
+Superscript_Three
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6100.
+
+Superscript_Two
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6099.
+
+SYN in Ada.Characters.Latin_1 *note A.3.3(6): 5971.
+
+System_Dispatching_Domain
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(6/3):
+8674.
+
+System_Name in System *note 13.7(4): 5532.
+
+Thursday in Ada.Calendar.Formatting *note 9.6.1(17/2): 4498.
+
+Tick
+ in Ada.Real_Time *note D.8(6): 8531.
+ in System *note 13.7(10): 5541.
+
+Tilde in Ada.Characters.Latin_1 *note A.3.3(14): 6040.
+
+Time_First in Ada.Real_Time *note D.8(4): 8523.
+
+Time_Last in Ada.Real_Time *note D.8(4): 8524.
+
+Time_Span_First in Ada.Real_Time *note D.8(5): 8527.
+
+Time_Span_Last in Ada.Real_Time *note D.8(5): 8528.
+
+Time_Span_Unit in Ada.Real_Time *note D.8(5): 8530.
+
+Time_Span_Zero in Ada.Real_Time *note D.8(5): 8529.
+
+Time_Unit in Ada.Real_Time *note D.8(4): 8525.
+
+Trailing_Nonseparate
+ in Interfaces.COBOL *note B.4(23): 8129.
+
+Trailing_Separate in Interfaces.COBOL *note B.4(23): 8127.
+
+Tuesday in Ada.Calendar.Formatting *note 9.6.1(17/2): 4496.
+
+UC_A_Acute in Ada.Characters.Latin_1 *note A.3.3(23): 6115.
+
+UC_A_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6116.
+
+UC_A_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6118.
+
+UC_A_Grave in Ada.Characters.Latin_1 *note A.3.3(23): 6114.
+
+UC_A_Ring in Ada.Characters.Latin_1 *note A.3.3(23): 6119.
+
+UC_A_Tilde in Ada.Characters.Latin_1 *note A.3.3(23): 6117.
+
+UC_AE_Diphthong
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6120.
+
+UC_C_Cedilla
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6121.
+
+UC_E_Acute in Ada.Characters.Latin_1 *note A.3.3(23): 6123.
+
+UC_E_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6124.
+
+UC_E_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6125.
+
+UC_E_Grave in Ada.Characters.Latin_1 *note A.3.3(23): 6122.
+
+UC_I_Acute in Ada.Characters.Latin_1 *note A.3.3(23): 6127.
+
+UC_I_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6128.
+
+UC_I_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6129.
+
+UC_I_Grave in Ada.Characters.Latin_1 *note A.3.3(23): 6126.
+
+UC_Icelandic_Eth
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6130.
+
+UC_Icelandic_Thorn
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6144.
+
+UC_N_Tilde in Ada.Characters.Latin_1 *note A.3.3(24): 6131.
+
+UC_O_Acute in Ada.Characters.Latin_1 *note A.3.3(24): 6133.
+
+UC_O_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6134.
+
+UC_O_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6136.
+
+UC_O_Grave in Ada.Characters.Latin_1 *note A.3.3(24): 6132.
+
+UC_O_Oblique_Stroke
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6138.
+
+UC_O_Tilde in Ada.Characters.Latin_1 *note A.3.3(24): 6135.
+
+UC_U_Acute in Ada.Characters.Latin_1 *note A.3.3(24): 6140.
+
+UC_U_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6141.
+
+UC_U_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6142.
+
+UC_U_Grave in Ada.Characters.Latin_1 *note A.3.3(24): 6139.
+
+UC_Y_Acute in Ada.Characters.Latin_1 *note A.3.3(24): 6143.
+
+UCHAR_MAX in Interfaces.C *note B.3(6): 7990.
+
+Unbounded in Ada.Text_IO *note A.10.1(5): 6865.
+
+Unsigned in Interfaces.COBOL *note B.4(23): 8125.
+
+Upper_Case_Map
+ in Ada.Strings.Maps.Constants *note A.4.6(5): 6430.
+
+Upper_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6422.
+
+US in Ada.Characters.Latin_1 *note A.3.3(6): 5980.
+
+Vertical_Line
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6038.
+
+VT in Ada.Characters.Latin_1 *note A.3.3(5): 5960.
+
+VTS in Ada.Characters.Latin_1 *note A.3.3(17): 6057.
+
+Wednesday in Ada.Calendar.Formatting *note 9.6.1(17/2): 4497.
+
+Wide_Character_Set
+ in Ada.Strings.Wide_Maps.Wide_Constants *note A.4.8(48/2): 6514.
+
+wide_nul in Interfaces.C *note B.3(31/1): 8016.
+
+Wide_Space in Ada.Strings *note A.4.1(4/2): 6225.
+
+Wide_Wide_Space in Ada.Strings *note A.4.1(4/2): 6226.
+
+Word_Size in System *note 13.7(13): 5545.
+
+Yen_Sign in Ada.Characters.Latin_1 *note A.3.3(21/3): 6085.
+
+\1f
+File: aarm2012.info, Node: Index, Prev: Annex Q, Up: Top
+
+Index
+*****
+
+Index entries are given by paragraph number.
+* Menu:
+
+* operators::
+* A::
+* B::
+* C::
+* D::
+* E::
+* F::
+* G::
+* H::
+* I::
+* J::
+* K::
+* L::
+* M::
+* N::
+* O::
+* P::
+* Q::
+* R::
+* S::
+* T::
+* U::
+* V::
+* W::
+* X::
+* Y::
+
+\1f
+File: aarm2012.info, Node: operators, Next: A, Up: Index
+
+operators
+=========
+
+
+
+& operator *note 4.4(1/3): 2817, *note 4.5.3(3): 3013.
+
+* operator *note 4.4(1/3): 2824, *note 4.5.5(1): 3040.
+** operator *note 4.4(1/3): 2838, *note 4.5.6(7): 3074.
+
++ operator *note 4.4(1/3): 2809, *note 4.5.3(1): 3005, *note 4.5.4(1):
+3030.
+
+- operator *note 4.4(1/3): 2813, *note 4.5.3(1): 3009, *note 4.5.4(1):
+3034.
+
+/ operator *note 4.4(1/3): 2830, *note 4.5.5(1): 3046.
+/= operator *note 4.4(1/3): 2787, *note 4.5.2(1): 2962, *note
+6.6(6/3): 3796.
+
+10646:2011, ISO/IEC standard *note 1.2(8/3): 1137.
+14882:2011, ISO/IEC standard *note 1.2(9/3): 1140.
+1539-1:2004, ISO/IEC standard *note 1.2(3/2): 1117.
+19769:2004, ISO/IEC technical report *note 1.2(10/2): 1143.
+1989:2002, ISO standard *note 1.2(4/2): 1120.
+
+3166-1:2006, ISO/IEC standard *note 1.2(4.1/3): 1123.
+
+639-3:2007, ISO standard *note 1.2(1.1/3): 1111.
+6429:1992, ISO/IEC standard *note 1.2(5): 1126.
+646:1991, ISO/IEC standard *note 1.2(2): 1114.
+
+8859-1:1998, ISO/IEC standard *note 1.2(6/3): 1131.
+
+9899:2011, ISO/IEC standard *note 1.2(7/3): 1134.
+
+< operator *note 4.4(1/3): 2791, *note 4.5.2(1): 2966.
+<= operator *note 4.4(1/3): 2795, *note 4.5.2(1): 2970.
+
+= operator *note 4.4(1/3): 2783, *note 4.5.2(1): 2958.
+
+> operator *note 4.4(1/3): 2799, *note 4.5.2(1): 2974.
+>= operator *note 4.4(1/3): 2803, *note 4.5.2(1): 2978.
+
+
+\1f
+File: aarm2012.info, Node: A, Next: B, Prev: operators, Up: Index
+
+A
+==
+
+
+
+abnormal completion *note 7.6.1(2/2): 3960.
+abnormal state of an object *note 13.9.1(4): 5598.
+ [partial] *note 9.8(21): 4616, *note 11.6(6/3): 5033, *note
+A.13(17): 7125.
+abnormal task *note 9.8(4): 4606.
+abnormal termination
+ of a partition *note 10.2(25.c): 4803.
+abort
+ of a partition *note E.1(7): 8697.
+ of a task *note 9.8(4): 4605.
+ of the execution of a construct *note 9.8(5): 4609.
+abort completion point *note 9.8(15): 4612.
+abort-deferred operation *note 9.8(5): 4610.
+abort_statement *note 9.8(2): 4599.
+ used *note 5.1(4/2): 3354, *note P: 9999.
+Abort_Task
+ in Ada.Task_Identification *note C.7.1(3/3): 8278.
+abortable_part *note 9.7.4(5): 4584.
+ used *note 9.7.4(2): 4577, *note P: 10270.
+abs operator *note 4.4(1/3): 2842, *note 4.5.6(1): 3063.
+absolute value *note 4.4(1/3): 2844, *note 4.5.6(1): 3065.
+abstract data type (ADT)
+ See private types and private extensions *note 7.3(1): 3855.
+ See also abstract type *note 3.9.3(1/2): 2321.
+abstract formal subprogram *note 12.6(8.c/2): 5250.
+abstract subprogram *note 3.9.3(1/2): 2324, *note 3.9.3(3/2): 2332.
+abstract type *note 3.9.3(1.2/2): 2330, *note 3.9.3(1/2): 2320, *note
+N(1.1/2): 9514.
+abstract_subprogram_declaration *note 3.9.3(1.1/3): 2326.
+ used *note 3.1(3/3): 1350, *note P: 9648.
+ACATS
+ Ada Conformity Assessment Test Suite *note 1.3(1.c/3): 1162.
+accept_alternative *note 9.7.1(5): 4546.
+ used *note 9.7.1(4): 4543, *note P: 10254.
+accept_statement *note 9.5.2(3): 4353.
+ used *note 5.1(5/2): 3363, *note 9.7.1(5): 4547, *note P: 10257.
+acceptable interpretation *note 8.6(14): 4147.
+Access attribute *note 3.10.2(24/1): 2464, *note 3.10.2(32/3): 2474.
+ See also Unchecked_Access attribute *note 13.10(3): 5616.
+access discriminant *note 3.7(9/2): 2100.
+access parameter *note 6.1(24/2): 3572.
+access paths
+ distinct *note 6.2(12/3): 3634.
+access result type *note 6.1(24/2): 3573.
+access type *note 3.10(1): 2367, *note N(2): 9515.
+ subpool *note 13.11.4(22/3): 5714.
+access types
+ input-output unspecified *note A.7(6): 6767.
+access value *note 3.10(1): 2368.
+access-to-constant type *note 3.10(10): 2403.
+access-to-object type *note 3.10(7/1): 2392.
+access-to-subprogram type *note 3.10(7/1): 2393, *note 3.10(11): 2405.
+access-to-variable type *note 3.10(10): 2404.
+Access_Check *note 11.5(11/2): 5000.
+ [partial] *note 4.1(13): 2554, *note 4.1.5(8/3): 2629, *note
+4.6(51/3): 3211, *note 4.8(10.4/3): 3289.
+access_definition *note 3.10(6/2): 2385.
+ used *note 3.3.1(2/3): 1554, *note 3.6(7/2): 2006, *note 3.7(5/2):
+2094, *note 6.1(13/2): 3547, *note 6.1(15/3): 3558, *note 6.5(2.3/2):
+3752, *note 8.5.1(2/3): 4088, *note 12.4(2/3): 5137, *note P: 10149.
+access_to_object_definition *note 3.10(3): 2377.
+ used *note 3.10(2/2): 2374, *note P: 9803.
+access_to_subprogram_definition *note 3.10(5): 2381.
+ used *note 3.10(2/2): 2376, *note P: 9805.
+access_type_definition *note 3.10(2/2): 2372.
+ used *note 3.2.1(4/2): 1446, *note 12.5.4(2): 5218, *note P: 9672.
+accessibility
+ distributed *note 3.10.2(32.1/3): 2479.
+ from shared passive library units *note E.2.1(8): 8722.
+accessibility level *note 3.10.2(3/2): 2442.
+accessibility rule
+ Access attribute *note 3.10.2(28/3): 2467, *note 3.10.2(32/3):
+2475.
+ checking in generic units *note 12.3(11.s): 5105.
+ not part of generic contract *note 3.9.1(4.k): 2279.
+ requeue statement *note 9.5.4(6/3): 4436.
+ type conversion *note 4.6(24.17/3): 3161, *note 4.6(24.21/2): 3168.
+ type conversion, array components *note 4.6(24.6/2): 3156.
+accessibility rules
+ See also Heart of Darkness *note 3.10.2(3.b/3): 2449.
+Accessibility_Check *note 11.5(19.1/2): 5009.
+ [partial] *note 3.10.2(29): 2469, *note 4.6(39.1/2): 3189, *note
+4.6(48/3): 3203, *note 4.8(10.1/3): 3280, *note 6.5(8/3): 3770, *note
+6.5(21/3): 3776, *note 13.11.4(25/3): 5716, *note 13.11.4(26/3): 5718,
+*note E.4(18/1): 8793.
+accessible partition *note E.1(7): 8699.
+accuracy *note 4.6(32): 3179, *note G.2(1): 8940.
+ACID *note 1.3(1.c/3): 1155.
+ACK
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5955.
+acquire
+ execution resource associated with protected object *note 9.5.1(5):
+4340.
+activation
+ of a task *note 9.2(1): 4244.
+activation failure *note 9.2(1): 4246.
+Activation_Is_Complete
+ in Ada.Task_Identification *note C.7.1(4/3): 8281.
+activator
+ of a task *note 9.2(5): 4247.
+active locale *note A.19(8/3): 7932.
+active partition *note 10.2(28/3): 4808, *note E.1(2): 8692.
+active priority *note D.1(15): 8332.
+actual *note 12.3(7/3): 5103.
+actual duration *note D.9(12): 8553.
+actual parameter
+ for a formal parameter *note 6.4.1(3): 3719.
+actual subtype *note 3.3(23/3): 1533, *note 12.5(4): 5182.
+ of an object *note 3.3.1(9/2): 1575.
+actual type *note 12.5(4): 5184.
+actual_parameter_part *note 6.4(4): 3697.
+ used *note 4.1.6(10/3): 2642, *note 6.4(2): 3692, *note 6.4(3):
+3696, *note 9.5.3(2): 4405, *note P: 9867.
+Actual_Quantum
+ in Ada.Dispatching.Round_Robin *note D.2.5(4/2): 8390.
+Acute
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6101.
+ACVC
+ Ada Compiler Validation Capability *note 1.3(1.c/3): 1160.
+Ada *note A.2(2): 5900.
+Ada calling convention *note 6.3.1(3/3): 3658.
+Ada Commentary Integration Document (ACID) *note 1.3(1.c/3): 1154.
+Ada Compiler Validation Capability
+ ACVC *note 1.3(1.c/3): 1161.
+Ada Conformity Assessment Test Suite
+ ACATS *note 1.3(1.c/3): 1163.
+Ada Issue (AI) *note 1.3(1.c/3): 1152.
+Ada Rapporteur Group (ARG) *note 1.3(1.c/3): 1150.
+Ada.Ada.Unchecked_Deallocate_Subpool *note 13.11.5(3/3): 5725.
+Ada.Assertions *note 11.4.2(12/2): 4971.
+Ada.Asynchronous_Task_Control *note D.11(3/2): 8572.
+Ada.Calendar *note 9.6(10): 4458.
+Ada.Calendar.Arithmetic *note 9.6.1(8/2): 4489.
+Ada.Calendar.Formatting *note 9.6.1(15/2): 4493.
+Ada.Calendar.Time_Zones *note 9.6.1(2/2): 4485.
+Ada.Characters *note A.3.1(2): 5903.
+Ada.Characters.Conversions *note A.3.4(2/2): 6178.
+Ada.Characters.Handling *note A.3.2(2/2): 5907.
+Ada.Characters.Latin_1 *note A.3.3(3): 5947.
+Ada.Command_Line *note A.15(3): 7127.
+Ada.Complex_Text_IO *note G.1.3(9.1/2): 8933.
+Ada.Containers *note A.18.1(3/2): 7225.
+Ada.Containers.Bounded_Priority_Queues *note A.18.31(2/3): 7916.
+Ada.Containers.Bounded_Synchronized_Queues *note A.18.29(2/3): 7901.
+Ada.Containers.Doubly_Linked_Lists *note A.18.3(5/3): 7337.
+Ada.Containers.Generic_Array_Sort *note A.18.26(3/2): 7878.
+Ada.Containers.Generic_Constrained_Array_Sort *note A.18.26(7/2):
+7880.
+Ada.Containers.Generic_Sort *note A.18.26(9.2/3): 7882.
+Ada.Containers.Hashed_Maps *note A.18.5(2/3): 7428.
+Ada.Containers.Hashed_Sets *note A.18.8(2/3): 7567.
+Ada.Containers.Indefinite_Doubly_Linked_Lists *note A.18.12(2/3):
+7811.
+Ada.Containers.Indefinite_Hashed_Maps *note A.18.13(2/3): 7813.
+Ada.Containers.Indefinite_Hashed_Sets *note A.18.15(2/3): 7817.
+Ada.Containers.Indefinite_Holders *note A.18.18(5/3): 7824.
+Ada.Containers.Indefinite_Multiway_Trees *note A.18.17(2/3): 7821.
+Ada.Containers.Indefinite_Ordered_Maps *note A.18.14(2/3): 7815.
+Ada.Containers.Indefinite_Ordered_Sets *note A.18.16(2/3): 7819.
+Ada.Containers.Indefinite_Vectors *note A.18.11(2/3): 7809.
+Ada.Containers.Multiway_Trees *note A.18.10(7/3): 7733.
+Ada.Containers.Ordered_Maps *note A.18.6(2/3): 7483.
+Ada.Containers.Ordered_Sets *note A.18.9(2/3): 7642.
+Ada.Containers.Synchronized_Queue_Interfaces *note A.18.27(3/3): 7886.
+Ada.Containers.Unbounded_Priority_Queues *note A.18.30(2/3): 7908.
+Ada.Containers.Unbounded_Synchronized_Queues *note A.18.28(2/3): 7894.
+Ada.Containers.Vectors *note A.18.2(6/3): 7236.
+Ada.Decimal *note F.2(2): 8829.
+Ada.Direct_IO *note A.8.4(2): 6807.
+Ada.Directories *note A.16(3/2): 7137.
+Ada.Directories.Hierarchical_File_Names *note A.16.1(3/3): 7191.
+Ada.Directories.Information *note A.16(124/2): 7187.
+Ada.Dispatching *note D.2.1(1.2/3): 8338.
+Ada.Dispatching.EDF *note D.2.6(9/2): 8395.
+Ada.Dispatching.Non_Preemptive *note D.2.4(2.2/3): 8377.
+Ada.Dispatching.Round_Robin *note D.2.5(4/2): 8386.
+Ada.Dynamic_Priorities *note D.5.1(3/2): 8443.
+Ada.Environment_Variables *note A.17(3/2): 7205.
+Ada.Exceptions *note 11.4.1(2/2): 4927.
+Ada.Execution_Time *note D.14(3/2): 8585.
+Ada.Execution_Time.Group_Budgets *note D.14.2(3/3): 8619.
+Ada.Execution_Time.Interrupts *note D.14.3(3/3): 8646.
+Ada.Execution_Time.Timers *note D.14.1(3/2): 8603.
+Ada.Finalization *note 7.6(4/3): 3927.
+Ada.Float_Text_IO *note A.10.9(33): 7029.
+Ada.Float_Wide_Text_IO *note A.11(2/2): 7052.
+Ada.Float_Wide_Wide_Text_IO *note A.11(3/2): 7055.
+Ada.Integer_Text_IO *note A.10.8(21): 7027.
+Ada.Integer_Wide_Text_IO *note A.11(2/2): 7051.
+Ada.Integer_Wide_Wide_Text_IO *note A.11(3/2): 7054.
+Ada.Interrupts *note C.3.2(2/3): 8224.
+Ada.Interrupts.Names *note C.3.2(12): 8235.
+Ada.IO_Exceptions *note A.13(3): 7114.
+Ada.Iterator_Interfaces *note 5.5.1(2/3): 3439.
+Ada.Locales *note A.19(3/3): 7925.
+Ada.Numerics *note A.5(3/2): 6579.
+Ada.Numerics.Complex_Arrays *note G.3.2(53/2): 9041.
+Ada.Numerics.Complex_Elementary_Functions *note G.1.2(9/1): 8915.
+Ada.Numerics.Complex_Types *note G.1.1(25/1): 8887.
+Ada.Numerics.Discrete_Random *note A.5.2(17): 6635.
+Ada.Numerics.Elementary_Functions *note A.5.1(9/1): 6614.
+Ada.Numerics.Float_Random *note A.5.2(5): 6622.
+Ada.Numerics.Generic_Complex_Arrays *note G.3.2(2/2): 9005.
+Ada.Numerics.Generic_Complex_Elementary_Functions *note G.1.2(2/2):
+8894.
+Ada.Numerics.Generic_Complex_Types *note G.1.1(2/1): 8866.
+Ada.Numerics.Generic_Elementary_Functions *note A.5.1(3): 6585.
+Ada.Numerics.Generic_Real_Arrays *note G.3.1(2/2): 8988.
+Ada.Numerics.Real_Arrays *note G.3.1(31/2): 9000.
+Ada.Real_Time *note D.8(3): 8521.
+Ada.Real_Time.Timing_Events *note D.15(3/2): 8650.
+Ada.Sequential_IO *note A.8.1(2): 6781.
+Ada.Storage_IO *note A.9(3): 6839.
+Ada.Streams *note 13.13.1(2): 5776.
+Ada.Streams.Stream_IO *note A.12.1(3/3): 7065.
+Ada.Strings *note A.4.1(3): 6223.
+Ada.Strings.Bounded *note A.4.4(3): 6300.
+Ada.Strings.Bounded.Equal_Case_Insensitive *note A.4.10(7/3): 6529.
+Ada.Strings.Bounded.Hash *note A.4.9(7/3): 6519.
+Ada.Strings.Bounded.Hash_Case_Insensitive *note A.4.9(11.7/3): 6523.
+Ada.Strings.Bounded.Less_Case_Insensitive *note A.4.10(18/3): 6533.
+Ada.Strings.Equal_Case_Insensitive *note A.4.10(2/3): 6527.
+Ada.Strings.Fixed *note A.4.3(5): 6262.
+Ada.Strings.Fixed.Equal_Case_Insensitive *note A.4.10(5/3): 6528.
+Ada.Strings.Fixed.Hash_Case_Insensitive *note A.4.9(11.5/3): 6522.
+Ada.Strings.Fixed.Less_Case_Insensitive *note A.4.10(16/3): 6532.
+Ada.Strings.Hash *note A.4.9(2/3): 6518.
+Ada.Strings.Hash_Case_Insensitive *note A.4.9(11.2/3): 6521.
+Ada.Strings.Less_Case_Insensitive *note A.4.10(13/3): 6531.
+Ada.Strings.Maps *note A.4.2(3/2): 6237.
+Ada.Strings.Maps.Constants *note A.4.6(3/2): 6417.
+Ada.Strings.Unbounded *note A.4.5(3): 6362.
+Ada.Strings.Unbounded.Equal_Case_Insensitive *note A.4.10(10/3): 6530.
+Ada.Strings.Unbounded.Hash *note A.4.9(10/3): 6520.
+Ada.Strings.Unbounded.Hash_Case_Insensitive *note A.4.9(11.10/3):
+6524.
+Ada.Strings.Unbounded.Less_Case_Insensitive *note A.4.10(21/3): 6534.
+Ada.Strings.UTF_Encoding *note A.4.11(3/3): 6536.
+Ada.Strings.UTF_Encoding.Conversions *note A.4.11(15/3): 6547.
+Ada.Strings.UTF_Encoding.Strings *note A.4.11(22/3): 6553.
+Ada.Strings.UTF_Encoding.Wide_Strings *note A.4.11(30/3): 6560.
+Ada.Strings.UTF_Encoding.Wide_Wide_Strings *note A.4.11(38/3): 6567.
+Ada.Strings.Wide_Bounded *note A.4.7(1/3): 6434.
+Ada.Strings.Wide_Bounded.Wide_Equal_Case_Insensitive *note A.4.7(1/3):
+6442.
+Ada.Strings.Wide_Bounded.Wide_Hash *note A.4.7(1/3): 6438.
+Ada.Strings.Wide_Bounded.Wide_Hash_Case_Insensitive *note A.4.7(1/3):
+6446.
+Ada.Strings.Wide_Equal_Case_Insensitive *note A.4.7(1/3): 6440.
+Ada.Strings.Wide_Fixed *note A.4.7(1/3): 6433.
+Ada.Strings.Wide_Fixed.Wide_Equal_Case_Insensitive *note A.4.7(1/3):
+6441.
+Ada.Strings.Wide_Fixed.Wide_Hash *note A.4.7(1/3): 6437.
+Ada.Strings.Wide_Fixed.Wide_Hash_Case_Insensitive *note A.4.7(1/3):
+6445.
+Ada.Strings.Wide_Hash *note A.4.7(1/3): 6436.
+Ada.Strings.Wide_Hash_Case_Insensitive *note A.4.7(1/3): 6444.
+Ada.Strings.Wide_Maps *note A.4.7(3): 6449.
+Ada.Strings.Wide_Maps.Wide_Constants *note A.4.7(1/3): 6448, *note
+A.4.8(28/2): 6512.
+Ada.Strings.Wide_Unbounded *note A.4.7(1/3): 6435.
+Ada.Strings.Wide_Unbounded.Wide_Equal_Case_Insensitive *note
+A.4.7(1/3): 6443.
+Ada.Strings.Wide_Unbounded.Wide_Hash *note A.4.7(1/3): 6439.
+Ada.Strings.Wide_Unbounded.Wide_Hash_Case_Insensitive *note
+A.4.7(1/3): 6447.
+Ada.Strings.Wide_Wide_Bounded *note A.4.8(1/3): 6476.
+Ada.Strings.Wide_Wide_Bounded.Wide_Wide_Equal_Case_Insensitive *note
+A.4.8(1/3): 6484.
+Ada.Strings.Wide_Wide_Bounded.Wide_Wide_Hash *note A.4.8(1/3): 6480.
+Ada.Strings.Wide_Wide_Bounded.Wide_Wide_Hash_Case_Insensitive *note
+A.4.8(1/3): 6488.
+Ada.Strings.Wide_Wide_Equal_Case_Insensitive *note A.4.8(1/3): 6482.
+Ada.Strings.Wide_Wide_Fixed *note A.4.8(1/3): 6475.
+Ada.Strings.Wide_Wide_Fixed.Wide_Wide_Equal_Case_Insensitive *note
+A.4.8(1/3): 6483.
+Ada.Strings.Wide_Wide_Fixed.Wide_Wide_Hash *note A.4.8(1/3): 6479.
+Ada.Strings.Wide_Wide_Fixed.Wide_Wide_Hash_Case_Insensitive *note
+A.4.8(1/3): 6487.
+Ada.Strings.Wide_Wide_Hash *note A.4.8(1/3): 6478.
+Ada.Strings.Wide_Wide_Hash_Case_Insensitive *note A.4.8(1/3): 6486.
+Ada.Strings.Wide_Wide_Maps *note A.4.8(3/2): 6491.
+Ada.Strings.Wide_Wide_Maps.Wide_Wide_Constants *note A.4.8(1/3): 6490.
+Ada.Strings.Wide_Wide_Unbounded *note A.4.8(1/3): 6477.
+Ada.Strings.Wide_Wide_Unbounded.Wide_Wide_Equal_Case_Insensitive *note
+A.4.8(1/3): 6485.
+Ada.Strings.Wide_Wide_Unbounded.Wide_Wide_Hash *note A.4.8(1/3): 6481.
+Ada.Strings.Wide_Wide_Unbounded.Wide_Wide_Hash_Case_Insensitive *note
+A.4.8(1/3): 6489.
+Ada.Synchronous_Barriers *note D.10.1(3/3): 8567.
+Ada.Synchronous_Task_Control *note D.10(3/2): 8554.
+Ada.Synchronous_Task_Control.EDF *note D.10(5.2/3): 8560.
+Ada.Tags *note 3.9(6/2): 2229.
+Ada.Tags.Generic_Dispatching_Constructor *note 3.9(18.2/3): 2254.
+Ada.Task_Attributes *note C.7.2(2): 8293.
+Ada.Task_Identification *note C.7.1(2/2): 8272.
+Ada.Task_Termination *note C.7.3(2/2): 8305.
+Ada.Text_IO *note A.10.1(2): 6860.
+Ada.Text_IO.Bounded_IO *note A.10.11(3/2): 7030.
+Ada.Text_IO.Complex_IO *note G.1.3(3): 8923.
+Ada.Text_IO.Editing *note F.3.3(3): 8840.
+Ada.Text_IO.Text_Streams *note A.12.2(3): 7104.
+Ada.Text_IO.Unbounded_IO *note A.10.12(3/2): 7040.
+Ada.Unchecked_Conversion *note 13.9(3/3): 5590.
+Ada.Unchecked_Deallocate_Subpool
+ child of Ada *note 13.11.5(3/3): 5725.
+Ada.Unchecked_Deallocation *note 13.11.2(3/3): 5669.
+Ada.Wide_Characters *note A.3.1(4/2): 5904.
+Ada.Wide_Characters.Handling *note A.3.5(3/3): 6198.
+Ada.Wide_Text_IO *note A.11(2/2): 7050.
+Ada.Wide_Text_IO.Bounded_IO *note A.11(4/3): 7056.
+Ada.Wide_Text_IO.Complex_IO *note G.1.4(1): 8936.
+Ada.Wide_Text_IO.Editing *note F.3.4(1): 8859.
+Ada.Wide_Text_IO.Text_Streams *note A.12.3(3): 7107.
+Ada.Wide_Text_IO.Unbounded_IO *note A.11(5/3): 7058.
+Ada.Wide_Wide_Characters *note A.3.1(6/2): 5905.
+Ada.Wide_Wide_Characters.Handling *note A.3.6(1/3): 6220.
+Ada.Wide_Wide_Text_IO *note A.11(3/2): 7053.
+Ada.Wide_Wide_Text_IO.Bounded_IO *note A.11(4/3): 7057.
+Ada.Wide_Wide_Text_IO.Complex_IO *note G.1.5(1/2): 8938.
+Ada.Wide_Wide_Text_IO.Editing *note F.3.5(1/2): 8862.
+Ada.Wide_Wide_Text_IO.Text_Streams *note A.12.4(3/2): 7110.
+Ada.Wide_Wide_Text_IO.Unbounded_IO *note A.11(5/3): 7059.
+Ada_To_COBOL
+ in Interfaces.COBOL *note B.4(14): 8116.
+adafinal *note B.1(39/3): 7974.
+adainit *note B.1(39/3): 7973.
+Add
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(9/2): 8630.
+Add_Task
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(8/2): 8624.
+address
+ arithmetic *note 13.7.1(6): 5564.
+ comparison *note 13.7(14/3): 5547.
+ in System *note 13.7(12): 5542.
+Address aspect *note 13.3(12): 5395.
+Address attribute *note 13.3(11): 5391, *note J.7.1(5): 9136.
+Address clause *note 13.3(7/2): 5369, *note 13.3(12): 5393.
+Address_To_Access_Conversions
+ child of System *note 13.7.2(2): 5572.
+Adjacent attribute *note A.5.3(48): 6713.
+Adjust *note 7.6(2): 3926.
+ in Ada.Finalization *note 7.6(6/2): 3930.
+adjusting the value of an object *note 7.6(15): 3940, *note 7.6(16/3):
+3942.
+adjustment *note 7.6(15): 3941, *note 7.6(16/3): 3943.
+ as part of assignment *note 5.2(14/3): 3394.
+ADT (abstract data type)
+ See private types and private extensions *note 7.3(1): 3856.
+ See also abstract type *note 3.9.3(1/2): 2322.
+advice *note 1.1.2(37): 1047.
+Aft attribute *note 3.5.10(5): 1976.
+aggregate *note 4.3(1): 2668, *note 4.3(2): 2670.
+ used *note 4.4(7/3): 2903, *note 4.7(2): 3240, *note P: 9977.
+ See also composite type *note 3.2(2/2): 1396.
+AI *note 1.3(1.c/3): 1153.
+aliased *note 3.10(9/3): 2400, *note N(3): 9516.
+aliasing
+ See distinct access paths *note 6.2(12/3): 3635.
+Alignment
+ in Ada.Strings *note A.4.1(6): 6231.
+Alignment (subtype) aspect *note 13.3(26.4/2): 5407.
+Alignment attribute *note 13.3(23/2): 5399, *note 13.3(26.2/2): 5403.
+Alignment clause *note 13.3(7/2): 5370, *note 13.3(25/2): 5401, *note
+13.3(26.4/2): 5405.
+All_Calls_Remote aspect *note E.2.3(16/3): 8763.
+All_Calls_Remote pragma *note E.2.3(5): 8751, *note L(2): 9329.
+All_Checks *note 11.5(25/3): 5014.
+Allocate
+ in System.Storage_Pools *note 13.11(7): 5624.
+ in System.Storage_Pools.Subpools *note 13.11.4(14/3): 5704.
+Allocate_From_Subpool
+ in System.Storage_Pools.Subpools *note 13.11.4(11/3): 5701.
+Allocation_Check *note 11.5(19.2/2): 5010.
+ [partial] *note 4.8(10.2/2): 3283, *note 4.8(10.3/2): 3286, *note
+4.8(10.4/3): 3291, *note 13.11.4(30/3): 5721.
+allocator *note 4.8(2/3): 3254.
+ used *note 4.4(7/3): 2905, *note P: 9946.
+Alphanumeric
+ in Interfaces.COBOL *note B.4(16/3): 8118.
+alphanumeric character
+ a category of Character *note A.3.2(31): 5943.
+Alphanumeric_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6426.
+ambiguous *note 8.6(30): 4168.
+ambiguous cursor
+ of a vector *note A.18.2(240/2): 7323.
+ambiguous grammar *note 1.1.4(14.a): 1083.
+Amendment Correction *note 1.1.2(39.n/3): 1055.
+ampersand *note 2.1(15/3): 1190.
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5987.
+ampersand operator *note 4.4(1/3): 2819, *note 4.5.3(3): 3015.
+ancestor *note N(3.1/2): 9517.
+ of a library unit *note 10.1.1(11): 4683.
+ of a tree node *note A.18.10(4/3): 7730.
+ of a type *note 3.4.1(10/2): 1658.
+ ultimate *note 3.4.1(10/2): 1660.
+ancestor subtype
+ of a formal derived type *note 12.5.1(5/3): 5196.
+ of a private_extension_declaration *note 7.3(8): 3869.
+ancestor type
+ of an extension_aggregate *note 4.3.2(5/3): 2718.
+Ancestor_Find
+ in Ada.Containers.Multiway_Trees *note A.18.10(40/3): 7765.
+ancestor_part *note 4.3.2(3): 2713.
+ used *note 4.3.2(2): 2711, *note P: 9879.
+and operator *note 4.4(1/3): 2775, *note 4.5.1(2): 2937.
+and then (short-circuit control form) *note 4.4(1/3): 2781, *note
+4.5.1(1): 2932.
+angle threshold *note G.2.4(10): 8980.
+Annex
+ informative *note 1.1.2(18): 1012.
+ normative *note 1.1.2(14): 1009.
+ Specialized Needs *note 1.1.2(7): 1006.
+anonymous access type *note 3.10(12/3): 2408.
+anonymous allocator *note 3.10.2(14/3): 2457.
+anonymous array type *note 3.3.1(1/3): 1545.
+anonymous protected type *note 3.3.1(1/3): 1547.
+anonymous task type *note 3.3.1(1/3): 1546.
+anonymous type *note 3.2.1(7/2): 1451.
+Any_Priority subtype of Integer
+ in System *note 13.7(16): 5552.
+APC
+ in Ada.Characters.Latin_1 *note A.3.3(19): 6078.
+apostrophe *note 2.1(15/3): 1191.
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5988.
+Append
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(23/2): 7361.
+ in Ada.Containers.Vectors *note A.18.2(46/2): 7281, *note
+A.18.2(47/2): 7282.
+ in Ada.Strings.Bounded *note A.4.4(13): 6310, *note A.4.4(14):
+6311, *note A.4.4(15): 6312, *note A.4.4(16): 6313, *note A.4.4(17):
+6314, *note A.4.4(18): 6315, *note A.4.4(19): 6316, *note A.4.4(20):
+6317.
+ in Ada.Strings.Unbounded *note A.4.5(12): 6372, *note A.4.5(13):
+6373, *note A.4.5(14): 6374.
+Append_Child
+ in Ada.Containers.Multiway_Trees *note A.18.10(52/3): 7777.
+applicable index constraint *note 4.3.3(10): 2756.
+application areas *note 1.1.2(7): 1007.
+applies
+ aspect *note 13.1.1(23/3): 5342, *note 13.1.1(27/3): 5343, *note
+13.1.1(29/3): 5344, *note 13.1.1(30/3): 5345.
+apply
+ to a callable construct by a return statement *note 6.5(4/2): 3756.
+ to a loop_statement by an exit_statement *note 5.7(4): 3501.
+ to a program unit by a program unit pragma *note 10.1.5(2): 4762.
+arbitrary order *note 1.1.4(18): 1089.
+ allowed *note 2.8(12): 1325, *note 3.3.1(20/2): 1588, *note 3.5(9):
+1691, *note 3.6(22/2): 2031, *note 3.11(10/1): 2511, *note 3.11(11/3):
+2512, *note 3.11(13): 2513, *note 4.1.1(7): 2567, *note 4.1.2(7): 2578,
+*note 4.3(5): 2677, *note 4.3.1(19): 2705, *note 4.3.2(7): 2721, *note
+4.3.3(22): 2758, *note 4.3.3(23): 2761, *note 4.5.2(27/3): 2996, *note
+4.8(10/2): 3279, *note 5.2(7): 3386, *note 6.1.1(26/3): 3604, *note
+6.1.1(34/3): 3613, *note 6.1.1(35/3): 3618, *note 6.4(10/2): 3709, *note
+6.4.1(17): 3735, *note 7.6(12): 3938, *note 7.6(16/3): 3944, *note
+7.6.1(9/3): 3967, *note 7.6.1(11.1/3): 3973, *note 7.6.1(20.2/3): 3982,
+*note 9.7.1(15): 4556, *note 9.8(4): 4604, *note 12.3(20): 5119, *note
+13.11.5(7/3): 5726, *note K.2(164.2/3): 9304.
+Arccos
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(5): 8904.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(6): 6601.
+Arccosh
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(7): 8912.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6611.
+Arccot
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(5): 8906.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(6): 6604.
+Arccoth
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(7): 8914.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6613.
+Arcsin
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(5): 8903.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(6): 6599.
+Arcsinh
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(7): 8911.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6610.
+Arctan
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(5): 8905.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(6): 6602.
+Arctanh
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(7): 8913.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6612.
+ARG *note 1.3(1.c/3): 1151.
+Argument
+ in Ada.Command_Line *note A.15(5): 7129.
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(10/2): 9015,
+*note G.3.2(31/2): 9029.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(10): 8882.
+argument of a pragma *note 2.8(9): 1320.
+Argument_Count
+ in Ada.Command_Line *note A.15(4): 7128.
+Argument_Error
+ in Ada.Numerics *note A.5(3/2): 6580.
+Arithmetic
+ child of Ada.Calendar *note 9.6.1(8/2): 4489.
+array *note 3.6(1): 1986.
+array component expression *note 4.3.3(6): 2750.
+array component iterator *note 5.5.2(3/3): 3476.
+array for a loop *note 5.5.2(11/3): 3486.
+array indexing
+ See indexed_component *note 4.1.1(1): 2559.
+array slice *note 4.1.2(1): 2572.
+array type *note 3.6(1): 1987, *note N(4): 9518.
+array_aggregate *note 4.3.3(2): 2729.
+ used *note 4.3(2): 2673, *note 13.4(3): 5461, *note P: 10448.
+array_component_association *note 4.3.3(5/2): 2744.
+ used *note 4.3.3(4): 2742, *note P: 9894.
+array_type_definition *note 3.6(2): 1988.
+ used *note 3.2.1(4/2): 1444, *note 3.3.1(2/3): 1558, *note
+12.5.3(2): 5213, *note P: 9698.
+ASCII
+ package physically nested within the declaration of Standard *note
+A.1(36.3/2): 5888.
+ in Standard *note A.1(36.3/2): 5887.
+aspect *note 13.1(0.1/3): 5276, *note K.1(1/3): 9280, *note N(4.1/3):
+9519.
+ interfacing *note B.1(0.1/3): 7940.
+ predicate *note 3.2.4(1/3): 1501.
+aspect of representation *note 13.1(8/3): 5297.
+aspect_clause *note 13.1(2/1): 5281.
+ used *note 3.8(5/1): 2156, *note 3.11(4/1): 2496, *note 9.1(5/1):
+4216, *note 9.4(5/1): 4282, *note 9.4(8/1): 4295, *note P: 10184.
+aspect_definition *note 13.1.1(4/3): 5333.
+ used *note 13.1.1(2/3): 5330, *note P: 10433.
+aspect_mark *note 13.1.1(3/3): 5331.
+ used *note 2.8(3/3): 1313, *note 11.4.2(6.1/3): 4967, *note
+13.1.1(2/3): 5327, *note L(2.3/3): 9342, *note P: 9641.
+aspect_specification *note 13.1.1(2/3): 5326.
+ used *note 3.2.1(3/3): 1437, *note 3.2.2(2/3): 1464, *note
+3.3.1(2/3): 1552, *note 3.8(6/3): 2161, *note 3.9.3(1.1/3): 2329, *note
+6.1(2/3): 3516, *note 6.3(2/3): 3642, *note 6.7(2/3): 3802, *note
+6.8(2/3): 3813, *note 7.1(3/3): 3829, *note 7.2(2/3): 3844, *note
+7.3(2/3): 3860, *note 7.3(3/3): 3866, *note 8.5.1(2/3): 4090, *note
+8.5.2(2/3): 4102, *note 8.5.3(2/3): 4107, *note 8.5.4(2/3): 4115, *note
+8.5.5(2/3): 4131, *note 9.1(2/3): 4202, *note 9.1(3/3): 4207, *note
+9.1(6/3): 4219, *note 9.4(2/3): 4267, *note 9.4(3/3): 4272, *note
+9.4(7/3): 4288, *note 9.5.2(2/3): 4352, *note 10.1.3(3/3): 4731, *note
+10.1.3(4): 4734, *note 10.1.3(5): 4737, *note 10.1.3(6): 4740, *note
+11.1(2/3): 4873, *note 12.1(3/3): 5046, *note 12.3(2/3): 5075, *note
+12.4(2/3): 5139, *note 12.5(2.1/3): 5165, *note 12.6(2.1/3): 5235, *note
+12.6(2.2/3): 5239, *note 12.7(2/3): 5261, *note P: 9692.
+aspects
+ Address *note 13.3(12): 5394.
+ Alignment (subtype) *note 13.3(26.4/2): 5406.
+ All_Calls_Remote *note E.2.3(16/3): 8762.
+ Asynchronous *note E.4.1(8.1/3): 8801.
+ Atomic *note C.6(6.2/3): 8249.
+ Atomic_Components *note C.6(6.6/3): 8255.
+ Attach_Handler *note C.3.1(6.3/3): 8205.
+ Bit_Order *note 13.5.3(4): 5523.
+ Coding *note 13.4(7): 5465.
+ Component_Size *note 13.3(70): 5440.
+ Constant_Indexing *note 4.1.6(2/3): 2633.
+ Convention *note B.1(2/3): 7954.
+ CPU *note D.16(8/3): 8668.
+ Default_Component_Value *note 3.6(22.2/3): 2032.
+ Default_Iterator *note 5.5.1(8/3): 3454.
+ Default_Storage_Pool *note 13.11.3(5/3): 5690.
+ Default_Value *note 3.5(56.3/3): 1761.
+ Dispatching_Domain *note D.16.1(18/3): 8683.
+ Dynamic_Predicate *note 3.2.4(1/3): 1504.
+ Elaborate_Body *note 10.2.1(26.1/3): 4853.
+ Export *note B.1(1/3): 7943.
+ External_Name *note B.1(1/3): 7947.
+ External_Tag *note 13.3(75/3): 5451, *note K.2(65): 9295.
+ Implicit_Dereference *note 4.1.5(2/3): 2620.
+ Import *note B.1(1/3): 7941.
+ Independent *note C.6(6.3/3): 8251.
+ Independent_Components *note C.6(6.9/3): 8259.
+ Inline *note 6.3.2(5.1/3): 3685.
+ Input *note 13.13.2(38/3): 5824.
+ Interrupt_Handler *note C.3.1(6.2/3): 8203.
+ Interrupt_Priority *note D.1(6.3/3): 8326.
+ Iterator_Element *note 5.5.1(9/3): 3457.
+ Layout *note 13.5(1): 5469.
+ Link_Name *note B.1(1/3): 7945.
+ Machine_Radix *note F.1(1): 8827.
+ No_Return *note 6.5.1(3.2/3): 3787.
+ Output *note 13.13.2(38/3): 5826.
+ Pack *note 13.2(5.1/3): 5348.
+ Post *note 6.1.1(4/3): 3590.
+ Post'Class *note 6.1.1(5/3): 3594.
+ Pre *note 6.1.1(2/3): 3582.
+ Pre'Class *note 6.1.1(3/3): 3586.
+ Preelaborate *note 10.2.1(11/3): 4822.
+ Priority *note D.1(6.2/3): 8324.
+ Pure *note 10.2.1(17/3): 4835.
+ Read *note 13.13.2(38/3): 5820.
+ Record layout *note 13.5(1): 5473.
+ Relative_Deadline *note D.2.6(9.2/3): 8401.
+ Remote_Call_Interface *note E.2.3(7/3): 8760.
+ Remote_Types *note E.2.2(4/3): 8735.
+ Shared_Passive *note E.2.1(4/3): 8720.
+ Size (object) *note 13.3(41): 5416.
+ Size (subtype) *note 13.3(48): 5423.
+ Small *note 3.5.10(2/1): 1969.
+ Static_Predicate *note 3.2.4(1/3): 1502.
+ Storage_Pool *note 13.11(15): 5640.
+ Storage_Size (access) *note 13.11(15): 5642.
+ Storage_Size (task) *note 13.3(65.2/3): 5431.
+ Stream_Size *note 13.13.2(1.5/2): 5788.
+ Synchronization *note 9.5(12/3): 4330.
+ Type_Invariant *note 7.3.2(2/3): 3892.
+ Type_Invariant'Class *note 7.3.2(3/3): 3894.
+ Unchecked_Union *note B.3.3(3.2/3): 8093.
+ Variable_Indexing *note 4.1.6(3/3): 2635.
+ Volatile *note C.6(6.4/3): 8253.
+ Volatile_Components *note C.6(6.7/3): 8257.
+ Write *note 13.13.2(38/3): 5822.
+assembly language *note C.1(4/3): 8189.
+Assert
+ in Ada.Assertions *note 11.4.2(14/2): 4974.
+Assert pragma *note 11.4.2(3/2): 4957, *note L(2.1/2): 9332.
+assertion *note N(4.2/3): 9520.
+assertion expressions *note 11.4.2(1.1/3): 4955.
+assertion policy
+ Assert pragma *note 11.4.2(18/3): 4975.
+Assertion_Error
+ raised by failure of assertion *note 11.4.2(18/3): 4976.
+ raised by failure of run-time check *note 3.2.4(31/3): 1518, *note
+4.6(57/3): 3226, *note 6.1.1(32/3): 3607, *note 6.1.1(33/3): 3610, *note
+6.1.1(35/3): 3617, *note 7.3.2(22/3): 3900.
+ in Ada.Assertions *note 11.4.2(13/2): 4972.
+Assertion_Policy pragma *note 11.4.2(6.1/3): 4964, *note 11.4.2(6/2):
+4961, *note L(2.2/2): 9336, *note L(2.3/3): 9339.
+assertions *note 11.4.2(1.1/3): 4954.
+ child of Ada *note 11.4.2(12/2): 4971.
+Assign
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(17.5/3): 7354.
+ in Ada.Containers.Hashed_Maps *note A.18.5(17.7/3): 7450.
+ in Ada.Containers.Hashed_Sets *note A.18.8(17.3/3): 7585.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(20/3): 7838.
+ in Ada.Containers.Multiway_Trees *note A.18.10(32/3): 7757.
+ in Ada.Containers.Ordered_Maps *note A.18.6(16.7/3): 7504.
+ in Ada.Containers.Ordered_Sets *note A.18.9(16.3/3): 7659.
+ in Ada.Containers.Vectors *note A.18.2(34.7/3): 7268.
+ See assignment operation *note 5.2(3): 3380.
+Assign_Task
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(11/3):
+8679.
+assigning back of parameters *note 6.4.1(17): 3732.
+assignment
+ user-defined *note 7.6(1): 3919.
+assignment operation *note 5.2(3): 3379, *note 5.2(12): 3392, *note
+7.6(13): 3939.
+ during elaboration of an object_declaration *note 3.3.1(18/2):
+1586.
+ during evaluation of a generic_association for a formal object of
+mode in *note 12.4(11): 5153.
+ during evaluation of a parameter_association *note 6.4.1(11): 3725.
+ during evaluation of an aggregate *note 4.3(5): 2676.
+ during evaluation of an initialized allocator *note 4.8(7/2): 3270.
+ during evaluation of an uninitialized allocator *note 4.8(9/2):
+3273.
+ during evaluation of concatenation *note 4.5.3(10): 3025.
+ during execution of a for loop *note 5.5(9/3): 3438.
+ during execution of an assignment_statement *note 5.2(12): 3393.
+ during parameter copy back *note 6.4.1(17): 3733.
+ list of uses *note 7.6.1(24.d): 3983.
+assignment_statement *note 5.2(2): 3376.
+ used *note 5.1(4/2): 3346, *note P: 9991.
+associated components
+ of a record_component_association *note 4.3.1(10): 2701.
+associated declaration
+ of an aspect specification *note 13.1.1(1/3): 5325.
+associated discriminants
+ of a named discriminant_association *note 3.7.1(5): 2128.
+ of a positional discriminant_association *note 3.7.1(5): 2129.
+associated entity
+ of an aspect specification *note 13.1.1(5/3): 5337.
+associated object
+ of a value of a by-reference type *note 6.2(10/3): 3629.
+ of a value of a limited type *note 6.2(10.f): 3630.
+asterisk *note 2.1(15/3): 1195.
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5991.
+asynchronous
+ remote procedure call *note E.4.1(9/3): 8804.
+Asynchronous aspect *note E.4.1(8.1/3): 8802.
+Asynchronous pragma *note J.15.13(2/3): 9278, *note L(3.1/3): 9345.
+asynchronous remote procedure call *note E.4(1): 8780.
+asynchronous_select *note 9.7.4(2): 4575.
+ used *note 9.7(2): 4531, *note P: 10247.
+Asynchronous_Task_Control
+ child of Ada *note D.11(3/2): 8572.
+at-most-once execution *note E.4(11): 8789.
+at_clause *note J.7(1): 9130.
+ used *note 13.1(2/1): 5285, *note P: 10427.
+atomic *note C.6(7/3): 8261.
+Atomic aspect *note C.6(6.2/3): 8250.
+Atomic pragma *note J.15.8(2/3): 9228, *note L(4.1/3): 9348.
+Atomic_Components aspect *note C.6(6.6/3): 8256.
+Atomic_Components pragma *note J.15.8(5/3): 9237, *note L(5.1/3):
+9351.
+Attach_Handler
+ in Ada.Interrupts *note C.3.2(7): 8230.
+Attach_Handler aspect *note C.3.1(6.3/3): 8206.
+Attach_Handler pragma *note J.15.7(4/3): 9221, *note L(6.1/3): 9354.
+attaching
+ to an interrupt *note C.3(2): 8198.
+attribute *note 4.1.4(1): 2602, *note K.2(1/3): 9281.
+ representation *note 13.3(1/1): 5353.
+ specifiable *note 13.3(5/3): 5365.
+ specifying *note 13.3(1/1): 5354.
+attribute_definition_clause *note 13.3(2): 5355.
+ used *note 13.1(2/1): 5282, *note P: 10424.
+attribute_designator *note 4.1.4(3/2): 2606.
+ used *note 4.1.4(2): 2605, *note 13.1(3): 5289, *note 13.3(2):
+5360, *note P: 10444.
+Attribute_Handle
+ in Ada.Task_Attributes *note C.7.2(3): 8294.
+attribute_reference *note 4.1.4(2): 2603.
+ used *note 4.1(2/3): 2528, *note P: 9835.
+attributes
+ Access *note 3.10.2(24/1): 2463, *note 3.10.2(32/3): 2473.
+ Address *note 13.3(11): 5390, *note J.7.1(5): 9135.
+ Adjacent *note A.5.3(48): 6712.
+ Aft *note 3.5.10(5): 1975.
+ Alignment *note 13.3(23/2): 5398, *note 13.3(26.2/2): 5402.
+ Base *note 3.5(15): 1699.
+ Bit_Order *note 13.5.3(4): 5519.
+ Body_Version *note E.3(4): 8772.
+ Callable *note 9.9(2): 4619.
+ Caller *note C.7.1(14/3): 8284.
+ Ceiling *note A.5.3(33): 6696.
+ Class *note 3.9(14): 2246, *note 7.3.1(9): 3889, *note J.11(2/2):
+9151.
+ Component_Size *note 13.3(69): 5436.
+ Compose *note A.5.3(24): 6684.
+ Constrained *note 3.7.2(3/3): 2138, *note J.4(2): 9128.
+ Copy_Sign *note A.5.3(51): 6717.
+ Count *note 9.9(5): 4625.
+ Definite *note 12.5.1(23/3): 5199.
+ Delta *note 3.5.10(3): 1971.
+ Denorm *note A.5.3(9): 6666.
+ Digits *note 3.5.8(2/1): 1919, *note 3.5.10(7): 1977.
+ Exponent *note A.5.3(18): 6680.
+ External_Tag *note 13.3(75/3): 5447.
+ First *note 3.5(12): 1693, *note 3.6.2(3): 2053.
+ First(N) *note 3.6.2(4): 2055.
+ First_Bit *note 13.5.2(3/2): 5505.
+ First_Valid *note 3.5.5(7.2/3): 1871.
+ Floor *note A.5.3(30): 6694.
+ Fore *note 3.5.10(4): 1973.
+ Fraction *note A.5.3(21): 6682.
+ Has_Same_Storage *note 13.3(73.2/3): 5443.
+ Identity *note 11.4.1(9): 4946, *note C.7.1(12): 8282.
+ Image *note 3.5(35): 1729.
+ Input *note 13.13.2(22): 5801, *note 13.13.2(32): 5805.
+ Last *note 3.5(13): 1695, *note 3.6.2(5): 2057.
+ Last(N) *note 3.6.2(6): 2059.
+ Last_Bit *note 13.5.2(4/2): 5507.
+ Last_Valid *note 3.5.5(7.3/3): 1873.
+ Leading_Part *note A.5.3(54): 6722.
+ Length *note 3.6.2(9): 2065.
+ Length(N) *note 3.6.2(10): 2067.
+ Machine *note A.5.3(60): 6727.
+ Machine_Emax *note A.5.3(8): 6664.
+ Machine_Emin *note A.5.3(7): 6662.
+ Machine_Mantissa *note A.5.3(6): 6660.
+ Machine_Overflows *note A.5.3(12): 6674, *note A.5.4(4): 6755.
+ Machine_Radix *note A.5.3(2): 6657, *note A.5.4(2): 6751.
+ Machine_Rounding *note A.5.3(41.1/2): 6702.
+ Machine_Rounds *note A.5.3(11): 6672, *note A.5.4(3): 6753.
+ Max *note 3.5(19): 1705.
+ Max_Alignment_For_Allocation *note 13.11.1(4/3): 5661.
+ Max_Size_In_Storage_Elements *note 13.11.1(3/3): 5659.
+ Min *note 3.5(16): 1702.
+ Mod *note 3.5.4(16.1/2): 1840.
+ Model *note A.5.3(68): 6741, *note G.2.2(7): 8963.
+ Model_Emin *note A.5.3(65): 6735, *note G.2.2(4): 8956.
+ Model_Epsilon *note A.5.3(66): 6737.
+ Model_Mantissa *note A.5.3(64): 6733, *note G.2.2(3/2): 8954.
+ Model_Small *note A.5.3(67): 6739.
+ Modulus *note 3.5.4(17): 1842.
+ Old *note 6.1.1(26/3): 3602.
+ Output *note 13.13.2(19): 5799, *note 13.13.2(29): 5803.
+ Overlaps_Storage *note 13.3(73.6/3): 5445.
+ Partition_Id *note E.1(9): 8700.
+ Pos *note 3.5.5(2): 1863.
+ Position *note 13.5.2(2/2): 5503.
+ Pred *note 3.5(25): 1714.
+ Priority *note D.5.2(3/2): 8450.
+ Range *note 3.5(14): 1697, *note 3.6.2(7): 2061.
+ Range(N) *note 3.6.2(8): 2063.
+ Read *note 13.13.2(6): 5793, *note 13.13.2(14): 5797.
+ Remainder *note A.5.3(45): 6707.
+ Result *note 6.1.1(29/3): 3605.
+ Round *note 3.5.10(12): 1983.
+ Rounding *note A.5.3(36): 6698.
+ Safe_First *note A.5.3(71): 6743, *note G.2.2(5): 8958.
+ Safe_Last *note A.5.3(72): 6745, *note G.2.2(6): 8960.
+ Scale *note 3.5.10(11): 1980.
+ Scaling *note A.5.3(27): 6689.
+ Signed_Zeros *note A.5.3(13): 6676.
+ Size *note 13.3(40): 5412, *note 13.3(45): 5419.
+ Small *note 3.5.10(2/1): 1965.
+ Storage_Pool *note 13.11(13): 5632.
+ Storage_Size *note 13.3(60/3): 5429, *note 13.11(14): 5634, *note
+J.9(2): 9144.
+ Stream_Size *note 13.13.2(1.2/3): 5786.
+ Succ *note 3.5(22): 1707.
+ Tag *note 3.9(16): 2250, *note 3.9(18): 2252.
+ Terminated *note 9.9(3): 4623.
+ Truncation *note A.5.3(42): 6705.
+ Unbiased_Rounding *note A.5.3(39): 6700.
+ Unchecked_Access *note 13.10(3): 5614, *note H.4(18): 9091.
+ Val *note 3.5.5(5): 1865.
+ Valid *note 13.9.2(3/3): 5610, *note H(6): 9049.
+ Value *note 3.5(52): 1755.
+ Version *note E.3(3): 8770.
+ Wide_Image *note 3.5(28): 1726.
+ Wide_Value *note 3.5(40): 1749.
+ Wide_Wide_Image *note 3.5(27.1/2): 1721.
+ Wide_Wide_Value *note 3.5(39.1/2): 1737.
+ Wide_Wide_Width *note 3.5(37.1/2): 1731.
+ Wide_Width *note 3.5(38): 1733.
+ Width *note 3.5(39): 1735.
+ Write *note 13.13.2(3): 5791, *note 13.13.2(11): 5795.
+available
+ stream attribute *note 13.13.2(39/2): 5828.
+avoid overspecifying environmental issues *note 10(3.a): 4637.
+
+
+\1f
+File: aarm2012.info, Node: B, Next: C, Prev: A, Up: Index
+
+B
+==
+
+
+
+Backus-Naur Form (BNF)
+ complete listing *note P: 9595.
+ cross reference *note P: 10475.
+ notation *note 1.1.4(3): 1080.
+ under Syntax heading *note 1.1.2(25): 1017.
+Barrier_Limit subtype of Positive
+ in Ada.Synchronous_Barriers *note D.10.1(4/3): 8568.
+base *note 2.4.2(3): 1283, *note 2.4.2(6): 1291.
+ used *note 2.4.2(2): 1279, *note P: 9619.
+base 16 literal *note 2.4.2(1): 1276.
+base 2 literal *note 2.4.2(1): 1270.
+base 8 literal *note 2.4.2(1): 1273.
+Base attribute *note 3.5(15): 1700.
+base decimal precision
+ of a floating point type *note 3.5.7(9): 1903.
+ of a floating point type *note 3.5.7(10): 1905.
+base priority *note D.1(15): 8331.
+base range
+ of a decimal fixed point type *note 3.5.9(16): 1952.
+ of a fixed point type *note 3.5.9(12): 1946.
+ of a floating point type *note 3.5.7(8): 1902, *note 3.5.7(10):
+1907.
+ of a modular type *note 3.5.4(10): 1828.
+ of a scalar type *note 3.5(6): 1682.
+ of a signed integer type *note 3.5.4(9): 1824.
+ of an enumeration type *note 3.5(6.b): 1683.
+ of an ordinary fixed point type *note 3.5.9(13): 1947.
+base subtype
+ of a type *note 3.5(15): 1701.
+Base_Name
+ in Ada.Directories *note A.16(19/2): 7151.
+based_literal *note 2.4.2(2): 1278.
+ used *note 2.4(2): 1254, *note P: 9610.
+based_numeral *note 2.4.2(4): 1285.
+ used *note 2.4.2(2): 1281, *note P: 9621.
+basic letter
+ a category of Character *note A.3.2(27): 5940.
+basic_declaration *note 3.1(3/3): 1344.
+ used *note 3.11(4/1): 2495, *note P: 9821.
+basic_declarative_item *note 3.11(4/1): 2494.
+ used *note 3.11(3): 2492, *note 7.1(3/3): 3831, *note P: 10115.
+Basic_Map
+ in Ada.Strings.Maps.Constants *note A.4.6(5): 6431.
+Basic_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6423.
+Beaujolais effect *note 8.4(1.b): 4054.
+ [partial] *note 3.6(18.b): 2026, *note 8.6(22.a): 4159, *note
+8.6(34.a): 4171, *note 8.6(34.k): 4173.
+become nonlimited *note 7.3.1(5/1): 3884, *note 7.5(16): 3913.
+BEL
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5956.
+belong
+ to a range *note 3.5(4): 1677.
+ to a subtype *note 3.2(8/2): 1417.
+belongs
+ subpool to a pool *note 13.11.4(20/3): 5712.
+bibliography *note 1.2(1/3): 1109.
+big endian *note 13.5.3(2): 5514.
+big-O notation *note A.18(3.b/2): 7221.
+binary
+ literal *note 2.4.2(1): 1271.
+ in Interfaces.COBOL *note B.4(10): 8109.
+binary adding operator *note 4.5.3(1): 3003.
+binary literal *note 2.4.2(1): 1269.
+binary operator *note 4.5(9): 2924.
+binary_adding_operator *note 4.5(4): 2918.
+ used *note 4.4(4): 2889, *note P: 9933.
+Binary_Format
+ in Interfaces.COBOL *note B.4(24): 8130.
+bit field
+ See record_representation_clause *note 13.5.1(1): 5478.
+bit ordering *note 13.5.3(2): 5512.
+bit string
+ See logical operators on boolean arrays *note 4.5.1(2): 2943.
+Bit_Order
+ in System *note 13.7(15/2): 5548.
+Bit_Order aspect *note 13.5.3(4): 5524.
+Bit_Order attribute *note 13.5.3(4): 5520.
+Bit_Order clause *note 13.3(7/2): 5375, *note 13.5.3(4): 5522.
+blank
+ in text input for enumeration and numeric types *note A.10.6(5/2):
+7020.
+Blank_When_Zero
+ in Ada.Text_IO.Editing *note F.3.3(7): 8845.
+block_statement *note 5.6(2): 3492.
+ used *note 5.1(5/2): 3361, *note P: 10005.
+blocked
+ [partial] *note D.2.1(11/3): 8352.
+ a task state *note 9(10): 4190.
+ during an entry call *note 9.5.3(19): 4425.
+ execution of a selective_accept *note 9.7.1(16): 4557.
+ on a delay_statement *note 9.6(21): 4476.
+ on an accept_statement *note 9.5.2(24): 4394.
+ waiting for activations to complete *note 9.2(5): 4248.
+ waiting for dependents to terminate *note 9.3(5): 4255.
+blocked interrupt *note C.3(2): 8197.
+blocking, potentially *note 9.5.1(8): 4345.
+ Abort_Task *note C.7.1(16): 8288.
+ delay_statement *note 9.6(34): 4479, *note D.9(5): 8551.
+ remote subprogram call *note E.4(17): 8792.
+ RPC operations *note E.5(23): 8821.
+ Suspend_Until_True *note D.10(10): 8563.
+BMP *note 3.5.2(2/3): 1787, *note 3.5.2(3/3): 1793.
+BNF (Backus-Naur Form)
+ complete listing *note P: 9594.
+ cross reference *note P: 10474.
+ notation *note 1.1.4(3): 1079.
+ under Syntax heading *note 1.1.2(25): 1016.
+body *note 3.11(5): 2498, *note 3.11.1(1/3): 2518.
+ used *note 3.11(3): 2493, *note P: 9820.
+body_stub *note 10.1.3(2): 4723.
+ used *note 3.11(5): 2500, *note P: 9825.
+Body_Version attribute *note E.3(4): 8773.
+BOM_16
+ in Ada.Strings.UTF_Encoding *note A.4.11(12/3): 6545.
+BOM_16BE
+ in Ada.Strings.UTF_Encoding *note A.4.11(10/3): 6543.
+BOM_16LE
+ in Ada.Strings.UTF_Encoding *note A.4.11(11/3): 6544.
+BOM_8
+ in Ada.Strings.UTF_Encoding *note A.4.11(9/3): 6542.
+Boolean *note 3.5.3(1): 1803.
+ in Standard *note A.1(5): 5879.
+boolean type *note 3.5.3(1): 1806.
+Bounded
+ child of Ada.Strings *note A.4.4(3): 6300.
+bounded error *note 1.1.2(31): 1038, *note 1.1.5(8): 1098.
+ cause *note 4.8(11.1/2): 3295, *note 6.2(12/3): 3636, *note
+7.6.1(14/1): 3975, *note 9.4(20.1/2): 4316, *note 9.5.1(8): 4343, *note
+9.8(20/3): 4613, *note 10.2(26): 4805, *note 13.9.1(9): 5603, *note
+13.11.2(11): 5675, *note A.17(25/2): 7213, *note A.18.2(238/3): 7321,
+*note A.18.2(239/2): 7322, *note A.18.2(243/2): 7325, *note
+A.18.3(152.1/3): 7397, *note A.18.3(152.2/3): 7398, *note A.18.3(152/2):
+7396, *note A.18.4(75.1/3): 7421, *note A.18.4(75.2/3): 7422, *note
+A.18.7(96.13/3): 7560, *note A.18.7(96.14/3): 7561, *note
+A.18.10(220/3): 7803, *note A.18.10(221/3): 7804, *note A.18.18(68/3):
+7846, *note A.18.18(69/3): 7847, *note A.18.19(10/3): 7850, *note
+A.18.20(14/3): 7854, *note A.18.21(15/3): 7859, *note A.18.22(12/3):
+7863, *note A.18.23(15/3): 7868, *note A.18.24(12/3): 7872, *note
+A.18.25(14/3): 7875, *note C.7.1(17/3): 8289, *note C.7.2(13.2/1): 8301,
+*note D.2.6(30/2): 8403, *note D.3(13.1/2): 8425, *note E.1(10/2): 8702,
+*note E.3(6): 8776, *note J.7.1(11): 9141.
+Bounded_IO
+ child of Ada.Text_IO *note A.10.11(3/2): 7030.
+ child of Ada.Wide_Text_IO *note A.11(4/3): 7056.
+ child of Ada.Wide_Wide_Text_IO *note A.11(4/3): 7057.
+Bounded_Priority_Queues
+ child of Ada.Containers *note A.18.31(2/3): 7916.
+Bounded_Slice
+ in Ada.Strings.Bounded *note A.4.4(28.1/2): 6321, *note
+A.4.4(28.2/2): 6322.
+Bounded_String
+ in Ada.Strings.Bounded *note A.4.4(6): 6303.
+Bounded_Synchronized_Queues
+ child of Ada.Containers *note A.18.29(2/3): 7901.
+bounds
+ of a discrete_range *note 3.6.1(6): 2046.
+ of an array *note 3.6(13): 2016.
+ of the index range of an array_aggregate *note 4.3.3(24): 2762.
+box
+ compound delimiter *note 3.6(15): 2021.
+BPH
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6049.
+broadcast signal
+ See protected object *note 9.4(1): 4263.
+ See requeue *note 9.5.4(1): 4430.
+Broken_Bar
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6086.
+BS
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5957.
+budget *note D.14.2(14/2): 8638.
+Budget_Has_Expired
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(9/2): 8631.
+Budget_Remaining
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(9/2): 8632.
+Buffer_Size
+ in Ada.Storage_IO *note A.9(4): 6840.
+Buffer_Type subtype of Storage_Array
+ in Ada.Storage_IO *note A.9(4): 6841.
+build-in-place
+ See built in place
+built in place *note 7.6(17.1/3): 3946.
+by copy parameter passing *note 6.2(2): 3622.
+by reference parameter passing *note 6.2(2): 3625.
+by-copy type *note 6.2(3/3): 3627.
+by-reference type *note 6.2(4): 3628.
+ atomic or volatile *note C.6(18): 8267.
+Byte
+ in Interfaces.COBOL *note B.4(29/3): 8137.
+ See storage element *note 13.3(8): 5387.
+byte sex
+ See ordering of storage elements in a word *note 13.5.3(5): 5525.
+Byte_Array
+ in Interfaces.COBOL *note B.4(29/3): 8138.
+
+
+\1f
+File: aarm2012.info, Node: C, Next: D, Prev: B, Up: Index
+
+C
+==
+
+
+
+C
+ child of Interfaces *note B.3(4): 7986.
+C interface *note B.3(1/3): 7985.
+C standard *note 1.2(7/3): 1135.
+C++ standard *note 1.2(9/3): 1141.
+C_float
+ in Interfaces.C *note B.3(15): 8002.
+Calendar
+ child of Ada *note 9.6(10): 4458.
+call *note 6(2/3): 3511.
+ master of *note 3.10.2(10.1/3): 2453.
+call on a dispatching operation *note 3.9.2(2/3): 2297.
+callable *note 9.9(2): 4622.
+Callable attribute *note 9.9(2): 4620.
+callable construct *note 6(2/3): 3512.
+callable entity *note 6(2/3): 3510.
+called partition *note E.4(1): 8782.
+Caller attribute *note C.7.1(14/3): 8285.
+calling convention *note 6.3.1(2/1): 3657, *note B.1(11/3): 7962.
+ Ada *note 6.3.1(3/3): 3659.
+ associated with a designated profile *note 3.10(11): 2407.
+ entry *note 6.3.1(13): 3665.
+ Intrinsic *note 6.3.1(4): 3661.
+ protected *note 6.3.1(12): 3663.
+calling partition *note E.4(1): 8781.
+calling stub *note E.4(10): 8787.
+CAN
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5973.
+Cancel_Handler
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(10/2): 8635.
+ in Ada.Execution_Time.Timers *note D.14.1(7/2): 8610.
+ in Ada.Real_Time.Timing_Events *note D.15(5/2): 8656.
+cancellation
+ of a delay_statement *note 9.6(22/3): 4477.
+ of an entry call *note 9.5.3(20): 4426.
+cancellation of a remote subprogram call *note E.4(13): 8790.
+canonical form *note A.5.3(3): 6659.
+canonical order of array components *note 5.5.2(11/3): 3487.
+canonical semantics *note 11.6(2/3): 5027.
+canonical-form representation *note A.5.3(10): 6671.
+capacity
+ of a hashed map *note A.18.5(41/2): 7471.
+ of a hashed set *note A.18.8(63/2): 7627.
+ of a queue *note A.18.27(10/3): 7892.
+ of a vector *note A.18.2(2/2): 7234.
+ in Ada.Containers.Hashed_Maps *note A.18.5(8/2): 7435.
+ in Ada.Containers.Hashed_Sets *note A.18.8(10/2): 7576.
+ in Ada.Containers.Vectors *note A.18.2(19/2): 7247.
+Capacity_Error
+ in Ada.Containers *note A.18.1(5.1/3): 7228.
+case insensitive *note 2.3(5/3): 1246.
+case_expression *note 4.5.7(5/3): 3093.
+ used *note 4.5.7(2/3): 3084, *note P: 9951.
+case_expression_alternative *note 4.5.7(6/3): 3097.
+ used *note 4.5.7(5/3): 3096, *note P: 9959.
+case_statement *note 5.4(2/3): 3404.
+ used *note 5.1(5/2): 3359, *note P: 10003.
+case_statement_alternative *note 5.4(3): 3408.
+ used *note 5.4(2/3): 3407, *note P: 10019.
+cast
+ See type conversion *note 4.6(1/3): 3128.
+ See unchecked type conversion *note 13.9(1): 5589.
+catch (an exception)
+ See handle *note 11(1/3): 4864.
+categorization aspect *note E.2(2/3): 8708.
+categorization pragma *note E.2(2/3): 8704.
+ Remote_Call_Interface *note E.2.3(2): 8745.
+ Remote_Types *note E.2.2(2): 8729.
+ Shared_Passive *note E.2.1(2): 8714.
+categorized library unit *note E.2(2/3): 8709.
+category
+ of types *note 3.2(2/2): 1389, *note 3.4(1.1/2): 1608.
+category (of types) *note N(4.3/2): 9521.
+category determined for a formal type *note 12.5(6/3): 5190.
+catenation operator
+ See concatenation operator *note 4.4(1/3): 2823.
+ See concatenation operator *note 4.5.3(3): 3019.
+Cause_Of_Termination
+ in Ada.Task_Termination *note C.7.3(3/2): 8306.
+CCH
+ in Ada.Characters.Latin_1 *note A.3.3(18): 6067.
+cease to exist
+ object *note 7.6.1(11/3): 3970, *note 13.11.2(10/2): 5674.
+ type *note 7.6.1(11/3): 3971.
+Cedilla
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6106.
+Ceiling
+ in Ada.Containers.Ordered_Maps *note A.18.6(41/2): 7530.
+ in Ada.Containers.Ordered_Sets *note A.18.9(51/2): 7691, *note
+A.18.9(71/2): 7704.
+Ceiling attribute *note A.5.3(33): 6697.
+ceiling priority
+ of a protected object *note D.3(8/3): 8421.
+Ceiling_Check
+ [partial] *note C.3.1(11/3): 8214, *note D.3(13): 8422.
+Ceiling_Locking locking policy *note D.3(7): 8420.
+Cent_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6082.
+change of representation *note 13.6(1/3): 5528.
+char
+ in Interfaces.C *note B.3(19): 8005.
+char16_array
+ in Interfaces.C *note B.3(39.5/3): 8029.
+char16_nul
+ in Interfaces.C *note B.3(39.3/2): 8026.
+char16_t
+ in Interfaces.C *note B.3(39.2/2): 8025.
+char32_array
+ in Interfaces.C *note B.3(39.14/3): 8039.
+char32_nul
+ in Interfaces.C *note B.3(39.12/2): 8036.
+char32_t
+ in Interfaces.C *note B.3(39.11/2): 8035.
+char_array
+ in Interfaces.C *note B.3(23/3): 8009.
+char_array_access
+ in Interfaces.C.Strings *note B.3.1(4): 8053.
+CHAR_BIT
+ in Interfaces.C *note B.3(6): 7987.
+Character *note 3.5.2(2/3): 1789.
+ used *note 2.7(2): 1302, *note P: 9631.
+ in Standard *note A.1(35/3): 5884.
+character encoding *note A.4.11(46/3): 6575.
+character plane *note 2.1(1/3): 1166.
+character set *note 2.1(1/3): 1164.
+character set standard
+ 16 and 32-bit *note 1.2(8/3): 1138.
+ 7-bit *note 1.2(2): 1115.
+ 8-bit *note 1.2(6/3): 1132.
+ control functions *note 1.2(5): 1127.
+character type *note 3.5.2(1): 1785, *note N(5): 9522.
+character_literal *note 2.5(2): 1292.
+ used *note 3.5.1(4): 1777, *note 4.1(2/3): 2531, *note 4.1.3(3):
+2589, *note P: 9718.
+Character_Mapping
+ in Ada.Strings.Maps *note A.4.2(20/2): 6251.
+Character_Mapping_Function
+ in Ada.Strings.Maps *note A.4.2(25): 6257.
+Character_Range
+ in Ada.Strings.Maps *note A.4.2(6): 6240.
+Character_Ranges
+ in Ada.Strings.Maps *note A.4.2(7): 6241.
+Character_Sequence subtype of String
+ in Ada.Strings.Maps *note A.4.2(16): 6247.
+Character_Set
+ in Ada.Strings.Maps *note A.4.2(4/2): 6238.
+ in Ada.Strings.Wide_Maps *note A.4.7(46/2): 6470.
+ in Ada.Strings.Wide_Maps.Wide_Constants *note A.4.8(48/2): 6513.
+ in Interfaces.Fortran *note B.5(11): 8170.
+Character_Set_Version
+ in Ada.Wide_Characters.Handling *note A.3.5(4/3): 6199.
+characteristics
+ [partial] *note 3.4(7/3): 1620.
+Characters
+ child of Ada *note A.3.1(2): 5903.
+chars_ptr
+ in Interfaces.C.Strings *note B.3.1(5/2): 8054.
+chars_ptr_array
+ in Interfaces.C.Strings *note B.3.1(6/2): 8055.
+check
+ language-defined *note 11.5(2/3): 4982, *note 11.6(1/3): 5022.
+check, language-defined
+ Access_Check *note 4.1(13): 2555, *note 4.1.5(8/3): 2630, *note
+4.6(51/3): 3212, *note 4.8(10.4/3): 3290.
+ Accessibility_Check *note 3.10.2(29): 2470, *note 4.6(39.1/2):
+3190, *note 4.6(48/3): 3204, *note 4.8(10.1/3): 3281, *note 6.5(8/3):
+3771, *note 6.5(21/3): 3777, *note 13.11.4(25/3): 5717, *note
+13.11.4(26/3): 5719, *note E.4(18/1): 8794.
+ Allocation_Check *note 4.8(10.2/2): 3284, *note 4.8(10.3/2): 3287,
+*note 4.8(10.4/3): 3292, *note 13.11.4(30/3): 5722.
+ Ceiling_Check *note C.3.1(11/3): 8215, *note D.3(13): 8423.
+ controlled by assertion policy *note 3.2.4(31/3): 1517, *note
+4.6(51/3): 3214, *note 6.1.1(32/3): 3608, *note 6.1.1(33/3): 3611, *note
+6.1.1(35/3): 3616, *note 7.3.2(9/3): 3898.
+ Discriminant_Check *note 4.1.3(15): 2596, *note 4.3(6): 2679, *note
+4.3.2(8/3): 2723, *note 4.6(43): 3196, *note 4.6(45): 3198, *note
+4.6(51/3): 3208, *note 4.6(52): 3221, *note 4.7(4): 3246, *note
+4.8(10/2): 3277, *note 6.5(5.11/3): 3765.
+ Division_Check *note 3.5.4(20): 1849, *note 4.5.5(22): 3056, *note
+A.5.1(28): 6616, *note A.5.3(47): 6711, *note G.1.1(40): 8889, *note
+G.1.2(28): 8917, *note K.2(202): 9312.
+ Elaboration_Check *note 3.11(9): 2510.
+ Index_Check *note 4.1.1(7): 2570, *note 4.1.2(7): 2580, *note
+4.3.3(29/3): 2766, *note 4.3.3(30): 2768, *note 4.5.3(8): 3022, *note
+4.6(51/3): 3210, *note 4.7(4): 3248, *note 4.8(10/2): 3275.
+ Length_Check *note 4.5.1(8): 2947, *note 4.6(37): 3185, *note
+4.6(52): 3217.
+ Overflow_Check *note 3.5.4(20): 1846, *note 4.4(11): 2911, *note
+4.5.7(21/3): 3107, *note 5.4(13): 3416, *note G.2.1(11): 8950, *note
+G.2.2(7): 8966, *note G.2.3(25): 8972, *note G.2.4(2): 8978, *note
+G.2.6(3): 8985.
+ Partition_Check *note E.4(19): 8797.
+ Range_Check *note 3.2.2(11): 1485, *note 3.5(24): 1713, *note
+3.5(27): 1720, *note 3.5(39.12/3): 1748, *note 3.5(39.4/3): 1742, *note
+3.5(39.5/3): 1745, *note 3.5(43/3): 1754, *note 3.5(55/3): 1760, *note
+3.5.5(7): 1870, *note 3.5.9(19): 1961, *note 4.2(11): 2663, *note
+4.3.3(28): 2764, *note 4.5.1(8): 2949, *note 4.5.6(6): 3070, *note
+4.5.6(13): 3079, *note 4.6(28): 3175, *note 4.6(38): 3187, *note
+4.6(46): 3200, *note 4.6(51/3): 3206, *note 4.7(4): 3244, *note
+13.13.2(35/3): 5808, *note A.5.2(39): 6651, *note A.5.3(26): 6688, *note
+A.5.3(29): 6693, *note A.5.3(50): 6716, *note A.5.3(53): 6721, *note
+A.5.3(59): 6726, *note A.5.3(62): 6731, *note K.2(11): 9284, *note
+K.2(114): 9299, *note K.2(122): 9302, *note K.2(184): 9307, *note
+K.2(220): 9316, *note K.2(241): 9319, *note K.2(41): 9289, *note
+K.2(47): 9292.
+ Reserved_Check *note C.3.1(10/3): 8211.
+ Storage_Check *note 11.1(6): 4881, *note 13.3(67): 5434, *note
+13.11(17): 5646, *note D.7(17/1): 8499, *note D.7(18/1): 8504, *note
+D.7(19/1): 8509.
+ Tag_Check *note 3.9.2(16): 2314, *note 4.6(42): 3194, *note
+4.6(52): 3219, *note 5.2(10): 3389, *note 6.5(8.1/3): 3773.
+checking pragmas *note 11.5(1/2): 4980.
+child
+ of a library unit *note 10.1.1(1): 4647.
+Child_Count
+ in Ada.Containers.Multiway_Trees *note A.18.10(46/3): 7771.
+Child_Depth
+ in Ada.Containers.Multiway_Trees *note A.18.10(47/3): 7772.
+choice
+ of an exception_handler *note 11.2(5.b/3): 4900.
+choice parameter *note 11.2(9): 4902.
+choice_expression *note 4.4(2.1/3): 2858.
+ used *note 3.8.1(5/3): 2195, *note 4.4(3.2/3): 2883, *note P: 9792.
+choice_parameter_specification *note 11.2(4): 4895.
+ used *note 11.2(3): 4891, *note P: 10325.
+choice_relation *note 4.4(2.2/3): 2869.
+ used *note 4.4(2.1/3): 2862, *note P: 9916.
+Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(12): 6008.
+class
+ of types *note 3.2(2/2): 1390, *note 3.4(1.1/2): 1607.
+ See also package *note 7(1): 3824.
+ See also tag *note 3.9(3): 2227.
+class (of types) *note N(6/2): 9523.
+Class attribute *note 3.9(14): 2247, *note 7.3.1(9): 3890, *note
+J.11(2/2): 9152.
+class factory *note 3.9(30/2): 2263.
+class-wide postcondition expression *note 6.1.1(5/3): 3592.
+class-wide precondition expression *note 6.1.1(3/3): 3584.
+class-wide type *note 3.4.1(4): 1647, *note 3.7(26): 2112.
+cleanup
+ See finalization *note 7.6.1(1): 3954.
+clear
+ execution timer object *note D.14.1(12/2): 8614.
+ group budget object *note D.14.2(15/2): 8642.
+ timing event object *note D.15(9/2): 8660.
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(13/2): 7346.
+ in Ada.Containers.Hashed_Maps *note A.18.5(12/2): 7439.
+ in Ada.Containers.Hashed_Sets *note A.18.8(14/2): 7580.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(11/3): 7829.
+ in Ada.Containers.Multiway_Trees *note A.18.10(23/3): 7748.
+ in Ada.Containers.Ordered_Maps *note A.18.6(11/2): 7493.
+ in Ada.Containers.Ordered_Sets *note A.18.9(13/2): 7654.
+ in Ada.Containers.Vectors *note A.18.2(24/2): 7252.
+ in Ada.Environment_Variables *note A.17(7/2): 7210.
+cleared
+ termination handler *note C.7.3(9/2): 8319.
+clock *note 9.6(6/3): 4457.
+ in Ada.Calendar *note 9.6(12): 4464.
+ in Ada.Execution_Time *note D.14(5/2): 8591.
+ in Ada.Execution_Time.Interrupts *note D.14.3(3/3): 8647.
+ in Ada.Real_Time *note D.8(6): 8532.
+clock jump *note D.8(32): 8547.
+clock tick *note D.8(23): 8546.
+Clock_For_Interrupts
+ in Ada.Execution_Time *note D.14(9.3/3): 8596.
+Close
+ in Ada.Direct_IO *note A.8.4(8): 6814.
+ in Ada.Sequential_IO *note A.8.1(8): 6786.
+ in Ada.Streams.Stream_IO *note A.12.1(10): 7073.
+ in Ada.Text_IO *note A.10.1(11): 6871.
+close result set *note G.2.3(5): 8970.
+closed entry *note 9.5.3(5): 4408.
+ of a protected object *note 9.5.3(7/3): 4413.
+ of a task *note 9.5.3(6/3): 4411.
+closed under derivation *note 3.2(2.b/2): 1397, *note 3.4(28): 1635,
+*note N(6/2): 9524.
+closure
+ downward *note 3.10.2(13.b/2): 2456, *note 3.10.2(37/2): 2483.
+COBOL
+ child of Interfaces *note B.4(7): 8106.
+COBOL interface *note B.4(1/3): 8105.
+COBOL standard *note 1.2(4/2): 1121.
+COBOL_Character
+ in Interfaces.COBOL *note B.4(13): 8115.
+COBOL_To_Ada
+ in Interfaces.COBOL *note B.4(15): 8117.
+code point
+ for characters *note 3.5.2(2/3): 1791, *note 3.5.2(11.p/3): 1802.
+code_statement *note 13.8(2): 5577.
+ used *note 5.1(4/2): 3356, *note P: 10001.
+Coding aspect *note 13.4(7): 5466.
+coextension
+ of an object *note 3.10.2(14.4/3): 2458.
+Col
+ in Ada.Text_IO *note A.10.1(37): 6923.
+collection
+ of an access type *note 7.6.1(11.1/3): 3972.
+colon *note 2.1(15/3): 1206.
+ in Ada.Characters.Latin_1 *note A.3.3(10): 5998.
+column number *note A.10(9): 6853.
+comma *note 2.1(15/3): 1198.
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5993.
+Command_Line
+ child of Ada *note A.15(3): 7127.
+Command_Name
+ in Ada.Command_Line *note A.15(6): 7130.
+comment *note 2.7(2): 1301.
+comments, instructions for submission *note 0.2(58/1): 1002.
+Commercial_At
+ in Ada.Characters.Latin_1 *note A.3.3(10): 6004.
+Communication_Error
+ in System.RPC *note E.5(5): 8810.
+comparison operator
+ See relational operator *note 4.5.2(1): 2953.
+compatibility
+ composite_constraint with an access subtype *note 3.10(15/2): 2416.
+ constraint with a subtype *note 3.2.2(12): 1486.
+ delta_constraint with an ordinary fixed point subtype *note J.3(9):
+9125.
+ digits_constraint with a decimal fixed point subtype *note
+3.5.9(18): 1958.
+ digits_constraint with a floating point subtype *note J.3(10):
+9126.
+ discriminant constraint with a subtype *note 3.7.1(10): 2132.
+ index constraint with a subtype *note 3.6.1(7): 2047.
+ range with a scalar subtype *note 3.5(8): 1687.
+ range_constraint with a scalar subtype *note 3.5(8): 1688.
+compatible
+ a type, with a convention *note B.1(12): 7963.
+compilation *note 10.1.1(2): 4648.
+ separate *note 10.1(1): 4642.
+Compilation unit *note 10.1(2): 4644, *note 10.1.1(9): 4678, *note
+N(7): 9525.
+compilation units needed
+ by a compilation unit *note 10.2(2): 4789.
+ remote call interface *note E.2.3(18): 8764.
+ shared passive library unit *note E.2.1(11): 8725.
+compilation_unit *note 10.1.1(3): 4650.
+ used *note 10.1.1(2): 4649, *note P: 10278.
+compile-time error *note 1.1.2(27): 1022, *note 1.1.5(4): 1092.
+compile-time semantics *note 1.1.2(28): 1027.
+complete context *note 8.6(4): 4143.
+completely defined *note 3.11.1(8): 2521.
+completion
+ abnormal *note 7.6.1(2/2): 3961.
+ compile-time concept *note 3.11.1(1/3): 2517.
+ normal *note 7.6.1(2/2): 3959.
+ run-time concept *note 7.6.1(2/2): 3957.
+completion and leaving (completed and left) *note 7.6.1(2/2): 3956.
+completion legality
+ [partial] *note 3.10.1(13): 2434.
+ entry_body *note 9.5.2(16): 4382.
+Complex
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(3): 8867.
+ in Interfaces.Fortran *note B.5(9): 8166.
+Complex_Arrays
+ child of Ada.Numerics *note G.3.2(53/2): 9041.
+Complex_Elementary_Functions
+ child of Ada.Numerics *note G.1.2(9/1): 8915.
+Complex_IO
+ child of Ada.Text_IO *note G.1.3(3): 8923.
+ child of Ada.Wide_Text_IO *note G.1.4(1): 8936.
+ child of Ada.Wide_Wide_Text_IO *note G.1.5(1/2): 8938.
+Complex_Matrix
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(4/2): 9007.
+Complex_Text_IO
+ child of Ada *note G.1.3(9.1/2): 8933.
+Complex_Types
+ child of Ada.Numerics *note G.1.1(25/1): 8887.
+Complex_Vector
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(4/2): 9006.
+component *note 3.2(2/2): 1395.
+ of a type *note 3.2(6/2): 1409.
+component subtype *note 3.6(10): 2011.
+component_choice_list *note 4.3.1(5): 2693.
+ used *note 4.3.1(4/2): 2692, *note P: 9874.
+component_clause *note 13.5.1(3): 5483.
+ used *note 13.5.1(2): 5482, *note P: 10451.
+component_declaration *note 3.8(6/3): 2157.
+ used *note 3.8(5/1): 2155, *note 9.4(6): 4285, *note P: 9779.
+component_definition *note 3.6(7/2): 2004.
+ used *note 3.6(3): 1994, *note 3.6(5): 2000, *note 3.8(6/3): 2159,
+*note P: 9743.
+component_item *note 3.8(5/1): 2154.
+ used *note 3.8(4): 2152, *note P: 9777.
+component_list *note 3.8(4): 2149.
+ used *note 3.8(3): 2148, *note 3.8.1(3): 2190, *note P: 9774.
+Component_Size aspect *note 13.3(70): 5441.
+Component_Size attribute *note 13.3(69): 5437.
+Component_Size clause *note 13.3(7/2): 5372, *note 13.3(70): 5439.
+components
+ of a record type *note 3.8(9/2): 2163.
+Compose
+ in Ada.Directories *note A.16(20/2): 7152.
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(14/3):
+7202.
+Compose attribute *note A.5.3(24): 6685.
+Compose_From_Cartesian
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(9/2): 9013,
+*note G.3.2(29/2): 9025.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(8): 8878.
+Compose_From_Polar
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(11/2): 9018,
+*note G.3.2(32/2): 9030.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(11): 8883.
+composite type *note 3.2(2/2): 1394, *note N(8/2): 9526.
+composite_constraint *note 3.2.2(7): 1478.
+ used *note 3.2.2(5): 1473, *note P: 9683.
+compound delimiter *note 2.2(10): 1228.
+compound_statement *note 5.1(5/2): 3357.
+ used *note 5.1(3): 3343, *note P: 9989.
+concatenation operator *note 4.4(1/3): 2821, *note 4.5.3(3): 3017.
+concrete subprogram
+ See nonabstract subprogram *note 3.9.3(1/2): 2325.
+concrete type
+ See nonabstract type *note 3.9.3(1/2): 2323.
+concurrent processing
+ See task *note 9(1/3): 4183.
+condition *note 4.5.7(4/3): 3091.
+ used *note 4.5.7(3/3): 3086, *note 5.3(2): 3398, *note 5.5(3/3):
+3426, *note 5.7(2): 3500, *note 9.5.2(7): 4372, *note 9.7.1(3): 4541,
+*note P: 10253.
+ See also exception *note 11(1/3): 4861.
+conditional_entry_call *note 9.7.3(2): 4571.
+ used *note 9.7(2): 4530, *note P: 10246.
+conditional_expression *note 4.5.7(2/3): 3082.
+ used *note 4.4(7/3): 2907, *note P: 9948.
+configuration
+ of the partitions of a program *note E(4): 8691.
+configuration pragma *note 10.1.5(8): 4767.
+ Assertion_Policy *note 11.4.2(7/3): 4969.
+ Detect_Blocking *note H.5(4/2): 9109.
+ Discard_Names *note C.5(4): 8245.
+ Locking_Policy *note D.3(5): 8413.
+ Normalize_Scalars *note H.1(4): 9054.
+ Partition_Elaboration_Policy *note H.6(5/2): 9115.
+ Priority_Specific_Dispatching *note D.2.2(5/2): 8364.
+ Profile *note 13.12(14/3): 5746.
+ Queuing_Policy *note D.4(5): 8435.
+ Restrictions *note 13.12(8/3): 5740.
+ Reviewable *note H.3.1(4): 9059.
+ Suppress *note 11.5(5/2): 4993.
+ Task_Dispatching_Policy *note D.2.2(5/2): 8362.
+ Unsuppress *note 11.5(5/2): 4995.
+confirming
+ aspect specification *note 13.1(18.2/3): 5314.
+ representation item *note 13.1(18.2/3): 5312.
+ representation value *note 13.1(18.2/3): 5313.
+conformance *note 6.3.1(1): 3651.
+ of an implementation with the Standard *note 1.1.3(1): 1064.
+ See also full conformance, mode conformance, subtype conformance,
+type conformance
+Conjugate
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(13/2): 9019,
+*note G.3.2(34/2): 9032.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(12): 8885, *note
+G.1.1(15): 8886.
+consistency
+ among compilation units *note 10.1.4(5): 4756.
+constant *note 3.3(13/3): 1523.
+ result of a function_call *note 6.4(12/2): 3712.
+ See also literal *note 4.2(1): 2650.
+ See also static *note 4.9(1): 3305.
+constant indexing *note 4.1.6(12/3): 2644.
+constant object *note 3.3(13/3): 1525.
+constant view *note 3.3(13/3): 1527.
+Constant_Indexing aspect *note 4.1.6(2/3): 2634.
+Constant_Reference
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(17.3/3): 7352.
+ in Ada.Containers.Hashed_Maps *note A.18.5(17.3/3): 7446, *note
+A.18.5(17.5/3): 7448.
+ in Ada.Containers.Hashed_Sets *note A.18.8(17.2/3): 7584, *note
+A.18.8(58.3/3): 7625.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(18/3): 7836.
+ in Ada.Containers.Multiway_Trees *note A.18.10(30/3): 7755.
+ in Ada.Containers.Ordered_Maps *note A.18.6(16.3/3): 7500, *note
+A.18.6(16.5/3): 7502.
+ in Ada.Containers.Ordered_Sets *note A.18.9(16.2/3): 7658, *note
+A.18.9(73.3/3): 7709.
+ in Ada.Containers.Vectors *note A.18.2(34.3/3): 7264, *note
+A.18.2(34.5/3): 7266.
+Constant_Reference_Type
+ in Ada.Containers.Indefinite_Holders *note A.18.18(16/3): 7834.
+ in Ada.Containers.Multiway_Trees *note A.18.10(28/3): 7753.
+Constants
+ child of Ada.Strings.Maps *note A.4.6(3/2): 6417.
+constituent
+ of a construct *note 1.1.4(17): 1088.
+constrained *note 3.2(9): 1420.
+ known to be *note 3.3(23.1/3): 1538.
+ object *note 3.3.1(9/2): 1577.
+ object *note 6.4.1(16): 3727.
+ subtype *note 3.2(9): 1422, *note 3.4(6): 1617, *note 3.5(7): 1684,
+*note 3.5.1(10): 1782, *note 3.5.4(9): 1825, *note 3.5.4(10): 1829,
+*note 3.5.7(11): 1908, *note 3.5.9(13): 1948, *note 3.5.9(16): 1953,
+*note 3.6(15): 2019, *note 3.6(16): 2022, *note 3.7(26): 2108, *note
+3.9(15): 2249.
+ subtype *note 3.10(14/3): 2414.
+ subtype *note K.2(33): 9286.
+Constrained attribute *note 3.7.2(3/3): 2139, *note J.4(2): 9129.
+constrained by its initial value *note 3.3.1(9/2): 1574.
+ [partial] *note 4.8(6/3): 3267, *note 6.5(5.11/3): 3762.
+constrained_array_definition *note 3.6(5): 1997.
+ used *note 3.6(2): 1990, *note P: 9740.
+constraint *note 3.2.2(5): 1471.
+ [partial] *note 3.2(7/2): 1410.
+ of a first array subtype *note 3.6(16): 2024.
+ of a subtype *note 3.2(8/2): 1415.
+ of an object *note 3.3.1(9/2): 1573.
+ used *note 3.2.2(3/2): 1468, *note P: 9680.
+Constraint_Error
+ raised by failure of run-time check *note 1.1.5(12.b): 1107, *note
+3.2.2(12): 1487, *note 3.5(24): 1709, *note 3.5(27): 1716, *note
+3.5(39.12/3): 1746, *note 3.5(39.4/3): 1740, *note 3.5(39.5/3): 1743,
+*note 3.5(43/3): 1752, *note 3.5(55/3): 1758, *note 3.5.4(20): 1847,
+*note 3.5.5(7): 1868, *note 3.5.9(19): 1962, *note 3.9.2(16): 2315,
+*note 4.1(13): 2556, *note 4.1.1(7): 2571, *note 4.1.2(7): 2582, *note
+4.1.3(15): 2598, *note 4.1.5(8/3): 2631, *note 4.2(11): 2664, *note
+4.3(6): 2680, *note 4.3.2(8/3): 2724, *note 4.3.3(31): 2769, *note
+4.4(11): 2912, *note 4.5(10): 2928, *note 4.5(11): 2929, *note 4.5(12):
+2930, *note 4.5.1(8): 2950, *note 4.5.3(8): 3023, *note 4.5.5(22): 3057,
+*note 4.5.6(6): 3071, *note 4.5.6(12): 3077, *note 4.5.6(13): 3080,
+*note 4.5.7(21/3): 3108, *note 4.6(28): 3176, *note 4.6(57/3): 3225,
+*note 4.6(60): 3229, *note 4.7(4): 3250, *note 4.8(10.4/3): 3293, *note
+4.8(10/2): 3278, *note 5.2(10): 3390, *note 5.4(13): 3417, *note
+6.5(5.11/3): 3763, *note 6.5(8.1/3): 3774, *note 11.1(4): 4875, *note
+11.4.1(14/2): 4949, *note 11.5(10): 4999, *note 13.9.1(9): 5605, *note
+13.13.2(35/3): 5809, *note A.4.3(109): 6297, *note A.4.7(47): 6471,
+*note A.4.8(51/2): 6515, *note A.5.1(28): 6617, *note A.5.1(34): 6618,
+*note A.5.2(39): 6652, *note A.5.2(40.1/1): 6654, *note A.5.3(26): 6686,
+*note A.5.3(29): 6691, *note A.5.3(47): 6709, *note A.5.3(50): 6714,
+*note A.5.3(53): 6719, *note A.5.3(59): 6724, *note A.5.3(62): 6729,
+*note A.15(14): 7135, *note B.3(53): 8047, *note B.3(54): 8048, *note
+B.4(58): 8157, *note E.4(19): 8798, *note E.4(20.u): 8799, *note
+E.4(20.v): 8800, *note G.1.1(40): 8890, *note G.1.2(28): 8918, *note
+G.2.1(12): 8951, *note G.2.2(7): 8962, *note G.2.3(26): 8973, *note
+G.2.4(3): 8979, *note G.2.6(4): 8986, *note K.2(11): 9282, *note
+K.2(114): 9297, *note K.2(122): 9300, *note K.2(184): 9305, *note
+K.2(202): 9310, *note K.2(220): 9314, *note K.2(241): 9317, *note
+K.2(261): 9323, *note K.2(41): 9287, *note K.2(47): 9290.
+ in Standard *note A.1(46): 5893.
+Construct *note 1.1.4(16): 1087, *note N(9): 9527.
+constructor
+ See initialization *note 3.3.1(18/2): 1587.
+ See initialization *note 7.6(1): 3920.
+ See initialization expression *note 3.3.1(4): 1568.
+ See Initialize *note 7.6(1): 3921.
+ See initialized allocator *note 4.8(4): 3265.
+container *note N(9.1/3): 9528.
+ cursor *note A.18(2/2): 7218.
+ list *note A.18.3(1/2): 7334.
+ map *note A.18.4(1/2): 7408.
+ set *note A.18.7(1/2): 7545.
+ vector *note A.18.2(1/2): 7232.
+container element iterator *note 5.5.2(3/3): 3478.
+Containers
+ child of Ada *note A.18.1(3/2): 7225.
+Containing_Directory
+ in Ada.Directories *note A.16(17/2): 7149.
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(11/3):
+7199.
+Contains
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(43/2): 7381.
+ in Ada.Containers.Hashed_Maps *note A.18.5(32/2): 7466.
+ in Ada.Containers.Hashed_Sets *note A.18.8(44/2): 7609, *note
+A.18.8(57/2): 7621.
+ in Ada.Containers.Multiway_Trees *note A.18.10(41/3): 7766.
+ in Ada.Containers.Ordered_Maps *note A.18.6(42/2): 7531.
+ in Ada.Containers.Ordered_Sets *note A.18.9(52/2): 7692, *note
+A.18.9(72/2): 7705.
+ in Ada.Containers.Vectors *note A.18.2(71/2): 7306.
+context free grammar
+ complete listing *note P: 9593.
+ cross reference *note P: 10473.
+ notation *note 1.1.4(3): 1078.
+ under Syntax heading *note 1.1.2(25): 1015.
+context_clause *note 10.1.2(2): 4698.
+ used *note 10.1.1(3): 4651, *note P: 10281.
+context_item *note 10.1.2(3): 4700.
+ used *note 10.1.2(2): 4699, *note P: 10296.
+contiguous representation
+ [partial] *note 13.1(7.a/2): 5295, *note 13.5.2(5): 5509, *note
+13.7.1(12): 5568, *note 13.9(9): 5591, *note 13.9(17/3): 5594, *note
+13.11(17.d): 5648, *note 13.11(21.6/3): 5654.
+Continue
+ in Ada.Asynchronous_Task_Control *note D.11(3/2): 8574.
+contract model of generics *note 12.3(1.a/3): 5070.
+control character
+ a category of Character *note A.3.2(22): 5935.
+ a category of Character *note A.3.3(4): 5948, *note A.3.3(15):
+6042.
+ See also format_effector *note 2.1(13/3): 1183.
+Control_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6418.
+Controlled
+ in Ada.Finalization *note 7.6(5/2): 3928.
+controlled type *note 7.6(2): 3923, *note 7.6(9/2): 3935, *note N(10):
+9529.
+controlling access result *note 3.9.2(2/3): 2303.
+controlling formal parameter *note 3.9.2(2/3): 2300.
+controlling operand *note 3.9.2(2/3): 2299.
+controlling result *note 3.9.2(2/3): 2301.
+controlling tag
+ for a call on a dispatching operation *note 3.9.2(1/2): 2291.
+controlling tag value *note 3.9.2(14): 2311.
+ for the expression in an assignment_statement *note 5.2(9): 3387.
+controlling type
+ of a formal_abstract_subprogram_declaration *note 12.6(8.4/3):
+5249.
+convention *note 6.3.1(2/1): 3656, *note B.1(11/3): 7961.
+Convention aspect *note B.1(2/3): 7955.
+Convention pragma *note J.15.5(4/3): 9206, *note L(8.1/3): 9358.
+conversion *note 4.6(1/3): 3127, *note 4.6(28): 3173.
+ access *note 4.6(24.11/2): 3158, *note 4.6(24.18/2): 3164, *note
+4.6(24.19/2): 3166, *note 4.6(47): 3202.
+ arbitrary order *note 1.1.4(18): 1091.
+ array *note 4.6(24.2/2): 3153, *note 4.6(36): 3183.
+ composite (non-array) *note 4.6(21/3): 3147, *note 4.6(40): 3192.
+ enumeration *note 4.6(21.1/2): 3149, *note 4.6(34): 3181.
+ numeric *note 4.6(24.1/2): 3151, *note 4.6(29): 3178.
+ unchecked *note 13.9(1): 5587.
+ value *note 4.6(5/2): 3143.
+ view *note 4.6(5/2): 3141.
+Conversion_Error
+ in Interfaces.COBOL *note B.4(30): 8139.
+Conversions
+ child of Ada.Characters *note A.3.4(2/2): 6178.
+ child of Ada.Strings.UTF_Encoding *note A.4.11(15/3): 6547.
+Convert
+ in Ada.Strings.UTF_Encoding.Conversions *note A.4.11(16/3): 6548,
+*note A.4.11(17/3): 6549, *note A.4.11(18/3): 6550, *note A.4.11(19/3):
+6551, *note A.4.11(20/3): 6552.
+convertible *note 4.6(4/3): 3139.
+ required *note 4.6(24.13/2): 3159, *note 4.6(24.4/2): 3154, *note
+8.6(27.1/3): 4165.
+Copy
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(17.6/3): 7355.
+ in Ada.Containers.Hashed_Maps *note A.18.5(17.8/3): 7451.
+ in Ada.Containers.Hashed_Sets *note A.18.8(17.4/3): 7586.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(21/3): 7839,
+*note A.18.20(10/3): 7853, *note A.18.21(13/3): 7858, *note
+A.18.22(10/3): 7862, *note A.18.23(13/3): 7867, *note A.18.24(10/3):
+7871.
+ in Ada.Containers.Multiway_Trees *note A.18.10(33/3): 7758.
+ in Ada.Containers.Ordered_Maps *note A.18.6(16.8/3): 7505.
+ in Ada.Containers.Ordered_Sets *note A.18.9(16.4/3): 7660.
+ in Ada.Containers.Vectors *note A.18.2(34.8/3): 7269.
+copy back of parameters *note 6.4.1(17): 3730.
+copy parameter passing *note 6.2(2): 3623.
+Copy_Array
+ in Interfaces.C.Pointers *note B.3.2(15): 8085.
+Copy_File
+ in Ada.Directories *note A.16(13/2): 7146.
+Copy_Sign attribute *note A.5.3(51): 6718.
+Copy_Subtree
+ in Ada.Containers.Multiway_Trees *note A.18.10(54/3): 7779.
+Copy_Terminated_Array
+ in Interfaces.C.Pointers *note B.3.2(14): 8084.
+Copyright_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6089.
+core language *note 1.1.2(2): 1004.
+Correction *note 1.1.2(39.aa/3): 1060.
+corresponding constraint *note 3.4(6): 1619.
+corresponding discriminants *note 3.7(18): 2102.
+corresponding index
+ for an array_aggregate *note 4.3.3(8): 2755.
+corresponding subtype *note 3.4(18/3): 1629.
+corresponding value
+ of the target type of a conversion *note 4.6(28): 3172.
+Corrigendum *note 1.1.2(39.n/3): 1054.
+Cos
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(4): 8900.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(5): 6593.
+Cosh
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(6): 8908.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6607.
+Cot
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(4): 8902.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(5): 6597.
+Coth
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(6): 8910.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6609.
+Count
+ in Ada.Direct_IO *note A.8.4(4): 6810.
+ in Ada.Streams.Stream_IO *note A.12.1(7): 7069.
+ in Ada.Strings.Bounded *note A.4.4(48): 6331, *note A.4.4(49):
+6332, *note A.4.4(50): 6333.
+ in Ada.Strings.Fixed *note A.4.3(13): 6272, *note A.4.3(14): 6273,
+*note A.4.3(15): 6274.
+ in Ada.Strings.Unbounded *note A.4.5(43): 6388, *note A.4.5(44):
+6389, *note A.4.5(45): 6390.
+ in Ada.Text_IO *note A.10.1(5): 6863.
+Count attribute *note 9.9(5): 4626.
+Count_Type
+ in Ada.Containers *note A.18.1(5/2): 7227.
+Country
+ in Ada.Locales *note A.19(6/3): 7931.
+Country code standard *note 1.2(4.1/3): 1124.
+Country_Code
+ in Ada.Locales *note A.19(4/3): 7927.
+Country_Unknown
+ in Ada.Locales *note A.19(5/3): 7929.
+cover
+ a type *note 3.4.1(9): 1656.
+ of a choice and an exception *note 11.2(6): 4901.
+cover a value *note 3.8.1(1.a): 2183.
+ by a discrete_choice *note 3.8.1(9): 2200.
+ by a discrete_choice_list *note 3.8.1(13): 2201.
+CPU aspect *note D.16(8/3): 8669.
+CPU clock tick *note D.14(15/2): 8599.
+CPU pragma *note J.15.9(2/3): 9258, *note L(8.2/3): 9362.
+CPU subtype of CPU_Range
+ in System.Multiprocessors *note D.16(4/3): 8666.
+CPU time
+ of a task *note D.14(11/3): 8598.
+CPU_Range
+ in System.Multiprocessors *note D.16(4/3): 8664.
+CPU_Tick
+ in Ada.Execution_Time *note D.14(4/2): 8590.
+CPU_Time
+ in Ada.Execution_Time *note D.14(4/2): 8586.
+CPU_Time_First
+ in Ada.Execution_Time *note D.14(4/2): 8587.
+CPU_Time_Last
+ in Ada.Execution_Time *note D.14(4/2): 8588.
+CPU_Time_Unit
+ in Ada.Execution_Time *note D.14(4/2): 8589.
+CR
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5962.
+create *note 3.1(12): 1384.
+ in Ada.Direct_IO *note A.8.4(6): 6812.
+ in Ada.Sequential_IO *note A.8.1(6): 6784.
+ in Ada.Streams.Stream_IO *note A.12.1(8): 7071.
+ in Ada.Text_IO *note A.10.1(9): 6869.
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(7/3):
+8675.
+Create_Directory
+ in Ada.Directories *note A.16(7/2): 7140.
+Create_Path
+ in Ada.Directories *note A.16(9/2): 7142.
+Create_Subpool
+ in System.Storage_Pools.Subpools *note 13.11.4(7/3): 5698.
+creation
+ of a protected object *note C.3.1(10/3): 8208.
+ of a return object *note 6.5(5.11/3): 3761.
+ of a tag *note 13.14(20/2): 5868.
+ of a task object *note D.1(17/3): 8333.
+ of an object *note 3.3(1): 1521.
+critical section
+ See intertask communication *note 9.5(1): 4322.
+CSI
+ in Ada.Characters.Latin_1 *note A.3.3(19): 6074.
+Currency_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6084.
+current column number *note A.10(9): 6854.
+current index
+ of an open direct file *note A.8(4): 6780.
+ of an open stream file *note A.12.1(1.1/1): 7063.
+current instance
+ of a generic unit *note 8.6(18): 4153.
+ of a type *note 8.6(17/3): 4152.
+current line number *note A.10(9): 6855.
+current mode
+ of an open file *note A.7(7): 6770.
+current page number *note A.10(9): 6856.
+Current size
+ of a stream file *note A.12.1(1.1/1): 7064.
+ of an external file *note A.8(3): 6779.
+Current_Directory
+ in Ada.Directories *note A.16(5/2): 7138.
+Current_Error
+ in Ada.Text_IO *note A.10.1(17): 6887, *note A.10.1(20): 6894.
+Current_Handler
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(10/2): 8634.
+ in Ada.Execution_Time.Timers *note D.14.1(7/2): 8609.
+ in Ada.Interrupts *note C.3.2(6): 8229.
+ in Ada.Real_Time.Timing_Events *note D.15(5/2): 8655.
+Current_Input
+ in Ada.Text_IO *note A.10.1(17): 6885, *note A.10.1(20): 6892.
+Current_Output
+ in Ada.Text_IO *note A.10.1(17): 6886, *note A.10.1(20): 6893.
+Current_State
+ in Ada.Synchronous_Task_Control *note D.10(4): 8558.
+Current_Task
+ in Ada.Task_Identification *note C.7.1(3/3): 8276.
+Current_Task_Fallback_Handler
+ in Ada.Task_Termination *note C.7.3(5/2): 8309.
+Current_Use
+ in Ada.Containers.Bounded_Priority_Queues *note A.18.31(7/3): 7921.
+ in Ada.Containers.Bounded_Synchronized_Queues *note A.18.29(6/3):
+7905.
+ in Ada.Containers.Synchronized_Queue_Interfaces *note A.18.27(7/3):
+7890.
+ in Ada.Containers.Unbounded_Priority_Queues *note A.18.30(7/3):
+7913.
+ in Ada.Containers.Unbounded_Synchronized_Queues *note A.18.28(6/3):
+7898.
+cursor
+ ambiguous *note A.18.2(240/2): 7324.
+ for a container *note A.18(2/2): 7217.
+ invalid *note A.18.2(248/2): 7327, *note A.18.3(153/2): 7400, *note
+A.18.4(76/2): 7424, *note A.18.7(97/2): 7563, *note A.18.10(222/3):
+7806.
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(7/2): 7339.
+ in Ada.Containers.Hashed_Maps *note A.18.5(4/2): 7430.
+ in Ada.Containers.Hashed_Sets *note A.18.8(4/2): 7569.
+ in Ada.Containers.Multiway_Trees *note A.18.10(9/3): 7735.
+ in Ada.Containers.Ordered_Maps *note A.18.6(5/2): 7486.
+ in Ada.Containers.Ordered_Sets *note A.18.9(5/2): 7645.
+ in Ada.Containers.Vectors *note A.18.2(9/2): 7240.
+
+
+\1f
+File: aarm2012.info, Node: D, Next: E, Prev: C, Up: Index
+
+D
+==
+
+
+
+dangling references
+ prevention via accessibility rules *note 3.10.2(3/2): 2446.
+Data_Error
+ in Ada.Direct_IO *note A.8.4(18): 6836.
+ in Ada.IO_Exceptions *note A.13(4): 7121.
+ in Ada.Sequential_IO *note A.8.1(15): 6803.
+ in Ada.Storage_IO *note A.9(9): 6844.
+ in Ada.Streams.Stream_IO *note A.12.1(26): 7098.
+ in Ada.Text_IO *note A.10.1(85): 7012.
+date and time formatting standard *note 1.2(5.1/2): 1129.
+Day
+ in Ada.Calendar *note 9.6(13): 4467.
+ in Ada.Calendar.Formatting *note 9.6.1(23/2): 4509.
+Day_Count
+ in Ada.Calendar.Arithmetic *note 9.6.1(10/2): 4490.
+Day_Duration subtype of Duration
+ in Ada.Calendar *note 9.6(11/2): 4463.
+Day_Name
+ in Ada.Calendar.Formatting *note 9.6.1(17/2): 4494.
+Day_Number subtype of Integer
+ in Ada.Calendar *note 9.6(11/2): 4462.
+Day_of_Week
+ in Ada.Calendar.Formatting *note 9.6.1(18/2): 4502.
+DC1
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5966.
+DC2
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5967.
+DC3
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5968.
+DC4
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5969.
+DCS
+ in Ada.Characters.Latin_1 *note A.3.3(18): 6063.
+Deadline subtype of Time
+ in Ada.Dispatching.EDF *note D.2.6(9/2): 8396.
+Deallocate
+ in System.Storage_Pools *note 13.11(8): 5625.
+ in System.Storage_Pools.Subpools *note 13.11.4(15/3): 5705.
+Deallocate_Subpool
+ in System.Storage_Pools.Subpools *note 13.11.4(12/3): 5702.
+deallocation of storage *note 13.11.2(1): 5666.
+Decimal
+ child of Ada *note F.2(2): 8829.
+decimal digit
+ a category of Character *note A.3.2(28): 5941.
+decimal fixed point type *note 3.5.9(1): 1924, *note 3.5.9(6): 1942.
+Decimal_Conversions
+ in Interfaces.COBOL *note B.4(31): 8140.
+Decimal_Digit_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6424.
+Decimal_Element
+ in Interfaces.COBOL *note B.4(12/3): 8113.
+decimal_fixed_point_definition *note 3.5.9(4): 1932.
+ used *note 3.5.9(2): 1928, *note P: 9731.
+Decimal_IO
+ in Ada.Text_IO *note A.10.1(73): 6987.
+decimal_literal *note 2.4.1(2): 1256.
+ used *note 2.4(2): 1253, *note P: 9609.
+Decimal_Output
+ in Ada.Text_IO.Editing *note F.3.3(11): 8852.
+Declaration *note 3.1(5): 1360, *note 3.1(6/3): 1363, *note N(11):
+9530.
+declaration list
+ declarative_part *note 3.11(6.1/2): 2506.
+ package_specification *note 7.1(6/2): 3838.
+declarative region
+ of a construct *note 8.1(1): 3988.
+declarative_item *note 3.11(3): 2491.
+ used *note 3.11(2): 2490, *note P: 9818.
+declarative_part *note 3.11(2): 2489.
+ used *note 5.6(2): 3494, *note 6.3(2/3): 3643, *note 7.2(2/3):
+3845, *note 9.1(6/3): 4220, *note 9.5.2(5): 4365, *note P: 10229.
+declare *note 3.1(8): 1372, *note 3.1(12): 1383.
+declared pure *note 10.2.1(17/3): 4834.
+Decode
+ in Ada.Strings.UTF_Encoding.Strings *note A.4.11(26/3): 6557, *note
+A.4.11(27/3): 6558, *note A.4.11(28/3): 6559.
+ in Ada.Strings.UTF_Encoding.Wide_Strings *note A.4.11(34/3): 6564,
+*note A.4.11(35/3): 6565, *note A.4.11(36/3): 6566.
+ in Ada.Strings.UTF_Encoding.Wide_Wide_Strings *note A.4.11(42/3):
+6571, *note A.4.11(43/3): 6572, *note A.4.11(44/3): 6573.
+Decrement
+ in Interfaces.C.Pointers *note B.3.2(11/3): 8082.
+deeper
+ accessibility level *note 3.10.2(3/2): 2444.
+ statically *note 3.10.2(4): 2451, *note 3.10.2(17): 2460.
+default constant indexing function *note 5.5.1(16/3): 3463.
+default cursor subtype *note 5.5.1(8/3): 3453.
+default directory *note A.16(48/2): 7184.
+default element subtype *note 5.5.1(9/3): 3456.
+default entry queuing policy *note 9.5.3(17): 4423.
+default iterator function *note 5.5.1(8/3): 3451.
+default iterator subtype *note 5.5.1(8/3): 3452.
+default pool *note 13.11.3(4.1/3): 5687.
+default treatment *note C.3(5): 8202.
+default variable indexing function *note 5.5.1(21/3): 3464.
+Default_Aft
+ in Ada.Text_IO *note A.10.1(64): 6969, *note A.10.1(69): 6979,
+*note A.10.1(74): 6989.
+ in Ada.Text_IO.Complex_IO *note G.1.3(5): 8925.
+Default_Base
+ in Ada.Text_IO *note A.10.1(53): 6951, *note A.10.1(58): 6960.
+Default_Bit_Order
+ in System *note 13.7(15/2): 5551.
+Default_Component_Value aspect *note 3.6(22.2/3): 2033.
+Default_Currency
+ in Ada.Text_IO.Editing *note F.3.3(10): 8848.
+Default_Deadline
+ in Ada.Dispatching.EDF *note D.2.6(9/2): 8397.
+Default_Exp
+ in Ada.Text_IO *note A.10.1(64): 6970, *note A.10.1(69): 6980,
+*note A.10.1(74): 6990.
+ in Ada.Text_IO.Complex_IO *note G.1.3(5): 8926.
+default_expression *note 3.7(6): 2096.
+ used *note 3.7(5/2): 2092, *note 3.8(6/3): 2160, *note 6.1(15/3):
+3556, *note 12.4(2/3): 5138, *note P: 10379.
+Default_Fill
+ in Ada.Text_IO.Editing *note F.3.3(10): 8849.
+Default_Fore
+ in Ada.Text_IO *note A.10.1(64): 6968, *note A.10.1(69): 6978,
+*note A.10.1(74): 6988.
+ in Ada.Text_IO.Complex_IO *note G.1.3(5): 8924.
+Default_Iterator aspect *note 5.5.1(8/3): 3455.
+Default_Modulus
+ in Ada.Containers.Indefinite_Holders *note A.18.21(10/3): 7857,
+*note A.18.23(10/3): 7866.
+default_name *note 12.6(4): 5242.
+ used *note 12.6(3/2): 5241, *note P: 10413.
+Default_Priority
+ in System *note 13.7(17): 5555.
+Default_Quantum
+ in Ada.Dispatching.Round_Robin *note D.2.5(4/2): 8387.
+Default_Radix_Mark
+ in Ada.Text_IO.Editing *note F.3.3(10): 8851.
+Default_Separator
+ in Ada.Text_IO.Editing *note F.3.3(10): 8850.
+Default_Setting
+ in Ada.Text_IO *note A.10.1(80): 6999.
+Default_Storage_Pool aspect *note 13.11.3(5/3): 5691.
+Default_Storage_Pool pragma *note 13.11.3(3/3): 5683, *note L(8.3/3):
+9365.
+Default_Subpool_for_Pool
+ in System.Storage_Pools.Subpools *note 13.11.4(13/3): 5703.
+Default_Value aspect *note 3.5(56.3/3): 1762.
+Default_Width
+ in Ada.Text_IO *note A.10.1(53): 6950, *note A.10.1(58): 6959,
+*note A.10.1(80): 6998.
+deferred constant *note 7.4(2/3): 3903.
+deferred constant declaration *note 3.3.1(6/3): 1570, *note 7.4(2/3):
+3902.
+defining name *note 3.1(10): 1373.
+defining_character_literal *note 3.5.1(4): 1776.
+ used *note 3.5.1(3): 1775, *note P: 9717.
+defining_designator *note 6.1(6): 3530.
+ used *note 6.1(4.2/2): 3524, *note 12.3(2/3): 5082, *note P: 10051.
+defining_identifier *note 3.1(4): 1358.
+ used *note 3.2.1(3/3): 1434, *note 3.2.2(2/3): 1462, *note
+3.3.1(3): 1564, *note 3.5.1(3): 1774, *note 3.10.1(2/2): 2425, *note
+5.5(4): 3430, *note 5.5.2(2/3): 3467, *note 6.1(7): 3535, *note
+6.5(2.1/3): 3744, *note 7.3(2/3): 3858, *note 7.3(3/3): 3862, *note
+8.5.1(2/3): 4087, *note 8.5.2(2/3): 4100, *note 9.1(2/3): 4200, *note
+9.1(3/3): 4206, *note 9.1(6/3): 4218, *note 9.4(2/3): 4265, *note
+9.4(3/3): 4271, *note 9.4(7/3): 4287, *note 9.5.2(2/3): 4349, *note
+9.5.2(5): 4362, *note 9.5.2(8): 4374, *note 10.1.3(4): 4733, *note
+10.1.3(5): 4736, *note 10.1.3(6): 4739, *note 11.2(4): 4896, *note
+12.5(2.1/3): 5162, *note 12.5(2.2/3): 5167, *note 12.7(2/3): 5258, *note
+P: 10034.
+defining_identifier_list *note 3.3.1(3): 1563.
+ used *note 3.3.1(2/3): 1553, *note 3.3.2(2): 1599, *note 3.7(5/2):
+2089, *note 3.8(6/3): 2158, *note 6.1(15/3): 3552, *note 11.1(2/3):
+4872, *note 12.4(2/3): 5129, *note P: 10320.
+defining_operator_symbol *note 6.1(11): 3538.
+ used *note 6.1(6): 3532, *note P: 10057.
+defining_program_unit_name *note 6.1(7): 3533.
+ used *note 6.1(4.1/2): 3521, *note 6.1(6): 3531, *note 7.1(3/3):
+3828, *note 7.2(2/3): 3843, *note 8.5.3(2/3): 4105, *note 8.5.5(2/3):
+4132, *note 12.3(2/3): 5077, *note P: 10168.
+Definite attribute *note 12.5.1(23/3): 5200.
+definite subtype *note 3.3(23/3): 1536.
+definition *note 3.1(7): 1365.
+Degree_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6096.
+DEL
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6041.
+delay_alternative *note 9.7.1(6): 4549.
+ used *note 9.7.1(4): 4544, *note 9.7.2(2): 4562, *note P: 10262.
+delay_relative_statement *note 9.6(4): 4451.
+ used *note 9.6(2): 4448, *note P: 10241.
+delay_statement *note 9.6(2): 4446.
+ used *note 5.1(4/2): 3353, *note 9.7.1(6): 4550, *note 9.7.4(4/2):
+4583, *note P: 10259.
+Delay_Until_And_Set_CPU
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(14/3):
+8682.
+Delay_Until_And_Set_Deadline
+ in Ada.Dispatching.EDF *note D.2.6(9/2): 8399.
+delay_until_statement *note 9.6(3): 4449.
+ used *note 9.6(2): 4447, *note P: 10240.
+Delete
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(24/2): 7362.
+ in Ada.Containers.Hashed_Maps *note A.18.5(25/2): 7459, *note
+A.18.5(26/2): 7460.
+ in Ada.Containers.Hashed_Sets *note A.18.8(24/2): 7593, *note
+A.18.8(25/2): 7594, *note A.18.8(55/2): 7619.
+ in Ada.Containers.Ordered_Maps *note A.18.6(24/2): 7513, *note
+A.18.6(25/2): 7514.
+ in Ada.Containers.Ordered_Sets *note A.18.9(23/2): 7667, *note
+A.18.9(24/2): 7668, *note A.18.9(68/2): 7701.
+ in Ada.Containers.Vectors *note A.18.2(50/2): 7285, *note
+A.18.2(51/2): 7286.
+ in Ada.Direct_IO *note A.8.4(8): 6815.
+ in Ada.Sequential_IO *note A.8.1(8): 6787.
+ in Ada.Streams.Stream_IO *note A.12.1(10): 7074.
+ in Ada.Strings.Bounded *note A.4.4(64): 6346, *note A.4.4(65):
+6347.
+ in Ada.Strings.Fixed *note A.4.3(29): 6287, *note A.4.3(30): 6288.
+ in Ada.Strings.Unbounded *note A.4.5(59): 6403, *note A.4.5(60):
+6404.
+ in Ada.Text_IO *note A.10.1(11): 6872.
+Delete_Children
+ in Ada.Containers.Multiway_Trees *note A.18.10(53/3): 7778.
+Delete_Directory
+ in Ada.Directories *note A.16(8/2): 7141.
+Delete_File
+ in Ada.Directories *note A.16(11/2): 7144.
+Delete_First
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(25/2): 7363.
+ in Ada.Containers.Ordered_Maps *note A.18.6(26/2): 7515.
+ in Ada.Containers.Ordered_Sets *note A.18.9(25/2): 7669.
+ in Ada.Containers.Vectors *note A.18.2(52/2): 7287.
+Delete_Last
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(26/2): 7364.
+ in Ada.Containers.Ordered_Maps *note A.18.6(27/2): 7516.
+ in Ada.Containers.Ordered_Sets *note A.18.9(26/2): 7670.
+ in Ada.Containers.Vectors *note A.18.2(53/2): 7288.
+Delete_Leaf
+ in Ada.Containers.Multiway_Trees *note A.18.10(35/3): 7760.
+Delete_Subtree
+ in Ada.Containers.Multiway_Trees *note A.18.10(36/3): 7761.
+Delete_Tree
+ in Ada.Directories *note A.16(10/2): 7143.
+delimiter *note 2.2(8/2): 1227.
+delivery
+ of an interrupt *note C.3(2): 8195.
+delta
+ of a fixed point type *note 3.5.9(1): 1925.
+Delta attribute *note 3.5.10(3): 1972.
+delta_constraint *note J.3(2): 9120.
+ used *note 3.2.2(6): 1477, *note P: 9686.
+Denorm attribute *note A.5.3(9): 6667.
+denormalized number *note A.5.3(10): 6668.
+denote *note 8.6(16): 4151.
+ informal definition *note 3.1(8): 1371.
+ name used as a pragma argument *note 8.6(32): 4169.
+depend on a discriminant
+ for a component *note 3.7(20): 2105.
+ for a constraint or component_definition *note 3.7(19): 2104.
+dependence
+ elaboration *note 10.2(9): 4794.
+ of a task on a master *note 9.3(1): 4250.
+ of a task on another task *note 9.3(4): 4254.
+ semantic *note 10.1.1(26/2): 4693.
+depth
+ accessibility level *note 3.10.2(3/2): 2445.
+ in Ada.Containers.Multiway_Trees *note A.18.10(19/3): 7744.
+depth-first order *note A.18.10(5/3): 7732.
+Dequeue
+ in Ada.Containers.Bounded_Priority_Queues *note A.18.31(5/3): 7919.
+ in Ada.Containers.Bounded_Synchronized_Queues *note A.18.29(5/3):
+7904.
+ in Ada.Containers.Synchronized_Queue_Interfaces *note A.18.27(6/3):
+7889.
+ in Ada.Containers.Unbounded_Priority_Queues *note A.18.30(5/3):
+7911.
+ in Ada.Containers.Unbounded_Synchronized_Queues *note A.18.28(5/3):
+7897.
+Dequeue_Only_High_Priority
+ in Ada.Containers.Bounded_Priority_Queues *note A.18.31(6/3): 7920.
+ in Ada.Containers.Unbounded_Priority_Queues *note A.18.30(6/3):
+7912.
+dereference *note 4.1(8): 2545.
+Dereference_Error
+ in Interfaces.C.Strings *note B.3.1(12): 8061.
+derivation class
+ for a type *note 3.4.1(2/2): 1643.
+derived from
+ directly or indirectly *note 3.4.1(2/2): 1642.
+derived type *note 3.4(1/2): 1605, *note N(13/2): 9533.
+ [partial] *note 3.4(24): 1631.
+derived_type_definition *note 3.4(2/2): 1609.
+ used *note 3.2.1(4/2): 1447, *note P: 9673.
+descendant *note 10.1.1(11): 4684, *note N(13.1/2): 9534.
+ at run-time *note 3.9(12.3/3): 2244.
+ of a tree node *note A.18.10(4/3): 7731.
+ of a type *note 3.4.1(10/2): 1657.
+ of an incomplete view *note 7.3.1(5.2/3): 3888.
+ of the full view of a type *note 7.3.1(5.1/3): 3887.
+ relationship with scope *note 8.2(4): 3997.
+Descendant_Tag
+ in Ada.Tags *note 3.9(7.1/2): 2237.
+designate *note 3.10(1): 2369.
+designated profile
+ of an access-to-subprogram type *note 3.10(11): 2406.
+ of an anonymous access type *note 3.10(12/3): 2411.
+designated subtype
+ of a named access type *note 3.10(10): 2401.
+ of an anonymous access type *note 3.10(12/3): 2409.
+designated type
+ of a named access type *note 3.10(10): 2402.
+ of an anonymous access type *note 3.10(12/3): 2410.
+designator *note 6.1(5): 3526.
+ used *note 6.3(2/3): 3645, *note P: 10083.
+destructor
+ See finalization *note 7.6(1): 3922.
+ See finalization *note 7.6.1(1): 3955.
+Detach_Handler
+ in Ada.Interrupts *note C.3.2(9): 8232.
+Detect_Blocking pragma *note H.5(3/2): 9108, *note L(8.4/2): 9368.
+Determinant
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(46/2): 9037.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(24/2): 8996.
+determined category for a formal type *note 12.5(6/3): 5189.
+determines
+ a type by a subtype_mark *note 3.2.2(8): 1481.
+Device_Error
+ in Ada.Direct_IO *note A.8.4(18): 6834.
+ in Ada.Directories *note A.16(43/2): 7176.
+ in Ada.IO_Exceptions *note A.13(4): 7119.
+ in Ada.Sequential_IO *note A.8.1(15): 6801.
+ in Ada.Streams.Stream_IO *note A.12.1(26): 7096.
+ in Ada.Text_IO *note A.10.1(85): 7010.
+Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6088.
+Difference
+ in Ada.Calendar.Arithmetic *note 9.6.1(12/2): 4492.
+ in Ada.Containers.Hashed_Sets *note A.18.8(32/2): 7599, *note
+A.18.8(33/2): 7600.
+ in Ada.Containers.Ordered_Sets *note A.18.9(33/2): 7675, *note
+A.18.9(34/2): 7676.
+digit *note 2.4.1(4.1/2): 1267.
+ used *note 2.4.1(3): 1261, *note 2.4.2(5): 1290, *note P: 9627.
+digits
+ of a decimal fixed point subtype *note 3.5.9(6): 1941, *note
+3.5.10(7): 1979.
+Digits attribute *note 3.5.8(2/1): 1920, *note 3.5.10(7): 1978.
+digits_constraint *note 3.5.9(5): 1936.
+ used *note 3.2.2(6): 1476, *note P: 9685.
+dimensionality
+ of an array *note 3.6(12): 2012.
+direct access *note A.8(3): 6777.
+direct file *note A.8(1/2): 6774.
+Direct_IO
+ child of Ada *note A.8.4(2): 6807.
+direct_name *note 4.1(3): 2535.
+ used *note 3.8.1(2): 2185, *note 4.1(2/3): 2523, *note 5.1(8):
+3369, *note 9.5.2(3): 4354, *note 10.2.1(4.2/2): 4818, *note 13.1(3):
+5287, *note J.7(1): 9131, *note L(25.2/2): 9444, *note P: 10429.
+Direction
+ in Ada.Strings *note A.4.1(6): 6234.
+directly specified
+ of a representation aspect of an entity *note 13.1(8/3): 5299.
+ of an operational aspect of an entity *note 13.1(8.1/3): 5305.
+directly visible *note 8.3(2): 4011, *note 8.3(21): 4035.
+ within a pragma in a context_clause *note 10.1.6(3): 4775.
+ within a pragma that appears at the place of a compilation unit
+*note 10.1.6(5): 4779.
+ within a use_clause in a context_clause *note 10.1.6(3): 4773.
+ within a with_clause *note 10.1.6(2/2): 4771.
+ within the parent_unit_name of a library unit *note 10.1.6(2/2):
+4769.
+ within the parent_unit_name of a subunit *note 10.1.6(4): 4777.
+Directories
+ child of Ada *note A.16(3/2): 7137.
+directory *note A.16(45/2): 7177.
+directory entry *note A.16(49/2): 7185.
+directory name *note A.16(46/2): 7180.
+Directory_Entry_Type
+ in Ada.Directories *note A.16(29/2): 7161.
+disabled
+ predicate checks *note 3.2.4(7/3): 1509.
+Discard_Names pragma *note C.5(3): 8243, *note L(9): 9370.
+discontiguous representation
+ [partial] *note 13.1(7.a/2): 5296, *note 13.5.2(5): 5510, *note
+13.7.1(12): 5569, *note 13.9(9): 5592, *note 13.9(17/3): 5595, *note
+13.11(17.d): 5649, *note 13.11(21.6/3): 5655.
+discrete array type *note 4.5.2(1): 2982.
+discrete type *note 3.2(3): 1399, *note 3.5(1): 1663, *note N(14):
+9535.
+discrete_choice *note 3.8.1(5/3): 2194.
+ used *note 3.8.1(4): 2193, *note P: 9790.
+discrete_choice_list *note 3.8.1(4): 2191.
+ used *note 3.8.1(3): 2189, *note 4.3.3(5/2): 2747, *note
+4.5.7(6/3): 3098, *note 5.4(3): 3409, *note P: 9895.
+Discrete_Random
+ child of Ada.Numerics *note A.5.2(17): 6635.
+discrete_range *note 3.6.1(3): 2041.
+ used *note 3.6.1(2): 2039, *note 4.1.2(2): 2575, *note P: 9752.
+discrete_subtype_definition *note 3.6(6): 2001.
+ used *note 3.6(5): 1999, *note 5.5(4): 3431, *note 9.5.2(2/3):
+4350, *note 9.5.2(8): 4375, *note P: 10236.
+discriminant *note 3.2(5/2): 1405, *note 3.7(1/2): 2076, *note
+N(15/2): 9536.
+ of a variant_part *note 3.8.1(6): 2198.
+ use in a record definition *note 3.8(12/3): 2164.
+discriminant_association *note 3.7.1(3): 2122.
+ used *note 3.7.1(2): 2120, *note P: 9768.
+Discriminant_Check *note 11.5(12): 5001.
+ [partial] *note 4.1.3(15): 2595, *note 4.3(6): 2678, *note
+4.3.2(8/3): 2722, *note 4.6(43): 3195, *note 4.6(45): 3197, *note
+4.6(51/3): 3207, *note 4.6(52): 3220, *note 4.7(4): 3245, *note
+4.8(10/2): 3276, *note 6.5(5.11/3): 3764.
+discriminant_constraint *note 3.7.1(2): 2119.
+ used *note 3.2.2(7): 1480, *note P: 9688.
+discriminant_part *note 3.7(2): 2081.
+ used *note 3.10.1(2/2): 2426, *note 7.3(2/3): 3859, *note 7.3(3/3):
+3863, *note 12.5(2.1/3): 5163, *note 12.5(2.2/3): 5168, *note P: 10384.
+discriminant_specification *note 3.7(5/2): 2088.
+ used *note 3.7(4): 2087, *note P: 9759.
+discriminants
+ known *note 3.7(26): 2107.
+ unknown *note 3.7(1.b/2): 2080.
+ unknown *note 3.7(26): 2111.
+discriminated type *note 3.7(8/2): 2099.
+dispatching *note 3.9(3): 2223.
+ child of Ada *note D.2.1(1.2/3): 8338.
+dispatching call
+ on a dispatching operation *note 3.9.2(1/2): 2285.
+dispatching operation *note 3.9.2(1/2): 2284, *note 3.9.2(2/3): 2298.
+ [partial] *note 3.9(1): 2208.
+dispatching point *note D.2.1(4/2): 8344.
+ [partial] *note D.2.3(8/2): 8372, *note D.2.4(9/3): 8381.
+dispatching policy for tasks *note 9(10.a/3): 4197.
+ [partial] *note D.2.1(5/2): 8350.
+dispatching, task *note D.2.1(4/2): 8342.
+Dispatching_Domain
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(5/3):
+8673.
+Dispatching_Domain aspect *note D.16.1(18/3): 8684.
+Dispatching_Domain pragma *note J.15.10(2/3): 9263, *note L(9.1/3):
+9373.
+Dispatching_Domain_Error
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(4/3):
+8672.
+Dispatching_Domains
+ child of System.Multiprocessors *note D.16.1(3/3): 8671.
+Dispatching_Policy_Error
+ in Ada.Dispatching *note D.2.1(1.4/3): 8340.
+Display_Format
+ in Interfaces.COBOL *note B.4(22): 8124.
+displayed magnitude (of a decimal value) *note F.3.2(14): 8839.
+disruption of an assignment *note 9.8(21): 4617, *note 13.9.1(5):
+5599.
+ [partial] *note 11.6(6/3): 5034.
+distinct access paths *note 6.2(12/3): 3633.
+distinguished receiver notation *note 4.1.3(19.e/2): 2601.
+distributed accessibility *note 3.10.2(32.1/3): 2478.
+distributed program *note E(3): 8690.
+distributed system *note E(2): 8689.
+distributed systems *note C(1): 8182.
+divide *note 2.1(15/3): 1205.
+ in Ada.Decimal *note F.2(6/3): 8835.
+divide operator *note 4.4(1/3): 2832, *note 4.5.5(1): 3048.
+Division_Check *note 11.5(13/2): 5002.
+ [partial] *note 3.5.4(20): 1848, *note 4.5.5(22): 3055, *note
+A.5.1(28): 6615, *note A.5.3(47): 6710, *note G.1.1(40): 8888, *note
+G.1.2(28): 8916, *note K.2(202): 9311.
+Division_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6169.
+DLE
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5965.
+Do_APC
+ in System.RPC *note E.5(10): 8815.
+Do_RPC
+ in System.RPC *note E.5(9): 8814.
+documentation (required of an implementation) *note 1.1.3(18): 1074,
+*note M.1(1/2): 9505, *note M.2(1/2): 9507, *note M.3(1/2): 9512.
+documentation requirements *note 1.1.2(34): 1043, *note M(1/3): 9503.
+ summary of requirements *note M.1(1/2): 9504.
+Dollar_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5985.
+dope *note 13.5.1(15.d): 5498.
+dot *note 2.1(15/3): 1202.
+dot selection
+ See selected_component *note 4.1.3(1): 2583.
+double
+ in Interfaces.C *note B.3(16): 8003.
+Double_Precision
+ in Interfaces.Fortran *note B.5(6): 8163.
+Doubly_Linked_Lists
+ child of Ada.Containers *note A.18.3(5/3): 7337.
+downward closure *note 3.10.2(13.b/2): 2455, *note 3.10.2(37/2): 2482.
+drift rate *note D.8(41): 8548.
+Duration
+ in Standard *note A.1(43): 5892.
+dynamic binding
+ See dispatching operation *note 3.9(1): 2210.
+dynamic semantics *note 1.1.2(30): 1034.
+Dynamic_Predicate aspect *note 3.2.4(1/3): 1505.
+Dynamic_Priorities
+ child of Ada *note D.5.1(3/2): 8443.
+dynamically determined tag *note 3.9.2(1/2): 2288.
+dynamically enclosing
+ of one execution by another *note 11.4(2): 4915.
+dynamically tagged *note 3.9.2(5/2): 2306.
+
+
+\1f
+File: aarm2012.info, Node: E, Next: F, Prev: D, Up: Index
+
+E
+==
+
+
+
+e
+ in Ada.Numerics *note A.5(3/2): 6582.
+EDF
+ child of Ada.Dispatching *note D.2.6(9/2): 8395.
+ child of Ada.Synchronous_Task_Control *note D.10(5.2/3): 8560.
+EDF_Across_Priorities task dispatching policy *note D.2.6(7/2): 8394.
+edited output *note F.3(1/2): 8836.
+Editing
+ child of Ada.Text_IO *note F.3.3(3): 8840.
+ child of Ada.Wide_Text_IO *note F.3.4(1): 8860.
+ child of Ada.Wide_Wide_Text_IO *note F.3.5(1/2): 8862.
+effect
+ external *note 1.1.3(8): 1068.
+efficiency *note 11.5(29): 5018, *note 11.6(1/3): 5026.
+Eigensystem
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(49/2): 9039.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(27/2): 8998.
+Eigenvalues
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(48/2): 9038.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(26/2): 8997.
+elaborable *note 3.1(11.g): 1380.
+Elaborate pragma *note 10.2.1(20): 4839, *note L(10): 9375.
+Elaborate_All pragma *note 10.2.1(21): 4843, *note L(11): 9379.
+Elaborate_Body aspect *note 10.2.1(26.1/3): 4854.
+Elaborate_Body pragma *note 10.2.1(22): 4847, *note L(12): 9383.
+elaborated *note 3.11(8): 2508.
+elaboration *note 3.1(11): 1376, *note 3.1(11.a): 1378, *note
+N(15.1/2): 9537, *note N(19): 9545.
+ abstract_subprogram_declaration *note 3.9.3(11.1/2): 2335.
+ access_definition *note 3.10(17/2): 2419.
+ access_type_definition *note 3.10(16): 2418.
+ array_type_definition *note 3.6(21): 2028.
+ aspect_clause *note 13.1(19/1): 5318.
+ choice_parameter_specification *note 11.4(7): 4926.
+ component_declaration *note 3.8(17): 2172.
+ component_definition *note 3.6(22/2): 2030, *note 3.8(18/2): 2176.
+ component_list *note 3.8(17): 2171.
+ declaration with a True Import aspect *note B.1(38/3): 7970.
+ declarative_part *note 3.11(7): 2507.
+ deferred constant declaration *note 7.4(10/3): 3906.
+ delta_constraint *note J.3(11): 9127.
+ derived_type_definition *note 3.4(26): 1632.
+ digits_constraint *note 3.5.9(19): 1959.
+ discrete_subtype_definition *note 3.6(22/2): 2029.
+ discriminant_constraint *note 3.7.1(12): 2134.
+ entry_declaration *note 9.5.2(22/1): 4391.
+ enumeration_type_definition *note 3.5.1(10): 1781.
+ exception_declaration *note 11.1(5): 4879.
+ expression_function_declaration *note 6.8(8/3): 3818.
+ fixed_point_definition *note 3.5.9(17): 1957.
+ floating_point_definition *note 3.5.7(13): 1912.
+ full type definition *note 3.2.1(11): 1459.
+ full_type_declaration *note 3.2.1(11): 1458.
+ generic body *note 12.2(2): 5067.
+ generic_declaration *note 12.1(10): 5063.
+ generic_instantiation *note 12.3(20): 5118.
+ incomplete_type_declaration *note 3.10.1(12): 2433.
+ index_constraint *note 3.6.1(8): 2050.
+ integer_type_definition *note 3.5.4(18): 1844.
+ loop_parameter_specification *note 5.5(9/3): 3437.
+ nongeneric package_body *note 7.2(6): 3850.
+ nongeneric subprogram_body *note 6.3(6): 3647.
+ null_procedure_declaration *note 6.7(5/3): 3806.
+ number_declaration *note 3.3.2(7): 1603.
+ object_declaration *note 3.3.1(15): 1582.
+ of library units for a foreign language main subprogram *note
+B.1(39/3): 7975.
+ package_body of Standard *note A.1(50): 5897.
+ package_declaration *note 7.1(8): 3839.
+ partition *note E.1(6): 8695.
+ partition *note E.5(21): 8818.
+ per-object constraint *note 3.8(18.1/1): 2177.
+ pragma *note 2.8(12): 1324.
+ private_extension_declaration *note 7.3(17): 3878.
+ private_type_declaration *note 7.3(17): 3877.
+ protected declaration *note 9.4(12): 4308.
+ protected_body *note 9.4(15): 4312.
+ protected_definition *note 9.4(13): 4310.
+ range_constraint *note 3.5(9): 1689.
+ real_type_definition *note 3.5.6(5): 1887.
+ record_definition *note 3.8(16): 2170.
+ record_extension_part *note 3.9.1(5): 2281.
+ record_type_definition *note 3.8(16): 2169.
+ renaming_declaration *note 8.5(3): 4078.
+ single_protected_declaration *note 9.4(12): 4309.
+ single_task_declaration *note 9.1(10): 4234.
+ subprogram_declaration *note 6.1(31/2): 3576.
+ subtype_declaration *note 3.2.2(9): 1482.
+ subtype_indication *note 3.2.2(9): 1483.
+ task declaration *note 9.1(10): 4233.
+ task_body *note 9.1(13): 4237.
+ task_definition *note 9.1(11): 4235.
+ use_clause *note 8.4(12): 4069.
+ variant_part *note 3.8.1(22): 2204.
+elaboration control *note 10.2.1(1): 4810.
+elaboration dependence
+ library_item on another *note 10.2(9): 4793.
+Elaboration_Check *note 11.5(20): 5011.
+ [partial] *note 3.11(9): 2509.
+element
+ of a storage pool *note 13.11(11): 5631.
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(14/2): 7347.
+ in Ada.Containers.Hashed_Maps *note A.18.5(14/2): 7441, *note
+A.18.5(31/2): 7465.
+ in Ada.Containers.Hashed_Sets *note A.18.8(15/2): 7581, *note
+A.18.8(52/2): 7616.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(12/3): 7830.
+ in Ada.Containers.Multiway_Trees *note A.18.10(24/3): 7749.
+ in Ada.Containers.Ordered_Maps *note A.18.6(13/2): 7495, *note
+A.18.6(39/2): 7528.
+ in Ada.Containers.Ordered_Sets *note A.18.9(14/2): 7655, *note
+A.18.9(65/2): 7698.
+ in Ada.Containers.Vectors *note A.18.2(27/2): 7255, *note
+A.18.2(28/2): 7256.
+ in Ada.Strings.Bounded *note A.4.4(26): 6318.
+ in Ada.Strings.Unbounded *note A.4.5(20): 6375.
+elementary type *note 3.2(2/2): 1393, *note N(16): 9538.
+Elementary_Functions
+ child of Ada.Numerics *note A.5.1(9/1): 6614.
+eligible
+ a type, for a convention *note B.1(14/3): 7964.
+else part
+ of a selective_accept *note 9.7.1(11): 4553.
+EM
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5974.
+embedded systems *note C(1): 8181, *note D(1): 8322.
+empty element
+ of a vector *note A.18.2(4/2): 7235.
+empty holder *note A.18.18(3/3): 7823.
+Empty_Holder
+ in Ada.Containers.Indefinite_Holders *note A.18.18(7/3): 7826.
+Empty_List
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(8/2): 7340.
+Empty_Map
+ in Ada.Containers.Hashed_Maps *note A.18.5(5/2): 7431.
+ in Ada.Containers.Ordered_Maps *note A.18.6(6/2): 7487.
+Empty_Set
+ in Ada.Containers.Hashed_Sets *note A.18.8(5/2): 7570.
+ in Ada.Containers.Ordered_Sets *note A.18.9(6/2): 7646.
+Empty_Tree
+ in Ada.Containers.Multiway_Trees *note A.18.10(10/3): 7736.
+Empty_Vector
+ in Ada.Containers.Vectors *note A.18.2(10/2): 7241.
+enabled
+ invariant expression *note 7.3.2(21/3): 3899.
+ postcondition expression *note 6.1.1(19/3): 3600.
+ precondition expression *note 6.1.1(19/3): 3599.
+ predicate checks *note 3.2.4(7/3): 1508.
+encapsulation
+ See package *note 7(1): 3822.
+enclosing
+ immediately *note 8.1(13): 3993.
+Encode
+ in Ada.Strings.UTF_Encoding.Strings *note A.4.11(23/3): 6554, *note
+A.4.11(24/3): 6555, *note A.4.11(25/3): 6556.
+ in Ada.Strings.UTF_Encoding.Wide_Strings *note A.4.11(31/3): 6561,
+*note A.4.11(32/3): 6562, *note A.4.11(33/3): 6563.
+ in Ada.Strings.UTF_Encoding.Wide_Wide_Strings *note A.4.11(39/3):
+6568, *note A.4.11(40/3): 6569, *note A.4.11(41/3): 6570.
+Encoding
+ in Ada.Strings.UTF_Encoding *note A.4.11(13/3): 6546.
+encoding scheme *note A.4.11(46/3): 6574.
+Encoding_Error
+ in Ada.Strings.UTF_Encoding *note A.4.11(8/3): 6541.
+Encoding_Scheme
+ in Ada.Strings.UTF_Encoding *note A.4.11(4/3): 6537.
+end of a line *note 2.2(2/3): 1225.
+End_Error
+ raised by failure of run-time check *note 13.13.2(37/1): 5811.
+ in Ada.Direct_IO *note A.8.4(18): 6835.
+ in Ada.IO_Exceptions *note A.13(4): 7120.
+ in Ada.Sequential_IO *note A.8.1(15): 6802.
+ in Ada.Streams.Stream_IO *note A.12.1(26): 7097.
+ in Ada.Text_IO *note A.10.1(85): 7011.
+End_Of_File
+ in Ada.Direct_IO *note A.8.4(16): 6829.
+ in Ada.Sequential_IO *note A.8.1(13): 6796.
+ in Ada.Streams.Stream_IO *note A.12.1(12): 7081.
+ in Ada.Text_IO *note A.10.1(34): 6917.
+End_Of_Line
+ in Ada.Text_IO *note A.10.1(30): 6910.
+End_Of_Page
+ in Ada.Text_IO *note A.10.1(33): 6915.
+End_Search
+ in Ada.Directories *note A.16(33/2): 7165.
+endian
+ big *note 13.5.3(2): 5515.
+ little *note 13.5.3(2): 5518.
+ENQ
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5954.
+Enqueue
+ in Ada.Containers.Bounded_Priority_Queues *note A.18.31(5/3): 7918.
+ in Ada.Containers.Bounded_Synchronized_Queues *note A.18.29(5/3):
+7903.
+ in Ada.Containers.Synchronized_Queue_Interfaces *note A.18.27(5/3):
+7888.
+ in Ada.Containers.Unbounded_Priority_Queues *note A.18.30(5/3):
+7910.
+ in Ada.Containers.Unbounded_Synchronized_Queues *note A.18.28(5/3):
+7896.
+entity *note 3.1(12.b): 1385.
+ [partial] *note 3.1(1): 1342.
+entry
+ closed *note 9.5.3(5): 4409.
+ open *note 9.5.3(5): 4407.
+ single *note 9.5.2(20): 4389.
+entry call *note 9.5.3(1): 4400.
+ simple *note 9.5.3(1): 4402.
+entry calling convention *note 6.3.1(13): 3664.
+entry family *note 9.5.2(20): 4386.
+entry index subtype *note 3.8(18/2): 2175, *note 9.5.2(20): 4387.
+entry queue *note 9.5.3(12): 4418.
+entry queuing policy *note 9.5.3(17): 4422.
+ default policy *note 9.5.3(17): 4424.
+entry_barrier *note 9.5.2(7): 4371.
+ used *note 9.5.2(5): 4364, *note P: 10228.
+entry_body *note 9.5.2(5): 4361.
+ used *note 9.4(8/1): 4294, *note P: 10213.
+entry_body_formal_part *note 9.5.2(6): 4368.
+ used *note 9.5.2(5): 4363, *note P: 10227.
+entry_call_alternative *note 9.7.2(3/2): 4563.
+ used *note 9.7.2(2): 4561, *note 9.7.3(2): 4572, *note P: 10267.
+entry_call_statement *note 9.5.3(2): 4403.
+ used *note 5.1(4/2): 3351, *note 9.7.2(3.1/2): 4568, *note P: 9996.
+entry_declaration *note 9.5.2(2/3): 4347.
+ used *note 9.1(5/1): 4215, *note 9.4(5/1): 4281, *note P: 10203.
+entry_index *note 9.5.2(4): 4359.
+ used *note 9.5.2(3): 4355, *note P: 10221.
+entry_index_specification *note 9.5.2(8): 4373.
+ used *note 9.5.2(6): 4369, *note P: 10232.
+enumeration literal *note 3.5.1(6/3): 1778.
+enumeration type *note 3.2(3): 1400, *note 3.5.1(1): 1769, *note
+N(17): 9539.
+enumeration_aggregate *note 13.4(3): 5460.
+ used *note 13.4(2): 5459, *note P: 10447.
+Enumeration_IO
+ in Ada.Text_IO *note A.10.1(79): 6997.
+enumeration_literal_specification *note 3.5.1(3): 1773.
+ used *note 3.5.1(2): 1771, *note P: 9714.
+enumeration_representation_clause *note 13.4(2): 5457.
+ used *note 13.1(2/1): 5283, *note P: 10425.
+enumeration_type_definition *note 3.5.1(2): 1770.
+ used *note 3.2.1(4/2): 1441, *note P: 9667.
+environment *note 10.1.4(1): 4753.
+environment declarative_part *note 10.1.4(1): 4754.
+ for the environment task of a partition *note 10.2(13): 4795.
+environment task *note 10.2(8): 4792.
+environment variable *note A.17(1/2): 7204.
+Environment_Task
+ in Ada.Task_Identification *note C.7.1(3/3): 8277.
+Environment_Variables
+ child of Ada *note A.17(3/2): 7205.
+EOT
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5953.
+EPA
+ in Ada.Characters.Latin_1 *note A.3.3(18): 6070.
+epoch *note D.8(19): 8544.
+equal operator *note 4.4(1/3): 2785, *note 4.5.2(1): 2960.
+Equal_Case_Insensitive
+ child of Ada.Strings *note A.4.10(2/3): 6527.
+ child of Ada.Strings.Bounded *note A.4.10(7/3): 6529.
+ child of Ada.Strings.Fixed *note A.4.10(5/3): 6528.
+ child of Ada.Strings.Unbounded *note A.4.10(10/3): 6530.
+Equal_Subtree
+ in Ada.Containers.Multiway_Trees *note A.18.10(14/3): 7740.
+equality operator *note 4.5.2(1): 2954.
+ special inheritance rule for tagged types *note 3.4(17/2): 1627,
+*note 4.5.2(14/3): 2990.
+equals sign *note 2.1(15/3): 1209.
+Equals_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(10): 6001.
+equivalence of use_clauses and selected_components *note 8.4(1.a):
+4053.
+equivalent element
+ of a hashed set *note A.18.8(64/2): 7628.
+ of an ordered set *note A.18.9(78/2): 7711.
+equivalent key
+ of a hashed map *note A.18.5(42/2): 7472.
+ of an ordered map *note A.18.6(55/2): 7534.
+Equivalent_Elements
+ in Ada.Containers.Hashed_Sets *note A.18.8(46/2): 7610, *note
+A.18.8(47/2): 7611, *note A.18.8(48/2): 7612.
+ in Ada.Containers.Ordered_Sets *note A.18.9(3/2): 7643.
+Equivalent_Keys
+ in Ada.Containers.Hashed_Maps *note A.18.5(34/2): 7467, *note
+A.18.5(35/2): 7468, *note A.18.5(36/2): 7469.
+ in Ada.Containers.Ordered_Maps *note A.18.6(3/2): 7484.
+ in Ada.Containers.Ordered_Sets *note A.18.9(63/2): 7696.
+Equivalent_Sets
+ in Ada.Containers.Hashed_Sets *note A.18.8(8/2): 7574.
+ in Ada.Containers.Ordered_Sets *note A.18.9(9/2): 7650.
+erroneous execution *note 1.1.2(32): 1040, *note 1.1.5(10): 1100.
+ cause *note 3.7.2(4): 2140, *note 3.9(25.3/2): 2261, *note
+6.4.1(18/3): 3736, *note 9.8(21): 4618, *note 9.10(11): 4631, *note
+11.5(26): 5015, *note 13.3(13/3): 5396, *note 13.3(27): 5408, *note
+13.3(28/2): 5409, *note 13.9.1(8): 5601, *note 13.9.1(12/3): 5606, *note
+13.9.1(13/3): 5607, *note 13.11(21): 5652, *note 13.11.2(16/3): 5681,
+*note 13.13.2(53/2): 5831, *note A.10.3(22/1): 7018, *note
+A.12.1(36.1/1): 7100, *note A.13(17): 7123, *note A.17(28/2): 7214,
+*note A.18.2(252/2): 7329, *note A.18.3(157/2): 7402, *note
+A.18.4(80/2): 7426, *note A.18.7(101/2): 7565, *note A.18.18(70/3):
+7848, *note A.18.19(11/3): 7851, *note A.18.20(15/3): 7855, *note
+A.18.21(16/3): 7860, *note A.18.22(13/3): 7864, *note A.18.23(16/3):
+7869, *note A.18.24(13/3): 7873, *note A.18.25(15/3): 7876, *note
+B.1(38.1/3): 7972, *note B.3.1(51): 8070, *note B.3.1(55): 8071, *note
+B.3.1(56): 8072, *note B.3.1(57): 8073, *note B.3.2(35): 8086, *note
+B.3.2(36): 8087, *note B.3.2(37): 8088, *note B.3.2(38): 8089, *note
+B.3.2(39): 8090, *note B.3.2(42): 8091, *note C.3.1(14): 8218, *note
+C.3.1(14.1/3): 8219, *note C.7.1(18): 8291, *note C.7.2(14): 8302, *note
+C.7.2(15): 8303, *note C.7.2(15.1/2): 8304, *note D.2.6(31/2): 8404,
+*note D.5.1(12): 8448, *note D.11(9): 8581, *note D.14(19/2): 8600,
+*note D.14.1(25/2): 8617, *note D.14.2(35/2): 8643, *note H.4(26): 9103,
+*note H.4(27): 9104.
+error
+ compile-time *note 1.1.2(27): 1023, *note 1.1.5(4): 1093.
+ link-time *note 1.1.2(29): 1031, *note 1.1.5(4): 1095.
+ run-time *note 1.1.2(30): 1037, *note 1.1.5(6): 1097, *note
+11.5(2/3): 4985, *note 11.6(1/3): 5024.
+ See also bounded error, erroneous execution
+ESA
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6054.
+ESC
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5976.
+Establish_RPC_Receiver
+ in System.RPC *note E.5(12): 8817.
+ETB
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5972.
+ETX
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5952.
+evaluable *note 3.1(11.g): 1381.
+evaluation *note 3.1(11): 1377, *note 3.1(11.a): 1379, *note
+N(17.1/2): 9540, *note N(19): 9546.
+ aggregate *note 4.3(5): 2675.
+ allocator *note 4.8(7/2): 3268.
+ array_aggregate *note 4.3.3(21): 2757.
+ attribute_reference *note 4.1.4(11): 2616.
+ case_expression *note 4.5.7(21/3): 3109.
+ concatenation *note 4.5.3(5): 3020.
+ dereference *note 4.1(13): 2553.
+ discrete_range *note 3.6.1(8): 2051.
+ extension_aggregate *note 4.3.2(7): 2720.
+ generalized_reference *note 4.1.5(8/3): 2628.
+ generic_association *note 12.3(21): 5120.
+ generic_association for a formal object of mode in *note 12.4(11):
+5152.
+ if_expression *note 4.5.7(20/3): 3105.
+ indexed_component *note 4.1.1(7): 2566.
+ initialized allocator *note 4.8(7/2): 3269.
+ membership test *note 4.5.2(27/3): 2995.
+ name *note 4.1(11/2): 2550.
+ name that has a prefix *note 4.1(12): 2551.
+ null literal *note 4.2(9): 2658.
+ numeric literal *note 4.2(9): 2657.
+ parameter_association *note 6.4.1(7): 3723.
+ prefix *note 4.1(12): 2552.
+ primary that is a name *note 4.4(10): 2909.
+ qualified_expression *note 4.7(4): 3242.
+ quantified_expression *note 4.5.8(6/3): 3123.
+ range *note 3.5(9): 1690.
+ range_attribute_reference *note 4.1.4(11): 2617.
+ record_aggregate *note 4.3.1(18): 2702.
+ record_component_association_list *note 4.3.1(19): 2703.
+ selected_component *note 4.1.3(14): 2594.
+ short-circuit control form *note 4.5.1(7): 2945.
+ slice *note 4.1.2(7): 2577.
+ string_literal *note 4.2(10): 2661.
+ uninitialized allocator *note 4.8(8): 3272.
+ Val *note 3.5.5(7): 1867, *note K.2(261): 9322.
+ Value *note 3.5(55/3): 1757.
+ value conversion *note 4.6(28): 3171.
+ view conversion *note 4.6(52): 3215.
+ Wide_Value *note 3.5(43/3): 1751.
+ Wide_Wide_Value *note 3.5(39.4/3): 1739.
+Exception *note 11(1/3): 4865, *note 11.1(1): 4870, *note N(18): 9541.
+exception function *note 6.8(6/3): 3816.
+exception occurrence *note 11(1/3): 4860.
+exception_choice *note 11.2(5): 4897.
+ used *note 11.2(3): 4892, *note P: 10327.
+exception_declaration *note 11.1(2/3): 4871.
+ used *note 3.1(3/3): 1355, *note P: 9653.
+exception_handler *note 11.2(3): 4890.
+ used *note 11.2(2): 4888, *note P: 10323.
+Exception_Id
+ in Ada.Exceptions *note 11.4.1(2/2): 4928.
+Exception_Identity
+ in Ada.Exceptions *note 11.4.1(5/2): 4939.
+Exception_Information
+ in Ada.Exceptions *note 11.4.1(5/2): 4943.
+Exception_Message
+ in Ada.Exceptions *note 11.4.1(4/3): 4937.
+Exception_Name
+ in Ada.Exceptions *note 11.4.1(2/2): 4930, *note 11.4.1(5/2): 4940.
+Exception_Occurrence
+ in Ada.Exceptions *note 11.4.1(3/2): 4933.
+Exception_Occurrence_Access
+ in Ada.Exceptions *note 11.4.1(3/2): 4934.
+exception_renaming_declaration *note 8.5.2(2/3): 4099.
+ used *note 8.5(2): 4074, *note P: 10139.
+Exceptions
+ child of Ada *note 11.4.1(2/2): 4927.
+Exchange_Handler
+ in Ada.Interrupts *note C.3.2(8): 8231.
+Exclamation
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5982.
+exclamation point *note 2.1(15/3): 1214.
+Exclude
+ in Ada.Containers.Hashed_Maps *note A.18.5(24/2): 7458.
+ in Ada.Containers.Hashed_Sets *note A.18.8(23/2): 7592, *note
+A.18.8(54/2): 7618.
+ in Ada.Containers.Ordered_Maps *note A.18.6(23/2): 7512.
+ in Ada.Containers.Ordered_Sets *note A.18.9(22/2): 7666, *note
+A.18.9(67/2): 7700.
+excludes null
+ subtype *note 3.10(13.1/2): 2413.
+executable *note 3.1(11.g): 1382.
+execution *note 3.1(11): 1375, *note N(19): 9544.
+ abort_statement *note 9.8(4): 4603.
+ aborting the execution of a construct *note 9.8(5): 4608.
+ accept_statement *note 9.5.2(24): 4392.
+ Ada program *note 9(1/3): 4178.
+ assignment_statement *note 5.2(7): 3385, *note 7.6(17): 3945, *note
+7.6.1(12/2): 3974.
+ asynchronous_select with a delay_statement trigger *note 9.7.4(7):
+4588.
+ asynchronous_select with a procedure call trigger *note 9.7.4(6/2):
+4587.
+ asynchronous_select with an entry call trigger *note 9.7.4(6/2):
+4586.
+ block_statement *note 5.6(5): 3497.
+ call on a dispatching operation *note 3.9.2(14): 2310.
+ call on an inherited subprogram *note 3.4(27/2): 1633.
+ case_statement *note 5.4(11/3): 3414.
+ conditional_entry_call *note 9.7.3(3): 4574.
+ delay_statement *note 9.6(20): 4472.
+ dynamically enclosing *note 11.4(2): 4916.
+ entry_body *note 9.5.2(26): 4397.
+ entry_call_statement *note 9.5.3(8): 4415.
+ exit_statement *note 5.7(5): 3502.
+ extended_return_statement *note 6.5(5.11/3): 3759.
+ goto_statement *note 5.8(5): 3506.
+ handled_sequence_of_statements *note 11.2(10): 4903.
+ handler *note 11.4(7): 4925.
+ if_statement *note 5.3(5/3): 3403.
+ included by another execution *note 11.4(2.a): 4919.
+ instance of Unchecked_Deallocation *note 7.6.1(10): 3968.
+ loop_statement *note 5.5(7): 3434.
+ loop_statement with a for iteration_scheme *note 5.5(9/3): 3436.
+ loop_statement with a while iteration_scheme *note 5.5(8): 3435.
+ null_statement *note 5.1(13): 3370.
+ partition *note 10.2(25): 4799.
+ pragma *note 2.8(12): 1323.
+ program *note 10.2(25): 4798.
+ protected subprogram call *note 9.5.1(3): 4337.
+ raise_statement with an exception_name *note 11.3(4/2): 4910.
+ re-raise statement *note 11.3(4/2): 4911.
+ remote subprogram call *note E.4(9): 8786.
+ requeue protected entry *note 9.5.4(9): 4439.
+ requeue task entry *note 9.5.4(8): 4438.
+ requeue_statement *note 9.5.4(7/3): 4437.
+ selective_accept *note 9.7.1(15): 4555.
+ sequence_of_statements *note 5.1(15): 3372.
+ simple_return_statement *note 6.5(6/2): 3766.
+ subprogram call *note 6.4(10/2): 3708.
+ subprogram_body *note 6.3(7): 3648.
+ task *note 9.2(1): 4241.
+ task_body *note 9.2(1): 4242.
+ timed_entry_call *note 9.7.2(4/2): 4569.
+execution resource
+ associated with a protected object *note 9.4(18): 4313.
+ required for a task to run *note 9(10): 4195.
+execution time
+ of a task *note D.14(11/3): 8597.
+Execution_Time
+ child of Ada *note D.14(3/2): 8585.
+exhaust
+ a budget *note D.14.2(14/2): 8639.
+exist
+ cease to *note 7.6.1(11/3): 3969, *note 13.11.2(10/2): 5673.
+Exists
+ in Ada.Directories *note A.16(24/2): 7157.
+ in Ada.Environment_Variables *note A.17(5/2): 7208.
+exit_statement *note 5.7(2): 3498.
+ used *note 5.1(4/2): 3347, *note P: 9992.
+Exit_Status
+ in Ada.Command_Line *note A.15(7): 7131.
+Exp
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(3): 8897.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(4): 6589.
+expanded name *note 4.1.3(4): 2591.
+Expanded_Name
+ in Ada.Tags *note 3.9(7/2): 2232.
+expected profile *note 8.6(26): 4160.
+ accept_statement entry_direct_name *note 9.5.2(11): 4376.
+ Access attribute_reference prefix *note 3.10.2(2.3/2): 2440.
+ attribute_definition_clause name *note 13.3(4): 5363.
+ character_literal *note 4.2(3): 2652.
+ formal subprogram actual *note 12.6(6): 5245.
+ formal subprogram default_name *note 12.6(5): 5244.
+ name in an aspect_specification *note 13.1.1(8/3): 5341.
+ subprogram_renaming_declaration *note 8.5.4(3): 4116.
+expected type *note 8.6(20/2): 4154.
+ abort_statement task_name *note 9.8(3): 4602.
+ access attribute_reference *note 3.10.2(2/2): 2439.
+ Access attribute_reference prefix *note 3.10.2(2.3/2): 2441.
+ actual parameter *note 6.4.1(3): 3720.
+ aggregate *note 4.3(3/2): 2674.
+ allocator *note 4.8(3/3): 3261.
+ array_aggregate *note 4.3.3(7/2): 2752.
+ array_aggregate component expression *note 4.3.3(7/2): 2753.
+ array_aggregate discrete_choice *note 4.3.3(8): 2754.
+ assignment_statement expression *note 5.2(4/2): 3384.
+ assignment_statement variable_name *note 5.2(4/2): 3383.
+ Attach_Handler pragma second argument *note J.15.7(6/3): 9224.
+ attribute_definition_clause expression or name *note 13.3(4): 5362.
+ attribute_designator expression *note 4.1.4(7): 2614.
+ case_expression selecting_expression *note 4.5.7(15/3): 3102.
+ case_expression_alternative discrete_choice *note 4.5.7(15/3):
+3103.
+ case_statement selecting_expression *note 5.4(4/3): 3411.
+ case_statement_alternative discrete_choice *note 5.4(4/3): 3413.
+ character_literal *note 4.2(3): 2651.
+ code_statement *note 13.8(4): 5579.
+ component_clause expressions *note 13.5.1(7): 5494.
+ component_declaration default_expression *note 3.8(7): 2162.
+ condition *note 4.5.7(14/3): 3101.
+ CPU pragma argument *note J.15.9(3/3): 9260.
+ decimal fixed point type digits *note 3.5.9(6): 1940.
+ delay_relative_statement expression *note 9.6(5): 4453.
+ delay_until_statement expression *note 9.6(5): 4454.
+ delta_constraint expression *note J.3(3): 9123.
+ dependent_expression *note 4.5.7(8/3): 3100.
+ dereference name *note 4.1(8): 2546.
+ discrete_subtype_definition range *note 3.6(8): 2007.
+ discriminant default_expression *note 3.7(7): 2098.
+ discriminant_association expression *note 3.7.1(6): 2130.
+ Dispatching_Domains pragma argument *note J.15.10(3/3): 9264.
+ entry_index *note 9.5.2(11): 4377.
+ enumeration_representation_clause expressions *note 13.4(4): 5462.
+ expression in an aspect_specification *note 13.1.1(7/3): 5340.
+ expression of a Default_Component_Value aspect *note 3.6(22.4/3):
+2034.
+ expression of a Default_Value aspect *note 3.5(56.5/3): 1763.
+ expression of a predicate aspect *note 3.2.4(2/3): 1506.
+ expression of expression function *note 6.8(3/3): 3814.
+ expression of extended_return_statement *note 6.5(3/2): 3755.
+ expression of simple_return_statement *note 6.5(3/2): 3754.
+ extension_aggregate *note 4.3.2(4/2): 2716.
+ extension_aggregate ancestor expression *note 4.3.2(4/2): 2717.
+ external name *note J.15.5(6/3): 9210.
+ first_bit *note 13.5.1(7): 5496.
+ fixed point type delta *note 3.5.9(6): 1939.
+ generic formal in object actual *note 12.4(4): 5141.
+ generic formal object default_expression *note 12.4(3): 5140.
+ index_constraint discrete_range *note 3.6.1(4): 2045.
+ indexable_container_object_prefix *note 4.1.6(11/3): 2643.
+ indexed_component expression *note 4.1.1(4): 2564.
+ Interrupt_Priority pragma argument *note J.15.11(5/3): 9271.
+ invariant expression *note 7.3.2(4/3): 3896.
+ iterable_name *note 5.5.2(3/3): 3475.
+ iterator_name *note 5.5.2(3/3): 3474.
+ last_bit *note 13.5.1(7): 5497.
+ link name *note J.15.5(6/3): 9209.
+ linker options *note B.1(10.1/3): 7959.
+ membership test simple_expression *note 4.5.2(3/3): 2986.
+ modular_type_definition expression *note 3.5.4(5): 1820.
+ name in an aspect_specification *note 13.1.1(7/3): 5339.
+ number_declaration expression *note 3.3.2(3): 1601.
+ object in an aspect_specification *note 13.1.1(6/3): 5338.
+ object_declaration initialization expression *note 3.3.1(4): 1566.
+ parameter default_expression *note 6.1(17): 3562.
+ position *note 13.5.1(7): 5495.
+ postcondition expression *note 6.1.1(6/3): 3597.
+ precondition expression *note 6.1.1(6/3): 3596.
+ Priority pragma argument *note J.15.11(5/3): 9270.
+ quantified_expression *note 4.5.8(5/3): 3121.
+ range simple_expressions *note 3.5(5): 1681.
+ range_attribute_designator expression *note 4.1.4(7): 2615.
+ range_constraint range *note 3.5(5): 1680.
+ real_range_specification bounds *note 3.5.7(5): 1898.
+ record_aggregate *note 4.3.1(8/2): 2698.
+ record_component_association expression *note 4.3.1(10): 2700.
+ reference_object_name *note 4.1.5(5/3): 2627.
+ Relative_Deadline pragma argument *note J.15.12(3/3): 9274.
+ requested decimal precision *note 3.5.7(4): 1897.
+ restriction parameter expression *note 13.12(5): 5739.
+ selecting_expression case_expression *note 4.5.7(15/3): 3104.
+ selecting_expression case_statement *note 5.4(4/3): 3412.
+ short-circuit control form relation *note 4.5.1(1): 2934.
+ signed_integer_type_definition simple_expression *note 3.5.4(5):
+1819.
+ slice discrete_range *note 4.1.2(4): 2576.
+ Storage_Size pragma argument *note J.15.4(4/3): 9179.
+ string_literal *note 4.2(4): 2653.
+ subpool_handle_name *note 4.8(3/3): 3262.
+ type_conversion operand *note 4.6(6): 3145.
+ Unchecked_Access attribute *note 13.10(4.a): 5617.
+ variant_part discrete_choice *note 3.8.1(6): 2199.
+expiration time
+ [partial] *note 9.6(1): 4444.
+ for a delay_relative_statement *note 9.6(20): 4474.
+ for a delay_until_statement *note 9.6(20): 4473.
+expires
+ execution timer *note D.14.1(15/3): 8616.
+explicit declaration *note 3.1(5): 1361, *note N(11): 9531.
+explicit initial value *note 3.3.1(1/3): 1543.
+explicit_actual_parameter *note 6.4(6): 3703.
+ used *note 6.4(5): 3702, *note P: 10093.
+explicit_dereference *note 4.1(5): 2541.
+ used *note 4.1(2/3): 2524, *note P: 9831.
+explicit_generic_actual_parameter *note 12.3(5): 5092.
+ used *note 12.3(4): 5091, *note P: 10363.
+explicitly aliased parameter *note 6.1(23.1/3): 3570.
+explicitly assign *note 10.2(2): 4787.
+explicitly limited record *note 3.8(13.1/3): 2165.
+exponent *note 2.4.1(4): 1264, *note 4.5.6(11/3): 3076.
+ used *note 2.4.1(2): 1259, *note 2.4.2(2): 1282, *note P: 9622.
+Exponent attribute *note A.5.3(18): 6681.
+exponentiation operator *note 4.4(1/3): 2840, *note 4.5.6(7): 3072.
+Export aspect *note B.1(1/3): 7944.
+Export pragma *note J.15.5(3/3): 9200, *note L(13.1/3): 9386.
+exported entity *note B.1(23/3): 7967.
+expression *note 4.4(1/3): 2774, *note 4.4(2): 2847.
+ predicate-static *note 3.2.4(15/3): 1512.
+ used *note 2.8(3/3): 1316, *note 3.3.1(2/3): 1551, *note 3.3.2(2):
+1600, *note 3.5.4(4): 1818, *note 3.5.7(2): 1891, *note 3.5.9(3): 1930,
+*note 3.5.9(4): 1933, *note 3.5.9(5): 1937, *note 3.7(6): 2097, *note
+3.7.1(3): 2125, *note 4.1.1(2): 2562, *note 4.1.4(3/2): 2608, *note
+4.1.4(5): 2613, *note 4.3.1(4/2): 2691, *note 4.3.2(3): 2714, *note
+4.3.3(3/2): 2735, *note 4.3.3(5/2): 2746, *note 4.4(7/3): 2906, *note
+4.5.7(3/3): 3089, *note 4.5.7(4/3): 3092, *note 4.5.7(5/3): 3094, *note
+4.5.7(6/3): 3099, *note 4.5.8(3/3): 3120, *note 4.6(2): 3133, *note
+4.7(2): 3238, *note 5.2(2): 3378, *note 5.4(2/3): 3405, *note 6.4(6):
+3704, *note 6.5(2.1/3): 3746, *note 6.5(2/2): 3742, *note 6.8(2/3):
+3812, *note 9.5.2(4): 4360, *note 9.6(3): 4450, *note 9.6(4): 4452,
+*note 11.3(2/2): 4907, *note 11.4.2(3/2): 4959, *note 12.3(5): 5093,
+*note 13.1.1(4/3): 5335, *note 13.3(2): 5358, *note 13.5.1(4): 5489,
+*note 13.12(4.1/2): 5738, *note B.1(8): 7958, *note B.1(10.1/3): 7960,
+*note D.2.2(3.2/2): 8361, *note J.3(2): 9121, *note J.7(1): 9132, *note
+J.8(1): 9143, *note J.15.4(2/3): 9178, *note J.15.5(2/3): 9197, *note
+J.15.5(3/3): 9204, *note J.15.7(4/3): 9223, *note J.15.9(2/3): 9259,
+*note L(2.1/2): 9334, *note L(6.1/3): 9356, *note L(8.2/3): 9363, *note
+L(13.1/3): 9390, *note L(14.1/3): 9396, *note L(19): 9418, *note
+L(27.2/2): 9454, *note L(35.1/3): 9484, *note P: 9889.
+expression_function_declaration *note 6.8(2/3): 3809.
+ used *note 3.1(3/3): 1352, *note P: 9650.
+extended_digit *note 2.4.2(5): 1289.
+ used *note 2.4.2(4): 1286, *note P: 9626.
+Extended_Index subtype of Index_Type'Base
+ in Ada.Containers.Vectors *note A.18.2(7/2): 7237.
+extended_return_object_declaration *note 6.5(2.1/3): 3743.
+ used *note 6.5(2.2/3): 3748, *note P: 10100.
+extended_return_statement *note 6.5(2.2/3): 3747.
+ used *note 5.1(5/2): 3362, *note P: 10006.
+extension
+ of a private type *note 3.9(2.1/2): 2221, *note 3.9.1(1/2): 2275.
+ of a record type *note 3.9(2.1/2): 2219, *note 3.9.1(1/2): 2273.
+ of a type *note 3.9(2/2): 2218, *note 3.9.1(1/2): 2271.
+ in Ada.Directories *note A.16(18/2): 7150.
+extension_aggregate *note 4.3.2(2): 2710.
+ used *note 4.3(2): 2672, *note P: 9869.
+extensions to Ada 2005 *note 1.1.2(39.ff/3): 1062, *note 2.2(14.d/3):
+1229, *note 2.8(19.f/3): 1328, *note 3.2.1(16.g/3): 1460, *note
+3.2.2(15.e/3): 1490, *note 3.2.4(35.a/3): 1520, *note 3.3(26.j/3): 1541,
+*note 3.3.1(33.l/3): 1596, *note 3.5(63.n/3): 1768, *note 3.5.5(17.b/3):
+1878, *note 3.6(30.j/3): 2037, *note 3.7(37.m/3): 2118, *note
+3.8(31.j/3): 2182, *note 3.8.1(29.f/3): 2207, *note 3.9.3(16.l/3): 2338,
+*note 3.10.1(23.m/3): 2438, *note 3.10.2(41.r/3): 2488, *note
+4.1(17.h/3): 2558, *note 4.1.5(15.a/3): 2632, *note 4.1.6(21.a/3): 2648,
+*note 4.3.1(31.f/3): 2709, *note 4.5.2(39.l/3): 3002, *note
+4.5.7(21.a/3): 3110, *note 4.5.8(13.a/3): 3124, *note 4.8(20.q/3): 3303,
+*note 5.1(19.e/3): 3375, *note 5.5.1(21.a/3): 3465, *note 5.5.2(15.a/3):
+3491, *note 6.1(42.m/3): 3579, *note 6.1.1(40.a/3): 3620, *note
+6.3(11.g/3): 3650, *note 6.3.2(7.d/3): 3687, *note 6.5(28.s/3): 3784,
+*note 6.5.1(10.b/3): 3792, *note 6.7(6.b/3): 3808, *note 6.8(9.a/3):
+3819, *note 7.1(17.e/3): 3841, *note 7.2(15.f/3): 3851, *note
+7.3(24.g/3): 3882, *note 7.3.2(24.b/3): 3901, *note 7.6(27.l/3): 3953,
+*note 8.4(16.h/3): 4071, *note 8.5.1(8.h/3): 4098, *note 8.5.2(6.a/3):
+4103, *note 8.5.3(6.b/3): 4108, *note 8.5.4(21.g/3): 4127, *note
+8.5.5(7.c/3): 4139, *note 8.6(34.w/3): 4177, *note 9.1(32.j/3): 4240,
+*note 9.4(35.h/3): 4320, *note 9.5(18.b/3): 4333, *note 9.5.2(37.e/3):
+4399, *note 9.5.4(20.b/3): 4443, *note 10.1.3(24.d/3): 4752, *note
+10.2.1(28.m/3): 4859, *note 11.1(8.c/3): 4885, *note 11.4.2(28.c/3):
+4979, *note 12.1(24.d/3): 5065, *note 12.3(29.j/3): 5125, *note
+12.4(12.i/3): 5157, *note 12.5(16.g/3): 5191, *note 12.5.1(28.j/3):
+5205, *note 12.6(24.e/3): 5254, *note 12.7(25.f/3): 5275, *note
+13.1.1(38.b/3): 5346, *note 13.2(9.d/3): 5351, *note 13.3(85.o/3): 5456,
+*note 13.11.1(5.d/3): 5663, *note 13.11.3(9.c/3): 5693, *note
+13.11.4(35.a/3): 5724, *note 13.11.5(10.f/3): 5727, *note
+13.12.1(13.c/3): 5772, *note 13.13.2(60.v/3): 5835, *note A.3.5(64.a/3):
+6219, *note A.3.6(1.a/3): 6221, *note A.4.7(48.g/3): 6474, *note
+A.4.8(51.b/3): 6517, *note A.4.9(12.d/3): 6526, *note A.4.10(22.a/3):
+6535, *note A.4.11(108.a/3): 6578, *note A.12.1(36.g/3): 7103, *note
+A.16.1(38.b/3): 7203, *note A.18.2(264.d/3): 7332, *note
+A.18.3(164.d/3): 7406, *note A.18.4(84.d/3): 7427, *note A.18.5(62.e/3):
+7482, *note A.18.6(95.f/3): 7543, *note A.18.7(105.d/3): 7566, *note
+A.18.8(88.e/3): 7641, *note A.18.9(116.e/3): 7722, *note
+A.18.10(233.c/3): 7808, *note A.18.17(7.a/3): 7822, *note
+A.18.18(74.b/3): 7849, *note A.18.19(17.a/3): 7852, *note
+A.18.20(20.a/3): 7856, *note A.18.21(22.a/3): 7861, *note
+A.18.22(19.a/3): 7865, *note A.18.23(21.a/3): 7870, *note
+A.18.24(18.a/3): 7874, *note A.18.25(20.a/3): 7877, *note
+A.18.26(13.b/3): 7885, *note A.18.27(17.b/3): 7893, *note
+A.18.28(12.c/3): 7900, *note A.18.29(13.a/3): 7907, *note
+A.18.30(17.c/3): 7915, *note A.18.31(14.a/3): 7923, *note A.19(12.a/3):
+7934, *note B.1(51.e/3): 7979, *note B.3.3(32.c/3): 8103, *note
+C.3.1(25.d/3): 8222, *note C.6(24.e/3): 8271, *note D.1(29.g/3): 8337,
+*note D.2.4(11.b/3): 8383, *note D.2.6(34.c/3): 8406, *note D.7(22.j/3):
+8520, *note D.10(12.b/3): 8566, *note D.10.1(15.a/3): 8571, *note
+D.14.3(7.a/3): 8649, *note D.16(14.a/3): 8670, *note D.16.1(33.a/3):
+8685, *note E.2.1(11.b/3): 8728, *note E.2.2(20.k/3): 8743, *note
+E.2.2(20.m/3): 8744, *note E.2.3(20.f/3): 8769, *note E.4.1(10.b/3):
+8805, *note J.15.9(6.a/3): 9261, *note J.15.10(5.a/3): 9265.
+extensions to Ada 83 *note 1.1.2(39.g): 1051, *note 2.1(19.b): 1218,
+*note 2.8(19.d): 1327, *note 2.8(29.a): 1337, *note 3.2.3(8.b): 1498,
+*note 3.3(26.a): 1540, *note 3.3.1(33.a): 1592, *note 3.3.2(10.a): 1604,
+*note 3.4(38.d): 1639, *note 3.5(63.b): 1765, *note 3.5.2(11.f): 1799,
+*note 3.5.4(36.a): 1861, *note 3.5.5(17.a): 1877, *note 3.5.9(28.b/3):
+1964, *note 3.6(30.a): 2035, *note 3.6.1(18.a): 2052, *note 3.6.3(8.e):
+2073, *note 3.7(37.a): 2116, *note 3.7.2(4.b/1): 2141, *note 3.8(31.a):
+2179, *note 3.8.1(29.a): 2205, *note 3.9(33.a): 2264, *note 3.9.1(17.a):
+2282, *note 3.9.2(24.a): 2317, *note 3.10(26.a): 2420, *note
+3.10.1(23.a): 2435, *note 3.10.2(41.a): 2484, *note 3.11(14.a/2): 2515,
+*note 4.1(17.a): 2557, *note 4.1.3(19.a): 2599, *note 4.1.4(16.a): 2619,
+*note 4.2(14.b): 2666, *note 4.3(6.b): 2681, *note 4.3.1(31.a): 2706,
+*note 4.3.2(13.a): 2725, *note 4.3.3(45.a): 2771, *note 4.4(15.a): 2913,
+*note 4.5.2(39.a): 2998, *note 4.5.3(14.d): 3027, *note 4.5.5(35.a):
+3059, *note 4.6(71.d): 3231, *note 4.8(20.b): 3298, *note 4.9(44.a):
+3325, *note 5.1(19.a): 3373, *note 5.2(28.a): 3395, *note 5.4(18.a):
+3419, *note 6.1(42.a): 3577, *note 6.2(13.a): 3638, *note 6.3(11.a):
+3649, *note 6.3.1(25.a): 3683, *note 6.4.1(18.a): 3737, *note 6.6(9.a):
+3798, *note 7.3(24.a): 3880, *note 7.4(14.a): 3907, *note 7.5(23.a):
+3916, *note 7.6(27.b): 3951, *note 8.2(12.b): 4008, *note 8.3(29.p):
+4048, *note 8.4(16.e): 4070, *note 8.5.5(7.a): 4138, *note 8.6(34.b):
+4172, *note 9.1(32.a/1): 4238, *note 9.4(35.a/3): 4317, *note
+9.5.2(37.a): 4398, *note 9.5.4(20.a): 4442, *note 9.6(40.b): 4483, *note
+9.7(4.a): 4532, *note 9.7.4(13.a): 4597, *note 10.1.1(35.n): 4694, *note
+10.1.2(31.a): 4718, *note 10.1.3(24.a): 4750, *note 10.1.4(10.b/2):
+4759, *note 10.2(34.d): 4809, *note 10.2.1(28.c): 4855, *note
+11.2(12.a): 4904, *note 11.4.1(19.x): 4950, *note 11.5(31.a): 5019,
+*note 12.1(24.a): 5064, *note 12.3(29.c): 5123, *note 12.4(12.b): 5155,
+*note 12.5.4(13.b): 5222, *note 12.7(25.a): 5272, *note 13.1(29.b/1):
+5322, *note 13.3(85.a): 5453, *note 13.4(14.a): 5468, *note 13.5.3(9.a):
+5527, *note 13.7(38.a.1/1): 5557, *note 13.8(14.a): 5582, *note
+13.9.2(13.d): 5613, *note 13.11(43.a): 5656, *note 13.12(17.b): 5748,
+*note 13.13(1.b): 5775, *note 13.14(20.e): 5870, *note A.1(56.d): 5898,
+*note A.2(4.e/3): 5901, *note A.3(1.a/3): 5902, *note A.4(1.a/3): 6222,
+*note A.5(5.b): 6583, *note A.5.3(72.g): 6748, *note A.5.4(4.c): 6758,
+*note A.6(1.b): 6762, *note A.9(11.a/3): 6845, *note A.10(11.a): 6859,
+*note A.10.1(86.b): 7016, *note A.11(5.a): 7060, *note A.15(22.b/3):
+7136, *note B(2.b): 7938, *note B.1(51.a): 7977, *note C(1.a): 8184,
+*note D(6.a): 8323, *note D.1(29.b): 8336, *note E(1.a): 8686, *note
+F(7.b): 8824, *note G(7.a): 8865, *note G.2(3.a): 8943, *note
+G.2.1(16.g): 8953, *note H(6.b): 9051, *note J.7(2.c): 9133, *note
+J.15.1(6.b/3): 9163.
+extensions to Ada 95 *note 1.1.2(39.s/2): 1057, *note 2.1(19.f/2):
+1219, *note 2.3(8.c/2): 1247, *note 3.2.2(15.d/2): 1489, *note
+3.3.1(33.g/2): 1594, *note 3.3.1(33.h/2): 1595, *note 3.4(38.i/2): 1640,
+*note 3.5(63.j/2): 1766, *note 3.5.2(11.l/2): 1801, *note 3.5.4(36.k/2):
+1862, *note 3.6(30.g/2): 2036, *note 3.6.3(8.h/2): 2075, *note
+3.8(31.e/2): 2180, *note 3.8(31.f/2): 2181, *note 3.9(33.e/2): 2267,
+*note 3.9.1(17.b/2): 2283, *note 3.9.2(24.c/2): 2319, *note
+3.9.3(16.d/2): 2336, *note 3.9.4(36.a/2): 2366, *note 3.10(26.f/2):
+2423, *note 3.10.1(23.j/2): 2437, *note 3.10.2(41.g/2): 2486, *note
+4.1.3(19.e/2): 2600, *note 4.2(14.d/2): 2667, *note 4.3(6.k/2): 2683,
+*note 4.3.1(31.c/2): 2707, *note 4.3.3(45.f/2): 2772, *note
+4.5.2(39.f/2): 2999, *note 4.6(71.l/2): 3233, *note 4.8(20.h/2): 3301,
+*note 5.1(19.d/2): 3374, *note 6.1(42.f/2): 3578, *note 6.4(31.d/2):
+3713, *note 6.5(28.i/2): 3781, *note 6.5.1(10.a/2): 3791, *note
+6.7(6.a/2): 3807, *note 7.3(24.d/2): 3881, *note 7.4(14.j/2): 3908,
+*note 7.5(23.c/2): 3917, *note 7.6(27.c/2): 3952, *note 8.3.1(16.b/2):
+4052, *note 8.5.1(8.d/2): 4096, *note 8.5.4(21.a/2): 4125, *note
+8.6(34.q/2): 4175, *note 9.1(32.e/2): 4239, *note 9.4(35.b/2): 4318,
+*note 9.6.1(91.b/2): 4525, *note 9.7.4(13.b/2): 4598, *note
+10.1.1(35.r/2): 4695, *note 10.1.2(31.g/2): 4720, *note 10.1.2(31.h/3):
+4721, *note 10.1.3(24.b/2): 4751, *note 10.2.1(28.g/2): 4857, *note
+11.3(7.b/2): 4912, *note 11.4.1(19.cc/2): 4953, *note 11.4.2(28.a/2):
+4977, *note 11.5(31.g/2): 5020, *note 12.3(29.i/2): 5124, *note
+12.4(12.e/2): 5156, *note 12.5.1(28.c/2): 5203, *note 12.5.5(7.a/2):
+5226, *note 12.6(24.a/2): 5252, *note 12.7(25.b/2): 5273, *note
+13.1(29.i/2): 5323, *note 13.5.1(31.e/2): 5501, *note 13.7(38.e/2):
+5558, *note 13.7.1(16.d/2): 5571, *note 13.11(43.e/2): 5658, *note
+13.12(17.c/3): 5749, *note 13.12.1(13.a/2): 5771, *note 13.13.1(11.b/2):
+5785, *note 13.13.2(60.i/2): 5833, *note A.1(56.h/2): 5899, *note
+A.3.1(7.b/2): 5906, *note A.3.2(60.c/2): 5945, *note A.3.4(35.a/2):
+6197, *note A.4.2(67.a/2): 6261, *note A.4.5(88.d/2): 6415, *note
+A.4.6(8.b/2): 6432, *note A.4.7(48.b/2): 6473, *note A.4.8(51.a/2):
+6516, *note A.4.9(12.c/2): 6525, *note A.5(5.c/2): 6584, *note
+A.5.3(72.i/2): 6749, *note A.10.7(26.b/2): 7026, *note A.10.11(29.a/2):
+7039, *note A.10.12(29.a/2): 7049, *note A.11(5.b/2): 7061, *note
+A.12.4(5.a/2): 7113, *note A.16(131.c/2): 7188, *note A.17(33.b/2):
+7215, *note A.18(5.w/3): 7224, *note A.18.1(8.c/2): 7229, *note
+A.18.2(264.b/2): 7330, *note A.18.3(164.a/2): 7403, *note
+A.18.5(62.c/2): 7480, *note A.18.6(95.d/2): 7541, *note A.18.8(88.c/2):
+7639, *note A.18.9(116.c/2): 7720, *note A.18.11(8.a/2): 7810, *note
+A.18.12(7.a/2): 7812, *note A.18.13(8.a/2): 7814, *note A.18.14(8.a/2):
+7816, *note A.18.15(4.a/2): 7818, *note A.18.16(4.a/2): 7820, *note
+A.18.26(13.a/2): 7884, *note B.3(84.b/2): 8050, *note B.3.1(60.b/2):
+8075, *note B.3.3(32.a/2): 8101, *note C.7.3(17.a/2): 8320, *note
+D.2.2(22.a/2): 8368, *note D.2.4(11.a/2): 8382, *note D.2.5(19.a/2):
+8392, *note D.2.6(34.b/2): 8405, *note D.3(23.a/2): 8428, *note
+D.5.1(19.a/2): 8449, *note D.5.2(11.a/2): 8453, *note D.7(22.b/2): 8518,
+*note D.10(12.a/2): 8565, *note D.11(19.a/2): 8582, *note D.13(10.a/3):
+8584, *note D.14(29.b/2): 8601, *note D.14.1(29.a/2): 8618, *note
+D.14.2(38.a/2): 8644, *note D.15(27.a/2): 8662, *note E.2.2(20.c/3):
+8741, *note F.3.5(6.a/2): 8863, *note G.1.1(58.g/2): 8893, *note
+G.1.3(35.a/2): 8934, *note G.1.5(1.a/2): 8939, *note G.3(1.c/3): 8987,
+*note G.3.1(91.b/2): 9004, *note G.3.2(161.b/2): 9045, *note
+H.4(28.c/2): 9105, *note H.4(28.h/3): 9106, *note H.5(7.a/2): 9111,
+*note H.6(17.a/2): 9118, *note J.15.1(6.c/3): 9164.
+external call *note 9.5(4/3): 4325.
+external effect
+ of the execution of an Ada program *note 1.1.3(8): 1067.
+ volatile/atomic objects *note C.6(20): 8268.
+external file *note A.7(1): 6763.
+external interaction *note 1.1.3(8): 1069.
+external name *note B.1(34): 7968.
+external requeue *note 9.5(7): 4328.
+external streaming
+ type supports *note 13.13.2(52/3): 5830.
+External_Name aspect *note B.1(1/3): 7948.
+External_Tag
+ in Ada.Tags *note 3.9(7/2): 2235.
+External_Tag aspect *note 13.3(75/3): 5452, *note K.2(65): 9296.
+External_Tag attribute *note 13.3(75/3): 5448.
+External_Tag clause *note 13.3(7/2): 5373, *note 13.3(75/3): 5449,
+*note K.2(65): 9293.
+extra permission to avoid raising exceptions *note 11.6(5): 5028.
+extra permission to reorder actions *note 11.6(6/3): 5030.
+
+
+\1f
+File: aarm2012.info, Node: F, Next: G, Prev: E, Up: Index
+
+F
+==
+
+
+
+factor *note 4.4(6): 2895.
+ used *note 4.4(5): 2892, *note P: 9935.
+factory *note 3.9(30/2): 2262.
+failure
+ of a language-defined check *note 11.5(2/3): 4986.
+ in Ada.Command_Line *note A.15(8): 7133.
+fall-back handler *note C.7.3(9/2): 8314.
+False *note 3.5.3(1): 1804.
+family
+ entry *note 9.5.2(20): 4385.
+Feminine_Ordinal_Indicator
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6090.
+FF
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5961.
+Field subtype of Integer
+ in Ada.Text_IO *note A.10.1(6): 6866.
+FIFO_Queuing queuing policy *note D.4(7/2): 8439.
+FIFO_Within_Priorities task dispatching policy *note D.2.3(2/2): 8370.
+file
+ as file object *note A.7(2/3): 6766.
+file name *note A.16(46/2): 7181.
+file terminator *note A.10(7): 6851.
+File_Access
+ in Ada.Text_IO *note A.10.1(18): 6888.
+File_Kind
+ in Ada.Directories *note A.16(22/2): 7155.
+File_Mode
+ in Ada.Direct_IO *note A.8.4(4): 6809.
+ in Ada.Sequential_IO *note A.8.1(4): 6783.
+ in Ada.Streams.Stream_IO *note A.12.1(6): 7068.
+ in Ada.Text_IO *note A.10.1(4): 6862.
+File_Size
+ in Ada.Directories *note A.16(23/2): 7156.
+File_Type
+ in Ada.Direct_IO *note A.8.4(3): 6808.
+ in Ada.Sequential_IO *note A.8.1(3): 6782.
+ in Ada.Streams.Stream_IO *note A.12.1(5): 7067.
+ in Ada.Text_IO *note A.10.1(3): 6861.
+Filter_Type
+ in Ada.Directories *note A.16(30/2): 7162.
+finalization
+ of a master *note 7.6.1(4): 3965.
+ of a protected object *note 9.4(20): 4314.
+ of a protected object *note C.3.1(12/3): 8217.
+ of a task object *note J.7.1(8): 9140.
+ of an object *note 7.6.1(5): 3966.
+ of environment task for a foreign language main subprogram *note
+B.1(39/3): 7976.
+ child of Ada *note 7.6(4/3): 3927.
+Finalize *note 7.6(2): 3925.
+ in Ada.Finalization *note 7.6(6/2): 3931, *note 7.6(8/2): 3934.
+Find
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(41/2): 7379.
+ in Ada.Containers.Hashed_Maps *note A.18.5(30/2): 7464.
+ in Ada.Containers.Hashed_Sets *note A.18.8(43/2): 7608, *note
+A.18.8(56/2): 7620.
+ in Ada.Containers.Multiway_Trees *note A.18.10(38/3): 7763.
+ in Ada.Containers.Ordered_Maps *note A.18.6(38/2): 7527.
+ in Ada.Containers.Ordered_Sets *note A.18.9(49/2): 7689, *note
+A.18.9(69/2): 7702.
+ in Ada.Containers.Vectors *note A.18.2(68/2): 7303.
+Find_In_Subtree
+ in Ada.Containers.Multiway_Trees *note A.18.10(39/3): 7764.
+Find_Index
+ in Ada.Containers.Vectors *note A.18.2(67/2): 7302.
+Find_Token
+ in Ada.Strings.Bounded *note A.4.4(50.1/3): 6334, *note A.4.4(51):
+6335.
+ in Ada.Strings.Fixed *note A.4.3(15.1/3): 6275, *note A.4.3(16):
+6276.
+ in Ada.Strings.Unbounded *note A.4.5(45.1/3): 6391, *note
+A.4.5(46): 6392.
+Fine_Delta
+ in System *note 13.7(9): 5540.
+First
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(33/2): 7371.
+ in Ada.Containers.Hashed_Maps *note A.18.5(27/2): 7461.
+ in Ada.Containers.Hashed_Sets *note A.18.8(40/2): 7605.
+ in Ada.Containers.Ordered_Maps *note A.18.6(28/2): 7517.
+ in Ada.Containers.Ordered_Sets *note A.18.9(41/2): 7681.
+ in Ada.Containers.Vectors *note A.18.2(58/2): 7293.
+ in Ada.Iterator_Interfaces *note 5.5.1(3/3): 3441.
+First attribute *note 3.5(12): 1694, *note 3.6.2(3): 2054.
+first element
+ of a hashed set *note A.18.8(68/2): 7633.
+ of a set *note A.18.7(6/2): 7549.
+ of an ordered set *note A.18.9(81/3): 7715.
+first node
+ of a hashed map *note A.18.5(46/2): 7476.
+ of a map *note A.18.4(6/2): 7413.
+ of an ordered map *note A.18.6(58/3): 7537.
+first subtype *note 3.2.1(6): 1449, *note 3.4.1(5): 1648.
+First(N) attribute *note 3.6.2(4): 2056.
+first_bit *note 13.5.1(5): 5490.
+ used *note 13.5.1(3): 5486, *note P: 10454.
+First_Bit attribute *note 13.5.2(3/2): 5506.
+First_Child
+ in Ada.Containers.Multiway_Trees *note A.18.10(60/3): 7785.
+First_Child_Element
+ in Ada.Containers.Multiway_Trees *note A.18.10(61/3): 7786.
+First_Element
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(34/2): 7372.
+ in Ada.Containers.Ordered_Maps *note A.18.6(29/2): 7518.
+ in Ada.Containers.Ordered_Sets *note A.18.9(42/2): 7682.
+ in Ada.Containers.Vectors *note A.18.2(59/2): 7294.
+First_Index
+ in Ada.Containers.Vectors *note A.18.2(57/2): 7292.
+First_Key
+ in Ada.Containers.Ordered_Maps *note A.18.6(30/2): 7519.
+First_Valid attribute *note 3.5.5(7.2/3): 1872.
+Fixed
+ child of Ada.Strings *note A.4.3(5): 6262.
+fixed point type *note 3.5.9(1): 1922.
+Fixed_IO
+ in Ada.Text_IO *note A.10.1(68): 6977.
+fixed_point_definition *note 3.5.9(2): 1926.
+ used *note 3.5.6(2): 1882, *note P: 9725.
+Float *note 3.5.7(12): 1911, *note 3.5.7(14): 1913.
+ in Standard *note A.1(21): 5883.
+Float_IO
+ in Ada.Text_IO *note A.10.1(63): 6967.
+Float_Random
+ child of Ada.Numerics *note A.5.2(5): 6622.
+Float_Text_IO
+ child of Ada *note A.10.9(33): 7029.
+Float_Wide_Text_IO
+ child of Ada *note A.11(2/2): 7052.
+Float_Wide_Wide_Text_IO
+ child of Ada *note A.11(3/2): 7055.
+Floating
+ in Interfaces.COBOL *note B.4(9): 8107.
+floating point type *note 3.5.7(1): 1889.
+floating_point_definition *note 3.5.7(2): 1890.
+ used *note 3.5.6(2): 1881, *note P: 9724.
+Floor
+ in Ada.Containers.Ordered_Maps *note A.18.6(40/2): 7529.
+ in Ada.Containers.Ordered_Sets *note A.18.9(50/2): 7690, *note
+A.18.9(70/2): 7703.
+Floor attribute *note A.5.3(30): 6695.
+Flush
+ in Ada.Streams.Stream_IO *note A.12.1(25/1): 7091.
+ in Ada.Text_IO *note A.10.1(21/1): 6895.
+Fore attribute *note 3.5.10(4): 1974.
+form
+ of an external file *note A.7(1): 6765.
+ in Ada.Direct_IO *note A.8.4(9): 6820.
+ in Ada.Sequential_IO *note A.8.1(9): 6792.
+ in Ada.Streams.Stream_IO *note A.12.1(11): 7079.
+ in Ada.Text_IO *note A.10.1(12): 6877.
+formal object, generic *note 12.4(1): 5127.
+formal package, generic *note 12.7(1): 5256.
+formal parameter
+ of a subprogram *note 6.1(17): 3561.
+formal subprogram, generic *note 12.6(1): 5228.
+formal subtype *note 12.5(5): 5188.
+formal type *note 12.5(5): 5186.
+formal_abstract_subprogram_declaration *note 12.6(2.2/3): 5236.
+ used *note 12.6(2/2): 5231, *note P: 10406.
+formal_access_type_definition *note 12.5.4(2): 5217.
+ used *note 12.5(3/2): 5179, *note P: 10398.
+formal_array_type_definition *note 12.5.3(2): 5212.
+ used *note 12.5(3/2): 5178, *note P: 10397.
+formal_complete_type_declaration *note 12.5(2.1/3): 5161.
+ used *note 12.5(2/3): 5159, *note P: 10381.
+formal_concrete_subprogram_declaration *note 12.6(2.1/3): 5232.
+ used *note 12.6(2/2): 5230, *note P: 10405.
+formal_decimal_fixed_point_definition *note 12.5.2(7): 5211.
+ used *note 12.5(3/2): 5177, *note P: 10396.
+formal_derived_type_definition *note 12.5.1(3/2): 5193.
+ used *note 12.5(3/2): 5171, *note P: 10390.
+formal_discrete_type_definition *note 12.5.2(2): 5206.
+ used *note 12.5(3/2): 5172, *note P: 10391.
+formal_floating_point_definition *note 12.5.2(5): 5209.
+ used *note 12.5(3/2): 5175, *note P: 10394.
+formal_incomplete_type_declaration *note 12.5(2.2/3): 5166.
+ used *note 12.5(2/3): 5160, *note P: 10382.
+formal_interface_type_definition *note 12.5.5(2/2): 5224.
+ used *note 12.5(3/2): 5180, *note P: 10399.
+formal_modular_type_definition *note 12.5.2(4): 5208.
+ used *note 12.5(3/2): 5174, *note P: 10393.
+formal_object_declaration *note 12.4(2/3): 5128.
+ used *note 12.1(6): 5054, *note P: 10342.
+formal_ordinary_fixed_point_definition *note 12.5.2(6): 5210.
+ used *note 12.5(3/2): 5176, *note P: 10395.
+formal_package_actual_part *note 12.7(3/2): 5262.
+ used *note 12.7(2/3): 5260, *note P: 10417.
+formal_package_association *note 12.7(3.1/2): 5266.
+ used *note 12.7(3/2): 5265, *note P: 10420.
+formal_package_declaration *note 12.7(2/3): 5257.
+ used *note 12.1(6): 5057, *note P: 10345.
+formal_part *note 6.1(14): 3548.
+ used *note 6.1(12): 3541, *note 6.1(13/2): 3543, *note P: 10063.
+formal_private_type_definition *note 12.5.1(2): 5192.
+ used *note 12.5(3/2): 5170, *note P: 10389.
+formal_signed_integer_type_definition *note 12.5.2(3): 5207.
+ used *note 12.5(3/2): 5173, *note P: 10392.
+formal_subprogram_declaration *note 12.6(2/2): 5229.
+ used *note 12.1(6): 5056, *note P: 10344.
+formal_type_declaration *note 12.5(2/3): 5158.
+ used *note 12.1(6): 5055, *note P: 10343.
+formal_type_definition *note 12.5(3/2): 5169.
+ used *note 12.5(2.1/3): 5164, *note P: 10385.
+format_effector *note 2.1(13/3): 1182.
+Formatting
+ child of Ada.Calendar *note 9.6.1(15/2): 4493.
+Fortran
+ child of Interfaces *note B.5(4): 8160.
+Fortran interface *note B.5(1/3): 8159.
+Fortran standard *note 1.2(3/2): 1118.
+Fortran_Character
+ in Interfaces.Fortran *note B.5(12/3): 8171.
+Fortran_Integer
+ in Interfaces.Fortran *note B.5(5): 8161.
+forward iterator *note 5.5.2(4/3): 3482.
+Forward_Iterator
+ in Ada.Iterator_Interfaces *note 5.5.1(3/3): 3440.
+Fraction attribute *note A.5.3(21): 6683.
+Fraction_One_Half
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6111.
+Fraction_One_Quarter
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6110.
+Fraction_Three_Quarters
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6112.
+Free
+ in Ada.Strings.Unbounded *note A.4.5(7): 6367.
+ in Interfaces.C.Strings *note B.3.1(11): 8060.
+freed
+ See nonexistent *note 13.11.2(10/2): 5671.
+freeing storage *note 13.11.2(1): 5668.
+freezing
+ by a constituent of a construct *note 13.14(4/1): 5842.
+ by an expression *note 13.14(8/3): 5846.
+ by an implicit call *note 13.14(8.1/3): 5848.
+ by an object name *note 13.14(8/3): 5847.
+ class-wide type caused by the freezing of the specific type *note
+13.14(15): 5865.
+ constituents of a full type definition *note 13.14(15): 5863.
+ designated subtype caused by an allocator *note 13.14(13): 5860.
+ entity *note 13.14(2): 5836.
+ entity caused by a body *note 13.14(3/3): 5840.
+ entity caused by a construct *note 13.14(4/1): 5841.
+ entity caused by a name *note 13.14(11): 5856.
+ entity caused by the end of an enclosing construct *note
+13.14(3/3): 5839.
+ expression of an expression function by a call *note 13.14(10.1/3):
+5852.
+ expression of an expression function by Access attribute *note
+13.14(10.3/3): 5855.
+ expression of an expression function by an instantiation *note
+13.14(10.2/3): 5854.
+ first subtype caused by the freezing of the type *note 13.14(15):
+5864.
+ generic_instantiation *note 13.14(5/3): 5843.
+ nominal subtype caused by a name *note 13.14(11): 5857.
+ object_declaration *note 13.14(6): 5844.
+ profile *note 13.14(2.1/3): 5838.
+ profile of a callable entity by an instantiation *note
+13.14(10.2/3): 5853.
+ profile of a function call *note 13.14(10.1/3): 5851.
+ specific type caused by the freezing of the class-wide type *note
+13.14(15): 5866.
+ subtype caused by a record extension *note 13.14(7): 5845.
+ subtype caused by an implicit conversion *note 13.14(8.2/1): 5849.
+ subtype caused by an implicit dereference *note 13.14(11.1/1):
+5858.
+ subtypes of the profile of a callable entity *note 13.14(14/3):
+5861.
+ type caused by a range *note 13.14(12): 5859.
+ type caused by an expression *note 13.14(10): 5850.
+ type caused by the freezing of a subtype *note 13.14(15): 5862.
+freezing points
+ entity *note 13.14(2): 5837.
+Friday
+ in Ada.Calendar.Formatting *note 9.6.1(17/2): 4499.
+FS
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5977.
+full conformance
+ for discrete_subtype_definitions *note 6.3.1(24): 3681.
+ for expressions *note 6.3.1(19): 3678.
+ for known_discriminant_parts *note 6.3.1(23): 3679.
+ for profiles *note 6.3.1(18/3): 3676.
+ required *note 3.10.1(4/3): 2432, *note 6.3(4): 3646, *note
+6.7(2.1/3): 3803, *note 6.8(4/3): 3815, *note 7.3(9): 3871, *note
+8.3(12.3/2): 4027, *note 8.5.4(5/3): 4119, *note 9.5.2(14): 4379, *note
+9.5.2(16): 4383, *note 9.5.2(17): 4384, *note 10.1.3(11): 4747, *note
+10.1.3(12): 4748.
+full constant declaration *note 3.3.1(6/3): 1569.
+ corresponding to a formal object of mode in *note 12.4(10/2): 5148.
+full declaration *note 7.4(2/3): 3905.
+full name
+ of a file *note A.16(47/2): 7182.
+full stop *note 2.1(15/3): 1201.
+full type *note 3.2.1(8/2): 1453.
+full type definition *note 3.2.1(8/2): 1454.
+full view
+ of a type *note 3.2.1(8/2): 1455.
+Full_Name
+ in Ada.Directories *note A.16(15/2): 7147, *note A.16(39/2): 7169.
+Full_Stop
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5996.
+full_type_declaration *note 3.2.1(3/3): 1433.
+ used *note 3.2.1(2): 1429, *note P: 9657.
+function *note 6(1): 3509, *note N(19.1/2): 9547.
+ expression *note 6.8(6/3): 3817.
+ with a controlling access result *note 3.9.2(2/3): 2304.
+ with a controlling result *note 3.9.2(2/3): 2302.
+function call
+ master of *note 3.10.2(10.1/3): 2454.
+function instance *note 12.3(13): 5112.
+function_call *note 6.4(3): 3693.
+ used *note 4.1(2/3): 2530, *note P: 9837.
+function_specification *note 6.1(4.2/2): 3523.
+ used *note 6.1(4/2): 3519, *note 6.8(2/3): 3811, *note P: 10048.
+
+
+\1f
+File: aarm2012.info, Node: G, Next: H, Prev: F, Up: Index
+
+G
+==
+
+
+
+gaps *note 13.3(52.d/2): 5425.
+general access type *note 3.10(7/1): 2395, *note 3.10(8): 2399.
+general_access_modifier *note 3.10(4): 2380.
+ used *note 3.10(3): 2378, *note P: 9806.
+generalized iterator *note 5.5.2(3/3): 3472.
+generalized_indexing *note 4.1.6(10/3): 2640.
+ used *note 4.1(2/3): 2534, *note P: 9841.
+generalized_reference *note 4.1.5(4/3): 2625.
+ used *note 4.1(2/3): 2533, *note P: 9840.
+generation
+ of an interrupt *note C.3(2): 8194.
+Generator
+ in Ada.Numerics.Discrete_Random *note A.5.2(19): 6636.
+ in Ada.Numerics.Float_Random *note A.5.2(7): 6623.
+generic actual *note 12.3(7/3): 5102.
+generic actual parameter *note 12.3(7/3): 5101.
+generic actual subtype *note 12.5(4): 5181.
+generic actual type *note 12.5(4): 5183.
+generic body *note 12.2(1): 5066.
+generic contract issue *note 10.2.1(10/2): 4820, *note 12.3(11.y):
+5106.
+ [partial] *note 3.2.4(29/3): 1513, *note 3.4(5.1/3): 1616, *note
+3.7(10/3): 2101, *note 3.7.1(7/3): 2131, *note 3.9.1(3/2): 2278, *note
+3.9.4(17/2): 2365, *note 3.10.2(28.1/3): 2468, *note 3.10.2(32/3): 2476,
+*note 4.1.6(9/3): 2639, *note 4.5.2(9.8/3): 2988, *note 4.6(24.17/3):
+3162, *note 4.6(24.21/2): 3169, *note 4.8(5.6/3): 3266, *note 4.9(37/2):
+3324, *note 6.3.1(17.a): 3675, *note 6.5.1(6/2): 3789, *note 7.3(8):
+3870, *note 8.3(26/2): 4046, *note 8.3.1(7/2): 4051, *note 8.5.1(4.6/2):
+4093, *note 8.5.1(5/3): 4094, *note 8.5.4(4.3/2): 4118, *note
+9.1(9.9/2): 4232, *note 9.4(11.13/2): 4307, *note 9.4(11.8/2): 4306,
+*note 9.5(17/3): 4332, *note 9.5.2(13.4/2): 4378, *note 10.2.1(11.7/3):
+4827, *note 10.2.1(11/3): 4824, *note 10.2.1(17/3): 4837, *note
+12.4(8.5/2): 5145, *note 12.6(8.3/2): 5248, *note 13.11.2(3.1/3): 5670,
+*note 13.11.4(23/3): 5715, *note B.3.3(10/3): 8098, *note C.3.1(7/3):
+8207, *note J.15.7(7/3): 9225.
+generic contract model *note 12.3(1.a/3): 5069.
+generic contract/private type contract analogy *note 7.3(19.a): 3879.
+generic formal *note 12.1(9): 5062.
+generic formal object *note 12.4(1): 5126.
+generic formal package *note 12.7(1): 5255.
+generic formal subprogram *note 12.6(1): 5227.
+generic formal subtype *note 12.5(5): 5187.
+generic formal type *note 12.5(5): 5185.
+generic function *note 12.1(8/2): 5061.
+generic package *note 12.1(8/2): 5058.
+generic procedure *note 12.1(8/2): 5060.
+generic subprogram *note 12.1(8/2): 5059.
+generic unit *note 12(1): 5035, *note N(20): 9548.
+ See also dispatching operation *note 3.9(1): 2211.
+generic_actual_part *note 12.3(3): 5086.
+ used *note 12.3(2/3): 5079, *note 12.7(3/2): 5263, *note P: 10348.
+Generic_Array_Sort
+ child of Ada.Containers *note A.18.26(3/2): 7878.
+generic_association *note 12.3(4): 5089.
+ used *note 12.3(3): 5087, *note 12.7(3.1/2): 5267, *note P: 10361.
+Generic_Bounded_Length
+ in Ada.Strings.Bounded *note A.4.4(4): 6301.
+Generic_Complex_Arrays
+ child of Ada.Numerics *note G.3.2(2/2): 9005.
+Generic_Complex_Elementary_Functions
+ child of Ada.Numerics *note G.1.2(2/2): 8894.
+Generic_Complex_Types
+ child of Ada.Numerics *note G.1.1(2/1): 8866.
+Generic_Constrained_Array_Sort
+ child of Ada.Containers *note A.18.26(7/2): 7880.
+generic_declaration *note 12.1(2): 5040.
+ used *note 3.1(3/3): 1356, *note 10.1.1(5): 4662, *note P: 9654.
+Generic_Dispatching_Constructor
+ child of Ada.Tags *note 3.9(18.2/3): 2254.
+Generic_Elementary_Functions
+ child of Ada.Numerics *note A.5.1(3): 6585.
+generic_formal_parameter_declaration *note 12.1(6): 5053.
+ used *note 12.1(5): 5051, *note P: 10340.
+generic_formal_part *note 12.1(5): 5050.
+ used *note 12.1(3/3): 5044, *note 12.1(4): 5048, *note P: 10338.
+generic_instantiation *note 12.3(2/3): 5071.
+ used *note 3.1(3/3): 1357, *note 10.1.1(5): 4663, *note P: 10289.
+Generic_Keys
+ in Ada.Containers.Hashed_Sets *note A.18.8(50/2): 7614.
+ in Ada.Containers.Ordered_Sets *note A.18.9(62/2): 7695.
+generic_package_declaration *note 12.1(4): 5047.
+ used *note 12.1(2): 5042, *note P: 10334.
+Generic_Real_Arrays
+ child of Ada.Numerics *note G.3.1(2/2): 8988.
+generic_renaming_declaration *note 8.5.5(2/3): 4128.
+ used *note 8.5(2): 4077, *note 10.1.1(6): 4666, *note P: 10291.
+Generic_Sort
+ child of Ada.Containers *note A.18.26(9.2/3): 7882.
+Generic_Sorting
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(47/2): 7384.
+ in Ada.Containers.Vectors *note A.18.2(75/2): 7309.
+generic_subprogram_declaration *note 12.1(3/3): 5043.
+ used *note 12.1(2): 5041, *note P: 10333.
+Get
+ in Ada.Text_IO *note A.10.1(41): 6929, *note A.10.1(47): 6940,
+*note A.10.1(54): 6952, *note A.10.1(55): 6956, *note A.10.1(59): 6962,
+*note A.10.1(60): 6965, *note A.10.1(65): 6971, *note A.10.1(67): 6975,
+*note A.10.1(70): 6981, *note A.10.1(72): 6985, *note A.10.1(75): 6992,
+*note A.10.1(77): 6995, *note A.10.1(81): 7001, *note A.10.1(83): 7004.
+ in Ada.Text_IO.Complex_IO *note G.1.3(6): 8928, *note G.1.3(8):
+8931.
+Get_CPU
+ in Ada.Interrupts *note C.3.2(10.1/3): 8234.
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(13/3):
+8681.
+Get_Deadline
+ in Ada.Dispatching.EDF *note D.2.6(9/2): 8400.
+Get_Dispatching_Domain
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(10/3):
+8678.
+Get_First_CPU
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(8/3):
+8676.
+Get_Immediate
+ in Ada.Text_IO *note A.10.1(44): 6936, *note A.10.1(45): 6937.
+Get_Last_CPU
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(9/3):
+8677.
+Get_Line
+ in Ada.Text_IO *note A.10.1(49): 6943, *note A.10.1(49.1/2): 6946.
+ in Ada.Text_IO.Bounded_IO *note A.10.11(8/2): 7035, *note
+A.10.11(9/2): 7036, *note A.10.11(10/2): 7037, *note A.10.11(11/2):
+7038.
+ in Ada.Text_IO.Unbounded_IO *note A.10.12(8/2): 7045, *note
+A.10.12(9/2): 7046, *note A.10.12(10/2): 7047, *note A.10.12(11/2):
+7048.
+Get_Next_Entry
+ in Ada.Directories *note A.16(35/2): 7167.
+Get_Priority
+ in Ada.Dynamic_Priorities *note D.5.1(5): 8445.
+global to *note 8.1(15): 3995.
+Glossary *note N(1/2): 9513.
+glyphs *note 2.1(15.a/3): 1217.
+goto_statement *note 5.8(2): 3503.
+ used *note 5.1(4/2): 3348, *note P: 9993.
+govern a variant *note 3.8.1(20): 2203.
+govern a variant_part *note 3.8.1(20): 2202.
+grammar
+ ambiguous *note 1.1.4(14.a): 1085.
+ complete listing *note P: 9592.
+ cross reference *note P: 10472.
+ notation *note 1.1.4(3): 1077.
+ resolution of ambiguity *note 1.1.4(14.a): 1084, *note 8.6(3):
+4142.
+ under Syntax heading *note 1.1.2(25): 1014.
+graphic character
+ a category of Character *note A.3.2(23): 5936.
+graphic symbols *note 2.1(15.a/3): 1216.
+graphic_character *note 2.1(14/3): 1187.
+ used *note 2.5(2): 1293, *note 2.6(3): 1298, *note P: 9628.
+Graphic_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6419.
+Grave
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6010.
+greater than operator *note 4.4(1/3): 2801, *note 4.5.2(1): 2976.
+greater than or equal operator *note 4.4(1/3): 2805, *note 4.5.2(1):
+2980.
+greater-than sign *note 2.1(15/3): 1210.
+Greater_Than_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(10): 6002.
+Group_Budget
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(4/3): 8620.
+Group_Budget_Error
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(11/2): 8636.
+Group_Budget_Handler
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(5/2): 8621.
+Group_Budgets
+ child of Ada.Execution_Time *note D.14.2(3/3): 8619.
+GS
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5978.
+guard *note 9.7.1(3): 4540.
+ used *note 9.7.1(2): 4535, *note P: 10248.
+
+
+\1f
+File: aarm2012.info, Node: H, Next: I, Prev: G, Up: Index
+
+H
+==
+
+
+
+handle
+ an exception *note 11(1/3): 4867, *note N(18): 9543.
+ an exception occurrence *note 11(1.a): 4868.
+ an exception occurrence *note 11.4(1): 4913, *note 11.4(7): 4924.
+ subpool *note 13.11.4(18/3): 5710.
+handled_sequence_of_statements *note 11.2(2): 4886.
+ used *note 5.6(2): 3495, *note 6.3(2/3): 3644, *note 6.5(2.2/3):
+3749, *note 7.2(2/3): 3846, *note 9.1(6/3): 4221, *note 9.5.2(3): 4357,
+*note 9.5.2(5): 4366, *note P: 10039.
+handler *note 11.2(5.a): 4899.
+ execution timer *note D.14.1(13/2): 8615.
+ group budget *note D.14.2(14/2): 8640.
+ interrupt *note C.3(2): 8201.
+ termination *note C.7.3(8/3): 8313.
+ timing event *note D.15(10/2): 8661.
+Handling
+ child of Ada.Characters *note A.3.2(2/2): 5907.
+ child of Ada.Wide_Characters *note A.3.5(3/3): 6198.
+ child of Ada.Wide_Wide_Characters *note A.3.6(1/3): 6220.
+Has_Element
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(9.1/3): 7342.
+ in Ada.Containers.Hashed_Maps *note A.18.5(6.1/3): 7433.
+ in Ada.Containers.Hashed_Sets *note A.18.8(6.1/3): 7572.
+ in Ada.Containers.Multiway_Trees *note A.18.10(12/3): 7738.
+ in Ada.Containers.Ordered_Maps *note A.18.6(7.1/3): 7489.
+ in Ada.Containers.Ordered_Sets *note A.18.9(7.1/3): 7648.
+ in Ada.Containers.Vectors *note A.18.2(11.1/3): 7243.
+Has_Same_Storage attribute *note 13.3(73.2/3): 5444.
+Hash
+ child of Ada.Strings *note A.4.9(2/3): 6518.
+ child of Ada.Strings.Bounded *note A.4.9(7/3): 6519.
+ child of Ada.Strings.Unbounded *note A.4.9(10/3): 6520.
+Hash_Case_Insensitive
+ child of Ada.Strings *note A.4.9(11.2/3): 6521.
+ child of Ada.Strings.Bounded *note A.4.9(11.7/3): 6523.
+ child of Ada.Strings.Fixed *note A.4.9(11.5/3): 6522.
+ child of Ada.Strings.Unbounded *note A.4.9(11.10/3): 6524.
+Hash_Type
+ in Ada.Containers *note A.18.1(4/2): 7226.
+Hashed_Maps
+ child of Ada.Containers *note A.18.5(2/3): 7428.
+Hashed_Sets
+ child of Ada.Containers *note A.18.8(2/3): 7567.
+Head
+ in Ada.Strings.Bounded *note A.4.4(70): 6352, *note A.4.4(71):
+6353.
+ in Ada.Strings.Fixed *note A.4.3(35): 6293, *note A.4.3(36): 6294.
+ in Ada.Strings.Unbounded *note A.4.5(65): 6409, *note A.4.5(66):
+6410.
+head (of a queue) *note D.2.1(5/2): 8346.
+heap management
+ user-defined *note 13.11(1): 5621.
+ See also allocator *note 4.8(1): 3253.
+Heart of Darkness *note 3.10.2(3.b/3): 2448.
+held priority *note D.11(4/2): 8577.
+heterogeneous input-output *note A.12.1(1): 7062.
+hexadecimal
+ literal *note 2.4.2(1): 1277.
+hexadecimal digit
+ a category of Character *note A.3.2(30): 5942.
+hexadecimal literal *note 2.4.2(1): 1275.
+Hexadecimal_Digit_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6425.
+hidden from all visibility *note 8.3(5): 4019, *note 8.3(14): 4030.
+ by lack of a with_clause *note 8.3(20/2): 4034.
+ for a declaration completed by a subsequent declaration *note
+8.3(19): 4033.
+ for overridden declaration *note 8.3(15): 4031.
+ within the declaration itself *note 8.3(16): 4032.
+hidden from direct visibility *note 8.3(5): 4020, *note 8.3(21): 4039.
+ by an inner homograph *note 8.3(22): 4040.
+ where hidden from all visibility *note 8.3(23): 4041.
+hiding *note 8.3(5): 4018.
+Hierarchical_File_Names
+ child of Ada.Directories *note A.16.1(3/3): 7191.
+High_Order_First *note 13.5.3(2): 5513.
+ in Interfaces.COBOL *note B.4(25): 8131.
+ in System *note 13.7(15/2): 5549.
+highest precedence operator *note 4.5.6(1): 3061.
+highest_precedence_operator *note 4.5(7): 2921.
+Hold
+ in Ada.Asynchronous_Task_Control *note D.11(3/2): 8573.
+Holder
+ in Ada.Containers.Indefinite_Holders *note A.18.18(6/3): 7825.
+homograph *note 8.3(8): 4023.
+Hour
+ in Ada.Calendar.Formatting *note 9.6.1(24/2): 4510.
+Hour_Number subtype of Natural
+ in Ada.Calendar.Formatting *note 9.6.1(20/2): 4503.
+HT
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5958.
+HTJ
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6056.
+HTS
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6055.
+Hyphen
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5994.
+hyphen-minus *note 2.1(15/3): 1199.
+
+
+\1f
+File: aarm2012.info, Node: I, Next: J, Prev: H, Up: Index
+
+I
+==
+
+
+
+i
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(5): 8869.
+ in Interfaces.Fortran *note B.5(10): 8168.
+identifier *note 2.3(2/2): 1230.
+ used *note 2.8(2): 1305, *note 2.8(3/3): 1311, *note 2.8(21): 1331,
+*note 2.8(23): 1336, *note 3.1(4): 1359, *note 4.1(3): 2536, *note
+4.1.3(3): 2588, *note 4.1.4(3/2): 2607, *note 5.5(2): 3424, *note
+5.6(2): 3496, *note 6.1(5): 3528, *note 7.1(3/3): 3833, *note 7.2(2/3):
+3848, *note 9.1(4): 4213, *note 9.1(6/3): 4222, *note 9.4(4): 4278,
+*note 9.4(7/3): 4290, *note 9.5.2(3): 4358, *note 9.5.2(5): 4367, *note
+11.4.2(6.1/3): 4966, *note 11.4.2(6/2): 4962, *note 11.5(4.1/2): 4992,
+*note 11.5(4/2): 4989, *note 13.1.1(3/3): 5332, *note 13.1.1(4/3): 5336,
+*note 13.12(4/2): 5734, *note 13.12(11/3): 5744, *note D.2.2(3): 8356,
+*note D.2.2(3.2/2): 8359, *note D.3(3): 8409, *note D.3(4): 8410, *note
+D.3(4.a): 8412, *note D.4(3): 8432, *note D.4(4): 8434, *note H.6(3/2):
+9114, *note J.10(3/2): 9149, *note J.15.5(2/3): 9195, *note J.15.5(3/3):
+9201, *note J.15.5(4/3): 9207, *note L(2.2/2): 9337, *note L(2.3/3):
+9341, *note L(8.1/3): 9359, *note L(13.1/3): 9387, *note L(14.1/3):
+9393, *note L(20): 9421, *note L(21): 9424, *note L(23): 9433, *note
+L(25.1/2): 9441, *note L(27.2/2): 9452, *note L(27.3/3): 9457, *note
+L(29): 9464, *note L(36): 9487, *note L(37): 9490, *note L(37.3/2):
+9496, *note M.2(98): 9510, *note P: 9842.
+identifier specific to a pragma *note 2.8(10/3): 1321.
+identifier_extend *note 2.3(3.1/3): 1241.
+ used *note 2.3(2/2): 1233, *note P: 9598.
+identifier_start *note 2.3(3/2): 1234.
+ used *note 2.3(2/2): 1232, *note P: 9596.
+Identity
+ in Ada.Strings.Maps *note A.4.2(22): 6253.
+ in Ada.Strings.Wide_Maps *note A.4.7(22): 6465.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(22/2): 6507.
+Identity attribute *note 11.4.1(9): 4947, *note C.7.1(12): 8283.
+idle task *note D.11(4/2): 8578.
+IEC 559:1989 *note G.2.2(11.a): 8968.
+IEEE floating point arithmetic *note B.2(10.a): 7983, *note
+G.2.2(11.a): 8967.
+if_expression *note 4.5.7(3/3): 3085.
+ used *note 4.5.7(2/3): 3083, *note P: 9950.
+if_statement *note 5.3(2): 3397.
+ used *note 5.1(5/2): 3358, *note P: 10002.
+illegal
+ construct *note 1.1.2(27): 1025.
+ partition *note 1.1.2(29): 1033.
+Im
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(7/2): 9009,
+*note G.3.2(27/2): 9022.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(6): 8872.
+image
+ of a value *note 3.5(27.3/2): 1723, *note 3.5(30/3): 1728, *note
+K.2(273/3): 9325, *note K.2(277.4/2): 9326.
+ in Ada.Calendar.Formatting *note 9.6.1(35/2): 4521, *note
+9.6.1(37/2): 4523.
+ in Ada.Numerics.Discrete_Random *note A.5.2(26): 6644.
+ in Ada.Numerics.Float_Random *note A.5.2(14): 6632.
+ in Ada.Task_Identification *note C.7.1(3/3): 8275.
+ in Ada.Text_IO.Editing *note F.3.3(13): 8855.
+Image attribute *note 3.5(35): 1730.
+Imaginary
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(4/2): 8868.
+Imaginary subtype of Imaginary
+ in Interfaces.Fortran *note B.5(10): 8167.
+immediate scope
+ of (a view of) an entity *note 8.2(11): 4006.
+ of a declaration *note 8.2(2): 3996.
+Immediate_Reclamation restriction *note H.4(10): 9080.
+immediately enclosing *note 8.1(13): 3992.
+immediately visible *note 8.3(4): 4016, *note 8.3(21): 4036.
+immediately within *note 8.1(13): 3990.
+immutably limited *note 7.5(8.1/3): 3911.
+implementation *note 1.1.3(1.a): 1065.
+implementation advice *note 1.1.2(37): 1046.
+ summary of advice *note M.3(1/2): 9511.
+implementation defined *note 1.1.3(18): 1070.
+ summary of characteristics *note M.2(1/2): 9506.
+implementation permissions *note 1.1.2(36): 1045.
+implementation requirements *note 1.1.2(33): 1042.
+implementation-dependent
+ See unspecified *note 1.1.3(18): 1073.
+implemented
+ by a protected entry *note 9.4(11.1/3): 4300.
+ by a protected subprogram *note 9.4(11.1/3): 4299.
+ by a task entry *note 9.1(9.2/3): 4226.
+implicit conversion
+ legality *note 8.6(27.1/3): 4164.
+implicit declaration *note 3.1(5): 1362, *note N(11): 9532.
+implicit initial values
+ for a subtype *note 3.3.1(10): 1579.
+implicit subtype conversion *note 4.6(59): 3227, *note 4.6(60): 3228.
+ Access attribute *note 3.10.2(30): 2472.
+ access discriminant *note 3.7(27/2): 2114.
+ array bounds *note 4.6(38): 3188.
+ array index *note 4.1.1(7): 2568.
+ assignment to view conversion *note 4.6(55): 3222.
+ assignment_statement *note 5.2(11): 3391.
+ bounds of a decimal fixed point type *note 3.5.9(16): 1955.
+ bounds of a fixed point type *note 3.5.9(14): 1950.
+ bounds of a range *note 3.5(9): 1692, *note 3.6(18): 2025.
+ choices of aggregate *note 4.3.3(22): 2759.
+ component defaults *note 3.3.1(13/3): 1581.
+ default value of a scalar *note 3.3.1(11.1/3): 1580.
+ delay expression *note 9.6(20): 4475.
+ derived type discriminants *note 3.4(21): 1630.
+ discriminant values *note 3.7.1(12): 2135.
+ entry index *note 9.5.2(24): 4393.
+ expressions in aggregate *note 4.3.1(19): 2704.
+ expressions of aggregate *note 4.3.3(23): 2760.
+ function return *note 6.5(5.11/3): 3760, *note 6.5(6/2): 3768.
+ generic formal object of mode in *note 12.4(11): 5154.
+ inherited enumeration literal *note 3.4(29): 1636.
+ initialization expression *note 3.3.1(17): 1583.
+ initialization expression of allocator *note 4.8(7/2): 3271.
+ Interrupt_Priority aspect *note D.1(17/3): 8335, *note D.3(6.1/3):
+8418.
+ named number value *note 3.3.2(6): 1602.
+ operand of concatenation *note 4.5.3(9): 3024.
+ parameter passing *note 6.4.1(10): 3724, *note 6.4.1(11): 3726,
+*note 6.4.1(17): 3734.
+ Priority aspect *note D.1(17/3): 8334, *note D.3(6.1/3): 8417.
+ qualified_expression *note 4.7(4): 3249.
+ reading a view conversion *note 4.6(56): 3223.
+ result of inherited function *note 3.4(27/2): 1634.
+implicit_dereference *note 4.1(6): 2543.
+ used *note 4.1(4): 2540, *note P: 9845.
+Implicit_Dereference aspect *note 4.1.5(2/3): 2621.
+Import aspect *note B.1(1/3): 7942.
+Import pragma *note J.15.5(2/3): 9194, *note L(14.1/3): 9392.
+imported entity *note B.1(23/3): 7966.
+in (membership test) *note 4.4(1/3): 2807, *note 4.5.2(2/3): 2984.
+inaccessible partition *note E.1(7): 8698.
+inactive
+ a task state *note 9(10): 4188.
+Include
+ in Ada.Containers.Hashed_Maps *note A.18.5(22/2): 7456.
+ in Ada.Containers.Hashed_Sets *note A.18.8(21/2): 7590.
+ in Ada.Containers.Ordered_Maps *note A.18.6(21/2): 7510.
+ in Ada.Containers.Ordered_Sets *note A.18.9(20/2): 7664.
+included
+ one execution by another *note 11.4(2.a): 4918.
+ one range in another *note 3.5(4): 1679.
+incompatibilities with Ada 2005 *note 1.1.2(39.cc/3): 1061, *note
+2.3(8.d/3): 1248, *note 2.9(3.e/3): 1341, *note 3.4(38.m/3): 1641, *note
+3.5.1(16.c/3): 1784, *note 3.7(37.l/3): 2117, *note 3.8.1(29.e/3): 2206,
+*note 3.9(33.j/3): 2269, *note 3.9.3(16.j/3): 2337, *note
+3.10.2(41.p/3): 2487, *note 4.3.1(31.e/3): 2708, *note 4.3.2(13.e/3):
+2728, *note 4.5.2(39.k/3): 3001, *note 4.8(20.o/3): 3302, *note
+4.9.1(10.d/3): 3334, *note 6.3.1(25.h/3): 3684, *note 6.4.1(18.d/3):
+3739, *note 6.5(28.q/3): 3783, *note 8.5.1(8.g/3): 4097, *note
+8.6(34.v/3): 4176, *note 9.4(35.g/3): 4319, *note 10.1.2(31.i/3): 4722,
+*note 10.2.1(28.k/3): 4858, *note 11.4.2(28.b/3): 4978, *note
+12.5.1(28.i/3): 5204, *note 12.5.4(13.e/3): 5223, *note 12.6(24.d/3):
+5253, *note 12.7(25.e/3): 5274, *note 13.1(29.p/3): 5324, *note
+13.3(85.n/3): 5455, *note 13.13.2(60.u/3): 5834, *note A.3.2(60.d/3):
+5946, *note A.4.3(109.d/3): 6299, *note A.4.4(106.i/3): 6361, *note
+A.4.5(88.e/3): 6416, *note A.16(131.e/3): 7190, *note A.17(33.c/3):
+7216, *note A.18.1(8.d/3): 7230, *note A.18.2(264.c/3): 7331, *note
+A.18.3(164.c/3): 7405, *note A.18.5(62.d/3): 7481, *note A.18.6(95.e/3):
+7542, *note A.18.8(88.d/3): 7640, *note A.18.9(116.d/3): 7721, *note
+B.1(51.d/3): 7978, *note B.3(84.i/3): 8051, *note B.3.3(32.b/3): 8102,
+*note C.3.1(25.e/3): 8223, *note C.3.2(28.b/3): 8240, *note C.6(24.d/3):
+8270, *note C.7.1(21.d/3): 8292, *note D.2.1(17.b/3): 8353, *note
+D.7(22.g/3): 8519, *note D.14(29.c/3): 8602, *note E.2.2(20.j/3): 8742,
+*note E.2.3(20.e/3): 8768, *note J.15.7(8.a/3): 9226.
+incompatibilities with Ada 83 *note 1.1.2(39.e): 1050, *note
+2.8(19.c): 1326, *note 2.9(3.a): 1339, *note 3.2.2(15.a): 1488, *note
+3.2.3(8.a): 1497, *note 3.4(38.b): 1638, *note 3.5(63.a/1): 1764, *note
+3.5.2(11.b): 1798, *note 3.6.3(8.b): 2072, *note 4.2(14.a): 2665, *note
+4.3.3(45.a.1/1): 2770, *note 4.5.5(35.a.1/2): 3058, *note 4.6(71.a):
+3230, *note 4.8(20.a/1): 3297, *note 4.9(44.m): 3326, *note
+5.4(18.a.1/1): 3418, *note 6.5(28.a/2): 3778, *note 7.1(17.a): 3840,
+*note 8.6(34.a): 4170, *note 12.3(29.b): 5122, *note 12.5.1(28.a): 5202,
+*note 12.5.3(16.a): 5216, *note 12.5.4(13.a): 5221, *note 13.1(29.a):
+5321, *note 13.14(20.a): 5869, *note A.5.3(72.d): 6747, *note
+A.5.4(4.a): 6757, *note A.8.1(17.a): 6805, *note A.10.1(86.a): 7015,
+*note C.6(24.a): 8269, *note J.15.1(6.a/3): 9162.
+incompatibilities with Ada 95 *note 1.1.2(39.p/2): 1056, *note
+2.9(3.c/2): 1340, *note 3.7.1(15.c/2): 2137, *note 3.9(33.d/3): 2266,
+*note 3.9.2(24.b/2): 2318, *note 3.10(26.e/2): 2422, *note
+3.10.1(23.h/2): 2436, *note 3.10.2(41.b/2): 2485, *note 4.3(6.e/2):
+2682, *note 4.3.2(13.b/2): 2726, *note 4.5.5(35.d/2): 3060, *note
+4.6(71.j/2): 3232, *note 4.8(20.g/2): 3300, *note 5.2(28.d/2): 3396,
+*note 6.5(28.g/2): 3780, *note 8.3(29.s/2): 4049, *note 8.5.1(8.b/2):
+4095, *note 8.6(34.n/2): 4174, *note 9.7.2(7.b/3): 4570, *note
+10.1.2(31.f/2): 4719, *note 10.2.1(28.e/2): 4856, *note 11.4.1(19.bb/3):
+4952, *note 13.5.1(31.d/2): 5500, *note 13.5.2(5.c/2): 5511, *note
+13.11(43.d/2): 5657, *note 13.11.3(9.b/3): 5692, *note 13.14(20.p/2):
+5871, *note 13.14(20.t/3): 5872, *note A.4.1(6.a/3): 6236, *note
+A.4.3(109.a/3): 6298, *note A.4.4(106.f/3): 6360, *note A.4.5(88.b/2):
+6414, *note A.4.7(48.a/2): 6472, *note A.5.2(61.a/2): 6655, *note
+A.8.1(17.b/2): 6806, *note A.8.4(20.a/2): 6838, *note A.10.1(86.c/2):
+7017, *note A.10.7(26.a/3): 7025, *note A.12.1(36.b/2): 7102, *note
+B.3(84.a/3): 8049, *note C.3.1(25.a/2): 8221, *note D.7(22.a/2): 8517,
+*note D.8(51.a/3): 8549, *note E.2.2(20.b/3): 8740, *note E.2.3(20.b/3):
+8767, *note E.5(30.a/2): 8822.
+incomplete type *note 3.2(4.1/2): 1402, *note 3.10.1(2.1/2): 2427,
+*note N(20.1/2): 9549.
+incomplete view *note 3.10.1(2.1/2): 2428.
+ tagged *note 3.10.1(2.1/2): 2429.
+incomplete_type_declaration *note 3.10.1(2/2): 2424.
+ used *note 3.2.1(2): 1430, *note P: 9658.
+inconsistencies with Ada 2005 *note 1.1.2(39.z/3): 1059, *note
+2.1(19.g/3): 1220, *note 3.5(63.l/3): 1767, *note 3.9(33.i/3): 2268,
+*note 4.3.2(13.d/3): 2727, *note 4.3.3(45.i/3): 2773, *note
+4.5.2(39.i/3): 3000, *note 4.6(71.u/3): 3234, *note 6.4.1(18.c/3): 3738,
+*note 6.5(28.n/3): 3782, *note 7.6.1(24.cc/3): 3987, *note
+8.5.4(21.f.1/3): 4126, *note 9.6.1(91.c/3): 4526, *note 13.3(85.l/3):
+5454, *note A.10.5(52.a/3): 7019, *note A.10.8(27.a/3): 7028, *note
+A.16(131.d/3): 7189, *note A.18.3(164.b/3): 7404, *note D.14.2(38.b/3):
+8645.
+inconsistencies with Ada 83 *note 1.1.2(39.b): 1049, *note 3.4(38.a):
+1637, *note 3.5.2(11.a): 1797, *note 3.5.7(22.a): 1918, *note
+3.5.9(28.a): 1963, *note 3.6.3(8.a): 2071, *note 3.7.1(15.a): 2136,
+*note 4.5.3(14.a): 3026, *note 4.5.6(13.a.1/1): 3081, *note 9.6(40.a):
+4482, *note 11.1(8.a): 4884, *note 12.3(29.a): 5121, *note
+13.3(58.a.1/2): 5428, *note A.6(1.a): 6761, *note G.2.1(16.c): 8952,
+*note G.2.3(27.b): 8974.
+inconsistencies with Ada 95 *note 1.1.2(39.m/2): 1053, *note
+3.3.1(33.f/2): 1593, *note 3.5.2(11.h/2): 1800, *note 3.6.3(8.g/2):
+2074, *note 3.9(33.b/2): 2265, *note 3.10(26.c/2): 2421, *note
+4.8(20.f/2): 3299, *note 4.9(44.s/2): 3327, *note 6.5(28.f.1/3): 3779,
+*note 7.6.1(24.v.1/3): 3986, *note 9.6(40.e/2): 4484, *note
+11.4.1(19.y/2): 4951, *note 13.13.2(60.g/2): 5832, *note A.4.4(106.e/2):
+6359, *note A.12.1(36.a/3): 7101, *note B.3.1(60.a/2): 8074.
+Increment
+ in Interfaces.C.Pointers *note B.3.2(11/3): 8081.
+indefinite subtype *note 3.3(23/3): 1535, *note 3.7(26): 2113.
+Indefinite_Doubly_Linked_Lists
+ child of Ada.Containers *note A.18.12(2/3): 7811.
+Indefinite_Hashed_Maps
+ child of Ada.Containers *note A.18.13(2/3): 7813.
+Indefinite_Hashed_Sets
+ child of Ada.Containers *note A.18.15(2/3): 7817.
+Indefinite_Holders
+ child of Ada.Containers *note A.18.18(5/3): 7824.
+Indefinite_Multiway_Trees
+ child of Ada.Containers *note A.18.17(2/3): 7821.
+Indefinite_Ordered_Maps
+ child of Ada.Containers *note A.18.14(2/3): 7815.
+Indefinite_Ordered_Sets
+ child of Ada.Containers *note A.18.16(2/3): 7819.
+Indefinite_Vectors
+ child of Ada.Containers *note A.18.11(2/3): 7809.
+Independent aspect *note C.6(6.3/3): 8252.
+Independent pragma *note J.15.8(4/3): 9234, *note L(14.2/3): 9398.
+independent subprogram *note 11.6(6/3): 5031.
+Independent_Components aspect *note C.6(6.9/3): 8260.
+Independent_Components pragma *note J.15.8(7/3): 9243, *note
+L(14.3/3): 9401.
+independently addressable *note 9.10(1/3): 4628.
+ specified *note C.6(8.1/3): 8264.
+index
+ of an array *note 3.6(9.a): 2010.
+ of an element of an open direct file *note A.8(3): 6778.
+ in Ada.Direct_IO *note A.8.4(15): 6827.
+ in Ada.Streams.Stream_IO *note A.12.1(23): 7088.
+ in Ada.Strings.Bounded *note A.4.4(43.1/2): 6323, *note
+A.4.4(43.2/2): 6324, *note A.4.4(44): 6325, *note A.4.4(45): 6326, *note
+A.4.4(45.1/2): 6327, *note A.4.4(46): 6328.
+ in Ada.Strings.Fixed *note A.4.3(8.1/2): 6264, *note A.4.3(8.2/2):
+6265, *note A.4.3(9): 6266, *note A.4.3(10): 6267, *note A.4.3(10.1/2):
+6268, *note A.4.3(11): 6269.
+ in Ada.Strings.Unbounded *note A.4.5(38.1/2): 6380, *note
+A.4.5(38.2/2): 6381, *note A.4.5(39): 6382, *note A.4.5(40): 6383, *note
+A.4.5(40.1/2): 6384, *note A.4.5(41): 6385.
+index range *note 3.6(13): 2015.
+index subtype *note 3.6(9): 2008.
+index type *note 3.6(9): 2009.
+Index_Check *note 11.5(14): 5003.
+ [partial] *note 4.1.1(7): 2569, *note 4.1.2(7): 2579, *note
+4.3.3(29/3): 2765, *note 4.3.3(30): 2767, *note 4.5.3(8): 3021, *note
+4.6(51/3): 3209, *note 4.7(4): 3247, *note 4.8(10/2): 3274.
+index_constraint *note 3.6.1(2): 2038.
+ used *note 3.2.2(7): 1479, *note P: 9687.
+Index_Error
+ in Ada.Strings *note A.4.1(5): 6229.
+Index_Non_Blank
+ in Ada.Strings.Bounded *note A.4.4(46.1/2): 6329, *note A.4.4(47):
+6330.
+ in Ada.Strings.Fixed *note A.4.3(11.1/2): 6270, *note A.4.3(12):
+6271.
+ in Ada.Strings.Unbounded *note A.4.5(41.1/2): 6386, *note
+A.4.5(42): 6387.
+index_subtype_definition *note 3.6(4): 1995.
+ used *note 3.6(3): 1992, *note P: 9742.
+indexable container object *note 4.1.6(5/3): 2638.
+indexable container type *note 4.1.6(5/3): 2637, *note N(20.2/3):
+9550.
+indexed_component *note 4.1.1(2): 2560.
+ used *note 4.1(2/3): 2525, *note P: 9832.
+indexing
+ constant *note 4.1.6(12/3): 2645.
+ variable *note 4.1.6(16/3): 2647.
+individual membership test *note 4.5.2(26.1/3): 2994.
+indivisible *note C.6(10/3): 8265.
+inferable discriminants *note B.3.3(20/2): 8099.
+Information
+ child of Ada.Directories *note A.16(124/2): 7187.
+information hiding
+ See package *note 7(1): 3821.
+ See private types and private extensions *note 7.3(1): 3853.
+information systems *note C(1): 8183, *note F(1): 8823.
+informative *note 1.1.2(18): 1010.
+inherently mutable object *note 3.3(13/3): 1529.
+inheritance
+ See derived types and classes *note 3.4(1/2): 1606.
+ See also tagged types and type extension *note 3.9(1): 2215.
+inherited
+ from an ancestor type *note 3.4.1(11): 1661.
+inherited component *note 3.4(11): 1622, *note 3.4(12): 1623.
+inherited discriminant *note 3.4(11): 1621.
+inherited entry *note 3.4(12): 1625.
+inherited protected subprogram *note 3.4(12): 1624.
+inherited subprogram *note 3.4(17/2): 1626.
+Initial_Directory
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(12/3):
+7200.
+initialization
+ of a protected object *note 9.4(14): 4311.
+ of a protected object *note C.3.1(10/3): 8209, *note C.3.1(11/3):
+8213.
+ of a task object *note 9.1(12/1): 4236, *note J.7.1(7): 9138.
+ of an object *note 3.3.1(18/2): 1585.
+initialization expression *note 3.3.1(1/3): 1544, *note 3.3.1(4):
+1567.
+Initialize *note 7.6(2): 3924.
+ in Ada.Finalization *note 7.6(6/2): 3929, *note 7.6(8/2): 3933.
+initialized allocator *note 4.8(4): 3263.
+initialized by default *note 3.3.1(18/2): 1584.
+Inline aspect *note 6.3.2(5.1/3): 3686.
+Inline pragma *note J.15.1(2/3): 9159, *note L(15.1/3): 9404.
+innermost dynamically enclosing *note 11.4(2): 4917.
+input *note A.6(1/2): 6759.
+Input aspect *note 13.13.2(38/3): 5825.
+Input attribute *note 13.13.2(22): 5802, *note 13.13.2(32): 5806.
+Input clause *note 13.3(7/2): 5381, *note 13.13.2(38/3): 5818.
+input-output
+ unspecified for access types *note A.7(6): 6768.
+Insert
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(19/2): 7357,
+*note A.18.3(20/2): 7358, *note A.18.3(21/2): 7359.
+ in Ada.Containers.Hashed_Maps *note A.18.5(19/2): 7453, *note
+A.18.5(20/2): 7454, *note A.18.5(21/2): 7455.
+ in Ada.Containers.Hashed_Sets *note A.18.8(19/2): 7588, *note
+A.18.8(20/2): 7589.
+ in Ada.Containers.Ordered_Maps *note A.18.6(18/2): 7507, *note
+A.18.6(19/2): 7508, *note A.18.6(20/2): 7509.
+ in Ada.Containers.Ordered_Sets *note A.18.9(18/2): 7662, *note
+A.18.9(19/2): 7663.
+ in Ada.Containers.Vectors *note A.18.2(36/2): 7271, *note
+A.18.2(37/2): 7272, *note A.18.2(38/2): 7273, *note A.18.2(39/2): 7274,
+*note A.18.2(40/2): 7275, *note A.18.2(41/2): 7276, *note A.18.2(42/2):
+7277, *note A.18.2(43/2): 7278.
+ in Ada.Strings.Bounded *note A.4.4(60): 6342, *note A.4.4(61):
+6343.
+ in Ada.Strings.Fixed *note A.4.3(25): 6283, *note A.4.3(26): 6284.
+ in Ada.Strings.Unbounded *note A.4.5(55): 6399, *note A.4.5(56):
+6400.
+Insert_Child
+ in Ada.Containers.Multiway_Trees *note A.18.10(48/3): 7773, *note
+A.18.10(49/3): 7774, *note A.18.10(50/3): 7775.
+Insert_Space
+ in Ada.Containers.Vectors *note A.18.2(48/2): 7283, *note
+A.18.2(49/2): 7284.
+inspectable object *note H.3.2(5/2): 9066.
+inspection point *note H.3.2(5/2): 9065.
+Inspection_Point pragma *note H.3.2(3): 9062, *note L(16): 9408.
+instance
+ of a generic function *note 12.3(13): 5116.
+ of a generic package *note 12.3(13): 5113.
+ of a generic procedure *note 12.3(13): 5115.
+ of a generic subprogram *note 12.3(13): 5114.
+ of a generic unit *note 12.3(1): 5068.
+instructions for comment submission *note 0.2(58/1): 1001.
+int
+ in Interfaces.C *note B.3(7): 7991.
+Integer *note 3.5.4(11): 1831, *note 3.5.4(21): 1851.
+ in Standard *note A.1(12): 5880.
+integer literal *note 2.4(1): 1251.
+integer literals *note 3.5.4(14): 1838, *note 3.5.4(30): 1860.
+integer type *note 3.5.4(1): 1807, *note N(21): 9551.
+Integer_Address
+ in System.Storage_Elements *note 13.7.1(10/3): 5565.
+Integer_IO
+ in Ada.Text_IO *note A.10.1(52): 6949.
+Integer_Text_IO
+ child of Ada *note A.10.8(21): 7027.
+integer_type_definition *note 3.5.4(2): 1811.
+ used *note 3.2.1(4/2): 1442, *note P: 9668.
+Integer_Wide_Text_IO
+ child of Ada *note A.11(2/2): 7051.
+Integer_Wide_Wide_Text_IO
+ child of Ada *note A.11(3/2): 7054.
+interaction
+ between tasks *note 9(1/3): 4180.
+interface *note 3.9.4(4/2): 2344.
+ limited *note 3.9.4(5/2): 2349.
+ nonlimited *note 3.9.4(5/2): 2350.
+ protected *note 3.9.4(5/2): 2347.
+ synchronized *note 3.9.4(5/2): 2346.
+ task *note 3.9.4(5/2): 2348.
+ type *note 3.9.4(4/2): 2345.
+interface to assembly language *note C.1(4/3): 8186.
+interface to C *note B.3(1/3): 7984.
+interface to COBOL *note B.4(1/3): 8104.
+interface to Fortran *note B.5(1/3): 8158.
+interface to other languages *note B(1): 7935.
+interface type *note N(21.1/2): 9552.
+Interface_Ancestor_Tags
+ in Ada.Tags *note 3.9(7.4/2): 2241.
+interface_list *note 3.9.4(3/2): 2341.
+ used *note 3.4(2/2): 1611, *note 3.9.4(2/2): 2340, *note 7.3(3/3):
+3865, *note 9.1(2/3): 4203, *note 9.1(3/3): 4208, *note 9.4(2/3): 4268,
+*note 9.4(3/3): 4273, *note 12.5.1(3/2): 5195, *note P: 9799.
+interface_type_definition *note 3.9.4(2/2): 2339.
+ used *note 3.2.1(4/2): 1448, *note 12.5.5(2/2): 5225, *note P:
+10404.
+Interfaces *note B.2(3): 7980.
+Interfaces.C *note B.3(4): 7986.
+Interfaces.C.Pointers *note B.3.2(4): 8076.
+Interfaces.C.Strings *note B.3.1(3): 8052.
+Interfaces.COBOL *note B.4(7): 8106.
+Interfaces.Fortran *note B.5(4): 8160.
+interfacing aspect *note B.1(0.1/3): 7939.
+interfacing pragma *note J.15.5(1/3): 9180.
+ Convention *note J.15.5(1/3): 9185.
+ Export *note J.15.5(1/3): 9183.
+ Import *note J.15.5(1/3): 9181.
+internal call *note 9.5(3/3): 4324.
+internal code *note 13.4(7): 5464.
+internal requeue *note 9.5(7): 4327.
+Internal_Tag
+ in Ada.Tags *note 3.9(7/2): 2236.
+interpretation
+ of a complete context *note 8.6(10): 4144.
+ of a constituent of a complete context *note 8.6(15): 4150.
+ overload resolution *note 8.6(14): 4149.
+interrupt *note C.3(2): 8192.
+ example using asynchronous_select *note 9.7.4(10): 4590, *note
+9.7.4(12): 4595.
+interrupt entry *note J.7.1(5): 9134.
+interrupt handler *note C.3(2): 8200.
+Interrupt_Clocks_Supported
+ in Ada.Execution_Time *note D.14(9.1/3): 8594.
+Interrupt_Handler aspect *note C.3.1(6.2/3): 8204.
+Interrupt_Handler pragma *note J.15.7(2/3): 9218, *note L(17.1/3):
+9412.
+Interrupt_Id
+ in Ada.Interrupts *note C.3.2(2/3): 8225.
+Interrupt_Priority aspect *note D.1(6.3/3): 8327.
+Interrupt_Priority pragma *note J.15.11(4/3): 9269, *note L(18.1/3):
+9415.
+Interrupt_Priority subtype of Any_Priority
+ in System *note 13.7(16): 5554.
+Interrupts
+ child of Ada *note C.3.2(2/3): 8224.
+ child of Ada.Execution_Time *note D.14.3(3/3): 8646.
+Intersection
+ in Ada.Containers.Hashed_Sets *note A.18.8(29/2): 7597, *note
+A.18.8(30/2): 7598.
+ in Ada.Containers.Ordered_Sets *note A.18.9(30/2): 7673, *note
+A.18.9(31/2): 7674.
+intertask communication *note 9.5(1): 4321.
+ See also task *note 9(1/3): 4184.
+Intrinsic calling convention *note 6.3.1(4): 3660.
+invalid cursor
+ of a list container *note A.18.3(153/2): 7399.
+ of a map *note A.18.4(76/2): 7423.
+ of a set *note A.18.7(97/2): 7562.
+ of a tree *note A.18.10(222/3): 7805.
+ of a vector *note A.18.2(248/2): 7326.
+invalid representation *note 13.9.1(9): 5602.
+invariant *note N(21.2/3): 9553.
+invariant check *note 7.3.2(9/3): 3897.
+invariant expression *note 7.3.2(2/3): 3891.
+Inverse
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(46/2): 9036.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(24/2): 8995.
+Inverted_Exclamation
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6081.
+Inverted_Question
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6113.
+involve an inner product
+ complex *note G.3.2(56/2): 9042.
+ real *note G.3.1(34/2): 9001.
+IO_Exceptions
+ child of Ada *note A.13(3): 7114.
+IS1
+ in Ada.Characters.Latin_1 *note A.3.3(16): 6046.
+IS2
+ in Ada.Characters.Latin_1 *note A.3.3(16): 6045.
+IS3
+ in Ada.Characters.Latin_1 *note A.3.3(16): 6044.
+IS4
+ in Ada.Characters.Latin_1 *note A.3.3(16): 6043.
+Is_A_Group_Member
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(8/2): 8627.
+Is_Abstract
+ in Ada.Tags *note 3.9(7.5/3): 2242.
+Is_Alphanumeric
+ in Ada.Characters.Handling *note A.3.2(4/3): 5917.
+ in Ada.Wide_Characters.Handling *note A.3.5(12/3): 6207.
+Is_Attached
+ in Ada.Interrupts *note C.3.2(5): 8228.
+Is_Basic
+ in Ada.Characters.Handling *note A.3.2(4/3): 5913.
+Is_Callable
+ in Ada.Task_Identification *note C.7.1(4/3): 8280.
+Is_Character
+ in Ada.Characters.Conversions *note A.3.4(3/2): 6181.
+Is_Control
+ in Ada.Characters.Handling *note A.3.2(4/3): 5908.
+ in Ada.Wide_Characters.Handling *note A.3.5(5/3): 6200.
+Is_Current_Directory_Name
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(7/3): 7195.
+Is_Decimal_Digit
+ in Ada.Characters.Handling *note A.3.2(4/3): 5915.
+ in Ada.Wide_Characters.Handling *note A.3.5(10/3): 6205.
+Is_Descendant_At_Same_Level
+ in Ada.Tags *note 3.9(7.1/2): 2238.
+Is_Digit
+ in Ada.Characters.Handling *note A.3.2(4/3): 5914.
+ in Ada.Wide_Characters.Handling *note A.3.5(9/3): 6204.
+Is_Empty
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(12/2): 7345.
+ in Ada.Containers.Hashed_Maps *note A.18.5(11/2): 7438.
+ in Ada.Containers.Hashed_Sets *note A.18.8(13/2): 7579.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(10/3): 7828.
+ in Ada.Containers.Multiway_Trees *note A.18.10(16/3): 7741.
+ in Ada.Containers.Ordered_Maps *note A.18.6(10/2): 7492.
+ in Ada.Containers.Ordered_Sets *note A.18.9(12/2): 7653.
+ in Ada.Containers.Vectors *note A.18.2(23/2): 7251.
+Is_Full_Name
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(8/3): 7196.
+Is_Graphic
+ in Ada.Characters.Handling *note A.3.2(4/3): 5909.
+ in Ada.Wide_Characters.Handling *note A.3.5(19/3): 6214.
+Is_Held
+ in Ada.Asynchronous_Task_Control *note D.11(3/2): 8575.
+Is_Hexadecimal_Digit
+ in Ada.Characters.Handling *note A.3.2(4/3): 5916.
+ in Ada.Wide_Characters.Handling *note A.3.5(11/3): 6206.
+Is_In
+ in Ada.Strings.Maps *note A.4.2(13): 6245.
+ in Ada.Strings.Wide_Maps *note A.4.7(13): 6457.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(13/2): 6499.
+Is_ISO_646
+ in Ada.Characters.Handling *note A.3.2(10): 5932.
+Is_Leaf
+ in Ada.Containers.Multiway_Trees *note A.18.10(21/3): 7746.
+Is_Letter
+ in Ada.Characters.Handling *note A.3.2(4/3): 5910.
+ in Ada.Wide_Characters.Handling *note A.3.5(6/3): 6201.
+Is_Line_Terminator
+ in Ada.Characters.Handling *note A.3.2(4/3): 5919.
+ in Ada.Wide_Characters.Handling *note A.3.5(14/3): 6209.
+Is_Lower
+ in Ada.Characters.Handling *note A.3.2(4/3): 5911.
+ in Ada.Wide_Characters.Handling *note A.3.5(7/3): 6202.
+Is_Mark
+ in Ada.Characters.Handling *note A.3.2(4/3): 5920.
+ in Ada.Wide_Characters.Handling *note A.3.5(15/3): 6210.
+Is_Member
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(8/2): 8626.
+Is_Nul_Terminated
+ in Interfaces.C *note B.3(24): 8010, *note B.3(35): 8020, *note
+B.3(39.16/2): 8040, *note B.3(39.7/2): 8030.
+Is_Open
+ in Ada.Direct_IO *note A.8.4(10): 6821.
+ in Ada.Sequential_IO *note A.8.1(10): 6793.
+ in Ada.Streams.Stream_IO *note A.12.1(12): 7080.
+ in Ada.Text_IO *note A.10.1(13): 6878.
+Is_Other_Format
+ in Ada.Characters.Handling *note A.3.2(4/3): 5921.
+ in Ada.Wide_Characters.Handling *note A.3.5(16/3): 6211.
+Is_Parent_Directory_Name
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(6/3): 7194.
+Is_Punctuation_Connector
+ in Ada.Characters.Handling *note A.3.2(4/3): 5922.
+ in Ada.Wide_Characters.Handling *note A.3.5(17/3): 6212.
+Is_Relative_Name
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(9/3): 7197.
+Is_Reserved
+ in Ada.Interrupts *note C.3.2(4): 8227.
+Is_Root
+ in Ada.Containers.Multiway_Trees *note A.18.10(20/3): 7745.
+Is_Root_Directory_Name
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(5/3): 7193.
+Is_Round_Robin
+ in Ada.Dispatching.Round_Robin *note D.2.5(4/2): 8391.
+Is_Simple_Name
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(4/3): 7192.
+Is_Sorted
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(48/2): 7385.
+ in Ada.Containers.Vectors *note A.18.2(76/2): 7310.
+Is_Space
+ in Ada.Characters.Handling *note A.3.2(4/3): 5923.
+ in Ada.Wide_Characters.Handling *note A.3.5(18/3): 6213.
+Is_Special
+ in Ada.Characters.Handling *note A.3.2(4/3): 5918.
+ in Ada.Wide_Characters.Handling *note A.3.5(13/3): 6208.
+Is_String
+ in Ada.Characters.Conversions *note A.3.4(3/2): 6180.
+Is_Subset
+ in Ada.Containers.Hashed_Sets *note A.18.8(39/2): 7604.
+ in Ada.Containers.Ordered_Sets *note A.18.9(40/2): 7680.
+ in Ada.Strings.Maps *note A.4.2(14): 6246.
+ in Ada.Strings.Wide_Maps *note A.4.7(14): 6458.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(14/2): 6500.
+Is_Terminated
+ in Ada.Task_Identification *note C.7.1(4/3): 8279.
+Is_Upper
+ in Ada.Characters.Handling *note A.3.2(4/3): 5912.
+ in Ada.Wide_Characters.Handling *note A.3.5(8/3): 6203.
+Is_Wide_Character
+ in Ada.Characters.Conversions *note A.3.4(3/2): 6183.
+Is_Wide_String
+ in Ada.Characters.Conversions *note A.3.4(3/2): 6184.
+ISO 1989:2002 *note 1.2(4/2): 1119.
+ISO 639-3:2007 *note 1.2(1.1/3): 1110.
+ISO 8601:2004 *note 1.2(5.1/2): 1128.
+ISO/IEC 10646:2011 *note 1.2(8/3): 1136, *note 3.5.2(2/3): 1788, *note
+3.5.2(3/3): 1794, *note 3.5.2(4/3): 1796.
+ISO/IEC 14882:2011 *note 1.2(9/3): 1139.
+ISO/IEC 1539-1:2004 *note 1.2(3/2): 1116.
+ISO/IEC 3166-1:2006 *note 1.2(4.1/3): 1122.
+ISO/IEC 6429:1992 *note 1.2(5): 1125.
+ISO/IEC 646:1991 *note 1.2(2): 1113.
+ISO/IEC 8859-1:1998 *note 1.2(6/3): 1130.
+ISO/IEC 9899:2011 *note 1.2(7/3): 1133.
+ISO/IEC TR 19769:2004 *note 1.2(10/2): 1142.
+ISO_646 subtype of Character
+ in Ada.Characters.Handling *note A.3.2(9): 5930.
+ISO_646_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6428.
+issue
+ an entry call *note 9.5.3(8): 4416.
+italics
+ formal parameters of attribute functions *note 3.5(18.a): 1704.
+ implementation-defined *note 1.1.3(5.c): 1066.
+ nongraphic characters *note 3.5.2(2/3): 1790.
+ pseudo-names of anonymous types *note 3.2.1(7/2): 1452, *note
+A.1(2): 5877.
+ syntax rules *note 1.1.4(14): 1081.
+ terms introduced or defined *note 1.3(1/2): 1145.
+italics, like this *note 1(2.mm): 1003.
+iterable container object *note 5.5.1(11/3): 3461.
+iterable container object for a loop *note 5.5.2(12/3): 3488.
+iterable container type *note 5.5.1(11/3): 3459, *note N(21.3/3):
+9554.
+Iterate
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(45/2): 7382.
+ in Ada.Containers.Hashed_Maps *note A.18.5(37/2): 7470.
+ in Ada.Containers.Hashed_Sets *note A.18.8(49/2): 7613.
+ in Ada.Containers.Multiway_Trees *note A.18.10(42/3): 7767, *note
+A.18.10(44/3): 7769.
+ in Ada.Containers.Ordered_Maps *note A.18.6(50/2): 7532.
+ in Ada.Containers.Ordered_Sets *note A.18.9(60/2): 7693.
+ in Ada.Containers.Vectors *note A.18.2(73/2): 7307.
+ in Ada.Environment_Variables *note A.17(8/3): 7212.
+Iterate_Children
+ in Ada.Containers.Multiway_Trees *note A.18.10(68/3): 7793, *note
+A.18.10(70/3): 7795.
+Iterate_Subtree
+ in Ada.Containers.Multiway_Trees *note A.18.10(43/3): 7768, *note
+A.18.10(45/3): 7770.
+iteration cursor subtype *note 5.5.1(6/3): 3450.
+iteration_scheme *note 5.5(3/3): 3425.
+ used *note 5.5(2): 3422, *note P: 10024.
+iterator *note N(21.4/3): 9555.
+ array component *note 5.5.2(3/3): 3477.
+ container element *note 5.5.2(3/3): 3479.
+ forward *note 5.5.2(4/3): 3483.
+ generalized *note 5.5.2(3/3): 3473.
+ reverse *note 5.5.2(4/3): 3481.
+iterator object *note 5.5.1(6/3): 3448.
+iterator type *note 5.5.1(6/3): 3446.
+Iterator_Element aspect *note 5.5.1(9/3): 3458.
+Iterator_Interfaces
+ child of Ada *note 5.5.1(2/3): 3439.
+iterator_specification *note 5.5.2(2/3): 3466.
+ used *note 4.5.8(1/3): 3116, *note 5.5(3/3): 3428, *note P: 9967.
+
+
+\1f
+File: aarm2012.info, Node: J, Next: K, Prev: I, Up: Index
+
+J
+==
+
+
+
+j
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(5): 8870.
+ in Interfaces.Fortran *note B.5(10): 8169.
+
+
+\1f
+File: aarm2012.info, Node: K, Next: L, Prev: J, Up: Index
+
+K
+==
+
+
+
+Key
+ in Ada.Containers.Hashed_Maps *note A.18.5(13/2): 7440.
+ in Ada.Containers.Hashed_Sets *note A.18.8(51/2): 7615.
+ in Ada.Containers.Ordered_Maps *note A.18.6(12/2): 7494.
+ in Ada.Containers.Ordered_Sets *note A.18.9(64/2): 7697.
+Kind
+ in Ada.Directories *note A.16(25/2): 7158, *note A.16(40/2): 7170.
+known discriminants *note 3.7(26): 2106.
+known to be constrained *note 3.3(23.1/3): 1537.
+known to denote the same object *note 6.4.1(6.4/3): 3721.
+known to refer to the same object *note 6.4.1(6.11/3): 3722.
+known_discriminant_part *note 3.7(4): 2085.
+ used *note 3.2.1(3/3): 1435, *note 3.7(2): 2083, *note 9.1(2/3):
+4201, *note 9.4(2/3): 4266, *note P: 9757.
+
+
+\1f
+File: aarm2012.info, Node: L, Next: M, Prev: K, Up: Index
+
+L
+==
+
+
+
+label *note 5.1(7): 3366.
+ used *note 5.1(2/3): 3338, *note 5.1(3): 3340, *note P: 9985.
+Landau symbol O(X) *note A.18(3/2): 7219.
+language
+ interface to assembly *note C.1(4/3): 8187.
+ interface to non-Ada *note B(1): 7936.
+ in Ada.Locales *note A.19(6/3): 7930.
+Language code standard *note 1.2(1.1/3): 1112.
+language-defined categories
+ [partial] *note 3.2(10/2): 1425.
+language-defined category
+ of types *note 3.2(2/2): 1392.
+language-defined check *note 11.5(2/3): 4981, *note 11.6(1/3): 5021.
+language-defined class
+ [partial] *note 3.2(10/2): 1424.
+ of types *note 3.2(2/2): 1391.
+Language-defined constants *note Q.5(1/3): 10482.
+Language-defined exceptions *note Q.4(1/3): 10480.
+Language-Defined Library Units *note A(1): 5873.
+Language-defined objects *note Q.5(1/3): 10481.
+Language-defined packages *note Q.1(1/3): 10476.
+Language-defined subprograms *note Q.3(1/3): 10479.
+Language-defined subtypes *note Q.2(1/3): 10478.
+Language-defined types *note Q.2(1/3): 10477.
+Language-defined values *note Q.5(1/3): 10483.
+Language_Code
+ in Ada.Locales *note A.19(4/3): 7926.
+Language_Unknown
+ in Ada.Locales *note A.19(5/3): 7928.
+Last
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(35/2): 7373.
+ in Ada.Containers.Ordered_Maps *note A.18.6(31/2): 7520.
+ in Ada.Containers.Ordered_Sets *note A.18.9(43/2): 7683.
+ in Ada.Containers.Vectors *note A.18.2(61/2): 7296.
+ in Ada.Iterator_Interfaces *note 5.5.1(4/3): 3444.
+Last attribute *note 3.5(13): 1696, *note 3.6.2(5): 2058.
+last element
+ of a hashed set *note A.18.8(68/2): 7634.
+ of a set *note A.18.7(6/2): 7550.
+ of an ordered set *note A.18.9(81/3): 7716.
+last node
+ of a hashed map *note A.18.5(46/2): 7477.
+ of a map *note A.18.4(6/2): 7414.
+ of an ordered map *note A.18.6(58/3): 7538.
+Last(N) attribute *note 3.6.2(6): 2060.
+last_bit *note 13.5.1(6): 5492.
+ used *note 13.5.1(3): 5487, *note P: 10455.
+Last_Bit attribute *note 13.5.2(4/2): 5508.
+Last_Child
+ in Ada.Containers.Multiway_Trees *note A.18.10(62/3): 7787.
+Last_Child_Element
+ in Ada.Containers.Multiway_Trees *note A.18.10(63/3): 7788.
+Last_Element
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(36/2): 7374.
+ in Ada.Containers.Ordered_Maps *note A.18.6(32/2): 7521.
+ in Ada.Containers.Ordered_Sets *note A.18.9(44/2): 7684.
+ in Ada.Containers.Vectors *note A.18.2(62/2): 7297.
+Last_Index
+ in Ada.Containers.Vectors *note A.18.2(60/2): 7295.
+Last_Key
+ in Ada.Containers.Ordered_Maps *note A.18.6(33/2): 7522.
+Last_Valid attribute *note 3.5.5(7.3/3): 1874.
+lateness *note D.9(12): 8552.
+Latin-1 *note 3.5.2(2/3): 1786.
+Latin_1
+ child of Ada.Characters *note A.3.3(3): 5947.
+Layout aspect *note 13.5(1): 5470.
+Layout_Error
+ in Ada.IO_Exceptions *note A.13(4): 7122.
+ in Ada.Text_IO *note A.10.1(85): 7013.
+LC_A
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6011.
+LC_A_Acute
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6147.
+LC_A_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6148.
+LC_A_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6150.
+LC_A_Grave
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6146.
+LC_A_Ring
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6151.
+LC_A_Tilde
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6149.
+LC_AE_Diphthong
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6152.
+LC_B
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6012.
+LC_C
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6013.
+LC_C_Cedilla
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6153.
+LC_D
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6014.
+LC_E
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6015.
+LC_E_Acute
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6155.
+LC_E_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6156.
+LC_E_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6157.
+LC_E_Grave
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6154.
+LC_F
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6016.
+LC_G
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6017.
+LC_German_Sharp_S
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6145.
+LC_H
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6018.
+LC_I
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6019.
+LC_I_Acute
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6159.
+LC_I_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6160.
+LC_I_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6161.
+LC_I_Grave
+ in Ada.Characters.Latin_1 *note A.3.3(25): 6158.
+LC_Icelandic_Eth
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6162.
+LC_Icelandic_Thorn
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6176.
+LC_J
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6020.
+LC_K
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6021.
+LC_L
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6022.
+LC_M
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6023.
+LC_N
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6024.
+LC_N_Tilde
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6163.
+LC_O
+ in Ada.Characters.Latin_1 *note A.3.3(13): 6025.
+LC_O_Acute
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6165.
+LC_O_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6166.
+LC_O_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6168.
+LC_O_Grave
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6164.
+LC_O_Oblique_Stroke
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6170.
+LC_O_Tilde
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6167.
+LC_P
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6026.
+LC_Q
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6027.
+LC_R
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6028.
+LC_S
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6029.
+LC_T
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6030.
+LC_U
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6031.
+LC_U_Acute
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6172.
+LC_U_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6173.
+LC_U_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6174.
+LC_U_Grave
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6171.
+LC_V
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6032.
+LC_W
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6033.
+LC_X
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6034.
+LC_Y
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6035.
+LC_Y_Acute
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6175.
+LC_Y_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(26): 6177.
+LC_Z
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6036.
+Leading_Nonseparate
+ in Interfaces.COBOL *note B.4(23): 8128.
+Leading_Part attribute *note A.5.3(54): 6723.
+Leading_Separate
+ in Interfaces.COBOL *note B.4(23): 8126.
+leaf node
+ of a tree *note A.18.10(4/3): 7729.
+Leap_Seconds_Count subtype of Integer
+ in Ada.Calendar.Arithmetic *note 9.6.1(11/2): 4491.
+leaving *note 7.6.1(3/2): 3962.
+left *note 7.6.1(3/2): 3963.
+left parenthesis *note 2.1(15/3): 1193.
+Left_Angle_Quotation
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6091.
+Left_Curly_Bracket
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6037.
+Left_Parenthesis
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5989.
+Left_Square_Bracket
+ in Ada.Characters.Latin_1 *note A.3.3(12): 6005.
+legal
+ construct *note 1.1.2(27): 1024.
+ partition *note 1.1.2(29): 1032.
+legality determinable via semantic dependences *note 10(3.c): 4640.
+legality rules *note 1.1.2(27): 1021.
+length
+ of a dimension of an array *note 3.6(13): 2017.
+ of a list container *note A.18.3(3/2): 7336.
+ of a map *note A.18.4(5/2): 7412.
+ of a one-dimensional array *note 3.6(13): 2018.
+ of a set *note A.18.7(5/2): 7548.
+ of a vector container *note A.18.2(2/2): 7233.
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(11/2): 7344.
+ in Ada.Containers.Hashed_Maps *note A.18.5(10/2): 7437.
+ in Ada.Containers.Hashed_Sets *note A.18.8(12/2): 7578.
+ in Ada.Containers.Ordered_Maps *note A.18.6(9/2): 7491.
+ in Ada.Containers.Ordered_Sets *note A.18.9(11/2): 7652.
+ in Ada.Containers.Vectors *note A.18.2(21/2): 7249.
+ in Ada.Strings.Bounded *note A.4.4(9): 6306.
+ in Ada.Strings.Unbounded *note A.4.5(6): 6365.
+ in Ada.Text_IO.Editing *note F.3.3(11): 8853.
+ in Interfaces.COBOL *note B.4(34): 8142, *note B.4(39): 8146, *note
+B.4(44): 8150.
+Length attribute *note 3.6.2(9): 2066.
+Length(N) attribute *note 3.6.2(10): 2068.
+Length_Check *note 11.5(15): 5004.
+ [partial] *note 4.5.1(8): 2946, *note 4.6(37): 3184, *note 4.6(52):
+3216.
+Length_Error
+ in Ada.Strings *note A.4.1(5): 6227.
+Length_Range subtype of Natural
+ in Ada.Strings.Bounded *note A.4.4(8): 6305.
+less than operator *note 4.4(1/3): 2793, *note 4.5.2(1): 2968.
+less than or equal operator *note 4.4(1/3): 2797, *note 4.5.2(1):
+2972.
+less-than sign *note 2.1(15/3): 1208.
+Less_Case_Insensitive
+ child of Ada.Strings *note A.4.10(13/3): 6531.
+ child of Ada.Strings.Bounded *note A.4.10(18/3): 6533.
+ child of Ada.Strings.Fixed *note A.4.10(16/3): 6532.
+ child of Ada.Strings.Unbounded *note A.4.10(21/3): 6534.
+Less_Than_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(10): 6000.
+letter
+ a category of Character *note A.3.2(24): 5937.
+letter_lowercase *note 2.1(9/2): 1169.
+ used *note 2.3(3/2): 1236, *note P: 9600.
+letter_modifier *note 2.1(9.2/2): 1171.
+ used *note 2.3(3/2): 1238, *note P: 9602.
+letter_other *note 2.1(9.3/2): 1172.
+ used *note 2.3(3/2): 1239, *note P: 9603.
+Letter_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6420.
+letter_titlecase *note 2.1(9.1/2): 1170.
+ used *note 2.3(3/2): 1237, *note P: 9601.
+letter_uppercase *note 2.1(8/2): 1168.
+ used *note 2.3(3/2): 1235, *note P: 9599.
+level
+ accessibility *note 3.10.2(3/2): 2443.
+ library *note 3.10.2(22): 2462.
+lexical element *note 2.2(1): 1222.
+lexicographic order *note 4.5.2(26/3): 2993.
+LF
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5959.
+library *note 10.1.4(9): 4757.
+ [partial] *note 10.1.1(9): 4674.
+ informal introduction *note 10(2): 4635.
+ See also library level, library unit, library_item
+library level *note 3.10.2(22): 2461.
+Library unit *note 10.1(3): 4645, *note 10.1.1(9): 4673, *note N(22):
+9556.
+ informal introduction *note 10(2): 4633.
+ See also language-defined library units
+library unit pragma *note 10.1.5(7/3): 4763.
+ All_Calls_Remote *note E.2.3(6): 8753.
+ categorization pragmas *note E.2(2/3): 8706.
+ Elaborate_Body *note 10.2.1(24): 4849.
+ Preelaborate *note 10.2.1(4): 4814.
+ Pure *note 10.2.1(15): 4831.
+library_item *note 10.1.1(4): 4655.
+ informal introduction *note 10(2): 4634.
+ used *note 10.1.1(3): 4652, *note P: 10280.
+library_unit_body *note 10.1.1(7): 4668.
+ used *note 10.1.1(4): 4657, *note P: 10284.
+library_unit_declaration *note 10.1.1(5): 4659.
+ used *note 10.1.1(4): 4656, *note P: 10283.
+library_unit_renaming_declaration *note 10.1.1(6): 4664.
+ used *note 10.1.1(4): 4658, *note P: 10285.
+lifetime *note 3.10.2(3/2): 2447.
+limited interface *note 3.9.4(5/2): 2354.
+limited type *note 7.5(3/3): 3909, *note N(23/2): 9558.
+ becoming nonlimited *note 7.3.1(5/1): 3886, *note 7.5(16): 3915.
+ immutably *note 7.5(8.1/3): 3912.
+limited view *note 10.1.1(12.1/2): 4691.
+Limited_Controlled
+ in Ada.Finalization *note 7.6(7/2): 3932.
+limited_with_clause *note 10.1.2(4.1/2): 4706.
+ used *note 10.1.2(4/2): 4704, *note P: 10299.
+line *note 2.2(2/3): 1224.
+ in Ada.Text_IO *note A.10.1(38): 6925.
+line terminator *note A.10(7): 6849.
+Line_Length
+ in Ada.Text_IO *note A.10.1(25): 6902.
+link name *note B.1(35): 7969.
+link-time error
+ See post-compilation error *note 1.1.2(29): 1030.
+ See post-compilation error *note 1.1.5(4): 1094.
+Link_Name aspect *note B.1(1/3): 7946.
+Linker_Options pragma *note B.1(8): 7957, *note L(19): 9417.
+linking
+ See partition building *note 10.2(2): 4788.
+List
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(6/3): 7338.
+list container *note A.18.3(1/2): 7333.
+List pragma *note 2.8(21): 1330, *note L(20): 9420.
+List_Iterator_Interfaces
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(9.2/3): 7343.
+literal *note 4.2(1): 2649.
+ based *note 2.4.2(1): 1268.
+ decimal *note 2.4.1(1): 1255.
+ numeric *note 2.4(1): 1249.
+ See also aggregate *note 4.3(1): 2669.
+little endian *note 13.5.3(2): 5517.
+load time *note C.4(3): 8241.
+local to *note 8.1(14): 3994.
+local_name *note 13.1(3): 5286.
+ used *note 13.3(2): 5359, *note 13.4(2): 5458, *note 13.5.1(2):
+5480, *note 13.5.1(3): 5484, *note C.5(3): 8244, *note J.15.2(2/3):
+9169, *note J.15.3(2/3): 9175, *note J.15.5(2/3): 9196, *note
+J.15.5(3/3): 9202, *note J.15.5(4/3): 9208, *note J.15.6(2/3): 9216,
+*note J.15.8(2/3): 9229, *note J.15.8(3/3): 9232, *note J.15.8(4/3):
+9235, *note J.15.8(5/3): 9238, *note J.15.8(6/3): 9241, *note
+J.15.8(7/3): 9244, *note J.15.13(2/3): 9279, *note L(3.1/3): 9346, *note
+L(4.1/3): 9349, *note L(5.1/3): 9352, *note L(8.1/3): 9360, *note L(9):
+9371, *note L(13.1/3): 9388, *note L(14.1/3): 9394, *note L(14.2/3):
+9399, *note L(14.3/3): 9402, *note L(21.2/3): 9428, *note L(24.1/3):
+9436, *note L(37.2/3): 9493, *note L(38.1/3): 9499, *note L(39.1/3):
+9502, *note P: 10446.
+locale *note A.19(1/3): 7924.
+ active *note A.19(8/3): 7933.
+Locales
+ child of Ada *note A.19(3/3): 7925.
+locking policy *note D.3(6/2): 8415.
+ Ceiling_Locking *note D.3(7): 8419.
+Locking_Policy pragma *note D.3(3): 8408, *note L(21): 9423.
+Log
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(3): 8896.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(4): 6588.
+Logical
+ in Interfaces.Fortran *note B.5(7): 8164.
+logical operator *note 4.5.1(2): 2935.
+ See also not operator *note 4.5.6(3): 3068.
+logical_operator *note 4.5(2): 2916.
+long
+ in Interfaces.C *note B.3(7): 7993.
+Long_Binary
+ in Interfaces.COBOL *note B.4(10): 8110.
+long_double
+ in Interfaces.C *note B.3(17): 8004.
+Long_Float *note 3.5.7(15): 1914, *note 3.5.7(16): 1916, *note
+3.5.7(17): 1917.
+Long_Floating
+ in Interfaces.COBOL *note B.4(9): 8108.
+Long_Integer *note 3.5.4(22): 1852, *note 3.5.4(25): 1853, *note
+3.5.4(28): 1857.
+Look_Ahead
+ in Ada.Text_IO *note A.10.1(43): 6934.
+loop cursor *note 5.5.2(12/3): 3490.
+loop iterator *note 5.5.2(10/3): 3485.
+ container element iterator *note 5.5.2(12/3): 3489.
+loop parameter *note 5.5(6): 3432, *note 5.5.2(7/3): 3484.
+loop_parameter_specification *note 5.5(4): 3429.
+ used *note 4.5.8(1/3): 3113, *note 5.5(3/3): 3427, *note P: 10028.
+loop_statement *note 5.5(2): 3420.
+ used *note 5.1(5/2): 3360, *note P: 10004.
+low line *note 2.1(15/3): 1211.
+low-level programming *note C(1): 8179.
+Low_Line
+ in Ada.Characters.Latin_1 *note A.3.3(12): 6009.
+Low_Order_First *note 13.5.3(2): 5516.
+ in Interfaces.COBOL *note B.4(25): 8132.
+ in System *note 13.7(15/2): 5550.
+lower bound
+ of a range *note 3.5(4): 1673.
+lower-case letter
+ a category of Character *note A.3.2(25): 5938.
+Lower_Case_Map
+ in Ada.Strings.Maps.Constants *note A.4.6(5): 6429.
+Lower_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6421.
+LR(1) *note 1.1.4(14.a): 1082.
+
+
+\1f
+File: aarm2012.info, Node: M, Next: N, Prev: L, Up: Index
+
+M
+==
+
+
+
+Machine attribute *note A.5.3(60): 6728.
+machine code insertion *note 13.8(1): 5576, *note C.1(2): 8185.
+machine numbers
+ of a fixed point type *note 3.5.9(8/2): 1944.
+ of a floating point type *note 3.5.7(8): 1901.
+machine scalar *note 13.3(8.1/3): 5389.
+Machine_Code
+ child of System *note 13.8(7): 5581.
+Machine_Emax attribute *note A.5.3(8): 6665.
+Machine_Emin attribute *note A.5.3(7): 6663.
+Machine_Mantissa attribute *note A.5.3(6): 6661.
+Machine_Overflows attribute *note A.5.3(12): 6675, *note A.5.4(4):
+6756.
+Machine_Radix aspect *note F.1(1): 8828.
+Machine_Radix attribute *note A.5.3(2): 6658, *note A.5.4(2): 6752.
+Machine_Radix clause *note 13.3(7/2): 5383, *note F.1(1): 8826.
+Machine_Rounding attribute *note A.5.3(41.1/2): 6703.
+Machine_Rounds attribute *note A.5.3(11): 6673, *note A.5.4(3): 6754.
+macro
+ See generic unit *note 12(1): 5038.
+Macron
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6095.
+main subprogram
+ for a partition *note 10.2(7): 4791.
+malloc
+ See allocator *note 4.8(1): 3252.
+Map
+ in Ada.Containers.Hashed_Maps *note A.18.5(3/3): 7429.
+ in Ada.Containers.Ordered_Maps *note A.18.6(4/3): 7485.
+map container *note A.18.4(1/2): 7407.
+Map_Iterator_Interfaces
+ in Ada.Containers.Hashed_Maps *note A.18.5(6.2/3): 7434.
+ in Ada.Containers.Ordered_Maps *note A.18.6(7.2/3): 7490.
+Maps
+ child of Ada.Strings *note A.4.2(3/2): 6237.
+mark_non_spacing *note 2.1(9.4/2): 1173, *note 2.1(9.5/2): 1174.
+ used *note 2.3(3.1/3): 1242, *note P: 9605.
+mark_spacing_combining
+ used *note 2.3(3.1/3): 1243, *note P: 9606.
+marshalling *note E.4(9): 8784.
+Masculine_Ordinal_Indicator
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6108.
+master *note 7.6.1(3/2): 3964.
+master of a call *note 3.10.2(10.1/3): 2452.
+match
+ a character to a pattern character *note A.4.2(54): 6258.
+ a character to a pattern character, with respect to a character
+mapping function *note A.4.2(64): 6260.
+ a string to a pattern string *note A.4.2(54): 6259.
+matching components *note 4.5.2(16): 2991.
+Max attribute *note 3.5(19): 1706.
+Max_Alignment_For_Allocation attribute *note 13.11.1(4/3): 5662.
+Max_Asynchronous_Select_Nesting restriction *note D.7(18/1): 8502.
+Max_Base_Digits *note 3.5.7(6): 1899.
+ in System *note 13.7(8): 5537.
+Max_Binary_Modulus *note 3.5.4(7): 1822.
+ in System *note 13.7(7): 5535.
+Max_Decimal_Digits
+ in Ada.Decimal *note F.2(5): 8834.
+Max_Delta
+ in Ada.Decimal *note F.2(4): 8833.
+Max_Digits *note 3.5.7(6): 1900.
+ in System *note 13.7(8): 5538.
+Max_Digits_Binary
+ in Interfaces.COBOL *note B.4(11): 8111.
+Max_Digits_Long_Binary
+ in Interfaces.COBOL *note B.4(11): 8112.
+Max_Entry_Queue_Length restriction *note D.7(19.1/2): 8512.
+Max_Image_Width
+ in Ada.Numerics.Discrete_Random *note A.5.2(25): 6643.
+ in Ada.Numerics.Float_Random *note A.5.2(13): 6631.
+Max_Int *note 3.5.4(14): 1836.
+ in System *note 13.7(6): 5534.
+Max_Length
+ in Ada.Strings.Bounded *note A.4.4(5): 6302.
+Max_Mantissa
+ in System *note 13.7(9): 5539.
+Max_Nonbinary_Modulus *note 3.5.4(7): 1823.
+ in System *note 13.7(7): 5536.
+Max_Picture_Length
+ in Ada.Text_IO.Editing *note F.3.3(8): 8846.
+Max_Protected_Entries restriction *note D.7(14): 8493.
+Max_Scale
+ in Ada.Decimal *note F.2(3): 8830.
+Max_Select_Alternatives restriction *note D.7(12): 8489.
+Max_Size_In_Storage_Elements attribute *note 13.11.1(3/3): 5660.
+Max_Storage_At_Blocking restriction *note D.7(17/1): 8497.
+Max_Task_Entries restriction *note D.7(13): 8491.
+Max_Tasks restriction *note D.7(19/1): 8507.
+maximum box error
+ for a component of the result of evaluating a complex function
+*note G.2.6(3): 8983.
+maximum line length *note A.10(11): 6857.
+maximum page length *note A.10(11): 6858.
+maximum relative error
+ for a component of the result of evaluating a complex function
+*note G.2.6(3): 8982.
+ for the evaluation of an elementary function *note G.2.4(2): 8976.
+Members
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(8/2): 8628.
+Membership
+ in Ada.Strings *note A.4.1(6): 6233.
+membership test *note 4.5.2(2/3): 2983.
+membership_choice *note 4.4(3.2/3): 2882.
+ used *note 4.4(3.1/3): 2881, *note P: 9927.
+membership_choice_list *note 4.4(3.1/3): 2879.
+ used *note 4.4(3/3): 2878, *note P: 9925.
+Memory_Size
+ in System *note 13.7(13): 5546.
+mentioned
+ in a with_clause *note 10.1.2(6/2): 4714.
+Merge
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(50/2): 7387.
+ in Ada.Containers.Vectors *note A.18.2(78/2): 7312.
+message
+ See dispatching call *note 3.9.2(1/2): 2294.
+method
+ See dispatching subprogram *note 3.9.2(1/2): 2295.
+methodological restriction *note 10.1.3(13.a): 4749.
+metrics *note 1.1.2(35): 1044.
+Micro_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6102.
+Microseconds
+ in Ada.Real_Time *note D.8(14/2): 8536.
+Middle_Dot
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6105.
+Milliseconds
+ in Ada.Real_Time *note D.8(14/2): 8537.
+Min attribute *note 3.5(16): 1703.
+Min_Delta
+ in Ada.Decimal *note F.2(4): 8832.
+Min_Handler_Ceiling
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(7/2): 8623.
+ in Ada.Execution_Time.Timers *note D.14.1(6/2): 8606.
+Min_Int *note 3.5.4(14): 1835.
+ in System *note 13.7(6): 5533.
+Min_Scale
+ in Ada.Decimal *note F.2(3): 8831.
+minus *note 2.1(15/3): 1200.
+minus operator *note 4.4(1/3): 2815, *note 4.5.3(1): 3011, *note
+4.5.4(1): 3036.
+Minus_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5995.
+Minute
+ in Ada.Calendar.Formatting *note 9.6.1(25/2): 4511.
+Minute_Number subtype of Natural
+ in Ada.Calendar.Formatting *note 9.6.1(20/2): 4504.
+Minutes
+ in Ada.Real_Time *note D.8(14/2): 8539.
+mixed-language programs *note B(1): 7937, *note C.1(4/3): 8188.
+Mod attribute *note 3.5.4(16.1/2): 1841.
+mod operator *note 4.4(1/3): 2834, *note 4.5.5(1): 3050.
+mod_clause *note J.8(1): 9142.
+ used *note 13.5.1(2): 5481, *note P: 10450.
+mode *note 6.1(16): 3560.
+ used *note 6.1(15/3): 3553, *note 12.4(2/3): 5136, *note P: 10071.
+ in Ada.Direct_IO *note A.8.4(9): 6818.
+ in Ada.Sequential_IO *note A.8.1(9): 6790.
+ in Ada.Streams.Stream_IO *note A.12.1(11): 7077.
+ in Ada.Text_IO *note A.10.1(12): 6875.
+mode conformance *note 6.3.1(16/3): 3669.
+ required *note 8.5.4(4/3): 4117, *note 8.5.4(5/3): 4120, *note
+12.6(7/3): 5246, *note 12.6(8/3): 5247, *note 13.3(6): 5368.
+mode of operation
+ nonstandard *note 1.1.5(11): 1101.
+ standard *note 1.1.5(11): 1103.
+Mode_Error
+ in Ada.Direct_IO *note A.8.4(18): 6831.
+ in Ada.IO_Exceptions *note A.13(4): 7116.
+ in Ada.Sequential_IO *note A.8.1(15): 6798.
+ in Ada.Streams.Stream_IO *note A.12.1(26): 7093.
+ in Ada.Text_IO *note A.10.1(85): 7007.
+Model attribute *note A.5.3(68): 6742, *note G.2.2(7): 8964.
+model interval *note G.2.1(4): 8945.
+ associated with a value *note G.2.1(4): 8946.
+model number *note G.2.1(3): 8944.
+model-oriented attributes
+ of a floating point subtype *note A.5.3(63): 6732.
+Model_Emin attribute *note A.5.3(65): 6736, *note G.2.2(4): 8957.
+Model_Epsilon attribute *note A.5.3(66): 6738.
+Model_Mantissa attribute *note A.5.3(64): 6734, *note G.2.2(3/2):
+8955.
+Model_Small attribute *note A.5.3(67): 6740.
+Modification_Time
+ in Ada.Directories *note A.16(27/2): 7160, *note A.16(42/2): 7172.
+modular type *note 3.5.4(1): 1809.
+Modular_IO
+ in Ada.Text_IO *note A.10.1(57): 6958.
+modular_type_definition *note 3.5.4(4): 1817.
+ used *note 3.5.4(2): 1813, *note P: 9720.
+module
+ See package *note 7(1): 3823.
+modulus
+ of a modular type *note 3.5.4(7): 1821.
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(10/2): 9014,
+*note G.3.2(30/2): 9027.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(9): 8880.
+Modulus attribute *note 3.5.4(17): 1843.
+Monday
+ in Ada.Calendar.Formatting *note 9.6.1(17/2): 4495.
+Month
+ in Ada.Calendar *note 9.6(13): 4466.
+ in Ada.Calendar.Formatting *note 9.6.1(22/2): 4508.
+Month_Number subtype of Integer
+ in Ada.Calendar *note 9.6(11/2): 4461.
+More_Entries
+ in Ada.Directories *note A.16(34/2): 7166.
+Move
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(18/2): 7356.
+ in Ada.Containers.Hashed_Maps *note A.18.5(18/2): 7452.
+ in Ada.Containers.Hashed_Sets *note A.18.8(18/2): 7587.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(22/3): 7840.
+ in Ada.Containers.Multiway_Trees *note A.18.10(34/3): 7759.
+ in Ada.Containers.Ordered_Maps *note A.18.6(17/2): 7506.
+ in Ada.Containers.Ordered_Sets *note A.18.9(17/2): 7661.
+ in Ada.Containers.Vectors *note A.18.2(35/2): 7270.
+ in Ada.Strings.Fixed *note A.4.3(7): 6263.
+multi-dimensional array *note 3.6(12): 2014.
+Multiplication_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6137.
+multiply *note 2.1(15/3): 1196.
+multiply operator *note 4.4(1/3): 2826, *note 4.5.5(1): 3042.
+multiplying operator *note 4.5.5(1): 3038.
+multiplying_operator *note 4.5(6): 2920.
+ used *note 4.4(5): 2893, *note P: 9936.
+Multiprocessors
+ child of System *note D.16(3/3): 8663.
+Multiway_Trees
+ child of Ada.Containers *note A.18.10(7/3): 7733.
+mutable *note 3.7(28.b): 2115.
+mutates *note 7.6(17.6/3): 3950.
+MW
+ in Ada.Characters.Latin_1 *note A.3.3(18): 6068.
+
+
+\1f
+File: aarm2012.info, Node: N, Next: O, Prev: M, Up: Index
+
+N
+==
+
+
+
+n-dimensional array_aggregate *note 4.3.3(6): 2748.
+NAK
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5970.
+name *note 4.1(2/3): 2522.
+ [partial] *note 3.1(1): 1343.
+ of (a view of) an entity *note 3.1(8): 1370.
+ of a pragma *note 2.8(9): 1317.
+ of an external file *note A.7(1): 6764.
+ used *note 2.8(3/3): 1314, *note 3.2.2(4): 1470, *note 4.1(4):
+2539, *note 4.1(5): 2542, *note 4.1(6): 2544, *note 4.1.5(4/3): 2626,
+*note 4.4(7/3): 2904, *note 4.6(2): 3135, *note 4.8(2.1/3): 3260, *note
+5.2(2): 3377, *note 5.5.2(2/3): 3471, *note 5.7(2): 3499, *note 5.8(2):
+3504, *note 6.4(2): 3690, *note 6.4(3): 3694, *note 6.4(6): 3705, *note
+8.4(3): 4059, *note 8.5.1(2/3): 4085, *note 8.5.2(2/3): 4101, *note
+8.5.3(2/3): 4106, *note 8.5.4(2/3): 4114, *note 8.5.5(2/3): 4130, *note
+9.5.3(2): 4404, *note 9.5.4(2/3): 4432, *note 9.8(2): 4601, *note
+10.1.1(8): 4672, *note 10.1.2(4.1/2): 4707, *note 10.1.2(4.2/2): 4710,
+*note 10.2.1(3): 4813, *note 10.2.1(14): 4830, *note 10.2.1(20): 4841,
+*note 10.2.1(21): 4845, *note 10.2.1(22): 4848, *note 11.2(5): 4898,
+*note 11.3(2/2): 4906, *note 12.3(2/3): 5083, *note 12.3(5): 5098, *note
+12.6(4): 5243, *note 12.7(2/3): 5259, *note 13.1(3): 5290, *note
+13.1.1(4/3): 5334, *note 13.3(2): 5361, *note 13.11.3(3.1/3): 5686,
+*note 13.12(4.1/2): 5737, *note E.2.1(3): 8718, *note E.2.2(3): 8733,
+*note E.2.3(3): 8749, *note E.2.3(5): 8752, *note H.3.2(3): 9064, *note
+J.10(3/2): 9150, *note J.15.1(2/3): 9160, *note J.15.7(2/3): 9219, *note
+J.15.7(4/3): 9222, *note L(2): 9330, *note L(6.1/3): 9355, *note L(10):
+9376, *note L(11): 9381, *note L(12): 9384, *note L(15.1/3): 9405, *note
+L(16): 9409, *note L(17.1/3): 9413, *note L(26): 9447, *note L(28):
+9461, *note L(30): 9469, *note L(31): 9472, *note L(34): 9481, *note P:
+9846.
+ in Ada.Direct_IO *note A.8.4(9): 6819.
+ in Ada.Sequential_IO *note A.8.1(9): 6791.
+ in Ada.Streams.Stream_IO *note A.12.1(11): 7078.
+ in Ada.Text_IO *note A.10.1(12): 6876.
+ in System *note 13.7(4): 5531.
+name resolution rules *note 1.1.2(26/3): 1018.
+Name_Case_Equivalence
+ in Ada.Directories *note A.16(20.2/3): 7154.
+Name_Case_Kind
+ in Ada.Directories *note A.16(20.1/3): 7153.
+Name_Error
+ in Ada.Direct_IO *note A.8.4(18): 6832.
+ in Ada.Directories *note A.16(43/2): 7174.
+ in Ada.IO_Exceptions *note A.13(4): 7117.
+ in Ada.Sequential_IO *note A.8.1(15): 6799.
+ in Ada.Streams.Stream_IO *note A.12.1(26): 7094.
+ in Ada.Text_IO *note A.10.1(85): 7008.
+named
+ in a use clause *note 8.4(7.1/2): 4065.
+ in a with_clause *note 10.1.2(6/2): 4716.
+named association *note 6.4(7): 3706, *note 6.4.1(2/3): 3715, *note
+12.3(6): 5099.
+named component association *note 4.3.1(6): 2696.
+named discriminant association *note 3.7.1(4): 2126.
+named entry index *note 9.5.2(21): 4390.
+named number *note 3.3(24): 1539.
+named parameter association *note 6.4.1(2/3): 3717.
+named type *note 3.2.1(7/2): 1450.
+named_array_aggregate *note 4.3.3(4): 2741.
+ used *note 4.3.3(2): 2731, *note P: 9884.
+Names
+ child of Ada.Interrupts *note C.3.2(12): 8235.
+Nanoseconds
+ in Ada.Real_Time *note D.8(14/2): 8535.
+Native_Binary
+ in Interfaces.COBOL *note B.4(25): 8133.
+Natural *note 3.5.4(12): 1832.
+Natural subtype of Integer
+ in Standard *note A.1(13): 5881.
+NBH
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6050.
+NBSP
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6080.
+needed
+ of a compilation unit by another *note 10.2(2): 4790.
+ remote call interface *note E.2.3(18): 8765.
+ shared passive library unit *note E.2.1(11): 8726.
+needed component
+ extension_aggregate record_component_association_list *note
+4.3.2(6): 2719.
+ record_aggregate record_component_association_list *note 4.3.1(9):
+2699.
+needs finalization *note 7.6(9.1/2): 3936.
+ language-defined type *note A.4.5(72.1/2): 6413, *note
+A.5.2(15.1/2): 6634, *note A.5.2(27.1/2): 6646, *note A.8.1(17/2): 6804,
+*note A.8.4(20/2): 6837, *note A.10.1(86/2): 7014, *note A.12.1(27.1/2):
+7099, *note A.16(102/2): 7186, *note A.18.2(147.3/3): 7319, *note
+A.18.2(84/2): 7314, *note A.18.3(56/2): 7389, *note A.18.3(86.3/3):
+7394, *note A.18.4(4/2): 7410, *note A.18.4(41.3/3): 7420, *note
+A.18.7(4/2): 7547, *note A.18.7(36.2/3): 7556, *note A.18.7(96.2/3):
+7559, *note A.18.10(124/3): 7802, *note A.18.10(73/3): 7797, *note
+A.18.18(27/3): 7841, *note A.18.18(54/3): 7845, *note D.14.2(13/2):
+8637, *note D.15(8/2): 8658.
+NEL
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6052.
+new
+ See allocator *note 4.8(1): 3251.
+New_Char_Array
+ in Interfaces.C.Strings *note B.3.1(9): 8058.
+New_Line
+ in Ada.Text_IO *note A.10.1(28): 6906.
+New_Page
+ in Ada.Text_IO *note A.10.1(31): 6912.
+New_String
+ in Interfaces.C.Strings *note B.3.1(10): 8059.
+Next
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(37/2): 7375,
+*note A.18.3(39/2): 7377.
+ in Ada.Containers.Hashed_Maps *note A.18.5(28/2): 7462, *note
+A.18.5(29/2): 7463.
+ in Ada.Containers.Hashed_Sets *note A.18.8(41/2): 7606, *note
+A.18.8(42/2): 7607.
+ in Ada.Containers.Ordered_Maps *note A.18.6(34/2): 7523, *note
+A.18.6(35/2): 7524.
+ in Ada.Containers.Ordered_Sets *note A.18.9(45/2): 7685, *note
+A.18.9(46/2): 7686.
+ in Ada.Containers.Vectors *note A.18.2(63/2): 7298, *note
+A.18.2(64/2): 7299.
+ in Ada.Iterator_Interfaces *note 5.5.1(3/3): 3442.
+Next_Sibling
+ in Ada.Containers.Multiway_Trees *note A.18.10(64/3): 7789, *note
+A.18.10(66/3): 7791.
+No_Abort_Statements restriction *note D.7(5/3): 8459.
+No_Access_Parameter_Allocators restriction *note H.4(8.3/3): 9078.
+No_Access_Subprograms restriction *note H.4(17): 9088.
+No_Allocators restriction *note H.4(7): 9070.
+No_Anonymous_Allocators restriction *note H.4(8.1/3): 9074.
+No_Break_Space
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6079.
+No_Coextensions restriction *note H.4(8.2/3): 9076.
+No_Delay restriction *note H.4(21): 9098.
+No_Dependence restriction *note 13.12.1(6/2): 5763.
+No_Deposit aspect *note 6.5.1(1.a/3): 3785.
+No_Dispatch restriction *note H.4(19): 9094.
+No_Dynamic_Attachment restriction *note D.7(10/3): 8470.
+No_Dynamic_Priorities restriction *note D.7(9/2): 8468.
+No_Element
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(9/2): 7341.
+ in Ada.Containers.Hashed_Maps *note A.18.5(6/2): 7432.
+ in Ada.Containers.Hashed_Sets *note A.18.8(6/2): 7571.
+ in Ada.Containers.Multiway_Trees *note A.18.10(11/3): 7737.
+ in Ada.Containers.Ordered_Maps *note A.18.6(7/2): 7488.
+ in Ada.Containers.Ordered_Sets *note A.18.9(7/2): 7647.
+ in Ada.Containers.Vectors *note A.18.2(11/2): 7242.
+No_Exceptions restriction *note H.4(12): 9082.
+No_Fixed_Point restriction *note H.4(15): 9086.
+No_Floating_Point restriction *note H.4(14): 9084.
+No_Implementation_Aspect_Specifications restriction *note
+13.12.1(1.1/3): 5751.
+No_Implementation_Attributes restriction *note 13.12.1(2/2): 5753.
+No_Implementation_Identifiers restriction *note 13.12.1(2.1/3): 5755.
+No_Implementation_Pragmas restriction *note 13.12.1(3/2): 5757.
+No_Implementation_Units restriction *note 13.12.1(3.1/3): 5759.
+No_Implicit_Heap_Allocations restriction *note D.7(8): 8466.
+No_Index
+ in Ada.Containers.Vectors *note A.18.2(7/2): 7238.
+No_IO restriction *note H.4(20/2): 9096.
+No_Local_Allocators restriction *note H.4(8/1): 9072.
+No_Local_Protected_Objects restriction *note D.7(10.1/3): 8472.
+No_Local_Timing_Events restriction *note D.7(10.2/3): 8474.
+No_Nested_Finalization restriction *note D.7(4/3): 8457.
+No_Obsolescent_Features restriction *note 13.12.1(4/3): 5761.
+No_Protected_Type_Allocators restriction *note D.7(10.3/2): 8476.
+No_Protected_Types restriction *note H.4(5): 9068.
+No_Recursion restriction *note H.4(22): 9100.
+No_Reentrancy restriction *note H.4(23): 9102.
+No_Relative_Delay restriction *note D.7(10.5/3): 8479.
+No_Requeue_Statements restriction *note D.7(10.6/3): 8481.
+No_Return aspect *note 6.5.1(3.2/3): 3788.
+No_Return pragma *note J.15.2(2/3): 9168, *note L(21.2/3): 9426.
+No_Select_Statements restriction *note D.7(10.7/3): 8483.
+No_Specific_Termination_Handlers restriction *note D.7(10.8/3): 8485.
+No_Specification_of_Aspect restriction *note 13.12.1(6.1/3): 5765.
+No_Standard_Allocators_After_Elaboration restriction *note
+D.7(19.2/3): 8515.
+No_Tag
+ in Ada.Tags *note 3.9(6.1/2): 2231.
+No_Task_Allocators restriction *note D.7(7): 8463.
+No_Task_Hierarchy restriction *note D.7(3/3): 8455.
+No_Task_Termination restriction *note D.7(15.1/2): 8495.
+No_Terminate_Alternatives restriction *note D.7(6): 8461.
+No_Unchecked_Access restriction *note H.4(18): 9090.
+No_Use_Of_Attribute restriction *note 13.12.1(6.2/3): 5767.
+No_Use_Of_Pragma restriction *note 13.12.1(6.3/3): 5769.
+node
+ of a list *note A.18.3(2/2): 7335.
+ of a map *note A.18.4(5/2): 7411.
+ of a tree *note A.18.10(2/3): 7723.
+Node_Count
+ in Ada.Containers.Multiway_Trees *note A.18.10(17/3): 7742.
+nominal subtype *note 3.3(23/3): 1532, *note 3.3.1(8/2): 1571.
+ associated with a dereference *note 4.1(9/3): 2547.
+ associated with a type_conversion *note 4.6(27): 3170.
+ associated with an indexed_component *note 4.1.1(5): 2565.
+ of a component *note 3.6(20): 2027.
+ of a formal parameter *note 6.1(23/2): 3568.
+ of a function result *note 6.1(23/2): 3569.
+ of a generic formal object *note 12.4(9/2): 5146.
+ of a name *note 4.1(9.b): 2548.
+ of a record component *note 3.8(14): 2167.
+ of the result of a function_call *note 6.4(12/2): 3711.
+Non_Preemptive
+ child of Ada.Dispatching *note D.2.4(2.2/3): 8377.
+Non_Preemptive_FIFO_Within_Priorities task disp. policy *note
+D.2.4(2/2): 8376.
+nonconfirming
+ aspect specification *note 13.1(18.2/3): 5317.
+ representation item *note 13.1(18.2/3): 5316.
+ representation value *note 13.1(18.2/3): 5315.
+nondispatching call
+ on a dispatching operation *note 3.9.2(1/2): 2286.
+nonexistent *note 13.11.2(10/2): 5672, *note 13.11.2(16/3): 5680.
+nongraphic character *note 3.5(27.5/2): 1724.
+nonlimited interface *note 3.9.4(5/2): 2355.
+nonlimited type *note 7.5(7): 3910.
+ becoming nonlimited *note 7.3.1(5/1): 3885, *note 7.5(16): 3914.
+nonlimited_with_clause *note 10.1.2(4.2/2): 4709.
+ used *note 10.1.2(4/2): 4705, *note P: 10300.
+nonnormative
+ See informative *note 1.1.2(18): 1011.
+nonreturning *note 6.5.1(3.2/3): 3786.
+nonstandard integer type *note 3.5.4(26): 1855.
+nonstandard mode *note 1.1.5(11): 1102.
+nonstandard real type *note 3.5.6(8): 1888.
+normal completion *note 7.6.1(2/2): 3958.
+normal library unit *note E.2(4/3): 8713.
+normal state of an object *note 11.6(6/3): 5032, *note 13.9.1(4):
+5597.
+ [partial] *note 9.8(21): 4615, *note A.13(17): 7124.
+normal termination
+ of a partition *note 10.2(25.c): 4801.
+Normalize_Scalars pragma *note H.1(3): 9053, *note L(22): 9430.
+normalized exponent *note A.5.3(14): 6678.
+normalized number *note A.5.3(10): 6669.
+normative *note 1.1.2(14): 1008.
+not equal operator *note 4.4(1/3): 2789, *note 4.5.2(1): 2964.
+not in (membership test) *note 4.4(1/3): 2808, *note 4.5.2(2/3): 2985.
+not operator *note 4.4(1/3): 2845, *note 4.5.6(3): 3066.
+Not_A_Specific_CPU
+ in System.Multiprocessors *note D.16(4/3): 8665.
+Not_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6092.
+notes *note 1.1.2(38): 1048.
+notwithstanding *note 7.6(17.5/3): 3949, *note 10.1.6(6/2): 4781,
+*note 10.2(18.c): 4797, *note B.1(22/3): 7965, *note B.1(38/3): 7971,
+*note C.3.1(19/3): 8220, *note E.2.1(8): 8723, *note E.2.1(11): 8727,
+*note E.2.3(18): 8766, *note H.6(7/2): 9117, *note J.3(6): 9124.
+ [partial] *note J.15.5(8/3): 9211.
+NUL
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5949.
+ in Interfaces.C *note B.3(20/1): 8006.
+null access value *note 4.2(9): 2659.
+null array *note 3.6.1(7): 2048.
+null constraint *note 3.2(7/2): 1411.
+null extension *note 3.9.1(4.1/2): 2280.
+null pointer
+ See null access value *note 4.2(9): 2660.
+null procedure *note 6.7(3/3): 3804.
+null range *note 3.5(4): 1676.
+null record *note 3.8(15): 2168.
+null slice *note 4.1.2(7): 2581.
+null string literal *note 2.6(6): 1300.
+null value
+ of an access type *note 3.10(13/2): 2412.
+Null_Address
+ in System *note 13.7(12): 5543.
+Null_Bounded_String
+ in Ada.Strings.Bounded *note A.4.4(7): 6304.
+null_exclusion *note 3.10(5.1/2): 2384.
+ used *note 3.2.2(3/2): 1466, *note 3.7(5/2): 2090, *note 3.10(2/2):
+2375, *note 3.10(6/2): 2388, *note 6.1(13/2): 3544, *note 6.1(15/3):
+3554, *note 8.5.1(2/3): 4083, *note 12.4(2/3): 5131, *note P: 10372.
+Null_Id
+ in Ada.Exceptions *note 11.4.1(2/2): 4929.
+Null_Occurrence
+ in Ada.Exceptions *note 11.4.1(3/2): 4935.
+null_procedure_declaration *note 6.7(2/3): 3799.
+ used *note 3.1(3/3): 1351, *note P: 9649.
+Null_Ptr
+ in Interfaces.C.Strings *note B.3.1(7): 8056.
+Null_Set
+ in Ada.Strings.Maps *note A.4.2(5): 6239.
+ in Ada.Strings.Wide_Maps *note A.4.7(5): 6451.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(5/2): 6493.
+null_statement *note 5.1(6): 3365.
+ used *note 5.1(4/2): 3345, *note P: 9990.
+Null_Task_Id
+ in Ada.Task_Identification *note C.7.1(2/2): 8274.
+Null_Unbounded_String
+ in Ada.Strings.Unbounded *note A.4.5(5): 6364.
+Number of the Beast *note 6.6(6.a/3): 3797.
+number sign *note 2.1(15/3): 1189.
+Number_Base subtype of Integer
+ in Ada.Text_IO *note A.10.1(6): 6867.
+number_decimal *note 2.1(10/2): 1175.
+ used *note 2.3(3.1/3): 1244, *note P: 9607.
+number_declaration *note 3.3.2(2): 1598.
+ used *note 3.1(3/3): 1348, *note P: 9646.
+number_letter *note 2.1(10.1/2): 1176.
+ used *note 2.3(3/2): 1240, *note P: 9604.
+Number_Of_CPUs
+ in System.Multiprocessors *note D.16(5/3): 8667.
+Number_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5984.
+numeral *note 2.4.1(3): 1260.
+ used *note 2.4.1(2): 1258, *note 2.4.1(4): 1265, *note 2.4.2(3):
+1284, *note P: 9611.
+Numeric
+ in Interfaces.COBOL *note B.4(20/3): 8123.
+numeric type *note 3.5(1): 1665.
+numeric_literal *note 2.4(2): 1252.
+ used *note 4.4(7/3): 2901, *note P: 9942.
+numerics *note G(1): 8864.
+ child of Ada *note A.5(3/2): 6579.
+
+
+\1f
+File: aarm2012.info, Node: O, Next: P, Prev: N, Up: Index
+
+O
+==
+
+
+
+O(f(N)) *note A.18(3/2): 7220.
+object *note 3.3(2): 1522, *note N(24): 9559.
+ [partial] *note 3.2(1): 1388.
+object-oriented programming (OOP)
+ See dispatching operations of tagged types *note 3.9.2(1/2): 2292.
+ See tagged types and type extensions *note 3.9(1): 2213.
+object_declaration *note 3.3.1(2/3): 1548.
+ used *note 3.1(3/3): 1347, *note P: 9645.
+object_renaming_declaration *note 8.5.1(2/3): 4081.
+ used *note 8.5(2): 4073, *note P: 10138.
+obsolescent feature *note J(1/2): 9119.
+occur immediately within *note 8.1(13): 3989.
+occurrence
+ of an interrupt *note C.3(2): 8193.
+occurrence (of an exception) *note 11(1.c): 4869.
+octal
+ literal *note 2.4.2(1): 1274.
+octal literal *note 2.4.2(1): 1272.
+Old attribute *note 6.1.1(26/3): 3603.
+one's complement
+ modular types *note 3.5.4(27): 1856.
+one-dimensional array *note 3.6(12): 2013.
+one-pass context_clauses *note 10.1.2(1.a): 4696.
+only as a completion
+ entry_body *note 9.5.2(16): 4381.
+OOP (object-oriented programming)
+ See dispatching operations of tagged types *note 3.9.2(1/2): 2293.
+ See tagged types and type extensions *note 3.9(1): 2214.
+opaque type
+ See private types and private extensions *note 7.3(1): 3854.
+Open
+ in Ada.Direct_IO *note A.8.4(7): 6813.
+ in Ada.Sequential_IO *note A.8.1(7): 6785.
+ in Ada.Streams.Stream_IO *note A.12.1(9): 7072.
+ in Ada.Text_IO *note A.10.1(10): 6870.
+open alternative *note 9.7.1(14): 4554.
+open entry *note 9.5.3(5): 4406.
+ of a protected object *note 9.5.3(7/3): 4412.
+ of a task *note 9.5.3(6/3): 4410.
+operand
+ of a qualified_expression *note 4.7(3): 3241.
+ of a type_conversion *note 4.6(3): 3137.
+operand interval *note G.2.1(6): 8947.
+operand type
+ of a type_conversion *note 4.6(3): 3138.
+operates on a type *note 3.2.3(1/2): 1491.
+operation *note 3.2(10.a): 1427.
+operational aspect *note 13.1(8.1/3): 5304.
+ specifiable attributes *note 13.3(5/3): 5367.
+operational item *note 13.1(1.1/1): 5280.
+operator *note 6.6(1): 3793.
+ & *note 4.4(1/3): 2818, *note 4.5.3(3): 3014.
+ * *note 4.4(1/3): 2825, *note 4.5.5(1): 3041.
+ ** *note 4.4(1/3): 2839, *note 4.5.6(7): 3075.
+ + *note 4.4(1/3): 2810, *note 4.5.3(1): 3006, *note 4.5.4(1): 3031.
+ - *note 4.4(1/3): 2814, *note 4.5.3(1): 3010, *note 4.5.4(1): 3035.
+ / *note 4.4(1/3): 2831, *note 4.5.5(1): 3047.
+ /= *note 4.4(1/3): 2788, *note 4.5.2(1): 2963.
+ < *note 4.4(1/3): 2792, *note 4.5.2(1): 2967.
+ <= *note 4.4(1/3): 2796, *note 4.5.2(1): 2971.
+ = *note 4.4(1/3): 2784, *note 4.5.2(1): 2959.
+ > *note 4.4(1/3): 2800, *note 4.5.2(1): 2975.
+ >= *note 4.4(1/3): 2804, *note 4.5.2(1): 2979.
+ abs *note 4.4(1/3): 2843, *note 4.5.6(1): 3064.
+ ampersand *note 4.4(1/3): 2820, *note 4.5.3(3): 3016.
+ and *note 4.4(1/3): 2776, *note 4.5.1(2): 2938.
+ binary *note 4.5(9): 2925.
+ binary adding *note 4.5.3(1): 3004.
+ concatenation *note 4.4(1/3): 2822, *note 4.5.3(3): 3018.
+ divide *note 4.4(1/3): 2833, *note 4.5.5(1): 3049.
+ equal *note 4.4(1/3): 2786, *note 4.5.2(1): 2961.
+ equality *note 4.5.2(1): 2955.
+ exponentiation *note 4.4(1/3): 2841, *note 4.5.6(7): 3073.
+ greater than *note 4.4(1/3): 2802, *note 4.5.2(1): 2977.
+ greater than or equal *note 4.4(1/3): 2806, *note 4.5.2(1): 2981.
+ highest precedence *note 4.5.6(1): 3062.
+ less than *note 4.4(1/3): 2794, *note 4.5.2(1): 2969.
+ less than or equal *note 4.4(1/3): 2798, *note 4.5.2(1): 2973.
+ logical *note 4.5.1(2): 2936.
+ minus *note 4.4(1/3): 2816, *note 4.5.3(1): 3012, *note 4.5.4(1):
+3037.
+ mod *note 4.4(1/3): 2835, *note 4.5.5(1): 3051.
+ multiply *note 4.4(1/3): 2827, *note 4.5.5(1): 3043.
+ multiplying *note 4.5.5(1): 3039.
+ not *note 4.4(1/3): 2846, *note 4.5.6(3): 3067.
+ not equal *note 4.4(1/3): 2790, *note 4.5.2(1): 2965.
+ or *note 4.4(1/3): 2778, *note 4.5.1(2): 2940.
+ ordering *note 4.5.2(1): 2957.
+ plus *note 4.4(1/3): 2812, *note 4.5.3(1): 3008, *note 4.5.4(1):
+3033.
+ predefined *note 4.5(9): 2923.
+ relational *note 4.5.2(1): 2952.
+ rem *note 4.4(1/3): 2837, *note 4.5.5(1): 3053.
+ times *note 4.4(1/3): 2829, *note 4.5.5(1): 3045.
+ unary *note 4.5(9): 2927.
+ unary adding *note 4.5.4(1): 3029.
+ user-defined *note 6.6(1): 3795.
+ xor *note 4.4(1/3): 2780, *note 4.5.1(2): 2942.
+operator precedence *note 4.5(1): 2915.
+operator_symbol *note 6.1(9): 3536.
+ used *note 4.1(3): 2537, *note 4.1.3(3): 2590, *note 6.1(5): 3529,
+*note 6.1(11): 3539, *note P: 10055.
+optimization *note 11.5(29): 5017, *note 11.6(1/3): 5025.
+Optimize pragma *note 2.8(23): 1335, *note L(23): 9432.
+or else (short-circuit control form) *note 4.4(1/3): 2782, *note
+4.5.1(1): 2933.
+or operator *note 4.4(1/3): 2777, *note 4.5.1(2): 2939.
+Ordered_Maps
+ child of Ada.Containers *note A.18.6(2/3): 7483.
+Ordered_Sets
+ child of Ada.Containers *note A.18.9(2/3): 7642.
+ordering operator *note 4.5.2(1): 2956.
+ordinary file *note A.16(45/2): 7179.
+ordinary fixed point type *note 3.5.9(1): 1923, *note 3.5.9(8/2):
+1945.
+ordinary_fixed_point_definition *note 3.5.9(3): 1929.
+ used *note 3.5.9(2): 1927, *note P: 9730.
+OSC
+ in Ada.Characters.Latin_1 *note A.3.3(19): 6076.
+other_control *note 2.1(13.1/2): 1184.
+other_format *note 2.1(10.3/2): 1178.
+other_private_use *note 2.1(13.2/2): 1185.
+other_surrogate *note 2.1(13.3/2): 1186.
+others choice *note 4.3.3(6.b): 2751.
+output *note A.6(1/2): 6760.
+Output aspect *note 13.13.2(38/3): 5827.
+Output attribute *note 13.13.2(19): 5800, *note 13.13.2(29): 5804.
+Output clause *note 13.3(7/2): 5382, *note 13.13.2(38/3): 5819.
+overall interpretation
+ of a complete context *note 8.6(10): 4145.
+Overflow_Check *note 11.5(16): 5005.
+ [partial] *note 3.5.4(20): 1845, *note 4.4(11): 2910, *note
+4.5.7(21/3): 3106, *note 5.4(13): 3415, *note G.2.1(11): 8949, *note
+G.2.2(7): 8965, *note G.2.3(25): 8971, *note G.2.4(2): 8977, *note
+G.2.6(3): 8984.
+Overlap
+ in Ada.Containers.Hashed_Sets *note A.18.8(38/2): 7603.
+ in Ada.Containers.Ordered_Sets *note A.18.9(39/2): 7679.
+Overlaps_Storage attribute *note 13.3(73.6/3): 5446.
+overload resolution *note 8.6(1/3): 4140.
+overloadable *note 8.3(7): 4022.
+overloaded *note 8.3(6): 4021.
+ enumeration literal *note 3.5.1(9): 1780.
+overloading rules *note 1.1.2(26/3): 1019, *note 8.6(2): 4141.
+overridable *note 8.3(9/1): 4026.
+override *note 8.3(9/1): 4025, *note 12.3(17): 5117.
+ a primitive subprogram *note 3.2.3(7/2): 1495.
+ when implemented by *note 8.3(13.b/3): 4028, *note 9.1(9.2/3):
+4225, *note 9.4(11.1/3): 4298.
+overriding operation *note N(24.1/2): 9560.
+overriding_indicator *note 8.3.1(2/2): 4050.
+ used *note 3.9.3(1.1/3): 2327, *note 6.1(2/3): 3514, *note
+6.3(2/3): 3640, *note 6.7(2/3): 3800, *note 6.8(2/3): 3810, *note
+8.5.4(2/3): 4112, *note 9.5.2(2/3): 4348, *note 10.1.3(3/3): 4729, *note
+12.3(2/3): 5081, *note P: 10355.
+Overwrite
+ in Ada.Strings.Bounded *note A.4.4(62): 6344, *note A.4.4(63):
+6345.
+ in Ada.Strings.Fixed *note A.4.3(27): 6285, *note A.4.3(28): 6286.
+ in Ada.Strings.Unbounded *note A.4.5(57): 6401, *note A.4.5(58):
+6402.
+
+
+\1f
+File: aarm2012.info, Node: P, Next: Q, Prev: O, Up: Index
+
+P
+==
+
+
+
+Pack aspect *note 13.2(5.1/3): 5349.
+Pack pragma *note J.15.3(2/3): 9174, *note L(24.1/3): 9435.
+Package *note 7(1): 3820, *note N(25): 9561.
+package instance *note 12.3(13): 5109.
+package-private extension *note 7.3(14.a): 3876.
+package-private type *note 7.3(14.a): 3875.
+package_body *note 7.2(2/3): 3842.
+ used *note 3.11(6): 2503, *note 10.1.1(7): 4670, *note P: 9827.
+package_body_stub *note 10.1.3(4): 4732.
+ used *note 10.1.3(2): 4725, *note P: 10306.
+package_declaration *note 7.1(2): 3825.
+ used *note 3.1(3/3): 1353, *note 10.1.1(5): 4661, *note P: 10287.
+package_renaming_declaration *note 8.5.3(2/3): 4104.
+ used *note 8.5(2): 4075, *note 10.1.1(6): 4665, *note P: 10140.
+package_specification *note 7.1(3/3): 3827.
+ used *note 7.1(2): 3826, *note 12.1(4): 5049, *note P: 10111.
+packed *note 13.2(5.1/3): 5347.
+Packed_Decimal
+ in Interfaces.COBOL *note B.4(12/3): 8114.
+Packed_Format
+ in Interfaces.COBOL *note B.4(26): 8134.
+Packed_Signed
+ in Interfaces.COBOL *note B.4(27): 8136.
+Packed_Unsigned
+ in Interfaces.COBOL *note B.4(27): 8135.
+padding bits *note 13.1(7/2): 5294.
+Page
+ in Ada.Text_IO *note A.10.1(39): 6927.
+Page pragma *note 2.8(22): 1333, *note L(25): 9438.
+page terminator *note A.10(7): 6850.
+Page_Length
+ in Ada.Text_IO *note A.10.1(26): 6904.
+Paragraph_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6104.
+parallel processing
+ See task *note 9(1/3): 4181.
+parameter
+ explicitly aliased *note 6.1(23.1/3): 3571.
+ See formal parameter *note 6.1(17): 3563.
+ See generic formal parameter *note 12(1): 5039.
+ See also discriminant *note 3.7(1/2): 2078.
+ See also loop parameter *note 5.5(6): 3433.
+parameter assigning back *note 6.4.1(17): 3731.
+parameter copy back *note 6.4.1(17): 3729.
+parameter mode *note 6.1(18/3): 3564.
+parameter passing *note 6.4.1(1): 3714.
+parameter_and_result_profile *note 6.1(13/2): 3542.
+ used *note 3.10(5): 2383, *note 3.10(6/2): 2391, *note 6.1(4.2/2):
+3525, *note P: 9815.
+parameter_association *note 6.4(5): 3700.
+ used *note 6.4(4): 3698, *note P: 10091.
+parameter_profile *note 6.1(12): 3540.
+ used *note 3.10(5): 2382, *note 3.10(6/2): 2389, *note 6.1(4.1/2):
+3522, *note 9.5.2(2/3): 4351, *note 9.5.2(3): 4356, *note 9.5.2(6):
+4370, *note P: 9808.
+parameter_specification *note 6.1(15/3): 3551.
+ used *note 6.1(14): 3549, *note P: 10068.
+Parameterless_Handler
+ in Ada.Interrupts *note C.3.2(2/3): 8226.
+Params_Stream_Type
+ in System.RPC *note E.5(6): 8811.
+parent *note N(25.1/2): 9562.
+ in Ada.Containers.Multiway_Trees *note A.18.10(59/3): 7784.
+parent body
+ of a subunit *note 10.1.3(8/2): 4744.
+parent declaration
+ of a library unit *note 10.1.1(10): 4680.
+ of a library_item *note 10.1.1(10): 4679.
+parent subtype *note 3.4(3/2): 1613.
+parent type *note 3.4(3/2): 1614.
+parent unit
+ of a library unit *note 10.1.1(10): 4682.
+Parent_Tag
+ in Ada.Tags *note 3.9(7.2/2): 2239.
+parent_unit_name *note 10.1.1(8): 4671.
+ used *note 6.1(5): 3527, *note 6.1(7): 3534, *note 7.1(3/3): 3832,
+*note 7.2(2/3): 3847, *note 10.1.3(7): 4742, *note P: 10116.
+part
+ of a type *note 3.2(6/2): 1408.
+ of an object or value *note 3.2(6/2): 1407.
+partial view
+ of a type *note 7.3(4): 3867.
+partition *note 10.2(2): 4785, *note N(26): 9563.
+partition building *note 10.2(2): 4786.
+partition communication subsystem (PCS) *note E.5(1/2): 8806.
+Partition_Check
+ [partial] *note E.4(19): 8796.
+Partition_Elaboration_Policy pragma *note H.6(3/2): 9113, *note
+L(25.1/2): 9440.
+Partition_Id
+ in System.RPC *note E.5(4): 8809.
+Partition_Id attribute *note E.1(9): 8701.
+pass by copy *note 6.2(2): 3621.
+pass by reference *note 6.2(2): 3624.
+passive partition *note E.1(2): 8693.
+Pattern_Error
+ in Ada.Strings *note A.4.1(5): 6228.
+PC-map approach to finalization *note 7.6.1(24.s): 3984.
+PCS (partition communication subsystem) *note E.5(1/2): 8807.
+Peak_Use
+ in Ada.Containers.Bounded_Priority_Queues *note A.18.31(7/3): 7922.
+ in Ada.Containers.Bounded_Synchronized_Queues *note A.18.29(6/3):
+7906.
+ in Ada.Containers.Synchronized_Queue_Interfaces *note A.18.27(7/3):
+7891.
+ in Ada.Containers.Unbounded_Priority_Queues *note A.18.30(7/3):
+7914.
+ in Ada.Containers.Unbounded_Synchronized_Queues *note A.18.28(6/3):
+7899.
+pending interrupt occurrence *note C.3(2): 8196.
+per-object constraint *note 3.8(18/2): 2174.
+per-object expression *note 3.8(18/2): 2173.
+percent sign *note 2.1(15/3): 1215.
+Percent_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5986.
+perfect result set *note G.2.3(5): 8969.
+periodic task
+ example *note 9.6(39): 4480.
+ See delay_until_statement *note 9.6(39): 4481.
+Pi
+ in Ada.Numerics *note A.5(3/2): 6581.
+Pic_String
+ in Ada.Text_IO.Editing *note F.3.3(7): 8844.
+Picture
+ in Ada.Text_IO.Editing *note F.3.3(4): 8841.
+picture String
+ for edited output *note F.3.1(1/3): 8837.
+Picture_Error
+ in Ada.Text_IO.Editing *note F.3.3(9): 8847.
+Pilcrow_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6103.
+plain_char
+ in Interfaces.C *note B.3(11): 7999.
+plane
+ character *note 2.1(1/3): 1165.
+PLD
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6058.
+PLU
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6059.
+plus operator *note 4.4(1/3): 2811, *note 4.5.3(1): 3007, *note
+4.5.4(1): 3032.
+plus sign *note 2.1(15/3): 1197.
+Plus_Minus_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6098.
+Plus_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5992.
+PM
+ in Ada.Characters.Latin_1 *note A.3.3(19): 6077.
+point *note 2.1(15/3): 1203.
+Pointer
+ in Interfaces.C.Pointers *note B.3.2(5): 8077.
+ See access value *note 3.10(1): 2370.
+ See type System.Address *note 13.7(34/2): 5556.
+pointer type
+ See access type *note 3.10(1): 2371.
+Pointer_Error
+ in Interfaces.C.Pointers *note B.3.2(8): 8080.
+Pointers
+ child of Interfaces.C *note B.3.2(4): 8076.
+polymorphism *note 3.9(1): 2209, *note 3.9.2(1/2): 2289.
+pool
+ default *note 13.11.3(4.1/3): 5689.
+ subpool *note 13.11.4(18/3): 5708.
+pool element *note 3.10(7/1): 2397, *note 13.11(11): 5630.
+pool type *note 13.11(11): 5628.
+pool-specific access type *note 3.10(7/1): 2394, *note 3.10(8): 2398.
+Pool_of_Subpool
+ in System.Storage_Pools.Subpools *note 13.11.4(9/3): 5699.
+Pos attribute *note 3.5.5(2): 1864.
+position *note 13.5.1(4): 5488.
+ used *note 13.5.1(3): 5485, *note P: 10453.
+Position attribute *note 13.5.2(2/2): 5504.
+position number *note 3.5(1): 1664.
+ of an enumeration value *note 3.5.1(7): 1779.
+ of an integer value *note 3.5.4(15): 1839.
+positional association *note 6.4(7): 3707, *note 6.4.1(2/3): 3716,
+*note 12.3(6): 5100.
+positional component association *note 4.3.1(6): 2697.
+positional discriminant association *note 3.7.1(4): 2127.
+positional parameter association *note 6.4.1(2/3): 3718.
+positional_array_aggregate *note 4.3.3(3/2): 2732.
+ used *note 4.3.3(2): 2730, *note P: 9883.
+Positive *note 3.5.4(12): 1833.
+Positive subtype of Integer
+ in Standard *note A.1(13): 5882.
+Positive_Count subtype of Count
+ in Ada.Direct_IO *note A.8.4(4): 6811.
+ in Ada.Streams.Stream_IO *note A.12.1(7): 7070.
+ in Ada.Text_IO *note A.10.1(5): 6864.
+POSIX *note 1.2(10.a): 1144.
+possible interpretation *note 8.6(14): 4146.
+ for direct_names *note 8.3(24): 4044.
+ for selector_names *note 8.3(24): 4045.
+Post aspect *note 6.1.1(4/3): 3591.
+Post'Class aspect *note 6.1.1(5/3): 3595.
+post-compilation error *note 1.1.2(29): 1028.
+post-compilation rules *note 1.1.2(29): 1029.
+postcondition *note N(26.1/3): 9564.
+postcondition check *note 6.1.1(35/3): 3615.
+postcondition expression
+ class-wide *note 6.1.1(5/3): 3593.
+ specific *note 6.1.1(4/3): 3589.
+potentially blocking operation *note 9.5.1(8): 4344.
+ Abort_Task *note C.7.1(16): 8287.
+ delay_statement *note 9.6(34): 4478, *note D.9(5): 8550.
+ remote subprogram call *note E.4(17): 8791.
+ RPC operations *note E.5(23): 8820.
+ Suspend_Until_True *note D.10(10): 8562.
+potentially unevaluated expression *note 6.1.1(20/3): 3601.
+potentially use-visible *note 8.4(8/3): 4066.
+ [partial] *note 12.6(9.2/3): 5251.
+Pound_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6083.
+Pragma *note 2.8(1): 1303, *note 2.8(2): 1304, *note L(1): 9327, *note
+N(27): 9565.
+pragma argument *note 2.8(9): 1319.
+pragma name *note 2.8(9): 1318.
+pragma, categorization *note E.2(2/3): 8705.
+ Remote_Call_Interface *note E.2.3(2): 8746.
+ Remote_Types *note E.2.2(2): 8730.
+ Shared_Passive *note E.2.1(2): 8715.
+pragma, configuration *note 10.1.5(8): 4768.
+ Assertion_Policy *note 11.4.2(7/3): 4970.
+ Detect_Blocking *note H.5(4/2): 9110.
+ Discard_Names *note C.5(4): 8246.
+ Locking_Policy *note D.3(5): 8414.
+ Normalize_Scalars *note H.1(4): 9055.
+ Partition_Elaboration_Policy *note H.6(5/2): 9116.
+ Priority_Specific_Dispatching *note D.2.2(5/2): 8365.
+ Profile *note 13.12(14/3): 5747.
+ Queuing_Policy *note D.4(5): 8436.
+ Restrictions *note 13.12(8/3): 5741.
+ Reviewable *note H.3.1(4): 9060.
+ Suppress *note 11.5(5/2): 4994.
+ Task_Dispatching_Policy *note D.2.2(5/2): 8363.
+ Unsuppress *note 11.5(5/2): 4996.
+pragma, identifier specific to *note 2.8(10/3): 1322.
+pragma, interfacing
+ Convention *note J.15.5(1/3): 9186.
+ Export *note J.15.5(1/3): 9184.
+ Import *note J.15.5(1/3): 9182.
+pragma, library unit *note 10.1.5(7/3): 4764.
+ All_Calls_Remote *note E.2.3(6): 8754.
+ categorization pragmas *note E.2(2/3): 8707.
+ Elaborate_Body *note 10.2.1(24): 4850.
+ Preelaborate *note 10.2.1(4): 4815.
+ Pure *note 10.2.1(15): 4832.
+pragma, program unit *note 10.1.5(2): 4761.
+ Inline *note J.15.1(1/3): 9157.
+ library unit pragmas *note 10.1.5(7/3): 4766.
+pragma, representation *note 13.1(1/1): 5279.
+ Asynchronous *note J.15.13(1/3): 9276.
+ Atomic *note J.15.8(9/3): 9246.
+ Atomic_Components *note J.15.8(9/3): 9250.
+ Convention *note J.15.5(1/3): 9192.
+ Discard_Names *note C.5(6): 8248.
+ Export *note J.15.5(1/3): 9190.
+ Import *note J.15.5(1/3): 9188.
+ Independent *note J.15.8(9/3): 9254.
+ Independent_Components *note J.15.8(9/3): 9256.
+ No_Return *note J.15.2(1/3): 9166.
+ Pack *note J.15.3(1/3): 9172.
+ Unchecked_Union *note J.15.6(1/3): 9213.
+ Volatile *note J.15.8(9/3): 9248.
+ Volatile_Components *note J.15.8(9/3): 9252.
+pragma_argument_association *note 2.8(3/3): 1308.
+ used *note 2.8(2): 1306, *note 13.12(11/3): 5745, *note L(27.3/3):
+9458, *note P: 9633.
+pragmas
+ All_Calls_Remote *note E.2.3(5): 8750, *note L(2): 9328.
+ Assert *note 11.4.2(3/2): 4956, *note L(2.1/2): 9331.
+ Assertion_Policy *note 11.4.2(6.1/3): 4963, *note 11.4.2(6/2):
+4960, *note L(2.2/2): 9335, *note L(2.3/3): 9338.
+ Asynchronous *note J.15.13(2/3): 9277, *note L(3.1/3): 9344.
+ Atomic *note J.15.8(2/3): 9227, *note L(4.1/3): 9347.
+ Atomic_Components *note J.15.8(5/3): 9236, *note L(5.1/3): 9350.
+ Attach_Handler *note J.15.7(4/3): 9220, *note L(6.1/3): 9353.
+ Convention *note J.15.5(4/3): 9205, *note L(8.1/3): 9357.
+ CPU *note J.15.9(2/3): 9257, *note L(8.2/3): 9361.
+ Default_Storage_Pool *note 13.11.3(3/3): 5682, *note L(8.3/3):
+9364.
+ Detect_Blocking *note H.5(3/2): 9107, *note L(8.4/2): 9367.
+ Discard_Names *note C.5(3): 8242, *note L(9): 9369.
+ Dispatching_Domain *note J.15.10(2/3): 9262, *note L(9.1/3): 9372.
+ Elaborate *note 10.2.1(20): 4838, *note L(10): 9374.
+ Elaborate_All *note 10.2.1(21): 4842, *note L(11): 9378.
+ Elaborate_Body *note 10.2.1(22): 4846, *note L(12): 9382.
+ Export *note J.15.5(3/3): 9199, *note L(13.1/3): 9385.
+ Import *note J.15.5(2/3): 9193, *note L(14.1/3): 9391.
+ Independent *note J.15.8(4/3): 9233, *note L(14.2/3): 9397.
+ Independent_Components *note J.15.8(7/3): 9242, *note L(14.3/3):
+9400.
+ Inline *note J.15.1(2/3): 9158, *note L(15.1/3): 9403.
+ Inspection_Point *note H.3.2(3): 9061, *note L(16): 9407.
+ Interrupt_Handler *note J.15.7(2/3): 9217, *note L(17.1/3): 9411.
+ Interrupt_Priority *note J.15.11(4/3): 9268, *note L(18.1/3): 9414.
+ Linker_Options *note B.1(8): 7956, *note L(19): 9416.
+ List *note 2.8(21): 1329, *note L(20): 9419.
+ Locking_Policy *note D.3(3): 8407, *note L(21): 9422.
+ No_Return *note J.15.2(2/3): 9167, *note L(21.2/3): 9425.
+ Normalize_Scalars *note H.1(3): 9052, *note L(22): 9429.
+ Optimize *note 2.8(23): 1334, *note L(23): 9431.
+ Pack *note J.15.3(2/3): 9173, *note L(24.1/3): 9434.
+ Page *note 2.8(22): 1332, *note L(25): 9437.
+ Partition_Elaboration_Policy *note H.6(3/2): 9112, *note L(25.1/2):
+9439.
+ Preelaborable_Initialization *note 10.2.1(4.2/2): 4816, *note
+L(25.2/2): 9442.
+ Preelaborate *note 10.2.1(3): 4811, *note L(26): 9445.
+ Priority *note J.15.11(2/3): 9266, *note L(27.1/3): 9448.
+ Priority_Specific_Dispatching *note D.2.2(3.2/2): 8357, *note
+L(27.2/2): 9450.
+ Profile *note 13.12(11/3): 5742, *note L(27.3/3): 9455.
+ Pure *note 10.2.1(14): 4828, *note L(28): 9459.
+ Queuing_Policy *note D.4(3): 8430, *note L(29): 9462.
+ Relative_Deadline *note J.15.12(2/3): 9272, *note L(29.2/3): 9465.
+ Remote_Call_Interface *note E.2.3(3): 8747, *note L(30): 9467.
+ Remote_Types *note E.2.2(3): 8731, *note L(31): 9470.
+ Restrictions *note 13.12(3): 5728, *note L(32): 9473.
+ Reviewable *note H.3.1(3): 9057, *note L(33): 9477.
+ Shared_Passive *note E.2.1(3): 8716, *note L(34): 9479.
+ Storage_Size *note J.15.4(2/3): 9176, *note L(35.1/3): 9482.
+ Suppress *note 11.5(4/2): 4987, *note J.10(3/2): 9147, *note L(36):
+9485.
+ Task_Dispatching_Policy *note D.2.2(3): 8354, *note L(37): 9488.
+ Unchecked_Union *note J.15.6(2/3): 9214, *note L(37.2/3): 9491.
+ Unsuppress *note 11.5(4.1/2): 4990, *note L(37.3/2): 9494.
+ Volatile *note J.15.8(3/3): 9230, *note L(38.1/3): 9497.
+ Volatile_Components *note J.15.8(6/3): 9239, *note L(39.1/3): 9500.
+Pre aspect *note 6.1.1(2/3): 3583.
+Pre'Class aspect *note 6.1.1(3/3): 3587.
+precedence of operators *note 4.5(1): 2914.
+precondition *note N(27.1/3): 9566.
+precondition check
+ class-wide *note 6.1.1(33/3): 3612.
+ specific *note 6.1.1(32/3): 3609.
+precondition expression
+ class-wide *note 6.1.1(3/3): 3585.
+ specific *note 6.1.1(2/3): 3581.
+Pred attribute *note 3.5(25): 1715.
+predecessor element
+ of an ordered set *note A.18.9(81/3): 7718.
+predecessor node
+ of an ordered map *note A.18.6(58/3): 7540.
+predefined environment *note A(1): 5874.
+predefined exception *note 11.1(4): 4874.
+predefined library unit
+ See language-defined library units
+predefined operation
+ of a type *note 3.2.3(1/2): 1492.
+predefined operations
+ of a discrete type *note 3.5.5(10/3): 1876.
+ of a fixed point type *note 3.5.10(17): 1985.
+ of a floating point type *note 3.5.8(3): 1921.
+ of a record type *note 3.8(24): 2178.
+ of an access type *note 3.10.2(34/2): 2480.
+ of an array type *note 3.6.2(15): 2069.
+predefined operator *note 4.5(9): 2922.
+ [partial] *note 3.2.1(9): 1456.
+predefined type *note 3.2.1(10): 1457.
+ See language-defined types
+predicate *note 4.5.8(3/3): 3119, *note N(27.2/3): 9567.
+ of a subtype *note 3.2.4(6/3): 1507.
+ used *note 4.5.8(1/3): 3114, *note P: 9965.
+predicate aspect *note 3.2.4(1/3): 1499.
+predicate check
+ allocator *note 3.2.4(31/3): 1516.
+ enabled *note 3.2.4(7/3): 1510.
+ in out parameters *note 3.2.4(31/3): 1514.
+ object_declaration *note 3.2.4(31/3): 1515.
+ subtype conversion *note 4.6(51/3): 3213.
+predicate evaluated
+ membership *note 4.5.2(29/3): 2997.
+ Valid attribute *note 13.9.2(3/3): 5612, *note K.2(263/3): 9324.
+predicate specification *note 3.2.4(1/3): 1500.
+predicate-static *note 3.2.4(15/3): 1511.
+preelaborable
+ of an elaborable construct *note 10.2.1(5): 4819.
+preelaborable initialization *note 10.2.1(11.1/2): 4826.
+Preelaborable_Initialization pragma *note 10.2.1(4.2/2): 4817, *note
+L(25.2/2): 9443.
+Preelaborate aspect *note 10.2.1(11/3): 4823.
+Preelaborate pragma *note 10.2.1(3): 4812, *note L(26): 9446.
+preelaborated *note 10.2.1(11/3): 4825.
+ [partial] *note 10.2.1(11/3): 4821, *note E.2.1(9): 8724.
+preempt
+ a running task *note D.2.3(9/2): 8373.
+preference
+ for root numeric operators and ranges *note 8.6(29): 4166.
+ for universal access equality operators *note 8.6(29.1/3): 4167.
+preference control
+ See requeue *note 9.5.4(1): 4429.
+prefix *note 4.1(4): 2538.
+ of a prefixed view *note 4.1.3(9.2/3): 2593.
+ used *note 4.1.1(2): 2561, *note 4.1.2(2): 2574, *note 4.1.3(2):
+2585, *note 4.1.4(2): 2604, *note 4.1.4(4): 2610, *note 4.1.6(10/3):
+2641, *note 6.4(2): 3691, *note 6.4(3): 3695, *note P: 9862.
+prefixed view *note 4.1.3(9.2/3): 2592.
+prefixed view profile *note 6.3.1(24.1/2): 3682.
+Prepend
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(22/2): 7360.
+ in Ada.Containers.Vectors *note A.18.2(44/2): 7279, *note
+A.18.2(45/2): 7280.
+Prepend_Child
+ in Ada.Containers.Multiway_Trees *note A.18.10(51/3): 7776.
+prescribed result
+ for the evaluation of a complex arithmetic operation *note
+G.1.1(42): 8892.
+ for the evaluation of a complex elementary function *note
+G.1.2(35): 8920.
+ for the evaluation of an elementary function *note A.5.1(37): 6620.
+Previous
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(38/2): 7376,
+*note A.18.3(40/2): 7378.
+ in Ada.Containers.Ordered_Maps *note A.18.6(36/2): 7525, *note
+A.18.6(37/2): 7526.
+ in Ada.Containers.Ordered_Sets *note A.18.9(47/2): 7687, *note
+A.18.9(48/2): 7688.
+ in Ada.Containers.Vectors *note A.18.2(65/2): 7300, *note
+A.18.2(66/2): 7301.
+ in Ada.Iterator_Interfaces *note 5.5.1(4/3): 3445.
+Previous_Sibling
+ in Ada.Containers.Multiway_Trees *note A.18.10(65/3): 7790, *note
+A.18.10(67/3): 7792.
+primary *note 4.4(7/3): 2900.
+ used *note 4.4(6): 2896, *note P: 9938.
+primitive function *note A.5.3(17): 6679.
+primitive operation
+ [partial] *note 3.2(1): 1387.
+primitive operations *note N(28): 9568.
+ of a type *note 3.2.3(1/2): 1493.
+primitive operator
+ of a type *note 3.2.3(8): 1496.
+primitive subprograms
+ of a type *note 3.2.3(2): 1494.
+priority *note D.1(15): 8329.
+ of a protected object *note D.3(6/2): 8416.
+Priority aspect *note D.1(6.2/3): 8325.
+Priority attribute *note D.5.2(3/2): 8451.
+priority inheritance *note D.1(15): 8330.
+priority inversion *note D.2.3(11/2): 8374.
+priority of an entry call *note D.4(9): 8442.
+Priority pragma *note J.15.11(2/3): 9267, *note L(27.1/3): 9449.
+Priority subtype of Any_Priority
+ in System *note 13.7(16): 5553.
+Priority_Queuing queuing policy *note D.4(8): 8441.
+Priority_Specific_Dispatching pragma *note D.2.2(3.2/2): 8358, *note
+L(27.2/2): 9451.
+private declaration of a library unit *note 10.1.1(12): 4688.
+private descendant
+ of a library unit *note 10.1.1(12): 4690.
+private extension *note 3.2(4.1/2): 1404, *note 3.9(2.1/2): 2220,
+*note 3.9.1(1/2): 2274, *note N(29/2): 9569.
+ [partial] *note 7.3(14): 3874, *note 12.5.1(5/3): 5197.
+private library unit *note 10.1.1(12): 4687.
+private operations *note 7.3.1(1): 3883.
+private part *note 8.2(5): 3999.
+ of a package *note 7.1(6/2): 3837, *note 12.3(12.b): 5108.
+ of a protected unit *note 9.4(11/2): 4297.
+ of a task unit *note 9.1(9): 4224.
+private type *note 3.2(4.1/2): 1403, *note N(30/2): 9570.
+ [partial] *note 7.3(14): 3873.
+private types and private extensions *note 7.3(1): 3852.
+private with_clause *note 10.1.2(4.b/2): 4712.
+private_extension_declaration *note 7.3(3/3): 3861.
+ used *note 3.2.1(2): 1432, *note P: 9660.
+private_type_declaration *note 7.3(2/3): 3857.
+ used *note 3.2.1(2): 1431, *note P: 9659.
+procedure *note 6(1): 3508, *note N(30.1/2): 9571.
+ null *note 6.7(3/3): 3805.
+procedure instance *note 12.3(13): 5111.
+procedure_call_statement *note 6.4(2): 3689.
+ used *note 5.1(4/2): 3349, *note 9.7.2(3.1/2): 4567, *note P: 9994.
+procedure_or_entry_call *note 9.7.2(3.1/2): 4566.
+ used *note 9.7.2(3/2): 4564, *note 9.7.4(4/2): 4582, *note P:
+10263.
+procedure_specification *note 6.1(4.1/2): 3520.
+ used *note 6.1(4/2): 3518, *note 6.7(2/3): 3801, *note P: 10047.
+processing node *note E(2): 8687.
+profile *note 6.1(22): 3567.
+ associated with a dereference *note 4.1(10): 2549.
+ fully conformant *note 6.3.1(18/3): 3677.
+ mode conformant *note 6.3.1(16/3): 3670.
+ No_Implementation_Extensions *note 13.12.1(10/3): 5770.
+ subtype conformant *note 6.3.1(17/3): 3673.
+ type conformant *note 6.3.1(15/2): 3667.
+Profile pragma *note 13.12(11/3): 5743, *note L(27.3/3): 9456.
+profile resolution rule
+ name with a given expected profile *note 8.6(26): 4161.
+progenitor *note N(30.2/2): 9572.
+progenitor subtype *note 3.9.4(9/2): 2363.
+progenitor type *note 3.9.4(9/2): 2364.
+program *note 10.2(1): 4782, *note N(31): 9573.
+program execution *note 10.2(1): 4783.
+program library
+ See library *note 10(2): 4636.
+ See library *note 10.1.4(9): 4758.
+Program unit *note 10.1(1): 4643, *note N(32): 9574.
+program unit pragma *note 10.1.5(2): 4760.
+ Inline *note J.15.1(1/3): 9156.
+ library unit pragmas *note 10.1.5(7/3): 4765.
+program-counter-map approach to finalization *note 7.6.1(24.s): 3985.
+Program_Error
+ raised by failure of run-time check *note 1.1.3(20): 1075, *note
+1.1.5(8): 1099, *note 1.1.5(12): 1105, *note 1.1.5(12.b): 1106, *note
+3.5(27.c/2): 1725, *note 3.5.5(8): 1875, *note 3.10.2(29): 2471, *note
+3.11(14): 2514, *note 4.6(57/3): 3224, *note 4.8(10.1/3): 3282, *note
+4.8(10.2/2): 3285, *note 4.8(10.3/2): 3288, *note 4.8(10.4/3): 3294,
+*note 6.2(12/3): 3637, *note 6.4(11/2): 3710, *note 6.5(8/3): 3769,
+*note 6.5(21/3): 3775, *note 6.5.1(9/2): 3790, *note 7.6.1(15): 3976,
+*note 7.6.1(16/2): 3977, *note 7.6.1(17): 3978, *note 7.6.1(17.2/1):
+3979, *note 7.6.1(18/2): 3980, *note 7.6.1(20.b): 3981, *note
+8.5.4(8.1/1): 4123, *note 9.4(20): 4315, *note 9.5.1(17): 4346, *note
+9.5.3(7/3): 4414, *note 9.7.1(21): 4558, *note 9.8(20/3): 4614, *note
+10.2(26): 4806, *note 11.1(4): 4876, *note 11.5(8.a): 4998, *note
+11.5(19): 5008, *note 12.5.1(23.3/2): 5201, *note 13.7.1(16): 5570,
+*note 13.9.1(9): 5604, *note 13.11.2(13): 5676, *note 13.11.2(14): 5678,
+*note 13.11.4(27/3): 5720, *note 13.11.4(30/3): 5723, *note
+A.5.2(40.1/1): 6653, *note A.7(14/3): 6772, *note B.3.3(22/2): 8100,
+*note C.3.1(10/3): 8212, *note C.3.1(11/3): 8216, *note C.3.2(17/3):
+8236, *note C.3.2(20): 8237, *note C.3.2(21/3): 8238, *note C.3.2(22/2):
+8239, *note C.7.1(15): 8286, *note C.7.1(17/3): 8290, *note C.7.2(13):
+8300, *note D.3(13): 8424, *note D.3(13.2/2): 8426, *note D.3(13.4/2):
+8427, *note D.5.1(9): 8447, *note D.5.2(6/3): 8452, *note D.7(7.1/3):
+8464, *note D.7(10.4/3): 8477, *note D.7(19.1/2): 8513, *note D.10(10):
+8564, *note D.11(8): 8580, *note E.1(10/2): 8703, *note E.3(6): 8778,
+*note E.4(18/1): 8795, *note J.7.1(7): 9139.
+ in Standard *note A.1(46): 5894.
+prohibited
+ tampering with a holder *note A.18.18(35/3): 7843.
+ tampering with a list *note A.18.3(69.1/3): 7392.
+ tampering with a map *note A.18.4(15.1/3): 7418.
+ tampering with a set *note A.18.7(14.1/3): 7554.
+ tampering with a tree *note A.18.10(90/3): 7800.
+ tampering with a vector *note A.18.2(97.1/3): 7317.
+propagate *note 11.4(1): 4914.
+ an exception by a construct *note 11.4(6.a): 4923.
+ an exception by an execution *note 11.4(6.a): 4922.
+ an exception occurrence by an execution, to a dynamically enclosing
+execution *note 11.4(6): 4921.
+proper_body *note 3.11(6): 2501.
+ used *note 3.11(5): 2499, *note 10.1.3(7): 4743, *note P: 10319.
+protected action *note 9.5.1(4): 4338.
+ complete *note 9.5.1(6): 4341.
+ start *note 9.5.1(5): 4339.
+protected calling convention *note 6.3.1(12): 3662.
+protected declaration *note 9.4(1): 4260.
+protected entry *note 9.4(1): 4259.
+protected function *note 9.5.1(1): 4336.
+protected interface *note 3.9.4(5/2): 2352.
+protected object *note 9(3): 4185, *note 9.4(1): 4256.
+protected operation *note 9.4(1): 4257.
+protected procedure *note 9.5.1(1): 4335.
+protected subprogram *note 9.4(1): 4258, *note 9.5.1(1): 4334.
+protected tagged type *note 3.9.4(6/2): 2362.
+protected type *note N(33/2): 9575.
+protected unit *note 9.4(1): 4261.
+protected_body *note 9.4(7/3): 4286.
+ used *note 3.11(6): 2505, *note P: 9829.
+protected_body_stub *note 10.1.3(6): 4738.
+ used *note 10.1.3(2): 4727, *note P: 10308.
+protected_definition *note 9.4(4): 4275.
+ used *note 9.4(2/3): 4269, *note 9.4(3/3): 4274, *note P: 10198.
+protected_element_declaration *note 9.4(6): 4283.
+ used *note 9.4(4): 4277, *note P: 10200.
+protected_operation_declaration *note 9.4(5/1): 4279.
+ used *note 9.4(4): 4276, *note 9.4(6): 4284, *note P: 10199.
+protected_operation_item *note 9.4(8/1): 4291.
+ used *note 9.4(7/3): 4289, *note P: 10209.
+protected_type_declaration *note 9.4(2/3): 4264.
+ used *note 3.2.1(3/3): 1439, *note P: 9666.
+ptrdiff_t
+ in Interfaces.C *note B.3(12): 8000.
+PU1
+ in Ada.Characters.Latin_1 *note A.3.3(18): 6064.
+PU2
+ in Ada.Characters.Latin_1 *note A.3.3(18): 6065.
+public declaration of a library unit *note 10.1.1(12): 4686.
+public descendant
+ of a library unit *note 10.1.1(12): 4689.
+public library unit *note 10.1.1(12): 4685.
+punctuation_connector *note 2.1(10.2/2): 1177.
+ used *note 2.3(3.1/3): 1245, *note P: 9608.
+pure *note 10.2.1(15.1/3): 4833.
+Pure aspect *note 10.2.1(17/3): 4836.
+Pure pragma *note 10.2.1(14): 4829, *note L(28): 9460.
+Put
+ in Ada.Text_IO *note A.10.1(42): 6932, *note A.10.1(48): 6941,
+*note A.10.1(55): 6954, *note A.10.1(60): 6963, *note A.10.1(66): 6973,
+*note A.10.1(67): 6976, *note A.10.1(71): 6983, *note A.10.1(72): 6986,
+*note A.10.1(76): 6993, *note A.10.1(77): 6996, *note A.10.1(82): 7002,
+*note A.10.1(83): 7005.
+ in Ada.Text_IO.Bounded_IO *note A.10.11(4/2): 7031, *note
+A.10.11(5/2): 7032.
+ in Ada.Text_IO.Complex_IO *note G.1.3(7): 8930, *note G.1.3(8):
+8932.
+ in Ada.Text_IO.Editing *note F.3.3(14): 8856, *note F.3.3(15):
+8857, *note F.3.3(16): 8858.
+ in Ada.Text_IO.Unbounded_IO *note A.10.12(4/2): 7041, *note
+A.10.12(5/2): 7042.
+Put_Line
+ in Ada.Text_IO *note A.10.1(50): 6948.
+ in Ada.Text_IO.Bounded_IO *note A.10.11(6/2): 7033, *note
+A.10.11(7/2): 7034.
+ in Ada.Text_IO.Unbounded_IO *note A.10.12(6/2): 7043, *note
+A.10.12(7/2): 7044.
+
+
+\1f
+File: aarm2012.info, Node: Q, Next: R, Prev: P, Up: Index
+
+Q
+==
+
+
+
+qualified_expression *note 4.7(2): 3236.
+ used *note 4.1(2/3): 2532, *note 4.8(2/3): 3258, *note 13.8(2):
+5578, *note P: 10459.
+quantified expressions *note 4.5.8(5/3): 3122.
+quantified_expression *note 4.5.8(1/3): 3111.
+ used *note 4.4(7/3): 2908, *note P: 9949.
+quantifier *note 4.5.8(2/3): 3118.
+ used *note 4.5.8(1/3): 3112, *note P: 9963.
+Query_Element
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(16/2): 7349.
+ in Ada.Containers.Hashed_Maps *note A.18.5(16/2): 7443.
+ in Ada.Containers.Hashed_Sets *note A.18.8(17/2): 7583.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(14/3): 7832.
+ in Ada.Containers.Multiway_Trees *note A.18.10(26/3): 7751.
+ in Ada.Containers.Ordered_Maps *note A.18.6(15/2): 7497.
+ in Ada.Containers.Ordered_Sets *note A.18.9(16/2): 7657.
+ in Ada.Containers.Vectors *note A.18.2(31/2): 7259, *note
+A.18.2(32/2): 7260.
+Question
+ in Ada.Characters.Latin_1 *note A.3.3(10): 6003.
+Queue
+ in Ada.Containers.Bounded_Priority_Queues *note A.18.31(4/3): 7917.
+ in Ada.Containers.Bounded_Synchronized_Queues *note A.18.29(4/3):
+7902.
+ in Ada.Containers.Synchronized_Queue_Interfaces *note A.18.27(4/3):
+7887.
+ in Ada.Containers.Unbounded_Priority_Queues *note A.18.30(4/3):
+7909.
+ in Ada.Containers.Unbounded_Synchronized_Queues *note A.18.28(4/3):
+7895.
+queuing policy *note D.4(1/3): 8429, *note D.4(6): 8437.
+ FIFO_Queuing *note D.4(7/2): 8438.
+ Priority_Queuing *note D.4(8): 8440.
+Queuing_Policy pragma *note D.4(3): 8431, *note L(29): 9463.
+Quotation
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5983.
+quotation mark *note 2.1(15/3): 1188.
+quoted string
+ See string_literal *note 2.6(1): 1294.
+
+
+\1f
+File: aarm2012.info, Node: R, Next: S, Prev: Q, Up: Index
+
+R
+==
+
+
+
+raise
+ an exception *note 11(1/3): 4866.
+ an exception *note 11.3(4/2): 4909.
+ an exception *note N(18): 9542.
+ an exception occurrence *note 11.4(3): 4920.
+Raise_Exception
+ in Ada.Exceptions *note 11.4.1(4/3): 4936.
+raise_statement *note 11.3(2/2): 4905.
+ used *note 5.1(4/2): 3355, *note P: 10000.
+Random
+ in Ada.Numerics.Discrete_Random *note A.5.2(20): 6637.
+ in Ada.Numerics.Float_Random *note A.5.2(8): 6625.
+random number *note A.5.2(1): 6621.
+range *note 3.5(3): 1668, *note 3.5(4): 1672.
+ of a scalar subtype *note 3.5(7): 1686.
+ used *note 3.5(2): 1667, *note 3.6(6): 2003, *note 3.6.1(3): 2043,
+*note 3.8.1(5/3): 2197, *note 4.4(3.2/3): 2884, *note P: 9929.
+Range attribute *note 3.5(14): 1698, *note 3.6.2(7): 2062.
+Range(N) attribute *note 3.6.2(8): 2064.
+range_attribute_designator *note 4.1.4(5): 2612.
+ used *note 4.1.4(4): 2611, *note P: 9863.
+range_attribute_reference *note 4.1.4(4): 2609.
+ used *note 3.5(3): 1669, *note P: 9711.
+Range_Check *note 11.5(17): 5006.
+ [partial] *note 3.2.2(11): 1484, *note 3.5(24): 1712, *note
+3.5(27): 1717, *note 3.5(39.12/3): 1747, *note 3.5(39.4/3): 1741, *note
+3.5(39.5/3): 1744, *note 3.5(43/3): 1753, *note 3.5(55/3): 1759, *note
+3.5.5(7): 1869, *note 3.5.9(19): 1960, *note 4.2(11): 2662, *note
+4.3.3(28): 2763, *note 4.5.1(8): 2948, *note 4.5.6(6): 3069, *note
+4.5.6(13): 3078, *note 4.6(28): 3174, *note 4.6(38): 3186, *note
+4.6(46): 3199, *note 4.6(51/3): 3205, *note 4.7(4): 3243, *note
+13.13.2(35/3): 5807, *note A.5.2(39): 6650, *note A.5.3(26): 6687, *note
+A.5.3(29): 6692, *note A.5.3(50): 6715, *note A.5.3(53): 6720, *note
+A.5.3(59): 6725, *note A.5.3(62): 6730, *note K.2(11): 9283, *note
+K.2(114): 9298, *note K.2(122): 9301, *note K.2(184): 9308, *note
+K.2(220): 9315, *note K.2(241): 9320, *note K.2(41): 9288, *note
+K.2(47): 9291.
+range_constraint *note 3.5(2): 1666.
+ used *note 3.2.2(6): 1475, *note 3.5.9(5): 1938, *note J.3(2):
+9122, *note P: 9738.
+Ravenscar *note D.13(1/3): 8583.
+RCI
+ generic *note E.2.3(7/3): 8758.
+ library unit *note E.2.3(7/3): 8756.
+ package *note E.2.3(7/3): 8757.
+Re
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(7/2): 9008,
+*note G.3.2(27/2): 9021.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(6): 8871.
+re-raise statement *note 11.3(3): 4908.
+read
+ the value of an object *note 3.3(14): 1530.
+ in Ada.Direct_IO *note A.8.4(12): 6822.
+ in Ada.Sequential_IO *note A.8.1(12): 6794.
+ in Ada.Storage_IO *note A.9(6): 6842.
+ in Ada.Streams *note 13.13.1(5): 5783.
+ in Ada.Streams.Stream_IO *note A.12.1(15): 7083, *note A.12.1(16):
+7084.
+ in System.RPC *note E.5(7): 8812.
+Read aspect *note 13.13.2(38/3): 5821.
+Read attribute *note 13.13.2(6): 5794, *note 13.13.2(14): 5798.
+Read clause *note 13.3(7/2): 5379, *note 13.13.2(38/3): 5816.
+ready
+ a task state *note 9(10): 4192.
+ready queue *note D.2.1(5/2): 8345.
+ready task *note D.2.1(5/2): 8348.
+Real
+ in Interfaces.Fortran *note B.5(6): 8162.
+real literal *note 2.4(1): 1250.
+real literals *note 3.5.6(4): 1885.
+real time *note D.8(18): 8543.
+real type *note 3.2(3): 1401, *note 3.5.6(1): 1879, *note N(34): 9576.
+real-time systems *note C(1): 8180, *note D(1): 8321.
+Real_Arrays
+ child of Ada.Numerics *note G.3.1(31/2): 9000.
+Real_Matrix
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(4/2): 8990.
+real_range_specification *note 3.5.7(3): 1893.
+ used *note 3.5.7(2): 1892, *note 3.5.9(3): 1931, *note 3.5.9(4):
+1935, *note P: 9736.
+Real_Time
+ child of Ada *note D.8(3): 8521.
+real_type_definition *note 3.5.6(2): 1880.
+ used *note 3.2.1(4/2): 1443, *note P: 9669.
+Real_Vector
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(4/2): 8989.
+receiving stub *note E.4(10): 8788.
+reclamation of storage *note 13.11.2(1): 5667.
+recommended level of support *note 13.1(20/3): 5319.
+ Address attribute *note 13.3(15): 5397.
+ Alignment attribute for objects *note 13.3(33): 5411.
+ Alignment attribute for subtypes *note 13.3(29): 5410.
+ aspect Pack *note 13.2(7/3): 5350.
+ bit ordering *note 13.5.3(7): 5526.
+ Component_Size attribute *note 13.3(71): 5442.
+ enumeration_representation_clause *note 13.4(9): 5467.
+ record_representation_clause *note 13.5.1(17): 5499.
+ required in Systems Programming Annex *note C.2(2/3): 8190.
+ Size attribute *note 13.3(42/2): 5418, *note 13.3(54): 5426.
+ Stream_Size attribute *note 13.13.2(1.7/2): 5790.
+ unchecked conversion *note 13.9(16): 5593.
+ with respect to nonstatic expressions *note 13.1(21/3): 5320.
+record *note 3.8(1): 2142.
+ explicitly limited *note 3.8(13.1/3): 2166.
+record extension *note 3.4(5/2): 1615, *note 3.9.1(1/2): 2272, *note
+N(35): 9577.
+Record layout aspect *note 13.5(1): 5474.
+record type *note 3.8(1): 2143, *note N(36): 9578.
+record_aggregate *note 4.3.1(2): 2684.
+ used *note 4.3(2): 2671, *note 13.8(14.b): 5584, *note P: 9868.
+record_component_association *note 4.3.1(4/2): 2689.
+ used *note 4.3.1(3): 2688, *note P: 9873.
+record_component_association_list *note 4.3.1(3): 2686.
+ used *note 4.3.1(2): 2685, *note 4.3.2(2): 2712, *note P: 9871.
+record_definition *note 3.8(3): 2147.
+ used *note 3.8(2): 2146, *note 3.9.1(2): 2277, *note P: 9795.
+record_extension_part *note 3.9.1(2): 2276.
+ used *note 3.4(2/2): 1612, *note P: 9709.
+record_representation_clause *note 13.5.1(2): 5479.
+ used *note 13.1(2/1): 5284, *note P: 10426.
+record_type_definition *note 3.8(2): 2145.
+ used *note 3.2.1(4/2): 1445, *note P: 9671.
+reentrant *note A(3/2): 5875.
+Reference
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(17.4/3): 7353.
+ in Ada.Containers.Hashed_Maps *note A.18.5(17.4/3): 7447, *note
+A.18.5(17.6/3): 7449.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(19/3): 7837.
+ in Ada.Containers.Multiway_Trees *note A.18.10(31/3): 7756.
+ in Ada.Containers.Ordered_Maps *note A.18.6(16.4/3): 7501, *note
+A.18.6(16.6/3): 7503.
+ in Ada.Containers.Vectors *note A.18.2(34.4/3): 7265, *note
+A.18.2(34.6/3): 7267.
+ in Ada.Interrupts *note C.3.2(10): 8233.
+ in Ada.Task_Attributes *note C.7.2(5): 8296.
+reference discriminant *note 4.1.5(3/3): 2624.
+reference object *note 4.1.5(3/3): 2623.
+reference parameter passing *note 6.2(2): 3626.
+reference type *note 4.1.5(3/3): 2622, *note N(36.1/3): 9579.
+Reference_Preserving_Key
+ in Ada.Containers.Hashed_Sets *note A.18.8(58.2/3): 7624, *note
+A.18.8(58.4/3): 7626.
+ in Ada.Containers.Ordered_Sets *note A.18.9(73.2/3): 7708, *note
+A.18.9(73.4/3): 7710.
+Reference_Type
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(17.2/3): 7351.
+ in Ada.Containers.Hashed_Maps *note A.18.5(17.2/3): 7445.
+ in Ada.Containers.Hashed_Sets *note A.18.8(58.1/3): 7623.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(17/3): 7835.
+ in Ada.Containers.Multiway_Trees *note A.18.10(29/3): 7754.
+ in Ada.Containers.Ordered_Maps *note A.18.6(16.2/3): 7499.
+ in Ada.Containers.Ordered_Sets *note A.18.9(73.1/3): 7707.
+ in Ada.Containers.Vectors *note A.18.2(34.2/3): 7263.
+references *note 1.2(1/3): 1108.
+Registered_Trade_Mark_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6094.
+Reinitialize
+ in Ada.Task_Attributes *note C.7.2(6): 8298.
+relation *note 4.4(3/3): 2873.
+ used *note 4.4(2): 2852, *note P: 9898.
+relational operator *note 4.5.2(1): 2951.
+relational_operator *note 4.5(3): 2917.
+ used *note 4.4(2.2/3): 2871, *note 4.4(3/3): 2875, *note P: 9919.
+Relative_Deadline aspect *note D.2.6(9.2/3): 8402.
+Relative_Deadline pragma *note J.15.12(2/3): 9273, *note L(29.2/3):
+9466.
+Relative_Name
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(13/3):
+7201.
+relaxed mode *note G.2(1): 8942.
+release
+ execution resource associated with protected object *note 9.5.1(6):
+4342.
+rem operator *note 4.4(1/3): 2836, *note 4.5.5(1): 3052.
+Remainder attribute *note A.5.3(45): 6708.
+remote access *note E.1(5): 8694.
+remote access type *note E.2.2(9/3): 8737.
+remote access-to-class-wide type *note E.2.2(9/3): 8739.
+remote access-to-subprogram type *note E.2.2(9/3): 8738.
+remote call interface *note E.2(4/3): 8712, *note E.2.3(7/3): 8755.
+remote procedure call
+ asynchronous *note E.4.1(9/3): 8803.
+remote subprogram *note E.2.3(7/3): 8759.
+remote subprogram binding *note E.4(1): 8783.
+remote subprogram call *note E.4(1): 8779.
+remote types library unit *note E.2(4/3): 8711, *note E.2.2(4/3):
+8734.
+Remote_Call_Interface aspect *note E.2.3(7/3): 8761.
+Remote_Call_Interface pragma *note E.2.3(3): 8748, *note L(30): 9468.
+Remote_Types aspect *note E.2.2(4/3): 8736.
+Remote_Types pragma *note E.2.2(3): 8732, *note L(31): 9471.
+Remove_Task
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(8/2): 8625.
+Rename
+ in Ada.Directories *note A.16(12/2): 7145.
+renamed entity *note 8.5(3): 4080.
+renamed view *note 8.5(3): 4079.
+renaming *note N(36.2/2): 9580.
+renaming-as-body *note 8.5.4(1/3): 4109.
+renaming-as-declaration *note 8.5.4(1/3): 4110.
+renaming_declaration *note 8.5(2): 4072.
+ used *note 3.1(3/3): 1354, *note P: 9652.
+rendezvous *note 9.5.2(25): 4396.
+Replace
+ in Ada.Containers.Hashed_Maps *note A.18.5(23/2): 7457.
+ in Ada.Containers.Hashed_Sets *note A.18.8(22/2): 7591, *note
+A.18.8(53/2): 7617.
+ in Ada.Containers.Ordered_Maps *note A.18.6(22/2): 7511.
+ in Ada.Containers.Ordered_Sets *note A.18.9(21/2): 7665, *note
+A.18.9(66/2): 7699.
+Replace_Element
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(15/2): 7348.
+ in Ada.Containers.Hashed_Maps *note A.18.5(15/2): 7442.
+ in Ada.Containers.Hashed_Sets *note A.18.8(16/2): 7582.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(13/3): 7831.
+ in Ada.Containers.Multiway_Trees *note A.18.10(25/3): 7750.
+ in Ada.Containers.Ordered_Maps *note A.18.6(14/2): 7496.
+ in Ada.Containers.Ordered_Sets *note A.18.9(15/2): 7656.
+ in Ada.Containers.Vectors *note A.18.2(29/2): 7257, *note
+A.18.2(30/2): 7258.
+ in Ada.Strings.Bounded *note A.4.4(27): 6319.
+ in Ada.Strings.Unbounded *note A.4.5(21): 6376.
+Replace_Slice
+ in Ada.Strings.Bounded *note A.4.4(58): 6340, *note A.4.4(59):
+6341.
+ in Ada.Strings.Fixed *note A.4.3(23): 6281, *note A.4.3(24): 6282.
+ in Ada.Strings.Unbounded *note A.4.5(53): 6397, *note A.4.5(54):
+6398.
+Replenish
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(9/2): 8629.
+Replicate
+ in Ada.Strings.Bounded *note A.4.4(78): 6356, *note A.4.4(79):
+6357, *note A.4.4(80): 6358.
+representation
+ change of *note 13.6(1/3): 5529.
+representation aspect *note 13.1(8/3): 5298.
+ coding *note 13.4(7): 5463.
+ convention, calling convention *note B.1(1/3): 7949.
+ export *note B.1(1/3): 7951.
+ external_name *note B.1(1/3): 7952.
+ import *note B.1(1/3): 7950.
+ layout *note 13.5(1): 5471.
+ link_name *note B.1(1/3): 7953.
+ record layout *note 13.5(1): 5472.
+ specifiable attributes *note 13.3(5/3): 5366.
+ storage place *note 13.5(1): 5475.
+representation attribute *note 13.3(1/1): 5352.
+representation item *note 13.1(1/1): 5277.
+representation of an object *note 13.1(7/2): 5292.
+representation pragma *note 13.1(1/1): 5278.
+ Asynchronous *note J.15.13(1/3): 9275.
+ Atomic *note J.15.8(9/3): 9245.
+ Atomic_Components *note J.15.8(9/3): 9249.
+ Convention *note J.15.5(1/3): 9191.
+ Discard_Names *note C.5(6): 8247.
+ Export *note J.15.5(1/3): 9189.
+ Import *note J.15.5(1/3): 9187.
+ Independent *note J.15.8(9/3): 9253.
+ Independent_Components *note J.15.8(9/3): 9255.
+ No_Return *note J.15.2(1/3): 9165.
+ Pack *note J.15.3(1/3): 9171.
+ Unchecked_Union *note J.15.6(1/3): 9212.
+ Volatile *note J.15.8(9/3): 9247.
+ Volatile_Components *note J.15.8(9/3): 9251.
+representation-oriented attributes
+ of a fixed point subtype *note A.5.4(1): 6750.
+ of a floating point subtype *note A.5.3(1): 6656.
+representation_clause
+ See aspect_clause *note 13.1(4/1): 5291.
+represented in canonical form *note A.5.3(10): 6670.
+requested decimal precision
+ of a floating point type *note 3.5.7(4): 1896.
+requeue *note 9.5.4(1): 4428.
+requeue target *note 9.5.4(3/3): 4433.
+requeue-with-abort *note 9.5.4(13): 4440.
+requeue_statement *note 9.5.4(2/3): 4431.
+ used *note 5.1(4/2): 3352, *note P: 9997.
+require overriding *note 3.9.3(6/2): 2334.
+requires a completion *note 3.11.1(1/3): 2516, *note 3.11.1(6/3):
+2520.
+ declaration for which aspect Elaborate_Body is True *note
+10.2.1(25/3): 4852.
+ declaration of a partial view *note 7.3(4): 3868.
+ declaration to which a pragma Elaborate_Body applies *note
+10.2.1(25/3): 4851.
+ deferred constant declaration *note 7.4(2/3): 3904.
+ generic_package_declaration *note 7.1(5/2): 3835.
+ generic_subprogram_declaration *note 6.1(20/3): 3566.
+ incomplete_type_declaration *note 3.10.1(3/3): 2431.
+ library_unit_declaration *note 10.2(18.c): 4796.
+ package_declaration *note 7.1(5/2): 3834.
+ protected entry_declaration *note 9.5.2(16): 4380.
+ protected_declaration *note 9.4(11.2/2): 4302.
+ subprogram_declaration *note 6.1(20/3): 3565.
+ task_declaration *note 9.1(9.3/2): 4228.
+requires late initialization *note 3.3.1(8.1/2): 1572.
+requires overriding
+ [partial] *note 6.1.1(16/3): 3598.
+Reraise_Occurrence
+ in Ada.Exceptions *note 11.4.1(4/3): 4938.
+Reserve_Capacity
+ in Ada.Containers.Hashed_Maps *note A.18.5(9/2): 7436.
+ in Ada.Containers.Hashed_Sets *note A.18.8(11/2): 7577.
+ in Ada.Containers.Vectors *note A.18.2(20/2): 7248.
+reserved interrupt *note C.3(2): 8199.
+reserved word *note 2.9(2/3): 1338.
+Reserved_128
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6047.
+Reserved_129
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6048.
+Reserved_132
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6051.
+Reserved_153
+ in Ada.Characters.Latin_1 *note A.3.3(19): 6072.
+Reserved_Check
+ [partial] *note C.3.1(10/3): 8210.
+Reset
+ in Ada.Direct_IO *note A.8.4(8): 6817.
+ in Ada.Numerics.Discrete_Random *note A.5.2(21): 6639, *note
+A.5.2(24): 6642.
+ in Ada.Numerics.Float_Random *note A.5.2(9): 6626, *note A.5.2(12):
+6630.
+ in Ada.Sequential_IO *note A.8.1(8): 6789.
+ in Ada.Streams.Stream_IO *note A.12.1(10): 7076.
+ in Ada.Text_IO *note A.10.1(11): 6874.
+resolution rules *note 1.1.2(26/3): 1020.
+resolve
+ overload resolution *note 8.6(14): 4148.
+restriction *note 13.12(4/2): 5732.
+ used *note 13.12(3): 5730, *note L(32): 9476.
+restriction_parameter_argument *note 13.12(4.1/2): 5736.
+ used *note 13.12(4/2): 5735, *note P: 10463.
+restrictions
+ Immediate_Reclamation *note H.4(10): 9079.
+ Max_Asynchronous_Select_Nesting *note D.7(18/1): 8501.
+ Max_Entry_Queue_Length *note D.7(19.1/2): 8511.
+ Max_Protected_Entries *note D.7(14): 8492.
+ Max_Select_Alternatives *note D.7(12): 8488.
+ Max_Storage_At_Blocking *note D.7(17/1): 8496.
+ Max_Task_Entries *note D.7(13): 8490.
+ Max_Tasks *note D.7(19/1): 8506.
+ No_Abort_Statements *note D.7(5/3): 8458.
+ No_Access_Parameter_Allocators *note H.4(8.3/3): 9077.
+ No_Access_Subprograms *note H.4(17): 9087.
+ No_Allocators *note H.4(7): 9069.
+ No_Anonymous_Allocators *note H.4(8.1/3): 9073.
+ No_Asynchronous_Control *note J.13(3/2): 9153.
+ No_Coextensions *note H.4(8.2/3): 9075.
+ No_Delay *note H.4(21): 9097.
+ No_Dependence *note 13.12.1(6/2): 5762.
+ No_Dispatch *note H.4(19): 9093.
+ No_Dynamic_Attachment *note D.7(10/3): 8469.
+ No_Dynamic_Priorities *note D.7(9/2): 8467.
+ No_Exceptions *note H.4(12): 9081.
+ No_Fixed_Point *note H.4(15): 9085.
+ No_Floating_Point *note H.4(14): 9083.
+ No_Implementation_Aspect_Specifications *note 13.12.1(1.1/3): 5750.
+ No_Implementation_Attributes *note 13.12.1(2/2): 5752.
+ No_Implementation_Identifiers *note 13.12.1(2.1/3): 5754.
+ No_Implementation_Pragmas *note 13.12.1(3/2): 5756.
+ No_Implementation_Units *note 13.12.1(3.1/3): 5758.
+ No_Implicit_Heap_Allocations *note D.7(8): 8465.
+ No_IO *note H.4(20/2): 9095.
+ No_Local_Allocators *note H.4(8/1): 9071.
+ No_Local_Protected_Objects *note D.7(10.1/3): 8471.
+ No_Local_Timing_Events *note D.7(10.2/3): 8473.
+ No_Nested_Finalization *note D.7(4/3): 8456.
+ No_Obsolescent_Features *note 13.12.1(4/3): 5760.
+ No_Protected_Type_Allocators *note D.7(10.3/2): 8475.
+ No_Protected_Types *note H.4(5): 9067.
+ No_Recursion *note H.4(22): 9099.
+ No_Reentrancy *note H.4(23): 9101.
+ No_Relative_Delay *note D.7(10.5/3): 8478.
+ No_Requeue_Statements *note D.7(10.6/3): 8480.
+ No_Select_Statements *note D.7(10.7/3): 8482.
+ No_Specific_Termination_Handlers *note D.7(10.8/3): 8484.
+ No_Specification_of_Aspect *note 13.12.1(6.1/3): 5764.
+ No_Standard_Allocators_After_Elaboration *note D.7(19.2/3): 8514.
+ No_Task_Allocators *note D.7(7): 8462.
+ No_Task_Hierarchy *note D.7(3/3): 8454.
+ No_Task_Termination *note D.7(15.1/2): 8494.
+ No_Terminate_Alternatives *note D.7(6): 8460.
+ No_Unchecked_Access *note H.4(18): 9089.
+ No_Unchecked_Conversion *note J.13(4/2): 9154.
+ No_Unchecked_Deallocation *note J.13(5/2): 9155.
+ No_Use_Of_Attribute *note 13.12.1(6.2/3): 5766.
+ No_Use_Of_Pragma *note 13.12.1(6.3/3): 5768.
+ Simple_Barriers *note D.7(10.9/3): 8486.
+Restrictions pragma *note 13.12(3): 5729, *note L(32): 9474.
+Result attribute *note 6.1.1(29/3): 3606.
+result interval
+ for a component of the result of evaluating a complex function
+*note G.2.6(3): 8981.
+ for the evaluation of a predefined arithmetic operation *note
+G.2.1(8): 8948.
+ for the evaluation of an elementary function *note G.2.4(2): 8975.
+result subtype
+ of a function *note 6.5(3/2): 3753.
+return object
+ extended_return_statement *note 6.5(5.10/3): 3758.
+ simple_return_statement *note 6.5(6/2): 3767.
+return statement *note 6.5(1/2): 3740.
+return_subtype_indication *note 6.5(2.3/2): 3750.
+ used *note 6.5(2.1/3): 3745, *note P: 10098.
+reverse iterator *note 5.5.2(4/3): 3480.
+Reverse_Elements
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(27/2): 7365.
+ in Ada.Containers.Vectors *note A.18.2(54/2): 7289.
+Reverse_Find
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(42/2): 7380.
+ in Ada.Containers.Vectors *note A.18.2(70/2): 7305.
+Reverse_Find_Index
+ in Ada.Containers.Vectors *note A.18.2(69/2): 7304.
+Reverse_Iterate
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(46/2): 7383.
+ in Ada.Containers.Ordered_Maps *note A.18.6(51/2): 7533.
+ in Ada.Containers.Ordered_Sets *note A.18.9(61/2): 7694.
+ in Ada.Containers.Vectors *note A.18.2(74/2): 7308.
+Reverse_Iterate_Children
+ in Ada.Containers.Multiway_Trees *note A.18.10(69/3): 7794.
+Reverse_Solidus
+ in Ada.Characters.Latin_1 *note A.3.3(12): 6006.
+reversible iterable container object *note 5.5.1(11/3): 3462.
+reversible iterable container type *note 5.5.1(11/3): 3460.
+reversible iterator object *note 5.5.1(6/3): 3449.
+reversible iterator type *note 5.5.1(6/3): 3447.
+Reversible_Iterator
+ in Ada.Iterator_Interfaces *note 5.5.1(4/3): 3443.
+Reviewable pragma *note H.3.1(3): 9058, *note L(33): 9478.
+RI
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6060.
+right parenthesis *note 2.1(15/3): 1194.
+Right_Angle_Quotation
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6109.
+Right_Curly_Bracket
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6039.
+Right_Parenthesis
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5990.
+Right_Square_Bracket
+ in Ada.Characters.Latin_1 *note A.3.3(12): 6007.
+Ring_Above
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6097.
+ripple effect *note 10.1.2(1.b/2): 4697.
+root
+ of a tree *note A.18.10(3/3): 7727.
+ in Ada.Containers.Multiway_Trees *note A.18.10(22/3): 7747.
+root library unit *note 10.1.1(10): 4681.
+root node
+ of a tree *note A.18.10(3/3): 7728.
+root type
+ of a class *note 3.4.1(2/2): 1644.
+root_integer *note 3.5.4(14): 1834.
+ [partial] *note 3.4.1(8): 1654.
+root_real *note 3.5.6(3): 1883.
+ [partial] *note 3.4.1(8): 1655.
+Root_Storage_Pool
+ in System.Storage_Pools *note 13.11(6/2): 5623.
+Root_Storage_Pool_With_Subpools
+ in System.Storage_Pools.Subpools *note 13.11.4(4/3): 5695.
+Root_Stream_Type
+ in Ada.Streams *note 13.13.1(3/2): 5778.
+Root_Subpool
+ in System.Storage_Pools.Subpools *note 13.11.4(5/3): 5696.
+rooted at a type *note 3.4.1(2/2): 1645.
+roots the subtree *note A.18.10(3/3): 7725.
+Rosen trick *note 13.9.1(14.e/3): 5609.
+rotate *note B.2(9): 7982.
+Round attribute *note 3.5.10(12): 1984.
+Round_Robin
+ child of Ada.Dispatching *note D.2.5(4/2): 8386.
+Round_Robin_Within_Priorities task dispatching policy *note
+D.2.5(2/2): 8385.
+Rounding attribute *note A.5.3(36): 6699.
+RPC
+ child of System *note E.5(3): 8808.
+RPC-receiver *note E.5(21): 8819.
+RPC_Receiver
+ in System.RPC *note E.5(11): 8816.
+RS
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5979.
+run-time check
+ See language-defined check *note 11.5(2/3): 4983.
+run-time error *note 1.1.2(30): 1036, *note 1.1.5(6): 1096, *note
+11.5(2/3): 4984, *note 11.6(1/3): 5023.
+run-time polymorphism *note 3.9.2(1/2): 2290.
+run-time semantics *note 1.1.2(30): 1035.
+run-time type
+ See tag *note 3.9(3): 2225.
+running a program
+ See program execution *note 10.2(1): 4784.
+running task *note D.2.1(6/2): 8351.
+
+
+\1f
+File: aarm2012.info, Node: S, Next: T, Prev: R, Up: Index
+
+S
+==
+
+
+
+safe range
+ of a floating point type *note 3.5.7(9): 1904.
+ of a floating point type *note 3.5.7(10): 1906.
+safe separate compilation *note 10(3.b): 4638.
+Safe_First attribute *note A.5.3(71): 6744, *note G.2.2(5): 8959.
+Safe_Last attribute *note A.5.3(72): 6746, *note G.2.2(6): 8961.
+safety-critical systems *note H(1/2): 9046.
+same value
+ for a limited type *note 6.2(10.f): 3631.
+satisfies
+ a discriminant constraint *note 3.7.1(11): 2133.
+ a range constraint *note 3.5(4): 1678.
+ a subtype predicate *note 3.2.4(32/3): 1519.
+ an index constraint *note 3.6.1(7): 2049.
+ for an access value *note 3.10(15/2): 2417.
+Saturday
+ in Ada.Calendar.Formatting *note 9.6.1(17/2): 4500.
+Save
+ in Ada.Numerics.Discrete_Random *note A.5.2(24): 6641.
+ in Ada.Numerics.Float_Random *note A.5.2(12): 6629.
+Save_Occurrence
+ in Ada.Exceptions *note 11.4.1(6/2): 4944.
+scalar type *note 3.2(3): 1398, *note 3.5(1): 1662, *note N(37): 9581.
+scalar_constraint *note 3.2.2(6): 1474.
+ used *note 3.2.2(5): 1472, *note P: 9682.
+scale
+ of a decimal fixed point subtype *note 3.5.10(11): 1982, *note
+K.2(216): 9313.
+Scale attribute *note 3.5.10(11): 1981.
+Scaling attribute *note A.5.3(27): 6690.
+SCHAR_MAX
+ in Interfaces.C *note B.3(6): 7989.
+SCHAR_MIN
+ in Interfaces.C *note B.3(6): 7988.
+SCI
+ in Ada.Characters.Latin_1 *note A.3.3(19): 6073.
+scope
+ informal definition *note 3.1(8): 1369.
+ of (a view of) an entity *note 8.2(11): 4007.
+ of a declaration *note 8.2(10): 4003.
+ of a use_clause *note 8.4(6): 4064.
+ of a with_clause *note 10.1.2(5): 4713.
+ of an aspect_specification *note 8.2(10.1/3): 4005.
+ of an attribute_definition_clause *note 8.2(10.1/3): 4004.
+Search_Type
+ in Ada.Directories *note A.16(31/2): 7163.
+Second
+ in Ada.Calendar.Formatting *note 9.6.1(26/2): 4512.
+Second_Duration subtype of Day_Duration
+ in Ada.Calendar.Formatting *note 9.6.1(20/2): 4506.
+Second_Number subtype of Natural
+ in Ada.Calendar.Formatting *note 9.6.1(20/2): 4505.
+Seconds
+ in Ada.Calendar *note 9.6(13): 4468.
+ in Ada.Real_Time *note D.8(14/2): 8538.
+Seconds_Count
+ in Ada.Real_Time *note D.8(15): 8540.
+Seconds_Of
+ in Ada.Calendar.Formatting *note 9.6.1(28/2): 4514.
+Section_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6087.
+secure systems *note H(1/2): 9047.
+select an entry call
+ from an entry queue *note 9.5.3(13): 4420, *note 9.5.3(16): 4421.
+ immediately *note 9.5.3(8): 4417.
+select_alternative *note 9.7.1(4): 4542.
+ used *note 9.7.1(2): 4538, *note P: 10251.
+select_statement *note 9.7(2): 4527.
+ used *note 5.1(5/2): 3364, *note P: 10008.
+selected_component *note 4.1.3(2): 2584.
+ used *note 4.1(2/3): 2527, *note P: 9834.
+selection
+ of an entry caller *note 9.5.2(24): 4395.
+selective_accept *note 9.7.1(2): 4534.
+ used *note 9.7(2): 4528, *note P: 10244.
+selector_name *note 4.1.3(3): 2587.
+ used *note 3.7.1(3): 2123, *note 4.1.3(2): 2586, *note 4.3.1(5):
+2695, *note 6.4(5): 3701, *note 12.3(4): 5090, *note 12.7(3.1/2): 5268,
+*note P: 10362.
+semantic dependence
+ of one compilation unit upon another *note 10.1.1(26/2): 4692.
+semicolon *note 2.1(15/3): 1207.
+ in Ada.Characters.Latin_1 *note A.3.3(10): 5999.
+separate compilation *note 10.1(1): 4641.
+ safe *note 10(3.b): 4639.
+Separate_Interrupt_Clocks_Supported
+ in Ada.Execution_Time *note D.14(9.2/3): 8595.
+separator *note 2.2(3/2): 1226.
+separator_line *note 2.1(12/2): 1180.
+separator_paragraph *note 2.1(12.1/2): 1181.
+separator_space *note 2.1(11/2): 1179.
+sequence of characters
+ of a string_literal *note 2.6(5): 1299.
+sequence_of_statements *note 5.1(2/3): 3335.
+ used *note 5.3(2): 3402, *note 5.4(3): 3410, *note 5.5(2): 3423,
+*note 9.7.1(2): 4539, *note 9.7.1(5): 4548, *note 9.7.1(6): 4551, *note
+9.7.2(3/2): 4565, *note 9.7.3(2): 4573, *note 9.7.4(3): 4580, *note
+9.7.4(5): 4585, *note 11.2(2): 4887, *note 11.2(3): 4894, *note P:
+10025.
+sequential
+ actions *note 9.10(11): 4632, *note C.6(17): 8266.
+sequential access *note A.8(2): 6776.
+sequential file *note A.8(1/2): 6773.
+Sequential_IO
+ child of Ada *note A.8.1(2): 6781.
+service
+ an entry queue *note 9.5.3(13): 4419.
+set
+ execution timer object *note D.14.1(12/2): 8613.
+ group budget object *note D.14.2(15/2): 8641.
+ termination handler *note C.7.3(9/2): 8318.
+ timing event object *note D.15(9/2): 8659.
+ in Ada.Containers.Hashed_Sets *note A.18.8(3/3): 7568.
+ in Ada.Containers.Ordered_Sets *note A.18.9(4/3): 7644.
+ in Ada.Environment_Variables *note A.17(6/2): 7209.
+set container *note A.18.7(1/2): 7544.
+Set_Bounded_String
+ in Ada.Strings.Bounded *note A.4.4(12.1/2): 6309.
+Set_Col
+ in Ada.Text_IO *note A.10.1(35): 6919.
+Set_CPU
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(12/3):
+8680.
+Set_Deadline
+ in Ada.Dispatching.EDF *note D.2.6(9/2): 8398.
+Set_Dependents_Fallback_Handler
+ in Ada.Task_Termination *note C.7.3(5/2): 8308.
+Set_Directory
+ in Ada.Directories *note A.16(6/2): 7139.
+Set_Error
+ in Ada.Text_IO *note A.10.1(15): 6881.
+Set_Exit_Status
+ in Ada.Command_Line *note A.15(9): 7134.
+Set_False
+ in Ada.Synchronous_Task_Control *note D.10(4): 8557.
+Set_Handler
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(10/2): 8633.
+ in Ada.Execution_Time.Timers *note D.14.1(7/2): 8608.
+ in Ada.Real_Time.Timing_Events *note D.15(5/2): 8653.
+Set_Im
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(8/2): 9011,
+*note G.3.2(28/2): 9024.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(7): 8876.
+Set_Index
+ in Ada.Direct_IO *note A.8.4(14): 6826.
+ in Ada.Streams.Stream_IO *note A.12.1(22): 7087.
+Set_Input
+ in Ada.Text_IO *note A.10.1(15): 6879.
+Set_Iterator_Interfaces
+ in Ada.Containers.Hashed_Sets *note A.18.8(6.2/3): 7573.
+ in Ada.Containers.Ordered_Sets *note A.18.9(7.2/3): 7649.
+Set_Length
+ in Ada.Containers.Vectors *note A.18.2(22/2): 7250.
+Set_Line
+ in Ada.Text_IO *note A.10.1(36): 6921.
+Set_Line_Length
+ in Ada.Text_IO *note A.10.1(23): 6898.
+Set_Mode
+ in Ada.Streams.Stream_IO *note A.12.1(24): 7090.
+Set_Output
+ in Ada.Text_IO *note A.10.1(15): 6880.
+Set_Page_Length
+ in Ada.Text_IO *note A.10.1(24): 6899.
+Set_Pool_of_Subpool
+ in System.Storage_Pools.Subpools *note 13.11.4(10/3): 5700.
+Set_Priority
+ in Ada.Dynamic_Priorities *note D.5.1(4): 8444.
+Set_Quantum
+ in Ada.Dispatching.Round_Robin *note D.2.5(4/2): 8388.
+Set_Re
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(8/2): 9010,
+*note G.3.2(28/2): 9023.
+ in Ada.Numerics.Generic_Complex_Types *note G.1.1(7): 8874.
+Set_Specific_Handler
+ in Ada.Task_Termination *note C.7.3(6/2): 8310.
+Set_True
+ in Ada.Synchronous_Task_Control *note D.10(4): 8556.
+Set_Unbounded_String
+ in Ada.Strings.Unbounded *note A.4.5(11.1/2): 6371.
+Set_Value
+ in Ada.Task_Attributes *note C.7.2(6): 8297.
+shared passive library unit *note E.2(4/3): 8710, *note E.2.1(4/3):
+8719.
+shared variable
+ protection of *note 9.10(1/3): 4627.
+Shared_Passive aspect *note E.2.1(4/3): 8721.
+Shared_Passive pragma *note E.2.1(3): 8717, *note L(34): 9480.
+shift *note B.2(9): 7981.
+short
+ in Interfaces.C *note B.3(7): 7992.
+short-circuit control form *note 4.5.1(1): 2931.
+Short_Float *note 3.5.7(16): 1915.
+Short_Integer *note 3.5.4(25): 1854.
+SI
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5964.
+signal
+ as defined between actions *note 9.10(2): 4630.
+ See interrupt *note C.3(1/3): 8191.
+signal (an exception)
+ See raise *note 11(1/3): 4862.
+signal handling
+ example *note 9.7.4(10): 4589.
+signed integer type *note 3.5.4(1): 1808.
+signed_char
+ in Interfaces.C *note B.3(8): 7994.
+signed_integer_type_definition *note 3.5.4(3): 1814.
+ used *note 3.5.4(2): 1812, *note P: 9719.
+Signed_Zeros attribute *note A.5.3(13): 6677.
+simple entry call *note 9.5.3(1): 4401.
+simple name
+ of a file *note A.16(47/2): 7183.
+Simple_Barriers restriction *note D.7(10.9/3): 8487.
+simple_expression *note 4.4(4): 2886.
+ used *note 3.5(3): 1670, *note 3.5.4(3): 1816, *note 3.5.7(3):
+1895, *note 4.4(2.2/3): 2872, *note 4.4(3/3): 2874, *note 13.5.1(5):
+5491, *note 13.5.1(6): 5493, *note P: 9924.
+Simple_Name
+ in Ada.Directories *note A.16(16/2): 7148, *note A.16(38/2): 7168.
+ in Ada.Directories.Hierarchical_File_Names *note A.16.1(10/3):
+7198.
+simple_return_statement *note 6.5(2/2): 3741.
+ used *note 5.1(4/2): 3350, *note P: 9995.
+simple_statement *note 5.1(4/2): 3344.
+ used *note 5.1(3): 3341, *note P: 9987.
+Sin
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(4): 8899.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(5): 6591.
+single
+ class expected type *note 8.6(27/2): 4163.
+single entry *note 9.5.2(20): 4388.
+Single_Precision_Complex_Types
+ in Interfaces.Fortran *note B.5(8): 8165.
+single_protected_declaration *note 9.4(3/3): 4270.
+ used *note 3.3.1(2/3): 1562, *note P: 9702.
+single_task_declaration *note 9.1(3/3): 4205.
+ used *note 3.3.1(2/3): 1561, *note P: 9701.
+Sinh
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(6): 8907.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6606.
+size
+ of an object *note 13.1(7/2): 5293.
+ in Ada.Direct_IO *note A.8.4(15): 6828.
+ in Ada.Directories *note A.16(26/2): 7159, *note A.16(41/2): 7171.
+ in Ada.Streams.Stream_IO *note A.12.1(23): 7089.
+Size (object) aspect *note 13.3(41): 5417.
+Size (subtype) aspect *note 13.3(48): 5424.
+Size attribute *note 13.3(40): 5413, *note 13.3(45): 5420.
+Size clause *note 13.3(7/2): 5371, *note 13.3(41): 5415, *note
+13.3(48): 5422.
+size_t
+ in Interfaces.C *note B.3(13): 8001.
+Skip_Line
+ in Ada.Text_IO *note A.10.1(29): 6907.
+Skip_Page
+ in Ada.Text_IO *note A.10.1(32): 6913.
+slice *note 4.1.2(2): 2573.
+ used *note 4.1(2/3): 2526, *note P: 9833.
+ in Ada.Strings.Bounded *note A.4.4(28): 6320.
+ in Ada.Strings.Unbounded *note A.4.5(22): 6377.
+small
+ of a fixed point type *note 3.5.9(8/2): 1943.
+Small aspect *note 3.5.10(2/1): 1970.
+Small attribute *note 3.5.10(2/1): 1966.
+Small clause *note 3.5.10(2/1): 1968, *note 13.3(7/2): 5374.
+SO
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5963.
+Soft_Hyphen
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6093.
+SOH
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5950.
+solidus *note 2.1(15/3): 1204.
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5997.
+Solve
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(46/2): 9035.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(24/2): 8993.
+Sort
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(49/2): 7386.
+ in Ada.Containers.Vectors *note A.18.2(77/2): 7311.
+SOS
+ in Ada.Characters.Latin_1 *note A.3.3(19): 6071.
+SPA
+ in Ada.Characters.Latin_1 *note A.3.3(18): 6069.
+Space
+ in Ada.Characters.Latin_1 *note A.3.3(8): 5981.
+ in Ada.Strings *note A.4.1(4/2): 6224.
+special file *note A.16(45/2): 7178.
+special graphic character
+ a category of Character *note A.3.2(32): 5944.
+Special_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6427.
+Specialized Needs Annexes *note 1.1.2(7): 1005.
+specifiable
+ of Address for entries *note J.7.1(6): 9137.
+ of Address for stand-alone objects and for program units *note
+13.3(12): 5392.
+ of Alignment for first subtypes *note 13.3(26.4/2): 5404.
+ of Alignment for objects *note 13.3(25/2): 5400.
+ of Bit_Order for record types and record extensions *note
+13.5.3(4): 5521.
+ of Component_Size for array types *note 13.3(70): 5438.
+ of External_Tag for a tagged type *note 13.3(75/3): 5450, *note
+K.2(65): 9294.
+ of Input for a type *note 13.13.2(38/3): 5814.
+ of Machine_Radix for decimal first subtypes *note F.1(1): 8825.
+ of Output for a type *note 13.13.2(38/3): 5815.
+ of Read for a type *note 13.13.2(38/3): 5812.
+ of Size for first subtypes *note 13.3(48): 5421.
+ of Size for stand-alone objects *note 13.3(41): 5414.
+ of Small for fixed point types *note 3.5.10(2/1): 1967.
+ of Storage_Pool for a nonderived access-to-object type *note
+13.11(15): 5637.
+ of Storage_Size for a nonderived access-to-object type *note
+13.11(15): 5636.
+ of Storage_Size for a task first subtype *note J.9(3/3): 9146.
+ of Write for a type *note 13.13.2(38/3): 5813.
+specifiable (of an attribute and for an entity) *note 13.3(5/3): 5364.
+specific handler *note C.7.3(9/2): 8316.
+specific postcondition expression *note 6.1.1(4/3): 3588.
+specific precondition expression *note 6.1.1(2/3): 3580.
+specific type *note 3.4.1(3/2): 1646.
+Specific_Handler
+ in Ada.Task_Termination *note C.7.3(6/2): 8311.
+specified
+ of an aspect of representation of an entity *note 13.1(17): 5309.
+ of an operational aspect of an entity *note 13.1(18.1/1): 5311.
+specified (not!) *note 1.1.3(18): 1072, *note M.2(1.a): 9509.
+specified as independently addressable *note C.6(8.1/3): 8263.
+specified discriminant *note 3.7(18): 2103.
+Splice
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(30/2): 7368,
+*note A.18.3(31/2): 7369, *note A.18.3(32/2): 7370.
+Splice_Children
+ in Ada.Containers.Multiway_Trees *note A.18.10(57/3): 7782, *note
+A.18.10(58/3): 7783.
+Splice_Subtree
+ in Ada.Containers.Multiway_Trees *note A.18.10(55/3): 7780, *note
+A.18.10(56/3): 7781.
+Split
+ in Ada.Calendar *note 9.6(14): 4469.
+ in Ada.Calendar.Formatting *note 9.6.1(29/2): 4515, *note
+9.6.1(32/2): 4518, *note 9.6.1(33/2): 4519, *note 9.6.1(34/2): 4520.
+ in Ada.Execution_Time *note D.14(8/2): 8592.
+ in Ada.Real_Time *note D.8(16): 8541.
+Sqrt
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(3): 8895.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(4): 6586.
+squirrel away *note 8.5.4(8.g): 4122, *note 13.9.1(14.e/3): 5608.
+SS2
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6061.
+SS3
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6062.
+SSA
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6053.
+ST
+ in Ada.Characters.Latin_1 *note A.3.3(19): 6075.
+stand-alone constant *note 3.3.1(23/3): 1590.
+ corresponding to a formal object of mode in *note 12.4(10/2): 5149.
+stand-alone object *note 3.3.1(1/3): 1542.
+ [partial] *note 12.4(10/2): 5150.
+stand-alone variable *note 3.3.1(23/3): 1591.
+Standard *note A.1(4): 5878.
+standard error file *note A.10(6): 6848.
+standard input file *note A.10(5): 6846.
+standard mode *note 1.1.5(11): 1104.
+standard output file *note A.10(5): 6847.
+standard storage pool *note 13.11(17): 5644.
+Standard_Error
+ in Ada.Text_IO *note A.10.1(16): 6884, *note A.10.1(19): 6891.
+Standard_Input
+ in Ada.Text_IO *note A.10.1(16): 6882, *note A.10.1(19): 6889.
+Standard_Output
+ in Ada.Text_IO *note A.10.1(16): 6883, *note A.10.1(19): 6890.
+Start_Search
+ in Ada.Directories *note A.16(32/2): 7164.
+State
+ in Ada.Numerics.Discrete_Random *note A.5.2(23): 6640.
+ in Ada.Numerics.Float_Random *note A.5.2(11): 6628.
+statement *note 5.1(3): 3339.
+ used *note 5.1(2/3): 3336, *note P: 9983.
+statement_identifier *note 5.1(8): 3368.
+ used *note 5.1(7): 3367, *note 5.5(2): 3421, *note 5.6(2): 3493,
+*note P: 10023.
+static *note 3.3.2(1.a/3): 1597, *note 4.9(1): 3304.
+ constant *note 4.9(24): 3310.
+ constraint *note 4.9(27): 3316.
+ delta constraint *note 4.9(29): 3319.
+ digits constraint *note 4.9(29): 3318.
+ discrete_range *note 4.9(25): 3312.
+ discriminant constraint *note 4.9(31): 3321.
+ expression *note 4.9(2): 3306.
+ function *note 4.9(18): 3309.
+ index constraint *note 4.9(30): 3320.
+ range *note 4.9(25): 3311.
+ range constraint *note 4.9(29): 3317.
+ scalar subtype *note 4.9(26/3): 3314.
+ string subtype *note 4.9(26/3): 3315.
+ subtype *note 4.9(26/3): 3313.
+ subtype *note 12.4(9/2): 5147.
+ value *note 4.9(13.a): 3307.
+static semantics *note 1.1.2(28): 1026.
+Static_Predicate aspect *note 3.2.4(1/3): 1503.
+statically
+ constrained *note 4.9(32): 3322.
+ denote *note 4.9(14): 3308.
+statically compatible
+ for a constraint and a scalar subtype *note 4.9.1(4/3): 3331.
+ for a constraint and an access or composite subtype *note
+4.9.1(4/3): 3332.
+ for two subtypes *note 4.9.1(5/3): 3333.
+statically deeper *note 3.10.2(4): 2450, *note 3.10.2(17): 2459.
+statically determined tag *note 3.9.2(1/2): 2287.
+ [partial] *note 3.9.2(15): 2312, *note 3.9.2(19): 2316.
+statically matching
+ effect on subtype-specific aspects *note 13.1(14): 5308.
+ for constraints *note 4.9.1(1/2): 3328.
+ for ranges *note 4.9.1(3): 3330.
+ for subtypes *note 4.9.1(2/3): 3329.
+ required *note 3.9.2(10/2): 2308, *note 3.10.2(27.1/2): 2466, *note
+4.6(24.15/2): 3160, *note 4.6(24.5/2): 3155, *note 6.3.1(16.3/3): 3671,
+*note 6.3.1(17/3): 3674, *note 6.3.1(23): 3680, *note 6.5(5.2/3): 3757,
+*note 7.3(13): 3872, *note 8.5.1(4.2/2): 4091, *note 12.4(8.1/2): 5143,
+*note 12.5.1(14): 5198, *note 12.5.3(6): 5214, *note 12.5.3(7): 5215,
+*note 12.5.4(3): 5219, *note 12.7(7): 5270.
+statically tagged *note 3.9.2(4/2): 2305.
+statically unevaluated *note 4.9(32.1/3): 3323.
+Status_Error
+ in Ada.Direct_IO *note A.8.4(18): 6830.
+ in Ada.Directories *note A.16(43/2): 7173.
+ in Ada.IO_Exceptions *note A.13(4): 7115.
+ in Ada.Sequential_IO *note A.8.1(15): 6797.
+ in Ada.Streams.Stream_IO *note A.12.1(26): 7092.
+ in Ada.Text_IO *note A.10.1(85): 7006.
+storage deallocation
+ unchecked *note 13.11.2(1): 5665.
+storage element *note 13.3(8): 5386.
+storage management
+ user-defined *note 13.11(1): 5619.
+storage node *note E(2): 8688.
+storage place
+ of a component *note 13.5(1): 5477.
+ representation aspect *note 13.5(1): 5476.
+storage place attributes
+ of a component *note 13.5.2(1): 5502.
+storage pool *note 3.10(7/1): 2396, *note N(37.1/3): 9582.
+ default *note 13.11.3(4.1/3): 5688.
+storage pool element *note 13.11(11): 5629.
+storage pool that supports subpools *note 13.11.4(18/3): 5711.
+storage pool type *note 13.11(11): 5627.
+Storage_Array
+ in System.Storage_Elements *note 13.7.1(5): 5563.
+Storage_Check *note 11.5(23): 5012.
+ [partial] *note 11.1(6): 4880, *note 13.3(67): 5433, *note
+13.11(17): 5645, *note D.7(17/1): 8498, *note D.7(18/1): 8503, *note
+D.7(19/1): 8508.
+Storage_Count subtype of Storage_Offset
+ in System.Storage_Elements *note 13.7.1(4): 5561.
+Storage_Element
+ in System.Storage_Elements *note 13.7.1(5): 5562.
+Storage_Elements
+ child of System *note 13.7.1(2/2): 5559.
+Storage_Error
+ raised by failure of run-time check *note 4.8(14): 3296, *note
+8.5.4(8.1/1): 4124, *note 11.1(4): 4877, *note 11.1(6): 4882, *note
+11.5(23): 5013, *note 13.3(67): 5435, *note 13.11(17): 5647, *note
+13.11(18): 5650, *note A.7(14/3): 6771, *note D.7(17/1): 8500, *note
+D.7(18/1): 8505, *note D.7(19.3/3): 8516, *note D.7(19/1): 8510.
+ in Standard *note A.1(46): 5895.
+Storage_IO
+ child of Ada *note A.9(3): 6839.
+Storage_Offset
+ in System.Storage_Elements *note 13.7.1(3): 5560.
+Storage_Pool aspect *note 13.11(15): 5641.
+Storage_Pool attribute *note 13.11(13): 5633.
+Storage_Pool clause *note 13.3(7/2): 5376, *note 13.11(15): 5638.
+storage_pool_indicator *note 13.11.3(3.1/3): 5685.
+ used *note 13.11.3(3/3): 5684, *note L(8.3/3): 9366.
+Storage_Pools
+ child of System *note 13.11(5): 5622.
+Storage_Size
+ in System.Storage_Pools *note 13.11(9): 5626.
+ in System.Storage_Pools.Subpools *note 13.11.4(16/3): 5706.
+Storage_Size (access) aspect *note 13.11(15): 5643.
+Storage_Size (task) aspect *note 13.3(65.2/3): 5432.
+Storage_Size attribute *note 13.3(60/3): 5430, *note 13.11(14): 5635,
+*note J.9(2): 9145.
+Storage_Size clause *note 13.3(7/2): 5377, *note 13.11(15): 5639.
+Storage_Size pragma *note J.15.4(2/3): 9177, *note L(35.1/3): 9483.
+Storage_Unit
+ in System *note 13.7(13): 5544.
+stream *note 13.13(1): 5773, *note N(37.2/3): 9583.
+ in Ada.Streams.Stream_IO *note A.12.1(13): 7082.
+ in Ada.Text_IO.Text_Streams *note A.12.2(4): 7106.
+ in Ada.Wide_Text_IO.Text_Streams *note A.12.3(4): 7109.
+ in Ada.Wide_Wide_Text_IO.Text_Streams *note A.12.4(4/2): 7112.
+stream file *note A.8(1/2): 6775.
+stream type *note 13.13(1): 5774.
+Stream_Access
+ in Ada.Streams.Stream_IO *note A.12.1(4): 7066.
+ in Ada.Text_IO.Text_Streams *note A.12.2(3): 7105.
+ in Ada.Wide_Text_IO.Text_Streams *note A.12.3(3): 7108.
+ in Ada.Wide_Wide_Text_IO.Text_Streams *note A.12.4(3/2): 7111.
+Stream_Element
+ in Ada.Streams *note 13.13.1(4/1): 5779.
+Stream_Element_Array
+ in Ada.Streams *note 13.13.1(4/1): 5782.
+Stream_Element_Count subtype of Stream_Element_Offset
+ in Ada.Streams *note 13.13.1(4/1): 5781.
+Stream_Element_Offset
+ in Ada.Streams *note 13.13.1(4/1): 5780.
+Stream_IO
+ child of Ada.Streams *note A.12.1(3/3): 7065.
+Stream_Size aspect *note 13.13.2(1.5/2): 5789.
+Stream_Size attribute *note 13.13.2(1.2/3): 5787.
+Stream_Size clause *note 13.3(7/2): 5378.
+Streams
+ child of Ada *note 13.13.1(2): 5776.
+strict mode *note G.2(1): 8941.
+strict weak ordering *note A.18(5/3): 7222.
+String
+ in Standard *note A.1(37/3): 5889.
+string type *note 3.6.3(1): 2070.
+String_Access
+ in Ada.Strings.Unbounded *note A.4.5(7): 6366.
+string_element *note 2.6(3): 1297.
+ used *note 2.6(2): 1296, *note P: 9629.
+string_literal *note 2.6(2): 1295.
+ used *note 4.4(7/3): 2902, *note 6.1(9): 3537, *note P: 10060.
+Strings
+ child of Ada *note A.4.1(3): 6223.
+ child of Ada.Strings.UTF_Encoding *note A.4.11(22/3): 6553.
+ child of Interfaces.C *note B.3.1(3): 8052.
+Strlen
+ in Interfaces.C.Strings *note B.3.1(17): 8066.
+structure
+ See record type *note 3.8(1): 2144.
+STS
+ in Ada.Characters.Latin_1 *note A.3.3(18): 6066.
+STX
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5951.
+SUB
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5975.
+Sub_Second
+ in Ada.Calendar.Formatting *note 9.6.1(27/2): 4513.
+subaggregate
+ of an array_aggregate *note 4.3.3(6): 2749.
+subcomponent *note 3.2(6/2): 1406.
+subpool *note 13.11.4(18/3): 5707.
+subpool access type *note 13.11.4(22/3): 5713.
+subpool handle *note 13.11.4(18/3): 5709.
+Subpool_Handle
+ in System.Storage_Pools.Subpools *note 13.11.4(6/3): 5697.
+subpool_specification *note 4.8(2.1/3): 3259.
+ used *note 4.8(2/3): 3255, *note P: 9978.
+Subpools
+ child of System.Storage_Pools *note 13.11.4(3/3): 5694.
+subprogram *note 6(1): 3507, *note N(37.3/2): 9584.
+ abstract *note 3.9.3(3/2): 2333.
+subprogram call *note 6.4(1): 3688.
+subprogram instance *note 12.3(13): 5110.
+subprogram_body *note 6.3(2/3): 3639.
+ used *note 3.11(6): 2502, *note 9.4(8/1): 4293, *note 10.1.1(7):
+4669, *note P: 10212.
+subprogram_body_stub *note 10.1.3(3/3): 4728.
+ used *note 10.1.3(2): 4724, *note P: 10305.
+subprogram_declaration *note 6.1(2/3): 3513.
+ used *note 3.1(3/3): 1349, *note 9.4(5/1): 4280, *note 9.4(8/1):
+4292, *note 10.1.1(5): 4660, *note P: 10202.
+subprogram_default *note 12.6(3/2): 5240.
+ used *note 12.6(2.1/3): 5234, *note 12.6(2.2/3): 5238, *note P:
+10408.
+subprogram_renaming_declaration *note 8.5.4(2/3): 4111.
+ used *note 8.5(2): 4076, *note 10.1.1(6): 4667, *note P: 10292.
+subprogram_specification *note 6.1(4/2): 3517.
+ used *note 3.9.3(1.1/3): 2328, *note 6.1(2/3): 3515, *note
+6.3(2/3): 3641, *note 8.5.4(2/3): 4113, *note 10.1.3(3/3): 4730, *note
+12.1(3/3): 5045, *note 12.6(2.1/3): 5233, *note 12.6(2.2/3): 5237, *note
+P: 10407.
+subsystem *note 10.1(3): 4646, *note N(22): 9557.
+subtree
+ node which roots *note A.18.10(3/3): 7726.
+ of a tree *note A.18.10(3/3): 7724.
+Subtree_Node_Count
+ in Ada.Containers.Multiway_Trees *note A.18.10(18/3): 7743.
+subtype *note 3.2(8/2): 1412, *note N(38/3): 9585.
+ constraint of *note 3.2(8/2): 1416.
+ of a generic formal object *note 12.4(10.c): 5151.
+ type of *note 3.2(8/2): 1414.
+ values belonging to *note 3.2(8/2): 1419.
+subtype (of an object)
+ See actual subtype of an object *note 3.3(23/3): 1534.
+ See actual subtype of an object *note 3.3.1(9/2): 1576.
+subtype conformance *note 6.3.1(17/3): 3672, *note 12.3(11.j/3): 5104.
+ [partial] *note 3.10.2(34/2): 2481, *note 9.5.4(17): 4441.
+ required *note 3.9.2(10/2): 2309, *note 3.10.2(32/3): 2477, *note
+4.6(24.20/3): 3167, *note 8.5.1(4.3/2): 4092, *note 8.5.4(5/3): 4121,
+*note 9.1(9.7/2): 4230, *note 9.1(9.8/2): 4231, *note 9.4(11.6/2): 4304,
+*note 9.4(11.7/2): 4305, *note 9.5.4(5/3): 4435, *note 12.4(8.2/2):
+5144, *note 12.5.4(5/3): 5220.
+subtype conversion
+ bounds of a decimal fixed point type *note 3.5.9(16.a.1/1): 1956.
+ bounds of a fixed point type *note 3.5.9(14.a.1/1): 1951.
+ bounds of a floating point type *note 3.5.7(11.a.1/1): 1910.
+ bounds of signed integer type *note 3.5.4(9.a.1/1): 1827.
+ See type conversion *note 4.6(1/3): 3125.
+ See also implicit subtype conversion *note 4.6(1/3): 3129.
+subtype-specific
+ attribute_definition_clause *note 13.3(7.a): 5385.
+ of a representation item *note 13.1(8/3): 5301.
+ of an aspect *note 13.1(8/3): 5303.
+subtype_declaration *note 3.2.2(2/3): 1461.
+ used *note 3.1(3/3): 1346, *note P: 9644.
+subtype_indication *note 3.2.2(3/2): 1465.
+ used *note 3.2.2(2/3): 1463, *note 3.3.1(2/3): 1550, *note
+3.4(2/2): 1610, *note 3.6(6): 2002, *note 3.6(7/2): 2005, *note
+3.6.1(3): 2042, *note 3.8.1(5/3): 2196, *note 3.10(3): 2379, *note
+4.8(2/3): 3256, *note 5.5.2(2/3): 3470, *note 6.5(2.3/2): 3751, *note
+7.3(3/3): 3864, *note P: 9807.
+subtype_mark *note 3.2.2(4): 1469.
+ used *note 3.2.2(3/2): 1467, *note 3.6(4): 1996, *note 3.7(5/2):
+2091, *note 3.9.4(3/2): 2343, *note 3.10(6/2): 2387, *note 4.3.2(3):
+2715, *note 4.4(3.2/3): 2885, *note 4.6(2): 3132, *note 4.7(2): 3239,
+*note 6.1(13/2): 3545, *note 6.1(15/3): 3555, *note 8.4(4/3): 4062,
+*note 8.5.1(2/3): 4084, *note 12.3(5): 5097, *note 12.4(2/3): 5132,
+*note 12.5.1(3/2): 5194, *note 13.8(14.b): 5583, *note P: 9762.
+subtypes
+ of a profile *note 6.1(25): 3574.
+subunit *note 10.1.3(7): 4741, *note 10.1.3(8/2): 4745.
+ of a program unit *note 10.1.3(8/2): 4746.
+ used *note 10.1.1(3): 4654, *note P: 10282.
+Succ attribute *note 3.5(22): 1708.
+Success
+ in Ada.Command_Line *note A.15(8): 7132.
+successor element
+ of a hashed set *note A.18.8(68/2): 7635.
+ of a set *note A.18.7(6/2): 7551.
+ of an ordered set *note A.18.9(81/3): 7717.
+successor node
+ of a hashed map *note A.18.5(46/2): 7478.
+ of a map *note A.18.4(6/2): 7415.
+ of an ordered map *note A.18.6(58/3): 7539.
+Sunday
+ in Ada.Calendar.Formatting *note 9.6.1(17/2): 4501.
+super
+ See view conversion *note 4.6(5/2): 3144.
+Superscript_One
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6107.
+Superscript_Three
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6100.
+Superscript_Two
+ in Ada.Characters.Latin_1 *note A.3.3(22): 6099.
+support external streaming *note 13.13.2(52/3): 5829.
+Supported
+ in Ada.Execution_Time.Interrupts *note D.14.3(3/3): 8648.
+Suppress pragma *note 11.5(4/2): 4988, *note J.10(3/2): 9148, *note
+L(36): 9486.
+suppressed check *note 11.5(8/2): 4997.
+Suspend_Until_True
+ in Ada.Synchronous_Task_Control *note D.10(4): 8559.
+Suspend_Until_True_And_Set_Deadline
+ in Ada.Synchronous_Task_Control.EDF *note D.10(5.2/3): 8561.
+Suspension_Object
+ in Ada.Synchronous_Task_Control *note D.10(4): 8555.
+Swap
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(28/2): 7366.
+ in Ada.Containers.Multiway_Trees *note A.18.10(37/3): 7762.
+ in Ada.Containers.Vectors *note A.18.2(55/2): 7290, *note
+A.18.2(56/2): 7291.
+Swap_Links
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(29/2): 7367.
+Symmetric_Difference
+ in Ada.Containers.Hashed_Sets *note A.18.8(35/2): 7601, *note
+A.18.8(36/2): 7602.
+ in Ada.Containers.Ordered_Sets *note A.18.9(36/2): 7677, *note
+A.18.9(37/2): 7678.
+SYN
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5971.
+synchronization *note 9(1/3): 4182.
+Synchronization aspect *note 9.5(12/3): 4331.
+synchronization_kind *note 9.5(10/3): 4329.
+synchronized *note N(38.1/2): 9586.
+synchronized interface *note 3.9.4(5/2): 2351.
+synchronized tagged type *note 3.9.4(6/2): 2356.
+Synchronized_Queue_Interfaces
+ child of Ada.Containers *note A.18.27(3/3): 7886.
+Synchronous_Barrier
+ in Ada.Synchronous_Barriers *note D.10.1(5/3): 8569.
+Synchronous_Barriers
+ child of Ada *note D.10.1(3/3): 8567.
+Synchronous_Task_Control
+ child of Ada *note D.10(3/2): 8554.
+syntactic category *note 1.1.4(15): 1086.
+syntax
+ complete listing *note P(1): 9591.
+ cross reference *note P(1): 10471.
+ notation *note 1.1.4(3): 1076.
+ under Syntax heading *note 1.1.2(25): 1013.
+System *note 13.7(3/2): 5530.
+System.Address_To_Access_Conversions *note 13.7.2(2): 5572.
+System.Machine_Code *note 13.8(7): 5580.
+System.Multiprocessors *note D.16(3/3): 8663.
+System.Multiprocessors.Dispatching_Domains *note D.16.1(3/3): 8671.
+System.RPC *note E.5(3): 8808.
+System.Storage_Elements *note 13.7.1(2/2): 5559.
+System.Storage_Pools *note 13.11(5): 5622.
+System.Storage_Pools.Subpools *note 13.11.4(3/3): 5694.
+System_Dispatching_Domain
+ in System.Multiprocessors.Dispatching_Domains *note D.16.1(6/3):
+8674.
+System_Name
+ in System *note 13.7(4): 5532.
+systems programming *note C(1): 8178.
+
+
+\1f
+File: aarm2012.info, Node: T, Next: U, Prev: S, Up: Index
+
+T
+==
+
+
+
+T
+ italicized *note 4.5.1(3.b/2): 2944.
+Tag
+ in Ada.Tags *note 3.9(6/2): 2230.
+Tag attribute *note 3.9(16): 2251, *note 3.9(18): 2253.
+tag indeterminate *note 3.9.2(6/2): 2307.
+tag of an object *note 3.9(3): 2222.
+ class-wide object *note 3.9(22): 2257.
+ object created by an allocator *note 3.9(21): 2256.
+ preserved by type conversion and parameter passing *note 3.9(25):
+2260.
+ returned by a function *note 3.9(23): 2258, *note 3.9(24/2): 2259.
+ stand-alone object, component, or aggregate *note 3.9(20): 2255.
+Tag_Array
+ in Ada.Tags *note 3.9(7.3/2): 2240.
+Tag_Check *note 11.5(18): 5007.
+ [partial] *note 3.9.2(16): 2313, *note 4.6(42): 3193, *note
+4.6(52): 3218, *note 5.2(10): 3388, *note 6.5(8.1/3): 3772.
+Tag_Error
+ in Ada.Tags *note 3.9(8): 2243.
+tagged incomplete view *note 3.10.1(2.1/2): 2430.
+tagged type *note 3.9(2/2): 2216, *note N(39): 9587.
+ protected *note 3.9.4(6/2): 2360.
+ synchronized *note 3.9.4(6/2): 2358.
+ task *note 3.9.4(6/2): 2359.
+Tags
+ child of Ada *note 3.9(6/2): 2229.
+Tail
+ in Ada.Strings.Bounded *note A.4.4(72): 6354, *note A.4.4(73):
+6355.
+ in Ada.Strings.Fixed *note A.4.3(37): 6295, *note A.4.3(38): 6296.
+ in Ada.Strings.Unbounded *note A.4.5(67): 6411, *note A.4.5(68):
+6412.
+tail (of a queue) *note D.2.1(5/2): 8347.
+tamper with cursors
+ of a list *note A.18.3(62/2): 7390.
+ of a map *note A.18.4(8/2): 7416.
+ of a set *note A.18.7(8/2): 7552.
+ of a tree *note A.18.10(81/3): 7798.
+ of a vector *note A.18.2(91/2): 7315.
+tamper with elements
+ of a holder *note A.18.18(30/3): 7842.
+ of a list *note A.18.3(67/2): 7391.
+ of a map *note A.18.4(13/2): 7417.
+ of a set *note A.18.7(13/2): 7553.
+ of a tree *note A.18.10(87/3): 7799.
+ of a vector *note A.18.2(95/2): 7316.
+tampering
+ prohibited for a holder *note A.18.18(35/3): 7844.
+ prohibited for a list *note A.18.3(69.1/3): 7393.
+ prohibited for a map *note A.18.4(15.1/3): 7419.
+ prohibited for a set *note A.18.7(14.1/3): 7555.
+ prohibited for a tree *note A.18.10(90/3): 7801.
+ prohibited for a vector *note A.18.2(97.1/3): 7318.
+Tan
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(4): 8901.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(5): 6595.
+Tanh
+ in Ada.Numerics.Generic_Complex_Elementary_Functions *note
+G.1.2(6): 8909.
+ in Ada.Numerics.Generic_Elementary_Functions *note A.5.1(7): 6608.
+target
+ of an assignment operation *note 5.2(3): 3381.
+ of an assignment_statement *note 5.2(3): 3382.
+target object
+ of a requeue_statement *note 9.5(7): 4326.
+ of the name of an entry or a protected subprogram *note 9.5(2/3):
+4323.
+target statement
+ of a goto_statement *note 5.8(3): 3505.
+target subtype
+ of a type_conversion *note 4.6(3): 3136.
+task *note 9(1/3): 4179.
+ activation *note 9.2(1): 4245.
+ completion *note 9.3(1): 4252.
+ dependence *note 9.3(1): 4251.
+ execution *note 9.2(1): 4243.
+ termination *note 9.3(1): 4253.
+task declaration *note 9.1(1): 4198.
+task dispatching *note D.2.1(4/2): 8341.
+task dispatching point *note D.2.1(4/2): 8343.
+ [partial] *note D.2.3(8/2): 8371, *note D.2.4(9/3): 8380.
+task dispatching policy *note 9(10.a/3): 4196, *note D.2.2(7/2): 8366.
+ [partial] *note D.2.1(5/2): 8349.
+ EDF_Across_Priorities *note D.2.6(7/2): 8393.
+ FIFO_Within_Priorities *note D.2.3(2/2): 8369.
+ Non_Preemptive_FIFO_Within_Priorities *note D.2.4(2/2): 8375.
+ Round_Robin_Within_Priorities *note D.2.5(2/2): 8384.
+task interface *note 3.9.4(5/2): 2353.
+task priority *note D.1(15): 8328.
+task state
+ abnormal *note 9.8(4): 4607.
+ blocked *note 9(10): 4189.
+ callable *note 9.9(2): 4621.
+ held *note D.11(4/2): 8576.
+ inactive *note 9(10): 4187.
+ ready *note 9(10): 4191.
+ terminated *note 9(10): 4193.
+task tagged type *note 3.9.4(6/2): 2361.
+task type *note N(40/2): 9588.
+task unit *note 9(9): 4186.
+Task_Array
+ in Ada.Execution_Time.Group_Budgets *note D.14.2(6/2): 8622.
+Task_Attributes
+ child of Ada *note C.7.2(2): 8293.
+task_body *note 9.1(6/3): 4217.
+ used *note 3.11(6): 2504, *note P: 9828.
+task_body_stub *note 10.1.3(5): 4735.
+ used *note 10.1.3(2): 4726, *note P: 10307.
+task_definition *note 9.1(4): 4210.
+ used *note 9.1(2/3): 4204, *note 9.1(3/3): 4209, *note P: 10179.
+Task_Dispatching_Policy pragma *note D.2.2(3): 8355, *note L(37):
+9489.
+Task_Id
+ in Ada.Task_Identification *note C.7.1(2/2): 8273.
+Task_Identification
+ child of Ada *note C.7.1(2/2): 8272.
+task_item *note 9.1(5/1): 4214.
+ used *note 9.1(4): 4212, *note P: 10181.
+Task_Termination
+ child of Ada *note C.7.3(2/2): 8305.
+task_type_declaration *note 9.1(2/3): 4199.
+ used *note 3.2.1(3/3): 1438, *note P: 9665.
+Tasking_Error
+ raised by failure of run-time check *note 9.2(5): 4249, *note
+9.5.3(21): 4427, *note 11.1(4): 4878, *note 13.11.2(13): 5677, *note
+13.11.2(14): 5679, *note C.7.2(13): 8299, *note D.5.1(8): 8446, *note
+D.11(8): 8579.
+ in Standard *note A.1(46): 5896.
+template *note 12(1): 5036.
+ for a formal package *note 12.7(4): 5269.
+ See generic unit *note 12(1): 5037.
+term *note 4.4(5): 2891.
+ used *note 4.4(4): 2890, *note P: 9934.
+terminal interrupt
+ example *note 9.7.4(10): 4591.
+terminate_alternative *note 9.7.1(7): 4552.
+ used *note 9.7.1(4): 4545, *note P: 10256.
+terminated
+ a task state *note 9(10): 4194.
+Terminated attribute *note 9.9(3): 4624.
+termination
+ abnormal *note 10.2(25.c): 4804.
+ normal *note 10.2(25.c): 4802.
+ of a partition *note 10.2(25.c): 4800.
+ of a partition *note E.1(7): 8696.
+termination handler *note C.7.3(8/3): 8312.
+ fall-back *note C.7.3(9/2): 8315.
+ specific *note C.7.3(9/2): 8317.
+Termination_Handler
+ in Ada.Task_Termination *note C.7.3(4/2): 8307.
+Terminator_Error
+ in Interfaces.C *note B.3(40): 8045.
+tested type
+ of a membership test *note 4.5.2(3/3): 2987.
+text of a program *note 2.2(1): 1221.
+Text_IO
+ child of Ada *note A.10.1(2): 6860.
+Text_Streams
+ child of Ada.Text_IO *note A.12.2(3): 7104.
+ child of Ada.Wide_Text_IO *note A.12.3(3): 7107.
+ child of Ada.Wide_Wide_Text_IO *note A.12.4(3/2): 7110.
+throw (an exception)
+ See raise *note 11(1/3): 4863.
+thunk *note 13.14(19.i): 5867.
+Thursday
+ in Ada.Calendar.Formatting *note 9.6.1(17/2): 4498.
+tick *note 2.1(15/3): 1192.
+ in Ada.Real_Time *note D.8(6): 8531.
+ in System *note 13.7(10): 5541.
+Tilde
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6040.
+Time
+ in Ada.Calendar *note 9.6(10): 4459.
+ in Ada.Real_Time *note D.8(4): 8522.
+time base *note 9.6(6/3): 4456.
+time limit
+ example *note 9.7.4(12): 4594.
+time type *note 9.6(6/3): 4455.
+Time-dependent Reset procedure
+ of the random number generator *note A.5.2(34): 6649.
+time-out
+ example *note 9.7.4(12): 4593.
+ See asynchronous_select *note 9.7.4(12): 4592.
+ See selective_accept *note 9.7.1(1): 4533.
+ See timed_entry_call *note 9.7.2(1/2): 4559.
+Time_Error
+ in Ada.Calendar *note 9.6(18): 4471.
+Time_First
+ in Ada.Real_Time *note D.8(4): 8523.
+Time_Last
+ in Ada.Real_Time *note D.8(4): 8524.
+Time_Of
+ in Ada.Calendar *note 9.6(15): 4470.
+ in Ada.Calendar.Formatting *note 9.6.1(30/2): 4516, *note
+9.6.1(31/2): 4517.
+ in Ada.Execution_Time *note D.14(9/2): 8593.
+ in Ada.Real_Time *note D.8(16): 8542.
+Time_Of_Event
+ in Ada.Real_Time.Timing_Events *note D.15(6/2): 8657.
+Time_Offset
+ in Ada.Calendar.Time_Zones *note 9.6.1(4/2): 4486.
+Time_Remaining
+ in Ada.Execution_Time.Timers *note D.14.1(8/2): 8611.
+Time_Span
+ in Ada.Real_Time *note D.8(5): 8526.
+Time_Span_First
+ in Ada.Real_Time *note D.8(5): 8527.
+Time_Span_Last
+ in Ada.Real_Time *note D.8(5): 8528.
+Time_Span_Unit
+ in Ada.Real_Time *note D.8(5): 8530.
+Time_Span_Zero
+ in Ada.Real_Time *note D.8(5): 8529.
+Time_Unit
+ in Ada.Real_Time *note D.8(4): 8525.
+Time_Zones
+ child of Ada.Calendar *note 9.6.1(2/2): 4485.
+timed_entry_call *note 9.7.2(2): 4560.
+ used *note 9.7(2): 4529, *note P: 10245.
+Timer
+ in Ada.Execution_Time.Timers *note D.14.1(4/2): 8604.
+timer interrupt
+ example *note 9.7.4(12): 4596.
+Timer_Handler
+ in Ada.Execution_Time.Timers *note D.14.1(5/2): 8605.
+Timer_Resource_Error
+ in Ada.Execution_Time.Timers *note D.14.1(9/2): 8612.
+Timers
+ child of Ada.Execution_Time *note D.14.1(3/2): 8603.
+times operator *note 4.4(1/3): 2828, *note 4.5.5(1): 3044.
+timing
+ See delay_statement *note 9.6(1): 4445.
+Timing_Event
+ in Ada.Real_Time.Timing_Events *note D.15(4/2): 8651.
+Timing_Event_Handler
+ in Ada.Real_Time.Timing_Events *note D.15(4/2): 8652.
+Timing_Events
+ child of Ada.Real_Time *note D.15(3/2): 8650.
+To_Ada
+ in Interfaces.C *note B.3(22): 8008, *note B.3(26): 8012, *note
+B.3(28): 8014, *note B.3(32): 8018, *note B.3(37): 8022, *note B.3(39):
+8024, *note B.3(39.10/2): 8034, *note B.3(39.13/2): 8038, *note
+B.3(39.17/2): 8042, *note B.3(39.19/2): 8044, *note B.3(39.4/2): 8028,
+*note B.3(39.8/2): 8032.
+ in Interfaces.COBOL *note B.4(17): 8120, *note B.4(19): 8122.
+ in Interfaces.Fortran *note B.5(13): 8173, *note B.5(14): 8175,
+*note B.5(16): 8177.
+To_Address
+ in System.Address_To_Access_Conversions *note 13.7.2(3/3): 5574.
+ in System.Storage_Elements *note 13.7.1(10/3): 5566.
+To_Basic
+ in Ada.Characters.Handling *note A.3.2(6): 5926, *note A.3.2(7):
+5929.
+To_Binary
+ in Interfaces.COBOL *note B.4(45): 8152, *note B.4(48): 8155.
+To_Bounded_String
+ in Ada.Strings.Bounded *note A.4.4(11): 6307.
+To_C
+ in Interfaces.C *note B.3(21): 8007, *note B.3(25): 8011, *note
+B.3(27): 8013, *note B.3(32): 8017, *note B.3(36): 8021, *note B.3(38):
+8023, *note B.3(39.13/2): 8037, *note B.3(39.16/2): 8041, *note
+B.3(39.18/2): 8043, *note B.3(39.4/2): 8027, *note B.3(39.7/2): 8031,
+*note B.3(39.9/2): 8033.
+To_Character
+ in Ada.Characters.Conversions *note A.3.4(5/2): 6191.
+To_Chars_Ptr
+ in Interfaces.C.Strings *note B.3.1(8): 8057.
+To_COBOL
+ in Interfaces.COBOL *note B.4(17): 8119, *note B.4(18): 8121.
+To_Cursor
+ in Ada.Containers.Vectors *note A.18.2(25/2): 7253.
+To_Decimal
+ in Interfaces.COBOL *note B.4(35): 8143, *note B.4(40): 8147, *note
+B.4(44): 8151, *note B.4(47): 8154.
+To_Display
+ in Interfaces.COBOL *note B.4(36): 8144.
+To_Domain
+ in Ada.Strings.Maps *note A.4.2(24): 6255.
+ in Ada.Strings.Wide_Maps *note A.4.7(24): 6467.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(24/2): 6509.
+To_Duration
+ in Ada.Real_Time *note D.8(13): 8533.
+To_Fortran
+ in Interfaces.Fortran *note B.5(13): 8172, *note B.5(14): 8174,
+*note B.5(15): 8176.
+To_Holder
+ in Ada.Containers.Indefinite_Holders *note A.18.18(9/3): 7827.
+To_Index
+ in Ada.Containers.Vectors *note A.18.2(26/2): 7254.
+To_Integer
+ in System.Storage_Elements *note 13.7.1(10/3): 5567.
+To_ISO_646
+ in Ada.Characters.Handling *note A.3.2(11): 5933, *note A.3.2(12):
+5934.
+To_Long_Binary
+ in Interfaces.COBOL *note B.4(48): 8156.
+To_Lower
+ in Ada.Characters.Handling *note A.3.2(6): 5924, *note A.3.2(7):
+5927.
+ in Ada.Wide_Characters.Handling *note A.3.5(20/3): 6215, *note
+A.3.5(21/3): 6217.
+To_Mapping
+ in Ada.Strings.Maps *note A.4.2(23): 6254.
+ in Ada.Strings.Wide_Maps *note A.4.7(23): 6466.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(23/2): 6508.
+To_Packed
+ in Interfaces.COBOL *note B.4(41): 8148.
+To_Picture
+ in Ada.Text_IO.Editing *note F.3.3(6): 8843.
+To_Pointer
+ in System.Address_To_Access_Conversions *note 13.7.2(3/3): 5573.
+To_Range
+ in Ada.Strings.Maps *note A.4.2(24): 6256.
+ in Ada.Strings.Wide_Maps *note A.4.7(25): 6468.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(25/2): 6510.
+To_Ranges
+ in Ada.Strings.Maps *note A.4.2(10): 6244.
+ in Ada.Strings.Wide_Maps *note A.4.7(10): 6456.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(10/2): 6498.
+To_Sequence
+ in Ada.Strings.Maps *note A.4.2(19): 6250.
+ in Ada.Strings.Wide_Maps *note A.4.7(19): 6462.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(19/2): 6504.
+To_Set
+ in Ada.Containers.Hashed_Sets *note A.18.8(9/2): 7575.
+ in Ada.Containers.Ordered_Sets *note A.18.9(10/2): 7651.
+ in Ada.Strings.Maps *note A.4.2(8): 6242, *note A.4.2(9): 6243,
+*note A.4.2(17): 6248, *note A.4.2(18): 6249.
+ in Ada.Strings.Wide_Maps *note A.4.7(8): 6454, *note A.4.7(9):
+6455, *note A.4.7(17): 6460, *note A.4.7(18): 6461.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(8/2): 6496, *note
+A.4.8(9/2): 6497, *note A.4.8(17/2): 6502, *note A.4.8(18/2): 6503.
+To_String
+ in Ada.Characters.Conversions *note A.3.4(5/2): 6194.
+ in Ada.Strings.Bounded *note A.4.4(12): 6308.
+ in Ada.Strings.Unbounded *note A.4.5(11): 6370.
+To_Time_Span
+ in Ada.Real_Time *note D.8(13): 8534.
+To_Unbounded_String
+ in Ada.Strings.Unbounded *note A.4.5(9): 6368, *note A.4.5(10):
+6369.
+To_Upper
+ in Ada.Characters.Handling *note A.3.2(6): 5925, *note A.3.2(7):
+5928.
+ in Ada.Wide_Characters.Handling *note A.3.5(20/3): 6216, *note
+A.3.5(21/3): 6218.
+To_Vector
+ in Ada.Containers.Vectors *note A.18.2(13/2): 7245, *note
+A.18.2(14/2): 7246.
+To_Wide_Character
+ in Ada.Characters.Conversions *note A.3.4(4/2): 6185, *note
+A.3.4(5/2): 6195.
+To_Wide_String
+ in Ada.Characters.Conversions *note A.3.4(4/2): 6186, *note
+A.3.4(5/2): 6196.
+To_Wide_Wide_Character
+ in Ada.Characters.Conversions *note A.3.4(4/2): 6189.
+To_Wide_Wide_String
+ in Ada.Characters.Conversions *note A.3.4(4/2): 6190.
+token
+ See lexical element *note 2.2(1): 1223.
+Trailing_Nonseparate
+ in Interfaces.COBOL *note B.4(23): 8129.
+Trailing_Separate
+ in Interfaces.COBOL *note B.4(23): 8127.
+transfer of control *note 5.1(14/2): 3371.
+Translate
+ in Ada.Strings.Bounded *note A.4.4(53): 6336, *note A.4.4(54):
+6337, *note A.4.4(55): 6338, *note A.4.4(56): 6339.
+ in Ada.Strings.Fixed *note A.4.3(18): 6277, *note A.4.3(19): 6278,
+*note A.4.3(20): 6279, *note A.4.3(21): 6280.
+ in Ada.Strings.Unbounded *note A.4.5(48): 6393, *note A.4.5(49):
+6394, *note A.4.5(50): 6395, *note A.4.5(51): 6396.
+Translation_Error
+ in Ada.Strings *note A.4.1(5): 6230.
+Transpose
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(34/2): 9033.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(17/2): 8992.
+Tree
+ in Ada.Containers.Multiway_Trees *note A.18.10(8/3): 7734.
+Tree_Iterator_Interfaces
+ in Ada.Containers.Multiway_Trees *note A.18.10(13/3): 7739.
+triggering_alternative *note 9.7.4(3): 4578.
+ used *note 9.7.4(2): 4576, *note P: 10269.
+triggering_statement *note 9.7.4(4/2): 4581.
+ used *note 9.7.4(3): 4579, *note P: 10271.
+Trim
+ in Ada.Strings.Bounded *note A.4.4(67): 6348, *note A.4.4(68):
+6350, *note A.4.4(69): 6351.
+ in Ada.Strings.Fixed *note A.4.3(31): 6289, *note A.4.3(32): 6290,
+*note A.4.3(33): 6291, *note A.4.3(34): 6292.
+ in Ada.Strings.Unbounded *note A.4.5(61): 6405, *note A.4.5(62):
+6406, *note A.4.5(63): 6407, *note A.4.5(64): 6408.
+Trim_End
+ in Ada.Strings *note A.4.1(6): 6235.
+True *note 3.5.3(1): 1805.
+Truncation
+ in Ada.Strings *note A.4.1(6): 6232.
+Truncation attribute *note A.5.3(42): 6706.
+Tuesday
+ in Ada.Calendar.Formatting *note 9.6.1(17/2): 4496.
+two's complement
+ modular types *note 3.5.4(29): 1858.
+type *note 3.2(1): 1386, *note N(41/2): 9589.
+ abstract *note 3.9.3(1.2/2): 2331.
+ needs finalization *note 7.6(9.1/2): 3937.
+ of a subtype *note 3.2(8/2): 1413.
+ synchronized tagged *note 3.9.4(6/2): 2357.
+ See also tag *note 3.9(3): 2226.
+ See also language-defined types
+type conformance *note 6.3.1(15/2): 3666.
+ [partial] *note 3.4(17/2): 1628, *note 8.3(8): 4024, *note
+8.3(26/2): 4047, *note 10.1.4(4/3): 4755.
+ required *note 3.11.1(5): 2519, *note 4.1.4(14/2): 2618, *note
+8.6(26): 4162, *note 9.1(9.2/3): 4227, *note 9.1(9.5/3): 4229, *note
+9.4(11.1/3): 4301, *note 9.4(11.4/3): 4303, *note 9.5.4(3/3): 4434,
+*note 12.4(5/2): 5142.
+type conversion *note 4.6(1/3): 3126.
+ access *note 4.6(24.11/2): 3157, *note 4.6(24.18/2): 3163, *note
+4.6(24.19/2): 3165, *note 4.6(47): 3201.
+ arbitrary order *note 1.1.4(18): 1090.
+ array *note 4.6(24.2/2): 3152, *note 4.6(36): 3182.
+ composite (non-array) *note 4.6(21/3): 3146, *note 4.6(40): 3191.
+ enumeration *note 4.6(21.1/2): 3148, *note 4.6(34): 3180.
+ numeric *note 4.6(24.1/2): 3150, *note 4.6(29): 3177.
+ unchecked *note 13.9(1): 5586.
+ See also qualified_expression *note 4.7(1): 3235.
+type conversion, implicit
+ See implicit subtype conversion *note 4.6(1/3): 3130.
+type extension *note 3.9(2/2): 2217, *note 3.9.1(1/2): 2270.
+type of a discrete_range *note 3.6.1(4): 2044.
+type of a range *note 3.5(4): 1675.
+type parameter
+ See discriminant *note 3.7(1/2): 2077.
+type profile
+ See profile, type conformant *note 6.3.1(15/2): 3668.
+type resolution rules *note 8.6(20/2): 4155.
+ if any type in a specified class of types is expected *note
+8.6(21): 4156.
+ if expected type is specific *note 8.6(22): 4158.
+ if expected type is universal or class-wide *note 8.6(21): 4157.
+type tag
+ See tag *note 3.9(3): 2224.
+type-related
+ aspect *note 13.1(8.1/3): 5307.
+ aspect *note 13.1(8/3): 5302.
+ attribute_definition_clause *note 13.3(7.a): 5384.
+ operational item *note 13.1(8.1/3): 5306.
+ representation item *note 13.1(8/3): 5300.
+type_conversion *note 4.6(2): 3131.
+ used *note 4.1(2/3): 2529, *note P: 9836.
+ See also unchecked type conversion *note 13.9(1): 5588.
+type_declaration *note 3.2.1(2): 1428.
+ used *note 3.1(3/3): 1345, *note P: 9643.
+type_definition *note 3.2.1(4/2): 1440.
+ used *note 3.2.1(3/3): 1436, *note P: 9663.
+Type_Invariant aspect *note 7.3.2(2/3): 3893.
+Type_Invariant'Class aspect *note 7.3.2(3/3): 3895.
+Type_Set
+ in Ada.Text_IO *note A.10.1(7): 6868.
+types
+ of a profile *note 6.1(29): 3575.
+
+
+\1f
+File: aarm2012.info, Node: U, Next: V, Prev: T, Up: Index
+
+U
+==
+
+
+
+UC_A_Acute
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6115.
+UC_A_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6116.
+UC_A_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6118.
+UC_A_Grave
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6114.
+UC_A_Ring
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6119.
+UC_A_Tilde
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6117.
+UC_AE_Diphthong
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6120.
+UC_C_Cedilla
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6121.
+UC_E_Acute
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6123.
+UC_E_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6124.
+UC_E_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6125.
+UC_E_Grave
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6122.
+UC_I_Acute
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6127.
+UC_I_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6128.
+UC_I_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6129.
+UC_I_Grave
+ in Ada.Characters.Latin_1 *note A.3.3(23): 6126.
+UC_Icelandic_Eth
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6130.
+UC_Icelandic_Thorn
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6144.
+UC_N_Tilde
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6131.
+UC_O_Acute
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6133.
+UC_O_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6134.
+UC_O_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6136.
+UC_O_Grave
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6132.
+UC_O_Oblique_Stroke
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6138.
+UC_O_Tilde
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6135.
+UC_U_Acute
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6140.
+UC_U_Circumflex
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6141.
+UC_U_Diaeresis
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6142.
+UC_U_Grave
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6139.
+UC_Y_Acute
+ in Ada.Characters.Latin_1 *note A.3.3(24): 6143.
+UCHAR_MAX
+ in Interfaces.C *note B.3(6): 7990.
+UI *note 1.3(1.c/3): 1159.
+ultimate ancestor
+ of a type *note 3.4.1(10/2): 1659.
+unary adding operator *note 4.5.4(1): 3028.
+unary operator *note 4.5(9): 2926.
+unary_adding_operator *note 4.5(5): 2919.
+ used *note 4.4(4): 2887, *note P: 9931.
+Unbiased_Rounding attribute *note A.5.3(39): 6701.
+Unbounded
+ child of Ada.Strings *note A.4.5(3): 6362.
+ in Ada.Text_IO *note A.10.1(5): 6865.
+Unbounded_IO
+ child of Ada.Text_IO *note A.10.12(3/2): 7040.
+ child of Ada.Wide_Text_IO *note A.11(5/3): 7058.
+ child of Ada.Wide_Wide_Text_IO *note A.11(5/3): 7059.
+Unbounded_Priority_Queues
+ child of Ada.Containers *note A.18.30(2/3): 7908.
+Unbounded_Slice
+ in Ada.Strings.Unbounded *note A.4.5(22.1/2): 6378, *note
+A.4.5(22.2/2): 6379.
+Unbounded_String
+ in Ada.Strings.Unbounded *note A.4.5(4/2): 6363.
+Unbounded_Synchronized_Queues
+ child of Ada.Containers *note A.18.28(2/3): 7894.
+unchecked storage deallocation *note 13.11.2(1): 5664.
+unchecked type conversion *note 13.9(1): 5585.
+unchecked union object *note B.3.3(6/3): 8097.
+unchecked union subtype *note B.3.3(6/3): 8096.
+unchecked union type *note B.3.3(6/3): 8095.
+Unchecked_Access attribute *note 13.10(3): 5615, *note H.4(18): 9092.
+ See also Access attribute *note 3.10.2(24/1): 2465.
+Unchecked_Conversion
+ child of Ada *note 13.9(3/3): 5590.
+Unchecked_Deallocation
+ child of Ada *note 13.11.2(3/3): 5669.
+Unchecked_Union aspect *note B.3.3(3.2/3): 8094.
+Unchecked_Union pragma *note J.15.6(2/3): 9215, *note L(37.2/3): 9492.
+unconstrained *note 3.2(9): 1421.
+ object *note 3.3.1(9/2): 1578.
+ object *note 6.4.1(16): 3728.
+ subtype *note 3.2(9): 1423, *note 3.4(6): 1618, *note 3.5(7): 1685,
+*note 3.5.1(10): 1783, *note 3.5.4(9): 1826, *note 3.5.4(10): 1830,
+*note 3.5.7(11): 1909, *note 3.5.9(13): 1949, *note 3.5.9(16): 1954,
+*note 3.6(15): 2020, *note 3.6(16): 2023, *note 3.7(26): 2109, *note
+3.9(15): 2248.
+ subtype *note 3.10(14/3): 2415.
+ subtype *note K.2(33): 9285.
+unconstrained_array_definition *note 3.6(3): 1991.
+ used *note 3.6(2): 1989, *note P: 9739.
+undefined result *note 11.6(5): 5029.
+underline *note 2.1(15/3): 1212.
+ used *note 2.4.1(3): 1262, *note 2.4.2(4): 1287, *note P: 9615.
+Uniformity Issue (UI) *note 1.3(1.c/3): 1158.
+Uniformity Rapporteur Group (URG) *note 1.3(1.c/3): 1156.
+Uniformly_Distributed subtype of Float
+ in Ada.Numerics.Float_Random *note A.5.2(8): 6624.
+uninitialized allocator *note 4.8(4): 3264.
+uninitialized variables *note 13.9.1(2): 5596.
+ [partial] *note 3.3.1(21/3): 1589, *note 13.3(55.i): 5427.
+union
+ C *note B.3.3(1/3): 8092.
+ in Ada.Containers.Hashed_Sets *note A.18.8(26/2): 7595, *note
+A.18.8(27/2): 7596.
+ in Ada.Containers.Ordered_Sets *note A.18.9(27/2): 7671, *note
+A.18.9(28/2): 7672.
+unit consistency *note E.3(6): 8777.
+unit matrix
+ complex matrix *note G.3.2(148/2): 9044.
+ real matrix *note G.3.1(80/2): 9003.
+unit vector
+ complex vector *note G.3.2(90/2): 9043.
+ real vector *note G.3.1(48/2): 9002.
+Unit_Matrix
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(51/2): 9040.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(29/2): 8999.
+Unit_Vector
+ in Ada.Numerics.Generic_Complex_Arrays *note G.3.2(24/2): 9020.
+ in Ada.Numerics.Generic_Real_Arrays *note G.3.1(14/2): 8991.
+universal type *note 3.4.1(6/2): 1649.
+universal_access
+ [partial] *note 3.4.1(6/2): 1653, *note 4.2(8/2): 2656.
+universal_fixed
+ [partial] *note 3.4.1(6/2): 1652, *note 3.5.6(4): 1886.
+universal_integer
+ [partial] *note 3.4.1(6/2): 1650, *note 3.5.4(14): 1837, *note
+3.5.4(30): 1859, *note 4.2(8/2): 2654.
+universal_real
+ [partial] *note 3.4.1(6/2): 1651, *note 3.5.6(4): 1884, *note
+4.2(8/2): 2655.
+unknown discriminants *note 3.7(26): 2110.
+ [partial] *note 3.7(1.b/2): 2079.
+unknown_discriminant_part *note 3.7(3): 2084.
+ used *note 3.7(2): 2082, *note P: 9756.
+Unknown_Zone_Error
+ in Ada.Calendar.Time_Zones *note 9.6.1(5/2): 4487.
+unmarshalling *note E.4(9): 8785.
+unpolluted *note 13.13.1(2): 5777.
+unsigned
+ in Interfaces.C *note B.3(9): 7995.
+ in Interfaces.COBOL *note B.4(23): 8125.
+unsigned type
+ See modular type *note 3.5.4(1): 1810.
+unsigned_char
+ in Interfaces.C *note B.3(10): 7998.
+unsigned_long
+ in Interfaces.C *note B.3(9): 7997.
+unsigned_short
+ in Interfaces.C *note B.3(9): 7996.
+unspecified *note 1.1.3(18): 1071, *note M.2(1.a): 9508.
+ [partial] *note 2.1(5/3): 1167, *note 3.9(4/2): 2228, *note
+3.9(12.5/3): 2245, *note 4.5.2(13): 2989, *note 4.5.2(24.2/1): 2992,
+*note 4.5.5(21): 3054, *note 6.1.1(34/3): 3614, *note 6.1.1(35/3): 3619,
+*note 6.2(11/3): 3632, *note 7.2(5/3): 3849, *note 7.6(17.4/3): 3948,
+*note 9.8(14): 4611, *note 9.10(1/3): 4629, *note 10.2(26): 4807, *note
+11.1(6): 4883, *note 11.4.1(10.1/3): 4948, *note 11.5(27/2): 5016, *note
+13.1(18): 5310, *note 13.7.2(5/2): 5575, *note 13.9.1(7): 5600, *note
+13.11(20): 5651, *note 13.11(21.6/3): 5653, *note 13.13.2(36/2): 5810,
+*note A.1(1/3): 5876, *note A.5.1(34): 6619, *note A.5.2(28): 6647,
+*note A.5.2(34): 6648, *note A.5.3(41.3/2): 6704, *note A.7(6): 6769,
+*note A.10(8): 6852, *note A.10.7(8/3): 7021, *note A.10.7(12/3): 7022,
+*note A.10.7(17.3/2): 7023, *note A.10.7(19): 7024, *note A.14(1): 7126,
+*note A.18(5.v/2): 7223, *note A.18.2(231/3): 7320, *note A.18.2(252/2):
+7328, *note A.18.2(83/2): 7313, *note A.18.3(145/3): 7395, *note
+A.18.3(157/2): 7401, *note A.18.3(55/2): 7388, *note A.18.4(3/2): 7409,
+*note A.18.4(80/2): 7425, *note A.18.5(43/2): 7473, *note A.18.5(44/2):
+7474, *note A.18.5(45/2): 7475, *note A.18.5(46/2): 7479, *note
+A.18.6(56/3): 7535, *note A.18.6(57/2): 7536, *note A.18.7(3/2): 7546,
+*note A.18.7(101/2): 7564, *note A.18.7(87/2): 7557, *note A.18.7(88/2):
+7558, *note A.18.8(65/2): 7629, *note A.18.8(66.1/3): 7631, *note
+A.18.8(66/2): 7630, *note A.18.8(67/2): 7632, *note A.18.8(68/2): 7636,
+*note A.18.8(86/2): 7637, *note A.18.8(87/2): 7638, *note A.18.9(114/2):
+7719, *note A.18.9(79.1/3): 7713, *note A.18.9(79/3): 7712, *note
+A.18.9(80/2): 7714, *note A.18.10(227/3): 7807, *note A.18.10(72/3):
+7796, *note A.18.26(5/3): 7879, *note A.18.26(9.4/3): 7883, *note
+A.18.26(9/3): 7881, *note B.3(46.a.1/1): 8046, *note D.2.2(7.1/2): 8367,
+*note D.8(19): 8545, *note E.3(5/1): 8775, *note G.1.1(40): 8891, *note
+G.1.2(33): 8919, *note G.1.2(48): 8921, *note H(4.1): 9048, *note
+H.2(1): 9056, *note K.2(136.4/2): 9303.
+Unsuppress pragma *note 11.5(4.1/2): 4991, *note L(37.3/2): 9495.
+update
+ the value of an object *note 3.3(14): 1531.
+ in Interfaces.C.Strings *note B.3.1(18): 8067, *note B.3.1(19):
+8068.
+Update_Element
+ in Ada.Containers.Doubly_Linked_Lists *note A.18.3(17/2): 7350.
+ in Ada.Containers.Hashed_Maps *note A.18.5(17/2): 7444.
+ in Ada.Containers.Indefinite_Holders *note A.18.18(15/3): 7833.
+ in Ada.Containers.Multiway_Trees *note A.18.10(27/3): 7752.
+ in Ada.Containers.Ordered_Maps *note A.18.6(16/2): 7498.
+ in Ada.Containers.Vectors *note A.18.2(33/2): 7261, *note
+A.18.2(34/2): 7262.
+Update_Element_Preserving_Key
+ in Ada.Containers.Hashed_Sets *note A.18.8(58/2): 7622.
+ in Ada.Containers.Ordered_Sets *note A.18.9(73/2): 7706.
+Update_Error
+ in Interfaces.C.Strings *note B.3.1(20): 8069.
+upper bound
+ of a range *note 3.5(4): 1674.
+upper-case letter
+ a category of Character *note A.3.2(26): 5939.
+Upper_Case_Map
+ in Ada.Strings.Maps.Constants *note A.4.6(5): 6430.
+Upper_Set
+ in Ada.Strings.Maps.Constants *note A.4.6(4): 6422.
+URG *note 1.3(1.c/3): 1157.
+US
+ in Ada.Characters.Latin_1 *note A.3.3(6): 5980.
+usage name *note 3.1(10): 1374.
+use-visible *note 8.3(4): 4017, *note 8.4(9): 4067.
+use_clause *note 8.4(2): 4055.
+ used *note 3.11(4/1): 2497, *note 10.1.2(3): 4702, *note 12.1(5):
+5052, *note P: 9823.
+Use_Error
+ in Ada.Direct_IO *note A.8.4(18): 6833.
+ in Ada.Directories *note A.16(43/2): 7175.
+ in Ada.IO_Exceptions *note A.13(4): 7118.
+ in Ada.Sequential_IO *note A.8.1(15): 6800.
+ in Ada.Streams.Stream_IO *note A.12.1(26): 7095.
+ in Ada.Text_IO *note A.10.1(85): 7009.
+use_package_clause *note 8.4(3): 4058.
+ used *note 8.4(2): 4056, *note P: 10132.
+use_type_clause *note 8.4(4/3): 4061.
+ used *note 8.4(2): 4057, *note P: 10133.
+user-defined assignment *note 7.6(1): 3918.
+user-defined heap management *note 13.11(1): 5620.
+user-defined operator *note 6.6(1): 3794.
+user-defined storage management *note 13.11(1): 5618.
+UTC_Time_Offset
+ in Ada.Calendar.Time_Zones *note 9.6.1(6/2): 4488.
+UTF-16 *note A.4.11(46/3): 6577.
+UTF-8 *note A.4.11(46/3): 6576.
+UTF_16_Wide_String subtype of Wide_String
+ in Ada.Strings.UTF_Encoding *note A.4.11(7/3): 6540.
+UTF_8_String subtype of String
+ in Ada.Strings.UTF_Encoding *note A.4.11(6/3): 6539.
+UTF_Encoding
+ child of Ada.Strings *note A.4.11(3/3): 6536.
+UTF_String subtype of String
+ in Ada.Strings.UTF_Encoding *note A.4.11(5/3): 6538.
+
+
+\1f
+File: aarm2012.info, Node: V, Next: W, Prev: U, Up: Index
+
+V
+==
+
+
+
+Val attribute *note 3.5.5(5): 1866.
+Valid
+ in Ada.Text_IO.Editing *note F.3.3(5): 8842, *note F.3.3(12): 8854.
+ in Interfaces.COBOL *note B.4(33): 8141, *note B.4(38): 8145, *note
+B.4(43): 8149.
+Valid attribute *note 13.9.2(3/3): 5611, *note H(6): 9050.
+value *note 3.2(10.a): 1426.
+ in Ada.Calendar.Formatting *note 9.6.1(36/2): 4522, *note
+9.6.1(38/2): 4524.
+ in Ada.Environment_Variables *note A.17(4.1/3): 7207, *note
+A.17(4/2): 7206.
+ in Ada.Numerics.Discrete_Random *note A.5.2(26): 6645.
+ in Ada.Numerics.Float_Random *note A.5.2(14): 6633.
+ in Ada.Strings.Maps *note A.4.2(21): 6252.
+ in Ada.Strings.Wide_Maps *note A.4.7(21): 6464.
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(21/2): 6506.
+ in Ada.Task_Attributes *note C.7.2(4): 8295.
+ in Interfaces.C.Pointers *note B.3.2(6): 8078, *note B.3.2(7):
+8079.
+ in Interfaces.C.Strings *note B.3.1(13): 8062, *note B.3.1(14):
+8063, *note B.3.1(15): 8064, *note B.3.1(16): 8065.
+Value attribute *note 3.5(52): 1756.
+value conversion *note 4.6(5/2): 3142.
+values
+ belonging to a subtype *note 3.2(8/2): 1418.
+variable *note 3.3(13/3): 1524.
+variable indexing *note 4.1.6(16/3): 2646.
+variable object *note 3.3(13/3): 1526.
+variable view *note 3.3(13/3): 1528.
+Variable_Indexing aspect *note 4.1.6(3/3): 2636.
+variant *note 3.8.1(3): 2188.
+ used *note 3.8.1(2): 2187, *note P: 9787.
+ See also tagged type *note 3.9(1): 2212.
+variant_part *note 3.8.1(2): 2184.
+ used *note 3.8(4): 2153, *note P: 9778.
+Vector
+ in Ada.Containers.Vectors *note A.18.2(8/3): 7239.
+vector container *note A.18.2(1/2): 7231.
+Vector_Iterator_Interfaces
+ in Ada.Containers.Vectors *note A.18.2(11.2/3): 7244.
+Vectors
+ child of Ada.Containers *note A.18.2(6/3): 7236.
+version
+ of a compilation unit *note E.3(5/1): 8774.
+Version attribute *note E.3(3): 8771.
+vertical line *note 2.1(15/3): 1213.
+Vertical_Line
+ in Ada.Characters.Latin_1 *note A.3.3(14): 6038.
+view *note 3.1(7): 1364, *note N(42/2): 9590.
+ of a subtype (implied) *note 3.1(7.1/3): 1368.
+ of a type (implied) *note 3.1(7.1/3): 1367.
+ of an object (implied) *note 3.1(7.1/3): 1366.
+view conversion *note 4.6(5/2): 3140.
+virtual function
+ See dispatching subprogram *note 3.9.2(1/2): 2296.
+Virtual_Length
+ in Interfaces.C.Pointers *note B.3.2(13): 8083.
+visibility
+ direct *note 8.3(2): 4010, *note 8.3(21): 4037.
+ immediate *note 8.3(4): 4014, *note 8.3(21): 4038.
+ use clause *note 8.3(4): 4015, *note 8.4(9): 4068.
+visibility rules *note 8.3(1): 4009.
+visible *note 8.3(2): 4013, *note 8.3(14): 4029.
+ aspect_specification *note 8.3(23.1/3): 4043.
+ attribute_definition_clause *note 8.3(23.1/3): 4042.
+ within a pragma in a context_clause *note 10.1.6(3): 4776.
+ within a pragma that appears at the place of a compilation unit
+*note 10.1.6(5): 4780.
+ within a use_clause in a context_clause *note 10.1.6(3): 4774.
+ within a with_clause *note 10.1.6(2/2): 4772.
+ within the parent_unit_name of a library unit *note 10.1.6(2/2):
+4770.
+ within the parent_unit_name of a subunit *note 10.1.6(4): 4778.
+visible part *note 8.2(5): 3998.
+ of a formal package *note 12.7(10/2): 5271.
+ of a generic unit *note 8.2(8): 4002.
+ of a package (other than a generic formal package) *note 7.1(6/2):
+3836.
+ of a protected unit *note 9.4(11/2): 4296.
+ of a task unit *note 9.1(9): 4223.
+ of a view of a callable entity *note 8.2(6): 4000.
+ of a view of a composite type *note 8.2(7): 4001.
+ of an instance *note 12.3(12.b): 5107.
+volatile *note C.6(8/3): 8262.
+Volatile aspect *note C.6(6.4/3): 8254.
+Volatile pragma *note J.15.8(3/3): 9231, *note L(38.1/3): 9498.
+Volatile_Components aspect *note C.6(6.7/3): 8258.
+Volatile_Components pragma *note J.15.8(6/3): 9240, *note L(39.1/3):
+9501.
+VT
+ in Ada.Characters.Latin_1 *note A.3.3(5): 5960.
+VTS
+ in Ada.Characters.Latin_1 *note A.3.3(17): 6057.
+
+
+\1f
+File: aarm2012.info, Node: W, Next: X, Prev: V, Up: Index
+
+W
+==
+
+
+
+Wait_For_Release
+ in Ada.Synchronous_Barriers *note D.10.1(6/3): 8570.
+wchar_array
+ in Interfaces.C *note B.3(33/3): 8019.
+wchar_t
+ in Interfaces.C *note B.3(30/1): 8015.
+Wednesday
+ in Ada.Calendar.Formatting *note 9.6.1(17/2): 4497.
+well-formed picture String
+ for edited output *note F.3.1(1/3): 8838.
+Wide_Bounded
+ child of Ada.Strings *note A.4.7(1/3): 6434.
+Wide_Character *note 3.5.2(3/3): 1792.
+ in Standard *note A.1(36.1/3): 5885.
+Wide_Character_Mapping
+ in Ada.Strings.Wide_Maps *note A.4.7(20/2): 6463.
+Wide_Character_Mapping_Function
+ in Ada.Strings.Wide_Maps *note A.4.7(26): 6469.
+Wide_Character_Range
+ in Ada.Strings.Wide_Maps *note A.4.7(6): 6452.
+Wide_Character_Ranges
+ in Ada.Strings.Wide_Maps *note A.4.7(7): 6453.
+Wide_Character_Sequence subtype of Wide_String
+ in Ada.Strings.Wide_Maps *note A.4.7(16): 6459.
+Wide_Character_Set
+ in Ada.Strings.Wide_Maps *note A.4.7(4/2): 6450.
+ in Ada.Strings.Wide_Maps.Wide_Constants *note A.4.8(48/2): 6514.
+Wide_Characters
+ child of Ada *note A.3.1(4/2): 5904.
+Wide_Constants
+ child of Ada.Strings.Wide_Maps *note A.4.7(1/3): 6448, *note
+A.4.8(28/2): 6512.
+Wide_Equal_Case_Insensitive
+ child of Ada.Strings *note A.4.7(1/3): 6440.
+ child of Ada.Strings.Wide_Bounded *note A.4.7(1/3): 6442.
+ child of Ada.Strings.Wide_Fixed *note A.4.7(1/3): 6441.
+ child of Ada.Strings.Wide_Unbounded *note A.4.7(1/3): 6443.
+Wide_Exception_Name
+ in Ada.Exceptions *note 11.4.1(2/2): 4931, *note 11.4.1(5/2): 4941.
+Wide_Expanded_Name
+ in Ada.Tags *note 3.9(7/2): 2233.
+Wide_Fixed
+ child of Ada.Strings *note A.4.7(1/3): 6433.
+Wide_Hash
+ child of Ada.Strings *note A.4.7(1/3): 6436.
+ child of Ada.Strings.Wide_Bounded *note A.4.7(1/3): 6438.
+ child of Ada.Strings.Wide_Fixed *note A.4.7(1/3): 6437.
+ child of Ada.Strings.Wide_Unbounded *note A.4.7(1/3): 6439.
+Wide_Hash_Case_Insensitive
+ child of Ada.Strings *note A.4.7(1/3): 6444.
+ child of Ada.Strings.Wide_Bounded *note A.4.7(1/3): 6446.
+ child of Ada.Strings.Wide_Fixed *note A.4.7(1/3): 6445.
+ child of Ada.Strings.Wide_Unbounded *note A.4.7(1/3): 6447.
+Wide_Image attribute *note 3.5(28): 1727.
+Wide_Maps
+ child of Ada.Strings *note A.4.7(3): 6449.
+wide_nul
+ in Interfaces.C *note B.3(31/1): 8016.
+Wide_Space
+ in Ada.Strings *note A.4.1(4/2): 6225.
+Wide_String
+ in Standard *note A.1(41/3): 5890.
+Wide_Strings
+ child of Ada.Strings.UTF_Encoding *note A.4.11(30/3): 6560.
+Wide_Text_IO
+ child of Ada *note A.11(2/2): 7050.
+Wide_Unbounded
+ child of Ada.Strings *note A.4.7(1/3): 6435.
+Wide_Value attribute *note 3.5(40): 1750.
+Wide_Wide_Bounded
+ child of Ada.Strings *note A.4.8(1/3): 6476.
+Wide_Wide_Character *note 3.5.2(4/3): 1795.
+ in Standard *note A.1(36.2/3): 5886.
+Wide_Wide_Character_Mapping
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(20/2): 6505.
+Wide_Wide_Character_Mapping_Function
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(26/2): 6511.
+Wide_Wide_Character_Range
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(6/2): 6494.
+Wide_Wide_Character_Ranges
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(7/2): 6495.
+Wide_Wide_Character_Sequence subtype of Wide_Wide_String
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(16/2): 6501.
+Wide_Wide_Character_Set
+ in Ada.Strings.Wide_Wide_Maps *note A.4.8(4/2): 6492.
+Wide_Wide_Characters
+ child of Ada *note A.3.1(6/2): 5905.
+Wide_Wide_Constants
+ child of Ada.Strings.Wide_Wide_Maps *note A.4.8(1/3): 6490.
+Wide_Wide_Equal_Case_Insensitive
+ child of Ada.Strings *note A.4.8(1/3): 6482.
+ child of Ada.Strings.Wide_Wide_Bounded *note A.4.8(1/3): 6484.
+ child of Ada.Strings.Wide_Wide_Fixed *note A.4.8(1/3): 6483.
+ child of Ada.Strings.Wide_Wide_Unbounded *note A.4.8(1/3): 6485.
+Wide_Wide_Exception_Name
+ in Ada.Exceptions *note 11.4.1(2/2): 4932, *note 11.4.1(5/2): 4942.
+Wide_Wide_Expanded_Name
+ in Ada.Tags *note 3.9(7/2): 2234.
+Wide_Wide_Fixed
+ child of Ada.Strings *note A.4.8(1/3): 6475.
+Wide_Wide_Hash
+ child of Ada.Strings *note A.4.8(1/3): 6478.
+ child of Ada.Strings.Wide_Wide_Bounded *note A.4.8(1/3): 6480.
+ child of Ada.Strings.Wide_Wide_Fixed *note A.4.8(1/3): 6479.
+ child of Ada.Strings.Wide_Wide_Unbounded *note A.4.8(1/3): 6481.
+Wide_Wide_Hash_Case_Insensitive
+ child of Ada.Strings *note A.4.8(1/3): 6486.
+ child of Ada.Strings.Wide_Wide_Bounded *note A.4.8(1/3): 6488.
+ child of Ada.Strings.Wide_Wide_Fixed *note A.4.8(1/3): 6487.
+ child of Ada.Strings.Wide_Wide_Unbounded *note A.4.8(1/3): 6489.
+Wide_Wide_Image attribute *note 3.5(27.1/2): 1722.
+Wide_Wide_Maps
+ child of Ada.Strings *note A.4.8(3/2): 6491.
+Wide_Wide_Space
+ in Ada.Strings *note A.4.1(4/2): 6226.
+Wide_Wide_String
+ in Standard *note A.1(42.1/3): 5891.
+Wide_Wide_Strings
+ child of Ada.Strings.UTF_Encoding *note A.4.11(38/3): 6567.
+Wide_Wide_Text_IO
+ child of Ada *note A.11(3/2): 7053.
+Wide_Wide_Unbounded
+ child of Ada.Strings *note A.4.8(1/3): 6477.
+Wide_Wide_Value attribute *note 3.5(39.1/2): 1738.
+Wide_Wide_Width attribute *note 3.5(37.1/2): 1732.
+Wide_Width attribute *note 3.5(38): 1734.
+Width attribute *note 3.5(39): 1736.
+with_clause *note 10.1.2(4/2): 4703.
+ mentioned in *note 10.1.2(6/2): 4715.
+ named in *note 10.1.2(6/2): 4717.
+ used *note 10.1.2(3): 4701, *note P: 10297.
+within
+ immediately *note 8.1(13): 3991.
+word *note 13.3(8): 5388.
+Word_Size
+ in System *note 13.7(13): 5545.
+wording changes from Ada 2005 *note 1.1.2(39.jj/3): 1063.
+wording changes from Ada 83 *note 1.1.2(39.j/2): 1052.
+wording changes from Ada 95 *note 1.1.2(39.w/2): 1058.
+Write
+ in Ada.Direct_IO *note A.8.4(13): 6825.
+ in Ada.Sequential_IO *note A.8.1(12): 6795.
+ in Ada.Storage_IO *note A.9(7): 6843.
+ in Ada.Streams *note 13.13.1(6): 5784.
+ in Ada.Streams.Stream_IO *note A.12.1(18): 7085, *note A.12.1(19):
+7086.
+ in System.RPC *note E.5(8): 8813.
+Write aspect *note 13.13.2(38/3): 5823.
+Write attribute *note 13.13.2(3): 5792, *note 13.13.2(11): 5796.
+Write clause *note 13.3(7/2): 5380, *note 13.13.2(38/3): 5817.
+
+
+\1f
+File: aarm2012.info, Node: X, Next: Y, Prev: W, Up: Index
+
+X
+==
+
+
+
+xor operator *note 4.4(1/3): 2779, *note 4.5.1(2): 2941.
+
+
+\1f
+File: aarm2012.info, Node: Y, Prev: X, Up: Index
+
+Y
+==
+
+
+
+Year
+ in Ada.Calendar *note 9.6(13): 4465.
+ in Ada.Calendar.Formatting *note 9.6.1(21/2): 4507.
+Year_Number subtype of Integer
+ in Ada.Calendar *note 9.6(11/2): 4460.
+Yen_Sign
+ in Ada.Characters.Latin_1 *note A.3.3(21/3): 6085.
+Yield
+ in Ada.Dispatching *note D.2.1(1.3/3): 8339.
+Yield_To_Higher
+ in Ada.Dispatching.Non_Preemptive *note D.2.4(2.2/3): 8378.
+Yield_To_Same_Or_Higher
+ in Ada.Dispatching.Non_Preemptive *note D.2.4(2.2/3): 8379.
+
+\1f
+Tag Table:
+Node: Top\7f215
+Node: Front Matter\7f1585
+Node: 0.1\7f7498
+Node: 0.2\7f9939
+Ref: 1001\7f33867
+Ref: 1002\7f33867
+Node: 0.99\7f49528
+Node: 1\7f49737
+Ref: 1003\7f55805
+Node: 1.1\7f56365
+Node: 1.1.1\7f58378
+Node: 1.1.2\7f59943
+Ref: 1004\7f60655
+Ref: 1005\7f60967
+Ref: 1006\7f60967
+Ref: 1007\7f60967
+Ref: 1008\7f61445
+Ref: 1009\7f61445
+Ref: 1010\7f61911
+Ref: 1011\7f61911
+Ref: 1012\7f61911
+Ref: 1013\7f66406
+Ref: 1014\7f66411
+Ref: 1015\7f66411
+Ref: 1016\7f66411
+Ref: 1017\7f66411
+Ref: 1018\7f66515
+Ref: 1019\7f66516
+Ref: 1020\7f66516
+Ref: 1021\7f67607
+Ref: 1022\7f67607
+Ref: 1023\7f67607
+Ref: 1024\7f67647
+Ref: 1025\7f67649
+Ref: 1026\7f68014
+Ref: 1027\7f68014
+Ref: 1028\7f68865
+Ref: 1029\7f68865
+Ref: 1030\7f68865
+Ref: 1031\7f68865
+Ref: 1032\7f68916
+Ref: 1033\7f68918
+Ref: 1034\7f69669
+Ref: 1035\7f69669
+Ref: 1036\7f69669
+Ref: 1037\7f69669
+Ref: 1038\7f70202
+Ref: 1039\7f70202
+Ref: 1040\7f70548
+Ref: 1041\7f70548
+Ref: 1042\7f70671
+Ref: 1043\7f71303
+Ref: 1044\7f71862
+Ref: 1045\7f72023
+Ref: 1046\7f72708
+Ref: 1047\7f72708
+Ref: 1048\7f74133
+Ref: 1049\7f74925
+Ref: 1050\7f75957
+Ref: 1051\7f76595
+Ref: 1052\7f77214
+Ref: 1053\7f77965
+Ref: 1054\7f78305
+Ref: 1055\7f78455
+Ref: 1056\7f79437
+Ref: 1057\7f80988
+Ref: 1058\7f82661
+Ref: 1059\7f83619
+Ref: 1060\7f83928
+Ref: 1061\7f84933
+Ref: 1062\7f86333
+Ref: 1063\7f87871
+Node: 1.1.3\7f88413
+Ref: 1064\7f88655
+Ref: 1065\7f88716
+Ref: 1066\7f91827
+Ref: 1067\7f93516
+Ref: 1068\7f93516
+Ref: 1069\7f93641
+Ref: 1070\7f101798
+Ref: 1071\7f101798
+Ref: 1072\7f101798
+Ref: 1073\7f101798
+Ref: 1074\7f101798
+Ref: 1075\7f104278
+Node: 1.1.4\7f106535
+Ref: 1076\7f107019
+Ref: 1077\7f107019
+Ref: 1078\7f107019
+Ref: 1079\7f107019
+Ref: 1080\7f107019
+Ref: 1081\7f108328
+Ref: 1082\7f108657
+Ref: 1083\7f108658
+Ref: 1084\7f108658
+Ref: 1085\7f108658
+Ref: 1086\7f111496
+Ref: 1087\7f111655
+Ref: 1088\7f112347
+Ref: 1089\7f112443
+Ref: 1090\7f113018
+Ref: 1091\7f113020
+Node: 1.1.5\7f116204
+Ref: 1092\7f117044
+Ref: 1093\7f117049
+Ref: 1094\7f117049
+Ref: 1095\7f117049
+Ref: 1096\7f117798
+Ref: 1097\7f117803
+Ref: 1098\7f118483
+Ref: 1099\7f118544
+Ref: 1100\7f118777
+Ref: 1101\7f120410
+Ref: 1102\7f120410
+Ref: 1103\7f121035
+Ref: 1104\7f121037
+Ref: 1105\7f121832
+Ref: 1106\7f122559
+Ref: 1107\7f122748
+Node: 1.2\7f123829
+Ref: 1108\7f123975
+Ref: 1109\7f123976
+Ref: 1110\7f124326
+Ref: 1111\7f124327
+Ref: 1112\7f124327
+Ref: 1113\7f124462
+Ref: 1114\7f124462
+Ref: 1115\7f124462
+Ref: 1116\7f124598
+Ref: 1117\7f124599
+Ref: 1118\7f124599
+Ref: 1119\7f124738
+Ref: 1120\7f124739
+Ref: 1121\7f124739
+Ref: 1122\7f124872
+Ref: 1123\7f124873
+Ref: 1124\7f124873
+Ref: 1125\7f124997
+Ref: 1126\7f124997
+Ref: 1127\7f124997
+Ref: 1128\7f125129
+Ref: 1129\7f125130
+Ref: 1130\7f125277
+Ref: 1131\7f125278
+Ref: 1132\7f125278
+Ref: 1133\7f125464
+Ref: 1134\7f125465
+Ref: 1135\7f125465
+Ref: 1136\7f125646
+Ref: 1137\7f125647
+Ref: 1138\7f125647
+Ref: 1139\7f125938
+Ref: 1140\7f125939
+Ref: 1141\7f125939
+Ref: 1142\7f126049
+Ref: 1143\7f126050
+Ref: 1144\7f126281
+Node: 1.3\7f127107
+Ref: 1145\7f127247
+Ref: 1146\7f127891
+Ref: 1147\7f127893
+Ref: 1148\7f127893
+Ref: 1149\7f127893
+Ref: 1150\7f128422
+Ref: 1151\7f128423
+Ref: 1152\7f128500
+Ref: 1153\7f128502
+Ref: 1154\7f128800
+Ref: 1155\7f128801
+Ref: 1156\7f129010
+Ref: 1157\7f129012
+Ref: 1158\7f129218
+Ref: 1159\7f129219
+Ref: 1160\7f129641
+Ref: 1161\7f129643
+Ref: 1162\7f129643
+Ref: 1163\7f129643
+Node: 2\7f129915
+Node: 2.1\7f130652
+Ref: 1164\7f130830
+Ref: 1165\7f131087
+Ref: 1166\7f131087
+Ref: 1167\7f133902
+Ref: 1168\7f134648
+Ref: 1169\7f134804
+Ref: 1170\7f135066
+Ref: 1171\7f135224
+Ref: 1172\7f135380
+Ref: 1173\7f135530
+Ref: 1174\7f135688
+Ref: 1175\7f135857
+Ref: 1176\7f136012
+Ref: 1177\7f136165
+Ref: 1178\7f136334
+Ref: 1179\7f136483
+Ref: 1180\7f136638
+Ref: 1181\7f136793
+Ref: 1182\7f136981
+Ref: 1183\7f137325
+Ref: 1184\7f137582
+Ref: 1185\7f137800
+Ref: 1186\7f137961
+Ref: 1187\7f138170
+Ref: 1188\7f141636
+Ref: 1189\7f141637
+Ref: 1190\7f141637
+Ref: 1191\7f141637
+Ref: 1192\7f141637
+Ref: 1193\7f141637
+Ref: 1194\7f141637
+Ref: 1195\7f141637
+Ref: 1196\7f141637
+Ref: 1197\7f141637
+Ref: 1198\7f141637
+Ref: 1199\7f141637
+Ref: 1200\7f141637
+Ref: 1201\7f141637
+Ref: 1202\7f141637
+Ref: 1203\7f141637
+Ref: 1204\7f141637
+Ref: 1205\7f141637
+Ref: 1206\7f141637
+Ref: 1207\7f141637
+Ref: 1208\7f141637
+Ref: 1209\7f141637
+Ref: 1210\7f141637
+Ref: 1211\7f141637
+Ref: 1212\7f141637
+Ref: 1213\7f141637
+Ref: 1214\7f141637
+Ref: 1215\7f141637
+Ref: 1216\7f141731
+Ref: 1217\7f141732
+Ref: 1218\7f146147
+Ref: 1219\7f147624
+Ref: 1220\7f147995
+Node: 2.2\7f149733
+Ref: 1221\7f149947
+Ref: 1222\7f150020
+Ref: 1223\7f150020
+Ref: 1224\7f150521
+Ref: 1225\7f150528
+Ref: 1226\7f150882
+Ref: 1227\7f151950
+Ref: 1228\7f152095
+Ref: 1229\7f153695
+Node: 2.3\7f153906
+Ref: 1230\7f154163
+Ref: S0002\7f154163
+Ref: 1231\7f154176
+Ref: 1232\7f154194
+Ref: 1233\7f154213
+Ref: 1234\7f154321
+Ref: S0003\7f154321
+Ref: S0004\7f154321
+Ref: 1235\7f154336
+Ref: 1236\7f154363
+Ref: 1237\7f154390
+Ref: 1238\7f154417
+Ref: 1239\7f154443
+Ref: 1240\7f154466
+Ref: 1241\7f154597
+Ref: S0005\7f154597
+Ref: 1242\7f154612
+Ref: 1243\7f154639
+Ref: 1244\7f154672
+Ref: 1245\7f154697
+Ref: 1246\7f155462
+Ref: 1247\7f161072
+Ref: 1248\7f161358
+Node: 2.4\7f162331
+Ref: 1249\7f162443
+Ref: 1250\7f162519
+Ref: 1251\7f162579
+Ref: 1252\7f162701
+Ref: S0006\7f162701
+Ref: 1253\7f162705
+Ref: 1254\7f162724
+Node: 2.4.1\7f162937
+Ref: 1255\7f163047
+Ref: 1256\7f163215
+Ref: S0007\7f163215
+Ref: 1257\7f163219
+Ref: 1258\7f163230
+Ref: 1259\7f163240
+Ref: 1260\7f163265
+Ref: S0008\7f163265
+Ref: 1261\7f163269
+Ref: 1262\7f163278
+Ref: 1263\7f163289
+Ref: 1264\7f163312
+Ref: S0009\7f163312
+Ref: 1265\7f163323
+Ref: 1266\7f163337
+Ref: 1267\7f163391
+Ref: S0010\7f163391
+Node: 2.4.2\7f164726
+Ref: 1268\7f164833
+Ref: 1269\7f164834
+Ref: 1270\7f164834
+Ref: 1271\7f164834
+Ref: 1272\7f164834
+Ref: 1273\7f164834
+Ref: 1274\7f164834
+Ref: 1275\7f164834
+Ref: 1276\7f164834
+Ref: 1277\7f164834
+Ref: 1278\7f164990
+Ref: S0011\7f164990
+Ref: 1279\7f165003
+Ref: 1280\7f165010
+Ref: 1281\7f165026
+Ref: 1282\7f165044
+Ref: 1283\7f165066
+Ref: S0012\7f165066
+Ref: 1284\7f165070
+Ref: 1285\7f165100
+Ref: S0013\7f165100
+Ref: 1286\7f165113
+Ref: 1287\7f165130
+Ref: 1288\7f165141
+Ref: 1289\7f165179
+Ref: S0014\7f165179
+Ref: 1290\7f165183
+Ref: 1291\7f165262
+Node: 2.5\7f166536
+Ref: 1292\7f166818
+Ref: S0015\7f166818
+Ref: 1293\7f166824
+Node: 2.6\7f167499
+Ref: 1294\7f167902
+Ref: 1295\7f167969
+Ref: S0016\7f167969
+Ref: 1296\7f167976
+Ref: 1297\7f168015
+Ref: S0017\7f168015
+Ref: 1298\7f168044
+Ref: 1299\7f168242
+Ref: 1300\7f168559
+Node: 2.7\7f169973
+Ref: 1301\7f170207
+Ref: S0018\7f170207
+Ref: 1302\7f170231
+Node: 2.8\7f170899
+Ref: 1303\7f170993
+Ref: 1304\7f172007
+Ref: S0019\7f172007
+Ref: 1305\7f172027
+Ref: 1306\7f172040
+Ref: 1307\7f172071
+Ref: 1308\7f172171
+Ref: S0020\7f172171
+Ref: 1309\7f172203
+Ref: 1310\7f172218
+Ref: 1311\7f172250
+Ref: 1312\7f172265
+Ref: 1313\7f172302
+Ref: 1314\7f172318
+Ref: 1315\7f172349
+Ref: 1316\7f172365
+Ref: 1317\7f173910
+Ref: 1318\7f173910
+Ref: 1319\7f173984
+Ref: 1320\7f173986
+Ref: 1321\7f174339
+Ref: 1322\7f174340
+Ref: 1323\7f178494
+Ref: 1324\7f178494
+Ref: 1325\7f178722
+Ref: 1326\7f183959
+Ref: 1327\7f184207
+Ref: 1328\7f184753
+Ref: 1329\7f185552
+Ref: 1330\7f185553
+Ref: 1331\7f185558
+Ref: 1332\7f185588
+Ref: 1333\7f185589
+Ref: 1334\7f185612
+Ref: 1335\7f185613
+Ref: 1336\7f185622
+Ref: 1337\7f188497
+Node: 2.9\7f189444
+Ref: 1338\7f189713
+Ref: 1339\7f191810
+Ref: 1340\7f192317
+Ref: 1341\7f193148
+Node: 3\7f193807
+Node: 3.1\7f194432
+Ref: 1342\7f194524
+Ref: 1343\7f194611
+Ref: 1344\7f195069
+Ref: S0021\7f195069
+Ref: 1345\7f195084
+Ref: 1346\7f195105
+Ref: 1347\7f195135
+Ref: 1348\7f195158
+Ref: 1349\7f195187
+Ref: 1350\7f195214
+Ref: 1351\7f195256
+Ref: 1352\7f195287
+Ref: 1353\7f195329
+Ref: 1354\7f195353
+Ref: 1355\7f195384
+Ref: 1356\7f195410
+Ref: 1357\7f195440
+Ref: 1358\7f195489
+Ref: S0022\7f195489
+Ref: 1359\7f195493
+Ref: 1360\7f195554
+Ref: 1361\7f195642
+Ref: 1362\7f195644
+Ref: 1363\7f196268
+Ref: 1364\7f197690
+Ref: 1365\7f197690
+Ref: 1366\7f199214
+Ref: 1367\7f199214
+Ref: 1368\7f199214
+Ref: 1369\7f199856
+Ref: 1370\7f200290
+Ref: 1371\7f200392
+Ref: 1372\7f200491
+Ref: 1373\7f200811
+Ref: 1374\7f201046
+Ref: 1375\7f201678
+Ref: 1376\7f201760
+Ref: 1377\7f201762
+Ref: 1378\7f202120
+Ref: 1379\7f202122
+Ref: 1380\7f204583
+Ref: 1381\7f204653
+Ref: 1382\7f204722
+Ref: 1383\7f206178
+Ref: 1384\7f206249
+Ref: 1385\7f206527
+Node: 3.2\7f212286
+Ref: 1386\7f212448
+Ref: 1387\7f212448
+Ref: 1388\7f212583
+Ref: 1389\7f213331
+Ref: 1390\7f213332
+Ref: 1391\7f213376
+Ref: 1392\7f213519
+Ref: 1393\7f213570
+Ref: 1394\7f213637
+Ref: 1395\7f213638
+Ref: 1396\7f213712
+Ref: 1397\7f213876
+Ref: 1398\7f217805
+Ref: 1399\7f217944
+Ref: 1400\7f217946
+Ref: 1401\7f218053
+Ref: 1402\7f218415
+Ref: 1403\7f218416
+Ref: 1404\7f218416
+Ref: 1405\7f219117
+Ref: 1406\7f219385
+Ref: 1407\7f219626
+Ref: 1408\7f219894
+Ref: 1409\7f219894
+Ref: 1410\7f220796
+Ref: 1411\7f220914
+Ref: 1412\7f221398
+Ref: 1413\7f221589
+Ref: 1414\7f221589
+Ref: 1415\7f221668
+Ref: 1416\7f221668
+Ref: 1417\7f221801
+Ref: 1418\7f221837
+Ref: 1419\7f221837
+Ref: 1420\7f223261
+Ref: 1421\7f223261
+Ref: 1422\7f223261
+Ref: 1423\7f223261
+Ref: 1424\7f224810
+Ref: 1425\7f225414
+Ref: 1426\7f225506
+Ref: 1427\7f225647
+Node: 3.2.1\7f231668
+Ref: 1428\7f231903
+Ref: S0023\7f231903
+Ref: 1429\7f231909
+Ref: 1430\7f231941
+Ref: 1431\7f231979
+Ref: 1432\7f232014
+Ref: 1433\7f232100
+Ref: S0024\7f232100
+Ref: 1434\7f232120
+Ref: 1435\7f232141
+Ref: 1436\7f232169
+Ref: 1437\7f232205
+Ref: 1438\7f232238
+Ref: 1439\7f232270
+Ref: 1440\7f232351
+Ref: S0025\7f232351
+Ref: 1441\7f232366
+Ref: 1442\7f232398
+Ref: 1443\7f232432
+Ref: 1444\7f232457
+Ref: 1445\7f232489
+Ref: 1446\7f232516
+Ref: 1447\7f232549
+Ref: 1448\7f232577
+Ref: 1449\7f232780
+Ref: 1450\7f233210
+Ref: 1451\7f233333
+Ref: 1452\7f233526
+Ref: 1453\7f234334
+Ref: 1454\7f234545
+Ref: 1455\7f234618
+Ref: 1456\7f235283
+Ref: 1457\7f235772
+Ref: 1458\7f236707
+Ref: 1459\7f236806
+Ref: 1460\7f240319
+Node: 3.2.2\7f240452
+Ref: 1461\7f240790
+Ref: S0026\7f240790
+Ref: 1462\7f240811
+Ref: 1463\7f240834
+Ref: 1464\7f240867
+Ref: 1465\7f240947
+Ref: S0027\7f240947
+Ref: 1466\7f240954
+Ref: 1467\7f240976
+Ref: 1468\7f240990
+Ref: 1469\7f241022
+Ref: S0028\7f241022
+Ref: 1470\7f241035
+Ref: 1471\7f241356
+Ref: S0029\7f241356
+Ref: 1472\7f241360
+Ref: 1473\7f241381
+Ref: 1474\7f241427
+Ref: S0030\7f241427
+Ref: 1475\7f241442
+Ref: 1476\7f241461
+Ref: 1477\7f241481
+Ref: 1478\7f241526
+Ref: S0031\7f241526
+Ref: 1479\7f241541
+Ref: 1480\7f241560
+Ref: 1481\7f241685
+Ref: 1482\7f242144
+Ref: 1483\7f242239
+Ref: 1484\7f242598
+Ref: 1485\7f242598
+Ref: 1486\7f243049
+Ref: 1487\7f243347
+Ref: 1488\7f244820
+Ref: 1489\7f245649
+Ref: 1490\7f245861
+Node: 3.2.3\7f245992
+Ref: 1491\7f246216
+Ref: 1492\7f246435
+Ref: 1493\7f246606
+Ref: 1494\7f247844
+Ref: 1495\7f248700
+Ref: 1496\7f250161
+Ref: 1497\7f250313
+Ref: 1498\7f250703
+Node: 3.2.4\7f252114
+Ref: 1499\7f252520
+Ref: 1500\7f252520
+Ref: 1501\7f252520
+Ref: 1502\7f252520
+Ref: 1503\7f252520
+Ref: 1504\7f252520
+Ref: 1505\7f252520
+Ref: 1506\7f253139
+Ref: 1507\7f253934
+Ref: 1508\7f254051
+Ref: 1509\7f254051
+Ref: 1510\7f254051
+Ref: 1511\7f256401
+Ref: 1512\7f256401
+Ref: 1513\7f260444
+Ref: 1514\7f261618
+Ref: 1515\7f261618
+Ref: 1516\7f261618
+Ref: 1517\7f261618
+Ref: 1518\7f261618
+Ref: 1519\7f262026
+Ref: 1520\7f263296
+Node: 3.3\7f263347
+Ref: 1521\7f263546
+Ref: 1522\7f263860
+Ref: 1523\7f264908
+Ref: 1524\7f264909
+Ref: 1525\7f264909
+Ref: 1526\7f264909
+Ref: 1527\7f264909
+Ref: 1528\7f264909
+Ref: 1529\7f265370
+Ref: 1530\7f265538
+Ref: 1531\7f265678
+Ref: 1532\7f268142
+Ref: 1533\7f268240
+Ref: 1534\7f268242
+Ref: 1535\7f268416
+Ref: 1536\7f268418
+Ref: 1537\7f269133
+Ref: 1538\7f269133
+Ref: 1539\7f271337
+Ref: 1540\7f272201
+Ref: 1541\7f274558
+Node: 3.3.1\7f275925
+Ref: 1542\7f276067
+Ref: 1543\7f276068
+Ref: 1544\7f276068
+Ref: 1545\7f276230
+Ref: 1546\7f276232
+Ref: 1547\7f276232
+Ref: 1548\7f276527
+Ref: S0032\7f276527
+Ref: 1549\7f276541
+Ref: 1550\7f276589
+Ref: 1551\7f276618
+Ref: 1552\7f276644
+Ref: 1553\7f276676
+Ref: 1554\7f276724
+Ref: 1555\7f276752
+Ref: 1556\7f276778
+Ref: 1557\7f276810
+Ref: 1558\7f276858
+Ref: 1559\7f276890
+Ref: 1560\7f276916
+Ref: 1561\7f276948
+Ref: 1562\7f276981
+Ref: 1563\7f277042
+Ref: S0033\7f277042
+Ref: 1564\7f277054
+Ref: 1565\7f277077
+Ref: 1566\7f277150
+Ref: 1567\7f277291
+Ref: 1568\7f277349
+Ref: 1569\7f277844
+Ref: 1570\7f277932
+Ref: 1571\7f278640
+Ref: 1572\7f279081
+Ref: 1573\7f279636
+Ref: 1574\7f279933
+Ref: 1575\7f279992
+Ref: 1576\7f279994
+Ref: 1577\7f280096
+Ref: 1578\7f280098
+Ref: 1579\7f280183
+Ref: 1580\7f280793
+Ref: 1581\7f281688
+Ref: 1582\7f282656
+Ref: 1583\7f283401
+Ref: 1584\7f283624
+Ref: 1585\7f283865
+Ref: 1586\7f283867
+Ref: 1587\7f284091
+Ref: 1588\7f285924
+Ref: 1589\7f289663
+Ref: 1590\7f291219
+Ref: 1591\7f291220
+Ref: 1592\7f293166
+Ref: 1593\7f295241
+Ref: 1594\7f296064
+Ref: 1595\7f296270
+Ref: 1596\7f297040
+Node: 3.3.2\7f297530
+Ref: 1597\7f297745
+Ref: 1598\7f298225
+Ref: S0034\7f298225
+Ref: 1599\7f298240
+Ref: 1600\7f298286
+Ref: 1601\7f298350
+Ref: 1602\7f299038
+Ref: 1603\7f299091
+Ref: 1604\7f299814
+Node: 3.4\7f300698
+Ref: 1605\7f300887
+Ref: 1606\7f301059
+Ref: 1607\7f301721
+Ref: 1608\7f301722
+Ref: 1609\7f302528
+Ref: S0035\7f302528
+Ref: 1610\7f302574
+Ref: 1611\7f302599
+Ref: 1612\7f302621
+Ref: 1613\7f302780
+Ref: 1614\7f302781
+Ref: 1615\7f304248
+Ref: 1616\7f306837
+Ref: 1617\7f308544
+Ref: 1618\7f308544
+Ref: 1619\7f308722
+Ref: 1620\7f309514
+Ref: 1621\7f312489
+Ref: 1622\7f312490
+Ref: 1623\7f312864
+Ref: 1624\7f312865
+Ref: 1625\7f312865
+Ref: 1626\7f316297
+Ref: 1627\7f316641
+Ref: 1628\7f317210
+Ref: 1629\7f319685
+Ref: 1630\7f320637
+Ref: 1631\7f322712
+Ref: 1632\7f323188
+Ref: 1633\7f323918
+Ref: 1634\7f324622
+Ref: 1635\7f325065
+Ref: 1636\7f325555
+Ref: 1637\7f329067
+Ref: 1638\7f329635
+Ref: 1639\7f330727
+Ref: 1640\7f331692
+Ref: 1641\7f332743
+Node: 3.4.1\7f333765
+Ref: 1642\7f334081
+Ref: 1643\7f334392
+Ref: 1644\7f334394
+Ref: 1645\7f334394
+Ref: 1646\7f335298
+Ref: 1647\7f335755
+Ref: 1648\7f336376
+Ref: 1649\7f337367
+Ref: 1650\7f337687
+Ref: 1651\7f337687
+Ref: 1652\7f337687
+Ref: 1653\7f337687
+Ref: 1654\7f340557
+Ref: 1655\7f340557
+Ref: 1656\7f340712
+Ref: 1657\7f340891
+Ref: 1658\7f341236
+Ref: 1659\7f341317
+Ref: 1660\7f341319
+Ref: 1661\7f343414
+Node: 3.5\7f345171
+Ref: 1662\7f345275
+Ref: 1663\7f345346
+Ref: 1664\7f345409
+Ref: 1665\7f345488
+Ref: 1666\7f345710
+Ref: S0036\7f345710
+Ref: 1667\7f345722
+Ref: 1668\7f345741
+Ref: S0037\7f345741
+Ref: 1669\7f345747
+Ref: 1670\7f345783
+Ref: 1671\7f345804
+Ref: 1672\7f346068
+Ref: 1673\7f346068
+Ref: 1674\7f346068
+Ref: 1675\7f346068
+Ref: 1676\7f346267
+Ref: 1677\7f346465
+Ref: 1678\7f346583
+Ref: 1679\7f346660
+Ref: 1680\7f346819
+Ref: 1681\7f347048
+Ref: 1682\7f348768
+Ref: 1683\7f349466
+Ref: 1684\7f350255
+Ref: 1685\7f350255
+Ref: 1686\7f350329
+Ref: 1687\7f350566
+Ref: 1688\7f350714
+Ref: 1689\7f351531
+Ref: 1690\7f351609
+Ref: 1691\7f351863
+Ref: 1692\7f351863
+Ref: 1693\7f352092
+Ref: 1694\7f352107
+Ref: 1695\7f352323
+Ref: 1696\7f352338
+Ref: 1697\7f352543
+Ref: 1698\7f352558
+Ref: 1699\7f352624
+Ref: 1700\7f352639
+Ref: 1701\7f352793
+Ref: 1702\7f352806
+Ref: 1703\7f352821
+Ref: 1704\7f353122
+Ref: 1705\7f353472
+Ref: 1706\7f353487
+Ref: 1707\7f353773
+Ref: 1708\7f353788
+Ref: 1709\7f353957
+Ref: 1710\7f354122
+Ref: 1711\7f354123
+Ref: 1712\7f354609
+Ref: 1713\7f354610
+Ref: 1714\7f355084
+Ref: 1715\7f355099
+Ref: 1716\7f355268
+Ref: 1717\7f355433
+Ref: 1718\7f355434
+Ref: 1719\7f355935
+Ref: 1720\7f355936
+Ref: 1721\7f356428
+Ref: 1722\7f356443
+Ref: 1723\7f356681
+Ref: 1724\7f357573
+Ref: 1725\7f358401
+Ref: 1726\7f360821
+Ref: 1727\7f360836
+Ref: 1728\7f361132
+Ref: 1729\7f361946
+Ref: 1730\7f361961
+Ref: 1731\7f362948
+Ref: 1732\7f362963
+Ref: 1733\7f363285
+Ref: 1734\7f363300
+Ref: 1735\7f363557
+Ref: 1736\7f363572
+Ref: 1737\7f363829
+Ref: 1738\7f363844
+Ref: 1739\7f364296
+Ref: 1740\7f364297
+Ref: 1741\7f364803
+Ref: 1742\7f364804
+Ref: 1743\7f365649
+Ref: 1744\7f366170
+Ref: 1745\7f366171
+Ref: 1746\7f367493
+Ref: 1747\7f367709
+Ref: 1748\7f367710
+Ref: 1749\7f367915
+Ref: 1750\7f367930
+Ref: 1751\7f368352
+Ref: 1752\7f368353
+Ref: 1753\7f368834
+Ref: 1754\7f368835
+Ref: 1755\7f369967
+Ref: 1756\7f369982
+Ref: 1757\7f370369
+Ref: 1758\7f370370
+Ref: 1759\7f370841
+Ref: 1760\7f370842
+Ref: 1761\7f373102
+Ref: 1762\7f373102
+Ref: 1763\7f374294
+Ref: 1764\7f376142
+Ref: 1765\7f377242
+Ref: 1766\7f378718
+Ref: 1767\7f379382
+Ref: 1768\7f380889
+Node: 3.5.1\7f381376
+Ref: 1769\7f381489
+Ref: 1770\7f381627
+Ref: S0038\7f381627
+Ref: 1771\7f381641
+Ref: 1772\7f381678
+Ref: 1773\7f381761
+Ref: S0039\7f381761
+Ref: 1774\7f381767
+Ref: 1775\7f381789
+Ref: 1776\7f381856
+Ref: S0040\7f381856
+Ref: 1777\7f381860
+Ref: 1778\7f382612
+Ref: 1779\7f383743
+Ref: 1780\7f384084
+Ref: 1781\7f384528
+Ref: 1782\7f384528
+Ref: 1783\7f384528
+Ref: 1784\7f386546
+Node: 3.5.2\7f387446
+Ref: 1785\7f387614
+Ref: 1786\7f387841
+Ref: 1787\7f387842
+Ref: 1788\7f387842
+Ref: 1789\7f387842
+Ref: 1790\7f388519
+Ref: 1791\7f388521
+Ref: 1792\7f388689
+Ref: 1793\7f388690
+Ref: 1794\7f388690
+Ref: 1795\7f389203
+Ref: 1796\7f389204
+Ref: 1797\7f391491
+Ref: 1798\7f391950
+Ref: 1799\7f392517
+Ref: 1800\7f393152
+Ref: 1801\7f395453
+Ref: 1802\7f396719
+Node: 3.5.3\7f396721
+Ref: 1803\7f396885
+Ref: 1804\7f396990
+Ref: 1805\7f396992
+Ref: 1806\7f397082
+Node: 3.5.4\7f397592
+Ref: 1807\7f397710
+Ref: 1808\7f397710
+Ref: 1809\7f397710
+Ref: 1810\7f398086
+Ref: 1811\7f398161
+Ref: S0041\7f398161
+Ref: 1812\7f398165
+Ref: 1813\7f398199
+Ref: 1814\7f398267
+Ref: S0042\7f398267
+Ref: 1815\7f398285
+Ref: 1816\7f398319
+Ref: 1817\7f399125
+Ref: S0043\7f399125
+Ref: 1818\7f399141
+Ref: 1819\7f399204
+Ref: 1820\7f399336
+Ref: 1821\7f399630
+Ref: 1822\7f399630
+Ref: 1823\7f399630
+Ref: 1824\7f400530
+Ref: 1825\7f400731
+Ref: 1826\7f400733
+Ref: 1827\7f401529
+Ref: 1828\7f401536
+Ref: 1829\7f401650
+Ref: 1830\7f401652
+Ref: 1831\7f401796
+Ref: 1832\7f403255
+Ref: 1833\7f403255
+Ref: 1834\7f403468
+Ref: 1835\7f403468
+Ref: 1836\7f403468
+Ref: 1837\7f403826
+Ref: 1838\7f403828
+Ref: 1839\7f405711
+Ref: 1840\7f405890
+Ref: 1841\7f405905
+Ref: 1842\7f406235
+Ref: 1843\7f406250
+Ref: 1844\7f406405
+Ref: 1845\7f406747
+Ref: 1846\7f406747
+Ref: 1847\7f406747
+Ref: 1848\7f406939
+Ref: 1849\7f406939
+Ref: 1850\7f406939
+Ref: 1851\7f407115
+Ref: 1852\7f407209
+Ref: 1853\7f407818
+Ref: 1854\7f407818
+Ref: 1855\7f408660
+Ref: 1856\7f409614
+Ref: 1857\7f410721
+Ref: 1858\7f412168
+Ref: 1859\7f413340
+Ref: 1860\7f413340
+Ref: 1861\7f414896
+Ref: 1862\7f417513
+Node: 3.5.5\7f417980
+Ref: 1863\7f418251
+Ref: 1864\7f418266
+Ref: 1865\7f418582
+Ref: 1866\7f418597
+Ref: 1867\7f418773
+Ref: 1868\7f418788
+Ref: 1869\7f418896
+Ref: 1870\7f418898
+Ref: 1871\7f419767
+Ref: 1872\7f419782
+Ref: 1873\7f420014
+Ref: 1874\7f420029
+Ref: 1875\7f421499
+Ref: 1876\7f422422
+Ref: 1877\7f424078
+Ref: 1878\7f424360
+Node: 3.5.6\7f424427
+Ref: 1879\7f424539
+Ref: 1880\7f424768
+Ref: S0044\7f424768
+Ref: 1881\7f424781
+Ref: 1882\7f424809
+Ref: 1883\7f424881
+Ref: 1884\7f425776
+Ref: 1885\7f425776
+Ref: 1886\7f425957
+Ref: 1887\7f426268
+Ref: 1888\7f427859
+Node: 3.5.7\7f430007
+Ref: 1889\7f430139
+Ref: 1890\7f430361
+Ref: S0045\7f430361
+Ref: 1891\7f430387
+Ref: 1892\7f430399
+Ref: 1893\7f430457
+Ref: S0046\7f430457
+Ref: 1894\7f430482
+Ref: 1895\7f430510
+Ref: 1896\7f430580
+Ref: 1897\7f430790
+Ref: 1898\7f430850
+Ref: 1899\7f431021
+Ref: 1900\7f431238
+Ref: 1901\7f432267
+Ref: 1902\7f432417
+Ref: 1903\7f433079
+Ref: 1904\7f433213
+Ref: 1905\7f433785
+Ref: 1906\7f433920
+Ref: 1907\7f433922
+Ref: 1908\7f434539
+Ref: 1909\7f434541
+Ref: 1910\7f435200
+Ref: 1911\7f435207
+Ref: 1912\7f435384
+Ref: 1913\7f435544
+Ref: 1914\7f435703
+Ref: 1915\7f435868
+Ref: 1916\7f435868
+Ref: 1917\7f436761
+Ref: 1918\7f438545
+Node: 3.5.8\7f440614
+Ref: 1919\7f440905
+Ref: 1920\7f440920
+Ref: 1921\7f441530
+Node: 3.5.9\7f442373
+Ref: 1922\7f442500
+Ref: 1923\7f442500
+Ref: 1924\7f442500
+Ref: 1925\7f442589
+Ref: 1926\7f442777
+Ref: S0047\7f442777
+Ref: 1927\7f442781
+Ref: 1928\7f442816
+Ref: 1929\7f442892
+Ref: S0048\7f442892
+Ref: 1930\7f442918
+Ref: 1931\7f442930
+Ref: 1932\7f442993
+Ref: S0049\7f442993
+Ref: 1933\7f443019
+Ref: 1934\7f443044
+Ref: 1935\7f443056
+Ref: 1936\7f443113
+Ref: S0050\7f443113
+Ref: 1937\7f443140
+Ref: 1938\7f443152
+Ref: 1939\7f443222
+Ref: 1940\7f443424
+Ref: 1941\7f443426
+Ref: 1942\7f443426
+Ref: 1943\7f443976
+Ref: 1944\7f444090
+Ref: 1945\7f444237
+Ref: 1946\7f445537
+Ref: 1947\7f445691
+Ref: 1948\7f445981
+Ref: 1949\7f445983
+Ref: 1950\7f446285
+Ref: 1951\7f446682
+Ref: 1952\7f446741
+Ref: 1953\7f446901
+Ref: 1954\7f446903
+Ref: 1955\7f447154
+Ref: 1956\7f447644
+Ref: 1957\7f447698
+Ref: 1958\7f448029
+Ref: 1959\7f449937
+Ref: 1960\7f450036
+Ref: 1961\7f450038
+Ref: 1962\7f450261
+Ref: 1963\7f452799
+Ref: 1964\7f453149
+Node: 3.5.10\7f454185
+Ref: 1965\7f454457
+Ref: 1966\7f454472
+Ref: 1967\7f454654
+Ref: 1968\7f454656
+Ref: 1969\7f454905
+Ref: 1970\7f454905
+Ref: 1971\7f455011
+Ref: 1972\7f455026
+Ref: 1973\7f455354
+Ref: 1974\7f455369
+Ref: 1975\7f455918
+Ref: 1976\7f455933
+Ref: 1977\7f456515
+Ref: 1978\7f456530
+Ref: 1979\7f456854
+Ref: 1980\7f457965
+Ref: 1981\7f457980
+Ref: 1982\7f458093
+Ref: 1983\7f458462
+Ref: 1984\7f458477
+Ref: 1985\7f459155
+Node: 3.6\7f459971
+Ref: 1986\7f460073
+Ref: 1987\7f460073
+Ref: 1988\7f460441
+Ref: S0051\7f460441
+Ref: 1989\7f460454
+Ref: 1990\7f460487
+Ref: 1991\7f460554
+Ref: S0052\7f460554
+Ref: 1992\7f460573
+Ref: 1993\7f460601
+Ref: 1994\7f460631
+Ref: 1995\7f460690
+Ref: S0053\7f460690
+Ref: 1996\7f460694
+Ref: 1997\7f460753
+Ref: S0054\7f460753
+Ref: 1998\7f460773
+Ref: 1999\7f460804
+Ref: 2000\7f460843
+Ref: 2001\7f460899
+Ref: S0055\7f460899
+Ref: 2002\7f460913
+Ref: 2003\7f460934
+Ref: 2004\7f461033
+Ref: S0056\7f461033
+Ref: 2005\7f461056
+Ref: 2006\7f461093
+Ref: 2007\7f461163
+Ref: 2008\7f461493
+Ref: 2009\7f461607
+Ref: 2010\7f461679
+Ref: 2011\7f461873
+Ref: 2012\7f462274
+Ref: 2013\7f462274
+Ref: 2014\7f462274
+Ref: 2015\7f462887
+Ref: 2016\7f462935
+Ref: 2017\7f462995
+Ref: 2018\7f463119
+Ref: 2019\7f463592
+Ref: 2020\7f463592
+Ref: 2021\7f463847
+Ref: 2022\7f464018
+Ref: 2023\7f464018
+Ref: 2024\7f464275
+Ref: 2025\7f465138
+Ref: 2026\7f465448
+Ref: 2027\7f465751
+Ref: 2028\7f466033
+Ref: 2029\7f466345
+Ref: 2030\7f466711
+Ref: 2031\7f467098
+Ref: 2032\7f467648
+Ref: 2033\7f467648
+Ref: 2034\7f468929
+Ref: 2035\7f470742
+Ref: 2036\7f472399
+Ref: 2037\7f473104
+Node: 3.6.1\7f473382
+Ref: 2038\7f473740
+Ref: S0057\7f473740
+Ref: 2039\7f473747
+Ref: 2040\7f473765
+Ref: 2041\7f473804
+Ref: S0058\7f473804
+Ref: 2042\7f473818
+Ref: 2043\7f473839
+Ref: 2044\7f473897
+Ref: 2045\7f474013
+Ref: 2046\7f474711
+Ref: 2047\7f474897
+Ref: 2048\7f475098
+Ref: 2049\7f475217
+Ref: 2050\7f475536
+Ref: 2051\7f475650
+Ref: 2052\7f477077
+Node: 3.6.2\7f478060
+Ref: 2053\7f478955
+Ref: 2054\7f478970
+Ref: 2055\7f479099
+Ref: 2056\7f479114
+Ref: 2057\7f479241
+Ref: 2058\7f479256
+Ref: 2059\7f479383
+Ref: 2060\7f479398
+Ref: 2061\7f479525
+Ref: 2062\7f479540
+Ref: 2063\7f479673
+Ref: 2064\7f479688
+Ref: 2065\7f479842
+Ref: 2066\7f479857
+Ref: 2067\7f480022
+Ref: 2068\7f480037
+Ref: 2069\7f481296
+Node: 3.6.3\7f482424
+Ref: 2070\7f482572
+Ref: 2071\7f484198
+Ref: 2072\7f484487
+Ref: 2073\7f484791
+Ref: 2074\7f485155
+Ref: 2075\7f485654
+Node: 3.7\7f485690
+Ref: 2076\7f485857
+Ref: 2077\7f485857
+Ref: 2078\7f485858
+Ref: 2079\7f486729
+Ref: 2080\7f486730
+Ref: 2081\7f489095
+Ref: S0059\7f489095
+Ref: 2082\7f489099
+Ref: 2083\7f489128
+Ref: 2084\7f489191
+Ref: S0060\7f489191
+Ref: 2085\7f489232
+Ref: S0061\7f489232
+Ref: 2086\7f489246
+Ref: 2087\7f489276
+Ref: 2088\7f489370
+Ref: S0062\7f489370
+Ref: 2089\7f489383
+Ref: 2090\7f489411
+Ref: 2091\7f489427
+Ref: 2092\7f489444
+Ref: 2093\7f489478
+Ref: 2094\7f489505
+Ref: 2095\7f489527
+Ref: 2096\7f489579
+Ref: S0063\7f489579
+Ref: 2097\7f489583
+Ref: 2098\7f489647
+Ref: 2099\7f490130
+Ref: 2100\7f491500
+Ref: 2101\7f494198
+Ref: 2102\7f501162
+Ref: 2103\7f501464
+Ref: 2104\7f501910
+Ref: 2105\7f502534
+Ref: 2106\7f505202
+Ref: 2107\7f505202
+Ref: 2108\7f505202
+Ref: 2109\7f505202
+Ref: 2110\7f505321
+Ref: 2111\7f505323
+Ref: 2112\7f505684
+Ref: 2113\7f505686
+Ref: 2114\7f508059
+Ref: 2115\7f509396
+Ref: 2116\7f513757
+Ref: 2117\7f516320
+Ref: 2118\7f516916
+Node: 3.7.1\7f517266
+Ref: 2119\7f517800
+Ref: S0064\7f517800
+Ref: 2120\7f517814
+Ref: 2121\7f517842
+Ref: 2122\7f517901
+Ref: S0065\7f517901
+Ref: 2123\7f517928
+Ref: 2124\7f517958
+Ref: 2125\7f517977
+Ref: 2126\7f517997
+Ref: 2127\7f518104
+Ref: 2128\7f518452
+Ref: 2129\7f518538
+Ref: 2130\7f518820
+Ref: 2131\7f519687
+Ref: 2132\7f522091
+Ref: 2133\7f522642
+Ref: 2134\7f522810
+Ref: 2135\7f523164
+Ref: 2136\7f524744
+Ref: 2137\7f525601
+Node: 3.7.2\7f527137
+Ref: 2138\7f527838
+Ref: 2139\7f527853
+Ref: 2140\7f530215
+Ref: 2141\7f531123
+Node: 3.8\7f532571
+Ref: 2142\7f532675
+Ref: 2143\7f532675
+Ref: 2144\7f532838
+Ref: 2145\7f532912
+Ref: S0066\7f532912
+Ref: 2146\7f532947
+Ref: 2147\7f532996
+Ref: S0067\7f532996
+Ref: 2148\7f533029
+Ref: 2149\7f533107
+Ref: S0068\7f533107
+Ref: 2150\7f533123
+Ref: 2151\7f533139
+Ref: 2152\7f533166
+Ref: 2153\7f533182
+Ref: 2154\7f533286
+Ref: S0069\7f533286
+Ref: 2155\7f533295
+Ref: 2156\7f533320
+Ref: 2157\7f533390
+Ref: S0070\7f533390
+Ref: 2158\7f533403
+Ref: 2159\7f533430
+Ref: 2160\7f533455
+Ref: 2161\7f533495
+Ref: 2162\7f533570
+Ref: 2163\7f533820
+Ref: 2164\7f535402
+Ref: 2165\7f537656
+Ref: 2166\7f537657
+Ref: 2167\7f537779
+Ref: 2168\7f538000
+Ref: 2169\7f538469
+Ref: 2170\7f538617
+Ref: 2171\7f538721
+Ref: 2172\7f538868
+Ref: 2173\7f539404
+Ref: 2174\7f539405
+Ref: 2175\7f539405
+Ref: 2176\7f539817
+Ref: 2177\7f540778
+Ref: 2178\7f542665
+Ref: 2179\7f543677
+Ref: 2180\7f545448
+Ref: 2181\7f545558
+Ref: 2182\7f546392
+Node: 3.8.1\7f546584
+Ref: 2183\7f546937
+Ref: 2184\7f547651
+Ref: S0071\7f547651
+Ref: 2185\7f547682
+Ref: 2186\7f547709
+Ref: 2187\7f547729
+Ref: 2188\7f547771
+Ref: S0072\7f547771
+Ref: 2189\7f547789
+Ref: 2190\7f547824
+Ref: 2191\7f547867
+Ref: S0073\7f547867
+Ref: 2192\7f547871
+Ref: 2193\7f547891
+Ref: 2194\7f547983
+Ref: S0074\7f547983
+Ref: 2195\7f547992
+Ref: 2196\7f548022
+Ref: 2197\7f548043
+Ref: 2198\7f548116
+Ref: 2199\7f548331
+Ref: 2200\7f549183
+Ref: 2201\7f550808
+Ref: 2202\7f552781
+Ref: 2203\7f552781
+Ref: 2204\7f555020
+Ref: 2205\7f556003
+Ref: 2206\7f557142
+Ref: 2207\7f557544
+Node: 3.9\7f558464
+Ref: 2208\7f558610
+Ref: 2209\7f558610
+Ref: 2210\7f558611
+Ref: 2211\7f558611
+Ref: 2212\7f558611
+Ref: 2213\7f558770
+Ref: 2214\7f558772
+Ref: 2215\7f558772
+Ref: 2216\7f564762
+Ref: 2217\7f565164
+Ref: 2218\7f565166
+Ref: 2219\7f565293
+Ref: 2220\7f565294
+Ref: 2221\7f565294
+Ref: 2222\7f567269
+Ref: 2223\7f567602
+Ref: 2224\7f567671
+Ref: 2225\7f567673
+Ref: 2226\7f567673
+Ref: 2227\7f567673
+Ref: 2228\7f568344
+Ref: 2229\7f571267
+Ref: 2230\7f571337
+Ref: 2231\7f571449
+Ref: 2232\7f571524
+Ref: 2233\7f571580
+Ref: 2234\7f571646
+Ref: 2235\7f571722
+Ref: 2236\7f571777
+Ref: 2237\7f571875
+Ref: 2238\7f571955
+Ref: 2239\7f572094
+Ref: 2240\7f572177
+Ref: 2241\7f572278
+Ref: 2242\7f572380
+Ref: 2243\7f572425
+Ref: 2244\7f579284
+Ref: 2245\7f580440
+Ref: 2246\7f581175
+Ref: 2247\7f581190
+Ref: 2248\7f581441
+Ref: 2249\7f581456
+Ref: 2250\7f582552
+Ref: 2251\7f582567
+Ref: 2252\7f583085
+Ref: 2253\7f583100
+Ref: 2254\7f583666
+Ref: 2255\7f584835
+Ref: 2256\7f585125
+Ref: 2257\7f585459
+Ref: 2258\7f585876
+Ref: 2259\7f586430
+Ref: 2260\7f586550
+Ref: 2261\7f588225
+Ref: 2262\7f594684
+Ref: 2263\7f594684
+Ref: 2264\7f595011
+Ref: 2265\7f595151
+Ref: 2266\7f596949
+Ref: 2267\7f597618
+Ref: 2268\7f598475
+Ref: 2269\7f599168
+Node: 3.9.1\7f599976
+Ref: 2270\7f600116
+Ref: 2271\7f600116
+Ref: 2272\7f600117
+Ref: 2273\7f600117
+Ref: 2274\7f600117
+Ref: 2275\7f600117
+Ref: 2276\7f600773
+Ref: S0075\7f600773
+Ref: 2277\7f600783
+Ref: 2278\7f601201
+Ref: 2279\7f605514
+Ref: 2280\7f606378
+Ref: 2281\7f606584
+Ref: 2282\7f610411
+Ref: 2283\7f610548
+Node: 3.9.2\7f611044
+Ref: 2284\7f611271
+Ref: 2285\7f611272
+Ref: 2286\7f611272
+Ref: 2287\7f611272
+Ref: 2288\7f611272
+Ref: 2289\7f611272
+Ref: 2290\7f611272
+Ref: 2291\7f611272
+Ref: 2292\7f612257
+Ref: 2293\7f612259
+Ref: 2294\7f612259
+Ref: 2295\7f612259
+Ref: 2296\7f612259
+Ref: 2297\7f613500
+Ref: 2298\7f613501
+Ref: 2299\7f613618
+Ref: 2300\7f613810
+Ref: 2301\7f614063
+Ref: 2302\7f614065
+Ref: 2303\7f614486
+Ref: 2304\7f614486
+Ref: 2305\7f615447
+Ref: 2306\7f615883
+Ref: 2307\7f616141
+Ref: 2308\7f619527
+Ref: 2309\7f619654
+Ref: 2310\7f624778
+Ref: 2311\7f624778
+Ref: 2312\7f624977
+Ref: 2313\7f625322
+Ref: 2314\7f625324
+Ref: 2315\7f625448
+Ref: 2316\7f628789
+Ref: 2317\7f636440
+Ref: 2318\7f636595
+Ref: 2319\7f637530
+Node: 3.9.3\7f640207
+Ref: 2320\7f640391
+Ref: 2321\7f640391
+Ref: 2322\7f640392
+Ref: 2323\7f640392
+Ref: 2324\7f640526
+Ref: 2325\7f640528
+Ref: 2326\7f641856
+Ref: S0076\7f641856
+Ref: 2327\7f641871
+Ref: 2328\7f641902
+Ref: 2329\7f641953
+Ref: 2330\7f642057
+Ref: 2331\7f642058
+Ref: 2332\7f643186
+Ref: 2333\7f643187
+Ref: 2334\7f648433
+Ref: 2335\7f659037
+Ref: 2336\7f661966
+Ref: 2337\7f663219
+Ref: 2338\7f663964
+Node: 3.9.4\7f664851
+Ref: 2339\7f666388
+Ref: S0077\7f666388
+Ref: 2340\7f666461
+Ref: 2341\7f666570
+Ref: S0078\7f666570
+Ref: 2342\7f666585
+Ref: 2343\7f666613
+Ref: 2344\7f666760
+Ref: 2345\7f666760
+Ref: 2346\7f667101
+Ref: 2347\7f667101
+Ref: 2348\7f667102
+Ref: 2349\7f667102
+Ref: 2350\7f667102
+Ref: 2351\7f667102
+Ref: 2352\7f667102
+Ref: 2353\7f667102
+Ref: 2354\7f667102
+Ref: 2355\7f667102
+Ref: 2356\7f667584
+Ref: 2357\7f667585
+Ref: 2358\7f667585
+Ref: 2359\7f667585
+Ref: 2360\7f667585
+Ref: 2361\7f667585
+Ref: 2362\7f667585
+Ref: 2363\7f669557
+Ref: 2364\7f669558
+Ref: 2365\7f673143
+Ref: 2366\7f678577
+Node: 3.10\7f679002
+Ref: 2367\7f679110
+Ref: 2368\7f679110
+Ref: 2369\7f679110
+Ref: 2370\7f679402
+Ref: 2371\7f679404
+Ref: 2372\7f680061
+Ref: S0079\7f680061
+Ref: 2373\7f680076
+Ref: 2374\7f680092
+Ref: 2375\7f680130
+Ref: 2376\7f680146
+Ref: 2377\7f680213
+Ref: S0080\7f680213
+Ref: 2378\7f680235
+Ref: 2379\7f680260
+Ref: 2380\7f680310
+Ref: S0081\7f680310
+Ref: 2381\7f680369
+Ref: S0082\7f680369
+Ref: 2382\7f680412
+Ref: 2383\7f680468
+Ref: 2384\7f680552
+Ref: S0083\7f680552
+Ref: 2385\7f680685
+Ref: S0084\7f680685
+Ref: 2386\7f680700
+Ref: 2387\7f680734
+Ref: 2388\7f680757
+Ref: 2389\7f680802
+Ref: 2390\7f680830
+Ref: 2391\7f680874
+Ref: 2392\7f681009
+Ref: 2393\7f681010
+Ref: 2394\7f681010
+Ref: 2395\7f681010
+Ref: 2396\7f681170
+Ref: 2397\7f681348
+Ref: 2398\7f681571
+Ref: 2399\7f681571
+Ref: 2400\7f682389
+Ref: 2401\7f686806
+Ref: 2402\7f686807
+Ref: 2403\7f687009
+Ref: 2404\7f687174
+Ref: 2405\7f689317
+Ref: 2406\7f689411
+Ref: 2407\7f689516
+Ref: 2408\7f694237
+Ref: 2409\7f694238
+Ref: 2410\7f694238
+Ref: 2411\7f694735
+Ref: 2412\7f694799
+Ref: 2413\7f695719
+Ref: 2414\7f697441
+Ref: 2415\7f697442
+Ref: 2416\7f700435
+Ref: 2417\7f700642
+Ref: 2418\7f700933
+Ref: 2419\7f701226
+Ref: 2420\7f702977
+Ref: 2421\7f703793
+Ref: 2422\7f705117
+Ref: 2423\7f705853
+Node: 3.10.1\7f708449
+Ref: 2424\7f709127
+Ref: S0085\7f709127
+Ref: 2425\7f709137
+Ref: 2426\7f709164
+Ref: 2427\7f709277
+Ref: 2428\7f709278
+Ref: 2429\7f709568
+Ref: 2430\7f709568
+Ref: 2431\7f711912
+Ref: 2432\7f714146
+Ref: 2433\7f719913
+Ref: 2434\7f720366
+Ref: 2435\7f722425
+Ref: 2436\7f724765
+Ref: 2437\7f725898
+Ref: 2438\7f726923
+Node: 3.10.2\7f728168
+Ref: 2439\7f729403
+Ref: 2440\7f730069
+Ref: 2441\7f730071
+Ref: 2442\7f731922
+Ref: 2443\7f731923
+Ref: 2444\7f731923
+Ref: 2445\7f731923
+Ref: 2446\7f731923
+Ref: 2447\7f731923
+Ref: 2448\7f733409
+Ref: 2449\7f733411
+Ref: 2450\7f733415
+Ref: 2451\7f733415
+Ref: 2452\7f738361
+Ref: 2453\7f738361
+Ref: 2454\7f738361
+Ref: 2455\7f748785
+Ref: 2456\7f748786
+Ref: 2457\7f750205
+Ref: 2458\7f751732
+Ref: 2459\7f754332
+Ref: 2460\7f754332
+Ref: 2461\7f758790
+Ref: 2462\7f758790
+Ref: 2463\7f776748
+Ref: 2464\7f776763
+Ref: 2465\7f777082
+Ref: 2466\7f781241
+Ref: 2467\7f782939
+Ref: 2468\7f784042
+Ref: 2469\7f784047
+Ref: 2470\7f784062
+Ref: 2471\7f784062
+Ref: 2472\7f785287
+Ref: 2473\7f785707
+Ref: 2474\7f785722
+Ref: 2475\7f786035
+Ref: 2476\7f786127
+Ref: 2477\7f786469
+Ref: 2478\7f788291
+Ref: 2479\7f788291
+Ref: 2480\7f790050
+Ref: 2481\7f790409
+Ref: 2482\7f791671
+Ref: 2483\7f791672
+Ref: 2484\7f793384
+Ref: 2485\7f793847
+Ref: 2486\7f796649
+Ref: 2487\7f798313
+Ref: 2488\7f799458
+Node: 3.11\7f801754
+Ref: 2489\7f801990
+Ref: S0086\7f801990
+Ref: 2490\7f801996
+Ref: 2491\7f802038
+Ref: S0087\7f802038
+Ref: 2492\7f802052
+Ref: 2493\7f802077
+Ref: 2494\7f802169
+Ref: S0088\7f802169
+Ref: 2495\7f802183
+Ref: 2496\7f802203
+Ref: 2497\7f802219
+Ref: 2498\7f802242
+Ref: S0089\7f802242
+Ref: 2499\7f802246
+Ref: 2500\7f802261
+Ref: 2501\7f802290
+Ref: S0090\7f802290
+Ref: 2502\7f802304
+Ref: 2503\7f802322
+Ref: 2504\7f802337
+Ref: 2505\7f802349
+Ref: 2506\7f802553
+Ref: 2507\7f802604
+Ref: 2508\7f802769
+Ref: 2509\7f803417
+Ref: 2510\7f803417
+Ref: 2511\7f803820
+Ref: 2512\7f805060
+Ref: 2513\7f807090
+Ref: 2514\7f807095
+Ref: 2515\7f807257
+Node: 3.11.1\7f809589
+Ref: 2516\7f809829
+Ref: 2517\7f809903
+Ref: 2518\7f810052
+Ref: 2519\7f812375
+Ref: 2520\7f812505
+Ref: 2521\7f814343
+Node: 4\7f816436
+Node: 4.1\7f816998
+Ref: 2522\7f817608
+Ref: S0091\7f817608
+Ref: 2523\7f817623
+Ref: 2524\7f817639
+Ref: 2525\7f817670
+Ref: 2526\7f817692
+Ref: 2527\7f817708
+Ref: 2528\7f817731
+Ref: 2529\7f817761
+Ref: 2530\7f817781
+Ref: 2531\7f817805
+Ref: 2532\7f817827
+Ref: 2533\7f817858
+Ref: 2534\7f817884
+Ref: 2535\7f817924
+Ref: S0092\7f817924
+Ref: 2536\7f817928
+Ref: 2537\7f817942
+Ref: 2538\7f818228
+Ref: S0093\7f818228
+Ref: 2539\7f818232
+Ref: 2540\7f818240
+Ref: 2541\7f818289
+Ref: S0094\7f818289
+Ref: 2542\7f818293
+Ref: 2543\7f818331
+Ref: S0095\7f818331
+Ref: 2544\7f818335
+Ref: 2545\7f818686
+Ref: 2546\7f818686
+Ref: 2547\7f818885
+Ref: 2548\7f819787
+Ref: 2549\7f821142
+Ref: 2550\7f821813
+Ref: 2551\7f821980
+Ref: 2552\7f822063
+Ref: 2553\7f822244
+Ref: 2554\7f822409
+Ref: 2555\7f822411
+Ref: 2556\7f822483
+Ref: 2557\7f823561
+Ref: 2558\7f827828
+Node: 4.1.1\7f829159
+Ref: 2559\7f829369
+Ref: 2560\7f829439
+Ref: S0096\7f829439
+Ref: 2561\7f829443
+Ref: 2562\7f829451
+Ref: 2563\7f829465
+Ref: 2564\7f829844
+Ref: 2565\7f830089
+Ref: 2566\7f830377
+Ref: 2567\7f830488
+Ref: 2568\7f830564
+Ref: 2569\7f830566
+Ref: 2570\7f830566
+Ref: 2571\7f830696
+Node: 4.1.2\7f831809
+Ref: 2572\7f831914
+Ref: 2573\7f832191
+Ref: S0097\7f832191
+Ref: 2574\7f832195
+Ref: 2575\7f832203
+Ref: 2576\7f832378
+Ref: 2577\7f832871
+Ref: 2578\7f832972
+Ref: 2579\7f832972
+Ref: 2580\7f832974
+Ref: 2581\7f832974
+Ref: 2582\7f833179
+Node: 4.1.3\7f834703
+Ref: 2583\7f835019
+Ref: 2584\7f835090
+Ref: S0098\7f835090
+Ref: 2585\7f835094
+Ref: 2586\7f835104
+Ref: 2587\7f835139
+Ref: S0099\7f835139
+Ref: 2588\7f835143
+Ref: 2589\7f835157
+Ref: 2590\7f835177
+Ref: 2591\7f835245
+Ref: 2592\7f839446
+Ref: 2593\7f839448
+Ref: 2594\7f843107
+Ref: 2595\7f843189
+Ref: 2596\7f843189
+Ref: 2597\7f843381
+Ref: 2598\7f843383
+Ref: 2599\7f845005
+Ref: 2600\7f846238
+Ref: 2601\7f846513
+Node: 4.1.4\7f847411
+Ref: 2602\7f847523
+Ref: 2603\7f847762
+Ref: S0100\7f847762
+Ref: 2604\7f847766
+Ref: 2605\7f847774
+Ref: 2606\7f847850
+Ref: S0101\7f847850
+Ref: 2607\7f847864
+Ref: 2608\7f847883
+Ref: 2609\7f847968
+Ref: S0102\7f847968
+Ref: 2610\7f847972
+Ref: 2611\7f847980
+Ref: 2612\7f848041
+Ref: S0103\7f848041
+Ref: 2613\7f848060
+Ref: 2614\7f851086
+Ref: 2615\7f851086
+Ref: 2616\7f854056
+Ref: 2617\7f854056
+Ref: 2618\7f856022
+Ref: 2619\7f857274
+Node: 4.1.5\7f859923
+Ref: 2620\7f860379
+Ref: 2621\7f860379
+Ref: 2622\7f860608
+Ref: 2623\7f860662
+Ref: 2624\7f860794
+Ref: 2625\7f861234
+Ref: S0104\7f861234
+Ref: 2626\7f861261
+Ref: 2627\7f861467
+Ref: 2628\7f862372
+Ref: 2629\7f862590
+Ref: 2630\7f862592
+Ref: 2631\7f862682
+Ref: 2632\7f863958
+Node: 4.1.6\7f864041
+Ref: 2633\7f864777
+Ref: 2634\7f864777
+Ref: 2635\7f865539
+Ref: 2636\7f865539
+Ref: 2637\7f866678
+Ref: 2638\7f866754
+Ref: 2639\7f867424
+Ref: 2640\7f868176
+Ref: S0105\7f868176
+Ref: 2641\7f868208
+Ref: 2642\7f868215
+Ref: 2643\7f868466
+Ref: 2644\7f868751
+Ref: 2645\7f868751
+Ref: 2646\7f869559
+Ref: 2647\7f869559
+Ref: 2648\7f871384
+Node: 4.2\7f871500
+Ref: 2649\7f871597
+Ref: 2650\7f871788
+Ref: 2651\7f872250
+Ref: 2652\7f872250
+Ref: 2653\7f872959
+Ref: 2654\7f873742
+Ref: 2655\7f873742
+Ref: 2656\7f873742
+Ref: 2657\7f873793
+Ref: 2658\7f873793
+Ref: 2659\7f873793
+Ref: 2660\7f873793
+Ref: 2661\7f873885
+Ref: 2662\7f874300
+Ref: 2663\7f874300
+Ref: 2664\7f874610
+Ref: 2665\7f875576
+Ref: 2666\7f875934
+Ref: 2667\7f876662
+Node: 4.3\7f876803
+Ref: 2668\7f876904
+Ref: 2669\7f877019
+Ref: 2670\7f877080
+Ref: S0106\7f877080
+Ref: 2671\7f877084
+Ref: 2672\7f877104
+Ref: 2673\7f877126
+Ref: 2674\7f877230
+Ref: 2675\7f878853
+Ref: 2676\7f879142
+Ref: 2677\7f879213
+Ref: 2678\7f880316
+Ref: 2679\7f880316
+Ref: 2680\7f880425
+Ref: 2681\7f880930
+Ref: 2682\7f881519
+Ref: 2683\7f882618
+Node: 4.3.1\7f882775
+Ref: 2684\7f883108
+Ref: S0107\7f883108
+Ref: 2685\7f883114
+Ref: 2686\7f883190
+Ref: S0108\7f883190
+Ref: 2687\7f883204
+Ref: 2688\7f883236
+Ref: 2689\7f883354
+Ref: S0109\7f883354
+Ref: 2690\7f883369
+Ref: 2691\7f883395
+Ref: 2692\7f883416
+Ref: 2693\7f883473
+Ref: S0110\7f883473
+Ref: 2694\7f883498
+Ref: 2695\7f883525
+Ref: 2696\7f883560
+Ref: 2697\7f883690
+Ref: 2698\7f885277
+Ref: 2699\7f885625
+Ref: 2700\7f887159
+Ref: 2701\7f887295
+Ref: 2702\7f892914
+Ref: 2703\7f893046
+Ref: 2704\7f893327
+Ref: 2705\7f893707
+Ref: 2706\7f896448
+Ref: 2707\7f896991
+Ref: 2708\7f897434
+Ref: 2709\7f898010
+Node: 4.3.2\7f898592
+Ref: 2710\7f899471
+Ref: S0111\7f899471
+Ref: 2711\7f899486
+Ref: 2712\7f899505
+Ref: 2713\7f899561
+Ref: S0112\7f899561
+Ref: 2714\7f899565
+Ref: 2715\7f899579
+Ref: 2716\7f899674
+Ref: 2717\7f899770
+Ref: 2718\7f901293
+Ref: 2719\7f903179
+Ref: 2720\7f903663
+Ref: 2721\7f904276
+Ref: 2722\7f904306
+Ref: 2723\7f904307
+Ref: 2724\7f904745
+Ref: 2725\7f906304
+Ref: 2726\7f906452
+Ref: 2727\7f907164
+Ref: 2728\7f908145
+Node: 4.3.3\7f909028
+Ref: 2729\7f909934
+Ref: S0113\7f909934
+Ref: 2730\7f909946
+Ref: 2731\7f909975
+Ref: 2732\7f910062
+Ref: S0114\7f910062
+Ref: 2733\7f910077
+Ref: 2734\7f910089
+Ref: 2735\7f910103
+Ref: 2736\7f910126
+Ref: 2737\7f910140
+Ref: 2738\7f910163
+Ref: 2739\7f910185
+Ref: 2740\7f910199
+Ref: 2741\7f910255
+Ref: S0115\7f910255
+Ref: 2742\7f910270
+Ref: 2743\7f910301
+Ref: 2744\7f910397
+Ref: S0116\7f910397
+Ref: 2745\7f910411
+Ref: 2746\7f910435
+Ref: 2747\7f910455
+Ref: 2748\7f910485
+Ref: 2749\7f910633
+Ref: 2750\7f910824
+Ref: 2751\7f911395
+Ref: 2752\7f911688
+Ref: 2753\7f911788
+Ref: 2754\7f912243
+Ref: 2755\7f912380
+Ref: 2756\7f913106
+Ref: 2757\7f918015
+Ref: 2758\7f918267
+Ref: 2759\7f918267
+Ref: 2760\7f918535
+Ref: 2761\7f918537
+Ref: 2762\7f919607
+Ref: 2763\7f920728
+Ref: 2764\7f920728
+Ref: 2765\7f921295
+Ref: 2766\7f921296
+Ref: 2767\7f921973
+Ref: 2768\7f921973
+Ref: 2769\7f922378
+Ref: 2770\7f924609
+Ref: 2771\7f925341
+Ref: 2772\7f926979
+Ref: 2773\7f927768
+Node: 4.4\7f928406
+Ref: 2774\7f928584
+Ref: 2775\7f928953
+Ref: 2776\7f928955
+Ref: 2777\7f928955
+Ref: 2778\7f928955
+Ref: 2779\7f928955
+Ref: 2780\7f928955
+Ref: 2781\7f928955
+Ref: 2782\7f928955
+Ref: 2783\7f928955
+Ref: 2784\7f928955
+Ref: 2785\7f928955
+Ref: 2786\7f928955
+Ref: 2787\7f928955
+Ref: 2788\7f928955
+Ref: 2789\7f928955
+Ref: 2790\7f928955
+Ref: 2791\7f928955
+Ref: 2792\7f928955
+Ref: 2793\7f928955
+Ref: 2794\7f928955
+Ref: 2795\7f928955
+Ref: 2796\7f928955
+Ref: 2797\7f928955
+Ref: 2798\7f928955
+Ref: 2799\7f928955
+Ref: 2800\7f928955
+Ref: 2801\7f928955
+Ref: 2802\7f928955
+Ref: 2803\7f928955
+Ref: 2804\7f928955
+Ref: 2805\7f928955
+Ref: 2806\7f928955
+Ref: 2807\7f928955
+Ref: 2808\7f928955
+Ref: 2809\7f928955
+Ref: 2810\7f928955
+Ref: 2811\7f928955
+Ref: 2812\7f928955
+Ref: 2813\7f928955
+Ref: 2814\7f928955
+Ref: 2815\7f928955
+Ref: 2816\7f928955
+Ref: 2817\7f928955
+Ref: 2818\7f928955
+Ref: 2819\7f928955
+Ref: 2820\7f928955
+Ref: 2821\7f928955
+Ref: 2822\7f928955
+Ref: 2823\7f928955
+Ref: 2824\7f928955
+Ref: 2825\7f928955
+Ref: 2826\7f928955
+Ref: 2827\7f928955
+Ref: 2828\7f928955
+Ref: 2829\7f928955
+Ref: 2830\7f928955
+Ref: 2831\7f928955
+Ref: 2832\7f928955
+Ref: 2833\7f928955
+Ref: 2834\7f928955
+Ref: 2835\7f928955
+Ref: 2836\7f928955
+Ref: 2837\7f928955
+Ref: 2838\7f928955
+Ref: 2839\7f928955
+Ref: 2840\7f928955
+Ref: 2841\7f928955
+Ref: 2842\7f928955
+Ref: 2843\7f928955
+Ref: 2844\7f928955
+Ref: 2845\7f928955
+Ref: 2846\7f928955
+Ref: 2847\7f929015
+Ref: S0117\7f929015
+Ref: 2848\7f929030
+Ref: 2849\7f929044
+Ref: 2850\7f929059
+Ref: 2851\7f929078
+Ref: 2852\7f929098
+Ref: 2853\7f929111
+Ref: 2854\7f929126
+Ref: 2855\7f929144
+Ref: 2856\7f929164
+Ref: 2857\7f929178
+Ref: 2858\7f929242
+Ref: S0118\7f929242
+Ref: 2859\7f929257
+Ref: 2860\7f929278
+Ref: 2861\7f929305
+Ref: 2862\7f929325
+Ref: 2863\7f929352
+Ref: 2864\7f929373
+Ref: 2865\7f929400
+Ref: 2866\7f929426
+Ref: 2867\7f929453
+Ref: 2868\7f929478
+Ref: 2869\7f929547
+Ref: S0119\7f929547
+Ref: 2870\7f929562
+Ref: 2871\7f929581
+Ref: 2872\7f929601
+Ref: 2873\7f929663
+Ref: S0120\7f929663
+Ref: 2874\7f929678
+Ref: 2875\7f929697
+Ref: 2876\7f929717
+Ref: 2877\7f929746
+Ref: 2878\7f929773
+Ref: 2879\7f929855
+Ref: S0121\7f929855
+Ref: 2880\7f929859
+Ref: 2881\7f929886
+Ref: 2882\7f929959
+Ref: S0122\7f929959
+Ref: 2883\7f929963
+Ref: 2884\7f929984
+Ref: 2885\7f929998
+Ref: 2886\7f930036
+Ref: S0123\7f930036
+Ref: 2887\7f930042
+Ref: 2888\7f930065
+Ref: 2889\7f930071
+Ref: 2890\7f930100
+Ref: 2891\7f930118
+Ref: S0124\7f930118
+Ref: 2892\7f930122
+Ref: 2893\7f930131
+Ref: 2894\7f930152
+Ref: 2895\7f930174
+Ref: S0125\7f930174
+Ref: 2896\7f930178
+Ref: 2897\7f930191
+Ref: 2898\7f930206
+Ref: 2899\7f930220
+Ref: 2900\7f930325
+Ref: S0126\7f930325
+Ref: 2901\7f930338
+Ref: 2902\7f930363
+Ref: 2903\7f930380
+Ref: 2904\7f930398
+Ref: 2905\7f930405
+Ref: 2906\7f930418
+Ref: 2907\7f930439
+Ref: 2908\7f930466
+Ref: 2909\7f931653
+Ref: 2910\7f931793
+Ref: 2911\7f931793
+Ref: 2912\7f931793
+Ref: 2913\7f934564
+Node: 4.5\7f936134
+Ref: 2914\7f936285
+Ref: 2915\7f936285
+Ref: 2916\7f936653
+Ref: S0127\7f936653
+Ref: 2917\7f936705
+Ref: S0128\7f936705
+Ref: 2918\7f936774
+Ref: S0129\7f936774
+Ref: 2919\7f936826
+Ref: S0130\7f936826
+Ref: 2920\7f936871
+Ref: S0131\7f936871
+Ref: 2921\7f936937
+Ref: S0132\7f936937
+Ref: 2922\7f937935
+Ref: 2923\7f937935
+Ref: 2924\7f938092
+Ref: 2925\7f938094
+Ref: 2926\7f938094
+Ref: 2927\7f938094
+Ref: 2928\7f938661
+Ref: 2929\7f939244
+Ref: 2930\7f939441
+Node: 4.5.1\7f942218
+Ref: 2931\7f942443
+Ref: 2932\7f942443
+Ref: 2933\7f942443
+Ref: 2934\7f942590
+Ref: 2935\7f943015
+Ref: 2936\7f943015
+Ref: 2937\7f943015
+Ref: 2938\7f943015
+Ref: 2939\7f943015
+Ref: 2940\7f943015
+Ref: 2941\7f943015
+Ref: 2942\7f943015
+Ref: 2943\7f943196
+Ref: 2944\7f943879
+Ref: 2945\7f945941
+Ref: 2946\7f946244
+Ref: 2947\7f946244
+Ref: 2948\7f946408
+Ref: 2949\7f946410
+Ref: 2950\7f946499
+Node: 4.5.2\7f947415
+Ref: 2951\7f947590
+Ref: 2952\7f947590
+Ref: 2953\7f947590
+Ref: 2954\7f947591
+Ref: 2955\7f947591
+Ref: 2956\7f947681
+Ref: 2957\7f947683
+Ref: 2958\7f947830
+Ref: 2959\7f947832
+Ref: 2960\7f947832
+Ref: 2961\7f947832
+Ref: 2962\7f947832
+Ref: 2963\7f947832
+Ref: 2964\7f947832
+Ref: 2965\7f947832
+Ref: 2966\7f947832
+Ref: 2967\7f947832
+Ref: 2968\7f947832
+Ref: 2969\7f947832
+Ref: 2970\7f947832
+Ref: 2971\7f947832
+Ref: 2972\7f947832
+Ref: 2973\7f947832
+Ref: 2974\7f947832
+Ref: 2975\7f947832
+Ref: 2976\7f947832
+Ref: 2977\7f947832
+Ref: 2978\7f947832
+Ref: 2979\7f947832
+Ref: 2980\7f947832
+Ref: 2981\7f947832
+Ref: 2982\7f947832
+Ref: 2983\7f948187
+Ref: 2984\7f948188
+Ref: 2985\7f948188
+Ref: 2986\7f948636
+Ref: 2987\7f948637
+Ref: 2988\7f956231
+Ref: 2989\7f957757
+Ref: 2990\7f958158
+Ref: 2991\7f960479
+Ref: 2992\7f965747
+Ref: 2993\7f966149
+Ref: 2994\7f966960
+Ref: 2995\7f966991
+Ref: 2996\7f967272
+Ref: 2997\7f968818
+Ref: 2998\7f973490
+Ref: 2999\7f974540
+Ref: 3000\7f975394
+Ref: 3001\7f976430
+Ref: 3002\7f976806
+Node: 4.5.3\7f977552
+Ref: 3003\7f977736
+Ref: 3004\7f977736
+Ref: 3005\7f977736
+Ref: 3006\7f977736
+Ref: 3007\7f977736
+Ref: 3008\7f977736
+Ref: 3009\7f977736
+Ref: 3010\7f977736
+Ref: 3011\7f977736
+Ref: 3012\7f977736
+Ref: 3013\7f978014
+Ref: 3014\7f978014
+Ref: 3015\7f978014
+Ref: 3016\7f978014
+Ref: 3017\7f978014
+Ref: 3018\7f978014
+Ref: 3019\7f978014
+Ref: 3020\7f978418
+Ref: 3021\7f979469
+Ref: 3022\7f979471
+Ref: 3023\7f979620
+Ref: 3024\7f979987
+Ref: 3025\7f980270
+Ref: 3026\7f982010
+Ref: 3027\7f982753
+Node: 4.5.4\7f983089
+Ref: 3028\7f983271
+Ref: 3029\7f983271
+Ref: 3030\7f983271
+Ref: 3031\7f983271
+Ref: 3032\7f983271
+Ref: 3033\7f983271
+Ref: 3034\7f983271
+Ref: 3035\7f983271
+Ref: 3036\7f983271
+Ref: 3037\7f983271
+Node: 4.5.5\7f983773
+Ref: 3038\7f983953
+Ref: 3039\7f983953
+Ref: 3040\7f983953
+Ref: 3041\7f983953
+Ref: 3042\7f983953
+Ref: 3043\7f983953
+Ref: 3044\7f983953
+Ref: 3045\7f983953
+Ref: 3046\7f983953
+Ref: 3047\7f983953
+Ref: 3048\7f983953
+Ref: 3049\7f983953
+Ref: 3050\7f983953
+Ref: 3051\7f983953
+Ref: 3052\7f983953
+Ref: 3053\7f983953
+Ref: 3054\7f990755
+Ref: 3055\7f990763
+Ref: 3056\7f990763
+Ref: 3057\7f990763
+Ref: 3058\7f993751
+Ref: 3059\7f994263
+Ref: 3060\7f995147
+Node: 4.5.6\7f996445
+Ref: 3061\7f996639
+Ref: 3062\7f996639
+Ref: 3063\7f996639
+Ref: 3064\7f996639
+Ref: 3065\7f996639
+Ref: 3066\7f996827
+Ref: 3067\7f996827
+Ref: 3068\7f996827
+Ref: 3069\7f997705
+Ref: 3070\7f997707
+Ref: 3071\7f997707
+Ref: 3072\7f997952
+Ref: 3073\7f997952
+Ref: 3074\7f997952
+Ref: 3075\7f997952
+Ref: 3076\7f998418
+Ref: 3077\7f999225
+Ref: 3078\7f999621
+Ref: 3079\7f999621
+Ref: 3080\7f999764
+Ref: 3081\7f999935
+Node: 4.5.7\7f1000904
+Ref: 3082\7f1002495
+Ref: S0133\7f1002495
+Ref: 3083\7f1002499
+Ref: 3084\7f1002516
+Ref: 3085\7f1002611
+Ref: S0134\7f1002611
+Ref: 3086\7f1002628
+Ref: 3087\7f1002653
+Ref: 3088\7f1002679
+Ref: 3089\7f1002704
+Ref: 3090\7f1002740
+Ref: 3091\7f1002796
+Ref: S0135\7f1002796
+Ref: 3092\7f1002809
+Ref: 3093\7f1002870
+Ref: S0136\7f1002870
+Ref: 3094\7f1002899
+Ref: 3095\7f1002922
+Ref: 3096\7f1002962
+Ref: 3097\7f1003053
+Ref: S0137\7f1003053
+Ref: 3098\7f1003072
+Ref: 3099\7f1003119
+Ref: 3100\7f1006632
+Ref: 3101\7f1008064
+Ref: 3102\7f1008264
+Ref: 3103\7f1008264
+Ref: 3104\7f1008266
+Ref: 3105\7f1010820
+Ref: 3106\7f1011430
+Ref: 3107\7f1011430
+Ref: 3108\7f1011430
+Ref: 3109\7f1011570
+Ref: 3110\7f1011662
+Node: 4.5.8\7f1011719
+Ref: 3111\7f1011935
+Ref: S0138\7f1011935
+Ref: 3112\7f1011944
+Ref: 3113\7f1011955
+Ref: 3114\7f1011993
+Ref: 3115\7f1012016
+Ref: 3116\7f1012027
+Ref: 3117\7f1012053
+Ref: 3118\7f1012083
+Ref: S0139\7f1012083
+Ref: 3119\7f1012118
+Ref: S0140\7f1012118
+Ref: 3120\7f1012131
+Ref: 3121\7f1012887
+Ref: 3122\7f1013031
+Ref: 3123\7f1013496
+Ref: 3124\7f1015174
+Node: 4.6\7f1015208
+Ref: 3125\7f1015639
+Ref: 3126\7f1015641
+Ref: 3127\7f1015641
+Ref: 3128\7f1015641
+Ref: 3129\7f1015642
+Ref: 3130\7f1015642
+Ref: 3131\7f1015707
+Ref: S0141\7f1015707
+Ref: 3132\7f1015721
+Ref: 3133\7f1015734
+Ref: 3134\7f1015755
+Ref: 3135\7f1015768
+Ref: 3136\7f1015777
+Ref: 3137\7f1015860
+Ref: 3138\7f1015944
+Ref: 3139\7f1016004
+Ref: 3140\7f1016565
+Ref: 3141\7f1016566
+Ref: 3142\7f1016776
+Ref: 3143\7f1016777
+Ref: 3144\7f1016829
+Ref: 3145\7f1017659
+Ref: 3146\7f1019705
+Ref: 3147\7f1019706
+Ref: 3148\7f1019955
+Ref: 3149\7f1019956
+Ref: 3150\7f1022117
+Ref: 3151\7f1022118
+Ref: 3152\7f1022249
+Ref: 3153\7f1022250
+Ref: 3154\7f1022575
+Ref: 3155\7f1022690
+Ref: 3156\7f1022949
+Ref: 3157\7f1025399
+Ref: 3158\7f1025400
+Ref: 3159\7f1026592
+Ref: 3160\7f1026936
+Ref: 3161\7f1028872
+Ref: 3162\7f1029332
+Ref: 3163\7f1030082
+Ref: 3164\7f1030083
+Ref: 3165\7f1030665
+Ref: 3166\7f1030666
+Ref: 3167\7f1031013
+Ref: 3168\7f1031068
+Ref: 3169\7f1031203
+Ref: 3170\7f1032599
+Ref: 3171\7f1032714
+Ref: 3172\7f1032714
+Ref: 3173\7f1032714
+Ref: 3174\7f1032907
+Ref: 3175\7f1032909
+Ref: 3176\7f1032909
+Ref: 3177\7f1033186
+Ref: 3178\7f1033186
+Ref: 3179\7f1033700
+Ref: 3180\7f1035632
+Ref: 3181\7f1035632
+Ref: 3182\7f1035806
+Ref: 3183\7f1035806
+Ref: 3184\7f1035847
+Ref: 3185\7f1035847
+Ref: 3186\7f1036194
+Ref: 3187\7f1036194
+Ref: 3188\7f1036443
+Ref: 3189\7f1037253
+Ref: 3190\7f1037255
+Ref: 3191\7f1037460
+Ref: 3192\7f1037460
+Ref: 3193\7f1037810
+Ref: 3194\7f1037812
+Ref: 3195\7f1038564
+Ref: 3196\7f1038565
+Ref: 3197\7f1039460
+Ref: 3198\7f1039460
+Ref: 3199\7f1039783
+Ref: 3200\7f1039783
+Ref: 3201\7f1039899
+Ref: 3202\7f1039899
+Ref: 3203\7f1040657
+Ref: 3204\7f1040659
+Ref: 3205\7f1042075
+Ref: 3206\7f1042076
+Ref: 3207\7f1042076
+Ref: 3208\7f1042076
+Ref: 3209\7f1042076
+Ref: 3210\7f1042076
+Ref: 3211\7f1042076
+Ref: 3212\7f1042076
+Ref: 3213\7f1042480
+Ref: 3214\7f1042480
+Ref: 3215\7f1042930
+Ref: 3216\7f1043096
+Ref: 3217\7f1043097
+Ref: 3218\7f1043097
+Ref: 3219\7f1043097
+Ref: 3220\7f1043097
+Ref: 3221\7f1043097
+Ref: 3222\7f1044157
+Ref: 3223\7f1044627
+Ref: 3224\7f1044779
+Ref: 3225\7f1044780
+Ref: 3226\7f1044780
+Ref: 3227\7f1045670
+Ref: 3228\7f1046241
+Ref: 3229\7f1046246
+Ref: 3230\7f1048251
+Ref: 3231\7f1048944
+Ref: 3232\7f1051312
+Ref: 3233\7f1052596
+Ref: 3234\7f1055703
+Node: 4.7\7f1056584
+Ref: 3235\7f1056854
+Ref: 3236\7f1056927
+Ref: S0142\7f1056927
+Ref: 3237\7f1056940
+Ref: 3238\7f1056954
+Ref: 3239\7f1056968
+Ref: 3240\7f1056981
+Ref: 3241\7f1057043
+Ref: 3242\7f1057633
+Ref: 3243\7f1057633
+Ref: 3244\7f1057633
+Ref: 3245\7f1057633
+Ref: 3246\7f1057633
+Ref: 3247\7f1057633
+Ref: 3248\7f1057633
+Ref: 3249\7f1057858
+Ref: 3250\7f1057860
+Node: 4.8\7f1059662
+Ref: 3251\7f1059866
+Ref: 3252\7f1059868
+Ref: 3253\7f1059868
+Ref: 3254\7f1059955
+Ref: S0143\7f1059955
+Ref: 3255\7f1059973
+Ref: 3256\7f1059996
+Ref: 3257\7f1060028
+Ref: 3258\7f1060051
+Ref: 3259\7f1060130
+Ref: S0144\7f1060130
+Ref: 3260\7f1060151
+Ref: 3261\7f1060789
+Ref: 3262\7f1061319
+Ref: 3263\7f1061746
+Ref: 3264\7f1061815
+Ref: 3265\7f1062113
+Ref: 3266\7f1066507
+Ref: 3267\7f1067367
+Ref: 3268\7f1068690
+Ref: 3269\7f1068801
+Ref: 3270\7f1068803
+Ref: 3271\7f1068955
+Ref: 3272\7f1069035
+Ref: 3273\7f1069192
+Ref: 3274\7f1069730
+Ref: 3275\7f1069732
+Ref: 3276\7f1069732
+Ref: 3277\7f1069732
+Ref: 3278\7f1069821
+Ref: 3279\7f1069966
+Ref: 3280\7f1070871
+Ref: 3281\7f1070871
+Ref: 3282\7f1070871
+Ref: 3283\7f1072784
+Ref: 3284\7f1072784
+Ref: 3285\7f1072784
+Ref: 3286\7f1073912
+Ref: 3287\7f1073912
+Ref: 3288\7f1073912
+Ref: 3289\7f1074364
+Ref: 3290\7f1074364
+Ref: 3291\7f1074364
+Ref: 3292\7f1074364
+Ref: 3293\7f1074364
+Ref: 3294\7f1074366
+Ref: 3295\7f1075344
+Ref: 3296\7f1076115
+Ref: 3297\7f1077843
+Ref: 3298\7f1078178
+Ref: 3299\7f1079027
+Ref: 3300\7f1079737
+Ref: 3301\7f1080122
+Ref: 3302\7f1081985
+Ref: 3303\7f1082761
+Node: 4.9\7f1083597
+Ref: 3304\7f1083951
+Ref: 3305\7f1084060
+Ref: 3306\7f1084912
+Ref: 3307\7f1088216
+Ref: 3308\7f1088715
+Ref: 3309\7f1089263
+Ref: 3310\7f1089912
+Ref: 3311\7f1091353
+Ref: 3312\7f1091506
+Ref: 3313\7f1091839
+Ref: 3314\7f1091918
+Ref: 3315\7f1092137
+Ref: 3316\7f1093711
+Ref: 3317\7f1093830
+Ref: 3318\7f1093830
+Ref: 3319\7f1093830
+Ref: 3320\7f1093933
+Ref: 3321\7f1094077
+Ref: 3322\7f1094361
+Ref: 3323\7f1094709
+Ref: 3324\7f1098778
+Ref: 3325\7f1104866
+Ref: 3326\7f1107630
+Ref: 3327\7f1109441
+Node: 4.9.1\7f1111796
+Ref: 3328\7f1112024
+Ref: 3329\7f1112648
+Ref: 3330\7f1113787
+Ref: 3331\7f1114251
+Ref: 3332\7f1114440
+Ref: 3333\7f1115086
+Ref: 3334\7f1116532
+Node: 5\7f1117151
+Node: 5.1\7f1118721
+Ref: 3335\7f1119175
+Ref: S0145\7f1119175
+Ref: 3336\7f1119179
+Ref: 3337\7f1119191
+Ref: 3338\7f1119209
+Ref: 3339\7f1119233
+Ref: S0146\7f1119233
+Ref: 3340\7f1119247
+Ref: 3341\7f1119254
+Ref: 3342\7f1119274
+Ref: 3343\7f1119281
+Ref: 3344\7f1119355
+Ref: S0147\7f1119355
+Ref: 3345\7f1119359
+Ref: 3346\7f1119385
+Ref: 3347\7f1119410
+Ref: 3348\7f1119435
+Ref: 3349\7f1119454
+Ref: 3350\7f1119489
+Ref: 3351\7f1119517
+Ref: 3352\7f1119548
+Ref: 3353\7f1119570
+Ref: 3354\7f1119596
+Ref: 3355\7f1119616
+Ref: 3356\7f1119642
+Ref: 3357\7f1119714
+Ref: S0148\7f1119714
+Ref: 3358\7f1119729
+Ref: 3359\7f1119746
+Ref: 3360\7f1119771
+Ref: 3361\7f1119790
+Ref: 3362\7f1119816
+Ref: 3363\7f1119852
+Ref: 3364\7f1119873
+Ref: 3365\7f1119912
+Ref: S0149\7f1119912
+Ref: 3366\7f1119936
+Ref: S0150\7f1119936
+Ref: 3367\7f1119949
+Ref: 3368\7f1120000
+Ref: S0151\7f1120000
+Ref: 3369\7f1120004
+Ref: 3370\7f1123807
+Ref: 3371\7f1123890
+Ref: 3372\7f1124381
+Ref: 3373\7f1126853
+Ref: 3374\7f1127440
+Ref: 3375\7f1127624
+Node: 5.2\7f1127803
+Ref: 3376\7f1128106
+Ref: S0152\7f1128106
+Ref: 3377\7f1128128
+Ref: 3378\7f1128136
+Ref: 3379\7f1128300
+Ref: 3380\7f1128302
+Ref: 3381\7f1128490
+Ref: 3382\7f1128492
+Ref: 3383\7f1129567
+Ref: 3384\7f1129643
+Ref: 3385\7f1131416
+Ref: 3386\7f1131541
+Ref: 3387\7f1131876
+Ref: 3388\7f1132145
+Ref: 3389\7f1132145
+Ref: 3390\7f1132145
+Ref: 3391\7f1132486
+Ref: 3392\7f1133177
+Ref: 3393\7f1133177
+Ref: 3394\7f1133724
+Ref: 3395\7f1136239
+Ref: 3396\7f1137299
+Node: 5.3\7f1138395
+Ref: 3397\7f1138727
+Ref: S0153\7f1138727
+Ref: 3398\7f1138744
+Ref: 3399\7f1138770
+Ref: 3400\7f1138808
+Ref: 3401\7f1138834
+Ref: 3402\7f1138883
+Ref: 3403\7f1139034
+Node: 5.4\7f1140307
+Ref: 3404\7f1140669
+Ref: S0154\7f1140669
+Ref: 3405\7f1140697
+Ref: 3406\7f1140723
+Ref: 3407\7f1140762
+Ref: 3408\7f1140842
+Ref: S0155\7f1140842
+Ref: 3409\7f1140860
+Ref: 3410\7f1140895
+Ref: 3411\7f1140996
+Ref: 3412\7f1140997
+Ref: 3413\7f1141061
+Ref: 3414\7f1146179
+Ref: 3415\7f1146541
+Ref: 3416\7f1146541
+Ref: 3417\7f1146541
+Ref: 3418\7f1147917
+Ref: 3419\7f1149025
+Node: 5.5\7f1151999
+Ref: 3420\7f1152280
+Ref: S0156\7f1152280
+Ref: 3421\7f1152299
+Ref: 3422\7f1152334
+Ref: 3423\7f1152371
+Ref: 3424\7f1152421
+Ref: 3425\7f1152485
+Ref: S0157\7f1152485
+Ref: 3426\7f1152496
+Ref: 3427\7f1152520
+Ref: 3428\7f1152563
+Ref: 3429\7f1152622
+Ref: S0158\7f1152622
+Ref: 3430\7f1152635
+Ref: 3431\7f1152668
+Ref: 3432\7f1152938
+Ref: 3433\7f1153081
+Ref: 3434\7f1153131
+Ref: 3435\7f1153448
+Ref: 3436\7f1153849
+Ref: 3437\7f1153850
+Ref: 3438\7f1154594
+Node: 5.5.1\7f1158768
+Ref: 3439\7f1159041
+Ref: 3440\7f1159246
+Ref: 3441\7f1159302
+Ref: 3442\7f1159380
+Ref: 3443\7f1159488
+Ref: 3444\7f1159568
+Ref: 3445\7f1159648
+Ref: 3446\7f1159933
+Ref: 3447\7f1160067
+Ref: 3448\7f1160121
+Ref: 3449\7f1160195
+Ref: 3450\7f1160333
+Ref: 3451\7f1161065
+Ref: 3452\7f1161138
+Ref: 3453\7f1161267
+Ref: 3454\7f1161267
+Ref: 3455\7f1161267
+Ref: 3456\7f1161532
+Ref: 3457\7f1161532
+Ref: 3458\7f1161532
+Ref: 3459\7f1161908
+Ref: 3460\7f1162041
+Ref: 3461\7f1162115
+Ref: 3462\7f1162209
+Ref: 3463\7f1163162
+Ref: 3464\7f1164304
+Ref: 3465\7f1164396
+Node: 5.5.2\7f1164457
+Ref: 3466\7f1164821
+Ref: S0159\7f1164821
+Ref: 3467\7f1164835
+Ref: 3468\7f1164877
+Ref: 3469\7f1164891
+Ref: 3470\7f1164914
+Ref: 3471\7f1164962
+Ref: 3472\7f1165147
+Ref: 3473\7f1165147
+Ref: 3474\7f1165209
+Ref: 3475\7f1165338
+Ref: 3476\7f1165451
+Ref: 3477\7f1165451
+Ref: 3478\7f1165504
+Ref: 3479\7f1165504
+Ref: 3480\7f1165932
+Ref: 3481\7f1165932
+Ref: 3482\7f1165968
+Ref: 3483\7f1165968
+Ref: 3484\7f1166949
+Ref: 3485\7f1168481
+Ref: 3486\7f1169445
+Ref: 3487\7f1169708
+Ref: 3488\7f1170626
+Ref: 3489\7f1170796
+Ref: 3490\7f1170867
+Ref: 3491\7f1172660
+Node: 5.6\7f1172717
+Ref: 3492\7f1172998
+Ref: S0160\7f1172998
+Ref: 3493\7f1173018
+Ref: 3494\7f1173079
+Ref: 3495\7f1173133
+Ref: 3496\7f1173188
+Ref: 3497\7f1173701
+Node: 5.7\7f1174763
+Ref: 3498\7f1175096
+Ref: S0161\7f1175096
+Ref: 3499\7f1175120
+Ref: 3500\7f1175132
+Ref: 3501\7f1175330
+Ref: 3502\7f1176117
+Node: 5.8\7f1176972
+Ref: 3503\7f1177256
+Ref: S0162\7f1177256
+Ref: 3504\7f1177272
+Ref: 3505\7f1177330
+Ref: 3506\7f1178067
+Node: 6\7f1178943
+Ref: 3507\7f1179037
+Ref: 3508\7f1179037
+Ref: 3509\7f1179037
+Ref: 3510\7f1180307
+Ref: 3511\7f1180367
+Ref: 3512\7f1180450
+Node: 6.1\7f1181162
+Ref: 3513\7f1181469
+Ref: S0163\7f1181469
+Ref: 3514\7f1181484
+Ref: 3515\7f1181515
+Ref: 3516\7f1181554
+Ref: 3517\7f1181706
+Ref: S0164\7f1181706
+Ref: 3518\7f1181720
+Ref: 3519\7f1181753
+Ref: 3520\7f1181840
+Ref: S0165\7f1181840
+Ref: 3521\7f1181855
+Ref: 3522\7f1181888
+Ref: 3523\7f1181969
+Ref: S0166\7f1181969
+Ref: 3524\7f1181983
+Ref: 3525\7f1182009
+Ref: 3526\7f1182056
+Ref: S0167\7f1182056
+Ref: 3527\7f1182062
+Ref: 3528\7f1182082
+Ref: 3529\7f1182095
+Ref: 3530\7f1182138
+Ref: S0168\7f1182138
+Ref: 3531\7f1182142
+Ref: 3532\7f1182172
+Ref: 3533\7f1182237
+Ref: S0169\7f1182237
+Ref: 3534\7f1182243
+Ref: 3535\7f1182263
+Ref: 3536\7f1182413
+Ref: S0170\7f1182413
+Ref: 3537\7f1182417
+Ref: 3538\7f1183241
+Ref: S0171\7f1183241
+Ref: 3539\7f1183245
+Ref: 3540\7f1183288
+Ref: S0172\7f1183288
+Ref: 3541\7f1183294
+Ref: 3542\7f1183409
+Ref: S0173\7f1183409
+Ref: 3543\7f1183424
+Ref: 3544\7f1183445
+Ref: 3545\7f1183461
+Ref: 3546\7f1183484
+Ref: 3547\7f1183504
+Ref: 3548\7f1183542
+Ref: S0174\7f1183542
+Ref: 3549\7f1183556
+Ref: 3550\7f1183583
+Ref: 3551\7f1183702
+Ref: S0175\7f1183702
+Ref: 3552\7f1183716
+Ref: 3553\7f1183753
+Ref: 3554\7f1183759
+Ref: 3555\7f1183775
+Ref: 3556\7f1183798
+Ref: 3557\7f1183827
+Ref: 3558\7f1183854
+Ref: 3559\7f1183876
+Ref: 3560\7f1183915
+Ref: S0176\7f1183915
+Ref: 3561\7f1183993
+Ref: 3562\7f1184186
+Ref: 3563\7f1184298
+Ref: 3564\7f1184376
+Ref: 3565\7f1184859
+Ref: 3566\7f1184860
+Ref: 3567\7f1186512
+Ref: 3568\7f1187201
+Ref: 3569\7f1187586
+Ref: 3570\7f1187621
+Ref: 3571\7f1187622
+Ref: 3572\7f1187834
+Ref: 3573\7f1187914
+Ref: 3574\7f1188528
+Ref: 3575\7f1189483
+Ref: 3576\7f1190454
+Ref: 3577\7f1192229
+Ref: 3578\7f1193434
+Ref: 3579\7f1194866
+Node: 6.1.1\7f1195537
+Ref: 3580\7f1196056
+Ref: 3581\7f1196056
+Ref: 3582\7f1196219
+Ref: 3583\7f1196219
+Ref: 3584\7f1197035
+Ref: 3585\7f1197035
+Ref: 3586\7f1197264
+Ref: 3587\7f1197264
+Ref: 3588\7f1198265
+Ref: 3589\7f1198265
+Ref: 3590\7f1198429
+Ref: 3591\7f1198429
+Ref: 3592\7f1198837
+Ref: 3593\7f1198837
+Ref: 3594\7f1198988
+Ref: 3595\7f1198988
+Ref: 3596\7f1199259
+Ref: 3597\7f1199259
+Ref: 3598\7f1201442
+Ref: 3599\7f1205605
+Ref: 3600\7f1205605
+Ref: 3601\7f1205997
+Ref: 3602\7f1206409
+Ref: 3603\7f1206424
+Ref: 3604\7f1207117
+Ref: 3605\7f1212584
+Ref: 3606\7f1212599
+Ref: 3607\7f1214091
+Ref: 3608\7f1214091
+Ref: 3609\7f1214091
+Ref: 3610\7f1214390
+Ref: 3611\7f1214390
+Ref: 3612\7f1214390
+Ref: 3613\7f1215588
+Ref: 3614\7f1215588
+Ref: 3615\7f1216933
+Ref: 3616\7f1216933
+Ref: 3617\7f1216933
+Ref: 3618\7f1216933
+Ref: 3619\7f1216933
+Ref: 3620\7f1222850
+Node: 6.2\7f1222882
+Ref: 3621\7f1223139
+Ref: 3622\7f1223139
+Ref: 3623\7f1223139
+Ref: 3624\7f1223139
+Ref: 3625\7f1223139
+Ref: 3626\7f1223139
+Ref: 3627\7f1223677
+Ref: 3628\7f1223914
+Ref: 3629\7f1224484
+Ref: 3630\7f1226477
+Ref: 3631\7f1226714
+Ref: 3632\7f1227069
+Ref: 3633\7f1227806
+Ref: 3634\7f1227807
+Ref: 3635\7f1227807
+Ref: 3636\7f1227807
+Ref: 3637\7f1228477
+Ref: 3638\7f1233738
+Node: 6.3\7f1234740
+Ref: 3639\7f1235040
+Ref: S0177\7f1235040
+Ref: 3640\7f1235055
+Ref: 3641\7f1235086
+Ref: 3642\7f1235124
+Ref: 3643\7f1235161
+Ref: 3644\7f1235206
+Ref: 3645\7f1235251
+Ref: 3646\7f1235838
+Ref: 3647\7f1236091
+Ref: 3648\7f1236561
+Ref: 3649\7f1237464
+Ref: 3650\7f1238337
+Node: 6.3.1\7f1238552
+Ref: 3651\7f1238664
+Ref: 3652\7f1238664
+Ref: 3653\7f1238664
+Ref: 3654\7f1238664
+Ref: 3655\7f1238664
+Ref: 3656\7f1238953
+Ref: 3657\7f1238954
+Ref: 3658\7f1239357
+Ref: 3659\7f1239358
+Ref: 3660\7f1239659
+Ref: 3661\7f1239659
+Ref: 3662\7f1244024
+Ref: 3663\7f1244024
+Ref: 3664\7f1244204
+Ref: 3665\7f1244204
+Ref: 3666\7f1245869
+Ref: 3667\7f1245870
+Ref: 3668\7f1246192
+Ref: 3669\7f1246964
+Ref: 3670\7f1246965
+Ref: 3671\7f1247507
+Ref: 3672\7f1247540
+Ref: 3673\7f1247541
+Ref: 3674\7f1247808
+Ref: 3675\7f1247840
+Ref: 3676\7f1247897
+Ref: 3677\7f1247898
+Ref: 3678\7f1249458
+Ref: 3679\7f1252087
+Ref: 3680\7f1252342
+Ref: 3681\7f1252349
+Ref: 3682\7f1253200
+Ref: 3683\7f1254318
+Ref: 3684\7f1255932
+Node: 6.3.2\7f1257824
+Ref: 3685\7f1258700
+Ref: 3686\7f1258700
+Ref: 3687\7f1260520
+Node: 6.4\7f1260588
+Ref: 3688\7f1260700
+Ref: 3689\7f1261011
+Ref: S0178\7f1261011
+Ref: 3690\7f1261035
+Ref: 3691\7f1261060
+Ref: 3692\7f1261067
+Ref: 3693\7f1261111
+Ref: S0179\7f1261111
+Ref: 3694\7f1261134
+Ref: 3695\7f1261157
+Ref: 3696\7f1261164
+Ref: 3697\7f1261398
+Ref: S0180\7f1261398
+Ref: 3698\7f1261413
+Ref: 3699\7f1261438
+Ref: 3700\7f1261491
+Ref: S0181\7f1261491
+Ref: 3701\7f1261522
+Ref: 3702\7f1261540
+Ref: 3703\7f1261599
+Ref: S0182\7f1261599
+Ref: 3704\7f1261603
+Ref: 3705\7f1261626
+Ref: 3706\7f1261634
+Ref: 3707\7f1261639
+Ref: 3708\7f1263678
+Ref: 3709\7f1264330
+Ref: 3710\7f1266387
+Ref: 3711\7f1267141
+Ref: 3712\7f1267143
+Ref: 3713\7f1270032
+Node: 6.4.1\7f1271055
+Ref: 3714\7f1271164
+Ref: 3715\7f1272453
+Ref: 3716\7f1272454
+Ref: 3717\7f1272454
+Ref: 3718\7f1272454
+Ref: 3719\7f1272872
+Ref: 3720\7f1273098
+Ref: 3721\7f1277635
+Ref: 3722\7f1283322
+Ref: 3723\7f1288117
+Ref: 3724\7f1288584
+Ref: 3725\7f1288709
+Ref: 3726\7f1288961
+Ref: 3727\7f1293037
+Ref: 3728\7f1293037
+Ref: 3729\7f1293186
+Ref: 3730\7f1293186
+Ref: 3731\7f1293186
+Ref: 3732\7f1293186
+Ref: 3733\7f1293186
+Ref: 3734\7f1293423
+Ref: 3735\7f1293487
+Ref: 3736\7f1294696
+Ref: 3737\7f1295087
+Ref: 3738\7f1295724
+Ref: 3739\7f1296276
+Node: 6.5\7f1298648
+Ref: 3740\7f1298928
+Ref: 3741\7f1299208
+Ref: S0183\7f1299208
+Ref: S0184\7f1299208
+Ref: 3742\7f1299221
+Ref: 3743\7f1299311
+Ref: S0185\7f1299311
+Ref: 3744\7f1299325
+Ref: 3745\7f1299367
+Ref: 3746\7f1299403
+Ref: 3747\7f1299591
+Ref: S0186\7f1299591
+Ref: 3748\7f1299612
+Ref: 3749\7f1299664
+Ref: 3750\7f1299783
+Ref: S0187\7f1299783
+Ref: 3751\7f1299787
+Ref: 3752\7f1299814
+Ref: 3753\7f1299914
+Ref: 3754\7f1300091
+Ref: 3755\7f1300237
+Ref: 3756\7f1300516
+Ref: 3757\7f1302899
+Ref: 3758\7f1306227
+Ref: 3759\7f1306704
+Ref: 3760\7f1307005
+Ref: 3761\7f1307328
+Ref: 3762\7f1307328
+Ref: 3763\7f1307470
+Ref: 3764\7f1307470
+Ref: 3765\7f1307472
+Ref: 3766\7f1308768
+Ref: 3767\7f1308966
+Ref: 3768\7f1308968
+Ref: 3769\7f1310536
+Ref: 3770\7f1310536
+Ref: 3771\7f1310538
+Ref: 3772\7f1312200
+Ref: 3773\7f1312201
+Ref: 3774\7f1312427
+Ref: 3775\7f1313569
+Ref: 3776\7f1313571
+Ref: 3777\7f1313571
+Ref: 3778\7f1324150
+Ref: 3779\7f1326174
+Ref: 3780\7f1327025
+Ref: 3781\7f1328168
+Ref: 3782\7f1329703
+Ref: 3783\7f1331800
+Ref: 3784\7f1333271
+Node: 6.5.1\7f1334549
+Ref: 3785\7f1334941
+Ref: 3786\7f1335453
+Ref: 3787\7f1335453
+Ref: 3788\7f1335453
+Ref: 3789\7f1336892
+Ref: 3790\7f1337756
+Ref: 3791\7f1339621
+Ref: 3792\7f1339748
+Node: 6.6\7f1339822
+Ref: 3793\7f1339950
+Ref: 3794\7f1339950
+Ref: 3795\7f1339950
+Ref: 3796\7f1342533
+Ref: 3797\7f1342868
+Ref: 3798\7f1343440
+Node: 6.7\7f1344290
+Ref: 3799\7f1344660
+Ref: S0188\7f1344660
+Ref: 3800\7f1344674
+Ref: 3801\7f1344704
+Ref: 3802\7f1344749
+Ref: 3803\7f1345109
+Ref: 3804\7f1345295
+Ref: 3805\7f1345295
+Ref: 3806\7f1346259
+Ref: 3807\7f1346766
+Ref: 3808\7f1346882
+Node: 6.8\7f1347126
+Ref: 3809\7f1347496
+Ref: S0189\7f1347496
+Ref: 3810\7f1347510
+Ref: 3811\7f1347540
+Ref: 3812\7f1347579
+Ref: 3813\7f1347604
+Ref: 3814\7f1347854
+Ref: 3815\7f1348242
+Ref: 3816\7f1349466
+Ref: 3817\7f1349466
+Ref: 3818\7f1350283
+Ref: 3819\7f1350751
+Node: 7\7f1350805
+Ref: 3820\7f1350894
+Ref: 3821\7f1351264
+Ref: 3822\7f1351266
+Ref: 3823\7f1351266
+Ref: 3824\7f1351266
+Node: 7.1\7f1351516
+Ref: 3825\7f1351908
+Ref: S0190\7f1351908
+Ref: 3826\7f1351912
+Ref: 3827\7f1351992
+Ref: S0191\7f1351992
+Ref: 3828\7f1352014
+Ref: 3829\7f1352055
+Ref: 3830\7f1352092
+Ref: 3831\7f1352145
+Ref: 3832\7f1352185
+Ref: 3833\7f1352203
+Ref: 3834\7f1352490
+Ref: 3835\7f1352491
+Ref: 3836\7f1353073
+Ref: 3837\7f1353236
+Ref: 3838\7f1353589
+Ref: 3839\7f1354679
+Ref: 3840\7f1356433
+Ref: 3841\7f1357918
+Node: 7.2\7f1358051
+Ref: 3842\7f1358629
+Ref: S0192\7f1358629
+Ref: 3843\7f1358656
+Ref: 3844\7f1358697
+Ref: 3845\7f1358734
+Ref: 3846\7f1358779
+Ref: 3847\7f1358826
+Ref: 3848\7f1358844
+Ref: 3849\7f1360589
+Ref: 3850\7f1361504
+Ref: 3851\7f1364551
+Node: 7.3\7f1364675
+Ref: 3852\7f1365229
+Ref: 3853\7f1365231
+Ref: 3854\7f1365231
+Ref: 3855\7f1365231
+Ref: 3856\7f1365231
+Ref: 3857\7f1365918
+Ref: S0193\7f1365918
+Ref: 3858\7f1365936
+Ref: 3859\7f1365957
+Ref: 3860\7f1366035
+Ref: 3861\7f1366219
+Ref: S0194\7f1366219
+Ref: 3862\7f1366237
+Ref: 3863\7f1366258
+Ref: 3864\7f1366339
+Ref: 3865\7f1366379
+Ref: 3866\7f1366421
+Ref: 3867\7f1366492
+Ref: 3868\7f1366492
+Ref: 3869\7f1379322
+Ref: 3870\7f1379809
+Ref: 3871\7f1380547
+Ref: 3872\7f1383628
+Ref: 3873\7f1385307
+Ref: 3874\7f1385380
+Ref: 3875\7f1385524
+Ref: 3876\7f1385680
+Ref: 3877\7f1387599
+Ref: 3878\7f1387678
+Ref: 3879\7f1388446
+Ref: 3880\7f1392130
+Ref: 3881\7f1394007
+Ref: 3882\7f1394821
+Node: 7.3.1\7f1395382
+Ref: 3883\7f1395692
+Ref: 3884\7f1398398
+Ref: 3885\7f1398399
+Ref: 3886\7f1398399
+Ref: 3887\7f1398857
+Ref: 3888\7f1400042
+Ref: 3889\7f1408266
+Ref: 3890\7f1408281
+Node: 7.3.2\7f1413568
+Ref: 3891\7f1414031
+Ref: 3892\7f1414367
+Ref: 3893\7f1414367
+Ref: 3894\7f1414844
+Ref: 3895\7f1414844
+Ref: 3896\7f1415609
+Ref: 3897\7f1417021
+Ref: 3898\7f1417021
+Ref: 3899\7f1420306
+Ref: 3900\7f1420941
+Ref: 3901\7f1424244
+Node: 7.4\7f1424288
+Ref: 3902\7f1424764
+Ref: 3903\7f1424888
+Ref: 3904\7f1424977
+Ref: 3905\7f1425225
+Ref: 3906\7f1428176
+Ref: 3907\7f1430505
+Ref: 3908\7f1433429
+Node: 7.5\7f1433954
+Ref: 3909\7f1439057
+Ref: 3910\7f1441752
+Ref: 3911\7f1441945
+Ref: 3912\7f1441945
+Ref: 3913\7f1444627
+Ref: 3914\7f1444627
+Ref: 3915\7f1444627
+Ref: 3916\7f1447765
+Ref: 3917\7f1448367
+Node: 7.6\7f1450797
+Ref: 3918\7f1450920
+Ref: 3919\7f1450920
+Ref: 3920\7f1451490
+Ref: 3921\7f1451492
+Ref: 3922\7f1451492
+Ref: 3923\7f1451588
+Ref: 3924\7f1451672
+Ref: 3925\7f1451674
+Ref: 3926\7f1451674
+Ref: 3927\7f1453691
+Ref: 3928\7f1453776
+Ref: 3929\7f1453926
+Ref: 3930\7f1453994
+Ref: 3931\7f1454062
+Ref: 3932\7f1454159
+Ref: 3933\7f1454333
+Ref: 3934\7f1454409
+Ref: 3935\7f1454585
+Ref: 3936\7f1456978
+Ref: 3937\7f1456978
+Ref: 3938\7f1460145
+Ref: 3939\7f1461336
+Ref: 3940\7f1461583
+Ref: 3941\7f1461583
+Ref: 3942\7f1461784
+Ref: 3943\7f1461785
+Ref: 3944\7f1461980
+Ref: 3945\7f1463036
+Ref: 3946\7f1465742
+Ref: 3947\7f1465742
+Ref: 3948\7f1470328
+Ref: 3949\7f1470693
+Ref: 3950\7f1471025
+Ref: 3951\7f1479919
+Ref: 3952\7f1480173
+Ref: 3953\7f1482371
+Node: 7.6.1\7f1484034
+Ref: 3954\7f1484498
+Ref: 3955\7f1484500
+Ref: 3956\7f1484582
+Ref: 3957\7f1484583
+Ref: 3958\7f1484757
+Ref: 3959\7f1484759
+Ref: 3960\7f1484759
+Ref: 3961\7f1484759
+Ref: 3962\7f1485349
+Ref: 3963\7f1485350
+Ref: 3964\7f1485521
+Ref: 3965\7f1487572
+Ref: 3966\7f1490101
+Ref: 3967\7f1491262
+Ref: 3968\7f1492878
+Ref: 3969\7f1493601
+Ref: 3970\7f1493601
+Ref: 3971\7f1493603
+Ref: 3972\7f1495007
+Ref: 3973\7f1495356
+Ref: 3974\7f1498254
+Ref: 3975\7f1502962
+Ref: 3976\7f1503857
+Ref: 3977\7f1504399
+Ref: 3978\7f1506259
+Ref: 3979\7f1506970
+Ref: 3980\7f1507545
+Ref: 3981\7f1511659
+Ref: 3982\7f1512908
+Ref: 3983\7f1516907
+Ref: 3984\7f1521078
+Ref: 3985\7f1521088
+Ref: 3986\7f1522701
+Ref: 3987\7f1525111
+Node: 8\7f1526811
+Node: 8.1\7f1529142
+Ref: 3988\7f1529292
+Ref: 3989\7f1531354
+Ref: 3990\7f1531354
+Ref: 3991\7f1531354
+Ref: 3992\7f1531354
+Ref: 3993\7f1531354
+Ref: 3994\7f1531796
+Ref: 3995\7f1532533
+Node: 8.2\7f1538228
+Ref: 3996\7f1538814
+Ref: 3997\7f1541368
+Ref: 3998\7f1542419
+Ref: 3999\7f1542561
+Ref: 4000\7f1542920
+Ref: 4001\7f1542992
+Ref: 4002\7f1543197
+Ref: 4003\7f1544583
+Ref: 4004\7f1545647
+Ref: 4005\7f1545895
+Ref: 4006\7f1545900
+Ref: 4007\7f1546015
+Ref: 4008\7f1549529
+Node: 8.3\7f1552571
+Ref: 4009\7f1552672
+Ref: 4010\7f1552924
+Ref: 4011\7f1552924
+Ref: 4012\7f1552924
+Ref: 4013\7f1553232
+Ref: 4014\7f1553640
+Ref: 4015\7f1553640
+Ref: 4016\7f1553722
+Ref: 4017\7f1553846
+Ref: 4018\7f1553977
+Ref: 4019\7f1554095
+Ref: 4020\7f1554206
+Ref: 4021\7f1554333
+Ref: 4022\7f1554874
+Ref: 4023\7f1555580
+Ref: 4024\7f1555715
+Ref: 4025\7f1556195
+Ref: 4026\7f1556227
+Ref: 4027\7f1560050
+Ref: 4028\7f1563810
+Ref: 4029\7f1563815
+Ref: 4030\7f1563815
+Ref: 4031\7f1563920
+Ref: 4032\7f1564343
+Ref: 4033\7f1566050
+Ref: 4034\7f1567075
+Ref: 4035\7f1568715
+Ref: 4036\7f1568715
+Ref: 4037\7f1568715
+Ref: 4038\7f1568715
+Ref: 4039\7f1568864
+Ref: 4040\7f1568931
+Ref: 4041\7f1569119
+Ref: 4042\7f1569300
+Ref: 4043\7f1569358
+Ref: 4044\7f1569452
+Ref: 4045\7f1569572
+Ref: 4046\7f1571406
+Ref: 4047\7f1571752
+Ref: 4048\7f1582475
+Ref: 4049\7f1583229
+Node: 8.3.1\7f1586398
+Ref: 4050\7f1586762
+Ref: S0195\7f1586762
+Ref: 4051\7f1588172
+Ref: 4052\7f1591142
+Node: 8.4\7f1591523
+Ref: 4053\7f1591876
+Ref: 4054\7f1592256
+Ref: 4055\7f1592636
+Ref: S0196\7f1592636
+Ref: 4056\7f1592640
+Ref: 4057\7f1592662
+Ref: 4058\7f1592704
+Ref: S0197\7f1592704
+Ref: 4059\7f1592721
+Ref: 4060\7f1592737
+Ref: 4061\7f1592794
+Ref: S0198\7f1592794
+Ref: 4062\7f1592814
+Ref: 4063\7f1592836
+Ref: 4064\7f1593123
+Ref: 4065\7f1595002
+Ref: 4066\7f1595061
+Ref: 4067\7f1597576
+Ref: 4068\7f1597576
+Ref: 4069\7f1598578
+Ref: 4070\7f1600759
+Ref: 4071\7f1601528
+Node: 8.5\7f1601904
+Ref: 4072\7f1602521
+Ref: S0199\7f1602521
+Ref: 4073\7f1602537
+Ref: 4074\7f1602576
+Ref: 4075\7f1602618
+Ref: 4076\7f1602658
+Ref: 4077\7f1602701
+Ref: 4078\7f1602780
+Ref: 4079\7f1602943
+Ref: 4080\7f1602944
+Node: 8.5.1\7f1605000
+Ref: 4081\7f1605362
+Ref: S0200\7f1605362
+Ref: 4082\7f1605376
+Ref: 4083\7f1605399
+Ref: 4084\7f1605415
+Ref: 4085\7f1605449
+Ref: 4086\7f1605468
+Ref: 4087\7f1605500
+Ref: 4088\7f1605522
+Ref: 4089\7f1605555
+Ref: 4090\7f1605574
+Ref: 4091\7f1607665
+Ref: 4092\7f1607798
+Ref: 4093\7f1608344
+Ref: 4094\7f1610115
+Ref: 4095\7f1614141
+Ref: 4096\7f1615304
+Ref: 4097\7f1616261
+Ref: 4098\7f1616996
+Node: 8.5.2\7f1617136
+Ref: 4099\7f1617464
+Ref: S0201\7f1617464
+Ref: 4100\7f1617468
+Ref: 4101\7f1617524
+Ref: 4102\7f1617538
+Ref: 4103\7f1618032
+Node: 8.5.3\7f1618175
+Ref: 4104\7f1618491
+Ref: S0202\7f1618491
+Ref: 4105\7f1618504
+Ref: 4106\7f1618553
+Ref: 4107\7f1618567
+Ref: 4108\7f1620462
+Node: 8.5.4\7f1620602
+Ref: 4109\7f1620875
+Ref: 4110\7f1620933
+Ref: 4111\7f1621391
+Ref: S0203\7f1621391
+Ref: 4112\7f1621406
+Ref: 4113\7f1621437
+Ref: 4114\7f1621486
+Ref: 4115\7f1621505
+Ref: 4116\7f1621580
+Ref: 4117\7f1621867
+Ref: 4118\7f1622559
+Ref: 4119\7f1623311
+Ref: 4120\7f1623445
+Ref: 4121\7f1623728
+Ref: 4122\7f1631234
+Ref: 4123\7f1631342
+Ref: 4124\7f1631343
+Ref: 4125\7f1635309
+Ref: 4126\7f1636462
+Ref: 4127\7f1637196
+Node: 8.5.5\7f1637339
+Ref: 4128\7f1637646
+Ref: S0204\7f1637646
+Ref: 4129\7f1637678
+Ref: 4130\7f1637735
+Ref: 4131\7f1637754
+Ref: 4132\7f1637806
+Ref: 4133\7f1637865
+Ref: 4134\7f1637884
+Ref: 4135\7f1637935
+Ref: 4136\7f1637993
+Ref: 4137\7f1638012
+Ref: 4138\7f1638893
+Ref: 4139\7f1639667
+Node: 8.6\7f1639807
+Ref: 4140\7f1639971
+Ref: 4141\7f1640248
+Ref: 4142\7f1640851
+Ref: 4143\7f1641500
+Ref: 4144\7f1642261
+Ref: 4145\7f1642261
+Ref: 4146\7f1644640
+Ref: 4147\7f1644726
+Ref: 4148\7f1644728
+Ref: 4149\7f1644728
+Ref: 4150\7f1645498
+Ref: 4151\7f1645801
+Ref: 4152\7f1646259
+Ref: 4153\7f1647990
+Ref: 4154\7f1648910
+Ref: 4155\7f1649108
+Ref: 4156\7f1649683
+Ref: 4157\7f1649683
+Ref: 4158\7f1650417
+Ref: 4159\7f1650572
+Ref: 4160\7f1652445
+Ref: 4161\7f1652584
+Ref: 4162\7f1652715
+Ref: 4163\7f1653178
+Ref: 4164\7f1655155
+Ref: 4165\7f1655155
+Ref: 4166\7f1656985
+Ref: 4167\7f1658231
+Ref: 4168\7f1658845
+Ref: 4169\7f1659247
+Ref: 4170\7f1661959
+Ref: 4171\7f1661969
+Ref: 4172\7f1662236
+Ref: 4173\7f1666749
+Ref: 4174\7f1667805
+Ref: 4175\7f1668764
+Ref: 4176\7f1670031
+Ref: 4177\7f1670775
+Node: 9\7f1671329
+Ref: 4178\7f1671478
+Ref: 4179\7f1671558
+Ref: 4180\7f1671560
+Ref: 4181\7f1671792
+Ref: 4182\7f1671793
+Ref: 4183\7f1671793
+Ref: 4184\7f1671793
+Ref: 4185\7f1672113
+Ref: 4186\7f1673274
+Ref: 4187\7f1673518
+Ref: 4188\7f1673520
+Ref: 4189\7f1673520
+Ref: 4190\7f1673520
+Ref: 4191\7f1673520
+Ref: 4192\7f1673520
+Ref: 4193\7f1673520
+Ref: 4194\7f1673520
+Ref: 4195\7f1673668
+Ref: 4196\7f1673816
+Ref: 4197\7f1673817
+Node: 9.1\7f1675593
+Ref: 4198\7f1675715
+Ref: 4199\7f1676183
+Ref: S0205\7f1676183
+Ref: 4200\7f1676206
+Ref: 4201\7f1676227
+Ref: 4202\7f1676266
+Ref: 4203\7f1676307
+Ref: 4204\7f1676338
+Ref: 4205\7f1676448
+Ref: S0206\7f1676448
+Ref: 4206\7f1676466
+Ref: 4207\7f1676501
+Ref: 4208\7f1676541
+Ref: 4209\7f1676572
+Ref: 4210\7f1676613
+Ref: S0207\7f1676613
+Ref: 4211\7f1676629
+Ref: 4212\7f1676668
+Ref: 4213\7f1676697
+Ref: 4214\7f1676778
+Ref: S0208\7f1676778
+Ref: 4215\7f1676782
+Ref: 4216\7f1676808
+Ref: 4217\7f1676866
+Ref: S0209\7f1676866
+Ref: 4218\7f1676889
+Ref: 4219\7f1676923
+Ref: 4220\7f1676958
+Ref: 4221\7f1676999
+Ref: 4222\7f1677048
+Ref: 4223\7f1677370
+Ref: 4224\7f1677561
+Ref: 4225\7f1678896
+Ref: 4226\7f1678897
+Ref: 4227\7f1678897
+Ref: 4228\7f1679741
+Ref: 4229\7f1681139
+Ref: 4230\7f1682267
+Ref: 4231\7f1682525
+Ref: 4232\7f1682959
+Ref: 4233\7f1683429
+Ref: 4234\7f1683499
+Ref: 4235\7f1683780
+Ref: 4236\7f1683998
+Ref: 4237\7f1684904
+Ref: 4238\7f1688383
+Ref: 4239\7f1689502
+Ref: 4240\7f1690779
+Node: 9.2\7f1691343
+Ref: 4241\7f1691534
+Ref: 4242\7f1691636
+Ref: 4243\7f1691638
+Ref: 4244\7f1691638
+Ref: 4245\7f1691638
+Ref: 4246\7f1691783
+Ref: 4247\7f1694975
+Ref: 4248\7f1694975
+Ref: 4249\7f1695132
+Node: 9.3\7f1699330
+Ref: 4250\7f1699533
+Ref: 4251\7f1699533
+Ref: 4252\7f1699533
+Ref: 4253\7f1699533
+Ref: 4254\7f1700716
+Ref: 4255\7f1701428
+Node: 9.4\7f1705849
+Ref: 4256\7f1706003
+Ref: 4257\7f1706003
+Ref: 4258\7f1706003
+Ref: 4259\7f1706003
+Ref: 4260\7f1706173
+Ref: 4261\7f1706175
+Ref: 4262\7f1706175
+Ref: 4263\7f1706556
+Ref: 4264\7f1706695
+Ref: S0210\7f1706695
+Ref: 4265\7f1706722
+Ref: 4266\7f1706743
+Ref: 4267\7f1706782
+Ref: 4268\7f1706822
+Ref: 4269\7f1706853
+Ref: 4270\7f1706972
+Ref: S0211\7f1706972
+Ref: 4271\7f1706994
+Ref: 4272\7f1707028
+Ref: 4273\7f1707068
+Ref: 4274\7f1707099
+Ref: 4275\7f1707149
+Ref: S0212\7f1707149
+Ref: 4276\7f1707165
+Ref: 4277\7f1707225
+Ref: 4278\7f1707281
+Ref: 4279\7f1707389
+Ref: S0213\7f1707389
+Ref: 4280\7f1707393
+Ref: 4281\7f1707429
+Ref: 4282\7f1707459
+Ref: 4283\7f1707510
+Ref: S0214\7f1707510
+Ref: 4284\7f1707514
+Ref: 4285\7f1707559
+Ref: 4286\7f1707913
+Ref: S0215\7f1707913
+Ref: 4287\7f1707940
+Ref: 4288\7f1707974
+Ref: 4289\7f1708009
+Ref: 4290\7f1708058
+Ref: 4291\7f1708160
+Ref: S0216\7f1708160
+Ref: 4292\7f1708164
+Ref: 4293\7f1708200
+Ref: 4294\7f1708228
+Ref: 4295\7f1708251
+Ref: 4296\7f1708667
+Ref: 4297\7f1708903
+Ref: 4298\7f1710210
+Ref: 4299\7f1710211
+Ref: 4300\7f1710211
+Ref: 4301\7f1710211
+Ref: 4302\7f1711079
+Ref: 4303\7f1712614
+Ref: 4304\7f1713775
+Ref: 4305\7f1714087
+Ref: 4306\7f1714169
+Ref: 4307\7f1715919
+Ref: 4308\7f1716578
+Ref: 4309\7f1716657
+Ref: 4310\7f1716949
+Ref: 4311\7f1717168
+Ref: 4312\7f1717400
+Ref: 4313\7f1717957
+Ref: 4314\7f1718415
+Ref: 4315\7f1718415
+Ref: 4316\7f1720187
+Ref: 4317\7f1725988
+Ref: 4318\7f1726299
+Ref: 4319\7f1727569
+Ref: 4320\7f1728052
+Node: 9.5\7f1728646
+Ref: 4321\7f1728772
+Ref: 4322\7f1728772
+Ref: 4323\7f1729330
+Ref: 4324\7f1730278
+Ref: 4325\7f1730547
+Ref: 4326\7f1732318
+Ref: 4327\7f1732318
+Ref: 4328\7f1732318
+Ref: 4329\7f1734979
+Ref: S0217\7f1734979
+Ref: 4330\7f1735427
+Ref: 4331\7f1735427
+Ref: 4332\7f1737044
+Ref: 4333\7f1738084
+Node: 9.5.1\7f1738813
+Ref: 4334\7f1738977
+Ref: 4335\7f1738977
+Ref: 4336\7f1738977
+Ref: 4337\7f1740420
+Ref: 4338\7f1741087
+Ref: 4339\7f1741396
+Ref: 4340\7f1741396
+Ref: 4341\7f1741708
+Ref: 4342\7f1741708
+Ref: 4343\7f1742100
+Ref: 4344\7f1742201
+Ref: 4345\7f1742203
+Ref: 4346\7f1743479
+Node: 9.5.2\7f1747927
+Ref: 4347\7f1748363
+Ref: S0218\7f1748363
+Ref: 4348\7f1748377
+Ref: 4349\7f1748413
+Ref: 4350\7f1748435
+Ref: 4351\7f1748465
+Ref: 4352\7f1748501
+Ref: 4353\7f1748548
+Ref: S0219\7f1748548
+Ref: 4354\7f1748574
+Ref: 4355\7f1748588
+Ref: 4356\7f1748602
+Ref: 4357\7f1748634
+Ref: 4358\7f1748684
+Ref: 4359\7f1749004
+Ref: S0220\7f1749004
+Ref: 4360\7f1749008
+Ref: 4361\7f1749038
+Ref: S0221\7f1749038
+Ref: 4362\7f1749056
+Ref: 4363\7f1749077
+Ref: 4364\7f1749101
+Ref: 4365\7f1749133
+Ref: 4366\7f1749172
+Ref: 4367\7f1749221
+Ref: 4368\7f1749619
+Ref: S0222\7f1749619
+Ref: 4369\7f1749626
+Ref: 4370\7f1749654
+Ref: 4371\7f1749699
+Ref: S0223\7f1749699
+Ref: 4372\7f1749709
+Ref: 4373\7f1749752
+Ref: S0224\7f1749752
+Ref: 4374\7f1749761
+Ref: 4375\7f1749784
+Ref: 4376\7f1750639
+Ref: 4377\7f1750765
+Ref: 4378\7f1753892
+Ref: 4379\7f1754867
+Ref: 4380\7f1757109
+Ref: 4381\7f1757204
+Ref: 4382\7f1757338
+Ref: 4383\7f1757453
+Ref: 4384\7f1758764
+Ref: 4385\7f1759234
+Ref: 4386\7f1759234
+Ref: 4387\7f1759234
+Ref: 4388\7f1759694
+Ref: 4389\7f1759696
+Ref: 4390\7f1759975
+Ref: 4391\7f1760584
+Ref: 4392\7f1761430
+Ref: 4393\7f1761630
+Ref: 4394\7f1761632
+Ref: 4395\7f1761632
+Ref: 4396\7f1762930
+Ref: 4397\7f1763318
+Ref: 4398\7f1766609
+Ref: 4399\7f1767203
+Node: 9.5.3\7f1767333
+Ref: 4400\7f1767447
+Ref: 4401\7f1767520
+Ref: 4402\7f1767522
+Ref: 4403\7f1767807
+Ref: S0225\7f1767807
+Ref: 4404\7f1767818
+Ref: 4405\7f1767824
+Ref: 4406\7f1768379
+Ref: 4407\7f1768379
+Ref: 4408\7f1768379
+Ref: 4409\7f1768379
+Ref: 4410\7f1768546
+Ref: 4411\7f1768547
+Ref: 4412\7f1768858
+Ref: 4413\7f1768859
+Ref: 4414\7f1769021
+Ref: 4415\7f1770187
+Ref: 4416\7f1770336
+Ref: 4417\7f1770533
+Ref: 4418\7f1771827
+Ref: 4419\7f1771970
+Ref: 4420\7f1771970
+Ref: 4421\7f1772585
+Ref: 4422\7f1772876
+Ref: 4423\7f1772980
+Ref: 4424\7f1772982
+Ref: 4425\7f1774051
+Ref: 4426\7f1774626
+Ref: 4427\7f1775752
+Node: 9.5.4\7f1784509
+Ref: 4428\7f1784785
+Ref: 4429\7f1784931
+Ref: 4430\7f1784933
+Ref: 4431\7f1785028
+Ref: S0226\7f1785028
+Ref: 4432\7f1785065
+Ref: 4433\7f1785187
+Ref: 4434\7f1785583
+Ref: 4435\7f1786036
+Ref: 4436\7f1786524
+Ref: 4437\7f1789135
+Ref: 4438\7f1789508
+Ref: 4439\7f1789780
+Ref: 4440\7f1791306
+Ref: 4441\7f1792909
+Ref: 4442\7f1793313
+Ref: 4443\7f1793469
+Node: 9.6\7f1793595
+Ref: 4444\7f1793748
+Ref: 4445\7f1794222
+Ref: 4446\7f1794290
+Ref: S0227\7f1794290
+Ref: 4447\7f1794294
+Ref: 4448\7f1794319
+Ref: 4449\7f1794379
+Ref: S0228\7f1794379
+Ref: 4450\7f1794402
+Ref: 4451\7f1794446
+Ref: S0229\7f1794446
+Ref: 4452\7f1794463
+Ref: 4453\7f1794527
+Ref: 4454\7f1794632
+Ref: 4455\7f1794798
+Ref: 4456\7f1794799
+Ref: 4457\7f1794799
+Ref: 4458\7f1795830
+Ref: 4459\7f1795872
+Ref: 4460\7f1795939
+Ref: 4461\7f1795998
+Ref: 4462\7f1796052
+Ref: 4463\7f1796106
+Ref: 4464\7f1796581
+Ref: 4465\7f1796620
+Ref: 4466\7f1796677
+Ref: 4467\7f1796735
+Ref: 4468\7f1796791
+Ref: 4469\7f1796854
+Ref: 4470\7f1797104
+Ref: 4471\7f1797811
+Ref: 4472\7f1797976
+Ref: 4473\7f1798056
+Ref: 4474\7f1798219
+Ref: 4475\7f1798469
+Ref: 4476\7f1798976
+Ref: 4477\7f1799543
+Ref: 4478\7f1806946
+Ref: 4479\7f1806946
+Ref: 4480\7f1808096
+Ref: 4481\7f1808096
+Ref: 4482\7f1808560
+Ref: 4483\7f1809030
+Ref: 4484\7f1810492
+Node: 9.6.1\7f1811396
+Ref: 4485\7f1811732
+Ref: 4486\7f1811830
+Ref: 4487\7f1812524
+Ref: 4488\7f1812583
+Ref: 4489\7f1812686
+Ref: 4490\7f1812782
+Ref: 4491\7f1812948
+Ref: 4492\7f1813364
+Ref: 4493\7f1813888
+Ref: 4494\7f1814017
+Ref: 4495\7f1814030
+Ref: 4496\7f1814038
+Ref: 4497\7f1814047
+Ref: 4498\7f1814058
+Ref: 4499\7f1814075
+Ref: 4500\7f1814088
+Ref: 4501\7f1814098
+Ref: 4502\7f1814130
+Ref: 4503\7f1814242
+Ref: 4504\7f1814304
+Ref: 4505\7f1814366
+Ref: 4506\7f1814428
+Ref: 4507\7f1814505
+Ref: 4508\7f1814676
+Ref: 4509\7f1814848
+Ref: 4510\7f1815018
+Ref: 4511\7f1815189
+Ref: 4512\7f1815362
+Ref: 4513\7f1815464
+Ref: 4514\7f1815568
+Ref: 4515\7f1815837
+Ref: 4516\7f1816126
+Ref: 4517\7f1816683
+Ref: 4518\7f1817078
+Ref: 4519\7f1817595
+Ref: 4520\7f1818163
+Ref: 4521\7f1818593
+Ref: 4522\7f1818783
+Ref: 4523\7f1818907
+Ref: 4524\7f1819043
+Ref: 4525\7f1840599
+Ref: 4526\7f1840799
+Node: 9.7\7f1841316
+Ref: 4527\7f1841719
+Ref: S0230\7f1841719
+Ref: 4528\7f1841732
+Ref: 4529\7f1841758
+Ref: 4530\7f1841784
+Ref: 4531\7f1841816
+Ref: 4532\7f1842093
+Node: 9.7.1\7f1842290
+Ref: 4533\7f1842615
+Ref: 4534\7f1842683
+Ref: S0231\7f1842683
+Ref: 4535\7f1842711
+Ref: 4536\7f1842728
+Ref: 4537\7f1842766
+Ref: 4538\7f1842783
+Ref: 4539\7f1842824
+Ref: 4540\7f1842881
+Ref: S0232\7f1842881
+Ref: 4541\7f1842891
+Ref: 4542\7f1842930
+Ref: S0233\7f1842930
+Ref: 4543\7f1842943
+Ref: 4544\7f1842971
+Ref: 4545\7f1842998
+Ref: 4546\7f1843046
+Ref: S0234\7f1843046
+Ref: 4547\7f1843058
+Ref: 4548\7f1843076
+Ref: 4549\7f1843125
+Ref: S0235\7f1843125
+Ref: 4550\7f1843137
+Ref: 4551\7f1843154
+Ref: 4552\7f1843207
+Ref: S0236\7f1843207
+Ref: 4553\7f1843446
+Ref: 4554\7f1844010
+Ref: 4555\7f1844187
+Ref: 4556\7f1844832
+Ref: 4557\7f1845481
+Ref: 4558\7f1847315
+Node: 9.7.2\7f1848546
+Ref: 4559\7f1848985
+Ref: 4560\7f1849054
+Ref: S0237\7f1849054
+Ref: 4561\7f1849081
+Ref: 4562\7f1849122
+Ref: 4563\7f1849220
+Ref: S0238\7f1849220
+Ref: 4564\7f1849232
+Ref: 4565\7f1849257
+Ref: 4566\7f1849345
+Ref: S0239\7f1849345
+Ref: 4567\7f1849357
+Ref: 4568\7f1849384
+Ref: 4569\7f1850506
+Ref: 4570\7f1852427
+Node: 9.7.3\7f1852959
+Ref: 4571\7f1853824
+Ref: S0240\7f1853824
+Ref: 4572\7f1853851
+Ref: 4573\7f1853894
+Ref: 4574\7f1853986
+Node: 9.7.4\7f1855179
+Ref: 4575\7f1855529
+Ref: S0241\7f1855529
+Ref: 4576\7f1855556
+Ref: 4577\7f1855605
+Ref: 4578\7f1855669
+Ref: S0242\7f1855669
+Ref: 4579\7f1855673
+Ref: 4580\7f1855696
+Ref: 4581\7f1855785
+Ref: S0243\7f1855785
+Ref: 4582\7f1855789
+Ref: 4583\7f1855821
+Ref: 4584\7f1855859
+Ref: S0244\7f1855859
+Ref: 4585\7f1855863
+Ref: 4586\7f1855967
+Ref: 4587\7f1855968
+Ref: 4588\7f1856850
+Ref: 4589\7f1859503
+Ref: 4590\7f1859503
+Ref: 4591\7f1859503
+Ref: 4592\7f1859933
+Ref: 4593\7f1859934
+Ref: 4594\7f1859934
+Ref: 4595\7f1859934
+Ref: 4596\7f1859934
+Ref: 4597\7f1860267
+Ref: 4598\7f1860399
+Node: 9.8\7f1860577
+Ref: 4599\7f1861105
+Ref: S0245\7f1861105
+Ref: 4600\7f1861121
+Ref: 4601\7f1861134
+Ref: 4602\7f1861193
+Ref: 4603\7f1861340
+Ref: 4604\7f1861438
+Ref: 4605\7f1861438
+Ref: 4606\7f1861440
+Ref: 4607\7f1861440
+Ref: 4608\7f1862303
+Ref: 4609\7f1862303
+Ref: 4610\7f1862729
+Ref: 4611\7f1864660
+Ref: 4612\7f1865646
+Ref: 4613\7f1867039
+Ref: 4614\7f1867322
+Ref: 4615\7f1868558
+Ref: 4616\7f1868558
+Ref: 4617\7f1868558
+Ref: 4618\7f1868558
+Node: 9.9\7f1869393
+Ref: 4619\7f1869697
+Ref: 4620\7f1869712
+Ref: 4621\7f1869809
+Ref: 4622\7f1869810
+Ref: 4623\7f1869975
+Ref: 4624\7f1869990
+Ref: 4625\7f1870494
+Ref: 4626\7f1870509
+Node: 9.10\7f1871550
+Ref: 4627\7f1871813
+Ref: 4628\7f1871814
+Ref: 4629\7f1872505
+Ref: 4630\7f1874519
+Ref: 4631\7f1877783
+Ref: 4632\7f1878045
+Node: 9.11\7f1881977
+Node: 10\7f1885820
+Ref: 4633\7f1886863
+Ref: 4634\7f1886863
+Ref: 4635\7f1886863
+Ref: 4636\7f1887168
+Ref: 4637\7f1887661
+Ref: 4638\7f1888142
+Ref: 4639\7f1888152
+Ref: 4640\7f1888333
+Node: 10.1\7f1889473
+Ref: 4641\7f1889587
+Ref: 4642\7f1889587
+Ref: 4643\7f1889588
+Ref: 4644\7f1889903
+Ref: 4645\7f1890983
+Ref: 4646\7f1891230
+Node: 10.1.1\7f1893163
+Ref: 4647\7f1893523
+Ref: 4648\7f1893773
+Ref: S0246\7f1893773
+Ref: 4649\7f1893779
+Ref: 4650\7f1893821
+Ref: S0247\7f1893821
+Ref: 4651\7f1893835
+Ref: 4652\7f1893850
+Ref: 4653\7f1893872
+Ref: 4654\7f1893887
+Ref: 4655\7f1893915
+Ref: S0248\7f1893915
+Ref: 4656\7f1893930
+Ref: 4657\7f1893964
+Ref: 4658\7f1894001
+Ref: 4659\7f1894067
+Ref: S0249\7f1894067
+Ref: 4660\7f1894082
+Ref: 4661\7f1894109
+Ref: 4662\7f1894139
+Ref: 4663\7f1894163
+Ref: 4664\7f1894226
+Ref: S0250\7f1894226
+Ref: 4665\7f1894239
+Ref: 4666\7f1894276
+Ref: 4667\7f1894313
+Ref: 4668\7f1894370
+Ref: S0251\7f1894370
+Ref: 4669\7f1894374
+Ref: 4670\7f1894393
+Ref: 4671\7f1894430
+Ref: S0252\7f1894430
+Ref: 4672\7f1894434
+Ref: 4673\7f1894935
+Ref: 4674\7f1894935
+Ref: 4675\7f1894935
+Ref: 4676\7f1894935
+Ref: 4677\7f1894935
+Ref: 4678\7f1895242
+Ref: 4679\7f1896415
+Ref: 4680\7f1896415
+Ref: 4681\7f1896639
+Ref: 4682\7f1896932
+Ref: 4683\7f1897927
+Ref: 4684\7f1898067
+Ref: 4685\7f1898436
+Ref: 4686\7f1898436
+Ref: 4687\7f1898436
+Ref: 4688\7f1898436
+Ref: 4689\7f1898699
+Ref: 4690\7f1898821
+Ref: 4691\7f1901454
+Ref: 4692\7f1910812
+Ref: 4693\7f1910813
+Ref: 4694\7f1923288
+Ref: 4695\7f1924257
+Node: 10.1.2\7f1924945
+Ref: 4696\7f1925265
+Ref: 4697\7f1925677
+Ref: 4698\7f1926405
+Ref: S0253\7f1926405
+Ref: 4699\7f1926411
+Ref: 4700\7f1926445
+Ref: S0254\7f1926445
+Ref: 4701\7f1926449
+Ref: 4702\7f1926464
+Ref: 4703\7f1926559
+Ref: S0255\7f1926559
+Ref: 4704\7f1926563
+Ref: 4705\7f1926586
+Ref: 4706\7f1926640
+Ref: S0256\7f1926640
+Ref: 4707\7f1926681
+Ref: 4708\7f1926708
+Ref: 4709\7f1926749
+Ref: S0257\7f1926749
+Ref: 4710\7f1926782
+Ref: 4711\7f1926809
+Ref: 4712\7f1926991
+Ref: 4713\7f1927520
+Ref: 4714\7f1929225
+Ref: 4715\7f1929226
+Ref: 4716\7f1929286
+Ref: 4717\7f1929287
+Ref: 4718\7f1943976
+Ref: 4719\7f1945260
+Ref: 4720\7f1945697
+Ref: 4721\7f1946010
+Ref: 4722\7f1946422
+Node: 10.1.3\7f1947314
+Ref: 4723\7f1947847
+Ref: S0258\7f1947847
+Ref: 4724\7f1947851
+Ref: 4725\7f1947875
+Ref: 4726\7f1947895
+Ref: 4727\7f1947918
+Ref: 4728\7f1948027
+Ref: S0259\7f1948027
+Ref: 4729\7f1948041
+Ref: 4730\7f1948071
+Ref: 4731\7f1948120
+Ref: 4732\7f1948353
+Ref: S0260\7f1948353
+Ref: 4733\7f1948379
+Ref: 4734\7f1948423
+Ref: 4735\7f1948468
+Ref: S0261\7f1948468
+Ref: 4736\7f1948491
+Ref: 4737\7f1948535
+Ref: 4738\7f1948585
+Ref: S0262\7f1948585
+Ref: 4739\7f1948613
+Ref: 4740\7f1948657
+Ref: 4741\7f1948695
+Ref: S0263\7f1948695
+Ref: 4742\7f1948710
+Ref: 4743\7f1948728
+Ref: 4744\7f1948818
+Ref: 4745\7f1948912
+Ref: 4746\7f1949176
+Ref: 4747\7f1950368
+Ref: 4748\7f1950800
+Ref: 4749\7f1950991
+Ref: 4750\7f1954032
+Ref: 4751\7f1954322
+Ref: 4752\7f1954668
+Node: 10.1.4\7f1954779
+Ref: 4753\7f1954923
+Ref: 4754\7f1954923
+Ref: 4755\7f1957998
+Ref: 4756\7f1959177
+Ref: 4757\7f1965511
+Ref: 4758\7f1965928
+Ref: 4759\7f1967350
+Node: 10.1.5\7f1968597
+Ref: 4760\7f1968891
+Ref: 4761\7f1968891
+Ref: 4762\7f1968946
+Ref: 4763\7f1971439
+Ref: 4764\7f1971440
+Ref: 4765\7f1971440
+Ref: 4766\7f1971440
+Ref: 4767\7f1972388
+Ref: 4768\7f1972388
+Node: 10.1.6\7f1975249
+Ref: 4769\7f1975732
+Ref: 4770\7f1975733
+Ref: 4771\7f1975733
+Ref: 4772\7f1975733
+Ref: 4773\7f1977451
+Ref: 4774\7f1977451
+Ref: 4775\7f1977451
+Ref: 4776\7f1977451
+Ref: 4777\7f1978324
+Ref: 4778\7f1978324
+Ref: 4779\7f1978697
+Ref: 4780\7f1978697
+Ref: 4781\7f1978924
+Node: 10.2\7f1980865
+Ref: 4782\7f1980972
+Ref: 4783\7f1980972
+Ref: 4784\7f1980972
+Ref: 4785\7f1981197
+Ref: 4786\7f1981197
+Ref: 4787\7f1981404
+Ref: 4788\7f1981889
+Ref: 4789\7f1981890
+Ref: 4790\7f1981890
+Ref: 4791\7f1984383
+Ref: 4792\7f1986043
+Ref: 4793\7f1986647
+Ref: 4794\7f1986649
+Ref: 4795\7f1989054
+Ref: 4796\7f1992339
+Ref: 4797\7f1992340
+Ref: 4798\7f1994211
+Ref: 4799\7f1994332
+Ref: 4800\7f1995364
+Ref: 4801\7f1995365
+Ref: 4802\7f1995365
+Ref: 4803\7f1995365
+Ref: 4804\7f1995365
+Ref: 4805\7f1995584
+Ref: 4806\7f1995584
+Ref: 4807\7f1995848
+Ref: 4808\7f1998138
+Ref: 4809\7f2004450
+Node: 10.2.1\7f2005342
+Ref: 4810\7f2005449
+Ref: 4811\7f2007708
+Ref: 4812\7f2007709
+Ref: 4813\7f2007736
+Ref: 4814\7f2007747
+Ref: 4815\7f2007752
+Ref: 4816\7f2007931
+Ref: 4817\7f2007932
+Ref: 4818\7f2007961
+Ref: 4819\7f2008023
+Ref: 4820\7f2010630
+Ref: 4821\7f2012479
+Ref: 4822\7f2012624
+Ref: 4823\7f2012624
+Ref: 4824\7f2013009
+Ref: 4825\7f2013172
+Ref: 4826\7f2014123
+Ref: 4827\7f2016711
+Ref: 4828\7f2018942
+Ref: 4829\7f2018943
+Ref: 4830\7f2018962
+Ref: 4831\7f2018974
+Ref: 4832\7f2018979
+Ref: 4833\7f2019126
+Ref: 4834\7f2023982
+Ref: 4835\7f2024081
+Ref: 4836\7f2024081
+Ref: 4837\7f2024513
+Ref: 4838\7f2029414
+Ref: 4839\7f2029415
+Ref: 4840\7f2029438
+Ref: 4841\7f2029458
+Ref: 4842\7f2029483
+Ref: 4843\7f2029484
+Ref: 4844\7f2029511
+Ref: 4845\7f2029531
+Ref: 4846\7f2029556
+Ref: 4847\7f2029557
+Ref: 4848\7f2029586
+Ref: 4849\7f2029898
+Ref: 4850\7f2029903
+Ref: 4851\7f2030305
+Ref: 4852\7f2030465
+Ref: 4853\7f2031905
+Ref: 4854\7f2031905
+Ref: 4855\7f2034558
+Ref: 4856\7f2035009
+Ref: 4857\7f2036674
+Ref: 4858\7f2037829
+Ref: 4859\7f2039035
+Node: 11\7f2041160
+Ref: 4860\7f2041413
+Ref: 4861\7f2041415
+Ref: 4862\7f2041415
+Ref: 4863\7f2041415
+Ref: 4864\7f2041415
+Ref: 4865\7f2041415
+Ref: 4866\7f2041557
+Ref: 4867\7f2041699
+Ref: 4868\7f2041833
+Ref: 4869\7f2042180
+Node: 11.1\7f2043958
+Ref: 4870\7f2044075
+Ref: 4871\7f2044231
+Ref: S0264\7f2044231
+Ref: 4872\7f2044235
+Ref: 4873\7f2044287
+Ref: 4874\7f2045922
+Ref: 4875\7f2045922
+Ref: 4876\7f2045922
+Ref: 4877\7f2045922
+Ref: 4878\7f2045922
+Ref: 4879\7f2046331
+Ref: 4880\7f2046393
+Ref: 4881\7f2046393
+Ref: 4882\7f2046393
+Ref: 4883\7f2046497
+Ref: 4884\7f2046995
+Ref: 4885\7f2048153
+Node: 11.2\7f2048286
+Ref: 4886\7f2048566
+Ref: S0265\7f2048566
+Ref: 4887\7f2048581
+Ref: 4888\7f2048632
+Ref: 4889\7f2048660
+Ref: 4890\7f2048705
+Ref: S0266\7f2048705
+Ref: 4891\7f2048723
+Ref: 4892\7f2048756
+Ref: 4893\7f2048776
+Ref: 4894\7f2048813
+Ref: 4895\7f2048874
+Ref: S0267\7f2048874
+Ref: 4896\7f2048878
+Ref: 4897\7f2048923
+Ref: S0268\7f2048923
+Ref: 4898\7f2048938
+Ref: 4899\7f2048980
+Ref: 4900\7f2049086
+Ref: 4901\7f2049221
+Ref: 4902\7f2050637
+Ref: 4903\7f2050980
+Ref: 4904\7f2051635
+Node: 11.3\7f2052757
+Ref: 4905\7f2053011
+Ref: S0269\7f2053011
+Ref: 4906\7f2053052
+Ref: 4907\7f2053070
+Ref: 4908\7f2053196
+Ref: 4909\7f2053591
+Ref: 4910\7f2053693
+Ref: 4911\7f2053914
+Ref: 4912\7f2055491
+Node: 11.4\7f2055792
+Ref: 4913\7f2056063
+Ref: 4914\7f2056138
+Ref: 4915\7f2056794
+Ref: 4916\7f2056794
+Ref: 4917\7f2057039
+Ref: 4918\7f2057203
+Ref: 4919\7f2057204
+Ref: 4920\7f2058550
+Ref: 4921\7f2059901
+Ref: 4922\7f2060094
+Ref: 4923\7f2060095
+Ref: 4924\7f2060284
+Ref: 4925\7f2060284
+Ref: 4926\7f2060284
+Node: 11.4.1\7f2062021
+Ref: 4927\7f2062346
+Ref: 4928\7f2062451
+Ref: 4929\7f2062540
+Ref: 4930\7f2062596
+Ref: 4931\7f2062663
+Ref: 4932\7f2062740
+Ref: 4933\7f2062870
+Ref: 4934\7f2062993
+Ref: 4935\7f2063061
+Ref: 4936\7f2063193
+Ref: 4937\7f2063339
+Ref: 4938\7f2063417
+Ref: 4939\7f2063518
+Ref: 4940\7f2063639
+Ref: 4941\7f2063776
+Ref: 4942\7f2063941
+Ref: 4943\7f2064121
+Ref: 4944\7f2064237
+Ref: 4945\7f2064376
+Ref: 4946\7f2065654
+Ref: 4947\7f2065669
+Ref: 4948\7f2067049
+Ref: 4949\7f2070678
+Ref: 4950\7f2083017
+Ref: 4951\7f2083210
+Ref: 4952\7f2085115
+Ref: 4953\7f2085762
+Node: 11.4.2\7f2086713
+Ref: 4954\7f2087356
+Ref: 4955\7f2087356
+Ref: 4956\7f2088670
+Ref: 4957\7f2088671
+Ref: 4958\7f2088697
+Ref: 4959\7f2088735
+Ref: 4960\7f2088971
+Ref: 4961\7f2088972
+Ref: 4962\7f2088996
+Ref: 4963\7f2089054
+Ref: 4964\7f2089055
+Ref: 4965\7f2089097
+Ref: 4966\7f2089119
+Ref: 4967\7f2089153
+Ref: 4968\7f2089175
+Ref: 4969\7f2089223
+Ref: 4970\7f2089224
+Ref: 4971\7f2093117
+Ref: 4972\7f2093190
+Ref: 4973\7f2093248
+Ref: 4974\7f2093294
+Ref: 4975\7f2094127
+Ref: 4976\7f2094127
+Ref: 4977\7f2098468
+Ref: 4978\7f2098644
+Ref: 4979\7f2099532
+Node: 11.4.3\7f2099671
+Node: 11.5\7f2102495
+Ref: 4980\7f2102664
+Ref: 4981\7f2102934
+Ref: 4982\7f2102935
+Ref: 4983\7f2102935
+Ref: 4984\7f2102935
+Ref: 4985\7f2102935
+Ref: 4986\7f2103136
+Ref: 4987\7f2103550
+Ref: 4988\7f2103551
+Ref: 4989\7f2103560
+Ref: 4990\7f2103622
+Ref: 4991\7f2103623
+Ref: 4992\7f2103634
+Ref: 4993\7f2103685
+Ref: 4994\7f2103686
+Ref: 4995\7f2103686
+Ref: 4996\7f2103686
+Ref: 4997\7f2105321
+Ref: 4998\7f2105548
+Ref: 4999\7f2106191
+Ref: 5000\7f2106392
+Ref: 5001\7f2106666
+Ref: 5002\7f2106985
+Ref: 5003\7f2107114
+Ref: 5004\7f2107682
+Ref: 5005\7f2107892
+Ref: 5006\7f2108155
+Ref: 5007\7f2108748
+Ref: 5008\7f2109034
+Ref: 5009\7f2109178
+Ref: 5010\7f2109298
+Ref: 5011\7f2109592
+Ref: 5012\7f2110071
+Ref: 5013\7f2110071
+Ref: 5014\7f2110945
+Ref: 5015\7f2112310
+Ref: 5016\7f2112807
+Ref: 5017\7f2114513
+Ref: 5018\7f2114513
+Ref: 5019\7f2115374
+Ref: 5020\7f2117316
+Node: 11.6\7f2119584
+Ref: 5021\7f2119739
+Ref: 5022\7f2119739
+Ref: 5023\7f2119740
+Ref: 5024\7f2119740
+Ref: 5025\7f2119740
+Ref: 5026\7f2119740
+Ref: 5027\7f2119964
+Ref: 5028\7f2122285
+Ref: 5029\7f2122285
+Ref: 5030\7f2125402
+Ref: 5031\7f2126142
+Ref: 5032\7f2126314
+Ref: 5033\7f2126316
+Ref: 5034\7f2126316
+Node: 12\7f2132534
+Ref: 5035\7f2132637
+Ref: 5036\7f2132727
+Ref: 5037\7f2132955
+Ref: 5038\7f2132957
+Ref: 5039\7f2132957
+Node: 12.1\7f2134796
+Ref: 5040\7f2135324
+Ref: S0270\7f2135324
+Ref: 5041\7f2135328
+Ref: 5042\7f2135362
+Ref: 5043\7f2135461
+Ref: S0271\7f2135461
+Ref: 5044\7f2135476
+Ref: 5045\7f2135497
+Ref: 5046\7f2135536
+Ref: 5047\7f2135594
+Ref: S0272\7f2135594
+Ref: 5048\7f2135609
+Ref: 5049\7f2135630
+Ref: 5050\7f2135947
+Ref: S0273\7f2135947
+Ref: 5051\7f2135961
+Ref: 5052\7f2136006
+Ref: 5053\7f2136062
+Ref: S0274\7f2136062
+Ref: 5054\7f2136078
+Ref: 5055\7f2136115
+Ref: 5056\7f2136150
+Ref: 5057\7f2136191
+Ref: 5058\7f2136902
+Ref: 5059\7f2136903
+Ref: 5060\7f2136903
+Ref: 5061\7f2136903
+Ref: 5062\7f2137030
+Ref: 5063\7f2137480
+Ref: 5064\7f2140228
+Ref: 5065\7f2141597
+Node: 12.2\7f2141792
+Ref: 5066\7f2141906
+Ref: 5067\7f2142231
+Node: 12.3\7f2144158
+Ref: 5068\7f2144287
+Ref: 5069\7f2144451
+Ref: 5070\7f2144452
+Ref: 5071\7f2145659
+Ref: S0275\7f2145659
+Ref: 5072\7f2145682
+Ref: 5073\7f2145746
+Ref: 5074\7f2145752
+Ref: 5075\7f2145791
+Ref: 5076\7f2145825
+Ref: 5077\7f2145867
+Ref: 5078\7f2145933
+Ref: 5079\7f2145939
+Ref: 5080\7f2145978
+Ref: 5081\7f2146012
+Ref: 5082\7f2146053
+Ref: 5083\7f2146111
+Ref: 5084\7f2146117
+Ref: 5085\7f2146156
+Ref: 5086\7f2146206
+Ref: S0276\7f2146206
+Ref: 5087\7f2146220
+Ref: 5088\7f2146243
+Ref: 5089\7f2146292
+Ref: S0277\7f2146292
+Ref: 5090\7f2146331
+Ref: 5091\7f2146349
+Ref: 5092\7f2146430
+Ref: S0278\7f2146430
+Ref: 5093\7f2146434
+Ref: 5094\7f2146457
+Ref: 5095\7f2146483
+Ref: 5096\7f2146496
+Ref: 5097\7f2146503
+Ref: 5098\7f2146543
+Ref: 5099\7f2146551
+Ref: 5100\7f2146556
+Ref: 5101\7f2146819
+Ref: 5102\7f2146820
+Ref: 5103\7f2146820
+Ref: 5104\7f2151867
+Ref: 5105\7f2154223
+Ref: 5106\7f2155972
+Ref: 5107\7f2160258
+Ref: 5108\7f2160259
+Ref: 5109\7f2160766
+Ref: 5110\7f2160768
+Ref: 5111\7f2160768
+Ref: 5112\7f2160768
+Ref: 5113\7f2160768
+Ref: 5114\7f2160768
+Ref: 5115\7f2160768
+Ref: 5116\7f2160768
+Ref: 5117\7f2170516
+Ref: 5118\7f2174974
+Ref: 5119\7f2175357
+Ref: 5120\7f2175597
+Ref: 5121\7f2181134
+Ref: 5122\7f2181421
+Ref: 5123\7f2181935
+Ref: 5124\7f2184444
+Ref: 5125\7f2184632
+Node: 12.4\7f2184984
+Ref: 5126\7f2185099
+Ref: 5127\7f2185099
+Ref: 5128\7f2185676
+Ref: S0279\7f2185676
+Ref: 5129\7f2185690
+Ref: 5130\7f2185717
+Ref: 5131\7f2185723
+Ref: 5132\7f2185739
+Ref: 5133\7f2185762
+Ref: 5134\7f2185796
+Ref: 5135\7f2185829
+Ref: 5136\7f2185856
+Ref: 5137\7f2185861
+Ref: 5138\7f2185883
+Ref: 5139\7f2185923
+Ref: 5140\7f2185998
+Ref: 5141\7f2186108
+Ref: 5142\7f2186796
+Ref: 5143\7f2188163
+Ref: 5144\7f2188296
+Ref: 5145\7f2188933
+Ref: 5146\7f2189736
+Ref: 5147\7f2189883
+Ref: 5148\7f2191168
+Ref: 5149\7f2191169
+Ref: 5150\7f2191169
+Ref: 5151\7f2192058
+Ref: 5152\7f2192373
+Ref: 5153\7f2192373
+Ref: 5154\7f2192651
+Ref: 5155\7f2193613
+Ref: 5156\7f2194945
+Ref: 5157\7f2195843
+Node: 12.5\7f2195980
+Ref: 5158\7f2196845
+Ref: S0280\7f2196845
+Ref: 5159\7f2196861
+Ref: 5160\7f2196905
+Ref: 5161\7f2197039
+Ref: S0281\7f2197039
+Ref: 5162\7f2197058
+Ref: 5163\7f2197078
+Ref: 5164\7f2197100
+Ref: 5165\7f2197143
+Ref: 5166\7f2197237
+Ref: S0282\7f2197237
+Ref: 5167\7f2197256
+Ref: 5168\7f2197276
+Ref: 5169\7f2197369
+Ref: S0283\7f2197369
+Ref: 5170\7f2197385
+Ref: 5171\7f2197427
+Ref: 5172\7f2197469
+Ref: 5173\7f2197512
+Ref: 5174\7f2197561
+Ref: 5175\7f2197603
+Ref: 5176\7f2197647
+Ref: 5177\7f2197697
+Ref: 5178\7f2197746
+Ref: 5179\7f2197786
+Ref: 5180\7f2197827
+Ref: 5181\7f2197908
+Ref: 5182\7f2197908
+Ref: 5183\7f2197908
+Ref: 5184\7f2197908
+Ref: 5185\7f2198390
+Ref: 5186\7f2198390
+Ref: 5187\7f2198390
+Ref: 5188\7f2198390
+Ref: 5189\7f2198699
+Ref: 5190\7f2198700
+Ref: 5191\7f2208074
+Node: 12.5.1\7f2208881
+Ref: 5192\7f2210224
+Ref: S0284\7f2210224
+Ref: 5193\7f2210404
+Ref: S0285\7f2210404
+Ref: 5194\7f2210459
+Ref: 5195\7f2210478
+Ref: 5196\7f2211113
+Ref: 5197\7f2211114
+Ref: 5198\7f2218620
+Ref: 5199\7f2222625
+Ref: 5200\7f2222640
+Ref: 5201\7f2224605
+Ref: 5202\7f2227348
+Ref: 5203\7f2228267
+Ref: 5204\7f2229680
+Ref: 5205\7f2230044
+Node: 12.5.2\7f2231432
+Ref: 5206\7f2232424
+Ref: S0286\7f2232424
+Ref: 5207\7f2232479
+Ref: S0287\7f2232479
+Ref: 5208\7f2232531
+Ref: S0288\7f2232531
+Ref: 5209\7f2232583
+Ref: S0289\7f2232583
+Ref: 5210\7f2232644
+Ref: S0290\7f2232644
+Ref: 5211\7f2232703
+Ref: S0291\7f2232703
+Node: 12.5.3\7f2233918
+Ref: 5212\7f2234584
+Ref: S0292\7f2234584
+Ref: 5213\7f2234588
+Ref: 5214\7f2235431
+Ref: 5215\7f2235530
+Ref: 5216\7f2236583
+Node: 12.5.4\7f2237334
+Ref: 5217\7f2238005
+Ref: S0293\7f2238005
+Ref: 5218\7f2238009
+Ref: 5219\7f2238195
+Ref: 5220\7f2240007
+Ref: 5221\7f2240697
+Ref: 5222\7f2241128
+Ref: 5223\7f2241703
+Node: 12.5.5\7f2242358
+Ref: 5224\7f2243414
+Ref: S0294\7f2243414
+Ref: 5225\7f2243418
+Ref: 5226\7f2244877
+Node: 12.6\7f2244923
+Ref: 5227\7f2245046
+Ref: 5228\7f2245046
+Ref: 5229\7f2245395
+Ref: S0295\7f2245395
+Ref: 5230\7f2245399
+Ref: 5231\7f2245455
+Ref: 5232\7f2245603
+Ref: S0296\7f2245603
+Ref: 5233\7f2245623
+Ref: 5234\7f2245652
+Ref: 5235\7f2245686
+Ref: 5236\7f2245818
+Ref: S0297\7f2245818
+Ref: 5237\7f2245838
+Ref: 5238\7f2245876
+Ref: 5239\7f2245910
+Ref: 5240\7f2245990
+Ref: S0298\7f2245990
+Ref: 5241\7f2245994
+Ref: 5242\7f2246045
+Ref: S0299\7f2246045
+Ref: 5243\7f2246049
+Ref: 5244\7f2247170
+Ref: 5245\7f2247650
+Ref: 5246\7f2247902
+Ref: 5247\7f2248173
+Ref: 5248\7f2248941
+Ref: 5249\7f2250270
+Ref: 5250\7f2250971
+Ref: 5251\7f2256260
+Ref: 5252\7f2262500
+Ref: 5253\7f2263101
+Ref: 5254\7f2263714
+Node: 12.7\7f2264442
+Ref: 5255\7f2264559
+Ref: 5256\7f2264559
+Ref: 5257\7f2264922
+Ref: S0300\7f2264922
+Ref: 5258\7f2264949
+Ref: 5259\7f2264992
+Ref: 5260\7f2264998
+Ref: 5261\7f2265045
+Ref: 5262\7f2265133
+Ref: S0301\7f2265133
+Ref: 5263\7f2265174
+Ref: 5264\7f2265205
+Ref: 5265\7f2265235
+Ref: 5266\7f2265354
+Ref: S0302\7f2265354
+Ref: 5267\7f2265368
+Ref: 5268\7f2265422
+Ref: 5269\7f2265637
+Ref: 5270\7f2269264
+Ref: 5271\7f2269739
+Ref: 5272\7f2273737
+Ref: 5273\7f2273905
+Ref: 5274\7f2274806
+Ref: 5275\7f2275499
+Node: 12.8\7f2275637
+Node: 13\7f2278141
+Node: 13.1\7f2279293
+Ref: 5276\7f2279522
+Ref: 5277\7f2280429
+Ref: 5278\7f2280430
+Ref: 5279\7f2280430
+Ref: 5280\7f2280960
+Ref: 5281\7f2282831
+Ref: S0303\7f2282831
+Ref: S0304\7f2282831
+Ref: 5282\7f2282836
+Ref: 5283\7f2282882
+Ref: 5284\7f2282929
+Ref: 5285\7f2282971
+Ref: 5286\7f2282999
+Ref: S0305\7f2282999
+Ref: 5287\7f2283003
+Ref: 5288\7f2283029
+Ref: 5289\7f2283041
+Ref: 5290\7f2283088
+Ref: 5291\7f2283267
+Ref: 5292\7f2287271
+Ref: 5293\7f2287272
+Ref: 5294\7f2287781
+Ref: 5295\7f2288074
+Ref: 5296\7f2288075
+Ref: 5297\7f2291995
+Ref: 5298\7f2291996
+Ref: 5299\7f2291996
+Ref: 5300\7f2292268
+Ref: 5301\7f2292270
+Ref: 5302\7f2292270
+Ref: 5303\7f2292270
+Ref: 5304\7f2297567
+Ref: 5305\7f2297569
+Ref: 5306\7f2297569
+Ref: 5307\7f2297569
+Ref: 5308\7f2308846
+Ref: 5309\7f2314491
+Ref: 5310\7f2314945
+Ref: 5311\7f2316405
+Ref: 5312\7f2316909
+Ref: 5313\7f2317142
+Ref: 5314\7f2317142
+Ref: 5315\7f2317144
+Ref: 5316\7f2317144
+Ref: 5317\7f2317144
+Ref: 5318\7f2317247
+Ref: 5319\7f2317800
+Ref: 5320\7f2318912
+Ref: 5321\7f2325688
+Ref: 5322\7f2326347
+Ref: 5323\7f2328780
+Ref: 5324\7f2331188
+Node: 13.1.1\7f2333092
+Ref: 5325\7f2333514
+Ref: 5326\7f2333611
+Ref: S0306\7f2333611
+Ref: 5327\7f2333629
+Ref: 5328\7f2333645
+Ref: 5329\7f2333683
+Ref: 5330\7f2333699
+Ref: 5331\7f2333766
+Ref: S0307\7f2333766
+Ref: 5332\7f2333778
+Ref: 5333\7f2333849
+Ref: S0308\7f2333849
+Ref: 5334\7f2333853
+Ref: 5335\7f2333861
+Ref: 5336\7f2333874
+Ref: 5337\7f2338964
+Ref: 5338\7f2339284
+Ref: 5339\7f2339495
+Ref: 5340\7f2339495
+Ref: 5341\7f2339690
+Ref: 5342\7f2344642
+Ref: 5343\7f2345009
+Ref: 5344\7f2345199
+Ref: 5345\7f2345384
+Ref: 5346\7f2349512
+Node: 13.2\7f2349545
+Ref: 5347\7f2350484
+Ref: 5348\7f2350486
+Ref: 5349\7f2350486
+Ref: 5350\7f2352156
+Ref: 5351\7f2354190
+Node: 13.3\7f2354530
+Ref: 5352\7f2354751
+Ref: 5353\7f2354751
+Ref: 5354\7f2354901
+Ref: 5355\7f2355334
+Ref: S0309\7f2355334
+Ref: 5356\7f2355354
+Ref: 5357\7f2355365
+Ref: 5358\7f2355390
+Ref: 5359\7f2355417
+Ref: 5360\7f2355428
+Ref: 5361\7f2355453
+Ref: 5362\7f2355690
+Ref: 5363\7f2355858
+Ref: 5364\7f2357090
+Ref: 5365\7f2357091
+Ref: 5366\7f2357293
+Ref: 5367\7f2357336
+Ref: 5368\7f2358390
+Ref: 5369\7f2358724
+Ref: 5370\7f2358725
+Ref: 5371\7f2358725
+Ref: 5372\7f2358725
+Ref: 5373\7f2358725
+Ref: 5374\7f2358725
+Ref: 5375\7f2358725
+Ref: 5376\7f2358725
+Ref: 5377\7f2358725
+Ref: 5378\7f2358725
+Ref: 5379\7f2358725
+Ref: 5380\7f2358725
+Ref: 5381\7f2358725
+Ref: 5382\7f2358725
+Ref: 5383\7f2358725
+Ref: 5384\7f2358901
+Ref: 5385\7f2358902
+Ref: 5386\7f2359088
+Ref: 5387\7f2359088
+Ref: 5388\7f2359158
+Ref: 5389\7f2360459
+Ref: 5390\7f2361658
+Ref: 5391\7f2361673
+Ref: 5392\7f2362455
+Ref: 5393\7f2362470
+Ref: 5394\7f2362591
+Ref: 5395\7f2362591
+Ref: 5396\7f2365090
+Ref: 5397\7f2366569
+Ref: 5398\7f2370689
+Ref: 5399\7f2370704
+Ref: 5400\7f2371811
+Ref: 5401\7f2371812
+Ref: 5402\7f2372309
+Ref: 5403\7f2372324
+Ref: 5404\7f2372809
+Ref: 5405\7f2372810
+Ref: 5406\7f2373033
+Ref: 5407\7f2373033
+Ref: 5408\7f2373182
+Ref: 5409\7f2373516
+Ref: 5410\7f2374801
+Ref: 5411\7f2376982
+Ref: 5412\7f2384229
+Ref: 5413\7f2384244
+Ref: 5414\7f2384593
+Ref: 5415\7f2384608
+Ref: 5416\7f2384796
+Ref: 5417\7f2384796
+Ref: 5418\7f2385210
+Ref: 5419\7f2385562
+Ref: 5420\7f2385577
+Ref: 5421\7f2386185
+Ref: 5422\7f2386187
+Ref: 5423\7f2386622
+Ref: 5424\7f2386622
+Ref: 5425\7f2391323
+Ref: 5426\7f2392737
+Ref: 5427\7f2396686
+Ref: 5428\7f2403389
+Ref: 5429\7f2404199
+Ref: 5430\7f2404214
+Ref: 5431\7f2406236
+Ref: 5432\7f2406236
+Ref: 5433\7f2408047
+Ref: 5434\7f2408047
+Ref: 5435\7f2408047
+Ref: 5436\7f2408385
+Ref: 5437\7f2408400
+Ref: 5438\7f2408534
+Ref: 5439\7f2408549
+Ref: 5440\7f2408774
+Ref: 5441\7f2408774
+Ref: 5442\7f2409342
+Ref: 5443\7f2410937
+Ref: 5444\7f2410952
+Ref: 5445\7f2412019
+Ref: 5446\7f2412034
+Ref: 5447\7f2413403
+Ref: 5448\7f2413418
+Ref: 5449\7f2413507
+Ref: 5450\7f2413508
+Ref: 5451\7f2413830
+Ref: 5452\7f2413830
+Ref: 5453\7f2420786
+Ref: 5454\7f2423752
+Ref: 5455\7f2424863
+Ref: 5456\7f2425387
+Node: 13.4\7f2426080
+Ref: 5457\7f2426410
+Ref: S0310\7f2426410
+Ref: 5458\7f2426442
+Ref: 5459\7f2426457
+Ref: 5460\7f2426509
+Ref: S0311\7f2426509
+Ref: 5461\7f2426513
+Ref: 5462\7f2426582
+Ref: 5463\7f2428151
+Ref: 5464\7f2428234
+Ref: 5465\7f2428377
+Ref: 5466\7f2428377
+Ref: 5467\7f2429638
+Ref: 5468\7f2432283
+Node: 13.5\7f2433246
+Ref: 5469\7f2433358
+Ref: 5470\7f2433358
+Ref: 5471\7f2433358
+Ref: 5472\7f2433358
+Ref: 5473\7f2433358
+Ref: 5474\7f2433358
+Ref: 5475\7f2433358
+Ref: 5476\7f2433358
+Ref: 5477\7f2433358
+Node: 13.5.1\7f2433725
+Ref: 5478\7f2434056
+Ref: 5479\7f2434583
+Ref: S0312\7f2434583
+Ref: 5480\7f2434615
+Ref: 5481\7f2434649
+Ref: 5482\7f2434675
+Ref: 5483\7f2434740
+Ref: S0313\7f2434740
+Ref: 5484\7f2434764
+Ref: 5485\7f2434778
+Ref: 5486\7f2434793
+Ref: 5487\7f2434806
+Ref: 5488\7f2434832
+Ref: S0314\7f2434832
+Ref: 5489\7f2434844
+Ref: 5490\7f2434872
+Ref: S0315\7f2434872
+Ref: 5491\7f2434884
+Ref: 5492\7f2434918
+Ref: S0316\7f2434918
+Ref: 5493\7f2434930
+Ref: 5494\7f2435196
+Ref: 5495\7f2435196
+Ref: 5496\7f2435196
+Ref: 5497\7f2435196
+Ref: 5498\7f2441774
+Ref: 5499\7f2442488
+Ref: 5500\7f2449436
+Ref: 5501\7f2450183
+Node: 13.5.2\7f2450398
+Ref: 5502\7f2450590
+Ref: 5503\7f2450898
+Ref: 5504\7f2450913
+Ref: 5505\7f2452025
+Ref: 5506\7f2452040
+Ref: 5507\7f2452687
+Ref: 5508\7f2452702
+Ref: 5509\7f2453832
+Ref: 5510\7f2453832
+Ref: 5511\7f2455343
+Node: 13.5.3\7f2455726
+Ref: 5512\7f2456676
+Ref: 5513\7f2456763
+Ref: 5514\7f2456765
+Ref: 5515\7f2456765
+Ref: 5516\7f2457000
+Ref: 5517\7f2457002
+Ref: 5518\7f2457002
+Ref: 5519\7f2457216
+Ref: 5520\7f2457231
+Ref: 5521\7f2457346
+Ref: 5522\7f2457348
+Ref: 5523\7f2457530
+Ref: 5524\7f2457530
+Ref: 5525\7f2457879
+Ref: 5526\7f2459019
+Ref: 5527\7f2460358
+Node: 13.6\7f2460593
+Ref: 5528\7f2460755
+Ref: 5529\7f2460755
+Node: 13.7\7f2462431
+Ref: 5530\7f2462949
+Ref: 5531\7f2463012
+Ref: 5532\7f2463064
+Ref: 5533\7f2463176
+Ref: 5534\7f2463240
+Ref: 5535\7f2463306
+Ref: 5536\7f2463374
+Ref: 5537\7f2463445
+Ref: 5538\7f2463507
+Ref: 5539\7f2463578
+Ref: 5540\7f2463646
+Ref: 5541\7f2463718
+Ref: 5542\7f2463845
+Ref: 5543\7f2463883
+Ref: 5544\7f2463928
+Ref: 5545\7f2463987
+Ref: 5546\7f2464061
+Ref: 5547\7f2464159
+Ref: 5548\7f2464880
+Ref: 5549\7f2464894
+Ref: 5550\7f2464912
+Ref: 5551\7f2464933
+Ref: 5552\7f2465084
+Ref: 5553\7f2465154
+Ref: 5554\7f2465265
+Ref: 5555\7f2465369
+Ref: 5556\7f2469982
+Ref: 5557\7f2473183
+Ref: 5558\7f2474950
+Node: 13.7.1\7f2475810
+Ref: 5559\7f2476103
+Ref: 5560\7f2476193
+Ref: 5561\7f2476260
+Ref: 5562\7f2476338
+Ref: 5563\7f2476449
+Ref: 5564\7f2476609
+Ref: 5565\7f2477374
+Ref: 5566\7f2477434
+Ref: 5567\7f2477543
+Ref: 5568\7f2478343
+Ref: 5569\7f2478345
+Ref: 5570\7f2479464
+Ref: 5571\7f2481209
+Node: 13.7.2\7f2481378
+Ref: 5572\7f2481669
+Ref: 5573\7f2481937
+Ref: 5574\7f2482045
+Ref: 5575\7f2482497
+Node: 13.8\7f2485478
+Ref: 5576\7f2485611
+Ref: 5577\7f2485798
+Ref: S0317\7f2485798
+Ref: 5578\7f2485802
+Ref: 5579\7f2486499
+Ref: 5580\7f2487171
+Ref: 5581\7f2487171
+Ref: 5582\7f2489444
+Ref: 5583\7f2489712
+Ref: 5584\7f2489725
+Node: 13.9\7f2489848
+Ref: 5585\7f2489988
+Ref: 5586\7f2489988
+Ref: 5587\7f2489989
+Ref: 5588\7f2489989
+Ref: 5589\7f2489989
+Ref: 5590\7f2490350
+Ref: 5591\7f2491593
+Ref: 5592\7f2491593
+Ref: 5593\7f2496363
+Ref: 5594\7f2496592
+Ref: 5595\7f2496592
+Node: 13.9.1\7f2497779
+Ref: 5596\7f2498238
+Ref: 5597\7f2498444
+Ref: 5598\7f2498444
+Ref: 5599\7f2498742
+Ref: 5600\7f2500564
+Ref: 5601\7f2500810
+Ref: 5602\7f2502319
+Ref: 5603\7f2502319
+Ref: 5604\7f2502578
+Ref: 5605\7f2502580
+Ref: 5606\7f2504314
+Ref: 5607\7f2510376
+Ref: 5608\7f2513001
+Ref: 5609\7f2513147
+Node: 13.9.2\7f2513723
+Ref: 5610\7f2514171
+Ref: 5611\7f2514186
+Ref: 5612\7f2514348
+Ref: 5613\7f2517070
+Node: 13.10\7f2517735
+Ref: 5614\7f2518207
+Ref: 5615\7f2518222
+Ref: 5616\7f2518514
+Ref: 5617\7f2519585
+Node: 13.11\7f2521535
+Ref: 5618\7f2521663
+Ref: 5619\7f2521664
+Ref: 5620\7f2521664
+Ref: 5621\7f2521664
+Ref: 5622\7f2524029
+Ref: 5623\7f2524166
+Ref: 5624\7f2524350
+Ref: 5625\7f2524612
+Ref: 5626\7f2524874
+Ref: 5627\7f2525256
+Ref: 5628\7f2525256
+Ref: 5629\7f2525329
+Ref: 5630\7f2525329
+Ref: 5631\7f2525329
+Ref: 5632\7f2525873
+Ref: 5633\7f2525888
+Ref: 5634\7f2526020
+Ref: 5635\7f2526035
+Ref: 5636\7f2526709
+Ref: 5637\7f2526709
+Ref: 5638\7f2526709
+Ref: 5639\7f2526709
+Ref: 5640\7f2526909
+Ref: 5641\7f2526909
+Ref: 5642\7f2526909
+Ref: 5643\7f2526909
+Ref: 5644\7f2528660
+Ref: 5645\7f2528846
+Ref: 5646\7f2528848
+Ref: 5647\7f2528848
+Ref: 5648\7f2529794
+Ref: 5649\7f2529804
+Ref: 5650\7f2530227
+Ref: 5651\7f2531463
+Ref: 5652\7f2532150
+Ref: 5653\7f2536197
+Ref: 5654\7f2536197
+Ref: 5655\7f2536199
+Ref: 5656\7f2550521
+Ref: 5657\7f2551665
+Ref: 5658\7f2552253
+Node: 13.11.1\7f2554198
+Ref: 5659\7f2554671
+Ref: 5660\7f2554686
+Ref: 5661\7f2555291
+Ref: 5662\7f2555306
+Ref: 5663\7f2557092
+Node: 13.11.2\7f2557155
+Ref: 5664\7f2557320
+Ref: 5665\7f2557320
+Ref: 5666\7f2557321
+Ref: 5667\7f2557321
+Ref: 5668\7f2557321
+Ref: 5669\7f2557732
+Ref: 5670\7f2558379
+Ref: 5671\7f2560089
+Ref: 5672\7f2560090
+Ref: 5673\7f2560090
+Ref: 5674\7f2560090
+Ref: 5675\7f2560303
+Ref: 5676\7f2560632
+Ref: 5677\7f2560632
+Ref: 5678\7f2560721
+Ref: 5679\7f2560721
+Ref: 5680\7f2561421
+Ref: 5681\7f2561422
+Node: 13.11.3\7f2565710
+Ref: 5682\7f2566141
+Ref: 5683\7f2566142
+Ref: 5684\7f2566170
+Ref: 5685\7f2566254
+Ref: S0318\7f2566254
+Ref: 5686\7f2566272
+Ref: 5687\7f2566971
+Ref: 5688\7f2566971
+Ref: 5689\7f2566971
+Ref: 5690\7f2568462
+Ref: 5691\7f2568462
+Ref: 5692\7f2572381
+Ref: 5693\7f2573297
+Node: 13.11.4\7f2574071
+Ref: 5694\7f2574651
+Ref: 5695\7f2574755
+Ref: 5696\7f2574864
+Ref: 5697\7f2574931
+Ref: 5698\7f2575049
+Ref: 5699\7f2575291
+Ref: 5700\7f2575431
+Ref: 5701\7f2575589
+Ref: 5702\7f2576001
+Ref: 5703\7f2576256
+Ref: 5704\7f2576430
+Ref: 5705\7f2576716
+Ref: 5706\7f2577035
+Ref: 5707\7f2577329
+Ref: 5708\7f2577330
+Ref: 5709\7f2577330
+Ref: 5710\7f2577330
+Ref: 5711\7f2577330
+Ref: 5712\7f2578325
+Ref: 5713\7f2580273
+Ref: 5714\7f2580273
+Ref: 5715\7f2580768
+Ref: 5716\7f2581429
+Ref: 5717\7f2581429
+Ref: 5718\7f2581540
+Ref: 5719\7f2581540
+Ref: 5720\7f2581627
+Ref: 5721\7f2582954
+Ref: 5722\7f2582954
+Ref: 5723\7f2582954
+Ref: 5724\7f2586726
+Node: 13.11.5\7f2586802
+Ref: 5725\7f2587226
+Ref: 5726\7f2587767
+Ref: 5727\7f2589385
+Node: 13.11.6\7f2589424
+Node: 13.12\7f2595947
+Ref: 5728\7f2596532
+Ref: 5729\7f2596533
+Ref: 5730\7f2596546
+Ref: 5731\7f2596559
+Ref: 5732\7f2596625
+Ref: S0319\7f2596625
+Ref: 5733\7f2596642
+Ref: 5734\7f2596686
+Ref: 5735\7f2596700
+Ref: 5736\7f2596808
+Ref: S0320\7f2596808
+Ref: 5737\7f2596812
+Ref: 5738\7f2596825
+Ref: 5739\7f2596888
+Ref: 5740\7f2597321
+Ref: 5741\7f2597322
+Ref: 5742\7f2600867
+Ref: 5743\7f2600868
+Ref: 5744\7f2600885
+Ref: 5745\7f2600907
+Ref: 5746\7f2601548
+Ref: 5747\7f2601549
+Ref: 5748\7f2602963
+Ref: 5749\7f2603130
+Node: 13.12.1\7f2604506
+Ref: 5750\7f2604901
+Ref: 5751\7f2604902
+Ref: 5752\7f2605612
+Ref: 5753\7f2605613
+Ref: 5754\7f2605891
+Ref: 5755\7f2605892
+Ref: 5756\7f2608345
+Ref: 5757\7f2608346
+Ref: 5758\7f2608613
+Ref: 5759\7f2608614
+Ref: 5760\7f2608995
+Ref: 5761\7f2608996
+Ref: 5762\7f2610377
+Ref: 5763\7f2610378
+Ref: 5764\7f2610522
+Ref: 5765\7f2610523
+Ref: 5766\7f2610716
+Ref: 5767\7f2610717
+Ref: 5768\7f2610896
+Ref: 5769\7f2610897
+Ref: 5770\7f2613881
+Ref: 5771\7f2614477
+Ref: 5772\7f2614872
+Node: 13.13\7f2615201
+Ref: 5773\7f2615306
+Ref: 5774\7f2615306
+Ref: 5775\7f2616050
+Node: 13.13.1\7f2616173
+Ref: 5776\7f2617020
+Ref: 5777\7f2617077
+Ref: 5778\7f2617127
+Ref: 5779\7f2617313
+Ref: 5780\7f2617373
+Ref: 5781\7f2617445
+Ref: 5782\7f2617555
+Ref: 5783\7f2617679
+Ref: 5784\7f2617858
+Ref: 5785\7f2620923
+Node: 13.13.2\7f2621396
+Ref: 5786\7f2621960
+Ref: 5787\7f2621975
+Ref: 5788\7f2622746
+Ref: 5789\7f2622746
+Ref: 5790\7f2624656
+Ref: 5791\7f2626270
+Ref: 5792\7f2626285
+Ref: 5793\7f2626627
+Ref: 5794\7f2626642
+Ref: 5795\7f2632557
+Ref: 5796\7f2632572
+Ref: 5797\7f2633041
+Ref: 5798\7f2633056
+Ref: 5799\7f2633947
+Ref: 5800\7f2633962
+Ref: 5801\7f2634498
+Ref: 5802\7f2634513
+Ref: 5803\7f2637684
+Ref: 5804\7f2637699
+Ref: 5805\7f2638771
+Ref: 5806\7f2638786
+Ref: 5807\7f2640007
+Ref: 5808\7f2640008
+Ref: 5809\7f2640255
+Ref: 5810\7f2641984
+Ref: 5811\7f2642284
+Ref: 5812\7f2642595
+Ref: 5813\7f2642596
+Ref: 5814\7f2642596
+Ref: 5815\7f2642596
+Ref: 5816\7f2642596
+Ref: 5817\7f2642596
+Ref: 5818\7f2642596
+Ref: 5819\7f2642596
+Ref: 5820\7f2643006
+Ref: 5821\7f2643008
+Ref: 5822\7f2643008
+Ref: 5823\7f2643008
+Ref: 5824\7f2643008
+Ref: 5825\7f2643008
+Ref: 5826\7f2643008
+Ref: 5827\7f2643008
+Ref: 5828\7f2646648
+Ref: 5829\7f2651847
+Ref: 5830\7f2651848
+Ref: 5831\7f2652898
+Ref: 5832\7f2658743
+Ref: 5833\7f2659951
+Ref: 5834\7f2663686
+Ref: 5835\7f2664147
+Node: 13.14\7f2666014
+Ref: 5836\7f2674659
+Ref: 5837\7f2674659
+Ref: 5838\7f2675381
+Ref: 5839\7f2675780
+Ref: 5840\7f2675985
+Ref: 5841\7f2678828
+Ref: 5842\7f2678968
+Ref: 5843\7f2679304
+Ref: 5844\7f2679995
+Ref: 5845\7f2680202
+Ref: 5846\7f2682205
+Ref: 5847\7f2682302
+Ref: 5848\7f2682779
+Ref: 5849\7f2683017
+Ref: 5850\7f2683265
+Ref: 5851\7f2685282
+Ref: 5852\7f2685283
+Ref: 5853\7f2686817
+Ref: 5854\7f2686818
+Ref: 5855\7f2687443
+Ref: 5856\7f2688460
+Ref: 5857\7f2688603
+Ref: 5858\7f2689187
+Ref: 5859\7f2689587
+Ref: 5860\7f2689889
+Ref: 5861\7f2690842
+Ref: 5862\7f2691105
+Ref: 5863\7f2691164
+Ref: 5864\7f2691166
+Ref: 5865\7f2691409
+Ref: 5866\7f2691411
+Ref: 5867\7f2698076
+Ref: 5868\7f2699823
+Ref: 5869\7f2699883
+Ref: 5870\7f2700883
+Ref: 5871\7f2705158
+Ref: 5872\7f2706530
+Node: Annex A\7f2707540
+Ref: 5873\7f2707700
+Ref: 5874\7f2707700
+Ref: 5875\7f2719186
+Node: A.1\7f2724137
+Ref: 5876\7f2724398
+Ref: 5877\7f2724606
+Ref: 5878\7f2725119
+Ref: 5879\7f2725191
+Ref: 5880\7f2726481
+Ref: 5881\7f2726542
+Ref: 5882\7f2726603
+Ref: 5883\7f2728498
+Ref: 5884\7f2731254
+Ref: 5885\7f2734999
+Ref: 5886\7f2735389
+Ref: 5887\7f2735524
+Ref: 5888\7f2735580
+Ref: 5889\7f2735663
+Ref: 5890\7f2736573
+Ref: 5891\7f2736814
+Ref: 5892\7f2737055
+Ref: 5893\7f2737296
+Ref: 5894\7f2737333
+Ref: 5895\7f2737370
+Ref: 5896\7f2737407
+Ref: 5897\7f2738401
+Ref: 5898\7f2742604
+Ref: 5899\7f2743414
+Node: A.2\7f2744290
+Ref: 5900\7f2744510
+Ref: 5901\7f2745975
+Node: A.3\7f2746010
+Ref: 5902\7f2746774
+Node: A.3.1\7f2747378
+Ref: 5903\7f2747699
+Ref: 5904\7f2747893
+Ref: 5905\7f2748107
+Ref: 5906\7f2749056
+Node: A.3.2\7f2749131
+Ref: 5907\7f2749542
+Ref: 5908\7f2749664
+Ref: 5909\7f2749739
+Ref: 5910\7f2749814
+Ref: 5911\7f2749889
+Ref: 5912\7f2749964
+Ref: 5913\7f2750039
+Ref: 5914\7f2750114
+Ref: 5915\7f2750189
+Ref: 5916\7f2750307
+Ref: 5917\7f2750382
+Ref: 5918\7f2750457
+Ref: 5919\7f2750532
+Ref: 5920\7f2750607
+Ref: 5921\7f2750682
+Ref: 5922\7f2750757
+Ref: 5923\7f2750836
+Ref: 5924\7f2750970
+Ref: 5925\7f2751035
+Ref: 5926\7f2751100
+Ref: 5927\7f2751168
+Ref: 5928\7f2751227
+Ref: 5929\7f2751286
+Ref: 5930\7f2751422
+Ref: 5931\7f2751518
+Ref: 5932\7f2751583
+Ref: 5933\7f2751652
+Ref: 5934\7f2751796
+Ref: 5935\7f2752959
+Ref: 5936\7f2753150
+Ref: 5937\7f2753343
+Ref: 5938\7f2753594
+Ref: 5939\7f2753820
+Ref: 5940\7f2754063
+Ref: 5941\7f2754322
+Ref: 5942\7f2754513
+Ref: 5943\7f2754747
+Ref: 5944\7f2754941
+Ref: 5945\7f2760290
+Ref: 5946\7f2760463
+Node: A.3.3\7f2761730
+Ref: 5947\7f2762490
+Ref: 5948\7f2762552
+Ref: 5949\7f2762560
+Ref: 5950\7f2762632
+Ref: 5951\7f2762704
+Ref: 5952\7f2762776
+Ref: 5953\7f2762848
+Ref: 5954\7f2762920
+Ref: 5955\7f2762992
+Ref: 5956\7f2763064
+Ref: 5957\7f2763136
+Ref: 5958\7f2763208
+Ref: 5959\7f2763280
+Ref: 5960\7f2763353
+Ref: 5961\7f2763426
+Ref: 5962\7f2763499
+Ref: 5963\7f2763572
+Ref: 5964\7f2763645
+Ref: 5965\7f2763721
+Ref: 5966\7f2763794
+Ref: 5967\7f2763867
+Ref: 5968\7f2763940
+Ref: 5969\7f2764013
+Ref: 5970\7f2764086
+Ref: 5971\7f2764159
+Ref: 5972\7f2764232
+Ref: 5973\7f2764305
+Ref: 5974\7f2764378
+Ref: 5975\7f2764451
+Ref: 5976\7f2764524
+Ref: 5977\7f2764597
+Ref: 5978\7f2764670
+Ref: 5979\7f2764743
+Ref: 5980\7f2764816
+Ref: 5981\7f2764931
+Ref: 5982\7f2765012
+Ref: 5983\7f2765093
+Ref: 5984\7f2765174
+Ref: 5985\7f2765255
+Ref: 5986\7f2765336
+Ref: 5987\7f2765417
+Ref: 5988\7f2765498
+Ref: 5989\7f2765579
+Ref: 5990\7f2765660
+Ref: 5991\7f2765741
+Ref: 5992\7f2765822
+Ref: 5993\7f2765903
+Ref: 5994\7f2765984
+Ref: 5995\7f2766065
+Ref: 5996\7f2766123
+Ref: 5997\7f2766204
+Ref: 5998\7f2766365
+Ref: 5999\7f2766446
+Ref: 6000\7f2766527
+Ref: 6001\7f2766608
+Ref: 6002\7f2766689
+Ref: 6003\7f2766770
+Ref: 6004\7f2766851
+Ref: 6005\7f2767007
+Ref: 6006\7f2767088
+Ref: 6007\7f2767169
+Ref: 6008\7f2767250
+Ref: 6009\7f2767331
+Ref: 6010\7f2767416
+Ref: 6011\7f2767497
+Ref: 6012\7f2767578
+Ref: 6013\7f2767659
+Ref: 6014\7f2767740
+Ref: 6015\7f2767822
+Ref: 6016\7f2767904
+Ref: 6017\7f2767986
+Ref: 6018\7f2768068
+Ref: 6019\7f2768150
+Ref: 6020\7f2768232
+Ref: 6021\7f2768314
+Ref: 6022\7f2768396
+Ref: 6023\7f2768478
+Ref: 6024\7f2768560
+Ref: 6025\7f2768642
+Ref: 6026\7f2768728
+Ref: 6027\7f2768810
+Ref: 6028\7f2768892
+Ref: 6029\7f2768974
+Ref: 6030\7f2769056
+Ref: 6031\7f2769138
+Ref: 6032\7f2769220
+Ref: 6033\7f2769302
+Ref: 6034\7f2769384
+Ref: 6035\7f2769466
+Ref: 6036\7f2769548
+Ref: 6037\7f2769630
+Ref: 6038\7f2769712
+Ref: 6039\7f2769794
+Ref: 6040\7f2769876
+Ref: 6041\7f2769958
+Ref: 6042\7f2770068
+Ref: 6043\7f2770077
+Ref: 6044\7f2770131
+Ref: 6045\7f2770185
+Ref: 6046\7f2770239
+Ref: 6047\7f2770297
+Ref: 6048\7f2770371
+Ref: 6049\7f2770445
+Ref: 6050\7f2770519
+Ref: 6051\7f2770593
+Ref: 6052\7f2770667
+Ref: 6053\7f2770741
+Ref: 6054\7f2770815
+Ref: 6055\7f2770889
+Ref: 6056\7f2770963
+Ref: 6057\7f2771037
+Ref: 6058\7f2771111
+Ref: 6059\7f2771185
+Ref: 6060\7f2771259
+Ref: 6061\7f2771333
+Ref: 6062\7f2771407
+Ref: 6063\7f2771485
+Ref: 6064\7f2771559
+Ref: 6065\7f2771633
+Ref: 6066\7f2771707
+Ref: 6067\7f2771781
+Ref: 6068\7f2771855
+Ref: 6069\7f2771929
+Ref: 6070\7f2772003
+Ref: 6071\7f2772081
+Ref: 6072\7f2772155
+Ref: 6073\7f2772229
+Ref: 6074\7f2772303
+Ref: 6075\7f2772377
+Ref: 6076\7f2772451
+Ref: 6077\7f2772525
+Ref: 6078\7f2772599
+Ref: 6079\7f2772800
+Ref: 6080\7f2772886
+Ref: 6081\7f2772958
+Ref: 6082\7f2773044
+Ref: 6083\7f2773130
+Ref: 6084\7f2773216
+Ref: 6085\7f2773302
+Ref: 6086\7f2773388
+Ref: 6087\7f2773474
+Ref: 6088\7f2773560
+Ref: 6089\7f2773646
+Ref: 6090\7f2773732
+Ref: 6091\7f2773818
+Ref: 6092\7f2773904
+Ref: 6093\7f2773990
+Ref: 6094\7f2774070
+Ref: 6095\7f2774156
+Ref: 6096\7f2774304
+Ref: 6097\7f2774390
+Ref: 6098\7f2774459
+Ref: 6099\7f2774545
+Ref: 6100\7f2774631
+Ref: 6101\7f2774717
+Ref: 6102\7f2774803
+Ref: 6103\7f2774889
+Ref: 6104\7f2774975
+Ref: 6105\7f2775045
+Ref: 6106\7f2775131
+Ref: 6107\7f2775217
+Ref: 6108\7f2775303
+Ref: 6109\7f2775389
+Ref: 6110\7f2775475
+Ref: 6111\7f2775561
+Ref: 6112\7f2775647
+Ref: 6113\7f2775733
+Ref: 6114\7f2775881
+Ref: 6115\7f2775967
+Ref: 6116\7f2776053
+Ref: 6117\7f2776139
+Ref: 6118\7f2776225
+Ref: 6119\7f2776311
+Ref: 6120\7f2776397
+Ref: 6121\7f2776483
+Ref: 6122\7f2776569
+Ref: 6123\7f2776655
+Ref: 6124\7f2776741
+Ref: 6125\7f2776827
+Ref: 6126\7f2776913
+Ref: 6127\7f2776999
+Ref: 6128\7f2777085
+Ref: 6129\7f2777171
+Ref: 6130\7f2777319
+Ref: 6131\7f2777405
+Ref: 6132\7f2777491
+Ref: 6133\7f2777577
+Ref: 6134\7f2777663
+Ref: 6135\7f2777749
+Ref: 6136\7f2777835
+Ref: 6137\7f2777921
+Ref: 6138\7f2778007
+Ref: 6139\7f2778093
+Ref: 6140\7f2778179
+Ref: 6141\7f2778265
+Ref: 6142\7f2778351
+Ref: 6143\7f2778437
+Ref: 6144\7f2778523
+Ref: 6145\7f2778609
+Ref: 6146\7f2778757
+Ref: 6147\7f2778843
+Ref: 6148\7f2778929
+Ref: 6149\7f2779015
+Ref: 6150\7f2779101
+Ref: 6151\7f2779187
+Ref: 6152\7f2779273
+Ref: 6153\7f2779359
+Ref: 6154\7f2779445
+Ref: 6155\7f2779531
+Ref: 6156\7f2779617
+Ref: 6157\7f2779703
+Ref: 6158\7f2779789
+Ref: 6159\7f2779875
+Ref: 6160\7f2779961
+Ref: 6161\7f2780047
+Ref: 6162\7f2780195
+Ref: 6163\7f2780281
+Ref: 6164\7f2780367
+Ref: 6165\7f2780453
+Ref: 6166\7f2780539
+Ref: 6167\7f2780625
+Ref: 6168\7f2780711
+Ref: 6169\7f2780797
+Ref: 6170\7f2780883
+Ref: 6171\7f2780969
+Ref: 6172\7f2781055
+Ref: 6173\7f2781141
+Ref: 6174\7f2781227
+Ref: 6175\7f2781313
+Ref: 6176\7f2781399
+Ref: 6177\7f2781485
+Node: A.3.4\7f2782144
+Ref: 6178\7f2782502
+Ref: 6179\7f2782559
+Ref: 6180\7f2782637
+Ref: 6181\7f2782715
+Ref: 6182\7f2782793
+Ref: 6183\7f2782871
+Ref: 6184\7f2782965
+Ref: 6185\7f2783061
+Ref: 6186\7f2783141
+Ref: 6187\7f2783218
+Ref: 6188\7f2783319
+Ref: 6189\7f2783414
+Ref: 6190\7f2783520
+Ref: 6191\7f2783625
+Ref: 6192\7f2783781
+Ref: 6193\7f2783932
+Ref: 6194\7f2784094
+Ref: 6195\7f2784250
+Ref: 6196\7f2784432
+Ref: 6197\7f2789349
+Node: A.3.5\7f2789475
+Ref: 6198\7f2790044
+Ref: 6199\7f2790123
+Ref: 6200\7f2790182
+Ref: 6201\7f2790255
+Ref: 6202\7f2790327
+Ref: 6203\7f2790398
+Ref: 6204\7f2790469
+Ref: 6205\7f2790541
+Ref: 6206\7f2790649
+Ref: 6207\7f2790733
+Ref: 6208\7f2790812
+Ref: 6209\7f2790886
+Ref: 6210\7f2790968
+Ref: 6211\7f2791039
+Ref: 6212\7f2791118
+Ref: 6213\7f2791206
+Ref: 6214\7f2791278
+Ref: 6215\7f2791352
+Ref: 6216\7f2791425
+Ref: 6217\7f2791504
+Ref: 6218\7f2791571
+Ref: 6219\7f2799870
+Node: A.3.6\7f2799927
+Ref: 6220\7f2800155
+Ref: 6221\7f2800446
+Node: A.4\7f2800508
+Ref: 6222\7f2801291
+Node: A.4.1\7f2801986
+Ref: 6223\7f2802295
+Ref: 6224\7f2802395
+Ref: 6225\7f2802443
+Ref: 6226\7f2802496
+Ref: 6227\7f2802562
+Ref: 6228\7f2802581
+Ref: 6229\7f2802596
+Ref: 6230\7f2802609
+Ref: 6231\7f2802656
+Ref: 6232\7f2802706
+Ref: 6233\7f2802755
+Ref: 6234\7f2802801
+Ref: 6235\7f2802849
+Ref: 6236\7f2803029
+Node: A.4.2\7f2803438
+Ref: 6237\7f2803868
+Ref: 6238\7f2804027
+Ref: 6239\7f2804119
+Ref: 6240\7f2804175
+Ref: 6241\7f2804359
+Ref: 6242\7f2804445
+Ref: 6243\7f2804527
+Ref: 6244\7f2804609
+Ref: 6245\7f2805164
+Ref: 6246\7f2805295
+Ref: 6247\7f2805655
+Ref: 6248\7f2805706
+Ref: 6249\7f2805791
+Ref: 6250\7f2805872
+Ref: 6251\7f2806049
+Ref: 6252\7f2806164
+Ref: 6253\7f2806287
+Ref: 6254\7f2806352
+Ref: 6255\7f2806456
+Ref: 6256\7f2806550
+Ref: 6257\7f2806644
+Ref: 6258\7f2810659
+Ref: 6259\7f2810776
+Ref: 6260\7f2812929
+Ref: 6261\7f2813683
+Node: A.4.3\7f2814291
+Ref: 6262\7f2816070
+Ref: 6263\7f2816231
+Ref: 6264\7f2816565
+Ref: 6265\7f2816902
+Ref: 6266\7f2817198
+Ref: 6267\7f2817497
+Ref: 6268\7f2817784
+Ref: 6269\7f2818082
+Ref: 6270\7f2818363
+Ref: 6271\7f2818572
+Ref: 6272\7f2818725
+Ref: 6273\7f2818965
+Ref: 6274\7f2819159
+Ref: 6275\7f2819324
+Ref: 6276\7f2819652
+Ref: 6277\7f2819970
+Ref: 6278\7f2820115
+Ref: 6279\7f2820239
+Ref: 6280\7f2820393
+Ref: 6281\7f2820572
+Ref: 6282\7f2820822
+Ref: 6283\7f2821256
+Ref: 6284\7f2821430
+Ref: 6285\7f2821645
+Ref: 6286\7f2821828
+Ref: 6287\7f2822055
+Ref: 6288\7f2822227
+Ref: 6289\7f2822532
+Ref: 6290\7f2822651
+Ref: 6291\7f2822864
+Ref: 6292\7f2823048
+Ref: 6293\7f2823336
+Ref: 6294\7f2823509
+Ref: 6295\7f2823721
+Ref: 6296\7f2823894
+Ref: 6297\7f2844263
+Ref: 6298\7f2844515
+Ref: 6299\7f2845555
+Node: A.4.4\7f2846169
+Ref: 6300\7f2847738
+Ref: 6301\7f2847917
+Ref: 6302\7f2847952
+Ref: 6303\7f2848015
+Ref: 6304\7f2848051
+Ref: 6305\7f2848125
+Ref: 6306\7f2848195
+Ref: 6307\7f2848342
+Ref: 6308\7f2848514
+Ref: 6309\7f2848626
+Ref: 6310\7f2848808
+Ref: 6311\7f2848977
+Ref: 6312\7f2849180
+Ref: 6313\7f2849383
+Ref: 6314\7f2849589
+Ref: 6315\7f2849796
+Ref: 6316\7f2849988
+Ref: 6317\7f2850172
+Ref: 6318\7f2850907
+Ref: 6319\7f2851052
+Ref: 6320\7f2851247
+Ref: 6321\7f2851465
+Ref: 6322\7f2851694
+Ref: 6323\7f2853441
+Ref: 6324\7f2853805
+Ref: 6325\7f2854128
+Ref: 6326\7f2854451
+Ref: 6327\7f2854761
+Ref: 6328\7f2855085
+Ref: 6329\7f2855389
+Ref: 6330\7f2855618
+Ref: 6331\7f2855788
+Ref: 6332\7f2856050
+Ref: 6333\7f2856264
+Ref: 6334\7f2856446
+Ref: 6335\7f2856800
+Ref: 6336\7f2857144
+Ref: 6337\7f2857314
+Ref: 6338\7f2857452
+Ref: 6339\7f2857631
+Ref: 6340\7f2857827
+Ref: 6341\7f2858178
+Ref: 6342\7f2858500
+Ref: 6343\7f2858765
+Ref: 6344\7f2859000
+Ref: 6345\7f2859281
+Ref: 6346\7f2859532
+Ref: 6347\7f2859732
+Ref: 6348\7f2859943
+Ref: 6349\7f2860083
+Ref: 6350\7f2860195
+Ref: 6351\7f2860407
+Ref: 6352\7f2860588
+Ref: 6353\7f2860849
+Ref: 6354\7f2861080
+Ref: 6355\7f2861341
+Ref: 6356\7f2862018
+Ref: 6357\7f2862226
+Ref: 6358\7f2862431
+Ref: 6359\7f2870209
+Ref: 6360\7f2870736
+Ref: 6361\7f2871901
+Node: A.4.5\7f2872379
+Ref: 6362\7f2873652
+Ref: 6363\7f2873777
+Ref: 6364\7f2873875
+Ref: 6365\7f2873951
+Ref: 6366\7f2874021
+Ref: 6367\7f2874075
+Ref: 6368\7f2874190
+Ref: 6369\7f2874288
+Ref: 6370\7f2874387
+Ref: 6371\7f2874498
+Ref: 6372\7f2874622
+Ref: 6373\7f2874747
+Ref: 6374\7f2874862
+Ref: 6375\7f2875518
+Ref: 6376\7f2875656
+Ref: 6377\7f2875844
+Ref: 6378\7f2876052
+Ref: 6379\7f2876272
+Ref: 6380\7f2877935
+Ref: 6381\7f2878283
+Ref: 6382\7f2878590
+Ref: 6383\7f2878899
+Ref: 6384\7f2879196
+Ref: 6385\7f2879505
+Ref: 6386\7f2879785
+Ref: 6387\7f2880004
+Ref: 6388\7f2880167
+Ref: 6389\7f2880416
+Ref: 6390\7f2880620
+Ref: 6391\7f2880795
+Ref: 6392\7f2881133
+Ref: 6393\7f2881461
+Ref: 6394\7f2881626
+Ref: 6395\7f2881760
+Ref: 6396\7f2881934
+Ref: 6397\7f2882123
+Ref: 6398\7f2882393
+Ref: 6399\7f2882634
+Ref: 6400\7f2882828
+Ref: 6401\7f2882992
+Ref: 6402\7f2883198
+Ref: 6403\7f2883374
+Ref: 6404\7f2883566
+Ref: 6405\7f2883728
+Ref: 6406\7f2883867
+Ref: 6407\7f2883975
+Ref: 6408\7f2884179
+Ref: 6409\7f2884353
+Ref: 6410\7f2884546
+Ref: 6411\7f2884709
+Ref: 6412\7f2884902
+Ref: 6413\7f2885601
+Ref: 6414\7f2889712
+Ref: 6415\7f2890956
+Ref: 6416\7f2891261
+Node: A.4.6\7f2891688
+Ref: 6417\7f2892478
+Ref: 6418\7f2892554
+Ref: 6419\7f2892610
+Ref: 6420\7f2892666
+Ref: 6421\7f2892722
+Ref: 6422\7f2892778
+Ref: 6423\7f2892834
+Ref: 6424\7f2892890
+Ref: 6425\7f2892946
+Ref: 6426\7f2893002
+Ref: 6427\7f2893058
+Ref: 6428\7f2893114
+Ref: 6429\7f2893173
+Ref: 6430\7f2893291
+Ref: 6431\7f2893409
+Ref: 6432\7f2894385
+Node: A.4.7\7f2894708
+Ref: 6433\7f2895750
+Ref: 6434\7f2895752
+Ref: 6435\7f2895752
+Ref: 6436\7f2895752
+Ref: 6437\7f2895752
+Ref: 6438\7f2895752
+Ref: 6439\7f2895752
+Ref: 6440\7f2895752
+Ref: 6441\7f2895752
+Ref: 6442\7f2895752
+Ref: 6443\7f2895752
+Ref: 6444\7f2895752
+Ref: 6445\7f2895752
+Ref: 6446\7f2895752
+Ref: 6447\7f2895752
+Ref: 6448\7f2895752
+Ref: 6449\7f2895866
+Ref: 6450\7f2896053
+Ref: 6451\7f2896155
+Ref: 6452\7f2896216
+Ref: 6453\7f2896422
+Ref: 6454\7f2896529
+Ref: 6455\7f2896633
+Ref: 6456\7f2896737
+Ref: 6457\7f2897416
+Ref: 6458\7f2897557
+Ref: 6459\7f2897942
+Ref: 6460\7f2898003
+Ref: 6461\7f2898110
+Ref: 6462\7f2898208
+Ref: 6463\7f2898416
+Ref: 6464\7f2898541
+Ref: 6465\7f2898679
+Ref: 6466\7f2898749
+Ref: 6467\7f2898863
+Ref: 6468\7f2898971
+Ref: 6469\7f2899075
+Ref: 6470\7f2901365
+Ref: 6471\7f2902028
+Ref: 6472\7f2902269
+Ref: 6473\7f2902851
+Ref: 6474\7f2903988
+Node: A.4.8\7f2904849
+Ref: 6475\7f2906070
+Ref: 6476\7f2906072
+Ref: 6477\7f2906072
+Ref: 6478\7f2906072
+Ref: 6479\7f2906072
+Ref: 6480\7f2906072
+Ref: 6481\7f2906072
+Ref: 6482\7f2906072
+Ref: 6483\7f2906072
+Ref: 6484\7f2906072
+Ref: 6485\7f2906072
+Ref: 6486\7f2906072
+Ref: 6487\7f2906072
+Ref: 6488\7f2906072
+Ref: 6489\7f2906072
+Ref: 6490\7f2906072
+Ref: 6491\7f2906274
+Ref: 6492\7f2906405
+Ref: 6493\7f2906519
+Ref: 6494\7f2906587
+Ref: 6495\7f2906817
+Ref: 6496\7f2906939
+Ref: 6497\7f2907055
+Ref: 6498\7f2907169
+Ref: 6499\7f2907929
+Ref: 6500\7f2908085
+Ref: 6501\7f2908505
+Ref: 6502\7f2908578
+Ref: 6503\7f2908699
+Ref: 6504\7f2908812
+Ref: 6505\7f2909024
+Ref: 6506\7f2909161
+Ref: 6507\7f2909319
+Ref: 6508\7f2909396
+Ref: 6509\7f2909525
+Ref: 6510\7f2909648
+Ref: 6511\7f2909766
+Ref: 6512\7f2910045
+Ref: 6513\7f2912286
+Ref: 6514\7f2912475
+Ref: 6515\7f2913238
+Ref: 6516\7f2913519
+Ref: 6517\7f2913960
+Node: A.4.9\7f2914911
+Ref: 6518\7f2915304
+Ref: 6519\7f2916081
+Ref: 6520\7f2916672
+Ref: 6521\7f2917097
+Ref: 6522\7f2917800
+Ref: 6523\7f2918234
+Ref: 6524\7f2918713
+Ref: 6525\7f2919674
+Ref: 6526\7f2919892
+Node: A.4.10\7f2920098
+Ref: 6527\7f2920510
+Ref: 6528\7f2921989
+Ref: 6529\7f2922440
+Ref: 6530\7f2922936
+Ref: 6531\7f2923390
+Ref: 6532\7f2923855
+Ref: 6533\7f2924305
+Ref: 6534\7f2924798
+Ref: 6535\7f2925151
+Node: A.4.11\7f2925555
+Ref: 6536\7f2926154
+Ref: 6537\7f2926307
+Ref: 6538\7f2926376
+Ref: 6539\7f2926419
+Ref: 6540\7f2926464
+Ref: 6541\7f2926507
+Ref: 6542\7f2926548
+Ref: 6543\7f2926732
+Ref: 6544\7f2926869
+Ref: 6545\7f2927006
+Ref: 6546\7f2927133
+Ref: 6547\7f2927340
+Ref: 6548\7f2927502
+Ref: 6549\7f2927759
+Ref: 6550\7f2927976
+Ref: 6551\7f2928136
+Ref: 6552\7f2928342
+Ref: 6553\7f2928557
+Ref: 6554\7f2928730
+Ref: 6555\7f2928922
+Ref: 6556\7f2929052
+Ref: 6557\7f2929199
+Ref: 6558\7f2929329
+Ref: 6559\7f2929396
+Ref: 6560\7f2929531
+Ref: 6561\7f2929719
+Ref: 6562\7f2929916
+Ref: 6563\7f2930051
+Ref: 6564\7f2930203
+Ref: 6565\7f2930338
+Ref: 6566\7f2930410
+Ref: 6567\7f2930555
+Ref: 6568\7f2930758
+Ref: 6569\7f2930960
+Ref: 6570\7f2931100
+Ref: 6571\7f2931257
+Ref: 6572\7f2931397
+Ref: 6573\7f2931474
+Ref: 6574\7f2931986
+Ref: 6575\7f2931986
+Ref: 6576\7f2931986
+Ref: 6577\7f2931986
+Ref: 6578\7f2943173
+Node: A.5\7f2943401
+Ref: 6579\7f2944119
+Ref: 6580\7f2944154
+Ref: 6581\7f2944190
+Ref: 6582\7f2944323
+Ref: 6583\7f2945167
+Ref: 6584\7f2945327
+Node: A.5.1\7f2945560
+Ref: 6585\7f2946304
+Ref: 6586\7f2946434
+Ref: 6587\7f2946515
+Ref: 6588\7f2946596
+Ref: 6589\7f2946677
+Ref: 6590\7f2946842
+Ref: 6591\7f2946923
+Ref: 6592\7f2947004
+Ref: 6593\7f2947085
+Ref: 6594\7f2947166
+Ref: 6595\7f2947247
+Ref: 6596\7f2947328
+Ref: 6597\7f2947409
+Ref: 6598\7f2947493
+Ref: 6599\7f2947574
+Ref: 6600\7f2947655
+Ref: 6601\7f2947736
+Ref: 6602\7f2947817
+Ref: 6603\7f2948019
+Ref: 6604\7f2948221
+Ref: 6605\7f2948423
+Ref: 6606\7f2948628
+Ref: 6607\7f2948709
+Ref: 6608\7f2948790
+Ref: 6609\7f2948871
+Ref: 6610\7f2948952
+Ref: 6611\7f2949033
+Ref: 6612\7f2949114
+Ref: 6613\7f2949195
+Ref: 6614\7f2949368
+Ref: 6615\7f2953829
+Ref: 6616\7f2953829
+Ref: 6617\7f2953829
+Ref: 6618\7f2954625
+Ref: 6619\7f2954875
+Ref: 6620\7f2957046
+Node: A.5.2\7f2961830
+Ref: 6621\7f2962257
+Ref: 6622\7f2963550
+Ref: 6623\7f2963598
+Ref: 6624\7f2963647
+Ref: 6625\7f2963713
+Ref: 6626\7f2963789
+Ref: 6627\7f2963890
+Ref: 6628\7f2963976
+Ref: 6629\7f2964016
+Ref: 6630\7f2964119
+Ref: 6631\7f2964211
+Ref: 6632\7f2964305
+Ref: 6633\7f2964366
+Ref: 6634\7f2964581
+Ref: 6635\7f2964693
+Ref: 6636\7f2964838
+Ref: 6637\7f2964889
+Ref: 6638\7f2964959
+Ref: 6639\7f2965060
+Ref: 6640\7f2965146
+Ref: 6641\7f2965186
+Ref: 6642\7f2965289
+Ref: 6643\7f2965381
+Ref: 6644\7f2965475
+Ref: 6645\7f2965536
+Ref: 6646\7f2967084
+Ref: 6647\7f2967395
+Ref: 6648\7f2969953
+Ref: 6649\7f2970189
+Ref: 6650\7f2971738
+Ref: 6651\7f2971738
+Ref: 6652\7f2971738
+Ref: 6653\7f2972118
+Ref: 6654\7f2972118
+Ref: 6655\7f2981290
+Node: A.5.3\7f2982811
+Ref: 6656\7f2983017
+Ref: 6657\7f2983145
+Ref: 6658\7f2983160
+Ref: 6659\7f2983318
+Ref: 6660\7f2983850
+Ref: 6661\7f2983865
+Ref: 6662\7f2984507
+Ref: 6663\7f2984522
+Ref: 6664\7f2984907
+Ref: 6665\7f2984922
+Ref: 6666\7f2985584
+Ref: 6667\7f2985599
+Ref: 6668\7f2986115
+Ref: 6669\7f2986213
+Ref: 6670\7f2986297
+Ref: 6671\7f2986299
+Ref: 6672\7f2986825
+Ref: 6673\7f2986840
+Ref: 6674\7f2988292
+Ref: 6675\7f2988307
+Ref: 6676\7f2988658
+Ref: 6677\7f2988673
+Ref: 6678\7f2989117
+Ref: 6679\7f2989707
+Ref: 6680\7f2989824
+Ref: 6681\7f2989839
+Ref: 6682\7f2990101
+Ref: 6683\7f2990116
+Ref: 6684\7f2991269
+Ref: 6685\7f2991284
+Ref: 6686\7f2991525
+Ref: 6687\7f2991895
+Ref: 6688\7f2991897
+Ref: 6689\7f2992529
+Ref: 6690\7f2992544
+Ref: 6691\7f2992780
+Ref: 6692\7f2993080
+Ref: 6693\7f2993082
+Ref: 6694\7f2993696
+Ref: 6695\7f2993711
+Ref: 6696\7f2994152
+Ref: 6697\7f2994167
+Ref: 6698\7f2994662
+Ref: 6699\7f2994677
+Ref: 6700\7f2995114
+Ref: 6701\7f2995129
+Ref: 6702\7f2995596
+Ref: 6703\7f2995611
+Ref: 6704\7f2996283
+Ref: 6705\7f2996709
+Ref: 6706\7f2996724
+Ref: 6707\7f2997106
+Ref: 6708\7f2997121
+Ref: 6709\7f2997292
+Ref: 6710\7f2997609
+Ref: 6711\7f2997611
+Ref: 6712\7f2998146
+Ref: 6713\7f2998161
+Ref: 6714\7f2998336
+Ref: 6715\7f2998547
+Ref: 6716\7f2998549
+Ref: 6717\7f2999087
+Ref: 6718\7f2999102
+Ref: 6719\7f2999280
+Ref: 6720\7f2999489
+Ref: 6721\7f2999491
+Ref: 6722\7f3000391
+Ref: 6723\7f3000406
+Ref: 6724\7f3001056
+Ref: 6725\7f3001071
+Ref: 6726\7f3001071
+Ref: 6727\7f3001797
+Ref: 6728\7f3001812
+Ref: 6729\7f3001976
+Ref: 6730\7f3002227
+Ref: 6731\7f3002228
+Ref: 6732\7f3004556
+Ref: 6733\7f3004675
+Ref: 6734\7f3004690
+Ref: 6735\7f3005281
+Ref: 6736\7f3005296
+Ref: 6737\7f3005715
+Ref: 6738\7f3005730
+Ref: 6739\7f3006232
+Ref: 6740\7f3006247
+Ref: 6741\7f3007054
+Ref: 6742\7f3007069
+Ref: 6743\7f3007503
+Ref: 6744\7f3007518
+Ref: 6745\7f3007954
+Ref: 6746\7f3007969
+Ref: 6747\7f3008960
+Ref: 6748\7f3010606
+Ref: 6749\7f3011177
+Node: A.5.4\7f3011228
+Ref: 6750\7f3011414
+Ref: 6751\7f3011539
+Ref: 6752\7f3011554
+Ref: 6753\7f3011729
+Ref: 6754\7f3011744
+Ref: 6755\7f3012056
+Ref: 6756\7f3012071
+Ref: 6757\7f3012461
+Ref: 6758\7f3012898
+Node: A.6\7f3013072
+Ref: 6759\7f3013214
+Ref: 6760\7f3013214
+Ref: 6761\7f3013964
+Ref: 6762\7f3014290
+Node: A.7\7f3014984
+Ref: 6763\7f3015178
+Ref: 6764\7f3015178
+Ref: 6765\7f3015178
+Ref: 6766\7f3015778
+Ref: 6767\7f3017530
+Ref: 6768\7f3017532
+Ref: 6769\7f3017532
+Ref: 6770\7f3017595
+Ref: 6771\7f3018942
+Ref: 6772\7f3018944
+Node: A.8\7f3020226
+Ref: 6773\7f3020442
+Ref: 6774\7f3020443
+Ref: 6775\7f3020443
+Ref: 6776\7f3020872
+Ref: 6777\7f3022762
+Ref: 6778\7f3022762
+Ref: 6779\7f3022762
+Ref: 6780\7f3023318
+Node: A.8.1\7f3023996
+Ref: 6781\7f3024379
+Ref: 6782\7f3024396
+Ref: 6783\7f3024442
+Ref: 6784\7f3024540
+Ref: 6785\7f3024750
+Ref: 6786\7f3024942
+Ref: 6787\7f3024993
+Ref: 6788\7f3025044
+Ref: 6789\7f3025116
+Ref: 6790\7f3025169
+Ref: 6791\7f3025233
+Ref: 6792\7f3025294
+Ref: 6793\7f3025359
+Ref: 6794\7f3025469
+Ref: 6795\7f3025541
+Ref: 6796\7f3025615
+Ref: 6797\7f3025697
+Ref: 6798\7f3025766
+Ref: 6799\7f3025833
+Ref: 6800\7f3025900
+Ref: 6801\7f3025966
+Ref: 6802\7f3026035
+Ref: 6803\7f3026101
+Ref: 6804\7f3026327
+Ref: 6805\7f3026446
+Ref: 6806\7f3026998
+Node: A.8.2\7f3027531
+Node: A.8.3\7f3036485
+Node: A.8.4\7f3039678
+Ref: 6807\7f3040055
+Ref: 6808\7f3040072
+Ref: 6809\7f3040118
+Ref: 6810\7f3040177
+Ref: 6811\7f3040241
+Ref: 6812\7f3040339
+Ref: 6813\7f3040551
+Ref: 6814\7f3040743
+Ref: 6815\7f3040794
+Ref: 6816\7f3040845
+Ref: 6817\7f3040917
+Ref: 6818\7f3040970
+Ref: 6819\7f3041034
+Ref: 6820\7f3041095
+Ref: 6821\7f3041160
+Ref: 6822\7f3041270
+Ref: 6823\7f3041412
+Ref: 6824\7f3041487
+Ref: 6825\7f3041629
+Ref: 6826\7f3041703
+Ref: 6827\7f3041780
+Ref: 6828\7f3041847
+Ref: 6829\7f3041909
+Ref: 6830\7f3041991
+Ref: 6831\7f3042060
+Ref: 6832\7f3042127
+Ref: 6833\7f3042194
+Ref: 6834\7f3042260
+Ref: 6835\7f3042329
+Ref: 6836\7f3042395
+Ref: 6837\7f3042877
+Ref: 6838\7f3043168
+Node: A.8.5\7f3043686
+Node: A.9\7f3047066
+Ref: 6839\7f3048476
+Ref: 6840\7f3048524
+Ref: 6841\7f3048644
+Ref: 6842\7f3048788
+Ref: 6843\7f3048867
+Ref: 6844\7f3048956
+Ref: 6845\7f3050390
+Node: A.10\7f3050421
+Ref: 6846\7f3052697
+Ref: 6847\7f3052697
+Ref: 6848\7f3053692
+Ref: 6849\7f3054016
+Ref: 6850\7f3054016
+Ref: 6851\7f3054016
+Ref: 6852\7f3055310
+Ref: 6853\7f3055316
+Ref: 6854\7f3055316
+Ref: 6855\7f3055316
+Ref: 6856\7f3055316
+Ref: 6857\7f3056129
+Ref: 6858\7f3056129
+Ref: 6859\7f3057066
+Node: A.10.1\7f3057668
+Ref: 6860\7f3057953
+Ref: 6861\7f3057970
+Ref: 6862\7f3058016
+Ref: 6863\7f3058079
+Ref: 6864\7f3058139
+Ref: 6865\7f3058189
+Ref: 6866\7f3058270
+Ref: 6867\7f3058344
+Ref: 6868\7f3058398
+Ref: 6869\7f3058487
+Ref: 6870\7f3058708
+Ref: 6871\7f3058905
+Ref: 6872\7f3058957
+Ref: 6873\7f3059009
+Ref: 6874\7f3059082
+Ref: 6875\7f3059138
+Ref: 6876\7f3059203
+Ref: 6877\7f3059265
+Ref: 6878\7f3059331
+Ref: 6879\7f3059455
+Ref: 6880\7f3059506
+Ref: 6881\7f3059557
+Ref: 6882\7f3059611
+Ref: 6883\7f3059662
+Ref: 6884\7f3059713
+Ref: 6885\7f3059768
+Ref: 6886\7f3059819
+Ref: 6887\7f3059870
+Ref: 6888\7f3059921
+Ref: 6889\7f3059984
+Ref: 6890\7f3060037
+Ref: 6891\7f3060090
+Ref: 6892\7f3060147
+Ref: 6893\7f3060200
+Ref: 6894\7f3060253
+Ref: 6895\7f3060385
+Ref: 6896\7f3060432
+Ref: 6897\7f3060515
+Ref: 6898\7f3060586
+Ref: 6899\7f3060642
+Ref: 6900\7f3060713
+Ref: 6901\7f3060769
+Ref: 6902\7f3060834
+Ref: 6903\7f3060882
+Ref: 6904\7f3060947
+Ref: 6905\7f3061041
+Ref: 6906\7f3061160
+Ref: 6907\7f3061229
+Ref: 6908\7f3061348
+Ref: 6909\7f3061417
+Ref: 6910\7f3061484
+Ref: 6911\7f3061534
+Ref: 6912\7f3061586
+Ref: 6913\7f3061618
+Ref: 6914\7f3061670
+Ref: 6915\7f3061703
+Ref: 6916\7f3061770
+Ref: 6917\7f3061820
+Ref: 6918\7f3061887
+Ref: 6919\7f3061937
+Ref: 6920\7f3062010
+Ref: 6921\7f3062068
+Ref: 6922\7f3062141
+Ref: 6923\7f3062198
+Ref: 6924\7f3062264
+Ref: 6925\7f3062313
+Ref: 6926\7f3062379
+Ref: 6927\7f3062428
+Ref: 6928\7f3062494
+Ref: 6929\7f3062582
+Ref: 6930\7f3062649
+Ref: 6931\7f3062698
+Ref: 6932\7f3062764
+Ref: 6933\7f3062813
+Ref: 6934\7f3062989
+Ref: 6935\7f3063110
+Ref: 6936\7f3063229
+Ref: 6937\7f3063293
+Ref: 6938\7f3063469
+Ref: 6939\7f3063625
+Ref: 6940\7f3063689
+Ref: 6941\7f3063735
+Ref: 6942\7f3063798
+Ref: 6943\7f3063844
+Ref: 6944\7f3063987
+Ref: 6945\7f3064090
+Ref: 6946\7f3064153
+Ref: 6947\7f3064199
+Ref: 6948\7f3064267
+Ref: 6949\7f3064428
+Ref: 6950\7f3064452
+Ref: 6951\7f3064499
+Ref: 6952\7f3064564
+Ref: 6953\7f3064703
+Ref: 6954\7f3064799
+Ref: 6955\7f3065013
+Ref: 6956\7f3065180
+Ref: 6957\7f3065312
+Ref: 6958\7f3065535
+Ref: 6959\7f3065559
+Ref: 6960\7f3065606
+Ref: 6961\7f3065671
+Ref: 6962\7f3065810
+Ref: 6963\7f3065906
+Ref: 6964\7f3066120
+Ref: 6965\7f3066287
+Ref: 6966\7f3066419
+Ref: 6967\7f3066708
+Ref: 6968\7f3066730
+Ref: 6969\7f3066768
+Ref: 6970\7f3066817
+Ref: 6971\7f3066874
+Ref: 6972\7f3067014
+Ref: 6973\7f3067110
+Ref: 6974\7f3067369
+Ref: 6975\7f3067586
+Ref: 6976\7f3067717
+Ref: 6977\7f3067986
+Ref: 6978\7f3068008
+Ref: 6979\7f3068053
+Ref: 6980\7f3068097
+Ref: 6981\7f3068154
+Ref: 6982\7f3068294
+Ref: 6983\7f3068390
+Ref: 6984\7f3068649
+Ref: 6985\7f3068866
+Ref: 6986\7f3068998
+Ref: 6987\7f3069277
+Ref: 6988\7f3069301
+Ref: 6989\7f3069346
+Ref: 6990\7f3069390
+Ref: 6991\7f3069447
+Ref: 6992\7f3069587
+Ref: 6993\7f3069683
+Ref: 6994\7f3069942
+Ref: 6995\7f3070159
+Ref: 6996\7f3070291
+Ref: 6997\7f3070628
+Ref: 6998\7f3070656
+Ref: 6999\7f3070697
+Ref: 7000\7f3070769
+Ref: 7001\7f3070859
+Ref: 7002\7f3070906
+Ref: 7003\7f3071124
+Ref: 7004\7f3071299
+Ref: 7005\7f3071432
+Ref: 7006\7f3071621
+Ref: 7007\7f3071690
+Ref: 7008\7f3071757
+Ref: 7009\7f3071824
+Ref: 7010\7f3071890
+Ref: 7011\7f3071959
+Ref: 7012\7f3072025
+Ref: 7013\7f3072092
+Ref: 7014\7f3072310
+Ref: 7015\7f3072389
+Ref: 7016\7f3072513
+Ref: 7017\7f3072851
+Node: A.10.2\7f3073795
+Node: A.10.3\7f3077164
+Ref: 7018\7f3080651
+Node: A.10.4\7f3082123
+Node: A.10.5\7f3084833
+Ref: 7019\7f3095064
+Node: A.10.6\7f3095394
+Ref: 7020\7f3097509
+Node: A.10.7\7f3101718
+Ref: 7021\7f3103540
+Ref: 7022\7f3104954
+Ref: 7023\7f3106886
+Ref: 7024\7f3108011
+Ref: 7025\7f3110392
+Ref: 7026\7f3110867
+Node: A.10.8\7f3111119
+Ref: 7027\7f3115668
+Ref: 7028\7f3116665
+Node: A.10.9\7f3117342
+Ref: 7029\7f3124049
+Node: A.10.10\7f3126231
+Node: A.10.11\7f3131889
+Ref: 7030\7f3132540
+Ref: 7031\7f3132564
+Ref: 7032\7f3132671
+Ref: 7033\7f3132745
+Ref: 7034\7f3132857
+Ref: 7035\7f3132935
+Ref: 7036\7f3133041
+Ref: 7037\7f3133116
+Ref: 7038\7f3133218
+Ref: 7039\7f3135049
+Node: A.10.12\7f3135096
+Ref: 7040\7f3135613
+Ref: 7041\7f3135637
+Ref: 7042\7f3135756
+Ref: 7043\7f3135842
+Ref: 7044\7f3135966
+Ref: 7045\7f3136056
+Ref: 7046\7f3136174
+Ref: 7047\7f3136261
+Ref: 7048\7f3136375
+Ref: 7049\7f3138382
+Node: A.11\7f3138431
+Ref: 7050\7f3139051
+Ref: 7051\7f3139335
+Ref: 7052\7f3139335
+Ref: 7053\7f3139666
+Ref: 7054\7f3139964
+Ref: 7055\7f3139966
+Ref: 7056\7f3140377
+Ref: 7057\7f3140378
+Ref: 7058\7f3141175
+Ref: 7059\7f3141176
+Ref: 7060\7f3141774
+Ref: 7061\7f3141952
+Node: A.12\7f3142759
+Node: A.12.1\7f3143468
+Ref: 7062\7f3143609
+Ref: 7063\7f3144621
+Ref: 7064\7f3144621
+Ref: 7065\7f3144876
+Ref: 7066\7f3144973
+Ref: 7067\7f3145042
+Ref: 7068\7f3145089
+Ref: 7069\7f3145156
+Ref: 7070\7f3145226
+Ref: 7071\7f3145346
+Ref: 7072\7f3145570
+Ref: 7073\7f3145763
+Ref: 7074\7f3145816
+Ref: 7075\7f3145869
+Ref: 7076\7f3145943
+Ref: 7077\7f3145999
+Ref: 7078\7f3146062
+Ref: 7079\7f3146122
+Ref: 7080\7f3146186
+Ref: 7081\7f3146254
+Ref: 7082\7f3146326
+Ref: 7083\7f3146562
+Ref: 7084\7f3146783
+Ref: 7085\7f3147044
+Ref: 7086\7f3147206
+Ref: 7087\7f3147412
+Ref: 7088\7f3147490
+Ref: 7089\7f3147558
+Ref: 7090\7f3147622
+Ref: 7091\7f3147753
+Ref: 7092\7f3147812
+Ref: 7093\7f3147882
+Ref: 7094\7f3147950
+Ref: 7095\7f3148018
+Ref: 7096\7f3148085
+Ref: 7097\7f3148155
+Ref: 7098\7f3148222
+Ref: 7099\7f3148454
+Ref: 7100\7f3153819
+Ref: 7101\7f3154659
+Ref: 7102\7f3155607
+Ref: 7103\7f3157117
+Node: A.12.2\7f3157384
+Ref: 7104\7f3157783
+Ref: 7105\7f3157838
+Ref: 7106\7f3157918
+Node: A.12.3\7f3158542
+Ref: 7107\7f3158966
+Ref: 7108\7f3159026
+Ref: 7109\7f3159106
+Node: A.12.4\7f3159293
+Ref: 7110\7f3159791
+Ref: 7111\7f3159856
+Ref: 7112\7f3159938
+Ref: 7113\7f3160253
+Node: A.13\7f3160312
+Ref: 7114\7f3160702
+Ref: 7115\7f3160745
+Ref: 7116\7f3160779
+Ref: 7117\7f3160813
+Ref: 7118\7f3160847
+Ref: 7119\7f3160881
+Ref: 7120\7f3160915
+Ref: 7121\7f3160949
+Ref: 7122\7f3160983
+Ref: 7123\7f3165667
+Ref: 7124\7f3165999
+Ref: 7125\7f3166001
+Node: A.14\7f3166004
+Ref: 7126\7f3166166
+Node: A.15\7f3167232
+Ref: 7127\7f3167864
+Ref: 7128\7f3167926
+Ref: 7129\7f3167976
+Ref: 7130\7f3168042
+Ref: 7131\7f3168085
+Ref: 7132\7f3168142
+Ref: 7133\7f3168181
+Ref: 7134\7f3168238
+Ref: 7135\7f3169065
+Ref: 7136\7f3171511
+Node: A.16\7f3171546
+Ref: 7137\7f3172534
+Ref: 7138\7f3172604
+Ref: 7139\7f3172660
+Ref: 7140\7f3172722
+Ref: 7141\7f3172860
+Ref: 7142\7f3172925
+Ref: 7143\7f3173054
+Ref: 7144\7f3173115
+Ref: 7145\7f3173171
+Ref: 7146\7f3173236
+Ref: 7147\7f3173451
+Ref: 7148\7f3173518
+Ref: 7149\7f3173587
+Ref: 7150\7f3173665
+Ref: 7151\7f3173732
+Ref: 7152\7f3173799
+Ref: 7153\7f3174035
+Ref: 7154\7f3174176
+Ref: 7155\7f3174304
+Ref: 7156\7f3174378
+Ref: 7157\7f3174449
+Ref: 7158\7f3174514
+Ref: 7159\7f3174579
+Ref: 7160\7f3174644
+Ref: 7161\7f3174764
+Ref: 7162\7f3174824
+Ref: 7163\7f3174888
+Ref: 7164\7f3174944
+Ref: 7165\7f3175205
+Ref: 7166\7f3175270
+Ref: 7167\7f3175349
+Ref: 7168\7f3175817
+Ref: 7169\7f3175923
+Ref: 7170\7f3176027
+Ref: 7171\7f3176129
+Ref: 7172\7f3176231
+Ref: 7173\7f3176340
+Ref: 7174\7f3176413
+Ref: 7175\7f3176484
+Ref: 7176\7f3176554
+Ref: 7177\7f3177136
+Ref: 7178\7f3177138
+Ref: 7179\7f3177138
+Ref: 7180\7f3177845
+Ref: 7181\7f3177847
+Ref: 7182\7f3178644
+Ref: 7183\7f3178646
+Ref: 7184\7f3179566
+Ref: 7185\7f3180022
+Ref: 7186\7f3199199
+Ref: 7187\7f3207068
+Ref: 7188\7f3217820
+Ref: 7189\7f3217949
+Ref: 7190\7f3218818
+Node: A.16.1\7f3219715
+Ref: 7191\7f3220328
+Ref: 7192\7f3220351
+Ref: 7193\7f3220423
+Ref: 7194\7f3220503
+Ref: 7195\7f3220585
+Ref: 7196\7f3220668
+Ref: 7197\7f3220738
+Ref: 7198\7f3220813
+Ref: 7199\7f3220929
+Ref: 7200\7f3221063
+Ref: 7201\7f3221138
+Ref: 7202\7f3221209
+Ref: 7203\7f3229678
+Node: A.17\7f3229746
+Ref: 7204\7f3229933
+Ref: 7205\7f3230547
+Ref: 7206\7f3230622
+Ref: 7207\7f3230711
+Ref: 7208\7f3230794
+Ref: 7209\7f3230859
+Ref: 7210\7f3230925
+Ref: 7211\7f3230969
+Ref: 7212\7f3231024
+Ref: 7213\7f3234798
+Ref: 7214\7f3235203
+Ref: 7215\7f3237614
+Ref: 7216\7f3237759
+Node: A.18\7f3238169
+Ref: 7217\7f3239119
+Ref: 7218\7f3239119
+Ref: 7219\7f3239842
+Ref: 7220\7f3239843
+Ref: 7221\7f3240232
+Ref: 7222\7f3240801
+Ref: 7223\7f3248250
+Ref: 7224\7f3249297
+Node: A.18.1\7f3251502
+Ref: 7225\7f3251901
+Ref: 7226\7f3251953
+Ref: 7227\7f3252012
+Ref: 7228\7f3252101
+Ref: 7229\7f3253278
+Ref: 7230\7f3253405
+Node: A.18.2\7f3253806
+Ref: 7231\7f3254376
+Ref: 7232\7f3254376
+Ref: 7233\7f3254384
+Ref: 7234\7f3254384
+Ref: 7235\7f3254907
+Ref: 7236\7f3255959
+Ref: 7237\7f3256057
+Ref: 7238\7f3256225
+Ref: 7239\7f3256333
+Ref: 7240\7f3256631
+Ref: 7241\7f3256712
+Ref: 7242\7f3256758
+Ref: 7243\7f3256843
+Ref: 7244\7f3256940
+Ref: 7245\7f3257122
+Ref: 7246\7f3257192
+Ref: 7247\7f3257653
+Ref: 7248\7f3257726
+Ref: 7249\7f3257862
+Ref: 7250\7f3257933
+Ref: 7251\7f3258057
+Ref: 7252\7f3258127
+Ref: 7253\7f3258185
+Ref: 7254\7f3258310
+Ref: 7255\7f3258386
+Ref: 7256\7f3258520
+Ref: 7257\7f3258593
+Ref: 7258\7f3258796
+Ref: 7259\7f3258995
+Ref: 7260\7f3259184
+Ref: 7261\7f3259333
+Ref: 7262\7f3259562
+Ref: 7263\7f3260003
+Ref: 7264\7f3260169
+Ref: 7265\7f3260377
+Ref: 7266\7f3260562
+Ref: 7267\7f3260766
+Ref: 7268\7f3260948
+Ref: 7269\7f3261051
+Ref: 7270\7f3261152
+Ref: 7271\7f3261255
+Ref: 7272\7f3261429
+Ref: 7273\7f3261595
+Ref: 7274\7f3261814
+Ref: 7275\7f3262056
+Ref: 7276\7f3262290
+Ref: 7277\7f3262577
+Ref: 7278\7f3262760
+Ref: 7279\7f3262988
+Ref: 7280\7f3263103
+Ref: 7281\7f3263287
+Ref: 7282\7f3263400
+Ref: 7283\7f3263581
+Ref: 7284\7f3263782
+Ref: 7285\7f3264034
+Ref: 7286\7f3264217
+Ref: 7287\7f3264392
+Ref: 7288\7f3264526
+Ref: 7289\7f3264658
+Ref: 7290\7f3264728
+Ref: 7291\7f3264841
+Ref: 7292\7f3264949
+Ref: 7293\7f3265024
+Ref: 7294\7f3265089
+Ref: 7295\7f3265179
+Ref: 7296\7f3265257
+Ref: 7297\7f3265321
+Ref: 7298\7f3265410
+Ref: 7299\7f3265474
+Ref: 7300\7f3265530
+Ref: 7301\7f3265598
+Ref: 7302\7f3265658
+Ref: 7303\7f3265875
+Ref: 7304\7f3266056
+Ref: 7305\7f3266296
+Ref: 7306\7f3266501
+Ref: 7307\7f3266688
+Ref: 7308\7f3266828
+Ref: 7309\7f3267411
+Ref: 7310\7f3267456
+Ref: 7311\7f3267530
+Ref: 7312\7f3267591
+Ref: 7313\7f3268307
+Ref: 7314\7f3269217
+Ref: 7315\7f3273281
+Ref: 7316\7f3274410
+Ref: 7317\7f3275128
+Ref: 7318\7f3275129
+Ref: 7319\7f3290707
+Ref: 7320\7f3323132
+Ref: 7321\7f3326606
+Ref: 7322\7f3327723
+Ref: 7323\7f3328903
+Ref: 7324\7f3328904
+Ref: 7325\7f3329525
+Ref: 7326\7f3331104
+Ref: 7327\7f3331104
+Ref: 7328\7f3332211
+Ref: 7329\7f3332334
+Ref: 7330\7f3340001
+Ref: 7331\7f3340148
+Ref: 7332\7f3340717
+Node: A.18.3\7f3342136
+Ref: 7333\7f3342586
+Ref: 7334\7f3342588
+Ref: 7335\7f3342622
+Ref: 7336\7f3343163
+Ref: 7337\7f3343613
+Ref: 7338\7f3343757
+Ref: 7339\7f3344051
+Ref: 7340\7f3344131
+Ref: 7341\7f3344172
+Ref: 7342\7f3344256
+Ref: 7343\7f3344352
+Ref: 7344\7f3344530
+Ref: 7345\7f3344598
+Ref: 7346\7f3344666
+Ref: 7347\7f3344722
+Ref: 7348\7f3344806
+Ref: 7349\7f3345003
+Ref: 7350\7f3345152
+Ref: 7351\7f3345591
+Ref: 7352\7f3345757
+Ref: 7353\7f3345959
+Ref: 7354\7f3346139
+Ref: 7355\7f3346238
+Ref: 7356\7f3346296
+Ref: 7357\7f3346395
+Ref: 7358\7f3346627
+Ref: 7359\7f3346912
+Ref: 7360\7f3347138
+Ref: 7361\7f3347320
+Ref: 7362\7f3347499
+Ref: 7363\7f3347672
+Ref: 7364\7f3347804
+Ref: 7365\7f3347934
+Ref: 7366\7f3348002
+Ref: 7367\7f3348109
+Ref: 7368\7f3348228
+Ref: 7369\7f3348387
+Ref: 7370\7f3348598
+Ref: 7371\7f3348758
+Ref: 7372\7f3348821
+Ref: 7373\7f3348909
+Ref: 7374\7f3348971
+Ref: 7375\7f3349058
+Ref: 7376\7f3349121
+Ref: 7377\7f3349189
+Ref: 7378\7f3349246
+Ref: 7379\7f3349306
+Ref: 7380\7f3349485
+Ref: 7381\7f3349688
+Ref: 7382\7f3349872
+Ref: 7383\7f3350010
+Ref: 7384\7f3350583
+Ref: 7385\7f3350628
+Ref: 7386\7f3350700
+Ref: 7387\7f3350759
+Ref: 7388\7f3351534
+Ref: 7389\7f3352254
+Ref: 7390\7f3354611
+Ref: 7391\7f3355923
+Ref: 7392\7f3356544
+Ref: 7393\7f3356545
+Ref: 7394\7f3362415
+Ref: 7395\7f3385720
+Ref: 7396\7f3388097
+Ref: 7397\7f3388441
+Ref: 7398\7f3388856
+Ref: 7399\7f3389418
+Ref: 7400\7f3389418
+Ref: 7401\7f3391104
+Ref: 7402\7f3391106
+Ref: 7403\7f3397175
+Ref: 7404\7f3397366
+Ref: 7405\7f3397822
+Ref: 7406\7f3398427
+Node: A.18.4\7f3399951
+Ref: 7407\7f3400482
+Ref: 7408\7f3400482
+Ref: 7409\7f3401333
+Ref: 7410\7f3402032
+Ref: 7411\7f3402085
+Ref: 7412\7f3402534
+Ref: 7413\7f3402568
+Ref: 7414\7f3402569
+Ref: 7415\7f3402569
+Ref: 7416\7f3403567
+Ref: 7417\7f3404773
+Ref: 7418\7f3405396
+Ref: 7419\7f3405397
+Ref: 7420\7f3413733
+Ref: 7421\7f3426968
+Ref: 7422\7f3427380
+Ref: 7423\7f3427923
+Ref: 7424\7f3427923
+Ref: 7425\7f3428719
+Ref: 7426\7f3428873
+Ref: 7427\7f3432967
+Node: A.18.5\7f3434063
+Ref: 7428\7f3434861
+Ref: 7429\7f3434989
+Ref: 7430\7f3435281
+Ref: 7431\7f3435361
+Ref: 7432\7f3435400
+Ref: 7433\7f3435484
+Ref: 7434\7f3435580
+Ref: 7435\7f3435754
+Ref: 7436\7f3435823
+Ref: 7437\7f3435956
+Ref: 7438\7f3436023
+Ref: 7439\7f3436090
+Ref: 7440\7f3436145
+Ref: 7441\7f3436209
+Ref: 7442\7f3436282
+Ref: 7443\7f3436478
+Ref: 7444\7f3436699
+Ref: 7445\7f3437192
+Ref: 7446\7f3437358
+Ref: 7447\7f3437559
+Ref: 7448\7f3437737
+Ref: 7449\7f3437940
+Ref: 7450\7f3438121
+Ref: 7451\7f3438218
+Ref: 7452\7f3438302
+Ref: 7453\7f3438399
+Ref: 7454\7f3438677
+Ref: 7455\7f3438896
+Ref: 7456\7f3439067
+Ref: 7457\7f3439241
+Ref: 7458\7f3439415
+Ref: 7459\7f3439529
+Ref: 7460\7f3439641
+Ref: 7461\7f3439750
+Ref: 7462\7f3439823
+Ref: 7463\7f3439888
+Ref: 7464\7f3439945
+Ref: 7465\7f3440062
+Ref: 7466\7f3440191
+Ref: 7467\7f3440369
+Ref: 7468\7f3440458
+Ref: 7469\7f3440593
+Ref: 7470\7f3440729
+Ref: 7471\7f3441392
+Ref: 7472\7f3442231
+Ref: 7473\7f3442790
+Ref: 7474\7f3443882
+Ref: 7475\7f3444540
+Ref: 7476\7f3445471
+Ref: 7477\7f3445472
+Ref: 7478\7f3445472
+Ref: 7479\7f3445658
+Ref: 7480\7f3455276
+Ref: 7481\7f3455434
+Ref: 7482\7f3456014
+Node: A.18.6\7f3456328
+Ref: 7483\7f3457040
+Ref: 7484\7f3457149
+Ref: 7485\7f3457249
+Ref: 7486\7f3457541
+Ref: 7487\7f3457621
+Ref: 7488\7f3457660
+Ref: 7489\7f3457744
+Ref: 7490\7f3457840
+Ref: 7491\7f3458014
+Ref: 7492\7f3458081
+Ref: 7493\7f3458148
+Ref: 7494\7f3458203
+Ref: 7495\7f3458267
+Ref: 7496\7f3458340
+Ref: 7497\7f3458536
+Ref: 7498\7f3458757
+Ref: 7499\7f3459250
+Ref: 7500\7f3459416
+Ref: 7501\7f3459617
+Ref: 7502\7f3459795
+Ref: 7503\7f3459998
+Ref: 7504\7f3460179
+Ref: 7505\7f3460276
+Ref: 7506\7f3460332
+Ref: 7507\7f3460429
+Ref: 7508\7f3460707
+Ref: 7509\7f3460926
+Ref: 7510\7f3461097
+Ref: 7511\7f3461271
+Ref: 7512\7f3461445
+Ref: 7513\7f3461559
+Ref: 7514\7f3461671
+Ref: 7515\7f3461781
+Ref: 7516\7f3461844
+Ref: 7517\7f3461905
+Ref: 7518\7f3461967
+Ref: 7519\7f3462043
+Ref: 7520\7f3462111
+Ref: 7521\7f3462172
+Ref: 7522\7f3462247
+Ref: 7523\7f3462314
+Ref: 7524\7f3462378
+Ref: 7525\7f3462434
+Ref: 7526\7f3462502
+Ref: 7527\7f3462562
+Ref: 7528\7f3462668
+Ref: 7529\7f3462786
+Ref: 7530\7f3462894
+Ref: 7531\7f3463006
+Ref: 7532\7f3463625
+Ref: 7533\7f3463762
+Ref: 7534\7f3464346
+Ref: 7535\7f3465062
+Ref: 7536\7f3465842
+Ref: 7537\7f3466922
+Ref: 7538\7f3466923
+Ref: 7539\7f3466923
+Ref: 7540\7f3466923
+Ref: 7541\7f3476345
+Ref: 7542\7f3476504
+Ref: 7543\7f3477087
+Node: A.18.7\7f3477640
+Ref: 7544\7f3478152
+Ref: 7545\7f3478152
+Ref: 7546\7f3479006
+Ref: 7547\7f3479709
+Ref: 7548\7f3480050
+Ref: 7549\7f3480084
+Ref: 7550\7f3480085
+Ref: 7551\7f3480085
+Ref: 7552\7f3481113
+Ref: 7553\7f3482532
+Ref: 7554\7f3483387
+Ref: 7555\7f3483388
+Ref: 7556\7f3491699
+Ref: 7557\7f3505297
+Ref: 7558\7f3505533
+Ref: 7559\7f3508331
+Ref: 7560\7f3510992
+Ref: 7561\7f3511405
+Ref: 7562\7f3511948
+Ref: 7563\7f3511948
+Ref: 7564\7f3512933
+Ref: 7565\7f3513087
+Ref: 7566\7f3517188
+Node: A.18.8\7f3518290
+Ref: 7567\7f3519070
+Ref: 7568\7f3519198
+Ref: 7569\7f3519442
+Ref: 7570\7f3519522
+Ref: 7571\7f3519561
+Ref: 7572\7f3519645
+Ref: 7573\7f3519741
+Ref: 7574\7f3519915
+Ref: 7575\7f3519989
+Ref: 7576\7f3520057
+Ref: 7577\7f3520127
+Ref: 7578\7f3520260
+Ref: 7579\7f3520327
+Ref: 7580\7f3520394
+Ref: 7581\7f3520449
+Ref: 7582\7f3520522
+Ref: 7583\7f3520718
+Ref: 7584\7f3521087
+Ref: 7585\7f3521289
+Ref: 7586\7f3521386
+Ref: 7587\7f3521470
+Ref: 7588\7f3521567
+Ref: 7589\7f3521790
+Ref: 7590\7f3521906
+Ref: 7591\7f3522024
+Ref: 7592\7f3522142
+Ref: 7593\7f3522260
+Ref: 7594\7f3522376
+Ref: 7595\7f3522486
+Ref: 7596\7f3522584
+Ref: 7597\7f3522720
+Ref: 7598\7f3522832
+Ref: 7599\7f3522983
+Ref: 7600\7f3523091
+Ref: 7601\7f3523236
+Ref: 7602\7f3523364
+Ref: 7603\7f3523540
+Ref: 7604\7f3523607
+Ref: 7605\7f3523713
+Ref: 7606\7f3523775
+Ref: 7607\7f3523839
+Ref: 7608\7f3523895
+Ref: 7609\7f3524005
+Ref: 7610\7f3524187
+Ref: 7611\7f3524279
+Ref: 7612\7f3524425
+Ref: 7613\7f3524572
+Ref: 7614\7f3525170
+Ref: 7615\7f3525212
+Ref: 7616\7f3525279
+Ref: 7617\7f3525417
+Ref: 7618\7f3525600
+Ref: 7619\7f3525720
+Ref: 7620\7f3525837
+Ref: 7621\7f3525963
+Ref: 7622\7f3526099
+Ref: 7623\7f3526373
+Ref: 7624\7f3526562
+Ref: 7625\7f3526779
+Ref: 7626\7f3526991
+Ref: 7627\7f3527336
+Ref: 7628\7f3527636
+Ref: 7629\7f3528205
+Ref: 7630\7f3528735
+Ref: 7631\7f3528944
+Ref: 7632\7f3529199
+Ref: 7633\7f3529566
+Ref: 7634\7f3529567
+Ref: 7635\7f3529567
+Ref: 7636\7f3529768
+Ref: 7637\7f3534704
+Ref: 7638\7f3535109
+Ref: 7639\7f3536357
+Ref: 7640\7f3536515
+Ref: 7641\7f3537095
+Node: A.18.9\7f3537578
+Ref: 7642\7f3538261
+Ref: 7643\7f3538370
+Ref: 7644\7f3538478
+Ref: 7645\7f3538722
+Ref: 7646\7f3538802
+Ref: 7647\7f3538841
+Ref: 7648\7f3538925
+Ref: 7649\7f3539021
+Ref: 7650\7f3539195
+Ref: 7651\7f3539270
+Ref: 7652\7f3539338
+Ref: 7653\7f3539405
+Ref: 7654\7f3539472
+Ref: 7655\7f3539527
+Ref: 7656\7f3539600
+Ref: 7657\7f3539796
+Ref: 7658\7f3540165
+Ref: 7659\7f3540367
+Ref: 7660\7f3540464
+Ref: 7661\7f3540520
+Ref: 7662\7f3540617
+Ref: 7663\7f3540840
+Ref: 7664\7f3540956
+Ref: 7665\7f3541074
+Ref: 7666\7f3541192
+Ref: 7667\7f3541310
+Ref: 7668\7f3541426
+Ref: 7669\7f3541536
+Ref: 7670\7f3541599
+Ref: 7671\7f3541661
+Ref: 7672\7f3541759
+Ref: 7673\7f3541895
+Ref: 7674\7f3542007
+Ref: 7675\7f3542158
+Ref: 7676\7f3542266
+Ref: 7677\7f3542411
+Ref: 7678\7f3542539
+Ref: 7679\7f3542716
+Ref: 7680\7f3542783
+Ref: 7681\7f3542889
+Ref: 7682\7f3542951
+Ref: 7683\7f3543027
+Ref: 7684\7f3543088
+Ref: 7685\7f3543163
+Ref: 7686\7f3543227
+Ref: 7687\7f3543283
+Ref: 7688\7f3543351
+Ref: 7689\7f3543411
+Ref: 7690\7f3543532
+Ref: 7691\7f3543655
+Ref: 7692\7f3543782
+Ref: 7693\7f3544465
+Ref: 7694\7f3544602
+Ref: 7695\7f3545279
+Ref: 7696\7f3545322
+Ref: 7697\7f3545421
+Ref: 7698\7f3545489
+Ref: 7699\7f3545631
+Ref: 7700\7f3545817
+Ref: 7701\7f3545939
+Ref: 7702\7f3546058
+Ref: 7703\7f3546187
+Ref: 7704\7f3546318
+Ref: 7705\7f3546453
+Ref: 7706\7f3546577
+Ref: 7707\7f3546855
+Ref: 7708\7f3547044
+Ref: 7709\7f3547261
+Ref: 7710\7f3547473
+Ref: 7711\7f3547951
+Ref: 7712\7f3548551
+Ref: 7713\7f3548760
+Ref: 7714\7f3548998
+Ref: 7715\7f3549374
+Ref: 7716\7f3549375
+Ref: 7717\7f3549375
+Ref: 7718\7f3549375
+Ref: 7719\7f3557091
+Ref: 7720\7f3558785
+Ref: 7721\7f3558945
+Ref: 7722\7f3559529
+Node: A.18.10\7f3560254
+Ref: 7723\7f3561344
+Ref: 7724\7f3561814
+Ref: 7725\7f3561816
+Ref: 7726\7f3561816
+Ref: 7727\7f3562049
+Ref: 7728\7f3562049
+Ref: 7729\7f3562155
+Ref: 7730\7f3562299
+Ref: 7731\7f3562419
+Ref: 7732\7f3562757
+Ref: 7733\7f3563391
+Ref: 7734\7f3563550
+Ref: 7735\7f3563844
+Ref: 7736\7f3563925
+Ref: 7737\7f3563967
+Ref: 7738\7f3564025
+Ref: 7739\7f3564120
+Ref: 7740\7f3564233
+Ref: 7741\7f3564431
+Ref: 7742\7f3564498
+Ref: 7743\7f3564570
+Ref: 7744\7f3564651
+Ref: 7745\7f3564719
+Ref: 7746\7f3564786
+Ref: 7747\7f3564853
+Ref: 7748\7f3564916
+Ref: 7749\7f3564972
+Ref: 7750\7f3565045
+Ref: 7751\7f3565242
+Ref: 7752\7f3565391
+Ref: 7753\7f3565634
+Ref: 7754\7f3565826
+Ref: 7755\7f3565990
+Ref: 7756\7f3566190
+Ref: 7757\7f3566343
+Ref: 7758\7f3566415
+Ref: 7759\7f3566473
+Ref: 7760\7f3566572
+Ref: 7761\7f3566693
+Ref: 7762\7f3566820
+Ref: 7763\7f3566926
+Ref: 7764\7f3567048
+Ref: 7765\7f3567192
+Ref: 7766\7f3567332
+Ref: 7767\7f3567453
+Ref: 7768\7f3567591
+Ref: 7769\7f3567763
+Ref: 7770\7f3567908
+Ref: 7771\7f3568037
+Ref: 7772\7f3568109
+Ref: 7773\7f3568189
+Ref: 7774\7f3568504
+Ref: 7775\7f3568878
+Ref: 7776\7f3569187
+Ref: 7777\7f3569447
+Ref: 7778\7f3569703
+Ref: 7779\7f3569832
+Ref: 7780\7f3570069
+Ref: 7781\7f3570372
+Ref: 7782\7f3570617
+Ref: 7783\7f3570960
+Ref: 7784\7f3571236
+Ref: 7785\7f3571301
+Ref: 7786\7f3571369
+Ref: 7787\7f3571451
+Ref: 7788\7f3571518
+Ref: 7789\7f3571599
+Ref: 7790\7f3571670
+Ref: 7791\7f3571746
+Ref: 7792\7f3571811
+Ref: 7793\7f3571880
+Ref: 7794\7f3572025
+Ref: 7795\7f3572202
+Ref: 7796\7f3572998
+Ref: 7797\7f3573105
+Ref: 7798\7f3575148
+Ref: 7799\7f3576433
+Ref: 7800\7f3577452
+Ref: 7801\7f3577453
+Ref: 7802\7f3588025
+Ref: 7803\7f3629015
+Ref: 7804\7f3629428
+Ref: 7805\7f3629981
+Ref: 7806\7f3629981
+Ref: 7807\7f3631004
+Ref: 7808\7f3636448
+Node: A.18.11\7f3636514
+Ref: 7809\7f3637211
+Ref: 7810\7f3638445
+Node: A.18.12\7f3638515
+Ref: 7811\7f3639295
+Ref: 7812\7f3640593
+Node: A.18.13\7f3640675
+Ref: 7813\7f3641363
+Ref: 7814\7f3642685
+Node: A.18.14\7f3642759
+Ref: 7815\7f3643452
+Ref: 7816\7f3644775
+Node: A.18.15\7f3644850
+Ref: 7817\7f3645523
+Ref: 7818\7f3645913
+Node: A.18.16\7f3645987
+Ref: 7819\7f3646665
+Ref: 7820\7f3647056
+Node: A.18.17\7f3647131
+Ref: 7821\7f3647792
+Ref: 7822\7f3649148
+Node: A.18.18\7f3649225
+Ref: 7823\7f3649933
+Ref: 7824\7f3650336
+Ref: 7825\7f3650453
+Ref: 7826\7f3650541
+Ref: 7827\7f3650665
+Ref: 7828\7f3650739
+Ref: 7829\7f3650809
+Ref: 7830\7f3650867
+Ref: 7831\7f3650941
+Ref: 7832\7f3651078
+Ref: 7833\7f3651273
+Ref: 7834\7f3651447
+Ref: 7835\7f3651633
+Ref: 7836\7f3651794
+Ref: 7837\7f3651933
+Ref: 7838\7f3652059
+Ref: 7839\7f3652160
+Ref: 7840\7f3652222
+Ref: 7841\7f3653575
+Ref: 7842\7f3654244
+Ref: 7843\7f3655020
+Ref: 7844\7f3655021
+Ref: 7845\7f3659495
+Ref: 7846\7f3663281
+Ref: 7847\7f3663727
+Ref: 7848\7f3664449
+Ref: 7849\7f3667706
+Node: A.18.19\7f3667777
+Ref: 7850\7f3669781
+Ref: 7851\7f3670543
+Ref: 7852\7f3673027
+Node: A.18.20\7f3673095
+Ref: 7853\7f3674999
+Ref: 7854\7f3675853
+Ref: 7855\7f3676609
+Ref: 7856\7f3678971
+Node: A.18.21\7f3679051
+Ref: 7857\7f3681047
+Ref: 7858\7f3681369
+Ref: 7859\7f3682260
+Ref: 7860\7f3683013
+Ref: 7861\7f3685538
+Node: A.18.22\7f3685610
+Ref: 7862\7f3687473
+Ref: 7863\7f3688016
+Ref: 7864\7f3688769
+Ref: 7865\7f3691299
+Node: A.18.23\7f3691372
+Ref: 7866\7f3693351
+Ref: 7867\7f3693673
+Ref: 7868\7f3694560
+Ref: 7869\7f3695313
+Ref: 7870\7f3697708
+Node: A.18.24\7f3697780
+Ref: 7871\7f3699641
+Ref: 7872\7f3700180
+Ref: 7873\7f3700933
+Ref: 7874\7f3703333
+Node: A.18.25\7f3703406
+Ref: 7875\7f3706365
+Ref: 7876\7f3707121
+Ref: 7877\7f3709438
+Node: A.18.26\7f3709512
+Ref: 7878\7f3710382
+Ref: 7879\7f3711301
+Ref: 7880\7f3712607
+Ref: 7881\7f3713628
+Ref: 7882\7f3713969
+Ref: 7883\7f3715388
+Ref: 7884\7f3717623
+Ref: 7885\7f3717868
+Node: A.18.27\7f3718221
+Ref: 7886\7f3718967
+Ref: 7887\7f3719038
+Ref: 7888\7f3719094
+Ref: 7889\7f3719264
+Ref: 7890\7f3719433
+Ref: 7891\7f3719513
+Ref: 7892\7f3719941
+Ref: 7893\7f3722342
+Node: A.18.28\7f3722424
+Ref: 7894\7f3723222
+Ref: 7895\7f3723426
+Ref: 7896\7f3723629
+Ref: 7897\7f3723723
+Ref: 7898\7f3723825
+Ref: 7899\7f3723898
+Ref: 7900\7f3725184
+Node: A.18.29\7f3725266
+Ref: 7901\7f3726096
+Ref: 7902\7f3726298
+Ref: 7903\7f3726559
+Ref: 7904\7f3726653
+Ref: 7905\7f3726755
+Ref: 7906\7f3726828
+Ref: 7907\7f3727821
+Node: A.18.30\7f3727901
+Ref: 7908\7f3728931
+Ref: 7909\7f3729131
+Ref: 7910\7f3729334
+Ref: 7911\7f3729428
+Ref: 7912\7f3729585
+Ref: 7913\7f3729812
+Ref: 7914\7f3729885
+Ref: 7915\7f3732382
+Node: A.18.31\7f3732460
+Ref: 7916\7f3733522
+Ref: 7917\7f3733720
+Ref: 7918\7f3733979
+Ref: 7919\7f3734073
+Ref: 7920\7f3734230
+Ref: 7921\7f3734457
+Ref: 7922\7f3734530
+Ref: 7923\7f3735569
+Node: A.18.32\7f3735645
+Node: A.19\7f3740789
+Ref: 7924\7f3740965
+Ref: 7925\7f3741287
+Ref: 7926\7f3741382
+Ref: 7927\7f3741458
+Ref: 7928\7f3741528
+Ref: 7929\7f3741588
+Ref: 7930\7f3741664
+Ref: 7931\7f3741712
+Ref: 7932\7f3741840
+Ref: 7933\7f3741840
+Ref: 7934\7f3744067
+Node: Annex B\7f3744103
+Ref: 7935\7f3744261
+Ref: 7936\7f3744261
+Ref: 7937\7f3744261
+Ref: 7938\7f3745885
+Node: B.1\7f3746520
+Ref: 7939\7f3746793
+Ref: 7940\7f3746793
+Ref: 7941\7f3746848
+Ref: 7942\7f3746849
+Ref: 7943\7f3747116
+Ref: 7944\7f3747117
+Ref: 7945\7f3747687
+Ref: 7946\7f3747687
+Ref: 7947\7f3747687
+Ref: 7948\7f3747687
+Ref: 7949\7f3747687
+Ref: 7950\7f3747689
+Ref: 7951\7f3747689
+Ref: 7952\7f3747689
+Ref: 7953\7f3747689
+Ref: 7954\7f3748182
+Ref: 7955\7f3748182
+Ref: 7956\7f3749094
+Ref: 7957\7f3749095
+Ref: 7958\7f3749117
+Ref: 7959\7f3749964
+Ref: 7960\7f3749998
+Ref: 7961\7f3750120
+Ref: 7962\7f3750566
+Ref: 7963\7f3751259
+Ref: 7964\7f3751689
+Ref: 7965\7f3753717
+Ref: 7966\7f3754494
+Ref: 7967\7f3754495
+Ref: 7968\7f3756643
+Ref: 7969\7f3756839
+Ref: 7970\7f3758339
+Ref: 7971\7f3758340
+Ref: 7972\7f3759267
+Ref: 7973\7f3760138
+Ref: 7974\7f3760140
+Ref: 7975\7f3760140
+Ref: 7976\7f3760140
+Ref: 7977\7f3765646
+Ref: 7978\7f3766491
+Ref: 7979\7f3767339
+Node: B.2\7f3767495
+Ref: 7980\7f3768186
+Ref: 7981\7f3769786
+Ref: 7982\7f3769786
+Ref: 7983\7f3771433
+Node: B.3\7f3774295
+Ref: 7984\7f3774538
+Ref: 7985\7f3774539
+Ref: 7986\7f3775282
+Ref: 7987\7f3775364
+Ref: 7988\7f3775436
+Ref: 7989\7f3775511
+Ref: 7990\7f3775585
+Ref: 7991\7f3775712
+Ref: 7992\7f3775764
+Ref: 7993\7f3775816
+Ref: 7994\7f3775871
+Ref: 7995\7f3775975
+Ref: 7996\7f3776034
+Ref: 7997\7f3776093
+Ref: 7998\7f3776156
+Ref: 7999\7f3776257
+Ref: 8000\7f3776312
+Ref: 8001\7f3776372
+Ref: 8002\7f3776457
+Ref: 8003\7f3776520
+Ref: 8004\7f3776583
+Ref: 8005\7f3776685
+Ref: 8006\7f3776798
+Ref: 8007\7f3776866
+Ref: 8008\7f3776929
+Ref: 8009\7f3777040
+Ref: 8010\7f3777189
+Ref: 8011\7f3777267
+Ref: 8012\7f3777408
+Ref: 8013\7f3777546
+Ref: 8014\7f3777760
+Ref: 8015\7f3778068
+Ref: 8016\7f3778184
+Ref: 8017\7f3778260
+Ref: 8018\7f3778327
+Ref: 8019\7f3778428
+Ref: 8020\7f3778592
+Ref: 8021\7f3778671
+Ref: 8022\7f3778818
+Ref: 8023\7f3778962
+Ref: 8024\7f3779182
+Ref: 8025\7f3779549
+Ref: 8026\7f3779613
+Ref: 8027\7f3779701
+Ref: 8028\7f3779767
+Ref: 8029\7f3779864
+Ref: 8030\7f3780036
+Ref: 8031\7f3780112
+Ref: 8032\7f3780260
+Ref: 8033\7f3780409
+Ref: 8034\7f3780635
+Ref: 8035\7f3780886
+Ref: 8036\7f3780951
+Ref: 8037\7f3781040
+Ref: 8038\7f3781111
+Ref: 8039\7f3781214
+Ref: 8040\7f3781388
+Ref: 8041\7f3781464
+Ref: 8042\7f3781618
+Ref: 8043\7f3781773
+Ref: 8044\7f3782004
+Ref: 8045\7f3782216
+Ref: 8046\7f3784127
+Ref: 8047\7f3786936
+Ref: 8048\7f3787378
+Ref: 8049\7f3801747
+Ref: 8050\7f3802344
+Ref: 8051\7f3803521
+Node: B.3.1\7f3804214
+Ref: 8052\7f3804980
+Ref: 8053\7f3805035
+Ref: 8054\7f3805126
+Ref: 8055\7f3805251
+Ref: 8056\7f3805322
+Ref: 8057\7f3805378
+Ref: 8058\7f3805539
+Ref: 8059\7f3805619
+Ref: 8060\7f3805688
+Ref: 8061\7f3805727
+Ref: 8062\7f3805784
+Ref: 8063\7f3805852
+Ref: 8064\7f3805951
+Ref: 8065\7f3806015
+Ref: 8066\7f3806110
+Ref: 8067\7f3806176
+Ref: 8068\7f3806381
+Ref: 8069\7f3806567
+Ref: 8070\7f3813171
+Ref: 8071\7f3813436
+Ref: 8072\7f3813548
+Ref: 8073\7f3813605
+Ref: 8074\7f3814315
+Ref: 8075\7f3814874
+Node: B.3.2\7f3816021
+Ref: 8076\7f3817302
+Ref: 8077\7f3817358
+Ref: 8078\7f3817409
+Ref: 8079\7f3817563
+Ref: 8080\7f3817675
+Ref: 8081\7f3818312
+Ref: 8082\7f3818404
+Ref: 8083\7f3818562
+Ref: 8084\7f3818734
+Ref: 8085\7f3818970
+Ref: 8086\7f3822292
+Ref: 8087\7f3822485
+Ref: 8088\7f3822629
+Ref: 8089\7f3822847
+Ref: 8090\7f3823000
+Ref: 8091\7f3823327
+Node: B.3.3\7f3825138
+Ref: 8092\7f3825338
+Ref: 8093\7f3826185
+Ref: 8094\7f3826185
+Ref: 8095\7f3826435
+Ref: 8096\7f3826436
+Ref: 8097\7f3826436
+Ref: 8098\7f3827554
+Ref: 8099\7f3830766
+Ref: 8100\7f3831094
+Ref: 8101\7f3832887
+Ref: 8102\7f3833015
+Ref: 8103\7f3833433
+Node: B.4\7f3833749
+Ref: 8104\7f3833905
+Ref: 8105\7f3833906
+Ref: 8106\7f3834917
+Ref: 8107\7f3835036
+Ref: 8108\7f3835097
+Ref: 8109\7f3835162
+Ref: 8110\7f3835220
+Ref: 8111\7f3835272
+Ref: 8112\7f3835341
+Ref: 8113\7f3835451
+Ref: 8114\7f3835512
+Ref: 8115\7f3835614
+Ref: 8116\7f3835679
+Ref: 8117\7f3835770
+Ref: 8118\7f3835898
+Ref: 8119\7f3836002
+Ref: 8120\7f3836068
+Ref: 8121\7f3836139
+Ref: 8122\7f3836309
+Ref: 8123\7f3836489
+Ref: 8124\7f3836635
+Ref: 8125\7f3836669
+Ref: 8126\7f3836725
+Ref: 8127\7f3836781
+Ref: 8128\7f3836837
+Ref: 8129\7f3836893
+Ref: 8130\7f3836963
+Ref: 8131\7f3836996
+Ref: 8132\7f3837048
+Ref: 8133\7f3837100
+Ref: 8134\7f3837166
+Ref: 8135\7f3837199
+Ref: 8136\7f3837251
+Ref: 8137\7f3837411
+Ref: 8138\7f3837461
+Ref: 8139\7f3837538
+Ref: 8140\7f3837652
+Ref: 8141\7f3837773
+Ref: 8142\7f3837896
+Ref: 8143\7f3837972
+Ref: 8144\7f3838101
+Ref: 8145\7f3838310
+Ref: 8146\7f3838439
+Ref: 8147\7f3838514
+Ref: 8148\7f3838649
+Ref: 8149\7f3838867
+Ref: 8150\7f3838992
+Ref: 8151\7f3839063
+Ref: 8152\7f3839194
+Ref: 8153\7f3839410
+Ref: 8154\7f3839477
+Ref: 8155\7f3839548
+Ref: 8156\7f3839615
+Ref: 8157\7f3841776
+Node: B.5\7f3859524
+Ref: 8158\7f3859672
+Ref: 8159\7f3859673
+Ref: 8160\7f3860488
+Ref: 8161\7f3860535
+Ref: 8162\7f3860600
+Ref: 8163\7f3860664
+Ref: 8164\7f3860731
+Ref: 8165\7f3860774
+Ref: 8166\7f3860882
+Ref: 8167\7f3860957
+Ref: 8168\7f3861015
+Ref: 8169\7f3861079
+Ref: 8170\7f3861157
+Ref: 8171\7f3861257
+Ref: 8172\7f3861364
+Ref: 8173\7f3861436
+Ref: 8174\7f3861508
+Ref: 8175\7f3861581
+Ref: 8176\7f3861659
+Ref: 8177\7f3861840
+Node: Annex C\7f3867023
+Ref: 8178\7f3867164
+Ref: 8179\7f3867164
+Ref: 8180\7f3867165
+Ref: 8181\7f3867165
+Ref: 8182\7f3867165
+Ref: 8183\7f3867165
+Ref: 8184\7f3867424
+Node: C.1\7f3867741
+Ref: 8185\7f3868152
+Ref: 8186\7f3869215
+Ref: 8187\7f3869216
+Ref: 8188\7f3869216
+Ref: 8189\7f3869216
+Node: C.2\7f3873083
+Ref: 8190\7f3873476
+Node: C.3\7f3873605
+Ref: 8191\7f3873880
+Ref: 8192\7f3873933
+Ref: 8193\7f3874034
+Ref: 8194\7f3874139
+Ref: 8195\7f3874267
+Ref: 8196\7f3874365
+Ref: 8197\7f3874453
+Ref: 8198\7f3874593
+Ref: 8199\7f3874595
+Ref: 8200\7f3874871
+Ref: 8201\7f3874873
+Ref: 8202\7f3875699
+Node: C.3.1\7f3882505
+Ref: 8203\7f3883214
+Ref: 8204\7f3883214
+Ref: 8205\7f3883528
+Ref: 8206\7f3883528
+Ref: 8207\7f3884073
+Ref: 8208\7f3885526
+Ref: 8209\7f3885527
+Ref: 8210\7f3885853
+Ref: 8211\7f3885855
+Ref: 8212\7f3885920
+Ref: 8213\7f3886086
+Ref: 8214\7f3886087
+Ref: 8215\7f3886087
+Ref: 8216\7f3886442
+Ref: 8217\7f3886569
+Ref: 8218\7f3888219
+Ref: 8219\7f3888560
+Ref: 8220\7f3891937
+Ref: 8221\7f3894092
+Ref: 8222\7f3895367
+Ref: 8223\7f3895603
+Node: C.3.2\7f3895730
+Ref: 8224\7f3895992
+Ref: 8225\7f3896071
+Ref: 8226\7f3896124
+Ref: 8227\7f3896246
+Ref: 8228\7f3896332
+Ref: 8229\7f3896418
+Ref: 8230\7f3896523
+Ref: 8231\7f3896655
+Ref: 8232\7f3896842
+Ref: 8233\7f3896920
+Ref: 8234\7f3897041
+Ref: 8235\7f3897255
+Ref: 8236\7f3898352
+Ref: 8237\7f3899900
+Ref: 8238\7f3900218
+Ref: 8239\7f3900568
+Ref: 8240\7f3903541
+Node: C.4\7f3903922
+Ref: 8241\7f3904816
+Node: C.5\7f3909005
+Ref: 8242\7f3909357
+Ref: 8243\7f3909358
+Ref: 8244\7f3909381
+Ref: 8245\7f3909565
+Ref: 8246\7f3909567
+Ref: 8247\7f3910116
+Ref: 8248\7f3910116
+Node: C.6\7f3914003
+Ref: 8249\7f3914651
+Ref: 8250\7f3914651
+Ref: 8251\7f3914839
+Ref: 8252\7f3914839
+Ref: 8253\7f3915045
+Ref: 8254\7f3915045
+Ref: 8255\7f3915467
+Ref: 8256\7f3915467
+Ref: 8257\7f3915696
+Ref: 8258\7f3915696
+Ref: 8259\7f3916135
+Ref: 8260\7f3916135
+Ref: 8261\7f3916596
+Ref: 8262\7f3917238
+Ref: 8263\7f3918047
+Ref: 8264\7f3918047
+Ref: 8265\7f3919087
+Ref: 8266\7f3924724
+Ref: 8267\7f3924831
+Ref: 8268\7f3926040
+Ref: 8269\7f3930135
+Ref: 8270\7f3931008
+Ref: 8271\7f3931442
+Node: C.7\7f3932594
+Node: C.7.1\7f3933444
+Ref: 8272\7f3933758
+Ref: 8273\7f3933822
+Ref: 8274\7f3933900
+Ref: 8275\7f3934098
+Ref: 8276\7f3934168
+Ref: 8277\7f3934219
+Ref: 8278\7f3934270
+Ref: 8279\7f3934359
+Ref: 8280\7f3934430
+Ref: 8281\7f3934501
+Ref: 8282\7f3936757
+Ref: 8283\7f3936772
+Ref: 8284\7f3936966
+Ref: 8285\7f3936981
+Ref: 8286\7f3937338
+Ref: 8287\7f3937465
+Ref: 8288\7f3937465
+Ref: 8289\7f3937643
+Ref: 8290\7f3937775
+Ref: 8291\7f3938488
+Ref: 8292\7f3940197
+Node: C.7.2\7f3940689
+Ref: 8293\7f3941132
+Ref: 8294\7f3941149
+Ref: 8295\7f3941211
+Ref: 8296\7f3941294
+Ref: 8297\7f3941389
+Ref: 8298\7f3941498
+Ref: 8299\7f3942793
+Ref: 8300\7f3942908
+Ref: 8301\7f3943952
+Ref: 8302\7f3944437
+Ref: 8303\7f3944804
+Ref: 8304\7f3945082
+Node: C.7.3\7f3954064
+Ref: 8305\7f3954432
+Ref: 8306\7f3954498
+Ref: 8307\7f3954581
+Ref: 8308\7f3954813
+Ref: 8309\7f3954907
+Ref: 8310\7f3954988
+Ref: 8311\7f3955129
+Ref: 8312\7f3955364
+Ref: 8313\7f3955365
+Ref: 8314\7f3956490
+Ref: 8315\7f3956491
+Ref: 8316\7f3956491
+Ref: 8317\7f3956491
+Ref: 8318\7f3956491
+Ref: 8319\7f3956491
+Ref: 8320\7f3959885
+Node: Annex D\7f3960535
+Ref: 8321\7f3960671
+Ref: 8322\7f3960671
+Ref: 8323\7f3964320
+Node: D.1\7f3964939
+Ref: 8324\7f3965737
+Ref: 8325\7f3965737
+Ref: 8326\7f3966065
+Ref: 8327\7f3966065
+Ref: 8328\7f3968374
+Ref: 8329\7f3968374
+Ref: 8330\7f3968374
+Ref: 8331\7f3968374
+Ref: 8332\7f3968374
+Ref: 8333\7f3969496
+Ref: 8334\7f3969915
+Ref: 8335\7f3969917
+Ref: 8336\7f3973219
+Ref: 8337\7f3974175
+Node: D.2\7f3974307
+Node: D.2.1\7f3975129
+Ref: 8338\7f3975597
+Ref: 8339\7f3975688
+Ref: 8340\7f3975734
+Ref: 8341\7f3976547
+Ref: 8342\7f3976548
+Ref: 8343\7f3976548
+Ref: 8344\7f3976548
+Ref: 8345\7f3977158
+Ref: 8346\7f3977159
+Ref: 8347\7f3977159
+Ref: 8348\7f3977159
+Ref: 8349\7f3977159
+Ref: 8350\7f3977159
+Ref: 8351\7f3978146
+Ref: 8352\7f3980494
+Ref: 8353\7f3982740
+Node: D.2.2\7f3983119
+Ref: 8354\7f3983636
+Ref: 8355\7f3983637
+Ref: 8356\7f3983668
+Ref: 8357\7f3983813
+Ref: 8358\7f3983814
+Ref: 8359\7f3983863
+Ref: 8360\7f3983890
+Ref: 8361\7f3983916
+Ref: 8362\7f3986283
+Ref: 8363\7f3986284
+Ref: 8364\7f3986410
+Ref: 8365\7f3986412
+Ref: 8366\7f3986891
+Ref: 8367\7f3987336
+Ref: 8368\7f3990008
+Node: D.2.3\7f3991101
+Ref: 8369\7f3991510
+Ref: 8370\7f3991510
+Ref: 8371\7f3992825
+Ref: 8372\7f3992826
+Ref: 8373\7f3993267
+Ref: 8374\7f3993837
+Node: D.2.4\7f3995871
+Ref: 8375\7f3996336
+Ref: 8376\7f3996336
+Ref: 8377\7f3996477
+Ref: 8378\7f3996539
+Ref: 8379\7f3996573
+Ref: 8380\7f3999627
+Ref: 8381\7f3999627
+Ref: 8382\7f4002531
+Ref: 8383\7f4002686
+Node: D.2.5\7f4002741
+Ref: 8384\7f4003208
+Ref: 8385\7f4003208
+Ref: 8386\7f4003389
+Ref: 8387\7f4003392
+Ref: 8388\7f4003510
+Ref: 8389\7f4003639
+Ref: 8390\7f4003771
+Ref: 8391\7f4003876
+Ref: 8392\7f4008680
+Node: D.2.6\7f4008784
+Ref: 8393\7f4011417
+Ref: 8394\7f4011417
+Ref: 8395\7f4011607
+Ref: 8396\7f4011623
+Ref: 8397\7f4011657
+Ref: 8398\7f4011763
+Ref: 8399\7f4011930
+Ref: 8400\7f4012104
+Ref: 8401\7f4012600
+Ref: 8402\7f4012600
+Ref: 8403\7f4018573
+Ref: 8404\7f4018968
+Ref: 8405\7f4020634
+Ref: 8406\7f4020802
+Node: D.3\7f4021108
+Ref: 8407\7f4021582
+Ref: 8408\7f4021583
+Ref: 8409\7f4021605
+Ref: 8410\7f4021677
+Ref: 8411\7f4021748
+Ref: 8412\7f4021830
+Ref: 8413\7f4021941
+Ref: 8414\7f4021941
+Ref: 8415\7f4022122
+Ref: 8416\7f4022931
+Ref: 8417\7f4023616
+Ref: 8418\7f4023618
+Ref: 8419\7f4023713
+Ref: 8420\7f4023713
+Ref: 8421\7f4023777
+Ref: 8422\7f4025349
+Ref: 8423\7f4025349
+Ref: 8424\7f4025349
+Ref: 8425\7f4025852
+Ref: 8426\7f4026005
+Ref: 8427\7f4026301
+Ref: 8428\7f4031557
+Node: D.4\7f4032826
+Ref: 8429\7f4033034
+Ref: 8430\7f4033405
+Ref: 8431\7f4033406
+Ref: 8432\7f4033428
+Ref: 8433\7f4033500
+Ref: 8434\7f4033586
+Ref: 8435\7f4033651
+Ref: 8436\7f4033651
+Ref: 8437\7f4033752
+Ref: 8438\7f4034507
+Ref: 8439\7f4034507
+Ref: 8440\7f4034638
+Ref: 8441\7f4034638
+Ref: 8442\7f4034647
+Node: D.5\7f4042481
+Node: D.5.1\7f4043091
+Ref: 8443\7f4043601
+Ref: 8444\7f4043674
+Ref: 8445\7f4043888
+Ref: 8446\7f4044380
+Ref: 8447\7f4045437
+Ref: 8448\7f4048656
+Ref: 8449\7f4052495
+Node: D.5.2\7f4053497
+Ref: 8450\7f4053994
+Ref: 8451\7f4054009
+Ref: 8452\7f4055249
+Ref: 8453\7f4056490
+Node: D.6\7f4056599
+Node: D.7\7f4060362
+Ref: 8454\7f4060857
+Ref: 8455\7f4060858
+Ref: 8456\7f4061780
+Ref: 8457\7f4061781
+Ref: 8458\7f4062852
+Ref: 8459\7f4062853
+Ref: 8460\7f4063008
+Ref: 8461\7f4063008
+Ref: 8462\7f4063127
+Ref: 8463\7f4063127
+Ref: 8464\7f4063603
+Ref: 8465\7f4063607
+Ref: 8466\7f4063607
+Ref: 8467\7f4064226
+Ref: 8468\7f4064228
+Ref: 8469\7f4064342
+Ref: 8470\7f4064343
+Ref: 8471\7f4064874
+Ref: 8472\7f4064875
+Ref: 8473\7f4065033
+Ref: 8474\7f4065034
+Ref: 8475\7f4065159
+Ref: 8476\7f4065160
+Ref: 8477\7f4065683
+Ref: 8478\7f4065745
+Ref: 8479\7f4065746
+Ref: 8480\7f4066001
+Ref: 8481\7f4066002
+Ref: 8482\7f4066108
+Ref: 8483\7f4066109
+Ref: 8484\7f4066238
+Ref: 8485\7f4066239
+Ref: 8486\7f4066493
+Ref: 8487\7f4066494
+Ref: 8488\7f4066789
+Ref: 8489\7f4066789
+Ref: 8490\7f4066915
+Ref: 8491\7f4066915
+Ref: 8492\7f4067592
+Ref: 8493\7f4067594
+Ref: 8494\7f4067850
+Ref: 8495\7f4067851
+Ref: 8496\7f4068464
+Ref: 8497\7f4068465
+Ref: 8498\7f4068773
+Ref: 8499\7f4068774
+Ref: 8500\7f4068774
+Ref: 8501\7f4069017
+Ref: 8502\7f4069018
+Ref: 8503\7f4069527
+Ref: 8504\7f4069528
+Ref: 8505\7f4069528
+Ref: 8506\7f4069778
+Ref: 8507\7f4069779
+Ref: 8508\7f4070254
+Ref: 8509\7f4070255
+Ref: 8510\7f4070255
+Ref: 8511\7f4070844
+Ref: 8512\7f4070845
+Ref: 8513\7f4071123
+Ref: 8514\7f4071156
+Ref: 8515\7f4071157
+Ref: 8516\7f4071917
+Ref: 8517\7f4072891
+Ref: 8518\7f4073759
+Ref: 8519\7f4074962
+Ref: 8520\7f4076930
+Node: D.8\7f4077679
+Ref: 8521\7f4078027
+Ref: 8522\7f4078043
+Ref: 8523\7f4078062
+Ref: 8524\7f4078097
+Ref: 8525\7f4078131
+Ref: 8526\7f4078211
+Ref: 8527\7f4078235
+Ref: 8528\7f4078280
+Ref: 8529\7f4078324
+Ref: 8530\7f4078368
+Ref: 8531\7f4078415
+Ref: 8532\7f4078463
+Ref: 8533\7f4079827
+Ref: 8534\7f4079889
+Ref: 8535\7f4079986
+Ref: 8536\7f4080048
+Ref: 8537\7f4080110
+Ref: 8538\7f4080172
+Ref: 8539\7f4080234
+Ref: 8540\7f4080296
+Ref: 8541\7f4080364
+Ref: 8542\7f4080444
+Ref: 8543\7f4080637
+Ref: 8544\7f4081720
+Ref: 8545\7f4081720
+Ref: 8546\7f4083870
+Ref: 8547\7f4087058
+Ref: 8548\7f4089785
+Ref: 8549\7f4093954
+Node: D.9\7f4094827
+Ref: 8550\7f4095854
+Ref: 8551\7f4095854
+Ref: 8552\7f4098225
+Ref: 8553\7f4098225
+Node: D.10\7f4100336
+Ref: 8554\7f4100880
+Ref: 8555\7f4100950
+Ref: 8556\7f4101005
+Ref: 8557\7f4101062
+Ref: 8558\7f4101119
+Ref: 8559\7f4101189
+Ref: 8560\7f4101746
+Ref: 8561\7f4101765
+Ref: 8562\7f4103028
+Ref: 8563\7f4103028
+Ref: 8564\7f4103028
+Ref: 8565\7f4104254
+Ref: 8566\7f4104445
+Node: D.10.1\7f4104557
+Ref: 8567\7f4105055
+Ref: 8568\7f4105128
+Ref: 8569\7f4105317
+Ref: 8570\7f4105416
+Ref: 8571\7f4107472
+Node: D.11\7f4107529
+Ref: 8572\7f4108092
+Ref: 8573\7f4108165
+Ref: 8574\7f4108228
+Ref: 8575\7f4108294
+Ref: 8576\7f4108483
+Ref: 8577\7f4108484
+Ref: 8578\7f4108484
+Ref: 8579\7f4110475
+Ref: 8580\7f4110520
+Ref: 8581\7f4110631
+Ref: 8582\7f4113648
+Node: D.12\7f4114330
+Node: D.13\7f4117843
+Ref: 8583\7f4118103
+Ref: 8584\7f4122055
+Node: D.14\7f4122299
+Ref: 8585\7f4122806
+Ref: 8586\7f4122825
+Ref: 8587\7f4122849
+Ref: 8588\7f4122893
+Ref: 8589\7f4122937
+Ref: 8590\7f4123010
+Ref: 8591\7f4123068
+Ref: 8592\7f4123794
+Ref: 8593\7f4123895
+Ref: 8594\7f4124041
+Ref: 8595\7f4124154
+Ref: 8596\7f4124295
+Ref: 8597\7f4124510
+Ref: 8598\7f4124511
+Ref: 8599\7f4126628
+Ref: 8600\7f4128173
+Ref: 8601\7f4131016
+Ref: 8602\7f4131158
+Node: D.14.1\7f4132196
+Ref: 8603\7f4132726
+Ref: 8604\7f4132745
+Ref: 8605\7f4132898
+Ref: 8606\7f4132982
+Ref: 8607\7f4133096
+Ref: 8608\7f4133266
+Ref: 8609\7f4133434
+Ref: 8610\7f4133503
+Ref: 8611\7f4133630
+Ref: 8612\7f4133684
+Ref: 8613\7f4134295
+Ref: 8614\7f4134297
+Ref: 8615\7f4134498
+Ref: 8616\7f4136327
+Ref: 8617\7f4138737
+Ref: 8618\7f4140278
+Node: D.14.2\7f4140332
+Ref: 8619\7f4140912
+Ref: 8620\7f4140980
+Ref: 8621\7f4141150
+Ref: 8622\7f4141258
+Ref: 8623\7f4141380
+Ref: 8624\7f4141613
+Ref: 8625\7f4141735
+Ref: 8626\7f4141861
+Ref: 8627\7f4141987
+Ref: 8628\7f4142085
+Ref: 8629\7f4142154
+Ref: 8630\7f4142228
+Ref: 8631\7f4142301
+Ref: 8632\7f4142372
+Ref: 8633\7f4142450
+Ref: 8634\7f4142576
+Ref: 8635\7f4142668
+Ref: 8636\7f4142784
+Ref: 8637\7f4143092
+Ref: 8638\7f4143579
+Ref: 8639\7f4143579
+Ref: 8640\7f4143579
+Ref: 8641\7f4143868
+Ref: 8642\7f4143870
+Ref: 8643\7f4149144
+Ref: 8644\7f4150486
+Ref: 8645\7f4150641
+Node: D.14.3\7f4151167
+Ref: 8646\7f4151686
+Ref: 8647\7f4151704
+Ref: 8648\7f4151799
+Ref: 8649\7f4153412
+Node: D.15\7f4153470
+Ref: 8650\7f4154006
+Ref: 8651\7f4154024
+Ref: 8652\7f4154076
+Ref: 8653\7f4154192
+Ref: 8654\7f4154368
+Ref: 8655\7f4154548
+Ref: 8656\7f4154645
+Ref: 8657\7f4154774
+Ref: 8658\7f4155080
+Ref: 8659\7f4155324
+Ref: 8660\7f4155326
+Ref: 8661\7f4155540
+Ref: 8662\7f4162638
+Node: D.16\7f4163498
+Ref: 8663\7f4163944
+Ref: 8664\7f4164009
+Ref: 8665\7f4164060
+Ref: 8666\7f4164127
+Ref: 8667\7f4164301
+Ref: 8668\7f4164878
+Ref: 8669\7f4164878
+Ref: 8670\7f4166969
+Node: D.16.1\7f4167103
+Ref: 8671\7f4167687
+Ref: 8672\7f4167696
+Ref: 8673\7f4167757
+Ref: 8674\7f4167809
+Ref: 8675\7f4167893
+Ref: 8676\7f4167969
+Ref: 8677\7f4168047
+Ref: 8678\7f4168126
+Ref: 8679\7f4168329
+Ref: 8680\7f4168598
+Ref: 8681\7f4168778
+Ref: 8682\7f4168957
+Ref: 8683\7f4170042
+Ref: 8684\7f4170042
+Ref: 8685\7f4175780
+Node: Annex E\7f4175901
+Ref: 8686\7f4176264
+Ref: 8687\7f4176355
+Ref: 8688\7f4176355
+Ref: 8689\7f4176355
+Ref: 8690\7f4176656
+Ref: 8691\7f4176797
+Node: E.1\7f4178202
+Ref: 8692\7f4178434
+Ref: 8693\7f4178434
+Ref: 8694\7f4179626
+Ref: 8695\7f4180465
+Ref: 8696\7f4180862
+Ref: 8697\7f4180862
+Ref: 8698\7f4180862
+Ref: 8699\7f4180862
+Ref: 8700\7f4181565
+Ref: 8701\7f4181580
+Ref: 8702\7f4181985
+Ref: 8703\7f4182117
+Node: E.2\7f4184678
+Ref: 8704\7f4185118
+Ref: 8705\7f4185119
+Ref: 8706\7f4185119
+Ref: 8707\7f4185119
+Ref: 8708\7f4185119
+Ref: 8709\7f4185119
+Ref: 8710\7f4185909
+Ref: 8711\7f4186044
+Ref: 8712\7f4186177
+Ref: 8713\7f4186286
+Node: E.2.1\7f4189499
+Ref: 8714\7f4190405
+Ref: 8715\7f4190410
+Ref: 8716\7f4190477
+Ref: 8717\7f4190478
+Ref: 8718\7f4190507
+Ref: 8719\7f4190589
+Ref: 8720\7f4190724
+Ref: 8721\7f4190724
+Ref: 8722\7f4192697
+Ref: 8723\7f4192697
+Ref: 8724\7f4193652
+Ref: 8725\7f4193854
+Ref: 8726\7f4193854
+Ref: 8727\7f4193854
+Ref: 8728\7f4194485
+Node: E.2.2\7f4194673
+Ref: 8729\7f4195460
+Ref: 8730\7f4195465
+Ref: 8731\7f4195530
+Ref: 8732\7f4195531
+Ref: 8733\7f4195558
+Ref: 8734\7f4195640
+Ref: 8735\7f4195769
+Ref: 8736\7f4195769
+Ref: 8737\7f4198348
+Ref: 8738\7f4198485
+Ref: 8739\7f4198487
+Ref: 8740\7f4203120
+Ref: 8741\7f4204033
+Ref: 8742\7f4206144
+Ref: 8743\7f4206854
+Ref: 8744\7f4207363
+Node: E.2.3\7f4207539
+Ref: 8745\7f4208183
+Ref: 8746\7f4208188
+Ref: 8747\7f4208262
+Ref: 8748\7f4208263
+Ref: 8749\7f4208299
+Ref: 8750\7f4208384
+Ref: 8751\7f4208385
+Ref: 8752\7f4208416
+Ref: 8753\7f4208427
+Ref: 8754\7f4208432
+Ref: 8755\7f4208608
+Ref: 8756\7f4208609
+Ref: 8757\7f4208609
+Ref: 8758\7f4208609
+Ref: 8759\7f4208609
+Ref: 8760\7f4208757
+Ref: 8761\7f4208757
+Ref: 8762\7f4213133
+Ref: 8763\7f4213134
+Ref: 8764\7f4214187
+Ref: 8765\7f4214187
+Ref: 8766\7f4214187
+Ref: 8767\7f4216603
+Ref: 8768\7f4217884
+Ref: 8769\7f4218400
+Node: E.3\7f4219010
+Ref: 8770\7f4219829
+Ref: 8771\7f4219844
+Ref: 8772\7f4220040
+Ref: 8773\7f4220055
+Ref: 8774\7f4220318
+Ref: 8775\7f4220660
+Ref: 8776\7f4221143
+Ref: 8777\7f4221143
+Ref: 8778\7f4221555
+Node: E.4\7f4223054
+Ref: 8779\7f4223186
+Ref: 8780\7f4223186
+Ref: 8781\7f4223186
+Ref: 8782\7f4223186
+Ref: 8783\7f4223186
+Ref: 8784\7f4225008
+Ref: 8785\7f4225008
+Ref: 8786\7f4225008
+Ref: 8787\7f4225699
+Ref: 8788\7f4225699
+Ref: 8789\7f4226271
+Ref: 8790\7f4226711
+Ref: 8791\7f4227860
+Ref: 8792\7f4227860
+Ref: 8793\7f4228229
+Ref: 8794\7f4228230
+Ref: 8795\7f4228521
+Ref: 8796\7f4230066
+Ref: 8797\7f4230066
+Ref: 8798\7f4230421
+Ref: 8799\7f4237819
+Ref: 8800\7f4238919
+Node: E.4.1\7f4241331
+Ref: 8801\7f4242120
+Ref: 8802\7f4242120
+Ref: 8803\7f4243254
+Ref: 8804\7f4243255
+Ref: 8805\7f4244072
+Node: E.4.2\7f4244152
+Node: E.5\7f4248558
+Ref: 8806\7f4248728
+Ref: 8807\7f4248729
+Ref: 8808\7f4249273
+Ref: 8809\7f4249290
+Ref: 8810\7f4249347
+Ref: 8811\7f4249401
+Ref: 8812\7f4249564
+Ref: 8813\7f4249752
+Ref: 8814\7f4249911
+Ref: 8815\7f4250114
+Ref: 8816\7f4250273
+Ref: 8817\7f4250432
+Ref: 8818\7f4252514
+Ref: 8819\7f4252889
+Ref: 8820\7f4254620
+Ref: 8821\7f4254620
+Ref: 8822\7f4261509
+Node: Annex F\7f4262003
+Ref: 8823\7f4262143
+Ref: 8824\7f4264230
+Node: F.1\7f4264623
+Ref: 8825\7f4264825
+Ref: 8826\7f4264825
+Ref: 8827\7f4265107
+Ref: 8828\7f4265107
+Node: F.2\7f4266661
+Ref: 8829\7f4266920
+Ref: 8830\7f4266957
+Ref: 8831\7f4267013
+Ref: 8832\7f4267072
+Ref: 8833\7f4267124
+Ref: 8834\7f4267179
+Ref: 8835\7f4267521
+Node: F.3\7f4269491
+Ref: 8836\7f4269811
+Node: F.3.1\7f4275020
+Ref: 8837\7f4275172
+Ref: 8838\7f4275173
+Node: F.3.2\7f4282621
+Ref: 8839\7f4284030
+Node: F.3.3\7f4295253
+Ref: 8840\7f4296009
+Ref: 8841\7f4296026
+Ref: 8842\7f4296066
+Ref: 8843\7f4296201
+Ref: 8844\7f4296357
+Ref: 8845\7f4296424
+Ref: 8846\7f4296481
+Ref: 8847\7f4296550
+Ref: 8848\7f4296595
+Ref: 8849\7f4296652
+Ref: 8850\7f4296709
+Ref: 8851\7f4296766
+Ref: 8852\7f4297296
+Ref: 8853\7f4297334
+Ref: 8854\7f4297489
+Ref: 8855\7f4297688
+Ref: 8856\7f4298117
+Ref: 8857\7f4298564
+Ref: 8858\7f4298958
+Node: F.3.4\7f4307948
+Ref: 8859\7f4308150
+Ref: 8860\7f4308150
+Node: F.3.5\7f4308904
+Ref: 8861\7f4309132
+Ref: 8862\7f4309133
+Ref: 8863\7f4310065
+Node: Annex G\7f4310223
+Ref: 8864\7f4310341
+Ref: 8865\7f4312195
+Node: G.1\7f4312370
+Node: G.1.1\7f4313687
+Ref: 8866\7f4313994
+Ref: 8867\7f4314138
+Ref: 8868\7f4314271
+Ref: 8869\7f4314355
+Ref: 8870\7f4314387
+Ref: 8871\7f4314436
+Ref: 8872\7f4314490
+Ref: 8873\7f4314544
+Ref: 8874\7f4314602
+Ref: 8875\7f4314699
+Ref: 8876\7f4314796
+Ref: 8877\7f4314897
+Ref: 8878\7f4314974
+Ref: 8879\7f4315051
+Ref: 8880\7f4315131
+Ref: 8881\7f4315273
+Ref: 8882\7f4315337
+Ref: 8883\7f4315449
+Ref: 8884\7f4315551
+Ref: 8885\7f4315779
+Ref: 8886\7f4316298
+Ref: 8887\7f4319089
+Ref: 8888\7f4327554
+Ref: 8889\7f4327554
+Ref: 8890\7f4327554
+Ref: 8891\7f4327896
+Ref: 8892\7f4329557
+Ref: 8893\7f4338327
+Node: G.1.2\7f4338719
+Ref: 8894\7f4339110
+Ref: 8895\7f4339380
+Ref: 8896\7f4339434
+Ref: 8897\7f4339488
+Ref: 8898\7f4339542
+Ref: 8899\7f4339827
+Ref: 8900\7f4339878
+Ref: 8901\7f4339929
+Ref: 8902\7f4339980
+Ref: 8903\7f4340034
+Ref: 8904\7f4340088
+Ref: 8905\7f4340142
+Ref: 8906\7f4340196
+Ref: 8907\7f4340253
+Ref: 8908\7f4340305
+Ref: 8909\7f4340357
+Ref: 8910\7f4340409
+Ref: 8911\7f4340464
+Ref: 8912\7f4340519
+Ref: 8913\7f4340574
+Ref: 8914\7f4340629
+Ref: 8915\7f4340784
+Ref: 8916\7f4346803
+Ref: 8917\7f4346803
+Ref: 8918\7f4346803
+Ref: 8919\7f4347755
+Ref: 8920\7f4349793
+Ref: 8921\7f4353041
+Ref: 8922\7f4353843
+Node: G.1.3\7f4356531
+Ref: 8923\7f4357763
+Ref: 8924\7f4357936
+Ref: 8925\7f4357971
+Ref: 8926\7f4358020
+Ref: 8927\7f4358073
+Ref: 8928\7f4358211
+Ref: 8929\7f4358306
+Ref: 8930\7f4358559
+Ref: 8931\7f4358771
+Ref: 8932\7f4358901
+Ref: 8933\7f4359152
+Ref: 8934\7f4368828
+Node: G.1.4\7f4369237
+Ref: 8935\7f4369445
+Ref: 8936\7f4369445
+Node: G.1.5\7f4369856
+Ref: 8937\7f4370090
+Ref: 8938\7f4370091
+Ref: 8939\7f4370614
+Node: G.2\7f4370763
+Ref: 8940\7f4370965
+Ref: 8941\7f4370965
+Ref: 8942\7f4371445
+Ref: 8943\7f4373502
+Node: G.2.1\7f4373971
+Ref: 8944\7f4374994
+Ref: 8945\7f4377083
+Ref: 8946\7f4377184
+Ref: 8947\7f4377995
+Ref: 8948\7f4378384
+Ref: 8949\7f4379460
+Ref: 8950\7f4379460
+Ref: 8951\7f4379739
+Ref: 8952\7f4381585
+Ref: 8953\7f4383665
+Node: G.2.2\7f4383959
+Ref: 8954\7f4384528
+Ref: 8955\7f4384528
+Ref: 8956\7f4385625
+Ref: 8957\7f4385625
+Ref: 8958\7f4386161
+Ref: 8959\7f4386161
+Ref: 8960\7f4386958
+Ref: 8961\7f4386958
+Ref: 8962\7f4387755
+Ref: 8963\7f4387757
+Ref: 8964\7f4387757
+Ref: 8965\7f4388093
+Ref: 8966\7f4388094
+Ref: 8967\7f4389603
+Ref: 8968\7f4389604
+Node: G.2.3\7f4392447
+Ref: 8969\7f4394006
+Ref: 8970\7f4394174
+Ref: 8971\7f4400913
+Ref: 8972\7f4400915
+Ref: 8973\7f4401066
+Ref: 8974\7f4401541
+Node: G.2.4\7f4403496
+Ref: 8975\7f4403848
+Ref: 8976\7f4403848
+Ref: 8977\7f4404310
+Ref: 8978\7f4404312
+Ref: 8979\7f4404464
+Ref: 8980\7f4405673
+Node: G.2.5\7f4411183
+Node: G.2.6\7f4423841
+Ref: 8981\7f4424510
+Ref: 8982\7f4424975
+Ref: 8983\7f4425249
+Ref: 8984\7f4425635
+Ref: 8985\7f4425637
+Ref: 8986\7f4427514
+Node: G.3\7f4434812
+Ref: 8987\7f4436600
+Node: G.3.1\7f4436792
+Ref: 8988\7f4437212
+Ref: 8989\7f4437295
+Ref: 8990\7f4437362
+Ref: 8991\7f4438505
+Ref: 8992\7f4438987
+Ref: 8993\7f4439938
+Ref: 8994\7f4440016
+Ref: 8995\7f4440080
+Ref: 8996\7f4440143
+Ref: 8997\7f4440282
+Ref: 8998\7f4440356
+Ref: 8999\7f4440582
+Ref: 9000\7f4440839
+Ref: 9001\7f4442659
+Ref: 9002\7f4446099
+Ref: 9003\7f4455124
+Ref: 9004\7f4461122
+Node: G.3.2\7f4461393
+Ref: 9005\7f4462086
+Ref: 9006\7f4462172
+Ref: 9007\7f4462240
+Ref: 9008\7f4462506
+Ref: 9009\7f4462567
+Ref: 9010\7f4462634
+Ref: 9011\7f4462740
+Ref: 9012\7f4462850
+Ref: 9013\7f4462947
+Ref: 9014\7f4463050
+Ref: 9015\7f4463262
+Ref: 9016\7f4463333
+Ref: 9017\7f4463461
+Ref: 9018\7f4463565
+Ref: 9019\7f4463949
+Ref: 9020\7f4465888
+Ref: 9021\7f4466199
+Ref: 9022\7f4466260
+Ref: 9023\7f4466328
+Ref: 9024\7f4466434
+Ref: 9025\7f4466545
+Ref: 9026\7f4466642
+Ref: 9027\7f4466745
+Ref: 9028\7f4466963
+Ref: 9029\7f4467034
+Ref: 9030\7f4467162
+Ref: 9031\7f4467266
+Ref: 9032\7f4467648
+Ref: 9033\7f4467723
+Ref: 9034\7f4470614
+Ref: 9035\7f4470712
+Ref: 9036\7f4470782
+Ref: 9037\7f4470851
+Ref: 9038\7f4470986
+Ref: 9039\7f4471062
+Ref: 9040\7f4471294
+Ref: 9041\7f4471557
+Ref: 9042\7f4473404
+Ref: 9043\7f4482321
+Ref: 9044\7f4499770
+Ref: 9045\7f4505726
+Node: Annex H\7f4506001
+Ref: 9046\7f4506177
+Ref: 9047\7f4506178
+Ref: 9048\7f4506839
+Ref: 9049\7f4506969
+Ref: 9050\7f4506970
+Ref: 9051\7f4507745
+Node: H.1\7f4508578
+Ref: 9052\7f4509216
+Ref: 9053\7f4509217
+Ref: 9054\7f4509288
+Ref: 9055\7f4509288
+Node: H.2\7f4512931
+Ref: 9056\7f4513150
+Node: H.3\7f4515348
+Node: H.3.1\7f4515651
+Ref: 9057\7f4516475
+Ref: 9058\7f4516476
+Ref: 9059\7f4516540
+Ref: 9060\7f4516540
+Node: H.3.2\7f4525303
+Ref: 9061\7f4525948
+Ref: 9062\7f4525949
+Ref: 9063\7f4525974
+Ref: 9064\7f4525989
+Ref: 9065\7f4526475
+Ref: 9066\7f4526611
+Node: H.4\7f4531965
+Ref: 9067\7f4533132
+Ref: 9068\7f4533132
+Ref: 9069\7f4533294
+Ref: 9070\7f4533294
+Ref: 9071\7f4533413
+Ref: 9072\7f4533414
+Ref: 9073\7f4533883
+Ref: 9074\7f4533884
+Ref: 9075\7f4534006
+Ref: 9076\7f4534007
+Ref: 9077\7f4534117
+Ref: 9078\7f4534118
+Ref: 9079\7f4534666
+Ref: 9080\7f4534668
+Ref: 9081\7f4534911
+Ref: 9082\7f4534911
+Ref: 9083\7f4535826
+Ref: 9084\7f4535826
+Ref: 9085\7f4536700
+Ref: 9086\7f4536700
+Ref: 9087\7f4537518
+Ref: 9088\7f4537520
+Ref: 9089\7f4538018
+Ref: 9090\7f4538018
+Ref: 9091\7f4538056
+Ref: 9092\7f4538057
+Ref: 9093\7f4538104
+Ref: 9094\7f4538104
+Ref: 9095\7f4538248
+Ref: 9096\7f4538249
+Ref: 9097\7f4538774
+Ref: 9098\7f4538774
+Ref: 9099\7f4539139
+Ref: 9100\7f4539139
+Ref: 9101\7f4539264
+Ref: 9102\7f4539264
+Ref: 9103\7f4543753
+Ref: 9104\7f4544170
+Ref: 9105\7f4545853
+Ref: 9106\7f4546840
+Node: H.5\7f4547865
+Ref: 9107\7f4548299
+Ref: 9108\7f4548300
+Ref: 9109\7f4548399
+Ref: 9110\7f4548400
+Ref: 9111\7f4549249
+Node: H.6\7f4549282
+Ref: 9112\7f4549724
+Ref: 9113\7f4549725
+Ref: 9114\7f4549762
+Ref: 9115\7f4550519
+Ref: 9116\7f4550520
+Ref: 9117\7f4551005
+Ref: 9118\7f4553893
+Node: Annex J\7f4553949
+Ref: 9119\7f4554123
+Node: J.1\7f4556879
+Node: J.2\7f4558181
+Node: J.3\7f4560896
+Ref: 9120\7f4561603
+Ref: S0321\7f4561603
+Ref: 9121\7f4561621
+Ref: 9122\7f4561633
+Ref: 9123\7f4561703
+Ref: 9124\7f4561997
+Ref: 9125\7f4563252
+Ref: 9126\7f4563465
+Ref: 9127\7f4563697
+Node: J.4\7f4564658
+Ref: 9128\7f4564984
+Ref: 9129\7f4564984
+Node: J.5\7f4566409
+Node: J.6\7f4569014
+Node: J.7\7f4570146
+Ref: 9130\7f4570307
+Ref: S0322\7f4570307
+Ref: 9131\7f4570316
+Ref: 9132\7f4570335
+Ref: 9133\7f4571089
+Node: J.7.1\7f4571636
+Ref: 9134\7f4572166
+Ref: 9135\7f4572168
+Ref: 9136\7f4572168
+Ref: 9137\7f4572570
+Ref: 9138\7f4572905
+Ref: 9139\7f4573182
+Ref: 9140\7f4573332
+Ref: 9141\7f4574001
+Node: J.8\7f4577416
+Ref: 9142\7f4577580
+Ref: S0323\7f4577580
+Ref: 9143\7f4577599
+Node: J.9\7f4578668
+Ref: 9144\7f4578918
+Ref: 9145\7f4578918
+Ref: 9146\7f4579813
+Node: J.10\7f4580957
+Ref: 9147\7f4581364
+Ref: 9148\7f4581365
+Ref: 9149\7f4581374
+Ref: 9150\7f4581393
+Node: J.11\7f4584135
+Ref: 9151\7f4584570
+Ref: 9152\7f4584570
+Node: J.12\7f4585510
+Node: J.13\7f4586656
+Ref: 9153\7f4587185
+Ref: 9154\7f4587361
+Ref: 9155\7f4587541
+Node: J.14\7f4587950
+Node: J.15\7f4589487
+Node: J.15.1\7f4590466
+Ref: 9156\7f4590749
+Ref: 9157\7f4590749
+Ref: 9158\7f4590769
+Ref: 9159\7f4590770
+Ref: 9160\7f4590778
+Ref: 9161\7f4590784
+Ref: 9162\7f4592987
+Ref: 9163\7f4593460
+Ref: 9164\7f4593771
+Node: J.15.2\7f4594136
+Ref: 9165\7f4594443
+Ref: 9166\7f4594443
+Ref: 9167\7f4594463
+Ref: 9168\7f4594464
+Ref: 9169\7f4594485
+Ref: 9170\7f4594508
+Node: J.15.3\7f4595265
+Ref: 9171\7f4595557
+Ref: 9172\7f4595557
+Ref: 9173\7f4595577
+Ref: 9174\7f4595578
+Ref: 9175\7f4595598
+Node: J.15.4\7f4596213
+Ref: 9176\7f4596494
+Ref: 9177\7f4596495
+Ref: 9178\7f4596509
+Ref: 9179\7f4596795
+Node: J.15.5\7f4597311
+Ref: 9180\7f4597519
+Ref: 9181\7f4597520
+Ref: 9182\7f4597520
+Ref: 9183\7f4597520
+Ref: 9184\7f4597520
+Ref: 9185\7f4597520
+Ref: 9186\7f4597520
+Ref: 9187\7f4597520
+Ref: 9188\7f4597520
+Ref: 9189\7f4597520
+Ref: 9190\7f4597520
+Ref: 9191\7f4597520
+Ref: 9192\7f4597520
+Ref: 9193\7f4597683
+Ref: 9194\7f4597684
+Ref: 9195\7f4597729
+Ref: 9196\7f4597752
+Ref: 9197\7f4597814
+Ref: 9198\7f4597868
+Ref: 9199\7f4597900
+Ref: 9200\7f4597901
+Ref: 9201\7f4597946
+Ref: 9202\7f4597969
+Ref: 9203\7f4598031
+Ref: 9204\7f4598085
+Ref: 9205\7f4598117
+Ref: 9206\7f4598118
+Ref: 9207\7f4598156
+Ref: 9208\7f4598183
+Ref: 9209\7f4598489
+Ref: 9210\7f4598490
+Ref: 9211\7f4598884
+Node: J.15.6\7f4600872
+Ref: 9212\7f4601197
+Ref: 9213\7f4601198
+Ref: 9214\7f4601222
+Ref: 9215\7f4601223
+Ref: 9216\7f4601254
+Node: J.15.7\7f4601976
+Ref: 9217\7f4602312
+Ref: 9218\7f4602313
+Ref: 9219\7f4602340
+Ref: 9220\7f4602456
+Ref: 9221\7f4602457
+Ref: 9222\7f4602481
+Ref: 9223\7f4602486
+Ref: 9224\7f4602871
+Ref: 9225\7f4603295
+Ref: 9226\7f4604850
+Node: J.15.8\7f4605444
+Ref: 9227\7f4605827
+Ref: 9228\7f4605828
+Ref: 9229\7f4605836
+Ref: 9230\7f4605867
+Ref: 9231\7f4605868
+Ref: 9232\7f4605878
+Ref: 9233\7f4605934
+Ref: 9234\7f4605935
+Ref: 9235\7f4605958
+Ref: 9236\7f4605995
+Ref: 9237\7f4605996
+Ref: 9238\7f4606021
+Ref: 9239\7f4606052
+Ref: 9240\7f4606053
+Ref: 9241\7f4606080
+Ref: 9242\7f4606136
+Ref: 9243\7f4606137
+Ref: 9244\7f4606161
+Ref: 9245\7f4607793
+Ref: 9246\7f4607795
+Ref: 9247\7f4607795
+Ref: 9248\7f4607795
+Ref: 9249\7f4607795
+Ref: 9250\7f4607795
+Ref: 9251\7f4607795
+Ref: 9252\7f4607795
+Ref: 9253\7f4607795
+Ref: 9254\7f4607795
+Ref: 9255\7f4607795
+Ref: 9256\7f4607795
+Node: J.15.9\7f4608237
+Ref: 9257\7f4608794
+Ref: 9258\7f4608795
+Ref: 9259\7f4608800
+Ref: 9260\7f4608981
+Ref: 9261\7f4609852
+Node: J.15.10\7f4609873
+Ref: 9262\7f4610483
+Ref: 9263\7f4610484
+Ref: 9264\7f4610698
+Ref: 9265\7f4611289
+Node: J.15.11\7f4611325
+Ref: 9266\7f4611647
+Ref: 9267\7f4611648
+Ref: 9268\7f4611784
+Ref: 9269\7f4611785
+Ref: 9270\7f4611990
+Ref: 9271\7f4611990
+Node: J.15.12\7f4613836
+Ref: 9272\7f4614137
+Ref: 9273\7f4614138
+Ref: 9274\7f4614343
+Node: J.15.13\7f4615295
+Ref: 9275\7f4615600
+Ref: 9276\7f4615600
+Ref: 9277\7f4615620
+Ref: 9278\7f4615621
+Ref: 9279\7f4615635
+Node: Annex K\7f4616362
+Node: K.1\7f4616818
+Ref: 9280\7f4616991
+Node: K.2\7f4626268
+Ref: 9281\7f4626447
+Ref: 9282\7f4628061
+Ref: 9283\7f4628272
+Ref: 9284\7f4628274
+Ref: 9285\7f4632660
+Ref: 9286\7f4632675
+Ref: 9287\7f4634052
+Ref: 9288\7f4634422
+Ref: 9289\7f4634424
+Ref: 9290\7f4635229
+Ref: 9291\7f4635438
+Ref: 9292\7f4635440
+Ref: 9293\7f4638376
+Ref: 9294\7f4638391
+Ref: 9295\7f4638697
+Ref: 9296\7f4638697
+Ref: 9297\7f4648499
+Ref: 9298\7f4648514
+Ref: 9299\7f4648514
+Ref: 9300\7f4649698
+Ref: 9301\7f4649949
+Ref: 9302\7f4649950
+Ref: 9303\7f4653997
+Ref: 9304\7f4660006
+Ref: 9305\7f4663975
+Ref: 9306\7f4664140
+Ref: 9307\7f4664141
+Ref: 9308\7f4664642
+Ref: 9309\7f4664643
+Ref: 9310\7f4667346
+Ref: 9311\7f4667663
+Ref: 9312\7f4667665
+Ref: 9313\7f4670933
+Ref: 9314\7f4671527
+Ref: 9315\7f4671827
+Ref: 9316\7f4671829
+Ref: 9317\7f4675855
+Ref: 9318\7f4676020
+Ref: 9319\7f4676021
+Ref: 9320\7f4676507
+Ref: 9321\7f4676508
+Ref: 9322\7f4679313
+Ref: 9323\7f4679328
+Ref: 9324\7f4679737
+Ref: 9325\7f4680927
+Ref: 9326\7f4681797
+Node: Annex L\7f4684524
+Ref: 9327\7f4684674
+Ref: 9328\7f4684770
+Ref: 9329\7f4684771
+Ref: 9330\7f4684802
+Ref: 9331\7f4684845
+Ref: 9332\7f4684846
+Ref: 9333\7f4684872
+Ref: 9334\7f4684905
+Ref: 9335\7f4684956
+Ref: 9336\7f4684957
+Ref: 9337\7f4684981
+Ref: 9338\7f4685030
+Ref: 9339\7f4685031
+Ref: 9340\7f4685068
+Ref: 9341\7f4685090
+Ref: 9342\7f4685119
+Ref: 9343\7f4685141
+Ref: 9344\7f4685225
+Ref: 9345\7f4685226
+Ref: 9346\7f4685240
+Ref: 9347\7f4685324
+Ref: 9348\7f4685325
+Ref: 9349\7f4685333
+Ref: 9350\7f4685416
+Ref: 9351\7f4685417
+Ref: 9352\7f4685442
+Ref: 9353\7f4685525
+Ref: 9354\7f4685526
+Ref: 9355\7f4685550
+Ref: 9356\7f4685555
+Ref: 9357\7f4685673
+Ref: 9358\7f4685674
+Ref: 9359\7f4685712
+Ref: 9360\7f4685734
+Ref: 9361\7f4685784
+Ref: 9362\7f4685785
+Ref: 9363\7f4685790
+Ref: 9364\7f4685839
+Ref: 9365\7f4685840
+Ref: 9366\7f4685862
+Ref: 9367\7f4685924
+Ref: 9368\7f4685925
+Ref: 9369\7f4685971
+Ref: 9370\7f4685972
+Ref: 9371\7f4685995
+Ref: 9372\7f4686043
+Ref: 9373\7f4686044
+Ref: 9374\7f4686111
+Ref: 9375\7f4686112
+Ref: 9376\7f4686135
+Ref: 9377\7f4686155
+Ref: 9378\7f4686196
+Ref: 9379\7f4686197
+Ref: 9380\7f4686224
+Ref: 9381\7f4686244
+Ref: 9382\7f4686285
+Ref: 9383\7f4686286
+Ref: 9384\7f4686315
+Ref: 9385\7f4686395
+Ref: 9386\7f4686396
+Ref: 9387\7f4686436
+Ref: 9388\7f4686459
+Ref: 9389\7f4686516
+Ref: 9390\7f4686565
+Ref: 9391\7f4686651
+Ref: 9392\7f4686652
+Ref: 9393\7f4686692
+Ref: 9394\7f4686715
+Ref: 9395\7f4686772
+Ref: 9396\7f4686821
+Ref: 9397\7f4686872
+Ref: 9398\7f4686873
+Ref: 9399\7f4686896
+Ref: 9400\7f4686946
+Ref: 9401\7f4686947
+Ref: 9402\7f4686971
+Ref: 9403\7f4687056
+Ref: 9404\7f4687057
+Ref: 9405\7f4687065
+Ref: 9406\7f4687071
+Ref: 9407\7f4687113
+Ref: 9408\7f4687114
+Ref: 9409\7f4687139
+Ref: 9410\7f4687154
+Ref: 9411\7f4687234
+Ref: 9412\7f4687235
+Ref: 9413\7f4687262
+Ref: 9414\7f4687341
+Ref: 9415\7f4687342
+Ref: 9416\7f4687411
+Ref: 9417\7f4687412
+Ref: 9418\7f4687434
+Ref: 9419\7f4687477
+Ref: 9420\7f4687478
+Ref: 9421\7f4687483
+Ref: 9422\7f4687526
+Ref: 9423\7f4687527
+Ref: 9424\7f4687549
+Ref: 9425\7f4687633
+Ref: 9426\7f4687634
+Ref: 9427\7f4687655
+Ref: 9428\7f4687678
+Ref: 9429\7f4687725
+Ref: 9430\7f4687726
+Ref: 9431\7f4687775
+Ref: 9432\7f4687776
+Ref: 9433\7f4687785
+Ref: 9434\7f4687867
+Ref: 9435\7f4687868
+Ref: 9436\7f4687888
+Ref: 9437\7f4687934
+Ref: 9438\7f4687935
+Ref: 9439\7f4687975
+Ref: 9440\7f4687976
+Ref: 9441\7f4688013
+Ref: 9442\7f4688060
+Ref: 9443\7f4688061
+Ref: 9444\7f4688090
+Ref: 9445\7f4688137
+Ref: 9446\7f4688138
+Ref: 9447\7f4688165
+Ref: 9448\7f4688245
+Ref: 9449\7f4688246
+Ref: 9450\7f4688307
+Ref: 9451\7f4688308
+Ref: 9452\7f4688352
+Ref: 9453\7f4688379
+Ref: 9454\7f4688405
+Ref: 9455\7f4688455
+Ref: 9456\7f4688456
+Ref: 9457\7f4688473
+Ref: 9458\7f4688495
+Ref: 9459\7f4688596
+Ref: 9460\7f4688597
+Ref: 9461\7f4688616
+Ref: 9462\7f4688657
+Ref: 9463\7f4688658
+Ref: 9464\7f4688680
+Ref: 9465\7f4688764
+Ref: 9466\7f4688765
+Ref: 9467\7f4688849
+Ref: 9468\7f4688850
+Ref: 9469\7f4688886
+Ref: 9470\7f4688926
+Ref: 9471\7f4688927
+Ref: 9472\7f4688954
+Ref: 9473\7f4688994
+Ref: 9474\7f4688995
+Ref: 9475\7f4689008
+Ref: 9476\7f4689021
+Ref: 9477\7f4689069
+Ref: 9478\7f4689070
+Ref: 9479\7f4689114
+Ref: 9480\7f4689115
+Ref: 9481\7f4689144
+Ref: 9482\7f4689223
+Ref: 9483\7f4689224
+Ref: 9484\7f4689238
+Ref: 9485\7f4689284
+Ref: 9486\7f4689285
+Ref: 9487\7f4689294
+Ref: 9488\7f4689338
+Ref: 9489\7f4689339
+Ref: 9490\7f4689370
+Ref: 9491\7f4689456
+Ref: 9492\7f4689457
+Ref: 9493\7f4689488
+Ref: 9494\7f4689538
+Ref: 9495\7f4689539
+Ref: 9496\7f4689550
+Ref: 9497\7f4689633
+Ref: 9498\7f4689634
+Ref: 9499\7f4689644
+Ref: 9500\7f4689729
+Ref: 9501\7f4689730
+Ref: 9502\7f4689757
+Node: Annex M\7f4689971
+Ref: 9503\7f4690173
+Node: M.1\7f4690918
+Ref: 9504\7f4691064
+Ref: 9505\7f4691064
+Node: M.2\7f4698505
+Ref: 9506\7f4698669
+Ref: 9507\7f4698748
+Ref: 9508\7f4698860
+Ref: 9509\7f4698861
+Ref: 9510\7f4713077
+Node: M.3\7f4719609
+Ref: 9511\7f4719727
+Ref: 9512\7f4719727
+Node: Annex N\7f4750293
+Ref: 9513\7f4750441
+Ref: 9514\7f4750664
+Ref: 9515\7f4750818
+Ref: 9516\7f4750982
+Ref: 9517\7f4751299
+Ref: 9518\7f4751542
+Ref: 9519\7f4751677
+Ref: 9520\7f4751877
+Ref: 9521\7f4752161
+Ref: 9522\7f4752369
+Ref: 9523\7f4752464
+Ref: 9524\7f4752481
+Ref: 9525\7f4752746
+Ref: 9526\7f4753006
+Ref: 9527\7f4753064
+Ref: 9528\7f4753205
+Ref: 9529\7f4753435
+Ref: 9530\7f4753580
+Ref: 9531\7f4753682
+Ref: 9532\7f4753684
+Ref: 9533\7f4753946
+Ref: 9534\7f4754481
+Ref: 9535\7f4754648
+Ref: 9536\7f4754819
+Ref: 9537\7f4755086
+Ref: 9538\7f4755238
+Ref: 9539\7f4755305
+Ref: 9540\7f4755453
+Ref: 9541\7f4755602
+Ref: 9542\7f4755753
+Ref: 9543\7f4755896
+Ref: 9544\7f4756003
+Ref: 9545\7f4756097
+Ref: 9546\7f4756099
+Ref: 9547\7f4756217
+Ref: 9548\7f4756333
+Ref: 9549\7f4756976
+Ref: 9550\7f4757229
+Ref: 9551\7f4757396
+Ref: 9552\7f4757859
+Ref: 9553\7f4758201
+Ref: 9554\7f4758364
+Ref: 9555\7f4758533
+Ref: 9556\7f4758748
+Ref: 9557\7f4759010
+Ref: 9558\7f4759113
+Ref: 9559\7f4759287
+Ref: 9560\7f4759535
+Ref: 9561\7f4759711
+Ref: 9562\7f4760100
+Ref: 9563\7f4760278
+Ref: 9564\7f4760610
+Ref: 9565\7f4760732
+Ref: 9566\7f4760957
+Ref: 9567\7f4761074
+Ref: 9568\7f4761182
+Ref: 9569\7f4761799
+Ref: 9570\7f4761938
+Ref: 9571\7f4762217
+Ref: 9572\7f4762342
+Ref: 9573\7f4762586
+Ref: 9574\7f4762771
+Ref: 9575\7f4763104
+Ref: 9576\7f4763294
+Ref: 9577\7f4763432
+Ref: 9578\7f4763543
+Ref: 9579\7f4763673
+Ref: 9580\7f4763809
+Ref: 9581\7f4763949
+Ref: 9582\7f4764027
+Ref: 9583\7f4764332
+Ref: 9584\7f4764511
+Ref: 9585\7f4764826
+Ref: 9586\7f4765071
+Ref: 9587\7f4765319
+Ref: 9588\7f4765768
+Ref: 9589\7f4765997
+Ref: 9590\7f4766273
+Node: Annex P\7f4766396
+Ref: 9591\7f4766524
+Ref: 9592\7f4766524
+Ref: 9593\7f4766524
+Ref: 9594\7f4766524
+Ref: 9595\7f4766524
+Ref: 9596\7f4766690
+Ref: 9597\7f4766708
+Ref: 9598\7f4766727
+Ref: 9599\7f4766802
+Ref: 9600\7f4766829
+Ref: 9601\7f4766856
+Ref: 9602\7f4766883
+Ref: 9603\7f4766909
+Ref: 9604\7f4766932
+Ref: 9605\7f4767003
+Ref: 9606\7f4767030
+Ref: 9607\7f4767063
+Ref: 9608\7f4767088
+Ref: 9609\7f4767154
+Ref: 9610\7f4767172
+Ref: 9611\7f4767232
+Ref: 9612\7f4767242
+Ref: 9613\7f4767252
+Ref: 9614\7f4767300
+Ref: 9615\7f4767308
+Ref: 9616\7f4767319
+Ref: 9617\7f4767371
+Ref: 9618\7f4767385
+Ref: 9619\7f4767520
+Ref: 9620\7f4767527
+Ref: 9621\7f4767543
+Ref: 9622\7f4767561
+Ref: 9623\7f4767606
+Ref: 9624\7f4767667
+Ref: 9625\7f4767684
+Ref: 9626\7f4767695
+Ref: 9627\7f4767756
+Ref: 9628\7f4767833
+Ref: 9629\7f4767897
+Ref: 9630\7f4767981
+Ref: 9631\7f4768054
+Ref: 9632\7f4768116
+Ref: 9633\7f4768129
+Ref: 9634\7f4768160
+Ref: 9635\7f4768282
+Ref: 9636\7f4768297
+Ref: 9637\7f4768329
+Ref: 9638\7f4768344
+Ref: 9639\7f4768381
+Ref: 9640\7f4768397
+Ref: 9641\7f4768428
+Ref: 9642\7f4768444
+Ref: 9643\7f4768512
+Ref: 9644\7f4768533
+Ref: 9645\7f4768563
+Ref: 9646\7f4768586
+Ref: 9647\7f4768615
+Ref: 9648\7f4768642
+Ref: 9649\7f4768684
+Ref: 9650\7f4768715
+Ref: 9651\7f4768757
+Ref: 9652\7f4768781
+Ref: 9653\7f4768812
+Ref: 9654\7f4768838
+Ref: 9655\7f4768868
+Ref: 9656\7f4768938
+Ref: 9657\7f4768997
+Ref: 9658\7f4769029
+Ref: 9659\7f4769067
+Ref: 9660\7f4769102
+Ref: 9661\7f4769200
+Ref: 9662\7f4769221
+Ref: 9663\7f4769249
+Ref: 9664\7f4769285
+Ref: 9665\7f4769318
+Ref: 9666\7f4769350
+Ref: 9667\7f4769434
+Ref: 9668\7f4769466
+Ref: 9669\7f4769500
+Ref: 9670\7f4769525
+Ref: 9671\7f4769557
+Ref: 9672\7f4769584
+Ref: 9673\7f4769617
+Ref: 9674\7f4769645
+Ref: 9675\7f4769738
+Ref: 9676\7f4769761
+Ref: 9677\7f4769794
+Ref: 9678\7f4769868
+Ref: 9679\7f4769884
+Ref: 9680\7f4769898
+Ref: 9681\7f4769961
+Ref: 9682\7f4770007
+Ref: 9683\7f4770027
+Ref: 9684\7f4770107
+Ref: 9685\7f4770126
+Ref: 9686\7f4770146
+Ref: 9687\7f4770225
+Ref: 9688\7f4770244
+Ref: 9689\7f4770327
+Ref: 9690\7f4770375
+Ref: 9691\7f4770404
+Ref: 9692\7f4770430
+Ref: 9693\7f4770462
+Ref: 9694\7f4770510
+Ref: 9695\7f4770538
+Ref: 9696\7f4770564
+Ref: 9697\7f4770596
+Ref: 9698\7f4770644
+Ref: 9699\7f4770676
+Ref: 9700\7f4770702
+Ref: 9701\7f4770734
+Ref: 9702\7f4770767
+Ref: 9703\7f4770859
+Ref: 9704\7f4770882
+Ref: 9705\7f4770963
+Ref: 9706\7f4771009
+Ref: 9707\7f4771115
+Ref: 9708\7f4771140
+Ref: 9709\7f4771162
+Ref: 9710\7f4771237
+Ref: 9711\7f4771278
+Ref: 9712\7f4771314
+Ref: 9713\7f4771335
+Ref: 9714\7f4771421
+Ref: 9715\7f4771458
+Ref: 9716\7f4771565
+Ref: 9717\7f4771587
+Ref: 9718\7f4771677
+Ref: 9719\7f4771749
+Ref: 9720\7f4771782
+Ref: 9721\7f4771886
+Ref: 9722\7f4771920
+Ref: 9723\7f4772003
+Ref: 9724\7f4772074
+Ref: 9725\7f4772102
+Ref: 9726\7f4772203
+Ref: 9727\7f4772215
+Ref: 9728\7f4772317
+Ref: 9729\7f4772345
+Ref: 9730\7f4772416
+Ref: 9731\7f4772450
+Ref: 9732\7f4772571
+Ref: 9733\7f4772583
+Ref: 9734\7f4772691
+Ref: 9735\7f4772716
+Ref: 9736\7f4772728
+Ref: 9737\7f4772831
+Ref: 9738\7f4772843
+Ref: 9739\7f4772920
+Ref: 9740\7f4772953
+Ref: 9741\7f4773056
+Ref: 9742\7f4773084
+Ref: 9743\7f4773114
+Ref: 9744\7f4773194
+Ref: 9745\7f4773289
+Ref: 9746\7f4773320
+Ref: 9747\7f4773359
+Ref: 9748\7f4773445
+Ref: 9749\7f4773466
+Ref: 9750\7f4773540
+Ref: 9751\7f4773577
+Ref: 9752\7f4773644
+Ref: 9753\7f4773662
+Ref: 9754\7f4773733
+Ref: 9755\7f4773754
+Ref: 9756\7f4773806
+Ref: 9757\7f4773834
+Ref: 9758\7f4773985
+Ref: 9759\7f4774015
+Ref: 9760\7f4774108
+Ref: 9761\7f4774136
+Ref: 9762\7f4774152
+Ref: 9763\7f4774169
+Ref: 9764\7f4774203
+Ref: 9765\7f4774230
+Ref: 9766\7f4774252
+Ref: 9767\7f4774325
+Ref: 9768\7f4774400
+Ref: 9769\7f4774428
+Ref: 9770\7f4774533
+Ref: 9771\7f4774563
+Ref: 9772\7f4774582
+Ref: 9773\7f4774680
+Ref: 9774\7f4774779
+Ref: 9775\7f4774890
+Ref: 9776\7f4774906
+Ref: 9777\7f4774933
+Ref: 9778\7f4774949
+Ref: 9779\7f4775022
+Ref: 9780\7f4775046
+Ref: 9781\7f4775119
+Ref: 9782\7f4775146
+Ref: 9783\7f4775171
+Ref: 9784\7f4775211
+Ref: 9785\7f4775304
+Ref: 9786\7f4775331
+Ref: 9787\7f4775351
+Ref: 9788\7f4775430
+Ref: 9789\7f4775465
+Ref: 9790\7f4775531
+Ref: 9791\7f4775550
+Ref: 9792\7f4775613
+Ref: 9793\7f4775642
+Ref: 9794\7f4775669
+Ref: 9795\7f4775741
+Ref: 9796\7f4775832
+Ref: 9797\7f4775863
+Ref: 9798\7f4775914
+Ref: 9799\7f4776062
+Ref: 9800\7f4776139
+Ref: 9801\7f4776167
+Ref: 9802\7f4776250
+Ref: 9803\7f4776266
+Ref: 9804\7f4776304
+Ref: 9805\7f4776320
+Ref: 9806\7f4776427
+Ref: 9807\7f4776452
+Ref: 9808\7f4776639
+Ref: 9809\7f4776695
+Ref: 9810\7f4776835
+Ref: 9811\7f4776869
+Ref: 9812\7f4776892
+Ref: 9813\7f4776937
+Ref: 9814\7f4776965
+Ref: 9815\7f4777009
+Ref: 9816\7f4777108
+Ref: 9817\7f4777129
+Ref: 9818\7f4777214
+Ref: 9819\7f4777288
+Ref: 9820\7f4777313
+Ref: 9821\7f4777380
+Ref: 9822\7f4777400
+Ref: 9823\7f4777416
+Ref: 9824\7f4777461
+Ref: 9825\7f4777475
+Ref: 9826\7f4777536
+Ref: 9827\7f4777554
+Ref: 9828\7f4777569
+Ref: 9829\7f4777581
+Ref: 9830\7f4777640
+Ref: 9831\7f4777656
+Ref: 9832\7f4777687
+Ref: 9833\7f4777709
+Ref: 9834\7f4777725
+Ref: 9835\7f4777748
+Ref: 9836\7f4777778
+Ref: 9837\7f4777798
+Ref: 9838\7f4777822
+Ref: 9839\7f4777844
+Ref: 9840\7f4777875
+Ref: 9841\7f4777901
+Ref: 9842\7f4777962
+Ref: 9843\7f4777975
+Ref: 9844\7f4778026
+Ref: 9845\7f4778033
+Ref: 9846\7f4778103
+Ref: 9847\7f4778161
+Ref: 9848\7f4778214
+Ref: 9849\7f4778221
+Ref: 9850\7f4778235
+Ref: 9851\7f4778284
+Ref: 9852\7f4778291
+Ref: 9853\7f4778356
+Ref: 9854\7f4778365
+Ref: 9855\7f4778423
+Ref: 9856\7f4778436
+Ref: 9857\7f4778456
+Ref: 9858\7f4778522
+Ref: 9859\7f4778529
+Ref: 9860\7f4778611
+Ref: 9861\7f4778630
+Ref: 9862\7f4778738
+Ref: 9863\7f4778745
+Ref: 9864\7f4778843
+Ref: 9865\7f4778925
+Ref: 9866\7f4779008
+Ref: 9867\7f4779015
+Ref: 9868\7f4779081
+Ref: 9869\7f4779100
+Ref: 9870\7f4779122
+Ref: 9871\7f4779192
+Ref: 9872\7f4779301
+Ref: 9873\7f4779333
+Ref: 9874\7f4779454
+Ref: 9875\7f4779480
+Ref: 9876\7f4779501
+Ref: 9877\7f4779602
+Ref: 9878\7f4779629
+Ref: 9879\7f4779722
+Ref: 9880\7f4779741
+Ref: 9881\7f4779820
+Ref: 9882\7f4779833
+Ref: 9883\7f4779900
+Ref: 9884\7f4779929
+Ref: 9885\7f4780019
+Ref: 9886\7f4780031
+Ref: 9887\7f4780045
+Ref: 9888\7f4780068
+Ref: 9889\7f4780082
+Ref: 9890\7f4780105
+Ref: 9891\7f4780127
+Ref: 9892\7f4780141
+Ref: 9893\7f4780231
+Ref: 9894\7f4780262
+Ref: 9895\7f4780360
+Ref: 9896\7f4780384
+Ref: 9897\7f4780404
+Ref: 9898\7f4780481
+Ref: 9899\7f4780495
+Ref: 9900\7f4780510
+Ref: 9901\7f4780529
+Ref: 9902\7f4780549
+Ref: 9903\7f4780562
+Ref: 9904\7f4780577
+Ref: 9905\7f4780595
+Ref: 9906\7f4780615
+Ref: 9907\7f4780629
+Ref: 9908\7f4780696
+Ref: 9909\7f4780717
+Ref: 9910\7f4780744
+Ref: 9911\7f4780764
+Ref: 9912\7f4780791
+Ref: 9913\7f4780812
+Ref: 9914\7f4780839
+Ref: 9915\7f4780865
+Ref: 9916\7f4780892
+Ref: 9917\7f4780917
+Ref: 9918\7f4780989
+Ref: 9919\7f4781008
+Ref: 9920\7f4781028
+Ref: 9921\7f4781095
+Ref: 9922\7f4781114
+Ref: 9923\7f4781134
+Ref: 9924\7f4781163
+Ref: 9925\7f4781190
+Ref: 9926\7f4781264
+Ref: 9927\7f4781285
+Ref: 9928\7f4781350
+Ref: 9929\7f4781370
+Ref: 9930\7f4781378
+Ref: 9931\7f4781438
+Ref: 9932\7f4781461
+Ref: 9933\7f4781467
+Ref: 9934\7f4781496
+Ref: 9935\7f4781535
+Ref: 9936\7f4781543
+Ref: 9937\7f4781564
+Ref: 9938\7f4781607
+Ref: 9939\7f4781619
+Ref: 9940\7f4781634
+Ref: 9941\7f4781648
+Ref: 9942\7f4781701
+Ref: 9943\7f4781726
+Ref: 9944\7f4781743
+Ref: 9945\7f4781761
+Ref: 9946\7f4781768
+Ref: 9947\7f4781781
+Ref: 9948\7f4781802
+Ref: 9949\7f4781829
+Ref: 9950\7f4782334
+Ref: 9951\7f4782350
+Ref: 9952\7f4782422
+Ref: 9953\7f4782447
+Ref: 9954\7f4782473
+Ref: 9955\7f4782498
+Ref: 9956\7f4782534
+Ref: 9957\7f4782594
+Ref: 9958\7f4782676
+Ref: 9959\7f4782699
+Ref: 9960\7f4782739
+Ref: 9961\7f4782841
+Ref: 9962\7f4782888
+Ref: 9963\7f4782955
+Ref: 9964\7f4782966
+Ref: 9965\7f4783004
+Ref: 9966\7f4783027
+Ref: 9967\7f4783038
+Ref: 9968\7f4783064
+Ref: 9969\7f4783174
+Ref: 9970\7f4783239
+Ref: 9971\7f4783252
+Ref: 9972\7f4783273
+Ref: 9973\7f4783286
+Ref: 9974\7f4783350
+Ref: 9975\7f4783364
+Ref: 9976\7f4783378
+Ref: 9977\7f4783391
+Ref: 9978\7f4783453
+Ref: 9979\7f4783476
+Ref: 9980\7f4783508
+Ref: 9981\7f4783531
+Ref: 9982\7f4783618
+Ref: 9983\7f4783675
+Ref: 9984\7f4783686
+Ref: 9985\7f4783698
+Ref: 9986\7f4783753
+Ref: 9987\7f4783760
+Ref: 9988\7f4783780
+Ref: 9989\7f4783787
+Ref: 9990\7f4783851
+Ref: 9991\7f4783876
+Ref: 9992\7f4783901
+Ref: 9993\7f4783926
+Ref: 9994\7f4783945
+Ref: 9995\7f4783980
+Ref: 9996\7f4784008
+Ref: 9997\7f4784039
+Ref: 9998\7f4784061
+Ref: 9999\7f4784087
+Ref: 10000\7f4784107
+Ref: 10001\7f4784133
+Ref: 10002\7f4784206
+Ref: 10003\7f4784223
+Ref: 10004\7f4784248
+Ref: 10005\7f4784267
+Ref: 10006\7f4784293
+Ref: 10007\7f4784329
+Ref: 10008\7f4784350
+Ref: 10009\7f4784458
+Ref: 10010\7f4784530
+Ref: 10011\7f4784609
+Ref: 10012\7f4784617
+Ref: 10013\7f4784683
+Ref: 10014\7f4784709
+Ref: 10015\7f4784747
+Ref: 10016\7f4784773
+Ref: 10017\7f4784822
+Ref: 10018\7f4784930
+Ref: 10019\7f4784956
+Ref: 10020\7f4784995
+Ref: 10021\7f4785110
+Ref: 10022\7f4785145
+Ref: 10023\7f4785226
+Ref: 10024\7f4785261
+Ref: 10025\7f4785298
+Ref: 10026\7f4785348
+Ref: 10027\7f4785412
+Ref: 10028\7f4785436
+Ref: 10029\7f4785479
+Ref: 10030\7f4785568
+Ref: 10031\7f4785601
+Ref: 10032\7f4785692
+Ref: 10033\7f4785734
+Ref: 10034\7f4785748
+Ref: 10035\7f4785771
+Ref: 10036\7f4785819
+Ref: 10037\7f4785884
+Ref: 10038\7f4785945
+Ref: 10039\7f4785999
+Ref: 10040\7f4786054
+Ref: 10041\7f4786130
+Ref: 10042\7f4786142
+Ref: 10043\7f4786208
+Ref: 10044\7f4786276
+Ref: 10045\7f4786307
+Ref: 10046\7f4786346
+Ref: 10047\7f4786432
+Ref: 10048\7f4786465
+Ref: 10049\7f4786550
+Ref: 10050\7f4786577
+Ref: 10051\7f4786661
+Ref: 10052\7f4786681
+Ref: 10053\7f4786756
+Ref: 10054\7f4786776
+Ref: 10055\7f4786789
+Ref: 10056\7f4786853
+Ref: 10057\7f4786882
+Ref: 10058\7f4786969
+Ref: 10059\7f4786989
+Ref: 10060\7f4787059
+Ref: 10061\7f4787127
+Ref: 10062\7f4787190
+Ref: 10063\7f4787271
+Ref: 10064\7f4787292
+Ref: 10065\7f4787308
+Ref: 10066\7f4787331
+Ref: 10067\7f4787351
+Ref: 10068\7f4787419
+Ref: 10069\7f4787446
+Ref: 10070\7f4787534
+Ref: 10071\7f4787571
+Ref: 10072\7f4787577
+Ref: 10073\7f4787593
+Ref: 10074\7f4787616
+Ref: 10075\7f4787645
+Ref: 10076\7f4787672
+Ref: 10077\7f4787694
+Ref: 10078\7f4787828
+Ref: 10079\7f4787859
+Ref: 10080\7f4787897
+Ref: 10081\7f4787934
+Ref: 10082\7f4787979
+Ref: 10083\7f4788024
+Ref: 10084\7f4788110
+Ref: 10085\7f4788135
+Ref: 10086\7f4788142
+Ref: 10087\7f4788226
+Ref: 10088\7f4788249
+Ref: 10089\7f4788256
+Ref: 10090\7f4788339
+Ref: 10091\7f4788364
+Ref: 10092\7f4788465
+Ref: 10093\7f4788483
+Ref: 10094\7f4788563
+Ref: 10095\7f4788585
+Ref: 10096\7f4788650
+Ref: 10097\7f4788736
+Ref: 10098\7f4788778
+Ref: 10099\7f4788814
+Ref: 10100\7f4788897
+Ref: 10101\7f4788949
+Ref: 10102\7f4789056
+Ref: 10103\7f4789077
+Ref: 10104\7f4789166
+Ref: 10105\7f4789196
+Ref: 10106\7f4789241
+Ref: 10107\7f4789334
+Ref: 10108\7f4789364
+Ref: 10109\7f4789403
+Ref: 10110\7f4789428
+Ref: 10111\7f4789499
+Ref: 10112\7f4789590
+Ref: 10113\7f4789631
+Ref: 10114\7f4789668
+Ref: 10115\7f4789721
+Ref: 10116\7f4789761
+Ref: 10117\7f4789779
+Ref: 10118\7f4789855
+Ref: 10119\7f4789896
+Ref: 10120\7f4789933
+Ref: 10121\7f4789978
+Ref: 10122\7f4790025
+Ref: 10123\7f4790043
+Ref: 10124\7f4790123
+Ref: 10125\7f4790144
+Ref: 10126\7f4790222
+Ref: 10127\7f4790317
+Ref: 10128\7f4790338
+Ref: 10129\7f4790419
+Ref: 10130\7f4790459
+Ref: 10131\7f4790501
+Ref: 10132\7f4790631
+Ref: 10133\7f4790652
+Ref: 10134\7f4790727
+Ref: 10135\7f4790743
+Ref: 10136\7f4790809
+Ref: 10137\7f4790825
+Ref: 10138\7f4790901
+Ref: 10139\7f4790940
+Ref: 10140\7f4790982
+Ref: 10141\7f4791022
+Ref: 10142\7f4791065
+Ref: 10143\7f4791162
+Ref: 10144\7f4791185
+Ref: 10145\7f4791201
+Ref: 10146\7f4791235
+Ref: 10147\7f4791254
+Ref: 10148\7f4791286
+Ref: 10149\7f4791308
+Ref: 10150\7f4791341
+Ref: 10151\7f4791360
+Ref: 10152\7f4791444
+Ref: 10153\7f4791500
+Ref: 10154\7f4791514
+Ref: 10155\7f4791604
+Ref: 10156\7f4791653
+Ref: 10157\7f4791667
+Ref: 10158\7f4791763
+Ref: 10159\7f4791794
+Ref: 10160\7f4791843
+Ref: 10161\7f4791862
+Ref: 10162\7f4791972
+Ref: 10163\7f4792029
+Ref: 10164\7f4792048
+Ref: 10165\7f4792100
+Ref: 10166\7f4792159
+Ref: 10167\7f4792178
+Ref: 10168\7f4792229
+Ref: 10169\7f4792287
+Ref: 10170\7f4792306
+Ref: 10171\7f4792398
+Ref: 10172\7f4792419
+Ref: 10173\7f4792458
+Ref: 10174\7f4792499
+Ref: 10175\7f4792530
+Ref: 10176\7f4792614
+Ref: 10177\7f4792649
+Ref: 10178\7f4792689
+Ref: 10179\7f4792720
+Ref: 10180\7f4792794
+Ref: 10181\7f4792833
+Ref: 10182\7f4792862
+Ref: 10183\7f4792912
+Ref: 10184\7f4792932
+Ref: 10185\7f4793003
+Ref: 10186\7f4793037
+Ref: 10187\7f4793072
+Ref: 10188\7f4793113
+Ref: 10189\7f4793162
+Ref: 10190\7f4793253
+Ref: 10191\7f4793274
+Ref: 10192\7f4793313
+Ref: 10193\7f4793353
+Ref: 10194\7f4793384
+Ref: 10195\7f4793481
+Ref: 10196\7f4793515
+Ref: 10197\7f4793555
+Ref: 10198\7f4793586
+Ref: 10199\7f4793669
+Ref: 10200\7f4793729
+Ref: 10201\7f4793785
+Ref: 10202\7f4793857
+Ref: 10203\7f4793892
+Ref: 10204\7f4793922
+Ref: 10205\7f4793994
+Ref: 10206\7f4794038
+Ref: 10207\7f4794126
+Ref: 10208\7f4794160
+Ref: 10209\7f4794195
+Ref: 10210\7f4794244
+Ref: 10211\7f4794310
+Ref: 10212\7f4794345
+Ref: 10213\7f4794373
+Ref: 10214\7f4794396
+Ref: 10215\7f4794562
+Ref: 10216\7f4794598
+Ref: 10217\7f4794620
+Ref: 10218\7f4794650
+Ref: 10219\7f4794686
+Ref: 10220\7f4794778
+Ref: 10221\7f4794792
+Ref: 10222\7f4794806
+Ref: 10223\7f4794838
+Ref: 10224\7f4794888
+Ref: 10225\7f4794944
+Ref: 10226\7f4795010
+Ref: 10227\7f4795031
+Ref: 10228\7f4795055
+Ref: 10229\7f4795087
+Ref: 10230\7f4795126
+Ref: 10231\7f4795175
+Ref: 10232\7f4795243
+Ref: 10233\7f4795271
+Ref: 10234\7f4795344
+Ref: 10235\7f4795414
+Ref: 10236\7f4795437
+Ref: 10237\7f4795528
+Ref: 10238\7f4795534
+Ref: 10239\7f4795633
+Ref: 10240\7f4795696
+Ref: 10241\7f4795720
+Ref: 10242\7f4795819
+Ref: 10243\7f4795896
+Ref: 10244\7f4795962
+Ref: 10245\7f4795988
+Ref: 10246\7f4796014
+Ref: 10247\7f4796046
+Ref: 10248\7f4796137
+Ref: 10249\7f4796154
+Ref: 10250\7f4796192
+Ref: 10251\7f4796209
+Ref: 10252\7f4796250
+Ref: 10253\7f4796335
+Ref: 10254\7f4796406
+Ref: 10255\7f4796434
+Ref: 10256\7f4796461
+Ref: 10257\7f4796540
+Ref: 10258\7f4796558
+Ref: 10259\7f4796638
+Ref: 10260\7f4796655
+Ref: 10261\7f4796812
+Ref: 10262\7f4796853
+Ref: 10263\7f4796951
+Ref: 10264\7f4796976
+Ref: 10265\7f4797062
+Ref: 10266\7f4797089
+Ref: 10267\7f4797186
+Ref: 10268\7f4797229
+Ref: 10269\7f4797344
+Ref: 10270\7f4797393
+Ref: 10271\7f4797480
+Ref: 10272\7f4797502
+Ref: 10273\7f4797583
+Ref: 10274\7f4797609
+Ref: 10275\7f4797670
+Ref: 10276\7f4797748
+Ref: 10277\7f4797761
+Ref: 10278\7f4797812
+Ref: 10279\7f4797888
+Ref: 10280\7f4797903
+Ref: 10281\7f4797925
+Ref: 10282\7f4797940
+Ref: 10283\7f4798002
+Ref: 10284\7f4798036
+Ref: 10285\7f4798073
+Ref: 10286\7f4798174
+Ref: 10287\7f4798201
+Ref: 10288\7f4798231
+Ref: 10289\7f4798255
+Ref: 10290\7f4798351
+Ref: 10291\7f4798388
+Ref: 10292\7f4798425
+Ref: 10293\7f4798506
+Ref: 10294\7f4798524
+Ref: 10295\7f4798585
+Ref: 10296\7f4798637
+Ref: 10297\7f4798695
+Ref: 10298\7f4798709
+Ref: 10299\7f4798763
+Ref: 10300\7f4798785
+Ref: 10301\7f4798895
+Ref: 10302\7f4798922
+Ref: 10303\7f4799011
+Ref: 10304\7f4799038
+Ref: 10305\7f4799086
+Ref: 10306\7f4799109
+Ref: 10307\7f4799129
+Ref: 10308\7f4799152
+Ref: 10309\7f4799234
+Ref: 10310\7f4799264
+Ref: 10311\7f4799313
+Ref: 10312\7f4799407
+Ref: 10313\7f4799451
+Ref: 10314\7f4799539
+Ref: 10315\7f4799583
+Ref: 10316\7f4799681
+Ref: 10317\7f4799725
+Ref: 10318\7f4799797
+Ref: 10319\7f4799815
+Ref: 10320\7f4799878
+Ref: 10321\7f4799924
+Ref: 10322\7f4800018
+Ref: 10323\7f4800069
+Ref: 10324\7f4800097
+Ref: 10325\7f4800178
+Ref: 10326\7f4800211
+Ref: 10327\7f4800231
+Ref: 10328\7f4800268
+Ref: 10329\7f4800351
+Ref: 10330\7f4800427
+Ref: 10331\7f4800522
+Ref: 10332\7f4800540
+Ref: 10333\7f4800602
+Ref: 10334\7f4800635
+Ref: 10335\7f4800740
+Ref: 10336\7f4800761
+Ref: 10337\7f4800800
+Ref: 10338\7f4800891
+Ref: 10339\7f4800912
+Ref: 10340\7f4800993
+Ref: 10341\7f4801038
+Ref: 10342\7f4801128
+Ref: 10343\7f4801165
+Ref: 10344\7f4801200
+Ref: 10345\7f4801241
+Ref: 10346\7f4801338
+Ref: 10347\7f4801402
+Ref: 10348\7f4801408
+Ref: 10349\7f4801447
+Ref: 10350\7f4801481
+Ref: 10351\7f4801523
+Ref: 10352\7f4801589
+Ref: 10353\7f4801595
+Ref: 10354\7f4801634
+Ref: 10355\7f4801668
+Ref: 10356\7f4801709
+Ref: 10357\7f4801767
+Ref: 10358\7f4801773
+Ref: 10359\7f4801812
+Ref: 10360\7f4801894
+Ref: 10361\7f4801917
+Ref: 10362\7f4802023
+Ref: 10363\7f4802041
+Ref: 10364\7f4802144
+Ref: 10365\7f4802166
+Ref: 10366\7f4802192
+Ref: 10367\7f4802205
+Ref: 10368\7f4802212
+Ref: 10369\7f4802252
+Ref: 10370\7f4802322
+Ref: 10371\7f4802349
+Ref: 10372\7f4802355
+Ref: 10373\7f4802371
+Ref: 10374\7f4802394
+Ref: 10375\7f4802428
+Ref: 10376\7f4802461
+Ref: 10377\7f4802488
+Ref: 10378\7f4802493
+Ref: 10379\7f4802515
+Ref: 10380\7f4802555
+Ref: 10381\7f4802643
+Ref: 10382\7f4802687
+Ref: 10383\7f4802799
+Ref: 10384\7f4802819
+Ref: 10385\7f4802841
+Ref: 10386\7f4802884
+Ref: 10387\7f4802986
+Ref: 10388\7f4803006
+Ref: 10389\7f4803102
+Ref: 10390\7f4803144
+Ref: 10391\7f4803186
+Ref: 10392\7f4803229
+Ref: 10393\7f4803278
+Ref: 10394\7f4803320
+Ref: 10395\7f4803364
+Ref: 10396\7f4803414
+Ref: 10397\7f4803463
+Ref: 10398\7f4803503
+Ref: 10399\7f4803544
+Ref: 10400\7f4803790
+Ref: 10401\7f4803809
+Ref: 10402\7f4804360
+Ref: 10403\7f4804443
+Ref: 10404\7f4804530
+Ref: 10405\7f4804615
+Ref: 10406\7f4804671
+Ref: 10407\7f4804794
+Ref: 10408\7f4804823
+Ref: 10409\7f4804857
+Ref: 10410\7f4804964
+Ref: 10411\7f4805002
+Ref: 10412\7f4805036
+Ref: 10413\7f4805107
+Ref: 10414\7f4805174
+Ref: 10415\7f4805258
+Ref: 10416\7f4805301
+Ref: 10417\7f4805307
+Ref: 10418\7f4805354
+Ref: 10419\7f4805470
+Ref: 10420\7f4805501
+Ref: 10421\7f4805531
+Ref: 10422\7f4805649
+Ref: 10423\7f4805703
+Ref: 10424\7f4805766
+Ref: 10425\7f4805807
+Ref: 10426\7f4805854
+Ref: 10427\7f4805896
+Ref: 10428\7f4805946
+Ref: 10429\7f4805971
+Ref: 10430\7f4805983
+Ref: 10431\7f4806030
+Ref: 10432\7f4806101
+Ref: 10433\7f4806117
+Ref: 10434\7f4806155
+Ref: 10435\7f4806171
+Ref: 10436\7f4806242
+Ref: 10437\7f4806310
+Ref: 10438\7f4806317
+Ref: 10439\7f4806330
+Ref: 10440\7f4806414
+Ref: 10441\7f4806425
+Ref: 10442\7f4806450
+Ref: 10443\7f4806477
+Ref: 10444\7f4806488
+Ref: 10445\7f4806513
+Ref: 10446\7f4806610
+Ref: 10447\7f4806625
+Ref: 10448\7f4806699
+Ref: 10449\7f4806803
+Ref: 10450\7f4806837
+Ref: 10451\7f4806863
+Ref: 10452\7f4806972
+Ref: 10453\7f4806986
+Ref: 10454\7f4807001
+Ref: 10455\7f4807014
+Ref: 10456\7f4807071
+Ref: 10457\7f4807130
+Ref: 10458\7f4807195
+Ref: 10459\7f4807257
+Ref: 10460\7f4807347
+Ref: 10461\7f4807413
+Ref: 10462\7f4807457
+Ref: 10463\7f4807471
+Ref: 10464\7f4807569
+Ref: 10465\7f4807576
+Ref: 10466\7f4807645
+Ref: 10467\7f4807657
+Ref: 10468\7f4807717
+Ref: 10469\7f4807736
+Ref: 10470\7f4807801
+Ref: 10471\7f4807838
+Ref: 10472\7f4807838
+Ref: 10473\7f4807838
+Ref: 10474\7f4807838
+Ref: 10475\7f4807838
+Node: Annex Q\7f4853110
+Node: Q.1\7f4853706
+Ref: 10476\7f4853937
+Node: Q.2\7f4865286
+Ref: 10477\7f4865559
+Ref: 10478\7f4865559
+Node: Q.3\7f4881397
+Ref: 10479\7f4881649
+Node: Q.4\7f4948507
+Ref: 10480\7f4948756
+Node: Q.5\7f4952409
+Ref: 10481\7f4952691
+Ref: 10482\7f4952691
+Ref: 10483\7f4952691
+Node: Index\7f4976590
+Node: operators\7f4976885
+Node: A\7f4978334
+Node: B\7f5016672
+Node: C\7f5024631
+Node: D\7f5059752
+Node: E\7f5081170
+Node: F\7f5122858
+Node: G\7f5136219
+Node: H\7f5143952
+Node: I\7f5148220
+Node: J\7f5179755
+Node: K\7f5179946
+Node: L\7f5180725
+Node: M\7f5196235
+Node: N\7f5205752
+Node: O\7f5220146
+Node: P\7f5227509
+Node: Q\7f5254501
+Node: R\7f5256304
+Node: S\7f5278070
+Node: T\7f5307831
+Node: U\7f5326014
+Node: V\7f5337217
+Node: W\7f5341300
+Node: X\7f5347563
+Node: Y\7f5347698
+\1f
+End Tag Table