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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Fixes bug #704908
The declarations of pthread functions, used to generate weak references
to them, fail to suppress macros. Thus, if any pthread function has
been provided as a macro, compiling threads.c will fail.
This breaks on musl libc, which defines pthread_equal as a macro (in
addition to providing the function, as required).
Prevent the declarations for e.g. musl libc by refining the condition.
The idea for this solution was borrowed from the alpine linux guys, see
http://git.alpinelinux.org/cgit/aports/tree/main/libxml2/libxml2-pthread.patch
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
For https://bugzilla.gnome.org/show_bug.cgi?id=738805
The fix for CVE-2014-3660 introduced a regression in some case
where entity substitution is required and the entity is used
first in anotther entity referenced from an attribute value
When the xml parser encounters an xml encoding in an xml header while
configured with option XML_PARSE_IGNORE_ENC, it fails to free memory
allocated for storing the encoding.
The patch below fixes this.
How to reproduce:
1. Change doc/examples/parse4.c to add xmlCtxtUseOptions(ctxt,
XML_PARSE_IGNORE_ENC); after the call to xmlCreatePushParserCtxt.
2. Rebuild
3. run the following command from the top libxml2 directory:
LD_LIBRARY_PATH=.libs/ valgrind --leak-check=full
./doc/examples/.libs/parse4 ./test.xml , where test.xml contains
following
input:
<?xml version="1.0" encoding="UTF-81" ?><hi/>
valgrind will report:
==1964== 10 bytes in 1 blocks are definitely lost in loss record 1 of 1
==1964== at 0x4C272DB: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1964== by 0x4E88497: xmlParseEncName (parser.c:10224)
==1964== by 0x4E888FE: xmlParseEncodingDecl (parser.c:10295)
==1964== by 0x4E89630: xmlParseXMLDecl (parser.c:10534)
==1964== by 0x4E8B737: xmlParseTryOrFinish (parser.c:11293)
==1964== by 0x4E8E775: xmlParseChunk (parser.c:12283)
Signed-off-by: Bart De Schuymer <bart at amplidata com>
* 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
