Re: [xslt] patch - xsltAttrListTemplateProcess

[Mark Vakoc <thevakoc-xml yahoo com>]

>   Yes I understand. I understand also that it may not be trivial at all to
> reproduce on an independant test case. One debugging step which may be added
> to libxml2 is a tree construct checking debugging, like a non-verbose version
> of xmlDebugDumpxxx routines of debugXML.c but with just the PBM: checks and
> output parts. Running those checks when doing debugging (for example when
> freeing tree parts) might catch such problems. That should be investigated
> that can probably be done relatively easilly, and may lead to interesting
> results.

I think that would be a good idea, and we could introduce 'checked' builds that
would call the checking APIs in critical spots, for example in xmlFreeDoc

#ifdef LIBXML_CHECKED_BUILD
  valid = xmlDebugCheckDoc(cur);
#endif

Other than checking a node's document pointers what else can you think of that
should be validated?  The only things I can think of are:
 * a node's xmlNs declaration exists in the same document and is declared on an
ancestor node
 * a nodes last, next, prev pointers are all valid
 * nodes have the have appropriate members set correctly (i.e. a text node has
valid node->content, doesn't have children, etc.)

On an unrelated node would you have an objection to adding a unsigned long
member to the xmlNode struct?  I plan on implementing the xmldiff capability
along the lines of Microsoft's program and this member would be used to hold a
hash of the node for quick comparisions.  The hash for a node is generated by
the node's content including it's children.  I suppose I could use _private but
would prefer to keep that available outside the library.