From: jjf AT bcs DOT org DOT uk (J. J. Farrell)
Subject: Re: some unusual errors
24 Sep 1998 09:25:30 -0700
Message-ID: <199809232046.NAA04824.cygnus.gnu-win32@aleph.ssd.hal.com>
References: <36080502 DOT 41C6 AT delorie DOT com>
Content-Type: text
To: dj AT delorie DOT com (DJ Delorie)
Cc: gnu-win32 AT cygnus DOT com

> From: DJ Delorie <dj AT delorie DOT com>
> 
> J. J. Farrell wrote:
> > isspace() is prototyped as isspace(int); if the caller
> > were using the function version, then the prototype would
> > be effective, and the char would have been silently and
> > correctly widened to an int.
> 
> No, the char would have been silently and INcorrectly
> widened to a *signed* int, resulting in a range of values of
> -128..127.  That is not the legal range of values for the
> is*() functions.

You're still missing the point. A char is just a small integer.
A signed 8-bit 2's complement char has a range of values from
-128 to 127. If I assign one to a signed integer, the resulting
integer has exactly the same value as the signed char had.
Converting the parameter to an int in the macro would make no
difference whatsoever to the value of the parameter; but it
would make a call to the macro behave more like a call to the
equivalent function, in that it would get rid of the spurious
warning about a char being used as an array subscript.

> The legal range of values for is*() is 0..255 and EOF.  The
> automatic widening of a [default signed] char results in
> signed int values in the range -128..127.  You cannot rely
> on the automatic widening to give correct results.

Widening to an integer will make no difference to the result
- that's fundamental to my point; however, it will get rid of
the spurious warning message from the compiler.

Passing a signed char with the top bit set to a ctype function
results in undefined behaviour unless its value happens to
equal EOF. Converting it to an int makes no difference to this.

It's the caller's responsibility to make sure that the values
passed to the ctype routines are in the correct range; as long
as he does this, he can hold those values in whatever integral
type he likes - including signed char. If the type he chooses
can be automatically widened to an int by assignment (as is
the case with a signed char), then the prototype definition
for the ctype functions says that he can pass that parameter
in its original type to the function. He shouldn't end up with
spurious warnings from the compiler if he happens to be using
the macro version instead of the function.

> On a side note, using a signed char as the input makes it
> impossible to tell the difference between character 255 and
> the traditional EOF value of -1, as both have the same bit
> pattern (0xff) when stored in a signed char variable.

C doesn't guarantee that the value of EOF is different from
the value of some valid character anyway. Code that wants to
be portable to all Standard C implementations can't assume
that seeing an EOF value means end of file.

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".