From nobody Fri Sep 12 13:23:01 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 4cNZqf1sMtz67SNM for ; Fri, 12 Sep 2025 13:23:10 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cNZqf1Dtwz3pry; Fri, 12 Sep 2025 13:23:10 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757683390; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GBiGWwR+ThA/JOnLxCQl4M5+Xw8KyiBKgT2ImsMVgGU=; b=x7A9rkod9pQkE3e5O5EPEDSlHwYfPZLjMPTNRv6heLy3yzzhW6F+ZE8Qt6jkwuj4q980sA nZHCwkpVXgu3YAxyKcDVDIzmRoat/4g2Q/fQ5w8EJPklDuRjKMf6z4u2hf9ObpRJFrrvEq PF7Lg+lBD8SwpPmykrX/QYCBd//CExEBMcNksaK48GaFLK/vfEsKA3/VwztsDHhLYqkf4k iRK+zaqH+zX7GsZqHU6mYkq03gGsCmBUWeOZzb7Ga46GSpGUW9BtSZYb3Taw5QMR7koBQM rf/g4HGc8teAzfgh4s+QMKLBOUIXqr3vknQ6x5jJQxH7RYCEMLljROusHXYoOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757683390; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GBiGWwR+ThA/JOnLxCQl4M5+Xw8KyiBKgT2ImsMVgGU=; b=pnmibDIOhuCWsgh4AP/OeoAsE6MOmvauQodVXNNtlQORBXwWa6NgX5jPqD9j3biXqez+po SNdy9Ix01BBzt7kalxC12nnz0yv0AzCIXrxeM0WZwrsCCxFh7odL0Upv7b4ZxtfZsqtiqK 4Du7YkL83ptAH1AcVyrgRB/Cssq7Ccel0RJNw5WUnV7Oif9NpNBD7wemLukz7o5PtGw1RX elxOI/FheP5+u0UOnaHBh5gAVnpvz/rxeHTAlh2oyViigKqdfIXDaOx9MBAFOj2IEfT/C7 /CtbHALQQkZ4ctpDpngmRz795dkSdDg4lT8hqA/Ecqs/tlnM6MXGWLHWXtouVw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1757683390; a=rsa-sha256; cv=none; b=ZC9ntb0Vqs1VGsxQNGY32HGLr0g+NU+8smqM5P4TnMk/iCCVqCrYKPF1fiZnygu6kv9yHm XchltgwpJP2UrliS6/Z/buSEAuyuPDU3MYJrwoiw8IXm3THSEhTPHwDDOPedafFZ7d7eRi PViqGmpvlPAD/ziIOpEaIFDmDrNeoLKoD+TtsXfzCNBBimurGkDpgKaC6f52PfhaSl9tjR K+mMVunp6VIHU5FeLG2cvttlbIVj5HmB+Nh0onNuRopALWPA18tqlwGJBNhXq7jMVEYc0W 0yQX1GDPMCrQUSpvE4yuvgZTzyGemUe8h2ELxNp212k/a8aiJ9narFQ7uvqbWw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cNZqc6CV7zlt1; Fri, 12 Sep 2025 13:23:08 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= Cc: Bob Bishop , FreeBSD Current , Alan Somers , Toomas Soome Subject: Re: git: d549de769055 - main - libc: Remove readdir_r(3) [This broke building rust 1.88] Date: Fri, 12 Sep 2025 15:23:01 +0200 Message-ID: <5035133.Cjmsv3J8Qz@ravel> In-Reply-To: <86ms6zhmbq.fsf@ltc.des.dev> References: <1F6A4621-1505-4F78-97C6-85EA556B2165.ref@yahoo.com> <6053312.Zv9zXsTiuT@ravel> <86ms6zhmbq.fsf@ltc.des.dev> 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 Content-Type: multipart/signed; boundary="nextPart1955372.vR5SVPPSqJ"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart1955372.vR5SVPPSqJ Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Olivier Certner To: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= Date: Fri, 12 Sep 2025 15:23:01 +0200 Message-ID: <5035133.Cjmsv3J8Qz@ravel> In-Reply-To: <86ms6zhmbq.fsf@ltc.des.dev> MIME-Version: 1.0 > readdir_r() should never have existed. Sure, but it exists. > (snip) > but usually the size of the buffer is well-defined. That is not the > case for readdir_r(). Callers have to check in advance by calling > pathconf() or fpathconf() not just once at startup but _for every > directory they open_. The size of the buffer is actually well-defined (on systems where {NAME_MAX} is not indeterminate, that is), but it is indeed not static. That's cumbersome, but also has been documented from the start, in the standard and in our manual page at least. Though I would bet that most programs calling it do not do the proper dance. You certainly have a point here. > * Because unionfs exists, it is possible for pathconf() to return the > wrong value. If you union-mount a directory with a small _PC_NAME_MAX > on top of a directory with a large _PC_NAME_MAX, fpathconf() will > return the smaller of the two values. If you size your buffer > accordingly and the lower directory has children with long names, you > will suffer a buffer overrun. Yes, that's a fundamental problem for a flexible unionfs where the upper and lower layers can be changed underneath the union view. But we have a workaround here: Simply return NAME_MAX. We could as well just decide that we will cap _PC_NAME_MAX by that of the upper layer (which implies creating directories there, which our unionfs currently always does, but may not necessarily in the future). > * People have gotten used to reflexively choosing foo_r() over foo() > when both exist. In most cases that is the correct choice, but in > this particular case readdir() is almost always completely safe to use > (the only exception is if you have multiple threads calling readdir() > with the same DIR *, which is a bad idea and easily avoided). It is > also faster than readdir_r(). I completely agree, but see these more as points to actually obsolete readdir_r(), as POSIX just did (and we did long ago). We'll eventually remove it anyway. > * The fact that Rust uses readdir_r() on FreeBSD is evidence that it > needs to die. (...) It's strange and a bit sad they were not up to their task on this. > Rust is (hopefully) going to get fixed now, but > the only way to avoid a repeat performance is to drop readdir_r(). Now that readdir_r() is "officially" obsolete, we can hope that this time people will actually comply by themselves or when we poke them to. Hopefully, we'll be able to remove readdir_r() in 16. -- Olivier Certner --nextPart1955372.vR5SVPPSqJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmjEHrUACgkQjKEwQJce JieYXhAAuGBLD06huaFK3TfIjuYKRsk7abF+bVf8M5xKRt0GrsZDTo/ClyBoxDeU zi+yP7BqEtkBH/RyxtoT8eMV8qmNdCA/RVcwJjvocpFswK5YyMAzpDa2mzt8NHP+ uOrD6GxgH1svPm32RvRQQC2YYCFwxRhGkjkPfUb0J+XUVmQSN0uGIgOtkMTiPSZP rgnf4hUfWEbMVgHMeAZMOnGNQS8g7vNuuATpSyhE8eJSuXrtLDdz1Rt7+AbE4blC f6Q3KTZRIGLjMN4o6udXXAYFeFLsIW8aBNaZrzaY04jQXWVHi7D/38BFj+RfgUhX gEkPfVpgKzMOSXalsCtfHORwxsPKOK/tphVmjzA9OqGrbAToxwndHvhbhld3UPNc 5Y6/Oy5gp3CMeUTIWbHNAxDjO3K7T6eJ731CFWXoroFv4K4zwofZbvl0pxWjxaqT c0PjH2cOOrSjGfp6buv8ie9V8QAvdnsyf0ULkH05KSRUIxSLRQrPpwJHqiRt0LX0 3+KrkwZP34FaFhwiBm5JuyimeMv2RuF+d+UtCasGdHsOL7/7P+t0glOPG+NkbZxC x4iLHQ4SJhrjq+uf2PdGZjClVL2gaMXXnRRLqtixGbl/qu4PUYqzlPmLmUPlKVgc /iR7okOIBpN+8eOMmFLUqyCCfLAyAbfafORnXcLMIv9DHe76zyk= =ZqjS -----END PGP SIGNATURE----- --nextPart1955372.vR5SVPPSqJ--