Re: [xml] xmlParserHandleReference anyone?

[Daniel Veillard <veillard redhat com>]

On Thu, Jun 13, 2002 at 02:20:19PM +0200, Peter Jacobi wrote:
> Hi Daniel, All,
>
> OK, I would like to go through parser.c and parserInternals.c
> to remove the obsolote ctxt->token code.
>
> Daniel Veillard: 
> > We are in a good start to get rid of ctxt->token in the XML parser.
> > The last places where I found ctxt->token initialized is in
> > parserInternals.c:
> >
> > parserInternals.c:      ctxt->token = '&';
> > parserInternals.c:      ctxt->token = '&';
> > parserInternals.c:        ctxt->token = ent->content[0];
> >
> > but it is in xmlParserHandleReference() deprecated code, It should not
> > even be compiled in anymore.
>
> So this is the last call, if Daniel agrees:

  yep !

> ***
> *** Does anybody still use xmlParserHandleReference in 
> *** some ante-diluvian code? 
> ***

  I doubt it, it doesn't do anything anymore except printing an error
message about the use of obsolete code. This can be safely left as-is !

> Remember, that this would imply, that you modify xmllib2 sources,
> because in recent versions of libxml2 the body of 
> xmlParserHandleReference is disabled by an #if 0 block
> and the only thing the function does is giving a warning.

  Precisely, so we can go ahead with the ctxt->token cleanup !

BTW I reran xsltproc recently under valgrind (memory debug tool) using
DocBook workload, and I see a new problem in xmlParserHandlePEReference()
==13347== Invalid read of size 1
==13347==    at 0x807433E: xmlParserHandlePEReference (parser.c:903)
==13347==    by 0x8071712: xmlNextChar (parserInternals.c:1212)
==13347==    by 0x807379D: xmlSkipBlankChars (parser.c:379)
==13347==    by 0x807A4C9: xmlParseAttributeListDecl (parser.c:4255)
==13347==    Address 0x455C61B7 is 0 bytes after a block of size 55 alloc'd
==13347==    at 0x400613BE: malloc (vg_clientmalloc.c:618)
==13347==    by 0x808C752: xmlMallocLoc (xmlmemory.c:168)
==13347==    by 0x808C825: xmlMemMalloc (xmlmemory.c:221)
==13347==    by 0x8073FFF: xmlNewBlanksWrapperInputStream (parser.c:701)
==13347== 
==13347== Invalid read of size 1
==13347==    at 0x8074355: xmlParserHandlePEReference (parser.c:905)
==13347==    by 0x8071712: xmlNextChar (parserInternals.c:1212)
==13347==    by 0x807379D: xmlSkipBlankChars (parser.c:379)
==13347==    by 0x807A4C9: xmlParseAttributeListDecl (parser.c:4255)
==13347==    Address 0x455C61B8 is 1 bytes after a block of size 55 alloc'd
==13347==    at 0x400613BE: malloc (vg_clientmalloc.c:618)
==13347==    by 0x808C752: xmlMallocLoc (xmlmemory.c:168)
==13347==    by 0x808C825: xmlMemMalloc (xmlmemory.c:221)
==13347==    by 0x8073FFF: xmlNewBlanksWrapperInputStream (parser.c:701)
==13347== 

  basically it seems we now have PE refs substititions whose string is
smaller than 4 bytes, and hence leading to uninitialized memory accesses,
seems a small test is needed before the char encoding detection code.

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/