Re: [13278] sizeof and allignment on 32bit target

["John S. Yates, Jr." <jyates at netezza dot com>]

From: "Segher Boessenkool" <segher@koffie.nl>
Sent: Sunday, July 27, 2003 10:26 AM


> John Yates wrote:
> > Long ago I internalized the point that sizeof() does
> > not return the minimum number of bytes that need to
> > be copied in an aggregate assignment but rather the
> > spacing between elements in an array:
> > 
> > struct foo { ... };
> > foo a[2];
> > 
> > ((char*)&a[0]) + sizeof(foo) equals ((char*)&a[1])
> > 
> > This is a bit of a hole in the language definition
> > since there really is no way to obtain that minimum
> > number.
> 
> struct foo {
> ...
> some_type last_member;
> };
> 
> offsetof(struct foo, last_member) + sizeof a[0].last_member;

Sure.  If you know the exact declaration of a type and
are willing to abandon any pretense to abstraction or
maintainability.  Consider when the outer type is a
union rather than a struct...

My point was that a compiler synthesizing an assignment
operation for a POD-type probably uses a number other
than sizeof(<type>) for the number of bytes to be copied.

Your construction only reaffirms that point.

 
>  > Hence using sizeof() as the length of a
> > memcpy() to set a freestanding risks trashing some
> > other object if the compiler has practiced any kind
> > storage packing.
> 
> Overwriting padding bytes is guaranteed to be safe.

Can you point to chapter and verse where either a C or
a C++ standard insists that an implementation provide
padding beyond the declared members of a free-standing
struct or union?  It has been some years since I was
an active compiler writer so newer versions of either
standard may now address the issue.  But I am quite
sure that back when I lead the compiler group at Apollo
Computer there was no such wording.

/john