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
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
Precedence: bulk


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).