Version 1.4 of ais/ai-00082.txt

Unformatted version of ais/ai-00082.txt version 1.4
Other versions for file ais/ai-00082.txt

!standard E.4 (20)          99-08-31 AI95-00082/02
!standard E.5 (24)
!class binding interpretation 95-07-27
!status Corrigendum 2000 99-07-08
!status WG9 approved 95-06-14
!status ARG approved (subject to editorial review) 10-0-0 95-11-01
!status received 95-07-27
!qualifier Clarification
!subject The PCS may be defined by the user.
!summary
An implementation that conforms to Annex E, and that supports pragma Remote_Call_Interface (which is not required -- see E.2.3(20)) must allow the user to compile a body for System.RPC, and to compile children of System.RPC.
Such an implementation must implement remote subprogram calls using (only) the facilities of System.RPC; the generated code is not allowed to depend on special properties of one particular implementation of System.RPC, but must work for any correct implementation of System.RPC.
!question
A(4) says:
4 The implementation may restrict the replacement of language-defined compilation units. The implementation may restrict children of language-defined library units (other than Standard).
Is this intended to apply to the body of System.RPC, or its children? (No.)
May an implementation require that a particular version of System.RPC be used? (No.)
!recommendation
(See summary.)
!wording
(See corrigendum.)
!discussion
The intent is that the PCS be implemented by the user, or by a third party vendor -- it need not be implemented by the Ada compiler vendor. Hence, it is important that the user be able to provide a body, and child units, for System.RPC. This requires:
(1) The Ada compiler vendor must allow users to compile the body and
children of System.RPC, despite A(4).
(2) The Ada compiler must generate code that will work properly
with any correct implementation of the PCS; thus, the generated code must use the defined interface, and only that interface, and not depend on details of a particular PCS implementation.
Thus, it would be correct for a validation test to provide a PCS implementation, and require the implementation to use that PCS in tests.
!corrigendum E.05(24)
Insert after the paragraph:
The implementation of the RPC-receiver shall be reentrant, thereby allowing concurrent calls on it from the PCS to service concurrent remote subprogram calls into the partition.
the new paragraphs:
The permission of the introduction to Annex A does not apply to the body or children of System.RPC. Specifically, an implementation shall not restrict the replacement of the body of System.RPC. An implementation shall not restrict the compilation of children of System.RPC.
An implementation shall support remote subprogram calls using an implementation of System.RPC provided by the user.
!ACATS test
Tests CXE5002 and CXE5003 use this capability.
!appendix

!section E.4(20)
!subject vendor-supplied PCS
!reference RM95-E.4(20)
!from Dan Eilers 95-07-24
!reference as: 95-5232.a Dan Eilers  95-7-24>>
!discussion
  This question was raised at the Jun 8,9 1994 ACVC review meeting,
(not by me), but is forwarded here for tracking purposes.

  If a vendor supplies a PCS, is the vendor allowed to use that PCS
for all ACVC testing (possibly because the vendor's code-generation
somehow relies on it), or is the vendor required to use the ACVC-supplied
PCS for certain ACVC tests?  (the latter?)

****************************************************************

!section E.5(27)
!subject PCS supplied by third-party
!reference RM95-A(4)
!reference RM95-E.5(27)
!from Dan Eilers 95-07-24
!reference as: 95-5232.b Dan Eilers  95-7-24>>
!discussion
  This question was raised at the Jun 8,9 1994 ACVC review meeting,
(not by me), but is forwarded here for tracking purposes.

  If a vendor doesn't supply a body for System.RPC (as permitted
by E.5(27)), and doesn't allow replacement of System.RPC (as
permitted by A(4)) with an ACVC-supplied body, can this vendor
validate Annex E?  (no?)

****************************************************************

!section E.4(20)
!subject vendor-supplied PCS
!reference RM95-E.4(20)
!reference RM95-A(4)
!reference RM95-E.5(27)
!reference 95-5232.b Dan Eilers  95-7-24
!reference 95-5232.a Dan Eilers  95-7-24
!from Erhard Ploedereder
!reference as: 95-5235.a Erhard Ploedereder  95-7-26>>
!discussion

