[2/2] oledb32/tests: Add the XP+ behaviour and mark it as todo_wine

[André Hentschel]

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