threads/79887: [patch] freopen() isn't thread-safe

[David Xu]

The following reply was made to PR threads/79887; it has been noted by GNATS.

From: David Xu <davidxu at freebsd.org>
To: Dmitrij Tejblum <tejblum at yandex-team.ru>
Cc: bug-followup at freebsd.org
Subject: Re: threads/79887: [patch] freopen() isn't thread-safe
Date: Thu, 29 Dec 2005 13:26:03 +0800

 Dmitrij Tejblum wrote:
 > 
 > David Xu wrote:
 > 
 >> Indeed, this a bug, but the patch you provided breaks the samentic the
 >> FILE structure was designed for, here you conditionally call
 >> fp->_close(), this is incorrect, because the hook may be an external
 >> function, it should always be called to notify external code.
 > 
 > 
 > I only assume that
 > 1) _file and _close fields are internal to stdio, i.e. only stdio code 
 > manipulate with them directly
 > 2) If _file != -1, then the FILE is associated with the file descriptor, 
 > fp->_close == __sclose (because the only code that can set fp_close to 
 > something different is funopen, and it set _file to -1) and __sclose 
 > just close the _fp->_file
 > If so, we know that dup2() will close the descriptor too, dup2() is 
 > required to do it.
 > 
 I think we allow _close and others to be changed by user code unless
 someone can clarify that this is not allowed now, otherwise your
 assumption is false.
 
 
 >> I think the right fix is to fix those code which is still using
 >> STDERR_FILENO, or don't do following hack in freopen.c:
 >>     if (wantfd >= 0 && f != wantfd) {
 >>            if (_dup2(f, wantfd) >= 0) {
 >>                      (void)_close(f);
 >>                      f = wantfd;
 >>            }
 >>     }
 >> This is not required by standard.
 > 
 > 
 > Well, I tried to keep existing behaviour, and I think that the hack is 
 > indeed a good idea even though it is not required.