Sender: bill AT taniwha DOT tssc DOT co DOT nz
Message-ID: <34D97B49.8CD32F82@taniwha.tssc.co.nz>
Date: Thu, 05 Feb 1998 21:41:45 +1300
From: Bill Currie <bill AT taniwha DOT tssc DOT co DOT nz>
MIME-Version: 1.0
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
References: <Pine DOT SUN DOT 3 DOT 91 DOT 980204194047 DOT 26711C-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Eli Zaretskii wrote:
> This thread was born out of a concern that our ctype functions don't
> support EOF.  ANSI C requires this support.  Knowing that funny things
> will happen in this case doesn't seem to help a bit when we face the sad
> conclusion that our libc is not fully compliant with the ANSI C standard.

Hmmm, tough to optimize.
 
> Can you suggest a change for the macros?

#define isalnum(c) ( ((unsigned)(c)>255) ? 0 :
__dj_ctype_flags[((c)&0xff)+1] & __dj_ISALNUM)

However, this will break all side-effect rules :(

So maybe:

#define isalnum(c) ({ unsigned _c=c; ((unsigned)(_c)>255) ? 0 :
__dj_ctype_flags[((_c)&0xff)+1] & __dj_ISALNUM; })

Will the above work and be satisfactory?  If isalnum is passed a signed
char, 0x80-0xff will ofcourse fail, even if locale says those chars can
be alnums (does that happen?).

Bill
-- 
Leave others their otherness.