prevent dereferencing null

Bill Medland billmedland at mercuryspeed.com
Mon Jan 13 20:38:17 CST 2003


On January 13, 2003 06:36 pm, you wrote:
> On January 9, 2003 10:44 pm, Marcus Meissner wrote:
> > On Thu, Jan 09, 2003 at 05:45:00PM -0800, Bill Medland wrote:
> > > On January 9, 2003 03:12 pm, Dimitrie O. Paun wrote:
> > > > On January 9, 2003 07:08 pm, Bill Medland wrote:
> > > > > +    if (!tpinfo->chanbuf) {
> > > > > +        ERR("tpinfo has no Rpc Channel Buffer\n");
> > > > > +        return 0;
> > > > > +    }
> > > >
> > > > Is this expected behaviour? If so, there's no need for the ERR msg.
> > > > If not, there's no need for the test, we need to fix the root
> > > > cause...
> > >
> > > You are, of course, quite correct.
> > > I don't know what the expected behaviour is; all I know is that
> > > dereferncing the null pointer isn't.
> > > If someone actually understands all that proxy stuff then maybe they
> > > can do something about it.
> > > If not then I guess it is destined to languish unfixed.
> >
> > I vaguely remember this happening for inter-thread COM, I did not come
> > around to debug it yet.
> >
> > "return E_FAIL;" might be more appropriate too.
> >
> > Ciao, Marcus
>
> Does anyone have any test harness/Petzold-style code for investigating
> IProxyBuffer so that we can tighten up the loose edges?
Woops.  I mean IRpcProxyBuffer

-- 
Bill Medland
ACCPAC International, Inc.
medbi01 at accpac.com
Corporate: www.accpac.com
Hosted Services: www.accpaconline.com



More information about the wine-devel mailing list