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 08/21/2018 09:18 AM, Zack Weinberg wrote:
> 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.
Fair enough. So I guess the next step is that someone has to do that
analysis :-)
--
Cheers,
Carlos.