Debian switching to EGLIBC [LWN.net]

Debian switching to EGLIBC

Posted May 6, 2009 19:50 UTC (Wed) by nix (subscriber, #2304)
In reply to: Debian switching to EGLIBC by ajross
Parent article: Debian switching to EGLIBC

There's a lot more to locale support than the wchar stuff. In fact the
wchar stuff is decidedly minority and doesn't use more than a few tens of
Kb.

Most of the space consumption is charmaps (which we can't do without, and
the largest ones are Far Eastern and Unicode), converters to/from UTF-8
(obviously necessary if we want to handle other encodings at *all*) and
timezones (which we can't do without, although it would be nice if glibc
contained an interface to let us use the historical data in them properly:
Ulrich has explicitly (and bluntly) ruled this out without giving a
rationale. As usual. Maybe eglibc can add an appropriate interface.)

(Log in to post comments)

Debian switching to EGLIBC

Posted May 8, 2009 1:56 UTC (Fri) by spitzak (guest, #4593) [Link]

I would be extremely happy if I could rely on printf not changing the periods to commas when I don't expect it, and strcmp not changing. I have to force the C locale at startup just so our software can write files that I can be sure can be read.

Any intelligent person would have just made a different %-command. It really is not very hard for a programmer to choose what to do based on the locale. The C library, if it provides anything at all, should only provide a "this is the locale" call. It should have ZERO effect on the behavior of any functions that do not actually take a locale as an argument.