> As discussed on irc, .charset suffixes should be dropped before the
loop even begins (never used in pathnames), and they occur before the
@mod, not after it, so the logic for dropping them is different.

1. drop .charset: Sorry for proposing it again, i forget this case after around three weeks, as i said before, vim will generate three different .mo files with different charset -> zh_CN.UTF-8.po, zh_CN.cp936.po, zh_CN.po. In that case, dropping is to generate a lots of junk.

I now found it's not a bug of msgfmt. That is charset is converted by: iconv -f UTF-8 -t cp936 zh_CN.UTF-8.po | sed -e 's/charset=utf-8/charset=gbk/ > ... So that means, charset and pathname is decided by softwares, msgfmt does not do charset converting at all, just a format-translator. (btw, iconv.c is from alpine)

How do we deal with the case? Patch the special software(since these special cases are rare, maybe other editors like emacs have similar actions, general softwares only prepare UTF-8 files)?

Or put the drop back in the loop? I prefer the latter, it seems more elegant and correct than ugly patches, my idea is: ```

tt_TT.XXX@mod

tt_TT.XXX

tt.XXX@mod

tt.XXX

tt_TT@mod

tt_TT

tt@mod

```

I have made it in a similar way as @mod in the attached. Here's the output from strace:

```

15:14:32.235463 open("./es_MX.utf8@euro/LC_MESSAGES/hellogt.mo", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (No such file or directory)

15:14:32.235495 open("./es_MX.utf8/LC_MESSAGES/hellogt.mo", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (No such file or directory)

15:14:32.235560 open("./es.utf8@euro/LC_MESSAGES/hellogt.mo", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (No such file or directory)

15:14:32.235585 open("./es.utf8/LC_MESSAGES/hellogt.mo", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (No such file or directory)

15:14:32.235621 open("./es_MX@euro/LC_MESSAGES/hellogt.mo", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (No such file or directory)

15:14:32.235656 open("./es_MX/LC_MESSAGES/hellogt.mo", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (No such file or directory)

15:14:32.235683 open("./es@euro/LC_MESSAGES/hellogt.mo", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (No such file or directory)

15:14:32.235706 open("./es/LC_MESSAGES/hellogt.mo", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = 3

```

Other possible LANG is tested, too.

> One bug in my version: loclen+1 should be loclen+modlen+1. Without

changing that, the pathname gets truncated if @mod is used. Otherwise
it seems to work.

2. Yes, it is, made it in the attached.

> then we should probably increase this limit a bit, perhaps to 24 or
so.

3. the longest line is `tt_TT.iso885915@euro`, 21. 24 seems good for the current standard. Made it in the attached.

2017-03-17 19:37 GMT+00:00 Rich Felker <dalias@libc.org>:

On Fri, Mar 17, 2017 at 03:27:49PM -0400, Rich Felker wrote:
> + /* Logically split @mod suffix from locale name. */
> + modname = memchr(locname, '@', loclen);
> + if (!modname) modname = locname + loclen;
> + alt_modlen = modlen = loclen - (modname-locname);
> + loclen = modname-locname;
> +
> + /* Drop .charset identifier; it is not used. */
> + const char *csp = memchr(locname, '.', loclen);
> + if (csp) loclen = csp-locname;
> +
> + char name[dirlen+1 + loclen+1 + catlen+1 + domlen+3 + 1];
> + const void *map;

One bug in my version: loclen+1 should be loclen+modlen+1. Without
changing that, the pathname gets truncated if @mod is used. Otherwise
it seems to work.

One separate but related problem I noticed while testing is that
musl's locale name length limit of 16 is insufficient for something
like "en_GB.UTF-8@euro". If we want to allow users to have an explicit
".UTF-8" in the locale name (which, as we discussed a while back,
users may want to do if they plan to ssh into glibc-based systems)
then we should probably increase this limit a bit, perhaps to 24 or
so.

Rich