CVS difference for ais/ai-00131.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-00131.txt

--- ais/ai-00131.txt	1998/10/01 03:20:15	1.3
+++ ais/ai-00131.txt	1998/11/05 18:19:10	1.4
@@ -1,6 +1,7 @@
-!standard B.3      (69)                               98-05-05  AI95-00131/05
-!class confirmation 96-11-19
-!status work item (revised by Ted Baker, per action from St. Louis meeting) 96-05-05
+!standard B.3      (69)                               98-11-05  AI95-00131/06
+!class binding interpretation 98-11-05
+!status work item 98-11-05
+!status work item (revised by Ted Baker) 96-05-05
 !status work item (letter ballot was 10-3-0) 96-10-03
 !status ARG approved 8-0-0 (subject to letter ballot) 96-06-17
 !status work item 96-04-17
@@ -9,10 +10,14 @@
 !difficulty Hard
 !subject Interface to C -- passing records as parameters of mode 'in'
 
-!summary 96-11-19
+!summary 98-11-05
 
 The Implementation Advice in B.3(69) is correct as written.
 
+An implementation which support interfacing to C shall support pragma
+Convention with a C_Pass_By_Copy identifier.  An 'in' parameter of a
+C_Pass_By_Copy-compatible type should be passed by copy to a C function.
+
 !question 96-04-17
 
 B.3(69) says:
@@ -24,54 +29,85 @@
        corresponding to the Ada type T.
 
 The problem with this is that if one has a C function that is passed a
-struct, then how can one pass an Ada record to that?  One might think
-that if the Ada record is passed as an 'in' parameter, it will work.
-However, the above Implementation Advice implies that such an 'in'
-parameter will correspond to a t* on the C side, rather than a t.
+struct, then how can one pass an Ada record to that?  One might think that if
+the Ada record is passed as an 'in' parameter, it will work.  However, the
+above Implementation Advice implies that such an 'in' parameter will
+correspond to a t* on the C side, rather than a t.
 
-!response 98-04-01
+!recommendation 98-11-05
 
-It was a mistake to require pass-by-reference for records passed
-to C functions.  However, at this point, it would be disruptive to
-change the rule, and there is an alternative (see below).
-
-The most important use of this interface is to take an existing C
-interface, and use it from Ada code (as opposed to taking an existing
-Ada interface, and mapping it to some corresponding C code).
+The Implementation Advice in B.3(69) is left unchanged (that is, C-compatible
+records are passed by reference).
 
-Structs are passed by copy in C.  This can be implemented by passing a
-copy of the struct (on the stack, in a register, or whatever), or by
-making a copy at the call site, and passing the address of that copy.
-Either way, whatever the C compiler does, the goal should be for the Ada
-compiler to mimic the C compiler's method of passing structs (not
-pointers to structs).
-
-Nonetheless, we choose to keep the rule as is.  Instead, implementations
-can solve the problem by supporting the following implementation-defined
-convention.
+The convention C_Pass_By_Copy is added to the facilities available for
+interfacing with C.  This convention can only be used in pragma Convention
+(not in pragmas Import or Export) and only when this pragma is applied to a
+type.
 
-  pragma Convention(C_Pass_By_Copy, Some_Record_Type);
+There is no language interface package corresponding to C_Pass_By_Copy.  In
+other words, B.1(13) never applies to convention C_Pass_By_Copy, and there is
+no package named Interfaces.C_Pass_By_Copy.
 
-The effect is that argument is passed by copy, i.e.  in a manner
-consistent with what C expects if the corresponding formal in the
-C prototype is a struct (rather than a pointer to a struct).
+A type T is eligible for convention C_Pass_By_Copy if and only if T is a
+record type that has no discriminants and that only has components with
+statically constrained subtypes, and each component is C-compatible.  (The
+eligibility rules in B.3(15-18) do not apply to convention C_Pass_By_Copy.)
+
+If a type is C_Pass_By_Copy-compatible then it is also C-compatible.
+
+An implementation supporting interfacing to C shall support pragma Convention
+with a C_Pass_By_Copy convention_identifier for a C_Pass_By_Copy-eligible
+type.
+
+The following sentence is added to the Implementation Advice in B.3(64-71):
+
+An Ada parameter of a C_Pass_By_Copy-compatible (record) type T, of mode in,
+should be passed as a t argument to a C function, where t is the C struct
+corresponding to the Ada type T.
+
+Note that the rules B.1(19) and B.1(20) apply to convention C_Pass_By_Copy.
+In particular, an implementation may permit other types as C_Pass_By_Copy-
+compatible types (e.g., discriminated records).
+
+!wording 98-11-05
+
+See !recommendation.
+
+!discussion 98-11-05
+
+It was a mistake to require pass-by-reference for records passed to C
+functions.  However, at this point, it would be disruptive to change the
+rule, and there is an alternative (see below).
+
+The most important use of this interface is to take an existing C interface,
+and use it from Ada code (as opposed to taking an existing Ada interface, and
+mapping it to some corresponding C code).
+
+Structs are passed by copy in C.  This can be implemented by passing a copy
+of the struct (on the stack, in a register, or whatever), or by making a copy
+at the call site, and passing the address of that copy.  Either way, whatever
+the C compiler does, the goal should be for the Ada compiler to mimic the C
+compiler's method of passing structs (not pointers to structs).
+
+Nonetheless, we choose to keep the implementation advice as is.  Instead, we
+solve the problem by defining a new convention, C_Pass_By_Copy:
+
+   pragma Convention (C_Pass_By_Copy, Some_Record_Type);
 
