CVS difference for ai12s/ai12-0064-2.txt

Differences between 1.20 and version 1.21
Log of other versions for file ai12s/ai12-0064-2.txt

--- ai12s/ai12-0064-2.txt	2017/11/30 04:18:01	1.20
+++ ai12s/ai12-0064-2.txt	2017/12/16 04:13:46	1.21
@@ -1,4 +1,4 @@
-!standard 9.5(17/3)                                 17-10-14    AI12-0064-2/14
+!standard 9.5(17/3)                                 17-12-14    AI12-0064-2/15
 !standard 9.5.1(8)
 !standard 9.5.1(9)
 !standard 9.5.1(10)
@@ -10,10 +10,10 @@
 !standard 9.5.1(16)
 !standard 9.5.1(18)
 !standard 9.5.1(22.1/2)
-!standard 3.10.2(33/3)
+!standard 3.10.2(32/3)
 !standard 4.6(24.21/4)
 !standard 4.9(8)
-!standard 13.1.1(17/4)
+!standard 13.1.1(17/3)
 !standard 13.13.2(37/1)
 !class Amendment 15-10-17
 !status Amendment 1-2012 17-11-21
@@ -45,130 +45,6 @@
 execute any potentially blocking operations (other than deadlocking
 operations).
 
-[Summary of changes for October 2017 meeting:
-
-Added some proposal wording, and put in the missing !wording.
-
-Changed "blocking restriction expression" to "nonblocking expression" as
-requested. Changed many occurrences of "nonblocking expression" to
-"Nonblocking aspect" as suggested by Tucker.
-
-Changed "nonblocking-static" expressions to only allow combining with
-"and" and "and then", as requested. Note that I didn't change the wording
-for the "poor man's inference" (as Tucker called it), as I couldn't find
-any simplification. I considered replacing "and" and "and then" with
-"boolean operator or short-circuit form" (which have to be only "and" or
-"and then" in this context), but this is longer and doesn't seem to add
-any readability/understandability. In any case, we have to allow conforming
-to parts of an expression, and that seems to need some description of the
-parts in question. (If we just said "conform to some part of the expression",
-that would seem to leave a lot to the imagination, or to figuring out the
-details of the rules.) [This wording can be near around line 620 in this AI;
-I'm not giving exact numbers as editing changes the line numbers frequently.]
-
-Changed the "assume-the-best" and "assume-the-worst" rules to apply to
-stand-alone generic specifications and generic bodies as well as entities
-declared inside of them. (I noted this while describing the AI to the ARG in
-Vienna.) Since calls to subprograms that allow blocking can occur in the
-elaboration code of generic packages and in the bodies of generic subprograms,
-we need to know when and how to make checks on those calls. [This wording can
-be found at approximately lines 600-620 in this AI.]
-
-Minor: The nonblocking expression of a predefined operator of a composite
-type was "determined by" the expression of the type; I changed it to say
-it is "the same as" the expression of the type since that more clearly
-expresses the intent. (Else someone will ask "determined how"?).
-
-Note: We didn't discuss the Open Issue found near line 740; we need to decide
-how Nonblocking aspects will be added to the Standard library. I personally
-think we should write them all as aspects, since Global will have to be written
-that way, having both pragmas and aspects is ugly, and as such no Program Unit
-pragma Nonblocking is needed. But this needs discussion, as it changes the
-Barnes compromise.]
-
-[Summary of changes for June 2017 meeting: (Note: I kept this for the benefit
-of people who were not at the Vienna meeting.)
-
-Applied the minor wording changes requested during meeting #56 (Pittsburgh).
-
-Added definition of nonblocking-static expressions, to reply to a comment from
-Steve Baird that a static expression cannot have different values in a generic
-unit and its associated instance. This means that the nonblocking attribute
-cannot be static in some cases for a generic unit, and we still want to allow
-such attribute references to be used to specify nonblocking aspects. The value
-used to specify a nonblocking aspect needs to be known at compile-time, so that
-it can be used to enforce Legality Rules. Thus we need this term to allow only
-static expressions and Nonblocking attributes, and combinations of them.
-
-Nonblocking attributes are now static only if their prefix is not a generic
-unit nor declared in a generic unit.
-
-Tightened up the note 9.5.1(22.1/2) to say exactly what you have to do (specify
-the aspect to have the value True) rather than just "use" the aspect.
-
-Deleted a redundant rule about the Access attribute (it was given normatively
-in both 3.10.2 and 9.5).
-
-Finished the list of what needs to be done for non-container units. (Mostly
-adding "with Nonblocking => True"). Still need to figure out the list of
-paragraph numbers (I won't do that until we're pretty sure these rules are
-right).
-
-Moved the Legality Rules out of the aspect definition (it was just getting
-really long).
-
-Added the ability to specify the Nonblocking aspect for any type. This is
-used for the aspect of the predefined operators for composite types (and
-the previous uses for access-to-subprogram types). We allow it on all types
-so that private types completed by elementary types work; but we do not
-use it in generic matching unless the formal might be composite. Note that
-the Nonblocking aspect of an elementary type has no meaning at all other
-than to set the value of the corresponding attribute; it only exists so that
-private types completed by elementary types have a well-defined aspect.
-
-Changed nonblocking to be an operational aspect, as we need to be able to
-specify it on partial views.
-
-Moved the rules about predefined operators into the aspect definition, since
-they sometimes contradicted the other rules in that section (which isn't going
-to work.) Elementary predefined operators are always nonblocking (this is
-important if they re-emerge).
-
-Added a rule that if a composite type is specified to be nonblocking, then the
-type is illegal if any of the "=" operators used to implement its predefined
-"=" allow blocking. This is a lot easier way to get nonblocking "=" than trying
-to calculate that from all of the used "=" operators.
-
-Nonblocking is now an expression-valued aspect, so that it makes sense inside
-of generic units. Outside of any generic, it is required to be static so that
-we can enforce Legality Rules based on an unambiguous value. In order to
-follow the model of preconditions, the expression is given a name, the
-"nonblocking expression". I changed as many uses as possible to use
-this name; it makes more sense than talking about the "value of the
-Nonblocking aspect" when that might be a complex expression. (When Tucker
-reviewed the AI, he asked me to remove most of the remaining uses of "value",
-which did seem to improve the understandability.)
-
-Adopted a much more complex set of "assume-the-worst" rules for generic
-bodies. These are only needed if someone messes up the declaration of a
-generic unit (but that's likely to happen soon or later). See the discussion
-for examples of why we need these complex rules.
-
-Nonblocking for formal parameters is always that of the actual (unless it is
-directly specified); it no longer inherits from the surrounding unit. That
-eliminates matching checks for an instantiation in the normal case; matching
-is only necessary if the aspect is specified for the formal (which we allow).
-This change causes mistakes in defining the nonblocking aspects of a generic
-unit to make that unit illegal; the previous definition meant that they usually
-made the instance illegal instead (which clearly would be harder to debug and
-rather late as well).
-
-Tightened up the definition of the attributes, so they make more sense as
-expressions, and explicitly stated where the underlying expression is
-evaluated.]
-
----
-
 !wording
 
 [Editor's note: Individual rule changes scattered throughout the Standard
@@ -195,7 +71,7 @@
 
       AARM Reason: We define the term "nonblocking-static expression" so that
       nonblocking attribute references can be used to define the value of
-      other nonblocking aspects, but we don't allow anything with a value
+      other nonblocking aspects, but we don't allow anything else with a value
       not known at compile-time.
      
    For a program unit, for a task entry, for a formal package, formal
@@ -317,7 +193,7 @@
        literal True.
 
          AARM Reason: Enumeration literals can be renamed as functions,
-         and passed to generic formal functions, so we need to defined
+         and passed to generic formal functions, so we need to define
          the value of the aspect so the other rules are meaningful.
 
        For a predefined operator of an elementary type the Nonblocking 
@@ -574,11 +450,11 @@
       so long as they occur outside of any generic unit. The Nonblocking
       aspect of a generic unit will often depend on the actual parameters
       of the unit, so it cannot be static (or have any well-defined value).
-      We need this latter rule in case the attribute of an entity declared in
+      We need this latter rule in case the attribute of 
       a generic is used outside of the generic. Note that the previous rule
       makes it illegal to use such an attribute to specify aspect Nonblocking
       outside of a generic, but we don't want to allow any other uses since
-      it does not have a static value until instantiated.
+      it does not have a known value until instantiated.
 
       AARM Ramification: This rule does not apply to instances of generic
       units and entities declared within them.
@@ -634,7 +510,7 @@
         shall be nonblocking.
 
     In addition to the places where Legality Rules normally apply
-    (see 12.3), the above rules apply also in the private part of an
+    (see 12.3), the above rules also apply in the private part of an
     instance of a generic unit.
 
       AARM Ramification: For a generic formal parameter to be nonblocking
@@ -723,7 +599,7 @@
   runtime with just pragma Detect_Blocking -- why would anyone want to take
   the risk of an unexpected Program_Error if compile-time checks are available?]
 
-Modify 3.10.2(33/3): [Part of the definition of the Access attribute for subprograms]
+Modify 3.10.2(32/3): [Part of the definition of the Access attribute for subprograms]
 
    ...  The accessibility level of P shall not be statically deeper than that
    of S. {If S is nonblocking, P shall be nonblocking. }In addition to the
@@ -755,8 +631,6 @@
 language-defined. In this particular case, the rule itself is fine (it says
 "Unless otherwise specified...").]
 
