Ada array vs C pointer (call by reference)

Ada array vs C pointer (call by reference)

[Adrian Hoe]

Hi,

I have a C library function which takes a float * as a parameter. The
function is as below:

   int pwmRead (int pwmCount, float * data);

where data is an array of float which size is determined by pwmCount.

In Ada, I have:

   PWM_Count : Integer := No_Of_Components_Intended;
   PWM_Data : array (1 .. PWM_Count) of Float;

My concern is how safe to pass an Ada array to a C function as a
pointer (call by reference)? I presume Ada will allocate contiguous
memory for array, but what if it does not? How can we establish a
deterministic allocation and to make sure float * is accessed
contiguously? Is there any "safe" way to do this?

Thanks.
--
Adrian Hoe
http://adrianhoe.com

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

[Adrian Hoe]

On Jun 27, 9:39 am, Adrian Hoe <aby...@gmail.com> wrote:
> Hi,
>
> I have a C library function which takes a float * as a parameter. The
> function is as below:
>
>    int pwmRead (int pwmCount, float * data);
>
> where data is an array of float which size is determined by pwmCount.
>
> In Ada, I have:
>
>    PWM_Count : Integer := No_Of_Components_Intended;
>    PWM_Data : array (1 .. PWM_Count) of Float;
>
> My concern is how safe to pass an Ada array to a C function as a
> pointer (call by reference)? I presume Ada will allocate contiguous
> memory for array, but what if it does not? How can we establish a
> deterministic allocation and to make sure float * is accessed
> contiguously? Is there any "safe" way to do this?
>
> Thanks.
> --
> Adrian Hoehttp://adrianhoe.com


Sorry, PWM_Count should be declared as constant:

   PWM_Count : constant := No_Of_Components_Intended;

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

[Adam Beneschan]

On Jun 26, 6:39 pm, Adrian Hoe <aby...@gmail.com> wrote:
> Hi,
>
> I have a C library function which takes a float * as a parameter. The
> function is as below:
>
>    int pwmRead (int pwmCount, float * data);
>
> where data is an array of float which size is determined by pwmCount.
>
> In Ada, I have:
>
>    PWM_Count : Integer := No_Of_Components_Intended;
>    PWM_Data : array (1 .. PWM_Count) of Float;
>
> My concern is how safe to pass an Ada array to a C function as a
> pointer (call by reference)? I presume Ada will allocate contiguous
> memory for array, but what if it does not?

I've never heard of an Ada compiler that doesn't, absent some explicit
instruction (like a pragma) to do something unusual.  Even so, if
you're thinking of using an Ada compiler written on the planet
Zorxkrug where they might do some odd array allocation, you should
still be OK if you use the Convention pragma.  First of all, you
cannot declare PWM_Data with an anonymous array type, because then you
couldn't pass it as a parameter to *any* routine (what would the
parameter type be??).  So something like this should work:

    type Float_Array is array (Natural range <>) of Float;
    pragma Convention (C, Float_Array);
    PWM_Data : Float_Array (1 .. PWM_Count);

and now even the Zorxkrugian Ada compiler should allocate the array in
a way that will be compatible with the C code.  (In the Ada
declaration of pwmRead, the second parameter would have type
Float_Array.)

No guarantees, but a compiler that follows the Implementation Advice
should handle this correctly.

Oh, and you probably want to use Interfaces.C.C_Float instead of the
Ada type "Float", to ensure that you're using the same kind of float
that the C routine expects.

Hope this helps,

                            -- Adam

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

[Maciej Sobczak]

On 27 Cze, 04:55, Adam Beneschan <a...@irvine.com> wrote:

> Oh, and you probably want to use Interfaces.C.C_Float instead of the
> Ada type "Float", to ensure that you're using the same kind of float
> that the C routine expects.

Don't get me wrong, but I find it a bit of handwaving.
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.

In reality we have to rely on some external knowledge about the
implementation - but then, Interfaces.C.XXX have little added value,
because we might as well have the same knowledge about types from
Standard.

Is there any implementation where Interfaces.C.int has different
properties than Integer?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

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

[Adrian Hoe]

Maciej Sobczak wrote:
> On 27 Cze, 04:55, Adam Beneschan <a...@irvine.com> wrote:
>
> > Oh, and you probably want to use Interfaces.C.C_Float instead of the
> > Ada type "Float", to ensure that you're using the same kind of float
> > that the C routine expects.
>
> Don't get me wrong, but I find it a bit of handwaving.
> 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.
>
> In reality we have to rely on some external knowledge about the
> implementation - but then, Interfaces.C.XXX have little added value,
> because we might as well have the same knowledge about types from
> Standard.
>
> Is there any implementation where Interfaces.C.int has different
> properties than Integer?


Agree. Exactly my point.


> --
> Maciej Sobczak * www.msobczak.com * www.inspirel.com

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

[Georg Bauhaus]

Maciej Sobczak wrote:
> 
> Is there any implementation where Interfaces.C.int has different
> properties than Integer?

Try this with yours :-)

with Interfaces.C;

procedure Cint is
   use Interfaces;
   use type C.int;

   X: C.int;
begin
   X := C.int'last;
   X := X + 1;
end;

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

[Georg Bauhaus]

Georg Bauhaus wrote:
> Maciej Sobczak wrote:
>> Is there any implementation where Interfaces.C.int has different
>> properties than Integer?

> begin
>    X := C.int'last;
>    X := X + 1;
> end;

OK, no C side here, but I think you get the point.

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

[Maciej Sobczak]

On 27 Cze, 16:43, Georg Bauhaus <rm.tsoh.plus-
bug.bauh...@maps.futureapps.de> wrote:

> > Is there any implementation where Interfaces.C.int has different
> > properties than Integer?
>
> Try this with yours :-)
>
> with Interfaces.C;
>
> procedure Cint is
>    use Interfaces;
>    use type C.int;
>
>    X: C.int;
> begin
>    X := C.int'last;
>    X := X + 1;
> end;

