dwww Home | Show directory contents | Find package


                                   Annex J
                                 (normative)

                            Obsolescent Features


1/2 {AI95-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 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 A.6).

1.d           * The Epsilon, Mantissa, Emax, Small, Large, Safe_Emax,
                Safe_Small, and Safe_Large attributes of floating point types
                (see A.5.3).

1.e/2         * This paragraph was deleted.{AI95-00284-02}

1.f           * The pragmas System_Name, Storage_Unit, and Memory_Size (see
                13.7).

1.g           * The pragma Shared (see 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-01} A mention of the No_Obsolescent_Features
            restriction was added.


                        Wording Changes from Ada 2005

1.j/3       {AI05-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.


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


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-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-1} is not legal in Ada (and never was legal). One has
            to write:

5.f             """This is quoted."""


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/4     {AI12-0152-1} delta_constraint ::= delta static_simple_expression
         [range_constraint]


                            Name Resolution Rules

3/4 {AI12-0152-1} The simple_expression of a delta_constraint is expected to
be of any real type.


                               Legality Rules

4/4 {AI12-0152-1} The simple_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 3.5.9 that only allows a decimal fixed
point subtype).

6.a/2       This paragraph was deleted.{AI95-00114-01}


                              Static Semantics

7/4 {AI12-0152-1} 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 simple_expression of the
delta_constraint. If the delta_constraint includes a range_constraint, then
the ordinary fixed point subtype is constrained by the range_constraint.

8/4 {AI12-0152-1} 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 simple_expression of the
digits_constraint. If the digits_constraint includes a range_constraint, then
the floating point subtype is constrained by the range_constraint.


                              Dynamic Semantics

9/4 {AI12-0152-1} A delta_constraint is compatible with an ordinary fixed
point subtype if the value of the simple_expression is no less than the delta
of the subtype, and the range_constraint, if any, is compatible with the
subtype.

10/4 {AI12-0152-1} A digits_constraint is compatible with a floating point
subtype if the value of the simple_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).


                        Wording Changes from Ada 2012

11.c/4      {AI12-0152-1} Corrigendum: Changed the syntax so that the value
            following delta in a delta_constraint is a simple_expression. This
            is compatible as any expressions that would require extra
            parentheses are already illegal. The change is necessary to
            eliminate syntax ambguities in derived_type_definitions. The
            similar change for digits_constraint is documented in 3.5.9.


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.


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;


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


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


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 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 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 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/0077} {AI95-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 9.3.

        NOTES

20/1    1  {8652/0077} {AI95-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-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/0077} {AI95-00111-01} Corrigendum: The undefined term accept
            body was replaced by accept_statement.


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


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-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-01} {AI05-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-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 13.3).


                         Wording Changes from Ada 95

