Re: Interfacing to C and types visible to Ada

["Steve" <nospam_steved94@comcast.net>]

"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