is it really necessary for character values to be positive?

gwyn at brl-smoke.UUCP gwyn at brl-smoke.UUCP
Wed Jan 28 16:16:10 AEST 1987


In article <4604 at watmath.UUCP> rbutterworth at watmath.UUCP (Ray Butterworth) writes:
>But if getchar() were to be so changed, then things like
>    int c=getchar();
>	if (c!=EOF){
>        if (c==string[7])
>would work correctly.  Under the current definition, "c" is not
>sign extended but string[7] might be sign extended and the
>comparison will fail even if the two characters are in fact the same.

This is actually a consequence of the sloppy-signedness of "plain"
char.  If string[] is an array of unsigned chars, or if one uses
an explicit (unsigned char) cast on the right side (or a (char)
cast on the left side), your example will work under the current
rules.

>I don't know of any advantage or purpose to the current getchar()
>behaviour.

It had the "advantage" of returning a single value rather than two.
This fit in with common style and supported things like
	while ( (c = getchar()) != EOF )
		putchar( c );
It is certainly too late to change the getchar() interface, even if
one agrees that it "should" have been designed differently.



More information about the Comp.lang.c mailing list