Re: git: d549de769055 - main - libc: Remove readdir_r(3) [This broke building rust 1.88]

rb_at_gid.co.uk <http://rb_at_gid.co.uk/> wrote on:
Date: Fri, 12 Sep 2025 19:09:33 UTC :

> > On 12 Sep 2025, at 11:59, Dag-Erling Smørgrav <des@FreeBSD.org> wrote:
> > 
> > Bob Bishop <rb@gid.co.uk> writes:
> >> And while I’m here, POSIX.1 defines for readdir_r (and readdir):
> >> 
> >> [EOVERFLOW]
> >> One of the values in the structure to be returned cannot be represented correctly.
> >> 
> >> …which I think would cover the case of indeterminate NAME_MAX/PATH_MAX for readdir_r.
> > 
> > No, because readdir_r() has no way of knowing the size of the buffer
> > that was passed to it.
> 
> It doesn’t need to know.
> 
> If NAME_MAX is defined,

What I get looking at the 2024 POSIX text for this area . . .

"If {NAME_MAX} is indeterminate (indicated by fpathconf() returning -1)":
POSIX does not seem to base the definition vs. indeterminate status on a
#define being present vs. not. (I'm not sure if that is what you intended
in your wording.) It is a run-time test based on argument to fpathconf()
[or, presumably, pathconf()].

It does seem to allow NAME_MAX as a #define --but as an implementation
defined detail, not as a requirement.

> the user must supply an adequately sized buffer (based on NAME_MAX) or shoot themselves in the foot.
> 
> If NAME_MAX is indefinite, readdir_r() returns EOVERFLOW immediately.


When I look at IEEE Std 1003.1-2024 for readdir_r's
EOVERFLOW, I see:

    • The [EOVERFLOW] mandatory error condition is added. This change is to support large files.

and:

[EOVERFLOW] One of the values in the structure to be returned cannot be represented correctly.

I'm not so sure that implementations will interpret
"fpathconf() returning -1" as a "support large files"
issue in/for readdir_r. Seems more likely that the
"indicated by fpathconf() returning -1" would be
expected to be used in the calling code to avoid
use of readdir_r at all for "fpathconf() returning -1" .
(The need for that being why readdir_r is obsolete now.)

For reference:

long fpathconf(int fildes, int name);
long pathconf(const char *path, int name);

using _PC_NAME_MAX for name returns the
{NAME_MAX} Variable's value for the filedes
or path that was supplied. It can return -1
to indicate indeterminate for that specific
argument value. The return value does not
need to be the same for all argument values.

Related Rationale text about the obsolescent status:

"If {NAME_MAX} is indeterminate (indicated by fpathconf() returning -1),
there is no way to reliably allocate a buffer large enough to hold a
filename being returned by readdir_r(). Therefore, readdir_r() has
been marked obsolescent and readdir() is now required to be thread
safe as long as there are no concurrent calls to it on a single
directory stream."

===
Mark Millard
marklmi at yahoo.com