5 ms·
I don't totally get this.. isn't it in the nature of reading via read(2) that it is possible it reads some data and then errors? If this is indeed reflected in
by radiospiel 7y ago
I don't totally get this.. isn't it in the nature of reading via read(2) that it is possible it reads some data and then errors? If this is indeed reflected in the io.Reader.Read interface, then - regardless of who is allocating the buffer - the caller must evaluate both the result and the error.
It would indeed be possible in that scenario to return the buffer, and to return the error in a subsequent call, but this seems to change its behaviour into one that (to me) is surprisingly different.
The same is true for writing; write(2) can write some, but not all of the passed in data, and then err. What kind of API would one want tosee here?
- dooglius 7y agoI don't think this is correct, the return value is either -1 (an error) or a length is returned.
- EpicEng 7y ago>What kind of API would one want tosee here? In C it's almost always Length | error_code
- DSMan195276 7y agoDepends on your definition, in C a partial read or write isn't considered an error. You can't have both 8 bytes read and also get an EIO, it would have to be one or the other. It depends on the device and the why the read/write stopped that determines if you get an error like EIO or it just reports less bytes than you asked.
- heavenlyblue 7y ago>> The same is true for writing; write(2) can write some, but not all of the passed in data, and then err. What kind of API would one want tosee here? If OS "writes some bytes and then errors" - then for the current call write(2) will return the number of bytes written, and then on the next call you'll get the returned error.