Re: dup2() vs dup3() inconsistency when

["Michael Kerrisk" <mtk.manpages@googlemail.com>]

On Thu, Oct 9, 2008 at 10:57 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> 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.

Well, as long as we are fixing the dup3() interface in the way that Al
and Ulrich have suggested, what about another fix:

give an error if newfd is already open, thus forcing the user to do an
explicit close

?

This silent close in dup2() is an implementation blemish.  Why not eliminate it?

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html