Peter Kokot [Sun, 14 Oct 2018 10:54:08 +0000 (12:54 +0200)]
Sync leading and final newlines in source code files
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.
Peter Kokot [Sun, 14 Oct 2018 10:51:01 +0000 (12:51 +0200)]
Sync leading and final newlines in source code files
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.
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.
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.
Fix #30875: xml_parse_into_struct() does not resolve entities
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.
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.
Fix #66828: iconv_mime_encode Q-encoding longer than it should be
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.
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.
Fix intermittent failures in mysqli_stmt_bind_result_format.phpt
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.
projects / php / log