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

[Dmitrij Tejblum]

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

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

 David Xu wrote:
 
 > 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.
 
 Well, this is C, not C++, so there cannot be strict difference between 
 allowed and disallowed. But the _close field is not required by any 
 standarts (funopen() too) and is not documented by manpages (I checked 
 manpages with grep). And there does exist documented interface for 
 setting _close: funopen(). Thus _close is internal.