From owner-freebsd-hackers Tue Oct 17 04:47:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA23452 for hackers-outgoing; Tue, 17 Oct 1995 04:47:07 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA23447 for ; Tue, 17 Oct 1995 04:47:05 -0700 Received: from exalt.x.org by expo.x.org id AA26398; Tue, 17 Oct 95 07:46:33 -0400 Received: from localhost by exalt.x.org id HAA08641; Tue, 17 Oct 1995 07:46:32 -0400 Message-Id: <199510171146.HAA08641@exalt.x.org> To: Bruce Evans Cc: hackers@freefall.FreeBSD.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Tue, 17 Oct 1995 17:21:33 EST. <199510170721.RAA31630@godzilla.zeta.org.au> Organization: X Consortium Date: Tue, 17 Oct 1995 07:46:31 EST From: "Kaleb S. KEITHLEY" 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. It's not whether *I* enable it or disable it. The issue is what happens to users do it. Like the XFree86 xterm. I cannot control what a user might do, and if setting ENABLE_STARTUP_LOCALE introduces a new state that the program did not anticipate, it causes problems. > >>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. That's not a justification for non-compliance at the crt0.o level. As Terry and I have said, the people who use these programs and that usage is hampered by the lack of l10n/i18n, should be fixing those programs and sending the fixes back to the authors. > I think tradition is what requires the C locale to be strictly ASCII. Ah, the good old "that's the way we've always done it" argument. That dog won't hunt. For the most part the people who have always done it that way won't know the difference if the C locale has some minimal support for 8859-1. -- Kaleb