Re: [PATCH] libio: Implement internal function __libc_readline_unlocked

[Carlos O'Donell <carlos at redhat dot com>]

On 07/06/2018 02:28 PM, Jonathan Nieder wrote:
> Hi,
> 
> Florian Weimer wrote:
>> On 07/06/2018 02:31 PM, Florian Weimer wrote:
> 
>>> The caller should not call the function if the stream is in an error
>>> condition I added a comment to the header file.
> 
> Thanks.
> 
> [...]
>> --- a/include/stdio.h
>> +++ b/include/stdio.h
>> @@ -127,6 +127,19 @@ extern int __fxprintf (FILE *__fp, const char *__fmt, ...)
>>  extern int __fxprintf_nocancel (FILE *__fp, const char *__fmt, ...)
>>       __attribute__ ((__format__ (__printf__, 2, 3))) attribute_hidden;
>>  
>> +/* Read the next line from FP into BUFFER, of LENGTH bytes.  LINE will
>> +   include the line terminator and a NUL terminator.  On success,
>> +   return the length of the line, including the line terminator, but
>> +   excluding the NUL termintor.  On EOF, return zero and write a NUL
>> +   terminator.  On error, return -1 and set errno.  If the total byte
>> +   count (line and both terminators) exceeds LENGTH, return -1 and set
>> +   errno to ERANGE (but do not mark the stream as failed).
>> +
>> +   The behavior is undefined if FP is not seekable, or if the stream
>> +   is already in an error state.  */
>> +ssize_t __libc_readline_unlocked (FILE *fp, char *buffer, size_t length);
>> +libc_hidden_proto (__libc_readline_unlocked);
> 
> Makes sense.
> 
> What kind of stability guarantees do we make for this kind of
> double-underscored GLIBC_PRIVATE symbol?  E.g. if we decide to remove
> it later or change its behavior, is that easy to do?

Very easy.

> I'm not looking for any particular answer --- an answer like "see
> such-and-such wiki page" or "see such-and-such bug about missing
> documentation" would be the ideal.

Officially the use of GLIBC_PRIVATE symbols by anything other than
glibc is expressly forbidden, but we don't enforce that in any way.

We can change GLIBC_PRIVATE symbols at will. There is no stability
guarantee at all.

We sometimes find out a major project is using a GLIBC_PRIVATE symbol
for special reasons and we promise not to remove it until we can
find them a better interface e.g. rust vs. __pthread_get_minstack.

In these cases we have pity on rust and keep the symbol around while
we try to solve the larger problem of core runtime <-> high-level
language interaction.

-- 
Cheers,
Carlos.