CVS difference for ai05s/ai05-0229-1.txt

--- ai05s/ai05-0229-1.txt	2011/04/01 01:35:18	1.11
+++ ai05s/ai05-0229-1.txt	2011/04/01 01:53:10	1.12
@@ -70,7 +70,7 @@
 There is no use of language features defined in Annex J. It is implementation-defined
 if uses of the renamings of J.1 {and the pragmas of J.15} are detected by this
 restriction. This restriction applies only to the current compilation or environment,
-not the entire partition. 
+not the entire partition.
 
 AARM Note: The pragmas have exactly the functionality of the corresponding aspect,
 (unlike the typical obsolescent feature) and rejecting them could be a significant
@@ -96,7 +96,7 @@
 
 [Redundant: {The Pack aspect having the value True}[A pragma Pack] specifies that
 storage minimization should be the main criterion when selecting the representation
-of a composite type.] 
+of a composite type.]
 
 Delete 13.2(2-4). [Now in Annex J.]
 
@@ -105,9 +105,9 @@
   For a full type declaration of a composite type, the following language-defined
   representation aspect may be specified:
      Pack
-      The type of aspect Pack is Boolean. When aspect Pack is True for a type, the
-      type (or the extension part) is said to be packed. For a type extension, the
-      parent part is packed as for the parent type, and
+      The type of aspect Pack is Boolean. When aspect Pack is True for a type,
+      the type (or the extension part) is said to be packed. For a type
+      extension, the parent part is packed as for the parent type, and
       specifying Pack causes packing only of the extension part.
 
       If directly specified, the aspect_definition shall be a static expression.
@@ -123,11 +123,11 @@
 {Specifying the Pack aspect}[A pragma Pack] is for gaining space efficiency,
 possibly at the expense of time. If more explicit control over representation is
 desired, then a record_representation_clause, a Component_Size clause, or a Size
-clause should be used instead of, or in addition to, {the Pack aspect}[a pragma Pack]. 
+clause should be used instead of, or in addition to, {the Pack aspect}[a pragma Pack].
 
 Modify 13.2(7):
 
-The recommended level of support for {the Pack aspect}[pragma Pack] is: 
+The recommended level of support for {the Pack aspect}[pragma Pack] is:
 
 Modify AARM Notes 13.2(9.b-d/2), replacing "pragma Pack" with "the Pack aspect".
 
@@ -140,8 +140,8 @@
 Modify A.1(42), A.1(42.1/2), B.4(12), B.4(16), B.4(20), B.4(29), B.5(12) to use the
 Pack aspect rather than the pragma as described above.
 
-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).
+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).
 
@@ -152,7 +152,8 @@
 If [a pragma Pack applies to]{the Pack aspect is True for} a type any
 of ...
 
-AARM notes in 13.1 and 13.3 need modification from "pragma Pack" to "aspect Pack".
+AARM notes in 13.1 and 13.3 need modification from "pragma Pack" to "aspect
+Pack".
 
 
 ===pragma No_Return (the pragma is to be obsolescent)
@@ -161,8 +162,9 @@
 
 Modify 6.5.1(1/2):
 
-{Specifying aspect No_Return to have the value True}[A pragma No_Return] indicates that a procedure
-cannot return normally [Redundant:; it may propagate an exception or loop forever]. 
+{Specifying aspect No_Return to have the value True}[A pragma No_Return]
+indicates that a procedure cannot return normally [Redundant:; it may propagate
+an exception or loop forever].
 
 Delete 6.5.1(2-3/2). [Now in Annex J.]
 
@@ -209,9 +211,9 @@
 
 Modify 13.11.3(1/2):
 
-{Specifying aspect Controlled to have value True prevents}[Pragma Controlled is used to prevent]
-any automatic reclamation of storage (garbage collection) for the objects created by allocators
-of a given access type.
+{Specifying aspect Controlled to have value True prevents}[Pragma Controlled is
+used to prevent] any automatic reclamation of storage (garbage collection) for
+the objects created by allocators of a given access type.
 
 Delete 13.11.3(2-4). [Now in Annex J.]
 
