Version 1.2 of ais/ai-00343.txt

Unformatted version of ais/ai-00343.txt version 1.2
Other versions for file ais/ai-00343.txt

!standard B.03 (68.1/1)          03-08-04 AI95-00343/01
!standard B.03 (69/1)
!class binding interpretation 03-08-04
!status Amendment 200Y 04-12-02
!status ARG Approved 8-0-2 04-11-20
!status work item 03-08-04
!status received 03-07-12
!qualifier Omission
!priority Low
!difficulty Easy
!subject C_Pass_By_Copy convention is required
!summary
A type must have the C_Pass_By_Copy convention in order for B.3(68.1/1) to apply.
!question
I happened to be looking at the Interfacing sections in the RM today and noticed something in RM2000 which seemed wrong. Paragraphs B.3(68.1/1,69/1) read as follows:
An Ada parameter of a C_Pass_By_Copy-compatible (record) type T, of mode IN, is passed as a t argument to a C function, where t is the C struct corresponding to the Ada type T.
An Ada parameter of a record type T, of any mode, other than an IN parameter of a C_Pass_By_Copy-compatible type, is passed as a t* argument to a C function, where t is the C struct corresponding to the Ada type T.
Shouldn't both of the above references to "C_Pass_By_Copy- compatible type" actually say "type of convention C_Pass_By_Copy"? That is, just because a type is compatible with C_Pass_By_Copy is not relevant, what matters is whether it is specified to have that convention.
!recommendation
(See wording.)
!wording
Replace "C_Pass_By_Copy-compatible type" by "type of convention C_Pass_By_Copy" in B.3(68.1) and B.3(69).
!discussion
B.1(20) allows an implementation to support additional types as C_Pass_By_Copy types. Since C_Pass_By_Copy only has an effect for record types, there is no value to allowing other kinds of types as C_Pass_By_Copy. However, it makes sense for an implementation to permit additional kinds of record types to be C_Pass_By_Copy types.
If an implementation does so, we want them to be passed by copy only if the Convention pragma is explicitly given. However, they would always be passed by copy with the wording in the Standard. That's clearly wrong. Thus, the wording in the standard is corrected.
!corrigendum B.03(68.1/1)
Replace the paragraph:
by:
!corrigendum B.03(69/1)
Replace the paragraph:
by:
!ACATS test
This change only affects "types permitted by the implementation" to be C_Pass_By_Copy. Thus, any test would be implementation-dependent and have to use macros to define the type. That has insufficient value.
!appendix

From: Tucker Taft
Sent: Thursday, July 12, 2003  6:32 PM

I happened to be looking at the Interfacing sections
in the RM today and noticed something in RM2000 which
seemed wrong.  Paragraphs B.3(68.1/1,69/1) read as follows:

    An Ada parameter of a C_Pass_By_Copy-compatible (record)
    type T, of mode IN, is passed as a t argument to a C
    function, where t is the C struct corresponding to the
    Ada type T.

    An Ada parameter of a record type T, of any mode, other
    than an IN parameter of a C_Pass_By_Copy-compatible type,
    is passed as a t* argument to a C function, where t is the
    C struct corresponding to the Ada type T.

Shouldn't both of the above references to "C_Pass_By_Copy-
compatible type" actually say "type of convention
C_Pass_By_Copy"?  That is, just because a type is *compatible*
with C_Pass_By_Copy is not relevant, what matters is whether
it is specified to have that convention.

Or am I the one who is confused?

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

From: Robert Dewar
Sent: Monday, July 14, 2003  9:04 AM

Tuck is not confused IMO, he is quite right that this is an error.
I must say that I hate to see such a megakludge as C_Pass_By_Copy enshrined
in the standard, but I guess there is no choice but to hold our noses here
and let it by :-)

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

From: Pascal Leroy
Sent: Tuesday, July 29, 2003  4:51 AM

I think you are confused.

A type is C_Pass_By_Copy-compatible if (paraphrasing B.1(13-20)):

1 - If is declared in a language interface package for C_Pass_By_Copy.
Well, this case doesn't arise, as there is no such package.

2 - It has a pragma Convention (C_Pass_By_Copy).  Obviously we agree
that this is OK.

3 - It is derived from a C_Pass_By_Copy compatible type.

4 - The implementation permits it as C_Pass_By_Copy compatible.

We definitely want case #3 and #4 to be covered.

Case #3 is necessary because, if you derive from a type that has a
pragma Convention (C_Pass_By_Copy), you surely want parameters of the
derived type to by passed by copy, not by reference (at least by
default).

