From: "Segher Boessenkool" <segher@xxxxxxxxx>
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
