International Standard ISO/IEC 8652:1995

Information technology -- Programming languages -- Ada
AMENDMENT 1 (Draft 11)

Technologies de l'information -- Langages de programmation -- Ada
AMENDEMENT 1

Amendment 1 to International Standard ISO/IEC 8652:1995 was prepared by AXE Consultants.

© 2005, 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. 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 the source code and documentation. Any other use or distribution of this document is prohibited without the prior express permission of AXE.

Introduction

International Standard ISO/IEC 8652:1995 defines the Ada programming language.

This amendment modifies Ada by making changes and additions that improve:

• The safety of applications written in Ada;
• The portability of applications written in Ada;
• Interoperability with other languages and systems; and
• Accessibility and ease of transition from idioms in other programming and modeling languages.

This amendment incorporates the following major additions to the International Standard:

• The Ravenscar profile to provide a simplified tasking system for high-integrity systems (see clause D.13);
• A non-preemptive task dispatching policy (see clause D.2.4);
• Aggregates, constructor functions, and constants for limited types (see clauses 4.3.1, 6.5, and 7.5);
• Control of overriding to eliminate errors (see clause 8.3);
• Improvements for access types, such as null excluding subtypes (see clause 3.10), additional uses for anonymous access types (see clauses 3.6 and 8.5.1), and anonymous access-to-subprogram subtypes to support 'downward closures' (see clauses 3.10 and 3.10.2);
• Additional context clause capabilities: limited views to allow mutually dependent types (see clauses 3.10.1 and 10.1.2) and private context clauses that apply only in the private part of a package (see clause 10.1.2);
• Added standard packages, including time management (see 9.6), file directory and name management (see clause A.16), containers (see clause A.17), execution-time clocks (see clause D.14), timing events (see clause D.15), and array and vector operations (see clause G.3);
• Interfaces, to provide a limited form of multiple inheritance of operations (see clause 3.9.4); and
• A mechanism for writing C unions to make interfaces with C systems easier (see clause B.3.3).

This Amendment is organized by sections corresponding to those in the International Standard. These sections include wording changes and additions to the International Standard. Clause and subclause headings are given for each clause that contains a wording change. Clauses and subclauses that do not contain any change or addition are omitted.

For each change, an anchor paragraph from the International Standard (as corrected by Technical Corrigendum 1) is given. New or revised text and instructions are given with each change. The anchor paragraph can be replaced or deleted, or text can be inserted before or after it. When a heading immediately precedes the anchor paragraph, any text inserted before the paragraph is intended to appear under the heading.

Typographical conventions:

Instructions about the text changes are in this font. The actual text changes are in the same fonts as the International Standard - this font for text, this font for syntax, and this font for Ada source code. Note that this document is designed to be viewed with the default font as some Roman font, similar to the Ada 95 standard. This may require some adjustments to your browser.

Disclaimer:

This document is a draft of a possible amendment to Ada 95 (International Standard ISO/IEC 8652:1995). This draft contains only proposals substantially approved by the ISO/IEC JTC 1/SC 22/WG 9 Ada Rapporteur Group (ARG). Many other important proposals are under consideration by the ARG. Neither the ARG nor any other group has determined which, if any, of these proposals will be included in the amendment. Any proposal may be substantially changed or withdrawn before this document begins standardization, and other proposals may be added. This document is not an official publication or work product of the ARG.

Forward and Introduction

Introduction

Replace paragraph 3: [AI95-00387-01]

• Rationale for the Ada Programming Language -- 1995 edition, which gives an introduction to the new features of Ada, and explains the rationale behind them. Programmers should read this first.

by:

• Ada 95 Rationale. This gives an introduction to the new features of Ada incorporated in the 1995 edition of this Standard, and explains the rationale behind them. Programmers unfamiliar with Ada 95 should read this first.

• Ada 2005 Rationale. This gives an introduction to the changes and new features in Ada 2005 (compared with the 1995 edition), and explains the rationale behind them. Programmers should read this rationale before reading this Standard in depth.

Replace paragraph 5: [AI95-00387-01]

• The Annotated Ada Reference Manual (AARM). The AARM contains all of the text in the RM95, plus various annotations. It is intended primarily for compiler writers, validation test writers, and others who wish to study the fine details. The annotations include detailed rationale for individual rules and explanations of some of the more arcane interactions among the rules.

by:

• The Annotated Ada Reference Manual (AARM). The AARM contains all of the text in the consolidated Ada Reference Manual, plus various annotations. It is intended primarily for compiler writers, validation test writers, and others who wish to study the fine details. The annotations include detailed rationale for individual rules and explanations of some of the more arcane interactions among the rules.

Replace paragraph 6: [AI95-00387-01]

Ada was originally designed with three overriding concerns: program reliability and maintenance, programming as a human activity, and efficiency. This 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.

by:

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 amended version provides further flexibility and adds more standardized packages within the framework provided by the 1995 revision.

