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

[Rich Felker]

On Fri, Dec 16, 2005 at 12:05:23AM +0300, Vladimir Mosgalin wrote:
> 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?

Yes. I assume either wine does not use locale, or wine implements
separate safe libc calls for the win32 code to use.

> 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.

That is incredibly bloated. Here's a more sane setup:

brightrain:~$ ls -l /usr/local/bin/mplayer
-rwxr-xr-x   1 root     root      6051280 Dec  9 22:07 /usr/local/bin/mplayer*
brightrain:~$ ldd /usr/local/bin/mplayer
        libmp3lame.so.0 => /usr/local/lib/libmp3lame.so.0 (0x40017000)
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x400af000)
        libcdda_interface.so.0 => /usr/local/lib/libcdda_interface.so.0 (0x400ed000)
        libcdda_paranoia.so.0 => /usr/local/lib/libcdda_paranoia.so.0 (0x40102000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x4010c000)
        libgif.so.4 => /usr/local/lib/libgif.so.4 (0x40122000)
        libXext.so.6 => /usr/X11/lib/libXext.so.6 (0x4012a000)
        libX11.so.6 => /usr/X11/lib/libX11.so.6 (0x40136000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x401d5000)
        libdl.so.2 => /lib/libdl.so.2 (0x401e7000)
        libm.so.6 => /lib/libm.so.6 (0x401eb000)
        libc.so.6 => /lib/libc.so.6 (0x40208000)
        libSM.so.6 => /usr/X11/lib/libSM.so.6 (0x402e4000)
        libICE.so.6 => /usr/X11/lib/libICE.so.6 (0x402ed000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

> 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.

For once I agree!! :))))))))

Anyway bloat is not binary size, that's only one aspect. Source bloat
is also bloat.

> 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();

Not thread-safe. This is why POSIX locale is fundamentally broken.
Using a global variable for the locale is absolutely not acceptable.

> > 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.

Then WTF are you supposed to set locale to on a non-localized system
with UTF8 encoding?? (aka a "globalized" system :)

> > 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.

I don't think a lot of people have already switched. This is why I
think it's imperative that software press people to move to it and
away from legacy crap.

Want to know why I'm so opposed to legacy crap? It only works for
certain languages, mostly European and CJK. The rest of the world is
left out, and as long as software doesn't support unicode, they're
forced more and more to use English for computing, which amounts to
cultural & linguistic impirialism. Even when the legacy crap does
work, it only works inside the locale that uses the particular legacy
encoding, making it impossible for people to communicate between
locales in any language but English.

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

Nonsense. Any software written in C uses utf-8 for unicode. utf-16 is
not even an option.

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

Fixing reality and running from it are two entirely different things.
Living with a crappy reality is easy but not always the best solution.

Rich