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. Gary
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/
-- Gary Pennington Solaris Kernel Development, Sun Microsystems Gary Pennington sun com
Attachment:
libxml2.patch
Description: Text document