From nobody Sat Sep 13 01:29:34 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 4cNty81TXDz67Pjb for ; Sat, 13 Sep 2025 01:29:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cNty62BlSz46mw for ; Sat, 13 Sep 2025 01:29:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=aOXJU84F; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1757726987; bh=kZAbqQ6fhrngxRzqo9E3oQzDqFFxYTs0F611OFyojlk=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=aOXJU84FlhscQsAigNyqTkmUUYlfSaTM7NuZuPsGYFObCNdLI5PkaOjCaxkVvu+g2BPQF2uPsJzrPadZAYd5aRDVSZdUvGDrMoyDmpuMA5TRS1eThC1l2zgLIjIrP6KszLrzXS0YnnwOu3iyEgeSA2WIZDN+9zg8luwATyeqYJ4s8l4xDrketU+6K9npQAcu2DvNj11MQCGCKerJamWI8q+omvbiP8PydGzl9AIJOFF58yUt1DVdnoYL4VqlXqryr7Bb7B00QTfNeIdcZvQNt3kdpuLblpMqXtlb3zhRjaurOP3uYHCWI4xDWmclQuMQfxBUU3HY8MsArLhUYnxJTQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1757726987; bh=1XemUfeMek1fVzy0WVm614J1qrg8tlrBUJGjKfi5h6L=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=IhT6pR87hUzrDtHaHxi6+nfYctB7aARX0M3563jlpHuqxqXtOIzwR9hCVMBCjJMl6yG+80h1tvNne93OuAm6dJo5k1Ari0UbZZ1rPZ+0nH5eoWtKfSg6gyzo0JY9GZomnL+1tw3aRVO25SmNbY28anTX3snQxCxr9KyQwhmmJ/iddulUYo0pV3wEPy6nV+/5Hwljl9FbaqYFMqXjp+mOYpeVPlH8jpVPCJuJ+DErZXGHGRlSmohqfUM+TDyG+8i1FoUJtRtKWwcn8e1RSuvkmMs/H+b31ChyxcdldHQH/hVNnuEHFW+YA7w71KYukAqQBFSjI8nKhJxKnoykSv82MA== X-YMail-OSG: 8dAqvQUVM1ndJIU54p0_pwtb5ttchYL0Ed1d6akLhOoSzyLDRZkHSUP7nNuTkXe 3bHCm0lrqWkUOv9TyPzdYQ2.qLMULFhvG04bwBbemlo1LzWdlv60jMKDYzZJ98s9Mz4wLTt2_eph 4EkdI8Za_eSd_Atqx66T88yMjt9YZzb5vEYyTi6WydkXHk9tjtKWK6W4q9r.fsSJvfmvAd3wZwx7 vXTBaqxRY5OE.SNCdc2RDza.J9lemfATthiz7h5wHLHBUXgsDrNPHnCJBAlS0pJj0ETNtld_mQeT JNclxRW0sKDSoTB_cWX5U5yVylQlLwORjBKJd8Q2u5lucJtw3HLlo6BoqsGIMbUrO1lAqwdMdMVB mfrf9rt_SWGynXFRFSYigJSVAHNgUwVINbasr73pY5n9R0zVYfBeoJgQ0ilbS2Wfx3CDdrbTF9Fl AXvfYJVFpHDpQsJQy2hhCjjTkE2nRWisOPUyOkGvgiYl4h1C7yKZUN5NA.ifXxoGe3qwUKUTq03j CFjvslHCmvSJfq_vOhFhX84nW7ERgzBarcDhR.huY3p8UQcSUL.yhTWsqwqPTWJ0F7Ocljp2CwLj VqT8NDFQNs6MZfj9ulBHsz4XAW8ltTBBfMXui0C_XC0fSyyQqEURtm8AB1MPIyE1wu6unnXojB4U Xp7KU38zxpWGSL1I8i0TxsfHOcdkVcNWqK__.He3.OIo55GYfYmfM78C3_XppS2MqlTXTwKX0qlA R_tRqn2ikIzEt4xRa5VdLuV8xIycBgOjICrtRutdgMnvhUkZShmQ.Actd747GcIcTw..2GqxL.kl 6aUy0H9OKaMXHanT5bxa7J7pA0Le5TsXP9FtfS6HiPJ.mk7mhHfHVtcUr8OCtC9rnLzWVl5N78ps ixOcWp_bYG.Axpqg5ZUhj91zCMADc5kCJ7KDsNybFSz64PLiObw0D.p49lfDO_X8kRwirRXfcFLA gnIDBie6.Ygl52GmF2bGEFamNuP3tkEu3aKr_mXwJERzk_pwdKEXsaaTEFFQyWxgseorIaDQoYeO AmrzTw.EgY.TcIZeSHDjE.2dnxaFcMr3DkOEpUK17qthbbbRpcIHMVBY6oWBHLazVLGHG1_Mur9y nYtA62KZbkras7t_psuciDy1EJz3fvWA_miIUKqXQDcmSnnpnGzUR4MdloCnWUqSLEfF6.mmNOU4 87mMQTsG8P9eYvg164LpDj4_JDhlfJ.ZUWaXitluJ49fz1Skq7jNg_iHROL6rveOaUWksP8OHSJU ixviZqLz9smGnt3yz1RxxN0sfenzLE4sWPwQUBEeraY08vASXu4vsi2E7sIVtCVWzeP6aJiZTxtd IU1Stt1gZ.pn5TE.KrCVeHc4xdszHNl3gg9aZ_r6mjucBCjsi4nH6UTFz2ZSfoptoc7cxTrNNYk3 A4k.kxHbg_Q3IFjnMvvxTpUpjOvytNHO9RyYXxY0.Ow9KjMKF.7QUCakekzxd8bj2Utp28HufNsU 8rwxdvnZHOIE0FFi0VvHWiL4gTqqgnt7RMRAdwdKxZtvfSrbMcElcUKGghwvNyi0kkdoFe3dWFYl 49Z6WPBVwJEnxF5tgK.UoPbHdCDgFsr.xAp4G9Sh8u9_zedbrMQyn01_kSEBdk2kFKWli3PLFS92 CLEu340aq8cvU3y1YaB.UU6QvvXy5X4fCokOsBrA.uE_g5NIaqsJR94hj7SjRVgxo3iicRSTHBeS uUNfEfhnHFHU3uGo9pAOB0JyOboR2GeapKjGwswpxwA.Tz222Vk6MOoIV5ciRw3hKnsEZqiO2pDm KCY4mQtzl48aJ0XGjgVOJciVGFrxbpabLB56IKrKBWBvzrMrGAxI4xXzCCc0BZ6QBFJDw9jb7d14 5F74KcfBioUBUVM48IQApTYyx42A974XAkzY6E2UKC3e.b3S8Uc_0guNyDNWG1y83eozYnp6WGxR qIu57lvHT2B2HnvFQMzqNFA1ct8G9eOHsURq60sbM0IOgLexB.ahWJustWsh8tYUn23LSuwd1.4N 7b5.iRLRb_pCAwSJ0DunMHkkMxCswvZvneO9QmNKcs_fDQrznfuUifmu0FdWoXmF9Bz91SyYoAfe yRySC2yz801k0MPLNJ76Z0qv47dcd5g6InxF32M1ntHjXPUZxEMCaNgmlkis2y77Oj9jFUYKGZx0 CO20YrNPkZnK.BLJpo.Wsi7FwIU1OxVak_sc0HN8Tm98jhvgsETOc9msd_il8qHUwkZ4ERw0n3je Edt4eQnRpIVaCKtaY1tS4kSfB9Q2bYV4- X-Sonic-MF: X-Sonic-ID: dd7b30e4-0230-496a-81d6-d8a1b729e245 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 13 Sep 2025 01:29:47 +0000 Received: by hermes--production-gq1-7bfc77444d-7l9vb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e592922285ca16f9dae88868fbf5831d; Sat, 13 Sep 2025 01:29:45 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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] Message-Id: <5C059E86-3471-4CC8-92AC-35122B1904F8@yahoo.com> Date: Fri, 12 Sep 2025 18:29:34 -0700 To: rb@gid.co.uk, FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: <5C059E86-3471-4CC8-92AC-35122B1904F8.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.91 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.909]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from] X-Rspamd-Queue-Id: 4cNty62BlSz46mw 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=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, 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. >=20 > 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: =E2=80=A2 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." =3D=3D=3D Mark Millard marklmi at yahoo.com