Date: Fri, 11 Jul 2014 23:02:28 -0700 From: Isaac Dunham <ibid.ag@...il.com> To: musl@...ts.openwall.com Subject: Re: Status towards next release (1.1.4) 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 ...so I'm wondering whether this will improve compatability. (I'm not eager to go hunt down the issue right now; I expect it's some variant of the usual locale issues.) > - Gettext/mo file lookup core. This is not integrated with libc yet, > but tested and working. > > - Openrisc (or1k) port. Stefan Kristiansson's work seems basically > complete and is in the testing phase now. I'm hoping to merge it > in the next few days. > > There are several things we need to focus on now: > > - 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? 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. -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. ;-) ) > > Rich Thanks, Isaac Dunham
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.