Annex J
(normative)
Obsolescent Features
1/2 {AI95-00368-01} [{obsolescent feature} 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.
J.1 Renamings of Ada 83 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.
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 is not legal in Ada 83, nor will it be in Ada 95. 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 delta_constraint ::= delta static_expression [range_constraint]
Name Resolution Rules
3 {expected type (delta_constraint expression) [partial]} The expression of
a delta_constraint is expected to be of any real type.
Legality Rules
4 The expression of a delta_constraint shall be static.
5 For a subtype_indication with a delta_constraint, the subtype_mark shall
denote an ordinary fixed point subtype.
6 {notwithstanding} 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 A subtype_indication with a subtype_mark that denotes an ordinary fixed
point subtype and a delta_constraint defines an ordinary fixed point subtype
with a delta given by the value of the expression of the delta_constraint. If
the delta_constraint includes a range_constraint, then the ordinary fixed
point subtype is constrained by the range_constraint.
8 A subtype_indication with a subtype_mark that denotes a floating point
subtype and a digits_constraint defines a floating point subtype with a
requested decimal precision (as reflected by its Digits attribute) given by
the value of the expression of the digits_constraint. If the
digits_constraint includes a range_constraint, then the floating point subtype
is constrained by the range_constraint.
Dynamic Semantics
9 {compatibility (delta_constraint with an ordinary fixed point subtype)
[partial]} A delta_constraint is compatible with an ordinary fixed point
subtype if the value of the expression is no less than the delta of the
subtype, and the range_constraint, if any, is compatible with the subtype.
10 {compatibility (digits_constraint with a floating point subtype)
[partial]} A digits_constraint is compatible with a floating point subtype if
the value of the expression is no greater than the requested decimal precision
of the subtype, and the range_constraint, if any, is compatible with the
subtype.
11 {elaboration (delta_constraint) [partial]} 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).
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 {extensions to Ada 83} 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 {interrupt entry} 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 {specifiable (of Address for entries) [partial]} 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 {initialization (of a task object) [partial]} 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.
{Program_Error (raised by failure of run-time check)} If this check fails,
Program_Error is raised. Otherwise, the interrupt entry is attached to the
interrupt associated with the specified address.
8 {finalization (of a task object) [partial]} 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 {bounded error (cause) [partial]} 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 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 To be honest: T'Storage_Size cannot be particularly meaningful in
the presence of a pragma 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 pragma, 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/2 {AI95-00345-01}
{specifiable (of Storage_Size for a task first subtype)
[partial]} Storage_Size may be specified for a task first
subtype that is not an interface via an
attribute_definition_clause.
Wording Changes from Ada 95
3.a/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/2 {AI95-00224-01} This clause 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/2 {AI95-00326-01} This clause 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/2 {AI95-00326-01} This clause 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} {Restrictions (No_Asynchronous_Control)}
No_Asynchronous_Control
Semantic dependence on the predefined package
Asynchronous_Task_Control is not allowed.
4/2 {AI95-00394-01} {Restrictions (No_Unchecked_Conversion)}
No_Unchecked_Conversion
Semantic dependence on the predefined generic function
Unchecked_Conversion is not allowed.
5/2 {AI95-00394-01} {Restrictions (No_Unchecked_Deallocation)}
No_Unchecked_Deallocation
Semantic dependence on the predefined generic procedure
Unchecked_Deallocation is not allowed.
Wording Changes from Ada 95
5.a/2 {AI95-00394-01} This clause 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/2 {AI95-00394-01} This clause is new. These subprograms were moved
to Characters.Conversions (see A.3.4).
Generated by dwww version 1.15 on Thu May 23 08:02:05 CEST 2024.