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

Paolo Carlini paolo.carlini@oracle.com
Thu May 20 09:17:00 GMT 2010


Hi,
> On 05/19/2010 06:26 PM, Paolo Carlini wrote:
>> 80    std::time_get<_CharT, _InIter>::do_get [with _CharT = char,
>> _InIter = std::istreambuf_iterator<char, std::char_traits<char>  >,
>> iter_type = std::istreambuf_iterator<char, std::char_traits<char>  >,
>> std::ios_base::iostate = std::_Ios_Iostate]
>>
>> Now I need help about figuring out of serious is this issue: suppose we
>> are exporting this new vtable and an old binary tries to link against
>> it. Would it break?
>
> As I mentioned before, I believe it will only break if something in
> the binary both derives from time_get and adds additional virtual
> functions, e.g.
>
> class mytime : std::time_get<...>
> {
>   virtual void dostuff ();
> }
>
> If this were compiled against the old time_get, it would put dostuff()
> at position 80 in the vtable that mytime shares with time_get;
> compiled against the new time_get dostuff() would be at offset 88,
> which breaks binary compatibility.
>
> I don't know how likely this scenario is.
Thanks Jason for your clarification. I'm catching up with the discussion
which developed while I was sleeping, and I understand people want to be
careful about that. I don't disagree, indeed, when I sent my last
messages yesterday I was pretty sure that without a special trick (which
I don't know) or a new mechanism we could not proceed without risking
breaking the ABI.

Thanks,
Paolo.



More information about the Libstdc++ mailing list