[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180315194348.GN1436@brightrain.aerifal.cx>
Date: Thu, 15 Mar 2018 15:43:48 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Re: #define __MUSL__ in features.h
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
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.
