Article View: comp.std.c
Article #1502Re: Structure Member Padding
From: Alan J Rosenthal
Date: Fri, 13 Jul 1990 14:44
Date: Fri, 13 Jul 1990 14:44
19 lines
1335 bytes
1335 bytes
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.
Technical Details
Message-ID:
<1990Jul13.104407.29078@jarvis.csri.toronto.edu>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!dgp.toronto.edu!flapsReferences:
<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>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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