Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!randvax!segue!jim
From: jim@segue.segue.com (Jim Balter)
Newsgroups: comp.unix.programmer
Subject: Re: struct 32 bit aligned and padded
Message-ID: <7196@segue.segue.com>
Date: 21 Apr 91 00:46:49 GMT
References: <14082@arctic.nprdc.navy.mil>
Reply-To: jim@segue.segue.com (Jim Balter)
Organization: Segue Software, Inc. - Santa Monica, CA. +1-213-453-2161
Lines: 53

In article <14082@arctic.nprdc.navy.mil> stanonik@nprdc.navy.mil (Ron Stanonik) writes:
>The problem was that on the
>3b2, structs are not only aligned on 32 bit boundaries (which
>we expected), but also padded to 32 bit boundaries.

If a struct is aligned on a 32 bit boundary, that implies that it is padded
to a 32-bit boundary.  Consider struct foo x[2]; x[1] is aligned on a 32-bit
boundary.  Thus x[0] is padded to a 32-bit boundary.  If it weren't, then
sizeof(x) != sizeof(x[0]) + sizeof(x[1]).  If C had both a padd_sizeof and
an unpadded_sizeof, then this wouldn't need to be, but it doesn't.

>here's a little program
>	struct s0 { char c[2]; };
>
>	struct s1 { struct s0 s0; short s; } x1;
>
>	main()
>	{
>		printf("offset of short = %d\n", (int)&x1.s - (int)&x1);
>	}
>
>We expected the short x1.s to be two bytes from the start of the struct x1.

Some compilers are smart enough to align structures based on what they need.
Apparently, your 3b2 compiler is aligning all structures on 32-bit boundaries
even when they only need to be aligned on char boundaries.  A structure needs
to be as aligned as its most aligned member, but no more.  And there mustn't
be padding before the first member.  Thus, an s0 embedded in an s1 needs to be
short-aligned, but no more.

>But on the 3b2 running sysVr3.2,
>x1.s is offset 4 bytes, apparently because the struct s0 is padded
>out to a 32 bit boundary in s1.  Is this a "feature" of sysVr3.2,
>or just the 3b2's?

It's just a "feature" of the particular compiler you are using.

>From K&R second edition, I gather there are no
>assurances regarding alignment or padding in this instance, but this
>behaviour seems contrary to the usefulness of C as a low level language.

ANSI requires that an implementation document the alignment used, but it
can't mandate what that alignment is, precisely to make C useful as a low
level language, because different hardware has different requirements.
The expectation is that the alignment used suits the hardware, and that
structures are not more aligned than necessary.  You just happen to be using
a low-quality compiler.

If the structures you are dealing with are not being transmitted between
machines, there shouldn't be a problem unless there is some invalid use of
casts or unions.  If they are being transmitted between machines, they should
be converted to and from a canonical form.  Is is a mistake to make assumptions
about byte order or alignment consistency among different machine archtectures.