From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Re: a bug in bindtextdomain() and strip '.UTF-8'
Date: Mon, 13 Feb 2017 12:08:25 -0500 [thread overview]
Message-ID: <20170213170825.GH1520@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAPG2z08MUcj-0i=_kOO=WTP4bAufc2Dx8v6kGvmzHnoVu4c-nA@mail.gmail.com>
On Sun, Feb 12, 2017 at 02:56:53PM +0800, He X wrote:
> 1. cat is added to the keys, also do a validate
> 2. so we what do we deal with the gettextdir() exactly? inline it or
> construct a gettextpointer()?
> 3. i added a extra locbuf array, and goto is replaced by a loop, memcpy is
> replaced by snprintf, compiled, and working well with fcitx
I haven't verified the loop logic yet but on a high level it looks
correct.
> 4. i just found that i forgot to store the keys to new buffer, it's ok to
> just use normal expression? or we need atomic operations?
> ```
> + p->cat = category;
> + p->binding = q;
> + p->lm = lm;
> ```
This is fine since the new msgcat is not visible to other threads
until it's installed with an atomic, which makes all previous writes
visible. I do want to rework this all with a lock structure rather
than atomics but that's a separate project.
> 5. I do want to rewrite all to .UTF8, but it's a bit annoying as your
> words, then i changed the code to simply strip.
Since this part is separate and there seems to be disagreement about
what it should do, let's separate it from the issue at hand; it's
really a separate change from making gettext do proper fallbacks
anyway.
> > (safe for the user's terminal)
> LANG is set by users who are using musl and it's modified to zh_CN at
> setlocale(), app will use UTF8 directly, there's no such situation where
> charset will cause troubles to users' terminal, except apps which get the
> LANG manually by getenv(). I have not seen such strange applications so
> far, and most apps only have the UTF8 translation files.
>
> For moving from glibc to musl, i think doing this way is good for now, we
> could delete it later, or just keep it forever. And most people won't use
> non-UTF8 at all, if they do use GBK, their app will even fallback to UTF8,
> because no translation files for GBK. So, it's not so dagerous, i think :).
The main considerations are:
1. what happens when a glibc user ssh's into a musl-based system
2. what happens when a musl user ssh's into a glibc-based system
3. what happens when running musl binaries on a glibc-based system
For #1 and #3, it's desirable for musl to accept ".UTF-8" in the
locale name, and for #2, users may desire to have ".UTF-8" in their
LC_* env vars so that remote glibc programs behave correctly.
For #1 and #3, if a glibc uses is using a legacy non-UTF-8 locale and
runs a musl program, they're either going to get messed-up output or
ASCII-only, depending on decisions we make and/or what their locale
value is. These are not really important since legacy encodings are
not supported, but it might be nice to make least-bad.
If the user has a locale name like "fr_FR" or "zh_CN" that, that's
going to be interpreted differently by musl vs glibc; that was already
decided a long time ago in the interest of designing around the future
rather than broken legacy stuff. But if the locale name is explicitly
non-UTF-8 like "zh_CN.GBK", we could opt to reject it without breaking
anything, and this may give users better feedback about what's going
wrong if they have such settings when ssh'ing into a musl-based
system.
Rich
next prev parent reply other threads:[~2017-02-13 17:08 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-20 11:25 He X
2017-01-29 4:52 ` He X
2017-01-29 13:39 ` Szabolcs Nagy
2017-01-29 14:07 ` Rich Felker
2017-01-29 14:48 ` He X
2017-01-29 15:55 ` Rich Felker
2017-01-29 16:14 ` He X
2017-01-29 16:33 ` Rich Felker
2017-02-08 10:13 ` He X
2017-02-08 14:31 ` Rich Felker
2017-02-09 9:49 ` He X
2017-02-11 2:36 ` Rich Felker
2017-02-11 6:00 ` He X
2017-02-11 23:59 ` Rich Felker
2017-02-12 2:34 ` Rich Felker
2017-02-12 6:56 ` He X
2017-02-12 7:11 ` He X
2017-02-13 17:08 ` Rich Felker [this message]
2017-02-13 8:01 ` He X
2017-02-13 13:28 ` Rich Felker
2017-02-13 14:06 ` He X
2017-02-13 17:12 ` Rich Felker
2017-03-04 8:02 ` He X
2017-03-17 19:27 ` Rich Felker
2017-03-17 19:37 ` Rich Felker
2017-03-18 7:34 ` He X
2017-03-18 12:28 ` Rich Felker
2017-03-18 13:50 ` He X
2017-02-13 14:12 ` He X
2017-02-13 17:13 ` Rich Felker
2017-01-29 16:37 ` Rich Felker
2017-01-30 0:37 ` He X
2017-01-30 14:17 ` He X
2017-01-29 16:40 ` Szabolcs Nagy
2017-01-29 16:49 ` Rich Felker
2017-01-30 12:36 ` He X
2017-01-30 13:05 ` Szabolcs Nagy
2017-01-30 1:32 ` He X
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170213170825.GH1520@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).