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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3652 invoked from network); 7 Sep 2022 03:39:49 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Sep 2022 03:39:49 -0000 Received: (qmail 19671 invoked by uid 550); 7 Sep 2022 03:39:45 -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 19635 invoked from network); 7 Sep 2022 03:39:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1662521968; bh=YgBl/qPancXdYdwOs3oeLiUJY8WgNZWxoNpnTxL8Ues=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References:In-Reply-To; b=UAXxWicXussNl8TfYjvM5oc1a5u83BLvScfQTC4wX8g0BjQtkRfUFE1KYDa1DOrVO YvZAdegaNz20ATmuKIQ0YLZgL4FXEw/O+orDdVZ7mlgNoWtVOc5GhQf5VtlzzGqmd8 CNg7Mxm2cIRSEorPFLme4z2ezmUyN70xQQi0YOIM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Wed, 7 Sep 2022 05:39:24 +0200 From: Markus Wichmann To: musl@lists.openwall.com Cc: Gabriel Ravier , Joakim Sindholt Message-ID: <20220907033924.GB1649@voyager> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220906191950.GD9709@brightrain.aerifal.cx> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:PSp44Uinv5vvvejdjPTlodsHPgE1j5s1JJVRTLQ+WGD3T3ZoUmf nAfWDWvVIxptWK7pIhkLQpauAJ8vOmeemrtA9poAtWTp3kZjlunEw5wv5bBAtbWpe1mO6MN jpH00K1ODTfKPM5RDjjf6oSWyncl87K/fB6POpR56H8JD5QBRVM+OY/Ke1XxYEwhN8vu6gq 9Ziw+94k0mFtfusKkR71Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:soxWObVXWUE=:HAo1kjkDYio6VvSigbrCRT h7e+P8DUjLMbgJMGW/t/qj1MVEE39BzyXzriOH0kvfd+SHUuFxILz54Qm26gLdxpl9iVyeK9K Ymfscewl8Y1JUByYn/u3jMNdp+gChafOxJLTOipMgQetFnFhT3kmGdzOiPbVyA72eMlE4iw9X u1OZbY9NX0kSFwoYViOgS4fMVeJup8uUVbxD6brQ7bToWFUAUzA1S3kA4sD+fAcJgmE3twbx/ yUisjFZ3W4OfDJlihbzgXpUHBjMxKpKLZoqcHu/4Q8gvkNk2jIaZNSMQ5/L3iZzFHp/PgP402 10V6Kbpw8sMe1DZpOTZosc4RzpSt28wsFDeEgxWxVZ6hDdTXZ0r7m7FE9xfsP8usg/l7V1XFy Q6lPcPOD0whw/HtjZ+OM1N4fDnqOxV6gFl7T/+X6MoR1sgQ7DoV2sCMw8pw0K0K5jxxi3/zMt 2U6db1pv/W6GjlYYZm7rBt3qwl4+YJdh7Cdofz20uJQDc5UZgkF8DZukqQZVD7b3Gn8TDWqQp yeHtwFeTIgthnon5HvgJtz7WhgKbyfWV2Gu2MTyzy4duxMINAwQy72h3sD0coD1P12RHCKGQn KNwuHp9Ptq01+Qv2707yhXZmLev5oYh4w8gJ2baGRORpBSmVg5v/YO1L4vOIo9aaOsQlxDiOx e1o2QP8GN81Eg2BVafG9xXBS+TjbfdkeEhEiwXnORTI9P0uHj2jIt0LvPoHfFXMxtCggkJ4Kp CPfTwCkQnhfsnGAiHEqzHrC9strFvL+Bn5WDYyj0m7cn8qQFfJimiAYLXbGo+FDq6Av84yHfQ Sr/zswsTanfFQmwwjtWKVZyosjI1cGfuAHQOHuIInXG79wgxEMupMzC3WjWQMxK7gvL4cReRv cuoN+755HkfFUPj41DUF0XAkqr9TpjhF7uWXpePKKWSOxNrw8pB5WSocjSIku32rkjPWYR/Qf w174bjhT5MKhQs8S5/AQUhLAAoj6MAxFHapYt571iL4xZM6YMrbPTZXKj4EwF6w5nTy3Ysq5U t6XppscKfBC2PQ0OPoe+5oHemJRunZYDFGMyRye5kWACyi4pc+gvzvlXXQENTCaI/GRWuj2fL fCEsIXvVUqGJM3EDUHl/CLURG5SNwmLeahZml5rVUlWmOLz7tiMjrTDdD7M9UBwGopEg48eyN XWBkLHLCZqZiNNITolZ4ElJMLH Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] ecvt(0, 0, ...) is broken 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 mo= ve > > > 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 b= e > > retained and an error attribute be added. Configure tests would fail t= o > > 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. Ciao, Markus