Interfacing to C and types visible to Ada

Interfacing to C and types visible to Ada

[Maciej Sobczak]

I have a question related to interfacing to C, but I think it deserves
a new thread.

Imagine a C API that uses the int type to express something that does
not have any dedicated domain. In other words, it is not "number of
apples", not "height in meters", not "hotel room number", etc., it is
just plain "integer", which meaning can depend on how the given
library is actually used.

We can use Interfaces.C.int for binding Ada to C, but there is still a
need to expose somehow the type to regular Ada code. What type should
be used?

Standard.Integer is the most natural choice, because it clearly
expresses the "domainless" character of the given type. On the other
hand, it might not be the same as Interfaces.C.int in terms of its
range.

Interfaces.C.int might be a good choice as well, because it
"guarantees" (modulo what we have discussed in another thread) that
the information is transported correctly. The disadvantage is that it
is ugly and exposes implementation details which are not needed.

The Ada wrapper library might also define its own type that will be
equivalent in range to Interfaces.C.int. What is the right name for
such a type? "Integer" is the best choice due to the character of this
type, but it collides with Standard.Integer. On the other hand,
packages are supposed to be the cure for such conflicts.

What do you recommend? I would go for the last option: "Integer"
defined in the library's package.

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

Re: Interfacing to C and types visible to Ada

[Georg Bauhaus]

Maciej Sobczak schrieb:

> just plain "integer", which meaning can depend on how the given
> library is actually used.
> 
> We can use Interfaces.C.int for binding Ada to C, but there is still a
> need to expose somehow the type to regular Ada code. What type should
> be used?

Your description sounds almost like the answer to me.

    type Whatever_Integer is range C.int'First .. C.int'Last;
    --  explain this


> 
> Standard.Integer is the most natural choice, because it clearly
> expresses the "domainless" character of the given type.

Except, as Randy has pointed out, Integer might have a smaller
range than C.int.

Re: Interfacing to C and types visible to Ada

[Ludovic Brenta]

Maciej Sobczak wrote:
> Imagine a C API that uses the int type to express something that does
> not have any dedicated domain. In other words, it is not "number of
> apples", not "height in meters", not "hotel room number", etc., it is
> just plain "integer", which meaning can depend on how the given
> library is actually used.

How about making the Ada binding generic, e.g.:

generic
   type Integer_Type is range <>;
package Ada_Binding is
   function Foo return Integer_Type;
end Ada_Binding;

with Interfaces.C;
package body Ada_Binding is
   function Foo return Integer_Type is
      function Internal return Interfaces.C.int;
      pragma Import (C, Internal, "foo");
   begin
      return Integer_Type (Internal);
   end Foo;
end Ada_Binding;

This way, the user of the library specifies the particular meaning of
the "integers" in each case. This design makes it possible to create
several instances of Ada_Binding with different meanings and then
benefit from Ada's strong typing.

--
Ludovic Brenta.

Re: Interfacing to C and types visible to Ada

[Robert A Duff]

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

> We can use Interfaces.C.int for binding Ada to C, but there is still a
> need to expose somehow the type to regular Ada code. What type should
> be used?

You can do one of:

    subtype Int is Interfaces.C.int; -- rename the type
    type Int is new Interfaces.C.int; -- declare a new type

> The Ada wrapper library might also define its own type that will be
> equivalent in range to Interfaces.C.int. What is the right name for
> such a type?

I don't know, but Integer is not a good choice, IMHO.
If you have:

    package My_Binding is
        type Integer is ...

then inside My_Binding (including its children), that Integer will hide
the one in Standard.  In other packages that say "use My_Binding;",
the Integer in Standard will hide the one in My_Binding.
You will be continually confused about which Integer you are
referring to.  And people who are familiar with Ada, but not
familiar with My_Binding will be even more confused.

- Bob

Re: Interfacing to C and types visible to Ada

[tmoran]

> not have any dedicated domain. In other words, it is not "number of
> apples", not "height in meters", not "hotel room number", etc., it is
> just plain "integer", which meaning can depend on how the given
  So the only known fact about these entities is that they are
