This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Maintaining libio (was: Re: [PATCH v2 1/2] libio: Multiple fixes for open_{w}memstram (BZ#18241 and BZ#20181))
- From: Zack Weinberg <zackw at panix dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 19 Apr 2017 08:52:21 -0400
- Subject: Re: Maintaining libio (was: Re: [PATCH v2 1/2] libio: Multiple fixes for open_{w}memstram (BZ#18241 and BZ#20181))
- Authentication-results: sourceware.org; auth=none
- References: <1470418850-22175-1-git-send-email-adhemerval.zanella@linaro.org> <1470688986-8798-1-git-send-email-adhemerval.zanella@linaro.org> <a94ed40e-3965-6880-9218-93adf1247c55@redhat.com>
On Wed, Apr 19, 2017 at 5:17 AM, Florian Weimer <fweimer@redhat.com> wrote:
> 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.
I had been thinking about proposing a patch to stop installing
libio.h, myself. It definitely is getting in the way of forward
progress.
However, stdio in general could use a great deal of revision, and we
don't want to break compatibility several releases in a row. Maybe it
makes more sense to start in on a "revise stdio" project on a branch,
but not merge any breaking changes until it's completely ready to go?
Meanwhile, on trunk, we could make stdio.h stop including libio.h and
add a deprecation warning to libio.h -- that should be enough to flush
out applications that still need it, and find out what exactly they
need.
(I wish I had time to help with a stdio overhaul, but realistically I don't.)
zw