Hi! On Thu 15-05-25 23:33:22, Alejandro Colomar wrote: > I'm updating the manual pages for POSIX.1-2024, and have some doubts > about close(2). The manual page for close(2) says (conforming to > POSIX.1-2008): > > The EINTR error is a somewhat special case. Regarding the EINTR > error, POSIX.1‐2008 says: > > If close() is interrupted by a signal that is to be > caught, it shall return -1 with errno set to EINTR and > the state of fildes is unspecified. > > This permits the behavior that occurs on Linux and many other > implementations, where, as with other errors that may be re‐ > ported by close(), the file descriptor is guaranteed to be > closed. However, it also permits another possibility: that the > implementation returns an EINTR error and keeps the file de‐ > scriptor open. (According to its documentation, HP‐UX’s close() > does this.) The caller must then once more use close() to close > the file descriptor, to avoid file descriptor leaks. This di‐ > vergence in implementation behaviors provides a difficult hurdle > for portable applications, since on many implementations, > close() must not be called again after an EINTR error, and on at > least one, close() must be called again. There are plans to ad‐ > dress this conundrum for the next major release of the POSIX.1 > standard. > > TL;DR: close(2) with EINTR is allowed to either leave the fd open or > closed, and Linux leaves it closed, while others (HP-UX only?) leaves it > open. > > Now, POSIX.1-2024 says: > > If close() is interrupted by a signal that is to be caught, then > it is unspecified whether it returns -1 with errno set to > [EINTR] and fildes remaining open, or returns -1 with errno set > to [EINPROGRESS] and fildes being closed, or returns 0 to > indicate successful completion; [...] > > <https://pubs.opengroup.org/onlinepubs/9799919799/functions/close.html> > > Which seems to bless HP-UX and screw all the others, requiring them to > report EINPROGRESS. > > Was there any discussion about what to do in the Linux kernel? I'm not aware of any discussions but indeed we are returning EINTR while closing the fd. Frankly, changing the error code we return in that case is really asking for userspace regressions so I'm of the opinion we just ignore the standard as in my opinion it goes against a long established reality. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
