From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12614 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 15:51:22 -0300 Message-ID: References: <20180315183939.GI1436@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114f8a885d5c1f056777fa94" X-Trace: blaine.gmane.org 1521139785 4779 195.159.176.226 (15 Mar 2018 18:49:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Mar 2018 18:49:45 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12628-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 15 19:49:41 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 1ewXwa-0001AL-UQ for gllmg-musl@m.gmane.org; Thu, 15 Mar 2018 19:49:41 +0100 Original-Received: (qmail 14244 invoked by uid 550); 15 Mar 2018 18:51:37 -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 14074 invoked from network); 15 Mar 2018 18:51:34 -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=R9eKF0hcgZ2f1dbZyLUBWTYmBfMHmt3xKgFptLvGqgk=; b=HYSvnl3lc6SRZKpYvG7dVEc6NlPeOvFnFc3nJ3aJ/JWtpnqeCle74u+sZlOCM7UW2+ TFQSOWyHU1c6W3YngG8eidYhnTyun4u6D8/5/K6ucDoJ2RMH3591PZbDm+2kw8AFiaML kDHlyTvMyq2g1z5YkbEPHG4BaDrxAdIXgW3eOwCVO8FGxHSyZtGfIMfwIOrJMXHTszQT 1cVWs1A2afbqDfBwooftLg5foHk0FtW6jeQ+EuTkMB79iRX/AHs9TNhBheZd/xe+Dx3F dFU9kf85TNsT2BJ6gCuMTfkAwjrjX0BEYBKxvoLzHdZ3LiCEnvR15oMrbNHMAQ8VZ8UJ ZZPQ== 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=R9eKF0hcgZ2f1dbZyLUBWTYmBfMHmt3xKgFptLvGqgk=; b=ZRDcQ2iudMvYlyR3Okkl+ZRwwT5V3NRGw5LR50YOeyqC3I7XDyo/GwzQHjgB+yDTVM jOrd4VxagZ29l8X+B6XADt9TOo8QCEw4Thq3h+RPbCZNbOUinL0tpjFbyySMnnW3O1F8 Qq7FN5c7ngzdOpdi5PK8sda92FQHLEeTSeRLQcTH0r+uHZZ2o9SKutBPRWDL3oI8yjaB kfAjY9ck3Je8r3LcdNt8UTPzwZzBtAdLwt3YtE6thjUHoxTVIZIVQhl+2zaSRNgrbXNM VRiWHGrjEZR/915yJXYeePbItTfb2VI5NM4F2d+9ru4jeMiI1aUGEi44txWtXRbtlM5u cEEQ== X-Gm-Message-State: AElRT7Erw/fd44IdVgMME5Ez66h/O0Z3f0ya7u+FXVVRK88oKY3OrG+T gKUKCchLlydQN8suhW8K0uMcZCTih3ELhGtCQJE= X-Google-Smtp-Source: AG47ELuZIzxXcfDXth+4eHUC/AWklXQE36CHmcuwK4/RQdVkhDO+3j4TQUaHUQaE7azv5Tg18S5I2afSbi89Jsb3eOo= X-Received: by 10.55.139.7 with SMTP id n7mr14105788qkd.210.1521139882742; Thu, 15 Mar 2018 11:51:22 -0700 (PDT) In-Reply-To: <20180315183939.GI1436@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12614 Archived-At: --001a114f8a885d5c1f056777fa94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 15, 2018 at 3:39 PM, Rich Felker wrote: > On Thu, Mar 15, 2018 at 12:55:29PM -0300, dgutson . wrote: > > > On Fri, Mar 29, 2013 at 09:44:05PM +0100, Daniel Cegie=C5=82ka wrote: > > > > Is it possible to add to the features.h __MUSL__ definition? > > > > > > > > glibc can be identified by __GLIBC__, uclibc through __UCLIBC__ etc= . > > > > > > Is this question in the FAQ yet? If not, it really should be. The > > > answer is no, it won't be added, because it's a bug to assume a > > > certain implementation has particular properties rather than testing. > > > > That is a beautiful theory in an ideal world, but in the real world, > > > > implementations have bugs, and sometimes we need to workaround these > bugs. > > If there's an actual bug you need to work around, detect it. > Hard-coding "musl is buggy" is not beneficial to us; rather it leads > to broken hacks lingering long after the bug is fixed. > > > (e.g. the FD* issue reported by Martin Galvan). > > That's not a bug. It's compiler warnings being wrongly produced for a > system header, probably because someone added -I/usr/include or > similar (normally GCC suppresses these). > > The musl policy regarding not having a macro like __MUSL__ is doing > exactly what it's intended to do: encouraging developers and package > maintainers to come to us (or investigate on their own) and fix the > underlying portability problems (and sometimes musl bugs) rather than > writing hacks to a specific version of musl that will be wrong a few > versions later. > Fact #1: Software is not perfect. Bugs may show up. And sometimes in bad timing when doing a release. So, user developers have two options: hack the library with a workaround, and release with a hacked library untested and unverified by its supporting community, or they can leave the library as-is, and implement the workaround in the using code (which requires the macro in order to limit the impact to the library implementation). Fact #2: Fixes take time, because community projects have their own agenda and triaging policies. So, in the hypothetical bug of a library (no matter this particular case I referred to, there were, there are, and there will always be bugs) the macro will work as an escape hatch until the fix of the hypothetical bug is ready upstream. I'm writing this from a very practical and industry point of view (who have worked in FLOSS projects before and commercial projects). > > 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? --001a114f8a885d5c1f056777fa94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 15, 2018 at 3:39 PM, Rich Felker <dalias@libc.org> wrote:
On Thu, Mar = 15, 2018 at 12:55:29PM -0300, dgutson . wrote:
> > On Fri, Mar 29, 2013 at 09:44:05PM +0100, Daniel Cegie=C5=82ka wr= ote:
> > > Is it possible to add to the features.h __MUSL__ definition?=
> > >
> > > glibc can be identified by __GLIBC__, uclibc through __UCLIB= C__ etc.
> >
> > Is this question in the FAQ yet? If not, it really should be. The=
> > answer is no, it won't be added, because it's a bug to as= sume a
> > certain implementation has particular properties rather than test= ing.
>
> That is a beautiful theory in an ideal world, but in the real world, >
> implementations have bugs, and sometimes we need to workaround these b= ugs.

