From: "H. Peter Anvin" <hpa@zytor.com>
To: Ulrich Drepper <drepper@redhat.com>
Cc: mtk.manpages@gmail.com, Al Viro <viro@zeniv.linux.org.uk>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: dup2() vs dup3() inconsistency when
Date: Thu, 09 Oct 2008 13:57:32 -0700 [thread overview]
Message-ID: <48EE703C.7070901@zytor.com> (raw)
In-Reply-To: <48EE6F22.5070306@redhat.com>
Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> H. Peter Anvin wrote:
>> The result of dup3(fd, fd, O_CLOEXEC) is to set the O_CLOEXEC flag on fd.
>
> That's bad and disregarded by Al and myself because it is one and the
> same descriptor and therefore it changes the source descriptor.
It's not the source descriptor, per se, it is the "new" descriptor,
which happens to have a side effect of closing the "old" descriptor.
>> Step (2) could be considered a bit dubious, but the behaviour of
>> dup2(fd, fd) is a direct consequence of the chosen semantics.
>
> The behavior of dup2(fd,fd) is just a result of an accident in the
> original implementation. It makes no sense and the mistake doesn't have
> to be repeated.
Inconsistency is bad, too, and one could *definitely* argue that the
fundamental problem is the one of closing a pre-existing descriptor
rather than forcing the user to do that explicitly if that behaviour was
desired.
-hpa
next prev parent reply other threads:[~2008-10-09 20:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-09 12:10 dup2() vs dup3() inconsistency when Michael Kerrisk
2008-10-09 17:21 ` H. Peter Anvin
2008-10-09 20:31 ` Ulrich Drepper
2008-10-09 20:43 ` H. Peter Anvin
2008-10-09 20:52 ` Ulrich Drepper
2008-10-09 20:57 ` H. Peter Anvin [this message]
2008-10-09 21:04 ` Ulrich Drepper
2008-10-10 5:04 ` Michael Kerrisk
2008-10-10 12:09 ` Bernd Petrovitsch
2008-10-10 12:15 ` Michael Kerrisk
2008-10-10 13:02 ` Bernd Petrovitsch
2008-10-10 13:15 ` Michael Kerrisk
2008-10-10 13:31 ` Bernd Petrovitsch
2008-10-10 5:01 ` Michael Kerrisk
2008-10-10 13:43 ` Heikki Orsila
[not found] <bl2EV-7G2-9@gated-at.bofh.it>
[not found] ` <bl7v3-5sk-17@gated-at.bofh.it>
[not found] ` <blasN-OS-9@gated-at.bofh.it>
[not found] ` <blaCu-Z0-11@gated-at.bofh.it>
[not found] ` <blaMj-18o-23@gated-at.bofh.it>
[not found] ` <blaMj-18o-21@gated-at.bofh.it>
[not found] ` <bliqg-2DH-1@gated-at.bofh.it>
2008-10-10 11:42 ` Bodo Eggert
2008-10-10 11:59 ` Michael Kerrisk
2008-10-10 13:19 ` Bodo Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48EE703C.7070901@zytor.com \
--to=hpa@zytor.com \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.