CVS difference for ai12s/ai12-0028-1.txt

Differences between 1.4 and version 1.5
Log of other versions for file ai12s/ai12-0028-1.txt

--- ai12s/ai12-0028-1.txt	2013/01/03 04:49:48	1.4
+++ ai12s/ai12-0028-1.txt	2013/02/01 06:38:40	1.5
@@ -286,3 +286,132 @@
 the number of fixed arguments is needed for that, too.
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Monday, July 23, 2012  9:33 AM
+
+> Append after B.3(60.15/3)
+>
+> For some implementation-dependent integer M greater than or equal to
+> 16,
+
+I find this a weird way of specifying the requirement that you support at least
+_0 up to _16.  And where in the world did "16" come from? If we have such a
+requirement, I would put it in a separate sentence in the implementation
+requirements section.  E.g.:
+
+    Implementations shall support at least up to C_Variadic_16.
+
+> ... the identifiers C_Variadic_0, C_Variadic_1, C_Variadic_2, and on
+> up to C_Variadic_*M* are convention identifiers.
+
+If we drop "M" then this becomes simply:
+
+   ..., C_Variadic_2, and so on, are convention identifiers.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, July 23, 2012  10:58 AM
+
+> I find this a weird way of specifying the requirement that you support
+> at least _0 up to _16.  And where in the world did "16" come from?
+
+I see two choices here:
+    1) Don't require any support for this feature. That means
+       code that is intended to be portable can't use this feature.
+    2) Pick a number. I picked one - 16 just seemed like a reasonable
+       value. No more justification than that.
+
+I agree that the wording changes you suggested are improvements.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, July 23, 2012  11:12 AM
+
+> I see two choices here:
+> 1) Don't require any support for this feature. That means code that is
+> intended to be portable can't use this feature.
+> 2) Pick a number. I picked one - 16 just seemed like a reasonable
+> value. No more justification than that.
+
+I don't see any need for a limit here at all.  We don't specify elsewhere a
+separate requirement for number of parameters allowed in a subprogram.
+Implementations of course have some capacity limits, but pulling this number
+"16" out of a hat seems a bit bizarre at this stage.  I would presume this is
+just a pattern match thing, where if the convention name matches
+"C_Variadic_<integer>" and <integer> is less than or equal to the number of
+formal parameters, it is acceptable.
+
+I suppose one could argue for a separate aspect, something like First_Varying =>
+N+1, which would perhaps be easier to swallow. This would make it independent of
+the "language" specified by "Convention," which might be nice for interfacing to
+other languages that have similar capabilities.
+
+> I agree that the wording changes you suggested are improvements.
+
+Glad they were useful.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, July 23, 2012  12:04 PM
+
+> I don't see any need for a limit here at all.  We don't specify
+> elsewhere a separate requirement for number of parameters allowed in a
+> subprogram.
+
+Ok, you've convinced me.
+
+This felt like a different situation because it affects whether a given
+identifier is a recognized convention name, but I suppose this difference isn't
+really significant.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, July 24, 2012  6:09 PM
+
+> I would presume
+> this is just a pattern match thing, where if the convention name
+> matches "C_Variadic_<integer>" and <integer> is less than or equal to
+> the number of formal parameters, it is acceptable.
+
+Well that's a totally new mechanism, makes it MUCH harder to implement IMO.
+
+> I suppose one could argue for a separate aspect, something like
+> First_Varying => N+1, which would perhaps be easier to swallow.
+> This would make it independent of the "language" specified by
+> "Convention," which might be nice for interfacing to other languages
+> that have similar capabilities.
+
+Better
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, July 24, 2012  6:35 PM
+
+I think this would imply that the "calling convention" part of determining
+whether two profiles are subtype conformant (6.3.1(17/3)) would need to look at
+more than the Conventions of the two profiles.
+
+Consider:
+
+     procedure Proc (X, Y, Z : Integer) with Convention => C,
+                                             First_Varying => 2);
+
+     type Ref is access procedure (Xx, Yy, Zz : Integer)
+        with Convention => C;
+
+     Ptr : Ref := Proc'Access; -- legal?
+
+This example must be illegal (right?) and yet the profiles for Ref and Proc have
+the same Convention (i.e., C). So just looking at the convention isn't enough.
+
+We could certainly do this, but it seems to run counter to the idea that an Ada
+source-level Convention for a profile corresponds to an implementation level
+calling convention.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent