[PATCH 2/2] msvcrt/tests: Work around sscanf("%hhd") not working yet.
Signed-off-by: Serge Gautherie <winehq-git_serge_180711(a)gautherie.fr> --- 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... --- dlls/msvcrt/tests/scanf.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/dlls/msvcrt/tests/scanf.c b/dlls/msvcrt/tests/scanf.c index 07132e4..e2c619c 100644 --- a/dlls/msvcrt/tests/scanf.c +++ b/dlls/msvcrt/tests/scanf.c @@ -201,14 +201,24 @@ static void test_sscanf( void ) result = 0xdeadbeef; strcpy(buffer,"12345678"); + ret = p_sscanf(buffer, "%d", &result); + ok(ret == 1, "Wrong number of arguments read: %d\n", ret); + /* int */ + ok(result == 0x00bc614e, "Wrong number read (%08x)\n", result); + + result = 0xdeadbeef; ret = p_sscanf(buffer, "%hd", (short *)&result); ok(ret == 1, "Wrong number of arguments read: %d\n", ret); - ok(result == 0xdead614e, "Wrong number read (%x)\n", result); + /* int, truncated to short int */ + ok(result == 0xdead614e, "Wrong number read (%08x)\n", result); result = 0xdeadbeef; ret = p_sscanf(buffer, "%hhd", (char *)&result); ok(ret == 1, "Wrong number of arguments read: %d\n", ret); - ok(result == 0xbc614e, "Wrong number read (%x)\n", result); + /* int, NOT truncated to char: overflow! */ + ok(result == 0x00bc614e, "Wrong number read (%08x)\n", result); + /* int, truncated to char: intended, but not working yet! */ + todo_wine ok(result == 0xdeadbe4e || broken(result == 0x00bc614e), "Wrong number read (%08x)\n", result); strcpy(buffer,"12345678901234"); ret = p_sscanf(buffer, "%lld", &result64); -- 2.10.0.windows.1
On 11/2/19 9:51 PM, Serge Gautherie wrote:
Signed-off-by: Serge Gautherie <winehq-git_serge_180711(a)gautherie.fr> --- 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: <http://test.winehq.org/data/tests/msvcrt:scanf.html> Note that ucrtbase and msvcrt behave differently here; msvcrt's scanf() can't change its behaviour due to backwards-compatibility.
--- dlls/msvcrt/tests/scanf.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/dlls/msvcrt/tests/scanf.c b/dlls/msvcrt/tests/scanf.c index 07132e4..e2c619c 100644 --- a/dlls/msvcrt/tests/scanf.c +++ b/dlls/msvcrt/tests/scanf.c @@ -201,14 +201,24 @@ static void test_sscanf( void )
result = 0xdeadbeef; strcpy(buffer,"12345678"); + ret = p_sscanf(buffer, "%d", &result); + ok(ret == 1, "Wrong number of arguments read: %d\n", ret); + /* int */ + ok(result == 0x00bc614e, "Wrong number read (%08x)\n", result); + + result = 0xdeadbeef; ret = p_sscanf(buffer, "%hd", (short *)&result); ok(ret == 1, "Wrong number of arguments read: %d\n", ret); - ok(result == 0xdead614e, "Wrong number read (%x)\n", result); + /* int, truncated to short int */ + ok(result == 0xdead614e, "Wrong number read (%08x)\n", result);
result = 0xdeadbeef; ret = p_sscanf(buffer, "%hhd", (char *)&result); ok(ret == 1, "Wrong number of arguments read: %d\n", ret); - ok(result == 0xbc614e, "Wrong number read (%x)\n", result); + /* int, NOT truncated to char: overflow! */ + ok(result == 0x00bc614e, "Wrong number read (%08x)\n", result); + /* int, truncated to char: intended, but not working yet! */ + todo_wine ok(result == 0xdeadbe4e || broken(result == 0x00bc614e), "Wrong number read (%08x)\n", result);
strcpy(buffer,"12345678901234"); ret = p_sscanf(buffer, "%lld", &result64);
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... --
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.
participants (2)
-
Serge Gautherie -
Zebediah Figura