[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