Re: Re: #define __MUSL__ in features.h

[Rich Felker <dalias@libc.org>]

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 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