Steffen, i think that's just a historical accident. The next step would be to create an issue on the bug tracker for a enhancement request to standardise `dup3` with the appropriate flag (maybe consider `O_ALLOCATE_LOWEST` as a name). The description could just be a more formal version of your email, and the desired action should be the API you propose to standardise.
>From Dhruv McElwaine. On Sat, 8 Nov 2025 at 21:55, Steffen Nurpmeso via austin-group-l at The Open Group <[email protected]> wrote: > Sorry, i posted this to the -request address (history expansion > instead of alias :() Please drop that :(( > > --- Forwarded from Steffen Nurpmeso <[email protected]> --- > ... > Hello. > > Instead of opening an issue i first asked. Because for > dup{,2,3}() RATIONALE says > > The dup3( ) function with the O_CLOEXEC and O_CLOFORK flags is > necessary to avoid a data race in multi-threaded > applications. > > Without O_CLOFORK, a file descriptor is leaked into a child > process created by one thread in the window between another > thread creating a file descriptor with dup2( ) and then using > fcntl( ) to set the FD_CLOFORK flag. > > Without O_CLOEXEC, a file descriptor intentionally inherited by > child processes is similarly leaked into an executed program if > FD_CLOEXEC is not set atomically. > > The safe counterpart for avoiding the same race with dup( ) is > the use of the F_DUPFD_CLOFORK or F_DUPFD_CLOEXEC action of the > fcntl( ) function. > > How does the latter fit in the paragraphs above? > What i need for a library function is to duplicate a file > descriptor, which then shall have both, CLOFORK and CLOEXEC set. > The only option i see is using one of F_DUPFD_CLO{EXEC,FORK}, what > is "most pressing" :-/, and then F_GETFD, or in the "other" > FD_CLO{EXEC,FORK}, and then call F_SETFD. This makes three system > calls? > > (It would be easy if dup3() would allow passing a dedicated > non-existing fd as "filedes2", to mean "create the duplicate". > And i may not be able to even create a fd for dup3() to overwrite, > on say /dev/null, for example in a chroot without any (accessible) > files.) > > So why does POSIX say > > The safe counterpart for avoiding the same race with dup( ) is > the use of the F_DUPFD_CLOFORK or F_DUPFD_CLOEXEC action of the > fcntl( ) function. > > when it seems to me that i cannot (at least, *generically*) > program code that create a new descriptor duplicate with both of > the CLO* flags set *atomically*? Why it is safe? It is not!?! > > -- End forward <20251108210454.P0Qsvig8@steffen%sdaoden.eu> > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > >
