[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: threads/79887: [patch] freopen() isn't thread-safe
The following reply was made to PR threads/79887; it has been noted by GNATS.
From: Dmitrij Tejblum <tejblum@xxxxxxxxxxxxxx>
To: David Xu <davidxu@xxxxxxxxxxx>
Cc: bug-followup@xxxxxxxxxxx
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.
