This merges all usages of emitting an offset TypeError into a new ZEND_API function
zend_illegal_container_offset(const zend_string* container, const zval *offset, int type);
Where the container should represent the type on which the access is attempted (e.g. string, array)
The offset zval that is used, where the error message will display its type
The type of access, which should be a BP_VAR_* constant, to get special message for isset/empty/unset
Struct members require some alignment based on their type. This means
that if a struct member is not aligned, there will be a hole created by
the compiler in the struct, which is wasted space. This patch reorders
some of the most commonly used structs, but in such a way that the
fields which were in the same cache line still belong together.
The only exception to this is exception_ignore_args, which was
temporally not close to nearby members, and as such I placed
it further up to close a hole.
On 64-bit Linux this gives us the following shrinks:
* zend_op_array: 248 -> 240
* zend_ssa_var: 56 -> 48
* zend_ssa_var_info: 48 -> 40
* php_core_globals: 672 -> 608
* zend_executor_globals: 1824 -> 1792
On 32-bit, the sizes will either remain the same or will result in
smaller shrinks.
* Remove always-false check in zend_lookup_class_ex()
This check is always false because of the undefined behaviour rule that
says a NULL pointer must never be dereferenced: we already dereference name
when checking the cache slot, before the NULL check. So the NULL may be
optimised away by the compiler. It looks like the code isn't even
supposed to work with name being NULL, so just remove the check.
* Remove always-true check in zend_fetch_static_property_address_ex()
* Simplify always-true conditions
`zend_uchar` suggests that the value is an ASCII character, but here,
it's about very small integers. This is misleading, so let's use a
C99 integer instead.
On all architectures currently supported by PHP, `zend_uchar` and
`uint8_t` are identical. This change is only about code readability.
The problem is that we're using the variable_ptr in the opcode handler
*after* it has already been destroyed. The solution is to create a
specialised version of zend_assign_to_variable which takes in two
destination zval pointers.
Closes GH-10524
This debug code is part of arginfo validation. This validation will
never trigger properly because the OR operation makes the first if
always true. Fix it by changing to an AND.
Closes GH-10417
Signed-off-by: George Peter Banyard <girgias@php.net>
The assertion failure was triggered in a debug code-path that validates
property types for internal classes.
zend_verify_internal_read_property_type was called with retval being a
reference, which is not allowed because that function eventually calls to
i_zend_check_property_type, which does not expect a reference.
The non-debug code-path already takes into account that retval can be a
reference, as it optionally dereferences retval.
Add a dereference in zend_verify_internal_read_property_type just before
the call to zend_verify_property_type, which is how other callers often
behave as well.
