This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines in all
*.phpt sections.
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
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
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.
There's no need to actually try to trigger an out-of-memory condition
to proof the leak; instead we can simply rely on the Zend MM to report
the memory leaks in debug mode (at least on Linux). Therefore we
simplify the regression test, which also makes it run much faster.
Due to incorrect string termination and length handling, several HTML
entities missed the trailing semicolon.
We also fix the obviously wrong expectations in two already existing
tests.
The search path needs to be appended with the wild card. Till now, an
edge case existed, so then if a path is 259 bytes long, which is smaller
_MAX_PATH, the suffix would cause the final search path to become longer
than _MAX_PATH. It is an edge case, when the starting path happens to
have a specific length. If the starting path was longer than _MAX_PATH
or the addition of "\\*" would not exceed _MAX_PATH, the function was
correct. Except for rewind, which was broken in the case of the long
path.
Validate that "C" serialization payload is followed by "}" prior to
calling the unserialize() handler. This mitigates issues caused by
unserialize() not correctly handling strings that are not NUL
terminated. Making sure that there is a "}" at the end avoids the
problem.
Some JFIF images contain empty APP segments, i.e. those which consist
only of the marker bytes and the length, but without actual content.
It appears to be doubtful to have empty APP segments, but we should
apply the robustness principle, and accept these, instead of simply
failing in this case.
We choose to add empty APP segments to $imageinfo with an empty string
as value, instead of NULL, or even to omit these segments altogether.
This patch also fixes the potential issue that php_stream_read() might
not read the supposed number of bytes, which could result in garbage to
be added to the read value.
This reverts commit 94e9d0a2ae.
This code needs to be mindful about modifications to the array
happening during callback execution. It was written in a way that
only accessed the reference, which is guaranteed not to move. The
changed implementation instead accesses the array slot, leading to
use-after-free.
Run ext/standard/tests/array/bug61967.phpt under valgrind to see
the issue.
The sizeof()s for Content-Length and Transfer-Encoding were missing
the trailing ":". Apart from being generally wrong, this no longer
verified that the header actually contains a colon, leading to the
null http_header_value being used.
Additionally, in the interest of being defensive, also make sure
that http_header_value is non-null by setting it to the end of
the header line (effectively an empty string) if there is no colon.
If the following conditions are correct, this value is not going
to be used though.