-Note that there is no issue for modes 'in out' and 'out'; C
-doesn't have these modes, and the closest correspondence to C is a
-pointer-to-struct argument.
-
-The above convention is the minimum recommended level of support
-for portable applications interfacing to C.  Some Implementations
-also provide other mechanisms.  For example, GNAT also provides a
-pragma C_Pass_By_Copy that has a similar effect to the convention
-above, and has extended Import and Export pragmas that allow
-specification of passing mechanisms on a parameter by parameter
-basis.  This AI does not discourage such other mechanisms, but
-recommends that at least the convention C_Pass_By_Copy be
-supported by all implementations.
+The effect is that any 'in' parameter of the type T is passed by copy to a
+subprogram of convention C, i.e., in a manner consistent with what C expects
+if the corresponding formal in the C prototype is a struct (rather than a
+pointer to a struct).
 
-!appendix 96-04-17
+In order to make sure that this solution is portable, an implementation that
+supports interfacing to C is required to support convention C_Pass_By_Copy.
 
+Note that there is no issue for modes 'in out' and 'out'; C doesn't have
+these modes, and the closest correspondence to C is a pointer-to-struct
+argument.
+
+!appendix 98-11-05
+
 !section B.3(69)
 !subject Interface to C -- passing records as parameters
 !reference RM95-B.3(69)
@@ -161,7 +197,7 @@
 
 ****************************************************************
 
-From dewar@gnat.com Mon Sep  9 22:37 EST 1996
+>From dewar@gnat.com Mon Sep  9 22:37 EST 1996
 Subject: Re: Letter Ballot #4; due 10/9/96
 
 "I believe the summary of this should emphasize that passing by
@@ -181,7 +217,7 @@
 
 ****************************************************************
 
-From ploedere@grimm.informatik.uni-stuttgart.de Sun Sep 15 20:50 EST 1996
+>From ploedere@grimm.informatik.uni-stuttgart.de Sun Sep 15 20:50 EST 1996
 Subject: Re: Results of Letter Ballot #4
 
 AI95-00131 -- Interface to C -- passing records as parameters
@@ -208,7 +244,7 @@
 
 ****************************************************************
 
-From action@sw-eng.falls-church.va.us Sun May  4 13:01 EST 1997
+>From action@sw-eng.falls-church.va.us Sun May  4 13:01 EST 1997
 Date: Sun, 4 May 97 08:53:18 EDT
 From: dewar@gnat.com (Robert Dewar)
 Subject: Re: Agenda Items for June 2 Meeting of WG9
@@ -276,7 +312,7 @@
 
 ****************************************************************
 
-From ploedere@kafka.informatik.uni-stuttgart.de Tue Jul  1 08:44:04 1997
+>From ploedere@kafka.informatik.uni-stuttgart.de Tue Jul  1 08:44:04 1997
 Date: Tue, 1 Jul 1997 14:44:25 +0200 (MET DST)
 Subject: Excerpts WG-9 Minutes
 
@@ -343,7 +379,7 @@
 
 ****************************************************************
 
-From ploedere@droste.informatik.uni-stuttgart.de Fri Nov 21 12:36 EST 1997
+>From ploedere@droste.informatik.uni-stuttgart.de Fri Nov 21 12:36 EST 1997
 Date: Fri, 21 Nov 1997 13:36:10 +0100 (MET)
 Subject: Minutes of St. Louis meeting
 
@@ -370,17 +406,19 @@
 
 ****************************************************************
 
-From bobduff@world.std.com Mon Nov 24 22:06 EST 1997
+>From bobduff@world.std.com Mon Nov 24 22:06 EST 1997
 Date: Mon, 24 Nov 1997 17:05:02 -0500
 Subject: Re: Minutes of St. Louis meeting
 
 > AI-131
-> 
+>
 > Erhard cites the WG-9 resolution of the subject of interfacing AIs and once
-> again questions the summary of this AI because it doesnt follow the C
-> language standard.  Someone reminded the meeting that Robert D. has influenced
+> again questions the summary of this AI because it doesn t follow the C
+> language standard.  Someone reminded the meeting that Robert D. has
+influenced
 > the current decision because of the large base of users for GNAT.  Erhard
-> argues that this being an Implementation Advice, GNAT would be free to ignore
+> argues that this being an Implementation Advice, GNAT would be free to
+ignore
 > it, but he believes that the current advice is plainly wrong for an ISO
 > standard and should be corrected.
 
@@ -388,18 +426,24 @@
 vendors will ignore, and the ACVC will fail to enforce.
 
  Ted suggests that the user should be
-> encouraged to use a pragma, like the one described in the AI, for forcing the
-> convention for parameter passing.  Gary proposes that this AI which deals with
-> both implementation advice and language interfaces may be best handled by the
-> newly proposed WG-9 rapporteur group dealing with interfacing issues.  There
-> were objections to the currently described pragma C_Pass_By_Copy which focuses
+> encouraged to use a pragma, like the one described in the AI, for forcing
+the
+> convention for parameter passing.  Gary proposes that this AI which deals
+with
+> both implementation advice and language interfaces may be best handled by
+the
+> newly proposed WG-9 rapporteur group dealing with interfacing issues.
+There
+> were objections to the currently described pragma C_Pass_By_Copy which
+focuses
 > on data size; instead there is a preference for making the pragma
-> convention-based, making it apply to all usages of the Convention C.  Ted will
+> convention-based, making it apply to all usages of the Convention C.  Ted
+will
 > rewrite this AI to support the Convention approach.
 
 ****************************************************************
 
-From baker@dad.cs.fsu.edu Fri Dec 12 18:53 EST 1997
+>From baker@dad.cs.fsu.edu Fri Dec 12 18:53 EST 1997
 Date: Fri, 12 Dec 1997 18:53:42 GMT
 Subject: AI 131, on C by-value struct parameters
 
