bpo-45243: Use connection limits to simplify `sqlite3` tests by erlend-aasland · Pull Request #29356 · python/cpython
Bigmem tests rewriting does not look correct to me. These tests are specially purposed to test the integer overflow. [...]
The C code explicitly checks the current connection limit (SQLITE_LIMIT_LENGTH); it does not check against INT_MAX. The maximum limit is defined by the compile-time constant SQLITE_MAX_LENGTH, which defaults to 1_000_000_000 (and can be maximum 2**31-1). This limit can be altered using sqlite3_setlimit(db, SQLITE_LIMIT_LENGTH, new_limit) on the database connection. Using bigmem tests we of course ensure that we will hit the roof, but only if the test machine has enough RAM. Using custom connection limits in the test, we can lower the limit temporarily and ensure that we can run these tests on any machine.
executemany check:
| size_t sql_len = strlen(sql_script); | |
| int max_length = sqlite3_limit(self->connection->db, | |
| SQLITE_LIMIT_LENGTH, -1); | |
| if (sql_len >= (unsigned)max_length) { | |
| PyErr_SetString(self->connection->DataError, | |
| "query string is too large"); | |
| return NULL; | |
| } |
execute / create statement check:
| sqlite3 *db = connection->db; | |
| int max_length = sqlite3_limit(db, SQLITE_LIMIT_LENGTH, -1); | |
| if (size >= max_length) { | |
| PyErr_SetString(connection->DataError, | |
| "query string is too large"); | |
| return NULL; | |
| } |