Re: [xml] Line numbers stored by libxml2

On Tue, Oct 09, 2007 at 07:43:36PM +0200, Mike Hommey wrote:

I got a report against the debian package containing xmllint [1] about
the fact that lines above 65535 are incorrectly reported as line 65535,
at least in schema validation reports.

The problem here is that the xmlNode struct only stores the line number
as an unsigned short, which explains the saturation at 65535. Now,
changing this the basic way will obviously break ABI, so I'm wondering
- you consider this bug a bug, or don't care about xml files with more
than 65535 lines,

  I consider that no normal user is gonna use an editor to edit a file at line
100,000 . Such a file is gonna be machine generated. The fix will be to fix the
generator, and the likelyhood of having the same error occur before 65,535 is
high enough that they can get the context from another occurence very probably.
  Also if using such document you usually use streaming interfaces, so the
parsing context is available and ctxt->input->line is a 32 bit int which can
be looked at to check if needed and complement the missing bit without
changing the APIs or ABIs

- you have a prefered way to fix the issue.

  Completely depends in what context, i.e. is ctxt available.

After a quick thought about the issue, I'd say it could be fixed
without breaking ABI by adding a field that would contain the 16 upper
bits of an int, with the lower bits still being in the existing field.

What would be your take ?

  Anything which change the node representation will be refused, but 
within that constraint I certainly take patches which improve the user


Red Hat Virtualization group
Daniel Veillard      | virtualization library
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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