Re: [xml] function consolidation

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]