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 EDCB12F2F2 for ; Sat, 26 Oct 2024 12:10:21 +0200 (CEST) Received: (qmail 30106 invoked by uid 550); 26 Oct 2024 10:10:17 -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 30068 invoked from network); 26 Oct 2024 10:10:17 -0000 Date: Sat, 26 Oct 2024 12:10:07 +0200 From: Robert Clausecker 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: Subject: Re: [musl] Prototypes without implementations Am Sat, Oct 26, 2024 at 01:21:23AM +0000 schrieb Laurent Bercot: > > I think ENOSYS is probably the way to go, especially since (via the > > kernel) that's already happening on some architectures. > > Note that providing ENOSYS implementations makes cross-compiling harder. > > When the libc provides no implementation, a sysdep test can compile > and link a program using the API, and conclude that the functionality > doesn't exist when the link fails. This works when cross-compiling. > > When the libc provides an ENOSYS implementation, the link will succeed, > and a sysdep test needs to *run* a program to check that the > functionality works correctly. This is not possible when cross-compiling. > > I'd rather have libcs omit stub implementations entirely, so that > applications can test for functionality without having to run anything. > Stub implementations make tests and integration of replacement > implementations more difficult. (And not even only for cross builds. > Looking at you, musl's utmp functions.) This entire debate happened multiple times with commercial UNIX vendors some thirty years ago, who would declare all sorts of functions in their headers and define all sort of syscalls in their libc, only to then not actually implement them (they would return ENOSYS or ENOTSUPP) or only implement them if you bought some extra option. This was almost universally agreed to be a great annoyance to authors of portable software and the consensus was to avoid this stuff as much as possible. They changed things so that e.g. if you didn't buy the inet package, you just wouldn't have the header files for inet stuff installed, making it so that software could very easily detect if the feature was available or not at build time. Please don't bring back the mistakes of the past. If a function is not present, don't declare it. Failing that, don't define it. But do not define it and then just have it fail at runtime. That's a really bad move. Yours, Robert Clausecker -- () ascii ribbon campaign - for an encoding-agnostic world /\ - against html email - against proprietary attachments