Re: May close() return any error code?

Al Viro
2015-08-02T13:57:30Z

On Sun, Aug 02, 2015 at 09:42:20AM +0200, Pavel Machek wrote:
> > This seems coming from evdev_flush(). As there is no fd leak, it's no
> > big problem per se. But, now the question is whether returning such
> > an error code is correct behavior at all. At least, it doesn't seem
> > defined in POSIX:
> >
> http://pubs.opengroup.org/onlinepubs/009695399/functions/close.html
>
> Returning an error from close() would imply that file descriptor is
> not closed.... seems like bad idea. Just fix the kernel not to do it.

The only thing implied here is failure to RTF{M,S}. To quote close(2):

NOTES
Not checking the return value of close() is a common but nevertheless
serious programming error. It is quite possible that errors on a pre‐
vious write(2) operation are first reported at the final close(). Not
checking the return value when closing the file may lead to silent loss
of data. This can especially be observed with NFS and with disk quota.
Note that the return value should only be used for diagnostics. In
particular close() should not be retried after an EINTR since this may
cause a reused descriptor from another thread to be closed.

That's Linux one. FreeBSD one says

In case of any error except EBADF, the supplied file descriptor is deal-
located and therefore is no longer valid.

and that matches behaviour of historical BSD variants as well. POSIX is being
its usual charming self and says "if a kernel shipped by $VALUED_MEMBER does
this and that cretinous thing, far be it from us to call it broken".