From owner-freebsd-hackers  Mon Oct 16 18:46:56 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id SAA03146
          for hackers-outgoing; Mon, 16 Oct 1995 18:46:56 -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 SAA03134
          for <hackers@freefall.FreeBSD.org>; Mon, 16 Oct 1995 18:46:53 -0700
Received: from exalt.x.org by expo.x.org id AA11461; Mon, 16 Oct 95 21:46:21 -0400
Received: from localhost by exalt.x.org id VAA25626; Mon, 16 Oct 1995 21:46:15 -0400
Message-Id: <199510170146.VAA25626@exalt.x.org>
To: ache@astral.msk.su
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 04:09:48 EST.
             <WlS9mWmql2@ache.dialup.demos.ru> 
Organization: X Consortium
Date: Mon, 16 Oct 1995 21:46:15 EST
From: "Kaleb S. KEITHLEY" <kaleb@x.org>
Sender: owner-hackers@FreeBSD.org
Precedence: bulk


> In message <199510170051.RAA25909@phaeton.artisoft.com> Terry Lambert
>     writes:
> 
> >For one, my "hack" meets the definition of the ISO ratification of X3J11
> >and at the same time conforms to ISO 8859-x character set rules.
> 
> >It works for all ISO8859-x users, not just ISO8859-1.
> 
> >The difference is wherein the character code points are set based on
> >columnar location.  This was, in fact, one of the stated design goals
> >of the 8859-x standards.
> 
> Well, lets consider D7 char from 8859-1 exactly: is it
> ispunct() too f.e, in 8859-5?
> Lets consider DF char exactly, is it islower() too f.e. in 8859-5?

I thought we already established that in the C locale ANSI stipulates
islower/tolower/isupper/toupper only apply to 0x20<=c<=0x7e? 

> BTW, why we even forced to be strictly in 8859 bounds? Why another
> charset with lower half equal to ASCII can't live too?

No one is saying you can't. But the use of 8859-5 over e.g. KOI8-R does
seem to have some advantages, for the reasons Terry pointed out.

> >The one real issue is the collating sequence.  This is a non-issue for
> >"7-bit-ASCII-first" sort orders.  They will be correct.  It *IS* an
> >issue for "non-internationalized code pretending to be internationalized".
> 
> >I have absolutely no sympathy for such code; it should be fixed.
> 
> Well, it should be fixed by *WHOM* and *WHEN*? As you don't have sympathy,
> maybe you take this task as contacting to authors, fixing, etc.
> for each such program? Some of such programs needed right now,
> and I can't say to my users that they 'should be fixed', it means
> say nothing.

I don't know how well "free" translates into Russian. On this side of the
pond we have a saying: There Ain't No Such Thing As A Free Lunch, or 
TANSTAAFL for short. I said this to you in private email, now I'll say it 
here on hackers. There is a price for using free software. If it doesn't 
work for you, the burden is on you to fix it. Your hack to crt0.o as a 
means to avoid fixing the broken software you're using is just that, a 
hack. A big hairy green monster of a hack. I don't want hacks in the OS 
I'm using. You fix the software you're using. When you fix it make sure
you send the fix to the author. With any luck some day you won't be forced 
to fix it again every time there's a new release.

> >If you need to make code that isn't internationalized and you want a hack,
> >call the setlocale(,"") in main() if the desired program.
> 
> It will be broken for locales wich char width > 8bits.

I don't believe this, and I explained why in a previous email.

> Proper thing is to call non-standard startup_setlocale() which
> check char size not exceeds 8bit.

Can you even begin to imagine what would happen if, e.g. Microsoft or Sun 
said this is what you have to do?

--

Kaleb