Date: Tue, 17 Oct 1995 17:21:33 +1000 From: Bruce Evans <bde@zeta.org.au> To: ache@astral.msk.su, kaleb@x.org Cc: hackers@freefall.freebsd.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Message-ID: <199510170721.RAA31630@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>Now all that goals are reached by 'setenv ENABLE_STARTUP_LOCALE' >>and without any program modifications. >EXCEPT THAT VIOLATES ANSI/POSIX/ISO C, which stipulates that on the >entry to main() the program must be in the C locale. People who use >this hack on correctly written programs find that it breaks their >programs in not very subtle ways, as you've already found with the >i18n-aware xterm that XFree86 distributes. You don't have to use ENABLE_STARTUP_LOCALE if you want full conformance. Let me give some examples of ctype and locale brokenness in X, not to pick on you or X, but to show how hard it is to do things right. I only have the XF311 sources to look at; perhaps the originals are better. xterm/main.c: Begins with setlocale(LC_ALL, NULL). This reads the current locale and throws away the value (except possibly on K&R systems with NULL defined as 0, when the uncast NULL may cause a core dump). The current locale is guaranteed to be the C locale on ANSI conformant systems so there is no point in reading it. xprop/xprop.c: `char *string; ... isalpha(string[0])' should dump core if string[0] is negative and not EOF. Another of ache's hacks makes it work right. The hack breaks ctype's handling of EOF, however. xrdb/xrdb.c: `char c; ... isalpha(c)' should dump core as above. These are trivial bugs. If programs can't call isalpha() with correct args, I have no confidence in them handling locale complications in full generailty. >>It is especially essential when >>program isn't FreeBSD native but comes from 3rd party, i.e. >>ports area. Moreover, they can be reached on any remote system >>too, includes freefall f.e. >Then perhaps the process of putting something into ports should include >minimally localizing the program to set the locale to whatever the >user has set in his or her LC_ALL, LC_CTYPE, or LANG environment variable. There aren't enough resources or interest. The core sources should be localized before ports, but haven't been. The following programs in /usr/src/*bin/*.c call setlocale(): csh, ee. That's all. >>Maybe this functionality isn't kosher but you even can't imagine how >>it is useful. >Let me get this straight. You're willing to compromise ANSI/POSIX/ISO >compliance because the functionality is useful. I'm not even asking to >compromise compliance and still get some useful behavior, and your >response is to make up completely bogus arguments like ANSI requires >the C locale to be strictly ASCII, no more, no less. I wonder if NetBSD >is this broken? I'm starting to think it might be time to switch camps. I think tradition is what requires the C locale to be strictly ASCII. Hmm. _startup_setlocale() could change things that aren't specified by ANSI - it could change the behaviour of isprint() and isspace() according to $LANG, but it can't change the behaviour of isupper() etc. This would fix ls. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510170721.RAA31630>