[Someone asked me why it was that structures need internal paddding. This was my reply.]

From: scs@eskimo.com (Steve Summit)
Date: Sun, 17 Mar 2002 20:56:35 -0500
Message-Id: <2002Mar17.2056.scs.007@aeroroot.scs.ndip.eskimo.net>

You wrote:
> ...what is still haunting my brain is why structures
> need internal padding

It's for ``alignment''. Many processors can't access 2- and 4-byte quantities (e.g. ints and long ints) if they're crammed in every-which-way.

Suppose you have this structure:

	struct	{
		char a[3];
		short int b;
		long int c;
		char d[3];
		};

Now, you might think that it ought to be possible to pack this structure into memory like this:

	+-------+-------+-------+-------+
	|           a           |   b   |
	+-------+-------+-------+-------+
	|   b   |           c           |
	+-------+-------+-------+-------+
	|   c   |           d           |
	+-------+-------+-------+-------+

But it's much, much easier on the processor if the compiler arranges it like this:

	+-------+-------+-------+
	|           a           |
	+-------+-------+-------+
	|       b       |
	+-------+-------+-------+-------+
	|               c               |
	+-------+-------+-------+-------+
	|           d           |
	+-------+-------+-------+

In the ``packed'' version, notice how it's at least a little bit hard for you and me to see how the b and c fields wrap around? In a nutshell, it's hard for the processor, too. Therefore, most compilers will ``pad'' the structure (as if with extra, invisible fields) like this:

	+-------+-------+-------+-------+
	|           a           | pad1  |
	+-------+-------+-------+-------+
	|       b       |     pad2      |
	+-------+-------+-------+-------+
	|               c               |
	+-------+-------+-------+-------+
	|           d           | pad3  |
	+-------+-------+-------+-------+