Interfacing to C: API with structures but without binary layout

Interfacing to C: API with structures but without binary layout

[Maciej Sobczak]

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/

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

[Lutz Donnerhacke]

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

Hard problem even in C. The binary layout of passed structures might differ
between different executables notably between kernel and application, if the
C-compiler options of both are different enough.

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

I wrote a very thin binding to the Linux kernel (resulting in a inlined
INT 80 after all). If the API/ABI does not define the struture closely enough
to use representation clauses, an Ada record with layout Pragma(C) did
always the job.

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

It is the canonical way, yes. Given the majority of existing software, you
can collect the information directly and provide platform specific Ada
sources. This is causes by the platform specific API, which can't be
described portable by a higher level language.

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

[Jeffrey Creem]

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.