Mail Archives: djgpp/2013/12/04/21:54:09
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
- Raw text -