🚀 go-pugleaf

Steve Clamage (clamage@Eng.Sun.COM) wrote:

|> tony@online.tmx.com.au (Tony Cook) writes:

|> >J. Kanze (kanze@gabi-soft.fr) wrote:

|> >: 	struct X { int i ; char c ; } ;
|> >: 	X				x ;
|> >: 	char			c[ 3 ] ;

|> >: On my system, sizeof( X ) == 8, as does sizeof( x ).  And of course,
|> >: sizeof( c ) == 3.  Curiously, however, the two variables only take up a
|> >: total of 8 bytes; in this particular case, the physical sizeof x is 5,
|> >: and not 8.  This is a perfectly legal, and frequent, implementation.)

|> >Are you sure about this?  Considering X is a POD, what if the
|> >programmer has coded:

|> >	memset(&x, 0, sizeof(X));

|> >somewhere in their program?  Or does this produce undefined
|> >behaviour?

|> I think James meant that only the first 5 bytes of the struct have
|> meaningful data; the rest is padding needed for alignment. The
|> compiler must allocate sizeof(X) bytes for any type X, if only
|> because distinct objects must not overlap.

Actually, I was just writing faster than I was thinking; what I said
(and meant) is wrong.  (I even think that there was a clarification with
regards to this in the C standard.)

What I think a compiler could do is apply the as-if rule.  A conforming
program cannot compare the address of x and the address of c; if the
compiler could determine that sizeof( X ) was never used to write
unsigned char's from the address of x (or something like that), then it
could allocate them without the padding.  Given the cost of memory, and
the complexity of the analysis necessary, I don't really expect to see
any compilers doing this, though.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]