Path: utzoo!attcan!uunet!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Structure Member Padding
Message-ID: <13321@smoke.BRL.MIL>
Date: 8 Jul 90 12:17:48 GMT
References: <1929@xn.LL.MIT.EDU> <1990Jul6.152959.336@zoo.toronto.edu> <1990Jul7.225141.12002@sq.sq.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 36

In article <1990Jul7.225141.12002@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:
>#  a requirement that objects of a particular type be located on storage
>#  boundaries with addresses that are particular multiples of a byte address.
>(presumably meaning "with byte addresses that are multiples of a particular
>value", but never mind, the intent is clear).

No, non-char objects do not have "byte addresses", only chars have those.
On a word-addressable architecture, a char must evenly divide a word, so
word-aligned objects will be aligned on specific multiples of "byte
addresses" even though "byte addressing" will in that case be an artifact
invented by the compiler implementor specifically for the purpose of being
able to denote individual members of packed char arrays.

>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).

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).

Your argument about struct member alignment seems correct, but it raises
a problem with
	struct {
		short s;
		char a, b, c;
	};
on a word-addressed architecture, if short is made a half-word.  Note that
your line of argument would lead to the conclusion that there can be no
padding before the first char, but in such a situation a half-word of
padding would be necessary.  So, if your interpretation is correct, an
implementor in such an environment would have to make his shorts full-
word sized.  This may not be a big problem, but I'm somewhat surprised
by this.  I think we could use an official interpretation ruling here too.