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