Re: Status towards next release (1.1.4)

[Rich Felker <dalias@libc.org>]

On Fri, Jul 11, 2014 at 11:02:28PM -0700, Isaac Dunham wrote:
> On Sat, Jul 12, 2014 at 01:10:35AM -0400, Rich Felker wrote:
> > I think we're pretty well on-schedule for the next release. Here's a
> > summary of progress so far:
> <snip> 
> > - Locale framework. Right now this is mostly just a framework and does
> >   nothing useful.
> > 
> > - Byte-based C locale, not committed. As discussed previously, this is
> >   non-essential for conforming to current standards, so I'm inclined
> >   to omit it for now. But if there's demand for it we can consider
> >   adding it.
> 
> I'd like to at least test this to see how well it works.
> I just discovered that sword built with C++11 regex support dies with
> complaints related to the locale:
> terminate called after throwing an instance of 'std::runtime_error'
>   what():  locale::facet::_S_create_c_locale name not valid

What musl version? (1.1.3 or git?) I doubt this has anything to do
with musl's actual locale implementation, which has essentially no
outwardly-visible behavior right now, but we can check.

If you're not using git, see if git fixes it. 1.1.3 and earlier
rejected unknown locale names (anything but C, C.UTF-8, or POSIX).
Now, any name is accepted, and unknown names are all aliases for
C.UTF-8.

> > - The Big Bikeshed: where to find locale files? These will be somewhat
> >   musl-specific (to the extent that no other implementation uses the
> >   design I have in mind, though it would be easy for others to use
> >   it), so there's no existing practice to simply adopt. The files are
> >   not machine-specific (we'll support either endianness .mo file) so
> >   /usr/share (or other prefix variants) is the natural base location.
> 
> /usr/share/muslnls is awkward, maybe newnls?

FWIW, on glibc it's a mix of /usr/share/locale (messages,
non-machine-specific) and /usr/lib/locale (nasty machine-specific
binary stuff for other locale categories).

> I don't care exactly what gets decided, but a couple issues come to mind:
> -the name should NOT be .../"locale" or any other name in use on Linux
> systems. otherwise parallel installs break.

Agreed. We should not use a pathname with existing precedent for an
incompatible purpose.

> -it would be nice if the end of the path is at most 6 chars, since
> paths have to be stored somewhere...
> (Actually, this implies that 4 chars would be ideal:
> "/usr/share/" is 11 non-zero bytes, then add 4, then NUL, making 16 bytes,
> which shouldn't need any padding. This is, of course, decidedly premature
> optimization. ;-) )

Yes, I think it's premature optimization. I'd rather the name be clean
and reasonable to users than needlessly short. There's no fundamental
reason strings need padding to 16-byte boundaries anyway; if they are
padded as such, it's a toolchain issue and we should try to fix it at
the toolchain level.

Rich