Re: [xml] Problems with libxml2-2.6.4

[Daniel Veillard <veillard redhat com>]

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:
> > > Hi,
> > >
> > > 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,
> > >                                          int recovery);
> > >
> > > (You'll note that argument 1 is xmlSAXHandlerPtr. However, if code does the
> > > following:
> > >
> > >   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
> > > otherwise.)
> > >
> > > 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
> useful.

  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 
Linux. 
  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

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