Tail padding, again

[Jim Dehnert]

> From mitchell at codesourcery.com Fri Nov  3 22:00:09 2000
> 
> >>>>> "Jim" == Jim Dehnert <dehnert at baalbek.engr.sgi.com> writes:
> 
>     Jim> The committee was also _very_ interested in using the tail
>     Jim> padding, and examples were provided that I thought were
>     Jim> fairly convincing.  Backing out of this at this time would
>     Jim> cause various people a fair amount of trouble, I think.
> 
> Who?  Are those people committed to implementing the rest of the ABI?

My understanding is that the Compaq compiler released in the summer
implemented the data model.  The original request for this overlaying
came from HP.  Perhaps they would like to comment.

> I know of three front-ends that have pretty major problems with doing
> this kind of overlyaing: GCC, HP, and EDG.  It's not easily doable in
> any of them.  Worse yet, it's going to cause major problems in various
> back-ends, too.  I know it will cause trouble in both the HP and GCC
> back-ends.  (For example, the GCC back-end assumes that access through
> an `S*' can only alias things of types that appear as fields in `S';
> that totally breaks if you overlay things.)

It only breaks if you do copying with memcpy(sizeof) instead of
memcpy(dsize).  The Standard, as I recall, specifies copying
member-by-member.  Both Jason (g++) and Daveed (HP, then EDG) were
heavily involved in this subject, and didn't seem to expect such major
problems.  Doesn't mean they didn't overlook them, of course, but it
was discussed extensively.

> Furthermore, this is going to break a *lot* of code, including pretty
> much any code that derives from/includes a C struct.  (Copy
> constructor for derived class calls C copying function, which does a
> memcpy, which clobbers parts of the derived class.)  Users are going
> to be very surprised when adding or removing a non-virtual member
> function changes the size of a class.
> 
> Translation from C++ to C is something a *lot* of compilers and tools
> do internally.  This optimization makes it very, very difficult to
> represent C++ structure layout in terms of C structs.

Again, POD data (C structs) has align=nvalign, and size=nvsize=dsize.
We do NOT put other members in POD padding, for the reasons you
mention.  As far as I can tell, C structs will be laid out exactly the
same in C++ as in C, and C copying (memcpy) will work fine for them.
That certainly was the intent.

Are you overlooking this, or am I missing something?

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272