Date:	Mon, 14 Jun 1999 10:18:24 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Morten Welinder <terra AT diku DOT dk>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: strtol
In-Reply-To:	<199906131429.QAA09339@tyr.diku.dk>
Message-ID:	<Pine.SUN.3.91.990614101719.21962C-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 Sun, 13 Jun 1999, Morten Welinder wrote:

> It's subtle.  If s is a "char *" or "signed char *" and c is an int,
> then after "c = *s;", c is -27.  isdigit is only defined in the
> range -1 to 255.  (EOF is -1.)

Right.

Funny, I was just fixing a similar bug in strlwr and strupr (reported
to the bug-tracker a few days ago) when I got your message.

I understand that either "c = *(unsigned char *)s;" or declaring c as
unsigned should fix these problems, right?  (strtol and other similar
functions don't call getc, so they don't have to be bothered with the
EOF nuisance.)

These problems appeared because before v2.02 the ctype macros were
ANDing the argument with 0xff, which failed with EOF, so the AND was
taken out.  It turns out that some library functions that used the
ctype macros relied on that behavior.

> While I am at it.  My Solaris manual says that tolower/toupper are
> defined for all ints, so toupper(123456789) returns 123456789.

Probably because Solaris is wchar-clean.  We aren't.  ANSI says the
argument to ctype macros is an int that can accept the value of EOF or
values representable by an unsigned char.

- Raw text -