From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12620 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:37:39 -0300 Message-ID: References: <20180315183939.GI1436@brightrain.aerifal.cx> <20180315185358.GJ1436@brightrain.aerifal.cx> <20180315193244.GK1436@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c04e552e48c460567789fe8" X-Trace: blaine.gmane.org 1521142564 3678 195.159.176.226 (15 Mar 2018 19:36:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Mar 2018 19:36:04 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12634-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 15 20:36:00 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 1ewYfP-0000ro-AU for gllmg-musl@m.gmane.org; Thu, 15 Mar 2018 20:35:59 +0100 Original-Received: (qmail 22331 invoked by uid 550); 15 Mar 2018 19:37:53 -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 22293 invoked from network); 15 Mar 2018 19:37:52 -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=bInQP5i/Tvd1lYuisN+GYXGXjm73ZjquUO/IbTE6sQQ=; b=mBNv77dvwvq96a5dPv8mzxROROI3lh6l62rAkW1g8dqR1GhT3rNHu8pmJOyPh2Hmlq AgXOitx3Odu3hMY6LPjowA9DedSWn8Ny6Kdl43B9LvVyLPf+DKUYZoRsoT5448Vvfpjm qzSH+4o37XMCaaOuIn+kQPTmE3pcc8NmvcQYJPxS0Pnjh9B0G9NgUATmxyLA9/nqr3Ij UJZkez8Z2HZMf3Pdhlcw7NtOC21d9BKplb9UfetEJ1huqLzF+7j34X/TVnDHQw6ghsPE cd/rfnbjU1XdGKGTSqut7Uai62J8clk3crPQ2y1BOQ7qFquxvGu8tytZXSAc6sdwGOSX QpOg== 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=bInQP5i/Tvd1lYuisN+GYXGXjm73ZjquUO/IbTE6sQQ=; b=WJ7rW00AIsMTYDhs+EAHk+7fjJIbKuFUjB1k2GkXlk8k6WLtH0pxOyTxfQRj/iqBl0 BjiCuptoGUr4w23bIbYFYFP1o/QeSXdOyZMYOLQohdG+mZN57q9i2vt1U+ixzKIhABmo AGYJ5fStc7CMZLg6ZGepOOjYGOz0VImUWp97OUtPh7P1AOveNeWKPotDqdbRSPVsFvUZ Xp+rdvHicgx6zXl7JOVoX0crO5szlLaGdq/iNWAI/kvff8ecQKDT8G+QjAcX1hN8OuM2 acmBILR1r1tGtRTsqUKpOUFB9n5ACWdd7MwH9YYUi/CDIqqWQ034oSkqvCYMmMGKIaWB r65w== X-Gm-Message-State: AElRT7GMnFIgnh0s+Ewp+hhzJKjNcdu6L2aO3sgJEUhhPx5ryhnwS5ZC Xx/DtrBvqTlQxLHJXW2KfzyX8UuWlvway+fsM9o= X-Google-Smtp-Source: AG47ELu13NSnVVNxA8GIRCaYvCOxACpE6GcmZpZ+WUIaStx81T6sRPOI7HCwXGbj/aT5vO7TavXmhuq77IAPNOzzgaU= X-Received: by 10.233.239.73 with SMTP id d70mr13351353qkg.134.1521142659841; Thu, 15 Mar 2018 12:37:39 -0700 (PDT) In-Reply-To: <20180315193244.GK1436@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12620 Archived-At: --94eb2c04e552e48c460567789fe8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 15, 2018 at 4:32 PM, Rich Felker wrote: > On Thu, Mar 15, 2018 at 04:02:03PM -0300, Martin Galvan wrote: > > 2018-03-15 15:53 GMT-03:00 Rich Felker : > > > In any case it's not a bug in musl. The code is perfectly valid C. If > > > the compiler is producing a warning for it, either ignore it or ask > > > the compiler to stop. > > > > Just because some code is valid C, it doesn't mean it's not buggy. > > It's valid C that does exactly what it's intended to do. > > > >> The compiler warnings aren't being wrongly produced. musl will indee= d > > >> perform a signed-to-unsigned conversion here. > > > > > > Because that's how the C language works. > > > > Yes. And gcc has checks to try and make up for C's weak typing. > > > > While your definition of "bug" is debatable, IMHO if a commonly used > > option causes application builds to break due to some library, the > > library has a usability issue. The issue is even bigger when we're > > talking about something as core as the standard C library. > > Perhaps this should be documented more explicitly, but there is no > guarantee that building with -Werror[=3Danything except warnings which > are constraint violations in C] will succeed, especially when GCC is > not honoring its usual promise not to produce warnings for code > expanded from macros from -isystem paths. I did just test and indeed > the warning is produced with gcc 6.3.0. > > > >> 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 bu= g > > > 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. > > FWIW, mixing these two issues in one thread is not very productive. > The warning issue is separate and should be discussed on its own. > > 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? --94eb2c04e552e48c460567789fe8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 15, 2018 at 4:32 PM, Rich Felker <dalias@libc.org> wrote:
On Thu, Mar = 15, 2018 at 04:02:03PM -0300, Martin Galvan wrote:
> 2018-03-15 15:53 GMT-03:00 Rich Felker <dalias@libc.org>:
> > In any case it's not a bug in musl. The code is perfectly val= id C. If
> > the compiler is producing a warning for it, either ignore it or a= sk
> > the compiler to stop.
>
> Just because some code is valid C, it doesn't mean it's not bu= ggy.

It's valid C that does exactly what it's intended to do.

> >> The compiler warnings aren't being wrongly produced. musl= will indeed
> >> perform a signed-to-unsigned conversion here.
> >
> > Because that's how the C language works.
>
> Yes. And gcc has checks to try and make up for C's weak typing. >
> While your definition of "bug" is debatable, IMHO if a commo= nly used
> option causes application builds to break due to some library, the
> library has a usability issue. The issue is even bigger when we're=
> talking about something as core as the standard C library.

Perhaps this should be documented more explicitly, but there is no guarantee that building with -Werror[=3Danything except warnings which
are constraint violations in C] will succeed, especially when GCC is
not honoring its usual promise not to produce warnings for code
expanded from macros from -isystem paths. I did just test and indeed
the warning is produced with gcc 6.3.0.

> >> 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 b= ug
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 versi= on, 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.
=C2=A0

FWIW, mixing these two issues in one thread is not very productive.
The warning issue is separate and should be discussed on its own.

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?
--94eb2c04e552e48c460567789fe8--