the same size as Interfaces.C.Int?  What operations are legitimate?
Clearly not arithmetic (adding hotel room numbers?).  Does ">" always make
sense?  Are they black box bit patterns (eg window handles)?  Should
your wrapper say "type Whatever is [limited] private;" and then
"for Whatever'size use Interfaces.C.Int'size;"  How would you specify
one of these as an Ada generic parameter?

Re: Interfacing to C and types visible to Ada

[Keith Thompson]

Maciej Sobczak <see.my.homepage@gmail.com> writes:
> I have a question related to interfacing to C, but I think it deserves
> a new thread.
>
> Imagine a C API that uses the int type to express something that does
> not have any dedicated domain. In other words, it is not "number of
> apples", not "height in meters", not "hotel room number", etc., it is
> just plain "integer", which meaning can depend on how the given
> library is actually used.
>
> We can use Interfaces.C.int for binding Ada to C, but there is still a
> need to expose somehow the type to regular Ada code. What type should
> be used?
>
> Standard.Integer is the most natural choice, because it clearly
> expresses the "domainless" character of the given type. On the other
> hand, it might not be the same as Interfaces.C.int in terms of its
> range.

Yes, and that's a fatal flaw; I wouldn't even consider using
Standard.Integer.  What if your C API gives you a value outside the
range of Standard.Integer?

> Interfaces.C.int might be a good choice as well, because it
> "guarantees" (modulo what we have discussed in another thread) that
> the information is transported correctly. The disadvantage is that it
> is ugly and exposes implementation details which are not needed.
>
> The Ada wrapper library might also define its own type that will be
> equivalent in range to Interfaces.C.int. What is the right name for
> such a type? "Integer" is the best choice due to the character of this
> type, but it collides with Standard.Integer. On the other hand,
> packages are supposed to be the cure for such conflicts.
>
> What do you recommend? I would go for the last option: "Integer"
> defined in the library's package.

Re-using the name "Integer" is, IMHO, a really bad idea.

Study the C API and come up with a description of what the type is
actually used for.  Then, for the Ada binding, declare a type or
subtype with a name based on that description.  Make it a subtype or
derived type of Interfaces.C.int, so there's no risk of getting the
range wrong.  (Using a subtype has the advantage -- and the
disadvantage -- of allowing it to be assigned to other objects of type
Interfaces.C.int.)

I'm not sure I understand this "domainless" business.  Can you provide
a simple example?

-- 
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: Interfacing to C and types visible to Ada

[Maciej Sobczak]

On 3 Lip, 21:35, Keith Thompson <ks...@mib.org> wrote:

> Study the C API and come up with a description of what the type is
> actually used for.

It is used for integers. That's the problem. :-)

> I'm not sure I understand this "domainless" business.  Can you provide
> a simple example?

Sure. The C library is a database access library. It allows the user
to transmit data of various types, which are all "domainless". One of
these types is, well, integer. Whether it is a "room number" or
"number of apples" depends on the actual application, but the database
access library does not influence it. It is really an integer, having
a value in some range. The range happens to be defined by C's int,
which on the particular compiler is 32-bit, signed.

The Ada wrapper should expose this type as "some" integer as well, but
I have doubts which integer is best.

I think that the suggestion to have subtype or derivation from
Integer.C.int make the most sense. User applications will use their
own types anyway and the casts from/to the "database integer" are
unavoidable.
I also like the solution with generic parameter (Ludovic), but it will
not be consistent with other supported types like string and
timestamp, for which the natural mapping choices are String and
Ada.Calendar.Time.

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

Re: Interfacing to C and types visible to Ada

