Re: Interfacing C type, unconstrained array with record

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 16 Oct 2010 12:19:18 -0700 (PDT), Ron Wills wrote:
>
>> The "pragma Convention" did the trick! I must say, Ada is the one
>> language I've encountered that seems to have the largest learning
>> curve because of the most cryptic references I ever seen ;)
>
> What you are doing is interfacing to another language. That is not Ada, but
> system programming. If you think pragma Convention cryptic, well, what
> about reading the compiler manual for call stack frame format details and
> implementing that using Assembler code insertions? (:-))

Good point.  And what about reading the C standard to find all
the good features for interfacing to Ada (or to any other
language)?  That's easy -- there are no such features!

> P.S. to dear ARG members. Why discrimnants cannot be mapped onto components
> of a C structure. I mean making OK this:
>
>    type Vector is array (size_t range <>) of Whatever;
> � �pragma Convention (C, Vector);
> � �type Constrained (Size : size_t) is record
>    � � �List� : Vector (1..Size);
> � �end record;
> � �pragma Convention (C, Constrained);

Well, in fact I think that will work in GNAT, although it
will warn about the fact that C doesn't have discriminants.

But this is tricky.  The C code depends on the fact that the
List component comes last.  There is no such requirement
in Ada that discriminant-dependent fields come last
(either in the declaration, or in the memory layout).

What if there were two discriminants, and two discriminant-dependent
arrays?  That doesn't match anything on the C side.

Many compilers use extra dope when there are discriminants
or unconstrained arrays.  Ada 83 didn't have very good
support for interfacing -- most of this stuff was invented
for Ada 95.  But by that time, compilers already existed,
and the compiler writers didn't want to change the "dope".
For example, I know of one compiler that would store
the size (in bytes) of the above record (in addition to
the Size field, which is the length of that array).

Whether that's a good idea is arguable, but it has the
advantage that block "=" and ":=" don't have to
calculate the size in bytes.  And it's just a special
case of storing the offset of each discriminant-dependent
component (to avoid recalculating those) -- the size is
just the offset of the end.

(By the way, I prefer to use "size" to refer to memory
sizes, measured in bits, bytes, words, or whatever,
and use "length" to refer to array lengths, measured
in number of components.  The latter is a higher-level
concept.)

Anyway, I guess the real answer to your question is,
C doesn't have discriminants, so nobody thought
it would be a good idea to require interfacing
discriminants to something in C.  It could make
sense, but only in very limited cases.  Compilers
are allowed to support it, but there's no portable
(language defined) support.

- Bob