From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12619 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: #define __MUSL__ in features.h Date: Thu, 15 Mar 2018 15:32:44 -0400 Message-ID: <20180315193244.GK1436@brightrain.aerifal.cx> References: <20180315183939.GI1436@brightrain.aerifal.cx> <20180315185358.GJ1436@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1521142276 16235 195.159.176.226 (15 Mar 2018 19:31:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Mar 2018 19:31:16 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12633-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 15 20:31:12 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 1ewYaj-00045i-To for gllmg-musl@m.gmane.org; Thu, 15 Mar 2018 20:31:09 +0100 Original-Received: (qmail 10239 invoked by uid 550); 15 Mar 2018 19:32:59 -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 10178 invoked from network); 15 Mar 2018 19:32:56 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12619 Archived-At: 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 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 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[=anything 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 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. 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