Re: Import a type from C

["David Thompson" <david.thompson1@worldnet.att.net>]

08
Rupert Pigott <darkboo-remove-this-ng.@hotmail.com> wrote :
> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> 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