Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!cs.uoregon.edu!ogicse!intelhf!ichips!iwarp.intel.com!inews!nevin!bhoughto
From: bhoughto@nevin.intel.com (Blair P. Houghton)
Newsgroups: comp.lang.c
Subject: Re: getchar and EOF (was: One more point regarding = and == (more flamage))
Message-ID: <3727@inews.intel.com>
Date: 9 Apr 91 06:32:39 GMT
References: <3465@litchi.bbn.com> <1991Apr4.215605.2801@syssoft.com> <1991Apr7.064003.8552@athena.mit.edu>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 28

In article <1991Apr7.064003.8552@athena.mit.edu> scs@adam.mit.edu writes:
>I was going to say that "EOF is guaranteed not to compare equal
>to any char value," but this is not really true.  If you have
>
>	signed char c = '\377';
>
>and EOF is -1, then c == EOF will succeed.  ("signed" is a new
>ANSI C keyword; the test also succeeds if c is a "plain" char, on
>machines for which plain chars are signed.)

This is a strong example of the oft-forgotten distinction that
`char' is a datatype that implies bytes rather than characters.

If one could assume only characters, then (barring
locale-specific features) one can assume (7-bit) ascii,
which has values only from '\0' to '\177', obviating this
confusion with `(signed char)(-1)'.  But one can't, so one
shouldn't (the ascii-only assumption is bogus at the
outset, since it ignores the loadable (8-bit) fonts of most
ANSI terminals, of which DEC VT character terminals are a
near conformant).

But like I said before, anything much more complex than
7-bit ascii usually deserves more care than getchar(3).

				--Blair
				  "Trigraphs? We don' got no trigraphs...
				   We don' need no steenking trigraphs!"