Replace paragraph 32: [AI95-00285-01; AI95-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, and Wide_Character are predefined.

by:

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.

Replace paragraph 34: [AI95-00285-01; AI95-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 and Wide_String are predefined.

by:

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.

Insert after paragraph 38: [AI95-00387-01]

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.

the new paragraph:

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 synchronized types (task types and protected types) thereby enabling concurrent programming and inheritance to be merged.

Replace paragraph 41: [AI95-00387-01]

Representation 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.

by:

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.

Replace paragraph 42: [AI95-00387-01]

The predefined environment of the language provides for input-output and other capabilities (such as string manipulation and random number generation) 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. Other standard library packages are defined in annexes of the standard to support systems with specialized requirements.

by:

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.

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.

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.

Replace paragraph 44: [AI95-00387-01]

This International Standard replaces the first edition of 1987. In this edition, the following major language changes have been incorporated:

by:

This amended International Standard updates the edition of 1995 which replaced the first edition of 1987. In the 1995 edition, the following major language changes were incorporated:

Replace paragraph 45: [AI95-00387-01]

• Support for standard 8-bit and 16-bit character sets. See Section 2, 3.5.2, 3.6.3, A.1, A.3, and A.4.

by:

• Support for standard 8-Bit and 16-bit characters was added. See clauses 2.1, 3.5.2, 3.6.3, A.1, A.3, and A.4.

Replace paragraph 46: [AI95-00387-01]

• Object-oriented programming with run-time polymorphism. See the discussions of classes, derived types, tagged types, record extensions, and private extensions in clauses 3.4, 3.9, and 7.3. See also the new forms of generic formal parameters that are allowed by 12.5.1, ``Formal Private and Derived Types'' and 12.7, ``Formal Packages''.

by:

• The type model was extended to include facilities for object-oriented programming with dynamic polymorphism. See the discussions of classes, derived types, tagged types, record extensions, and private extensions in clauses 3.4, 3.9, and 7.3. Additional forms of generic formal parameters were allowed as described in clauses 12.5.1 and 12.7.

Replace paragraph 47: [AI95-00387-01]

• Access types have been extended to allow an access value to designate a subprogram or an object declared by an object declaration (as opposed to just a heap-allocated object). See 3.10.

by:

• Access types were extended to allow an access value to designate a subprogram or an object declared by an object declaration as opposed to just an object allocated on a heap. See clause 3.10.

Replace paragraph 48: [AI95-00387-01]

• Efficient data-oriented synchronization is provided via protected types. See Section 9.

by:

• Efficient data-oriented synchronization was provided by the introduction of protected types. See clause 9.4.

Replace paragraph 49: [AI95-00387-01]

• The library units of a library may be organized into a hierarchy of parent and child units. See Section 10.

by:

• The library structure was extended to allow library units to be organized into a hierarchy of parent and child units. See clause 10.1.

Replace paragraph 50: [AI95-00387-01]

• Additional support has been added for interfacing to other languages. See Annex B.

by:

• Additional support was added for interfacing to other languages. See Annex B.

Replace paragraph 51: [AI95-00387-01]

• The Specialized Needs Annexes have been added to provide specific support for certain application areas:

by:

• The Specialized Needs Annexes were added to provide specific support for certain application areas:

Replace paragraph 57: [AI95-00387-01]

• Annex H, ``Safety and Security''

by:

• Annex H, ``High Integrity Systems''

Amendment 1 modifies the 1995 International Standard by making changes and additions that improve the capability of the language and the reliability of programs written in the language. In particular the changes were designed to improve the portability of programs, interfacing to other languages, and both the object-oriented and real-time capabilities.

The following significant changes with respect to the 1995 edition are incorporated:

• 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 clauses 2.1, 3.5, 3.6, A.1, A.3, and A.4.

• 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 clauses 3.4, 3.9, and 7.3. An alternative notation for calling operations more akin to that used in other languages has also been added. See clause 4.1.3.

• Access types have been further extended to unify properties such as the ability to access constants and to exclude null values. See clause 3.10. Anonymous access types are now permitted more freely and anonymous access-to-subprogram types are introduced. See clauses 3.3, 3.6, 3.10, and 8.5.1.

• 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 clauses 3.10.1 and 10.1.2. In addition, limited types have been made more useful by the provision of aggregates, constants, and constructor functions. See clauses 4.3, 6.5, and 7.5.

• 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 clauses 9.6.1, A.4, A.16, A.17, and A.18.

• Two of the Specialized Needs Annexes have been considerably enhanced:

• 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 clauses D.2, D.13, D.14, and D.15.

• 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 clause G.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 clauses 6.1, 11.4.2, and 11.5.

Section 1: General

1.1.2 Structure

Replace paragraph 13: [AI95-00347-01]

• Annex H, ``Safety and Security''

by:

• Annex H, ``High Integrity Systems''

1.1.4 Method of Description and Syntax Notation

Insert after paragraph 14: [AI95-00285-01]

• 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.

the new paragraph:

The delimiters, compound delimiters, reserved words, and numeric_literals are exclusively made of the characters whose code position is between 16#20# and 16#7E#, inclusively. The special characters for which names are defined in this International Standard (see 2.1) belong to the same range. For example, the character E in the definition of exponent is the character whose name is "LATIN CAPITAL LETTER E", not "GREEK CAPITAL LETTER EPSILON".

Insert before paragraph 15: [AI95-00395-01]

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.

the new paragraph:

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 locale-independent full case folding, as defined by documents referenced in the note in section 1 of ISO/IEC 10646:2003.

1.2 Normative References

Replace paragraph 3: [AI95-00415-01]

ISO/IEC 1539:1991, Information technology -- Programming languages -- FORTRAN.

by:

ISO/IEC 1539:2004, Information technology -- Programming languages -- Fortran -- Part 1: Base language.

Replace paragraph 4: [AI95-00415-01]

ISO 1989:1985, Programming languages -- COBOL.

by:

ISO/IEC 1989:2002, Programming languages -- COBOL.

Insert after paragraph 5: [AI95-00351-01]

ISO/IEC 6429:1992, Information technology - Control functions for coded graphic character sets.

the new paragraph:

ISO 8601:2004, Data elements and interchange formats - Information interchange - Representation of dates and times.

Replace paragraph 7: [AI95-00415-01]

ISO/IEC 9899:1990, Programming languages -- C.

by:

ISO/IEC 9899:1999, Programming languages -- C, supplemented by Technical Corrigendum 1:2001 and Technical Corrigendum 2:2004.

Replace paragraph 8: [AI95-00285-01; AI95-00376-01]

ISO/IEC 10646-1:1993, Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane, supplemented by Technical Corrigendum 1:1996.

by:

ISO/IEC 10646:2003, Information technology - Universal Multiple-Octet Coded Character Set (UCS).

ISO/IEC 14882:2003, Information technology - Programming languages - C++.

ISO/IEC TR 19769:2004, Information technology - Programming Languages, their environments and system software inferfaces - Extensions for the programming language C to support new character data types.

1.3 Definitions

Replace paragraph 1: [AI95-00415-01]

Terms are defined throughout this International Standard, indicated by italic type. Terms explicitly defined in this International Standard are not to be presumed to refer implicitly to similar terms defined elsewhere. Terms not defined in this International Standard are to be interpreted according to the Webster's Third New International Dictionary of the English Language. Informal descriptions of some terms are also given in Annex N, "Glossary".

by:

Terms are defined throughout this International Standard, indicated by italic type. Terms explicitly defined in this International Standard are not to be presumed to refer implicitly to similar terms defined elsewhere. Mathematical terms not defined in this International Standard are to be interpreted according to the CRC Concise Encyclopedia of Mathematics, Second Edition. Other terms not defined in this International Standard are to be interpreted according to the Webster's Third New International Dictionary of the English Language. Informal descriptions of some terms are also given in Annex N, "Glossary".

Section 2: Lexical Elements

2.1 Character Set

Replace paragraph 1: [AI95-00285-01; AI95-00395-01]

The only characters allowed outside of comments are the graphic_characters and format_effectors.

by:

The character repertoire for the text of an Ada program consists of the collection of characters described by the ISO/IEC 10646:2003 Universal Multiple-Octet Coded Character Set. This collection is organized in planes, each plane comprising 65536 characters.

Delete paragraph 2: [AI95-00285-01]

character ::= graphic_character | format_effector | other_control_function

Replace paragraph 3: [AI95-00285-01; AI95-00395-01]

graphic_character ::= identifier_letter | digit | space_character | special_character

by:

A character is any character defined within ISO/IEC 10646:2003 other than those whose relative code position in their plane is 16#FFFE# or 16#FFFF#.

Replace paragraph 4: [AI95-00285-01; AI95-00395-01]

The character repertoire for the text of an Ada program consists of the collection of characters called the Basic Multilingual Plane (BMP) of the ISO 10646 Universal Multiple-Octet Coded Character Set, plus a set of format_effectors and, in comments only, a set of other_control_functions; the coded representation for these characters is implementation defined (it need not be a representation defined within ISO-10646-1).

by:

The coded representation for characters is implementation defined (it need not be a representation defined within ISO/IEC 10646:2003). A character whose relative code position in its plane is 16#FFFE# or 16#FFFF# is not allowed anywhere in the text of a program.

The semantics of an Ada program whose text is not in Normalization Form KC (as defined by section 24 of ISO/IEC 10646:2003) is implementation defined.

Replace paragraph 5: [AI95-00285-01]

The description of the language definition in this International Standard uses the graphic symbols defined for Row 00: Basic Latin and Row 00: Latin-1 Supplement of the ISO 10646 BMP; these correspond to the graphic symbols of ISO 8859-1 (Latin-1); no graphic symbols are used in this International Standard for characters outside of Row 00 of the BMP. The actual set of graphic symbols used by an implementation for the visual representation of the text of an Ada program is not specified.

by:

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 section 1 of ISO/IEC 10646:2003. The actual set of graphic symbols used by an implementation for the visual representation of the text of an Ada program is not specified.

Replace paragraph 6: [AI95-00285-01]

The categories of characters are defined as follows:

by:

Characters are categorized as follows:

Delete paragraph 7: [AI95-00285-01]

identifier_letter

upper_case_identifier_letter | lower_case_identifier_letter

Replace paragraph 8: [AI95-00285-01]

upper_case_identifier_letter

Any character of Row 00 of ISO 10646 BMP whose name begins ``Latin Capital Letter''.

by:

letter_uppercase

Any character whose General Category is defined to be "Letter, Uppercase".

Replace paragraph 9: [AI95-00285-01]

lower_case_identifier_letter

Any character of Row 00 of ISO 10646 BMP whose name begins ``Latin Small Letter''.

by:

letter_lowercase

Any character whose General Category is defined to be "Letter, Lowercase".

letter_titlecase

Any character whose General Category is defined to be "Letter, Titlecase".

letter_modifier

Any character whose General Category is defined to be "Letter, Modifier".

letter_other

Any character whose General Category is defined to be "Letter, Other".

mark_non_spacing

Any character whose General Category is defined to be "Mark, Non-Spacing".

mark_spacing_combining

Any character whose General Category is defined to be "Mark, Spacing Combining".

Replace paragraph 10: [AI95-00285-01]

digit

One of the characters 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9.

by:

number_decimal_digit

Any character whose General Category is defined to be "Number, Decimal Digit".

number_letter

Any character whose General Category is defined to be "Number, Letter".

Replace paragraph 11: [AI95-00285-01]

space_character

The character of ISO 10646 BMP named ``Space''.

by:

separator_space

Any character whose General Category is defined to be "Separator, Space".

Replace paragraph 12: [AI95-00285-01]

special_character

Any character of the ISO 10646 BMP that is not reserved for a control function, and is not the space_character, an identifier_letter, or a digit.

by:

separator_line

Any character whose General Category is defined to be "Separator, Line".

separator_paragraph

Any character whose General Category is defined to be "Separator, Paragraph".

Replace paragraph 13: [AI95-00285-01]

format_effector

The control functions of ISO 6429 called character tabulation (HT), line tabulation (VT), carriage return (CR), line feed (LF), and form feed (FF).

by:

format_effector

The characters whose code positions are 16#09# (CHARACTER TABULATION), 16#0A# (LINE FEED(LF)), 16#0B# (LINE TABULATION), 16#0C# (FORM FEED(FF)), 16#0D# (CARRIAGE RETURN(CR)), 16#85# (NEXT LINE(NEL)), and the characters in categories separator_line and separator_paragraph. The names mentioned in parentheses in this list are not defined by ISO/IEC 10646:2003; they are only used for convenience in this International Standard.

other_control

Any character whose General Category is defined to be "Other, Control", and which is not defined to be a format_effector.

other_format

Any character whose General Category is defined to be "Other, Format".

other_private_use

Any character whose General Category is defined to be "Other, Private Use".

other_surrogate

Any character whose General Category is defined to be "Other, Surrogate".

punctuation_connector

Any character whose General Category is defined to be "Punctuation, Connector".

Replace paragraph 14: [AI95-00285-01; AI95-00395-01]

other_control_function

Any control function, other than a format_effector, that is allowed in a comment; the set of other_control_functions allowed in comments is implementation defined.

by:

graphic_character

Any character which is not in the categories other_control, other_private_use, other_surrogate, format_effector, and whose relative code position in its plane is neither 16#FFFE# nor 16#FFFF#.

Replace paragraph 15: [AI95-00285-01]

The following names are used when referring to certain special_characters:

by:

The following names are used when referring to certain characters (the first name is that given in ISO/IEC 10646:2003):

Delete paragraph 16: [AI95-00285-01]

In a nonstandard mode, the implementation may support a different character repertoire; in particular, the set of characters that are considered identifier_letters can be extended or changed to conform to local conventions.

Replace paragraph 17: [AI95-00285-01]

1 Every code position of ISO 10646 BMP that is not reserved for a control function is defined to be a graphic_character by this International Standard. This includes all code positions other than 0000 - 001F, 007F - 009F, and FFFE - FFFF.

by:

1 The characters in categories other_control, other_private_use, and other_surrogate are only allowed in comments.

2.2 Lexical Elements, Separators, and Delimiters

Replace paragraph 2: [AI95-00285-01]

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 character tabulation (HT) signifies at least one end of line.

by:

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 position is 16#09# (CHARACTER TABULATION) signifies at least one end of line.

Replace paragraph 3: [AI95-00285-01]

In some cases an explicit separator is required to separate adjacent lexical elements. A separator is any of a space character, a format effector, or the end of a line, as follows:

by:

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:

Replace paragraph 4: [AI95-00285-01]

• A space character is a separator except within a comment, a string_literal, or a character_literal.

by:

• A separator_space is a separator except within a comment, a string_literal, or a character_literal.

Replace paragraph 5: [AI95-00285-01]

• Character tabulation (HT) is a separator except within a comment.

by:

• The character whose code position is 16#09# (CHARACTER TABULATION) is a separator except within a comment.

Replace paragraph 8: [AI95-00285-01]

A delimiter is either one of the following special characters:

by:

A delimiter is either one of the following characters:

2.3 Identifiers

Replace paragraph 2: [AI95-00285-01; AI95-00395-01]

identifier ::=
   identifier_letter {[underline] letter_or_digit}

by:

identifier ::=
   identifier_start {identifier_start | identifier_extend}

Replace paragraph 3: [AI95-00285-01; AI95-00395-01]

letter_or_digit ::= identifier_letter | digit

by:

identifier_start ::=
     letter_uppercase
   | letter_lowercase
   | letter_titlecase
   | letter_modifier
   | letter_other
   | number_letter

identifier_extend ::=
     mark_non_spacing
   | mark_spacing_combining
   | number_decimal_digit
   | punctuation_connector
   | other_format

Replace paragraph 4: [AI95-00395-01]

An identifier shall not be a reserved word.

by:

After eliminating the characters in category other_format, an identifier shall not contain two consecutive characters in category punctuation_connector, or end with a character in that category.

Replace paragraph 5: [AI95-00285-01; AI95-00395-01]

All characters of an identifier are significant, including any underline character. Identifiers differing only in the use of corresponding upper and lower case letters are considered the same.

by:

Two identifiers are considered the same if they consist of the same sequence of characters after applying the following transformations (in this order):

• The characters in category other_format are eliminated.

• The remaining sequence of characters is converted to upper case.

Replace paragraph 6: [AI95-00285-01; AI95-00395-01]

In a nonstandard mode, an implementation may support other upper/lower case equivalence rules for identifiers, to accommodate local conventions.

by:

After applying these transformations, an identifier shall not be identical to a reserved word (in upper case).

In a nonstandard mode, an implementation may support other upper/lower case equivalence rules for identifiers, to accommodate local conventions.

NOTES
3 Identifiers differing only in the use of corresponding upper and lower case letters are considered the same.

2.4.1 Decimal Literals

Insert after paragraph 5: [AI95-00285-01]

exponent ::= E [+] numeral | E - numeral

the new paragraph:

digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

2.6 String Literals

Insert after paragraph 7: [AI95-00285-01]

NOTES
6 An end of line cannot appear in a string_literal.

the new paragraph:

7 No transformation is performed on the sequence of characters in a string_literal.

2.9 Reserved Words

In paragraph 2 replace: [AI95-00284-02; AI95-00395-01]

The following are the reserved words (ignoring upper/lower case distinctions):

by:

The following are the reserved words. Within a program, some or all of the letters of a reserved word may be in upper case, and one or more characters in category other_format may be inserted within or at the end of the reserved word.

In the list in paragraph 2, add: [AI95-00284-02; AI95-00395-01]

interface
overriding
synchronized

Section 3: Declarations and Types

3.1 Declarations

Replace paragraph 3: [AI95-00348-01]

basic_declaration ::=
     type_declaration | subtype_declaration
   | object_declaration | number_declaration
   | subprogram_declaration | abstract_subprogram_declaration
   | package_declaration | renaming_declaration
   | exception_declaration | generic_declaration
   | generic_instantiation

by:

basic_declaration ::=
     type_declaration | subtype_declaration
   | object_declaration | number_declaration
   | subprogram_declaration | abstract_subprogram_declaration
   | null_procedure_declaration | package_declaration
   | renaming_declaration | exception_declaration
   | generic_declaration | generic_instantiation

3.2 Types and Subtypes

Replace paragraph 4: [AI95-00326-01]

The composite types are the record types, record extensions, array types, task types, and protected types. A private type or private extension represents a partial view (see 7.3) of a type, providing support for data abstraction. A partial view is a composite type.

by:

The composite types are the record types, record extensions, array types, task types, and protected types.

There can be multiple views of a type with varying sets of operations. An incomplete type represents an incomplete view (see 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 7.3) of a type, providing support for data abstraction. The full view (see 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.

Replace paragraph 5: [AI95-00326-01]

Certain composite types (and partial 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.

by:

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.

Replace paragraph 6: [AI95-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.

by:

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.

Replace paragraph 7: [AI95-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 3.5 for range_constraints, 3.6.1 for index_constraints, and 3.7.1 for discriminant_constraints.

by:

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 3.5 for range_constraints, 3.6.1 for index_constraints, and 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 is called a null exclusion (see 3.10).

Replace paragraph 8: [AI95-00231-01; AI95-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. Such values belong to the subtype.

by:

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, in the case of a subtype of an access type, any applicable null exclusion. Such values belong to the subtype.

3.2.1 Type Declarations

Replace paragraph 4: [AI95-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

by:

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

Replace paragraph 7: [AI95-00230-01]

A type defined by a type_declaration 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 (including a parameter or a discriminant). 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."

by:

A type defined by a type_declaration 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."

Replace paragraph 8: [AI95-00230-01; AI95-00326-01]

A named type that is declared by a full_type_declaration, or an anonymous type that is defined as part of declaring an object of the type, is called a full type. The type_definition, task_definition, protected_definition, or access_definition that defines a full type is called a full type definition. Types declared by other forms of type_declaration are not separate types; they are partial or incomplete views of some full type.

by:

A named type that is declared by a full_type_declaration, 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, task_definition, protected_definition, or access_definition that defines a full type is called a full type definition. Types declared by other forms of type_declaration are not separate types; they are partial or incomplete views of some full type.

3.2.2 Subtype Declarations

Replace paragraph 3: [AI95-00231-01]

subtype_indication ::=  subtype_mark [constraint]

by:

subtype_indication ::=  [null_exclusion] subtype_mark [constraint]

3.2.3 Classification of Operations

Replace paragraph 1: [AI95-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 8.6) is T, or if it has an access parameter (see 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.

by:

An operation operates on a type T if it yields a value of type T, if it has an operand whose expected type (see 8.6) is T, or if it has an access parameter or access result type (see 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.

Insert after paragraph 6: [AI95-00335-01]

• 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;

the new paragraph:

• For a specific type, the stream-oriented attributes of the type that are available (see 13.13.2) at the end of the list of declarative_items where the type is declared;

Replace paragraph 7: [AI95-00200-01]

• Any subprograms not covered above that are explicitly declared immediately within the same declarative region as the type and that override (see 8.3) other implicitly declared primitive subprograms of the type.

by:

• In the case of 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 8.3) other implicitly declared primitive subprograms of the type.

3.3.1 Object Declarations

Replace paragraph 2: [AI95-00385-01; AI95-00406-01]

object_declaration ::=
   defining_identifier_list : [aliased] [constant] subtype_indication [:= expression]
 | defining_identifier_list : [aliased] [constant] array_type_definition [:= expression]
 | single_task_declaration
 | single_protected_declaration

by:

object_declaration ::=
   defining_identifier_list : [aliased] [constant] subtype_indication [:= expression]
 | defining_identifier_list : [aliased] [constant] access_definition [:= expression]
 | defining_identifier_list : [aliased] [constant] array_type_definition [:= expression]
 | single_task_declaration
 | single_protected_declaration

Replace paragraph 5: [AI95-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. An initialization expression shall not be given if the object is of a limited type.

by:

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.

Replace paragraph 8: [AI95-00373-01; AI95-00385-01]

The subtype_indication or full type definition of an object_declaration defines the nominal subtype of the object. The object_declaration declares an object of the nominal subtype.

by:

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 nominal subtype.

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 which includes a name denoting the current instance of the type or denoting an access discriminant.

Replace paragraph 9: [AI95-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 or aliased (see 3.10) 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. In the case of an aliased object, this initial value may be either explicit or implicit; in the other cases, an explicit initial value is required. 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.

by:

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.

Replace paragraph 16: [AI95-00385-01]

1.

The subtype_indication, array_type_definition, single_task_declaration, or single_protected_declaration is first elaborated. This creates the nominal subtype (and the anonymous type in the latter three cases).

by:

1.

The subtype_indication, access_definition, array_type_definition, single_task_declaration, or single_protected_declaration is first elaborated. This creates the nominal subtype (and the anonymous type in the last four cases).

Replace paragraph 18: [AI95-00373-01]

3.

The object is created, and, if there is not an initialization expression, any per-object expressions (see 3.8) are elaborated and any implicit initial values for the object or for its subcomponents are obtained as determined by the nominal subtype.

by:

3.

The object is created, and, if there is not an initialization expression, any per-object expressions (see 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 5.2 and 7.6, Initialize and Adjust procedures can be called.

Delete paragraph 19: [AI95-00373-01]

4.

Any initial values (whether explicit or implicit) are assigned to the object or to the corresponding subcomponents. As described in 5.2 and 7.6, Initialize and Adjust procedures can be called.

Replace paragraph 20: [AI95-00373-01]

For the third step above, the object creation and any elaborations and evaluations are performed in an arbitrary order, except that if the default_expression for a discriminant is evaluated to obtain its initial value, then this evaluation is performed before that of the default_expression for any component that depends on the discriminant, and also before that of any default_expression that includes the name of the discriminant. The evaluations of the third step and the assignments of the fourth step are performed in an arbitrary order, except that each evaluation is performed before the resulting value is assigned.

by:

For the third step above, evaluations and assignments are performed in an arbitrary order subject to the following restrictions:

• Assignment to any part of the object is preceded by the evaluation of the value that is to be assigned.

• The evaluation of a default_expression that includes the name of a discriminant is preceded by the assigment to that discriminant.

• The evaluation of the default_expression for any component that depends on a discriminant is preceded by the assignment to that discriminant.

• The assignments to any components, including implicit components, not requiring late initialization must 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 must precede the initial value evaluations of the component occurring later.

3.4 Derived Types and Classes

Replace paragraph 1: [AI95-00401-01]

A derived_type_definition defines a new type (and its first subtype) whose characteristics are derived from those of a parent type.

by:

A derived_type_definition defines a new type (and its first subtype) whose characteristics are derived from those of a parent type, and possibly from progenitor types.

Replace paragraph 2: [AI95-00251-01; AI95-00419-01]

derived_type_definition ::= [abstract] new parent_subtype_indication [record_extension_part]

by:

interface_list ::= interface_subtype_mark {and interface_subtype_mark}

derived_type_definition ::=
    [abstract] [limited] new parent_subtype_indication [[and interface_list] record_extension_part]

Replace paragraph 3: [AI95-00251-01; AI95-00401-01]

The parent_subtype_indication defines the parent subtype; its type is the parent type.

by:

An interface_subtype_mark in an interface_list names a progenitor subtype; its type is the progenitor type. The parent_subtype_indication defines the parent subtype; its type is the parent type.

A derived type has one parent type and zero or more progenitor types.

Replace paragraph 5: [AI95-00401-01; AI95-00419-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.

by:

If there is a record_extension_part, the derived type is called a record extension of the parent type. A record_extension_part (and an interface_list) shall be provided if and only if the parent type is a tagged type.

If the reserved word limited appears in a derived_type_definition, the parent type shall be a limited type.

Replace paragraph 8: [AI95-00251-01; AI95-00401-01]

• Each class of types that includes the parent type also includes the derived type.

by:

• Each class of types that includes the parent type or a progenitor type also includes the derived type.

Replace paragraph 15: [AI95-00419-01]

• The derived type is limited if and only if the parent type is limited.

by:

• The derived type is limited if the parent is a limited type that is not an interface type, or if the reserved word limited appears.

Replace paragraph 17: [AI95-00401-01]

• For each user-defined primitive subprogram (other than a user-defined equality operator -- see below) of the parent 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 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 4.5.2).

by:

• 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 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 4.5.2).

Replace paragraph 18: [AI95-00401-01]

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 type, after systematic replacement of each subtype of its profile (see 6.1) that is of the parent type with a corresponding subtype of the derived type. For a given subtype of the parent type, the corresponding subtype of the derived type is defined as follows:

by:

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 6.1) that is of the parent or progenitor type 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:

Replace paragraph 22: [AI95-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 type by the derived type is handled as part of the normal type conversion associated with parameter passing -- see 6.4.1.

by:

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 6.4.1.

Replace paragraph 23: [AI95-00251-01; AI95-00401-01]

If a primitive subprogram of the parent 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 7.3.1.

by:

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 7.3.1.

Replace paragraph 27: [AI95-00391-01; AI95-00401-01]

For the execution of a call on an inherited subprogram, a call on the corresponding primitive subprogram of the parent type is performed; the normal conversion of each actual parameter to the subtype of the corresponding formal parameter (see 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 parent's subprogram is converted to the derived type.

by:

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 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 parent or progenitor's subprogram 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.

Insert after paragraph 35: [AI95-00251-01; AI95-00401-01]

17 If the reserved word abstract is given in the declaration of a type, the type is abstract (see 3.9.3).

the new paragraph:

18 An interface type which has a progenitor type "is derived from" that type, and therefore is a derived type. A derived_type_definition, however, never defines an interface type.

3.4.1 Derivation Classes

Replace paragraph 2: [AI95-00251-01; AI95-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. 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).

by:

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 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).

Replace paragraph 6: [AI95-00230-01]

Universal types

Universal types are defined for (and belong to) the integer, real, and fixed point classes, and are referred to in this standard as respectively, universal_integer, universal_real, and universal_fixed. These are analogous to class-wide types for these language-defined numeric 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) is ``universal'' in that it is acceptable where some particular type in the class is expected (see 8.6).

by:

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 8.6).

Replace paragraph 10: [AI95-00230-01; AI95-00351-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 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. The ultimate ancestor of a type is the ancestor of the type that is not a descendant of any other type.

by:

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. Each untagged type has a unique ultimate ancestor.

3.5 Scalar Types

Insert after paragraph 27: [AI95-00285-01]

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 3.5.7) immediately below the value of Arg; Constraint_Error is raised if there is no such machine number.

the new paragraphs:

S'Wide_Wide_Image

S'Wide_Wide_Image denotes a function with the following specification:

        function S'Wide_Wide_Image(Arg : S'Base)
          return Wide_Wide_String

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.

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.

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).

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 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.

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 3.5.10) digits after the decimal point.

Replace paragraph 30: [AI95-00285-01]

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.

by:

The function returns an image of the value of Arg as a Wide_String, that is, a sequence of characters representing the value in display form. The lower bound of the result is one. The image has the same sequence of character 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).

Delete paragraph 31: [AI95-00285-01]

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.

Delete paragraph 32: [AI95-00285-01]

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 or implementation-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).

Delete paragraph 33: [AI95-00285-01]

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 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.

Delete paragraph 34: [AI95-00285-01]

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 3.5.10) digits after the decimal point.

Replace paragraph 37: [AI95-00285-01]

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_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_Image for the same value of Arg).

by:

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 character as 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).

S'Wide_Wide_Width

S'Wide_Wide_Width denotes the maximum length of a Wide_Wide_String returned by S'Wide_Wide_Image over all the values of S. It denotes zero for a subtype that has a null range. Its type is universal_integer.

Insert after paragraph 39: [AI95-00285-01]

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.

the new paragraphs:

S'Wide_Wide_Value

S'Wide_Wide_Value denotes a function with the following specification:

        function S'Wide_Wide_Value(Arg : Wide_Wide_String)
          return S'Base

This function returns a value given an image of the value as a Wide_Wide_String, ignoring any leading or trailing spaces.

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.

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.

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:

• numeric_literal

• numeral.[exponent]

• .numeral[exponent]

• base#based_numeral.#[exponent]

• base#.based_numeral#[exponent]

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.

Replace paragraph 43: [AI95-00285-01]

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 nongraphic character of the type), the result is the corresponding enumeration value; otherwise Constraint_Error is raised.

