Hacker News Reader

Comment by merlincorey | Hacker News Reader

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

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

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 for some related thoughts.

Ah, yes, that Semipredicate problem article is very informative, thanks for sharing.

Reply on news.ycombinator.com