Re: Constants to decode __ctype_b_loc() table

[Rich Felker <dalias@libc.org>]

On Thu, Oct 16, 2014 at 11:37:39AM +0300, Sergey Dmitrouk wrote:
> On Wed, Oct 15, 2014 at 07:07:12PM -0700, Rich Felker wrote:
> > In the link you cited:
> > 
> >     "This interface is not in the source standard; it is only in the
> >     binary standard."
> 
> Even if it's a binary interface, it shouldn't be underspecified.  Right
> now __ctype_b_loc.c contains an array of numbers which correspond to
> what glibc has.  Consider the following situation: glibc changes masks
> at some point, musl doesn't, someone uses masks from new glibc's
> headers after reading a thread like this one and obtains broken locales.

glibc can't change these because every existing glibc binary using the
ctype functions depends on them. They could do it with a new symbol
version, but that would be a lot of gratuitous breakage, and if we
wanted to support that it would take a lot more hacks than just
"updating" our tables.

> Having this documented in form of a comment instead of public interface
> would be good as well, in this case clients could consult place where
> it's documented and be sure that their constants are correct.  Say, add
> a comment to __ctype_b_loc.c to clarify meaning of the table and
> document masks at the same time.

The documentation is purely that this object which __ctype_b_loc
returns a pointer to is a binary blob matching what glibc provides for
the purpose of running glibc-linked binaries. It's not an API
interface but an ABI interface.

Rich