mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Cc: Gabriel Ravier <gabravier@gmail.com>,
	Joakim Sindholt <opensource@zhasha.com>
Subject: Re: [musl] ecvt(0, 0, ...) is broken
Date: Wed, 7 Sep 2022 05:39:24 +0200	[thread overview]
Message-ID: <20220907033924.GB1649@voyager> (raw)
In-Reply-To: <20220906191950.GD9709@brightrain.aerifal.cx>

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.

Ciao,
Markus

  reply	other threads:[~2022-09-07  3:39 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
2022-09-07  3:39             ` Markus Wichmann [this message]
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=20220907033924.GB1649@voyager \
    --to=nullplan@gmx.net \
    --cc=gabravier@gmail.com \
    --cc=musl@lists.openwall.com \
    --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).