Path: utzoo!utgpu!news-server.csri.toronto.edu!dgp.toronto.edu!flaps
Newsgroups: comp.std.c
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Structure Member Padding
Message-ID: <1990Jul13.104407.29078@jarvis.csri.toronto.edu>
References: <1929@xn.LL.MIT.EDU> <1990Jul6.152959.336@zoo.toronto.edu> <1990Jul7.225141.12002@sq.sq.com> <13321@smoke.BRL.MIL> <10420@ogicse.ogc.edu>
Distribution: na
Date: 13 Jul 90 14:44:07 GMT
Lines: 19

daniels@ogicse.ogc.edu (Scott David Daniels) writes:
>This can easily be done by the compiler (it simply keeps track of holes and
>their alignments, and fills them whenever an appropriate (non-array) element
>is added.  The reason for non-array is to allow the existing code that extends
>a struct by adding to a final array at the end to continue to work.

For:
	struct { int i; char c; } var;
and
	struct { int i; char c[1]; } var;
to have different layouts, indeed different semantics with respect to layout,
would be quite bizarre.  Actually, it would be ok by me for the char to be
placed in different portions of the otherwise-wasted word in the two cases, but
for the behaviour of extending the struct by adding to the count passed to
malloc() to differ in the two cases would be strange.

ajr

p.s. the memcpy-clobber problem is of course more serious.