Tail padding, again

[Mark Mitchell]

>>>>> "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?

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.)

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.

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com