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.
Convert zend_hash_find_ex(..., 1) to zend_hash_find_known_hash(...)
Convert zend_hash_find_ex(..., 0) to zend_hash_find(...)
Also add serializable changes to UPGRADING.INTERNALS summary
This prevents serialization and unserialization of a class and its
children in a way that does not depend on the zend_class_serialize_deny
and zend_class_unserialize_deny handlers that will be going away
in PHP 9 together with the Serializable interface.
In stubs, `@not-serializable` can be used to set this flag.
This patch only uses the new flag for a handful of Zend classes,
converting the remainder is left for later.
Closes GH-7249.
Fixes bug #81111.
I was originally planning more changes here, but then I realized
that zend_atol() is actually used to parse all numbers in inis,
not just those expecting sizes. I think I'll just leave it at
that.
[ci skip]
This macro is a footgun because it creates an uninitialized array
(only an allocation). This macro is no longer used in php-src,
and we have better alternatives like array_init() or
ZVAL_ARR(arr, zend_new_array(size_hint)).
* Prevents some unnecessary strlen() computation
* Use interned "NULL"
* Certain PGSQL_API functions now accept zend_string* instead of char*
Closes GH-6792
Instead of requiring the type to be determined in advance by the
describer function and then requiring get_col to return a buffer
of appropriate type, allow get_col to return an arbitrary zval.
See UPGRADING.INTERNALS for a more detailed description of the
change.
This makes the result fetching simpler, more efficient and more
flexible. The general possibility already existed via the special
PDO_PARAM_ZVAL type, but the usage was very inconvenient and/or
inefficient. Now it's possible to easily implement behavior like
"return int if it fits, otherwise string" and to avoid any kind
of complex management of temporary buffers.
This also fixes bug #40913 (our second highest voted bug of all
time, for some reason). PARAM_LOB result bindings will now
consistently return a stream resource, independently of the used
database driver.
I've tried my best to update all PDO drivers for this change, but
some of the changes may be broken, as I cannot test or even build
some of these drivers (in particular PDO dblib and PDO oci).
Fixes are appreciated -- a working CI setup would be even more
appreciated ;)
Currently compiler flags passed by extensions using the standard
``PHP_NEW_EXTENSION`` and ``PHP_ADD_SOURCES`` m4 macros are prepended
before the ones defined by ``Zend/Zend.m4``.
This was not really an issue before as ``Zend.m4`` only included
``-Wall`` but since the addition of ``-Wextra`` various issue about
disabling flags have been brought up.
A preliminary attempt was done in commit 5c1cf7669b
but this turns out to be more or less irrelevant.
The root issue is that ``PHP_NEW_EXTENSION`` and ``PHP_ADD_SOURCES`` call the
``PHP_ADD_SOURCES_X`` macro and pass their flags as the 3rd argument which prepends
the flags. There exists a 6th argument for this macro which appends them but from a
cursory look at https://heap.space/search?full=PHP_ADD_SOURCES_X&project=php-src
this is not used. Moreover, the comment describing this macro explicitly informs
that this macro should not be used directly.
As such we drop the 6th argument of ``PHP_ADD_SOURCES_X`` and move the `special-flags`
argument to be appended instead of prepended.
Closes GH-6204
Checking the linker compatibility with extranous `ImageLoad()` calls is
possible, but unnecessary, since the modules are either already loaded
or loaded shortly afterwards, so that we can get the required
information directly from the module handles. And actually, doing
`ImageLoad()` as well as `LoadLibrary()` leaves a tiny room for a race
condition, because both functions will lookup the module in the search
path, so there is no *guarantee* that both are dealing with the same
module. Dropping the `ImageLoad()` calls also has the advantage to no
longer face the issue reported in bug #79557. A very minor additional
advantage is that we no longer have to link against Imagehlp.dll.
Furthermore, there is no need to check for CRT compatibility multiple
times, so we can simplify the signature of `php_win32_crt_compatible`,
and at the same time clean up main.c a bit.
These changes require to change the signature of the exported
`php_win32_image_compatible` and `php_win32_crt_compatible` functions,
which now expect a `HMODULE` and nothing, respectively, instead of the
module name.
The `zend_system_id` is a (true global) system ID that fingerprints a process state. When extensions add engine hooks during MINIT/startup, entropy is added the system ID for each hook. This allows extensions to identify that changes have been made to the engine since the last PHP process restart.
Closes GH-5871
This is an annoying edge case that regularly gets broken. As we're
not aware of significant users of this API, and there are other
ways to hook this, remove support for EXT_NOP.
Voidification of Zend API which always succeeded
Use bool argument types instead of int for boolean arguments
Use bool return type for functions which return true/false (1/0)
Use zend_result return type for functions which return SUCCESS/FAILURE as they don't follow normal boolean semantics
Closes GH-6002