>  If a vendor supplies a PCS, is the vendor allowed to use that PCS
> for all ACVC testing (possibly because the vendor's code-generation
> somehow relies on it), or is the vendor required to use the ACVC-supplied
> PCS for certain ACVC tests?  (the latter?)

>  If a vendor doesn't supply a body for System.RPC (as permitted
> by E.5(27)), and doesn't allow replacement of System.RPC (as
> permitted by A(4)) with an ACVC-supplied body, can this vendor
> validate Annex E?  (no?)

My opinion, as reflected in the minutes of the ACVC reviewer meeting:

if an implementation provides a PCS and allows it to be replaced, all of the
tests should be applicable; if it doesn't allow replacement, then some tests
will be inapplicable; if it doesn't provide a PCS, then it must accept a
replacement (and all tests will be applicable).

(To actually check the pragma All_Calls_Remote, a replacement of the PCS by
a ACVC-provided one seems necessary; hence the above possibility of
inapplicable tests, if the implementation doesn't allow replacement.)

On the second question, a definite "no". Presumably this is a rethorical
question in the first place, akin to "is a restriction to 10-line
compilation units allowed?".



****************************************************************

!section E.4(20)
!subject vendor-supplied PCS
!reference RM95-E.4(20)
!reference 95-5232.a Dan Eilers  95-7-24
!from Anthony Gargaro 95-7-26
!reference as: 95-5236.a Anthony Gargaro  95-7-26>>
!discussion

>   This question was raised at the Jun 8,9 1994 ACVC review meeting,
> (not by me), but is forwarded here for tracking purposes.

>   If a vendor supplies a PCS, is the vendor allowed to use that PCS
> for all ACVC testing (possibly because the vendor's code-generation
> somehow relies on it), or is the vendor required to use the ACVC-supplied
> PCS for certain ACVC tests?  (the latter?)

There was some discussion of this issue at the last International Real-Time
Ada Issues Workshop in Santa Barbara.

It seems that the most sensible approach is the following (and which I believe
was acceptable to those at the workshop participating in the discussion). If
an Ada implementation is presented for validation together with a PCS, then it
may be validated providing that it passes the Annex E ACVC tests with that
PCS. If an Ada implementation is presented for validation without a PCS then,
it may be validated providing that it passes the Annex E ACVC tests with the
ACVC-supplied PCS (as proposed by Richard Powers). In each case the validation
will specify the conditions under which the implementation was validated.

The advantage of this approach is that it provides the motivation for compiler
vendors to support Annex E while not stifling the implementation permissions
allowed for enhanced feature support.

****************************************************************

!section E.4(20)
!subject vendor-supplied PCS
!reference RM95-E.4(20)
!reference 95-5232.a Dan Eilers  95-7-24
!from Bob Duff
!reference as: 95-5237.a Robert A Duff 95-7-26>>
!discussion
>   This question was raised at the Jun 8,9 1994 ACVC review meeting,
> (not by me), but is forwarded here for tracking purposes.
>
>   If a vendor supplies a PCS, is the vendor allowed to use that PCS
> for all ACVC testing (possibly because the vendor's code-generation
> somehow relies on it), or is the vendor required to use the ACVC-supplied
> PCS for certain ACVC tests?  (the latter?)

The latter makes more sense to me.  The whole point of this part of the
language design is to allow people to plug in their own, or third-party,
versions of the PCS.  So the code-generation should not rely on some
particular PCS.



****************************************************************

!section E.5(27)
!subject PCS supplied by third-party
!reference RM95-A(4)
!reference RM95-E.5(27)
!reference 95-5232.b Dan Eilers  95-7-24
!from Bob Duff
!reference as: 95-5237.b Robert A Duff 95-7-26>>
!discussion
>   This question was raised at the Jun 8,9 1994 ACVC review meeting,
> (not by me), but is forwarded here for tracking purposes.
>
>   If a vendor doesn't supply a body for System.RPC (as permitted
> by E.5(27)), and doesn't allow replacement of System.RPC (as
> permitted by A(4)) with an ACVC-supplied body, can this vendor
> validate Annex E?  (no?)

