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

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

--- ai12s/ai12-0064-2.txt	2016/06/07 00:38:33	1.3
+++ ai12s/ai12-0064-2.txt	2016/08/30 21:52:44	1.4
@@ -1,5 +1,20 @@
-!standard 9.5.1(11)                                16-06-02    AI12-0064-2/02
+!standard 9.5(17/3)                                 16-08-29    AI12-0064-2/03
+!standard 9.5.1(8)
+!standard 9.5.1(9)
+!standard 9.5.1(10)
+!standard 9.5.1(11)
+!standard 9.5.1(12)
+!standard 9.5.1(13)
+!standard 9.5.1(14)
+!standard 9.5.1(15)
+!standard 9.5.1(16)
 !standard 9.5.1(18)
+!standard 3.10.2(33/3)
+!standard 4.5(9)
+!standard 4.6(24.21/4)
+!standard 4.9(8)
+!standard 13.1.1(17/4)
+!standard 13.13.2(37/1)
 !class Amendment 15-10-17
 !status work item 15-12-18
 !status received 15-10-17
@@ -22,47 +37,73 @@
 
 !proposal
 
-Modify 3.10.2(33/3):
+[Summary of changes for October 2016 meeting:
 
-   ...  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
-   places where Legality Rules normally apply (see 12.3),
-   {these rules apply}[this rule applies] also in the private part of an
-  instance of a generic unit.
+Defined the term "allows blocking", as "not nonblocking" or "aspect Nonblocking
+has the value False" are awkward.
 
-Add after 4.6(24.21/4): [Type conversion Legality Rules for access-to-subprogram types]
+Redid the definition of the aspect so that it is defined for all program units
+and for task entries. (Even though not all entities allow it to be specified.)
+We also defined the aspect Nonblocking to always have the value False for entries.
 
-  * If the target type is nonblocking, the operand type shall be nonblocking. 
+Changed default value of S'Nonblocking for a formal subprogram in the generic
+specification (as requested in Pisa).
 
-[Editor's note: This was moved from Tucker's explicit wording; we're not
-scattering conversion rules all over the Standard.]
+Removed special case for synchronized interfaces, and added an AARM note to
+explain why that's not needed. (also from Pisa).
 
-Add after 4.9(8):
+Removed special case for renames of entries, (and entry calls in general), and
+added an AARM note to explain why.
 
-  * an attribute_reference whose designator is Nonblocking;
+Added an AARM note to highlight that a routine that overridings an allows
+blocking routine (like Finalize) can still be declared nonblocking itself.
+(Else any non-trivial finalization, allocation, and streaming could never be
+used in nonblocking code.)
+
+Added changes to 13.1 and 13.1.1 to eliminate the "no language-defined aspectcs
+can be specified on generic formal parameters", 'cause it's clearly not true.
+
+Changed "program unit" to "entity" in various places, as formal parameters,
+access-to-subprogram types, and other things aren't program units.
+
+Moved most of the text from 9.5.1 to 9.5 along with these new definitions.
+
+Redid the note at the end of 9.5.1 to suggest the use of aspect Nonblocking on
+protected units, as well as Detect_Blocking to clean up anything missed.
+
+Started work on a list of changes to language-defined units. This pointed
+out the need for the nonblocking attribute for formal packages, so that
+was defined.]
 
-Modify 9.5.1(11):
 
-  * an entry_call_statement{, or a call on a procedure that
-    renames or is implemented by an entry};
-    
-Add after 9.5.1(18):
+[Editor's note: Individual rule changes scattered throughout the Standard
+follow this primary definition.]
 
-   For a program unit other than a protected operation, for
+Add after 9.5(17/3):
+
+   Static Semantics
+
+   For a program unit, for a task entry, for
    a formal package, formal subprogram, formal object of an anonymous
    access-to-subprogram type, and for a named access-to-subprogram type
    (including a formal type), the following language-defined
-   representation aspect may be specified:
+   representation aspect is defined:
 
    Nonblocking
 
        The type of aspect Nonblocking is Boolean. When aspect
-       Nonblocking is False for a program unit, the entity might contain
-       a potentially blocking operation. If the aspect is True for a
-       program unit, the program unit is said to be *nonblocking*. If
-       directly specified, the aspect_definition shall be a static
-       expression. This aspect is inherited by overridings of
+       Nonblocking is False for an entity, the entity might contain
+       a potentially blocking operation; such an entity *allows blocking*.
+       If the aspect is True for an entity, the entity is said to be
+       *nonblocking*. This aspect is inherited by overridings of
        dispatching subprograms.
+
+[Editor's note: This last sentence seems like nonsense, given that we
+want to allow nonblocking overridings of allows blocking subprograms.
+(If we don't allow that, then no finalization, allocation, or streaming
+could ever be nonblocking, which seems wrong.) I think it really means
+that the inherited primitive subprograms inherit the attribute unless
+otherwise specified. But maybe it's just trying to set a default?? Dunno.]
      
          AARM Ramification: specifying Nonblocking is False imposes
          no requirements. Specifying Nonblocking is True imposes
@@ -70,20 +111,27 @@
          prevent deadlock. pragma Detect_Blocking can be used to ensure
          that Program_Error is raised in a deadlock situation.
 
+       The Nonblocking aspect may be specified for all entities for
+       which it is defined, except for protected operations and
+       task entries. If directly specified, the aspect_definition shall
+       be a static expression. 
+
        For a generic instantiation, the aspect is determined by the setting
        for the generic unit[Redundant, re-evaluated based on the actual
        parameters.] If the aspect is directly specified for an instance,
        the value shall be confirming.
 
-       AARM Ramification: The value for the generic unit might be different
-       than that for the instance if it involves one or more Nonblocking
-       attribute references.
+         AARM Ramification: The value for the generic unit might be different
+         than that for the instance if it involves one or more Nonblocking
+         attribute references.
 
        [Editor's note: I'm presuming that all of the contents of the instance
        are re-evaluated by the rules of 12.3. I didn't go look that up, so
        we might need a special rule to force that; but it would be the
        expected "macro" behavior.]
 
+       For a (protected or task) entry, the value of the aspect is False.
+
        For any other program unit, formal package,
        formal subprogram, formal object, or (formal) access-to-subprogram
        type, the aspect is determined by the setting for the innermost
@@ -100,30 +148,36 @@
 
          * a select_statement;
          * an accept_statement;
-         * entry_call_statement or a call on a procedure that renames an entry;
-         * a call on a primitive procedure of a synchronized tagged type that
-           does not have Synchronization aspect of By_Protected_Procedure;
-
-[Editor's note: The above rewording is from the ARG meeting #54 minutes. But
-can't a primitive procedure of a limited interface type be implemented by an
-entry??? Nothing in the Legality Rules of 3.9.4 prevent it, and the example
-in 3.9.4 shows that it would be possible indirectly at a minimum. Consider
-that Append could be implemented by an entry for the synchronized interface
-in that example. Thus this rule needs to include limited interfaces (which,
-unfortunately, would effectively prevent them from being used in nonblocking
-contexts - unless we extended the aspect to interfaces, in which case we'd
-need some additional matching rules).]
-
          * a delay_statement;
          * an abort_statement;
          * task creation or activation.
-
-       AARM Ramification: Implicit calls for finalization, storage pools, and
-       the like are covered by the above prohibition. The rules above say
-       "a call", not "an explicit call".
 
-[Editor's note: The above note was added to address Steve's concern about
-implicit calls.]
+         AARM Ramification: Implicit calls for finalization, storage pools, and
+         the like are covered by the above prohibition. The rules above say
+         "a call", not "an explicit call". Such calls are considered statically
+         bound when that is possible, that is when the controlling object has
+         a known specific type (even if the actual implementation uses dispatching).
+
+         AARM Discussion: We don't need to specially worry about subprograms of
+         limited interfaces that are implemented by entries, as any such
+         subprogram necessarily has the value False for the Nonblocking aspect,
+         and thus is already covered by the prohibition against calling such
+         subprograms.
+
+         Similarly, we don't need to worry specially about entry calls, as they
+         will be detected by the prohibition against calls to entities with the
+         Nonblocking aspect False.
+         End AARM Discussion.
+
+       For the purposes of the above rule, an entry_body is considered
+       nonblocking if the immediately enclosing protected unit is nonblocking.
+
+         AARM Reason: An entry always allows blocking (by rule); but we want to
+         be able to compile-time check for most violations of prohibition against
+         potentially blocking operations in a protected action (in 9.5.1). We do
+         that by using the nonblocking status of the protected unit as the
+         controlling factor, and enforce that by not allowing the specification
+         of the Nonblocking aspect for any protected operation.
 
        A subprogram shall be nonblocking if it overrides a nonblocking
        dispatching operation. An entry shall not implement a
@@ -131,12 +185,17 @@
        nonblocking access-to-subprogram type, the subprogram denoted by
        the prefix shall be nonblocking.
 
-       AARM Discussion: Rules elsewhere in the standard (4.6 and 3.10.2)
-       ensure that access-to-subprogram conversion and the Access attribute
-       enforce nonblocking.
-
-[Editor's note: I moved those rules, leaving this note for the language-lawyer
-reader.]
+         AARM Discussion: Rules elsewhere in the standard (4.6 and 3.10.2)
+         ensure that access-to-subprogram conversion and the Access attribute
+         enforce nonblocking.
+
+         AARM Ramification: A nonblocking subprogram can override one that
+         allows blocking, but the reverse is illegal. Thus one can declare
+         a Finalize subprogram to be nonblocking, even though it overrides a
+         routine that allows blocking. (This works as a nonblocking subprogram
+         allows a strict subset of the operations allowed in allows blocking
+         subprograms, so calling such a subprogram as if it allows blocking
+         -- as is necessary in a dispatching call -- is harmless.)
        
        In a generic instantiation:
        
@@ -163,7 +222,10 @@
        unit has to explicitly specify aspect Nonblocking to be True.
        In particular, these rules do not apply when it or some enclosing unit
        specifies aspect Nonblocking to be an expression involving attribute
-       Nonblocking of a generic formal parameter (see below).
+       Nonblocking of a generic formal parameter (see below). However, in
+       such a case, these rules do apply in the instance of the specification
+       of the generic unit (the normal re-checking is needed). For instance,
+       the body of an expression function might make a prohibited call.
             
 For a prefix S that denotes a subprogram (including a formal subprogram): 
 
@@ -173,25 +235,44 @@
        static].
 
        The prefix S shall statically denote a subprogram.