3.b/2       {AI95-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.


J.10 Specific Suppression of Checks


1/2 {AI95-00224-01} Pragma Suppress can be used to suppress checks on specific
entities.


                                   Syntax

2/2     {AI95-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-01} The identifier shall be the name of a check (see 11.5).
The name shall statically denote some entity.

5/2 {AI95-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.


                              Static Semantics

6/2 {AI95-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
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-01} An implementation is allowed to place restrictions on
specific Suppress pragmas.

        NOTES

8/2     3  {AI95-00224-01} An implementation may support a similar On
        parameter on pragma Unsuppress (see 11.5).


                         Wording Changes from Ada 95

8.a/3       {AI95-00224-01} {AI05-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.


J.11 The Class Attribute of Untagged Incomplete Types



                              Static Semantics

1/2 {AI95-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-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-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-01} {AI05-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.


J.12 Pragma Interface



                                   Syntax

1/2     {AI95-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-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-01} {AI05-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.


J.13 Dependence Restriction Identifiers


1/2 {AI95-00394-01} The following restrictions involve dependence on specific
language-defined units. The more general restriction No_Dependence (see
13.12.1) should be used for this purpose.


                              Static Semantics

2/2 {AI95-00394-01} The following restriction_identifiers exist:

3/2 {AI95-00394-01} No_Asynchronous_Control
                Semantic dependence on the predefined package
                Asynchronous_Task_Control is not allowed.

4/2 {AI95-00394-01} No_Unchecked_Conversion
                Semantic dependence on the predefined generic function
                Unchecked_Conversion is not allowed.

5/2 {AI95-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-01} {AI05-0299-1} This subclause is new. These
            restrictions are replaced by the more general No_Dependence (see
            13.12.1).


J.14 Character and Wide_Character Conversion Functions



                              Static Semantics

1/2 {AI95-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-01} {AI05-0299-1} This subclause is new. These
            subprograms were moved to Characters.Conversions (see A.3.4).


J.15 Aspect-related Pragmas


1/3 {AI05-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-1} {AI05-0299-1} This subclause is new. Many existing
            pragmas have been converted into aspects; the pragmas have moved
            here.


J.15.1 Pragma Inline



                                   Syntax

1/3     {AI05-0229-1} The form of a pragma Inline, which is a program unit
        pragma (see 10.1.5), is as follows:

2/3       pragma Inline (name{, name});


                               Legality Rules

3/3 {AI05-0229-1} The pragma shall apply to one or more callable entities or
generic subprograms.


                              Static Semantics

4/3 {AI05-0229-1} Pragma Inline specifies that the Inline aspect (see 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-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-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-01} {AI05-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-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-01} {AI05-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-1} {AI05-0299-1} This subclause is new. Pragma Inline
            was moved here from 6.3.2; aspect Inline lives there now.


J.15.2 Pragma No_Return



                                   Syntax

1/3     {AI05-0229-1} The form of a pragma No_Return, which is a
        representation pragma (see 13.1), is as follows:

2/3       pragma No_Return (procedure_local_name{, procedure_local_name});


                               Legality Rules

3/3 {AI05-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-1} Pragma No_Return specifies that the No_Return aspect (see
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-1} {AI05-0299-1} This subclause is new. Pragma
            No_Return was moved here from 6.5.1; aspect No_Return lives there
            now.


J.15.3 Pragma Pack



                                   Syntax

1/3     {AI05-0229-1} The form of a pragma Pack, which is a representation
        pragma (see 13.1), is as follows:

2/3       pragma Pack (first_subtype_local_name);


                               Legality Rules

3/3 {AI05-0229-1} The first_subtype_local_name of a pragma Pack shall denote a
composite subtype.


                              Static Semantics

4/3 {AI05-0229-1} Pragma Pack specifies that the Pack aspect (see 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-1} {AI05-0299-1} This subclause is new. Pragma Pack was
            moved here from 13.2; aspect Pack lives there now.


J.15.4 Pragma Storage_Size



                                   Syntax

1/3     {AI05-0229-1} The form of a pragma Storage_Size is as follows:

2/3       pragma Storage_Size (expression);

3/3     {AI05-0229-1} A pragma Storage_Size is allowed only immediately within
        a task_definition.


                            Name Resolution Rules

4/3 {AI05-0229-1} The expression of a pragma Storage_Size is expected to be of
any integer type.


                              Static Semantics

5/3 {AI05-0229-1} The pragma Storage_Size sets the Storage_Size aspect (see
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-1} {AI05-0299-1} This subclause is new. Pragma
            Storage_Size was moved here from 13.3; aspect Storage_Size lives
            there now.


J.15.5 Interfacing Pragmas



                                   Syntax

1/3     {AI05-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-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-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-1} The convention_identifier of an interfacing pragma shall be
the name of a convention (see B.1).

8/3 {AI05-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-1} The external_name_string_expression and
link_name_string_expression of a pragma Import or Export shall be static.

10/3 {AI05-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-1} An interfacing pragma specifies various aspects of the
entity denoted by the local_name as follows:

12/3   * The Convention aspect (see B.1) is convention_identifier.

13/3   * A pragma Import specifies that the Import aspect (see B.1) is True.

14/3   * A pragma Export specifies that the Export aspect (see 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 B.1) is specified to be
        external_name_string_expression. If a link name is given in the
        pragma, the Link_Name aspect (see B.1) is specified to be the
        link_name_string_expression.


                        Wording Changes from Ada 2005

15.a/3      {AI05-0229-1} {AI05-0299-1} This subclause is new. Pragmas Import,
            Export, and Convention were moved here from B.1; aspects Import,
            Export, Convention, Link_Name, and External_Name live there now.


J.15.6 Pragma Unchecked_Union



                                   Syntax

1/3     {AI05-0229-1} The form of a pragma Unchecked_Union, which is a
        representation pragma (see 13.1), is as follows:

2/3       pragma Unchecked_Union (first_subtype_local_name);


                               Legality Rules

3/3 {AI05-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-1} A pragma Unchecked_Union specifies that the Unchecked_Union
aspect (see 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-1} {AI05-0299-1} This subclause is new. Pragma
            Unchecked_Union was moved here from B.3.3; aspect Unchecked_Union
            lives there now.


J.15.7 Pragmas Interrupt_Handler and Attach_Handler



                                   Syntax

1/3     {AI05-0229-1} The form of a pragma Interrupt_Handler is as follows:

2/3       pragma Interrupt_Handler (handler_name);

3/3     {AI05-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-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-1} For the Attach_Handler pragma, the expected type for the
expression is Interrupts.Interrupt_Id (see C.3.2).


                               Legality Rules

7/3 {AI05-0033-1} {AI05-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 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-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-1} For an implementation that supports Annex C, a pragma
Interrupt_Handler specifies the Interrupt_Handler aspect (see 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 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-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-1} {AI05-0299-1} This subclause is new. Pragmas
            Interrupt_Handler and Attach_Handler were moved here from C.3.1;
            aspects Interrupt_Handler and Attach_Handler live there now.


J.15.8 Shared Variable Pragmas



                                   Syntax

1/3     {AI05-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-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-1}   pragma Independent_Components (local_name);

7.a/3       Discussion: {AI05-0009-1} {AI05-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-1} {AI05-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-1} These pragmas are representation pragmas (see 13.1). Each of
these pragmas specifies that the similarly named aspect (see C.6) of the type,
object, or component denoted by its argument is True.


                               Legality Rules

10/3 {AI05-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-1} {AI05-0299-1} This subclause is new. These pragmas
            were moved here from C.6; various aspects live there now.


J.15.9 Pragma CPU


0.a/3       Discussion: {AI05-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-1} The form of a pragma CPU is as follows:

2/3       pragma CPU (expression);


                            Name Resolution Rules

3/3 {AI05-0229-1} The expected type for the expression of a pragma CPU is
System.Multiprocessors.CPU_Range.


                               Legality Rules

4/3 {AI05-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-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-1} For an implementation that supports Annex D, a pragma CPU
specifies the value of the CPU aspect (see 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-1} Pragma CPU is new.


J.15.10 Pragma Dispatching_Domain


0.a/3       Discussion: {AI05-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-1} The form of a pragma Dispatching_Domain is as follows:

2/3       pragma Dispatching_Domain (expression);


                            Name Resolution Rules

3/3 {AI05-0167-1} The expected type for the expression is
System.Multiprocessors.Dispatching_Domains.Dispatching_Domain.


                               Legality Rules

4/3 {AI05-0167-1} A Dispatching_Domain pragma is allowed only immediately
within a task_definition.


                              Static Semantics

5/3 {AI05-0167-1} For an implementation that supports Annex D, a pragma
Dispatching_Domain specifies the value of the Dispatching_Domain aspect (see
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-1} Pragma Dispatching_Domain is new.


J.15.11 Pragmas Priority and Interrupt_Priority



                                   Syntax

1/3     {AI05-0229-1} The form of a pragma Priority is as follows:

2/3       pragma Priority (expression);

3/3     {AI05-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-1} The expected type for the expression in a Priority or
Interrupt_Priority pragma is Integer.


                               Legality Rules

6/3 {AI05-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-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-1} For an implementation that supports Annex D, a pragma
Priority specifies the value of the Priority aspect (see 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-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-1} {AI05-0299-1} This subclause is new. Pragmas
            Interrupt_Priority and Priority were moved here from D.1; aspects
            Interrupt_Priority and Priority live there now.


J.15.12 Pragma Relative_Deadline



                                   Syntax

1/3     {AI05-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-1} The expected type for a relative_deadline_expression is
Real_Time.Time_Span.


                               Legality Rules

4/3 {AI05-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-1} For an implementation that supports Annex D, a pragma
Relative_Deadline specifies the value of the Relative_Deadline aspect (see
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-1} {AI05-0299-1} This subclause is new. Pragma
            Relative_Deadline was moved here from D.2.6; aspect
            Relative_Deadline lives there now.


J.15.13 Pragma Asynchronous



                                   Syntax

1/3     {AI05-0229-1} The form of a pragma Asynchronous, which is a
        representation pragma (see 13.1), is as follows:

2/3       pragma Asynchronous (local_name);


                              Static Semantics

3/3 {AI05-0229-1} For an implementation that supports Annex E, a pragma
Asynchronous specifies that the Asynchronous aspect (see E.4.1) for the
procedure or type denoted by local_name has the value True.


                               Legality Rules

4/3 {AI05-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-1} {AI05-0299-1} This subclause is new. Pragma
            Asynchronous was moved here from E.4.1; aspect Asynchronous lives
            there now.

Generated by dwww version 1.15 on Sat Jun 15 21:57:23 CEST 2024.