by:

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 nongraphic character 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.

Delete paragraph 44: [AI95-00285-01]

For the evaluation of a call on S'Wide_Value (or S'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.

Delete paragraph 45: [AI95-00285-01]

For the evaluation of a call on S'Wide_Value (or S'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:

Delete paragraph 46: [AI95-00285-01]

• numeric_literal

Delete paragraph 47: [AI95-00285-01]

• numeral.[exponent]

Delete paragraph 48: [AI95-00285-01]

• .numeral[exponent]

Delete paragraph 49: [AI95-00285-01]

• base#based_numeral.#[exponent]

Delete paragraph 50: [AI95-00285-01]

• base#.based_numeral#[exponent]

Delete paragraph 51: [AI95-00285-01]

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.

Replace paragraph 55: [AI95-00285-01]

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_Value for a corresponding Arg of type Wide_String.

by:

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.

Replace paragraph 56: [AI95-00285-01]

An implementation may extend the Wide_Value, Value, Wide_Image, and Image attributes of a floating point type to support special values such as infinities and NaNs.

by:

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.

Replace paragraph 59: [AI95-00285-01]

21 For any value V (including any nongraphic character) of an enumeration subtype S, S'Value(S'Image(V)) equals V, as does S'Wide_Value(S'Wide_Image(V)). Neither expression ever raises Constraint_Error.