@@ -460,15 +504,19 @@
 |      change" argument, since existing bindings relying on by-reference
 |      passing would be affected.
 |    * 2. Fix the RM to alter the Advice to by-value passing. The argument in
-|      favor is that this matches the C standard and that interfacing to all C
+|      favor is that this matches the C standard and that interfacing to all
+C
 |      routines becomes possible.
 |    * 2.a. As an alternative to 2, it has been proposed to advise by-value
-|      only for record types with convention C, thus slightly ameliorating the
+|      only for record types with convention C, thus slightly ameliorating
+the
 |      incompatibility.
 |    * 3. Follow the action of (at least) two Ada implementations which are
-|      providing implementation-defined pragmas to achieve by-value passing of
+|      providing implementation-defined pragmas to achieve by-value passing
+of
 |      records. In this case, form and semantics of the pragma should be
-|      specified. (The "too late" argument applies here as well, since the two
+|      specified. (The "too late" argument applies here as well, since the
+two
 |      implementations are rumored to have different semantics.)
 
 | The ARG is split on the issue. In Montreux, 2/2a was the preferred
@@ -508,12 +556,15 @@
 meeting, with some comments/corrections from Bob Duff:
 
 | > AI-131
-| > 
-| > Erhard cites the WG-9 resolution of the subject of interfacing AIs and once
-| > again questions the summary of this AI because it doesnt follow the C
-| > language standard.  Someone reminded the meeting that Robert D. has influenced
+| >
+| > Erhard cites the WG-9 resolution of the subject of interfacing AIs and
+once
+| > again questions the summary of this AI because it doesn t follow the C
+| > language standard.  Someone reminded the meeting that Robert D. has
+influenced
 | > the current decision because of the large base of users for GNAT.  Erhard
-| > argues that this being an Implementation Advice, GNAT would be free to ignore
+| > argues that this being an Implementation Advice, GNAT would be free to
+ignore
 | > it, but he believes that the current advice is plainly wrong for an ISO
 | > standard and should be corrected.
 
@@ -521,23 +572,29 @@
 | vendors will ignore, and the ACVC will fail to enforce.
 
 |  Ted suggests that the user should be
-| > encouraged to use a pragma, like the one described in the AI, for forcing the
-| > convention for parameter passing.  Gary proposes that this AI which deals with
-| > both implementation advice and language interfaces may be best handled by the
-| > newly proposed WG-9 rapporteur group dealing with interfacing issues.  There
-| > were objections to the currently described pragma C_Pass_By_Copy which focuses
+| > encouraged to use a pragma, like the one described in the AI, for forcing
+the
+| > convention for parameter passing.  Gary proposes that this AI which deals
+with
+| > both implementation advice and language interfaces may be best handled by
+the
+| > newly proposed WG-9 rapporteur group dealing with interfacing issues.
+There
+| > were objections to the currently described pragma C_Pass_By_Copy which
+focuses
 | > on data size; instead there is a preference for making the pragma
-| > convention-based, making it apply to all usages of the Convention C.  Ted will
+| > convention-based, making it apply to all usages of the Convention C.  Ted
+will
 | > rewrite this AI to support the Convention approach.
 
 ****************************************************************
 
-From dewar@gnat.com Fri Dec 12 19:09 EST 1997
+>From dewar@gnat.com Fri Dec 12 19:09 EST 1997
 Date: Fri, 12 Dec 97 14:04:38 EST
 Subject: Re: AI 131, on C by-value struct parameters
 
-I think it is far too late on this issue to be making such substantial 
-changes to the reference manual. I *never* liked what was in the RM, 
+I think it is far too late on this issue to be making such substantial
+changes to the reference manual. I *never* liked what was in the RM,
 and always complained about it, and I definitely dislike the C_Pass_By_COpy
 junk.
 
@@ -558,9 +615,11 @@
    follow the same conventions as the "local" C compiler -- but this is
    not a requirement.
 
-This is implementation advice that is the exact opposite of what is in the RM.
+This is implementation advice that is the exact opposite of what is in the
+RM.
 Yes, it is what the RM should have said. The reason it did not was simply a
-lack of understanding of the issues, but it is too late now to go changing it.
+lack of understanding of the issues, but it is too late now to go changing
+it.
 
 <<b. If a user wants the effect of C by-value struct parameters,
    the user should specify the mode "in", and the convention
@@ -570,7 +629,8 @@
 >>
 
 I strongly object to suggesting standardizing the GNAt approach here which
-is based on the DEC pragmas (e.g. Import_Procedure), they are much too strange
+is based on the DEC pragmas (e.g. Import_Procedure), they are much too
+strange
 to standardize.
 
 I would at most semi-standardize the ARA agreed on solution, which is
@@ -591,29 +651,29 @@
 
 ****************************************************************
 
-From stt@inmet.com Fri Dec 12 20:28 EST 1997
+>From stt@inmet.com Fri Dec 12 20:28 EST 1997
 Date: Fri, 12 Dec 1997 15:29:01 -0500
 Subject: Re: AI 131, on C by-value struct parameters
 
 > You two were not at the ARG meeting, but I believe you both
 > are critical to the resolution of this AI.
-> 
+>
 > I was assigned the job of rewriting AI95-00131, which deals with
 > the interfacing of C struct parameters.  I need your help, to make
 > sure what I write will be acceptable to you.
-> 
+>
 > The gist of what I propose is:
-> 
+>
 > 1) For the default treatment of record parameters of subprograms
 >    that are imported/exported as C-language, the Ada compiler should
 >    follow the same conventions as the "local" C compiler -- but this is
 >    not a requirement.
 
