Re: Ada array vs C pointer (call by reference)

[Adam Beneschan <adam@irvine.com>]

On Jun 28, 10:52 am, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Adam Beneschan <a...@irvine.com> writes:
> > On Jun 27, 3:14 pm, Keith Thompson <ks...@mib.org> wrote:
> >> It doesn't *mandate* the representation used by the C compiler; the
> >> author of the Interfaces.C implementation has to *know* the
> >> representation used by the C compiler.
>
> > Which is, of course, impossible without a crystal ball.
>
> No need for crystal balls.  Just read the documentation of the C
> compiler.

What do you mean by "the" C compiler?  My impression was that more
than one C compiler exists in the world.  And even for particular
target architectures, more than one C compiler exists for many of
these.  How is the Ada compiler supposed to know which one you're
using, without a crystal ball?  I get the impression that Adrian is
faced with that sort of problem; Maciej also mentioned this, and also
mentioned the real possibility that even one C compiler could use
differing representations for floats or other data types depending on
command-line flags.

I'm probably pretty confused here---I don't even know what we're
arguing about any more, and I could well be overinterpreting what some
people are saying.  Some people seem to think the Ada compiler will
know how the C compiler works, and some seem to go far enough to say
that the Ada compiler should be able to *guarantee* that types in
Interfaces.C will have the same representation, and that the RM
requires this.  I don't think that makes any sense.  Others have
seemed to imply that since multiple C compilers exist and that Ada
won't know for sure which one is being used, it's pointless to use
Interfaces.C; I don't think that makes sense either.  My
interpretation is that an Ada compiler vendor should know what the
data representations are for the *typical* C compiler used in the
typical fashion on that system (which may well be a C compiler made
available by the same vendor, or a related one), and should make
things so that Interfaces.C will work with that.  But since there's no
guarantee that any particular object file or library will have been
compiled with that C compiler, that's the most any Ada compiler can
do.

I also don't think there's any requirement for Ada to dig around
external files to figure out what the representations are.  I checked
a C book we had lying around, and while it gave no specific definition
for the representations of "int", "float", etc., it did say that the
boundaries of those types are available in <limits.h>.  This is (or
was) apparently part of the ANSI standard.  Does this mean that an Ada
compiler has to read <limits.h> [assuming it knows what the default
#include directory is] to find information about the types used by the
C compiler?  I really, really do not think there is any such RM
requirement.


> This whole argument started because somebody wanted to use Float instead
> of C_Float.  But there is nothing in the Ada RM saying that Float should
> correspond to anything in particular.  There IS something in the RM
> saying that C_Float corresponds to float as implemented by the C
> compiler(s) that the Ada compiler claims to support interfacing to.
> And the Ada compiler documentation will tell you which C compiler(s)
> are supported.

Yeah, I think those last two sentences are the key here.

                             -- Adam