+
+         AARM Ramification: The evaluation of the prefix S will have no effect,
+         which is necessary for S'Nonblocking to be static. For the intended
+         use in aspect specifications, we don't want any evaluation, as it
+         would happen at some freezing point.
+
+       If S denotes a formal subprogram of a generic unit G, the value of
+       S'Nonblocking is True within the body of G or within the body of a
+       generic unit declared within the declarative region of G, and False
+       otherwise. Otherwise, S'Nonblocking returns the value of the
+       Nonblocking aspect of S.
+
+         AARM Reason: Inside the generic body of G (and the bodies of generic
+         child units of G), we assume the worst about S'Nonblocking, so we
+         enforce the nonblocking restrictions on entities that use it to define
+         their own nonblocking aspect. In the specification of G, we
+         assume-the-best and expect the Legality Rules (all of them) to be
+         rechecked in the instance. This does not impose any requirement on
+         the formal subprogram (that can be done by specifying the value of the
+         aspect).
+
+         AARM To Be Honest: In an instance, S'Nonblocking returns the value
+         of the nonblocking aspect of the actual subprogram, even if referenced
+         through the name of the formal.
 
-       AARM Ramification: The evaluation of the prefix S will have no effect,
-       which is necessary for S'Nonblocking to be static. For the intended
-       use in aspect specifications, we don't want any evaluation, as it
-       would happen at some freezing point.
-
-       If S denotes a formal subprogram, the value of S'Nonblocking is True.
-       Otherwise, S'Nonblocking returns the value of the Nonblocking aspect
-       of S.
-
-       AARM Reason: Inside a generic unit, we assume the worst about
-       S'Nonblocking, so we enforce the nonblocking restrictions on
-       entities that use it to define their own nonblocking aspect. The
-       actual subprogram does not have to be nonblocking.
-
-       AARM To Be Honest: In an instance, S'Nonblocking returns the value
-       of the nonblocking aspect of the actual subprogram, even if referenced
-       through the name of the formal.
+For a prefix P that denotes a package (including a formal package): 
 
