[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220906191950.GD9709@brightrain.aerifal.cx>
Date: Tue, 6 Sep 2022 15:19:51 -0400
From: Rich Felker <dalias@...c.org>
To: Markus Wichmann <nullplan@....net>
Cc: musl@...ts.openwall.com, Gabriel Ravier <gabravier@...il.com>,
Joakim Sindholt <opensource@...sha.com>
Subject: Re: 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
