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

[S.J.Leviseur]

In article <300 at bms-at.UUCP> stuart at bms-at.UUCP (Stuart D. Gathman) writes:
>In article <2221 at eagle.ukc.ac.uk>, sjl at ukc.ac.uk (S.J.Leviseur) writes:
....
>> 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.

It will work on any machine that allows signed chars (despite being ideologically
unsound!)

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

The case I was thinking of here is reading on a pipe. This seems to be
popular. The use of EOF is valid used in this context.

Another favorite is assigning the result of getchar to a char and then
testing to see if the char is -1.

There are others ....

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

Yes, worse luck :-(