kern/176233: [libc] [patch] New dup3() implementation for FreeBSD

Jilles Tjoelker jilles at stack.nl
Sat Feb 23 16:40:03 UTC 2013


The following reply was made to PR kern/176233; it has been noted by GNATS.

From: Jilles Tjoelker <jilles at stack.nl>
To: "Jukka A. Ukkonen" <jau at iki.fi>
Cc: bug-followup at FreeBSD.org
Subject: Re: kern/176233: [libc] [patch] New dup3() implementation for FreeBSD
Date: Sat, 23 Feb 2013 17:30:32 +0100

 On Wed, Feb 20, 2013 at 11:13:14AM +0200, Jukka A. Ukkonen wrote:
 > Quoting Jilles Tjoelker:
 
 > > PR kern/176233:
 > > > [dup3 implementation based on F_DUP2FD_CLOEXEC]
 
 > > The dup3() function appears to be used in the wild and there is a gnulib
 > > replacement for it, even though it seems of rather limited use compared
 > > to fcntl(F_DUPFD_CLOEXEC). Most uses of dup2() are for passing fd 0, 1
 > > or 2 to a process so that the close-on-exec flag should be clear.
 
 > > I think glibc's [EINVAL] on oldfd == newfd actually makes some sense as
 > > it forces the programmer to separate clearly the cases where oldfd !=
 > > newfd and oldfd == newfd. http://austingroupbugs.net/view.php?id=411
 > > also proposes requiring it.
 
 > This is a kind of a philosophical choise.
 > Do we expect the programmer to pass two equal file descriptors
 > intentionally or not?
 > The Linux community and the Austin group have taken the view in
 > which they do not trust the programmer to do it intentionally.
 > The NetBSD way is to rely on the programmer to use the trick
 > by choise, not by accident. Personally I rather like the latter
 > approach. ;-)
 > Also simple good style favors sticking to similar behavior as the
 > existing dup2() while the "big academic problem" Linux has been
 > solving with their deviant behavior is in fact more of a paper tiger.
 
 > Anyhow were the large majority to prefer the pointlessly restrictive
 > (in my mind) Linux approach over the NetBSD approach and over
 > consistency with the existing dup2(), you have the necessary check
 > included in my patch between "#if 0/#endif".
 
 Some more rationale from the Linux/glibc side about this:
 http://www.cygwin.com/ml/libc-ports/2011-09/msg00009.html
 
 Basically, if x != y, dup3(x, y, O_CLOEXEC) ensures y is set CLOEXEC and
 dup3(x, y, 0) ensures y is set not CLOEXEC. This breaks down if x == y.
 
 -- 
 Jilles Tjoelker


More information about the freebsd-bugs mailing list