Date: Sat, 23 Feb 2013 16:40:02 GMT From: Jilles Tjoelker <jilles@stack.nl> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/176233: [libc] [patch] New dup3() implementation for FreeBSD Message-ID: <201302231640.r1NGe2sw044047@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/176233; it has been noted by GNATS. From: Jilles Tjoelker <jilles@stack.nl> To: "Jukka A. Ukkonen" <jau@iki.fi> Cc: bug-followup@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201302231640.r1NGe2sw044047>