On Fri, Mar 25, 2005 at 05:13:55PM -0500, Rob Richards wrote:
> Daniel Veillard wrote:
> 
> > I still think we should xmlFree() the name parameter. The underlying 
> > reason
> >is that it's an API refinement and I prefer an immediate crash immediately
> >identified in case someone expected a different behaviour than a slow 
> >memory
> >leak which may only be tracked painfully months later.
> > The function eats the name that's expected I think.
> > The case of xmlNewNodeEatName the only error is when the program runs out
> >of memory, then it will generate a leak, I will fix that, it's broken.
> > 
> >
> Hadn't thought of it that way, but I would have to agree with that 
> point. I tend to think more along the lines that if a function fails its 
> my job to perform my own cleanup.
> 
> If free'ing the name is the way to go do you want another patch? 

  If you have the patch handy, yes, sure, otherwise it's really not a big
deal :-)

> Re-tested the regressions adding xmlFree when called by eatname on the 
> name in both spots (invalid node type and xmlMalloc failure in the 
> xmlNewPropInternal function) and everything ran fine without leaking 
> this time.

  good :-) Then send the CVs diff to be sure we came to the same conclusion :-)

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
[EMAIL PROTECTED]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
[email protected]
http://mail.gnome.org/mailman/listinfo/xml

Reply via email to