-Add Nonblocking to the list of operational aspects in AARM  13.1(8.mm-rr/1).
-
 Remove generic_formal_parameter_declaration from the list in 13.1.1(17/5).
 
 [Editor's note: Nonblocking is allowed there, of course, so the statement will
@@ -785,28 +659,15 @@
    stream-oriented attributes must allow blocking as well.
 
 
-Wording for definition of language-defined packages and subprograms is TBD.
-These are just appropriate aspect clauses, and in a few cases, the deletion
-of the English text that says something is potentially blocking.
+Wording for definition of language-defined packages and subprograms is given
+in AI12-0064-2. These are just appropriate aspect clauses, and in a few cases,
+the deletion of the English text that says something is potentially blocking.
 
 If a language-defined package needs to add Nonblocking, any pragma will
-also be changed to the aspect form at the same time. [Author's note: I've
-discussed this issue with John; he mainly does not want that to happen
-for an empty package. The only empty language-defined package is Ada, and
-that is Pure so no change is needed at this time.]
-
-For instance, we'll change
-
-    package Ada.Command_Line is
-       pragma Preelaborate(Command_Line);
+also be changed to the aspect form at the same time.
 
-to
+[Lengthy Editor's note: (Preserved here as it was part of the approved AI.)
 
-    package Ada.Command_Line
-       with Preelaborate, Nonblocking is
-
-[Lengthy Editor's note:
-
 We intend that language-defined subprograms are nonblocking
 unless this Standard says otherwise. Specifically, 9.5.1(18) said (before we
 deleted it above):
@@ -1449,6 +1310,406 @@
 routines, depending on which of the formal routines they are allowed to use.
 (Given that we leave that unspecified in the Standard, it's probably better to
 use a global setting as was done here.)
+
+!corrigendum 3.10.2(32/3)
+
+@drepl
+@xindent<P'Access yields an access value that designates the subprogram
+denoted by P. The type of P'Access is an access-to-subprogram
+type (@i<S>), as determined by the expected type. The accessibility
+level of P shall not be statically deeper than that of @i<S>. In
+addition to the places where Legality Rules normally apply (see
+12.3), this rule applies also in the private part of an instance
+of a generic unit. The profile of P shall be subtype conformant
+with the designated profile of @i<S>, and shall not be Intrinsic.
+If the subprogram denoted by P is declared within a generic unit,
+and the expression P'Access occurs within the body of that generic
+unit or within the body of a generic unit declared within
+the declarative region of the generic unit, then the ultimate ancestor
+of @i<S> shall be either a nonformal type declared within the generic
+unit or an anonymous access type of an access parameter.>
+@dby
+@xindent<P'Access yields an access value that designates the subprogram
+denoted by P. The type of P'Access is an access-to-subprogram
+type (@i<S>), as determined by the expected type. The accessibility
+level of P shall not be statically deeper than that of @i<S>.
+If @i<S> is nonblocking, P shall be nonblocking. In
+addition to the places where Legality Rules normally apply (see
+12.3), these rules apply also in the private part of an instance
+of a generic unit. The profile of P shall be subtype conformant
+with the designated profile of @i<S>, and shall not be Intrinsic.
+If the subprogram denoted by P is declared within a generic unit,
+and the expression P'Access occurs within the body of that generic
+unit or within the body of a generic unit declared within
+the declarative region of the generic unit, then the ultimate ancestor
+of @i<S> shall be either a nonformal type declared within the generic
+unit or an anonymous access type of an access parameter.>
+
+!corrigendum 4.6(24.21/4)
+
+@dinsa
+@xinbull<The accessibility level of the operand type shall not be statically
+deeper than that of the target type. If the operand type is declared within a
+generic body, the target type shall be declared within the generic body.>
+@dinst
+@xinbull<If the target type is nonblocking, the operand type shall be
+nonblocking.>
+
+!corrigendum 4.9(8)
+
+@dinsa
+@xbullet<an @fa<attribute_reference> whose @fa<prefix> statically denotes a
+statically constrained array object or array subtype, and whose
+@fa<attribute_designator> is First, Last, or Length, with an optional dimension;>
+@dinst
+@xbullet<an @fa<attribute_reference> whose @fa<prefix> denotes a non-generic
+entity that is not declared in a generic unit, and whose
+@fa<attribute_designator> is Nonblocking;>
+
+!corrigendum 9.5(17/3)
+
+@dinsa
+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. 
+@dinss
+@s8<@i<Static Semantics>>
+
+An @fa<expression> is @i<nonblocking-static> if it is one of the following:
+
+@xbullet<a static expression;>
+
+@xbullet<a Nonblocking @fa<attribute_reference>;>
+
+@xbullet<a call to a predefined boolean logical operator @b<and> where each
+operand is nonblocking-static;>
+
+@xbullet<an @b<and then> short-circuit control form where each operand is
+nonblocking-static;>
+
+@xbullet<a parenthesized nonblocking-static @fa<expression>.>
+
+For a program unit, for a task entry, for a formal package, formal
+subprogram, formal object of an anonymous access-to-subprogram type, 
+enumeration literal, and for a type (including a formal type), the
+following language-defined operational aspect is defined:
+
+@xhang<@xterm<Nonblocking>
+This aspect specifies the blocking restriction for the entity; it shall
+be specified by an @fa<expression>, called a @i<nonblocking expression>. If
+directly specified, the @fa<aspect_definition> shall be a
+nonblocking-static expression. The expected type for the @fa<expression> is
+the predefined type Boolean. The @fa<aspect_definition> can be
+omitted from the specification of this aspect; in that case the
+nonblocking expression for the entity is the enumeration literal True.>
+
+@xindent<The Nonblocking aspect may be specified for all entities for
+which it is defined, except for protected operations and
+task entries. In particular, Nonblocking may be specified for
+generic formal parameters.>
+
+@xindent<When the nonblocking expression is static for an entity,
+the expression is evaluated to produce a static value for the aspect.
+When aspect Nonblocking is statically False for an entity, the entity
+might contain a potentially blocking operation; such an entity @i<allows
+blocking>. If the aspect is statically True for an entity, the entity
+is said to be @i<nonblocking>.>
+
+@xindent<For a generic instantiation and entities declared within such an
+instance, the aspect is determined by the nonblocking
+expression for the corresponding entity of the generic unit, with
+any Nonblocking attributes of the generic formal parameters replaced
+by the appropriate nonblocking expression of the corresponding actual
+parameters. If the aspect is directly specified for an instance, the
+specified expression shall be static and have the same value as the
+nonblocking expression of the instance (after replacement).>
+
+@xindent<For a (protected or task) entry, the Nonblocking aspect is
+the Boolean literal False.>
+
+@xindent<For an enumeration literal, the Nonblocking aspect is the Boolean
+literal True.>
+
+@xindent<For a predefined operator of an elementary type the Nonblocking 
+aspect is the Boolean literal True. For a predefined operator of a
+composite type, the Nonblocking aspect of the operator is
+the same as the Nonblocking aspect for the type.>
+
+@xindent<For a dereference of an access-to-subprogram type, the Nonblocking
+aspect of the designated subprogram is that of the access-to-subprogram type.>
+
+@xindent<For a full type declaration that has a partial view, the
+aspect is the same as that of the partial view.>
+
+@xindent<For an inherited primitive dispatching subprogram that is null or
+abstract, the subprogram is nonblocking if and only if a corresponding
+subprogram of at least one ancestor is nonblocking. For any other
+inherited subprogram, it is nonblocking if and only if the
+corresponding subprogram of the parent is nonblocking.>
+
+@xindent<Unless directly specified, overridings of dispatching operations
+inherit this aspect.>
+
+@xindent<Unless directly specified, for a formal type, formal package, or
+formal subprogram, the aspect is that of the actual type, package, or
+subprogram.>
+
+@xindent<Unless directly specified, for a derived type the Nonblocking 
+aspect is that of the parent type.>
+
+@xindent<Unless directly specified, for any other program unit, type, or formal
+object, the Nonblocking aspect of the entity is determined by the
+Nonblocking aspect for the innermost program unit enclosing the entity.>
+
+@xindent<If not specified for a library unit, the nonblocking expression
+is the Boolean literal True if the library unit is declared pure and is
+not a generic unit, and the Boolean literal False otherwise.>
+
+For a @fa<prefix> S that denotes a subprogram (including a formal subprogram):
+
+@xhang<@xterm<S'Nonblocking>
+Denotes whether subprogram S is considered nonblocking; the type
+of this attribute is the predefined type Boolean.>
+
+@xindent<The @fa<prefix> S shall statically denote a subprogram.>
+
+@xindent<S'Nonblocking represents the nonblocking expression of S;
+evaluation of S'Nonblocking evaluates that expression.>
+
+For a @fa<prefix> P that denotes a package (including a formal package):
+
+@xhang<@xterm<P'Nonblocking>
+Denotes whether package P is considered nonblocking; the type
+of this attribute is the predefined type Boolean.
+P'Nonblocking represents the nonblocking expression of P;
+evaluation of P'Nonblocking evaluates that expression.>
+
+For a @fa<prefix> S that denotes a subtype (including formal subtypes):
+
+@xhang<@xterm<S'Nonblocking>
+Denotes whether predefined operators (and in the case of
+access-to-subprogram subtypes) a subprogram designated by a value of
+type S are considered nonblocking; the type of this attribute is the
+predefined type Boolean. S'Nonblocking represents the nonblocking
+expression of S; evaluation of S'Nonblocking evaluates that expression.>
+
+The following are defined to be @i<potentially blocking> operations:
+
+@xbullet<a @fa<select_statement>;>
+
+@xbullet<an @fa<accept_statement>;>
+
+@xbullet<an @fa<entry_call_statement>, or a call on a procedure that
+renames or is implemented by an entry;>
+
+@xbullet<a @fa<delay_statement>;>
+
+@xbullet<an @fa<abort_statement>;>
+
+@xbullet<task creation or activation;>
+
+@xbullet<during a protected action, an external call on a protected subprogram
+(or an external requeue) with the same target object as that of the
+protected action;>
+
+@xbullet<a call on a subprogram whose body contains a potentially blocking
+operation.>
+
+If a language-defined subprogram allows blocking, then a call on the
+subprogram is a potentially blocking operation.
+
+@s8<@i<Legality Rules>>
+
+A nonblocking program unit shall not contain, other than within
+nested units with Nonblocking specified as statically False, a call on a
+callable entity for which the Nonblocking aspect is statically False, nor
+shall it contain any of the following:
+
+@xbullet<a @fa<select_statement>;>
+
+@xbullet<an @fa<accept_statement>;>
+
+@xbullet<a @fa<delay_statement>;>
+
+@xbullet<an @fa<abort_statement>;>
+
+@xbullet<task creation or activation.>
+
+For the purposes of the above rule, an @fa<entry_body> is considered
+nonblocking if the immediately enclosing protected unit is nonblocking.
+
+A subprogram shall be nonblocking if it overrides a nonblocking
+dispatching operation. An entry shall not implement a nonblocking
+procedure. If an inherited dispatching subprogram allows blocking, then
+the corresponding subprogram of each ancestor shall allow blocking.
+
+It is illegal to specify aspect Nonblocking for the full view of a type
+that has a partial view.
+
+Aspect Nonblocking shall be specified for a derived type only if it
+fully conforms to the nonblocking expression of the ancestor type
+or if it is specified to have the Boolean literal True.
+
+If aspect Nonblocking is specified for an entity that is not a generic
+unit or declared inside of a generic unit, the @fa<aspect_definition> shall
+be a static expression.
+
+If the prefix of a Nonblocking @fa<attribute_reference> denotes a generic
+unit @i<G>, the reference shall occur within the declarative region of @i<G>.
+
+The predefined equality operator for a composite type is illegal if it is
+nonblocking and, for a record type, it is not overridden by a primitive
+equality operator, and:
+
+@xbullet<for a record type, the parent primitive "=" allows blocking; or>
+
+@xbullet<any component that has a record type that has a primitive "=" that
+allows blocking; or>
+
+@xbullet<any component that has a non-record type that has a predefined "="
+that allows blocking.>
+
+In a generic instantiation (after replacement in the nonblocking 
+expressions by values of the actuals as described previously):
+
+@xbullet<the actual subprogram corresponding to a nonblocking formal
+subprogram shall be nonblocking (an actual that is an
+entry is not permitted in this case);>
+
+@xbullet<the actual type corresponding to a nonblocking formal
+private, derived, array, or access-to-subprogram type shall
+be nonblocking;>
+
+@xbullet<the actual object corresponding to a formal object of a
+nonblocking access-to-subprogram type shall be of a nonblocking
+access-to-subprogram type;>
+
+@xbullet<the actual instance corresponding to a nonblocking formal package
+shall be nonblocking.>
+
+In addition to the places where Legality Rules normally apply
+(see 12.3), the above rules also apply in the private part of an
+instance of a generic unit.
+
+A program unit @i<P> declared inside of a generic unit but not in a generic body
+or that is a generic specification not declared in a generic unit
+is considered nonblocking for the purposes of checking the restrictions on a
+nonblocking unit only if the value of its Nonblocking aspect is statically
+True. For the purposes of checks in @i<P>, a call to a subprogram is considered
+nonblocking unless the value of its Nonblocking aspect is statically False.
+
+A program unit @i<P> declared inside of a generic body or that is a generic body
+is considered nonblocking for the purposes of checking the restrictions on a
+nonblocking unit unless the value of its Nonblocking aspect is statically
+False. For the purposes of checks in @i<P>, a call to a subprogram is considered
+to allow blocking unless:
+
+@xbullet<the value of its Nonblocking aspect is statically True, or>
+
+@xbullet<its nonblocking expression (that is, Nonblocking aspect)
+conforms exactly to that of @i<P>, or conforms to some part of the
+nonblocking expression of @i<P> that is combined with the remainder of the
+nonblocking expression of @i<P> by one or more @b<and> or @b<and then>
+operations.>
+
+!corrigendum 9.5.1(8)
+
+@drepl
+During a protected action, it is a bounded error to invoke an operation that
+is @i<potentially blocking>. The following are defined to be potentially
+blocking operations: 
+@dby
+During a protected action, it is a bounded error to invoke an operation that
+is potentially blocking (see 9.5).
+
+!corrigendum 9.5.1(9)
+
+@ddel
+@xbullet<a @fa<select_statement>;>
+
+!corrigendum 9.5.1(10)
+
+@ddel
+@xbullet<an @fa<accept_statement>;>
+
+!corrigendum 9.5.1(11)
+
+@ddel
+@xbullet<an @fa<entry_call_statement>;>
+
+!corrigendum 9.5.1(12)
+
+@ddel
+@xbullet<a @fa<delay_statement>;>
+
+!corrigendum 9.5.1(13)
+
+@ddel
+@xbullet<an @fa<abort_statement>;>
+
+!corrigendum 9.5.1(14)
+
+@ddel
+@xbullet<task creation or activation;>
+
+!corrigendum 9.5.1(15)
+
+@ddel
+@xbullet<an external call on a protected subprogram (or an external requeue)
+with the same target object as that of the protected action;>
+
+!corrigendum 9.5.1(16)
+
+@ddel
+@xbullet<a call on a subprogram whose body contains a potentially blocking
+operation.>
+
+!corrigendum 9.5.1(18)
+
+@ddel
+Certain language-defined subprograms are potentially blocking. In particular,
+the subprograms of the language-defined input-output packages that manipulate
+files (implicitly or explicitly) are potentially blocking. Other potentially
+blocking subprograms are identified where they are defined. When not
+specified as potentially blocking, a language-defined subprogram is
+nonblocking. 
+
+!corrigendum 9.5.1(22.1/2)
+
+@drepl
+@xindent<@s9<22  The @fa<pragma> Detect_Blocking may be used to ensure that all
+executions of potentially blocking operations during a protected action
+raise Program_Error. See H.5.>>
+@dby
+@xindent<@s9<22  The aspect Nonblocking can be specified True on the definition
+of a protected unit in order to reject most attempts to use potentially
+blocking operations within the protected unit (see 9.5). The @fa<pragma>
+Detect_Blocking may be used to ensure that any remaining executions of
+potentially blocking operations during a protected action raise Program_Error.
+See H.5.>>
+
+!corrigendum 13.1.1(17/5)
+
+@drepl
+There are no language-defined aspects that may be specified on a
+@fa<renaming_declaration>, a @fa<generic_formal_parameter_declaration>,
+a @fa<subunit>, a @fa<package_body>, a @fa<task_body>, a @fa<protected_body>,
+an @fa<entry_body>, or a @fa<body_stub> other than a @fa<subprogram_body_stub>.
+@dby
+There are no language-defined aspects that may be specified on a
+@fa<renaming_declaration>, a @fa<subunit>, a @fa<package_body>,
+a @fa<task_body>, a @fa<protected_body>, an @fa<entry_body>, or a @fa<body_stub>
+other than a @fa<subprogram_body_stub>.
+
+!corrigendum 13.13.2(37/1)
+
+@dinsa
+In the default implementation of Read and Input for a type, End_Error is raised
+if the end of the stream is reached before the reading of a value of the type
+is completed.
+@dinst
+The aspect Nonblocking is the Boolean literal False for the default
+implementations of stream-oriented attributes.
+
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent