From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Re: #define __MUSL__ in features.h
Date: Thu, 15 Mar 2018 15:43:48 -0400 [thread overview]
Message-ID: <20180315194348.GN1436@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAFdMc-0Eaq+syEvdOMQk7Y6eQA7zkfn2fhxXogjkkd7c3Tas2g@mail.gmail.com>
On Thu, Mar 15, 2018 at 04:37:39PM -0300, dgutson . wrote:
> > > >> So whenever we find a bug on musl we should just stop all our
> > > >> development until you've fixed the bug?
> > > >
> > > > No. As noted above, if you need to support systems that might have bug
> > > > X, you write a test (configure-time or run-time as appropriate) to
> > > > detect bug X and handle it.
> > >
> > > Precisely, and __MUSL__ would be really useful for this.
> >
> > Absolutely not. __MUSL__ would not tell you anything about whether bug
> > X is present. It would facilitate permanently assuming "musl has bug
> > X" because you observed bug X on musl at one point in the past.
> >
>
> Then turn __MUSL__ a number holding the version, as in cplusplus, etc, so
> people can do
>
> #if __MUSL__ < someversion
> #endif
>
> and it will be clear what happens and will solve the chronology issue.
This is a never-ending FAQ tarpit. Version numbers DO NOT WORK to
indicate presence or absence of bugs, because distros will backport
fixes. Apparently you never dealt with the hell of Redhat shipping
"2.6.x" kernels that had all the bugfixes from late 3.x, and
applications trying to infer stuff from the version number. DON'T DO
THAT. If you need to know if a bug or a feature is present, TEST FOR
IT.
Rich
next prev parent reply other threads:[~2018-03-15 19:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-15 15:55 dgutson .
2018-03-15 18:39 ` Rich Felker
2018-03-15 18:48 ` Martin Galvan
2018-03-15 18:53 ` Rich Felker
2018-03-15 19:00 ` dgutson .
2018-03-15 19:13 ` dgutson .
2018-03-15 19:42 ` Rich Felker
2018-03-15 20:16 ` u-uy74
2018-03-15 20:44 ` u-uy74
2018-03-15 19:37 ` Rich Felker
2018-03-15 19:42 ` dgutson .
2018-03-15 19:02 ` Martin Galvan
2018-03-15 19:32 ` Rich Felker
2018-03-15 19:37 ` dgutson .
2018-03-15 19:43 ` Rich Felker [this message]
2018-03-15 19:52 ` dgutson .
2018-03-15 21:46 ` Szabolcs Nagy
2018-03-15 22:38 ` Rich Felker
2018-03-15 18:51 ` dgutson .
2018-03-15 21:06 ` Markus Wichmann
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=20180315194348.GN1436@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.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).