1. agreed with rich, nplurals is important too; compiling the kernel, cannot update the patch

2. no other ways, musl will use generic config 100%, and then the exception, the run time error is hardcoded there; but i doubt if this really breaks binaries, the function is only called by libstdc++ itself. you cant only update the config, but does not update libstdc++. libstdc++ exported the same abi for common binaries, wont break most dynamic-loaded binary in my view.

btw, with 'p-> to q->', 'strip .UTF-8'(these two in the first thread), and these two patches, fcitx, chromium are working well.

but there're some names like 'de_DE@euro', 'zh_CN.GBK', these should be stripped, either, any good ideas?

2017-01-29 22:07 GMT+08:00 Rich Felker <dalias@libc.org>:

On Sun, Jan 29, 2017 at 02:39:47PM +0100, Szabolcs Nagy wrote:
> * He X <xw897002528@gmail.com> [2017-01-29 12:52:56 +0800]:
> > 1. no memset after malloc, caused chromium crash:
> > http://www.openwall.com/lists/musl/2017/01/28/1
> > --- musl-1.1.16/src/locale/dcngettext.c 2017-01-29 04:42:49.002221317 +0000
> > +++ musl-1.1.16/src/locale/dcngettext.c 2017-01-29 04:42:49.002221317 +0000
> > @@ -180,6 +180,7 @@
> > __munmap((void *)map, map_size);
> > goto notrans;
> > }
> > + memset(p, 0, sizeof *p + namelen + 1);
> > p->map = map;
> > p->map_size = map_size;
> > memcpy(p->name, name, namelen+1);
>
> if you want to zero the entire allocation, then use calloc.
> but i think initializing plural_rule is enough.

Conceptually it seems nice to avoid filling name[] twice, but since
namelen is bounded in size (note: we should be using strnlen elsewhere
where it first gets introduced, but strlen is already checked) it's
not such a practical issue. I would be ok with just zeroing
plural_rule and nplurals (the latter doesn't seem necessary but
leaving it uninitialized until later seems to be a poor choice w.r.t.
future-proofing the code) but just calling calloc for these
allocations is probably the cleanest fix.

> > 2. musl uses generic config of libstdc++, which blocked the support of
> > locale, patch is there:
> > https://github.com/xhebox/noname-linux/issues/2#issuecomment-275704150
>
> this breaks the abi of libstdc++ because the definition of
> a type in the public api is changed.
>
> so existing c++ binaries break if the toolchain is patched.

I'm not sufficiently familiar with this code to understand why right
away. Do you see an easy fix to avoid ABI breakage while fixing the
bug?

Rich