Voidification of Zend API which always succeeded
Use bool argument types instead of int for boolean arguments
Use bool return type for functions which return true/false (1/0)
Use zend_result return type for functions which return SUCCESS/FAILURE as they don't follow normal boolean semantics
Closes GH-6002
From an engine perspective, named parameters mainly add three
concepts:
* The SEND_* opcodes now accept a CONST op2, which is the
argument name. For now, it is looked up by linear scan and
runtime cached.
* This may leave UNDEF arguments on the stack. To avoid having
to deal with them in other places, a CHECK_UNDEF_ARGS opcode
is used to either replace them with defaults, or error.
* For variadic functions, EX(extra_named_params) are collected
and need to be freed based on ZEND_CALL_HAS_EXTRA_NAMED_PARAMS.
RFC: https://wiki.php.net/rfc/named_params
Closes GH-5357.
Run debug build shutdown GC regardless even if GC has been disabled.
Of course, this only does something meaningful if the GC has been
disabled at runtime and root collection is still enabled. We cannot
prevent leaks if GC is disabled completely.
exit() is now internally implemented by throwing an exception,
performing a normal stack unwind and a clean shutdown. This ensures
that no persistent resource leaks occur.
The exception is internal, cannot be caught and does not result in
the execution of finally blocks. This may be relaxed in the future.
Closes GH-5768.
Replace EG(autoload_func) with a C level zend_autoload hook.
This avoids having to do one indirection through PHP function
calls. The need for EG(autoload_func) was a leftover from the
__autoload() implementation.
Additionally, drop special-casing of spl_autoload(), and instead
register it just like any other autoloading function. This fixes
bug #71236 as a side-effect.
Finally, change spl_autoload_functions() to always return an array.
The distinction between false and an empty array no longer makes
sense here.
Closes GH-5696.
We regularly find new places where we forgot to reset fake_scope.
Instead of having to handle this for each caller of zend_call_function()
and similar APIs, handle it directly in zend_call_function().
This adds the following APIs:
void zend_call_known_function(
zend_function *fn, zend_object *object, zend_class_entry *called_scope,
zval *retval_ptr, int param_count, zval *params);
void zend_call_known_instance_method(
zend_function *fn, zend_object *object, zval *retval_ptr, int param_count, zval *params);
void zend_call_known_instance_method_with_0_params(
zend_function *fn, zend_object *object, zval *retval_ptr);
void zend_call_known_instance_method_with_1_params(
zend_function *fn, zend_object *object, zval *retval_ptr, zval *param);
void zend_call_known_instance_method_with_2_params(
zend_function *fn, zend_object *object, zval *retval_ptr, zval *param1, zval *param2);
These are used to perform a call if you already have the
zend_function you want to call. zend_call_known_function()
is the base API, the rest are just really thin wrappers around
it for the common case of instance method calls.
Closes GH-5692.
A time limit can be set on PHP script execution via `set_time_limit` (or .ini file).
When the time limit is reached, the OS will notify PHP and `timed_out` and `vm_interrupt`
flags are set. While these flags are regularly checked when executing PHP code, once the
end of the script is reached, they are not checked while invoking shutdown functions
(registered via `register_shutdown_function`).
Of course, if the shutdown functions are implemented *in* PHP, then the interrupt flag
will be checked while the VM is running PHP bytecode and the timeout will take effect.
But if the shutdown functions are built-in (implemented in C), it will not.
Since the shutdown functions are invoked through `zend_call_function`, add a check of the
`vm_interrupt` flag there. Then, the script time limit will be respected when *entering*
each shutdown function. The fact still remains that if a shutdown function is built-in and
runs for a long time, script execution will not time out until it finishes and the
interpreter tries to invoke the next one.
Still, the behavior of scripts with execution time limits will be more consistent after
this patch. To make the execution time-out feature work even more precisely, it would
be necessary to scrutinize all the built-in functions and add checks of the `vm_interrupt`
flag in any which can run for a long time. That might not be worth the effort, though.
It should be mentioned that this patch does not solely affect shutdown functions, neither
does it solely allow for interruption of running code due to script execution timeout.
Anything else which causes `vm_interrupt` to be set, such as the PHP interpreter receiving
a signal, will take effect when exiting from an internal function. And not just internal
functions which are called because they were registered to run at shutdown; there are
other cases where a series of internal functions might run in the midst of a script. In
all such cases, it will be possible to interrupt the interpreter now.
Closes GH-5543.
The 'int dummy' parameter to this function makes it appear that it was intended as a
signal handler, but it is not being used as such. So remove the redundant parameter.
get_gc() implementations that need to explore heterogeneous data
currently work by computing how many GC entries they need,
allocating a buffer for that and storing it on the object. This
is inefficient and wastes memory, because the buffer is retained
after the GC run.
This commit adds an API for a single global GC buffer, which can
be reused by get_gc implementations (as only one get_gc call is
ever active at the same time). The GC buffer will automatically
grow during the GC run and be discarded at the end.
Not NULLing the static_variables pointer for shadow methods during
static var shutdown would be a way to avoid this leak, but unless
there's evidence that inherited private methods with static vars are
actually a common use-case, I don't think we should keep this kind
of fragile edge-case optimization.
Fixes OSS-Fuzz #17875.
This is a fix for symfony/symfony#32995.
The behavior is:
* Throwing exception when loading parent/interface is allowed
(and we will also throw one if the class is simply not found).
* If this happens, the bucket key for the class is reset, so
it's possibly to try registering the same class again.
* However, if the class has already been used due to a variance
obligation, the exception is upgraded to a fatal error, as we
cannot safely unregister the class stub anymore.
The requirements for parent/interface are difference than for the
variance checks in type declarations. The latter can work on fully
unlinked classes, but the former need inheritance to be essentially
finished, only variance checks may still be outstanding.
Adding a new flag for this because we have lots of space, but we
could also represent these "inheritance states" more compactly in
the future.
