Potential NULL dereference in shell.c?

(1) By icy17 (amberliu) on 2023-10-12 14:48:33 [source]

I've just seen that the code in shell.c like:

rc = sqlite3_exec(p->db,
       "SELECT sql FROM"
       "  (SELECT sql sql, type type, tbl_name tbl_name, name name, rowid x"
       "     FROM sqlite_schema UNION ALL"
       "   SELECT sql, type, tbl_name, name, rowid FROM sqlite_temp_schema) "
       "WHERE type!='meta' AND sql NOTNULL AND name NOT LIKE 'sqlite_%' "
       "ORDER BY x",
       callback, &data, 0
    );
    if( rc==SQLITE_OK ){
      sqlite3_stmt *pStmt;
      rc = sqlite3_prepare_v2(p->db,
               "SELECT rowid FROM sqlite_schema"
               " WHERE name GLOB 'sqlite_stat[134]'",
               -1, &pStmt, 0);
      bfdoStats = sqlite3_step(pStmt)==SQLITE_ROW;
      sqlite3_finalize(pStmt);
    }

I don't understand why there is no check after sqlite3_prepare_v2, calling sqlite3_step with a NULL pointer cause a bug!

(2) By Stephan Beal (stephan) on 2023-10-12 14:56:17 in reply to 1 [link] [source]

I don't understand why there is no check after sqlite3_prepare_v2, calling sqlite3_step with a NULL pointer cause a bug!

No, it won't. First, the only case where that prepare() could fail is an out-of-memory condition. Secondly, both step() and finalize() are NULL-safe, returning without side-effects if passed NULL.

(3) By Larry Brasfield (larrybr) on 2023-10-12 15:18:07 in reply to 1 [link] [source]

I don't understand why there is no check after sqlite3_prepare_v2, calling sqlite3_step with a NULL pointer cause a bug!

In some cases, such checks are missing because it was thought that the prepare could not fail. That thinking overlooks the possibility of OOM failures, so we correct such oversights where they reach our awareness.

This one is now fixed on trunk. Thanks for the report.

(4) By anonymous on 2023-10-12 17:14:03 in reply to 1 [link] [source]

Hi all,

is there a reason for the presence of the (redundant?) alias names? This 2nd select could be simplified to "SELECT sql, type, tbl_name, name, oid x" . correct?

best regards

(5) By Larry Brasfield (larrybr) on 2023-10-13 02:58:01 in reply to 4 [link] [source]

is there a reason for the presence of the (redundant?) alias names?

Probably. The people who work on that code are not prone to randomness. I did not write the query, but sometimes end up with some extra stuff like that as a query evolves from its earliest conceptual form to its "final" form. Seeing how just one column is renamed in the projection, I can imagine the duplication was carrying some (slight) meaning, or there was less duplication before the rest of the query was simplified.

Now, if you ask "Is there a present reason ...?" Only inertia, a reluctance to alter others' code without good reason, and ...

This 2nd select could be simplified to "SELECT sql, type, tbl_name, name, oid x" . correct?

Yes. Could be. Among those who touch the shell, there is not much poring over code that is working merely to better conform to a sleekness ideal. We try to avoid gratuitous diffs.