Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141229173713.GM4574@brightrain.aerifal.cx>
Date: Mon, 29 Dec 2014 12:37:13 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: the case for __MUSL__

On Mon, Dec 29, 2014 at 11:17:55AM -0600, Josiah Worcester wrote:
> On Dec 29, 2014 11:15 AM, "Josiah Worcester" <josiahw@...il.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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.