From owner-freebsd-bugs@FreeBSD.ORG Tue Feb 19 23:30:02 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 51730555 for ; Tue, 19 Feb 2013 23:30:02 +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 44641103 for ; Tue, 19 Feb 2013 23:30:02 +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 r1JNU1DE091190 for ; Tue, 19 Feb 2013 23:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1JNU1BG091189; Tue, 19 Feb 2013 23:30:01 GMT (envelope-from gnats) Date: Tue, 19 Feb 2013 23:30:01 GMT Message-Id: <201302192330.r1JNU1BG091189@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: Tue, 19 Feb 2013 23:30:02 -0000 The following reply was made to PR kern/176233; it has been noted by GNATS. From: Jilles Tjoelker To: bug-followup@FreeBSD.org, jau@iki.fi Cc: Subject: Re: kern/176233: [libc] [patch] New dup3() implementation for FreeBSD Date: Wed, 20 Feb 2013 00:28:41 +0100 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. The O_NONBLOCK and O_NOSIGPIPE flags appear contrary to the idea of dup2/dup3 since they affect the underlying object and not just the new file descriptor like O_CLOEXEC does. Unknown/unsupported flags should indeed [EINVAL] so we have a chance to add new flags later. -- Jilles Tjoelker