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

[Keith Thompson <kst-u@mib.org>]

Maciej Sobczak <see.my.homepage@gmail.com> writes:
> On 27 Cze, 18:11, Keith Thompson <ks...@mib.org> wrote:
> > > Ada *cannot* guarantee that Interfaces.C.C_Float is the *right* float,
> > > because it does not verify how the C code was compiled and there is a
> > > lot of freedom given to C implementers in this area.
> > > Same for all other types.
> >
> > No, Ada can't guarantee it directly.  Instead, Ada requires the
> > implementation to guarantee it.
> 
> And how the implementation can guarantee it without mandating the
> representation on the C compiler?

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.

And yes, the fact that different C compilers on the same system might
use different representations is an issue.

> Consider a C compiler that has a switch that selects the
> representation for fundamental types. It is not uncommon.
> I can have *the same* program compiled twice by *the same* compiler
> and the two versions will differ in representation of their
> fundamental types.
> 
> How Ada implementation can guarantee anything in this area?

The C compiler invoked with the switch and the same compiler invoked
without the switch are logically two different C implementations.

The Ada compiler, if it wants to support both of them, might provide
two distinct Interfaces.* subpackages, say Interfaces.C_Foo and
Interfaces.C_Bar.

It's an imperfect solution, but no perfect solution is possible.

> > Look at it this way.  You have the choice of using
> > Interfaces.C.C_Float, which (assuming the Ada implementation gets it
> > right), is guaranteed to match C's float
> 
> There is no way to guarantee that. The only way is to name two
> compilers and say that *they* are compatible with this and that
> switches. But then - there is no added value from Interfaces.C.XXX.

I disagree.  The developers of the particular implementation of
Interfaces.C have done the work of figuring out the characteristics of
the particular C implementation, so you don't have to.

> > Why would you even
> > consider using Float?
> 
> Because the amount of magic and handwaving in interfacing is the same
> as with Interfaces.C.C_float, but it is less typing. :-)

If you use Interfaces.C.C_float and it doesn't work, you can complain
to your Ada compiler vendor, who just might have a solution that's
better than anything you or I have thought of.

The bottom line is that there's no fundamental reason to assume that
Ada's Float and C's float have the same representation, or that an Ada
compiler should necessarily follow a C compiler's decisions regarding
type representations.  Though there's nothing wrong with doing so if
it happens to be convenient, as it is in the case of GNAT.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"