On 01/13/2016 09:20 PM, Nikolay Sivov wrote:
On 13.01.2016 15:00, Paul Gofman wrote:
I managed to make Windows OleGetClipboard to fail by pre-locking the clipboard by OpenClipboard and verified that output pointer is zeroed. I should note that Wine OleGetClipboard does not fail in this case. Should I add such a test to this patch (with todo_wine on OleGetClipboard returning CLIPBRD_E_CANT_OPEN)?
Sure, if tests are reliable on Windows and we don't have them already it won't hurt to add them.
I will add such test to this patch which will also verify that output pointer is natively zeroed on error (it is not a complete verification of course as in theory Windows may behave differently on different errors, though I suppose this is very unlikely).
On 01/13/2016 02:18 PM, Paul Gofman wrote:
So when OLE is not initialized on Windows it returns S_OK and valid interface pointer? It's better to test this with minimal application, not wine tests, to avoid any possible side effects of previous init/uninit sequences. Or just make it a very first test before first attempt to initialize.
Yes, this is the case (at least in my WinXP virtual machine). The same is when I make this test first (before any initializations, right at the beginning of top-level test function). I can add such a test but presumably as a separate patch as it is not related to zeroing pointer on error (I could not get OleGetClipboard failing on Windows due to unitialized OLE so far).