Re: dup2() vs dup3() inconsistency when

From: H. Peter Anvin
Date: Thu Oct 09 2008 - 13:22:02 EST


Michael Kerrisk wrote:
Al,

your 2008-07-26 commit 6c5d0512a091480c9f981162227fdb1c9d70e555 for
fs/fcntl.c:sys_dup3 contains

+ if (unlikely(oldfd == newfd))
+ return -EINVAL;

This makes dup2() and dup3() differ with respect to the oldfd==newfd
case (dup2() becomes a no-op, just returning oldfd, dup3() gives the
EINVAL error.

Your commit log doesn't explain the rationale for this change. What
is it? (I could guess that it is to error on a case that may be a
user programming error, but I want to check this with you, so that I
add the right text to the man page.)


The dup2() behavior comes from the logical consequence of dup2()'s "close on reuse"; one would think it would be logical for dup3() to behave the same way.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/