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
E_RECOVERABLE errors are reported as "Catchable fatal error". This is
misleading, because they actually can't be caught via try-catch statements.
Therefore we change the wording to "Recoverable fatal error" as suggested by
Nikita.
Squashed commit of the following:
commit e05d3b6732
Author: Andrea Faulds <ajf@ajf.me>
Date: Wed Mar 30 01:43:35 2016 +0100
UPGRADING and NEWS
commit 6caf1d4585
Author: Andrea Faulds <ajf@ajf.me>
Date: Sun Mar 20 21:18:33 2016 +0000
Fixes
commit 6dadb1b0ef
Author: Andrea Faulds <ajf@ajf.me>
Date: Sun Feb 14 02:15:01 2016 +0000
Add test for numeric string errors in assignment
commit bd5f04e8dd
Author: Andrea Faulds <ajf@ajf.me>
Date: Sat Feb 13 23:53:05 2016 +0000
Add test for numeric string errors
commit c72e92f16d
Author: Andrea Faulds <ajf@ajf.me>
Date: Tue Jan 26 23:28:33 2016 +0000
Add test for scientific notation in integer operations
commit d94c08852d
Author: Andrea Faulds <ajf@ajf.me>
Date: Sun Feb 14 01:25:57 2016 +0000
Disable optimiser evaluation for numeric string errors
commit 30ee954ed1
Author: Andrea Faulds <ajf@ajf.me>
Date: Sun Feb 14 01:46:25 2016 +0000
fixup
commit a6403b79e0
Author: Andrea Faulds <ajf@ajf.me>
Date: Sat Feb 13 22:00:27 2016 +0000
Do not convert error-causing numeric strings ahead-of-time
commit f9dc354014
Author: Andrea Faulds <ajf@ajf.me>
Date: Sat Feb 13 19:15:38 2016 +0000
Disable compile-time evaluation for numeric string errors
commit e05b0cc849
Author: Andrea Faulds <ajf@ajf.me>
Date: Fri Feb 5 11:42:26 2016 +0000
Make _zval_get_long_func_noisy function for inlining
commit 84d66321a5
Author: Andrea Faulds <ajf@ajf.me>
Date: Tue Jan 26 23:10:00 2016 +0000
Update tests
commit 5ac4a0cc4b
Author: Andrea Faulds <ajf@ajf.me>
Date: Tue Jan 26 22:08:19 2016 +0000
Use is_numeric_string_ex for zval_get_long etc.
commit c21f088485
Author: Andrea Faulds <ajf@ajf.me>
Date: Thu Jan 7 21:13:04 2016 +0000
Update tests
commit 63e214cf81
Author: Andrea Faulds <ajf@ajf.me>
Date: Wed Jan 6 00:28:01 2016 +0000
Warn on non-/bad numeric strings in arithmetic
This reverts commit 6f6bd8ce53.
`mt_rand()` is seedable with `mt_srand()` which means it can be used to (re)produce specific streams of numbers. All code (no matter how few instances that may be) that previously depended on this behaviour will no longer produce the same results.
This kind of change needs to be discussed before being committed.
Fixed recognition of the operator
Added opcode, still doing multiply instead of pow()
opcode now always returns int(42)
The right answer, but always a float
Yanked code from pow() implementation.
Should not handle negative long as exponent ourselves
Added test cases from pow()
Moved precedence higher than '~'
Added GMP operator overloading
Added ZEND_ASSIGN_POW (**=) operator.
Added pow() as a language construct.
Adjusted test cases for changed precedence.
Reduced pow() to shell function around ZEND_API pow_function()
Reduced test case to only contain edge cases
Added overloading test case
Moved unary minus above T_POW
Revert "Added pow() as a language construct."
Bad bad bad idea.
This reverts commit f60b98cf7a8371233d800a6faa286ddba4432d02.
Reverted unary minus behaviour due to previous revert.
Convert arrays to int(0)
Exponent with array as a base becomes int(0)
Rebase against master
Fixed tokenizer test case
The bug report actually urges PHP 5.3's behavior to be
reinstated -- that is, make "\0", when used as a separator,
be the same as no separator at all. I believe that is not a
proper course of action and that "\0" being interpreted as
no seperator was a bug in PHP 5.3.
Using "" for no separator, in both 5.3 and 5.4, before and
after this change, causes no separator to be used, so
there is no functionality loss.
