!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 WG9 Approved 06-06-09 !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) @drepl @xbullet, is passed as a t argument to a C function, where t is the C struct corresponding to the Ada type T.> @dby @xbullet, is passed as a t argument to a C function, where t is the C struct corresponding to the Ada type T.> !corrigendum B.03(69/1) @drepl @xbullet 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.> @dby @xbullet parameter of a type of convention C_Pass_By_Copy, is passed as a t* argument to a C function, where t is the C struct corresponding to the Ada type T.> !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. ****************************************************************