zend_lazy_object_get_properties() is used by zend_std_get_properties_ex() to fetch the properties of lazy objects. It initializes the object and returns its properties.
When initialization fails we return an empty ht because most callers do not check for NULL. We rely on the exception thrown during initialization. We also assign that empty ht to zend_object.properties for the same reasons.
We asserted that zend_object.properties was either NULL or &zend_empty_array, but there are other cases in which a uninitialized lazy object may have a properties ht.
Here I remove the assertion, and return the existing properties ht if there is one. Otherwise I return zend_new_array(0) instead of &zend_emtpy_array as not all callers expect an immutable array (e.g. FE_FETCH does not).
Instead of always saying that a name is reserved or deprecated and
cannot/should not be used as a class name, take the usage into account and say
the name cannot be used as an enum name, trait name, etc. In the process, for
class names add a missing "a".
The return value of zho_build_properties_ex() is passed to ZVAL_ARR(), which sets the IS_TYPE_REFCOUNTED flag. Returning &zend_emtpy_array will crash later when trying to dtor the zval.
I'm fixing this by returning zend_new_array(0) instead of &zend_empty_array.
An alternative was to make ZVAL_ARR() aware of immutable arrays, like ZVAL_STR() is with interned strings, but I found no other problematic cases.
For the `Exception`, `ReflectionClass`, and `ReflectionAttribute` classes, the
`__clone()` method is declared to be private, and the implementation has a
comment that it should never be executed. However, the implementation can be
executed by using a `ReflectionMethod`. Fix the comments to instead explain why
the implementation is needed.
[skip ci]
zend_get_property_info_for_slot(obj, slot) assumes that 'slot' belongs to 'obj', but that may not be the case for lazy proxies.
Fortunately, the property info is often already available in path when it is needed.
For other cases, I make zend_get_property_info_for_slot() aware of lazy objects, and add zend_get_property_info_for_slot_self() for cases where the 'slot' is known to belong to the object itself.
Fixes oss-fuzz #71446
When allocating enough room for floats, the allocator used overflows with
large ndigits/EG(precision) value which used an signed integer to
increase the size of thebuffer.
Testing with the zend operator directly is enough to trigger
the issue rather than higher level math interface.
close GH-15715
To match other capitalized strings like `ZEND_STR_UNKNOWN_CAPITALIZED` and
`ZEND_STR_ARRAY_CAPITALIZED`. Since this known string was only added in PHP
8.4, no backwards compatibility alias is needed.
In zend_std_has_property with ZEND_PROPERTY_EXISTS, we'd just return true when
no get hook was present. However, this function is supposed to return false for
uninitialized properties. PROPERTY_EXISTS is somewhat of a misnomer. Virtual
properties continue to always return true, given there's no backing value to
check.
Fixes GH-15694
Closes GH-15822
A common convention is to name internal C header files as `*_int.h`.
Since a couple of these are actually installed, we add comments that
this is not supposed to happen, (a) to avoid installing further
internal headers, and (b) to pave the way to fix this in the next major
PHP version.
Somewhat special is php_gmp_int.h, where "int" is meant as abbreviation
for "interface".
Another common convention is appending `_priv` or `_private`, but since
there have not been any issues regarding these headers so far, we
refrain from adding respective comments to these headers.
Anyhow, it might be a good idea to introduce some common naming
convention for such internal/private headers.
This is a sync with upstream already fixed in early 2024 which fixes
64-bit builds on 32-bit hosts. PHP's bundled config.guess sets the
host_alias, for example, on Solaris systems to 64-bit if the compiler
supports it even though the architecture is actually 32-bit. These
assembly files resolve this situation in a build-system-agnostic way by
including the architecture file that is supported by the compiler.
This patch simplifies line endings tracked in the Git repository and
syncs them to the LF style instead of the CRLF.
Newline characters:
- LF (\n) (*nix and Mac)
- CRLF (\r\n) (Windows)
- CR (\r) (old Mac, obsolete)
To see which line endings are in the index and in the working copy the
following command can be used:
`git ls-files --eol`
Git also provides `.gitattributes` file to specify files that need
specific line endings in the working directory on all platforms (either
CRLF or LF):
```
file-with-crlf text eol=crlf
```
Changed files shouldn't cause issues on modern Windows platforms because
also Git can do output conversion if core.autocrlf=true is set on
Windows and use CRLF newlines in all files in the working tree.
Unless CRLF files are tracked specifically, Git by default tracks all
files in the index using LF newlines.
Unlike the `userland_declaration_error_const.phpt` test, the point of this test
is to demonstrate using a class constant as the default parameter. See also the
corresponding internal_declaration_* tests.
[skip ci]
We also add zend_map_ptr_static, so that we do not incur the overhead of constantly recreating the internal run_time_cache pointers on each request.
This mechanism might be extended for mutable_data of internal classes too.
There was a typo in make_ppc64_sysv_macho_gas.S with missing closing
multi-line comment. Upstream fixed it in ~2023:
https://github.com/boostorg/context/
* Check VM interrupt while internal frame is on top
* Use tab instead of spaces
* fix frame used in interrupt and refactor
* remove unused failures for zend_jit_check_timeout
* Fix JIT support
Co-authored-by: Bob Weinand <bobwei9@hotmail.com>
* Fix the missing store to vm_interrupt
* Rename new functions
* Special case zend_interrupt_function in JIT code
* refactor to use ZEND_VM_SET_OPCODE_NO_INTERRUPT
* Split atomic exchange into load + store
It is difficult to determine performance of atomics sometimes. In this
case, the separate load+store is still correct, and a load does not
cause a modification, and might be faster for some platforms than an
exchange. A load+store is slower than an exchange, but we're fine
trading the penalty to the slow path and keeping the happy path faster.
---------
Co-authored-by: Bob Weinand <bobwei9@hotmail.com>
Saki Takamachi