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

Florian Weimer fweimer@redhat.com
Mon Feb 16 15:10:41 GMT 2026


* 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.

Thanks,
Florian



More information about the Libc-alpha mailing list