Bug #79293 [NEW]: SQLite3Result::fetchArray() may fetch rows after last row

From: Date: Fri, 21 Feb 2020 10:31:13 +0000
Subject: Bug #79293 [NEW]: SQLite3Result::fetchArray() may fetch rows after last row
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-225659@lists.php.net to get a copy of this message
From: cmb Operating system: * PHP version: 7.3Git-2020-02-21 (Git) Package: SQLite related Bug Type: Bug Bug description:SQLite3Result::fetchArray() may fetch rows after last row Description: ------------ SQLite3Result::fetchArray() returns FALSE if a query result has been fully fetched; however, calling SQLite3::fetchArray() afterwards on this result set may allow to traverse it again without having called SQLite3Result::reset(). From the sqlite3_step() docs[1] (emphasis mine): | SQLITE_DONE means that the statement has finished executing | successfully. sqlite3_step() *should* *not* be called again on | this virtual machine without first calling sqlite3_reset() to | reset the virtual machine back to its initial state. So this behavior of SQLite3Result::fetchArray() relies on something that should not be done, and therefore might trigger arbitrary behavior. And even if the behavior is reliable, it would still be confusing, see e.g. parts of the second example of bug #64531. [1] <https://www.sqlite.org/c3ref/step.html> Test script: --------------- <?php $db = new SQLite3(':memory:'); $db->exec("CREATE TABLE foo (bar INT)"); for ($i = 1; $i <= 3; $i++) { $db->exec("INSERT INTO foo VALUES ($i)"); } $res = $db->query("SELECT * FROM foo"); while (($row = $res->fetchArray(SQLITE3_ASSOC))) { var_dump($row); } var_dump($res->fetchArray(SQLITE3_ASSOC)); ?> Expected result: ---------------- array(1) { ["bar"]=> int(1) } array(1) { ["bar"]=> int(2) } array(1) { ["bar"]=> int(3) } bool(false) Actual result: -------------- array(1) { ["bar"]=> int(1) } array(1) { ["bar"]=> int(2) } array(1) { ["bar"]=> int(3) } array(1) { ["bar"]=> int(1) } -- Edit bug report at https://bugs.php.net/bug.php?id=79293&edit=1 -- Fix committed: https://bugs.php.net/fix.php?id=79293&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=79293&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=79293&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=79293&r=needscript Try newer version: https://bugs.php.net/fix.php?id=79293&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=79293&r=support Expected behavior: https://bugs.php.net/fix.php?id=79293&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=79293&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=79293&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=79293&r=globals PHP version support discontinued: https://bugs.php.net/fix.php?id=79293&r=phptooold Daylight Savings: https://bugs.php.net/fix.php?id=79293&r=dst IIS Stability: https://bugs.php.net/fix.php?id=79293&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=79293&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=79293&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=79293&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=79293&r=mysqlcfg

« previous php.bugs (#225659) next »