draft ANSI standard: one change that would *really* help Europe

[Stuart D. Gathman]

In article <2221 at eagle.ukc.ac.uk>, sjl at 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>