Annex J
(normative)
Obsolescent Features
1/2 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.
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.
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.
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.
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.
Syntax
2/4 delta_constraint ::= delta static_simple_expression
[range_constraint]
Name Resolution Rules
3/4 The simple_expression of a delta_constraint is expected to be of any real
type.
Legality Rules
4/4 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).
Static Semantics
7/4 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 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 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 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.
J.4 The Constrained Attribute
Static Semantics
1 For every private subtype S, the following attribute is defined:
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.
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;
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;".
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.
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.
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.
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 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 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;
J.8 Mod Clauses
Syntax
1 mod_clause ::= at mod static_expression;
Static Semantics
2 A record_representation_clause of the form:
3/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;
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.
3/3 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.
J.10 Specific Suppression of Checks
1/2 Pragma Suppress can be used to suppress checks on specific entities.
Syntax
2/2 The form of a specific Suppress pragma is as follows:
3/2 pragma Suppress(identifier, [On =>] name);
Legality Rules
4/2 The identifier shall be the name of a check (see 11.5). The name shall
statically denote some entity.
5/2 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 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.
Implementation Permissions
7/2 An implementation is allowed to place restrictions on specific Suppress
pragmas.
NOTES
8/2 3 An implementation may support a similar On parameter on pragma
Unsuppress (see 11.5).
J.11 The Class Attribute of Untagged Incomplete Types
Static Semantics
1/2 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 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.
J.12 Pragma Interface
Syntax
1/2 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.
J.13 Dependence Restriction Identifiers
1/2 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 The following restriction_identifiers exist:
3/2 No_Asynchronous_Control
Semantic dependence on the predefined package
Asynchronous_Task_Control is not allowed.
4/2 No_Unchecked_Conversion
Semantic dependence on the predefined generic function
Unchecked_Conversion is not allowed.
5/2 No_Unchecked_Deallocation
Semantic dependence on the predefined generic procedure
Unchecked_Deallocation is not allowed.
J.14 Character and Wide_Character Conversion Functions
Static Semantics
1/2 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;
J.15 Aspect-related Pragmas
1/3 Pragmas can be used as an alternative to aspect_specifications to specify
certain aspects.
J.15.1 Pragma Inline
Syntax
1/3 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 The pragma shall apply to one or more callable entities or generic
subprograms.
Static Semantics
4/3 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.
Implementation Permissions
5/3 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.
NOTES
6/3 4 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.
J.15.2 Pragma No_Return
Syntax
1/3 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 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 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.
J.15.3 Pragma Pack
Syntax
1/3 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 The first_subtype_local_name of a pragma Pack shall denote a composite
subtype.
Static Semantics
4/3 Pragma Pack specifies that the Pack aspect (see 13.2) for the type denoted
by first_subtype_local_name has the value True.
J.15.4 Pragma Storage_Size
Syntax
1/3 The form of a pragma Storage_Size is as follows:
2/3 pragma Storage_Size (expression);
3/3 A pragma Storage_Size is allowed only immediately within a
task_definition.
Name Resolution Rules
4/3 The expression of a pragma Storage_Size is expected to be of any integer
type.
Static Semantics
5/3 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.
J.15.5 Interfacing Pragmas
Syntax
1/3 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 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 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 The convention_identifier of an interfacing pragma shall be the name of a
convention (see B.1).
8/3 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 The external_name_string_expression and link_name_string_expression of a
pragma Import or Export shall be static.
10/3 The local_name of each of these pragmas shall denote a declaration that
may have the similarly named aspect specified.
Static Semantics
11/3 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.
J.15.6 Pragma Unchecked_Union
Syntax
1/3 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 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 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.
J.15.7 Pragmas Interrupt_Handler and Attach_Handler
Syntax
1/3 The form of a pragma Interrupt_Handler is as follows:
2/3 pragma Interrupt_Handler (handler_name);
3/3 The form of a pragma Attach_Handler is as follows:
4/3 pragma Attach_Handler (handler_name, expression);
Name Resolution Rules
5/3 For the Interrupt_Handler and Attach_Handler pragmas, the handler_name
shall resolve to denote a protected procedure with a parameterless profile.
6/3 For the Attach_Handler pragma, the expected type for the expression is
Interrupts.Interrupt_Id (see C.3.2).
Legality Rules
7/3 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.
Static Semantics
8/3 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.
J.15.8 Shared Variable Pragmas
Syntax
1/3 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 pragma Independent (component_local_name);
5/3 pragma Atomic_Components (array_local_name);
6/3 pragma Volatile_Components (array_local_name);
7/3 pragma Independent_Components (local_name);
Name Resolution Rules
8/3 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 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 The local_name of each of these pragmas shall denote a declaration that
may have the similarly named aspect specified.
J.15.9 Pragma CPU
Syntax
1/3 The form of a pragma CPU is as follows:
2/3 pragma CPU (expression);
Name Resolution Rules
3/3 The expected type for the expression of a pragma CPU is
System.Multiprocessors.CPU_Range.
Legality Rules
4/3 A CPU pragma is allowed only immediately within a task_definition, or the
declarative_part of a subprogram_body.
5/3 For a CPU pragma that appears in the declarative_part of a
subprogram_body, the expression shall be static.
Static Semantics
6/3 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.
J.15.10 Pragma Dispatching_Domain
Syntax
1/3 The form of a pragma Dispatching_Domain is as follows:
2/3 pragma Dispatching_Domain (expression);
Name Resolution Rules
3/3 The expected type for the expression is
System.Multiprocessors.Dispatching_Domains.Dispatching_Domain.
Legality Rules
4/3 A Dispatching_Domain pragma is allowed only immediately within a
task_definition.
Static Semantics
5/3 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.
J.15.11 Pragmas Priority and Interrupt_Priority
Syntax
1/3 The form of a pragma Priority is as follows:
2/3 pragma Priority (expression);
3/3 The form of a pragma Interrupt_Priority is as follows:
4/3 pragma Interrupt_Priority [(expression);]
Name Resolution Rules
5/3 The expected type for the expression in a Priority or Interrupt_Priority
pragma is Integer.
Legality Rules
6/3 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 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 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 If there is no expression in an Interrupt_Priority pragma, the
Interrupt_Priority aspect has the value Interrupt_Priority'Last.
J.15.12 Pragma Relative_Deadline
Syntax
1/3 The form of a pragma Relative_Deadline is as follows:
2/3 pragma Relative_Deadline (relative_deadline_expression);
Name Resolution Rules
3/3 The expected type for a relative_deadline_expression is
Real_Time.Time_Span.
Legality Rules
4/3 A Relative_Deadline pragma is allowed only immediately within a
task_definition or the declarative_part of a subprogram_body.
Static Semantics
5/3 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.
J.15.13 Pragma Asynchronous
Syntax
1/3 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 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 The local_name of a pragma Asynchronous shall denote a declaration that
may have aspect Asynchronous specified.
Generated by dwww version 1.15 on Sat May 18 12:18:42 CEST 2024.