Tests show test propsys:propsys is failing for many Windows 7 machines. https://test.winehq.org/data/patterns-tb-win.html#propsys:propsys
It looks like windows 7 processes VT_R4 like VT_R8. (`0.125f / 0x3e000000 (float/4 byte)` becomes `5.1392085562440189e-315 / 0x3e000000 (double/8 byte)`.
Is this worth the effort to remove the failures from the test patterns page?
-- v2: propsys/tests: Add broken for unexpected value in windows 7.
From: Bernhard Übelacker bernhardu@mailbox.org
--- dlls/propsys/tests/propsys.c | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/dlls/propsys/tests/propsys.c b/dlls/propsys/tests/propsys.c index 76d6c866546..53aea0abd15 100644 --- a/dlls/propsys/tests/propsys.c +++ b/dlls/propsys/tests/propsys.c @@ -1747,6 +1747,27 @@ do \ } \ } while (0)
+#define check_PropVariantToBSTR2(type, member, value, expect_str, broken_str) \ +do \ +{ \ + PROPVARIANT check_propvar_ = {.vt = (type), .member = (value)}; \ + HRESULT check_hr_; \ + BSTR check_bstr_; \ + \ + check_hr_ = PropVariantToBSTR(&check_propvar_, &check_bstr_); \ + ok_(__FILE__, __LINE__)(check_hr_ == S_OK, \ + "PropVariantToBSTR returned %#lx.\n", check_hr_); \ + \ + if (check_hr_ == S_OK) \ + { \ + ok_(__FILE__, __LINE__)( \ + !wcscmp(check_bstr_, (expect_str)) || \ + (broken_str && broken(!wcscmp(check_bstr_, (broken_str)))), \ + "Unexpected bstr %s.\n", debugstr_w(check_bstr_)); \ + SysFreeString(check_bstr_); \ + } \ +} while (0) + static void test_PropVariantToBSTR(void) { unsigned char test_bytes[] = {1, 20, 30, 4}; @@ -1765,7 +1786,7 @@ static void test_PropVariantToBSTR(void) todo_wine { check_PropVariantToBSTR(VT_BOOL, boolVal, TRUE, L"1"); - check_PropVariantToBSTR(VT_R4, fltVal, 0.125f, L"0.125"); + check_PropVariantToBSTR2(VT_R4, fltVal, 0.125f, L"0.125", L"5.13920855624402E-315" /* Win 7 */ ); check_PropVariantToBSTR(VT_R8, dblVal, 0.456, L"0.456"); } check_PropVariantToBSTR(VT_I1, cVal, -123, L"-123");
v2: - Move the broken into a copy `check_PropVariantToBSTR2` to avoid touching all other test lines.
On Mon Mar 3 04:22:16 2025 +0000, Bernhard Übelacker wrote:
This isn't just a precision issue, but completely garbage output, right?
I think this windows version handles `VT_R4` and `VT_R8` the same. Therefore VT_R4 returns the interpretation as a double instead of a float. This is what gdb shows when placing the 0.125 to some memory and casting this to float or double:
$ gdb -q --args tools/makedep Reading symbols from tools/makedep... (gdb) starti ... (gdb) set *(long long*)$rsp = 0 (gdb) x/8xb $rsp 0x7fffffffd600: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 (gdb) set *(float*)$rsp = 0.125 (gdb) x/8xb $rsp 0x7fffffffd600: 0x00 0x00 0x00 0x3e 0x00 0x00 0x00 0x00 (gdb) print *(float*)$rsp $1 = 0.125 (gdb) print *(double*)$rsp $2 = 5.1392085562440189e-315 (gdb)So it seems not completely garbage, just the bits from a float interpreted as double. I will try to push a check_PropVariantToBSTR2 version later.
I pushed v2, is this somewhere near what you suggested?
On Mon Mar 3 12:47:08 2025 +0000, Bernhard Übelacker wrote:
I pushed v2, is this somewhere near what you suggested?
Yes, could do that. I was also thinking we could do string comparison for R4 vs R8 with the same float field value. When strings are the same presumably you get this broken case, without specifying nonsensical string constant.
-
Bernhard Übelacker -
Bernhard Übelacker (＠bernhardu)
-
Nikolay Sivov (＠nsivov)