[PATCH] msvcrt: Fix fscanf return when EOF is immediately after an end of line.

[Piotr Caban]

Hi Erich,

msvcr80 is the first dll that was changed. Attaching a hacky test that 
shows it (it also shows difference is %S format handling but it's not 
something that has to be fixed as part of your patch).

Thanks,
Piotr

On 10/18/19 9:30 PM, Erich E. Hoover wrote:
> Ah, well - glad I asked :)  How much specificity do you want in
> figuring out where this got fixed? (since there are no tests before
> msvcr90)
> 
> Best,
> Erich
> 
> On Fri, Oct 18, 2019 at 1:22 PM Piotr Caban <piotr.caban at gmail.com> wrote:
>>
>> Hi,
>>
>> The test is not failing on msvcr120 only because it’s skipped on all machines.
>>
>> The tests are linked agains msvcrt.dll, you need to load the function dynamically.
>>
>> Thanks,
>> Piotr
>>
>>> On 18 Oct 2019, at 21:15, Erich E. Hoover <erich.e.hoover at gmail.com> wrote:
>>>
>>> Wow, thanks Piotr!
>>>
>>> Are you sure you were testing against msvcr90?  I just ran a couple
>>> tries against the testbot and I see it doing what we expect on
>>> msvcr120, but msvcr90 it's giving 0 (
>>> https://testbot.winehq.org/JobDetails.pl?Key=57997 ).  I'll go through
>>> and establish exactly what version they fixed this in, but I want to
>>> make sure that there isn't something weird going on with msvcr90.
>>>
>>> Best,
>>> Erich
>>>
>>> On Fri, Oct 18, 2019 at 12:45 PM Piotr Caban <piotr.caban at gmail.com> wrote:
>>>>
>>>> Hi Erich,
>>>>
>>>> I've done some testing and here's what I found:
>>>>   - swscanf in msvcrt returns 0 as you have described
>>>>   - swscanf in msvcr90 returns WEOF
>>>>   - __stdio_common_vswscanf in ucrtbase returns WEOF
>>>>
>>>> It looks like there's a bug/backward compatibility code in native
>>>> msvcrt.dll. It would be good to do some more testing on different
>>>> *wscanf functions in msvcrt.
>>>>
>>>> I guess that the way to go is to:
>>>>   - add swscanf tests in msvcrt (you can use L"" there)
>>>>   - add swscanf tests in one of the newer dlls
>>>>   - make the implementation change specific to newer versions of C-runtime
>>>>
>>>> Hope it helps,
>>>> Piotr
>>>>
>>>> On 10/18/19 5:40 PM, Erich E. Hoover wrote:
>>>>> Hi Piotr,
>>>>>
>>>>> I just ran the widecharstring case on the testbot (
>>>>> https://testbot.winehq.org/JobDetails.pl?Key=57989 ) and that seems to
>>>>> return 0 instead of WEOF...  Are you alright with just adding this
>>>>> test to demonstrate that it doesn't work the same way?  Failing test:
>>>>> ===
>>>>>      buffer[0] = ' ';
>>>>>      buffer[1] = '\t';
>>>>>      buffer[2] = '\n';
>>>>>      buffer[3] = '\n';
>>>>>      buffer[4] = 0;
>>>>>      ret = swscanf(buffer, formats, results);
>>>>>      ok( ret == (short)WEOF, "ret = %d\n", ret );
>>>>> ===
>>>>>
>>>>> Best,
>>>>> Erich
>>>>>
>>>>> On Fri, Oct 18, 2019 at 3:49 AM Piotr Caban <piotr.caban at gmail.com> wrote:
>>>>>>
>>>>>> Hi Erich,
>>>>>>
>>>>>> On 10/17/19 5:41 PM, Erich E. Hoover wrote:
>>>>>>> +                    /* if we have reached the EOF and output nothing then report EOF */
>>>>>>> +                    if (nch==_EOF_  && rd==0 && st==0) {
>>>>>> _UNLOCK_FILE_(file);
>>>>>>> +                        return _EOF_RET;
>>>>>>> +                    }
>>>>>>
>>>>>> Please also update the widecharstring case.
>>>>>>
>>>>>>> +    fp = fopen(file_name, "wb");
>>>>>>> +    ok(fp, "fp = %p\n", fp);
>>>>>> This cause compilation warning.
>>>>>>
>>>>>> Thanks,
>>>>>> Piotr
>>>>
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tmp.diff
Type: text/x-patch
Size: 2216 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20191021/70d80969/attachment.bin>