Case #4 is more tricky.  After all, if an implementation has a type that
is C_Pass_By_Copy compatible by magic, it could give an explicit pragma
Convention (C_Pass_By_Copy), right?  Well, not quite, because an
implementation may have magic types that are compatible with more than
one convention (say Fortran and C_Pass_By_Copy) and you cannot write
several convention pragmas for a single type.

I wrote the rules after carefully considering these two cases.  Note
that the rules say "compatible", not "eligible".  It would be clearly
wrong to say that any C_Pass_By_Copy-eligible type is passed by copy.

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

From: Robert Dewar
Sent: Tuesday, July 29, 2003  7:54 AM

Could you give an example of what you are talking about here, since it seems
very weird to me.

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

From: Tucker Taft
Sent: Tuesday, July 29, 2003  9:48 AM

I think the use of the term "compatible" is unfortunate.
You are implying that it is clearly distinct from the
term "eligible" in meaning, but not to me.  "Compatible with
X" means *can* be used in conjunction with X, not *must*
be used with X.

If we don't want to say "a type of convention C_Pass_By_Copy"
then we should say "a C_Pass_By_Copy type" or something like that.
A "C_Pass_By_Copy-compatible type" simply doesn't convey the
meaning properly to me.

Note that when we say "C-compatible" type we are not saying that
it *must* be passed to C, but merely that it may be passed to C.
Carrying over the term "compatible" from this usage to
the C_Pass_By_Copy usage seems like a mistake.

Even with the "magic" types, I personally see no harm
in saying that they are implicitly of convention C_Pass_By_Copy,
or that they are implicitly "C_Pass_By_Copy types."

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

From: Pascal Leroy
Sent: Tuesday, July 29, 2003  10:33 AM

Heck, that's gibberish that is in the RM and that I just inherited.
These two notions are technical terms, mentioned in the index, and
entirely distinct.  If you tell me that the terminology is confusing, I
couldn't agree more, but at least it is well defined.  I see no point in
using yet another different terminology for the case of C_Pass_By_Copy,
when C_Pass_By_Copy-compatible has exactly the right properties.

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

From: Tucker Taft
Sent: Tuesday, July 29, 2003  11:13 AM

You are right that eligible and compatible are defined
in the RM, but I believe you are making a distinction
that does not exist.  L-eligible are those types that
are *required* to be supported for a pragma Convention.
L-compatible are those additional types that the implementation
happens to support.  L-compatible types can also be used as
components of composite types for which convention L is,
specified, or as parameters to subprograms with convention L.

But an L-compatible type is not by definition of
convention L (though it may have such
a convention by default, or by explicit user action).
An L-compatible type can be specified to have convention L
with a pragma (if it hasn't already been directly specified,
of course).

So I still think you are misusing the meaning of L-compatible
by saying that simply by being C_Pass_By_Copy compatible the
type is automatically passed by copy.

I believe it is only if it is in fact of *convention* C_Pass_By_Copy
(implicitly or explicitly) that it is passed by copy.

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

From: Pascal Leroy
Sent: Tuesday, July 29, 2003  11:47 AM

I understand that you are proposing a formulation different from that in
the RM, but I fail to see what the difference would be in practice.  Can
you show an example where your wording would cause a different passing
mode to be chosen?

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

From: Tucker Taft
Sent: Tuesday, July 29, 2003  12:44 PM

If you look at the definition of L-compatible, there
are four bullets (B.1(13-19)).  The first is irrelevant
for C_Pass_By_Copy since it only applies to record types.
The second says that if you successfully apply pragma
convention L to a type, then it must by definition be
L-compatible.  A bit of a tautology...

The third says that a type derived from an L-compatible
type is L-compatible (even if you override the
inherited convention, presumably?).

The fourth says that the implementation can allow
essentially any type to be L-compatible.  For example, it
might allow constrained subtypes of types with discriminants,
or unchecked unions, or records containing arrays (where the array
type doesn't happen to have a pragma Convention C applied to it, but
is C-eligible), in the case of C_Pass_By_Copy.

It is the fourth bullet which seems most clearly to distinguish
C_Pass_By_Copy compatible from C_Pass_By_Copy convention.
An implementation might allow additional kinds of record
types to be used in a C_Pass_By_Copy pragma, meaning they
are C_Pass_By_Copy compatible, but it won't in fact pass them
by copy unless the programmer specifies the pragma.

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

From: Gary Dismukes
Sent: Tuesday, July 29, 2003  1:54 PM

I agree with Tucker.  The pass-by-copy rules should only take effect
if the convention applies (C_Pass_By_Copy-compatible isn't sufficient).

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

From: Pascal Leroy
Sent: Wednesday, July 30, 2003  5:13 AM

OK, now I see your point and I agree there is a problem.  Sorry if I
have been thick.

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


Questions? Ask the ACAA Technical Agent