Path: utzoo!attcan!uunet!husc6!think!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: sizeof( _variable_ )
Message-ID: <61238@sun.uucp>
Date: 25 Jul 88 18:01:56 GMT
References: <1264@bc-cis.UUCP> <5940002@hpcupt1.HP.COM>
Sender: news@sun.uucp
Lines: 34

> The 3B2 runs AT&T's WE32000 series processors.  They're 32 bit machines and
> align structures on 4-byte (1-machine word) boundaries.

Correct, but...

> That way, in an array of these structures, items after the first are still
> properly aligned.

this depends on your definition of "properly".  A structure consisting only of
"char"s and arrays of same need not be aligned on a 4-byte boundary, even on
machines that require 4-byte alignment for 4-byte quantities; the SPARC
processor requires 4-byte alignment for 4-byte quantities, but structures are
not automatically aligned on 4-byte boundaries by the SPARC C compiler.
("sizeof z" in the example given yields 22 on a SPARC-based system.)

PCC and its derivatives align structures to the maximum of:

	1) the "default structure alignment", which differs from machine to
	   machine;

	2) the maximum alignment requirement of all the members of the
	   structure.

Thus, a structure containing a "long" on a machine requiring "long"s to be
aligned on 4-byte boundaries will be aligned on at least a 4-byte boundary.

The only advantage I see to aligning all structures on some "natural" boundary
would be that you'd be more likely to be able to use "fast" memory copy code,
if that code required alignment on some "natural" boundary.  I don't know if
the WE32K compiler aligns structures on 4-byte boundaries for this reason, or
because the porter got confused and thought the "default structure alignment"
for a machine has to be the most restrictive alignment of all data types on
machines such as the WE32100 with restrictive alignment requirements (not
realizing that the compiler handles this for you, by 2) above).