This patch simplifies line endings tracked in the Git repository and
syncs them to all include the LF style instead of the CRLF files.
Newline characters:
- LF (\n) (*nix and Mac)
- CRLF (\r\n) (Windows)
- CR (\r) (old Mac, obsolete)
To see which line endings are in the index and in the working copy the
following command can be used:
`git ls-files --eol`
Git additionally provides `.gitattributes` file to specify if some files
need to have specific line endings on all platforms (either CRLF or LF).
Changed files shouldn't cause issues on modern Windows platforms because
also Git can do output conversion is core.autocrlf=true is set on
Windows and use CRLF newlines in all files in the working tree.
Unless CRLF files are tracked specifically, Git by default tracks all
files in the index using LF newlines.
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>
This is related to Zend VM regression bug #75881. The regression was fixed in the VM, so there is no user visible change from the termination correction.
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>
Newer MySQL versions are stricter about invalid values. Three issues
are fixed:
* Don't use negative values with ZEROFILL. ZEROFILL implies UNSIGNED.
* Use a legal TIMESTAMP value. TIMESTAMP does not accept a Unix timestamp.
* Specify BIGINT values as strings, to avoid overflows.
This is a cherry-pick of d2dc0a3291 from master.
There were two distinct issues here:
* $trend was compared against 'NULL' using !=, which does not work
as intended in the case where $trend==0.0.
* current_targets was declared as double(17,0), which means that
the fractional part was rounded, so that the same comparison in
SQL (rounded) and in PHP (not rounded) did not necessarily
match.
Please don't write mt_rand based tests, it takes ages to debug this
crap...
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.
