From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12625 Path: news.gmane.org!.POSTED!not-for-mail From: "dgutson ." Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: #define __MUSL__ in features.h Date: Thu, 15 Mar 2018 16:52:59 -0300 Message-ID: References: <20180315183939.GI1436@brightrain.aerifal.cx> <20180315185358.GJ1436@brightrain.aerifal.cx> <20180315193244.GK1436@brightrain.aerifal.cx> <20180315194348.GN1436@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11356bceba3e1f056778d64f" X-Trace: blaine.gmane.org 1521143489 1128 195.159.176.226 (15 Mar 2018 19:51:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Mar 2018 19:51:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12639-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 15 20:51:25 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ewYuI-00009A-61 for gllmg-musl@m.gmane.org; Thu, 15 Mar 2018 20:51:22 +0100 Original-Received: (qmail 32457 invoked by uid 550); 15 Mar 2018 19:53:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 32342 invoked from network); 15 Mar 2018 19:53:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=yuvw9JQGZnRtQktuG/KWGYcSPpyHoyYur2eQgtuYG/0=; b=Uk7OUOrvyY+anXRltvEGDaxlOl0xtKyLANvVXiL38yQSREvYvHwMDzo0Jr1bWDaCAH uryz4SJVd5C88lGq2YKljMjjOuKCyuhNdww0ve41l8wVa/AMwJ7ms7/BzJTO+n3ECyxx S3WUQArvuOQMBxC8kWj1a0L8FKwfQQKoGmO5E64lKE3zQklL2QThC57rXmGQ3HysSjhc sxH1dmcxsgN8WkeCrO2wM41HseA8cFPgrJDad/K8fM2XC4zWUZB7gK4xtTyHqEWAqTl7 3IfMt7eo08htLOgpjajARvqW/Tmu4bNYsWpLInQSPQugOpkhTVZZ7dSa8aGJxy9kxAG7 HMIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=yuvw9JQGZnRtQktuG/KWGYcSPpyHoyYur2eQgtuYG/0=; b=EVPnyr745+DUG1eBkl3X99lZZs9CfqFJervIsuHQQnVHJH2ERO6qubuBanC9aZ2A27 DX9SthRvbyQ21pweRyY0DDA5dAfnjyn/wMKqqKT7pxxxyTl873uCFaf0/cQtAk3RWdTj qkuJdu/o7WN/QM6gjw3aRklNXEB2CTJThGruZKkw3Iysi3+2c2F8FclqyXzf7ztUzhH+ 2++zyrJtvtfmd41H2ulETjWrpIJ7prcq0K/evTzJiqbwZDwSv6peq+ZYg9eT+eoF9lJF hCwWJ3gaBrE9G9qom4btQxIsbsB1x1L/P2TZVMDKzU73cg3qrHb01f3nb1oyFtxQY3Ip /E+Q== X-Gm-Message-State: AElRT7Hy6K4LGKQUlGFZXUzkrdMJB7P8tS17zXqzGcbbQ+2iDBY5Xg6l wzQb66YPoK+UMoNXxUSgSleeHL5vrFiUjXkIx4o= X-Google-Smtp-Source: AG47ELtr1HyyFPL5+x1vbsnz5FPWLDBgzvRj5RAoT1WUVoppO5yL+KRFpKIph6tO2Hdh1JRGjCKabnzIzTzwqxXBYdQ= X-Received: by 10.237.34.172 with SMTP id p41mr15260090qtc.316.1521143579818; Thu, 15 Mar 2018 12:52:59 -0700 (PDT) In-Reply-To: <20180315194348.GN1436@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12625 Archived-At: --001a11356bceba3e1f056778d64f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 15, 2018 at 4:43 PM, Rich Felker wrote: > 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 hav= e > bug > > > > > X, you write a test (configure-time or run-time as appropriate) t= o > > > > > 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 bu= g > > > 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. > OK my last comment. If you are 100% positive that there will never be a negative number or a wraparound due to types conversion, then I suggest to add some compiler-dependant pragma warning disabling locally in those lines. We cannot afford to loose static checking capabilities of a compiler because of a very specific occurrence. And sorry for spamming this thread. > Rich > --=20 Who=E2=80=99s got the sweetest disposition? One guess, that=E2=80=99s who? Who=E2=80=99d never, ever start an argument? Who never shows a bit of temperament? Who's never wrong but always right? Who'd never dream of starting a fight? Who get stuck with all the bad luck? --001a11356bceba3e1f056778d64f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 15, 2018 at 4:43 PM, Rich Felker <dalias@libc.org> wrote:
On Thu, Mar = 15, 2018 at 04:37:39PM -0300, dgutson . wrote:
> > > >> So whenever we find a bug on musl we should just st= op 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 appr= opriate) 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 whethe= r 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 pa= st.
> >
>
> 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.

OK my last comment. If you are 100%= positive that there will never be a negative number or a wraparound due to=
types conversion, then I suggest to add some compiler-dependant = pragma warning disabling locally in those lines.
We cannot afford= to loose static checking capabilities of a compiler because of a very spec= ific occurrence.
And sorry for spamming this thread.

Rich



--
Who=E2= =80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
= Who=E2=80=99d never, ever start an argument?
Who never shows a bit of te= mperament?
Who's never wrong but always right?
Who'd never dr= eam of starting a fight?
Who get stuck with all the bad luck?
--001a11356bceba3e1f056778d64f--