A(4) should be interpreted as not applying to System.RPC -- clearly, the
vendor can't forbid replacement of System.RPC.

- Bob


****************************************************************

!section E.5(27)
!subject PCS supplied by third-party
!reference RM95-A(4)
!reference RM95-E.5(27)
!reference RM95-E.2.3(20)
!reference 95-5232.b Dan Eilers  95-7-24
!from Anthony Gargaro 95-7-27
!reference as: 95-5238.a Anthony Gargaro  95-7-27>>
!discussion

>   This question was raised at the Jun 8,9 1994 ACVC review meeting,
> (not by me), but is forwarded here for tracking purposes.

>   If a vendor doesn't supply a body for System.RPC (as permitted
> by E.5(27)), and doesn't allow replacement of System.RPC (as
> permitted by A(4)) with an ACVC-supplied body, can this vendor
> validate Annex E?  (no?)

Since support for the Remote_Call_Interface pragma is optional E.2.3(20), it
seems that an implementation may validate Annex E under the conditions cited
above.

****************************************************************

!section E.4(20)
!subject vendor-supplied PCS
!reference RM95-E.4(20)
!reference 95-5232.a Dan Eilers  95-7-24
!reference 95-5237.a Robert A Duff 95-7-26
!from Anthony Gargaro 95-7-27
!reference as: 95-5240.a Anthony Gargaro  95-7-27>>
!discussion

>>   This question was raised at the Jun 8,9 1994 ACVC review meeting,
>> (not by me), but is forwarded here for tracking purposes.
>>
>>   If a vendor supplies a PCS, is the vendor allowed to use that PCS
>> for all ACVC testing (possibly because the vendor's code-generation
>> somehow relies on it), or is the vendor required to use the ACVC-supplied
>> PCS for certain ACVC tests?  (the latter?)

> The latter makes more sense to me.  The whole point of this part of the
> language design is to allow people to plug in their own, or third-party,
> versions of the PCS.  So the code-generation should not rely on some
> particular PCS.

It is more accurate to say that the purpose of System.RPC is to allow
implementations to permit third-party versions of the PCS in the absence of an
implementation-provided PCS.

> So the code-generation should not rely on some particular PCS.

However, this should not be mandated by the ACVC tests. For example, child
packages of System.RPC are permitted by E.5(26) and may be referenced to
implement features of Annex E. Furthermore, these packages may use unspecified
declarations in the private part of System.RPC. Thus, attempting to enforce
such a rule in the ACVC tests seems beyond what is required by the Annex.

****************************************************************

!section E.4(20)
!subject vendor-supplied PCS
!reference RM95-E.4(20)
!reference 95-5232.a Dan Eilers  95-7-24
!reference 95-5237.a Robert A Duff 95-7-26
!reference 95-5240.a Anthony Gargaro 95-7-27
!from Tucker Taft 95-7-27
!reference as: 95-5241.a Tucker Taft 95-7-27>>
!discussion

> >>   This question was raised at the Jun 8,9 1994 ACVC review meeting,
> >> (not by me), but is forwarded here for tracking purposes.
> >>
> >>   If a vendor supplies a PCS, is the vendor allowed to use that PCS
> >> for all ACVC testing (possibly because the vendor's code-generation
> >> somehow relies on it), or is the vendor required to use the ACVC-supplied
> >> PCS for certain ACVC tests?  (the latter?)
>
> > The latter makes more sense to me.  The whole point of this part of the
> > language design is to allow people to plug in their own, or third-party,
> > versions of the PCS.  So the code-generation should not rely on some
> > particular PCS.
>
> It is more accurate to say that the purpose of System.RPC is to allow
> implementations to permit third-party versions of the PCS in the absence of an
> implementation-provided PCS.

The intent is that the user should *always* be able to provide
their own implementation of System.RPC.  It totally defeats
the purpose of having this standard interface if you are
forced to use the compiler vendor's own implementation of it.

