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

Re: [xml] Varying pointers in SAX2 error reporting callbacks



On Sun, Aug 31, 2003 at 05:08:06PM +0100, Dave Beckett wrote:
> There are two methods in the xmlSAXHandler structure (in parser.h)
> for error reporting:
>   warningSAXFunc warning;
>   errorSAXFunc error;
> 
> These callbacks have the following signatures:
> 
>   typedef void (*warningSAXFunc) (void *ctx, const char *msg, ...);
>   typedef void (*errorSAXFunc) (void *ctx, const char *msg, ...);
> 
> where the first argument 'ctx' is the userData field aka
> ctxt->userData inside libxml2, or so I thought.
> 
> However, it seems that these aren't always called with that;
> sometimes they are returned ctxt itself, an xmlParserCtxtPtr.
> 
> i.e. depending on the call or the type of error, you get a
> different pointer!
> 
> I got bitten by this since I was handling an XML error that I had not
> had before - failure to find an external entity (which is in xmlIO.c,
> see below) - and the error reporting in my application just crashed.
> 
> In the latest sources in CVS:
> 
> grep 'sax->error(' *.c | grep -v 'ctxt->userData'
> 
> SAX2.c:                 ctxt->sax->error(ctxt,
> SAX2.c:     ctxt->sax->error(ctxt,
> SAX2.c:     ctxt->sax->error(ctxt,
> SAX2.c:     ctxt->sax->error(ctxt,
> SAX2.c:            ctxt->sax->error(ctxt,
> SAX2.c:     ctxt->sax->error(ctxt,
> SAX2.c:     ctxt->sax->error(ctxt,
> SAX2.c:     ctxt->sax->error(ctxt,
> parserInternals.c:        ctxt->sax->error = *((errorSAXFunc *) value);
> xmlIO.c:            ctxt->sax->error(ctxt,
> xmlIO.c:            ctxt->sax->error(ctxt,
> 
> grep 'sax->warning(' *.c | grep -v 'ctxt->userData'
> 
> SAX2.c:     ctxt->sax->warning(ctxt,
> SAX2.c:     ctxt->sax->warning(ctxt,
> SAX2.c:     ctxt->sax->warning(ctxt,
> SAX2.c:     ctxt->sax->warning(ctxt,
> xmlIO.c:            ctxt->sax->warning(ctxt,
> xmlIO.c:            ctxt->sax->warning(ctxt,
> 
> 
> If you look instead for the sax->error/warning calls with
> ctxt->userData, there are hundreds of them.  So I expect the ones
> above are the problem.

  Right that's baaad, and should be fixed !
Would you mind making a bugzilla entry so it doesn't get lost ?

> Since I want to work with installed libxml2s, I'll validate the
> returned pointer so I can pick the correct one:
> 
>   if(((raptor_parser*)ctx)->magic == RAPTOR_LIBXML_MAGIC)
>     rdf_parser=(raptor_parser*)ctx;
>   else
>     /* ctx is not userData */
>     rdf_parser=(raptor_parser*)((xmlParserCtxtPtr)ctx)->userData;
> 
> which works.

  Yup, that's the only practical way to handle this right now, sorry :-\
The problem is around ->magic there is a minimal chance of failure, better
avoid it for good.

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/



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