[PATCH] ole32: OleGetClipboard(): zero output interface pointer on error

[Paul Gofman]

Hi Nikolay,

    I came through this while testing COM/OLE init stuff and tried to
use OleGetClipboard to probe actual OLE state in Windows. The fact is
that on Windows OleGetClipboard succeeds for me even if Ole is not
initialized (and this is not the case in Wine). So straightforward test
will be failing on Windows (returning S_OK when I expect and error in
Wine). It is probably some separate compatibility issue. My test used to
assign 0xdeadbeef to the interface pointer and release any non-null
interface after the call regardless of status (as I saw as a common
practice in ole tests), so it crashed under wine. I just thought it is
appropriate to zero pointer on output as long it is a standard convention.
    I could possibly search for some conditions when OleGetClipboard
fails on Windows to make a valid test like this. Does it make sense or
better leave it as is for now?

Thanks,
    Paul.

On 01/13/2016 02:05 PM, Nikolay Sivov wrote:
> On 13.01.2016 13:23, Paul Gofman wrote:
>> Signed-off-by: Paul Gofman <gofmanp at gmail.com>
>> ---
>>  dlls/ole32/clipboard.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/dlls/ole32/clipboard.c b/dlls/ole32/clipboard.c
>> index ca9520f..b871bbc 100644
>> --- a/dlls/ole32/clipboard.c
>> +++ b/dlls/ole32/clipboard.c
>> @@ -2201,6 +2201,7 @@ HRESULT WINAPI OleGetClipboard(IDataObject **obj)
>>      TRACE("(%p)\n", obj);
>>  
>>      if(!obj) return E_INVALIDARG;
>> +    *obj = NULL;
>>  
>>      if(FAILED(hr = get_ole_clipbrd(&clipbrd))) return hr;
>>
> Hi, Paul.
>
> This is to handle a case when OLE was not initialized, right? If so, it
> should be easy to add a test for it. It makes sense to zero it as a
> common convention for out interface pointers, but a test won't hurt.
>
>