This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Christopher Jefferson wrote:

>> But the harder problem is the following scenario:
>> 
>> * libstdc++ defines a class C, whose ABI is now changing
>> 
>> * libfoo.so depends on libstdc++.so and uses the old version of C
>> 
>> * main.c creates objects of class C (using the new definition of C)
>> and passes them to functions in libfoo.so

> It wouldn't fix the problem. It would however lead to libfoo.so and
> main.c not linking, rather than the current unpredictable run-time
> crash.

Yes, that's certainly an improved failure mode.  Don't get me wrong; I'm
not arguing against inline namespaces.

I just think that Ian posed the problem of "how can we future-proof
things so that we never have to bump the .so version again?" and I think
the answers are essentially:

(a) Convince the ISO committee that doing anything which breaks the ABI
is unacceptable, or

(b) Ignore the ISO committe, at least to the extent they mandate
ABI-breaking changes

I do think the earlier suggestion of "add a few spare vtable slots" is a
good bit of future-proofing, in that it improves the odds that any given
change will be ABI-compatible.

There's also the issue that many changes to "private" parts of classes
would seem to be OK, but, in the presence of inline functions, are
definitely not OK.  But, that's presumably an issue with which the
libstdc++ maintainers have long ago become comfortable.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]