Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Oct 1995 07:46:31 EST
From:      "Kaleb S. KEITHLEY" <kaleb@x.org>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        hackers@freefall.FreeBSD.org
Subject:   Re: A couple problems in FreeBSD 2.1.0-950922-SNAP 
Message-ID:  <199510171146.HAA08641@exalt.x.org>
In-Reply-To: Your message of Tue, 17 Oct 1995 17:21:33 EST. <199510170721.RAA31630@godzilla.zeta.org.au> 

next in thread | previous 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.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510171146.HAA08641>