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

Hi,

> On 13 Sep 2025, at 02:29, Mark Millard <marklmi@yahoo.com> wrote:
> 
> 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.

Yes. My bad, I was lazily trying to say “If pathconf() gives a defined value for NAME_MAX..." 

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

…and this was just a suggestion to make holding on to readdir_r() for a while less unpalatable.

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


--
Bob Bishop       t: +44 (0)118 940 1243
rb@gid.co.uk     m: +44 (0)783 626 4518