Re: [xml] Problems with libxml2-2.6.4

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:

                xmlSAXParseFile         (xmlSAXHandlerPtr sax,
                                         const char *filename,
                                         int recovery);

(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
      type xmlSAXHandlerV1
    - 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
tidiest way.

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
common platforms).

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
this cast.

The patch is against 2.6.4, but I can generate the patch for 2.6.7 if that's



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

Gary Pennington
Solaris Kernel Development,
Sun Microsystems
Gary Pennington sun com

Attachment: libxml2.patch
Description: Text document

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