[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
viable:-
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
curses).
Many thanks,
James.
--
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
- [Bug-gnulib] Calls to getstr() from findutils,
James Youngman <=