bug-gnulib
[Top][All Lists]
Advanced

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

Re: [Bug-gnulib] Calls to getstr() from findutils


From: Bruno Haible
Subject: Re: [Bug-gnulib] Calls to getstr() from findutils
Date: Thu, 22 May 2003 14:15:05 +0200 (CEST)

James Youngman writes:
> Findutils calls getstr(), whose interface it expects to conform to
> versions 1.10 and previous of gnulib's lib/getline.c file (versions
> 1.3 and previous of lib/getstr.c).  Specifically, findutils does this
> in locate/locate.c:-
> 
>   pathsize = 1026;            /* Increased as necessary by getstr.  */
>   path = xmalloc (pathsize);
>   /* ... */
>   /* Overlay the old path with the remainder of the new.  */
>   nread = getstr (&path, &pathsize, fp, '\0', count);
> 
> getstr() is now static in gnulib's getline.c file

We made it static because we thought noone was using it, and
overlooked findutils. I see that 'locate' uses it in an inner loop.

Can you try using a different char* variable for reading the line,
then use memcpy, and measure how much speed difference it makes?
I mean, it's better for maintainability to use standard APIs.

> 1. Modify getline.c to add a getstr() interface (possibly renaming it)
>    and maintain the modified version

Of course we need to rename it, to avoid the clash with curses. My
proposal is 'getdelimo' or 'getdelim_offset'.

But the problem with reintroducing getstr in getline.c is that so many
programs don't use this function - they need getdelim and getline only
- and would compile useless code if we removed the
"#if defined __GNU_LIBRARY__ && HAVE_GETDELIM"
conditional.

> 2. Copy getline.c to another directory, and use my local getline.c
>    replacement, tracking changes in gnulib periodically.

We wish to avoid code duplication like this. gnulib is precisely an
effort to avoid this kind of maintenance hassle.

> 3. Devise some horrible patching arrangement for the build process
>    so that we keep the pristine gnulib sources but just tack on a 
>    global function to the end of getline.c which exposes the required 
>    functionality.

Not an option either.

What I propose - in the case that getstr() is really performance
relevant for 'locate' - is to move out the getstr() function from
getline.c to a separate file getdelimo.c. findutils would use a new
module 'getdelimo', whereas all other programs continue to just use
'getline'.

If that sounds ok, I can do the modifications tomorrow.

Bruno




reply via email to

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