This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: linux-generic dup2 behaviour


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)
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]