From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Cc: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Subject: Re: The Perl/FD issue: update
Date: Sun, 23 Sep 2001 20:10:06 +0200
Message-ID: <000401c1445a$f99f5a00$047d76d5@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-reply-to: <2950-Sun23Sep2001185940+0300-eliz@is.elta.co.il>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Is it possible that handles 3 and 4 are somehow already closed, or
> otherwise invalid, when stdiohk.c gets to fflush and close them?  You

Seems very unlikely; I inserted the fclose() just before the call to
exit(), so any such problems would have to occur in exit(), before the
stdio hook.  But all that happens there is atexit handling and
destructors.  So unless there is some library destructor that could
have such an effect, that seems VERY unlikely.

> should see some kind of failure indications from fflush and/or close
> if that's the case.

I'll add some more fprintf()s and see what it gives.

> Another possibility is that some code purges the buffered characters
> before stdiohk.c fflushes them.
Again, I don't see any opportunity for that.

> fseek comes to mind (it does fflush when it purges, but perhaps
> there's a bug).  Looking at the FILE object of the stream,
specifically
> at f->_ptr and f->_cnt, might tell something interesting.
Will add those to the printf's.