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

[Adhemerval Zanella Netto]

On 16/02/26 12:10, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>>>> I don't think applications can meaningfully allocate the FTS type or
>>>> copy it, so we could add hidden members (with an internal umbrella
>>>> struct) that are not present on the external interface?
>>>
>>> The main issue is the _ftsent, where is uses a flexible array for the
>>> file name and the gnulib added some internal member over the time.  So
>>> we can no easily add internal fields without breaking compatibility.
>>
>> I think we can internally allocate it as:
>>
>>  struct wrapper_ftsent
>>  {
>>    /* required extra fields */
>>    FTSENT fsent;
>>  };
>>
>> and then accessing the fields when required assuming this layout.  It does
>> complicate a bit the code, but it should be doable.
> 
> Exactly, as long as we allocate and deallocate inside glibc, we have a
> lot of flexibility.

The resulting patch requires to import some gnulib modules [1], and adapt it
to the glibc (LFS, 64-bit time, linknamespace and PLT fixes); but it does
not trigger any regression.  And taking in consideration this is the
implementation used on findutils and coreutils I think it should be
battle proven.

I extended the FTS/FTS64 struct with the fields required for the gnulib
support options (FTS_TIGHT_CYCLE_CHECK, FTS_CWDFD, FTS_DEFER_STAT,
FTS_VERBATIM, and FTS_MOUNT) and assuming application do not allocate
or embedded the struct it should be backward compatible.

I did not see much meaningful performance difference for {n}ftw, although
I think we can simplify the nftw refactor with the newer flags FTS_CWDFD.
The gnulib fixes two longstanding issues (BZ 22944, BZ 20331).

[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=82e60c6e48116d3d33abf12b22707047f199f0ea