[Bug libc/682] New: stdout and file descriptor mismatch after a freopen()

[Bug libc/682] New: stdout and file descriptor mismatch after a freopen()

[vincent+libc at vinc17 dot org]

Closing stdin with fclose(stdin) and redirecting stdout with freopen(...,stdout)
make stdout associated with file descriptor 0 instead of 1, leading to
non-documented side effects (and even incompatible with documentation supplied
with Linux: the stdin(3) man page). After a discussion (in French) in
fr.comp.lang.c, several users agreed that this could be seen as a bug and should
be fixed. See bug 670 for a testcase.

Note: Of course, stdin and stderr are affected too, and so is the fopen() function.

A correct behavior would be to reserve file descriptors 0, 1 and 2 for stdin,
stdout and stderr at the fopen/fclose/freopen level (the functions defined by
the ISO C standard). If the programmer uses system calls directly, he should
make sure not to break this convention.

-- 
           Summary: stdout and file descriptor mismatch after a freopen()
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: vincent+libc at vinc17 dot org
                CC: glibc-bugs at sources dot redhat dot com


http://sources.redhat.com/bugzilla/show_bug.cgi?id=682

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/682] stdout and file descriptor mismatch after a freopen()

[gotom at debian dot or dot jp]

------- Additional Comments From gotom at debian dot or dot jp  2005-02-14 15:47 -------
I don't understand how to implement your proposal: "A correct behavior
would be to reserve file descriptors 0, 1 and 2 for stdin, stdout and
stderr at the fopen/fclose/freopen level".

BTW, looking through the discussion in bug 670, I think the following
interpretation of freopen() can provide your request:

 - interpret freopen() that freopen(path, mode, fp) assigns the same
   fd number which is previously used in fp (using dup2()).

This is known as BSD freopen() behavior.

However, I know this behavior has problem because there's race
condition between fd=open(path) and dup2(fd, fp->fd) - the fd
specified in the 2nd argument of dup2() is possibly used for the other
purpose when signal handler is called or concurrent thread is running
at the same time.

In order to fix this race condition, the 2nd argument of dup2() should
be the original fp->fd - but unfortunatelly standards say freopen()
should always close the fp in first, so we can't avoid this problem.

I marked it as invalid until you propose the correct implementation.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://sources.redhat.com/bugzilla/show_bug.cgi?id=682

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/682] stdout and file descriptor mismatch after a freopen()

[vincent+libc at vinc17 dot org]

------- Additional Comments From vincent+libc at vinc17 dot org  2005-02-14 17:30 -------
I propose the following idea:
  * open() always returns fd > 2 (or -1 if an error occurred). [*]
  * If fp is stdin, stdout or stderr, then freopen() uses open() + dup2().
i.e. the only way to get a fd <= 2 (corresponding to a standard stream) is to
force this with dup2().

[*] This would require a kernel fix, I suppose. Otherwise, just make sure that
fd > 2 if fopen() is used (for instance, by reassigning the fd with dup2()).
This wouldn't eliminate the race condition though, but pure C programs would
work as expected.

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=682

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/682] stdout and file descriptor mismatch after a freopen()

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2005-02-14 17:36 -------
This violates POSIX:
http://www.opengroup.org/onlinepubs/009695399/functions/open.html
Open must always return the lowest numbered unused fd if it succeeds.


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=682

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/682] stdout and file descriptor mismatch after a freopen()

[vincent+libc at vinc17 dot org]

------- Additional Comments From vincent+libc at vinc17 dot org  2005-02-15 00:10 -------
However the current behavior violates the ISO C standard (or the system
documentation is incorrect).

But the solution to reserve the fd 0, 1 and 2 for stdin, stdout and stderr in
ISO C programs (as long as a race condition doesn't occur) would be OK. Note
that a C implementation isn't required to have fully reentrant standard
functions, so that if the programmer wants stdin, stdout and stderr to really
correspond to the standard streams, then he should also make sure that no race
condition occurs.

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=682

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/682] stdout and file descriptor mismatch after a freopen()

[michael dot kerrisk at gmx dot net]

------- Additional Comments From michael dot kerrisk at gmx dot net  2005-06-16 15:50 -------
(In reply to comment #4)
> However the current behavior violates the ISO C standard (or the system
> documentation is incorrect).

Which part of the standard do you believe this violates?
SUSv3 permits the Linux behaviour, as far as I can see.
And I believe it is common on other implementations also.

> But the solution to reserve the fd 0, 1 and 2 for stdin, stdout and stderr in
> ISO C programs (as long as a race condition doesn't occur) would be OK. Note
> that a C implementation isn't required to have fully reentrant standard
> functions, so that if the programmer wants stdin, stdout and stderr to really
> correspond to the standard streams, then he should also make sure that no race
> condition occurs.

I do not believe any change should be made.  See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=295859
for further information.

Cheers,

Michael

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=682

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/682] stdout and file descriptor mismatch after a freopen()

[vincent+libc at vinc17 dot org]

------- Additional Comments From vincent+libc at vinc17 dot org  2005-06-16 21:12 -------
If the stdin(3) man page is changed, then I think this is OK. Well, I still
think that the "system" documentation is incomplete (Section 26.1). Section 26
says "it does all three steps automatically", but this doesn't mean that this is
*equivalent* to these 3 steps.

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=682

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/682] stdout and file descriptor mismatch after a freopen()

[vincent+libc at vinc17 dot org]

------- Additional Comments From vincent+libc at vinc17 dot org  2009-10-29 17:58 -------
(In reply to comment #5)
> (In reply to comment #4)
> > However the current behavior violates the ISO C standard (or the system
> > documentation is incorrect).
> 
> Which part of the standard do you believe this violates?

I haven't looked at it closely, but see:

  http://austingroupbugs.net/view.php?id=173

It seems that instead of the behavior, the spec will be changed to avoid the
contradiction, but that's not so simple.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=682

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/682] stdout and file descriptor mismatch after a freopen()

[jackie.rosen at hushmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=682

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #8 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/682] stdout and file descriptor mismatch after a freopen()

[schwab at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=682

Andreas Schwab <schwab at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jackie.rosen at hushmail dot com   |

-- 
You are receiving this mail because:
You are on the CC list for the bug.