bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: getline


From: Simon Josefsson
Subject: Re: getline
Date: Sun, 17 Jul 2005 10:55:33 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

Paul Eggert <address@hidden> writes:

> Simon Josefsson <address@hidden> writes:
>
>> 1) Port the libc LGPL getdelim into a gnulib module.
>> 2a) Port the libc LGPL getline into a gnulib module.
>> 2b) Write a gnulib LGPL getline module that use the gnulib LGPL getdelim.
>> 3) Keep the current getndelim2 as a GPL module.
>>
>> The libc getline seem somewhat different from libc getdelim;
>> presumably it is faster than a simple getline implementation that use
>> getdelim.  I'm not sure this matter for gnulib though, so I prefer 2b
>> for simplicity.
>
> 2b might be simpler in the short run, but will it be in the long run?
> Or are you assuming that libc getline won't ever change much?

Glibc getline was last modified over 3 years ago.

On the other hand, I doubt a getline implementation that invoke
getdelim (i.e., 2b) would _ever_ have to change.  It is a one-liner.
So it would be easy maintenance.

Further, porting the libc getline implementation into a gnulib module
is some work, and if the libc implementation do change, it will have
to be synced manually, which I'd rather avoid.  With a one-liner
getline, we would only have to sync getdelim manually when/if it
changes.  Unless, of course, the files could be kept in sync
automatically, but:

>> Finally, I'm not sure we can ever hope to sync these files between
>> gnulib and libc.  The libc implementation look inside the FILE
>> structure.  Gnulib code can't do that.
>
> It could do so conditionally.  For example, it might use the
> stdio_ext.h interface on Solaris.
> <http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr5j?q=stdio_ext&a=view>.

I don't see any way to get access to the stdio data buffer, which
would be required if you want to use memchr on the stdio buffer, like
glibc does.  Further, the page says it doesn't work in 64-bit
environment.

> However, you're the expert here, and if you've judged that 2b)
> is less work overall, perhaps we should just do that.  We can
> always switch to 2a) later if need be.

I believe 2b is the simplest for gnulib.  My position is that I don't
care about the efficiency, I only need the function for compatibility
with platforms that doesn't have getline.  For perspective, the
getline implementation I posted should be roughly as fast as the
current getndelim2, so there should be no noticeable performance loss
for gnulib getline users.  If someone wants to do the work involved
with 2a, that's fine, but I doubt it will be significantly faster.

Ok, I'll propose a patch.

Thanks,
Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]