Re: portability patch for io/ftw.c

[Jim Meyering]

Ulrich Drepper <address@hidden> wrote:
>> IMHO, we shouldn't have to make such
>> exceptions and litter otherwise-clean code with cpp conditionals
>> involving _LIBC.  end of rant :-)
>
> ???  Of course we need these _LIBC exceptions.  I'm not going to add all
> the HAVE_* macros.  That's just calling for problems.

Hmm... knew I shouldn't have said that :-)
I know that using HAVE_* macros in public header files is not an option.
What I mean is for the portable .c files.  I certainly didn't expect to
hear you offer to fix them all :-)  I should have called it a *pointless*
rant.  I know it's too late to change.

>> If you can point to such a system, please let everyone know.
>> That code has been used in the GNU tools I maintain for a long
>> time, without causing any problems, afaik.
>
> I fortunately don't have to use any non-Linux system.  Maybe all these
> legacy systems died the dead they deserved.

I hope so :-)

>> As for being optimal, there may be a few proprietary systems on which
>> the strlen is not strictly necessary, but I don't want to spend my
>> time finding them and optimizing this code to accommodate them.
>
> Well, the case also is important if your configure script decides to not
> use the built-in nftw from glibc on Linux.  The old libc should of
> course be updated but if this happens after compiling coreutils you're
> stuck with the inefficient nftw.

Currently I cannot use glibc's nftw on *any* system, because it lacks
functionality required by du.  So the copy distributed with coreutils
  ftp://alpha.gnu.org/gnu/coreutils/coreutils-4.5.6.tar.bz2
contains changes to do the following:

  - handle trailing slashes properly (dereference per POSIX)
      (I've already sent you a patch for this)
  - report chdir failures to the callback function
      proposed here: 
http://sources.redhat.com/ml/bug-glibc/2003-01/msg00037.html
  - support pruning (for du's --exclude* options)

However, that might not matter in the long run, if I switch to using
fts instead.  fts is not subject to stack-size limitations, since it
doesn't use recursion like ftw.  But it does have at least one problem:
it performs an O(N^2) (N=depth-in-hierarchy) cycle check for each directory
it processes.  Once that's been fixed, I'll be able to compare the
performance of du using ftw with that using fts.

> Anyway, I've applied the patch since none of this really matters for glibc.

Thanks!

pgpgC_tz02Cvc.pgp
Description: PGP signature