Interfacing Ada95 programs to each other and to C and C++

[gwinn@ma.ultranet.com (Joe Gwinn)]

This is my current list of issues in interfacing Ada95 programs to each
other and to C and C++ programs.  Some of these issues have been mentioned
in prior postings, but are repeated here for completeness.  We are still
integrating, so not all issues have been uncovered and solved.


The prime requirement is not just successful interfacing, it's bulletproof
target-independent, compiler-independent portable interfacing.  There are
many solutions that will work for one or another specific pair of
compilers and/or languages, but very few solutions will work for any or
even most pairs.  Why is this important?  Because with the short lifetimes
of current compiler versions and COTS targets, we will port our code many
times in the development and life of the code, and it's too expensive and
error prone if the interfaces (many having hundreds of message types) fall
apart every time something is changed.

There are two related interface areas, procedure call conventions and
handling of data and data structures passed through the procedure call
interface, and the passing of messages (moveable data structures) between
programs in various languages via some kind of communications system.  In
procedure call issues, at least the target processor is the same.


1.  Alignment clauses do not necessarily govern dynamic objects (those
declared in procedures rather than the main).  Things that must be aligned
must thus be handled at the "main" level, or alignment commands will be
ignored.  This matters for two reasons.  First, many realtime
communications systems require specific data alignments.  Likewise, I/O
drivers and hardware.  Second, different compilers, especially if targeted
on different processors, often pad the elements of data structures
differently.  If one makes all fields 32-bit items, padding is lass
variable.  

2.  Rep specs cannot be used on enumeration types (because many compilers
generate tremendous amounts of code to handle all possible cases, however
unlikely), so one cannot use enumeration types in messages.  

3.  If an integer field in a record is a subrange type, Ada will tend to
use the smallest kind of integer that will hold the field, overriding any
rep specs to the contrary.  Other languages and compilers, especially on
different targets, may chose different kinds of integer and different
paddings.  This too can be solved by making all integers 32-bit, and
dropping any use of subranges (and the attendant range checks).  

4.  There may also be a endian problem; we haven't completely sorted this
out yet, but we have cases where the wrong end of a 32-bit integer is kept
as a packed subrange.  This may just be a bug. 

5.  Floating-point fields, 32-bit and 64-bit IEEE 754, have caused no
problems so far, even between machines of differing type, something of a
surprise.  Floating point is more complex than integers, and some machines
have somewhat different endian behaviour for floats than for integers.


These are the causes of most problems we have seen so far.  Simple human
error has accounted for the rest.


Joe Gwinn