CONSTRAINT_ERROR - overflow check failed.
I get the same with Integer.

What is the difference then?

And even assuming that on *your* implementation it is different - how
does it influence the interfacing with C? It does not, because
interfacing is about data transfer, not about arithmetics.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

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

[Georg Bauhaus]

Maciej Sobczak wrote:
> On 27 Cze, 16:43, Georg Bauhaus <rm.tsoh.plus-
> bug.bauh...@maps.futureapps.de> wrote:
> 
>>> Is there any implementation where Interfaces.C.int has different
>>> properties than Integer?
...
>> procedure Cint is
>>    use Interfaces;
>>    use type C.int;
>>
>>    X: C.int;
>> begin
>>    X := C.int'last;
>>    X := X + 1;
>> end;
> 
> CONSTRAINT_ERROR - overflow check failed.
> I get the same with Integer.
> 
> What is the difference then?

I should have made the example adress the difference
between the Ada types Integer and C.int as a representative
of C's int behavior.
In code that uses C integers I'll see C.int used, and
hence meaningfully different types. This points me to
different behavior on the C side even when inside Ada
it makes no difference:

int inc(int x) { return x + 1; }

with Interfaces.C, Ada.Text_IO;

procedure Cint is
   use Interfaces;
   use type C.int;

   function C_inc(X: C.int) return C.int;
   pragma import(C, C_inc, "inc");

   X: C.int;
begin
   X := C.int'last;
   X := C_inc(X);
   Ada.Text_IO.Put_Line(C.int'image(X));
end;

prompt>cint
-2147483648

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

[Keith Thompson]

Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> writes:
> Maciej Sobczak wrote:
> > On 27 Cze, 16:43, Georg Bauhaus <rm.tsoh.plus-
> > bug.bauh...@maps.futureapps.de> wrote:
> > 
> >>> Is there any implementation where Interfaces.C.int has different
> >>> properties than Integer?
> ...
> >> procedure Cint is
> >>    use Interfaces;
> >>    use type C.int;
> >>
> >>    X: C.int;
> >> begin
> >>    X := C.int'last;
> >>    X := X + 1;
> >> end;
> > 
> > CONSTRAINT_ERROR - overflow check failed.
> > I get the same with Integer.
> > 
> > What is the difference then?
> 
> I should have made the example adress the difference
> between the Ada types Integer and C.int as a representative
> of C's int behavior.
> In code that uses C integers I'll see C.int used, and
> hence meaningfully different types. This points me to
> different behavior on the C side even when inside Ada
> it makes no difference:
> 
> int inc(int x) { return x + 1; }
> 
> with Interfaces.C, Ada.Text_IO;
> 
> procedure Cint is
>    use Interfaces;
>    use type C.int;
> 
>    function C_inc(X: C.int) return C.int;
>    pragma import(C, C_inc, "inc");
> 
>    X: C.int;
> begin
>    X := C.int'last;
>    X := C_inc(X);
>    Ada.Text_IO.Put_Line(C.int'image(X));
> end;
> 
> prompt>cint
> -2147483648

Strictly speaking, signed integer overflow in C invokes undefined
behavior (what Ada calls "erroneous execution").

Two's-complement wraparound is certainly the most common behavior for
most C implementations, but a C optimizer can alter the generated code
based on the assumption that the overflow won't happen.  (That's not
likely in this particular case.)

-- 
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"

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

[Keith Thompson]

Maciej Sobczak <see.my.homepage@gmail.com> writes:
> On 27 Cze, 04:55, Adam Beneschan <a...@irvine.com> wrote:
> > Oh, and you probably want to use Interfaces.C.C_Float instead of the
> > Ada type "Float", to ensure that you're using the same kind of float
> > that the C routine expects.
> 
> Don't get me wrong, but I find it a bit of handwaving.
> 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.

> In reality we have to rely on some external knowledge about the
> implementation - but then, Interfaces.C.XXX have little added value,
> because we might as well have the same knowledge about types from
> Standard.
> 
> Is there any implementation where Interfaces.C.int has different
> properties than Integer?

I don't know, and I suggest that you don't know either.

To answer that question, you'd have to look at every existing Ada
implementation, and at every existing C implementation that targets
the same systems.

To answer it usefully, you'd also have to look at every *future*
implementation on which your code might run.

There is no fundamental reason to assume that Ada's Integer and C's
int have the same properties.  That's exactly why Interfaces.C exists.

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, or of using Float, which has
no such guarantee (but saves a little typing).  Why would you even
consider using Float?

-- 
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"

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

[Robert A Duff]

Keith Thompson <kst-u@mib.org> writes:

> Interfaces.C.C_Float, which (assuming the Ada implementation gets it
> right), is guaranteed to match C's float, or of using Float, which has
> no such guarantee (but saves a little typing).  Why would you even
> consider using Float?

You might have a program that uses Float all over the place,
and you want to add some interface to C in one tiny corner
of that program.  You might be tempted to use Float at the
interface to C in order to avoid a lot of type conversions.

It's a pretty good bet that Ada's Float and Ada's Interfaces.C.C_Float,
and C's float are all represented the same.  If you're using GNAT,
I think the documentation guarantees that.

But you're right -- the "right" way to interface to C is to use the
types in Interfaces.C, and use pragma Convention when you declare
your own types.

- Bob

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

[Keith Thompson]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
> > Interfaces.C.C_Float, which (assuming the Ada implementation gets it
> > right), is guaranteed to match C's float, or of using Float, which has
> > no such guarantee (but saves a little typing).  Why would you even
> > consider using Float?
> 
> You might have a program that uses Float all over the place,
> and you want to add some interface to C in one tiny corner
> of that program.  You might be tempted to use Float at the
> interface to C in order to avoid a lot of type conversions.
> 
> It's a pretty good bet that Ada's Float and Ada's Interfaces.C.C_Float,
> and C's float are all represented the same.  If you're using GNAT,
> I think the documentation guarantees that.
> 
> But you're right -- the "right" way to interface to C is to use the
> types in Interfaces.C, and use pragma Convention when you declare
> your own types.

And if you take the shortcut of assuming that Float and C_Float are
the same, and your program is later compiled on a system where they're
not, you're not likely to get an error message.  In the worst case,
you'll just get subtly wrong answers.

-- 
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"

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

[Stephen Leake]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Keith Thompson <kst-u@mib.org> writes:
>
>> Interfaces.C.C_Float, which (assuming the Ada implementation gets it
>> right), is guaranteed to match C's float, or of using Float, which has
>> no such guarantee (but saves a little typing).  Why would you even
>> consider using Float?
>
> You might have a program that uses Float all over the place,
> and you want to add some interface to C in one tiny corner
> of that program.  You might be tempted to use Float at the
> interface to C in order to avoid a lot of type conversions.

A better way to avoid a lot of type conversions is to provide a thin C
interface using Interfaces.C.C_Float, and a thin Ada wrapper that does
the type conversion to Ada.Float (or some other user provided type).

-- 
-- Stephe

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

[Keith Thompson]

Stephen Leake <Stephe.Leake@nasa.gov> writes:
> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> > Keith Thompson <kst-u@mib.org> writes:
> >> Interfaces.C.C_Float, which (assuming the Ada implementation gets it
> >> right), is guaranteed to match C's float, or of using Float, which has
> >> no such guarantee (but saves a little typing).  Why would you even
> >> consider using Float?
> >
> > You might have a program that uses Float all over the place,
> > and you want to add some interface to C in one tiny corner
> > of that program.  You might be tempted to use Float at the
> > interface to C in order to avoid a lot of type conversions.
> 
> A better way to avoid a lot of type conversions is to provide a thin C
> interface using Interfaces.C.C_Float, and a thin Ada wrapper that does
> the type conversion to Ada.Float (or some other user provided type).

That will still involve a lot of type conversions at run time, even if
you don't have to write a lot of them in your code.  If Float and
C_Float happen to have the same representation, that's fine.  But if
they differ, then the conversions could have bad numeric consequences.

To summarize:

Programming Is Hard.

-- 
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"

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

[Rob Norris]

On Fri, 27 Jun 2008 13:00:27 -0400, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:

>Keith Thompson <kst-u@mib.org> writes:
>
>> Interfaces.C.C_Float, which (assuming the Ada implementation gets it
>> right), is guaranteed to match C's float, or of using Float, which has
>> no such guarantee (but saves a little typing).  Why would you even
>> consider using Float?
>
>You might have a program that uses Float all over the place,
>and you want to add some interface to C in one tiny corner
>of that program.  You might be tempted to use Float at the
>interface to C in order to avoid a lot of type conversions.
>
>It's a pretty good bet that Ada's Float and Ada's Interfaces.C.C_Float,
>and C's float are all represented the same.  If you're using GNAT,
>I think the documentation guarantees that.
>
>But you're right -- the "right" way to interface to C is to use the
>types in Interfaces.C, and use pragma Convention when you declare
>your own types.
>
>- Bob

Not too sure where to put my 2p in this thread, but the 'right' way certainly works much better at
run time!
 
We have plenty of code that maps between Ada and C, some of it GNAT and gcc (but different versions
on different platforms) and also Ada and C#.

Every so often some one forgets and slips in an Ada float or integer in the data structures. Then at
runtime it either get strange results / constriant errors / crashes. Then I come to have a look and
go Aha - you should be using Interfaces.C - and these problems go away*

*Except for all the weird alignment issues of records / structures different compilers sometime
give.

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

[Maciej Sobczak]

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?

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?

> 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.

> 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. :-)

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

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