-From what I have seen, there is real confusion when this issue is 
+>From what I have seen, there is real confusion when this issue is
 discussed between "by-value/by-copy" *semantics* versus
-passing of an address (perhaps of a temp) at run-time.  
-The "size" oriented semantics of the configuration pragma 
-C_Pass_By_Copy (as opposed to the *convention* C_Pass_By_Copy) 
+passing of an address (perhaps of a temp) at run-time.
+The "size" oriented semantics of the configuration pragma
+C_Pass_By_Copy (as opposed to the *convention* C_Pass_By_Copy)
 adds to the confusion, unfortunately.
 
 Let me try to explain my *personal* position on this problem,
@@ -622,11 +682,11 @@
 My experience with C is that passing "structs" by copy is relatively
 rare, and returning structs is even rarer.  By coincidence, our
 Ada front end (which is written in ANSI C) *does* pass and return
-2-word structs by copy -- a lot.  When we have compiled this with various 
+2-word structs by copy -- a lot.  When we have compiled this with various
 C compilers, our heavy use of of by-value struct parameters/returns
 has been the major source of problems.  We have found bugs in this
 area in almost every compiler we have used (including gcc, Green Hills
-C, acc, Metrowerks C, etc.).  
+C, acc, Metrowerks C, etc.).
 
 This all seems to back up my own experience that passing/returning
 structs by value is not an extremely heavily used feature in C.
@@ -666,7 +726,7 @@
 
 ****************************************************************
 
-From baker@dad.cs.fsu.edu Sun Dec 14 18:40 EST 1997
+>From baker@dad.cs.fsu.edu Sun Dec 14 18:40 EST 1997
 Date: Sun, 14 Dec 1997 18:40:37 GMT
 Subject: Re: AI 131, on C by-value struct parameters
 
@@ -677,7 +737,7 @@
 
 ****************************************************************
 
-From dewar@gnat.com Sun Dec 14 19:01 EST 1997
+>From dewar@gnat.com Sun Dec 14 19:01 EST 1997
 Date: Sun, 14 Dec 97 13:56:48 EST
 Subject: Re: AI 131, on C by-value struct parameters
 
@@ -692,7 +752,7 @@
 
 ****************************************************************
 
-From baker@dad.cs.fsu.edu Sun Dec 14 19:09 EST 1997
+>From baker@dad.cs.fsu.edu Sun Dec 14 19:09 EST 1997
 Date: Sun, 14 Dec 1997 19:09:30 GMT
 Subject: what to do about AI 131?
 
@@ -708,7 +768,8 @@
 
 | ... do nothing at all, I am pretty sure that any proposal at this stage
 | other than what I suggested makes no sense and would thus also be defeated.
-| The RM is not badly broken here, the ARG is not in the business of extending
+| The RM is not badly broken here, the ARG is not in the business of
+extending
 | the language, my advice is forget to do anything about it!
 
 Is this acceptable to the rest of the ARG, or should I proceed with
@@ -718,13 +779,14 @@
 
 ****************************************************************
 
-From dewar@gnat.com Sun Dec 14 19:16 EST 1997
+>From dewar@gnat.com Sun Dec 14 19:16 EST 1997
 Date: Sun, 14 Dec 97 14:12:04 EST
 Subject: Re: what to do about AI 131?
 
 <<| ... do nothing at all, I am pretty sure that any proposal at this stage
 | other than what I suggested makes no sense and would thus also be defeated.
-| The RM is not badly broken here, the ARG is not in the business of extending
+| The RM is not badly broken here, the ARG is not in the business of
+extending
 | the language, my advice is forget to do anything about it!
 >>
 
@@ -735,14 +797,15 @@
 
 (a) consistent with the RM and did not change it
 (b) if extensions are proposed like pragmas, they should be consistent
-	with ARA agreed on practice.
+        with ARA agreed on practice.
 
 Basically the ARA decided that the RM was not sufficiently broken to need
 fixing, and that adding a pragma solved the problem. The various Ad 95
 vendors have agreed to implement this prgma (ACT and Intermetrics have
 already done so).
 
-I think the solution chosen is ugly, and I thought so 18 months ago when we agreed
+I think the solution chosen is ugly, and I thought so 18 months ago when we
+agreed
 on it, but at that time Aonix said their solution was set in stone, and could
 not be changed, so ACT felt it was better to have a common solution, even if
 it was clearly flawed compared to the ideal solution.
@@ -752,12 +815,14 @@
 Ted told me that the ARG was thinking along the lines of solutions that would
 violate both (a) and (b) above, which i find completely unacceptable.
 
-Certainly I can guarantee that ACT will not pay any attention to any such AI, we cannot
-afford to upset existing customers with gratuitous changes in this kind of area.
+Certainly I can guarantee that ACT will not pay any attention to any such AI,
+we cannot
+afford to upset existing customers with gratuitous changes in this kind of
+area.
 
 ****************************************************************
 
-From dewar@gnat.com Mon Dec 15 00:07 EST 1997
+>From dewar@gnat.com Mon Dec 15 00:07 EST 1997
 Date: Sun, 14 Dec 97 19:03:14 EST
 Subject: Re: what to do about AI 131?
 
@@ -783,7 +848,7 @@
 
 ****************************************************************
 
-From baker@dad.cs.fsu.edu Mon Dec 15 00:35 EST 1997
+>From baker@dad.cs.fsu.edu Mon Dec 15 00:35 EST 1997
 Date: Mon, 15 Dec 1997 00:35:48 GMT
 Subject: Re: what to do about AI 131?
 
@@ -806,7 +871,7 @@
 
 ****************************************************************
 
