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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,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 5114 invoked from network); 7 Sep 2022 03:52:03 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Sep 2022 03:52:03 -0000 Received: (qmail 26436 invoked by uid 550); 7 Sep 2022 03:51:59 -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 26404 invoked from network); 7 Sep 2022 03:51:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=57dedkkPDAIfcCNPweSXy8z0QUeyJU/N5lKmek4Xmk0=; b=jVS1zA2IePDY4K6u9e/hklzexiSM1EtnXOzPynm6kOGJnbqRtoVM7iWkQo4ZNARpM0 45m6Hvlv+z495UNz58b6q7xythKU87GG9GkG9QsCb6ObLdxfmo/PuhLhqIiMXVdg97Q8 S4vT6pln4X729b1JxkNouMkbtysF1qFhMRmpSOtHzBbJvRmwVN/Q7V9fhtJkrXFcZsXa jklajZ4HADHNbCdCEoo++3KLhM3r8w2GRuoIt/ADVsCcQ3lZRX3I5vhJsOYyXgvKLh2L 3No0fGoiWApe70/FUTippiTgAeeXSxrjca5w/Ntbs+XC92S+FeWasx1c/Iz9aqeuW2I8 8mbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=57dedkkPDAIfcCNPweSXy8z0QUeyJU/N5lKmek4Xmk0=; b=mb/dIzDK0WscAcuOrn410X6vF2dmOPsBPlCjnRfLEepxn47rvlAn3IRfEm/9TOSBAz MYIFJks3Le50FUgSQUs82h3oBnSfpwZEpt1znk5lwKaNl+977jWTD6vp480fCbgreEHu l/Sn6hsPLjuvjxZKjfWfatVFoJ8OViMnssAzj3g3an0pTcZv8Efyf6ZJ2jBIGNrufQ7F wdQOU9Xnllzs0YlKzLA94YAmNIYuI4tOBBIMVJGJc+hjWr5xcnQCFs6/B2N4TIW6KQMu c1h1hvHiqX31/rFpSczA9LgSsJ+O8TddrcHasmto+m24m+PA25yG3MKkDaCtmqmY265J xySA== X-Gm-Message-State: ACgBeo1tr2tM7xsoXbP0nHYo/2EWNSS/mLnHOHu7iTP+2pBHjzHQPJbJ Gd3e3w1VnkZ6pUBg4jhvXOIJjf7suFo0ekf/uLIdIvo0 X-Google-Smtp-Source: AA6agR738mgubUhs5OSHvHAGLWYMPti7lMFei5JOrdm3xaRvpzuwIidtdNYJRjFVqOJ0Jsz+4UwHRoCvRn9xO2k26As= X-Received: by 2002:a17:903:26d4:b0:176:d22a:19b6 with SMTP id jg20-20020a17090326d400b00176d22a19b6mr1765167plb.137.1662522706583; Tue, 06 Sep 2022 20:51:46 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <20220907033924.GB1649@voyager> From: Jeffrey Walton Date: Tue, 6 Sep 2022 23:51:35 -0400 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] ecvt(0, 0, ...) is broken 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. Recommend the distros build with the option. 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. Jeff