Re: MSVCRT: Still problems in ASCII Mode

[Dan Kegel]

Thanks.
Please don't use rand() in testcases, though.
Would a constant 'a' suffice in this case?

Which app did you find this in, btw?

On Tue, Feb 3, 2009 at 1:55 PM, Uwe Bonnes
<bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote:
> Hello,
>
> it seems that in ASCII mode, fseek() may disturb reading. Appended patch
> adds a todo_wine.
>
> Bye
> --
> Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. [phone] -------- Fax. [phone] ----------
> diff --git a/dlls/msvcrt/tests/file.c b/dlls/msvcrt/tests/file.c
> index 9032e51..2a72212 100644
> --- a/dlls/msvcrt/tests/file.c
> +++ b/dlls/msvcrt/tests/file.c
> @@ -306,7 +306,8 @@ static void test_asciimode(void)
>  {
>     FILE *fp;
>     char buf[64];
> -    int c, i, j;
> +    int c, i, j, done, count1, count2;
> +
>
> /* Simple test of CR CR LF handling.  Test both fgets and fread code paths, they're different! */
>     fp = fopen("ascii.tst", "wb");
> @@ -372,6 +373,46 @@ static void test_asciimode(void)
>     ok((c = fgetc(fp)) == '1', "fgetc fails to read next char when positioned on \\r\n");
>     fclose(fp);
>
> +    fp= fopen("ascii.tst","wb");
> +    for (i=0; i<1000; i++)
> +      {
> +       unsigned char c = (rand()+ ' ') & 0x7f;
> +       if (isgraph(c) || (c == ' '))
> +         fputc(c, fp);
> +       else if ((c == '\r') || (c == '\n'))
> +         fputs("\r\n", fp);
> +      }
> +    fclose(fp);
> +
> +    done = 0;
> +    count1 = 0;
> +
> +    fp = fopen("ascii.tst", "r");
> +    while (!done)
> +      {
> +       c= fgetc(fp);
> +       if (c == EOF)
> +         done =  1;
> +       else if (isalnum(c))
> +         count1 ++;
> +      }
> +    fclose(fp);
> +
> +    done = 0;
> +    count2 = 0;
> +
> +    fp = fopen("ascii.tst", "r");
> +    while (!done)
> +      {
> +       c= fgetc(fp);
> +       fseek(fp, 0, SEEK_CUR);
> +       if (c == EOF)
> +         done =  1;
> +       else if (isalnum(c))
> +         count2 ++;
> +     }
> +    fclose(fp);
> +    todo_wine ok((count1 == count2), "fseek caused short read %d vs %d\n", count2, count1);
>     unlink("ascii.tst");
>  }

MSVCRT: Still problems in ASCII Mode

[Uwe Bonnes]

> > > > > "Dan" == Dan Kegel <dank(a)kegel.com> writes:

Dan> Thanks.  Please don't use rand() in testcases, though.  Would a
    Dan> constant 'a' suffice in this case?

    Dan> Which app did you find this in, btw?

It the application that can be downloaded for free after registration on
http://forms.analog.com/form_pages/rfcomms/adisimpll.asp?ref=ASC-PR-067
running the tutorial

Appended a changed test case, writing one single line. It starts to fail
when the file, including CR and LF gets bigger then 512 bytes. This hits
probably 
                /* in text mode, strip \r if followed by \n.
                 * BUG: should save state across calls somehow, so CR LF that
                 * straddles buffer boundary gets recognized properly?
                 */

It is not clear, if this  is the real cause for the simpll.exe failure.

Bye

-- 
Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------
diff --git a/dlls/msvcrt/tests/file.c b/dlls/msvcrt/tests/file.c
index 9032e51..cd377af 100644
--- a/dlls/msvcrt/tests/file.c
+++ b/dlls/msvcrt/tests/file.c
@@ -306,7 +306,7 @@ static void test_asciimode(void)
 {
     FILE *fp;
     char buf[64];
-    int c, i, j;
+    int c, i, j, done, count1, count2;
 
     /* Simple test of CR CR LF handling.  Test both fgets and fread code paths, they're different! */
     fp = fopen("ascii.tst", "wb");
@@ -372,6 +372,44 @@ static void test_asciimode(void)
     ok((c = fgetc(fp)) == '1', "fgetc fails to read next char when positioned on \\r\n");
     fclose(fp);
 
+    fp= fopen("ascii.tst","wb");
+    for (i=0; i<511; i++)
+      {
+	fputc('a', fp);
+      }
+    fputs("\r\n", fp);
+    fclose(fp);
+
+    done = 0;
+    count1 = 0;
+    
+    fp = fopen("ascii.tst", "r");
+    while (!done)
+      {
+	c= fgetc(fp);
+	if (c == EOF)
+	  done =  1;
+	else if (isgraph(c))
+	  count1 ++;
+      }
+    fclose(fp);
+	
+    done = 0;
+    count2 = 0;
+    
+    fp = fopen("ascii.tst", "r");
+    while (!done)
+      {
+	c= fgetc(fp);
+	fseek(fp, 0, SEEK_CUR);
+	if (c == EOF)
+	  done =  1;
+	else if (isgraph(c))
+	  count2 ++;
+     }
+    fclose(fp);
+    todo_wine ok((count1 == count2), "fseek caused short read %d vs %d\n", count2, count1);
+
     unlink("ascii.tst");
 }

MSVCRT: Still problems in ASCII Mode

[Dan Kegel]

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote:
> Appended a changed test case, writing one single line. It starts to fail
> when the file, including CR and LF gets bigger then 512 bytes. This hits
> probably
>                /* in text mode, strip \r if followed by \n.
>                 * BUG: should save state across calls somehow, so CR LF that
>                 * straddles buffer boundary gets recognized properly?
>                 */

So it turns out all 'a' obscures the problem.  Here's
a better test case.  We're seeking to one byte too far
in the file, and in this test, the last 510 bytes returned
are off by one.