* main: Ignore `register_argc_argv` when `SG(request_info).argc` is available
* sapi: Remove hardcoded `register_argc_argv` for CLI SAPIs
This INI is ignored since the previous commit, which makes the hardcoded
setting obsolete.
* main: Deprecate deriving $_SERVER['argc'] and $_SERVER['argv'] from the query string
RFC: https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_the_register_argc_argv_ini_directive
* main: Adjust deprecation message for `register_argc_argv`
* NEWS/UPGRADING
* uri: Make the `.free_uri` handlers safe to call with `NULL`
The `php_uri_free()` function already unconditionally called `->free_uri()` and
thus couldn't be safely used when the `->uri` was `NULL` for some reason.
The lexbor implementation was already safe, because `lxb_url_destroy()` is
guaranteed to be a noop for `NULL`.
* uri: Stop checking for `NULL` before calling `->free_uri()`
This implicitly fixes an `UNEXPECTED(…->uri != NULL)` in `uri_free_obj_handler`
that likely should have read `EXPECTED` instead.
* uri: Remove unnecessary reset of `->uri` to `NULL` in `php_uri_object_handler_free()`
* uri: Document the requirement of `free_uri()` being safe with `NULL`
* Purge most special cases for building ODBC with specific drivers
PDO_ODBC doesn't do this, and most of these drivers are not in use with
PHP, at least like this. Chances are these expose an ODBC driver you can
use with a normal driver manager like unixODBC or iODBC. If not, it can
be specified as a custom driver, though it does not include any
workarounds.
There might be some redundant definitions now as a result.
IBM Db2 is kept as a special case due to it also being in PDO_ODBC,
though I wonder how good of an idea this is.
See GH-15630
* Remove never used include
This would only be used on 68k classic Mac OS. Did PHP ever run there?
* Fold HAVE_SQL_EXTENDED_FETCH
All supported driver managers can do extended fetches.
* Ope, accidentally deleted this in a refactor
* All driver managers support SQLDataSources now too
So we don't need the define?
* Remove undef CHAR
There's no justification behind as to why this should be.
* Don't special case SQL_TIMESTAMP
The default handling for turning into SQL_C_CHAR is fine, and the
special case for Adabas is no longer needed.
* Assume fetch_hash is always possible
The driver managers and even Db2 support this.
This would also allow simplifying the fetch code to merge fetch_into and
fetch_array into a single implementation perhaps.
* Update UPGRADING for driver specific removal
* Update NEWS for driver specific removal
* uri: Fix handling of the `errors == NULL && !silent` for uri_parser_whatwg
Previously, when `errors` was `NULL`, the `errors` pointer was used to set the
`$errors` property when throwing the exception, leading to a crash. Use a local
zval to pass the errors to the Exception and copy it into the `errors` input
when it is non-`NULL`.
* uri: Only pass the `errors` zval when interested in it in `php_uri_instantiate_uri()`
This is no longer necessary since the previous commit and also is a layering
violation, since `php_uri_instantiate_uri()` should not care how `parse_uri()`
works internally.
* uri: Use `ZVAL_EMPTY_ARRAY()` when no parsing errors are available
* uri: Avoid redundant refcounting in error handling of uri_parser_whatwg
* NEWS
The rename code can error out prior to the reassignment of the filename,
which is why the test causes a crash.
The rename code can also error out at a later point,
which means it will have already assigned the new filename.
We detect in which case we are in and act accordingly.
Closes GH-19761.
PSFS_FEED_ME is supposed to be returned when the filter did not receive
enough data and did not generate buckets for the output brigade.
The test generates buckets anyway on the output brigade, and the stream
layer did not handle that case causing a memory leak.
To solve this, discard any such buckets as it would conflict with the
status code returned by the filter. This keeps BC and solves the leak.
Closes GH-18972.
* uri: Inline implementation of `php_uri_implementation_set_object_handlers()`
There is no one time fits all solution to initialization of the object
handlers. A follow-up commit will use distinct `create_object` handlers for
each parser class.
Explicitly spelling out the handlers is a well-established pattern in php-src
and I don't see a reason to diverge from that with an intransparent helper
method.
* uri: Initialize the `.internal` field of `uri_object_t` immediately upon creation
This makes the objects much safer to use, since the `.parser` will always be
available and matching the object.
* uri: Remove `uri_parser_name` parameter of `uri_unserialize()`
The parser for a given object is already known from the object itself and
particularly must never change. Reassigning the value in `uri_unserialize()` is
just unsafe, especially since the existing `->uri` is freed with the destructor
of the reassigned parser.
Just rely on the `->parser` field being set to the correct value.
* uri: Remove the `uri_parser` parameter from `php_uri_instantiate_uri()`
Similarly to the previous change to `uri_unserialize()`, the `->parser` must
always match the object for the freeing to be safe.
Given that we expect to successfully parse URIs, we can eagerly initialize the
resulting URI object when using the `::parse()` methods and destruct it again
when parsing fails and `null` is returned instead. Calling the destructor is
safe, since `uri` will be `NULL`, which will result in a noop.
The `base_url_object` must also match the object that is currently being
constructed. Verify this using assertions matching the `->ce` and the
`->parser`.
* uri: Export the individual object handlers
This commit implements GH-8967.
SQLite supports multiple transaction modes. These include:
- DEFERRED (default) only acquires a lock when you start a read/write
- IMMEDIATE acquires a reserved lock
- EXCLUSIVE acquires an exclusive lock (stricter than immediate)
In WAL mode IMMEDIATE and EXCLUSIVE are identical.
One reason for wanting to specify a transaction mode is that SQLite
doesn't respect busy_timeout when a DEFERRED transaction tries to
upgrade a read lock to a write lock. Normally if you try to acquire a
lock and have busy_timeout configured, SQLite will wait for that period
until giving up and erroring out (SQLITE_BUSY). With DEFERRED, if you
have a transaction that first reads and there's a concurrent writer
while it's trying to upgrade to a write lock, you will immediately get
SQLITE_BUSY regardless of your busy_timeout.
Prior to this commit, the only available workarounds were:
- Using $pdo->exec("BEGIN IMMEDIATE TRANSACTION") instead of
$pdo->beginTransaction()
- Doing a dummy write at the start of each transaction so you don't get
stuck with a read lock
Both of those aren't very usable, especially in a framework context
where the user doesn't have complete control over how transactions are
started.
To address that, this commit adds four class constants to Pdo\Sqlite:
- ATTR_TRANSACTION_MODE -- a new attribute
- TRANSACTION_MODE_DEFERRED = 0
- TRANSACTION_MODE_IMMEDIATE = 1
- TRANSACTION_MODE_EXCLUSIVE = 2
These can be used as:
$pdo->setAttribute(
$pdo::ATTR_TRANSACTION_MODE,
$pdo::TRANSACTION_MODE_IMMEDIATE
);
* uri: Do not copy the normalized URI when cloning RFC 3986 URIs
The with-ers are not yet implemented for RFC 3986, the argument in the comment
however makes sense and the implementation did not match the comment.
* uri: Fix typo in comment in uri_parser_rfc3986.c
Co-authored-by: Máté Kocsis <kocsismate90@gmail.com>
---------
Co-authored-by: Máté Kocsis <kocsismate90@gmail.com>
* uri: Call the proper `clone_obj` handler in `uri_write_component_ex()`
For external URI implementation it's possible that the `->clone_obj` handler
does not match `uri_clone_obj_handler()`. Use the handler of the object instead
of making assumptions.
* uri: Call `RETVAL_OBJ(new_object)` early in `uri_write_component_ex()`
This allows to remove some error handling logic.
* uri: Remove now-useless declaration of `uri_clone_obj_handler` from php_uri_common.h
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.
