Date: Mon, 9 Feb 1998 13:47:16 +0100 (MET) From: Hans-Bernhard Broeker To: Eli Zaretskii cc: Vik Heyndrickx , DJ Delorie , djgpp-workers AT delorie DOT com Subject: Re: char != unsigned char... sometimes, sigh In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.