Re: [dlls/shdocvw] Initialize variable (Coverity)

[Nikolay Sivov]

On 2/1/2011 17:14, Paul Vriens wrote:
> Hi,
>
> Addresses Coverity #1090.
>
> If CoCreateInstance() fails we check the uninitialized urlfile variable.

Same story with urlobj. In fact it looks better to try CoCreateInstance 
first, before anything else like lstrcpy and just return earlier on failure.

[dlls/shdocvw] Initialize variable (Coverity)

[Paul Vriens]

On 02/01/2011 03:26 PM, Nikolay Sivov wrote:
> On 2/1/2011 17:14, Paul Vriens wrote:
> > Hi,
> >
> > Addresses Coverity #1090.
> >
> > If CoCreateInstance() fails we check the uninitialized urlfile variable.
>
> Same story with urlobj. In fact it looks better to try CoCreateInstance
> first, before anything else like lstrcpy and just return earlier on
> failure.

Isn't urlobj, NULL'ed by CoCreateInstance on failure?

[dlls/shdocvw] Initialize variable (Coverity)

[Nikolay Sivov]

On 2/1/2011 19:21, Paul Vriens wrote:
> On 02/01/2011 03:26 PM, Nikolay Sivov wrote:
> > On 2/1/2011 17:14, Paul Vriens wrote:
> > > Hi,
> > >
> > > Addresses Coverity #1090.
> > >
> > > If CoCreateInstance() fails we check the uninitialized urlfile 
> > > variable.
> >
> > Same story with urlobj. In fact it looks better to try CoCreateInstance
> > first, before anything else like lstrcpy and just return earlier on
> > failure.
>
> Isn't urlobj, NULL'ed by CoCreateInstance on failure?

You're right, it should null it. We don't have a test for that by the 
way (that it's nulled on unregistered class failure).
So this could be left as it is.