the case for __MUSL__

the case for __MUSL__

[Richard Gorton]

Hi,

I'm working on getting C++ working for our target: we use clang, and libcxx/libcxxabi libraries from llvm.org
it seems to me (as I'm doing this) that instead of doing things like

// Our compiler defines __COGNITIVE__
#if defined(__COGNITIVE__)

It would make more sense to use

#if defined(__MUSL__)


I'm not proposing/suggesting use of this within musl itself, but for use in other libraries (such as libcxx) which 'know' about the internal implementation of libc.
Thoughts & Comments appreciated



An example case is in libcxx/src/locale.cpp, where there are bits of code related to accessing the current locale:

const ctype<char>::mask*
ctype<char>::classic_table()  _NOEXCEPT
{
#if defined(__APPLE__) || defined(__FreeBSD__)
    return _DefaultRuneLocale.__runetype;
#elif defined(__NetBSD__)
    return _C_ctype_tab_ + 1;
#elif defined(__GLIBC__)
    return __cloc()->__ctype_b;
#elif __sun__
    return __ctype_mask;
#elif defined(_LIBCPP_MSVCRT) || defined(__MINGW32__)
    return _ctype+1; // internal ctype mask table defined in msvcrt.dll
// This is assumed to be safe, which is a nonsense assumption because we're
// going to end up dereferencing it later...
#elif defined(__EMSCRIPTEN__) || defined(__COGNITIVE__)
    return *__ctype_b_loc();
#elif defined(_AIX)
    return (const unsigned int *)__lc_ctype_ptr->obj->mask;
#elif defined(__ANDROID__)
    return _ctype_;
#else
    // Platform not supported: abort so the person doing the port knows what to
    // fix
# warning  ctype<char>::classic_table() is not implemented
    printf("ctype<char>::classic_table() is not implemented\n");
    abort();
    return NULL;
#endif
}



Regards,
	Richard
	rcgorton@cog-e.com

Re: the case for __MUSL__

[Josiah Worcester]

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

On Dec 29, 2014 10:27 AM, "Richard Gorton" <
rcgorton@cognitive-electronics.com> wrote:
>
>
> Hi,
>
> I'm working on getting C++ working for our target: we use clang, and
libcxx/libcxxabi libraries from llvm.org
> it seems to me (as I'm doing this) that instead of doing things like
>
> // Our compiler defines __COGNITIVE__
> #if defined(__COGNITIVE__)
>
> It would make more sense to use
>
> #if defined(__MUSL__)
>
>
> I'm not proposing/suggesting use of this within musl itself, but for use
in other libraries (such as libcxx) which 'know' about the internal
implementation of libc.
> Thoughts & Comments appreciated
>
>
>
> An example case is in libcxx/src/locale.cpp, where there are bits of code
related to accessing the current locale:
>
I suspect the thing to do here is more to iterate over the set of chars and
construct the table as needed: there's no sensible interface to this bit of
functionality in a standard way (and musl to my knowledge doesn't have the
table you want exposed anywhere). Note that doing it that way ought to just
work anywhere.

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

Re: the case for __MUSL__

[Josiah Worcester]

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

On Dec 29, 2014 11:15 AM, "Josiah Worcester" <josiahw@gmail.com> wrote:
> I suspect the thing to do here is more to iterate over the set of chars
and construct the table as needed: there's no sensible interface to this
bit of functionality in a standard way (and musl to my knowledge doesn't
have the table you want exposed anywhere). Note that doing it that way
ought to just work anywhere.

Minor correction: the table is exposed via __ctype_b_loc which you were
using. :)

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

Re: the case for __MUSL__

[Rich Felker]

On Mon, Dec 29, 2014 at 11:17:55AM -0600, Josiah Worcester wrote:
> On Dec 29, 2014 11:15 AM, "Josiah Worcester" <josiahw@gmail.com> wrote:
> > I suspect the thing to do here is more to iterate over the set of chars
> and construct the table as needed: there's no sensible interface to this
> bit of functionality in a standard way (and musl to my knowledge doesn't
> have the table you want exposed anywhere). Note that doing it that way
> ought to just work anywhere.
> 
> Minor correction: the table is exposed via __ctype_b_loc which you were
> using. :)

This is not a public interface for musl. The macros needed to
interpret the table are not in any public headers, and the table
contents cannot change in any locale-specific manner. The only purpose
of these tables is for ABI compatibility with glibc-linked binaries.
When building against musl, applications should ue the portable
standard ctype.h functions/macros (and the portable table building
approach you suggested if they need tables) rather than hacking in
access to the ABI-compat tables. Future versions of musl may have an
option for omitting all glibc ABI-compat bloat for users not needing
it.

Rich

Re: the case for __MUSL__

[Richard Gorton]

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.

	Regards,
		Richard Gorton
		rcgorton@cog-e.com



On Dec 29, 2014, at 12:37 PM, Rich Felker <dalias@libc.org> wrote:

> On Mon, Dec 29, 2014 at 11:17:55AM -0600, Josiah Worcester wrote:
>> On Dec 29, 2014 11:15 AM, "Josiah Worcester" <josiahw@gmail.com> wrote:
>>> I suspect the thing to do here is more to iterate over the set of chars
>> and construct the table as needed: there's no sensible interface to this
>> bit of functionality in a standard way (and musl to my knowledge doesn't
>> have the table you want exposed anywhere). Note that doing it that way
>> ought to just work anywhere.
>> 
>> Minor correction: the table is exposed via __ctype_b_loc which you were
>> using. :)
> 
> This is not a public interface for musl. The macros needed to
> interpret the table are not in any public headers, and the table
> contents cannot change in any locale-specific manner. The only purpose
> of these tables is for ABI compatibility with glibc-linked binaries.
> When building against musl, applications should ue the portable
> standard ctype.h functions/macros (and the portable table building
> approach you suggested if they need tables) rather than hacking in
> access to the ABI-compat tables. Future versions of musl may have an
> option for omitting all glibc ABI-compat bloat for users not needing
> it.
> 
> Rich

Re: the case for __MUSL__

[Josiah Worcester]

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

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.

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

Re: the case for __MUSL__

[Justin Cormack]

On Mon, Dec 29, 2014 at 5:59 PM, Josiah Worcester <josiahw@gmail.com> 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.

There are cases where glibc uses a non standard/bizarre/buggy
interface and using #ifdef __GLIBC__ and leaving Musl to use the sane
default case works. Best to avoid those if at all possible though.

Justin

Re: the case for __MUSL__

[Rich Felker]

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