CVS difference for acs/ac-00011.txt

Differences between 1.2 and version 1.3
Log of other versions for file acs/ac-00011.txt

--- acs/ac-00011.txt	2001/09/19 00:04:37	1.2
+++ acs/ac-00011.txt	2001/09/21 01:57:44	1.3
@@ -298,3 +298,116 @@
 
 ****************************************************************
 
+From: Pascal Leroy
+Date: Wednesday, September 19, 2001, 4:12 AM
+
+I am certainly calling for an AI to fix the actual/formal matching rule, as it
+is clearly a hole in the language.
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Wednesday, September 19, 2001, 4:07 AM
+
+> Hmmm! interesting, should convention C for an array imply this property?
+
+No, I disagree, representation items should not affect the static semantics of a
+type.  Otherwise you run into the situation where the legality of a construct
+may depend on a Convention pragma appearing after that construct.  For instance:
+
+    type Acc is access constant Interfaces.C.Int;
+    type A is array (1 .. 10) of Interfaces.C.Int;
+    function F return A;
+    procedure P (X : Acc := F (1)'Access); -- Legal?
+    pragma Convention (C, A);
+
+With your proposal it would be impossible to check the legality of the 'Access
+attribute at the place where it occurs, because type A is not frozen at this
+place, and the Convention pragma would later make the components aliased.  To me
+that's a no-no: I believe in one-pass semantic analysis.
+
+This being said I'm in favor of making the components of Char_Ptr_Array aliased.
+This seems to be a simple, harmless change.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Wednesday, September 19, 2001, 9:10 AM
+
+I could see requiring that the *user* specify aliased for the
+array if they plan to also specify convention C, but that seems
+a bit onerous.
+
+> ...
+> This being said I'm in favor of making the components of Char_Ptr_Array
+> aliased. This seems to be a simple, harmless change.
+
+I agree.  Sounds like a "clarification" to me ;-).
+
+****************************************************************
+
+From: Ted Baker
+Date: Wednesday, September 19, 2001, 6:25 AM
+
+I've run into the problem of needing to alias components when doing
+C interfacing (Florist).  It would be convenient if convention C
+for an array would imply aliased.  However, I guess that would not
+solve the basic problem with the pointer-to-array types that are
+defined in the standard C interface packages, or would it?
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Wednesday, September 19, 2001, 1:35 PM
+
+> I could see requiring that the *user* specify aliased for the
+> array if they plan to also specify convention C, but that seems
+> a bit onerous.
+
+But then maybe the user doesn't want aliased components at all, e.g. because
+she is not creating pointers to elements of the array, or only does that on
+the C side.
+
+****************************************************************
+
+From: Florian Weimer
+Date: Wednesday, September 19, 2001, 2:46 PM
+
+Ted Baker <baker@dad.cs.fsu.edu> writes:
+
+> I've run into the problem of needing to alias components when doing
+> C interfacing (Florist).  It would be convenient if convention C
+> for an array would imply aliased.
+
+And for a record type, too?  Doesn't this cause problems when
+referring to C bit fields?  (I don't use C bit fields, I don't know if
+there's a portable way to interface to them from Ada.)
+
+> However, I guess that would not solve the basic problem with the
+> pointer-to-array types that are defined in the standard C interface
+> packages, or would it?
+
+For Interfaces.C, all types are required to be 'C-compatible',
+cf. B.3(42).  I don't think this requirement extends to
+Interfaces.C.Strings.  In addition, all array types in Interfaces.C
+explicitly have aliased components.
+
+Anyway, it is extremely unlikely that the aliased and unaliased
+representations of chars_ptr_array differ in an existing Ada
+implementation.  It is hard to image how one can store pointers in an
+array in a way which you cannot address the pointers individually.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Wednesday, September 19, 2001, 12:32 PM
+
+<< No, I disagree, representation items should not affect the static
+semantics of a type...>>
+
+Representation items OFTEN affect the static semantics of a type, e.g.
+pragma Packed means that no more derived subprograms can be given, and
+a SMALL clause for fixed-point can affect the value of static expressions.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent