The (void)_dummy is apparently considered a read of an uninitialized
variable. As it is a _Bool now, which has trap representations, this
is no longer considered legal and results in somewhat odd ubsan
warnings of the form:
runtime error: load of value 0, which is not a valid value for type 'zend_bool' (aka 'bool')
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.
Add ZVAL_CHAR/RETVAL_CHAR/RETURN_CHAR as a shortcut for using
ZVAL_INTERNED_STRING and ZSTR_CHAR.
Add zend_string_init_fast() as a helper for the empty string /
one char interned string / zend_string_init() pattern.
Also add corresponding ZVAL_STRINGL_FAST etc macros.
Closes GH-5684.
We have a bunch of APIs for getting type names and it's sometimes
hard to keep them apart ... make it clear that this is the one
you definitely do not want to use.
Currently, disabling a function only replaces the internal
function handler with one that throws a warning, and a few
places in the engine special-case such functions, such as
function_exists. This leaves us with a Schrödinger's function,
which both does not exist (function_exists returns false) and
does exist (you cannot define a function with the same name).
In particular, this prevents the implementation of robust
polyfills, as reported in https://bugs.php.net/bug.php?id=79382:
if (!function_exists('getallheaders')) {
function getallheaders(...) { ... }
}
If getallheaders() is a disabled function, this code will break.
This patch changes disable_functions to remove the functions from
the function table completely. For all intents and purposes, it
will look like the function does not exist.
This also renders two bits of PHP functionality obsolete and thus
deprecated:
* ReflectionFunction::isDisabled(), as it will no longer be
possible to construct the ReflectionFunction of a disabled
function in the first place.
* get_defined_functions() with $exclude_disabled=false, as
get_defined_functions() now never returns disabled functions.
Fixed bug #79382.
Closes GH-5473.
Closes GH-5353. From now on, PHP will have reflection information
about default values of parameters of internal functions.
Co-authored-by: Nikita Popov <nikita.ppv@gmail.com>
Currently, trait methods are aliased will continue to use the
original function name. In a few places in the codebase, we will
try to look up the actual method name instead. However, this does
not work if an aliased method is used indirectly
(https://bugs.php.net/bug.php?id=69180).
I think it would be better to instead actually change the method
name to the alias. This is in principle easy: We have to allow
function_name to be changed even if op array is otherwise shared
(similar to static_variables). This means we need to addref/release
the function_name separately, but I don't think there is a
performance concern here (especially as everything is usually
interned).
There is a bit of complication in opcache, where we need to make
sure that the function name is released the correct number of times
(interning may overwrite the name in the original op_array, but we
need to release it as many times as the op_array is shared).
Fixes bug #69180.
Fixes bug #74939.
Closes GH-5226.
I noticed that we have various places where we work around macros
conflicting with PHP function names. Rather than require this,
fix our ZEND_FE etc macros to avoid pre-scan macro expansion.
This requires duplicating the ZEND_FN/ZEND_MN macros in places,
but that seems like a reasonable tradeoff.
This is inline with similar changes to the math functions. Especially,
array to number conversion makes no sense here, and is likely to hide
a programming error.
To make that feasible, we introduce the `n` specifier for classic ZPP
so we can stick with `zend_parse_method_parameters()`.
We also remove a test case, which has been degenerated to a ZPP test.
Instead add RETURN_COPY(_VALUE) macros will the expected behavior.
RETURN_ZVAL doesn't make any sense since PHP 7, but has stuck
around, probably because the alternative was to write directly to
the return_value variable.
This is one of our more common argument unions. Usage is just
prototyped in a few places, certainly not a full conversion.
I'm removing the str_replace.phpt test, because aparently it was
split up into smaller tests at some point, but the original has
not been removed.
Closes GH-4970.
Using this requires care! The zpp implementation for this union
must be consistent with the arginfo implementation!
Apart from array|object, this is probably only the case for
int|float right now.
Fixes a bug introduced in 4008704f62
The trailing comma is followed by `)` when the varargs list
is empty in the macro, which is a syntax error in C
This fixes compilation of code such as the following
PHP_FUNCTION(get_metadata) {
if (zend_parse_parameters_throw(ZEND_NUM_ARGS(), "") == FAILURE) {
return;
}
Closes GH-4896.
We now store the pointer payload and the type mask separately. This
is in preparation for union types, where we will be using both at
the same time.
To avoid increasing the size of arginfo structures, the
pass_by_reference and is_variadic fields are now stored as part of
the type_mask (8-bit are reserved for custom use).
Different types of pointer payloads are distinguished based on bits
in the type_mask.
Since `zend_parse_parameters()` throws now, there is no reason to
explicitly call `zend_parse_parameters_throw()` anymore, and since both
have actually the same implementation, we redefine the latter as macro.
