Mail Archives: djgpp-workers/2013/07/17/11:40:13
> Date: Wed, 17 Jul 2013 01:01:26 +0200
> From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
>
> Please inspect the code snippet below:
>
> #include <stdio.h>
>
> int main(void)
> {
> char buffer[1024];
> FILE *f = fopen("foobar.txt", "w");
>
> clearerr(f);
>
> if (fgets(buffer, sizeof(buffer), f) == NULL)
> printf("EOF encountered before data\n");
>
> printf("ferror = %s\n", ferror(f) ? "TRUE" : "FALSE");
> printf("feof = %s\n", feof(f) ? "TRUE" : "FALSE");
>
> return 0;
> }
>
>
> The code snippet is not arbitrary (especially the "w" mode instead of the "w+"
> mode in the fopen function) but represents a compilable and working version of
> the code produced by the lua interpreter for the first two lines of the
> following lua code snippet:
>
> local f = io.open("foobar.txt", "w")
> local r, m, c = f:read()
> assert(r == nil and ismsg(m) and type(c) == "number")
>
>
> The above code is part of a test suite and it shall fail because it tries to
> read from a file opened to be written. The second line fails and initializes
> the variables in such a way that the assert is not triggert (the data is a
> error message and the file descriptor, but that is of no importance here).
> This is the way the test shall work and this is the way the code works if lua
> has been compiled on linux. If lua is compiled using any version of djgpp,
> the second line:
> local r, m, c = f:read()
> behaves in a different way (it does not fail, among other things) and the
> variables are initialized with nonsense data making the following assertion
> to be triggert and thus aborting the complete test suite.
>
> The reason for the different behavior of lua's :read() function is the
> different way the ferror function has been implemented on linux and djgpp.
>
> The issue concerns the fread, fwrite, __putc and __getc functions only.
> These functions manipulate the file stream FILE *. Functions like read,
> _read and dos_read are not involved because they work with the file descriptor.
> If these functions fail due to accessing the file with wrong file mode,
> they set the appropriate dos error number.
> Of course, ferror can only fail for those functions that use the file stream.
>
> The patch below will fix the issue for read and write functions.
> As usual, suggestions, objections, comments are welcome.
What standard mandates that reading from a file stream open in "w"
mode shall set the error flag for the stream?
DJGPP currently sets the EOF flag, not the error flag. Why is that
wrong?
- Raw text -