Hi, you may want to use the attached patch, rather than the last one, since the bug occured to xmlSearchNs as well. Kasimier Buchcik wrote:
Hi, Petr Pajas wrote:Hi Daniel, All, I'm trying to make XML::LibXML perl module work with 2.6. After examining one of the self tests that broke after upgrade, I suspect that xmlReconciliateNs doesn't do its right job (if at all). The documentation says: "This function checks that all the namespaces declared within the given tree are properly declared. This is needed for example after Copy or Cut and then paste operations. ..." Now, I have a document like this: <?xml version="1.0"?> <foo><x:a xmlns:x="http://foo.bar";><x:b/></x:a></foo> and try either: a) move <x:b/> one level up, into <foo> b) move <x:b/> into another document in both cases, expecting xmlReconciliateNs to create xmlns:x="http://foo.bar"; on <x:b/>. This is at least what it used to do with libxml2-2.5.x. The attached file is my lame attempt of rewriting of the test case into C. It demonstrates the problem in the following way: 1) run it without parameters to check for a) 2) run it with 1 parameter (arbitrary) to check for b) 3) run it with 2 parameter (-"-) to check for b), freeing the original document as soon as <x:b> was moved and namespaces reconciliated. I compile it with: gcc -I /usr/include/libxml2 -L /usr/lib -lxml2 -o testns testns.c with 2.6, I get 1) ./testns <?xml version="1.0"?> <foo><x:a xmlns:x="http://foo.bar"/><x:b/></foo> (bad: x:b has prefix but no namespace declared) 2) ./testns x <?xml version="1.0"?> <x:b/> (bad) 3) ./testns x x <?xml version="1.0"?> <b/> (even worse - maybe because of the new string reusing code?) while with 2.5.3: 1) ./testns <?xml version="1.0"?> <foo><x:a xmlns:x="http://foo.bar"/><x:b xmlns:x="http://foo.bar"/></foo> 2) ./testns x <?xml version="1.0"?> <x:b xmlns:x="http://foo.bar"/> 3) ./testns x x <?xml version="1.0"?> <x:b xmlns:x="http://foo.bar"/> which all look well. I looked into the corresponding tree.c code. It appears, that xmlReconciliateNs simply does nothing, being fooled by xmlSearchNsByHref which returns node->ns even though it failed to find a corresponding nsDef. If the behavior of 2.6 is intended, is there a workaround? Thanks, -- PetrI attached a patch fixing that issue. The new speedup part of the function did not prevent the specified node's namespace to be compared to the searched one.
Kasimier
Attachment:
tree.diff
Description: Text document