CVS difference for ais/ai-00048.txt

--- ais/ai-00048.txt	1998/09/30 00:17:10	1.1
+++ ais/ai-00048.txt	1999/07/08 17:25:14	1.2
@@ -1,5 +1,6 @@
-!standard E.2.3    (07)                               96-11-16  AI95-00048/07
+!standard E.2.3    (07)                               99-07-07  AI95-00048/08
 !class binding interpretation 95-06-25
+!status Corrigendum 2000 99-05-24
 !status WG9 approved 96-12-07
 !status ARG approved 12-0-0  96-10-07
 !status ARG approved (subj. ed. rev., letter ballot was 11-0-1) 96-10-03
@@ -11,14 +12,14 @@
 !difficulty Medium
 !subject An RCI unit can be a library subprogram
 
-!summary 96-07-23
+!summary
 
 A shared passive or remote types library unit must be a package or
 generic package, not a subprogram or generic subprogram.  However, a
 remote call interface library unit may be a package, generic package,
 subprogram, or generic subprogram.
 
-!question 95-06-25
+!question
 
 The rules for pragma Shared_Passive (E.2.1(3)), pragma Remote_Types
 (E.2.2(3)), and pragma Remote_Call_Interface (E.2.3(3)) seem to allow
@@ -38,11 +39,11 @@
 passive or remote types library unit?  (No.)  Can a subprogram or
 generic subprogram be a remote call interface library unit?  (Yes.)
 
-!recommendation 96-07-23
+!recommendation
 
 (See summary.)
 
-!wording 96-07-23
+!wording
 
 Modify wording as follows (@i<...> marks italics, {...} marks
 insertions, [...] marks deletions):
@@ -120,8 +121,95 @@
 implies that main subprograms that are RCI subprograms must be
 supported.  We see no implementation difficulty in that.
 
-!appendix 96-06-06
+!corrigendum E.02.03(7)
 
+@drepl
+A @i<remote call interface (RCI)> is a library unit to which the pragma
+Remote_Call_Interface applies. A subprogram declared in the visible part of
+such a library unit is called a @i<remote subprogram>.
+@dby
+A @i<remote call interface (RCI)> is a library unit to which the
+pragma Remote_Call_Interface applies. A subprogram declared in the
+visible part of such a library unit, or by such a library unit, is
+called a @i<remote subprogram>.
+
+!corrigendum E.02.03(9)
+
+@drepl
+In addition, the following restrictions apply to the visible part of an
+RCI library unit:
+@dby
+In addition, the following restrictions apply to a RCI library unit:
+
+!corrigendum E.02.03(10)
+
+@drepl
+@xbullet<it shall not contain the declaration of a variable;>
+@dby
+@xbullet<its visible part shall not contain the declaration of a variable;>
+
+!corrigendum E.02.03(11)
+
+@drepl
+@xbullet<it shall not contain the declaration of a limited type;>
+@dby
+@xbullet<its visible part shall not contain the declaration of a limited type;>
+
+!corrigendum E.02.03(12)
+
+@drepl
+@xbullet<it shall not contain a nested @fa<generic_declaration>;>
+@dby
+@xbullet<its visible part shall not contain a nested @fa<generic_declaration>;>
+
+!corrigendum E.02.03(13)
+
+@drepl
+@xbullet<it shall not contain the declaration of a subprogram to which a
+pragma Inline applies;>
+@dby
+@xbullet<it shall not be, nor shall its visible part contain, the declaration
+of a subprogram to which a pragma Inline applies;>
+
+!corrigendum E.02.03(14)
+
+@drepl
+@xbullet<it shall not contain a subprogram (or access-to-subprogram)
+declaration whose profile has an access parameter, or a formal
+parameter of a limited type unless that limited type has
+user-specified Read and Write attributes;>
+@dby
+@xbullet<it shall not be, nor shall its visible part contain, a
+subprogram (or access-to-subprogram) declaration whose profile
+has an access parameter, or a formal parameter of a limited type
+unless that limited type has user-specified Read and Write attributes;>
+
+!corrigendum E.02.03(19)
+
+@drepl
+If a pragma All_Calls_Remote applies to a given RCI library package,
+then the implementation shall route any call to a subprogram of the RCI
+package from outside the declarative region of the package through the
+Partition Communication Subsystem (PCS); see E.5. Calls to such subprograms
+from within the declarative region of the package are defined to be local and
+shall not go through the PCS.
+@dby
+If a pragma All_Calls_Remote applies to a given RCI library unit,
+then the implementation shall route any call to a subprogram
+of the RCI unit from outside the declarative region of the unit
+through the Partition Communication Subsystem (PCS); see E.5.
+Calls to such subprograms from within the declarative region of
+the unit are defined to be local and shall not go through the PCS.
+
+!ACATS test
+
+Test(s) are needed. A B-Test should be constructed to check that Shared_Passive
+and Remote_Types units cannot be library subprograms. A C-Test should be
+constructed to check that Remote_Call_Interface units can be library
+subprograms.
+
+!appendix
+
 !section E.2.3(07)
 !subject Can an RCI unit be a library subprogram?
 !reference RM95-E.2.3(7);6.0
@@ -439,10 +527,10 @@
 > package, in that it cannot be called remotely.  (I would hate to have to
 > explain that when teaching Ada 95.)
 
-On the contrary, I believe it is easier to explain  that categorization 
-pragmas  apply only to library level packages. Furthermore, if the remote call 
-interface pragma is applied to a library level subprogram, then it would seem a 
-further issue is raised as to why the All_Calls_Remote pragma cannot be applied 
+On the contrary, I believe it is easier to explain  that categorization
+pragmas  apply only to library level packages. Furthermore, if the remote call
+interface pragma is applied to a library level subprogram, then it would seem a
+further issue is raised as to why the All_Calls_Remote pragma cannot be applied
 to a library level subprogram.
 
 
@@ -760,7 +848,7 @@
 >  > As well it should have been.  Library subprograms are a horrible kludge
 >  > that have caused no end of trouble.  Unfortunately, Ada 9X was just a
 >  > wee bit too late for that -- upward compatibility reared its ugly head.
-> 
+>
 > I'm sympathetic to this view, but it's irrelevant.
 
 Agreed -- it's irrelevant.  Sorry, I was just venting my frustration.  ;-)
@@ -797,7 +885,7 @@
 
 >  > Bottom line: I don't care much one way or the other.  We could waste a
 >  > lot of time arguing about it, though, if we're not careful.
-> 
+>
 > Right.  We should just adopt my position and be done with it. ;-)
 
 Fine with me.  ;-)