Date: Mon, 16 Oct 1995 02:25:29 +0300 (MSK) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) <ache@astral.msk.su> To: hackers@freefall.FreeBSD.org, "Kaleb S. KEITHLEY" <kaleb@x.org> Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Message-ID: <YlfXPWmmJ1@ache.dialup.demos.ru> In-Reply-To: <199510151747.NAA04827@exalt.x.org>; from "Kaleb S. KEITHLEY" at Sun, 15 Oct 1995 13:47:59 EST References: <199510151747.NAA04827@exalt.x.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199510151747.NAA04827@exalt.x.org> Kaleb S. KEITHLEY
writes:
>Andrey Chernov said:
>>>just fixing ls isn't enough. The default table of character types in
>>>libc/locale/table.c isn't populated well enought to handle the whole
>>>ISO8859-1 character set. The following patch fixes ls, libc, and also
>>Default code table is ASCII and _not_ ISO8859-1, so it not needed to be
>>populated. Default code table is strict 7bit.
>No, it doesn't need to be, but is there a reason it can't do the right
>thing anyway? The table is defined as having 256 elements, so populating
>it with something useful isn't going to hurt anything.
Historycally ctype(>127) returns 0 in many systems that I see,
it means non-control, non-alpha, non-etc.
If you want 8859-1, just use proper locale.
>>>fixes some bugs in mklocale's lt_LN LC_CTYPE template.
>>BLANK fixes are incorrect, see isblank(3).
>Then the man page is wrong. The interpretation of blank on e.g. SVR4
>is that *only* '0x20' is a "blank". On at least one SVR4 system I have
>here this is documented as specified by ISO8859-1.
>Compatibility is a good thing. I think you should be compatible.
If SVR4 do it, it isn't enough reason to do it too. Since isblank()
isn't POSIX function, I prefer to see some standards and docs before
change current behaviour. If you know such docs, please point me.
>>XDIGIT fixes are right but ASCII locale used
>>for digits and xdigits in any cases.
>I'm not sure what this means.
It means that isdigit/isxdigit works independent of current locale.
They always refers to ASCII locale in FreeBSD. Ctype.h comment says that
it is done by following ANSI standard.
>>Other fixes which includes some additional big/lower letters probably
>>can go, I need to check 8859-1 description first.
>You can check if you want. :-)
After checking I agree with you for letters range, as I already
say I do commit based on this idea.
>>BTW, xterm is known to dump core when any of 8bit locales set,
>>f.e. ISO8859-1 or KOI8-R. color_xterm or mxterm works right.
>>Can you track this bug, please?
>What bug would this be? I'm not having any trouble at all running xterm
>in ISO8859-1 locales on FreeBSD 2.1.0-950922-SNAP (and I wouldn't have
>the first idea what to do in the KOI8-R locale :-)). You aren't by any
>chance using XFree86's xterm are you? If so report the problem to them.
xterm dumps core on startup when LANG variable set to one of
existen locales expect "C". This bug present in SNAP you mention.
Yes, I mean XFree86 xterm (I don't think they can be differ,
but I am not shure).
BTW, setting LANG to iso8859-1 does nothing, you need to specify
full name like fr_FR.ISO_8859-1. On your snap second underscore
maybe ommited, to be shure, check /usr/share/locale.
--
Andrey A. Chernov : And I rest so composedly, /Now, in my bed,
ache@astral.msk.su : That any beholder /Might fancy me dead -
FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead.
RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YlfXPWmmJ1>