Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!pacbell.com!ucsd!nprdc!stanonik
From: stanonik@nprdc.navy.mil (Ron Stanonik)
Newsgroups: comp.unix.programmer
Subject: struct 32 bit aligned and padded
Message-ID: <14082@arctic.nprdc.navy.mil>
Date: 11 Apr 91 16:23:46 GMT
Sender: news@nprdc.navy.mil
Reply-To: stanonik@nprdc.navy.mil (Ron Stanonik)
Organization: Navy Personnel R&D Center, San Diego
Lines: 33

We ran into a little problem while porting some 4.3bsd/sunos
code to a 3b2 running sysVr3.2.  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.  For example,
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.
That's what happens on vax's running 4.3bsd, sun's running sunos4.1, hp's
running hpux, 386's running sysVr4.  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?  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.

(Specfically we ran into this because EGP headers end on a 16 bit
boundary, immediately followed by the remainder of the EGP packet.
Because the header was padded, the remainder of the packet was
incorrectly positioned.)

Thanks,

Ron Stanonik
stanonik@nprdc.navy.mil
ucsd!nprdc!stanonik