[Keith Thompson]

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"

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

[Adam Beneschan]

On Jun 27, 3:14 pm, Keith Thompson <ks...@mib.org> wrote:
> Maciej Sobczak <see.my.homep...@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.

Which is, of course, impossible without a crystal ball.  Anyway, I
don't see anything in the RM that makes any such requirement.  The
language involved uses a lot of "corresponds to" phrasing, which I
think is deliberately fuzzy enough to avoid *requiring* an Ada
implementation to do something that cannot realistically be done in a
guaranteed manner.  I think the idea is that the implementor is just
expected to define the types in a way that is probably going to make
things work right.  That's about as strong a statement as one can
make.  But, of course, it's still different from the standard Ada
types like Integer and Float; there are no such expectations put on
Ada implementations that the type representations correspond at all to
C types.

                                  -- Adam

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

[Stephen Leake]

Adam Beneschan <adam@irvine.com> writes:

> On Jun 27, 3:14 pm, Keith Thompson <ks...@mib.org> wrote:
>> Maciej Sobczak <see.my.homep...@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.
>
> Which is, of course, impossible without a crystal ball.  

No, the vendor must provide both the Ada compiler and the C compiler.
Are there any vendors out there that don't?

-- 
-- Stephe

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

[Keith Thompson]

Stephen Leake <Stephe.Leake@nasa.gov> writes:
> Adam Beneschan <adam@irvine.com> writes:
> > On Jun 27, 3:14 pm, Keith Thompson <ks...@mib.org> wrote:
> >> Maciej Sobczak <see.my.homep...@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.
> >
> > Which is, of course, impossible without a crystal ball.  
> 
> No, the vendor must provide both the Ada compiler and the C compiler.
> Are there any vendors out there that don't?

No, the vendor certainly doesn't have to provide both the Ada compiler
and the C compiler.  The author of the Ada compiler simply has to know
how the C compiler represents the various types, in order to get
Interfaces.C right.  In most cases, the C type representations are
mandated, or at least strongly suggested, by the underlying system.

