CVS difference for ai12s/ai12-0064-2.txt
--- ai12s/ai12-0064-2.txt 2016/09/03 03:36:10 1.5
+++ ai12s/ai12-0064-2.txt 2016/11/15 04:05:01 1.6
@@ -1,4 +1,4 @@
-!standard 9.5(17/3) 16-09-02 AI12-0064-2/04
+!standard 9.5(17/3) 16-11-14 AI12-0064-2/05
!standard 9.5.1(8)
!standard 9.5.1(9)
!standard 9.5.1(10)
@@ -96,19 +96,12 @@
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.
+ dispatching operations, unless directly specified.
-[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
+ AARM Ramification: specifying Nonblocking as False imposes
+ no requirements. Specifying Nonblocking as True imposes
additional compile-time checks to prevent blocking, but does not
- prevent deadlock. pragma Detect_Blocking can be used to ensure
+ prevent deadlock. A 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
@@ -138,7 +131,7 @@
to call an entry, no matter how it occurs, so the value ought to be
False. Moreover, we do not want a subprogram that renames an entry
to be able to override a nonblocking subprogram. We could have used
- individual rules for these cases, but there were getting to be many
+ individual rules for these cases, but there were already many
of them, and this solution avoids the need for extra rules.
For any other program unit, formal package,
@@ -290,10 +283,7 @@
considered nonblocking; the value of this attribute is of type
Boolean, Redundant[and is always static].
- 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.]
-
[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
@@ -324,13 +314,10 @@
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 notes: End mostly unchanged text. The last sentence of the last note
-perhaps should be deleted, since aspect Nonblocking serves that purpose. I
-considered trying to unify Nonblocking and potentially blocking further, but
+ actually reaches the potentially blocking operation.
+
+[Editor's notes: End mostly unchanged text. 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 existing code to a Bounded Error (since the default for Nonblocking
@@ -441,8 +428,9 @@
not specified as potentially blocking, a language-defined subprogram is
nonblocking.
-Non-generic units that are pure are automatically nonblocking (these are noted
-below). Other unit should explicitly have Nonblocking specified.
+Non-generic units that are pure are automatically nonblocking as specified in
+9.5 (these are noted below). Other units should explicitly have Nonblocking
+specified.
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
@@ -578,13 +566,13 @@
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_Barriers — D.10.1 - Nonblocking => True (Wait_For_Release has Nonblocking => False by D.10.1(14/3); that paragraph 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_Identification — C.7.1 - Nonblocking => True (Abort_Task has Nonblocking => False by C.7.1(16); that paragraph 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)
@@ -627,13 +615,15 @@
System.Storage_Pools — 13.11 - Nonblocking => False (*** user overriding)
System.Storage_Pools.Subpools — 13.11.4 - Nonblocking => False (*** user overriding)
+Items marked "Pure" are pure, and thus automatically are Nonblocking.
+
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).
+Strings -- those explicitly have Nonblocking => True specified. 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
Questions? Ask the ACAA Technical Agent