From: cgf AT bbc DOT com (Christopher Faylor) Subject: freopen bug? 18 Feb 1998 00:56:07 -0800 Message-ID: Reply-To: cygwin32-developers AT cygnus DOT com To: cygwin32-developers AT cygnus DOT com Mumit Khan has indicated that he is having problems getting collect2 to work with EGCS due to an apparent bug in newlib's freopen. The problem is that freopen is apparently not preserving the fd of the stream that is operating on. While, there is nothing in the man page to indicate that this is unacceptable behavior, it does seem to run counter to the usual use of the function, i.e. to reopen stdin/stdout/stderr. When a program forks after using freopen to redirect stdout and stderr, the forkee is confused by the fact that the handles for stdout and stderr are not 1 and 2. The program below illustrates the problem: #include #include #include main(int argc, char **argv) { FILE *fd1 = freopen("output.log", "a", stdout); FILE *fd2 = freopen("output.log", "a", stderr); fprintf(stderr, "%d %d\n", fileno(stdout), fileno(stderr)); } I've included a patch which fixes this behavior but, being unfamiliar with the reent structure conventions, I am not sure that this is the best solution. Regardless, I'm sure that Mumit would greatly appreciate a fix to this problem that has plagued him for months... (I am puzzled as to why the forker was able to use a stdout stream with a file handle of 3, but the forkee was unable to. Possibly another bug...) --- /source/src/cdk/newlib/libc/stdio/freopen.c Thu Dec 11 04:36:49 1997 +++ ./freopen.c Wed Feb 18 01:02:17 1998 @@ -136,7 +136,12 @@ */ if (isopen) - (void) (*fp->_close) (fp->_cookie); + { + (void) (*fp->_close) (fp->_cookie); + dup2(f, fp->_file); + close(f); + f = fp->_file; + } if (fp->_flags & __SMBF) _free_r (ptr, (char *) fp->_bf._base); fp->_w = 0; -- http://www.bbc.com/ cgf AT bbc DOT com "Strange how unreal VMS=>UNIX Solutions Boston Business Computing the real can be."