Splited the most expensive part of inline i_zend_is_true() into a separate zend_object_is_true().
Replaced zendi_convert_to_long() with cals to zend_is_true().
Now that zend_ulong is 64bit on 64bit platforms, it should be
sufficient to always use it, rather than supporting multiple
types.
API changes:
* _zend_print_unsigned_to_buf and _zend_print_signed_to_buf
no longer exist.
* smart_str(ing)_print_long and smart_str(ing)_print_unsigned
no longer exist.
* Instead of all these, zend_print_ulong_to_buf and
zend_print_long_to_buf should be used.
* smart_str_append_generic_ex no longer exists.
* smart_str(ing)_append_off_t(_ex) no longer exists, use
smart_str(ing)_append_long(_ex) instead.
This API is experemental. It may be changed or removed.
It should be used only for really often used functions.
(Keep the original parsing code and wrap usage with #ifndef FAST_ZPP)
These function get the long / double / string value of a zval with
usual cast semantics, but without actually modifying the zval.
Didn't go on a killing spree for convert_to_* yet...
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 'result' argument of fast_add_function() may alias with either
of its operands (or both). Take care not to write to 'result' before
reading op1 and op2.
warning: 'local_dval' may be used uninitialized in this function
[-Wmaybe-uninitialized]
warning: 'dval2' may be used uninitialized in this function
[-Wmaybe-uninitialized]
A recent change (by me) introduced a call to __builtin_offsetof()
into zend_operators.h which is not defined by GCC prior to
version 4.
Changed the code to use offsetof() instead: this is defined in
<stddef.h>, so #include this header conditionally (#ifdef GNUC)
PHP should preserve the least significant bits when casting from double
to long. Zend.m4 contains this:
AC_DEFINE([ZEND_DVAL_TO_LVAL_CAST_OK], 1, [Define if double cast to long preserves least significant bits])
If ZEND_DVAL_TO_LVAL_CAST_OK is not defined, zend_operators.h had an
inline implementation of zend_dval_to_lval() that would do a cast to an
int64_t (when sizeof(long) == 4), then a cast to unsigned long and
finally the cast to long.
While this works well for doubles inside the range of values of the type
used in the first cast (int64_t in the 32-bit version and unsigned long
in the 64-bit version), if outside the range, it is undefined behavior
that WILL give varying and not particularly useful results.
This commit uses fmod() to first put the double in a range that can
safely be cast to unsigned long and then casts this unsigned long to
long. This last cast is implementation defined, but it's very likely
that this gives the expected result (i.e. the internal 2's complement
representation is unchanged) on all platforms that PHP supports. In any
case, the previous implementationa already had this assumption.
This alternative code path is indeed significantly slower than simply
casting the double (almost an order of magnitude), but that should not
matter because casting doubles with a very high absolute value is a
rare event.
Restored double->long conversion behavior to that of PHP 5.2 (on most platforms) and prior:
* Out-of-range numbers overflow/preserve least significant bits (no LONG_MAX/MIN limit)
* See bug #42868 (presumably-rare platform with different results in 5.2)
* On 32-bit platforms with 64-bit long type, a zend_long64 cast has been added,
otherwise it's the same as 5.2
* Use this conversion method everywhere instead of some plain (long) casts
Added 'L' parameter parsing specifier to ensure a LONG_MAX/MIN limit:
* Essentially what 5.3's new conversion was doing in most cases
* Functions with "limit" or "length" type params could be updated to use this,
and prevent confusing overflow behavior with huge numbers (*also* in 5.2)
- See bug #47854, for example; or even #42868 again
# Test updates coming
