[MPlayer-dev-eng] [PATCH] Use _NET_WM_NAME for UTF-8 title in X11 if supported

Rich Felker dalias at aerifal.cx
Fri Jun 23 17:05:21 CEST 2006


On Fri, Jun 23, 2006 at 02:47:57PM +0200, Matthias Hopf wrote:
> On Jun 22, 06 12:02:37 -0400, Rich Felker wrote:
> > > At least glibc and *BSD libcs have xlocale.h, which gives you
> > > thread-safe locale switching.
> > 
> > "At least"?? Making nasty nonstandard extensions that horribly bloat
> > the standard library even more is anything but a good thing.
> > Thankfully no one uses that crap...
> 
> Rich, the rational behind having thread-safe locales is reasonable. No

The rationale is to patch up a broken design (C/POSIX locale system),
and this is done with a whole secondary set of functions that are
nonportable and thus impossible to use in any serious program. A much
smarter system would be to abandon the locale system entirely and make
a (lightweight, not GNU bloatware style) library that's actually able
to support the needs of international programs (programs that deal
with datasets and input from more than one nation).

> need to get offensive, especially as I did not promote this in any form.

OK. :)

> > The fundamental problem is simply that so many core library routines
> > depend on locale when they shouldn't. If this were fixed then the
> > issue would mostly go away.
> 
> So *printf shouldn't depend on locale? Which functions should depend on
> the locale setting then, if not printf?

strcoll, strxfrm, strftime, strptime, maybe fnmatch/regcomp/regexec
(for collation classes and equivalence classes perhaps?), nl_langinfo,
localeconv (altho it should probably be considered deprecated anyway),
strfmon, maybe a few others.

Most of the other functions which depend on locale do it for LC_CTYPE
(which should always be UTF-8) or LC_NUMERIC (which causes horrible
breakage..).

Rich




More information about the MPlayer-dev-eng mailing list