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 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 Precedence: bulk > Date: Tue, 03 Dec 2013 03:40:10 +0100 > From: Juan Manuel Guerrero > > 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?