CVS difference for ais/ai-00131.txt

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

--- ais/ai-00131.txt	1998/11/18 19:41:48	1.5
+++ ais/ai-00131.txt	1999/02/28 00:31:13	1.6
@@ -1,4 +1,4 @@
-!standard B.3      (69)                               98-11-05  AI95-00131/06
+!standard B.3      (69)                               99-02-23  AI95-00131/07
 !class binding interpretation 98-11-05
 !status work item 98-11-05
 !status work item (revised by Ted Baker) 96-05-05
@@ -10,13 +10,14 @@
 !difficulty Hard
 !subject Interface to C -- passing records as parameters of mode 'in'
 
-!summary 98-11-05
+!summary 99-02-23
 
 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.
+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.
 
 !question 96-04-17
 
@@ -73,7 +74,7 @@
 
 See !recommendation.
 
-!discussion 98-11-05
+!discussion 99-02-23
 
 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
@@ -92,7 +93,7 @@
 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);
+   pragma Convention (C_Pass_By_Copy, T);
 
 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
@@ -105,8 +106,12 @@
 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.
+
+Although this is not explicitly stated in the RM, it is clear that an Ada
+function with result type T corresponds to a C function with return type t,
+where t is the C type corresponding to the Ada type T.
 
-!appendix 98-11-05
+!appendix 96-04-17
 
 !section B.3(69)
 !subject Interface to C -- passing records as parameters
@@ -197,7 +202,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
@@ -217,7 +222,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
@@ -244,7 +249,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
@@ -312,7 +317,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
 
@@ -379,7 +384,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
 
@@ -406,7 +411,7 @@
 
 ****************************************************************
 
->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
 
@@ -443,7 +448,7 @@
 
 ****************************************************************
 
->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
 
@@ -589,7 +594,7 @@
 
 ****************************************************************
 
->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
 
@@ -651,7 +656,7 @@
 
 ****************************************************************
 
->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
 
@@ -669,7 +674,7 @@
 >    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
@@ -726,7 +731,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
 
@@ -737,7 +742,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
 
@@ -752,7 +757,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?
 
@@ -779,7 +784,7 @@
 
 ****************************************************************
 
->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?
 
@@ -822,7 +827,7 @@
 
 ****************************************************************
 
->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?
 
@@ -848,7 +853,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?
 
@@ -871,7 +876,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?
 
@@ -893,7 +898,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?
 
@@ -927,7 +932,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?
 
@@ -946,7 +951,7 @@
 
 ****************************************************************
 
->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?
 
@@ -964,7 +969,7 @@
 
 ****************************************************************
 
->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?
 
@@ -1006,7 +1011,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?
 
@@ -1027,7 +1032,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?
 
@@ -1047,7 +1052,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?
 
@@ -1060,7 +1065,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?
 
@@ -1090,7 +1095,7 @@
 
 ****************************************************************
 
->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?
 
@@ -1110,7 +1115,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?
 
@@ -1157,7 +1162,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
 
@@ -1175,7 +1180,7 @@
 
 ****************************************************************
 
->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?
 
@@ -1214,7 +1219,7 @@
 
 ****************************************************************
 
->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?
 
@@ -1270,7 +1275,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?
 
@@ -1298,7 +1303,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?
 
@@ -1311,7 +1316,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?
 
@@ -1337,7 +1342,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?
@@ -1354,7 +1359,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?
 
@@ -1386,7 +1391,7 @@
 
 ****************************************************************
 
->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?
 
@@ -1410,7 +1415,7 @@
 
 ****************************************************************
 
->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?
 
@@ -1427,7 +1432,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?
 
@@ -1472,7 +1477,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?
 
@@ -1495,7 +1500,7 @@
 
 ****************************************************************
 
->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?
 
@@ -1536,7 +1541,7 @@
 
 ****************************************************************
 
->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?
 
@@ -1717,233 +1722,6 @@
 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
