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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6b77ce1ba18f9267 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-01-13 20:47:50 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!arclight.uoregon.edu!wn14feed!wn12feed!worldnet.att.net!bgtnsc04-news.ops.worldnet.att.net.POSTED!not-for-mail From: "David Thompson" Newsgroups: comp.lang.ada References: Subject: Re: Import a type from C X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: Date: Tue, 14 Jan 2003 04:47:50 GMT NNTP-Posting-Host: 12.89.130.180 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 1042519670 12.89.130.180 (Tue, 14 Jan 2003 04:47:50 GMT) NNTP-Posting-Date: Tue, 14 Jan 2003 04:47:50 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:32989 Date: 2003-01-14T04:47:50+00:00 List-Id: 08 Rupert Pigott wrote : > "Stephen Leake" wrote in message > news:u7kfqjnvv.fsf@gsfc.nasa.gov... ... > > Note that [Convention(C,] really means "the C compiler that the Ada > > compiler knows about, with its default command line args". ... > > So I always use a rep spec, instead of relying on Convention (C). Then > > I write some C code that checks the struct size, to be sure there is > > no padding. > > Perhaps I'm overly pessimistic here... IIRC there is no guarantee > of the order of members within a structure in C either. One of those > little gotchas (along with no alignment control) that **** portable > code and force you to go the long way around... > In C there is except only partly for bitfields. Which of course you may be using if you try (unsuccessfully) to fully specify a record. C90 6.5.2.1 and C99 6.7.2.1p10,12,13,15 [bracketed text deleted] An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified. ... Each non-bit-field member of a structure or union object is aligned in an implementation-defined manner appropriate to its type. Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. ... There may [therefore] be unnamed padding within a structure object, but not at its beginning. ... There may be unnamed padding at the end of a structure or union[, as necessary to achieve the approriate alignment...]. In C++98 the corresponding requirement is partially relaxed. 9.2[class.mem]p12: Nonstatic data members of a (non-union) class declared without an intervening access-specifier are allocated so that later members have higher addresses within a class object. The order of allocation of nonstatic data members separated by an access-specifier is unspecified (11.1). Implementation alignment requirements might cause two adjacent members not to be allocated immediately after each other; so might requirements for [vptrs]. 9.6[class.bit]p1: A member-declarator of the form ... specifies a bit-field .... Allocation of bit-fields within a class object is implementation-defined. Alignment of bit-fields is implementation-defined. .... p3: The address-of operator & shall not be applied to a bit-field .... A non-const reference shall not be bound to a bit-field. .... The address ordering is redundantly specified in 5.9[expr.rel]p2. Note that in C++ (standard) terminology, 'class' subsumes 'struct' and 'union' except where excluded, and 'nonstatic' members of a class are those that exist in each instance (data/variable) or apply to a given instance (function/method) using the magic 'this'. (And like Ada, in both C and C++, 'implementation-defined' must be documented but 'unspecified' need not.) -- - David.Thompson 1 now at worldnet.att.net