[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140714034826.GP179@brightrain.aerifal.cx>
Date: Sun, 13 Jul 2014 23:48:26 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Status towards next release (1.1.4)
On Sun, Jul 13, 2014 at 02:16:30PM +0530, Weldon Goree wrote:
> Just because I figure someone should propose the most brute possible
> strategy: what about storing the .mo data in the library itself? Port
> the built-ins to the format, and you have a single code path for locale
> access, and it doesn't involve persistent storage. If I'm understanding
> your idea right and you're talking about the equivalent of
> SYS_LC_MESSAGES and parts of LC_TIME and LC_COLLATE, this isn't nearly
> as bloated as it sounds at first (particularly if one is putting, say, 4
> locales in a given build rather than 446).
>
> Now, obviously maintainers wouldn't like the choice of either 1 bloated
> binary or 446 non-bloated binaries (or God forbid the Cartesian product
> of all the possible locale combinations), and this kind of violates the
> basic idea of locale that you shouldn't need to recompile software to
> get it to speak French, but I just wanted to throw that idea out there.
Indeed, this idea violates that and many other principles:
- That support for Unicode should be cheap (your idea makes
setlocale(), which any portable program supporting non-ASCII text
needs to call, pull in a huge part of the library)
- That the person compiling the software generally has no idea what
languages the user will care about.
- That while character encodings and character identity are
essentially finished, settled matters that won't change, language
and culture are fluid. A program with locale data hard-linked into
is is basically guaranteed not only to be incomplete in the future,
but outright WRONG in the future. The best analogy I can think of
would be hard-coding timezones into the binary.
And probably many others. So I don't think this idea is viable.
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.
