CVS difference for ais/ai-00383.txt

Differences between 1.3 and version 1.4
Log of other versions for file 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(70)
+!standard B.03(19)                                  05-05-23  AI95-00383/01
+!standard B.03(39)
 !class binding interpretation 04-08-31
+!status work item 05-05-23
 !status received 04-08-31
 !priority Low
 !difficulty Medium
@@ -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
+array objects.
 The language requires support for C-compatible unconstrained array types
@@ -20,6 +25,31 @@
+Replace B.1(17)
+    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
 function result.
+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
+been proposed.
+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
+.. index_subtype'last)".
+Nothing in this proposal would prevent an implementation from choosing this

Questions? Ask the ACAA Technical Agent