Re: [xml] xmlRemoveID bug and a patch

On Sun, Aug 31, 2003 at 01:45:05AM +0100, bill hobbiton cjb net wrote:
I appreciate that the 'IDness' is only defined by the presence of the
attribute and the attribute's declaration as an ID type in the DTD.  
However, the problem is that when I rename an attribute with xmlSetProp
that is an ID, the value is changed in the xml tree, but the respective
document's ID hash table is not updated to the correct value. As a result

  Right, that is a bug, point taken ! This need fixing...

of this, future xmlGetID lookups may give false positives for attributes
that were removed. So, it seems that I am supposed to remove the ID
explicitely from the documents IDs hash table with xmlRemoveID, which is
documented as removing "the given attribute from the ID table maintained
internally." In the function's present form, this appears to always fail
due to a miscast pointer:

    xmlAttrPtr cur;
    cur = xmlHashLookup(table, ID);
    if (cur != attr) {

The 'table' pointer, which refers to a document's 'ids' table has inserted
into it xmlIDPtrs by the xmlAddID function. Here, they are being cast into 
a xmlAttrPtr and compared with the xmlAttrPtr parameter 'attr'.

  Hum, right too, the ID table used to point directly to an xmlAttrPtr
and this is not the case anymore, bug #2

I understand that an attribute being an ID is dependent on the DTD. What I
am trying to get at is that xmlUnsetProp and xmlFreeProp will _check_ the
property to see if it as an ID with xmlIsID and then (attempt to) remove
the internal hash table reference with xmlRemoveID, whereas xmlSetProp
will not perform any such check. To me, it would seem logical to make this

   This is a bug in xmlSetProp, an that need to be fixed.

Please find attached a sample program and xml file that should demonstrate
the xmlRemoveID IDs hash table problem. I have hopefully included enough
commentary in the source code for you to be able to comprehend its
behavoiral objectives. If I have misinterpreted the desired use of any of
the function calls, then please accept my apologies and my polite request
that you point out where I have gone wrong. If you need any further 
clarifications of the example, please don't hesitate to contact me.

   No that's fine, thanks for the detailed program and explanations,
I will try to get those bugs fixed.



P.S. with the amount of bonces on the list due to the various Windows virus,
     subscribing is a far more reliable way to communicate. I have to batch
     delete huge quantities of error mail.

Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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