Date: Thu, 5 Feb 1998 11:48:02 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: DJ Delorie <dj AT delorie DOT com>
cc: djgpp-workers AT delorie DOT com
Subject: Re: char != unsigned char... sometimes, sigh
In-Reply-To: <199802050213.VAA14414@delorie.com>
Message-ID: <Pine.SUN.3.91.980205114743.28596C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Wed, 4 Feb 1998, DJ Delorie wrote:

> OK, then, how do we fix it? Is there ever a case where the is*()
> functions/macros *care* if it's EOF or 0xff?  The only ones I know of
> are tolower/toupper, which return 0 for EOF (funny, toupper/tolower
> return *unsigned* char!).  If we change that to return 0xff for EOF,
> then it won't matter if EOF==0xff, and we can just mask the value
> we're given with 0xff and be done with it (not even add 1).

You could always treat EOF as a special case in toupper/tolower.

However, frankly, I don't understand why do we need at all to AND with
0xff (but then I never understood the intricacies of signed vs
unsigned char, either).  Is it only to prevent users of ctype to read
beyond the end of the __dj_ctype arrays?  If so, I'm not sure we need
to go through such trouble out of user safety concerns: it's IMHO
contrary to C design.

If ANDing with 0xff is not a requirement, we could say something like
this:

 static unsigned short ctype_flags[] = {
   ... /* put here what's now in __dj_ctype_flags[] */
 };

 unsigned short *__dj_ctype_flags = &ctype_flags[1];

and then define the macros like this:

 #define isalnum(c)  (__dj_ctype_flags[(int)(c)] & __dj_ISALNUM)

which should work with EOF and 0xff alike.

Is anything wrong with this way?