CVS difference for ai05s/ai05-0229-1.txt
--- ai05s/ai05-0229-1.txt 2011/06/20 04:55:18 1.17
+++ ai05s/ai05-0229-1.txt 2011/08/06 05:43:51 1.18
@@ -1,4 +1,6 @@
-!standard 13.2(5) 11-06-10 AI05-0229-1/11
+!standard 13.2(5) 11-08-05 AI05-0229-1/12
+!standard 2.8(29/2)
+!standard 3.7(37/2)
!standard 4.8(15)
!standard 6.3.2(2)
!standard 6.3.2(3)
@@ -13,8 +15,32 @@
!standard 6.5.1(4/2)
!standard 6.5.1(8/2)
!standard 6.5.1(10/2)
+!standard 9.10(1)
+!standard 10.1.4(7/2)
+!standard 10.2.1(25)
+!standard 10.2.1(26)
!standard 11.4.1(4/2)
+!standard 11.5(7.2/2)
+!standard 11.6(6)
+!standard 13.2(1)
+!standard 13.2(2)
+!standard 13.2(3)
+!standard 13.2(4)
+!standard 13.2(5)
+!standard 13.2(7)
+!standard 13.3(38)
+!standard 13.3(58)
+!standard 13.3(60)
+!standard 13.3(61)
+!standard 13.3(62)
+!standard 13.3(63)
+!standard 13.3(64)
+!standard 13.3(65)
+!standard 13.3(66)
+!standard 13.3(73)
!standard 13.3.1(0)
+!standard 13.6(1)
+!standard 13.8(13)
!standard 13.11.3(1)
!standard 13.11.3(2)
!standard 13.11.3(3)
@@ -24,8 +50,98 @@
!standard 13.11.3(7)
!standard 13.11.3(8)
!standard 13.12.1(4/2)
-!standard B.3.3(4)
+!standard A.1(37)
+!standard A.1(42)
+!standard A.1(42.1/2)
+!standard B.1(1)
+!standard B.1(2)
+!standard B.1(4)
+!standard B.1(5)
+!standard B.1(6)
+!standard B.1(7)
+!standard B.1(9.1/1)
+!standard B.1(10)
+!standard B.1(11)
+!standard B.1(14)
+!standard B.1(21)
+!standard B.3(23)
+!standard B.3(33)
+!standard B.3(34)
+!standard B.3(39.5/2)
+!standard B.3(39.6/2)
+!standard B.3(39.14/2)
+!standard B.3(39.15/2)
+!standard B.3.3(1/2)
+!standard B.3.3(2/2)
+!standard B.3.3(3/2)
+!standard B.3.3(4/2)
+!standard B.3.3(5/2)
+!standard B.3.3(6/2)
+!standard B.3.3(29/2)
+!standard B.4(12)
+!standard B.4(16)
+!standard B.4(20)
+!standard B.4(29)
+!standard B.5(12)
+!standard C.3.1(1)
+!standard C.3.1(2)
+!standard C.3.1(3)
+!standard C.3.1(4)
+!standard C.3.1(5)
+!standard C.3.1(6)
+!standard C.3.1(7/2)
+!standard C.3.1(9)
+!standard C.3.1(10)
+!standard C.3.1(11/2)
+!standard C.3.1(12/1)
+!standard C.3.1(14.1/1)
+!standard C.3.1(17)
+!standard C.3.1(19)
+!standard C.3.1(22)
+!standard C.3.2(17)
+!standard C.3.2(21)
+!standard C.3.2(24)
+!standard C.3.2(28)
+!standard C.6(21)
+!standard D.1(2)
+!standard D.1(3)
+!standard D.1(4)
+!standard D.1(5)
+!standard D.1(6)
+!standard D.1(7)
+!standard D.1(8)
+!standard D.1(13)
+!standard D.1(14)
+!standard D.1(16)
+!standard D.1(17)
+!standard D.1(18)
+!standard D.1(19)
+!standard D.2.6(2/2)
+!standard D.2.6(3/2)
+!standard D.2.6(4/2)
+!standard D.2.6(5/2)
+!standard D.2.6(6/2)
+!standard D.2.6(9/2)
+!standard D.2.6(12/2)
+!standard D.2.6(13/2)
+!standard D.3(6.1/2)
+!standard D.3(8/2)
+!standard D.3(10/2)
+!standard D.3(11/2)
+!standard D.13(5/2)
+!standard D.16(0)
+!standard E.2.3(13)
+!standard E.2.3(16)
+!standard E.2.3(19/1)
+!standard E.4.1(1)
+!standard E.4.1(2)
+!standard E.4.1(3)
+!standard E.4.1(4)
+!standard E.4.1(5)
+!standard E.4.1(6)
+!standard E.4.1(7)
!standard E.4.1(8)
+!standard E.4.1(9)
!standard J.15(0)
!standard J.15.1(0)
!standard J.15.2(0)
@@ -125,7 +241,7 @@
"Aspect Pack" instead, but this seems more meaningful, and more like the inline clause.
Similar comments apply to all of the other clauses that were named "pragma Something".]
-Change "packing" to "Pack" in 13.3(55.e), 13.3(72), 13.3(72.a), 13.1(7.g),
+Change "packing" to "Pack" in 13.3(55.e), 13.3(73), 13.3(73.a), 13.1(7.g),
9.10(1/3), 9.10(1.c), 13.6(1).
[Note: We're only changing uses where "packing is specified" or the like.]
@@ -181,9 +297,9 @@
In B.3(23), delete "pragma Pack" (it is bogus to have both Pack and
Component_Size specified for the same type; Pack is ineffective in that case).
-Add "with Pack" to B.3(33), B.3(39.6/2), and B.3(39.14/2).
+Add "with Pack" to B.3(33), B.3(39.5/2), and B.3(39.14/2).
-Delete B.3(34), B.3(39.7/2), and B.3(39.15/2) [which are just pragma Pack].
+Delete B.3(34), B.3(39.6/2), and B.3(39.15/2) [which are just pragma Pack].
Modify C.6(21):
@@ -280,12 +396,9 @@
defined to be an *unchecked union subtype*. An object of an unchecked union type
is defined to be an *unchecked union object*.
-Modify B.3.3(29/2):
+Delete B.3.3(29/2) (pragma Controlled has been removed).
-An implementation may require that {aspect Controlled is True}[pragma Controlled
-be specified] for the type of an access subcomponent of an unchecked union type.
-
===pragma Discard_Names:
[Editor's note: Can't get make this pragma obsolescent; its use as a
@@ -544,7 +657,31 @@
Delete 6.3.2(7).
+Replace Inline in 2.8(29/2):
+ pragma Pure(Rational_Numbers); -- Set the categorization of package Rational_Numbers (see 7.1)
+
+
+Modify the last sentence of 10.1.4(7/2):
+
+If the given compilation unit
+contains the body of a subprogram {for}[to] which {aspect}[a @fa<pragma>] Inline
+{is True}[applies], the implementation may also remove any compilation unit
+containing a call to that subprogram.
+
+Modify 11.5(7.2/2):
+
+"...to a subprogram {for which aspect}[that has a pragma] Inline {is True}[applied to it],..."
+Modify 11.6(6):
+
+"..., and {for which the}[has no] Inline {aspect is False}[pragma applied to it]. ..."
+
+Modify 13.8(13):
+
+ M : Mask;
+ procedure Set_Mask{
+ with Inline};[ pragma Inline(Set_Mask);]
+
Other pragmas:
===pragma Preelaborable_Initialization (referred to as P_I below)
@@ -577,8 +714,8 @@
[Redundant: This aspect is never inherited;] if not directly specified,
the aspect is False.
Attach_Handler
- The type of aspect Interrupt_Handler is Interrupts.Interrupt_Id.
- [Redundant: This aspect is never inherited.]
+ The value of aspect Attach_Handler is an expression, which shall be of type
+ Interrupts.Interrupt_Id. [Redundant: This aspect is never inherited.]
Delete C.3.1(7/3). [Also in Annex J.]
@@ -598,24 +735,34 @@
C.3.2). [Redundant: Such procedures are allowed to be attached to multiple
interrupts.]
+[Editor's note: We change "can" to "may" to eliminate a banned word in ISO
+standards, here and elsewhere in this clause.]
+
Replace C.3.1(10):
-The value of the Attach_Handler aspect identifies an interrupt. As part of the
-initialization of the associated object, if the Attach_Handler aspect is
-specified, the handler procedure is attached to the specified interrupt. A check
-is made that the corresponding interrupt is not reserved. Program_Error is
-raised if the check fails, and the existing treatment for the interrupt is not
-affected.
+The expression specified for the Attach_Handler aspect of a protected procedure P
+is evaluated as part of the creation of the protected object that contains P.
+The value of the expression identifies an interrupt. As part of the initialization of
+that object, P (the @fa<handler> procedure) is attached to the identified interrupt.
+A check is made that the corresponding interrupt is not reserved. Program_Error is
+raised if the check fails, and the existing treatment for the interrupt is not affected.
Modify C.3.1(11/2):
If the Ceiling_Locking policy (see D.3) is in effect, then upon the
-initialization of a protected object for which either {the}[an] Attach_Handler
-or Interrupt_Handler [pragma applies to]{aspect is specified for} one of its
-procedures, a check is made that the ceiling priority defined in the
-protected_definition is in the range of System.Interrupt_Priority. If the check
-fails, Program_Error is raised.
+initialization of a protected object {that contains a protected procedure}
+for which either {the}[an] Attach_Handler
+{aspect is specified} or {the} Interrupt_Handler [pragma applies to]{aspect is True}[ one of its
+procedures], a check is made that the {initial} ceiling priority {of the
+object (see D.3)}[defined in the protected_definition] is in the range of
+System.Interrupt_Priority. If the check fails, Program_Error is raised.
+
+If the Ceiling_Locking policy (see D.3) is in effect, then upon the initialization of a protected object
+for which either the Attach_Handler aspect is specified or the Interrupt_Handler aspect is True
+for one of its procedures, a check is made that the initial ceiling priority of the object is in the
+range of System.Interrupt_Priority. If the check fails, Program_Error is raised.
+
Modify C.3.1(12/1):
When a protected object is finalized, for any of its procedures that are
@@ -683,7 +830,7 @@
Static Semantics
- For a task type (including the anonymous type of a single_task_definition),
+ For a task type (including the anonymous type of a single_task_declaration),
the following language-defined representation aspect may be specified:
Storage_Size
The value of aspect Storage_Size is an expression, which shall be of
@@ -698,8 +845,8 @@
to not be used for that attribute.
[Editor's note: Task types cannot be derived, so we don't have to worry about
-aspect inheritance, other than from task interfaces (a new possibility). Should
-we make specifying the aspect for those illegal?? The inabilility to derive also
+aspect inheritance, other than from task interfaces (a new possibility). We make
+those illegal (they can't be useful). The inabilility to derive also
means we cannot run afoul of 13.1(10).]
Delete 13.3(62-65) [Now in Annex J.]
@@ -746,8 +893,8 @@
Static Semantics
- For a task type (including the anonymous type of a single_task_definition),
- protected type (including the anonymous type of a single_protected_definition),
+ For a task type (including the anonymous type of a single_task_declaration),
+ protected type (including the anonymous type of a single_protected_declaration),
or subprogram, the following language-defined representation aspects may be
specified:
Priority
@@ -774,7 +921,7 @@
At most one of the Priority and Interrupt_Priority aspects may be specified for
a given entity.
-AARM Ramification: This includes specifying via pragmas (see J.15.7).
+AARM Ramification: This includes specifying via pragmas (see J.15.11).
Neither of the Priority or Interrupt_Priority aspects shall be specified for a
synchronized interface type.
@@ -796,7 +943,7 @@
Modify D.1(16):
The effect of specifying [such a pragma in a protected_definition]{a Priority or
-Interrupt_Priority aspect for a protected type or single_protected_definition}
+Interrupt_Priority aspect for a protected type or single_protected_declaration}
is discussed in D.3.
Modify D.1(17):
@@ -852,7 +999,7 @@
Add after D.2.6(9/2):
- For a task type (including the anonymous type of a single_task_definition)
+ For a task type (including the anonymous type of a single_task_declaration)
or subprogram, the following language-defined representation aspect may be
specified:
Relative_Deadline
@@ -881,10 +1028,11 @@
Relative_Deadline {is specified} is the value of Real_Time.Clock +
[relative_deadline_]expression{ that is the value of the aspect}, where {this
entire expression, including }the call of Real_Time.Clock{, is evaluated}
-[is made] between task creation and the start of its activation. If there is no
-Relative_Deadline pragma then the initial absolute
-deadline of a task is the value of Default_Deadline. [Redundant: The
-environment task is also given an initial deadline by this rule.]
+[is made] between task creation and the start of its activation. If {the aspect}
+[there is no] Relative_Deadline {is not specified}[pragma] then the initial absolute
+deadline of a task is the value of Default_Deadline. The
+environment task is also given an initial deadline by this rule{, using the
+value of the Relative_Deadline aspect of the main subprogram (if any)}.
[Editor's note: The original wording did not specify when the deadline
expression is evaluated. Since it is per-object, it also has to be evaluated
@@ -898,7 +1046,7 @@
Static Semantics
- For a task type (including the anonymous type of a single_task_definition) or
+ For a task type (including the anonymous type of a single_task_declaration) or
subprogram, the following language-defined representation aspect may be specified:
CPU
The value of aspect CPU is an expression, which shall be of
@@ -1033,7 +1181,7 @@
The implementation permits T as an L-compatible type.
- If a Convention aspect is specified for a type, then the type shall
+ If the Convention aspect is specified for a type, then the type shall
either be compatible with or eligible for the specified convention.
Notwithstanding any rule to the contrary, a declaration with a True
@@ -1385,7 +1533,7 @@
The external_name_string_expression and link_name_string_expression of a pragma Import
or Export shall be static.
-The local_name of of each of these pragmas shall denote a declaration that may have
+The local_name of each of these pragmas shall denote a declaration that may have
the similarly named aspect specified.
Static Semantics
@@ -1528,7 +1676,7 @@
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_definition that contains the pragma; otherwise, the expression is
+single_task_declaration that contains the pragma; otherwise, the expression is
associated with the aspect for the subprogram that contains the pragma.
[Editor's note: J.15.10 is in AI05-0167-1.]
@@ -1568,10 +1716,10 @@
value of the Priority aspect (see D.1) and a pragma Interrupt_Priority specifies
the value of the Interrupt_Priority aspect as follows:
* If the pragma appears in a task_definition, the expression is associated with
- the aspect for the task type or single_task_definition that contains the
+ the aspect for the task type or single_task_declaration that contains the
pragma;
* If the pragma appears in a protected_definition, the expression is associated
- with the aspect for the protected type or single_protected_definition that
+ with the aspect for the protected type or single_protected_declaration that
contains the pragma;
* 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
@@ -1602,7 +1750,7 @@
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_definition that contains the pragma; otherwise, the
+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.
@@ -1848,6 +1996,39 @@
Therefore, we decided to drop this pragma completely (rather than turn it into
an aspect).
+
+!corrigendum 2.8(29/2)
+
+@drepl
+@xcode<@b<pragma> List(Off); --@ft<@i< turn off listing generation>>
+@b<pragma> Optimize(Off); --@ft<@i< turn off optional optimizations>>
+@b<pragma> Inline(Set_Mask); --@ft<@i< generate code for Set_Mask inline>>
+@b<pragma> Import(C, Put_Char, External_Name =@> "putchar"); --@ft<@i< import C putchar function>>>
+@dby
+@xcode<@b<pragma> List(Off); --@ft<@i< turn off listing generation>>
+@b<pragma> Optimize(Off); --@ft<@i< turn off optional optimizations>>
+@b<pragma> Pure(Rational_Numbers); --@ft<@i< set categorization for package>>
+@b<pragma> Assert(Exists(File_Name), Message => "Nonexistent file"); --@ft<@i< assert file exists>>>
+
+
+!corrigendum 3.7(37/2)
+
+@drepl
+@xcode<@b<task type> Worker(Prio : System.Priority; Buf : @b<access> Buffer) @b<is>
+ --@ft<@i< discriminants used to parameterize the task type (see 9.1)>>
+ @b<pragma> Priority(Prio); --@ft<@i< see D.1>>
+ @b<entry> Fill;
+ @b<entry> Drain;
+@b<end> Worker;>
+@dby
+@xcode<@b<task type> Worker(Prio : System.Priority; Buf : @b<access> Buffer)
+ @b<with> Priority => Prio @b<is> --@ft<@i< see D.1>>
+ --@ft<@i< discriminants used to parameterize the task type (see 9.1)>>
+ @b<entry> Fill;
+ @b<entry> Drain;
+@b<end> Worker;>
+
+
!corrigendum 4.8(15)
@drepl
@@ -1856,6 +2037,7 @@
@dby
@s9<27 Implementations are permitted, but not required, to provide garbage collection.>
+
!corrigendum 6.3.2(2)
@ddel
@@ -1864,7 +2046,7 @@
!corrigendum 6.3.2(3)
@ddel
-@xindent<@b<pragma> Inline(@fa<name> {, @fa<name>});>
+@xcode<@ft<@b<pragma> Inline(@fa<name> {, @fa<name>});>>
!corrigendum 6.3.2(4)
@@ -1913,6 +2095,14 @@
The @fa<name> in a @fa<pragma> Inline can denote more than one entity in the case of
overloading. Such a @fa<pragma> applies to all of the denoted entities.>
+
+!corrigendum 6.5.1(0)
+
+@drepl
+Pragma No_Return
+@dby
+Non-returning Procedures
+
!corrigendum 6.5.1(1/2)
@drepl
@@ -1932,7 +2122,7 @@
!corrigendum 6.5.1(3/2)
@drepl
-@xindent<@b<pragma> No_Return(@i<procedure_>@fa<local_name>{, @i<procedure_>@fa<local_name>});>
+@xcode<@ft<@b<pragma> No_Return(@i<procedure_>@fa<local_name>{, @i<procedure_>@fa<local_name>});>>
@dby
@s8<@i<Static Semantics>>
@@ -1977,88 +2167,861 @@
@xcode<@b<procedure> Fail(Msg : String) --@ft<@i< raises Fatal_Error exception>>
@b<with> No_Return =@> True;
--@ft<@i< Inform compiler and reader that procedure never returns normally>>>
+
+!corrigendum 9.10(1)
+!comment This contains the AI-0009-1 and AI-0201-1 changes as well.
+
+@drepl
+If two different objects, including nonoverlapping parts of the same
+object, are @i<independently addressable>, they can be manipulated
+concurrently by two different tasks without synchronization. Normally,
+any two nonoverlapping objects are independently addressable. However,
+if packing, record layout, or Component_Size is specified for a given
+composite object, then it is implementation defined whether or not two
+nonoverlapping parts of that composite object are independently
+addressable.
+@dby
+If two different objects, including nonoverlapping parts of the same
+object, are @i<independently addressable>, they can be manipulated
+concurrently by two different tasks without synchronization.
+Any two nonoverlapping objects are independently addressable if
+either object is specified as independently addressable (see C.6). Otherwise,
+two nonoverlapping objects are independently addressable
+except when they are both parts of a composite object for which
+a non-confirming representation item is used to specify
+record layout, Component_Size, Pack, Atomic, or convention, in which case
+it is unspecified whether the parts are independently addressable.
+
+
+!corrigendum 10.1.4(7/2)
+
+@drepl
+When a compilation unit that declares or renames a library unit is added to the
+environment, the implementation may remove from the environment any preexisting
+@fa<library_item> or @fa<subunit> with the same full expanded name. When a
+compilation unit that is a subunit or the body of a library unit is added to
+the environment, the implementation may remove from the environment any
+preexisting version of the same compilation unit. When a compilation unit that
+contains a @fa<body_stub> is added to the environment, the implementation may
+remove any preexisting @fa<library_item> or @fa<subunit> with the same full
+expanded name as the @fa<body_stub>. When a given compilation unit is removed
+from the environment, the implementation may also remove any compilation unit
+that depends semantically upon the given one. If the given compilation unit
+contains the body of a subprogram to which a @fa<pragma> Inline applies, the
+implementation may also remove any compilation unit containing a call to that
+subprogram.
+@dby
+When a compilation unit that declares or renames a library unit is added to the
+environment, the implementation may remove from the environment any preexisting
+@fa<library_item> or @fa<subunit> with the same full expanded name. When a
+compilation unit that is a subunit or the body of a library unit is added to
+the environment, the implementation may remove from the environment any
+preexisting version of the same compilation unit. When a compilation unit that
+contains a @fa<body_stub> is added to the environment, the implementation may
+remove any preexisting @fa<library_item> or @fa<subunit> with the same full
+expanded name as the @fa<body_stub>. When a given compilation unit is removed
+from the environment, the implementation may also remove any compilation unit
+that depends semantically upon the given one. If the given compilation unit
+contains the body of a subprogram for which aspect Inline is True, the
+implementation may also remove any compilation unit containing a call to that
+subprogram.
+
+!corrigendum 10.2(15)
+
+@drepl
+@xbullet<Any included @fa<library_unit_declaration> to which a @fa<pragma> Elaborate_Body
+applies is immediately followed by its @fa<library_unit_body>, if included.>
+@dby
+@xbullet<Any included @fa<library_unit_declaration> for which aspect Elaborate_Body is True
+(including when a @fa<pragma> Elaborate_Body applies) is immediately followed by its
+@fa<library_unit_body>, if included.>
+
+
+!corrigendum 10.2.1(25)
+
+@drepl
+If a @fa<pragma> Elaborate_Body applies to a declaration, then the declaration requires
+a completion (a body).
+@dby
+If the aspect Elaborate_Body is True for a declaration (including when @fa<pragma>
+Elaborate_Body applies), then the declaration requires a completion (a body).
+
+!corrigendum 10.2.1(26)
+
+@drepl
+A @fa<pragma> Elaborate specifies that the body of the named library unit is elaborated
+before the current @fa<library_item>. A @fa<pragma> Elaborate_All specifies that each @fa<library_item>
+that is needed by the named library unit declaration is elaborated before the current @fa<library_item>.
+A @fa<pragma> Elaborate_Body specifies that the body of the library unit is elaborated immediately after
+its declaration.
+@dby
+A @fa<pragma> Elaborate specifies that the body of the named library unit is elaborated
+before the current @fa<library_item>. A @fa<pragma> Elaborate_All specifies that each @fa<library_item>
+that is needed by the named library unit declaration is elaborated before the current @fa<library_item>.
+
+A @fa<pragma> Elaborate_Body sets the Elaborate_Body representation aspect of the
+library unit to which it applies to the value True. If the Elaborate_Body aspect
+of a library unit is True, the body of the library unit is elaborated
+immediately after its declaration.
+
+
+!corrigendum 11.4.1(4/2)
+
+@drepl
+@xcode< @b<procedure> Raise_Exception(E : @b<in> Exception_Id;
+ Message : @b<in> String := "");
+ @b<pragma> No_Return(Raise_Exception);
+ @b<function> Exception_Message(X : Exception_Occurrence) @b<return> String;
+ @b<procedure> Reraise_Occurrence(X : @b<in> Exception_Occurrence);>
+@dby
+@xcode< @b<procedure> Raise_Exception(E : @b<in> Exception_Id;
+ Message : @b<in> String := "")
+ @b<with> No_Return =@> True;
+ @b<function> Exception_Message(X : Exception_Occurrence) @b<return> String;
+ @b<procedure> Reraise_Occurrence(X : @b<in> Exception_Occurrence);>
+
+!corrigendum 11.5(7.2/2)
+
+@drepl
+If a checking pragma applies to a generic instantiation, then the checking
+pragma also applies to the instance. If a checking pragma applies to a call to
+a subprogram that has a @fa<pragma> Inline applied to it, then the checking
+pragma also applies to the inlined subprogram body.
+@dby
+If a checking pragma applies to a generic instantiation, then the checking
+pragma also applies to the instance. If a checking pragma applies to a call to
+a subprogram for which aspect Inline is True, then the checking
+pragma also applies to the inlined subprogram body.
+
+!corrigendum 11.6(6)
+
+@drepl
+If an exception is raised due to the failure of a language-defined check, then upon
+reaching the corresponding @fa<exception_handler> (or the termination of the task,
+if none), the external interactions that have occurred need reflect only that the
+exception was raised somewhere within the execution of the @nt<sequence_of_statements>
+with the handler (or the @fa<task_body>), possibly earlier (or later if the interactions
+are independent of the result of the checked operation) than that defined by the canonical
+semantics, but not within the execution of some abort-deferred operation or @i<independent>
+subprogram that does not dynamically enclose the execution of the construct whose check failed.
+An independent subprogram is one that is defined outside the library unit containing the
+construct whose check failed, and has no Inline pragma applied to it. Any assignment that
+occurred outside of such abort-deferred operations or independent subprograms can be
+disrupted by the raising of the exception, causing the object or its parts to become
+abnormal, and certain subsequent uses of the object to be erroneous, as explained in 13.9.1.
+@dby
+If an exception is raised due to the failure of a language-defined check, then upon
+reaching the corresponding @fa<exception_handler> (or the termination of the task,
+if none), the external interactions that have occurred need reflect only that the
+exception was raised somewhere within the execution of the @nt<sequence_of_statements>
+with the handler (or the @fa<task_body>), possibly earlier (or later if the interactions
+are independent of the result of the checked operation) than that defined by the canonical
+semantics, but not within the execution of some abort-deferred operation or @i<independent>
+subprogram that does not dynamically enclose the execution of the construct whose check failed.
+An independent subprogram is one that is defined outside the library unit containing the
+construct whose check failed, and for which the Inline aspect is False. Any assignment that
+occurred outside of such abort-deferred operations or independent subprograms can be
+disrupted by the raising of the exception, causing the object or its parts to become
+abnormal, and certain subsequent uses of the object to be erroneous, as explained in 13.9.1.
+
+
+!corrigendum 13.2(0)
+
+@drepl
+Pragma Pack
+@dby
+Packed Types
+
+!corrigendum 13.2(1)
+
+@drepl
+A @fa<pragma> Pack specifies that storage
+minimization should be the main criterion when
+selecting the representation of a composite type.
+@dby
+The Pack aspect having the value True specifies that storage minimization
+should be the main criterion when selecting the representation of a composite type.
+
+!corrigendum 13.2(2)
+
+@ddel
+The form of a @fa<pragma> Pack is as follows:
+
+!corrigendum 13.2(3)
+
+@ddel
+@xcode<@ft<@b<pragma> Pack(@i<first_subtype_>@fa<local_name>);>>
+
+!corrigendum 13.2(4)
+
+@ddel
+The @i<first_subtype_>@fa<local_name> of a @fa<pragma> Pack shall denote a
+composite subtype.
+
+!comment %% 13.2(5) and 13.2(7) need changes here.
+
+!corrigendum 13.3(38)
+
+@drepl
+@s9<5 A @fa<component_clause>, Component_Size clause, or a @fa<pragma> Pack can override a
+specified Alignment.>
+@dby
+@s9<5 A @fa<component_clause>, Component_Size clause, or specifying the Pack aspect to True
+can override a specified Alignment.>
+
+!corrigendum 13.3(58)
+
+@drepl
+@s9<7 A @fa<component_clause> or Component_Size clause can override a specified Size.
+A @fa<pragma> Pack cannot.>
+@dby
+@s9<7 A @fa<component_clause> or Component_Size clause can override a specified Size.
+Aspect Pack cannot.>
+
+!comment %% 13.3(60), 13.3(61), 13.3(62), 13.3(63), and 13.3(64) need changes here.
+
+!corrigendum 13.3(65)
+
+@drepl
+@s8<@i<Name Resolution Rules>>
+
+The @fa<expression> of a @fa<pragma> Storage_Size
+is expected to be of any integer type.
+@dby
+@s8<@i<Static Semantics>>
+
+For a task type (including the anonymous type of a @fa<single_task_declaration>),
+the following language-defined representation aspect may be specified:
+
+@xhang<@xTerm<Storage_Size>
+The value of aspect Storage_Size is an @fa<expression>, which shall be of
+any integer type.>
+
+@s8<@i<Legality Rules>>
+
+The Storage_Size aspect shall not be specified for a task interface type.
+
+!corrigendum 13.3(66)
+
+@drepl
+A @fa<pragma> Storage_Size is elaborated when an object of the type defined by the
+immediately enclosing @fa<task_definition> is created. For the elaboration of a
+@fa<pragma> Storage_Size, the @fa<expression> is evaluated; the Storage_Size attribute
+of the newly created task object is at least the value of the @fa<expression>.
+@dby
+
+
+!corrigendum 13.3(73)
+
+@drepl
+@xbullet<An implementation should support specified Component_Sizes that are factors
+and multiples of the word size. For such Component_Sizes, the array should contain
+no gaps between components. For other Component_Sizes (if supported), the array should
+contain no gaps between components when packing is also specified; the implementation
+should forbid this combination in cases where it cannot support a no-gaps representation.>
+@dby
+@xbullet<An implementation should support specified Component_Sizes that are factors
+and multiples of the word size. For such Component_Sizes, the array should contain
+no gaps between components. For other Component_Sizes (if supported), the array should
+contain no gaps between components when Pack is also specified; the implementation
+should forbid this combination in cases where it cannot support a no-gaps representation.>
+
+
+!corrigendum 13.3.1(0)
+
+@dinsc
+
+Force a conflict; the real text is found in the conflict file.
+
+
+!corrigendum 13.6(1)
+
+@drepl
+A @fa<type_conversion> (see 4.6) can be used to convert between two different
+representations of the same array or record. To convert an array from one
+representation to another, two array types need to be declared with matching
+component subtypes, and convertible index types. If one type has packing specified
+and the other does not, then explicit conversion can be used to pack or unpack an array.
+@dby
+A @fa<type_conversion> (see 4.6) can be used to convert between two different
+representations of the same array or record. To convert an array from one
+representation to another, two array types need to be declared with matching
+component subtypes, and convertible index types. If one type has Pack specified
+and the other does not, then explicit conversion can be used to pack or unpack an array.
+
+
+
+!corrigendum 13.8(13)
+
+@drepl
+@xcode<M : Mask;
+@b<procedure> Set_Mask; @b<pragma> Inline(Set_Mask);>
+@dby
+@xcode<M : Mask;
+@b<procedure> Set_Mask
+ @b<with> Inline;>
+
+!corrigendum 13.11.3(1)
+
+@ddel
+Pragma Controlled is used to prevent any automatic reclamation of storage (garbage
+collection) for the objects created by @fa<allocator>s of a given access type.
+
+!corrigendum 13.11.3(2)
+
+@ddel
+@xindent<The form of a pragma Controlled is as follows:>
+
+!corrigendum 13.11.3(3)
+
+@ddel
+@xcode<@ft<@b<pragma> Controlled(@i<first_subtype_>@fa<local_name>)>>
+
+!corrigendum 13.11.3(4)
+
+@ddel
+The @i<first_subtype_>@fa<local_name> of a @fa<pragma> Controlled shall denote a
+non-derived access subtype.
+
+!corrigendum 13.11.3(5)
+
+@ddel
+A @fa<pragma> Controlled is a representation pragma that specifies the controlled
+aspect of representation.
+
+!corrigendum 13.11.3(6)
+
+@ddel
+@i<Garbage collection> is a process that automatically reclaims storage, or moves
+objects to a different address, while the objects still exist.
+
+!corrigendum 13.11.3(7)
+
+@ddel
+If a @fa<pragma> Controlled is specified for an access type with a standard storage pool,
+then garbage collection is not performed for objects in that pool.
+
+!corrigendum 13.11.3(8)
+
+@ddel
+An implementation need not support garbage collection, in which case, a pragma Controlled
+has no effect.
+
+!corrigendum 13.12.1(4/2)
+
+@drepl
+@xhang<@xterm<No_Obsolescent_Features>
+There is no use of language features defined in Annex J. It is
+implementation defined whether uses of the renamings of J.1 are detected by this
+restriction. This restriction applies only to the current compilation or
+environment, not the entire partition.>
+@dby
+@xhang<@xterm<No_Obsolescent_Features>
+There is no use of language features defined in Annex J. It is
+implementation defined whether uses of the renamings of J.1 and of the @fa<pragma>s of
+J.15 are detected by this restriction. This restriction applies only to the current
+compilation or environment, not the entire partition.>
+
+!comment %% A.1(37), A.1(42), and A.1(42.1/2) need changes here.
+
+!corrigendum B.1(0)
+
+@drepl
+Interfacing Pragmas
+@dby
+Interfacing Aspects
+
+!corrigendum B.1(1)
+
+@drepl
+A @fa<pragma> Import is used to import an entity defined in a foreign language into an Ada
+program, thus allowing a foreign-language subprogram to be called from Ada, or a foreign-language
+variable to be accessed from Ada. In contrast, a @fa<pragma> Export is used to export an
+Ada entity to a foreign language, thus allowing an Ada subprogram to be called from a foreign
+language, or an Ada object to be accessed from a foreign language. The @fa<pragma>s
+Import and Export are intended primarily for objects and subprograms, although implementations
+are allowed to support other entities.
+@dby
+An @i<interfacing> aspect is a representation aspect that is one of the
+aspects Import, Export, Link_Name, External_Name, or Convention.
+
+Specifying aspect Import to have the value True is used to import
+an entity defined in a foreign language into an Ada program, thus
+allowing a foreign-language subprogram to be called from Ada, or a
+foreign-language variable to be accessed from Ada. In contrast, specifying
+aspect Export to have the value True is used to export an Ada entity to a
+foreign language, thus allowing an Ada subprogram to be called from a
+foreign language, or an Ada object to be accessed from a foreign
+language. The Import and Export aspects are intended primarily for
+objects and subprograms, although implementations are allowed to
+support other entities. The Link_Name and External_Name aspects are
+used to specify the link name and external name, respectively, to be
+used to identify imported or exported entities in the external
+environment.
+
+!corrigendum B.1(2)
+
+@drepl
+A @fa<pragma> Convention is used to specify that an Ada entity should use the conventions of another
+language. It is intended primarily for types and "callback" subprograms. For example, "@b<pragma>
+Convention(Fortran, Matrix);" implies that Matrix should be represented according to the
+conventions of the supported Fortran implementation, namely column-major order.
+@dby
+The Convention aspect is used to indicate that an Ada entity should
+use the conventions of another language. It is intended primarily for
+types and "callback" subprograms. For example, "@b<with> Convention =@>
+Fortran" on the declaration of an array type Matrix implies that
+Matrix should be represented according to the conventions of the
+supported Fortran implementation, namely column-major order.
+
+!comment %% B.1(4), B.1(5), B.1(6), B.1(7) and B.1(9.1/1) need changes here.
+
+!corrigendum B.1(10)
+
+@drepl
+The expected type for a @i<string_>@fa<expression> in an interfacing pragma
+or in pragma Linker_Options is String.
+@dby
+The Import and Export aspects are of type Boolean.
+
+The Link_Name and External_Name aspects are of type String.
+
+The expected type for the @i<string_>@fa<expression> in pragma Linker_Options, is
+String.
+
+!comment %% B.1(11), B.1(14), and B.1(21) need changes here.
+
+!comment %% More B.1(xx) need changes here.
+
+
+!comment %% B.3(23), B.3(33), B.3(34), B.3(39.5/2), B.3(39.6/2), B.3(39.14/2), and B.3(39.15/2) need changes here.
+
+
+!corrigendum B.3.3(0)
+
+@drepl
+Pragma Unchecked_Union
+@dby
+Unchecked Union Types
+
+!comment %% B.3.3(1/2), B.3.3(2/2), B.3.3(3/2), B.3.3(4/2), B.3.3(5/2), and B.3.3(6/2) need changes here.
+
+!corrigendum B.3.3(29/2)
+
+@ddel
+An implementation may require that @fa<pragma> Controlled
+be specified for the type of an access subcomponent of an unchecked union type.
+
+
+!comment %% B.4(12), B.4(16), B.4(20), and B.4(29) need changes here.
+
+!comment %% B.5(12) needs changes here.
+
+!comment %% C.3.1(1), C.3.1(2), C.3.1(3), C.3.1(4), C.3.1(5), and C.3.1(6) need changes here.
+
+!corrigendum C.3.1(7/2)
+
+@drepl
+The Attach_Handler pragma is only allowed immediately within the @fa<protected_definition>
+where the corresponding subprogram is declared. The corresponding
+@fa<protected_type_declaration> or @fa<single_protected_declaration> shall be a
+library-level declaration.
+@dby
+If either the Attach_Hander or Interrupt_Handler aspect are specifed for a
+protected procedure, the corresponding
+@fa<protected_type_declaration> or @fa<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), this
+rule also applies in the private part of an instance of a generic unit.
+
+!corrigendum C.3.1(9)
+
+@drepl
+If the pragma Interrupt_Handler appears in a @fa<protected_definition>, then the corresponding procedure can
+be attached dynamically, as a handler, to interrupts (see C.3.2). Such procedures are allowed to be attached
+to multiple interrupts.
+@dby
+If the Interrupt_Handler aspect of a protected procedure is True,
+then the procedure may be attached dynamically, as a handler, to interrupts (see
+C.3.2). Such procedures are allowed to be attached to multiple
+interrupts.
+
+!corrigendum C.3.1(10)
+
+@drepl
+The @fa<expression> in the Attach_Handler pragma as evaluated at object creation time specifies an interrupt.
+As part of the initialization of that object, if the Attach_Handler pragma is specified, the @i<handler>
+procedure is attached to the specified interrupt. A check is made that the corresponding interrupt
+is not reserved. Program_Error is raised if the check fails, and the existing treatment for the
+interrupt is not affected.
+@dby
+The @fa<expression> specified for the Attach_Handler aspect of a protected procedure @i<P>
+is evaluated as part of the creation of the protected object that contains @i<P>.
+The value of the @fa<expression> identifies an interrupt. As part of the initialization
+of that object, @i<P> (the @fa<handler> procedure) is attached to the
+identified interrupt. A check is made that the corresponding interrupt is not reserved.
+Program_Error is raised if the check fails, and the existing treatment for the interrupt is not
+affected.
+
+!corrigendum C.3.1(11/2)
+
+@drepl
+If the Ceiling_Locking policy (see D.3) is in effect, then upon the initialization of a protected object
+for which that either an Attach_Handler or Interrupt_Handler pragma applies to one of its procedures,
+a check is made that the ceiling priority defined in the @fa<protected_definition> is in the range of
+System.Interrupt_Priority. If the check fails, Program_Error is raised.
+@dby
+If the Ceiling_Locking policy (see D.3) is in effect, then upon the initialization of a protected object
+that contains a protected procedure for which either the Attach_Handler aspect is specified or
+the Interrupt_Handler aspect is True, a check is made that the initial ceiling priority of the object
+is in the range of System.Interrupt_Priority. If the check fails, Program_Error is raised.
+
+!corrigendum C.3.1(12/1)
+
+@drepl
+When a protected object is finalized, for any of its procedures that are attached to interrupts,
+the handler is detached. If the handler was attached by a procedure in the Interrupts package
+or if no user handler was previously attached to the interrupt, the default treatment is restored.
+If an Attach_Handler pragma was used and the most recently attached handler for the same interrupt
+is the same as the one that was attached at the time the protected object was initialized,
+the previous handler is restored.
+@dby
+When a protected object is finalized, for any of its procedures that are attached to interrupts,
+the handler is detached. If the handler was attached by a procedure in the Interrupts package
+or if no user handler was previously attached to the interrupt, the default treatment is restored.
+If the Attach_Handler aspect was specified and the most recently attached handler for the same interrupt
+is the same as the one that was attached at the time the protected object was initialized,
+the previous handler is restored.
+
+!corrigendum C.3.1(14.1/1)
+
+@drepl
+If the handlers for a given interrupt attached via pragma Attach_Handler are not attached and
+detached in a stack-like (LIFO) order, program execution is erroneous. In particular, when
+a protected object is finalized, the execution is erroneous if any of the procedures of the
+protected object are attached to interrupts via pragma Attach_Handler and the most recently
+attached handler for the same interrupt is not the same as the one that was attached at the time
+the protected object was initialized.
+@dby
+If the handlers for a given interrupt attached via aspect Attach_Handler are not attached and
+detached in a stack-like (LIFO) order, program execution is erroneous. In particular, when
+a protected object is finalized, the execution is erroneous if any of the procedures of the
+protected object are attached to interrupts via aspect Attach_Handler and the most recently
+attached handler for the same interrupt is not the same as the one that was attached at the time
+the protected object was initialized.
+
+!corrigendum C.3.1(17)
+
+@drepl
+When the pragmas Attach_Handler or Interrupt_Handler apply to a protected procedure, the
+implementation is allowed to impose implementation-defined restrictions on the corresponding
+@fa<protected_type_declaration> and @fa<protected_body>.
+@dby
+When the aspects Attach_Handler or Interrupt_Handler are specified for a protected procedure, the
+implementation is allowed to impose implementation-defined restrictions on the corresponding
+@fa<protected_type_declaration> and @fa<protected_body>.
+
+!corrigendum C.3.1(19)
+
+@drepl
+Notwithstanding what this subclause says elsewhere, the Attach_Handler and Interrupt_Handler
+pragmas are allowed to be used for other, implementation defined, forms of interrupt handlers.
+@dby
+Notwithstanding what this subclause says elsewhere, the Attach_Handler and Interrupt_Handler
+aspects are allowed to be used for other, implementation defined, forms of interrupt handlers.
+
+!corrigendum C.3.1(22)
+
+@drepl
+@s9<4 The Attach_Handler pragma can provide static attachment of handlers to interrupts
+if the implementation supports preelaboration of protected objects. (See C.4.)>
+@dby
+@s9<4 The Attach_Handler aspect may provide static attachment of handlers to interrupts
+if the implementation supports preelaboration of protected objects. (See C.4.)>
+
+!corrigendum C.3.2(17)
+
+@drepl
+The Attach_Handler procedure attaches the specified handler to the interrupt, overriding any
+existing treatment (including a user handler) in effect for that interrupt. If New_Handler is
+null, the default treatment is restored. If New_Handler designates a protected procedure to
+which the pragma Interrupt_Handler does not apply, Program_Error is raised. In this case, the
+operation does not modify the existing interrupt treatment.
+@dby
+The Attach_Handler procedure attaches the specified handler to the interrupt, overriding any
+existing treatment (including a user handler) in effect for that interrupt. If New_Handler is
+null, the default treatment is restored. If New_Handler designates a protected procedure for
+which the aspect Interrupt_Handler is False, Program_Error is raised. In this case, the
+operation does not modify the existing interrupt treatment.
+
+!corrigendum C.3.2(21)
+
+@drepl
+If, by using the Attach_Handler, Detach_Handler, or Exchange_Handler procedures, an attempt
+is made to detach a handler that was attached statically (using the pragma Attach_Handler),
+the handler is not detached and Program_Error is raised.
+@dby
+If, by using the Attach_Handler, Detach_Handler, or Exchange_Handler procedures, an attempt
+is made to detach a handler that was attached statically (using the aspect Attach_Handler),
+the handler is not detached and Program_Error is raised.
+
+!corrigendum C.3.2(24)
+
+@drepl
+If the Ceiling_Locking policy (see D.3) is in effect, the implementation shall document the
+default ceiling priority assigned to a protected object that contains either the Attach_Handler
+or Interrupt_Handler pragmas, but not the Interrupt_Priority pragma. This default need not be
+the same for all interrupts.
+@dby
+If the Ceiling_Locking policy (see D.3) is in effect, the implementation shall document the
+default ceiling priority assigned to a protected object that contains a protected procedures
+that specifies either the Attach_Handler
+or Interrupt_Handler aspects, but does not specify the Interrupt_Priority aspect. This default
+need not be the same for all interrupts.
+
+!comment %% C.3.2(28) needs changes here.
+
+
+!comment %% C.6(21) needs changes here.
+
+
+!comment %% D.1(2), D.1(3), D.1(4), D.1(5), D.1(6), and D.1(7) need changes here.
+
+!corrigendum D.1(8)
+
+@drepl
+For a Priority pragma that appears in the @fa<declarative_part> of a @fa<subprogram_body>,
+the @fa<expression> shall be static, and its value shall be in the range of System.Priority.
+@dby
+If the Priority aspect is specified for a subprogram, the @fa<expression> shall be
+static, and its value shall be in the range of System.Priority.
+
+At most one of the Priority and Interrupt_Priority aspects may be specified for
+a given entity.
+
+Neither of the Priority or Interrupt_Priority aspects shall be specified for a
+synchronized interface type.
+
+!corrigendum D.1(13)
+
+@ddel
+The priority specified by a Priority or Interrupt_Priority pragma is the value of the @fa<expression>
+in the pragma, if any. If there is no @fa<expression> in an Interrupt_Priority pragma,
+the priority value is Interrupt_Priority'Last.
+
+!comment %% D.1(14), D.1(16), D.1(17), D.1(18), and D.1(19) need changes here.
+
+
+!comment %% D.2.6(2/2), D.2.6(3/2), D.2.6(4/2), D.2.6(5/2), D.2.6(6/2), and D.2.6(9/2) need changes here.
+
+!corrigendum D.2.6(12/2)
+
+@drepl
+A Relative_Deadline pragma has no effect if it occurs in the @fa<declarative_part>
+of the @fa<subprogram_body> of a subprogram other than the main subprogram.
+@dby
+The Relative_Deadline aspect has no effect if it is specified for a subprogram
+other than the main subprogram.
+
+!corrigendum D.2.6(13/2)
+
+@drepl
+The initial absolute deadline of a task containing pragma Relative_Deadline is the value of
+Real_Time.Clock + @i<relative_deadline_>@fa<expression>, where the call of Real_Time.Clock
+is made between task creation and the start of its activation. If there is no
+Relative_Deadline pragma then the initial absolute deadline of a task is the value of
+Default_Deadline. The environment task is also given an initial deadline by this rule.
+@dby
+The initial absolute deadline of a task for which aspect Relative_Deadline is specified
+is the value of Real_Time.Clock + the @fa<expression> that is the value of the aspect,
+where this entire expression, including the call of Real_Time.Clock, is evaluated
+between task creation and the start of its activation. If the aspect Relative_Deadline
+is not specified then the initial absolute deadline of a task is the value of
+Default_Deadline. The environment task is also given an initial deadline by this rule,
+using the value of the Relative_Deadline aspect of the main subprogram (if any).
+
+
+!corrigendum D.3(6.1/2)
+
+@drepl
+The @fa<expression> of a Priority or Interrupt_Priority pragma (see D.1) is
+evaluated as part of the creation of the corresponding protected object and
+converted to the subtype System.Any_Priority or System.Interrupt_Priority,
+respectively. The value of the expression is the initial priority of the
+corresponding protected object. If no Priority or Interrupt_Priority pragma
+applies to a protected object, the initial priority is specified by the locking
+policy.
+@dby
+The @fa<expression> specified for the Priority or Interrupt_Priority aspect (see
+D.1) is evaluated as part of the creation of the corresponding protected object
+and converted to the subtype System.Any_Priority or System.Interrupt_Priority,
+respectively. The value of the expression is the initial priority of the
+corresponding protected object. If no Priority or Interrupt_Priority aspect is
+specified for a protected object, the initial priority is specified by
+the locking policy.
+
+!corrigendum D.3(8/2)
+
+@drepl
+@xbullet<Every protected object has a @i<ceiling priority>, which is determined by either
+a Priority or Interrupt_Priority pragma as defined in D.1, or by assignment to the
+Priority attribute as described in D.5.2. The ceiling priority of a protected object
+(or ceiling, for short) is an upper bound on the active priority a task can have when
+it calls protected operations of that protected object.>
+@dby
+@xbullet<Every protected object has a @i<ceiling priority>, which is determined by either
+a Priority or Interrupt_Priority aspect as defined in D.1, or by assignment to the
+Priority attribute as described in D.5.2. The ceiling priority of a protected object
+(or ceiling, for short) is an upper bound on the active priority a task can have when
+it calls protected operations of that protected object.>
+
+!corrigendum D.3(10/2)
+
+@drepl
+@xbullet<If an Interrupt_Handler or Attach_Handler pragma (see C.3.1) appears in a
+@fa<protected_definition> without an Interrupt_Priority pragma, the initial priority
+of protected objects of that type is implementation defined, but in the range of the
+subtype System.Interrupt_Priority.>
+@dby
+@xbullet<If an Interrupt_Handler or Attach_Handler aspect (see C.3.1) is specified
+for a protected subprogram of a protected type that does not have the Interrupt_Priority
+aspect specified, the initial priority of protected objects of that type is
+implementation defined, but in the range of the subtype System.Interrupt_Priority.>
+
+!corrigendum D.3(11/2)
+
+@drepl
+@xbullet<If no pragma Priority, Interrupt_Priority, Interrupt_Handler, or Attach_Handler
+is specified in the @fa<protected_definition>, then the initial priority of the corresponding
+protected object is System.Priority'Last.>
+@dby
+@xbullet<If neither aspect Priority nor Interrupt_Priority is specified for a protected
+type, and no protected subprogram of the type has aspect Interrupt_Handler or
+Attach_Handler specified, then the initial priority of the corresponding
+protected object is System.Priority'Last.>
+
+!corrigendum D.13(5/2)
+
+@drepl
+Force a conflict;
+@dby
+the real text is found in the conflict file.
+
+
+!corrigendum D.16(0)
+
+@dinsc
+
+Force a conflict; the real text is found in the conflict file.
-!corrigendum 11.4.1(4/2)
+
+!corrigendum E.2.3(13/1)
@drepl
-@xcode< @b<procedure> Raise_Exception(E : @b<in> Exception_Id;
- Message : @b<in> String := "");
- @b<pragma> No_Return(Raise_Exception);
- @b<function> Exception_Message(X : Exception_Occurrence) @b<return> String;
- @b<procedure> Reraise_Occurrence(X : @b<in> Exception_Occurrence);>
+@xbullet<it shall not be, nor shall its visible part contain, the declaration of a subprogram
+to which a pragma Inline applies;>
@dby
-@xcode< @b<procedure> Raise_Exception(E : @b<in> Exception_Id;
- Message : @b<in> String := "")
- @b<with> No_Return =@> True;
- @b<function> Exception_Message(X : Exception_Occurrence) @b<return> String;
- @b<procedure> Reraise_Occurrence(X : @b<in> Exception_Occurrence);>
+@xbullet<it shall not be, nor shall its visible part contain, the declaration of a subprogram
+for which aspect Inline is True;>
-!corrigendum 13.3.1(0)
+!corrigendum E.2.3(16)
-@dinsc
+@drepl
+If a pragma All_Calls_Remote applies to a library unit, the library unit shall be a remote call
+interface.
+@dby
+A pragma All_Calls_Remote sets the All_Calls_Remote representation aspect of the
+library unit to which it applies to the value True. If the All_Calls_Remote
+aspect of a library unit is True, the library unit shall be a remote call
+interface.
-Force a conflict; the real text is found in the conflict file.
+!corrigendum E.2.3(19/1)
-!corrigendum 13.11.3(1)
+@drepl
+If a pragma All_Calls_Remote applies to a given RCI library unit, then the implementation shall
+route any call to a subprogram of the RCI unit package from outside the declarative region of the
+unit through the Partition Communication Subsystem (PCS); see E.5. Calls to such subprograms from
+within the declarative region of the unit package are defined to be local and shall not go through
+the PCS.
+@dby
+If aspect All_Calls_Remote is True for a given RCI library unit, then the implementation shall
+route any call to a subprogram of the RCI unit package from outside the declarative region of the
+unit through the Partition Communication Subsystem (PCS); see E.5. Calls to such subprograms from
+within the declarative region of the unit package are defined to be local and shall not go through
+the PCS.
-@ddel
-Pragma Controlled is used to prevent any automatic reclamation of storage (garbage
-collection) for the objects created by @fa<allocator>s of a given access type.
-!corrigendum 13.11.3(2)
+!corrigendum E.4.1(0)
-@ddel
-@xindent<The form of a pragma Controlled is as follows:>
+@drepl
+Pragma Asynchronous
+@dby
+Asynchronous Remote Subprograms
-!corrigendum 13.11.3(3)
+!corrigendum E.4.1(1)
-@ddel
-@xindent<@b<pragma> Controlled(@i<first_subtype_>@fa<local_name>)>
+@drepl
+This subclause introduces the pragma Asynchronous which allows a remote subprogram call to
+return prior to completion of the execution of the corresponding remote subprogram body.
+@dby
+This subclause introduces the aspect Asynchronous which can be specified to allow a
+remote subprogram call to return prior to completion of the execution of the corresponding
+remote subprogram body.
-!corrigendum 13.11.3(4)
+!comment %% E.4.1(2), E.4.1(3), E.4.1(4), E.4.1(5), and E.4.1(6) need to be deleted here.
+!corrigendum E.4.1(7)
+
@ddel
-The @i<first_subtype_>@fa<local_name> of a @fa<pragma> Controlled shall denote a
-non-derived access subtype.
+@xbullet<The first subtype of a remote access-to-class-wide type.>
-!corrigendum 13.11.3(5)
+!corrigendum E.4.1(8)
-@ddel
-A @fa<pragma> Controlled is a representation pragma that specifies the controlled
-aspect of representation.
+@drepl
+A pragma Asynchronous is a representation pragma. When applied to a type, it specifies the
+type-related @i<asynchronous> aspect of the type.
+@dby
+For a remote procedure, the following language-defined
+representation aspect may be specified:
-!corrigendum 13.11.3(6)
+@xhang<@xterm<Asynchronous>
+The type of aspect Asynchronous is Boolean.
+If directly specified, the @fa<aspect_definition> shall be a static expression.
+If not specified, the aspect is False.>
-@ddel
-@i<Garbage collection> is a process that automatically reclaims storage, or moves
-objects to a different address, while the objects still exist.
+For a remote access type, the following language-defined
+representation aspect may be specified:
-!corrigendum 13.11.3(7)
+@xhang<@xterm<Asynchronous>
+The type of aspect Asynchronous is Boolean.
+If directly specified, the @fa<aspect_definition> shall be a static expression.
+If not specified (including by inheritance), the aspect is False.>
-@ddel
-If a @fa<pragma> Controlled is specified for an access type with a standard storage pool,
-then garbage collection is not performed for objects in that pool.
+@s8<@i<Legality Rules>>
-!corrigendum 13.11.3(8)
+If aspect Asynchronous is specified for a remote procedure, the formal
+parameters of the procedure shall all be of mode @b<in>.
-@ddel
-An implementation need not support garbage collection, in which case, a pragma Controlled
-has no effect.
+If aspect Asynchronous is specified for a remote access type, the type shall be
+a remote access-to-class-wide type, or the type shall be a remote
+access-to-procedure type with the formal parameters of the designated profile of
+the type all of mode @i<in>.
-!corrigendum 13.12.1(4/2)
+!corrigendum E.4.1(9)
@drepl
-@xhang<@xterm<No_Obsolescent_Features>
-There is no use of language features defined in Annex J. It is
-implementation defined whether uses of the renamings of J.1 are detected by this
-restriction. This restriction applies only to the current compilation or
-environment, not the entire partition.>
+A remote call is @i<asynchronous> if it is a call to a procedure, or a call through a value of
+an access-to-procedure type, to which a pragma Asynchronous applies. In addition, if a pragma
+Asynchronous applies to a remote access-to-class-wide type, then a dispatching call on a procedure
+with a controlling operand designated by a value of the type is asynchronous if the formal parameters
+of the procedure are all of mode @b<in>.
@dby
-@xhang<@xterm<No_Obsolescent_Features>
-There is no use of language features defined in Annex J. It is
-implementation defined whether uses of the renamings of J.1 and of the @fa<pragma>s of
-J.15 are detected by this restriction. This restriction applies only to the current
-compilation or environment, not the entire partition.>
+A remote call is @i<asynchronous> if it is a call to a procedure, or a call through a value of
+an access-to-procedure type, for which aspect Asynchronous is True. In addition, if aspect
+Asynchronous is True for a remote access-to-class-wide type, then a dispatching call on a procedure
+with a controlling operand designated by a value of the type is asynchronous if the formal parameters
+of the procedure are all of mode @b<in>.
+
!corrigendum J.15(0)
@@ -2075,7 +3038,7 @@
The form of a pragma Inline, which is a program unit pragma (see
10.1.5), is as follows:
-@xindent<@b<pragma> Inline(@fa<name> {, @fa<name>});>
+@xcode<@ft<@b<pragma> Inline(@fa<name> {, @fa<name>});>>
@s8<@i<Legality Rules>>
@@ -2106,7 +3069,7 @@
The form of a @fa<pragma> No_Return, which is a representation pragma (see 13.1),
is as follows:
-@xindent<@b<pragma> No_Return(@i<procedure_>@fa<local_name>{, @i<procedure_>@fa<local_name>});>
+@xcode<@ft<@b<pragma> No_Return(@i<procedure_>@fa<local_name>{, @i<procedure_>@fa<local_name>});>>
@s8<@i<Legality Rules>>
@@ -2118,143 +3081,154 @@
@fa<Pragma> No_Return specifies that the No_Return aspect (see 6.3.2) for each
procedure denoted by each @fa<local_name> given in the @fa<pragma> has the value True.
-
-
-** TBD below here...
+!corrigendum J.15.3(0)
-J.15.3 Pragma Pack
+@dinsc
@s8<@i<Syntax>>
-The form of a pragma Pack, which is a representation pragma (see 13.1),
+The form of a @fa<pragma> Pack, which is a representation pragma (see 13.1),
is as follows:
- pragma Pack(*first_subtype_*local_name);
+@xcode<@ft<@b<pragma> Pack(@i<first_subtype_>@fa<local_name>);>>
+
@s8<@i<Legality Rules>>
-The first_subtype_local_name of a pragma Pack shall denote a composite
+The @i<first_subtype_>@fa<local_name> of a @fa<pragma> Pack shall denote a composite
subtype.
@s8<@i<Static Semantics>>
-Pragma Pack specifies that the Pack aspect (see 13.2) for the type
-denoted by *first_subtype_*local_name has the value True.
+@fa<Pragma> Pack specifies that the Pack aspect (see 13.2) for the type
+denoted by @i<first_subtype_>@fa<local_name> has the value True.
-J.15.4 pragma Storage_Size
+!corrigendum J.15.4(0)
+
+@dinsc
@s8<@i<Syntax>>
-The form of a pragma Storage_Size is as follows:
+The form of a @fa<pragma> Storage_Size is as follows:
- pragma Storage_Size(expression);
+@xcode<@ft<@b<pragma> Storage_Size(@fa<expression>);>>
-A pragma Storage_Size is allowed only immediately within a task_definition.
+A @fa<pragma> Storage_Size is allowed only immediately within a @fa<task_definition>.
@s8<@i<Name Resolution Rules>>
-The expression of a pragma Storage_Size is expected to be of any integer type.
+The @fa<expression> of a @fa<pragma> Storage_Size is expected to be of any integer type.
@s8<@i<Static Semantics>>
-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.
+The @fa<pragma> Storage_Size sets the Storage_Size aspect (see 13.3) of the type defined
+by the immediately enclosing @fa<task_definition> to the value of the @fa<expression>
+of the @fa<pragma>.
-J.15.5 Interfacing pragmas
+!corrigendum J.15.5(0)
+
+@dinsc
@s8<@i<Syntax>>
-An interfacing pragma is a representation pragma that is one of the pragmas Import,
+An @i<interfacing> pragma is a representation pragma that is one of the pragmas Import,
Export, or Convention. Their forms are as follows:
-
- pragma Import(
- [Convention =>] convention_identifier, [Entity =>] local_name
- [, [External_Name =>] external_name_string_expression] [, [Link_Name =>] link_name_string_expression]);
- pragma Export(
- [Convention =>] convention_identifier, [Entity =>] local_name
- [, [External_Name =>] external_name_string_expression] [, [Link_Name =>] link_name_string_expression]);
+@xcode<@ft<@b<pragma> Import(@hr
+ [Convention =@>] @i<convention_>@fa<identifier>, [Entity =@>] @fa<local_name>
+ [, [External_Name =@>] @i<external_name_string_>@fa<expression>]
+ [, [Link_Name =@>] @i<link_name_string_>@fa<expression>]);>>
+
+@xcode<@ft<@b<pragma> Export(@hr
+ [Convention =@>] @i<convention_>@fa<identifier>, [Entity =@>] @fa<local_name>
+ [, [External_Name =@>] @i<external_name_string_>@fa<expression>]
+ [, [Link_Name =@>] @i<link_name_string_>@fa<expression>]);>>
- pragma Convention([Convention =>] convention_identifier,[Entity =>] local_name);
+@xcode<@ft<@b<pragma> Convention([Convention =@>] @i<convention_>@fa<identifier>,[Entity =@>] @fa<local_name>);>>
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.
+the @i<pragma_argument_>@fa<identifier> unless the argument for External_Name is given.
@s8<@i<Name Resolution Rules>>
-The expected type for a external_name_string_expression and a link_name_string_expression
+The expected type for a @i<external_name_string_>@fa<expression> and a @i<link_name_string_>@fa<expression>
in an interfacing pragma is String.
@s8<@i<Legality Rules>>
-The convention_identifier of an interfacing pragma shall be the name of a convention (see B.1).
+The @i<convention_>@fa<identifier> of an interfacing pragma shall be the name of a convention (see B.1).
-A pragma Import shall be the completion of a declaration.
+A @fa<pragma> Import shall be the completion of a declaration.
-The external_name_string_expression and link_name_string_expression of a pragma Import
-or Export shall be static.
+The @i<external_name_string_>@fa<expression> and @i<link_name_string_>@fa<expression> of a
+@fa<pragma> Import or Export shall be static.
-The local_name of of each of these pragmas shall denote a declaration that may have
+The @fa<local_name> of each of these pragmas shall denote a declaration that may have
the similarly named aspect specified.
@s8<@i<Static Semantics>>
-An interfacing pragam specifies various aspects of the entity denoted by the
-local_name as follows:
+An interfacing pragma specifies various aspects of the entity denoted by the
+@fa<local_name> as follows:
-* The Convention aspect (see B.1) is convention_identifier.
+@xbullet<The Convention aspect (see B.1) is @i<convention_>@fa<identifier>.>
-* A pragma Import specifies that the Import aspect (see B.1) is True.
+@xbullet<A @fa<pragma> Import specifies that the Import aspect (see B.1) is True.>
-* A pragma Export specifies that the Export aspect (see B.1) is True.
+@xbullet<A @fa<pragma> Export specifies that the Export aspect (see B.1) is True.>
-* For both pragma Import and Export, if an
- external name is given in the pragma, the External_Name aspect
- is specified to be external_name_string_expression. If a link name
- is given in the pragma, the Link_Name aspect is specified to be the
- link_name_string_expression.
+@xbullet<For both @fa<pragma> Import and Export, if an
+ external name is given in the pragma, the External_Name aspect (see B.1)
+ is specified to be @i<external_name_string_>@fa<expression>. If a link name
+ is given in the pragma, the Link_Name aspect (see B.1) is specified to be the
+ @i<link_name_string_>@fa<expression>.>
-J.15.6 Pragma Unchecked_Union
+!corrigendum J.15.6(0)
+@dinsc
+
@s8<@i<Syntax>>
-The form of a pragma Unchecked_Union, which is a representation pragma (see
+The form of a @fa<pragma> Unchecked_Union, which is a representation pragma (see
13.1), is as follows:
- pragma Unchecked_Union (first_subtype_local_name);
+@xcode<@ft<@b<pragma> Unchecked_Union (@i<first_subtype_>@fa<local_name>);>>
@s8<@i<Legality Rules>>
-The first_subtype_local_name of a pragma Unchecked_Union shall denote an
-unconstrained discriminated record subtype having a variant_part.
+The @i<first_subtype_>@fa<local_name> of a @fa<pragma> Unchecked_Union shall denote an
+unconstrained discriminated record subtype having a @fa<variant_part>.
@s8<@i<Static Semantics>>
-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.
+A @fa<pragma> Unchecked_Union specifies that the Unchecked_Union aspect (see B.3.3)
+for the type denoted by @i<first_subtype_>@fa<local_name> has the value True.
-J.15.7 Pragmas Interrupt_Handler and Attach_Handler
+!corrigendum J.15.7(0)
-The form of a pragma Interrupt_Handler is as follows:
- pragma Interrupt_Handler(handler_name);
+@dinsc
+The form of a @fa<pragma> Interrupt_Handler is as follows:
+
+@xindent<@b<pragma> Interrupt_Handler(@i<handler_>@fa<name>);>
+
The form of a pragma Attach_Handler is as follows:
- pragma Attach_Handler(handler_name, expression);
+
+@xcode<@ft<@b<pragma> Attach_Handler(@i<handler_>@fa<name>, @fa<expression>);>>
@s8<@i<Name Resolution Rules>>
-For the Interrupt_Handler and Attach_Handler pragmas, the handler_name shall
-resolve to denote a protected procedure with a parameterless profile.
+For the Interrupt_Handler and Attach_Handler pragmas, the @i<handler_>@fa<name>
+shall resolve to denote a protected procedure with a parameterless profile.
-For the Attach_Handler pragma, the expected type for the expression is
+For the Attach_Handler pragma, the expected type for the @fa<expression> is
Interrupts.Interrupt_Id (see C.3.2).
@s8<@i<Legality Rules>>
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
+within the @fa<protected_definition> where the corresponding subprogram is declared.
+The corresponding @fa<protected_type_declaration> or @fa<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.
@@ -2263,177 +3237,189 @@
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
+@i<handler_>@fa<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
-[Redundant: as evaluated at object creation time].
+the protected procedure @i<handler_>@fa<name> to have the value of the given
+@fa<expression> as evaluated at object creation time.
-J.15.8 Shared variable pragmas
+!corrigendum J.15.8
+
+@dinsc
@s8<@i<Syntax>>
-The form for pragmas Atomic, Volatile, Independent, Atomic_Components, and
+The form for @fa<pragma>s Atomic, Volatile, Independent, Atomic_Components, and
Volatile_Components, and Independent_Components is as follows:
- pragma Atomic(local_name);
+@xcode<@ft<@b<pragma> Atomic(@fa<local_Name>);>>
- pragma Volatile(local_name);
+@xcode<@ft<@b<pragma> Volatile(@fa<local_Name>);>>
- pragma Independent(component_local_name);
+@xcode<@ft<@b<pragma> Atomic(@i<component_>@fa<local_Name>);>>
- pragma Atomic_Components(array_local_name);
+@xcode<@ft<@b<pragma> Atomic_Components(@i<array_>@fa<local_Name>);>>
- pragma Volatile_Components(array_local_name);
+@xcode<@ft<@b<pragma> Volatile_Components(@i<array_>@fa<local_Name>);>>
- pragma Independent_Components(local_name);
+@xcode<@ft<@b<pragma> Independent_Components(@fa<local_Name>);>>
@s8<@i<Name Resolution Rules>>
-The local_name in an Atomic or Volatile pragma shall resolve to denote either
-an object_declaration, a non-inherited component_declaration, or a
-full_type_declaration. The component_local_name in an Independent pragma shall
-resolve to denote a non-inherited component_declaration. The array_local_name
+The @fa<local_name> in an Atomic or Volatile pragma shall resolve to denote either
+an @fa<object_declaration>, a non-inherited @fa<component_declaration>, or a
+@fa<full_type_declaration>. The @i<component_>@fa<local_name> in an Independent
+pragma shall resolve to denote a non-inherited @fa<component_declaration>. The
+@i<array_>@fa<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
+The @fa<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.
@s8<@i<Static Semantics>>
-These pragmas are representation pragmas (see 13.1). Each of these pragmas
+These @fa<pragma>s are representation pragmas (see 13.1). Each of these @fa<pragma>s
specifies that the similarly named aspect (see C.6) of the type, object, or
component denoted by its argument is True.
@s8<@i<Legality Rules>>
-The local_name of of each of these pragmas shall denote a declaration that may have
-the similarly named aspect specified.
+The @fa<local_name> of of each of these @fa<pragma>s shall denote a declaration that
+may have the similarly named aspect specified.
-J.15.9 pragma CPU
+!corrigendum J.15.9
-AARM Discussion: This pragma is born obsolescent; it is defined to provide
-consistency with existing real-time pragmas.
+@dinsc
@s8<@i<Syntax>>
-The form of a pragma CPU is as follows:
- pragma CPU (expression);
+The form of a @fa<pragma> CPU is as follows:
+@xcode<@ft<@b<pragma> CPU(@fa<expression>);>>
+
@s8<@i<Name Resolution Rules>>
-The expected type for the expression of a pragma CPU is
+The expected type for the @fa<expression> of a pragma CPU is
System.Multiprocessors.CPU_Range.
@s8<@i<Legality Rules>>
-A CPU pragma is allowed only immediately within a task_definition, or the
-declarative_part of a subprogram_body. At most one such pragma shall appear
-within a given construct.
+A CPU pragma is allowed only immediately within a @fa<task_definition>, or the
+@fa<declarative_part> of a @fa<subprogram_body>. At most one such pragma
+shall appear within a given construct.
-For a CPU pragma that appears in the declarative_part of a subprogram_body, the
-expression shall be static.
+For a CPU pragma that appears in the @fa<declarative_part> of a @fa<subprogram_body>,
+the @fa<expression> shall be static.
@s8<@i<Static Semantics>>
-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_definition that contains the pragma; otherwise, the expression is
-associated with the aspect for the subprogram that contains the pragma.
+For an implementation that supports Annex D, a @fa<pragma> CPU specifies the value of
+the CPU aspect (see D.16). If the @fa<pragma> appears in a @fa<task_definition>, the
+@fa<expression> is associated with the aspect for the task type or
+@fa<single_task_declaration> that contains the @fa<pragma>; otherwise, the
+@fa<expression> is associated with the aspect for the subprogram that contains
+the @fa<pragma>.
-[Editor's note: J.15.10 is in AI05-0167-1.]
+!comment J.15.10 is in AI05-0167-1.
-J.15.11 Pragmas Priority and Interrupt_Priority
+!corrigendum J.15.11
@s8<@i<Syntax>>
-The form of a pragma Priority is as follows:
+The form of a @fa<pragma> Priority is as follows:
- pragma Priority(expression);
+@xcode<@ft<@b<pragma> Priority(@fa<expression>);>>
-The form of a pragma Interrupt_Priority is as follows:
+The form of a @fa<pragma> Interrupt_Priority is as follows:
- pragma Interrupt_Priority[(expression)];
+@xcode<@ft<@b<pragma> Interrupt_Priority[(@fa<expression>)];>>
@s8<@i<Name Resolution Rules>>
-The expected type for the expression in a Priority or Interrupt_Priority pragma
+The expected type for the @fa<expression> in a Priority or Interrupt_Priority pragma
is Integer.
@s8<@i<Legality Rules>>
-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. At most one such pragma shall appear within a given
+A Priority pragma is allowed only immediately within a @fa<task_definition>, a
+@fa<protected_definition>, or the @fa<declarative_part> of a @fa<subprogram_body>.
+An Interrupt_Priority pragma is allowed only immediately within a @fa<task_definition>
+or a @fa<protected_definition>. At most one such pragma shall appear within a given
construct.
-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
+For a Priority pragma that appears in the @fa<declarative_part> of a @fa<subprogram_body,>
+the @fa<expression> shall be static, and its value shall be in the range of
System.Priority.
@s8<@i<Static Semantics>>
-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
+For an implementation that supports Annex D, a @fa<pragma> Priority specifies the
+value of the Priority aspect (see D.1) and a @fa<pragma> Interrupt_Priority specifies
the value of the Interrupt_Priority aspect as follows:
-* If the pragma appears in a task_definition, the expression is associated with
- the aspect for the task type or single_task_definition that contains the
- pragma;
-* If the pragma appears in a protected_definition, the expression is associated
- with the aspect for the protected type or single_protected_definition that
- contains the pragma;
-* 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.
-If there is no expression in an Interrupt_Priority pragma, the
+@xbullet<If the @fa<pragma> appears in a @fa<task_definition>, the @fa<expression>
+is associated with the aspect for the task type or @fa<single_task_declaration> that
+contains the @fa<pragma>;>
+
+@xbullet<If the @fa<pragma> appears in a @fa<protected_definition>, the @fa<expression>
+is associated with the aspect for the protected type or @fa<single_protected_declaration>
+that contains the @fa<pragma>;>
+
+@xbullet<If the @fa<pragma> appears in the @fa<declarative_part> of a @fa<subprogram_body>,
+the @fa<expression> is associated with the aspect for the subprogram that contains the
+@fa<pragma>.>
+
+If there is no @fa<expression> in an Interrupt_Priority pragma, the
Interrupt_Priority aspect has the value Interrupt_Priority'Last.
-J.15.12 pragma Relative_Deadline
+!corrigendum J.15.12
+@dinsc
+
@s8<@i<Syntax>>
-The form of a pragma Relative_Deadline is as follows:
- pragma Relative_Deadline (relative_deadline_expression);
+The form of a @fa<pragma> Relative_Deadline is as follows:
+@xcode<@ft<@b<pragma> Relative_Deadline (@i<relative_deadline_>@fa<expression>);>>
+
@s8<@i<Name Resolution Rules>>
-The expected type for relative_deadline_expression is Real_Time.Time_Span.
+The expected type for a @i<relative_deadline_>@fa<expression> is Real_Time.Time_Span.
@s8<@i<Legality Rules>>
-A Relative_Deadline pragma is allowed only immediately within a task_definition
-or the declarative_part of a subprogram_body. At most one such pragma shall
+A Relative_Deadline pragma is allowed only immediately within a @fa<task_definition>
+or the @fa<declarative_part> of a @fa<subprogram_body>. At most one such pragma shall
appear within a given construct.
@s8<@i<Static Semantics>>
-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_definition that contains the pragma; otherwise, the
-expression is associated with the aspect for the subprogram that contains the
-pragma.
+For an implementation that supports Annex D, a @fa<pragma> Relative_Deadline
+specifies the value of the Relative_Deadline aspect (see D.2.6). If the @fa<pragma>
+appears in a @fa<task_definition>, the @fa<expression> is associated with the aspect for
+the task type or @fa<single_task_declaration> that contains the @fa<pragma>; otherwise, the
+@fa<expression> is associated with the aspect for the subprogram that contains the
+@fa<pragma>.
-J.15.13 Pragma Asynchronous
+!corrigendum J.15.13
+
+@dinsc
@s8<@i<Syntax>>
-The form of a pragma Asynchronous, which is a representation pragma (see 13.1),
+The form of a @fa<pragma> Asynchronous, which is a representation pragma (see 13.1),
is as follows:
- pragma Asynchronous(local_name);
+@xcode<@ft<@b<pragma> Asynchronous(@fa<local_name>);>>
@s8<@i<Static Semantics>>
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.
+@fa<local_name> has the value True.
@s8<@i<Legality Rules>>
-The local_name of a pragma Asynchronous shall denote a declaration that may have
+The @fa<local_name> of a pragma Asynchronous shall denote a declaration that may have
aspect Asynchronous specified.
@@ -5805,5 +6791,65 @@
J.
Also note that I didn't really support moving all those pragmas into Annex J.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, July 6, 2011 6:11 PM
+
+Christoph Grein notes that the lists of 13.1(8.f-kk) contains a number of obsolescent
+pragmas. This list gives type-related representation items, subtype-related ones, and
+ones that are neither.
+
+Replacing these pragmas with aspects directly won't work, because while pragmas are
+representation items, an aspect_specification is not a representation item (although
+it mught be used to specify a aspect of representation -- go figure).
+
+The choices seem to be:
+(1) Do nothing. The pragmas might be obsolescent, but they surely are still representation
+items and still make sense in this list.
+
+(2) Change the list headers to talk about aspects of representation rather than the
+actual items. That would require dropping "pragma" and "clause" throughout the lists. This
+would be the most correct and useful, but also is the most churn. At least this is an
+AARM note so not much documentation of the changes is needed.
+
+(3) Just change "pragma" to "aspect" here and be happy. But that seems to confuse aspects
+with the means of setting them.
+
+(4) Somehow change "representation item" to include aspect_specifications that set
+representation aspects, and then change "pragma" to "aspect" as needed. This might actually
+be the best solution, since not calling such things "representation items" seems unusual.
+But we've been living with that for a long time now, and I don't think we need such a
+change elsewhere. Since that would be a normative change, it would have the most risk.
+
+(5) Delete this silly list (it is a pain to maintain, and it is of dubious utility --
+especially given the new aspect index).
+
+I'm leaning toward (1), but that probably is in part because it is the least work for me.
+(2) would probably be the most accurate and least confusing, but (5) also is appealing.
+
+Thoughts??
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, July 6, 2011 6:30 PM
+
+> I'm leaning toward (1), but that probably is in part because it is the
+> least work for me. (2) would probably be the most accurate and least
+> confusing, but (5) also is appealing.
+
+I more-or-less agree. I lean toward (1). I think this AARM junk is my handiwork, but
+I wouldn't mind (5) too much -- just get rid of it if it's causing trouble.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, July 6, 2011 6:31 PM
+
+I recommend you leave it basically as is, but perhaps add some general comment like
+"(note that corresponding statements could be made about aspects and
+aspect_specifications)".
****************************************************************
Questions? Ask the ACAA Technical Agent