From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5450 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Status towards next release (1.1.4) Date: Sat, 12 Jul 2014 10:26:06 -0400 Message-ID: <20140712142606.GG179@brightrain.aerifal.cx> References: <20140712051035.GA15099@brightrain.aerifal.cx> <20140712060227.GD1789@newbook> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1405175186 19777 80.91.229.3 (12 Jul 2014 14:26:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Jul 2014 14:26:26 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5455-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jul 12 16:26:20 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1X5yFn-00020o-SJ for gllmg-musl@plane.gmane.org; Sat, 12 Jul 2014 16:26:19 +0200 Original-Received: (qmail 21663 invoked by uid 550); 12 Jul 2014 14:26:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21653 invoked from network); 12 Jul 2014 14:26:18 -0000 Content-Disposition: inline In-Reply-To: <20140712060227.GD1789@newbook> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5450 Archived-At: 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: > > > - 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