>Ignoring errors on close isn't good enough for reliably composable programs.
close() generating errors isn't good enough for reliably composable
programs.
Yes, it's a problem. Fixing it isn't my job. It's the job of the
person who implements close().
> I agreee that POSIX semantics for close(2) are a mess, but your assumption that close can't fail isn't true.
Well, they will have to be. And if they're not, complain to the author
of close().
> Lets say a trival program wants to append to a file so it opens the file, writes to the end, closes the file. The network file systems like NFS and AFS flush the caches on close for historic reasons.
Well, yes, it's been known for a while that network file systems cannot
safely implement a (sane) POSIX API.
> A simple if ( !close(fd) ) exit(1); at least admits there is a problem even it just passes the buck to its parent. I can imagine few things worse in than *silient* data corruption in an API.
Yeah, and the problem *is not solvable*, not by you, not by the parent,
not by anyone. If a destructor fails, there is no good decision you can
make. I choose to assume they don't. You choose to exit, and that's
valid too, although abort() would probably be more suited than exit(1);
and you can reasonably argue that fd_close() should abort(), instead of
returning, if close() fails - that's a discussion we can have. But it
should still return void. If it returns, it succeeded.
--
Laurent
Received on Mon Apr 27 2020 - 15:36:19 UTC