This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: What to do about gnulib libio dependencies?
On Tue, Aug 21, 2018 at 9:04 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 08/21/2018 08:27 AM, Zack Weinberg wrote:
>> On Tue, Aug 21, 2018 at 7:41 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
>>> Carlos O'Donell wrote:
>>>>
>>>> Why is gnulib expecting these internals
>>>> to be stable?
>>>
>>> It's not. If glibc changes its internals in this area, gnulib will have to
>>> either adapt or give up. I hope it won't be the latter; too many GNU
>>> programs use that functionality.
>>
>> I think it would clarify this discussion if you gave concrete examples
>> of existing programs that use these functions, and described what they
>> are doing with them that can't be accomplished using the standard
>> interfaces. Since Florian expressed concern specifically about their
>> interaction with wide streams, it would also be good to know if these
>> programs ever make any use of wide streams (I tend to think that the
>> entire wchar.h set of interfaces is not fit for purpose anyway and
>> shouldn't be a priority).
>
> I think Florian's argument of "minimum harm" bypasses this line of
> reasoning. Either we accept all the interfaces or we don't and cause
> some harm.
Well, the question in my mind is, how much harm will it be? I don't
see how we can assess the tradeoff between consequences for external
applications and increased maintenance burden for us, without knowing
how important these APIs are to external applications. I would also
want to dig into just how invasive of libio internals these APIs
actually are. If they're like the stuff in stdio_ext.h, that's not a
big deal, but if they involve messing with vtables or forcing us to
preserve the C++-stream distinction between put and get pointers or
something on that level, that would be much more of a problem, IMO.
> Would you be opposed to having an "amnesty day" in which we accept
> the gnulib interface, and get some assurances from Paul that this
> won't happen again?
I am reluctant to agree to this without understanding the scope of the
problem better.
zw