[MPlayer-dev-eng] Re: [PATCH] print appropriate error when failing to open a file

[Vladimir Mosgalin]

Hi Rich Felker!

 On 2005.12.15 at 14:43:49 -0500, Rich Felker wrote next:

> They don't load and run foreign dll's and use huge bloated
> replacements for each of the libc functions that are broken by locale.

You sure? First, I don't really see what foreign dll has to do with
it - does it perform libc calls? How does wine works them?

About using "huge bloated replacements" - you know, in my build
mplayer's size is 8.5mb. No, it isn't static - it's dynamically linked
to 65 libaries, and doesn't use gui at all. Compiled size of vfscanf()
in glibc 2 is 25kb. And that function is among ten largest ones, the
other ones are smaller. Replacement for any function will be less
bloated then glibc one, too.

Second, if you desperately want to use libc functions, you can use hacks like

#define push_lc_numeric(x) do {                    \
   const char *tmplocale = setlocale(LC_NUMERIC,NULL); \
   setlocale(LC_NUMERIC,x);
#define pop_lc_numeric()                   \
   setlocale(LC_NUMERIC,tmplocale);            \
} while (0)

push_lc_numeric("C");
sprintf(...);
pop_lc_numeric();

> In any case, using non-C/POSIX LC_CTYPE is NOT AN OPTION.
> Is it possible to set LC_CTYPE to C.UTF-8 or POSIX.UTF-8 (or C.* where
> * is any encoding)? If so we could use a hack to ignore the language

No it's not.

> part of the user's locale and just set the user's preferred character
> encoding.

Well, actually there is a hack. You can use setlocale(LC_ALL, "") first,
then get required information on encoding etc via nl_langinfo()
function. Then you reset LC_CTYPE and the other categories you don't
like back to C, and use iconv to convert from utf-8 to encoding
nl_langinfo returned in mp_msg.

This solution will work nice on linux, however it'll require libiconv on
BSD and windows, while pure setlocale solution should work everywhere.


Another solution is to use some external library which handles locales
independent from POSIX. natspec (http://natspec.sourceforge.net/) may be
a good choice. It uses its own code to parse LANGUAGE/LANG/LC_*
variables and provides a set of functions for converting messages and
other i18n stuff. I don't really know how good will it work on windows,
but at least authors care about different systems and know of other ways
of getting locale setting except POSIX environment variables.

> However I don't know if this is even useful. IMO it's better to leave
> legacy encodings in a state of painful lack of support and eventually
> transition software over to UTF-8-only.

It may seem easy for you, but you know, people are having problems right
now.
If you think that a lot of people have switched to UTF-8 already, that's
probably because you live in USA or in some other english-speaking
country where UTF-8 works mostly as us-ascii. In Russia, where folks
uses CP1251 under windows, CP1251 or KOI8-R "legacy Cyrillic UNIX
encoding" in *nix, CP866 (legacy DOS encoding) in windows console and
have standart ISO8859-5 encoding which no gives a damn about, quite a
few people use UTF-8 in Linux.

Not to mention that it's not like windows software will be switching to
utf-8 soon, MS seems to prefer utf-16.

Running from reality is easy, but isn't always a best solution...

-- 

Vladimir