Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!rbutterworth
From: rbutterworth@watmath.UUCP
Newsgroups: comp.lang.c
Subject: Re: is it really necessary for character values to be positive?
Message-ID: <4604@watmath.UUCP>
Date: Fri, 23-Jan-87 10:10:25 EST
Article-I.D.: watmath.4604
Posted: Fri Jan 23 10:10:25 1987
Date-Received: Sat, 24-Jan-87 04:49:44 EST
References: <44@houligan.UUCP> <5541@brl-smoke.ARPA>
Organization: U of Waterloo, Ontario
Lines: 31

In article <5541@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> Of course EOF can be defined differently; its only constraint is that
> it must be distinct from any possible valid value returned by getc()
> (which, by the way, does NOT sign-extend input chars).

I think this discussion is going around in circles again.
The reason for the question about EOF being allowed to have a
value that does not correspond to the int value of any char,
signed or unsigned, was to allow getchar() to be redefined to
return a possibly sign-extended value.

If getchar() returned such a value, it would simplify things and
solve a number of problems.  The only things that would be hurt
are those programs that "know" what EOF looks like.

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.

Similarly the is*() and to*() functions could be defined to work
on both string[7] and getchar() results.

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

Making EOF out-of-bounds allows getchar() to be defined differently
than it currently is, and thereby solves these problems.