* PHP-8.2:
Fix getting the address of an uninitialized property of a SimpleXMLElement resulting in a crash
Fix GH-12962: Double free of init_file in phpdbg_prompt.c
Have to use file_put_contents() instead of --FILE-- because we have to
actually load it using the exec command, *and* have to make multiple
files, and note that we can only load files relative from the current
directory, so we can't rely on files being in the sapi/phpdbg/tests
folder.
Closes GH-12680.
By default phpdbg is enabled (--enable-phpdbg) and user can get info in
the `./configure --help` output if they want to disable it like with the
other configuration options.
* Add string output escaping into zend dump (phpdbg + opcache debug)
* Use ZSTR_VAL macro instead direct string access
* Move "escaped_string" into local switch/case scope
* Add zend_string_release
* Add Z_STR_P macro instead direct string access
* Merge zend_string declaration and its assigment in one stmt
Fixes GH-10715
When a string starting with a NUL character is passed to
phpdbg_vprint(), the vasprintf() will return that 0 characters have been
printed. This causes msglen == 0. When phpdbg_process_print() is called
with a message of length 0, the -1 to check for '\n' will perform an out
of bounds read. Since nothing is printed anyway for msglen == 0, it
seems best to just skip the printing routine for this case.
Closes GH-10720.
Multiple tests had to be changed to escape the arguments in shell
commands. Some tests are skipped because they behave differently with
spaces in the path versus without. One notable example of this is the
hashbang test which does not work because spaces in hashbangs paths are
not supported in Linux.
Co-authored-by: Michael Voříšek <mvorisek@mvorisek.cz>
`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.
* Zend/zend_enum: make `forbidden_methods` static+const
* main/php_syslog: make `xdigits` static
* sapi/fpm: make several globals `const`
* sapi/phpdbg: make `OPTIONS` static
* sapi/phpdbg/help: make help texts const
* sapi/cli: make `template_map` const
* ext/ffi: make `zend_ffi_types` static
* ext/bcmath: make `ref_str` const
* ext/phar: make several globals static+const
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.
