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