On 08/11/2010 11:11 PM, Austin Lund wrote:
On 12 August 2010 14:23, Vitaliy Margolen<wine-de...@kievinfo.com> wrote:
On 08/11/2010 09:14 PM, Austin Lund wrote:
On 11 August 2010 20:12, David Adam<david.adam.c...@gmail.com> wrote:
I wasn't sure of the best way to do this. But basically I want to
check that the Vtbl had been set. I cannot cast to
IDirectMusicPortImpl and I'm still confused by the COM macros.
You shouldn't be checking for any vtbl, it's all object's internal stuff. If
you must check a pointer if it's null or not, then do that explicitly.
Pointers have different size in 32-bit and 64-bit architectures.
Also you don't need two things pointing to one another. IDirectMusicPort is
a pointer in a first place. So no need for memset either. And no need for
all the extra traces that print the same stuff. You already checking if it's
null or not. The value of the pointer won't be of any use.
The setting (or not) of the Vtbl is exactly why the crash in bug 22598
occurs. So if I'm not allowed to test for this, then this bug
shouldn't have a test written for it?
The IDirectMusicPort is a pointer. To zero it you do "ptr = NULL". Don't
mention any vtbs in test. Think of it an (void*) pointer - what it points to
shouldn't matter.
The test I wrote for this bug just ensures that the object has
something put into it to avoid the segfault.
You can't test that. All you can test is that you got the IDirectMusicPort
back or not. What exactly inside is irrelevant.
And if IDirectMusicPerformance8_PChannelInfo succeeds and you getting not
null pDirectMusicPort back but it points to bogus data or is unchanged (as
it is now), it's outright invalid behavior that should be fixed. No tests
needed for that.
Vitaliy.