(GNAT/gcc is the only case I know of where an Ada compiler and a C
compiler come from the same source.)

-- 
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"

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

[Adam Beneschan]

On Jun 28, 7:04 am, Stephen Leake <Stephe.Le...@nasa.gov> wrote:
> Adam Beneschan <a...@irvine.com> writes:
> > On Jun 27, 3:14 pm, Keith Thompson <ks...@mib.org> wrote:
> >> Maciej Sobczak <see.my.homep...@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.
>
> > Which is, of course, impossible without a crystal ball.
>
> No, the vendor must provide both the Ada compiler and the C compiler.
> Are there any vendors out there that don't?

Yes.

                       -- Adam

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

[Robert A Duff]

Adam Beneschan <adam@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.

Maybe you're worried that the C compiler will change the size of float
in a future version?  Well, first of all, that won't happen because it
will break existing C programs.  But if it does, then that's a new and
different implementation of C, and the Ada compiler would have to be
modified in order to support interfacing to it.  Why is that a problem?

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.

- Bob

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

[Adam Beneschan]

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

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

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> 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?

The one the compiler writer chooses to support, for interfacing.

Or more than one, if the compiler writer so chooses.

>...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?

The supported C compiler(s) should be documented.  If you use some other
C compiler, you're not playing by the rules of the game.

It's the same with interfacing to hardware -- if I give you an Ada
compiler that generates code for an x86, and you try to run programs
on a SPARC, it won't work.  That should not be a surprise!  ;-)

>...Some people seem to think the Ada compiler will
> know how the C compiler works, ...

Yes, of course it will.  It won't know how ALL C compilers in the world
work (of course), but it will know about the one (or ones) that are
supported.

>... 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.

Yes, the RM requires this.  But you have to obey the Ada compiler's
documentation.  If it says "compile the C part of your program with gcc
version xxx using so-and-so switches", and use some other C compiler, or
some other switches, it might not work.

> 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.

The compiler writer can read limits.h, just as well as any other
documentation.

>> 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.

OK.  So what is the confusion?

- Bob

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

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:e2c1ab35-55c8-4873-afcd-ee27bdbbd36a@i36g2000prf.googlegroups.com...
...
>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.

Well, it intends to require it for a specific C compiler implementations. 
But that intent only occurs in the AARM (see B.2(13.a-b)).

For a specific implementation (which might include particular compiler 
switches), the intent is that the types are correct.

But of course, this is all Implementation Advice (there would be no 
normative way to say this), so implementations are free to ignore it.


> ... 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.

That is definitely *not* the intent: see B.2(13.a-b). But I think that is 
how most implementers have interpreted the intent, because it's easier to do 
that making a separate package for every version of every supported 
compiler. (Remember, since the intent is Advice, implementers are not wrong 
in ignoring it.)

...
>> 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.

Surely.

                           Randy.

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

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:e2c1ab35-55c8-4873-afcd-ee27bdbbd36a@i36g2000prf.googlegroups.com...
...
>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.

Well, it intends to require it for a specific C compiler implementations. 
But that intent only occurs in the AARM (see B.2(13.a-b)).

For a specific implementation (which might include particular compiler 
switches), the intent is that the types are correct.

But of course, this is all Implementation Advice (there would be no 
normative way to say this), so implementations are free to ignore it.


> ... 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.

That is definitely *not* the intent: see B.2(13.a-b). But I think that is 
how most implementers have interpreted the intent, because it's easier to do 
that making a separate package for every version of every supported 
compiler. (Remember, since the intent is Advice, implementers are not wrong 
in ignoring it.)

...
>> 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.

Surely.

                           Randy.

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

[Peter C. Chapin]

Maciej Sobczak wrote:

>> 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?

My understanding is that the interfacing to C is only really meaningful 
if the Ada compiler is in some way associated with a corresponding C 
compiler (for example, created by the same vendor). In such a case, the 
Ada side selects appropriate types in Interfaces.C to match the types 
used by the *associated* C compiler. If the C compiler supports multiple 
representations of its basic types, well, that's interesting... the Ada 
side could do the same (compiler option?). The point is that the two 
compilers are working together.

