Date:	Mon, 9 Feb 1998 13:47:16 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>, DJ Delorie <dj AT delorie DOT com>,
	djgpp-workers AT delorie DOT com
Subject:	Re: char != unsigned char... sometimes, sigh
In-Reply-To:	<Pine.SUN.3.91.980208135023.6339N-100000@is>
Message-ID:	<Pine.LNX.3.93.980209133727.31635E-100000@acp3bf>
MIME-Version:	1.0

On Sun, 8 Feb 1998, Eli Zaretskii wrote:

> Negative numbers from the signed char range do not belong to the
> unsigned char range.  People who use signed char for characters with
> ASCII code beyond 127 write buggy code; they should use unsigned char
> instead.

Exactly. That's why Plauger says that you have to call them as in
'isalpha((unsigned char)c)' if there's any chance that c might be
a 'negative char'. 

> I agree that it would be nice to have the ctype functions/macros
> support the cases such as `(char)0x84', but if that support causes the
> library to break ANSI compliance, and no viable solution could be
> found, I have no problems with unsupporting it.

You can support all input values except ((unsigned char)EOF), i.e. 
(char)0xff, by using a table of 256+128 entries. But then, correcting what
is really incorrect use of these function for _almost_ all values isn't
useful enough to pay the overhead. 

Heck, I'd even prefer an implementation that just abort()s if any netagive
value other than EOF is passed in, with a message like 'isalpha() called
incorrectly: argument < -1'. If I'm not totally mistaken, this'ld still be
ANSI-compliant, but we'ld catch almost every erroneous use of the
function, forcing the users to correct their programs. Such behaviour
should be documented, of course, so the users get the problem explained by
looking up the function in the libc docs. 

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -