Date:	Mon, 14 Jun 1999 18:18:09 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: strtol
In-Reply-To:	<Pine.LNX.3.93.990614165247.31120G-100000@acp3bf>
Message-ID:	<Pine.SUN.3.91.990614181221.24744A-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 14 Jun 1999, Hans-Bernhard Broeker wrote:

> It may work, but it's a bit unclear. The cast to (unsigned char) would be
> cleaner, I think. Or, for that matter, defining c as an unsigned char
> variable straight away.

Thanks for the feedback.

I agree that these might be cleaner, but as we are (I hope) very close to 
releasing v2.03, I wanted a change that was as local as possible.  The 
cast is impossible to do without non-trivial changes to the code (it 
assigns to c once and then uses c throughout), and declaring c unsigned 
char instead of int can have unexpected results elsewhere in the code, 
since c participates in integer computations of the return value.

> The rule is simple: a char that is to be passed to a <ctype.h> functions
> must either already *be* a unsigned char, or be casted into one. 

Where is this rule spelled out?  ANSI says that ctype functions accept an 
int, including EOF (which cannot be casted to unsigned char; fixing that 
in v2.02 was the reason these bugs came into existence in the first 
place).

- Raw text -