diff options
author | Christoph M. Becker <cmbecker69@gmx.de> | 2020-02-21 13:24:37 +0100 |
---|---|---|
committer | Christoph M. Becker <cmbecker69@gmx.de> | 2020-02-21 13:36:29 +0100 |
commit | f133f0024ec801dc9636ee5bf84a93de1300d4b2 (patch) | |
tree | f3bed38ec62e41c00844766b009eb300620166bd /ext/reflection/php_reflection.c | |
parent | ad000a63e8a1b6aacbff5d7bd806abfe388c18eb (diff) | |
download | php-git-f133f0024ec801dc9636ee5bf84a93de1300d4b2.tar.gz |
Fix #79294: ::columnType() may fail after SQLite3Stmt::reset()
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>
Diffstat (limited to 'ext/reflection/php_reflection.c')
0 files changed, 0 insertions, 0 deletions