IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
* add libxml2-config.cmake.in template
* configure.ac: add libxml2-config.cmake.in to the configured file list
* Makefile.am: install libxml2-config.cmake under ${libdir}/cmake/libxml2
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
For https://bugzilla.gnome.org/show_bug.cgi?id=689483
It seems there are functions that do use the const qualifier for some of the
arguments, but it seems that there are a lot of functions that don't use it and
probably should.
So I created a patch against 2.9.0 that makes as much as possible const in
tree.h, and changed other files as needed.
There were a lot of cases like "const xmlNodePtr node". This doesn't actually
do anything, there the *pointer* is constant not the object it points to. So I
changed those to "const xmlNode *node".
I also removed some consts, mostly in the Copy functions, because those
functions can actually modify the doc or node they copy from
For https://bugzilla.gnome.org/show_bug.cgi?id=737937
Visual Studio 14 CTP (the VS which comes with Windows 10) defines snprintf().
It could be seen as a good idea as snprintf() is part of the C99 standard but
unfortunately libxml2 as many packages defines snprintf as _snprintf, the
function to use for any previous versions of the Visual Studio runtime. More,
to avoid hiding/shadowing snprintf() declaration in stdio.h is protected by an
"#ifdef snprintf" followed by an "#error", so compilation fails.
But the fix is easy: the corresponding C/C++ compiler defines _MSC_VER to 1900
so it is enough to guard the snprintf define against it, cf. the attached patch
for win32config.h (from 2.9.1 "latest" tarball).
For https://bugzilla.gnome.org/show_bug.cgi?id=737532
add save, change and restore LDFLAGS before AC_CHECK_LIB call
when functions gzread and lzma_code are searching inside action-if-found
of AC_CHECK_HEADERS
For https://bugzilla.gnome.org/show_bug.cgi?id=672539
Reported by Axel Miller <axel.miller@ppi.de>
Consider the following start-tag:
<x xmlns=""version="">
The start-tag does not conform to the rule
[40] STag ::= '<' Name (S Attribute)* S? '>'
since there is no whitespace in front of the attribute "version".
Thus, libxml2 should reject the start-tag.
But it doesn't:
$ echo '<x xmlns=""version=""/>' | xmllint -
<?xml version="1.0"?>
<x xmlns="" version=""/>
The error seems to happen only if there is a namespace declaration in
front of
the attribute. A missing whitespace between other attributes is handled
correctly:
$ echo '<x someattr=""version=""/>' | xmllint -
-:1: parser error : attributes construct error
<x someattr=""version=""/>
^
[...]
For https://bugzilla.gnome.org/show_bug.cgi?id=734017
Solaris has had libxml2 version 2.9.1 for a while, with Python versions 2.6 and
2.7. While preparing to also build a module for Python 3.4, we ran into an
issue with the test case sync.py failing. The failure involved parsing a
string that included a Python dictionary, then complaining when the order of
the parsed result did not match the original order. But Python dictionaries
are unordered by definition; see section 5.5 of
https://docs.python.org/2/tutorial/datastructures.html . For whatever reason,
Python 2.6 and 2.7 always happened to report the pair of values back in their
original order, but with Python 3.4 the order is random. The attached patch
allows for either order; it also fixes a typo that was repeated several times
thanks to the magic of copy & paste.
If dup() fails and returns -1, gzdopen() will transparently return NULL,
but then close() will fail after being called on an invalid FD. Change
the code to only call close() on valid FDs.
Coverity issue: #72382
As written by Martin Kletzander <mkletzan@redhat.com>:
Since commit 8eb55d782a, when you parse
and save an URI that has no server (or similar) part, two slashes
after the 'schema:' get lost. It means 'uri:///noserver' is turned
into 'uri:/noserver'.
basically
foo:///only/path
means a host of "" while
foo:/only/path
means no host at all
So the best fix IMHO is to fix the URI parser to record the first
case and an empty host string and the second case as a NULL host string
I would not revert the initial patch, we should not 'invent' those
slash, but we should instead when parsing keep the information that
it's a host based path and that foo:/// means the presence of a host
but an empty one.
Once applied the resulting patch below, all cases seems to be saved
properly:
thinkpad:~/XML -> ./testURI uri:/noserver
uri:/noserver
thinkpad:~/XML -> ./testURI uri:///noserver
uri:///noserver
thinkpad:~/XML -> ./testURI uri://server/foo
uri://server/foo
thinkpad:~/XML -> ./testURI uri:/noserver/foo
uri:/noserver/foo
thinkpad:~/XML -> ./testURI uri:///
uri:///
thinkpad:~/XML -> ./testURI uri://
uri://
thinkpad:~/XML -> ./testURI uri:/
uri:/
thinkpad:~/XML ->
If you revert the initial patch that last case fails
The problem is that I don't want to change the xmlURI structure to
minimize ABI breakage, so I could not extend the field. The natural
solution is to denote that uri:/// has an empty host by making
the uri server field an empty string which works very well but breaks
applications (like libvirt ;-) who blindly look at uri->server
not being NULL to try to reach it !
Simplest was to stick the port to -1 in that case, instead of 0
application don't bother looking at the port of there is no server
string, this makes the patch more complex than a 1 liner, but
is better for ABI.
xmlCoreDepthFirstItertor and xmlCoreBreadthFirstItertr only
implement a python2-compatible iterator interface. The next()
method has been changed to __next__(). An alias has been
defined to keep python2 compatibility.
For https://bugzilla.gnome.org/show_bug.cgi?id=734280
libxml2 reports wrong error column numbers (field int2 in xmlError)
in structured error handler, after parsing XML attribute values.
Example XML:
<?xml version="1.0" encoding="UTF-8"?>
<root
xmlns="urn:colbug">&</root>
<!--
1 2 3 4
1234567890123456789012345678901234567890
-->
Expected location of the error would be line 3, column 21.
The actual location of the error is line 3, column 9:
$ ./xmlparse colbug2.xml
colbug2.xml:3:9: xmlParseEntityRef: no name
The 12 characters of the xmlns attribute value "urn:colbug" are
not accounted for in the error column value.
For https://bugzilla.gnome.org/show_bug.cgi?id=734276
libxml2 reports wrong error column numbers (field int2 in xmlError)
in structured error handler, after an XML declaration containing
whitespace.
Example XML:
<?xml version="1.0" encoding="UTF-8" ?><root>&</root>
<!--
1 2 3 4 5 6
123456789012345678901234567890123456789012345678901234567890
-->
Expected location of the error would be line 1, column 53.
The actual location of the error is line 1, column 44:
$ ./xmlparse colbug1.xml
colbug1.xml:1:44: xmlParseEntityRef: no name
For https://bugzilla.gnome.org/show_bug.cgi?id=734363
When using xml schema validation, structured error callbacks do not get
passed a valid column number in xmlError field "int2".
$ ./xmlsaxparse colbug5.xml colbug5.xsd
colbug5.xml:3:0: Element '{urn:colbug5}bx': This element is not
expected.
Expected is ( {urn:colbug5}b ).
The schema error is reported for line 3, column 0 (= N/A).
I'd like to have the column number of the error passed in the xmlError
structure. With this test case: line 3, column 9.
