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

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

--- ai12s/ai12-0064-2.txt	2016/08/30 21:52:44	1.4
+++ ai12s/ai12-0064-2.txt	2016/09/03 03:36:10	1.5
@@ -1,4 +1,4 @@
-!standard 9.5(17/3)                                 16-08-29    AI12-0064-2/03
+!standard 9.5(17/3)                                 16-09-02    AI12-0064-2/04
 !standard 9.5.1(8)
 !standard 9.5.1(9)
 !standard 9.5.1(10)
@@ -55,10 +55,10 @@
 Removed special case for renames of entries, (and entry calls in general), and
 added an AARM note to explain why.
 
-Added an AARM note to highlight that a routine that overridings an allows
+Added an AARM note to highlight that a routine that overrides 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.)
+(Else any non-trivial finalization and allocation/deallocation could never be
+used in nonblocking code, which would be bad.)
 
 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.
@@ -132,6 +132,15 @@
 
        For a (protected or task) entry, the value of the aspect is False.
 
+         AARM Reason: An entry can be renamed as a procedure, so the value
+         of the aspect has to be well-defined (as the attribute can be applied
+         to a procedure). We do not want a nonblocking subprogram to be able
+         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
+         of them, and this solution avoids the need for extra rules.
+
        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
@@ -174,7 +183,7 @@
 
          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
+         potentially blocking operations in a protected action (see 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.
@@ -319,12 +328,12 @@
   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
+[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
 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
+a lot of existing 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
@@ -352,8 +361,8 @@
 ensure that any remaining executions of potentially blocking operations
 during a protected action raise Program_Error. See H.5. 
 
-AARM Discussion: The deadlock case cannot be detected at compile-time,
-so pragma Detect_Blocking is needed to give it consistent behavior.
+  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):
 

Questions? Ask the ACAA Technical Agent