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 <[email protected]> wrote: > > > > Bob Bishop <[email protected]> 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
