From nobody Sat Sep 13 17:20:28 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cPJ3R473Nz67G8h for ; Sat, 13 Sep 2025 17:20:51 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gid2.gid.co.uk (ns0.gid.co.uk [IPv6:2001:470:94de::240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gid2.gid.co.uk", Issuer "gid2.gid.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cPJ3R1T66z41W8 for ; Sat, 13 Sep 2025 17:20:51 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; none Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by gid2.gid.co.uk (8.15.2/8.15.2) with ESMTP id 58DHKivs019760; Sat, 13 Sep 2025 18:20:44 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from smtpclient.apple ([194.32.164.24]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 58DHKcik073246; Sat, 13 Sep 2025 18:20:38 +0100 (BST) (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: git: d549de769055 - main - libc: Remove readdir_r(3) [This broke building rust 1.88] From: rb@gid.co.uk In-Reply-To: <5C059E86-3471-4CC8-92AC-35122B1904F8@yahoo.com> Date: Sat, 13 Sep 2025 18:20:28 +0100 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <1D02413E-B7DF-4604-A28E-45AA9B49496C@gid.co.uk> References: <5C059E86-3471-4CC8-92AC-35122B1904F8.ref@yahoo.com> <5C059E86-3471-4CC8-92AC-35122B1904F8@yahoo.com> To: Mark Millard X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cPJ3R1T66z41W8 Hi, > On 13 Sep 2025, at 02:29, Mark Millard wrote: >=20 > rb_at_gid.co.uk wrote on: > Date: Fri, 12 Sep 2025 19:09:33 UTC : >=20 >>> On 12 Sep 2025, at 11:59, Dag-Erling Sm=C3=B8rgrav = wrote: >>>=20 >>> Bob Bishop writes: >>>> And while I=E2=80=99m here, POSIX.1 defines for readdir_r (and = readdir): >>>>=20 >>>> [EOVERFLOW] >>>> One of the values in the structure to be returned cannot be = represented correctly. >>>>=20 >>>> =E2=80=A6which I think would cover the case of indeterminate = NAME_MAX/PATH_MAX for readdir_r. >>>=20 >>> No, because readdir_r() has no way of knowing the size of the buffer >>> that was passed to it. >>=20 >> It doesn=E2=80=99t need to know. >>=20 >> If NAME_MAX is defined, >=20 > What I get looking at the 2024 POSIX text for this area . . . >=20 > "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()]. >=20 > 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 =E2=80=9CIf pathconf() gives a = defined value for NAME_MAX..."=20 >> the user must supply an adequately sized buffer (based on NAME_MAX) = or shoot themselves in the foot. >>=20 >> If NAME_MAX is indefinite, readdir_r() returns EOVERFLOW immediately. =E2=80=A6and 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: >=20 > =E2=80=A2 The [EOVERFLOW] mandatory error condition is added. This = change is to support large files. >=20 > and: >=20 > [EOVERFLOW] One of the values in the structure to be returned cannot = be represented correctly. >=20 > 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.) >=20 > For reference: >=20 > long fpathconf(int fildes, int name); > long pathconf(const char *path, int name); >=20 > 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. >=20 > Related Rationale text about the obsolescent status: >=20 > "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." >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 -- Bob Bishop t: +44 (0)118 940 1243 rb@gid.co.uk m: +44 (0)783 626 4518