Alignment (was: Structure Member Padding)

[Doug Gwyn]

In article <1990Aug8.012908.28364 at sq.sq.com> msb at sq.sq.com (Mark Brader) writes:
>A few weeks ago I wrote:
>! Note that alignment is a function of the type only, and it isn't
>! permitted for a type to have an alignment requirement larger than its
>! own size -- e.g., chars couldn't be required to be on even addresses --
>! because elements of an array are guaranteed to be adjacent (in 3.1.2.5).
>Doug Gwyn replied:
>> Chars could, however, in theory be constrained to even MACHINE addresses,
>> although consecutive char* values in C programs would still be required
>> to index consecutive char objects (each of which would, in such a case,
>> occupy two machine storage units).
>1.6 says that any object is a contiguous sequence of bytes, each of which
>is individually addressable.  3.3.3.4 forces the size of type char to be
>exactly 1 byte.  

But the "byte" in the C language need not correspond with a location
addressed by a unit of MACHINE address space.  For example, on a machine
that permits individual addressing of 8-bit bytes, a C implementation
could choose to allocate 16 bits per "char".  It is possible, although
not too likely, that quirks of the machine architecture would make this
the best choice.  (It is more likely that such a choice would be due to
a desire to avoid having to use the wchar_t kludgery to handle large
character sets, although PORTABLE programs would not be able to rely on
this feature for all implementations, alas.)

>If Doug is speaking of a machine with addressing in units smaller than
>bytes, then yes, I agree it would be possible for chars to be constrained
>to even machine addresses in that sense.  This doesn't contradict what
>I said, because I was speaking of byte addresses.

To be more specific, you were talking about the official C standard
meaning for "byte address", not the common usage of the term.  While
these will often be the same for many C implementations, they need not be.

You're right about the logical consequences of the standard constraints
involving arrays of char, sizeof(char)==1, etc.  Chars can have padding,
but every other C object must have size some integral multiple of the
size of a (padded) char.

>If 1.6 did not define "alignment" as it does, the last-quoted sentence
>might be taken to be saying that struct members can have additional
>alignment requirements beyond those imposed by the type, and I can see
>that an interpretation ruling might say that it DOES have that meaning.

Alignment is something that should not be defined too specifically.
For example, function arguments often have different requirements
imposed by the call stack than for ordinary statically-allocated storage.
(This was true of the original implementation of C, on the PDP-11.)
What is "necessary" can thus depend on various implementation choices.
Since these can change between releases of a compiler on the same system,
programs ought not to rely very much on the details of padding and
alignment; they should merely be written with the understanding that
padding and alignment constraints MAY affect storage layout, other than
those aspects for which the C standard insists be done a certain way.
One such requirement is that
	struct { type_t m; } s;
	assert((char *)&s == (char *)&s.m);
which can in fact be usefully exploited in legitimate applications.