"Laurent Bercot" wrote:
> If you are in the rare case where you need to check the return code from
> close(), then you should probably use close() directly, not a wrapper
> around it.
I wouldn't go quite that far--I'd say a wrapper to handle EINTR is
useful in either case--but I agree that it's
I think that depends on the situation. In many cases, you're right,
there is nothing the program can do about the failure. But in a
program with user interaction, for example, it may make sense to
prompt the user to retry or ignore the failure.
Abort, Ignore, Retry?
Remember that dreaded
"Laurent Bercot" wrote:
> If a destructor fails, there is no good decision you can make.
I think that depends on the situation. In many cases, you're right,
there is nothing the program can do about the failure. But in a
program with user interaction, for example, it may make sense to
prompt
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
On 27.04.20 13:30, Laurent Bercot wrote:
Hi Laurent. It's been a while. :)
Long time no see. :) We'd love to have you on #s6, if you can!
I'm updating my packages to catch up with skalibs, gcc warnings, etc.,
and fd_close() returning void is one of the changes that hit me.
Looking over
Hi Laurent. It's been a while.
:)
Long time no see. :) We'd love to have you on #s6, if you can!
I'm updating my packages to catch up with skalibs, gcc warnings, etc.,
and fd_close() returning void is one of the changes that hit me.
Looking over past discussions, I agree that POSIX is a
Hi Laurent. It's been a while. :)
I'm updating my packages to catch up with skalibs, gcc warnings, etc.,
and fd_close() returning void is one of the changes that hit me.
Looking over past discussions, I agree that POSIX is a mess
here--nevertheless, given that close() is the way it is, I think
