Re: [xml] Problems with libxml2-2.6.4

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:

                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

  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
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]