🚀 go-pugleaf

In article <4582@pt.cs.cmu.edu> bsy@PLAY.MACH.CS.CMU.EDU (Flexi-thumbs) writes:
>In article <11118@pur-ee.UUCP> hankd@pur-ee.UUCP (Hank Dietz) writes:
>>In C, it has been a very common idiom to ASSUME that the address of the first
>>member of a struct IS the address of the struct.  For example: [elided]
>
...
>The big problem that you're referring to is probably the injunction against
>reordering structure members, viz., Section A8.3 of K&R 2nd Ed (pg 213).
>You'll find it in the ANSI std too.  So, the assumption is valid for all
>architectures that do not require padding before the first element of the
>struct.  Does anybody know of any?  I'd conjecture that no machine is that
>silly.
....

It isn't a machine issue... it is a compiler issue.  Suppose an int is 4
units and a char is 1 unit, with alignment constraints to match.  At the
risk of reopening the great endian wars, given a struct like:

struct s { char c; int i; } t;

a compiler might legally decide to make &t be 3 units BEFORE &(t.c);
effectively {pad3, char, int} versus {char, pad3, int}.  This does not
violate the above referenced ordering constraints, and might make sense in
that the machine might be able to extract the char value from a fetched word
(int) faster if the padding appears in front rather than behind.  Basically,
the difference would be extracting the char by a simple mask versus
extracting it using a multi-bit shift (and perhaps also a mask).

Why isn't this a big problem?  Easy.  The compiler doesn't know it will need
to pad struct s until it encounters the int member, and by that time most
compilers have generated the allocation offset for the char field.  In
short, it is easier for the compiler not to put padding in front.

						-hankd@ee.ecn.purdue.edu