public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: libc-alpha@sourceware.org
Subject: Re: Future of libio vtable compatibility
Date: Mon, 18 Jun 2018 18:25:00 -0000	[thread overview]
Message-ID: <59a4b90c-4a7f-802e-8e5a-407dccbeade4@linaro.org> (raw)
In-Reply-To: <CAKCAbMg-fk4H82gstvZia6+PxGy6V1itZugadkRYqvB-cpiQXg@mail.gmail.com>



On 18/06/2018 14:41, Zack Weinberg wrote:
> On Mon, Jun 18, 2018 at 1:13 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
>>
>> We could require that vtable compatibility requires setting an
>> environment variable in glibc 2.28.  This might finally allow us to
>> gather some data.  Either nobody needs backwards compatibility, or our
>> backwards compatibility is just too perfect.  It's difficult to tell
>> why we don't see more bug reports in this area.
> 
> This is not quite the same thing as vtable compatibility, but based on
> having had to read a bunch of the relevant code for the bits/types/
> work, I suspect that programs that require the "old" FILE struct have
> been broken for some time.
> 
> zw
> 

I do think the libio compatibility is really more a burden than a 
solution. If I recall correctly, we already have it broken in some
occasions (for instance [1]) to fix actual reported bugs. And I 
think it is quite unproductive to keep compatibility to quite broken
API which does not seem to used anywhere and which requires an
extra burden in both testing and development for the sake of
compatibility (which we can't effectively test by the way).

[1] https://sourceware.org/ml/libc-alpha/2017-04/msg00356.html 

  reply	other threads:[~2018-06-18 18:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-15  7:50 Florian Weimer
2018-06-18 16:07 ` Carlos O'Donell
2018-06-18 17:15   ` Florian Weimer
2018-06-18 17:41     ` Zack Weinberg
2018-06-18 18:25       ` Adhemerval Zanella [this message]
2018-06-18 19:08       ` Florian Weimer
2018-06-18 19:26         ` Zack Weinberg
2018-06-18 19:22     ` Carlos O'Donell
2018-06-18 20:18       ` Florian Weimer
2018-06-18 20:28         ` Carlos O'Donell
     [not found]           ` <878t7bu834.fsf@mid.deneb.enyo.de>
     [not found]             ` <80e0f086-a966-618d-7b27-1f42a7b9a5c9@redhat.com>
2018-06-19 19:11               ` Florian Weimer
2018-06-19 19:20                 ` Carlos O'Donell
2018-06-19 12:18       ` Joseph Myers
2018-06-19 12:39         ` Adhemerval Zanella

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59a4b90c-4a7f-802e-8e5a-407dccbeade4@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).