The tradeoff here is speed. Again, if you are using standard LibXML2 API then everything will work as expected. I have no idea why do you need to create new xmlNsPtr objects - this sounds like a waste of CPU/memory to me but you might have your reasons. But this also breaks a few assumptions on how LibXML2 represents the DOM tree in memory and you are on your own in this case.
Aleksey On 3/20/14, 1:26 AM, Frank Gross wrote: > Hi, > > Actually, I have an additional layer to emulate DOM compliant API over > libxml. In that layer, I have a global list of xmlNsPtr for all > namespaces encountered by the nodes (and referenced in node->ns) of a > single XML document. And for each namespace definition (xmlns:xxx) set > on a node, a new xmlNsPtr is created and referenced in node->nsDef. So > during canonicalization process, when a node looks for a parent > namespace definition via xmlSearchNs, it can happen that the xmlNsPtr > reference from the node is different from the parent node->nsDef , even > if the href and prefix value are the same. Then of course simple pointer > comparison doesn't work. So I was asking myself if such situation cannot > happen to other people, and maybe change the pointer comparison because > depending on how people build and manipulate the document, the test is > not always accurate. > > > Frank > > > Le 20/03/2014 03:16, Aleksey Sanin a écrit : >> How do you manipulate the XML tree? If you are using "official" LibXML2 >> function then I believe this code should work just fine unless there is >> a bug in the strings dictionary. >> >> Aleksey >> >> On 3/12/14, 10:28 AM, Frank Gross wrote: >>> Hi, >>> >>> I'm getting some trouble to verify a XML signature because the >>> xmlC14NProcessNamespacesAxis() function does a xmlNsPtr pointer >>> comparison to decide whether a sub node belongs to the same default >>> namespace as an ancestor. But if the sub node has been manipulated by >>> program (in my case) to point to another xmlNsPtr with same values, the >>> canonicalization process breaks. Wouldn't it be better to check the >>> namespace href values instead as in following patch ? >>> >>> diff --git a/lib-xmlsoft-libxml2/src/c14n.c >>> b/lib-xmlsoft-libxml2/src/c14n.c >>> index 9c3cad2..f73e709 100644 >>> --- a/lib-xmlsoft-libxml2/src/c14n.c >>> +++ b/lib-xmlsoft-libxml2/src/c14n.c >>> @@ -623,7 +623,7 @@ xmlC14NProcessNamespacesAxis(xmlC14NCtxPtr ctx, >>> xmlNodePtr cur, int visible) >>> for(ns = n->nsDef; ns != NULL; ns = ns->next) { >>> tmp = xmlSearchNs(cur->doc, cur, ns->prefix); >>> >>> - if((tmp == ns) && !xmlC14NIsXmlNs(ns) && xmlC14NIsVisible(ctx, >>> ns, cur)) { >>> + if((xmlStrEqual(tmp->href,ns->href)) && >>> (xmlStrEqual(tmp->prefix,ns->prefix)) && !xmlC14NIsXmlNs(ns) && >>> xmlC14NIsVisible(ctx, ns, cur)) { >>> already_rendered = xmlC14NVisibleNsStackFind(ctx->ns_rendered, >>> ns); >>> if(visible) { >>> xmlC14NVisibleNsStackAdd(ctx->ns_rendered, ns, cur); >>> >>> Regards, >>> Frank >>> > _______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml