Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!vrdxhq!bms-at!stuart
From: stuart@bms-at.UUCP (Stuart D. Gathman)
Newsgroups: comp.lang.c,comp.std.internat
Subject: Re: draft ANSI standard:  one change that would *really* help Europe
Message-ID: <300@bms-at.UUCP>
Date: Sun, 7-Dec-86 21:05:20 EST
Article-I.D.: bms-at.300
Posted: Sun Dec  7 21:05:20 1986
Date-Received: Mon, 8-Dec-86 02:05:34 EST
References: <1382@hoptoad.uucp> <8322@lll-crg.ARpA> <2221@eagle.ukc.ac.uk>
Organization: Business Management Systems, Inc., Fairfax, VA
Lines: 34
Summary: Not us!
Xref: mnetor comp.lang.c:299 comp.std.internat:31

In article <2221@eagle.ukc.ac.uk>, sjl@ukc.ac.uk (S.J.Leviseur) writes:

> >>[John thinks that perhaps "char" should be unsigned - most programs
> >  would be more correct since they assUme that chars are unsigned]

> 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".

> 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)

> 		while (*cp != EOF)

Not in our code!  This type of code is not likely to work, even under K & R.
ANSI is only trying not to break *legal* programs.  The above essentially
is trying to use 255 (or whatever) instead of 0 as a string terminator.
Even if there was a legitimate reason for this, EOF is the wrong name
to use since it is _already defined as a return value of stdio functions_.

This code was broken already.

It's too bad that type checking doesn't can this sort of thing.  I wish
there was a way to define an enum type that is either a char or EOF, and
declare stdio functions to return that type.  Then if only enum weren't so
loose about converting to other types without a cast.  Sigh.

P.S.  Are you trying to tell me that official unix utilities are written like
that?
-- 
Stuart D. Gathman	<..!seismo!dgis!bms-at!stuart>