by:

21 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.

3.5.2 Character Types

Replace paragraph 2: [AI95-00285-01]

The predefined type Character is a character type whose values correspond to the 256 code positions of Row 00 (also known as Latin-1) of the ISO 10646 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 positions of Row 00 (0000-001F and 007F-009F) has a corresponding language-defined name, which is not usable as an enumeration literal, but which is usable with the attributes (Wide_)Image and (Wide_)Value; these names are given in the definition of type Character in A.1, ``The Package Standard'', but are set in italics.

by:

The predefined type Character is a character type whose values correspond to the 256 code positions of Row 00 (also known as Latin-1) of the ISO/IEC 10646:2003 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 positions of Row 00 (0000-001F and 007F-009F) 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 A.1, ``The Package Standard'', but are set in italics.

Replace paragraph 3: [AI95-00285-01; AI95-00395-01]

The predefined type Wide_Character is a character type whose values correspond to the 65536 code positions of the ISO 10646 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. The last 2 values of Wide_Character correspond to the nongraphic positions FFFE and FFFF of the BMP, and are assigned the language-defined names FFFE and FFFF. As with the other language-defined names for nongraphic characters, the names FFFE and FFFF are usable only with the attributes (Wide_)Image and (Wide_)Value; they are not usable as enumeration literals. All other values of Wide_Character are considered graphic characters, and have a corresponding character_literal.

