GNOME Bugzilla – Bug 734092
xmlParserCtxt.instate is changed illogically while parsing xml atrribute
Last modified: 2021-07-05 13:23:33 UTC
release: libxml2-2.7.8 file: parser.c func: xmlParseAttribute line: 8104 code context: 8099 SKIP_BLANKS; 8100 if (RAW == '=') { 8101 NEXT; 8102 SKIP_BLANKS; 8103 val = xmlParseAttValue(ctxt); 8104 ctxt->instate = XML_PARSER_CONTENT; 8105 } else { 8106 xmlFatalErrMsgStr(ctxt, XML_ERR_ATTRIBUTE_WITHOUT_VALUE, 8107 "Specification mandate value for attribute %s\n", name); 8108 return(NULL); 8109 } The xmlParserCtxt.instate is assigned to 'XML_PARSER_CONTENT' which is so unreasonable when parsing xml attribute. It will cause the xmlParserCtxt.instate changed from XML_PARSER_START_TAG to XML_PARSER_CONTENT in the SAX start element handler. Then error appears when I want to learn some other states of the SAX process by the xmlParserCtxt.instate. I wish that this bug will be fixed as soon as possible. Thanks.
I also fond that it is correct when parsing html attibute in HTMLParser.c.And this bug exists in latest version libxml2-2.9.1. Thanks
"It will cause the xmlParserCtxt.instate changed from XML_PARSER_START_TAG to XML_PARSER_CONTENT in the SAX start element handler" Where is the bug ? What the parser is currently doing is none of your business, it does propagate the event and pass the document data correctly. Now try to change that value to XML_PARSER_START_TAG there, and run the regression tests, you will see immediately it will fail :-) Don't touch the parser internals. In any case not a bug... Daniel
I just don't understand why xmlParserCtxt.instate need to change to XML_PARSER_CONTENT. Isn't it in start tag while parsing xml tag attribute? Why it is not changed while parsing html tag attribute? I want to know what's the different. I don't find any tests using the XML_PARSER_START_TAG to check the validation of xmlParserCtxt.instate in the sources of libxml2-2.7.8. I delete the 8104 line in the parser.c and re-compile the lib which is working so well in my apps. (In reply to comment #2) > "It will cause the xmlParserCtxt.instate changed from XML_PARSER_START_TAG to > XML_PARSER_CONTENT in the SAX start element handler" > Where is the bug ? > What the parser is currently doing is none of your business, it does propagate > the event and pass the document data correctly. > > Now try to change that value to XML_PARSER_START_TAG there, and run the > regression tests, you will see immediately it will fail :-) > > Don't touch the parser internals. In any case not a bug... > > Daniel
I you remove the line, make check fails ! The point is that the call before that line switch xmlParserCtxt.instate to the value for attribute content. You need to change it when going back. The HTML parser is way simpler than the XML one, you can't compare the two. Daniel
I don't find that it changes back to XML_PARSER_START_TAG after xmlParseAttribute is called. If an xml tag has atrributes, the xmlParserCtxt.instate will be XML_PARSER_CONTENT at the end of the start tag parsing. So it is still a bug. I still didn't find the check about the instate of XML_PARSER_CONTENT. Can you show me? I just want to figure out what I don't understand and wish the best of libxml2 which is an amazing library for me. Thanks! (In reply to comment #4) > I you remove the line, make check fails ! > The point is that the call before that line switch xmlParserCtxt.instate > to the value for attribute content. You need to change it when going back. > > The HTML parser is way simpler than the XML one, you can't compare the two. > > Daniel
OK, I just learned the point is that the xmlParserCtxt.instate should be changed to XML_PARSER_START_TAG but not XML_PARSER_CONTENT after xmlParseAttValueInternal is called which changes the instate to XML_PARSER_ATTRIBUTE_VALUE. I will commit a new bug about this. thanks!
Just try it will fail make check ! You have no bug and you want me to change my code in a complex place, while not even running the regression tests with the changes you suggest. the answer is NO ! That value is none of your business, if tomorrow I want to change it to XML_PARSER_FOO_BAR I will and won't consider any of your complains. You get the start tag raising a start element event, period, and that's not broken. Daniel
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/libxml2/-/issues/ Thank you for your understanding and your help.