+P'Nonblocking
+       Denotes whether package P is considered nonblocking; the value
+       of this attribute is of type Boolean, Redundant[and is always
+       static].
+
+       If P denotes a formal package of a generic unit G, the value of
+       P'Nonblocking is True within the body of G or within the body of a
+       generic unit declared within the declarative region of G, and False
+       otherwise. Otherwise, P'Nonblocking returns the value of the
+       Nonblocking aspect of P.
+
 For a prefix S that denotes an access-to-subprogram subtype (including formal
 access-to-subprogram subtypes): 
 
@@ -202,30 +283,147 @@
 
        The prefix S shall statically denote a subtype. [Editor's note:
        is it possible for it not to? If not, we don't need this rule.]
+
 
-Wording Locations TBD:
+[Editor's note: The following is moved from 9.5.1, including the AARM notes
+with minimal changes. The entry_call_statement rule had been previously
+identified as needing a change (it's really broken, having nothing specifically
+to do with this AI).]
+
+The following are defined to be *potentially blocking* operations: 
+
+  AARM Reason: The primary purpose of these rules is to define what operations
+  are not allowed in a protected operation (blocking is not allowed). Some of
+  these operations are not directly blocking. However, they are still treated
+  as potentially blocking, because allowing them in a protected action might
+  impose an undesirable implementation burden. 
+
+  * a select_statement;
+  * an accept_statement;
+  * an entry_call_statement, or a call on a procedure that
+    renames or is implemented by an entry;
+  * a delay_statement;
+  * an abort_statement;
+  * task creation or activation;
+  * an external call on a protected subprogram (or an external requeue) with
+    the same target object as that of the protected action; 
+
+  AARM Reason: This is really a deadlocking call, rather than a blocking call,
+  but we include it in this list for simplicity. 
+
+  * a call on a subprogram whose body contains a potentially blocking operation. 
+
+  AARM Reason: This allows an implementation to check and raise Program_Error as
+  soon as a subprogram is called, rather than waiting to find out whether it
+  actually reaches the potentially blocking operation. This in turn allows the
+  potentially blocking operation check to be performed prior to run time in some
+  environments. 
+
+[Editor's note: End mostly unchanged text. The last sentence of the last note
+perhaps should be struck, since aspect Nonblocking serves that purpose. I
+considered trying to unify Nonblocking and potentially blocking further, but
+that seemed messy and error-prone. One could imagine replacing the last rule
+with "a call on a subprogram with Nonblocking = False", but that would expose
+a lot of xisting code to a Bounded Error (since the default for Nonblocking
+is False, and that has to be the case for compatibility).]
+
+Language-defined subprograms for which the Nonblocking aspect has the value
+False [Redundant: (whether explicitly or by inheritance)] are potentially
+blocking.
+
+[Editor's note: This is what remains of 9.5.1(18). The old definition should be
+reflected in the aspect values for language-defined routines.]
+
+Modify 9.5.1(8):
+
+During a protected action, it is a bounded error to invoke an operation that is
+potentially blocking.[ The following are defined to be potentially blocking
+operations:]
+
+[Editor's note: This is no longer a definition for potentially blocking.]
+
+Delete 9.5.1(9-16, 18) and the associated AARM notes.
+
+Replace note 9.5.1(22.1/2) with:
+
+The aspect Nonblocking can be used 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 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. 
 
-       Language-defined operators other than "=" for record types are
-       nonblocking; "=" for record types is potentially blocking.
+AARM Discussion: The deadlock case cannot be detected at compile-time,
+so pragma Detect_Blocking is needed to give it consistent behavior.
 
+Modify 3.10.2(33/3):
+
+   ...  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
+   places where Legality Rules normally apply (see 12.3),
+   {these rules apply}[this rule applies] also in the private part of an
+  instance of a generic unit.
+
+Add after 4.5(9): [General rules for predefined operators]
+
+   Predefined operators other than "=" for record types are nonblocking; the
+   predefined "=" operator for record types allows blocking.
+
        AARM Reason: Record equality can be composed of operations including
-       user-defined "=" operators, which might be potentially blocking. We
+       user-defined "=" operators, which might allow blocking. We
        can't introduce an incompatibility here, so we have to assume the worst.
+
+[Editor's note: We might be able to do better here for untagged types by
+examining the type definition, but sadly for tagged types we have to allow it
+to be blocking as some overriding might need that (and all of the overridings
+need to be the same). As such, we do not bother with the extra complexity
+of rules to allow some record equality to be nonblocking.]
+
+Add after 4.6(24.21/4): [Type conversion Legality Rules for access-to-subprogram types]
+
+  * If the target type is nonblocking, the operand type shall be nonblocking. 
+
+Add after 4.9(8):
+
+  * an attribute_reference whose designator is Nonblocking;
+
+Modify the AARM Note 13.1(9.d/3):
+
+   ...most aspects do not need this complexity[ (including all language-defined
+   aspects as of this writing)], we avoid the complexity...
+
+[Editor's note: This and the next couple of changes are needed as Nonblocking
+can be specified on generic formal parameters, and it surely is
+language-defined. In this particular case, the rule itself is fine (it says
+"Unless otherwise specified...").]
+
+Delete "a generic_formal_parameter_declaration" from 13.1.1(17/4) [since
+we allow specifying Nonblocking on formals.]
+
+Modify the AARM Note 13.1.1(17.a/3):
+
+   Implementation-defined aspects can be allowed on these, of course; the
+   implementation will need to define the semantics. In {addition}[particular],
+   {the language does not define default aspect matching rules for generic
+   formals; only the handful of aspects allowed on formals have such rules.
+   Therefore,} the implementation will need to define actual [type] matching
+   rules for any aspects allowed on formal types[; there are no default matching
+   rules defined by the language.]
+
+Add after 13.13.2(37/1):
+
+   The default implementations of stream-oriented attributes has the value False
+   for aspect Nonblocking.
+
+   AARM Reason: The underlying Read/Write operations are called via dispatching
+   calls. Since we cannot afford any incompatibility with existing
+   Ada code, the stream operations allow blocking. Thus the
+   stream-oriented attributes must allow blocking as well.
 
-[Editor's note: We might be able to do better here for untagged types, but
-sadly for tagged types we have to allow it to be potentially blocking as
-some overriding might need it (and all of the overridings need to be the same).]
-
-       The default implementations of stream-oriented attributes for elementary
-       types are nonblocking. Other default implementations of stream-oriented
-       attributes are potentially blocking.
-
-       AARM Reason: As with equality, composite stream-oriented attributes can
-       be composed out of user-defined routines. Again, we have to assume the
-       worst.
+Wording for definition of language-defined packages and subprograms is TBD.
 
 [Editor's note: We intend that language-defined subprograms are nonblocking
-unless this Standard says otherwise. Specifically, 9.5.1(18) says:
+unless this Standard says otherwise. Specifically, 9.5.1(18) said (before we
+deleted it above):
 
   Certain language-defined subprograms are potentially blocking. In particular,
   the subprograms of the language-defined input-output packages that
@@ -234,32 +432,210 @@
   not specified as potentially blocking, a language-defined subprogram is
   nonblocking. 
 
-We'll accomplish that by adding "with Nonblocking => True" to all of the
-language-defined packages unless otherwise noted here.
+Non-generic units that are pure are automatically nonblocking (these are noted
+below). Other unit should explicitly have Nonblocking specified.
 
-We don't need to add that to units that are non-generic and declared pure,
-as those already default to True.
+We'll handle the containers in AI12-0112-1 (the AI that defines preconditions
+for the container operations); it probably makes the most sense to add all of
+the contracts at once for those.
+
+The entire list of non-container units is:
+
+{{Note: I've only done part of this list; the units that don't start with Ada haven't been handled yet.}}
+
+    Ada.Assertions  11.4.2 - Pure
+    Ada.Asynchronous_Task_Control  D.11 - Nonblocking => True
+    Ada.Calendar  9.6 - Nonblocking => True
+    Ada.Calendar.Arithmetic  9.6.1 - Nonblocking => True
+    Ada.Calendar.Formatting  9.6.1 - Nonblocking => True
+    Ada.Calendar.Time_Zones  9.6.1 - Nonblocking => True
+    Ada.Characters  A.3.1 - Pure
+    Ada.Conversions  A.3.4 - Pure
+    Ada.Handling  A.3.2 - Pure
+    Ada.Latin_1  A.3.3 - Pure
+    Ada.Command_Line  A.15 - Nonblocking => True
+    Ada.Complex_Text_IO  G.1.3 - Nonblocking => False (** String routines)
+    Ada.Decimal  F.2 - Pure
+    Ada.Direct_IO  A.8.4 - Nonblocking => False (I/O)
+    Ada.Directories  A.16 - Nonblocking => False (I/O) - Full_Name through Compose should have Nonblocking => True (as they are just string manipulation routines).
+    Ada.Directories.Hierarchical_File_Names  A.16.1 - Nonblocking => True (these are all string manipulation routines).
+    Ada.Directories.Information  A.16 - (**** Impl def)
+    Dispatching  D.2.1
+      EDF  D.2.6
+      Non_Preemptive  D.2.4
+      Round_Robin  D.2.5
+    Dynamic_Priorities  D.5.1
+    Environment_Variables  A.17
+    Exceptions  11.4.1
+    Execution_Time  D.14
+      Group_Budgets  D.14.2
+      Interrupts  D.14.3
+      Timers  D.14.1
+    Ada.Finalization  7.6 - Nonblocking => False (*** user overriding)
+    Float_Text_IO  A.10.9
+    Float_Wide_Text_IO  A.11
+    Float_Wide_Wide_Text_IO  A.11
+    Integer_Text_IO  A.10.8
+    Integer_Wide_Text_IO  A.11
+    Integer_Wide_Wide_Text_IO  A.11
+    Interrupts  C.3.2
+      Names  C.3.2
+    IO_Exceptions  A.13
+    Iterator_Interfaces  5.5.1
+    Locales  A.19
+    Numerics  A.5
+      Complex_Arrays  G.3.2
+      Complex_Elementary_Functions  G.1.2
+      Complex_Types  G.1.1
+      Discrete_Random  A.5.2
+      Elementary_Functions  A.5.1
+      Float_Random  A.5.2
+      Generic_Complex_Arrays  G.3.2
+      Generic_Complex_Elementary_Functions
+             G.1.2
+      Generic_Complex_Types  G.1.1
+      Generic_Elementary_Functions  A.5.1
+      Generic_Real_Arrays  G.3.1
+      Real_Arrays  G.3.1
+    Real_Time  D.8
+      Timing_Events  D.15
+    Sequential_IO  A.8.1
+    Storage_IO  A.9
+    Ada.Streams  13.13.1 - Nonblocking => False (*** user overriding)
+    Ada.Streams.Stream_IO  A.12.1 - Nonblocking => False
+    Strings  A.4.1
+      Bounded  A.4.4
+        Equal_Case_Insensitive  A.4.10
+        Hash  A.4.9
+        Hash_Case_Insensitive  A.4.9
+        Less_Case_Insensitive  A.4.10
+      Fixed  A.4.3
+        Equal_Case_Insensitive  A.4.10
+        Hash  A.4.9
+        Hash_Case_Insensitive  A.4.9
+        Less_Case_Insensitive  A.4.10
+      Equal_Case_Insensitive  A.4.10
+      Hash  A.4.9
+      Hash_Case_Insensitive  A.4.9
+      Less_Case_Insensitive  A.4.10
+      Maps  A.4.2
+        Constants  A.4.6
+      Unbounded  A.4.5
+        Equal_Case_Insensitive  A.4.10
+        Hash  A.4.9
+        Hash_Case_Insensitive  A.4.9
+        Less_Case_Insensitive  A.4.10
+      UTF_Encoding  A.4.11
+        Conversions  A.4.11
+        Strings  A.4.11
+        Wide_Strings  A.4.11
+        Wide_Wide_Strings  A.4.11
+      Wide_Bounded  A.4.7
+        Wide_Equal_Case_Insensitive
+               A.4.7
+        Wide_Hash  A.4.7
+        Wide_Hash_Case_Insensitive  A.4.7
+      Wide_Equal_Case_Insensitive  A.4.7
+      Wide_Fixed  A.4.7
+        Wide_Equal_Case_Insensitive
+               A.4.7
+        Wide_Hash  A.4.7
+        Wide_Hash_Case_Insensitive  A.4.7
+      Wide_Hash  A.4.7
+      Wide_Hash_Case_Insensitive  A.4.7
+      Wide_Maps  A.4.7
+        Wide_Constants  A.4.7
+      Wide_Unbounded  A.4.7
+        Wide_Equal_Case_Insensitive
+               A.4.7
+        Wide_Hash  A.4.7
+        Wide_Hash_Case_Insensitive  A.4.7
+      Wide_Wide_Bounded  A.4.8
+        Wide_Wide_Equal_Case_Insensitive
+               A.4.8
+        Wide_Wide_Hash  A.4.8
+        Wide_Wide_Hash_Case_Insensitive
+               A.4.8
+      Wide_Wide_Equal_Case_Insensitive  A.4.8
+      Wide_Wide_Fixed  A.4.8
+        Wide_Wide_Equal_Case_Insensitive  A.4.8
+        Wide_Wide_Hash  A.4.8
+        Wide_Wide_Hash_Case_Insensitive  A.4.8
+      Wide_Wide_Hash  A.4.8
+      Wide_Wide_Hash_Case_Insensitive - A.4.8
+      Wide_Wide_Maps  A.4.8
+        Wide_Wide_Constants  A.4.8
+      Wide_Wide_Unbounded  A.4.8
+        Wide_Wide_Equal_Case_Insensitive  A.4.8
+        Wide_Wide_Hash  A.4.8
+        Wide_Wide_Hash_Case_Insensitive  A.4.8
+  Ada.Synchronous_Barriers  D.10.1 - Nonblocking => True (Wait_For_Release has Nonblocking => False by D.10.1(14/3) - which should be deleted).
+  Ada.Synchronous_Task_Control  D.10 - Nonblocking => True (Suspend_Until_True has Nonblocking => False by D.10(10), that sentence should be deleted).
+  Ada.Synchronous_Task_Control.EDF  D.10 - Nonblocking => False (by D.10(10.1/3), that sentence should be deleted.)
+  Ada.Tags  3.9 - Nonblocking => True
+  Ada.Tags.Generic_Dispatching_Constructor  3.9 - Nonblocking => Constructor'Nonblocking (* generic)
+  Ada.Task_Attributes  C.7.2 - Nonblocking => True
+  Ada.Task_Identification  C.7.1 - Nonblocking => True (Abort_Task has Nonblocking => False by C.7.1(16) - which should be deleted)
+  Ada.Task_Termination  C.7.3 - Nonblocking => True
+  Ada.Text_IO  A.10.1 - Nonblocking => False (** String routines)
+  Ada.Text_IO.Bounded_IO  A.10.11 - Nonblocking => Bounded'Nonblocking (* generic)
+  Ada.Text_IO.Complex_IO  G.1.3 - Nonblocking => Complex_Types'Nonblocking (* generic)
+  Ada.Text_IO.Editing  F.3.3 - Nonblocking => False (** String routines)
+  Ada.Text_IO.Text_Streams  A.12.2 - Nonblocking => False
+  Ada.Text_IO.Unbounded_IO  A.10.12 - Nonblocking => False
+  Ada.Unchecked_Conversion  13.9 - Pure
+  Ada.Unchecked_Deallocate_Subpool  13.11.5 - Nonblocking => False (*** user calls)
+  Ada.Unchecked_Deallocation  13.11.2 - Nonblocking => True
+  Ada.Wide_Characters  A.3.1 - Pure
+  Ada.Wide_Characters.Handling  A.3.5 - Pure
+  Ada.Wide_Text_IO  A.11 - Nonblocking => False (** String routines)
+  Ada.Wide_Text_IO.Complex_IO  G.1.4 - Nonblocking => Complex_Types'Nonblocking (* generic)
+  Ada.Wide_Text_IO.Editing  F.3.4 - Nonblocking => False (** String routines)
+  Ada.Wide_Text_IO.Text_Streams  A.12.3 - Nonblocking => False
+  Ada.Wide_Text_IO.Wide_Bounded_IO  A.11 - Nonblocking => Wide_Bounded'Nonblocking (* generic)
+  Ada.Wide_Text_IO.Wide_Unbounded_IO  A.11 - Nonblocking => False
+  Ada.Wide_Wide_Characters  A.3.1 - Pure
+  Ada.Wide_Wide_Characters.Handling  A.3.6 - Pure
+  Ada.Wide_Wide_Text_IO  A.11 - Nonblocking => False (** String routines)
+  Ada.Wide_Wide_Text_IO.Complex_IO  G.1.4 - Nonblocking => Complex_Types'Nonblocking (* generic)
+  Ada.Wide_Wide_Text_IO.Editing  F.3.4 - Nonblocking => False (** String routines)
+  Ada.Wide_Wide_Text_IO.Text_Streams  A.12.3 - Nonblocking => False
+  Ada.Wide_Wide_Text_IO.Wide_Wide_Bounded_IO  A.11 - Nonblocking => Wide_Wide_Bounded'Nonblocking (* generic)
+  Ada.Wide_Wide_Text_IO.Wide_Wide_Unbounded_IO  A.11 - Nonblocking => False
+  Interfaces  B.2 - Pure
+  Interfaces.C  B.3 - Pure
+  Interfaces.C.Pointers  B.3.2 - Nonblocking => True
+  Interfaces.C.Strings  B.3.1 - Nonblocking => True
+  Interfaces.COBOL  B.4 - Nonblocking => True
+  Interfaces.Fortran  B.5 - Pure
+  System  13.7 - Pure
+  System.Address_To_Access_Conversions  13.7.2 - Nonblocking => True
+  System.Machine_Code  13.8 - (**** Impl def)
+  System.Multiprocessors  D.16 - Nonblocking => True
+  System.Multiprocessors.Dispatching_Domains  D.16.1 - Nonblocking => True
+  System.RPC  E.5 - Nonblocking => False (E.5(23) says this explicitly; that paragraph should be deleted.)
+  System.Storage_Elements  13.7.1 - Pure
+  System.Storage_Pools  13.11 - Nonblocking => False (*** user overriding)
+  System.Storage_Pools.Subpools  13.11.4 - Nonblocking => False (*** user overriding)
+
+Items marked "(* generic)" have Nonblocking given as a formula. This
+automatically matches the nonblocking setting to that of the actual
+parameters (see the !discussion for more on this).
+
+Items marked "(** String routines)" have Get/Put routines that operate only on
+Strings explicitly have Nonblocking => True given. That's in accordance with
+the AARM note 9.5.1(18.a) (and an old AI).
+
+Items marked "(*** user overriding)" are mainly used to provide a framework
+for user code (as in storage pools or streams). Since all dispatching calls
+have to have the same value for nonblocking, and we have to keep compatibility
+with existing Ada code, we cannot make such packages (and types) nonblocking.
+
+Items marked "(*** user calls)" make calls on code that is potentially
+user-defined via dispatching. These usually work in conjunction with types
+declared in packages associated with the previous item.
 
-For generic units that have formal subprograms (like the Ada.Containers packages),
-the package would instead have
-"with Nonblocking => Formal1'Nonblocking and Formal2'Nonblocking and ...;".
-This automatically matches the nonblocking setting to that of the actual
-subprograms (see the !discussion for more on this).
-
-The I/O packages are potentially blocking (Nonblocking => False), but we will
-mark the Put/Get routines that put into a string or get from a string as
-Nonblocking (see the first !example).
-
-There are special cases where subprograms are specifically marked as
-   "with Nonblocking => False;"
-* individual subprograms identified in the Standard as potentially blocking;
-* subprograms with anonymous-access-to-subprogram parameters (else we would
-   introduce a compatibility problem).
-
-Writing the exact text for this can wait until the larger details are worked
-out. In the case of the containers, it may make more sense to include those
-contracts in the AI that defines preconditions for the container operations;
-it probably makes the most sense to add all of the contracts at once.
+Items marked "(**** impl def)" have implementation-defined contents, so we need say nothing.
 
 End lengthy editor's note.]
 
@@ -369,7 +745,7 @@
 Nonblocking on generic formal parameters, and just depending on the Nonblocking
 attribute to handle that. That would eliminate the rules about generic formal
 matching. We didn't do that as that would require having nonblocking attributes
-for formal packages and formal objects (which would reduce the value somewhat),
+for formal objects (which would reduce the value somewhat),
 and would eliminate the "easy" solution for new code (which is to simply
 require everything to be nonblocking). Not everyone needs to write the most
 flexible possible generics.
@@ -379,7 +755,7 @@
 Comparing Alternative 1 with this proposal.
 
 The problem with alternative 1 is that a generic unit like the containers
-can be set to nonblocking, but then using this with a not nonblocking
+can be set to nonblocking, but then using this with an allows blocking
 routine requires an explicit override by the user on the instance. Since the
 default for most routines is that they are not nonblocking, this could provide
 a significant compatibility problem.

Questions? Ask the ACAA Technical Agent