Some of you might have been surprised to
see my opinion in source code (if you ever
looked) that reading only should require
verification and not writing. That is,
err = write(..., length) == length
is wrong.
The computer can't know what you meant to write.
Think of it like this, using logic. You write something. How do you know you made no mistakes? You read it.
It is insane for a computer to make a guarantee that you wrote what you tried to write. The sole purpose for the return value of write() is to make sure the system is working, no pipes are broken, etc. Very good--maybe.
If everything works, everything is working. So what if it breaks?
Ordinarily the computer treats things you write into as files--no matter what they really are, they are opened and closed, and accessed with file descriptors. What could possibly go wrong that makes a write fail? We don't know, and we don't care. The operating system's is to try as hard as possible to do its job, and only then allow failure. If a write fails, it is not a trivial thing. The output stream must be broken.
If an output stream is broken, to a program that means it disappears. The system has got to throw up its hands and say "broken pipe!" or whatever the error has been. The file descriptor is then disposed as worthless, and nothing could be written to it anyway--if the operating system's guarantees may be trusted.
Rather than saying "I guess I could only write 500 bytes of your message," the computer must admit that nothing else can be written. The value of the file handle changes to null. If a program ignores it, it is blown out of the water.
(The operating system has got to be good for something.)
8-26-03. In other words, the real failure is a binary failure: could or could not write. The indication that only so many bytes of your message could be written / "please try again later" is a false indication. The entire contents that you tried to write are worthless. You cannot pretend that 4000 of your 4024 bytes were saved, but now your disk has just run out of space.
1-11-04. To clarify: this applies to blocking I/O. Non-blocking operations have a different meaning of "try."