* Zack Weinberg: > BUGS > Prior to POSIX.1-2024, there was no official guarantee that > close() would always close the file descriptor, even on error. > Linux has always closed the file descriptor, even on error, > but other implementations might not have. > > The only such implementation we have heard of is HP-UX; at least > some versions of HP-UX’s man page for close() said it should be > retried if it returned -1 with errno set to EINTR. (If you know > exactly which versions of HP-UX are affected, or of any other > Unix where close() doesn’t always close the file descriptor, > please contact us about it.) The AIX documentation also says this: | The success of the close subroutine is undetermined if the following | is true: | | EINTR The state of the FileDescriptor is undetermined. Retry the | close routine to ensure that the FileDescriptor is closed. <https://www.ibm.com/docs/en/aix/7.2.0?topic=c-close-subroutine> So it's not just HP-UX. For z/OS, it looks like some other errors leave the descriptor open: | EAGAIN | | The call did not complete because the specified socket descriptor | is currently being used by another thread in the same process. | | For example, in a multithreaded environment, close() fails and | returns EAGAIN when the following sequence of events occurs (1) | thread is blocked in a read() or select() call on a given file or | socket descriptor and (2) another thread issues a simultaneous | close() call for the same descriptor. | […] | EBADF | fildes is not a valid open file descriptor, or the socket | parameter is not a valid socket descriptor. <https://www.ibm.com/docs/en/zos/2.1.0?topic=functions-close-close-file>
