From: utzoo!decvax!cca!gwyn@Brl@sri-unix
Newsgroups: net.unix-wizards
Title: Re:  C sizeof
Article-I.D.: sri-unix.3029
Posted: Wed Sep  1 00:55:40 1982
Received: Thu Sep  9 06:00:46 1982

From:     Doug Gwyn 
Date:     26 Aug 82 3:58:13-EDT (Thu)
Welcome to the hole-in-the-struct club.
On a PDP-11,
struct	{
	char	a;
	long	b;	/* not "int" whose size varies a lot */
	}
has to have a "padding" char so that the next MOS starts on a word (2-byte)
boundary, due to hardware restrictions (infamous "odd address trap").
Also, total struct size will always be even so that arrays of structs obey
the hardware restrictions too.

On the VAX this garbage is TOTALLY UNNECESSARY but some PCC implementor
apparently decided to squeeze a few nanoseconds out of the hardware by
longword (4-byte) aligning longs, floats, and doubles.  What burns me
about this is that it isn't even PDP-11 compatible so your binary files
will very likely not be accessible to the SAME C code on the VAX, and
there is no easy fix for this (contrary to initial appearances).

sizeof thing	always includes any alignment padding, so an array of n
things will have sizeof array == n * sizeof thing.

I/O of a padded struct does read/write the padding as well as the useful
data if you do something like
	write( 1, &thing, sizeof thing );
whereas to avoid the padding you would have to access MOSs separately:
	write( 1, &thing.a, sizeof thing.a );
	write( 1, &thing.b, sizeof thing.b );

Nothing can be done in general about this problem, since there are CPU
architectures that necessitate alignment (IBM 360 is maybe the worst).
It is a pity, though, that the VAX implementation is unnecessarily ugly.