Date: Mon, 9 Feb 1998 13:29:37 +0100 (MET)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
To: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
cc: 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.LNX.3.93.980209132222.31635C-100000@acp3bf>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk

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". 

And that's exactly the point: they *aren't* buggy in this respect. It's an
error to call any of the is* functions or macros with any negative
argument other than EOF. That's what the ANSI standard says.

> > If the passed 'c' is of type int, and its value is
> > -1, then the result has to be different from the one you get by passing it
> > 255.
> Not necessarily, but it should allowed to be different.

Yes. That's what I wanted to express, but obviously failed to do precisely
enough. 

> > > The only ones I know of are tolower/toupper, which return 0 for EOF
> > > (funny, toupper/tolower return *unsigned* char!).
> > 
> > Not really. They return an *int*, which in turn is the result of casting
> > an unsigned char to int. At least, that's what they *should* do.
> 
> They don't work for EOF.

As they currently are: may be not (haven't looked at them to remember). 
If they don't work, that has to be fixed, and *only* that. 

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