Date: Sun, 23 Sep 2001 18:59:41 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: tim DOT van DOT holder AT pandora DOT be
Message-Id: <2950-Sun23Sep2001185940+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com
In-reply-to: <000001c14443$4e3861a0$047d76d5@pandora.be>
	(tim DOT van DOT holder AT pandora DOT be)
Subject: Re: The Perl/FD issue: update
References:  <000001c14443$4e3861a0$047d76d5 AT pandora DOT be>
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

> From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> Date: Sun, 23 Sep 2001 17:20:36 +0200
> 
> Then, on a hunch, I added
> 
>   fflush (debug);
> 
> to M4's main().  Lo and behold, it started working.
> The same effect was reached by using
> 
>   fclose (debug);
> 
> So it would seem that the problem is that files attached to FD's
> 3 and 4 do not get closed at the end of the program, resulting in
> empty or incomplete files.
> Still, according to stdiohk.c, all files with fileno > 2 get
> fclose()d by __stdio_cleanup_proc(), and an fprintf() in the
> close helper does show it being called for FDs 0, 2, 4 and 3.

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
should see some kind of failure indications from fflush and/or close
if that's the case.

Another possibility is that some code purges the buffered characters
before stdiohk.c fflushes them.  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.