-From dewar@gnat.com Mon Dec 15 00:55 EST 1997
+>From dewar@gnat.com Mon Dec 15 00:55 EST 1997
 Date: Sun, 14 Dec 97 19:50:29 EST
 Subject: Re: what to do about AI 131?
 
@@ -828,7 +893,7 @@
 
 ****************************************************************
 
-From baker@dad.cs.fsu.edu Mon Dec 15 13:56 EST 1997
+>From baker@dad.cs.fsu.edu Mon Dec 15 13:56 EST 1997
 Date: Mon, 15 Dec 1997 13:55:51 GMT
 Subject: Re: what to do about AI 131?
 
@@ -841,7 +906,8 @@
 | use it with an essentially infinite value, then you get the semantics that
 | the RM should have recommended in the first place. Namely that, as in C,
 | if you want to passa a struct, you pass a struct (record), and if you want
-| to pass a pointer-to-srtuct, you pass a pointer-to-struct (access-to-record).
+| to pass a pointer-to-srtuct, you pass a pointer-to-struct (access-to-
+record).
 | This is obviously what the impl advice in the RM *should* have said, but
 | did not.
 
@@ -861,7 +927,7 @@
 
 ****************************************************************
 
-From dewar@gnat.com Mon Dec 15 15:23 EST 1997
+>From dewar@gnat.com Mon Dec 15 15:23 EST 1997
 Date: Mon, 15 Dec 97 10:19:00 EST
 Subject: Re: what to do about AI 131?
 
@@ -880,24 +946,25 @@
 
 ****************************************************************
 
-From ploedere@droste.informatik.uni-stuttgart.de Mon Dec 15 15:13 EST 1997
+>From ploedere@droste.informatik.uni-stuttgart.de Mon Dec 15 15:13 EST 1997
 Date: Mon, 15 Dec 1997 16:13:22 +0100 (MET)
 Subject: Re: what to do about AI 131?
 
-> But we are talking about a case where the vendors have formally met, discussed
+> But we are talking about a case where the vendors have formally met,
+discussed
 > the issue, and in the context of an industry association (the ARA) have
 > agreed to a common solution, and have/(are in the progress of) implemejting
 > a common solution.
 
 Great. Then pass it on to the ARG as the ARA proposal for a "standard"
 extension to the standard.  That's the intent of such a commonly agreed
-proposal, isn't it ? 
+proposal, isn't it ?
 
 Erhard
 
 ****************************************************************
 
-From dewar@gnat.com Mon Dec 15 16:34 EST 1997
+>From dewar@gnat.com Mon Dec 15 16:34 EST 1997
 Date: Mon, 15 Dec 97 11:29:32 EST
 Subject: Re: what to do about AI 131?
 
@@ -939,7 +1006,7 @@
 
 ****************************************************************
 
-From dewar@gnat.com Mon Dec 15 16:35 EST 1997
+>From dewar@gnat.com Mon Dec 15 16:35 EST 1997
 Date: Mon, 15 Dec 97 11:30:54 EST
 Subject: Re: what to do about AI 131?
 
@@ -960,7 +1027,7 @@
 
 ****************************************************************
 
-From stt@inmet.com Mon Dec 15 17:42 EST 1997
+>From stt@inmet.com Mon Dec 15 17:42 EST 1997
 Date: Mon, 15 Dec 1997 12:32:53 -0500
 Subject: Re: what to do about AI 131?
 
@@ -980,7 +1047,7 @@
 
 ****************************************************************
 
-From dewar@gnat.com Mon Dec 15 22:51 EST 1997
+>From dewar@gnat.com Mon Dec 15 22:51 EST 1997
 Date: Mon, 15 Dec 97 17:45:52 EST
 Subject: Re: what to do about AI 131?
 
@@ -993,7 +1060,7 @@
 
 ****************************************************************
 
-From bobduff@world.std.com Mon Dec 15 20:01 EST 1997
+>From bobduff@world.std.com Mon Dec 15 20:01 EST 1997
 Date: Mon, 15 Dec 1997 15:01:31 -0500
 Subject: Re: what to do about AI 131?
 
@@ -1023,11 +1090,12 @@
 
 ****************************************************************
 
-From baker@dad.cs.fsu.edu Mon Dec 15 20:12 EST 1997
+>From baker@dad.cs.fsu.edu Mon Dec 15 20:12 EST 1997
 Date: Mon, 15 Dec 1997 20:12:39 GMT
 Subject: Re: what to do about AI 131?
 
-| But we are talking about a case where the vendors have formally met, discussed
+| But we are talking about a case where the vendors have formally met,
+discussed
 | the issue, and in the context of an industry association (the ARA) have
 | agreed to a common solution, and have/(are in the progress of) implemejting
 | a common solution.
@@ -1042,7 +1110,7 @@
 
 ****************************************************************
 
-From dewar@gnat.com Mon Dec 15 23:06 EST 1997
+>From dewar@gnat.com Mon Dec 15 23:06 EST 1997
 Date: Mon, 15 Dec 97 18:01:45 EST
 Subject: Re: what to do about AI 131?
 
@@ -1089,7 +1157,7 @@
 
 ****************************************************************
 
-From dewar@gnat.com Tue Dec 16 00:25 EST 1997
+>From dewar@gnat.com Tue Dec 16 00:25 EST 1997
 Date: Mon, 15 Dec 97 19:20:32 EST
 To: arg95@sw-eng.falls-church.va.us, eachus@mitre.org
 
@@ -1107,22 +1175,25 @@
 
 ****************************************************************
 
