In this test file, the free_obj handler is called with a refcount of 2,
caused by the fact we do a GC_ADDREF() to increase its refcount while
its refcount is still 1 because the Foo object hasn't been destroyed yet
(due to the cycle caused by the sqlite function callback).
Solve this by introducing a get_gc handler.
Closes GH-11881.
The error handling is replaced using zend_replace_error_handling(), but
when SQLITE3_CHECK_INITIALIZED() returns early, the old error handling
isn't restored.
In the past, SQLITE3_CHECK_INITIALIZED() threw a warning when the check
failed. This was replaced a few years ago with an error exception. So we
can fix the bug by just removing the replacing error handling as it
accomplishes nothing anymore.
Closes GH-11607.
It used the "add_new" variant which assumes the key doesn't already
exist. But in case of duplicate keys we have to take the last result.
Closes GH-11453.
A previous fix[1] was not sufficient to catch all potential file URIs,
because the patch did not cater to URL encoding. Properly parsing and
decoding the URI may yield a different result than the handling of
SQLite3, so we play it safe, and reject any file URIs if open_basedir
is configured.
[1] <https://bugs.php.net/bug.php?id=77967>
Closes GH-10018.
This reverts commit 94ee4f9834.
The commit was a bit too late to be included in PHP 8.2 RC1. Given it's a massive ABI break, we decide to postpone the change to PHP 8.3.
The arguments 3 to 6 of the authorizer callback may be `NULL`[1], and
we have to properly deal with that. Instead of causing a segfault, we
deny authorization, which is still better than a crash, and apparently,
we cannot do better anyway.
[1] <https://www.sqlite.org/c3ref/set_authorizer.html>
Closes GH-9040.
Store the result of sqlite3_data_count() into a variable and check that inside a loop instead calling it directly all the time. GCC is not brave enough to figure out the function produces the same result every time and call it repeatedly. This change produces fairly small but measurable and consistent speedup.
1. Update: http://www.php.net/license/3_01.txt to https, as there is anyway server header "Location:" to https.
2. Update few license 3.0 to 3.01 as 3.0 states "php 5.1.1, 4.1.1, and earlier".
3. In some license comments is "at through the world-wide-web" while most is without "at", so deleted.
4. fixed indentation in some files before |
We're starting to see a mix between uses of zend_bool and bool.
Replace all usages with the standard bool type everywhere.
Of course, zend_bool is retained as an alias.
Not all extensions consistently throw exceptions when the user passes
a path name containing null bytes. Also, some extensions would throw
a ValueError while others would throw a TypeError. Error messages
also varied.
Now a ValueError is thrown after all failed path checks, at least for
as far as these occur in functions that are exposed to userland.
Closes GH-6216.
The (void)_dummy is apparently considered a read of an uninitialized
variable. As it is a _Bool now, which has trap representations, this
is no longer considered legal and results in somewhat odd ubsan
warnings of the form:
runtime error: load of value 0, which is not a valid value for type 'zend_bool' (aka 'bool')
Exception should be thrown before the db handle is destroyed.
The backtrace excerpt
==26628== Invalid read of size 4
==26628== at 0x53C49E3: sqlite3_errmsg (in /usr/lib64/libsqlite3.so.0.8.6)
==26628== by 0x38C4E9: zim_sqlite3_open (sqlite3.c:142)
==26628== by 0x8977BF: ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER (zend_vm_execute.h:1618)
==26628== by 0x8F801E: execute_ex (zend_vm_execute.h:53824)
==26628== by 0x8FC0BB: zend_execute (zend_vm_execute.h:57920)
==26628== by 0x828F54: zend_execute_scripts (zend.c:1672)
==26628== by 0x793C2C: php_execute_script (main.c:2621)
==26628== by 0x8FEA44: do_cli (php_cli.c:964)
==26628== by 0x8FF9DC: main (php_cli.c:1359)
Signed-off-by: Anatol Belski <ab@php.net>
The fix for feature request #53466 did not properly handle resetting of
the corresponding statement; the problem with this is that the
statement does not know about its result sets. But even if we could
fix this, the `complete` handling still appears to be brittle, since
the `sqlite3_column_type()`docs[1] state:
| If the SQL statement does not currently point to a valid row, or if
| the column index is out of range, the result is undefined.
Fortunately, we can use `sqlite3_data_count()` instead, since[2]:
| If prepared statement P does not have results ready to return (via
| calls to the sqlite3_column() family of interfaces) then
| sqlite3_data_count(P) returns 0.
Thus, we guard `SQLite3::columnType()` with `sqlite3_data_count()`, and
completely drop updating the `php_sqlite3_result_object.complete`
field, but keep it for ABI BC purposes.
[1] <https://www.sqlite.org/c3ref/column_blob.html>
[2] <https://www.sqlite.org/c3ref/data_count.html>
