Re: [2/2] oledb32/tests: Add the XP+ behaviour and mark it as todo_wine
El 10/11/10 15:02, André Hentschel escribió:
That's the behaviour of XP and up: http://test.winehq.org/data/tests/oledb32:convert.html
It's tricky to fix in Wine as you really don't know how much space you have in dst and assuming space breaks other tests.
--- dlls/oledb32/tests/convert.c | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/dlls/oledb32/tests/convert.c b/dlls/oledb32/tests/convert.c index b9ef71f..cdae859 100644 --- a/dlls/oledb32/tests/convert.c +++ b/dlls/oledb32/tests/convert.c @@ -1469,10 +1469,15 @@ static void test_converttostr(void) memset(dst, 0xcc, sizeof(dst)); dst_len = 0x1234; hr = IDataConvert_DataConvert(convert, DBTYPE_I2, DBTYPE_STR, 0,&dst_len, src, dst, 0, 0,&dst_status, 0, 0, 0); - ok(hr == DB_E_ERRORSOCCURRED, "got %08x\n", hr); - ok(dst_status == DBSTATUS_E_DATAOVERFLOW, "got %08x\n", dst_status); + todo_wine ok(hr == S_OK || + broken(hr == DB_E_ERRORSOCCURRED /* Win9x, WinMe, NT4 and 2k */), + "got %08x\n", hr); + todo_wine ok(dst_status == DBSTATUS_S_OK || + broken(dst_status == DBSTATUS_E_DATAOVERFLOW /* Win9x, WinMe, NT4 and 2k */), + "got %08x\n", dst_status); ok(dst_len == 4, "got %d\n", dst_len); - ok(dst[0] == (char)0xcc, "got %02x\n", dst[0]); + todo_wine ok(dst[0] == '4' || + broken(dst[0] == (char)0xcc /* Win9x, WinMe, NT4 and 2k */), "got %02x\n", dst[0]);
*(short *)src = 4321; memset(dst, 0xcc, sizeof(dst));
Weird. When I wrote that test, the WinXP-SP2 virtual machine did return DB_E_ERRORSOCCURRED/DBSTATUS_E_DATAOVERFLOW on this condition (available space equal to zero), and did not touch the output buffer in the process. In my opinion, Win9x behavior is actually OK, and the behavior you observe is the one that should be flagged as broken. It is hard to imagine the newer behavior (apparently "assume unbounded output buffer if reported space is zero") as more correct than the Win9x behavior. I think this should be treated the same as your 1/2 patch, which flags the behavior as Vista-only brokenness.
Am 10.11.2010 22:24, schrieb Alex Villacís Lasso:
El 10/11/10 15:02, André Hentschel escribió:
That's the behaviour of XP and up: http://test.winehq.org/data/tests/oledb32:convert.html
It's tricky to fix in Wine as you really don't know how much space you have in dst and assuming space breaks other tests.
--- dlls/oledb32/tests/convert.c | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/dlls/oledb32/tests/convert.c b/dlls/oledb32/tests/convert.c index b9ef71f..cdae859 100644 --- a/dlls/oledb32/tests/convert.c +++ b/dlls/oledb32/tests/convert.c @@ -1469,10 +1469,15 @@ static void test_converttostr(void) memset(dst, 0xcc, sizeof(dst)); dst_len = 0x1234; hr = IDataConvert_DataConvert(convert, DBTYPE_I2, DBTYPE_STR, 0,&dst_len, src, dst, 0, 0,&dst_status, 0, 0, 0); - ok(hr == DB_E_ERRORSOCCURRED, "got %08x\n", hr); - ok(dst_status == DBSTATUS_E_DATAOVERFLOW, "got %08x\n", dst_status); + todo_wine ok(hr == S_OK || + broken(hr == DB_E_ERRORSOCCURRED /* Win9x, WinMe, NT4 and 2k */), + "got %08x\n", hr); + todo_wine ok(dst_status == DBSTATUS_S_OK || + broken(dst_status == DBSTATUS_E_DATAOVERFLOW /* Win9x, WinMe, NT4 and 2k */), + "got %08x\n", dst_status); ok(dst_len == 4, "got %d\n", dst_len); - ok(dst[0] == (char)0xcc, "got %02x\n", dst[0]); + todo_wine ok(dst[0] == '4' || + broken(dst[0] == (char)0xcc /* Win9x, WinMe, NT4 and 2k */), "got %02x\n", dst[0]);
*(short *)src = 4321; memset(dst, 0xcc, sizeof(dst));
Weird. When I wrote that test, the WinXP-SP2 virtual machine did return DB_E_ERRORSOCCURRED/DBSTATUS_E_DATAOVERFLOW on this condition (available space equal to zero), and did not touch the output buffer in the process. In my opinion, Win9x behavior is actually OK, and the behavior you observe is the one that should be flagged as broken. It is hard to imagine the newer behavior (apparently "assume unbounded output buffer if reported space is zero") as more correct than the Win9x behavior. I think this should be treated the same as your 1/2 patch, which flags the behavior as Vista-only brokenness.
Looking twice it only happens on 64-bit systems. So maybe we should really mark it broken or differ the two cases with if(sizeof(void*)==8) -- Best Regards, André Hentschel
participants (2)
-
Alex Villacís Lasso -
André Hentschel