If there's an actual bug you need to work around, detect it.
Hard-coding "musl is buggy" is not beneficial to us; rather it le= ads
to broken hacks lingering long after the bug is fixed.

> (e.g. the FD* issue reported by Martin Galvan).

That's not a bug. It's compiler warnings being wrongly produ= ced for a
system header, probably because someone added -I/usr/include or
similar (normally GCC suppresses these).

The musl policy regarding not having a macro like __MUSL__ is doing
exactly what it's intended to do: encouraging developers and package maintainers to come to us (or investigate on their own) and fix the
underlying portability problems (and sometimes musl bugs) rather than
writing hacks to a specific version of musl that will be wrong a few
versions later.

Fact #1: Software is no= t perfect. Bugs may show up. And sometimes in bad timing when doing a relea= se.
So, user developers have two options: hack the library with a= workaround, and release with a
hacked library untested and unver= ified by its supporting community, or they can leave the library as-is, and=
implement the workaround in the using code (which requires the m= acro in order to limit the impact to the library implementation).

Fact #2: Fixes take time, because community projects have t= heir own agenda and triaging policies.

So, in the = hypothetical bug of a library (no matter this particular case I referred to= , there were, there are, and there will always be bugs)
the macro= will work as an escape hatch until the fix of the hypothetical bug is read= y upstream.

I'm writing this from a very pract= ical and industry point of view (who have worked in FLOSS projects before a= nd commercial projects).
=C2=A0

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?
--001a114f8a885d5c1f056777fa94--