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

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

--- ai12s/ai12-0002-1.txt	2016/06/07 21:42:05	1.4
+++ ai12s/ai12-0002-1.txt	2016/08/05 07:02:14	1.5
@@ -1,20 +1,23 @@
-!standard  E.2.3(11/1)                           12-06-06    AI12-0002-1/02
+!standard  E.2.3(11/1)                           16-07-22    AI12-0002-1/03
+!standard  E.2.3(15)
 !standard  E.2.3(17)
 !class binding interpretation 11-06-16
+!status Amendment 1-2012 16-07-22
+!status ARG Approved 6-0-5  16-06-11
 !status work item 11-06-16
 !status received 11-03-09
 !priority Low
 !difficulty Medium
 !qualifier Omission
-!subject RCI units should not allow types with user-defined stream attributes
+!subject RCI units do not allow specification of user-defined stream-oriented attributes
 !summary
 
 !summary
 
-RCI units do not allow types with user-defined stream attributes.
+RCI units do not allow specification of user-defined stream-oriented attributes.
 
 [Editor's note: This AI was originally an Ada 2005 AI, but it was not resolved
-and was deferred to after Ada 2012 is completed.]
+and was deferred.]
 
 !question
 
@@ -29,7 +32,7 @@
    type T is null record;
    procedure R (S : access Ada.Streams.Root_Stream_Type'Class; V : out T);
    procedure W (S : access Ada.Streams.Root_Stream_Type'Class; V : T);
-   for T'Read use R;
+   for T'Read use R; --
    for T'Write use W;
 end RCI_Str_Att;
 
@@ -41,11 +44,11 @@
 end RCI_Str_Att;
 
 The bodies of R and W are remote subprograms. But they need to be used in
-marshalling when calling remote procedure P. How can this work??
+marshalling when calling remote procedure P. Does this work?? (No.)
 
 !wording
 
-Add after E.2.3(16):
+Add after E.2.3(15):
 
 Specification of a stream-oriented attribute is illegal in the specification
 of a remote call interface library unit. In addition to the places where
@@ -60,38 +63,30 @@
 course that this leak actually makes the whole thing unimplementable (you can't
 marshal with remote stream implementations, because to call the remote stream
 operation you have to marshal the value of the type, which has to be done
-remotely, and on forever). Thus the leak should be closed simply by saying such
-leaks are illegal. [But I didn't specify the form of such a rule, darn.]
+remotely, and on forever). Thus the leak should be repaired simply by saying
+that defining stream-oriented attributes for such a type is illegal.
 There are already rules to prevent such access from the visible part of the
 unit, and it clearly seems intended that everything not remote in the unit
 is used only in the partition that the unit is assigned to.
 
-Thomas' insistence that instances should be replicated in all partitions
-seems to violate E.2.3(17): the "unit" shall be assigned to a single partition.
-I don't know whether E.2.3(17) should be changed to allow specification
-replication or whether Thomas' implementation is just wrong. In any case, I
-see no reason to treat instances differently than other non-remote bodies
-(it forces people to use generics when they're not otherwise needed - ugly).
-
-(He also seems concerned about dragging in the closure of normal bodies, yet
-seems unconcerned about doing the same with instance bodies. This seems
-weird at best.)
-
-The solution we adopt to the original problem surely depends on what the
-answer to this secondary question is - the secondary question seems to allow
-the "leak" and institutionalize it. And that's OK if we say that non-remote
-routines (including instances) get replicated -- but it doesn't make sense
-to treat instances and other bodies differently.
+!corrigendum E.2.3(15)
 
-See the e-mail thread for suggestions and additional problem cases.
+@dinsa
+@xbullet<any public child of the library unit shall be a remote call interface
+library unit.>
+@dinst
+Specification of a stream-oriented attribute is illegal in the specification
+of a remote call interface library unit. In addition to the places where
+Legality Rules normally apply (see 12.3), this rule
+applies also in the private part of an instance of a generic unit.
 
-!ACATS Test
+!ASIS
 
-** TBD.
+No ASIS effect.
 
-!ASIS
+!ACATS Test
 
-** TBD.
+An ACATS B-Test should be created to check this rule.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent