CVS difference for ais/ai-00383.txt
--- ais/ai-00383.txt 2004/09/10 00:43:34 1.3
+++ ais/ai-00383.txt 2005/05/24 01:17:21 1.4
@@ -1,6 +1,7 @@
-!standard B.03(42) 04-08-31 AI95-00383/00
+!standard B.03(19) 05-05-23 AI95-00383/01
!class binding interpretation 04-08-31
+!status work item 05-05-23
!status received 04-08-31
@@ -8,6 +9,10 @@
+We do not require support for conventions other than Ada for unconstrained
+array objects, unconstrained array function results, and most unconstrained
The language requires support for C-compatible unconstrained array types
@@ -20,6 +25,31 @@
+ T is an access-to-object type and its designated type is L-compatible.
+ T is an access-to-object type, its designated type is L-compatible,
+ and either its designated subtype is not an unconstrained array subtype
+ or L is Ada.
+Add after B.1(39) (in the Implementation Advice section):
+ The recommended level of support for an interfacing pragma specifying a
+ convention other than Ada or Intrinsic does not include the following cases:
+ - An interfacing pragma applied to an object whose nominal subtype is
+ an unconstrained array subtype.
+ - An Export or Convention pragma applied to a subprogram which has
+ a parameter of an unconstrained array subtype.
+ - An interfacing pragma applied to a function with
+ an unconstrained array result subtype.
Consider the following example:
@@ -77,6 +107,102 @@
A call (from Ada) to a convention-C function with an unconstrained array result
presents much the same problem; the caller does not know the bounds of the
+The phrase "for a language" in B.1(12) means that nothing in B.1(12-19)
+applies in the case where L = Intrinsic. Thus, there is no need to mention
+the L = Intrinsic case in the revised B.1(17).
+In the following example (for which support is recommended)
+ procedure Proc (X : String);
+ pragma Import (C, Proc, "Foobar");
+, it is expected that callers will pass in no bounds information.
+There has been some concern expressed that under the terms of this proposal,
+it is not possible to write a portable program that (1) calls a C function
+that returns a String (a char*, really); or (2) implements a callback that
+has String (or equivalently Char_Array) parameters.
+It has never been possible to write portable code which uses these constructs;
+this proposal is only an explicit recognition of the existing state of affairs.
+Furthermore, this is not a big problem in practice. In most cases where no
+better solution is available, it suffices to declare a constrained array
+subtype (or an access type designating same) that is "big enough". For example,
+ subtype Big_String is Interfaces.C.Char_Array (0 .. 500000);
+ procedure P (X : Big_String);
+ pragma Export (C, P, "aabbcc");
+This imprecise representation need only be used until precise bounds
+information becomes available:
+ procedure P (X : Big_String) is
+ subtype S is Interfaces.C.Char_Array (0 .. Get_Length (X));
+ type S_Ref is access all S;
+ for S_Ref'Storage_Size use 0;
+ function Cvt is new Unchecked_Conversion (System.Address, S_Ref);
+ -- or use System.Address_To_Access_Conversions instead
+ X_With_Correct_Bounds : S renames Cvt (X'Address).all;
+ -- no subsequent references to X; use X_With_Correct_Bounds instead.
+It is true that this is somewhat cumbersome, but no better alternative has
+One could explore the alternative of leaving the recommended level of
+support unmodified and instead working out a definition of the dynamic
+semantics of these constructs. Following the model of unchecked union
+types (whose discriminants are not represented at runtime), one could imagine
+"unchecked array" types (whose bounds are not represented at runtime).
+The notion of "inferable discriminants" could be generalized to include
+"inferable bounds" and much of the other wording from AI-216 would also
+carry over (e.g., discriminant check suppression => index check suppression).
+Unfortunately, the analogy breaks down in some important ways.
+All objects of a given unchecked union type are the same size.
+Thus, discriminant values are not needed in order to compute the size of an
+unchecked union object. There would be no way to compute the size of one of
+these "unchecked" array objects. This might be something fundamentally
+new for some compilers. At the very least, any operation which would normally
+require a size computation would have to be defined to raise Program_Error
+instead. This would affect assignment, concatenation, boolean vector operations,
+inherited constraints, etc.
+A call to a convention-Ada routine which expects to be passed a
+dope vector also could not be supported, nor could evaluation of
+bounds-related array attributes. Finally, the unsupported operations for
+unchecked union types listed in AI-216 would also be unsupported
+(i.e., equality testing, membership tests, conversion to a "normal" array type,
+and streaming attributes).
+Given that all these commonly used constructs would fail, it would
+be silly to claim that the language supports these "dopeless" array types.
+Furthermore, these failures would result in runtime errors whereas the
+proposed solution, while cumbersome, allows rejection of unsupported
+constructs at compile time.
+Tuck reports that "We support unconstrained arrays as parameters in C
+conventions by giving the array the maximum bounds (i.e. index_subtype'first
+Nothing in this proposal would prevent an implementation from choosing this
Questions? Ask the ACAA Technical Agent