> > So the code-generation should not rely on some particular PCS.
>
> However, this should not be mandated by the ACVC tests. For example, child
> packages of System.RPC are permitted by E.5(26) and may be referenced to
> implement features of Annex E.

I don't agree.  Where does the RM allow such a dependence on features
outside of System.RPC for standard Annex E capabilities?  The intent was
that an implementor of a PCS could provide extra capabilities,
not that a compiler could require extra capabilities.

Compare E.5(1) with E.5(26).  E.5(1) is a hard requirement to use the
System.RPC interface to implement remote subprogram calls.
E.5(26) is simply allowing the supplier of a PCS (not a compiler)
to provide extra stuff for the user's benefit (not the compiler's benefit).
These are very different things.

> ... Furthermore, these packages may use unspecified
> declarations in the private part of System.RPC. Thus, attempting to enforce
> such a rule in the ACVC tests seems beyond what is required by the Annex.

I don't agree.  I believe a compiler should be required to work
with whatever kind of "null" PCS that accompanies the ACVC suite.
Otherwise, the definition of the standard System.RPC interface
is a complete waste.

-Tuck

****************************************************************

!section E.4(20)
!subject vendor-supplied PCS
!reference RM95-E.4(20)
!reference 95-5232.a Dan Eilers  95-7-24
!reference 95-5237.a Robert A Duff 95-7-26
!reference 95-5240.a Anthony Gargaro 95-7-27
!reference 95-5241.a Tucker Taft 95-7-27
!from Anthony Gargaro 95-7-28
!reference as: 95-5242.a Anthony Gargaro  95-7-28>>
!discussion

> I don't agree.  Where does the RM allow such a dependence on features
> outside of System.RPC for standard Annex E capabilities?

The Annex neither allows nor disallows such a dependence.

> Compare E.5(1) with E.5(26).  E.5(1) is a hard requirement to use the
> System.RPC interface to implement remote subprogram calls.

E.5(1) states that a conforming implementation shall use the RPC interface; it
does not require that a conforming implementation shall only use the RPC
interface.

> E.5(26) is simply allowing the supplier of a PCS (not a compiler)
> to provide extra stuff for the user's benefit (not the compiler's benefit).
> These are very different things.

E.5(26) is an implementation permission and may be read as applying to either
the compiler/PCS implementor or the PCS implementor. If it is restricted to
the PCS implementor, then E.5(27) is somewhat difficult to interpret.

> I don't agree.  I believe a compiler should be required to work
> with whatever kind of "null" PCS that accompanies the ACVC suite.

This position may harm innovation by compiler implementations that provide a
PCS. It serves no purpose to enforce this perceived compliance. Presumably,
innovative implementations wishing to compete in the interchangeable PCS
market will have a mode whereby they can be validated using the ACVC-supplied
PCS. The important consideration is not to preclude an innovative
implementation from validation.

> Otherwise, the definition of the standard System.RPC interface
> is a complete waste.

I disagree. It provides exactly what is required to motivate compiler
implementors to support the Annex without having to incur the cost of
developing a PCS.


****************************************************************

!section A(4)
!subject PCS supplied by third-party
!reference RM95-A(4)
!reference RM95-E.5(27)
!reference RM95-E.2.3(20)
!reference 95-5232.b Dan Eilers  95-7-24
!reference 95-5238.a Anthony Gargaro  95-7-27
!from Bob Duff
!reference as: 95-5243.a Robert A Duff 95-7-28>>
!discussion

> >   This question was raised at the Jun 8,9 1994 ACVC review meeting,
> > (not by me), but is forwarded here for tracking purposes.
>
> >   If a vendor doesn't supply a body for System.RPC (as permitted
> > by E.5(27)), and doesn't allow replacement of System.RPC (as
> > permitted by A(4)) with an ACVC-supplied body, can this vendor
> > validate Annex E?  (no?)
>
> Since support for the Remote_Call_Interface pragma is optional E.2.3(20), it
> seems that an implementation may validate Annex E under the conditions cited
> above.

True.  (We should never have given in to the political pressure that
caused us to add this permission.  It makes "Conformance to Annex E"
a rather useless concept.  Too late to worry about that, though.)

However, if the implementation *does* support R_C_I, then I think it has
to do so in the standard way, which requires using the standard
System.RPC interface, not relying on some vendor-supplied version of
System.RPC.  An implementation can of course have an *option* to rely on
implementation-defined stuff.

- Bob

****************************************************************

!section E.4(20)
!subject vendor-supplied PCS
!reference RM95-E.4(20)
!reference 95-5232.a Dan Eilers  95-7-24
!reference 95-5237.a Robert A Duff 95-7-26
!reference 95-5240.a Anthony Gargaro  95-7-27>>
!from Ted Baker 95-7-28
!reference as: 95-5244.a Ted Baker  95-7-28>>
!discussion

| > The latter makes more sense to me.  The whole point of this part of the
| > language design is to allow people to plug in their own, or third-party,
| > versions of the PCS.  So the code-generation should not rely on some
| > particular PCS.

| It is more accurate to say that the purpose of System.RPC is to allow
| implementations to permit third-party versions of the PCS in the absence of an
| implementation-provided PCS.

| However, this should not be mandated by the ACVC tests. For example, child
| packages of System.RPC are permitted by E.5(26) and may be referenced to
| implement features of Annex E. Furthermore, these packages may use unspecified
| declarations in the private part of System.RPC. Thus, attempting to enforce
| such a rule in the ACVC tests seems beyond what is required by the Annex.

This sounds wrong to me.  I thought the main selling point of the
Ada support for distribution is that it is an "open" system.  If
you give in on this, you lose credibility.



****************************************************************

!section E.4(20)
!subject vendor-supplied PCS
!reference RM95-E.4(20)
!reference 95-5232.a Dan Eilers  95-7-24
!reference 95-5237.a Robert A Duff 95-7-26
!reference 95-5240.a Anthony Gargaro 95-7-27
!reference 95-5241.a Tucker Taft 95-7-27
!reference 95-5242.a Anthony Gargaro 95-7-28
!from Tucker Taft 95-7-28
!reference as: 95-5245.a Tucker Taft 95-7-28>>
!discussion

> > I don't agree.  Where does the RM allow such a dependence on features
> > outside of System.RPC for standard Annex E capabilities?
>
> The Annex neither allows nor disallows such a dependence.
>
> > Compare E.5(1) with E.5(26).  E.5(1) is a hard requirement to use the
> > System.RPC interface to implement remote subprogram calls.
>
> E.5(1) states that a conforming implementation shall use the RPC interface; it
> does not require that a conforming implementation shall only use the RPC
> interface.

My understanding of the intent has always been that the compiler-generated
stubs must not depend on anything outside the RPC interface.

I believe you are playing word games here by claiming that "shall use
the RPC interface" means "may but need not use the RPC interface."
What possible force does this requirement have if we allow
compiler-generated stubs to have arbitrary dependence on
proprietary interfaces in order to implement RPC?

> ...  I believe a compiler should be required to work
> > with whatever kind of "null" PCS that accompanies the ACVC suite.
>
> This position may harm innovation by compiler implementations that provide a
> PCS. It serves no purpose to enforce this perceived compliance. Presumably,
> innovative implementations wishing to compete in the interchangeable PCS
> market will have a mode whereby they can be validated using the ACVC-supplied
> PCS. The important consideration is not to preclude an innovative
> implementation from validation.

This does not harm innovation.  The E.5(1) requirement in my view is that
the compiler must work using any conforming implementation of System.RPC.
It is allowed to work faster or more efficiently using some
proprietary interfaces if desired, but that should be under
control of a pragma, switch, etc.  In the "standard" mode, it
should use the System.RPC interfaces only.  Otherwise E.5(1)
means nothing.

From the very beginning we emphasized the importance of the
user being in charge of the actual communication protocols.
The theory is that communication architectures vary all over
the map, and there is no way the compiler vendor could provide
solutions that handled all interesting communication architectures.
Hence, we defined a standard interface which allowed the user
to replace the PCS.

