X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
Date:	Tue, 03 Dec 2013 09:02:28 +0200
From:	Eli Zaretskii <eliz AT gnu DOT org>
Subject:	Re: Question about different behavior of fclose/fread on plain dos and windows.
In-reply-to:	<529D448A.7050208@gmx.de>
X-012-Sender:	halo1 AT inter DOT net DOT il
To:	djgpp AT delorie DOT com
Message-id:	<831u1u5se3.fsf@gnu.org>
References:	<529D448A DOT 7050208 AT gmx DOT de>
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> Date: Tue, 03 Dec 2013 03:40:10 +0100
> From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
> 
> The code shall open the same file for writing and reading.  I have compiled
> the code on linux and on Win98SE, Win2K and WinXP.  On windows I have used
> DJGPP 2.03 and DJGPP 2.04.  In all these cases the code works as I expected.
> This means that reading after having closed the file shall result in a filled
> buf_r.  The program gives the following output:
> 
> fwrite(fw) OK (7): pipapo
> fread(fr) OK (0):
> fread(fr) OK (7): pipapo
> 
> 
> But if I compile the same code on plain DOS (MSDOS 6.22 or MSDOS 7.1) the program
> fails producing the following output:
> fwrite(fw) OK (7): pipapo
> fread(fr) OK (0):
> fread(fr) FO (0):
> 
> 
> (If you run the program twice on plain dos remove the produced file.txt before
> starting the program or the program will seem to work.)

Does it work reliably if you open the file for reading only after its
write handle is closed?  How about if you call clearerr on the stream,
before the second read?

> As can be seen the the reading file struct does not note that the writing file
> struct has changed/updated the file content.  The fact that really surprises me
> is the different behavior of the dos emulation of windows and the plain dos behavior.
> Am I missing something here?  Is this the normal dos behavior or must the library
> be fixed?  Is there a way to fix the library so that the behavior on plain dos
> becomes the same than on windows?

I don't think the library does anything fancy here.  I suggest to step
through fread with a debugger, and see what is going on inside
_filbuf.  It is possible that the EOF and error flags of the stream
play some dirty games here, but then why the different behavior on
different OSes?

- Raw text -