From owner-freebsd-bugs@FreeBSD.ORG Sat Feb 23 16:40:03 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8B871940 for ; Sat, 23 Feb 2013 16:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 659987C4 for ; Sat, 23 Feb 2013 16:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1NGe28e044048 for ; Sat, 23 Feb 2013 16:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1NGe2sw044047; Sat, 23 Feb 2013 16:40:02 GMT (envelope-from gnats) Date: Sat, 23 Feb 2013 16:40:02 GMT Message-Id: <201302231640.r1NGe2sw044047@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Jilles Tjoelker Subject: Re: kern/176233: [libc] [patch] New dup3() implementation for FreeBSD X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Jilles Tjoelker List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 16:40:03 -0000 The following reply was made to PR kern/176233; it has been noted by GNATS. From: Jilles Tjoelker To: "Jukka A. Ukkonen" 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