From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11091 invoked from network); 7 Sep 2022 13:44:30 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Sep 2022 13:44:30 -0000 Received: (qmail 20025 invoked by uid 550); 7 Sep 2022 13:44:25 -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 19984 invoked from network); 7 Sep 2022 13:44:25 -0000 Date: Wed, 7 Sep 2022 09:44:11 -0400 From: Rich Felker To: Jeffrey Walton Cc: musl@lists.openwall.com Message-ID: <20220907134410.GE9709@brightrain.aerifal.cx> References: <7bf9a30d-4ba8-1fe7-8c80-db99446db307@gmail.com> <6c1dfc63-b3e8-46a3-1db1-4d5bdf031086@gmail.com> <20220906141311.b8650027f3499c080f45b4fd@zhasha.com> <166c0b26-198a-91d3-08c9-ba135fc57065@gmail.com> <20220906141736.GC9709@brightrain.aerifal.cx> <20220906184826.GA1649@voyager> <20220906191950.GD9709@brightrain.aerifal.cx> <20220907033924.GB1649@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] ecvt(0, 0, ...) is broken On Tue, Sep 06, 2022 at 11:51:35PM -0400, Jeffrey Walton wrote: > On Tue, Sep 6, 2022 at 11:39 PM Markus Wichmann wrote: > > > > On Tue, Sep 06, 2022 at 03:19:51PM -0400, Rich Felker wrote: > > > On Tue, Sep 06, 2022 at 08:48:26PM +0200, Markus Wichmann wrote: > > > > On Tue, Sep 06, 2022 at 10:17:36AM -0400, Rich Felker wrote: > > > > > But these are garbage functions. The > > > > > right answer is to fix whatever is using them to use snprintf and move > > > > > on. > > > > > > > > Well, then why not remove them from the lib? Any program using them > > > > would invoke a link failure. Indeed, for GCC, the declarations could be > > > > retained and an error attribute be added. Configure tests would fail to > > > > find these functions and possibly switch on alternative paths. > > > > > > > > Of course, that is not ABI compatible. But isn't excising broken > > > > functions better than retaining them? > > > > > > If that were the case we would have removed gets, so no. > > > > > > > That would have been the next function on my hit list. > > > > Alright, next idea then: Could we put a linker warning on these > > functions to encourage users to switch? That would not break ABI, as all > > symbols are still there and the functions do what they are supposed to > > (as well as we ever implemented them, at least). But new compilations > > would get a nag to make them stop. > > > > Unfortunately, it is possible that a configure script may misinterpret > > these warnings as errors, and if it was set up to test for a function's > > existence and the function is mandatory, then that script would fail > > when previously, it would succeed. > > > > What I'm trying to get at more generally here is a mechanism for > > deprecating libc functions. Because apparently we have amassed a few > > junk functions that people should not keep using. And experience > > suggests that merely documenting this state of affairs will not change > > it, since developers only ever read documentation after things go wrong. > > Make it a configure option, like --no-xxx or --disablke-xxx. Having multiple build-time configurations with different functionality, especially different symbol sets (ABI-breaking), is something musl very intentionally does not do. > Recommend > the distros build with the option. I very much do not recommend that distros build with incompatible ABI changes. This not only makes it impossible (in general, without assumptions on what symbols it's using/not-using) to take a dynamic-linked musl binary that was not built for the particular distro and use it there, but can even break binaries the user themselves compiled *on the distro* when they perform an upgrade. There is utterly no value in doing this, and huge platform reputation destroying cost. If a distro has a policy of not wanting to build packages that use fcnv or ecnv or gets, all it takes is a recipe to check the symbol tables along with other checks they should already be doing (like checking that the package did not create suid-root files without being flagged as allowed to do so) as part of packaging a distro. This does not need an intentionally-compat-breaking libc to do it. Note that distros are very much on board with all this, and that's why we have a healthy ecosystem. For example when there are new interfaces proposed for inclusion in musl, the Alpine folks always reach out to confirm that they're actually going to be going upstream before patching them in early to support the need of some software they're trying to package. This ensures that we don't end up with ABI mismatches and a fragmented platform. > Now the problem is transferred to the distros. When a user uses a > deprecated function that's no longer supported by the standard, the > distros can decide what to do. They can help users move away from the > functions, supply patches for the deprecated functions, etc. I'm confused who the "users" are here. Distros generally deal with the bad decisions of upstream software providers, not of their users, in the course of what they do -- it's upstreams they have to convince to stop doing stuff that's deprecated or nonportable. I guess there may also be some value in pointing out to users building in-house software (that they compile themselves) on top of the distro that certain functions they're using are deprecated/bad-to-use, which could probably be achieved by some sort of warning, without breaking anything. Rich