CVS difference for 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
@@ -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
-[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.
Questions? Ask the ACAA Technical Agent