Maintaining libio (was: Re: [PATCH v2 1/2] libio: Multiple fixes for open_{w}memstram (BZ#18241 and BZ#20181))

[Florian Weimer <fweimer at redhat dot com>]

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?

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