Re: quartz: Check allocation failure and clear memory in DSound Renderer
On Fr, 2007-03-09 at 03:02 -0800, Chris Robinson wrote:
+ ZeroMemory(pDSoundRender, sizeof(DSoundRenderImpl));
Since you clear the whole struct, ...
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;
... there is no need to clear it again. -- By by ... Detlef
Detlef Riekenberg wrote:
@@ -325,9 +328,15 @@ HRESULT DSoundRender_create(IUnknown * pUnkOuter, LPVOID * ppv) pDSoundRender->pClock = NULL; pDSoundRender->init = FALSE; pDSoundRender->started = FALSE; ... there is no need to clear it again.
However, note that NULL is not always all binary zero in memory. :)
Dmitry Timoshkov wrote:
However, note that NULL is not always all binary zero in memory. :) I don't believe it's true since NULL is defined as (void *)0.
Actually it may aswell be just 0 in C. Just in C++ it's defined to be (void *)0. But even with just 0 an assignment/compare/whatever will get you an implicit typecast which makes the compiler generate any necessary conversion. See http://c-faq.com/null/ Felix
"Felix Nawothnig" <flexo(a)holycrap.org> wrote:
Dmitry Timoshkov wrote:
However, note that NULL is not always all binary zero in memory. :) I don't believe it's true since NULL is defined as (void *)0.
Actually it may aswell be just 0 in C. Just in C++ it's defined to be (void *)0. But even with just 0 an assignment/compare/whatever will get you an implicit typecast which makes the compiler generate any necessary conversion.
Have you read it at all? NULL is guaranteed to be 0 in all contexts. If some C++ compiler decides to generate not 0 data while converting/casting a NULL pointer, it should be declared broken. -- Dmitry.
"Dmitry Timoshkov" <dmitry(a)codeweavers.com> writes:
Have you read it at all? NULL is guaranteed to be 0 in all contexts.
If some C++ compiler decides to generate not 0 data while converting/casting a NULL pointer, it should be declared broken.
The point is that (void*)0 isn't guaranteed to be represented by an all-zero bit pattern; but that's the case on any platform worth worrying about. -- Alexandre Julliard julliard(a)winehq.org
"Alexandre Julliard" <julliard(a)winehq.org> wrote:
The point is that (void*)0 isn't guaranteed to be represented by an all-zero bit pattern; but that's the case on any platform worth worrying about.
If (void*)0 doesn't guarantee to actually set all bits to 0, then HEAP_ZERO_MEMORY doesn't guarantee it either. -- Dmitry.
"Dmitry Timoshkov" <dmitry(a)codeweavers.com> writes:
If (void*)0 doesn't guarantee to actually set all bits to 0, then HEAP_ZERO_MEMORY doesn't guarantee it either.
Yes, that's the point. In theory you have to initialize things with an explicit assignment, instead of a memset or HEAP_ZERO_MEMORY. In practice it doesn't matter. -- Alexandre Julliard julliard(a)winehq.org
On Fri, 9 Mar 2007, Felix Nawothnig wrote:
Detlef Riekenberg wrote:
@@ -325,9 +328,15 @@ HRESULT DSoundRender_create(IUnknown * pUnkOuter, LPVOID * ppv) pDSoundRender->pClock = NULL; pDSoundRender->init = FALSE; pDSoundRender->started = FALSE; ... there is no need to clear it again.
However, note that NULL is not always all binary zero in memory. :)
Isn't it zero on all sane systems, i.e. all systems we care about and even more? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner
participants (5)
-
Alexandre Julliard -
Detlef Riekenberg -
Dmitry Timoshkov -
Felix Nawothnig -
Francois Gouget