-Tuck

****************************************************************

!section A(4)
!subject vendor-supplied PCS
!reference RM95-A(4)
!reference RM95-E.4(20)
!reference RM95-E.5(1)
!reference RM95-E.5(26)
!reference RM95-E.5(27)
!reference RM95-E.2.3(20)
!reference 95-5232.a Dan Eilers  95-7-24
!reference 95-5232.b Dan Eilers  95-7-24
!reference 95-5235.a Erhard Ploedereder  95-7-26
!reference 95-5236.a Anthony Gargaro  95-7-26
!reference 95-5237.a Robert A Duff 95-7-26
!reference 95-5237.b Robert A Duff 95-7-26
!reference 95-5238.a Anthony Gargaro  95-7-27
!reference 95-5240.a Anthony Gargaro 95-7-27
!reference 95-5241.a Tucker Taft 95-7-27
!from Offer Pazy 95-7-29
!reference as: 95-5246.a Offer Pazy 95-7-29>>

!discussion

> ... and doesn't allow replacement of System.RPC (as
> permitted by A(4)) with an ACVC-supplied body

> A(4) should be interpreted as not applying to System.RPC -- clearly, the
> vendor can't forbid replacement of System.RPC.

I agree. I think the DS annnex should require that System.RPC must be
replaceable.  This is consistent with the approach to the annexes in that
they can further restrict implementation permissions given in the core.

As to teh general question, I fully agree with Bob and Tucker on this.
The whole idea of the annex was to support open systems in the sense that
users will be able to insert their own communication component, otherwise
supporting the annex is not very useful. Remember that a likely scenario is
that distributed systems will be constructed from partitions compiled by
different compilers. Since we don't standardize on the message format, the
only hook for the user is to code the PCS. Also, it is unlikely that the
ACVC will test the annex in a real network environment, and it is not
likely that vendors wil support many possible configurations, so again the
only practical solution is to have third-party PCS.  That was the whole
motivation behind the annex.  We certainly don't want to repeat the
situation with early 83 ACVC's wherr the tests allowed delays to never
actually expire and to IO to be implemented by raising a Use_Error (I'm not
talking of course about embedded systems).

Finally, as Tucker pointed out, it was never intended that the generated
code will use specialized, private hooks (or child packages) to implement
the basic RPC as defined by the annex.  The child packages are intended for
user-visible extentions, not the generated code.

Child packages are mentioned in the annex not as a way for the
implementation to use private intefaces (all semantics must be implemented
using PCS itself), but rather to emphasize that *additional* feature should
be placed in a separate place and not clutter System.PCS itself.

To summarize I would suggest that implementations are either tested with
the ACVC-supplied PCS or if they want to do it with their own PCS, this
should work "against" an ACVC-supplied node so that conformance could be
checked.

Offer Pazy
31 Robinwood Ave.
Boston, MA. 02130
USA
(617)522-5988
pazy@world.std.com

****************************************************************

!section E.4(20)
!subject vendor-supplied PCS
!reference RM95-E.4(20)
!reference 95-5232.a Dan Eilers  95-7-24
!reference 95-5237.a Robert A Duff 95-7-26
!reference 95-5240.a Anthony Gargaro 95-7-27
!reference 95-5241.a Tucker Taft 95-7-27
!reference as: 95-5242.a Anthony Gargaro  95-7-28
!from Offer Pazy 95-7-29
!reference as: 95-5247.a Offer Pazy 95-7-29>>

!discussion

> The Annex neither allows nor disallows such a dependence.

> E.5(1) states that a conforming implementation shall use the RPC interface
> does not require that a conforming implementation shall only use the RPC
> interface.

I don't believe that this is a corerct reading of the words.  The annex
says: "Shall use the package to implement RPC".  We are not (yet) at the
stage of legally defending rules, but there is no confusion with respect to
the intention and the rules. I don't think that implying that such ambiguity
exists is beneficial at this point.



