Date:	Sun, 8 Feb 1998 13:51:13 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
cc:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>,
	DJ Delorie <dj AT delorie DOT com>,
	djgpp workers list <djgpp-workers AT delorie DOT com>
Subject:	Re: char != unsigned char... sometimes, sigh
In-Reply-To:	<34DAC80D.1EC@rug.ac.be>
Message-ID:	<Pine.SUN.3.91.980208135053.6339O-100000@is>
MIME-Version:	1.0

On Fri, 6 Feb 1998, Vik Heyndrickx wrote:

> This thread was re-born (renaissance?). I originally started this thread
> out of the concern that many users don't understand that (char)'\x84' is
> less than 0, and I requested to modify the default of "char". Only later
> I ran into these buggy is* macros, which don't work well primarily
> because of the current default of "char". It may seem that this last
> reason was the only reason to change it, but it certainly is not.

For me, ANSI compliance is the main concern.  Anything else is
secondary to it.  If the current version is not ANSI-compliant, IMHO
it should be fixed ASAP.

However, making untrivial changes with global consequences, such as
switching to unsigned char by default, just to make buggy code
magically turn correct is not my idea of a small change in a minor
release.

> > In the 'C' locale: probably no. But who knows: maybe there is some locale
> > that has actually quenched a printable character into this position? Well,
> > on looking it up: there is! According to a Linux man page, 0xff is 'LATIN
> > SMALL LETTER Y WITH DIAERESIS' in ISO-Latin-1. So in that locale,
> > 'isgraph(0xff)' should return 1, and our implementation can't do that :-(
> 
> :-)

The issue with non-C locales doesn't belong to this discussion.
AFAIK, a non-C locale will need to override the ctype functions
anyway, if only to deal with non-English capital letters which have
ASCII codes beyond 127.

- Raw text -