Object handlers being separate from class entries is a legacy inherited from PHP 5. Today it has little benefit to keep them separate: in fact, accessing object handlers usually requires not-so-safe hacks.
While it is possible to swap handlers in a custom installed create_object handler, this mostly is tedious, as well as it requires allocating the object handlers struct at runtime, possibly caching it etc..
This allows extensions, which intend to observe other classes to install their own class handlers.
The life cycle of internal classes may now be simply observed by swapping the class handlers in post_startup stage.
The life cycle of userland classes may be observed by iterating over the new classes in zend_compile_file and zend_compile_string and then swapping their handlers.
In general, this would also be a first step in directly tying the object handlers to classes. Especially given that I am not aware of any case where the object handlers would be different between various instances of a given class.
Signed-off-by: Bob Weinand <bobwei9@hotmail.com>
* Emit deprecation warnings when adding dynamic properties to classes during unserialization - this will become an Error in php 9.0.
(Adding dynamic properties in other contexts was already a deprecation warning - the use case of unserialization was overlooked)
* Throw an error when attempting to add a dynamic property to a `readonly` class when unserializing
* Add new serialization methods `__serialize`/`__unserialize` for SplFixedArray to avoid creating deprecated dynamic
properties that would then be added to the backing fixed-size array
* Don't add named dynamic/declared properties (e.g. $obj->foo) of SplFixedArray to the backing array when unserializing
* Update tests to declare properties or to expect the deprecation warning
* Add news entry
Co-authored-by: Tyson Andre <tysonandre775@hotmail.com>
Add libxml_get_external_entity_loader(), which returns the currently
installed external entity loader, i.e. the value which was passed to
libxml_set_external_entity_loader() or null if no loader was installed
and the default entity loader will be used.
This allows libraries to save and restore the loader, controlling entity
expansion without interfering with the rest of the application.
Add macro Z_PARAM_FUNC_OR_NULL_WITH_ZVAL(). This allows us to get the
zval for a callable parameter without duplicating callable argument
parsing.
The saved zval keeps the object needed for fcc/fci alive, simplifying
memory management.
Fixes#76763.
If one tries to use such an alias as a type declaration the following error would be raised:
Fatal error: Cannot use 'int' as class name as it is reserved
These values not always converted to IS_LONG (e.g. by -- and ++) and
this leads to incorrect range inferene and later to incorrect JIT code
generation.
Using a lot of memory may overflow some `int` calculations; to avoid
that we make sure that the operands are promoted to `size_t`.
This issue has been analyzed by @chschneider.
Closes GH-9379.
Given that Windows ignores trailing dots and spaces in filenames, we
catch that ourselves to avoid confusion with the respective filenames
without these characters.
Closes GH-9229.
Ilija Tovilo