|Anonymous | Login||2022-05-28 16:28 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001577||[Issue 8 drafts] System Interfaces||Objection||Omission||2022-04-07 16:20||2022-05-26 10:37|
|Priority||normal||Resolution||Accepted As Marked|
|Organization||SHware Systems Dev.|
|Final Accepted Text||Note: 0005827|
|Summary||0001577: dup3 flags usage not entirely specified|
The current description for dup3() specifies the expected behavior when no bits are set in the flags argument, by reference to dup2 (either clearing the bits or inheriting both of them without change), and when all bits are set, in that specifying FD_CLOFORK and FD_CLOEXEC are both expected to be set in this case. The description does not specify what is to occur when one bit is set and the other is not specified; does this mean the setting for the unspecified bit is inherited from the fd being referenced or is it to be cleared, ignoring how it was set originally.
int fd2=open("./tmp", O_RDWR | O_CLOFORK | O_CREAT);
fd=dup3(fd, fd2, O_CLOEXEC);
Does fd have only FD_CLOEXEC only set, clearing FD_CLOFORK set in the open() call, or are both FD_CLOEXEC and FD_CLOFORK set?
An invoke like
fd=dup3(fd2, fd2, O_CLOEXEC)
would lead from reference to dup2 that both be set.
|Desired Action||Make it explicit which is the expected behavior, whether the input descriptors are the same or different, when only one O_* flag is specified.|
There is no "inheriting both of them without change" - that happens only
in dup2() when filedes1 == filedes2 (ie: that operation is a no-op).
For dup3() it is prohibited for filedes1 to be the same as filedes2, so
that situation cannot occur (though the wording for this could be
improved to make it clearer that it is not only when flags==0 that
that prohibition applies ... other than that would make no sense, we do
not need dup3() to be able to manipulate the flag bits for a fd, we have
fcntl() for that).
dup2() clears the flags, except in the no-op case. dup3() sets the
flags to exactly what is given in the flags arg.
I do agree that this should be clearer in the standard, it currently
just says that the flags arg can be the inclusive or of the 2 bits.
It nowhere says what then happens with that arg. It should specify
that the flags for the new fd (filedes2) are set (as if by open).
(The following changes make the wording for dup3() and pipe2() consistent with accept4().)
The dup3() function shall be equivalent to the dup2() function if the flag argument is 0, except that it shall be an error if fildes is equal to fildes2. Additionally, the flag argument can be constructed from a bitwise-inclusive OR of flags from the following list:to:
The dup3() function shall be equivalent to the dup2() function, except that it shall be an error if fildes is equal to fildes2, and the state of FD_CLOEXEC and FD_CLOFORK on the fildes2 file descriptor shall be determined solely by the flag argument, which can be constructed from a bitwise-inclusive OR of flags from the following list:
On page 1413 line 47116 section pipe(), change:
The pipe2() function shall be equivalent to the pipe() function if the flag argument is 0. Additionally, the flag argument can be constructed from a bitwise-inclusive OR of flags from the following list (provided by <fcntl.h>):to:
The pipe2() function shall be equivalent to the pipe() function, except that the state of O_NONBLOCK on the new file descriptions and FD_CLOEXEC and FD_CLOFORK on the new file descriptors shall be determined solely by the flag argument, which can be constructed from a bitwise-inclusive OR of flags from the following list (provided by <fcntl.h>):
|2022-04-07 16:20||shware_systems||New Issue|
|2022-04-07 16:20||shware_systems||Name||=> Mark Ziegast|
|2022-04-07 16:20||shware_systems||Organization||=> SHware Systems Dev.|
|2022-04-07 16:20||shware_systems||Section||=> dup3()|
|2022-04-07 16:20||shware_systems||Page Number||=> 742|
|2022-04-07 16:20||shware_systems||Line Number||=> 25487-91|
|2022-04-07 18:31||kre||Note Added: 0005786|
|2022-04-28 15:50||Don Cragun||Relationship added||related to 0001557|
|2022-04-28 16:19||geoffclare||Relationship added||related to 0000411|
|2022-04-28 16:36||geoffclare||Note Added: 0005827|
|2022-04-28 16:37||geoffclare||Final Accepted Text||=> Note: 0005827|
|2022-04-28 16:37||geoffclare||Status||New => Resolved|
|2022-04-28 16:37||geoffclare||Resolution||Open => Accepted As Marked|
|2022-04-28 16:37||geoffclare||Tag Attached: issue8|
|2022-05-26 10:37||geoffclare||Status||Resolved => Applied|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|