[xml] Bugs in line and column number reporting


I've found a couple of bugs in the way libxml2 reports the line and column numbers when it finds malformed XML.

I think I could patch them in a simple way to make it work for our purposes, but obviously I don't know the libxml2 code or its use cases very well, and I'm not sure I could patch the bugs without breaking something for someone else, so I'm emailing the list so that hopefully someone more familiar with the code can fix them properly.

The bugs are:

1) When libxml2 finds a mismatched tag, like
it parses the closing tag using xmlParseNameAndCompare(), which increments ctxt->input->col for every character in the closing tag, and then if the closing tag doesn't match the opening tag, it calls xmlParseName(), which increments ctxt->input->col for every character in the closing tag *again*. So when the xmlErrorPtr reports the column number where the error occurred, it's too high, by the length of the closing tag (and may well be beyond the end of the line in the source document).

2) Calls to xmlParseEndTag1() have their "line" argument hardcoded to 0. This means that if there's a tag mismatch, xmlParseEndTag1() outputs this error message:

"Opening and ending tag mismatch: %s line %d and %s\n",
                       ctxt->name, line, name);
where line is always 0, regardless of what line the error actually occurred on. And because this "line 0" is written into the string, the calling application can't easily ignore it, which it could do with the line argument in xmlErrorPtr->line (which actually does seem to be correct).

Rachael Churchill

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