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.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE 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 06946211FF for ; Sat, 9 Mar 2024 16:50:09 +0100 (CET) Received: (qmail 26047 invoked by uid 550); 9 Mar 2024 15:46:04 -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 Received: (qmail 26015 invoked from network); 9 Mar 2024 15:46:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709999392; bh=pvdUHhXXY58C3H/hh6chcM5PXHTleWGJXsMVQoc+cgQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vCO8lMg0rvZIl9T2G5MZS19iUrR4kp2jDXA8SczucfxoRN4+UCZ9LV0Dmj36uM0Nf zJ/Xy1B2+WTolePbpgqlA88nGFsfLfTCIWWBTFvPI/lNcFAtiYDNWLYiq2RLuNoY/r 3bTUdBD1FZCZkUxW17Lx6Douhy+TX4lv+4NVmaI4b19vgVeY3hye0ucrWK5g5IzWvw 2gzWMZ3Ft3KYgINNvVo5K11+PVA1MrpSiSOa6EvelxIaePVtPNAZkxAVFLwX/F1Z5Q yZhocYgv4Jr1bYAAt37bHQG05eozbpWr29epViz6y++ElHwoRP6FwS/A2UoQog/KUo dZyqtQNuF/n7A== Date: Sat, 9 Mar 2024 16:49:42 +0100 From: Alejandro Colomar To: Rich Felker Cc: Guillem Jover , libc-alpha@sourceware.org, musl@lists.openwall.com, libbsd@lists.freedesktop.org, "Serge E. Hallyn" , "Skyler Ferrante (RIT Student)" , Iker Pedrosa , Christian Brauner Message-ID: References: <20240309150258.GS4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="W43slqlIjtJhyMut" Content-Disposition: inline In-Reply-To: <20240309150258.GS4163@brightrain.aerifal.cx> Subject: Re: [musl] Re: Tweaking the program name for functions --W43slqlIjtJhyMut Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sat, 9 Mar 2024 16:49:42 +0100 From: Alejandro Colomar To: Rich Felker Cc: Guillem Jover , libc-alpha@sourceware.org, musl@lists.openwall.com, libbsd@lists.freedesktop.org, "Serge E. Hallyn" , "Skyler Ferrante (RIT Student)" , Iker Pedrosa , Christian Brauner Subject: Re: [musl] Re: Tweaking the program name for functions Hi Rich, On Sat, Mar 09, 2024 at 10:02:58AM -0500, Rich Felker wrote: > > How about adding setprogname(3) (and getprogname(3)) to GNU and musl > > libc? >=20 > I really don't think they meet the criteria for inclusion. They don't > have historical cross platform precedent, they're not something we've > hit existing applications failing to build for lack of, they don't let > you do anything you couldn't already do, and the semantics would be > unclear I would ask the BSD authors of the API to learn all the implications of the pair of functions. I don't know them. Maybe Guillem knows. > (do they just configure the > legacy err.h functions? Why would you call err.h legacy? What do you offer to use instead? snprintf(3) + perror(3) + exit(3)? How about bugs in such NIH cases? You'd fix them in every project where you've written the same bug? That's why we have libraries. I don't mind if the entirety of err.h was moved to a liberr standalone library, but you have kidnapped those APIs in libc. Would you release them? > set > __progname/program_invocation_short_name? modify argv[0]?) Would you promise to keep __progname/program_invocation_short_name as a way to configure err.h in musl/glibc? If so, then maybe one can write a portable library that wraps the unportable set of libc's. But since you own err.h, _you_ must be the one making a contract. It's up to you to decide which contract you want to offer. I suggest making the same contract present in the BSDs. >=20 > The entire err.h function set in musl is 67 lines that compile down to > less than 500 bytes of machine code. If there's not a portable way to > configure them the way you want, There's not a portable way to configure them, AFAIK. You could say it's glibc and musl's fault, for importing the err.h functions without importing setprogname(3). In the BSD world, where these APIs originated, they seem to be configurable portably (within BSDs). And with libbsd, you can get relative portability to other systems. You have a problem when you want to call these functions in a core package, like shadow, because some distributions refuse to include libbsd in their core packages. > and you refuse to run a configure > script of some sort to determine if the setprogname function some > systems need exists, the simpler solution, I don't refuse to do that, but it means I also need to write code to handle the case where it's not available, and do some non-portable stuff in that case. In fact, I'll need to do that anyway, at least for some years until all systems I care about have a version of libc that has the functions. But, I'd like to be able to remove that code in, say, 5 or 10 years from now. > rather than trying to get > new contracts into libc and wait for them to be widely available, is > to copy-and-paste those 67 lines and customize them as needed in your > program, no? I partially agree with you, in that I don't like adding new contracts into libc. But that contract was already added broken into glibc and musl. I suggest you remove err.h from libc, and let a standalone library to implement them separately, allowing to configure them. I don't agree with your suggestion of going the NIH way. Maybe I'll push a bit harder for inclusion of libbsd in distributions. Then it'll be the problem of distributors to either package libbsd, or do a lot of work to patch projects to not rely on libbsd. It's not a bad idea, actually. >=20 > Rich Have a lovely day! Alex --=20 --W43slqlIjtJhyMut Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmXshRYACgkQnowa+77/ 2zJkWg/8DMtYAHJfz0zYOCKZyJ53sxXO/TRYNb2u4TQtBvNFbJ+5hWmMLskP1Noe lDHPefz7pZqIk9RAiPB+n3WBYHyKolZeC5+Ct8iQaZyTRpDGQi4N0KWc4NrhShm5 UKhlHfVUnw5eoGRRBcW9yQOjuuprLVDuq7OdiyR5ctdeVNr63vD1Pm8vkC8i5VAX +Uj7WqnTQvrv2T/Jjfo8CRDTXOUhVfFjBI1ohKjo+lVnCffGqOkDDJYwLfbC27Do sEJm+KBvtEBjNQsbhNbMQfpiQnLg82SFZKgBy7UKAyxPLaR+DZ8zOca2oML9uhKO vjjdKz24MdyKm19Ihvh04jXU80SSRfKUr6RjZuh4slAYjlF2n5S+7RUjFuVxajJB ziBTp0tJALY6qYUc7kV+wjmhr5yJgB9a8MsYCnxtivgIAB07uoeOMSQ8SUK1No5Q 4vUG36f7NMTWzByQ6mJgMiaSJ32znQidKvZTFMWNFMZVyL8Sf9qLW1+kVWMt4pdx b/8hpkdqWEYF30MvsSHn2WiiNmt8mWR4PsUXS2VOFtSA50ll4LE4ecaXwbwU7rTt cfgYBkXGTmgU9AiqY/2swLwd7TCvKl7picsShQmKtk0hMqrOuuQGd/csjV/CZO6n 51ZPuitdnGbGOcSZ/9CAGz0FGL2zgQQeyZp/R+fn1uYt/dQwIJM= =q50d -----END PGP SIGNATURE----- --W43slqlIjtJhyMut--