From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id A40E62B613 for ; Sat, 26 Oct 2024 15:22:41 +0200 (CEST) Received: (qmail 32590 invoked by uid 550); 26 Oct 2024 13:22:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com x-ms-reactions: disallow Received: (qmail 32552 invoked from network); 26 Oct 2024 13:22:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1729948947; x=1730553747; i=nullplan@gmx.net; bh=OsBN/jivqDq8xM8hVp2UIpituY4KKGMypQGTrkRxhjA=; h=X-UI-Sender-Class:Date:From:To:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To:Content-Transfer-Encoding: cc:content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=skDbIaI4c82TP3y89LrE6F2DXSkO4DbUSbqD1+jHQlgsnRt4ZTDyStRxMyyJtKg5 9Gbq3Z9rx7b5Uisb8i4fAE3iZm67fFLwE/uTHIlEawsN3ERpwY5KuY9+QqN9o1AhH V9C5I21tCxu0whe9uhdCqjZoe4Apdc63q2c29OETIK5kOu+jdSdb7Vg1VUZ9Ysm1x qPX6uscqEJV7ctgN0NjGI3oE1CUy8R0Q9rPTlOlSDJhxDTv8V4P3JKfjqzPike8G2 uP7TMQiTZN45Z5ltlwUgBc8pOpSVmbH+5tfogTv6Haljl4Pv7l4mAQUAPBkZqFNfU s30rzsPAwQOm8YxbZA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Sat, 26 Oct 2024 15:22:25 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: References: <878quc7xzy.fsf@alyssa.is> <20241025201011.GY10433@brightrain.aerifal.cx> <874j4zoob8.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:df2x26YqC1CV3hdE32v46YRuMtpJs3TpgOEkadllRN02V9vvcyB SXno3oVhYveVQzMRsPV2NSinTwnVkF6h8iHfDuKko4LrkgQ7S51wwQ5FxHBfu7pgP6fnj35 T3xL0oBfdlRNtLRCwkcIf4ywC2MVxE0I5qrSxHY6/K6kpLZwBoMhR3kq38A13mDA9m2BsXF oZ3Rz89KKWnJeUjqknDUQ== UI-OutboundReport: notjunk:1;M01:P0:w4VvYy/yQtU=;/g0rxFs0K7DcQX+3BJIbgJ1rBtK CHtNUy6LKDx7fs4zKUtwQpoZME5k0sRXhZ3TP/03Ba5f7JuBKT0ZybrkbnMKW8H4Ut4rxuu59 RwSkCGW5gpKLoXsSOrWG8KE4/rmS26dmTin7vqyPLDCVhFKGW4vtDMYk68sKS+6FxNLqxw4Zu p7E34CRw4Ks4sHa/wwD9E6v3gc0DY5JbmeOR4hyI78wW1ahPtyMONVargf0JBaMtgUx1LP+ny 4TCxHekuf3wRugpJPtaZ1EjztcH4jhqC6pWuxmtScV54/a6VPfl4dxTzxZ+qjFdYLF2NDSyep zZ+G2F6L7toP9mVM8O2ZUdcd3SLe4g/ZV6suhBp4bTunTaS+oggpLdyoK7A/L+0/9le1o1q7B 5AfI80F2Ye/PrTS/ksUCPNXIlBuJKXvIF4mIjv9cqh7A0PAFXnqDutA6H63xz93vJjXMB0fMV GYzzs1W61qFJ2Q9XK5UkmuGH4BC6m7bI6TCTDZ+rAfupljWC8Jgvy/EIZMS7slNu/R0q+uKF1 a5qRzeM4poKZRG86JXOQAxULrdz/L2iHq8xueWvijCOBXkiKls4gdYhXaMkhbWinDByFKe4B3 IeGALTXEBmxRErfeZluUbus4GFl6XYoVcq9wYiNTbLkZF8olooTTMUnN9SS2I8AOXJD/K59Zv ys5SR2nnFCTaZ0K1XPuAriizqluBt+Hb3u7S5vHSS0auHVWkPdgn0nqjqX6WfJyiBGfRF2Tc2 e7f0MaC0fThF7hHqOVUxdJIy/FZsNM3sSAL/NO37EFKMcW1hPj0szkZmLoaKEALIj9J+wwcdQ IbBfHiR/tTDwvaERZtlTROzQ== Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Prototypes without implementations Am Sat, Oct 26, 2024 at 10:28:38AM +0000 schrieb Laurent Bercot: > Who's "we"? Me and my sockpuppet. I was under the impression that this is the general consensus among regulars on this list, as it shone through on past discussions, but maybe I'm mistaken. > > Just because a > > function exists in the lib does not mean it will succeed at run-time. > > This is already the case with functions like getrandom() or pselect(). > > getrandom() is part of the problem, yes - a function that you cannot > test for at link time and that you have to make depend on a kernel > version in order to use. But because the problem already exists doesn't > mean it's a good idea to add to it. > You call the function, and if it fails, you fall back to another method (which includes attempting to seed a PRNG with getauxval(AT_RANDOM) or trying to open /dev/urandom or the like). Does it matter if it fails because the kernel is too old or just having a bad day? I would never check the kernel version before just calling the kernel interface. > pselect() is posix, it has a specification. If your pselect() isn't > doing what it's supposed to, then your implementation is nonconformant. Failing with ENOSYS and no side effects and no wait time is conformant as well. In the case of pselect(), it is probably the better behavior of libc as well if the kernel doesn't provide the necessary syscall, because the workaround if pselect() doesn't exist is so invasive. Indeed, if you have an application that can deal with pselect() not being available, you likely have an application that doesn't need pselect() at all. (The workaround could be the self-pipe trick, which obviates the need for pselect() completely). > > Even if you could run run-time tests, just because it succeeds at > > configure time does not mean it succeeds at any later date. And > > conversely, just because it fails at configure time does not mean it > > cannot succeed. > > The point isn't to test for "success" or "failure" (unless you've > found a solution to the halting problem, in which case I'm definitely > interested). The halting problem is precisely the reason why run-time tests are a bad idea even not cross-compiling. If the function under test fails with ENOSYS, you still have no idea if that is because of a stubbed out implementation. > The point is to have a decent heuristic for whether a > given function, identified by its name and signature, exists in your > system and has a reasonable chance of doing what you think it will do. See above. Failing with ENOSYS and no side effects is a perfectly conforming implementation of most POSIX functions. > Is it perfect? No. Do we have a better way of writing portable software > that does not involve starting every single executable with a battery > of tests? Also no. > If your binary links against musl, it does do precisely those tests. Not necessarily at the start of the runtime, but inside many functions, and in many of those never saves the state about what is or is not possible in the run-time kernel, so the tests are re-run everytime the function is called. I am talking about things such as all of the socket functions on socketcall architectures attempting to do the newer syscall directly and falling back to the socketcall mechanism if that fails. Or clock_gettime(), if it cannot be implemented in VDSO, trying first the 64-bit syscall, then the 32-bit one. To me, not much difference exists between a function failing with ENOSYS and it failing for any other reason. In the end, you still simply have a function failure at run-time and need to cope with it. And it could start working at any point in the future. Maybe not in the same process lifetime, but maybe in another one. > > Writing your software in the above manner is therefore > > not sensible. > > Every single project using a configure script such as one created by > GNU autoconf, or a build system generator such as cmake or meson, is > therefore not sensible. That's fair, but maybe we should still try to > avoid breaking them? > It is possible, though not effortless, to write sensible software using any of the aforementioned build systems. I have done so with cmake at least. It does require a shift in perspective, though, to not assuming a function will be successful just because it exists. Ciao, Markus