Re: quartz: Check allocation failure and clear memory in DSound Renderer

[Robert Shearman]

Chris Robinson wrote:
>      return CLASS_E_NOAGGREGATION;
>
>  pDSoundRender = CoTaskMemAlloc(sizeof(DSoundRenderImpl));
> -
>
> if (!pDSoundRender)
> -
>    return E_OUTOFMEMORY;
> -
>
> ZeroMemory(pDSoundRender, sizeof(DSoundRenderImpl));
>
> pDSoundRender->lpVtbl = &DSoundRender_Vtbl;
> pDSoundRender->IBasicAudio_vtbl = &IBasicAudio_Vtbl;
>
> @@ -325,9 +328,15 @@ HRESULT DSoundRender_create(IUnknown * pUnkOuter, LPVOID * ppv)
>      pDSoundRender->pClock = NULL;
>      pDSoundRender->init = FALSE;
>      pDSoundRender->started = FALSE;
> - ZeroMemory(&pDSoundRender->filterInfo, sizeof(FILTER_INFO));

The check for allocation failure is good, but clearing the memory that 
is going to be initialised anyway is inefficient and unnecessary.

quartz: Check allocation failure and clear memory in DSound Renderer

[Chris Robinson]

On Friday 09 March 2007 03:26:31 am you wrote:
> The check for allocation failure is good, but clearing the memory that
> is going to be initialised anyway is inefficient and unnecessary.

Not all of it is initialized, which is what led me to create the patch (if the 
object is created then released without ever being used, it may crash trying 
to delete the dsound buffer and device, since those pointers are never 
initialized when the filter isn't processed). As fields are added or changed 
to the struct, it becomes cumbersome to keep track and make sure each field 
is initialized to 0.

I suppose I could've removed the lines that set fields to 0/FALSE/NULL, but I 
didn't think to. It doesn't hurt anything to keep them (reduntantly setting a 
few extra fields to 0 when creating the filter object is the least of the 
speed concerns), but if you really want me to remove them I can send an 
updated patch.