by:

The predefined type Wide_Character is a character type whose values correspond to the 65536 code positions of the ISO/IEC 10646:2003 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.

The predefined type Wide_Wide_Character is a character type whose values correspond to the 2147483648 code positions of the ISO/IEC 10646:2003 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.

The characters whose code position 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 position 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.

Delete paragraph 4: [AI95-00285-01]

In a nonstandard mode, an implementation may provide other interpretations for the predefined types Character and Wide_Character, to conform to local conventions.

Delete paragraph 5: [AI95-00285-01]

If an implementation supports a mode with alternative interpretations for Character and Wide_Character, the set of graphic characters of Character should nevertheless remain a proper subset of the set of graphic characters of Wide_Character. Any character set ``localizations'' should be reflected in the results of the subprograms defined in the language-defined package Characters.Handling (see A.3) available in such a mode. In a mode with an alternative interpretation of Character, the implementation should also support a corresponding change in what is a legal identifier_letter.

3.5.4 Integer Types

Replace paragraph 16: [AI95-00340-01]

For every modular subtype S, the following attribute is defined:

by:

For every modular subtype S, the following attributes are defined:

S'Mod

S'Mod denotes a function with the following specification:

        function S'Mod (Arg : universal_integer)
             return S'Base

This function returns Arg mod S'Modulus.

