[Top][All Lists]

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

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

From: James Youngman
Subject: [Bug-gnulib] Calls to getstr() from findutils
Date: 22 May 2003 08:45:27 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Hi there.

I've recently taken on the maintenance of findutils.  Following some
difficulty in getting findutils's lib/* and m4/* to work with recent
versions of GNU auto*, I've updated to the current CVS version of
gnulib.  That has been a great step forward, but I have one remaining
problem I'd like a little advice on.

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, but none of the
globally-available functions allow an offset to be specified ("count",
above).  Using "getdelim(path+count, ...)" wouldn't work because
locate.c expects the function to perform realloc() as appropriate.

There are two obvious options :-

1. Modify getline.c to add a getstr() interface (possibly renaming it)
   and maintain the modified version
2. Copy getline.c to another directory, and use my local getline.c
   replacement, tracking changes in gnulib periodically.
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.  Yuck.  This is not a real option.

Option (1) Obviously means that I can no longer simply use
"gnulib-tool" to blast a new version of gnulib into place.  Option (2)
imposes an additional code maintenance burden upon me but will
certainly solve the problem.  

However, the real point of my email is to find out if option (4) is

4. Ask nicely to see if the gnulib maintainters will expose a function
   like the getstr() of version 1.10 of getline.c (obviously with a
   different name in order to avoid the potential conflict with

Many thanks,

James Youngman, Manchester, UK.  Telephone +44 161 445 1998
Findutils Home Page: http://www.gnu.org/software/findutils/
Findutils Bug Reporting https://savannah.gnu.org/bugs/?group=findutils

reply via email to

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