-From ncohen@us.ibm.com Tue Dec 16 04:18 EST 1997
+>From ncohen@us.ibm.com Tue Dec 16 04:18 EST 1997
 Date: Mon, 15 Dec 1997 23:17:09 -0500
 Subject: Re: what to do about AI 131?
 
 Bob Duff wrote:
 
 <<I think this AI should be a confirmation.  I think the answer in this case
-should agree with what the ARA decided, even if the ARG doesn't like it.  There
+should agree with what the ARA decided, even if the ARG doesn't like it.
+There
 are two ways to do that: (1) The AI could confirm the language as is, and in
 addition explicitly bless the C_Pass_By_Copy feature.  Or (2) the AI could
 confirm the language as is, and not mention C_Pass_By_Copy.  I prefer (1).>>
 
 So do I.  But more importantly, when the ARG reports this action back to WG9,
-we should call attention to it and state that we anticipate many more cases in
+we should call attention to it and state that we anticipate many more cases
+in
 which the preferred solution will be to accept a de facto consensus that has
-emerged among implementors.  We should then ask WG9 to formulate an appropriate
+emerged among implementors.  We should then ask WG9 to formulate an
+appropriate
 mechanism for dealing with such cases, because this is really a matter of WG9
 policy rather than ARG technical judgment.
 
@@ -1132,16 +1203,18 @@
 part of some official WG9 report.
 
 The reason we might want to bother doing this is purely political:  There are
-some people who might object that a problem cannot be solved by standard means
+some people who might object that a problem cannot be solved by standard
+means
 (even if all CURRENT implementations happen to use the same
-implementation-defined solution), but would happily settle for a solution that
+implementation-defined solution), but would happily settle for a solution
+that
 has an ISO imprimatur, even if it is only a nonbinding recommendation.
 
 -- Norman
 
 ****************************************************************
 
-From phl@Rational.Com Tue Dec 16 10:24 EST 1997
+>From phl@Rational.Com Tue Dec 16 10:24 EST 1997
 Date: Tue, 16 Dec 1997 11:23:35 +0000
 Subject: Re: what to do about AI 131?
 
@@ -1161,11 +1234,14 @@
 Although you seem to dislike formal documents these days, I still find the
 above description for convention C_Pass_By_Copy awfully vague.
 
-We (Rational Software) have not yet implemented this C_Pass_By_Copy thing.  Of
+We (Rational Software) have not yet implemented this C_Pass_By_Copy thing.
+Of
 course, we are not going to reinvent the wheel, so we would like to implement
 the same semantics as GNAT/Intermetrics.  But I am sorry to say that, after
-reading the above 4 lines 5 times, I still don't know what I should implement.
- Is C_Pass_By_Copy allowed for non-record types?  For by-reference types?  Are
+reading the above 4 lines 5 times, I still don't know what I should
+implement.
+ Is C_Pass_By_Copy allowed for non-record types?  For by-reference types?
+Are
 types in Interfaces.C C_Pass_By_Copy-compatible?
 
 Surely the answers to these questions were clear when Tuck and you discussed
@@ -1179,9 +1255,11 @@
 invented their own mechanism.
 
 To summarize, I am strongly opposed to closing this AI as "no action" or as a
-confirmation merely quoting the GNAT documentation.  This AI should refine the
+confirmation merely quoting the GNAT documentation.  This AI should refine
+the
 definition of the convention, in a way which is acceptable to all the vendors
-who have already implemented it (and if we cannot find such a definition, then
+who have already implemented it (and if we cannot find such a definition,
+then
  we have a problem).
 
 Pascal
@@ -1192,7 +1270,7 @@
 
 ****************************************************************
 
-From dewar@gnat.com Tue Dec 16 10:54 EST 1997
+>From dewar@gnat.com Tue Dec 16 10:54 EST 1997
 Date: Tue, 16 Dec 97 05:49:12 EST
 Subject: Re: what to do about AI 131?
 
@@ -1220,7 +1298,7 @@
 
 ****************************************************************
 
-From ploedere@droste.informatik.uni-stuttgart.de Tue Dec 16 17:27 EST 1997
+>From ploedere@droste.informatik.uni-stuttgart.de Tue Dec 16 17:27 EST 1997
 Date: Tue, 16 Dec 1997 18:27:07 +0100 (MET)
 Subject: To all Implementors !! was: Re: what to do about AI 131?
 
@@ -1233,7 +1311,7 @@
 
 ****************************************************************
 
-From eachus@mitre.org Tue Dec 16 21:03 EST 1997
+>From eachus@mitre.org Tue Dec 16 21:03 EST 1997
 Date: Tue, 16 Dec 1997 16:03:50 -0500
 Subject: Re: what to do about AI 131?
 
@@ -1242,7 +1320,7 @@
 >C_Pass_By_COpy convention over the pragma, or even not mentioning the
 >pragma. It won't make any difference, btu if it makes people
 >feel that somehow things are being done in a more correct fashion, fine :-)
- 
+
     Not more correct, but it should be the default choice.  If you can use
 the per type C_Pass_By_Copy, it doesn't burn other users, and doesn't have
 configuration control problems.  The Import and Export arguments are
@@ -1259,7 +1337,7 @@
 
 ****************************************************************
 
-From jmk7hj31@aurora.cdev.com Tue Dec 16 22:18 EST 1997
+>From jmk7hj31@aurora.cdev.com Tue Dec 16 22:18 EST 1997
 Date: Tue, 16 Dec 1997 16:18:28 -0600
 From: Mike Kamrad <J.M.KAMRAD.II@cdev.com>
 Subject: Re: To all Implementors !! was: Re: what to do about AI 131?
@@ -1276,7 +1354,7 @@
 
 ****************************************************************
 
