Bug 177282

Summary: xmlNode member 'line' is 16-bit integer, many XML files are longer than 65535 lines
Product: Red Hat Enterprise Linux 4 Reporter: starlight
Component: libxml2Assignee: Daniel Veillard <veillard>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://bugzilla.gnome.org/show_bug.cgi?id=325533
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-01-09 09:10:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
BI safe change 'line' member of 'xmlNode' from 16-bit to 32-bit integer none

Description starlight 2006-01-08 21:35:18 UTC
The 'line' member of 'xmlNode' is 16-bits long and useless
for generating error message for large XML files.

The author of 'libxml2' has been unhelpful, so I wrote a short
ABI safe patch that resolves the problem.  I'm posting this
report to save others aggravation.

See the GNOME bug report for discussion and details.


RH libxml2-2.6.16-6
GNOME libxml2-2.6.22

'libxml2' compiled with the patch will work for both 
applications compiled and linked against the regular 
'libxml2.so' and programs compiled and linked with the patched 
'libxml2'.  However patch-version applications will see garbage 
line numbers if run against the standard 'libxml2'.  This can
be prevented with a minor-version 'soname' tweak and/or
library version dependency (I'm fuzzy on the details
of the latter, never having done it myself), but I've got
no time to fiddle with this.

Comment 1 starlight 2006-01-08 21:35:18 UTC
Created attachment 122932 [details]
BI safe change 'line' member of 'xmlNode' from 16-bit to 32-bit integer

Comment 2 Daniel Veillard 2006-01-09 09:10:16 UTC
As already posted on the GNOME bugzilla, those kind of changes are a trade-off.
The RHEL version won't diverge from upsteam, this should be discussed there.
Large instance are streamed anyway, not processed with a DOM, this patch 
just makes the DOM based processing harder by inflating the in-memory size,
while for streaming processing getting the line number should be doable without
breaking inflating the size of DOM trees.