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

[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.