Re: [xml] function consolidation

[Rob Richards <rrichards ctindustries net>]

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? 
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.

>  We should really have this discussion on-list. Even if posting again the
> patch was looking like a duplicate we should stick to the list, that's why
> I'm adding it again. Someone may disagree with me for a good reason, and should
> have a chance to object, so Cc'ed to the list again.
>  
Was thinking the same thing as this went a little further than I had 
origionally thought.

Rob