Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
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
Reporter shware_systems View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied   Product Version
Name Mark Ziegast
Organization SHware Systems Dev.
User Reference
Section dup3()
Page Number 742
Line Number 25487-91
Final Accepted Text Note: 0005827
Summary 0001577: dup3 flags usage not entirely specified
Description 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.

As example:
int fd2=open("./tmp", O_RDWR | O_CLOFORK | O_CREAT);
int fd=3;
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.
Tags issue8
Attached Files

- Relationships
related to 0001557Closed 1003.1(2016/18)/Issue7+TC2 Better wording to describe FD_CLOEXEC. 
related to 0000411Appliedajosey 1003.1(2008)/Issue 7 adding atomic FD_CLOEXEC support 

-  Notes
(0005786)
kre (reporter)
2022-04-07 18:31

 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).
(0005827)
geoffclare (manager)
2022-04-28 16:36

 (The following changes make the wording for dup3() and pipe2() consistent with accept4().)

Change:
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>):

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker