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 B65913054B for ; Sun, 27 Oct 2024 01:35:20 +0200 (CEST) Received: (qmail 15839 invoked by uid 550); 26 Oct 2024 23:35:15 -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 15795 invoked from network); 26 Oct 2024 23:35:15 -0000 From: "Laurent Bercot" To: musl@lists.openwall.com Date: Sat, 26 Oct 2024 23:35:03 +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 >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? That's exactly what I'm doing. That's why I have a C programming=20 library that everything I write depends on: to wrap these excuses for interfaces into something that an application can reasonably use. It was annoying=20 to write. And the part of the library that generates random numbers was *especially* annoying, thanks in no small part to that getrandom() behaviour. I needed 4 attempts to make it work in a satisfying way. And you're saying everyone should do that, for *every* interface=20 exposed by the system? That is putting very unreasonable expectations on application writers, and making C even harder than people like to say it is. >Failing with ENOSYS and no side effects and no wait time is conformant >as well. Yeah. You're right. And my point, shared with other people in this thread, is that it's a bad thing, and we should avoid having these stub functions wherever possible. > (The workaround could be the self-pipe trick, which >obviates the need for pselect() completely). (Using a self-pipe is also better than pselect() for other reasons: it allows you to handle signals as regular events and process them in normal execution context rather than interruption context. So indeed pselect() is never needed, and the self-pipe trick - also implementable via signalfd() on Linux - should be the regular pattern, not a workaround.) >If the function under test fails with >ENOSYS, you still have no idea if that is because of a stubbed out >implementation. Exactly. So let's not add to the list of functions that do that. >If your binary links against musl, it does do precisely those tests. Not >necessarily at the start of the runtime, but inside many functions It is a very deliberate, very conscious choice in musl, and the explicit goal is that binaries linked against musl should run on as many kernel versions as possible, independently of the kernel version musl was built with. It is a reasonable design goal for a libc to avoid tying userspace to specific kernel features. If there is ever a place to test, live,=20 whether a system call is supported, and fall back to a different system call, or sequence of, if it isn't, a libc would be that place; and I appreciate that musl goes to these lengths to ensure independence from the kernel. It is not, however, a reasonable expectation that *applications* should do so with the system they're running on. Applications should be able to rely on the system - that's why specifications exist. The ecosystem is already in bad enough shape that extensive build-time configuration (that works badly, and that nobody likes) is needed for most software; claiming that the sensible way of writing applications is run-time tests for system independence is abandoning any pretense of practicality. >It is possible, though not effortless, to write sensible software using >any of the aforementioned build systems. Kudos to you for making it work. Now you should know as well as I do=20 that between writing sensible software with effort, and writing half-baked software with less effort, most of the ecosystem, including incredibly popular projects, will choose the latter. Let's not break them even more than they already are, please. -- Laurent