Alignment (was: Structure Member Padding)

[Mark Brader]

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.  

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.

But if Doug's "machine storage units" are bytes, then I think he's wrong.
The relevant excerpt from 3.1.2.5 is:

#  An "array type" describes a contiguously allocated nonempty set of
#  objects with a particular ... type, called the "element type".

I can't take "contiguously allocated" to mean anything else but that
the object declared by "char y[4];" occupies exactly 4 bytes, which have
consecutive addresses; sizeof y must be 4.  This interpretation is
confirmed by the footnote to 3.3.6, and by the last example in 3.3.3.4.
But, then, y[0] and y[1] are char objects not both on even addresses.

Doug, did I miss something, or am I not interpreting you correctly?


In subsequent discussion, Bob Larson noted that:
| Prime's C compiler stores char variables in the right half of a 2-byte
| "halfword", and character arrays are packed and start at the left. ...
| As far as I know, they havn't changed this behavor in their beta-test
| ansi compiler. ...
| union {
|     struct { char a, b, c, d;} x;
|     char y[4];
| }
| Code that assumes that x.a is the same as y[0] and x.d is y[3] will not
| work on Prime's C compiler.  Note that &x.a+1 != &x.b here.
[The last line was corrected by me.]

This is a different situation from what Doug describes; here y works as
I say above.  According to what I said before, such a compiler is non-
conforming with respect to the layout of x.  On rereading the relevant
section, however, I will soften only that to say that I *think* it's
non-conforming.

I'll repeat the wording that I quoted before, since it's probably
expired on most machines.

1.6 defines "alignment" as "a requirement that objects of a particular
type be located on storage boundaries with addresses that are particular
multiples of a byte address".

3.5.2.1 says that there may be padding within, or at the end of, a structure
"AS NECESSARY to achieve the appropriate alignment" -- my emphasis --
and mentions no other reason why there could be padding.

I argue that, if alignment is a requirment that can only be imposed on a
type, then this means that objects of the same type declared as consecutive
members of a struct can't have padding between them.

However, there is another sentence in 3.5.2.1 that gives me pause.  It
appears a little before the part dealing with padding, and says:

# Each non-bit-field member of a structure or union object is aligned
# in an implementation-defined manner appropriate to its type.

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.
I do think we need a ruling on this.

-- 
Mark Brader			"Relax -- I know the procedures backwards."
SoftQuad Inc., Toronto		"Yeah, well, that's a quick way to get killed."
utzoo!sq!msb, msb at sq.com			-- Chris Boucher, Star Cops

This article is in the public domain.