!standard B.03(42) 04-08-31 AI95-00383/00 !standard B.03(70) !class binding interpretation 04-08-31 !status received 04-08-31 !priority Low !difficulty Medium !subject !summary !question The language requires support for C-compatible unconstrained array types (e.g. B.3(42) as applied to Interfaces.C.Char_Array). The correspondence described in B.3(70) applies to both constrained and unconstrained array types. This works fine in the Ada-calling-C direction, but not in the case of Ada-called-by-C. In the latter case, Ada is passed no information about the bounds of the array. How are Ada constructs which require bounds information supposed to work? !wording !discussion Consider the following example: with Interfaces.C; package Foo is subtype Char_Array is Interfaces.C.Char_Array; Buffer : Char_Array (1 .. 10) := "1234567890"; Renamed_Slice : Char_Array renames Buffer (3 .. 7); procedure Proc1 (X : Char_Array); pragma Export (C, Proc1, Link_Name => "proc1"); end Foo; package body Foo is procedure Proc1_Callback (X : Char_Array); pragma Import (C, Proc1, Lin_Name => "proc1_callback"); -- -- Written in C, this routine takes a char* argument, which it passes -- as the argument of a call to proc1. procedure Assert (Condition : Boolean) is Test_Failed : exception; begin if not Condition then raise Test_Failed; end if; end Assert; procedure Proc1 (X : Char_Array) is use type Char_Array; use type Interfaces.C.Size_T; begin Assert (X'First = Renamed_Slice'First); Assert (X'Last = Renamed_Slice'Last); Assert (X = Renamed_Slice); end Proc1; begin Proc1 (Renamed_Slice); Proc1_Callback (Renamed_Slice); end Foo; The current language rules don't provide any justification for rejecting this example, but it is not clear how it can be implemented. Compare this situation with the treatment of missing discriminants for Unchecked_Union types (AI-216). Discriminant checks are suppressed and each construct which would require accessing a missing discriminant is either statically illegal or is defined to raise Program_Error at runtime. It seems that an analogous set of rules is needed to handle this case. Just as "inferable discriminants" are defined for Unchecked_Union types, a corresponding definition of "inferable bounds" might make sense; on the other hand, this might not be worth the definitional complexity. 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. --!corrigendum !example !ACATS test !appendix From: Randy Brukardt Sent: Tuesday, August 31, 2004 6:02 PM Steve wrote: > The language requires support for C-compatible unconstrained array types > (e.g. B.3(42) as applied to Interfaces.C.Char_Array). The correspondence > described in B.3(70) applies to both constrained and unconstrained array types. > This works fine in the Ada-calling-C direction, but not in the case of > Ada-called-by-C. In the latter case, Ada is passed no information about the > bounds of the array. How are Ada constructs which require bounds information > supposed to work? Obviously, they don't. Since this is just Implementation Advice anyway, it can be ignored if it says something that is nonsense. Certainly, that is true in this case. We can also apply Dewar's rule here - the language says something stupid (C certainly can't call unconstrained arrays). Janus/Ada just rejects any pragma Import or Export that it doesn't know how to code generate. While I followed the IA as much as possible, I didn't sweat anything that I couldn't figure out... Still, the IA should be fixed (thus I opened an AI as noted above). ... >Compare this situation with the treatment of missing discriminants for >Unchecked_Union types (AI-216). Discriminant checks are suppressed and each >construct which would require accessing a missing discriminant is either >statically illegal or is defined to raise Program_Error at runtime. >It seems that an analogous set of rules is needed to handle this case. >Just as "inferable discriminants" are defined for Unchecked_Union types, >a corresponding definition of "inferable bounds" might make sense; on the other >hand, this might not be worth the definitional complexity. Certainly not. We should just not allow such declarations; they cannot mean anything useful. >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. Right; this is the same problem. It should be noted that a legality rule would be OK here, because the rule would not need to depend on the representation of the unconstrained array: *all* unconstrained arrays should be banned in parameters of Export to C (and most other languages, too) and function returns of Import from C. But this rule probably should be IA as well, because we don't want to prevent an implementation from doing this if they can figure out some meaning for it. ****************************************************************