I never assumed that Interfaces.C could somehow magically allow any Ada 
compiler to work with any C compiler. I'm surprised that some people 
seem to expect that. However, when I call C code compiled with gcc using 
GNAT, I would expect Interfaces.C to specify the right types because gcc 
and GNAT are closely related compilers. Furthermore if I then move my 
Ada/C program to another Ada/C compiler suite, I would expect it to 
continue to work (if I'm using Interfaces.C properly, etc, of course).

Peter

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

[Maciej Sobczak]

On 28 Cze, 02:56, "Peter C. Chapin" <pcha...@sover.net> wrote:

> My understanding is that the interfacing to C is only really meaningful
> if the Ada compiler is in some way associated with a corresponding C
> compiler (for example, created by the same vendor).

This is exactly my point.

We have to rely on some external knowledge, which is provided by
compiler vendors. Or sometimes by just old good common sense.
In any case, there is nothing related to "portability" in
Interfaces.C. The types defined there are exactly as non-portable  (as
far as interfacing is concerned) as any other type in Ada, because the
other side is a moving target. And if some vendor gives guarantees
about any type, these guarantees are out of scope of AARM and can be
also given to types from other packages, including Standard. Actually,
I'd expect a quality vendor to document everything - and it is the
documentation that tells me what is compatible for interfacing and
what is not.

There is of course some added value in Interface.C.XXX - it is
documenting the intent. If I see something like:

procedure Foo (X : in Interfaces.C.int);

then I understand that the intent is to interface with some C code. I
will also expect some pragma Import/Export in the next line, and so on
- this is exactly the purpose of documenting the intent. I might not
have the same understanding with Integer as the parameter type, even
though there is nothing technical that guarantees compatibility with
Interfaces.C.int or prohibits it with Integer.

> However, when I call C code compiled with gcc using
> GNAT, I would expect Interfaces.C to specify the right types because gcc
> and GNAT are closely related compilers.

Yes.

> Furthermore if I then move my
> Ada/C program to another Ada/C compiler suite, I would expect it to
> continue to work

Yes, but it has nothing to do with Interfaces.C itself - it is only
the matter of how the Ada/C "suite" is documented, because depending
on which types you focus on, you will get different compiler pairs in
the set.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

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

[tmoran]

> In any case, there is nothing related to "portability" in
> Interfaces.C. The types defined there are exactly as non-portable  (as
> far as interfacing is concerned) as any other type in Ada, ...
> ...
> There is of course some added value in Interface.C.XXX - it is
> documenting the intent.
    Vendor supplied libraries with names like "Interfaces.GCC_C"
or "Interfaces.Visual_C" would convey that intent just as well,
but the source code would require modification to move from, say,
Gnat/GCC to some other compiler pair.  Interfaces.C would not
require source code modification and in that sense is more
inter-vendor portable.

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

[Keith Thompson]

Maciej Sobczak <see.my.homepage@gmail.com> writes:
> On 28 Cze, 02:56, "Peter C. Chapin" <pcha...@sover.net> wrote:
> > My understanding is that the interfacing to C is only really meaningful
> > if the Ada compiler is in some way associated with a corresponding C
> > compiler (for example, created by the same vendor).
> 
> This is exactly my point.

And it's exactly wrong, or at least overstated.

The only required association is that the provider of the Ada compiler
*knows* the characteristics of the relevant C compiler.  That's not
hard to find out.  I'm not associated with the authors of gcc, but I
can find out its characteristics on a given system in just a few
minutes.  For that matter, I can probably write a program that
produces as output the correct declarations for Interfaces.C.

And since code generated by different C compilers on the same system
has to interoperate, it's generally in the interest of the C compiler
vendors to use the same representations for types on a given system.

Providing both the C and Ada compilers certainly makes it easier to
get Interfaces.C right, but even if the compilers aren't associated,
it's reasonably easy and reasonably reliable (certainly more so than
just assuming that Float and C_Float are compatible).

-- 
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"

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

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> And how the implementation can guarantee it without mandating the
> representation on the C compiler?

The idea is that the Ada compiler writer chooses a particular
implementation of C, and supports interfacing to that.
No need to "mandate" -- just write the Ada compiler so it
mimics what that particular C compiler does.  And then the
Ada compiler writer writes documentation "this Ada implementation
supports interface to the Mumble C compiler, version 1.2.3".
The Ada implementation could support intefacing with multiple C
implementations, but if the Ada implementation claims to support
interfacing to C, it has to support at least one.

> 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.

That's conceptually two (or more) C implementations.  The Ada compiler
writer would document the switches that must be used on the C side.
Or maybe there would be similar switches on the Ada side,
and the documentation would require them to match.

> How Ada implementation can guarantee anything in this area?

An Ada implementation guarantees that Interfaces.C.C_Float matches the
representation of float chosen by a particular C implementation, such as
version 1.2.3 of the Mumble C compiler.  Not so hard.  And quite
useful.

- Bob

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

[Randy Brukardt]

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lzzlp6amdv.fsf@stalkings.ghoti.net...
> Maciej Sobczak <see.my.homepage@gmail.com> writes:
...
>> Is there any implementation where Interfaces.C.int has different
>> properties than Integer?
>
> I don't know, and I suggest that you don't know either.

I do! I do! ;-)

On Janus/Ada, Integer is always 16-bit (for compatibility with our original 
implementations), but Interfaces.C.Int is whatever the C compiler uses (for 
most targets, including Windows, that's 32-bit).

If you use Interfaces.C and pragma Convention as intended, your interfacing 
code ought to be portable - at least with the supported C compiler(s) (and 
you have a bug to report if it is not). If you use Integer or Float, you're 
adding portability issues where none are needed.

Indeed, IMHO any code explicitly using the predefined types is wrong in Ada 
(vis-a-vis portability). And yes, I include the various items in the 
standard language that do that (including the random number generator and of 
course type String). It's one of the worst flaws in the language (since it 
makes string usage not portable, which is idiotic).

                                     Randy.

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

[tmoran]

>Is there any implementation where Interfaces.C.int has different
>properties than Integer?
  Yes.  Janus Ada 95 Integer is 16 bits (for compatibility with older
programs) but Interfaces.C.Int is 32 bits.  Another reason to always
define your own types (or at least subtypes, so you can change them).
  It's amazing to me how many programmers make unwarranted assumptions.
In twenty years I suppose all young programmers will assume Integers
must "of course" be 64 bits.

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

[Maciej Sobczak]

On 27 Cze, 20:13, tmo...@acm.org wrote:
> >Is there any implementation where Interfaces.C.int has different
> >properties than Integer?
>
>   Yes.  Janus Ada 95 Integer is 16 bits (for compatibility with older
> programs) but Interfaces.C.Int is 32 bits.

Too bad - my C compiler has 16-bit int (yes, it is 100% standard
compliant), so your Ada compiler will be incompatible with my C
compiler.

>   It's amazing to me how many programmers make unwarranted assumptions.

Yes. Some programmers make unwarranted assumptions that int in C is 32-
bit. Amazing.

> In twenty years I suppose all young programmers will assume Integers
> must "of course" be 64 bits.

In twenty years the only language in use will be Java (or some of its
offspring) and it will have well-defined numeric types. ;-)

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

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

[Jeffrey R. Carter]

Adrian Hoe wrote:
> 
>    int pwmRead (int pwmCount, float * data);
> 
> where data is an array of float which size is determined by pwmCount.
> 
> In Ada, I have:
> 
>    PWM_Count : Integer := No_Of_Components_Intended;
>    PWM_Data : array (1 .. PWM_Count) of Float;
> 
> My concern is how safe to pass an Ada array to a C function as a
> pointer (call by reference)? I presume Ada will allocate contiguous
> memory for array, but what if it does not? How can we establish a
> deterministic allocation and to make sure float * is accessed
> contiguously? Is there any "safe" way to do this?

type C_Data is array (Positive range <>) of Interfaces.C.C_Float;
pragma Convention (C, C_Data);

function PWM_Read  (Count : in Interfaces.C.Int; Data : in C_Data)
return Interfaces.C.Int;
pragma Import (C, PWM_Read, "pwmRead");

PWM_Count : constant := ...;

PWM_Data : C_Data (1 .. PWM_Count);
Result   : Interfaces.C.Int;

Result := PWM_Read (PWM_Count, PWM_Data);

-- 
Jeff Carter
"Your mother was a hamster and your father smelt of elderberries."
Monty Python & the Holy Grail
06

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

[Adrian Hoe]

On Jun 27, 12:10 pm, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> Adrian Hoe wrote:
>
> >    int pwmRead (int pwmCount, float * data);
>
> > where data is an array of float which size is determined by pwmCount.
>
> > In Ada, I have:
>
> >    PWM_Count : Integer := No_Of_Components_Intended;
> >    PWM_Data : array (1 .. PWM_Count) of Float;
>
> > My concern is how safe to pass an Ada array to a C function as a
> > pointer (call by reference)? I presume Ada will allocate contiguous
> > memory for array, but what if it does not? How can we establish a
> > deterministic allocation and to make sure float * is accessed
> > contiguously? Is there any "safe" way to do this?
>
> type C_Data is array (Positive range <>) of Interfaces.C.C_Float;
> pragma Convention (C, C_Data);


Can I use Float instead of Interfaces.C.C_Float?

One question has been raised to me:

Why use Interfaces.C.Int, Interfaces.C.C_Float since they are all new
declaration of Ada types.

I know it is for readability and maintainability but the question is
logical as the declaration in Interfaces.C is just merely creating a
new Ada type with a new name, unless there is pragma Convention
statement after every such declaration in Interfaces.C.

So, that leads to another question:

Wouldn't it be better to write as such?

type C_Data is array (Positive range <>) of Float;
pragma Convention (C, C_Data);



> function PWM_Read  (Count : in Interfaces.C.Int; Data : in C_Data)
> return Interfaces.C.Int;
> pragma Import (C, PWM_Read, "pwmRead");
>
> PWM_Count : constant := ...;
>
> PWM_Data : C_Data (1 .. PWM_Count);
> Result   : Interfaces.C.Int;
>
> Result := PWM_Read (PWM_Count, PWM_Data);

Is PWM_Data passed as pointer to pwmRead?

Thanks again.
--
Adrian Hoe
http://adrianhoe.com

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

[Adam Beneschan]

On Jun 27, 1:22 am, Adrian Hoe <aby...@gmail.com> wrote:

> > type C_Data is array (Positive range <>) of Interfaces.C.C_Float;
> > pragma Convention (C, C_Data);
>
> Can I use Float instead of Interfaces.C.C_Float?

You could.  But keep in mind that the same compiler from planet
Zorxkrug that would allocate an array in a non-contiguous manner may
also implement Float in a very different way than you'd expect, like
maybe putting the exponent in the middle of the word instead of at the
left.  I mean, if you're going to worry about one you should worry
about the other too for consistency.  :-)

By the way, although it's uncommon, I do know of one Ada compiler
whose authors made the decision (in the Ada 83 days) to define Float
as a 64-bit floating-point type, and Short_Float as a 32-bit type.
This is of course different from C usage on the most common platforms
(in which typically "float" is 32 bits and "double" is 64).  So that
would be one reason to use Interfaces.C.C_Float.  The Ada compiler in
that case should at least attempt to use the same representation that
would be used for C programs; although, as Maciej pointed out, there's
no guarantee that this will be correct, it should at least try.  There
are no such requirements for the standard "Float" type---there is no
requirement or suggestion that it should conform to any particular C
definition of the type.


>
> One question has been raised to me:
>
> Why use Interfaces.C.Int, Interfaces.C.C_Float since they are all new
> declaration of Ada types.
>
> I know it is for readability and maintainability but the question is
> logical as the declaration in Interfaces.C is just merely creating a
> new Ada type with a new name, unless there is pragma Convention
> statement after every such declaration in Interfaces.C.

Implicitly, there is.  See B.3(42).

> So, that leads to another question:
>
> Wouldn't it be better to write as such?
>
> type C_Data is array (Positive range <>) of Float;
> pragma Convention (C, C_Data);

Only if you know for certain that Float is the same type as the C
"float" and don't care about portability.


> > function PWM_Read  (Count : in Interfaces.C.Int; Data : in C_Data)
> > return Interfaces.C.Int;
> > pragma Import (C, PWM_Read, "pwmRead");
>
> > PWM_Count : constant := ...;
>
> > PWM_Data : C_Data (1 .. PWM_Count);
> > Result   : Interfaces.C.Int;
>
> > Result := PWM_Read (PWM_Count, PWM_Data);
>
> Is PWM_Data passed as pointer to pwmRead?

If the Implementation Advice is followed, yes.  See B.3(70).  You
might want to read this section of the RM, since you're asking several
questions that the RM directly answers.

                                  -- Adam

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

[Jeffrey R. Carter]

Adrian Hoe wrote:
> 
> Can I use Float instead of Interfaces.C.C_Float?

You can use anything you want: Boolean, Duration, a task type, ...

But if you want to be sure it will work, you'll use Interfaces.C.C_Float.

> Why use Interfaces.C.Int, Interfaces.C.C_Float since they are all new
> declaration of Ada types.
> 
> I know it is for readability and maintainability but the question is
> logical as the declaration in Interfaces.C is just merely creating a
> new Ada type with a new name, unless there is pragma Convention
> statement after every such declaration in Interfaces.C.

