|
Description |
There are three issues with the description of opendir() related to the fd associated with a directory stream.
1. The phrase "If the type DIR is implemented using a file descriptor" is problematic, given that dirfd() no longer has an ENOTSUP error. I.e. For Issue 8, DIR always has the ability to store a fd; the optionality now is not if but when: the fd can be opened either by opendir() or by dirfd(). The suggested changes refer to the fd as "associated with" the stream, as that is the phrase used on the dirfd() page.
2. It describes opening with O_DIRECTORY and then in a separate paragraph says that FD_CLOEXEC is set. This implies that setting FD_CLOEXEC can be done separately, whereas to avoid race conditions the open should be done as if with O_CLOEXEC. (As is already required for dirfd().)
3. The wording "applications shall only be able to open up to a total of {OPEN_MAX} files and directories" has the same problem that all the EMFILE descriptions used to have. (They were reworded to use "file descriptors available to the process".)
Issue 1 also affects closedir().
In addition to these issues in the normative text, there are problems in RATIONALE too.
|
|
Desired Action |
On page 816 line 27933 section fdopendir(), change:If the type DIR is implemented using a file descriptor, applications shall only be able to open up to a total of {OPEN_MAX} files and directories.
If the type DIR is implemented using a file descriptor, the descriptor shall be obtained as if the O_DIRECTORY flag was passed to open().
If the type DIR is implemented using a file descriptor and a directory stream is opened by a successful call to opendir(), the FD_CLOEXEC flag shall be set on the file descriptor; see [xref to <fcntl.h>]. to:If opendir() opens a file descriptor for dirname to associate with the returned stream:
- The descriptor shall be allocated as if the O_DIRECTORY and O_CLOEXEC flags were passed to open().
- The descriptor shall be subject to the limit of {OPEN_MAX} file descriptors available to the process.
On page 818 line 28030 section fdopendir(), change:Based on historical implementations, the rules about file descriptors apply to directory streams as well. However, this volume of POSIX.1-202x does not mandate that the directory stream be implemented using file descriptors. The description of closedir() clarifies that if a file descriptor is used for the directory stream, it is mandatory that closedir() deallocate the file descriptor. When a file descriptor is used to implement the directory stream, opendir() behaves as if the FD_CLOEXEC flag had been set for the file descriptor. to:Based on historical implementations, the rules about file descriptors apply to directory streams as well. However, this volume of POSIX.1-202x does not mandate that opendir() opens a file descriptor to associate with the stream; this may instead be done by the first call to dirfd(), thus avoiding the need to allocate a file descriptor if dirfd() is never called. Once a file descriptor has been associated with the stream, it is mandatory that closedir() deallocate the file descriptor. If opendir() opens a file descriptor to associate with the stream, it behaves as if the O_CLOEXEC flag for open() had been used, so that the FD_CLOEXEC flag is set for the file descriptor.
On page 819 line 28079 section fdopendir(), change:if the type DIR is implemented using a file descriptor to:if it associates a file descriptor with the returned stream.
On page 667 line 23091 section closedir(), change:If a file descriptor is used to implement type DIR, that file descriptor shall be closed. to:If there is a file descriptor associated with the stream (whether opened by opendir() or dirfd(), or passed to fdopendir() when creating the stream), that file descriptor shall be closed by closedir().
|
Relationships 
