3 ms·

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

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

cesarb 8y ago
Do not confuse getchar(3) with read(2). From the manual page for read(2) (http://man7.org/linux/man-pages/man2/read.2.html http://man7.org/linux/man-pages/man2/read.2.html): 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.
- merlincorey 8y ago
  Ah yes, I did in fact mistake the function in question. I wonder why they chose not to use out of range values for EOF there, given that `getchar` surely predates `read`?
  - theoh 8y ago
    With read(), the return value is separate from the data read. It is arguably elegant to read as many characters as possible and to not consider hitting the end of the file as an error—just a point that can't be read beyond, like a stop on a piece of machinery. 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 https://en.wikipedia.org/wiki/Semipredicate_problem for some related thoughts.
    - merlincorey 8y ago
      Ah, yes, that Semipredicate problem article is very informative, thanks for sharing.
  - thatcks 8y ago
    I was going to assert that read significantly predates getchar, but it turns out that both may have existed from V1 Unix onward. However, getchar in V1 through V6 had a different EOF value from our familiar modern one of (-1); they all instead returned a 0 byte to indicate EOF. (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.)

cesarb 8y ago

Do not confuse getchar(3) with read(2). From the manual page for read(2) (http://man7.org/linux/man-pages/man2/read.2.html http://man7.org/linux/man-pages/man2/read.2.html): 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.

merlincorey 8y ago
Ah yes, I did in fact mistake the function in question. I wonder why they chose not to use out of range values for EOF there, given that `getchar` surely predates `read`?
- theoh 8y ago
  With read(), the return value is separate from the data read. It is arguably elegant to read as many characters as possible and to not consider hitting the end of the file as an error—just a point that can't be read beyond, like a stop on a piece of machinery. 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 https://en.wikipedia.org/wiki/Semipredicate_problem for some related thoughts.
  - merlincorey 8y ago
    Ah, yes, that Semipredicate problem article is very informative, thanks for sharing.
- thatcks 8y ago
  I was going to assert that read significantly predates getchar, but it turns out that both may have existed from V1 Unix onward. However, getchar in V1 through V6 had a different EOF value from our familiar modern one of (-1); they all instead returned a 0 byte to indicate EOF. (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.)