Comment by jerf
Another reason failing to check errors from "close" is in practice less of a big deal than some people seem to think is that if close fails, there's often nothing to be done about it. If it fails the odds that just retrying is going to work are pretty low. If it's not interactive there may not even be a human to notify. I've actually been trying to be better about this but so often the only practical difference is that hopefully a log line comes out and the reason the close failed won't also have trashed the log itself. And it becomes very hard to test because close doesn't actually fail all that often. If close failures are 0.000001% of my theoretical failure space I'm much more worried about the 5% cases.
I'm not saying to casually not care, exactly, I'm just saying that there are some solid reasons why very few programs "correctly" handle this, yet largely, life has gone on and compared to, say, failures to correctly encode output or failures to enforce permissions this is noise.
After close() was called on a file descriptor, that descriptor is gone as long as close() returns something other than EBADF. So if what you've closed is not a "regular" file, you can't even re-open it to retry; and what writes would you even have to retry anyhow? Not to mention about the position to seek to.