This regressed in 8.4 when dba started mixing objects and resources
(streams).
The streams are first destroyed at a first step in shutdown, and in slow
shutdown then the symbol table is destroyed which destroys the dba
objects. The dba objects still use the streams but they have been
destroyed already, causing a UAF. Using dtor_obj instead of free_obj
would work around this but would cause issues like memory leaks because
dtor_obj may be skipped while free_obj may not be.
Instead, use the same solution as mysqlnd uses in that we fully manage
the stream lifecycle ourselves. This also avoids users from meddling
with the stream through get_resources().
This would be fixed 'automatically' in the future when we are using
objects for everything.
Closes GH-19710.
When global constants' or class constants' availability is based on some
preprocessor condition, the generated arginfo header files wrap the
declarations in the preprocessor `#if` conditional blocks, one per declaration,
even if they are in the same conditional block based on comments in the stub
file. Instead of having multiple conditional blocks one after the other with
the same condition, combine them into a single conditional block.
This test reads an ini "file" from a string, and expects a warning
about locking. But if inifile support is disabled, then you'll get
Warning: dba_open(): Handler "inifile" is not available in
/path/to/ext/dba/tests/gh16390.php on line 3
instead. We skip the test if inifile support is disabled.
Closes GH-17011.
`dba_open()` accepts arbitrary stream wrapper paths, but unless no
locking (`-`) is specified, we try to determine the underlying file
path. If that fails, we need to error out.
Closes GH-16498.
When a class (or enum) has no methods, rather than using an array that only
contains `ZEND_FE_END`, use `NULL` for the functions. The implementation of
class registration for internal classes, `do_register_internal_class()` in
zend_API.c, already skips classes where the functions are `NULL`. By removing
these unneeded arrays, we can reduce the size of the header files, while also
removing an unneeded call to zend_register_functions() for each internal class
with no extra methods.
The wrong type was used in the size calculation. On 64-bit this
coincidentally doesn't cause issues, but on 32-bit it does because of
different padding vs 64-bit resulting in a different size.
Regressed in 2097237.
This is a follow-up of 4f6f4fb7d5
- PHP_DBA_DB_CHECK arguments quoted and normalized
- long lines reduced a bit
- Few additional AS_VAR_IF used
- Typo in variable name ${dbdp} fixed to ${dbdp4} as there is no dbdp
variable anymore as of 4.x and 5.x paths checks
The m4_normalize(m4_expand([$1])) expands the given argument if it
contains M4 macros, and then trims the items together into a space
separated string in an intuitive way.
- Macro headers synced with current PHP style (a minor description added
and parameters)
- macro arguments quoted
- redundant double quotes reduces
- AS_VAR_IF macros used
- Redundant check message removed because there is already error thrown
right after it
Currently, internal classes are registered with the following code:
INIT_CLASS_ENTRY(ce, "InternalClass", class_InternalClass_methods);
class_entry = zend_register_internal_class_ex(&ce, NULL);
class_entry->ce_flags |= ...;
This has worked well so far, except if InternalClass is readonly. It is because some inheritance checks are run by zend_register_internal_class_ex before ZEND_ACC_READONLY_CLASS is added to ce_flags.
The issue is fixed by adding a zend_register_internal_class_with_flags() zend API function that stubs can use from now on. This function makes sure to add the flags before running any checks. Since the new API is not available in lower PHP versions, gen_stub.php has to keep support for the existing API for PHP 8.3 and below.
* ext/dba/tests/setup/setup_dba_tests.inc: sort test output
Iterating through a database with firstkey() and nextkey() is
guaranteed to retrieve all rows, but apparently not in any particular
order. This is causing a test failure for at least one user, so we
steal the sort() approach from GDBM to ensure that the output is
predictable.
* ext/dba/tests/dba_*.phpt: sort expected test output
The actual output is now sorted for consistency, so we need to update
the expected output as well. As a nice side effect, some differences
in the expected outputs for the various engines have been eliminated.
Closes GH-14786
* ext/pgsql/tests/80_bug14383.phpt: sort expected test output
This test uses a routine from ext/dba that now sorts its (actual)
output, so we have to sort the expected output here as well.
* ext/dba/tests/setup/setup_dba_tests.inc: update comment
After doing some more digging, it looks like GDBM isn't the only
engine where the iteration order with firstkey() and nextkey()
might change unexpectedly.
David Carlier