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 6208 invoked from network); 6 Sep 2022 19:20:07 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 6 Sep 2022 19:20:07 -0000 Received: (qmail 11274 invoked by uid 550); 6 Sep 2022 19:20:05 -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 10218 invoked from network); 6 Sep 2022 19:20:04 -0000 Date: Tue, 6 Sep 2022 15:19:51 -0400 From: Rich Felker To: Markus Wichmann Cc: musl@lists.openwall.com, Gabriel Ravier , Joakim Sindholt Message-ID: <20220906191950.GD9709@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220906184826.GA1649@voyager> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] ecvt(0, 0, ...) is broken 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. > Because as the OP showed, our > implementations are not behaving as some callers would expect. If they're behaving as some caller expects, and we break that caller by breaking ABI stability policy, we're in the wrong. If that caller is making assumptions about what these functions do contrary to how they were ever documented to behave, they're in the wrong. Having clear position/policy on this, *even if it's on utter junk functions that are probably not used in any real world software*, is part of what makes folks trust musl. Rich