Date:	Wed, 4 Feb 1998 19:47:00 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Bill Currie <bill AT taniwha DOT tssc DOT co DOT nz>
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
In-Reply-To:	<34D7FD21.36B4842A@taniwha.tssc.co.nz>
Message-ID:	<Pine.SUN.3.91.980204194047.26711C-100000@is>
MIME-Version:	1.0

On Wed, 4 Feb 1998, Bill Currie wrote:

> Even if these functions were implemented as functions rather than
> macros,

DJGPP has both macros *and* functions.  It is actually a requirement of 
the ANSI standard that each function implemented as a macro has also a 
real function version in the library (so that you could, for example, 
pass its address to some other function).

> it wouldn't one bit of difference, passing a char (signed,
> unsigned or ambiguous) would ALWAYS cause `unexpected' results, the
> compiler will always do something funny when it extends the bits.

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.

> So really, the djgpp ctype.h header file should just make sure c is in
> the right range (don't want array bounds checking to fail) and be done
> with it. Forget about coping with `char's of any flavour, they're
> irrellevant.

Can you suggest a change for the macros?

- Raw text -