3.5.9 Fixed Point Types

Replace paragraph 8: [AI95-00100-01]

The set of values of a fixed point type comprise the integral multiples of a number called the small 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 (see 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.

by:

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 (see 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.

3.6 Array Types

Replace paragraph 7: [AI95-00230-01; AI95-00406-01]

component_definition ::= [aliased] subtype_indication

by:

component_definition ::=
   [aliased] subtype_indication
 | [aliased] access_definition

Delete paragraph 11: [AI95-00363-01]

Within the definition of a nonlimited composite type (or a limited composite type that later in its immediate scope becomes nonlimited -- see 7.3.1 and 7.5), if a component_definition contains the reserved word aliased and the type of the component is discriminated, then the nominal subtype of the component shall be constrained.

Replace paragraph 22: [AI95-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 or the evaluation of the range. The elaboration of a discrete_subtype_definition that contains one or more per-object expressions is defined in 3.8. The elaboration of a component_definition in an array_type_definition consists of the elaboration of the subtype_indication. The elaboration of any discrete_subtype_definitions and the elaboration of the component_definition are performed in an arbitrary order.

by:

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 or the evaluation of the range. The elaboration of a discrete_subtype_definition that contains one or more per-object expressions is defined in 3.8. The elaboration of a component_definition in an array_type_definition consists of the elaboration of the subtype_indication or access_definition. The elaboration of any discrete_subtype_definitions and the elaboration of the component_definition are performed in an arbitrary order.

3.6.2 Operations of Array Types

Replace paragraph 16: [AI95-00287-01]

48 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, unless the array type is limited. 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.

by:

48 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.

3.6.3 String Types

Replace paragraph 2: [AI95-00285-01]

There are two predefined string types, String and Wide_String, each indexed by values of the predefined subtype Positive; these are declared in the visible part of package Standard:

by:

There are three predefined string types, String, Wide_String, and Wide_Wide_String, each indexed by the value of the predefined subtype Positive; these are declared in the visible part of package Standard:

Replace paragraph 4: [AI95-00285-01]

type String is array (Positive range <>) of Character;
type Wide_String is array (Positive range <>) of Wide_Character;

by:

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;