[PATCH 2/2] msvcrt/tests: Work around sscanf("%hhd") not working yet.

[Zebediah Figura]

On 11/2/19 10:35 PM, Serge Gautherie wrote:
> On 03/11/2019 04:02, Zebediah Figura wrote:
> 
>> On 11/2/19 9:51 PM, Serge Gautherie wrote:
> 
>>> The only correct result is 0xdeadbe4e, as in dlls/ucrtbase/tests/scanf.c,
>>> but test fails on Windows/ReactOS too, until Wine code is fixed...
>>
>> Where are you getting this? The test seems to pass on all of our VMs:
> 
> It passes because 0x00bc614e is wrong.
> With correct value, it fails everywhere:
> https://testbot.winehq.org/JobDetails.pl?Key=58941
> 
> NB:
> I compiled this test snippet alone on GCC (probably Linux) and got the 
> correct value.
> 
>> Note that ucrtbase and msvcrt behave differently here; msvcrt's scanf()
>> can't change its behaviour due to backwards-compatibility.
> 
> I saw "hh" support is new in C99, compared to C90.
> Do you mean overflowing is a wanted (Windows) legacy bug?
> Or should trying to use "hh" cause an explicit warning/error instead?
> At the very least, current wrong behavior should be "documented", as my 
> patch somewhat does anyway.
> 
> I am not sure if/how you want to "fix" this, but corrupting memory feels 
> rather bad to me...
> 

Well, yes. The point is anyone linking to msvcrt rather than ucrtbase
isn't expecting "%hhd" to write only one byte. I doubt that any program
in practice actually depends on this, but, well, bug-for-bug compatibility.