[xml] Bugs in line and column number reporting

[Rachael Churchill <rachael churchill linguamatics com>]

Hi

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
<abcde><abcdx>
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).

Thanks,
Rachael Churchill