In the same time, let's not verify implementation aliases since they may now legitimately differ from their aliased function/method counterparts (think about the ext/dom refactoring where e.g. many return type declarations have changed). Additionally, unnecessary `@no-verify` tags are cleaned up.
When unserializing, the cached_resize field was not reset to -1
correctly, causing the setSize() method to think we were inside of a
resize operation.
Closes GH-13543.
* Update signature of pcre API
This changes the variables that are bools to actually be bools instead
of ints, which allows some additional optimization by the compiler (e.g.
removing some ternaries and move extensions).
It also gets rid of the use_flags argument because that's just the same
as flags == 0. This reduces the call frame.
* Use zend_string_release_ex where possible
* Remove duplicate symbols from strchr
* Avoid useless value conversions
* Use a raw HashTable* instead of a zval
* Move condition
* Make for loop cheaper by reusing a recently used value as start iteration index
* Remove useless condition
This can't be true if the second condition is true because it would
require the string to occupy the entire address space.
* Upgrading + remark
When you do an assignment between two zvals (no, not zval*), you copy
all fields. This includes the additional u2 data. So that means for
example the Z_NEXT index gets copied, which in some cases can therefore
cause a cycle in zend_hash lookups.
Instead of doing an assignment, we should be doing a ZVAL_COPY (or
ZVAL_COPY_VALUE for non-refcounting cases). This avoids copying u2.
Closes GH-12086.
Upon resizing, the elements are destroyed from lower index to higher
index. When an element refers to an object with a destructor, it can
refer to a lower (i.e. already destroyed) element, causing a uaf.
Set refcounted zvals to NULL after destroying them to avoid a uaf.
Closes GH-11959.
We may OOM during object initialization. In this case, free_obj needs to guard
against NULL values. There may be more cases where this is an issue, these were
the ones I was able to discover via script.
Fixes GH-11734
This merges all usages of emitting an offset TypeError into a new ZEND_API function
zend_illegal_container_offset(const zend_string* container, const zval *offset, int type);
Where the container should represent the type on which the access is attempted (e.g. string, array)
The offset zval that is used, where the error message will display its type
The type of access, which should be a BP_VAR_* constant, to get special message for isset/empty/unset
* PHP-8.2:
Fix DOMElement::append() and DOMElement::prepend() hierarchy checks
Fix spec compliance error for DOMDocument::getElementsByTagNameNS
Fix GH-11336: php still tries to unlock the shared memory ZendSem with opcache.file_cache_only=1 but it was never locked
Fix GH-11338: SplFileInfo empty getBasename with more than one slash
* PHP-8.1:
Fix DOMElement::append() and DOMElement::prepend() hierarchy checks
Fix spec compliance error for DOMDocument::getElementsByTagNameNS
Fix GH-11336: php still tries to unlock the shared memory ZendSem with opcache.file_cache_only=1 but it was never locked
Fix GH-11338: SplFileInfo empty getBasename with more than one slash
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
