Mail Archives: djgpp-workers/1998/02/05/04:52:10
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?
- Raw text -