@@ -226,25 +228,27 @@
 
 Modify 13.11.3(7):
 
-If {aspect Controlled is True}[a pragma Controlled is specified] for an access type with a standard
-storage pool, then garbage collection is not performed for objects in that pool. 
+If {aspect Controlled is True}[a pragma Controlled is specified] for an access
+type with a standard storage pool, then garbage collection is not performed for
+objects in that pool.
 
 Modify 13.11.3(8):
 
-An implementation need not support garbage collection, in which case, {aspect Controlled}[a pragma
-Controlled] has no effect. 
+An implementation need not support garbage collection, in which case, {aspect
+Controlled}[a pragma Controlled] has no effect.
 
 
 ===pragma Unchecked_Union: (the pragma is to be obsolescent)
 
-Change the title of clause B.3.3 to "Unchecked Union Types". 
+Change the title of clause B.3.3 to "Unchecked Union Types".
 
 Modify B.3.3(1/2):
 
-[Redundant: {Specifying aspect Unchecked_Union to have value True defines}[A pragma Unchecked_Union
-specifies] an interface correspondence between a given discriminated type and some C union.
-The {aspect requires}[pragma specifies] that the associated type {is}[shall be] given a
-representation that leaves no space for its discriminant(s).] 
+[Redundant: {Specifying aspect Unchecked_Union to have value True defines}[A
+pragma Unchecked_Union specifies] an interface correspondence between a given
+discriminated type and some C union. The {aspect requires}[pragma specifies]
+that the associated type {is}[shall be] given a representation that leaves no
+space for its discriminant(s).]
 
 Add after B.3.3(1/2):
 
@@ -260,50 +264,55 @@
 
 Modify B.3.3(6/2):
 
-A type {for}[to] which {aspect}[a pragma] Unchecked_Union {is True}[applies] is called an
-*unchecked union type*. A subtype of an unchecked union type is defined to be an *unchecked
-union subtype*. An object of an unchecked union type is defined to be an *unchecked union object*.
+A type {for}[to] which {aspect}[a pragma] Unchecked_Union {is True}[applies] is
+called an *unchecked union type*. A subtype of an unchecked union type is
+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):
 
-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.
+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 configuration pragma or
-to apply to all entities in a package specification cannot be modeled as an aspect.
+[Editor's note: Can't get make this pragma obsolescent; its use as a
+configuration pragma or to apply to all entities in a package specification
+cannot be modeled as an aspect.
+
+C.5: No changes needed for Discard_Names; the general wording for using
+representation pragmas as aspects applies here. But note that this is the only
+remaining representation pragma in the core.
+
+Add an AARM Ramification after C.5(6): Representation pragmas are automatically
+aspects, so Discard_Names can be used as an aspect_mark in an
+aspect_specification instead of using the pragma on individual entities.
+
+[Editor's note: We could try to reword this to recommend using an aspect rather
+than the (On => local_name) form, but it doesn't seem worth the effort. The AARM
+note is just to mention the possibility. We could also make something similar
+into a user note.]
 
-C.5: No changes needed for Discard_Names; the general wording for using representation
-pragmas as aspects applies here. But note that this is the only remaining representation
-pragma in the core.
-
-Add an AARM Ramification after C.5(6): Representation pragmas are automatically aspects,
-so Discard_Names can be used as an aspect_mark in an aspect_specification instead of
-using the pragma on individual entities.
-
-[Editor's note: We could try to reword this to recommend using an aspect rather than
-the (On => local_name) form, but it doesn't seem worth the effort. The AARM note is just
-to mention the possibility. We could also make something similar into a user note.]
 
-
 ** Unchanged - TBD ** -- Assigned to Ed.
 ===pragma Atomic, Atomic_Components, Independent,
-Independent_Components, Volatile, Volatile_Components: (the pragmas are to be obsolescent)
+Independent_Components, Volatile, Volatile_Components: (the pragmas are to be
+obsolescent)
 
 C.6(14): No changes needed for Atomic, Atomic_Components, Independent,
 Independent_Components, Volatile, Volatile_Components.
 
 ===pragma Asynchronous: (the pragma is to be obsolescent)
 
-Change the title of clause E.4.1 to "Asynchronous Remote Calls". 
+Change the title of clause E.4.1 to "Asynchronous Remote Calls".
 
 Modify E.4.1(1):
 
 [Redundant: This subclause introduces the {aspect}[pragma] Asynchronous which
-{which can be specified to allow}[allows] a remote subprogram call to return prior
-to completion of the execution of the corresponding remote subprogram body.] 
+{which can be specified to allow}[allows] a remote subprogram call to return
+prior to completion of the execution of the corresponding remote subprogram
+body.]
 
 Delete E.4.1(2-3). [Now in Annex J.]
 
@@ -325,12 +334,13 @@
 
 Replace E.4.1(4-7) with:
 
-If aspect Asynchronous is specified for a remote procedure, the formal parameters
-of the procedure shall all be of mode *in*.
+If aspect Asynchronous is specified for a remote procedure, the formal
+parameters of the procedure shall all be of mode *in*.
 
 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 *in*.
+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 *in*.
 
 Delete E.4.1(8).
 
@@ -338,10 +348,10 @@
 
 A remote call is asynchronous if it is a call to a procedure, or a call through
 a value of an access-to-procedure type, to which {aspect}[a pragma] Asynchronous
-{is True}[applies]. In addition, if {aspect}[a pragma] Asynchronous
-{is True}[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 in. 
+{is True}[applies]. In addition, if {aspect}[a pragma] Asynchronous {is
+True}[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 in.
 
 Edit AARM notes E.4(20.g-20.h) to replace "pragma Asychronous is applied" with
 "aspect Asychronous is specified". E.4(20.i) "pragma" becomes "aspect".
@@ -380,14 +390,14 @@
 
 ===pragma All_Calls_Remote
 
-[Editor's note: As a pragma that applies to a package, we're not going to make it
-obsolescent.]
+[Editor's note: As a pragma that applies to a package, we're not going to make
+it obsolescent.]
 
 Replace E.2.3(16):
 
 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
+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.
 
 Modify E.2.3(19/1):
@@ -398,9 +408,9 @@
 
 ===pragma Elaborate_Body
 
-[Editor's note: As a pragma that applies to a package, we're not going to make it
-obsolescent. But note that we still have to write the semantics in terms of the
-aspect so that whether the pragma or aspect is used is irrelevant.]
+[Editor's note: As a pragma that applies to a package, we're not going to make
+it obsolescent. But note that we still have to write the semantics in terms of
+the aspect so that whether the pragma or aspect is used is irrelevant.]
 
 Replace 10.2.1(25):
 
@@ -426,18 +436,18 @@
     Inline
       The type of aspect Inline is Boolean. When aspect Inline is True for a
       callable entity, indicates that inline expansion is
-      desired for all calls to that entity. When aspect Inline is True for a 
+      desired for all calls to that entity. When aspect Inline is True for a
       generic subprogram, inline expansion is desired for all calls to all
       instances of that generic subprogram.
 
       If directly specified, the aspect_definition shall be a static expression.
-      [Redundant: This aspect is never inherited;] if not directly specified, the
-      aspect is False.
+      [Redundant: This aspect is never inherited;] if not directly specified,
+      the aspect is False.
 
 Modify 6.3.2(6):
 
-For each call, an implementation is free to follow or to ignore the recommendation
-{determined}[expressed] by the {Inline aspect}[pragma].
+For each call, an implementation is free to follow or to ignore the
+recommendation {determined}[expressed] by the {Inline aspect}[pragma].
 
 Delete 6.3.2(6.1/2).
 
@@ -531,9 +541,9 @@
    partial view that the full view is well-behaved. The reason for supporting
    this for other composite types is more subtle: a non-null override
    for Initialize might occur in the private part, even for a nonprivate type;
-   in order to preserve privacy, we need a way to express on a type declared in 
+   in order to preserve privacy, we need a way to express on a type declared in
    a visible part that the private part does not contain any nasty override of
-   Initialize. 
+   Initialize.
 
    AARM ramification: A value of True may not be specified for the
    Preelaborable_Initialization aspect of a protected types with one
@@ -573,8 +583,8 @@
     Interrupt_Handler
       The type of aspect Interrupt_Handler is Boolean.
       If directly specified, the aspect_definition shall be a static expression.
-      [Redundant: This aspect is never inherited;] if not directly specified, the
-      aspect is False.
+      [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.]
@@ -659,13 +669,13 @@
 
 ===pragma Storage_Size (the pragma is to be obsolescent)
 
-[Editor's note: The existing attribute allows specification of Storage_Size for a task
-type *but* that attribute is obsolescent! Moreover, it would evaluate the
-expression too soon (when the type is frozen). My presumption is that this explicit
-wording overrides the "automatic" aspect implied by the obsolescent attribute.
-I handled this with a pair of AARM notes, since I don't want to rewrite the
-wording of an obsolescent attribute nor rewrite the aspect_specification wording
-for this unusual case.]
+[Editor's note: The existing attribute allows specification of Storage_Size for
+a task type *but* that attribute is obsolescent! Moreover, it would evaluate the
+expression too soon (when the type is frozen). My presumption is that this
+explicit wording overrides the "automatic" aspect implied by the obsolescent
+attribute. I handled this with a pair of AARM notes, since I don't want to
+rewrite the wording of an obsolescent attribute nor rewrite the
+aspect_specification wording for this unusual case.]
 
 Modify 13.3(60):
 
@@ -688,47 +698,49 @@
       The value of aspect Storage_Size is an expression, which shall be of
       any integer type.
 
-[Editor's note: I would have used the shorter wording "single task", but that term is
-not defined by the Standard. We do use it in a few AARM notes, but that isn't much help.
-Thus I used the longer wording.]
-
-AARM To Be Honest: This definition somewhat conflicts with the "automatic" one for
-the obsolescent attribute Storage_Size. We intend for that "automatic" one to not be
-used for that attribute.
+[Editor's note: I would have used the shorter wording "single task", but that
+term is not defined by the Standard. We do use it in a few AARM notes, but that
+isn't much help. Thus I used the longer wording.]
+
+AARM To Be Honest: This definition somewhat conflicts with the "automatic" one
+for the obsolescent attribute Storage_Size. We intend for that "automatic" one
+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 means we cannot
-run afoul of 13.1(10).]
+aspect inheritance, other than from task interfaces (a new possibility). Should
+we make specifying the aspect for those illegal?? The inabilility to derive also
+means we cannot run afoul of 13.1(10).]
 
 Delete 13.3(62-65) [Now in Annex J.]
 
 Replace 13.3(66) with:
 
-When a task object is created, the expression (if any) associated with the Storage_Size
-aspect of its type is evaluated; the Storage_Size attribute of the newly created
-task object is at least the value of the expression.
+When a task object is created, the expression (if any) associated with the
+Storage_Size aspect of its type is evaluated; the Storage_Size attribute of the
+newly created task object is at least the value of the expression.
 
-AARM Ramification: If the Storage_Size aspect is not specified for the type of the
-task object, the value of the Storage_Size attribute is unspecified.
+AARM Ramification: If the Storage_Size aspect is not specified for the type of
+the task object, the value of the Storage_Size attribute is unspecified.
 
 Add after J.9(3/2):
 
 AARM Ramification:
-When this attribute is specified with an attribute_definition_clause, the associated
-aspect is set to the value of the expression given in the attribute_definition_clause.
-This value is therefore the same for all objects of the type; in particular, it is
-not re-evaluated when objects are created. This is different than when the aspect
-is specified with an aspect_specification (see 13.3).
+When this attribute is specified with an attribute_definition_clause, the
+associated aspect is set to the value of the expression given in the
+attribute_definition_clause. This value is therefore the same for all objects of
+the type; in particular, it is not re-evaluated when objects are created. This
+is different than when the aspect is specified with an aspect_specification (see
+13.3).
 
 
 ===pragma Interrupt_Priority, Priority  (the pragmas are to be obsolescent)
 
-[Editor's Note: I'd much prefer that there was only one aspect here, but the rules about
-converting to subtype Any_Priority vs. to subtype Priority at evaluation time force
-two aspects. That's because these aspects are expressions that are evaluated when
-the task (or protected) object is elaborated, not values evaluated at the freezing point.
-Personally, I'd drop the two subtypes, but one presumes that there is some value to the
+[Editor's Note: I'd much prefer that there was only one aspect here, probably
+named "Base_Priority", but the rules about converting to subtype Any_Priority
+vs. to subtype Priority at evaluation time force two aspects. That's because
+these aspects are expressions that are evaluated when the task (or protected)
+object is elaborated, not values evaluated at the freezing point. Personally,
+I'd drop the two subtypes, but one presumes that there is some value to the
 bifrucation and in any case it is 30 years too late for that.]
 
 Delete D.1(2-7) [Moved to Annex J.]
@@ -739,7 +751,8 @@
 
   For a task type (including the anonymous type of a single_task_definition),
   protected type (including the anonymous type of a single_protected_definition),
-  or subprogram, the following language-defined representation aspects may be specified:
+  or subprogram, the following language-defined representation aspects may be
+  specified:
     Priority
       The value of aspect Priority is an expression, which shall be of
       type Integer.
@@ -749,16 +762,16 @@
 
 [Editor's Note: See the comment about "single task" in Storage_Size.]
 
-[Editor's note: Task types and protected types cannot be derived, and subprograms never
-inherit aspects, so we don't have to worry about aspect inheritance, other than from
-synchronized interfaces (a new possibility). Should we make specifying the aspects for
-those illegal?? The inabilility to derive also means we cannot
-run afoul of 13.1(10).]
+[Editor's note: Task types and protected types cannot be derived, and
+subprograms never inherit aspects, so we don't have to worry about aspect
+inheritance, other than from synchronized interfaces (a new possibility). Should
+we make specifying the aspects for those illegal?? The inabilility to derive
+also means we cannot run afoul of 13.1(10).]
 
 Replace D.1(8):
 
-If the Priority aspect is specified for a subprogram, the expression shall be static,
-and its value shall be in the range of System.Priority.
+If the Priority aspect is specified for a subprogram, the expression shall be
+static, and its value shall be in the range of System.Priority.
 
 Add after D.1(8):
 
@@ -767,9 +780,9 @@
 
 AARM Ramification: This includes specifying via pragmas (see J.15.7).
 
-Delete D.1(13). [This is covered by other wording, and seems to conflict with D.1(17)
-anyway. The definition of the value of the pragma is never used anywhere, so far
-as I can tell.]
+Delete D.1(13). [This is covered by other wording, and seems to conflict with
+D.1(17) anyway. The definition of the value of the pragma is never used
+anywhere, so far as I can tell.]
 
 Replace D.1(14):
 
@@ -850,10 +863,10 @@
 [Editor's Note: See the comment about "single task" in Storage_Size.]
 
 [Editor's note: Task types cannot be derived, and subprograms never
-inherit aspects, so we don't have to worry about aspect inheritance, other than from
-task interfaces (a new possibility). Should we make specifying the aspects for
-those illegal?? The inabilility to derive also means we cannot
-run afoul of 13.1(10).]
+inherit aspects, so we don't have to worry about aspect inheritance, other than
+from task interfaces (a new possibility). Should we make specifying the aspects
+for those illegal?? The inabilility to derive also means we cannot run afoul of
+13.1(10).]
 
 Replace D.2.6(12/2):
 
@@ -871,9 +884,9 @@
 deadline of a task is the value of Default_Deadline. [Redundant: The
 environment task is also given an initial deadline by this rule.]
 
-[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 when the 
-task is created (roughly).]
+[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
+when the task is created (roughly).]
 
 ===pragma CPU (the pragma is to be born obsolescent)
 
@@ -892,10 +905,10 @@
 [Editor's Note: See the comment about "single task" in Storage_Size.]
 
 [Editor's note: Task types cannot be derived, and subprograms never
-inherit aspects, so we don't have to worry about aspect inheritance, other than from
-task interfaces (a new possibility). Should we make specifying the aspects for
-those illegal?? The inabilility to derive also means we cannot
-run afoul of 13.1(10).]
+inherit aspects, so we don't have to worry about aspect inheritance, other than
+from task interfaces (a new possibility). Should we make specifying the aspects
+for those illegal?? The inabilility to derive also means we cannot run afoul of
+13.1(10).]
 
 Delete D.16(10/3). [Now in Annex J.]
 
@@ -971,7 +984,7 @@
 
 Legality Rules
 
-The first_subtype_local_name of a pragma Pack shall denote a composite 
+The first_subtype_local_name of a pragma Pack shall denote a composite
 subtype.
 
 Static Semantics
@@ -983,20 +996,20 @@
 
 Syntax
 
-The form of a pragma Inline, which is a program unit pragma (see 
+The form of a pragma Inline, which is a program unit pragma (see
 10.1.5), is as follows:
 
    pragma Inline(name {, name});
 
 Legality Rules
 
-The pragma shall apply to one or more callable entities or generic 
+The pragma shall apply to one or more callable entities or generic
 subprograms.
 
 [Editor's Note: "apply" comes from the definition of program unit pragma.
 
 Alternatively, we could have said:
-"The name of a pragma Inline shall apply to one or more callable entities or generic 
+"The name of a pragma Inline shall apply to one or more callable entities or generic
 subprograms that may have aspect Inline specified." which allows us to
 depend on the Legality Rules of the aspect. In that case, we'd want to swap
 the Legality Rules and Static Semantics sections. I didn't do this because
@@ -1011,7 +1024,7 @@
 
 AARM Ramification: Note that inline expansion is desired no matter
 what name is used in the call. This allows one to request inlining
-for only one of several overloaded subprograms as follows: 
+for only one of several overloaded subprograms as follows:
 
 package IO is
    procedure Put(X : in Integer);
@@ -1034,18 +1047,19 @@
 
 Implementation Permissions
 
-An implementation may allow a pragma Inline that has an argument which 
+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.
 
-AARM Reason: This is allowed for Ada 83 compatibility. This is only a 
+AARM Reason: This is allowed for Ada 83 compatibility. This is only a
 permission as this usage is considered obsolescent.
 
-AARM Discussion: We only need to allow this in declarative_parts, 
-because a body is only allowed in another body, and these all have declarative_parts.
+AARM Discussion: We only need to allow this in declarative_parts,
+because a body is only allowed in another body, and these all have
+declarative_parts.
 
 NOTES
 
-The name in a pragma Inline may denote more than one entity in the 
+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.3 Pragma No_Return
@@ -1053,15 +1067,15 @@
 Syntax
 
 The form of a pragma No_Return, which is a representation pragma (see 13.1),
-is as follows: 
+is as follows:
 
-  pragma No_Return(procedure_local_name{, procedure_local_name}); 
+  pragma No_Return(procedure_local_name{, procedure_local_name});
 
 Legality Rules
 
-Each procedure_local_name shall denote one or more procedures or generic procedures.
-[Redundant: The procedure_local_name shall not denote a null procedure nor an instance
-of a generic unit.]
+Each procedure_local_name shall denote one or more procedures or generic
+procedures. [Redundant: The procedure_local_name shall not denote a null
+procedure nor an instance of a generic unit.]
 
 Static Semantics
 
@@ -1072,13 +1086,15 @@
 
 Syntax
 
-The form of a pragma Controlled, which is a representation pragma (see 13.1), is as follows: 
+The form of a pragma Controlled, which is a representation pragma (see 13.1), is
+as follows:
 
   pragma Controlled(first_subtype_local_name);
 
 Legality Rules
 
-The first_subtype_local_name of a pragma Controlled shall denote a non-derived access subtype. 
+The first_subtype_local_name of a pragma Controlled shall denote a non-derived
+access subtype.
 
 Static Semantics
 
@@ -1090,115 +1106,126 @@
 
 Syntax
 
-The form of a pragma Unchecked_Union, which is a representation pragma (see 13.1), is as follows:
+The form of a pragma Unchecked_Union, which is a representation pragma (see
+13.1), is as follows:
 
   pragma Unchecked_Union (first_subtype_local_name);
 
 Legality Rules
 
-The first_subtype_local_name of a pragma Unchecked_Union shall denote an unconstrained discriminated
-record subtype having a variant_part.
+The first_subtype_local_name of a pragma Unchecked_Union shall denote an
+unconstrained discriminated record subtype having a variant_part.
 
 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 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.6  Pragma Asynchronous
 
 Syntax
 
-The form of a pragma Asynchronous, which is a representation pragma (see 13.1), is as follows: 
+The form of a pragma Asynchronous, which is a representation pragma (see 13.1),
+is as follows:
 
-  pragma Asynchronous(local_name); 
+  pragma Asynchronous(local_name);
 
 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.
+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
 
-The local_name of a pragma Asynchronous shall denote a declaration that may have aspect
-Asynchronous specified.
+The local_name of a pragma Asynchronous shall denote a declaration that may have
+aspect Asynchronous specified.
 
 J.15.7  Pragma Priority and Pragma Interrupt_Priority
 
 Syntax
 
-The form of a pragma Priority is as follows: 
+The form of a pragma Priority is as follows:
 
   pragma Priority(expression);
 
-The form of a pragma Interrupt_Priority is as follows: 
+The form of a pragma Interrupt_Priority is as follows:
 
-  pragma Interrupt_Priority[(expression)]; 
+  pragma Interrupt_Priority[(expression)];
 
 Name Resolution Rules
 
-The expected type for the expression in a Priority or Interrupt_Priority pragma is Integer. 
+The expected type for the expression in a Priority or Interrupt_Priority pragma
+is Integer.
 
 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 construct.
+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
+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 System.Priority. 
+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
 
-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:
-* 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.
+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:
+* 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 Interrupt_Priority aspect
-has the value Interrupt_Priority'Last.
+If there is no expression in an Interrupt_Priority pragma, the
+Interrupt_Priority aspect has the value Interrupt_Priority'Last.
 
 J.15.8  pragma CPU
 
-AARM Discussion: This pragma is born obsolescent; it is defined to provide consistency with
-existing real-time pragmas.
+AARM Discussion: This pragma is born obsolescent; it is defined to provide
+consistency with existing real-time pragmas.
 
 Syntax
 
-The form of a pragma CPU is as follows: 
+The form of a pragma CPU is as follows:
   pragma CPU (expression);
 
 Name Resolution Rules
 
-The expected type for the expression of a pragma CPU is System.Multiprocessors.CPU_Range.
+The expected type for the expression of a pragma CPU is
+System.Multiprocessors.CPU_Range.
 
 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 task_definition, or the
+declarative_part of a 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 declarative_part of a subprogram_body, the
+expression shall be static.
 
 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 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.
 
 J.15.9 pragma Relative_Deadline
 
 Syntax
 
-The form of a pragma Relative_Deadline is as follows: 
+The form of a pragma Relative_Deadline is as follows:
   pragma Relative_Deadline (relative_deadline_expression);
 
 Name Resolution Rules
@@ -1207,22 +1234,24 @@
 
 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 appear within a given
-construct.
+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
+appear within a given construct.
 
 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 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.
 
 J.15.10 pragma Storage_Size
 
 Syntax
 
-The form of a pragma Storage_Size is as follows: 
+The form of a pragma Storage_Size is as follows:
 
   pragma Storage_Size(expression);
 
@@ -1230,7 +1259,7 @@
 
 Name Resolution Rules
 
-The expression of a pragma Storage_Size is expected to be of any integer type. 
+The expression of a pragma Storage_Size is expected to be of any integer type.
 
 Static Semantics
 
@@ -1240,10 +1269,10 @@
 
 J.15.11 Pragmas Interrupt_Handler and Attach_Handler
 
-The form of a pragma Interrupt_Handler is as follows: 
+The form of a pragma Interrupt_Handler is as follows:
   pragma Interrupt_Handler(handler_name);
 
-The form of a pragma Attach_Handler is as follows: 
+The form of a pragma Attach_Handler is as follows:
   pragma Attach_Handler(handler_name, expression);
 
 Name Resolution Rules
@@ -1252,49 +1281,50 @@
 resolve to denote a protected procedure with a parameterless profile.
 
 For the Attach_Handler pragma, the expected type for the expression is
-Interrupts.Interrupt_Id (see C.3.2). 
+Interrupts.Interrupt_Id (see C.3.2).
 
 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 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. 
+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
 
-A pragma Interrupt_Handler specifies the Interrupt_Handler aspect for the
-protected procedure handler_name to have the value True. A pragma Attach_Handler
-specifies the Attach_Handler aspect for the protected procedure handler_name to
-have the value of the given expression [Redundant: as evaluated at object creation
-time].
+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
+[Redundant: as evaluated at object creation time].
 
 J.15.12 pragma Preelaborable_Initialization
 
   Syntax
 
    The form of a pragma Preelaborable_Initialization is as follows:
-     pragma Preelaborable_Initialization (direct_name); 
+     pragma Preelaborable_Initialization (direct_name);
 
   Static Semantics
     A pragma Preelaborable_Initialization specifies the
     Preelaborable_Initialization aspect (see 10.2.1) of the
-    type denoted by its argument is True. 
+    type denoted by its argument is True.
 
 [Editor's note: This is not a representation pragma since this is an operational
 aspect. Representation pragmas cannot be specified on partial views by 13.1(9).]
-  
+
   Legality Rules
     A Preelaborable_Initialization pragma shall appear in the visible part of
     a package or generic package.
 
     If the pragma appears in the first list of basic_declarative_items of a
-    package_specification, then the direct_name shall denote the first subtype of
-    a composite type such that the Preelaborable_Initialization
-    aspect of the type may be specified to be True, and the type shall be declared
-    immediately within the same package as the pragma.
+    package_specification, then the direct_name shall denote the first subtype
+    of a composite type such that the Preelaborable_Initialization aspect of the
+    type may be specified to be True, and the type shall be declared immediately
+    within the same package as the pragma.
 
     If the pragma appears in a generic_formal_part, then the direct_name shall
     denote a composite generic formal type declared in the same
@@ -1358,11 +1388,12 @@
 Boolean (True/False means the pragma is present/absent).
 
 
-The use of aspects as compared to pragmas is strongly preferred for subprograms (as
-there are no overloading problems to worry about; the target subprogram is obvious).
-The use of aspects is also preferred for types and objects, as the pragmas can
-get separated from the declarations and the declarations are (usually) short.
-There is no clear-cut decision for aspects applying to packages or other entities.
+The use of aspects as compared to pragmas is strongly preferred for subprograms
+(as there are no overloading problems to worry about; the target subprogram is
+obvious). The use of aspects is also preferred for types and objects, as the
+pragmas can get separated from the declarations and the declarations are
+(usually) short. There is no clear-cut decision for aspects applying to packages
+or other entities.
 
 Since we want to encourage the use of aspects, we make pragmas that can
 be replaced by aspects obsolescent, with the exception of pragmas that are