Re: Maintaining libio

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 19/04/2017 06:17, Florian Weimer wrote:
> On 08/08/2016 10:43 PM, Adhemerval Zanella wrote:
>> @@ -239,14 +254,14 @@ _IO_str_seekoff (_IO_FILE *fp, _IO_off64_t offset, int dir, int mode)
>>     if (mode == 0 && (fp->_flags & _IO_TIED_PUT_GET))
>>       mode = (fp->_flags & _IO_CURRENTLY_PUTTING ? _IOS_OUTPUT : _IOS_INPUT);
>>   +  bool was_writing = (fp->_IO_write_ptr > fp->_IO_write_base
>> +             || _IO_in_put_mode (fp));
>> +  if (was_writing)
>> +    _IO_str_switch_to_get_mode (fp);
> 
> This patch breaks backwards compatibility with applications which call _IO_str_seekoff directly.  This is an exported function and it was originally intended as a building block for building custom streams, so we cannot change what it does just to fit glibc's internal needs, based on how the function is called from within glibc.
> 
> But if we apply this standard of backwards compatibility, we cannot make *any* changes to libio (including important security hardening) without copying most of the code first.  We have no tests which check the extended API behavior, and the interface is very much under-documented, too.
> 
> What should we do here?

Right, so should we revert the patch, reopen both bugs and rework all libio 
in this case (which might span on multiple releases)? I know that we should
aim for compatibility where applicable, but I think blindly aim for it even
for bug/out of conformance cases adds more maintainer burden that actually
fixes real cases usage. 

For this specific case, the code is clearly buggy when ran a different libc
for a non-specific gnu extension (open_memstream). Should we still provide 
buggy compat interfaces in this case (as we are still aiming to provide)?

> 
> I'm leaning towards a clean break: Stop installing <libio.h>.  Remove all symbols related to external vtable support (i.e., an ABI break, so that affected programs fail in a clean manner).  Do this now, and revisit it for glibc 2.27 if someone actually has an application that breaks due to this.
> 
> For the old inlined putc_unlocked implementation which directly poked at struct _IO_FILE, I suggest we write tests and keep compatibility.
> 
> Comments?
> 
> Thanks,
> Florian