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=-3.0 required=5.0 tests=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 97DF4232BD for ; Sat, 26 Oct 2024 12:28:52 +0200 (CEST) Received: (qmail 5190 invoked by uid 550); 26 Oct 2024 10:28:48 -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 5152 invoked from network); 26 Oct 2024 10:28:48 -0000 From: "Laurent Bercot" To: musl@lists.openwall.com Date: Sat, 26 Oct 2024 10:28:38 +0000 Message-Id: In-Reply-To: References: <878quc7xzy.fsf@alyssa.is> <20241025201011.GY10433@brightrain.aerifal.cx> <874j4zoob8.fsf@alyssa.is> User-Agent: eM_Client/10.0.3530.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re[2]: [musl] Prototypes without implementations >I don't understand the remainder of the thread as it is now, because >normally we consider the above behavior to be insanity. Who's "we"? > 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. pselect() is posix, it has a specification. If your pselect() isn't doing what it's supposed to, then your implementation is nonconformant. Yes, nonconformant systems are ubiquitous too, that's a problem too, and that's why we test stuff, but standards are still a good thing. strlen() works everywhere and you don't need to test for it. (Yes, it's a low bar. And it's not true for strnlen(). Don't get me started.) >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 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. 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. > 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? > Especially since the functions talked about here are >system calls that on some architectures have been stubbed out in the >kernel, so the run-time behavior depends on run-time kernel version. That's why, unfortunately, some functionality has to be documented as depending on a run-time kernel version. It would be nice if we could minimize the occurrences of having to document a dependency to a run- time libc version, too. -- Laurent