The arg_info member of zend_function is now always a zend_arg_info*. Before,
it was a zend_internal_arg_info* on internal functions, unless the
ZEND_ACC_USER_ARG_INFO flag was set.
Closes GH-19022
This is unused both within php-src and a SourceGraph search returned 0 results.
This is also confusing as it talks about symbol tables without actually using any of the corresponding update functions.
Abstracting away the bool parameter is not that useful, and doesn't make the code more legible.
Moreover, it is not needed if one passes the zend_function* directly, which we always have.
This is because it can be derived/copied from the fn_flags.
The initial motivation was to see if it is possible to make the `func` field of `_zend_execute_data` constant.
For various reasons, this is not possible, but the added `const` qualifiers during this exploration remain useful.
The name of this function is confusing, it doesn't make a zval callable just normalizes strings to an array pair if the string references a static method.
In general, to store a userland function it is encouraged to store the resolved FCC rather than the zval.
Moreover, a sourcegraph search shows no usage of this API in external open source code.
RFC: https://wiki.php.net/rfc/deprecations_php_8_5#remove_disable_classes_ini_setting
This took longer to merge than expected but the initial motivation from 2 years ago still applied:
As described in the email to the PHP internals list [1] this feature is fundamentally broken and pointless.
Only internal classes can be disable which brings the following observation. On a minimal build of PHP, with only the mandatory extensions enabled, there are 148 classes/interfaces/traits defined. [2]
Other than the SPL ones (and even then), disabling any of these classes will cause issues within the engine.
Moreover, the SPL ones are not a security concern.
Therefore, any other class that can be disabled must come from an extension that can be disabled altogether. And "disabling" a class from an extension without disabling said extension will render it useless anyway.
If a hosting provided is concerned about an extension, then it should not enable it in the first place. Not break it ad hoc.
Considering the above, I cannot see how this functionality was ever useful.
This is in stark contrast to the disable_functions INI setting, which can be used to selectively remove functionality of an extension without breaking it overall.
What makes this setting particularly broken is that it does not unregister the class, it only overwrites the create CE handler to emit a warning and purge the properties and function hashtables. This leads to various use after free, segfaults, and broken expectations for the engine and extensions which define said classes. On top of that, it is possible to actually instantiate such a class (and even classes which actually disallow this like ext/imap) in userland, and pass it to function that are typed against said class without raising a TypeError. However, when trying to do anything with said object stuff is going to explode in countless ways.
[1] https://news-web.php.net/php.internals/120896
[2] https://gist.github.com/Girgias/63d55ba1e50b580412b004046daed02b
This returns the usual `{closure:FILE_NAME/FUNCTION:LINE_NO}` for anonymous functions rather than `Closure::__invoke` this is visible for `is_callable()` and any Engine call that uses `zend_fcall_info_init()` to get the name of the callable.
Related to GH-18063.
DL_LOAD now doesn't use RTLD_DEEPBIND deepbind anymore on platforms
where dlmopen with LM_ID_NEWLM is available:
this means shared library symbol isolation (if needed) must be enabled on
the user side when requiring libphp.so, by using dlmopen with LM_ID_NEWLM
instead of dlopen.
RTLD_DEEPBIND is still enabled when the Apache SAPI is in use.
Closes GH-10670.
Add recursion protection when emitting deprecation warnings for class
constants, since the deprecation message can come from an attribute that is
using the same constant for the message, or otherwise result in recursion.
But, internal constants are persisted, and thus cannot have recursion
protection. Otherwise, if a user error handler triggers bailout before the
recursion flag is removed then a subsequent request (e.g. with `--repeat 2`)
would start with that flag already applied. Internal constants can presumably
be trusted not to use deprecation messages that come from recursive attributes.
Fixes GH-18463
Fixes GH-17711
The motivation for this is that types should be considered immutable.
The only times this is not valid is during compilation, optimizations (opcache), or destruction.
Therefore the "normal" type foreach macros are marked to take const arguments and we add mutable version that say so in the name.
Thus add various const qualifiers to communicate intent.
We destroy classes of dl()'ed modules in clean_module_classes(), during
shutdown. Child classes of a module use structures of the parent class (such as
inherited properties), which are destroyed earlier, so we have a use-after-free
when destroying a child class.
Here I destroy classes in reverse order, as it is done in zend_shutdown() for
persistent classes.
Fixes GH-17961
Fixes GH-15367
