The first warning may trigger an error handler, destroying the operand
and its string. So we need to protect the string in that case.
Care was taken to avoid unnecessary refcounts and to avoid touching the
hot code path.
Closes GH-18951.
The strings we encounter are either interned in which case the
persistent bool doesn't matter; or they're temporary as the code already
assumes that anyway.
This patch shrinks the function from 3332 bytes to 3173 bytes on x86-64
with GCC 15.1.1.
This allows a cheaper exception check and also does not need a release
call.
This shrinks concat_function() on x86-64 with GCC 15.1.1 from 3443 bytes
to 3332 bytes.
This API can't handle references, yet everyone keeps forgetting that it
can't and that you should DEREF upfront. Fix every type of this issue
once and for all by moving the reference handling to this Zend API.
Closes GH-18761.
The compiler compiles $value == true to ZEND_BOOL, which always returns true for
objects (with the default cast_object handler). However, when compared to a
statically unknown rhs $value == $true, the resulting opcode ZEND_IS_EQUAL would
call the objects compare handler.
The zend_objects_not_comparable() handler, which is installed for enums and
other internal classes, blanketly returns false. This does not match the
ZEND_BOOL semantics.
Object to boolean comparison is now handled directly in zend_compare(),
analogous to object to null comparison. It continuous to call the cast_object
handler, but guarantees consistent behavior across ZEND_BOOL and ZEND_IS_EQUAL.
Fixes GH-16954
Closes GH-17031
These are either undefined or defined (to value 1):
- __DragonFly__
- __FreeBSD__
- HAS_MCAST_EXT
- HAVE_GETCWD
- HAVE_GETWD
- HAVE_GLIBC_ICONV
- HAVE_JIT
- HAVE_LCHOWN
- HAVE_NL_LANGINFO
- HAVE_RL_CALLBACK_READ_CHAR
- HAVE_RL_ON_NEW_LINE
- HAVE_SQL_EXTENDED_FETCH
- HAVE_UTIME
Follow up of GH-5526 (-Wundef)
Previously this returned `int`. Many functions actually take advantage
of the fact this returns exactly 0 or 1. For instance,
`main/streams/xp_socket.c` does:
sockopts |= STREAM_SOCKOP_IPV6_V6ONLY_ENABLED * zend_is_true(tmpzval);
And `Zend/zend_compile.c` does:
child = &ast->child[2 - zend_is_true(zend_ast_get_zval(ast->child[0]))];
I changed a few places trivially from `int` to `bool`, but there are
still many places such as the object handlers which return `int` that
should eventually be `bool`.
* Add behavioural tests for incdec operators
* Add support to ++/-- for objects castable to _IS_NUMBER
* Add str_increment() function
* Add str_decrement() function
RFC: https://wiki.php.net/rfc/saner-inc-dec-operators
Co-authored-by: Ilija Tovilo <ilija.tovilo@me.com>
Co-authored-by: Arnaud Le Blanc <arnaud.lb@gmail.com>
When the code was moved to solve the uaf for memory overflow, this
caused the refcount to be higher than one in some self-concatenation
scenarios. This in turn causes quadratic time performance problems when
these concatenations happen in a loop.
Closes GH-11508.
free_op2_string may be set to false when the operands are not strings, and
`result == op1 == op2`, by re-using the same string for both operands. In that
case, the string should still be copied to result because result is not actually
a string. Also change the op1 branch to stay consistent.
Introduced by GH-10049
The following sequence of actions was happening which caused a null
pointer dereference:
1. debug_backtrace() returns an array
2. The concatenation to $c will transform the array to a string via
`zval_get_string_func` for op2 and output a warning.
Note that zval op1 is of type string due to the first do-while
sequence.
3. The warning of an implicit "array to string conversion" triggers
the ob_start callback to run. This code transform $c (==op1) to a long.
4. The code below the 2 do-while sequences assume that both op1 and op2
are strings, but this is no longer the case. A dereference of the
string will therefore result in a null pointer dereference.
The solution used here is to work with the zend_string directly instead
of with the ops.
For the tests:
Co-authored-by: changochen1@gmail.com
Co-authored-by: cmbecker69@gmx.de
Co-authored-by: yukik@risec.co.jp
Closes GH-10049.
Since lowercasing and uppercasing is a common operation for both
internal purposes and userland purposes, it makes sense to implement a
NEON accelerated version for this.
When using ZEND_NORMALIZE_BOOL(a - b) where a and b are doubles, this
generates the following instruction sequence on x64:
subsd xmm0, xmm1
pxor xmm1, xmm1
comisd xmm0, xmm1
...
whereas if we use ZEND_THREEWAY_COMPARE we get two instructions less:
ucomisd xmm0, xmm1
The only difference is that the threeway compare uses *u*comisd instead
of comisd. The difference is that it will cause a FP signal if a
signaling NAN is used, but as far as I'm aware this doesn't matter for
our use case.
Similarly, the amount of instructions on AArch64 is also quite a bit
lower for this code compared to the old code.
** Results **
Using the benchmark https://gist.github.com/nielsdos/b36517d81a1af74d96baa3576c2b70df
I used hyperfine: hyperfine --runs 25 --warmup 3 './sapi/cli/php sort_double.php'
No extensions such as opcache used during benchmarking.
BEFORE THIS PATCH
-----------------
Time (mean ± σ): 255.5 ms ± 2.2 ms [User: 251.0 ms, System: 2.5 ms]
Range (min … max): 251.5 ms … 260.7 ms 25 runs
AFTER THIS PATCH
----------------
Time (mean ± σ): 236.2 ms ± 2.8 ms [User: 228.9 ms, System: 5.0 ms]
Range (min … max): 231.5 ms … 242.7 ms 25 runs
At least on 32-bit, the address computations overflow in running the
test on CI with UBSAN enabled. Fix it by reordering the arithmetic.
Since a part of the expression is already used in the code above the
computation, this should not negatively affect performance.
Closes GH-10936.
`zend_uchar` suggests that the value is an ASCII character, but here,
it's about very small integers. This is misleading, so let's use a
C99 integer instead.
On all architectures currently supported by PHP, `zend_uchar` and
`uint8_t` are identical. This change is only about code readability.
This abstracts away, and cleans up, the flag handling for properties of
strings that hold when concatenating two strings if they both hold that
property. (These macros also work with simply copies of strings because
a copy of a string can be considered a concatenation with the empty
string.) This gets rid of some branches and some repetitive code, and
leaves room for adding more flags like these in the future.
On short strings, there is no difference in performance. However, for
strings around 10,000 bytes long, the AVX2-accelerated function is
about 55% faster than the SSE2-accelerated one.
The UTF-8 valid flag needs to be copied upon interning,
otherwise strings that are concatenated at compile time lose this information.
However, if previously this string was interned without the flag it is not added
E.g. in the case the string is an existing class name.
Co-authored-by: Niels Dossche <7771979+nielsdos@users.noreply.github.com>
I learned this trick for doing a faster bounds check with both upper
and lower bounds by reading a disassembler listing of optimized code
produced by GCC; instead of doing 2 compares to check the upper and the
lower bound, add an immediate value to shift the range you are testing
for to the far low or high end of the range of possible values for the
type in question, and then a single compare will do. Intstead of
compare + compare + AND, you just do ADD + compare.
From microbenchmarking on my development PC, this makes strtoupper()
about 10% faster on long strings (~10,000 bytes).
* Remove ZEND_DVAL_TO_LVAL_CAST_OK
As far as I can see, this operation should always use the _slow method, and the results seem to be wrong when ZEND_DVAL_TO_LVAL_CAST_OK is enabled.
* update NEWS
