Re: [xml] Problems with libxml2-2.6.4
- From: Daniel Veillard <veillard redhat com>
- To: Gary Pennington <Gary Pennington sun com>
- Cc: xml gnome org, Frank Mueller sun com
- Subject: Re: [xml] Problems with libxml2-2.6.4
- Date: Tue, 24 Feb 2004 12:27:56 -0500
On Tue, Feb 24, 2004 at 04:53:14PM +0000, Gary Pennington wrote:
On Tue, Feb 24, 2004 at 07:36:32AM -0500, Daniel Veillard wrote:
On Mon, Feb 23, 2004 at 05:34:14PM +0000, Gary Pennington wrote:
I have a problem with libxml2 (2.6.4).
The problem lies with xmlSAXParseFile(). This function is defined as:
XMLPUBFUN xmlDocPtr XMLCALL
xmlSAXParseFile (xmlSAXHandlerPtr sax,
const char *filename,
(You'll note that argument 1 is xmlSAXHandlerPtr. However, if code does the
xmlDocPtr doc = xmlSAXParseFile(&xmlDefaultSAXHandler, filename, 0);
Then there is an issue, since xmlDefaultSAXHandler() is defined as:
XMLPUBFUN xmlSAXHandlerV1 * XMLCALL __xmlDefaultSAXHandler(void);
(With threads enabled, XMLPUBVAR xmlSAXHandlerV1 xmlDefaultSAXHandler
This means that compiling code that uses xmlSAXParseFile with
xmlDefaultSAXHandler will generate warnings since the function expects
a XMLSAXHandlerPtr for the first argument but gets xmlSAXHandlerV1*.
I can see that there is some kind of mismatch between the xmlSAXParseFile()
function and the definition of xmlDefaultSAXHandler, but it's not clear how
best to address it.
How should this best be corrected? Is it correct to just cast the value
of &xmlDefaultSAXHandler to xmlSAXHandlerPtr?
in the transition to 2.6 the following happened:
- the parser got converted to SAX2 internally, this was discussed
on the list.
- the xmlSAXHandlerPtr structure grew up as a result, especially
new startElementNs and endElementNs callbacks
- the old public variables got transformed to use a backward compatible
- the parser interfaces check for xmlSAXHandlerPtr->initialized
and if it's not XML_SAX2_MAGIC then it assume it's a V1 interface
and us the backward compatible internal code path for it.
Using xmlDefaultSAXHandler is safe, the parser will detect it's V1 and
use the older parsing code, so a cast is fine. You just don't get the
benefits of SAX2 and some of the speedup. You're basically using a
compatibility mode for pre-2.6,
Ok. I can see that this is one way of doing it, but I don't think it's the
I've attached a patch which completely removes the need for the V1 structure.
Since the new structure is simply an extension of the old structure and the
initialized field is used to indicate V1 (or V2) processing, this patch
will still allow V1 and V2 to work together with no requirement for
(potentially) confusing casts.
The only drawback to this approach is that there is a very small increase
in memory consumption over the period of the life of the structure. (i.e.
the size of the additional structure members - 4 pointers, 16 bytes on most
The big advantage is that it is source code compatible with existing code
and you don't need to modify your source when you recompile just to do
The patch is against 2.6.4, but I can generate the patch for 2.6.7 if that's
Sorry, I cannot do this. This change the size of the global variables.
And this generate a warning at runtime if you happen to use a library
or a binary linked agaisnt libxml2 version before 2.6.0 when running on
Moreover the fact that you're using SAXv1 compatibility handling instead
of the now default SAXv2 is worth a warning at compile time (which you can
still disable with an explicit cast).
I really think the current state is the best, you get a warning at compile
time, which is good actually (you would never have discovered the change
otherwise) and at the binary compat level the loader see the same size for
the global structure.
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
] [Thread Prev