Date: Sat, 13 Sep 2025 18:20:28 +0100 From: rb@gid.co.uk To: Mark Millard <marklmi@yahoo.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: git: d549de769055 - main - libc: Remove readdir_r(3) [This broke building rust 1.88] Message-ID: <1D02413E-B7DF-4604-A28E-45AA9B49496C@gid.co.uk> In-Reply-To: <5C059E86-3471-4CC8-92AC-35122B1904F8@yahoo.com>
index | next in thread | previous in thread | raw e-mail
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 4518home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1D02413E-B7DF-4604-A28E-45AA9B49496C>