[Steve]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:ff92d09d-5638-4422-ab11-d214529c0283@l64g2000hse.googlegroups.com...
>I have a question related to interfacing to C, but I think it deserves
> a new thread.
>
> Imagine a C API that uses the int type to express something that does
> not have any dedicated domain. In other words, it is not "number of
> apples", not "height in meters", not "hotel room number", etc., it is
> just plain "integer", which meaning can depend on how the given
> library is actually used.
>
> We can use Interfaces.C.int for binding Ada to C, but there is still a
> need to expose somehow the type to regular Ada code. What type should
> be used?
>
> Standard.Integer is the most natural choice, because it clearly
> expresses the "domainless" character of the given type. On the other
> hand, it might not be the same as Interfaces.C.int in terms of its
> range.
>

When interfacing to C or to hardware, depending on the interface I usually 
take 1 of 2 approaches:
  1) If data structures are being shared, I define records using 
representation clauses to ensure that the Ada and C representations match.

  2) If simple arguments are being passed I tend to use Interfaces.Integer_n 
and Interfaces.Unsigned_n  where n is usually either 8, 16, or 32.

  IMNSHO the interface should map exactly between the languages, no more, no 
less.  If the C code only handles 32 bit integers, the Ada interface should 
do the same.  If it is appropriate to define types that better abstract the 
interface, I do so in Ada and convert from the non-so abstract types in Ada.

Regards,
Steve
(The Duck)


> Interfaces.C.int might be a good choice as well, because it
> "guarantees" (modulo what we have discussed in another thread) that
> the information is transported correctly. The disadvantage is that it
> is ugly and exposes implementation details which are not needed.
>
> The Ada wrapper library might also define its own type that will be
> equivalent in range to Interfaces.C.int. What is the right name for
> such a type? "Integer" is the best choice due to the character of this
> type, but it collides with Standard.Integer. On the other hand,
> packages are supposed to be the cure for such conflicts.
>
> What do you recommend? I would go for the last option: "Integer"
> defined in the library's package.
>
> --
> Maciej Sobczak * www.msobczak.com * www.inspirel.com 

Re: Interfacing to C and types visible to Ada

[Fionn Mac Cumhaill]

On Thu, 3 Jul 2008 13:35:21 -0700 (PDT), Maciej Sobczak
<see.my.homepage@gmail.com> wrote:

>On 3 Lip, 21:35, Keith Thompson <ks...@mib.org> wrote:
>
>> Study the C API and come up with a description of what the type is
>> actually used for.
>
>It is used for integers. That's the problem. :-)
>
>> I'm not sure I understand this "domainless" business.  Can you provide
>> a simple example?
>
>Sure. The C library is a database access library. It allows the user
>to transmit data of various types, which are all "domainless". One of
>these types is, well, integer. Whether it is a "room number" or
>"number of apples" depends on the actual application, but the database
>access library does not influence it. It is really an integer, having
>a value in some range. The range happens to be defined by C's int,
>which on the particular compiler is 32-bit, signed.
>

I had the same problem. In my case, the database is medical data
stored in a Microsoft SQL Server database. Most of the data is stored
as integers or fixed-length strings in a variety of lengths.

The integers and strings were both mostly used to store arbitrary
codes of various kinds which should not be confused with each other.

I made no attempt to improve the Ada representation of a C integer. I
defined types in an Ada package which abstracted the behavior that I
needed and then produced a child package for it that did the database
I/O operations.

In the final result, there was no clearly-defined correspondence
between C types and my Ada types. There would have been no point in
trying to improve the representation of a C integer in Ada; some of my
types were enumerated types used to represent what was an integer in
the database. Likewise, some character strings were translated into
enumerated types.

My "domains" were a very specific fit to the contents of my database.
I don't think that there is much that can be done in general to
sharpen up a C integer for Ada use. There does not seem to be much
middle ground between a "domainless" integer and types defined to suit
a specific situation. Integer types that contain the non-negative and
positive subranges of a C integer might be useful.

In the more restricted domain of database applications, some
additional types might be useful. An integer field in a database
record might not contain an integer at all - it could contain a
database null value, which neither an Ada Integer or a C int can
represent. In my particular case, none of my arbitrary integer codes
could ever have a zero value, so a zero made a convenient
representation for a null, but this would not be generally useful.

Some kind of integer-on-steroids that can represent a null value as
well as the usual range of integer values might be useful.