bug-gnulib
[Top][All Lists]
Advanced

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

fts in gnulib behave different than glibc


From: Simon Josefsson
Subject: fts in gnulib behave different than glibc
Date: Wed, 28 Jul 2021 10:08:28 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Hi.  I replaced GNU InetUtils' old custom fts implementation with the
one from gnulib, but self-tests started failing.  Looking at the code,
it seems gnulib's fts implementation has diverged compared to glibc, and
has some optimizations that (I think) change the API (wrt stat and
chdir).  Also, gnulib's fts module is always enabled, even on modern
glibc systems.  InetUtils's usage of fts works fine with modern glibc,
but it didn't work with gnulib's version (it needed a FTS_NOCHDIR).  The
gnulib manual for the fts replacement module isn't terribly clear about
this.  Is there a reason for this behaviour?

I would prefer if there were two fts modules in gnulib:

1) One module 'fts' based on glibc's code, that is only enabled in on
systems that doesn't have fts, or where fts is known to be buggy.

2) One 'fts-faster' that is the current code, which can be used when you
always wants to pull in the optimized implementation.

Then InetUtils would use system fts on glibc platforms, and not always
have to pull in a replacement copy.

What do you think?

I could live with a new module 'fts-optional' that only pulls in the
current 'fts' module when the system is lacking it.  That doesn't fix
the API confusion, but is probably sufficient for InetUtils.

/Simon

Attachment: signature.asc
Description: PGP signature


reply via email to

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