[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 12 Jul 2014 10:26:06 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Status towards next release (1.1.4)
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
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.
