Please describe the problem:
When running xmllint to validate large xml files, all errors on lines after 65535 report back as errors on line 65535.

Steps to reproduce:
1. create an xsd which includes data validity and consistency requirements
2. Create an xml file > 65535 lines, which contains violates the xsd in lines after 65535
3. Validate the XML with the XSD:
  xmllint  --noout --schema XSDFILE XMLFILE


Actual results:
xmllint runs successfully and reports all errors in in the file, but all error messages after line 65535 report line 65535.

Expected results:
All error line numbers are accurately reported.

Does this happen every time?
Yes

Other information:
Looking at this bug: http://bugzilla.gnome.org/show_bug.cgi?id=143739

I see "lines got restricted to a short integer ... It wasn't clear that reporting the line number for very very large file would be useful anyway since editing such files manually is hazardous and they are usually generated and it's simpler to fix the problem in the generator than try to post process the instances."

I think this assumption is invalid.  In addition to using xmllint to prove that large XML files are valid according to their own schemas, line numbers are necessary to debug some possible errors.  If the error is caused by invalid data, then the data itself does show up in the error output, but the data string may or may not useful for searching in the source.  If the error is caused by missing data, then an error message that says that an X entity was missing a Y, without a line number, is not useful for debugging.

It's not clear to me from if the workarounds described in 143739 can be applied to xmllint or if this a permament loss of functionality - if so it's unfortunate, because it constrains the usefulness of xmllint.