Re: Importing C structs?

["Xenos" <dont.spam.me@spamhate.com>]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vispi4id6.fsf@smaug.pushface.org...
> "Xenos" <dont.spam.me@spamhate.com> writes:
>
> > We do this sort of think all the time.  Just create an Ada record
> > that is properly rep. spec'd according to the way your C compiler
> > does its structs.  If the parameter is a pointer to a struct use
> > either System.Address or an access type.
>
> I'm pretty sure GNAT will do the Right Thing here (ie pass the address
> of the record parameter). I suppose there might be problems with very
> small arrays on architectures where these are passed in registers? but

I believe the Ada standard requires that composite types are always sent by
reference, but I still "worry" about a compiler trying to optimize a call
with small records.

> since the Ada and C compilers have the same backend you are quite
> likely to be lucky. pragma Convention (C, ) means "do what the C
> compiler expects", after all.

Unfortunate we weren't so lucky (though we are now!).  We were stuck with
VADS.  Besides, if you DON'T specifically tell Ada to use an address as the
parameter AND you use Conversion to tell it to "do what C expects,"  what to
you think it will do?  Remember that C always passes by value.  Even though
Ada will always send the record by reference (a pointer), C will always send
it by sending the whole structure, unless you specifically tell it to send a
pointer to the record.  So, I think there is some ambiquity there.  I try
and avoid both luck and ambiquity is my software.

>
> The trouble with rep clauses where the C side has none, or hasn't used
> them, is that you only need to move to a different architecture
> (PowerPC vs i86) for it all to go out of the window.

Right, which it why I said that (1) it wasn't portable, and (2) that Ada is
forced to rep. spec. to the C compilers layout.  Changing platforms doesn't
negate the issue.  You still have to make the two sides agree.  Choosing not
to rep. spec. the data is not going to change to need to adapt the code to
the new arch.  At least with the rep. spec. will help to document what the
data is currently expected to look like.  Besides, I don't know of any
language with a portable feature to handle either Endianness or bit order.

>
> If you are sending the packets over a network, of course, it's more
> difficult.

For going over a network, we ALWAYS rep. spec. so that exact layout if
known.  Also requiring the data to be in network byte order takes care of
endian (at least as to defining which one the data is using).  As to bit
ordering for sub- or partial-byte sizes values, I've never seen a clean why
to handle this.  Even Ada has no standard to define which is bit zero.

>
> > Unfortunately, there is no portable way to do it.  But you usually
> > don't run into trouble unless your structs would have misaligned
> > fields.  The compiler avoids this by creating "holes."  Some C
> > compilers give you limited control of the packing, but again, its
> > not portable.
>
> With GNAT there's -gnatR which tells you what the representation
> actually is.