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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9ed448b3da4e578c X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Interfacing Ada to C Date: 1997/05/31 Message-ID: #1/1 X-Deja-AN: 245410326 References: <5mjvk9$sm7$1@luna.ffi.no> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-05-31T00:00:00+00:00 List-Id: In article , Matthew Heaney 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