Re: the case for __MUSL__

[Rich Felker <dalias@libc.org>]

On Mon, Dec 29, 2014 at 11:59:39AM -0600, Josiah Worcester wrote:
> On Dec 29, 2014 11:51 AM, "Richard Gorton" <
> rcgorton@cognitive-electronics.com> wrote:
> >
> >
> > That is a single example of some of the code in a library which is NOT
> musl.
> > There are other places in the example library which know about __APPLE__
> or __GLIBC__ or __sun__
> >
> > My thought is to use __MUSL__ in those libraries as appropriate in place
> of __<architecture>__ as the backing libc is musl.
> >
> > And said use of __MUSL__ is what I am interested in feedback about.
> >
> 
> The intent of not providing it is to force applications to use a portable
> interface rather then being libc specific. So, everyone's leaping to try
> and find ways to not need that.
> Sorry for the mismatched expectations.

Exactly. The intent is that musl should be supported by the #else case
with the portable code in it, or (even better) that all cases but the
#else should be removed as unnecessary so that the same code is used
everywhere.

In cases where musl is providing some non-standard interface from
glibc or BSD that you actually want to use, the right way to use it is
to test for its availability at compiletime with either some sort of
configure process (autoconf or similar) or via feature-specific macros
(like the ones POSIX defines for optional POSIX functionality in
unistd.h, although nothing like that exists yet for non-standard
extensions). Using a macro like __MUSL__ or __GLIBC__ to enable use of
such interfaces is not reasonable since it requires hard-coding
assumptions about which extensions are available in particular
versions rather than actually checking for the availability of the
interface you want.

Rich