Re: Re: #define __MUSL__ in features.h

["dgutson ." <danielgutson@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]

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



-- 
Who’s got the sweetest disposition?
One guess, that’s who?
Who’d 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?

[-- Attachment #2: Type: text/html, Size: 3721 bytes --]