-From baker@dad.cs.fsu.edu Tue Dec 16 22:21 EST 1997
+>From baker@dad.cs.fsu.edu Tue Dec 16 22:21 EST 1997
 Date: Tue, 16 Dec 1997 22:21:09 GMT
 Subject: Re: what to do about AI 131?
 
@@ -1308,14 +1386,14 @@
 
 ****************************************************************
 
-From dewar@gnat.com Wed Dec 17 03:55 EST 1997
+>From dewar@gnat.com Wed Dec 17 03:55 EST 1997
 Date: Tue, 16 Dec 97 22:51:02 EST
 Subject: Re: To all Implementors !! was: Re: what to do about AI 131?
 
 What puzzles me is the following: According to Ted, the substance of
 the proposal that WG9 turned down was precisely a precise characterization
 of something approximating the current Aonix/GNAT implementation of
-C_Pass_By_Copy. 
+C_Pass_By_Copy.
 
 Is this true?
 
@@ -1332,14 +1410,14 @@
 
 ****************************************************************
 
-From stt@inmet.com Wed Dec 17 06:14 EST 1997
+>From stt@inmet.com Wed Dec 17 06:14 EST 1997
 Date: Wed, 17 Dec 1997 01:14:21 -0500
 Subject: Re: To all Implementors !! was: Re: what to do about AI 131?
 
 > Incidentally, I would have been delighted to have a more formal
 > definition of the feature. All we had was a rough description by
 > email, and we did our best to conform to it, but no one disagrees
-> that it would be nice to have a more formal document. 
+> that it would be nice to have a more formal document.
 
 For what it is worth, I believe Vince DelVecchio wrote up a formal
 definition of C_Pass_By_Copy and put it on the "ACE" (Ada Common Environment)
@@ -1349,7 +1427,7 @@
 
 ****************************************************************
 
-From phl@Rational.Com Wed Dec 17 10:19 EST 1997
+>From phl@Rational.Com Wed Dec 17 10:19 EST 1997
 Date: Wed, 17 Dec 1997 11:18:12 +0000
 Subject: Re: what to do about AI 131?
 
@@ -1359,11 +1437,11 @@
 
 Consider:
 
-	type T1 is record ... end record;
-	pragma Convention (C_Pass_By_Copy, T1);
+        type T1 is record ... end record;
+        pragma Convention (C_Pass_By_Copy, T1);
 
-	type T2 is access procedure (X : T1; Y : Interfaces.C.Int);
-	pragma Convention (C_Pass_By_Copy, T2); -- Legal?
+        type T2 is access procedure (X : T1; Y : Interfaces.C.Int);
+        pragma Convention (C_Pass_By_Copy, T2); -- Legal?
 
 For the pragma Convention on T2 to be legal, Interfaces.C.Int has to be
 C_Pass_By_Copy-compatible, as per RM95 B.1(18).
@@ -1371,14 +1449,15 @@
 I have no doubt that the types in Interfaces.C should be
 C_Pass_By_Copy-compatible (but that should be stated in the AI).  However,
 things become more delicate when you consider user-defined types, because
