[PATCH] dirent.h: use __flexarr instead of hardcoding [1] length

[Etienne Brateau]

Hi,
Yes I mean Coreutils 9.2 (sorry for the confusion).

I tried to compile Coreutils 9.2 with gcc-14.2 on Hurd, and I got the error
at line of Coreutils lib/fts.c:1463 (
https://github.com/coreutils/gnulib/blob/master/lib/fts.c#L1463), because
gcc detects that access to d_name[1] (
https://github.com/coreutils/gnulib/blob/master/lib/fts.c#L235), and this
is "invalid" because it thinks that the size of d_name is 1.
I didn’t specified specific options to gcc, I just did `./configure &&
make`.

I discovered afterward that, this change actually break build of Perl
because, perl does `sizeof(dirent->d_name)` (
https://github.com/Perl/perl5/blob/blead/sv.c#L14148). And, with this
change, it doesn’t compile.

Doing a `sizeof(dirent->d_name)` seems to be a widely used technique (
https://codesearch.debian.net/search?q=sizeof%5B%5E%28%5D*%5C%28%5B%5E%29%5D*%5Cbd_name&literal=0
)

So this fix creates more problems that it solves.


Le jeu. 13 févr. 2025 à 20:14, Paul Eggert <eggert@cs.ucla.edu> a écrit :

> On 2/13/25 10:13, Etienne Brateau wrote:
> > The old definition prevent building gnulib 9.2 (file lib/fts.c) with
> > error strict-flex-arrays when checking for ISDOT when building Hurd.
>
> Gnulib doesn't have a version 9.2. Do you mean Coreutils 9.2's use of
> Gnulib?
>
> Also, "with error strict-flex-arrays when checking for ISDOT" is a bit
> hard to follow. Which relevant GCC options were used? And why does ISDOT
> and/or Hurd matter?
>
> Perhaps reword to "Pacify gcc -fstrict-flex-arrays=3
> -Wstrict-flex-arrays when building Coreutils 9.2's lib/fts.c." Or
> whatever options you were using.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250213/ec694391/attachment-0001.htm>