Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.lang.c
Subject: Re: is it really necessary for character values to be positive?
Message-ID: <5571@brl-smoke.ARPA>
Date: Wed, 28-Jan-87 01:16:10 EST
Article-I.D.: brl-smok.5571
Posted: Wed Jan 28 01:16:10 1987
Date-Received: Thu, 29-Jan-87 05:48:39 EST
References: <44@houligan.UUCP> <5541@brl-smoke.ARPA> <4604@watmath.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 24

In article <4604@watmath.UUCP> rbutterworth@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.