On 04/02/14 03:47, Bill Myers wrote:
Are we sure that this is the correct design, as opposed to having read return 0 for EoF or
perhaps returning None with a Result<Option<int>, IoError> return type?
After all, EOF is unlike all other I/O errors, since it is guaranteed to happen
on all readers, and the fact that it needs to be special cased might be an
indication that the design is wrong.
Also, in addition to "raw" eof, a partial read due to end of file causes the
same issues, so it seems that code needs to have two match conditions to handle eof,
while it would only need a single one if eof was represented by Ok(0).
This makes a lot of sense.
Although I wonder if the issue isn't more of a distinction between two
use-cases:
read_up_to_n_bytes(stream_buf, n)
vs:
read_n_bytes(my_struct, n)
In the first, you intend to only read as much as possible, within some
limit, then decode it. In the second, you intend to read a specific
amount, because that's what's REQUIRED by your file format spec.
Another approach I've use for handling this is to distinguish:
read(buf, n): definitely read the next n bytes, or fail --
used when you know what should be next. This moves the cursor, and
probably consumes internal file buffers
peek(buf, n): attempt to read n bytes, if available, for
later decoding -- used for lookahead, when you don't know what's next,
and want to check. This does NOT move the cursor, and possibly buffers
more data for a later read()
Note that this approach works well for buffered infinite streams, as
well as files.
--
Lee
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
