Re: Re: a bug in bindtextdomain() and strip '.UTF-8'

[Rich Felker <dalias@libc.org>]

On Sun, Jan 29, 2017 at 05:40:08PM +0100, Szabolcs Nagy wrote:
> * He X <xw897002528@gmail.com> [2017-01-29 22:48:34 +0800]:
> > 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.
> 
> that's not how abi works.. you change the __c_locale typedef
> of the generic config from int* to locale_t, such change
> breaks abi and cannot be upstreamed to gcc. (it's unfortunate
> that the c++ locale handling default for non-gnu systems
> does not use posix locales correctly, but breaking abi
> for all non-gnu systems is not an acceptable fix.)
> 
> with your change the abi of libstdc++ would look like
> the current gnu abi:
> 
> $ grep __locale_struct libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt |wc -l
> 72
> 
> the abi on a musl based system is like
> 
> $ nm -D /usr/lib/libstdc++.so.6 |grep __locale_struct |wc -l
> 0
> 
> so with your patch if a compiled binary refers to any one
> of those 72 symbols then the dynamic linker will fail to
> load it on a musl based system.

So would this work?

struct __generic_locale {
	int dummy;
	localt_t locale;
};

Then allocate these objects with new. That way int* could point to the
object (by pointing to its first member) and the locale_t could be
obtained. Wasteful and ugly, but valid.

Any other fix seems to assume int* can represent locale_t; I don't
think that's valid for a "generic" implementation.

Rich