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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
For https://bugzilla.gnome.org/show_bug.cgi?id=737840
the fix for 724903 introduced a regression on external entities carrying
IDs, revert that patch in part and add a specific test to avoid readding it
As pointed by Christian Schoenebeck <schoenebeck@crudebyte.com>
on the list and based on some of his early patches, this preserve
content when unescaped opening angle brackets are not escaped in
textual content like:
<p> a < b </p>
<p> a <0 </p>
<p> a <=0 </p>
while still reporting the error.
For https://bugzilla.gnome.org/show_bug.cgi?id=751631
If we fail conversing the current input stream while
processing the encoding declaration of the XMLDecl
then it's safer to just abort there and not try to
report further errors.
- A typo caused an undefined symbol reference.
- A structure field name did not match the corresponding C name due to a typo.
- Some structured fields were not properly aligned.
- The long/ulong types were wrongly mapped to 64-bit types.
- A typo in a /include directive caused a compilation error.
- Doc files copy now converts from UTF-8 and split long lines.
- Adjust /include file name mapping translation for proper prefix handling.
One of the operation on the reader could resolve entities
leading to the classic expansion issue. Make sure the
buffer used for xmlreader operation is bounded.
Introduce a new allocation type for the buffers for this effect.
For https://bugzilla.gnome.org/show_bug.cgi?id=747301
Use simple HTML5 DOCTYPE for about:legacy-compat
HTML5 uses a DOCTYPE without a PUBLIC or SYSTEM identifier. It looks
like this:
<!DOCTYPE html>
I can't use XSLT to output this, because to get a DOCTYPE I have to
provide a PUBLIC or SYSTEM identifier. Luckily, the standards folks
recognized this and provided this semantically equivalent form for the
HTML DOCTYPE:
<!DOCTYPE html SYSTEM "about:legacy-compat">
But people don't like seeing the "legacy" identifier in their output.
They'd rather see the shiny new DOCTYPE. Since we know that
about:legacy-compat is defined by the W3C to be semantically equivalent
to the sans-SYSTEM DOCTYPE, we could just special-case it in the HTML
serializer in libxml2. So if you set the SYSTEM identifier to
"about:legacy-compat", you get an HTML5 short-form DOCTYPE.
If the context node is an attribute, the attribute itself is on the
descendant-or-self axis. The principal node type of this axis is element,
so the only node test that can return the attribute is "node()". In other
words, "@attr/descendant-or-self::node()" is equivalent to "@attr".
This matches the behavior of Saxon-CE.
For https://bugzilla.gnome.org/show_bug.cgi?id=737851
Unfortunately this change has introduced a problem which results in
occasional hangs on Windows when running multi-threaded on a multi-core
host.
When locking the xmlRMutex the count field is increment inside the
critical section but when unlocking the count field is decremented
outside the critical section. The increment/decrement is not atomic so
this can result in the count field being updated incorrectly.
The solution is to change xmlRMutexUnlock to decrement the count field
before leaving the critical section rather than after.
See http://envisage-project.eu/proving-android-java-and-python-sorting-algorithm-is-broken-and-how-to-fix-it/
We use a "runLen" array of size 128, so it should be nearly impossible
to have our implementation overflow.
But in any case, the fix is relatively simple -- checking two extra
conditions in the invariant calculation.
I also took this opportunity to remove some redundancy in the
left/right merge logic in the invariant loop.
For https://bugzilla.gnome.org/show_bug.cgi?id=744980
The error handling of Conditional Section also need to be
straightened as the structure of the document can't be
guessed on a failure there and it's better to stop parsing
as further errors are likely to be irrelevant.
For https://bugzilla.gnome.org/show_bug.cgi?id=744980
There are times, like on unterminated entities that it's preferable to
stop parsing, even if that means less error reporting. Entities are
feeding the parser on further processing, and if they are ill defined
then it's possible to get the parser to bug. Also do the same on
Conditional Sections if the input is broken, as the structure of
the document can't be guessed.
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).
