Re: Constants to decode __ctype_b_loc() table

[Szabolcs Nagy <nsz@port70.net>]

* Sergey Dmitrouk <sdmitrouk@accesssoftek.com> [2014-10-16 11:37:39 +0300]:
> 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.

either glibc changes its locale system and keeps __ctype_b_loc around
with the old semantics (which they can do any time) or they change the
semantics of __ctype_b_loc breaking the current abi (which they should
not do)

this is why depending anything in source headers is broken when you
depend on internal abi: internal details of the source can change,
there is no guarantee about them, abi that is visible to existing
binaries cannot change (hopefully)

so libc++ should not use undocumented masks from glibc ctype.h

libc++ should use standard interfaces (that should be the default)
and if it must use __ctype_b_loc then recognize that glibc headers
are not under their control so they have to replicate the bits they
care about

> 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.

i think adding a comment makes sense, but i think we should not
encourage the dependence on accidentally visible abi details of
the libc