I suggest you read ARM B.3. There you'll find, "Each of the types declared in 
Interfaces.C is C-compatible."

> Wouldn't it be better to write as such?
> 
> type C_Data is array (Positive range <>) of Float;
> pragma Convention (C, C_Data);

Not if you want to be sure it will work.

> Is PWM_Data passed as pointer to pwmRead?

B.3 also contains, "An Ada parameter of an array type with component type T, of 
any mode, is passed as a t* argument to a C function, where t is the C type 
corresponding to the Ada type T."

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail
08

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

[Adrian Hoe]

On Jun 28, 6:54 am, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> Adrian Hoe wrote:
>
> > Can I use Float instead of Interfaces.C.C_Float?
>
> You can use anything you want: Boolean, Duration, a task type, ...
>
> But if you want to be sure it will work, you'll use Interfaces.C.C_Float.
>
> > Why use Interfaces.C.Int, Interfaces.C.C_Float since they are all new
> > declaration of Ada types.
>
> > I know it is for readability and maintainability but the question is
> > logical as the declaration in Interfaces.C is just merely creating a
> > new Ada type with a new name, unless there is pragma Convention
> > statement after every such declaration in Interfaces.C.
>
> I suggest you read ARM B.3. There you'll find, "Each of the types declared in
> Interfaces.C is C-compatible."
>
> > Wouldn't it be better to write as such?
>
> > type C_Data is array (Positive range <>) of Float;
> > pragma Convention (C, C_Data);
>
> Not if you want to be sure it will work.
>
> > Is PWM_Data passed as pointer to pwmRead?
>
> B.3 also contains, "An Ada parameter of an array type with component type T, of
> any mode, is passed as a t* argument to a C function, where t is the C type
> corresponding to the Ada type T."


Ok. Ada somewhat guarantees a safe environment of its own. The
ultimate concern is how Ada (or we) can guarantee a safe interfacing
to C?

Like those previous posts in this thread (by Maciej, Keith, et al), it
depends on compiler implementation. The question is, the C library
(which I am interfacing with) is compiled by unknown C compiler with
unknown switches and the author cannot be contacted. The only
documentation I have is the C header file. Can Ada safe implementation
guarantee a safe interface in this case? Or rather, how Ada can
guarantee a safe interface?

This does not limit to float * but can be anything else. The reason I/
we ask this (stupid) question is that I want to eliminate undesired
results because the results returned will be difficult to trace/prove
for correctness.
--
Adrian Hoe
http://adrianhoe.com

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

[Adam Beneschan]

On Jun 27, 6:15 pm, Adrian Hoe <aby...@gmail.com> wrote:

> Like those previous posts in this thread (by Maciej, Keith, et al), it
> depends on compiler implementation. The question is, the C library
> (which I am interfacing with) is compiled by unknown C compiler with
> unknown switches and the author cannot be contacted. The only
> documentation I have is the C header file.

Got a good disassembler?

If it really isn't documented what type of floats it's expecting, and
you have no way to determine what C compiler was being used, you're
pretty much down to looking at the disassembled code to figure out how
it works, or just trying different possibilities with small data
samples where you know what the correct result will be, and trying it
with different float sizes until you get the right result.  I don't
know what sort of different answer you were expecting.  Ada is a
programming language, not a magician.  Nobody here is suggesting that
in a case like this, that the Ada compiler should be able to figure
out how to interface to your library; and if you think they were,
you're overinterpreting.

Furthermore, even if there were some configuration information in the
library itself (such as debug information in a symbol table or DWARF
section) that gives information on the expected parameters, there is
certainly no language requirement that the Ada compiler go delve into
the library file to figure this out, and I doubt that any Ada compiler
would actually do so.  You're on your own, there.

                             -- Adam

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

[Randy Brukardt]

On Jun 27, 6:15 pm, Adrian Hoe <aby...@gmail.com> wrote:

> Like those previous posts in this thread (by Maciej, Keith, et al), it
> depends on compiler implementation. The question is, the C library
> (which I am interfacing with) is compiled by unknown C compiler with
> unknown switches and the author cannot be contacted. The only
> documentation I have is the C header file.

In that case, strictly speaking, you couldn't use the library from C, or 
Ada, or any other programming language. If you're willing to assume that the 
code conforms to the normal conventions for the target (that is, works like 
the "standard" C compiler), then of course Ada (via Interfaces.C) will work 
the same way.

But clearly, if this is compiled by a "weird" C compiler, you couldn't use 
it from gcc or MS-C anymore than you could use it from Ada. You could only 
use it from the "weird" C compiler, and your problem statement says that you 
don't know what that is. In other words, it is unusable, and you'd be best 
off rewriting it in Ada (or even a known C).

Nothing Ada-specific about that.

                                  Randy.

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

[Randy Brukardt]

On Jun 27, 6:15 pm, Adrian Hoe <aby...@gmail.com> wrote:

> Like those previous posts in this thread (by Maciej, Keith, et al), it
> depends on compiler implementation. The question is, the C library
> (which I am interfacing with) is compiled by unknown C compiler with
> unknown switches and the author cannot be contacted. The only
> documentation I have is the C header file.

In that case, strictly speaking, you couldn't use the library from C, or 
Ada, or any other programming language. If you're willing to assume that the 
code conforms to the normal conventions for the target (that is, works like 
the "standard" C compiler), then of course Ada (via Interfaces.C) will work 
the same way.

But clearly, if this is compiled by a "weird" C compiler, you couldn't use 
it from gcc or MS-C anymore than you could use it from Ada. You could only 
use it from the "weird" C compiler, and your problem statement says that you 
don't know what that is. In other words, it is unusable, and you'd be best 
off rewriting it in Ada (or even a known C).

Nothing Ada-specific about that.

                                  Randy.

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

