Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP
Path: utzoo!linus!vaxine!wjh12!genrad!decvax!ittvax!dcdwest!sdcsvax!sdcrdcf!hplabs!hao!seismo!rlgvax!guy
From: guy@rlgvax.UUCP
Newsgroups: net.unix-wizards
Subject: Re: getc() != EOF
Message-ID: <1949@rlgvax.UUCP>
Date: Fri, 25-May-84 21:39:06 EDT
Article-I.D.: rlgvax.1949
Posted: Fri May 25 21:39:06 1984
Date-Received: Mon, 28-May-84 06:10:40 EDT
References: <1138@sri-arpa.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 24

> In all conscience,

> 	while ( (c = getc()) != EOF )

> ought to work.  If somebody is to be blamed, it is surely not the
> people who wrote the code, but the people who made a C implementation
> that broke it.

Assuming you're referring to the case where "c" was declared as "char" and
it didn't work, the code was incorrect.  "getc" is documented as returning
an "int".  The reason is that it is desirable that it can return all possible
values that fit into a "char" (in the manual page it says "Getc returns the
next character (i.e., byte)), but if it returned a "char" there would be
no distinguished value which would indicate EOF.  It "ought to work" only
if 1) it is defined not to work except on 7-bit ASCII text files (or, at least,
files not containing the character '\0', or '\377', or '\351', or whatever
your choice for EOF is) or 2) it is defined as returning an "int", so that
in addition to all possible one-byte values it can also return a distinguished
value for EOF.  Consider this as possibly a weak vote for languages in
which a procedure (or expression; "getc" is a macro in UNIX) can return a
success/failure indication as well as a value.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy