Re: A question regarding Q20.1 from c-faq.com

santosh wrote:
James Kuyper wrote:

Mark McIntyre wrote:
jameskuyper@xxxxxxxxxxx wrote:
I would disagree; for the small set of routines where EOF is
returned through the same channel as valid characters, relying
solely upon an EOF value to diagnose an error/eof condition is the
wrong approach,
Why? The standard requires the functions to return EOF on an error
condition. It seems to me entirely reasonable for a programmer expect
to be able to rely on a guaranteed behaviour.
Yes. However, the standard does not prohibit getc() from returning EOF
when there is no end of file and no error condition. A programmer who
assumes that a value of EOF indicates only those two possibilities is
relying upon a guarantee not actually provided by the standard (though
it is something that is actually true on most real implementations,
explaining the popularity of that assumption).

The intent of the Standard was for an EOF return to indicate end-of-file
or error.

There's considerable reason to believe that C89 was written without considering the possibility of UCHAR_MAX > INT_MAX. However, I know for a fact that this issue was discussed on comp.std.c before C99 was approved, and that several actual committee members participated in that discussion. Therefore, I believe that this possibility was considered when C99 was written. Yet, neither C99 nor any of the TCs contains any changes that clarify this issue. Therefore, I believe that the standard, as currently written, does indeed reflect the intent of the committee.

As currently written, there's nothing in the standard about EOF exclusively indicating end-of-file or an error, only wording indicating that and end-of-file or error will cause a return value of EOF.

7.19.1 (3)

EOF

which expands to an integer constant expression, with type int and a
negative value, that is returned by several functions to indicate
end-of-file, that is, no more input from a stream;

Sure, but does that mean that value of EOF must only mean end-of-file? The very same functions we're talking about (and many others as well) also use EOF to indicate an I/O error, not and end-of-file. The wctob() function is defined as returning EOF for reasons that have nothing to do with I/O.

Taken to it's extreme, your argument would imply that no function is allowed to return a value equal to the value of EOF unless it indicated end-of-file. That would be a rather obscure constraint to apply to, for instance, the atoi() function.

....
What mandatory requirement does the standard impose which prohibits
getc() from returning EOF when it successfully reads a byte from the
file?
....
If this is not so, then why have these functions return an int value at
all? They could return an ordinary unsigned char or char value and the
programmer could be told to verify feof and ferror after each and every
read.

EOF would become essentially meaningless on such systems.

C was originally developed on a system where all the char types were 8 bits and int was larger (probably 16 bits, but I don't know for sure). The interface for getc() was chosen when similar systems were the only ones being considered. I doubt very much that C89 was written with the possibility of UCHAR_MAX>INT_MAX in mind. However, it didn't prohibit that possibility, and that possibility can be worked-around, and C99 was approved without any changes addressing that issue, which had been brought up by that time.
.

Relevant Pages

  • Re: Anyone object to the following change in libc?
    ... TL>> specifier. ... Is it an EOF? ... TL>ISO C standard" refers to "c89", which is the version of the C ... "The c89 utility (which specified a compiler for the C Language specified ...
    (freebsd-current)
  • Re: Internal read from parameter
    ... mustn't be allowed to write to a parameter, but why does the standard ... feature request. ... lists. ... integer:: eof, i ...
    (comp.lang.fortran)
  • Re: do_ud: end of file
    ... Eof is not an error. ... The standard quite deliberately avoids defining that particular error ... The standard wouldn't want to insist that implementations ... are changing the basic concept of direct access files. ...
    (comp.lang.fortran)
  • Re: reading exact contents of a line
    ... > Apparently there are a few compilers that violate the standard by ... > that more than one EOF value is allowed is that a few compilers happen ...
    (comp.lang.fortran)
  • Re: reading exact contents of a line
    ... Apparently there are a few compilers that violate the standard by ... having more than one EOF value. ...
    (comp.lang.fortran)