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
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.
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.
Fixes bugs #61967, #62607, #69068, #70713.
The primary changes are:
a) Use the ht_iterator mechanism to ensure safety not only if the
iterated array itself changes, but also if it is replaced (and
potentially destroyed) entirely. We use the same semantics for
behavior under modification as foreach-by-reference. In
particular, we advance to the next element before processing it.
If the iterated entity is exchanged we iterate the new one from
the start. If it is not an array/object we warn and abort.
b) Always create a reference to the current value. Previously the
code kept the value as a non-reference and updated it to the
reference value produced by the user callback. However this is
unsafe, as the array may have been reallocated in the meantime,
so the previous value pointer is no longer value.
c) Around a recursive walk, incref the reference containing the
array. This ensures that the location where the currently
iterated value is stored cannot be freed.
One problem I was not able to solve is that we cannot decrement
the apply count if the array is exchanged during a recursive walk.
Always duplicate the array before doing a sort with user-defined
comparison function, to avoid access to the intermediate
inconsistent state.
I've also dropped the "array modification" warning, as protection
against modifications is no longer relevant if we're always working
on a copy anyway.
This also required some changes to how SplArray forwards calls to
sorting functions.
