X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
Message-ID: <529FEB30.301@gmx.de>
Date: Thu, 05 Dec 2013 03:55:44 +0100
From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: Question about different behavior of fclose/fread on plain dos
 and windows.
References: <529D448A DOT 7050208 AT gmx DOT de> <831u1u5se3 DOT fsf AT gnu DOT org> <529DD111 DOT 8050000 AT gmx DOT de> <83r49u3xhn DOT fsf AT gnu DOT org>
In-Reply-To: <83r49u3xhn.fsf@gnu.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID:  V03:K0:xZpyDRmM4W4RNZ1KIMUPzaznlprc2//FkoIv6/8itP5PunCofY/
 EFB04+9NkOpGn1v6yOByUXtsLV3FJ1rCg3udvcIf6/Zz/ifrEV4nImdjy0eMROslgbB2Pje
 FNV0ktHB8ixfuP0WMiIwCD+fQB1q3haHenP3EQ4HzAguivuUQfZXPaV/GZRbKdrYPQrX4Rb
 39RKlEwrgWs1h7PrmIbZQ==
Reply-To: djgpp AT delorie DOT com

Am 03.12.2013 13:55, schrieb Eli Zaretskii:
>> Date: Tue, 03 Dec 2013 13:39:45 +0100
>> From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
>>
>> It has no influence if I call clearerr.  The flags that are cleared are not set
>> before the call.  It works reliably in all variants if I open the file for reading
>> after having closed the write handle.
> If you stepped through fread and its subroutines with a debugger, and
> saw that _filbuf is actually called, and calls _read (as opposed to
> just returning a -1 based on some flag), then I guess what you see is
> the difference in the implementation of INT 21h function 3Fh between
> the different systems.  Probably DOS records internally the size of
> the file when you open a handle for reading, or something similar.
>
> But do be sure that the error indeed comes from _read and not from
> some information recorded in the FILE object from before the file is
> closed.

To check this issue I have used the same program I have posted in my
first mail.  I am aware that Rod Pemberton presented a modified version
of the test code that does not fail, but at this stage of the investigation
I want to check if the lua generated code triggers a library bug or
if it exposes different INT 21h function 3Fh implementation across
the different OSs under test.

I have compiled the test code using djdev203, djdev204 and a freshly
compiled library from the CVS repository.  I have also compiled the
test code on linux.

1) The results are independent of what C library has been used to compile
    the test program.  An inspection of the repository shows that the
    relevant code like _read, _filbuf and _write have not been changed over
    the years, so this is no surprise.
2) The issue here concerns reading, writing and truncating files so enabling
    or disabling LFN support also has no influence.
3) The check divides the group of tested OSs in two:
    a) The group that makes the lua test pass.  This is the group where the
       reading file handle sees that the file content has been changed after
       the writing file handle has been closed.  In other words, the
       following code works as expected:

   fwrite(buf_w, sizeof(char), sizeof buf_w, fw);   // fw: write file handle
   fclose(fw);
   fseek(fr, 0, SEEK_SET);
   fread(buf_r, sizeof(char), sizeof buf_r, fr);   // fr: read file handle


       This group is composed by:  linux, WinXP, Win2K, Win98SE and Win95.


    b) The group that makes the lua check fail is the group where the
       reading file handle does not see the file changes produced by
       closing the writing file handle.
       This group is composed by:  FreeDOS 1.1, MSDOS 6.22, DOS 7.0 (plain
       dos after leaving the Win95 GUI) and DOS 7.1 (plain dos after leaving
       the Win98 GUI).


Stepping into _read shows that if the file exists then INT 21h function 3Fh
returns with AX different from zero and the buffer is filled, but if the file
does not exist then AX is zero and the buffer is not filled by INT 21h function 3Fh.
(Checked with MSDOS 6.22.)


As a final test I have checked the file length when the file handle is created.
To this purpose I have added to the open function the following code:

[snip]
   printf("before: %ld\n", filelength(fd));   // my code
   if ((oflag & O_TRUNC) && !should_create)
#ifndef TRUNC_CHECK
     _write(fd, 0, 0);
   printf("after: %ld\n", filelength(fd));   // my code
#else
     /* Windows 2000/XP will fail 0 byte writes (truncate) on a character
        device (nul, con) if opened with lfn calls.  We can either ignore
[snip]

If the writing file handle is opened the file is truncated and the file size
is different before and after _write has been called.  If the reading handle
is opened the before and after values are always the same. For all windows
versions, the before and after values of the reading file handle are zero
because either the file does not exist or the before allocated writing file
handle has truncated the file to zero length.  For all dos versions the
before and after values are always identical to the original file length.
This means, if the file does not exist then the values are zero, but if
the file exists the both values are identical to the original file length
although the previously allocated writing file handle has truncated the file
to zero length.

I do not have OpenWATCOM or other dos compilers to compare against DJGPP.

After all the question arises if the generated program is licit/valid?
Or in other words what says the C standard about the program I have
submitted?  I think there must be an answer about the question if the
changes to a file produced by a writing file handle that has been closed
become "visible" to a reading file handle of the same file or not?

Regards,
Juan M. Guerrero