Re: Interfacing to C: API with structures but without binary layout

[Jeffrey Creem <jeff@thecreems.com>]

Maciej Sobczak wrote:
> Another problem with interfacing: consider a C function that expects
> some data structure that is defined in terms of C struct definition,
> but without clear binary layout.
> A motivating example might be the connect(2) system call, which
> expects the sockaddr address structure. The only thing we know (by the
> standard) about this structure is that it contains *at least* some
> given fields. Depending on the actual system, however, it might
> contain some more fields for implementation-defined reasons, or they
> might be in different order, etc.
> 
> Now, in order to call such a function we need access to the
> appropriate header file, where the actual structure definition is
> provided. But Ada doesn't understand C headers and pragma Import(C,
> connect) will not be enough.
> 
> A straightforward solution is to create a thin wrapper (in C) for the
> given function that will expect parameters in well-defined form and
> layout and just forward them to the interesting system call. This
> wrapper will have to be compiled separately on each target system,
> picking the actual structure definition from the appropriate system
> header. Ada can then call the wrapper function.
> 
> Is this THE solution?
> 
> --
> Maciej Sobczak
> http://www.msobczak.com/
> 

There are a few possibilities.

1) Define the Ada records to match what you expect and hope for the best 
(not great but fine in some cases)

2) Create the wrappers that you have suggested (I've used this in some 
cases)

3) Use an automated bindings generator for some of the thin stuff and 
create the bindings during the ./configure step. This is certainly what 
some other languages do in some cases (e.g. Python). SWIG is a tool that 
can in theory be used in this cases. The current official sources do not 
support Ada but the maintains have indicated they will accept patches 
when they are ready. In the mean time, there is a branch being worked 
within the gnuada project SVN structure on sourceforge.

If you have a large library you want to bind to, contributing to SWIG 
may be an overall cost neutral approach and be helpful in the long term.

Having said that, many C libraries have gotten so cluttered with defines 
and decl specs and exports of various flavors that I suspect that some 
libraries will forever resist effective automated binding generation.

4) Something else similar. Specifically, GtkAda has a perl script that 
is semi-specific to Gtk that helps in the creation of bindings. It is 
sort of a middle ground and is an effective approach in some special cases.