Re: Future of libio vtable compatibility

[Carlos O'Donell <carlos at redhat dot com>]

On 06/18/2018 04:18 PM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> Let me pose another question...
>>  
>>> It almost looks to me as if nobody really wants that level of
>>> backwards compatibility.
>>
>> Assume you had reliable test system with 100 tests for the backwards
>> compatibility support.
>>
>> Given the tests, would you still make the same argument for removal?
> 
> Probably not.  Depends how good the tests are.  If lack of testing of
> those internal interfaces does not prevent library cleanups and other
> changes (such as the implement of fgetln, biased locking for stdio
> streams, or *printf speed-ups),
> 
>> Is the argument about poor testing semi-independent of the argument for
>> removal?
> 
> I think the lack of a testsuite is a huge upfront cost if we ever
> tackle libio modernization.  And if we treat vtables as an internal
> implementation detail, it's significantly easier to achieve some
> decent level of coverage.
> 
> If give up the notion of vtable compatibility (or internal, data
> structure layout compatibility), it will be somewhat easier to
> convince that certain fixes are acceptable.
> 
> For example, with virtual methods, the call graph between virtual
> methods is part of the API, and also the relative order of internal
> calls.  Or look at the marker support (see struct _IO_marker).  I'm
> not sure which of the streams are compatible with that.

So either...

(a) Improve libio vtable testing, covering the bug in question,
    and fixing the bug for compat.

and/or

(b) Remove libio vtable compat.

But given the dubious value of the libio vtable compat, I think we
should be deprecating it in a future release. I agree with you that
no complaints upstream is the strongest indicator that nobody is
using old binaries with really new glibc. We usually see breakage
very quickly when we touch features people care about.

It still feels like to me that this is glibc 3.0 material where we
kill the compat, and then enable everyone to start restructuring
the code immediately after 3.0 releases with the expectation set
that we aren't supporting ancient libstdc++ binaries. This can be
done without aprioiri trying to figure out which changes are possible
and which are not (your question about complexity).

My comment about making the next release 3.0 was not meant to give
anyone a heart attack, but just to indicate my willingness to move
this issue forward. Should 2.29 be 3.0?

Cheers,
Carlos.