-
-****************************************************************
-
-From: 	Pascal Leroy[SMTP:phl@RATIONAL.COM]
-Sent: 	Friday, November 06, 1998 5:26 AM
-Subject: 	Re: AI-00131: function results
-
-I am looking at AI-00131 again, and I am puzzled by the following issue:
-
-In ANSI C, a function can return a struct (of course, it can also return a
-pointer to a struct).  The RM (i.e., the implementation advice in B.3(63-71))
-doesn't offer any guidance regarding the correspondance between the return
-type of a C function and the return type of the corresponding Ada function.
-
-The situation is quite clear in the case of scalars, but in the case of
-structs, it seems that the RM as it stands doesn't make it possible to write a
-portable interface (since it specifies nothing, the behavior is presumably
-implementation-defined).  Should C_Pass_By_Copy also apply to function
-results? Or am I missing something?
-
-Pascal
-
-****************************************************************
-
-From: 	Robert Dewar[SMTP:dewar@GNAT.COM]
-Sent: 	Friday, November 06, 1998 6:52 AM
-Subject: 	Re: AI-00131: function results
-
-I think it is quite wrong for an Ada function that specifies a record to
-be returned to accept a pointer-to-record, that seems strange. It would
-mean that an implicit dereference had to occur, which just seems wrong
-to me. This is quite different from the IN parameter case, where the
-corespondence is between call-by-reference on the Ada side, and passing
-pointers byt value on the C side.
-
-There is no return-by-reference (at least not in the sense that would be
-relevant here).
-
-So I think it is clear that this is NOT controlled by the pragma, if you
-specify that a function returns a record on the Ada side, then it must
-return a struct on the C side.
-
-****************************************************************
-
-From: 	Pascal Leroy[SMTP:phl@RATIONAL.COM]
-Sent: 	Friday, November 06, 1998 9:15 AM
-Subject: 	Re: AI-00131: function results
-
-> if you
-> specify that a function returns a record on the Ada side, then it must
-> return a struct on the C side.
-
-That's a very reasonable statement, but I still find worrisome that the RM
-doesn't say a word on this topic.
-
-Pascal
-
-****************************************************************
-
-From: 	Tucker Taft[SMTP:stt@INMET.COM]
-Sent: 	Friday, November 06, 1998 10:40 AM
-Subject: 	Re: AI-00131: function results
-
-I think there is the usual confusion between what the C source code
-looks like, and what the generated machine code looks like.
-When a struct is returned at the source level, at the generated
-machine code level, C often does the same thing that Ada does,
-have the caller pass in a pointer to a place on the stack where
-the result should be placed.
-
-If the object is sufficiently small, then rather than using a
-caller-allocated stack temp for the function result, one or more
-registers are used.  The question is whether one purpose of this
-pragma (or perhaps some alternative one we invent) is to distinguish
-between these two approaches at the machine code level, or
-whether we presume that the Ada compiler should "know" enough about
-the C compiler(s) on the target to make the right choice without
-direction.
-
-This is analogous to the parameter passing case, though in that
-case there are three alternatives at the machine code level for
-something which at the C source code level is by-value (rather
-than by pointer): pass in registers if sufficiently short, push onto
-the stack if medium size, and pass a pointer to a temp if very large.
-
-I think the C_Pass_By_Copy pragma has always suffered from
-a confusion between the source issues and the machine-level issues.
-It partly stems from the fact that some Ada compilers "know" more
-about how the target C compiler works, or there is a standard
-ABI, while other Ada compilers know less about the target C compiler
-and are using pragmas (like this one) to figure out what to do.
-
-Hopefully this AI would clarify the situation somewhat.
-
--Tuck
-
-****************************************************************
-
-From: 	Robert Dewar[SMTP:dewar@GNAT.COM]
-Sent: 	Friday, November 06, 1998 8:33 AM
-Subject: 	Re: AI-00131: function results
-
-<<That's a very reasonable statement, but I still find worrisome that the RM
-doesn't say a word on this topic.
-
-Pascal
->>
-
-Doesn't worry me, the RM is totally broken in this area anyway. Better it
-say nothing than make a horrible mistake saying the wrong thing, as was the
-case with records passed as parameters.
-
-As long as implementations do the right thing, who cares what the RM says
-in implementation advice? What is troublesome is when the RM has wrong
-advice :-)
-
-Certainly the AI can most certainly clean this up, but this AI is not a
-terribly important one anyway, since it only affects impl advice.
-
-The critical issue here wrt Pass_By_Copy has not been what the RM says,
-because that can be ignored, since it is impl advice, but rather trying
-to make compilers do the same thing.
-
-I personally think C_Pass_By_Copy is a horrible kludge. Nothing the RM
-says will change my mind. The reason we implemented it was to be compatible
-with what the IM front end did. I am not sure we made the right choice in
-doing this, but for sure what the RM said was not a factor in our
-thinking at all!
-
-The AI is about matching the RM to practice, not influencing practice!
-
-****************************************************************
-
-From: 	Robert Dewar[SMTP:dewar@GNAT.COM]
-Sent: 	Friday, November 06, 1998 11:02 AM
-Subject: 	Re: AI-00131: function results
-
-<<If the object is sufficiently small, then rather than using a
-caller-allocated stack temp for the function result, one or more
-registers are used.  The question is whether one purpose of this
-pragma (or perhaps some alternative one we invent) is to distinguish
-between these two approaches at the machine code level, or
-whether we presume that the Ada compiler should "know" enough about
-the C compiler(s) on the target to make the right choice without
-direction.
->>
-
-Of course the compiler has to know how to pass parameters. It is
-definitely NOT the function of the C_Pass_By_COpy pragma to tell
-the compiler whether to pass in registers or not.
-
-The C_Pass_By_Copy pragma merely means that you pass it the way
-C would pass a struct, no more, no less, so I don't really see
-any confusion at all here.
-
-It is the same as for an Integer passed to a C int. the compiler has
-to know whether to put this in a register, on the stack or ???
-
-The only reason we have an issue is the injudicious advice in the RM
-to do what is in fact clearly the wrong thing!
-
-In the case of returned values, we have no bad advice to tackle, so there
-is no issue. I think the AI will just confuse things if it starts talking
-about the implementation level issues that Tuck raises.
-
-The deal is simple, if you write
-
-   function q returns x;
-   pragma Import (q);
-
-where x is a record type, then this must use a calling sequence compatible
-with the C function
-
-   cx q();
-
-where cx is the corresponding C struct.
-
-No discussion of registers, stacks, or any other low level stuff is
-needed. It is always the job of the Ada compiler to know how to pass
-stuff according to the specified convention. A compiler that does not
-know enough should NOT attempt to recognize the convention!
-
-****************************************************************
-
-From: 	Robert A Duff[SMTP:bobduff@WORLD.STD.COM]
-Sent: 	Monday, November 09, 1998 3:28 PM
-Subject: 	Re: AI-00131: function results
-
-> Of course the compiler has to know how to pass parameters. It is
-> definitely NOT the function of the C_Pass_By_COpy pragma to tell
-> the compiler whether to pass in registers or not.
-
-I agree with Robert.  The RM, and the AI, only need to talk about what
-Ada decls correspond to what C decls.  There's no need to mention
-anything about registers, and temporary copies that are then passed by
-ref, &c -- for all that stuff, the Ada compiler just has to get it
-right.  Yes, that generally means the Ada compiler writer has to know
-what the C compiler is going to do.
-
-I also agree with Robert that the original RM rule that made
-C_Pass_By_Copy_Necessary, was mistaken -- and I take part of the blame
-for that.
-
-- Bob
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent