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.