[PATCH v5 2/2] io: Use gnulib fts implementation (BZ 22944, BZ 20331)

[Adhemerval Zanella Netto]

On 11/04/26 23:45, Collin Funk wrote:
> Collin Funk <collin.funk1@gmail.com> writes:
> 
>> Here is a Gnulib patch which avoids the stat and preserves the old glibc
>> behavior:
>>
>> diff --git a/lib/fts.c b/lib/fts.c
>> index c61e8d89d8..fb42f243a0 100644
>> --- a/lib/fts.c
>> +++ b/lib/fts.c
>> @@ -1035,6 +1035,22 @@ check_for_dir:
>>                      if (! enter_dir (sp, p))
>>                        return NULL;
>>                    }
>> +
>> +                if (p->fts_info == FTS_NSOK)
>> +                  {
>> +                    if (S_ISREG (p->fts_statp->st_mode))
>> +                      p->fts_info = FTS_F;
>> +                    else if (S_ISDIR (p->fts_statp->st_mode))
>> +                      {
>> +                        if (! ISDOT (p->fts_name))
>> +                          p->fts_info = FTS_D;
>> +                        else
>> +                          {
>> +                            p->fts_info = (p->fts_level == FTS_ROOTLEVEL
>> +                                           ? FTS_D : FTS_DOT);
>> +                          }
>> +                      }
>> +                  }
>>                  return p;
>>          }
>>  cd_dot_dot:
> 
> Actually ignore this...
> 
> Having ent->fts_info set to FTS_F or FTS_D would imply that
> ent->fts_statp is valid, which it isn't. Therefore, this would cause
> more breakage. :)
> 
> I guess we will have to version the symbols.

Sigh, I was working with the assumption that gnulib code widely used to avoid
possible compatibility issues that would arise of changing a current support
flag; but it does not seem the case.

I was also trying to avoid adding a symbol versioning for fts because current
code it already quite a mess because LFS and time64 support; and I am not sure
whether we should base the compat implementation in a complete separate
implementation or if we should add some internal flags to support the compat
and default symbols differences (so we have a more complex implementation,
but less code to maintain).

Or we could just revert this changes, which I think it is hard way to fix it,
but feasible.

Thoughts?