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
After commit 3e62aae1, number_format() returns string with length,
but _php_math_number_format_ex_len() didn't set string length
on nan and inf. This cause segfault when destruct the return value.
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.
[DOC] New implementation of round() to work-around inconsistencies for win32
and 64 bit platforms.
This solution is very roughly based on BSD's implmentation of round(), which
itself is an implementation of C99 standard. We take the absolute value of number
we want to round time the 10 to the power of the number of decimal spaces we are
rounding to. The resulting value is rounded up and the pre-rounded value is
subtracted from it. If the difference is greater then 0.5000000001 we round up,
otherwise we round down.
used to return "" and not bool(false). It's not worth keeping it because
STR_FREE() and zval_dtor() always have to check for it and it slows down
the general case. In addition, it seems that empty_string has been abused
quite a lot, and was used not only for setting zval's but generally in
PHP code instead of "", which wasn't the intention. Last but not least,
nuking empty_string should improve stability as I doubt every place
correctly checked if they are not mistakenly erealloc()'ing it or
calling efree() on it.
NOTE: Some code is probably broken. Each extension maintainer should
check and see that my changes are OK. Also, I haven't had time to touch
PECL yet. Will try and do it tomorrow.
negative memory size in situations where the sprintf implementation of the
host system generated less decimal places than were requested.
Resolved this issue by making number_format examine the string returned
by spprintf and have it pad to the correct number of decimal places.
Added a test-case based on the bug report; the length of decimal places
required to trigger this bug is sprintf implementation dependent; as the
implementation is now using spprintf (provided by PHP), that number is
78 digits (NDIG - 2).
# I played with the idea of enhancing sprintf to do the equivalent, but
# it was too much effort considering that the precision of floats/doubles
# is not good enough to warrant it.
# This fix could do with some QA from someone else to make sure there are
# no memory bounds problems and then MFH it to PHP_4_3
in php_config.h. Redefine the zend_* versions in the case of Win32.
This fixes the build on systems that don't provide a native version of,
say, isinf() (e.g. Solaris).