> E.5(26) is an implementation permission and may be read as applying to eit
> the compiler/PCS implementor or the PCS implementor. If it is restricted t
> the PCS implementor, then E.5(27) is somewhat difficult to interpret.

On the contrary, if you say that the permission to add children is for the
compiler vendor then it does not make sense for it not to provide a body.
We did face a wording problem with the annex since we were talking about
potentially two entities, a compiler-vendor and a third-party (or a user),
but I belive thatthe rule is that "implementation" by itself is the
compilation system and when we mean otherwise, we say so.  For example, in
(26), we say "The PCS is allowed to have", not "the implementation is ..."


> > I don't agree.  I believe a compiler should be required to work
> > with whatever kind of "null" PCS that accompanies the ACVC suite.
>
> This position may harm innovation by compiler implementations that provide
> PCS. It serves no purpose to enforce this perceived compliance. Presumably
> innovative implementations wishing to compete in the interchangeable PCS
> market will have a mode whereby they can be validated using the ACVC-suppl
> PCS. The important consideration is not to preclude an innovative
> implementation from validation.

But then again, this goes contrary to the whole motivation of the annex.
The whole idea wa sthat we don't expect compiler vendors to be the *main*
force behind innovation, experimentation and rich support of PCSs.  If that
was the goal, we didn't have to have a PCS.  The compiler just provides a
mimimum support and the real comm work is expected to come from elsewhere.
This is where we shoudl ensure open interface and room for innovation.  Of
course, a compiler vendor may provide wonderful PCSs, but that was not the
motivation of the annex approach.


Offer Pazy
31 Robinwood Ave.
Boston, MA. 02130
USA
(617)522-5988
pazy@world.std.com

****************************************************************

!section E.4(20)
!subject vendor-supplied PCS
!reference RM95-E.4(20)
!reference 95-5232.a Dan Eilers  95-7-24
!reference 95-5237.a Robert A Duff 95-7-26
!reference 95-5240.a Anthony Gargaro 95-7-27
!reference 95-5241.a Tucker Taft 95-7-27
!reference 95-5242.a Anthony Gargaro 95-7-28
!reference 95-5245.a Tucker Taft 95-7-28
!from Anthony Gargaro 95-7-29
!reference as: 95-5248.a Anthony Gargaro  95-7-29>>
!discussion

> My understanding of the intent has always been that the compiler-generated
> stubs must not depend on anything outside the RPC interface.

I agree but my understanding is (or was) that the RPC interface does not
exclude the child packages mentioned in E.5(26) for an implementation-provided
PCS.

> I believe you are playing word games here by claiming that "shall use
> the RPC interface" means "may but need not use the RPC interface."

Well, those are not quite my words. All I have said is that because the word
"only" is missing then it is arguable that an implementation is disallowed
from using additional interfaces provided in child packages.

> It is allowed to work faster or more efficiently using some
> proprietary interfaces if desired, but that should be under
> control of a pragma, switch, etc.  In the "standard" mode, it
> should use the System.RPC interfaces only.  Otherwise E.5(1)
> means nothing.

Then it seems you would allow an implementation to be validated that used
additional interfaces providing that there is a mode whereby it can be
validated using only the System.RPC interface..

Again, my only concern is not to exclude a compiler implementation that takes
advantage of what I consider is a legitimate implementation permission in
E.5(26) from validation. Can we agree on this point?


****************************************************************

!from Randy Brukardt  99-7-8
!discussion

The discussion above makes it clear that wording is needed to disallow an
implementation from depending on facilities outside of System.RPC for
implementing the communication needed for remote subprogram calls. This
very hard to word. I tried variations of:

An implementation shall not use facilities other than those defined by
System.RPC to implement remote subprogram calls.

but this makes it sound like internal library routines (for marshalling,
perhaps) cannot be used. Therefore, I settled on a straightforward statement
of what must be supported:

An implementation shall support remote subprogram calls using an implementation
of System.RPC provided by the user.

An implementation which cheats in a visible way would violate this; and any
other "cheating" isn't our business, anyway.

****************************************************************

Questions? Ask the ACAA Technical Agent