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.
* PHP-7.1:
Fixed bug #76459 windows linkinfo lacks openbasedir check
Add NEWS
Fixed bug #76459 windows linkinfo lacks openbasedir check
Fix bug #76557: heap-buffer-overflow (READ of size 48) while reading exif data
Fix bug #76423 - Int Overflow lead to Heap OverFlow in exif_thumbnail_extract of exif.c
* PHP-7.0:
Fixed bug #76459 windows linkinfo lacks openbasedir check
Add NEWS
Fixed bug #76459 windows linkinfo lacks openbasedir check
Fix bug #76557: heap-buffer-overflow (READ of size 48) while reading exif data
Fix bug #76423 - Int Overflow lead to Heap OverFlow in exif_thumbnail_extract of exif.c
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.
Peter Kokot