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
 wrote:
> Hello,
>
> it seems that in ASCII mode, fseek() may disturb reading. Appended patch
> adds a todo_wine.
> Bye
>
> Uwe Bonnes                [e-mail]
>
> 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  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

MSVCRT: Still problems in ASCII Mode

[Dan Kegel]

Uwe Bonnes  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.