Re: Interfacing Ada to C

[bobduff@world.std.com (Robert A Duff)]

In article <mheaney-ya023680003005972336090001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>I'm not sure that the statement "depending on the endianness" is correct. 
>Isn't the compiler free to put A and B wherever it chooses?  You have no
>guarantee that A comes later or earlier than B, no matter what the
>endianess is.

Correct.

>All pragma Pack does is minimize the gaps between the components; it has
>nothing to say about the location of the components within the enclosing
>record (I think).

Correct, but the RM goes to some trouble to say how *much* those gaps
are minimized.

>Which is why I wouldn't recommend it for interfacing to another language. 
>A record representation clause should be used to explictly state the
>location of each and every component, so it's absolutely unambiguous what
>the layout is.  

Agreed that Pack shouldn't be used for interfacing purposes.  But you
don't always need to use record rep_clauses -- you can often use pragma
Convention(C or whatever) instead.  Record rep clauses are a pain during
maintenance -- they (over)specify all those bit numbers, when all you
really want to say is, "Do it like the corresponding C struct", or "lay
it out in order, using sensible alignment considerations."

>I don't use pragma Pack except on an array of Booleans, because the only
>time that pragma Pack makes a guarantee about representation is on an array
>whose component size is 1.

Now that's a bit harsh.  First of all, if what you want is to minimize
space, but you don't care what the exact layout is, then pragma Pack is
perfectly fine, even for non-Booleans.  Second, the RM *does* guarantee
a lot about how much packing is done (if the SP annex is supported).
E.g. a record containing three components of subtype "Integer range
1..2**5-1" and two components of subtype "Character range 'a'..'z'", and
three Booleans, is guaranteed to fit in 32 bits (on a typical 32-bit
machine).

>Sadly, there's no equivalent to Bit_Order for arrays.

Agreed.  I had mixed feelings during the Ada 9X project: should we beef
up the chap 13 features to really be complete, or should we weaken them,
since they cause a lot of extra compiler work for little benefit?  The
former is too tough, IMHO -- I mean, consider what additional
functionality would be needed to specify a bunch of records that map to
the 80386 instruction set?  Or the 386 segment tables (where fields are
split into pieces, and numbers are measured in bytes vs. pages,
according to some other bit)?

In the end, I decided that Ada isn't being used particularly because of
chap 13 features, and even if we eliminated chap 13 entirely, we would
be no worse off than other languages like C.  So, my approach was to
codify the meaning of existing features, mostly relying on existing Ada
83 AI's, and not go any further.  Yeah, pragma Bit_Order is a
counter-example to this philosophy, but the rules are pretty weak --
almost all Ada compilers today are for machines where the non-default
bit order is not required to be supported (i.e. byte-addressable
machines).

After all, people were agitating for the OOP features, and protected
types, and child packages -- we had no mandate to add a whole bunch of
stuff to chap 13.

- Bob