io::reader::read_byte for *FILE behaves surprisingly on EOF

[catamorphism]

In the io::reader impl for *libc::FILE, read_byte returns -1 on EOF. This is not surprising since it just calls libc::fgetc, but it's arguably wrong since callers are presumably going to use eof() to check for EOF and thus shouldn't have to worry about dealing with a bogus trailing -1.

Instead, perhaps it could fail? I'm not really sure. Or maybe this is supposed to be a low-level interface, but it still seems weird for Rust code to have to deal with sentinel values like this.

[catamorphism]

This came up with https://gist.github.com/8f81d3e2b39f31cca1cc -- maybe the real issue is that libc::eof is returning false one byte past when it should? I'm not really sure.

[Havvy]

java.lang.Scanner uses hasNext() to say whether or not the file has anymore contents. Why not keep io::reader.eof for its low-level impl and add io::reader.has_next for that use case?

[Havvy]

Since that gist is mine, I'd like to say that I find it odd I had to do a cast to get it in a format that is usable to convert to a str. I'd like read_str to return a u8 just to avoid the cast operation which feels inefficient to me.

[graydon]

I believe this is going to be completely gutted soon, and in the process I expect reading past EOF to become a condition. Consider this as a sub-bug of #6169 and/or #6168

[graydon]

still legit but still, I suspect, likely to be absorbed in the IO rewrite. Any day now.

[catamorphism]

New IO should solve this problem, but if you add a test, you can close this :-)

[alexcrichton]

This code has long since been purged, closing.