Re: structure layout question

In article <1172772376.435029@xxxxxxxxxxxxxxxxxxxxxxxx>,
kyle york <kyork@xxxxxxxxx> wrote:

Why does the C standard require the members of a structure not be
re-ordered (6.2.5.20)? Padding is allowed, and platform dependent, which
means one cannot rely on the exact layout anyway, so what's the point?

As best I recall, arbitrary padding is not permitted: only
where required to bring the entry into alignment (where alignment
rules are platform dependant.) So if you know the alignment rules
for (say) a "pure" double, then you also know the alignment
rules for a double embedded in a struct.

In any case, take the structure and wrap it around with a union,
the other member of which is an array of unsigned char. This is
a legal way to get at the bytes that make up the structure without
worrying about trap representations, and there are scenarios you
can construct where the alignment rules provide guarantees about
what will be where in the unsigned char array that wouldn't be met
if reordering was possible. For example, take the offset of a
member that was known to be followed by a char. char is the most
general alignment, so you know it followed -immediately- after the
end of the member. You know the size of the member via sizeof.
So the unsigned char array indexed at the offset of the member,
plus the sizeof the member, is certain to get you to the beginning of
that char -- but if you'd reordered the elements, the char could
be anywhere relative to the member in question.


Without this restriction the compiler could layout the structure in the
most efficient way possible, for some definition of efficient. It would
be easy enough to turn this reordering off with a compiler specific
pragma as is often done with padding.

And it would be easy enough for a compiler to provide a pragma to
pack efficiently, possibly breaking ordering or possibly requiring
slow movements in and out of internal char buffers if the architecture
doesn't support "move unaligned". You could call it something wild such
as ... ummm, say, #pragma pack
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell
.

Relevant Pages

  • Re: Data alignment problems with sizeof and new
    ... >I have a strange problem with a project involving classes with data alignment ... It appears that, in this particular project, the sizeof and new ... >operators are not taking the alignment padding into account when calculating ... >class with the first member being a dword size followed by doubles, ...
    (microsoft.public.vc.language)
  • Re: alignment revisited
    ... char -- 8 bits ... 0x0008 XX XX XX XX -- member 'j'. ... If the compiler does not add padding bytes, ...
    (comp.lang.cpp)
  • Re: sizeof() and a structure
    ... alignment, the structure itself won't necessarily require large ... struct c {char c;}; ... If you really want to waste memory, though, don't put members of the ... require sizeof-1 bytes of padding. ...
    (comp.lang.c)
  • Data alignment problems with sizeof and new
    ... I have a strange problem with a project involving classes with data alignment ... It appears that, in this particular project, the sizeof and new ... operators are not taking the alignment padding into account when calculating ... class with the first member being a dword size followed by doubles, ...
    (microsoft.public.vc.language)
  • Re: Padding at the end of structures
    ... You missed the part where I wrote "assuming a four-byte alignment ... since all objects can be accessed as arrays of unsigned char, ... However, even if the implementation honours the alignment of int, there ... need not be three bytes of padding after the char member. ...
    (comp.std.c)