CVS difference for acs/ac-00011.txt

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

--- acs/ac-00011.txt	2001/09/13 20:04:18	1.1
+++ acs/ac-00011.txt	2001/09/19 00:04:37	1.2
@@ -33,3 +33,268 @@
 
 ****************************************************************
 
+From: Robert Duff
+Date: Friday, September 14, 2001, 8:47 AM
+
+> (Indeed, I see this type as gratuitous junk - we don't fix junk.)
+
+I'm not sure why it's gratuitous junk.  It reflects a common usage in C,
+and this package is supposed to have useful stuff like that.
+
+However, in C every array has aliased components (in the sense that you
+can form the address of any component), so it seems like any array that
+is of general use, and is intended for interfacing to C should have
+aliased components.
+
+It's such an easy fix...
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, September 18, 2001 3:08 AM
+
+<<However, in C every array has aliased components (in the sense that you
+can form the address of any component), so it seems like any array that
+is of general use, and is intended for interfacing to C should have
+aliased components.>>
+
+Hmmm! interesting, should convention C for an array imply this property?
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, September 18, 2001 2:57 AM
+
+<<(Indeed, I see this type as gratuitous junk - we don't fix junk.)>>
+
+Yes, we do :-)
+
+For the record, I agree with the very simple and harmless proposal to
+make this type have aliased components.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Friday, September 14, 2001, 2:58 PM
+
+> I'm not sure why it's gratuitous junk.  It reflects a common usage in C,
+> and this package is supposed to have useful stuff like that.
+
+I don't think packages should have things in them that user can do as easily
+themselves. For the use-adverse, a type like this is actually harder to use
+than declaring your own. If the package provided some operations on the type,
+then there would be some value, but that is not the case for this type.
+
+> However, in C every array has aliased components (in the sense that you
+> can form the address of any component), so it seems like any array that
+> is of general use, and is intended for interfacing to C should have
+> aliased components.
+
+I don't disagree. I just don't think this type should be in the package in the
+first place, and I doubt that there is much use of it, so I don't think we
+should be taking the risks of changing it.
+
+> It's such an easy fix...
+
+For implementors, sure. However, making a component aliased can cause the
+representation of an array to change. Thus, there is a (small) risk of breaking
+existing programs (if they depend in some way on the representation, not
+unlikely when interfacing). I would have thought that there are no such
+programs, but the existence of this comment means that somebody tried to use
+this type (heaven knows why). Persumably there are others who also did so.
+
+I don't think this type deserves introducing an incompatibility, no matter how
+small or unlikely.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, September 18, 2001 3:11 AM
+
+FUD! It is obvious in this particular case that making the components
+aliased will not change the representation in any existing Ada 95
+implementation.
+
+****************************************************************
+
+From: Robert Duff
+Date: Saturday, September 15, 2001, 2:12 PM
+
+> If the package provided some operations on the
+> type, then there would be some value, but that is not the case for this
+> type.
+
+Well, it provides all the usual operations like array indexing...
+
+> For implementors, sure. However, making a component aliased can cause the
+> representation of an array to change.
+
+Not in this case -- it's interfacing to C, so we know what it's
+representation is.  The components are "really" aliased on the C side,
+so the representation has to reflect that.
+
+> I don't think this type deserves introducing an incompatibility, no matter
+> how small or unlikely.
+
+Shrug.  I don't think it's worth expending a whole lot of energy arguing
+about it.
+
+****************************************************************
+
+From: Florian Weimer
+Date: Sunday, September 16, 2001 4:52 AM
+
+> Not in this case -- it's interfacing to C, so we know what it's
+> representation is.  The components are "really" aliased on the C side,
+> so the representation has to reflect that.
+
+There doesn't seem to be a requirement in the standard that
+chars_ptr_array is C compatible.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, September 18, 2001 4:05 AM
+
+OK, but that's really a language lawyer dancing on a pin type argument,
+you have to read what's implied in such a case, and of course this
+is implied.
+
+****************************************************************
+
+From: Robert Duff
+Date: Tuesday, September 18, 2001, 9:42 AM
+
+In case anyone is curious about where chars_ptr_array came from, I dug
+up the following comment.  Interestingly, the suggested instantiation
+was not added.
+
+- Bob
+
+================================================================
+
+!topic C interface packages
+!reference RM9X-B.3;5.0
+!from Robb Nebbe 94-09-07
+<<reference as: 94-4697.a Robb Nebbe 94-9-7>>
+!discussion
+
+I have been using the C interface packages extensively and a couple of
+possible improvements have come up during my work. I believe them
+to be quite minor in scope (there are almost no semantics to define)
+but nonetheless useful.
+
+
+1) It would be nice to add a function in package Interfaces.C
+
+function Is_Nul_Terminated (Item : in char_array) return Boolean;
+
+I have places in my code where I already have a char_array
+object (so I'm not converting from a String where there is
+an parameter Append_Nul) and need to check if it is Nul
+terminated (it is actually a precondition for a subprogram and
+me raising an exception is a lot better than a segmentation fault)
+In many cases I already know if a particular char_array is Nul
+terminated or not but every once in a while I find myself
+needing to check.
+
+
+2) The addition of the type chars_ptr_array in Interfaces.C.Strings
+and a preinstantiation of Interfaces.C.Pointers would be useful.
+
+
+type chars_ptr_array is array (size_t range <>) of chars_ptr;
+
+- and -
+
+with Interfaces.C.Strings; use Interfaces.C.Strings;
+
+package Interfaces.C.String_Lists is  -- or some other name.
+  new Interfaces.C.Pointers( Index         => size_t,
+                             Element       => chars_ptr
+                             Element_Array => chars_ptr_array,
+                             Terminator    => null_ptr );
+
+
+The use of char **foo or char *foo[] is fairly common in C; common
+enough that a preinstantiation of Interfaces.C.Pointers should
+probably be included in B.3. Even if a preinstantiation is not provided
+it should be made fairly simple to instantiate Interfaces.C.Pointers
+for this common case. Right now chars_ptr_array is the missing piece
+and I can't think of any good reasons to why it shouldn't be declared
+in Interfaces.C.Strings.
+
+In order to limit any confusion it might be a good idea to rename
+char_array_ptr (a general access type to char_array found in
+Interfaces.C.Strings) to char_array_access.
+
+- Robb Nebbe
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Tuesday, September 18, 2001, 10:37 AM
+
+> package Interfaces.C.String_Lists is  -- or some other name.
+>   new Interfaces.C.Pointers( Index         => size_t,
+>                              Element       => chars_ptr
+>                              Element_Array => chars_ptr_array,
+>                              Terminator    => null_ptr );
+
+This instantiation got me thinking on a totally unrelated issue.
+
+The formal array type Element_Array has aliased components, chars_ptr_array
+doesn't (in the language as it stands today).
+
+In TC1, we have a rule (4.6(12.1/1)) which forbids view conversions between
+array types if one array has aliased components and the other doesn't.  But it
+seems to me that we should also have a similar rule for actual/formal matching
+in generic instantiations.  Otherwise, it is possible to use a generic to
+circumvent 4.6(12.1/1).
+
+Or am I missing something?
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, September 18, 2001, 11:44 AM
+
+> In TC1, we have a rule (4.6(12.1/1)) which forbids view conversions between
+> array types if one array has aliased components and the other doesn't.  But it
+> seems to me that we should also have a similar rule for actual/formal matching
+> in generic instantiations.  Otherwise, it is possible to use a generic to
+> circumvent 4.6(12.1/1).
+
+Well, we already have 12.5.3(8): "If the formal type has aliased components,
+then so shall the actual."
+
+But it appears that an formal type with unaliased components could match an
+actual type with aliased components, thus not only circumventing 4.6(12.1/1),
+but actually requiring the wrong behavior.
+
+The question is whether changing 12.5.3(8) to require matching of the aliased
+component property is an unacceptible incompatibility. (If so, we could define
+a "run-time" check that would always be detected at compile-time for
+non-sharing implementations.)
+
+> Or am I missing something?
+
+I don't think so.
+
+Note that 12.5.3(8) makes it impossible to instantate Interfaces.C.Pointers
+with Chars_Ptr_Array. So it doesn't work for the use described in the comment.
+
+(I must say that I don't find the comment very convincing. The point of the
+standard packages is to provide building-blocks that a user couldn't easily
+program themselves - for instance, Interfaces.C.Short because its not obvious
+what the representation of the C type is, Interface.C.To_C because its not
+certain that the representation of C and Ada strings are the same, etc. In a
+case like this where there is no barrier to programming the type themselves, it
+simply clutters the package. I know that I never go looking in the predefined
+packages to see if there is a type that might help; I only do so when there is
+a solid reason for doing so.)
+
+Anyway, I take it that at least two ARG members here are calling for an AI??
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent