Re: the case for __MUSL__

[Richard Gorton <rcgorton@cognitive-electronics.com>]

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