PATCH: linux-generic dup2 behaviour

[Linas Vepstas]

Argh, patch below is bad; here's why:

There is another m4 test case which closes stderr, on purpose,
then does a dup2(2,2) and expects to get back EBADF
Should I emulate this kind of behavior in glibc? If not, then
the question arises: what is the correct way of mapping
expected dup2() behavior to non-deprecated syscalls?

--linas


On 13 September 2011 16:10, Linas Vepstas <linasvepstas@gmail.com> wrote:
> Chris, here's another:
>
> man dup2 states that:
>   If  oldfd  is a valid file descriptor, and newfd has the same value as
>   oldfd, then dup2() does nothing, and returns newfd.
>
> while the linux kernel does this in fs/fcntl.c:
>  if (unlikely(oldfd == newfd)) return -EINVAL;
>
> Which I presume is correct for dup3.
> Thus, dup2 needs fixing. Note that m4 test suite catches this.
>
>
> ---
>  sysdeps/unix/sysv/linux/generic/dup2.c |    2 ++
>  1 file changed, 2 insertions(+)
>
> Index: glibc-2.14/sysdeps/unix/sysv/linux/generic/dup2.c
> ===================================================================
> --- glibc-2.14.orig/sysdeps/unix/sysv/linux/generic/dup2.c  2011-09-13
> 15:39:03.000000000 -0500
> +++ glibc-2.14/sysdeps/unix/sysv/linux/generic/dup2.c 2011-09-13
> 15:40:09.000000000 -0500
> @@ -26,6 +26,8 @@
>  int
>  __dup2 (int fd, int fd2)
>  {
> +  /* if fd's are equal, preserve documented dup2 response */
> +  if (fd == fd2) return fd;
>   return INLINE_SYSCALL(dup3, 3, fd, fd2, 0);
>  }
>  libc_hidden_def (__dup2)
>