> or zero, which indicates either end of file,
EOF is not zero.
It cannot be, because it must be outside the range of `char`.
On my (linux) system, EOF happens to be -1.
This is explained in in the first chapter of K&R.
EOF is not zero.
It cannot be, because it must be outside the range of `char`.
On my (linux) system, EOF happens to be -1.
This is explained in in the first chapter of K&R.
On success, the number of bytes read is returned (zero indicates end
of file), and the file position is advanced by this number. [...]
On error, -1 is returned, and errno is set appropriately. In this
case, it is left unspecified whether the file position (if any)
changes.I wonder why they chose not to use out of range values for EOF there, given that `getchar` surely predates `read`?
With getchar(), the decision was made to return the char directly (to have used a pointer to a single char would be daft, from the point of view of economy) and to use an in-band code to indicate end of file. This "in-band signalling" is considered a bit of a kludge by some people. So I'd say read() is a better/cleaner design.
See https://en.wikipedia.org/wiki/Semipredicate_problem for some related thoughts.
(The V7 getc/getchar/etc manpage notes this as a BUG, although it doesn't specifically document what the V1-V6 EOF was. Presumably everyone who this was relevant for already knew. All of this is based on the historical Unix trees available through www.tuhs.org.)