summaryrefslogtreecommitdiff
path: root/ext/sqlite3/php_sqlite3_structs.h
diff options
context:
space:
mode:
authorChristoph M. Becker <cmbecker69@gmx.de>2020-02-21 13:24:37 +0100
committerChristoph M. Becker <cmbecker69@gmx.de>2020-02-21 13:36:29 +0100
commitf133f0024ec801dc9636ee5bf84a93de1300d4b2 (patch)
treef3bed38ec62e41c00844766b009eb300620166bd /ext/sqlite3/php_sqlite3_structs.h
parentad000a63e8a1b6aacbff5d7bd806abfe388c18eb (diff)
downloadphp-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/sqlite3/php_sqlite3_structs.h')
-rw-r--r--ext/sqlite3/php_sqlite3_structs.h2
1 files changed, 1 insertions, 1 deletions
diff --git a/ext/sqlite3/php_sqlite3_structs.h b/ext/sqlite3/php_sqlite3_structs.h
index bd65063906..5a25af61e1 100644
--- a/ext/sqlite3/php_sqlite3_structs.h
+++ b/ext/sqlite3/php_sqlite3_structs.h
@@ -108,7 +108,7 @@ struct _php_sqlite3_result_object {
zval stmt_obj_zval;
int is_prepared_statement;
- int complete;
+ int complete; // unused
zend_object zo;
};