Sender: ml AT delorie DOT com
Message-ID: <347D7983.5191CC04@cdata.tvnet.hu>
Date: Thu, 27 Nov 1997 14:45:39 +0100
From: Molnar Laszlo <molnarl AT cdata DOT tvnet DOT hu>
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: djgpp-workers AT delorie DOT com
Subject: Re: popen/pclose update
References: <Pine DOT SUN DOT 3 DOT 91 DOT 971125141928 DOT 27505a-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Eli Zaretskii wrote:
> There's nothing wrong in submitting a patch file that is longer than the
> original code.  Nobody gets excited by long patch files.  They are
> applied by running a program which doesn't care how long the input is.
> Preserving as much of the original code as possible makes the probability
> of new bugs smaller and helps others to compare the two versions and see
> clearly what's been changed.  IMHO, this is much more important than
> saving some net bandwidth.

OK, I have no problems with patch files. But as I rewrote the whole
stuff (95% of the code), I think the diff wouldn't help understanding
code. It would just show 2 different files. 

> > Yeah, that is my problem. If DOS has all the data in its internal
> > buffer, why it doesn't show them to the newly opened file? Is it a
> > feature?
> Because you redirected the handle to another file.  You should cause DOS
> to flush its buffers *before* the redirection, since you don't want the
> data to end up in the wrong place.

No, my problem is not the redirection. Look at this code:

#include <stdio.h>
int main (void)
{
    FILE *f1,*f2;
    
    f1=fopen ("x","w");
    fprintf (f1,"12345");
    fflush (f1);
      
    f2=fopen ("x","r");
    fseek (f2,0,2);
    printf ("Size of file x: %ld\n",ftell (f2));
    return 0;
}

This is similar to the code in pclose(). It prints "5" under Linux, and
"0" under DOS. It seems, that DOS doesn't show the data in its internal
buffer to file f2. That's why I have to use close() after fflush() :(

bye, ML