From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d71460587da14d5b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-31 13:55:05 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!logbridge.uoregon.edu!swen.emba.uvm.edu!att541!att542!ip.att.net!newsfeed3.global.lmco.com!svlnews.lmms.lmco.com!not-for-mail From: "Xenos" Newsgroups: comp.lang.ada Subject: Re: Importing C structs? Date: Thu, 31 Jul 2003 16:40:29 -0400 Organization: Lockheed Martin Corporation Message-ID: References: NNTP-Posting-Host: 158.187.68.119 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Xref: archiver1.google.com comp.lang.ada:41107 Date: 2003-07-31T16:40:29-04:00 List-Id: "Simon Wright" wrote in message news:x7vispi4id6.fsf@smaug.pushface.org... > "Xenos" 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.