From: Rich Felker <dalias@libc.org>
To: Markus Wichmann <nullplan@gmx.net>
Cc: musl@lists.openwall.com, Gabriel Ravier <gabravier@gmail.com>,
Joakim Sindholt <opensource@zhasha.com>
Subject: Re: [musl] ecvt(0, 0, ...) is broken
Date: Tue, 6 Sep 2022 15:19:51 -0400 [thread overview]
Message-ID: <20220906191950.GD9709@brightrain.aerifal.cx> (raw)
In-Reply-To: <20220906184826.GA1649@voyager>
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
next prev parent reply other threads:[~2022-09-06 19:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-06 9:27 [musl] Bug report: fcvt seems dysfunctional Gabriel Ravier
2022-09-06 10:12 ` [musl] ecvt(0, 0, ...) is broken Gabriel Ravier
2022-09-06 12:13 ` Joakim Sindholt
2022-09-06 12:21 ` Gabriel Ravier
2022-09-06 14:17 ` Rich Felker
2022-09-06 18:48 ` Markus Wichmann
2022-09-06 19:19 ` Rich Felker [this message]
2022-09-07 3:39 ` Markus Wichmann
2022-09-07 3:51 ` Jeffrey Walton
2022-09-07 13:44 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220906191950.GD9709@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=gabravier@gmail.com \
--cc=musl@lists.openwall.com \
--cc=nullplan@gmx.net \
--cc=opensource@zhasha.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).