Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site basser.SUN
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!floyd!cmcl2!seismo!hao!hplabs!sdcrdcf!sdcsvax!dcdwest!ittvax!decvax!mulga!munnari!basser!chris
From: chris@basser.UUCP
Newsgroups: net.unix-wizards
Subject: ((c = getc(stdin)) == EOF) retraction
Message-ID: <310@basser.SUN>
Date: Thu, 31-May-84 20:58:01 EDT
Article-I.D.: basser.310
Posted: Thu May 31 20:58:01 1984
Date-Received: Tue, 5-Jun-84 19:42:40 EDT
Organization: Dept of C.S., University of Sydney
Lines: 26

[]
Oops, I made a mistake (or misread) when I said that the
above works if 'c' is a "char". The C reference manual section
6.1 (Characters and integers) says (quite explicitly) that 
"whether or not sign extension occurs for characters is machine
dependent...".

In other words, on lots of machines out there, that code will fail.
In any case, you need a return value bigger than a "char" to distinguish
between the set of valid characters and the EOF case.

It's my personal belief (and one I believe is shared by Mr Ritchie) that
C compilers which take the easy way out for their architecture by making
"char"s unsigned are unfortunate.  After all, what is the difference
between "char" and "unsigned char" with such compilers, and how are you
supposed to use 8 bit signed integers, except by hand? 

The C manual is apparently protecting the behaviour of C compilers from
the days before "unsigned" (sigh).

Special thanks for "dap:mulga" for correcting me on this. I have quoted
from the reference manual supplied with V7 UN*X above. I don't have a
copy of "The C programming language" to hand.

Chris Maltby
University of Sydney.