From owner-freebsd-hackers  Tue Oct 17 00:23:49 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id AAA12303
          for hackers-outgoing; Tue, 17 Oct 1995 00:23:49 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA12298
          for <hackers@freefall.freebsd.org>; Tue, 17 Oct 1995 00:23:35 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA31630; Tue, 17 Oct 1995 17:21:33 +1000
Date: Tue, 17 Oct 1995 17:21:33 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199510170721.RAA31630@godzilla.zeta.org.au>
To: ache@astral.msk.su, kaleb@x.org
Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP
Cc: hackers@freefall.freebsd.org
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

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