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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The XPath engine tries to guarantee that every XPath function can pop
'nargs' non-NULL values off the stack. libxslt, for example, relies on
this assumption. But the check isn't thorough enough if there are errors
during the evaluation of arguments. This can lead to segfaults:
https://mail.gnome.org/archives/xslt/2013-December/msg00005.html
This commit makes the handling of function arguments more robust.
* Bail out early when evaluation of XPath function arguments fails.
* Make sure that there are 'nargs' arguments in the current call frame.
Middle dot pairs (as in [1]) turned to grave accents/backticks,
section signs to dollars (for compatibility with ASCII).
[1] http://www.w3.org/TR/xmlschema-1/
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
For https://bugzilla.gnome.org/show_bug.cgi?id=711149
In Function:
int xmlCharEncCloseFunc(xmlCharEncodingHandler *handler)
If the freed handler is any one of handlers[i] list, then it will make that
hanldlers[i] as dangling. This may lead to crash issues at places where
handlers is read.
For https://bugzilla.gnome.org/show_bug.cgi?id=719515
fixes htmlParseTryOrFinish to interpret HTML_PARSE_NODEFDTD,
and updates xmllint to actually pass --nodefdtd to the push
version of the HTML parser
For https://bugzilla.gnome.org/show_bug.cgi?id=712528
Related to https://bugzilla.redhat.com/show_bug.cgi?id=877567
There is a bug in xzlib.c which causes certain compressed XML files to fail to
load correctly. The code in xz_decomp which attempts to verify the checksum
and length of the expanded data fails if the checksum or length at the end of
the file crosses a 1024 byte boundary. It calls gz_next4 to get those two
values. This function uses the stream state in state->zstrm, but calls
xz_avail which uses the state->strm stream info. This causes gz_next4 to
signal a premature EOF if the data it is fetching crosses a 1024 byte boundary.
This means that liblzma’s Libs.private will be included in LZMA_LIBS if
linking the libraries statically, ensuring that there are no undefined
symbol errors from liblzma’s private libraries.
If pkg-config isn’t installed, or if liblzma.pc couldn’t be found, fall
back to using AC_CHECK_LIB as before. This will cause static linking to
fail, but that’s not a regression.
This does not introduce a compile time dependency on pkg-config.
https://bugzilla.gnome.org/show_bug.cgi?id=711026
If libxml2 is built and linked against liblzma, the latter needs to appear in
libxml2’s Libs.private pkg-config field, otherwise static linking against
libxml2 will fail due to unresolved liblzma symbols.
https://bugzilla.gnome.org/show_bug.cgi?id=711026
My attempt to optimize XPath expressions containing '//' caused a
regression reported in bug #695699. This commit disables the
optimization for expressions of the form '//foo[predicate]'.
