like zend_ini_parser.h, list zend_ini_scanner_defs.h and
zend_language_scanner_defs.h.
Add all these files to generated_files so they don't get missed.
To prevent build failures like:
make: *** No rule to make target '/code/master/ext/json/php_json_scanner_defs.h', needed by 'ext/json/json_scanner.lo'. Stop.
The code fetched the class entry into ce for objects and static
properties. However, when the actual update needs to take place (when
result_def exists), the class entry in ce was reset to NULL. So the SSA
object type update never happened. Fetch the class entry in the
result_def>=0 case instead after the reset of ce to NULL.
Fix it by extending the array sizes by one character. As the input is
limited to the maximum path length, there will always be place to append
the slash. As the php_check_specific_open_basedir() simply uses the
strings to compare against each other, no new failures related to too
long paths are introduced.
We'll let the DOM and XML case handle a potentially too long path in the
library code.
PHP’s implementation of crypt_blowfish differs from the upstream Openwall
version by adding a “PHP Hack”, which allows one to cut short the BCrypt salt
by including a `$` character within the characters that represent the salt.
Hashes that are affected by the “PHP Hack” may erroneously validate any
password as valid when used with `password_verify` and when comparing the
return value of `crypt()` against the input.
The PHP Hack exists since the first version of PHP’s own crypt_blowfish
implementation that was added in 1e820eca02.
No clear reason is given for the PHP Hack’s existence. This commit removes it,
because BCrypt hashes containing a `$` character in their salt are not valid
BCrypt hashes.
We must not instantiate the object prior checking error conditions
Moreover, we need to release the HUGE amount of memory for files which are over 4GB when throwing a ValueError
Closes GH-10545
The problem is that we're using the variable_ptr in the opcode handler
*after* it has already been destroyed. The solution is to create a
specialised version of zend_assign_to_variable which takes in two
destination zval pointers.
Closes GH-10524
There are only very narrow circumstances under which this option has
been reported to provide 1% performance gain due to reduction of TLB
misses. In many setups, this option only increases memory usage, and
will actually decrease performance. To avoid this, let's leave it
disabled by default, and let it be an explicit decision to enable it.
For a discussion, see https://github.com/php/php-src/pull/10301
Closes GH-10336
Commit a21195650e added a TSRM destructor, but that destructor
will get called by tsrm_shutdown(), which is after opcache.so has
already been unloaded, resulting in a shutdown crash, e.g.:
#0 0x00007fad01737500 in ?? ()
#1 0x000055ac54e723c4 in tsrm_shutdown () at TSRM/TSRM.c:194
#2 0x000055ac54c42180 in main (argc=80, argv=0x55ac57bc14d0) at sapi/cli/php_cli.c:1388
By calling ts_free_id() before opcache.so gets unloaded, we can easily
fix this crash bug.
* ext/opcache/zend_jit: cast function to fix -Wincompatible-pointer-types
Regression by commit a21195650e
* TSRM/win32: fix ts_allocate_dtor cast
The dtor was casted to ts_allocate_ctor; luckily, ts_allocate_dtor and
ts_allocate_ctor just happen to be the same type.
This introduces an enum `fpm_init_return_status` to propagate the status
up to fpm_main. This also makes the code clearer by not using magic
integer return numbers.
Closes GH-10388
This changes the log level for an unknown child during wait as this is
not unuasual if FPM master has pid 1 and also possible in some cases
for higher pid processes. Based on that and the fact that this is not
really a problem, there is just a debug level message emitted for pid 1
and for higher pid a warning is emitted.
Closes GH-10319
(And any PECLs returning `zend_empty_array` in the handler->get_properties
overrides)
Closes GH-9697
This is similar to the fix used in d9651a9419
for array_walk.
This should make it safer for php-src (and PECLs, long-term) to return
the empty immutable array in `handler->get_properties` to avoid wasting memory.
See https://github.com/php/php-src/issues/9697#issuecomment-1273613175
The only possible internal iterator position for the empty array is at the end
of the empty array (nInternalPointer=0).
The `zend_hash*del*` helpers will always set nInternalPointer to 0 when an
array becomes empty,
regardless of previous insertions/deletions/updates to the array.
Daniel Black