Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!brl-adm!rutgers!clyde!cuae2!ltuxa!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: comp.lang.c,comp.std.internat
Subject: Re: draft ANSI standard:  one change that would *really* help Europe
Message-ID: <1391@ttrdc.UUCP>
Date: Mon, 8-Dec-86 00:44:16 EST
Article-I.D.: ttrdc.1391
Posted: Mon Dec  8 00:44:16 1986
Date-Received: Mon, 8-Dec-86 20:44:22 EST
References: <1382@hoptoad.uucp> <8322@lll-crg.ARpA> <2221@eagle.ukc.ac.uk>
Organization: AT&T, Computer Systems Division, Skokie, IL
Lines: 30
Xref: mnetor comp.lang.c:305 comp.std.internat:33

In article <2221@eagle.ukc.ac.uk>, sjl@ukc.UUCP writes:
>Actually this breaks *LOTS* of programs. We have a compiler with unsigned
>chars on some of our machines. This causes endless problems with what is
>'affectionately' known as the "EOF bug".
>The implementors of that compiler said it was the first thing they would
>alter if they reimplemented it because of the number of problems it caused.
>If you want to see for yourself have a look through your sources and find
>every occurence of a comparision between EOF or -1, and a char. Typically,
>where cp is a character pointer:-
>		if (*cp == EOF)
>	or
>		while (*cp != EOF)
>Older code is littered with these constructs.
>	sean

Ugh.  "Littered" is the right term.  Not only is this nonportable, it will
be FOOLED on systems where it normally works (signed char, 2's complement
representation) given the character '\377'.  So if you getchar(), say, upon
an arbitrary binary file and you are looking for EOF you are likely scr*wed
with this kind of code.

EOF is meant to be an out-of-band value for things like getchar() etc.
That's why they return int, and not char.

(Lint should warn about this kind of comparison.  I have learned the slow,
hard way that when I get C code from elsewhere, yes even the mighty BTL, I
lint it first and fix the warnings before compiling on a system other than
from whence it came!)

Dan