[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