Re: Interfacing to C and types visible to Ada

Maciej Sobczak <see.my.homepage@xxxxxxxxx> 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@xxxxxxx <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"
.

Relevant Pages

  • Re: For the AdaOS folks
    ... API that says create/delete an integer? ... >>as an Ada binding, I can do another registry query and get the ... libraries can strengthen the typing of the Ada interface. ...
    (comp.lang.ada)
  • Re: [announcement] SYSAPI and SYSSVC for Windows
    ... > using work-arounds in API is the worst thing I can imagine. ... > by a language, it is would be a great ... Ada has its own concept. ... should support the development of BeOS. ...
    (comp.lang.ada)
  • Re: For the AdaOS folks
    ... >> the second step is to provide API to query that names from an application. ... > And how do your identify your GNAT object? ... Ada run-time is another issue. ... It is not like Ada access type, because handle is not a pointer. ...
    (comp.lang.ada)
  • Re: Re-Marketing Ada (was "With and use")
    ... > What thinbind would be required to do, is to preprocess the header ... This destroys most of the original C API in a unusable way. ... > to infer inline Ada functions from them. ... Several macros are used to transform the API ...
    (comp.lang.ada)