Re: oleaut32: preliminary support for VT_DISPATCH as parameters to VarAdd (and other 2-operand operations) (try 2) (RESEND)

[Alexandre Julliard]

Alex Villací­s Lasso <a_villacis(a)palosanto.com> writes:
> +#define HANDLE_DISPATCH(left, right) \
> +    if ((V_VT(param_left) & VT_TYPEMASK) == VT_DISPATCH && \
> +        (V_VT(param_right) & VT_TYPEMASK) != VT_NULL) \
> +    {\
> +        HRESULT hres;\
> +        left = &tempLeft;\
> +        hres = VARIANT_FetchDispatchValue(param_left, left);\
> +        if (!SUCCEEDED(hres)) return hres;\
> +    }\
> +    if ((V_VT(param_right) & VT_TYPEMASK) == VT_DISPATCH &&\
> +        (V_VT(param_left) & VT_TYPEMASK) != VT_NULL)\
> +    {\
> +        HRESULT hres;\
> +        right = &tempRight;\
> +        hres = VARIANT_FetchDispatchValue(param_right, right);\
> +        if (!SUCCEEDED(hres)) return hres;\
> +    }

This macro is quite ugly. Also I don't see why you check the other
variant against VT_NULL first, aren't there cases where you still need
the other value?

-- 
Alexandre Julliard
julliard(a)winehq.org

oleaut32: preliminary support for VT_DISPATCH as parameters to VarAdd (and other 2-operand operations) (try 2) (RESEND)

[Alex Villací­s Lasso]

Alexandre Julliard escribió:
> Alex Villací­s Lasso <a_villacis(a)palosanto.com> writes:
> > +#define HANDLE_DISPATCH(left, right) \
> > +    if ((V_VT(param_left) & VT_TYPEMASK) == VT_DISPATCH && \
> > +        (V_VT(param_right) & VT_TYPEMASK) != VT_NULL) \
> > +    {\
> > +        HRESULT hres;\
> > +        left = &tempLeft;\
> > +        hres = VARIANT_FetchDispatchValue(param_left, left);\
> > +        if (!SUCCEEDED(hres)) return hres;\
> > +    }\
> > +    if ((V_VT(param_right) & VT_TYPEMASK) == VT_DISPATCH &&\
> > +        (V_VT(param_left) & VT_TYPEMASK) != VT_NULL)\
> > +    {\
> > +        HRESULT hres;\
> > +        right = &tempRight;\
> > +        hres = VARIANT_FetchDispatchValue(param_right, right);\
> > +        if (!SUCCEEDED(hres)) return hres;\
> > +    }
>
> This macro is quite ugly. Also I don't see why you check the other
> variant against VT_NULL first, aren't there cases where you still need
> the other value?

If I remove the check for VT_NULL on the other variant, I get this test 
failure:

../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p 
oleaut32_test.exe.so vartest.c && touch vartest.ok
fixme:variant:VarMod Could not convert left type 4096 to 20? rc == 
0x80020008
fixme:variant:VarMod Could not convert left type 8192 to 20? rc == 
0x80020008
fixme:variant:VarMod Could not convert left type 16384 to 20? rc == 
0x80020008
vartest.c:4910: Test failed: VarAdd: 1|0x0, 9|0x0: expected S_OK, vt 1, 
got 0x80020005 vt 0
vartest.c:4910: Test failed: VarAdd: 9|0x0, 1|0x0: expected S_OK, vt 1, 
got 0x80020005 vt 0
make: *** [vartest.ok] Error 2

This happens because for VarAdd, VT_NULL + VT_DISPATCH should succeed 
and give VT_NULL as a result, but the patch fetches the result value of 
the VT_DISPATCH before doing anything else. For null VT_DISPATCHs like 
the ones the test feeds the function, this causes the fetch to fail 
before the code for handling VT_NULLs is reached.

-- 
The following cryptic message was allegedly found in the inner edge of a Windows
XP installation CD:

4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420
7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074
6865206461726B6E6573732062696E64207468656D2E0A

It is rumored that only a true Unix Wizard can decypher this mysterious message,
which supposedly encodes the true nature and purpose of the software.