[lsb-discuss] LSB conf call notes for 2008-06-18

Theodore Tso tytso at mit.edu
Thu Jun 19 12:54:17 PDT 2008

On Thu, Jun 19, 2008 at 01:22:44AM +0400, Denis Silakov wrote:
> The particular problem with getdelim comes from getline
> optimization; let me quote the bug 2128 - here is the code from
> bits/stdio.h:
> # ifdef __USE_GNU
> /* Like `getdelim', but reads up to a newline.  */
> __STDIO_INLINE _IO_ssize_t
> getline (char **__lineptr, size_t *__n, FILE *__stream)
> {
>   return __getdelim (__lineptr, __n, '\n', __stream);
> }
> # endif /* GNU */
> - we have getline function redeclared as inline and calling
> __getdelim. Thus, if some application uses getline, it actually
> obtains __getdelim dependency.

One of the things that worries me a little about what we're doing if
we don't use the __ symbol is whether in the long-term, glibc will
always keep the getline() symbol as an exported symbol, and whether it
will always do what the optimized version found in the header files
say they will do.

There are some interfaces where this happens already (i.e., stat), and
I could easily imagine the glibc folks claiming that they only support
programs that use the glibc header files, and if the glibc header
files implement getline() in terms of __getdelim(), they are under no
obligation to provide the getline() symbol in glibc.  Worse would be
if there is bitrot and inconsistencies between what the header files
do for a function like getline() and what the weak symbol for
getline() does, such that an application program which is built using
the standard glibc and glibc header files behaves one way, and that
same application built against the LSB header files behaves another.

That being said, trying to keep our header files in sync in terms of
the inline functions in glibc's header files, isn't something that I'm
excited about.  So far at least, glibc is keeping an ABI interface for
getline(), if all applications built against glibc would never use
that symbol (since they would use __getdelim instead).  Let's cross
our figers and hope that continues to be true.

						- Ted

More information about the lsb-discuss mailing list