[Adrian Hoe]

On Jun 28, 10:17 am, Adam Beneschan <a...@irvine.com> wrote:
> On Jun 27, 6:15 pm, Adrian Hoe <aby...@gmail.com> wrote:
>
> > Like those previous posts in this thread (by Maciej, Keith, et al), it
> > depends on compiler implementation. The question is, the C library
> > (which I am interfacing with) is compiled by unknown C compiler with
> > unknown switches and the author cannot be contacted. The only
> > documentation I have is the C header file.
>
> Got a good disassembler?
>

Hi guys, I am back.

I had got the code disassembled and it was compiled using gcc. So, it
should work.

--
Adrian Hoe
http://adrianhoe.com

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

[Jeffrey R. Carter]

Adrian Hoe wrote:
> 
> Like those previous posts in this thread (by Maciej, Keith, et al), it
> depends on compiler implementation. The question is, the C library
> (which I am interfacing with) is compiled by unknown C compiler with
> unknown switches and the author cannot be contacted. The only
> documentation I have is the C header file. Can Ada safe implementation
> guarantee a safe interface in this case? Or rather, how Ada can
> guarantee a safe interface?

Interfaces.C should be considered an interface to some specific C compiler, not 
to C in the abstract. GNAT's version is an interface to gcc C, for example. 
Whether that compiler is the same as the one used to compile your library, or 
uses the same representations, is anyone's guess. But on most platforms, most C 
compilers use similar representations, so you're probably OK using Interfaces.C. 
If not, then you'd be in the same boat if you used a C compiler.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail
08

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

[anon]

All credited languages and their compilers use "Standards" for their Data 
representation, such as IEEE.  Which means that as along as you use the 
compilers that share the same standard or you code an understand of 
these differences in those standards in your routine you can be safe that 
your code will perform correctly.


In <5d649522-50be-4aa5-9dce-cd1daa2bcd0d@p39g2000prm.googlegroups.com>, Adrian Hoe <abyhoe@gmail.com> writes:
>On Jun 28, 6:54 am, "Jeffrey R. Carter"
><spam.jrcarter....@spam.acm.org> wrote:
>> Adrian Hoe wrote:
>>
>> > Can I use Float instead of Interfaces.C.C_Float?
>>
>> You can use anything you want: Boolean, Duration, a task type, ...
>>
>> But if you want to be sure it will work, you'll use Interfaces.C.C_Float.
>>
>> > Why use Interfaces.C.Int, Interfaces.C.C_Float since they are all new
>> > declaration of Ada types.
>>
>> > I know it is for readability and maintainability but the question is
>> > logical as the declaration in Interfaces.C is just merely creating a
>> > new Ada type with a new name, unless there is pragma Convention
>> > statement after every such declaration in Interfaces.C.
>>
>> I suggest you read ARM B.3. There you'll find, "Each of the types declared in
>> Interfaces.C is C-compatible."
>>
>> > Wouldn't it be better to write as such?
>>
>> > type C_Data is array (Positive range <>) of Float;
>> > pragma Convention (C, C_Data);
>>
>> Not if you want to be sure it will work.
>>
>> > Is PWM_Data passed as pointer to pwmRead?
>>
>> B.3 also contains, "An Ada parameter of an array type with component type T, of
>> any mode, is passed as a t* argument to a C function, where t is the C type
>> corresponding to the Ada type T."
>
>
>Ok. Ada somewhat guarantees a safe environment of its own. The
>ultimate concern is how Ada (or we) can guarantee a safe interfacing
>to C?
>
>Like those previous posts in this thread (by Maciej, Keith, et al), it
>depends on compiler implementation. The question is, the C library
>(which I am interfacing with) is compiled by unknown C compiler with
>unknown switches and the author cannot be contacted. The only
>documentation I have is the C header file. Can Ada safe implementation
>guarantee a safe interface in this case? Or rather, how Ada can
>guarantee a safe interface?
>
>This does not limit to float * but can be anything else. The reason I/
>we ask this (stupid) question is that I want to eliminate undesired
>results because the results returned will be difficult to trace/prove
>for correctness.
>--
>Adrian Hoe
>http://adrianhoe.com

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

[anon]

The unsafe way is to use "Address" attribute.

   function pwmRead ( Count : Interfaces.C.int ;
                      Data  : System.Address ) return Interfaces.C.int ;
   pragma Import ( C, pwmRead, "pwmRead" ) ;


The standard safe method you must use two interface packages.

   Interfaces.C ;
   Interfaces.C.Pointers ;

and create a C type of pointer package for the Float type, such as

   type Float_array is array ( Interfaces.C.size_t range <> ) 
        of aliased float;

    package Float_Pointer is new 
        Interfaces.C.Pointers ( Index              => size_t,
                                Element            => Float,
                                Element_Array      => Float_array,
                                Default_Terminator => 0 ) ;


study RM B.3.2 ( 45 ) for an example that uses character array. Should 
be easy to adapt to Float.


In <d390ae47-83b1-4cfb-8e66-d6a92f38cf4e@z32g2000prh.googlegroups.com>, Adrian Hoe <abyhoe@gmail.com> writes:
>Hi,
>
>I have a C library function which takes a float * as a parameter. The
>function is as below:
>
>   int pwmRead (int pwmCount, float * data);
>
>where data is an array of float which size is determined by pwmCount.
>
>In Ada, I have:
>
>   PWM_Count : Integer := No_Of_Components_Intended;
>   PWM_Data : array (1 .. PWM_Count) of Float;
>
>My concern is how safe to pass an Ada array to a C function as a
>pointer (call by reference)? I presume Ada will allocate contiguous
>memory for array, but what if it does not? How can we establish a
>deterministic allocation and to make sure float * is accessed
>contiguously? Is there any "safe" way to do this?
>
>Thanks.
>--
>Adrian Hoe
>http://adrianhoe.com