This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] libio: Implement internal function __libc_readline_unlocked
On 07/06/2018 02:28 PM, Jonathan Nieder wrote:
> 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.
>> --- 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?
> 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