[PATCH] io: Refactor {n}ftw to use fts for stack safety and conformance (BZ 33882)

[Adhemerval Zanella Netto]

On 13/02/26 19:14, Collin Funk wrote:
> Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:
>>
>> However it does way better memory usage for the pathological cases. Using the
>> nested 5000 directories from tst-nftw-bz33882 massif for master shows:
> [...]
>> And I do not if we can implement a feasible {n}ftw with recursion *without*
>> imposing some path limits (which is an arbitrary limits that conflict with the
>> GNU Coding Standards).
>>
>> Maybe we can optimize it better by reimplement a FTS without some extra
>> requirement, but this will also duplicate code.
> 
> FWIW, my opinion is that the ability to visit arbitrary depths is more
> important than the performance here.
> 
> Gnulib uses a slightly modified implementation of fts, e.g., it uses
> openat and avoids f?chdir, but both versions manage memory very
> efficiently and can visit arbitrary depths. This is quite important for
> GNU coreutils, for obvious reasons. Other implementations tend to impose
> arbitrary limits and/or overflow the stack.

As I added on BZ#33882, the glibc FTS implementation is subpar because it is 
constraint by the ABI (we can not change size, member alignment, or the 
semantics of existing members of FTS and FTSENT without all the extra burden 
of symbol versioning). 

I think we can try to adapt the gnulib implementation, but it will be a
somewhat complex task without breaking the API. And we will need to break the
ABI anyway to support FTS_TIGHT_CYCLE_CHECK/FTS_CWDFD/FTS_DEFER_STAT.  

So one option might just move the current implementation to compat and use the 
gnulib one as in a new 2.44 namespace.