Re: Permuting fields of records

>From Appendix A to K&R2 (I don't have the actual ANSI standard to hand):


For structure members in general,


"The members of a structure have addresses increasing in the order of
their declarations. A non-field member of a structure is aligned at an
addressing boundary depending on its type; therefore, there may be unnamed
holes in a structure. If a pointer to a structure is cast to the type of a
pointer to its first member, the result refers to the first member."


Which is to say, the compiler can't legally reorder the members of a
struct, but it can insert arbitrary amounts of padding anywhere except at
the start. Padding can be added before the struct but the address of the
struct points to the first data element. No padding is required by the
standard: members can be packed bit-to-bit.


For bit-field members,


"Adjacent field members of structures are packed into implementation-
dependent storage units in an implementation-dependent direction. When a
field following another field will not fit into a partially-filled storage
unit, it may be split between units, or the unit may be padded. An unnamed
field with width 0 forces this padding, so that the next field will begin
at the edge of the next storage unit."


So one can't really say anything about the location or space-consumption
of bit-fields under a general ANSI-C compiler. This makes life difficult
when writing (e.g.) Mach message handling code in a language other than C
(in C it's easy because you get given header files, which hopefully are
always compiled the same way), and means one ends up with highly-strung
code: give it a nasty look and it stops working.


I should know, that's exactly what I'm doing this week (writing stuff to
interface to an Ethernet board under Mach, in Standard ML).


On the other hand, given the portability aims of ANSI-C, their decisions
here are not unreasonable.


Nick Haines nickh@cmu.edu
--

Return to the comp.compilers page.
Search the comp.compilers archives again.