CVS difference for ai12s/ai12-0283-1.txt

Differences between 1.2 and version 1.3
Log of other versions for file ai12s/ai12-0283-1.txt

--- ai12s/ai12-0283-1.txt	2018/06/12 04:12:44	1.2
+++ ai12s/ai12-0283-1.txt	2018/07/13 01:08:34	1.3
@@ -1,7 +1,9 @@
-!standard E.2.2(9.3/1)                                  18-06-11  AI12-0283-1/01
+!standard E.2.2(9.3/1)                                  18-07-12  AI12-0283-1/02
 !standard E.2.3(13/3)
 !standard E.4(8)
 !class Amendment 18-06-11
+!status Amendment 1-2012 18-07-12
+!status ARG Approved 8-0-3  18-06-23
 !status work item 18-06-11
 !status received 18-05-15
 !priority Low
@@ -56,30 +58,31 @@
 
 Add after E.2.3(13/3):
 
-   * it shall not contain or be itself a remote subprogram that is
-     nonblocking (see 9.5);
+   * it shall not be, nor shall its visible part contain, the declaration of a 
+     subprogram that is nonblocking (see 9.5);
 
-   AARM Reason: All calls on remote subprograms are considered potentially 
-   blocking, so they cannot statically be allowed in nonblocking code.
+   AARM Reason: All such subprograms are remote subprograms, and all calls on 
+   remote subprograms are considered potentially blocking, so they cannot 
+   statically be allowed in nonblocking code.
 
    AARM Ramification: The declaration of a remote subprogram is illegal
    if the Nonblocking aspect is True, either implicitly by inheritance or
    by explicit specification.
 
 Add after E.4(8):
-
-   A dispatching call with a controlling operand designated by a value of a
-   remote access-to-class-wide type shall be to a subprogram that allows
-   blocking (see 9.5).
 
-   AARM Reason: This is a potentially blocking call (see below), so we must 
-   not assert that no blocking is possible.
+   A nonblocking program unit shall not contain, other than within nested 
+   units with Nonblocking specified as statically False, a dispatching call
+   with a controlling operand designated by a value of a remote 
+   access-to-class-wide type.
+
+   AARM Reason: Such a dispatching call is a potentially blocking call (see
+   below) even if the called subprogram is nonblocking, so we must not assert
+   that no blocking is possible.
 
    AARM Ramification: The call is illegal if the Nonblocking aspect 
-   of the called subprogram is True, either implicitly by inheritance or
-   by explicit specification. Note that if subprogram is nonblocking,
-   all overridings (and inherited versions) of that subprogram also
-   have to be nonblocking.
+   of the containing unit is True, either implicitly by inheritance or
+   by explicit specification.
 
 [Editor's note: I included a cross-reference in each of these rules to
 emphasize that "nonblocking" and "allows blocking" are technical terms
@@ -95,7 +98,7 @@
 
 E.4(17) says that remote calls are always potentially blocking. This needs
 to be reflected in the static value of the Nonblocking aspect - we don't
-want anything to be potentially blocking that has Nonblocking True.
+want anything that is potentially blocking to have Nonblocking True.
 
 We choose to define this using Legality Rules as that is the style of the
 existing categorization restrictions. We could have alternatively defined
@@ -105,6 +108,34 @@
 These rules are compatible as the default value for Nonblocking (if it not
 specified anywhere in a library unit) is False. One can only get failures
 if the entity or the enclosing package has been specified to be nonblocking.
+
+!corrigendum E.2.2(9.3/1)
+
+@dinsa
+A type that is derived from a remote access type is also a remote access type.
+@dinst
+A remote access-to-subprogram type shall not be nonblocking (see 9.5).
+
+!corrigendum E.2.3(13/3)
+
+@dinsa
+@xbullet<it shall not be, nor shall its visible part contain, the declaration 
+of a subprogram for which aspect Inline is True;>
+@dinst
+@xbullet<it shall not be, nor shall its visible part contain, the declaration
+of a  subprogram that is nonblocking (see 9.5);>
+
+!corrigendum E.4(8)
+
+@dinsa
+In a dispatching call with two or more controlling operands, if one controlling 
+operand is designated by a value of a remote access-to-class-wide type, then 
+all shall be. 
+@dinst
+A nonblocking program unit shall not contain, other than within nested 
+units with Nonblocking specified as statically False, a dispatching call
+with a controlling operand designated by a value of a remote 
+access-to-class-wide type.
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent