If the `ICONV_MIME_DECODE_CONTINUE_ON_ERROR` flag is set, parsing
should not fail, if there are illegal characters in the headers;
instead we silently ignore these like before.
Apparently, the presence of `cpuid.h` is not necessarily sufficient to
guarantee the availability of `__cpuid_count()`. We therefore test for
the latter explicitly.
If the callback set via `xml_set_external_entity_ref_handler()` returns
a falsy value, parsing is supposed to stop and the error number set to
`XML_ERROR_EXTERNAL_ENTITY_HANDLING`. This is already correctly done
by the libexpat binding, but the libxml2 binding ignores the return
value. We fix this by calling `xmlStopParser()` which is available as
of libxml 2.1.0[1] (PHP-7.1 requires at least libxml 2.6.11 anyway),
and setting the desired `errNo` ourselves.
[1] <http://xmlsoft.org/news.html>
Since we allow ext/xmlrpc to be built against a system libxmlrpc(-epi),
we must not `efree` memory which has been allocated via `malloc`. To
distinguish bundled and system libxmlrpc(-epi) we introduce the macro
`HAVE_XMLRPC_BUNDLED` (analogous to how it is done by ext/gd). We
deliberately keep the ugly `#ifdef`s, instead of tucking them away in
an `XMLRPC_FREE()` macro, to not forget that it is a bad idea to fork
and bundle a library, but to also allow building against an unpatched
system lib.
We define the `HAVE_TIDYOPTGETDOC` macro unconditionally, since the
Windows PHP SDK ships libtidy 2009/04/06 or newer for a long time.
We do not add a regression test, since 021.phpt already tests
`tidy_get_opt_doc`, but has previously been skipped due to
unavailability of the function.
Implements 8bit conversions equivalently to iso-8859-1 conversions.
This seems quite dubious to me, but seems to match the previous
behavior.
It might make more sense to map the characters into a private area
instead, so that the 8bit encoding is treated as binary data with
no case conversions (including no case conversions in the ascii
range).
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
Nikita Popov