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>
Since we're passing these parameter to C functions accepting `char*`
without any further checking, we should reject strings with NUL bytes
in the first place.
Since `zend_parse_parameters()` now throws on failure, it doesn't make
sense anymore to use `zend_parse_parameters_throw()` instead, and also
it's useless to set an explicit return value.
SQLite3::bindParam() and SQLite3::bindValue() have identical
implementation (the only thing that differs is the second parameter's
passing mode), so we unify the implementation.
The php_stream_read() and php_stream_write() functions now return
an ssize_t value, with negative results indicating failure. Functions
like fread() and fwrite() will return false in that case.
As a special case, EWOULDBLOCK and EAGAIN on non-blocking streams
should not be regarded as error conditions, and be reported as
successful zero-length reads/writes instead. The handling of EINTR
remains unclear and is internally inconsistent (e.g. some code-paths
will automatically retry on EINTR, while some won't).
I'm landing this now to make sure the stream wrapper ops API changes
make it into 7.4 -- however, if the user-facing changes turn out to
be problematic we have the option of clamping negative returns to
zero in php_stream_read() and php_stream_write() to restore the
old behavior in a relatively non-intrusive manner.
RFC: https://wiki.php.net/rfc/tostring_exceptions
And convert some object to string conversion related recoverable
fatal errors into Error exceptions.
Improve exception safety of internal code performing string
conversions.
