[RFC] C++1x breaking the ABI in one more place :(

Joe Buck Joe.Buck@synopsys.COM
Wed May 19 23:46:00 GMT 2010


On Wed, May 19, 2010 at 04:23:17PM -0700, Paolo Carlini wrote:
> Hi,
> > Putting the new file into an inline namespace would at least allow
> > code using the old and new std::time_get to live together, although
> > they couldn't be passed back and forth. I don't know how much people
> > do that.
> Turns out, the time_get object itself doesn't change size - I simply
> misread the output of abi_check, sorry - the failure is due to the
> *vtable* changing size. Thus I'm more optimistic, but want to make sure
> it's really fine linking against the new vtable before loosening
> abi_check about the size of vtables...

There is an ABI issue here, but it might be much lower priority.

If there is a class std::foo that has virtual functions, and a new
one is added at the end, code that used the old std::foo will still
work fine, and likewise if there's a class

class d1foo : public foo

that overrides the virtual functions of foo but doesn't add more.
However, if d1foo adds new virtual functions and there's a d2foo that
derives from that, you have a problem, because now the inconsistent tables
will be exposed.  Without that extra level of derivation and the extra
functions, the new entries at the end of the table would never be used by
the old code, so there would be no problem.  But otherwise the new
foo vtable slot collides with the old d1foo vtable slot.

But this is a kind of breakage that might be acceptable to fix an
otherwise broken library (though users should be warned about it),
especially in cases where we wouldn't expect this kind of use.

Now, if only we could hop in our time machines, go back, and put in a few
dummy slots in certain virtual function tables in the standard library.
They wouldn't cost much and could be filled in as missing functions are
discovered (or as program committees invent new functionality) without
any ABI breakage.




More information about the Libstdc++ mailing list