If you were to enter "w $>" the function would crash with a segmentation
fault because last_index is still NULL at that point. Fix it by checking
for NULL and erroring out if it is.
Closes GH-10353
Signed-off-by: George Peter Banyard <girgias@php.net>
When the validation logic for param->type was added, the logic did not
account for the case where param could be NULL. The existing code did
take that into account as can be seen in the `if (param)` check below.
Furthermore, phpdbg_set_breakpoint_expression even calls
phpdbg_create_conditional_break with param == NULL.
Fix it by placing the validation logic inside a NULL check.
If zend_register_module_ex were to return NULL, then module_entry will
be set to NULL, and the if's body will load module_entry->name. Since
module_entry is NULL, loading the name would cause a NULL pointer
dereference. However, since a NULL pointer dereference is undefined
behaviour, the compiler is free to remove the check.
Fix it by using *name instead of module_entry->name.
Closes GH-10157
Signed-off-by: George Peter Banyard <girgias@php.net>
The check checks whether p is non-NULL. But if it were NULL the function
would crash in later code, so the check is useless.
It seems like *p was intended, but that is redundant as well because
isspace would return false on '\0'.
The code checks if stack is a NULL pointer. Below that if the
stack->next pointer is updated unconditionally. Therefore a call with a
NULL pointer will crash, even though the if (stack) check seems to show
the intent that it is valid to call the function with NULL.
The function is not meant to be called with NULL, so just ZEND_ASSERT
instead.
This reallocates the PHP array when one can just use the named_params fields to pass the positional arguments instead.
Only usage of zend_fcall_info_args(_ex) remains in PDO.
This is very ugly: Bison provides a yynerrs variable, which is
usually not actually used, but also not annotated with
YY_MAYBE_UNUSED. Suppress this warning by adding a (void)yynerrs
into the top-level reduction action. The alternative would be to
disable the warning for these generated files.
The watch_*.phpt test apparently no longer fail on 32bit, so we remove
the XFAIL conditions. bug77269.phpt is practically identical to
bug77272.phpt, and there seems no particular reason to have an
additional test for libgd ≤ 2.2.5.
Closes GH-8448.
This is done by adding a new zend_atomic_bool type. The type
definition is only available for compiler alignment and size info; it
should be treated as opaque and only the zend_atomic_bool_* family of
functions should be used.
Note that directly using atomic_bool is complicated. All C++ compilers
stdlibs that I checked typedef atomic_bool to std::atomic<bool>, which
can't be used in an extern "C" section, and there's at least one usage
of this in core, and probably more outside of it.
So, instead use platform specific functions, preferring compiler
intrinsics.
The code used bitwise operators to avoid the short-circuiting behavior
of the logical operators. We refactor for clarity, and to keep
compilers and static analyzers happy.
Closes GH-8442.
- for packed arrays we store just an array of zvals without keys.
- the elements of packed array are accessible throuf as ht->arPacked[i]
instead of ht->arData[i]
- in addition to general ZEND_HASH_FOREACH_* macros, we introduced similar
familied for packed (ZEND_HASH_PACKED_FORECH_*) and real hashes
(ZEND_HASH_MAP_FOREACH_*)
- introduced an additional family of macros to access elements of array
(packed or real hashes) ZEND_ARRAY_ELEMET_SIZE, ZEND_ARRAY_ELEMET_EX,
ZEND_ARRAY_ELEMET, ZEND_ARRAY_NEXT_ELEMENT, ZEND_ARRAY_PREV_ELEMENT
- zend_hash_minmax() prototype was changed to compare only values
Because of smaller data set, this patch may show performance improvement
on some apps and benchmarks that use packed arrays. (~1% on PHP-Parser)
TODO:
- sapi/phpdbg needs special support for packed arrays (WATCH_ON_BUCKET).
- zend_hash_sort_ex() may require converting packed arrays to hash.
Add additional zend_compile_position argument, which can be either
AT_SHEBANG, AT_OPEN_TAG or AFTER_OPEN_TAG. The previous behavior
corresponds to AFTER_OPEN_TAG.
Closes GH-7462.
Currently, resource IDs are limited to 32-bits. As resource IDs
are not reused, this means that resource ID overflow for
long-running processes is very possible.
This patch switches resource IDs to use zend_long instead, which
means that on 64-bit systems, 64-bit resource IDs will be used.
This makes resource ID overflow practically impossible.
The tradeoff is an 8 byte increase in zend_resource size.
Closes GH-7436.
