[Bug-gnulib] getline bug?

[Simon Josefsson]

Before trying to get getline licensed as LGPL, I want to address the
following.  There is little point in trying to relicense the existing
gnulib getline, if I can't use it.

Isn't it a bug that the gnulib getline API is thread unsafe?  The
glibc version is thread safe, as far as I know, and I believe glibc
should set the standard for gnulib modules.

I need getline in Shishi, which is GPL, but aims to be thread safe.
(I also need it in libidn + gsasl, which are LGPL, but also aims to be
thread safe.)

Here's a proposed solution: Apply the following patch.  Then
applications (coreutils?) that want the optimized getline version can
put AC_DEFINE(USE_UNLOCKED_IO, 1) in their configure.ac.  Applications
that want the glibc version of getline doesn't have to do anything.

Finally a question: do the gnulib getline differ in any other way from
the glibc version?  It seems gnulib's getline call a getndelim2 which
seem to be slightly different from getdelim, which is what glibc uses.
If the interface is different, that seems bad as well.

For what it's worth, there is a simple, glibc-derived,
getline+getdelim in lessergnulib.  Not tested, though.

Thanks.

--- getndelim2.c        14 Jul 2004 21:50:02 +0200      1.8
+++ getndelim2.c        03 Oct 2004 01:15:49 +0200      
@@ -29,7 +29,9 @@
 #include <stdlib.h>
 #include <stddef.h>
 
+#ifdef USE_UNLOCKED_IO
 #include "unlocked-io.h"
+#endif
 
 #include <limits.h>
 #if HAVE_INTTYPES_H
--- getline     22 Sep 2004 17:50:30 +0200      1.7
+++ getline     03 Oct 2004 01:17:29 +0200      
@@ -11,7 +11,6 @@
 m4/ssize_t.m4
 
 Depends-on:
-unlocked-io
 
 configure.ac:
 AM_FUNC_GETLINE
--- getndelim2  22 Sep 2004 17:50:30 +0200      1.3
+++ getndelim2  03 Oct 2004 01:17:37 +0200      
@@ -9,7 +9,6 @@
 m4/ssize_t.m4
 
 Depends-on:
-unlocked-io
 
 configure.ac:
 gl_GETNDELIM2