If the library is built with ZEND_SIGNALS defined, it's unusable with an
external SAPI module because the zend_signal_startup() call is mandatory
in this case.
This bug is similar to #74149, but related to dynamic loading of PHP library.
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.
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.
Setting up an empty default handler is not only useless, but actually
harmful, since internal entity-references are not resolved anymore.
From the libexpat docs[1]:
| Setting the handler with this call has the side effect of
| turning off expansion of references to internally defined general
| entities. Instead these references are passed to the default
| handler.
[1] <https://www.xml.com/pub/1999/09/expat/reference.html#setdefhandler>
Before the fix for bug 48289 has been applied, the algorithm to
construct a Q-encoded-word has been optimistic, i.e. try to encode as
many bytes that *may* fit in the remaining space, calculate the actual
length of the Q-encoded word, and if it's too long, try again with a
reduced size. However, the fix for the mentioned bug replaced this by
a pessimistic algorithm, which always terminates[1] the for loop[2]
during the first iteration (which renders the following 3 lines as dead
code), and as such easily produces unnecessarily short encoded-words.
Instead the proper fix for the bug would have been to make sure that
`out_size` is always decremented, if the space isn't sufficient for the
encoded-word.
[1] <https://github.com/php/php-src/blob/php-7.3.0beta3/ext/iconv/iconv.c#L1421>
[2] <https://github.com/php/php-src/blob/php-7.3.0beta3/ext/iconv/iconv.c#L1360>
get_method() may modify the object pointer passed to it if method
forwarding is used. In this case we do not want to modify the
passed zval, so make sure that we copy the object into a temporary
first.
Whenever we return with `PSFS_PASS_ON`, we need to update
`bytes_consumed` to not mislead the caller. Instead of fixing the
respective `if` clauses, we eschew the early bail-outs to simplify the
code a bit.
According to the POSIX specification of `getgrnam_r()` the result of
`sysconf(_SC_GETGR_R_SIZE_MAX)` is an initial value suggested for the
size of the buffer, and `ERANGE` signals that insufficient storage was
supplied. So if we get `ERANGE`, we try again with a buffer twice as
big, and so on, instead of failing.
Basically, the algorithm to append a converted string to an existing
`smart_str` works by increasing the `smart_str` buffer, to let `iconv`
convert characters until there is no more space, to set the new length
of the `smart_str` and to repeat until there is no more input.
Formerly, the new length calculation has been wrong, though, since we
would have to take the old `out_len` into account (`buf_growth -
old_out_len - out_len`). However, since there is no need to take the
old `out_len` into account when increasing the `smart_str` buffer, we
can simplify the fix, avoiding an additional variable.
We must not ignore erroneous characters in mime headers, but rather let
iconv_mime_decode() fail in this case, issuing the usual notice
regarding illegal characters.
We have to cater to the possibility that `=?` is not the start of an
encoded-word, but rather a literal `=?`. If a line break is found
while we're still looking for the charset, we can safely assume that
it's a literal `=?`, and act accordingly.
If we're expecting the start of an encoded word (`=?`), but instead of
the question mark get a line break (CR or LF), we must not append it to
the `pretval`.