-there is no way to state that a type is compatible with several conventions (a
+there is no way to state that a type is compatible with several conventions
+(a
 hole in the language IMHO).  Consider:
 
-	type T3 is range ...;
-	pragma Convention (C, T3);
+        type T3 is range ...;
+        pragma Convention (C, T3);
 
-	type T4 is access procedure (X : T1; Y : T3);
-	pragma Convention (C_Pass_By_Copy, T4); -- Legal?
+        type T4 is access procedure (X : T1; Y : T3);
+        pragma Convention (C_Pass_By_Copy, T4); -- Legal?
 
 Assume that you cannot change the convention for T3, maybe because it's in a
 3rd-party package.  Then if we don't do anything, the pragma Convention on T4
@@ -1393,7 +1472,7 @@
 
 ****************************************************************
 
-From dewar@gnat.com Wed Dec 17 13:00 EST 1997
+>From dewar@gnat.com Wed Dec 17 13:00 EST 1997
 Date: Wed, 17 Dec 97 07:55:14 EST
 Subject: Re: what to do about AI 131?
 
@@ -1416,20 +1495,20 @@
 
 ****************************************************************
 
-From ploedere@droste.informatik.uni-stuttgart.de Wed Dec 17 13:43 EST 1997
+>From ploedere@droste.informatik.uni-stuttgart.de Wed Dec 17 13:43 EST 1997
 Date: Wed, 17 Dec 1997 14:43:18 +0100 (MET)
 Subject: Re: what to do about AI 131?
 
 > What puzzles me is the following: According to Ted, the substance of
 > the proposal that WG9 turned down was precisely a precise characterization
 > of something approximating the current Aonix/GNAT implementation of
-> C_Pass_By_Copy. 
+> C_Pass_By_Copy.
 >
 > Is this true?
 
 No, this is not true. I reiterate: WG9 has not really discussed that
 proposal. And, the pragma proposal was in no way made more precise than
-what we got from GNAT or wherever. 
+what we got from GNAT or wherever.
 
 What WG9 saw was a presentation of the problem of AI-131 (at the London
 meeting), as requested by WG9 (at the Phila. meeting) in response to the ARG
@@ -1442,22 +1521,22 @@
 My personal understanding at the time was that this was a fairly quickly
 hashed out solution that involved only GNAT and Intermetrics, combined with
 rumors that the two implementations then proceeded to implement it with
-somewhat differing semantics. 
+somewhat differing semantics.
 
 So much for history, now to the future...The WG9 resolution implies to me
 that WG9 wants to be presented with a solution that is common among vendors.
 To be common, its semantics need to be commonly agreed upon by the vendors
 (preferred) or be put forth by the ARG, based on input from the vendors and
-playing the arbitration role among conflicting views (hopefully not). 
+playing the arbitration role among conflicting views (hopefully not).
 
 To call this a "no action" item is esentially admitting defeat by saying
-"no, there is no common definition possible".  
+"no, there is no common definition possible".
 
 Erhard
 
 ****************************************************************
 
-From dewar@gnat.com Wed Dec 17 13:51 EST 1997
+>From dewar@gnat.com Wed Dec 17 13:51 EST 1997
 Date: Wed, 17 Dec 97 08:46:16 EST
 Subject: Re: what to do about AI 131?
 
@@ -1481,13 +1560,13 @@
 
 ****************************************************************
 
-From: 	Erhard Ploedereder[SMTP:ploedere@informatik.uni-stuttgart.de]
-Sent: 	Wednesday, May 06, 1998 7:07 PM
-Subject: 	Re: AI 131, revisited
+From:   Erhard Ploedereder[SMTP:ploedere@informatik.uni-stuttgart.de]
+Sent:   Wednesday, May 06, 1998 7:07 PM
+Subject:        Re: AI 131, revisited
 
 
 Based on all the words in the appendix, I don't think that this AI will
-fly (at least not with me) unless the semantics of the pragma are 
+fly (at least not with me) unless the semantics of the pragma are
 stated in detail. Questions like:
    -- effect on Ada parameter passing of actuals of such type
    -- applies to derived types ? subtypes ?
@@ -1500,9 +1579,9 @@
 
 ****************************************************************
 
-From: 	Ted Baker
-Sent: 	Wednesday, May 06, 1998 5:52 PM
-Subject: 	Re: AI 131, revisited
+From:   Ted Baker
+Sent:   Wednesday, May 06, 1998 5:52 PM
+Subject:        Re: AI 131, revisited
 
 Erhard,
 
@@ -1525,7 +1604,7 @@
 questions, here are some ideas, for continuing the discussion:
 
 | Based on all the words in the appendix, I don't think that this AI will
-| fly (at least not with me) unless the semantics of the pragma are 
+| fly (at least not with me) unless the semantics of the pragma are
 | stated in detail. Questions like:
 
 |    -- effect on Ada parameter passing of actuals of such type
@@ -1567,13 +1646,13 @@
 
 ****************************************************************
 
-From: 	Jean-Pierre Rosen[SMTP:rosen.adalog@wanadoo.fr]
-Sent: 	Thursday, May 07, 1998 1:47 AM
-To: 	arg95@ns1.sw-eng.falls-church.va.us
-Subject: 	Re: AI 131, revisited
+From:   Jean-Pierre Rosen[SMTP:rosen.adalog@wanadoo.fr]
+Sent:   Thursday, May 07, 1998 1:47 AM
+To:     arg95@ns1.sw-eng.falls-church.va.us
+Subject:        Re: AI 131, revisited
 
 >| Based on all the words in the appendix, I don't think that this AI will
->| fly (at least not with me) unless the semantics of the pragma are 
+>| fly (at least not with me) unless the semantics of the pragma are
 >| stated in detail. Questions like:
 >
 >|    -- effect on Ada parameter passing of actuals of such type
@@ -1589,9 +1668,9 @@
 
 ****************************************************************
 
-From: 	Robert Dewar
-Sent: 	Thursday, May 07, 1998 6:00 AM
-Subject: 	Re: AI 131, revisited
+From:   Robert Dewar
+Sent:   Thursday, May 07, 1998 6:00 AM
+Subject:        Re: AI 131, revisited
 
 <<Well, it should at least also apply to exported Ada procedures...
 >>
@@ -1600,9 +1679,9 @@
 
 ****************************************************************
 
-From: 	Ted Baker[SMTP:baker@dad.cs.fsu.edu]
-Sent: 	Thursday, May 07, 1998 7:25 AM
-Subject: 	Re: AI 131, revisited
+From:   Ted Baker[SMTP:baker@dad.cs.fsu.edu]
+Sent:   Thursday, May 07, 1998 7:25 AM
+Subject:        Re: AI 131, revisited
 
 | >|    -- effect on Ada parameter passing of actuals of such type
 | >
@@ -1631,12 +1710,36 @@
 
 ****************************************************************
 
-From: 	Robert Dewar[SMTP:dewar@gnat.com]
-Sent: 	Thursday, May 07, 1998 7:47 AM
-Subject: 	Re: AI 131, revisited
+From:   Robert Dewar[SMTP:dewar@gnat.com]
+Sent:   Thursday, May 07, 1998 7:47 AM
+Subject:        Re: AI 131, revisited
 
 Of course! Absolutely it is the case that exported procedures with
 convention C are affected! This is the case in current implementations
 most certainly!
 
 ****************************************************************
+
+From: 	Pascal Leroy
+Sent: 	Thursday, November 05, 1998 8:43 AM
+Subject: 	Re: AI-00131
+
+> That's confusing, the issue is not really pass by copy or not, since
+> C always passes by copy. The issue is passing this in a manner compatible
+> with a parameter of type struct on the C side. The existing implementation
+> advice is written in this style, so the AI should also use this language.
+
+You're right.  I was trying to make the summary simple and it's actually
+inaccurate.  I believe that the wording in other sections of the AI is
+correct. It seems that the second paragraph of the summary should be replaced
+by:
+
+"An implementation which supports interfacing to C shall support pragma
+Convention with a C_Pass_By_Copy identifier.  An 'in' parameter of a
+C_Pass_By_Copy-compatible type T should be passed as a t argument to a C
+function, where t is the C struct corresponding to type T."
+
+Pascal
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent