Use of unitialized variable in 3.32.1
(1) By Jim Borden (borrrden) on 2020-05-29 23:54:20
In the `analyzeOneTable` function the following occurs: ``` for(j=0; j<pPk->nKeyCol; j++){ k = sqlite3TableColumnToIndex(pIdx, pPk->aiColumn[j]); assert( k>=0 && k<pIdx->nColumn ); sqlite3VdbeAddOp3(v, OP_Column, iIdxCur, k, regKey+j); VdbeComment((v, "%s.column(%d)", pIdx->zName, i)); } ``` Note the use of `i` in the last line's comment. At least on GCC this gives a warning about the variable being possibly uninitialized and I think it was the intent to use `j` here.
(2) By anonymous on 2020-05-30 00:35:02 in reply to 1 [link]
It needs `-DSQLITE_ENABLE_STAT4`, but `clang` would still not flag it. It does look like `j` is intended. The code is at [analyze.c:1213](https://www.sqlite.org/src/file?udc=1&ln=1213-1218&ci=2e25d915bcb8d6f1&name=src%2Fanalyze.c)
(3) By Richard Hipp (drh) on 2020-05-30 00:43:50 in reply to 1 [link]
Thanks for the report! The problem is now [fixed on trunk][1]. Notes: * This only happens if SQLite is compiled with `-DSQLITE_ENABLE_EXPLAIN_COMMENTS` and with `-DSQLITE_ENABLE_STAT4`. Most builds of SQLite do not include either of those options. * Even when it does happen, the uninitialized integer is the input to an %d format for a string that is used as a debugging comment in the byte-code. So, in other words, the problem causes a goofy comment to appear in the comment column of the EXPLAIN output. In other words, it is utterly harmless. It is good that the problem was found. (Thanks, borrrden!) I only include the notes above to try to prevent a CVE from being written with a scary headline: "Critical Uninitialized Variable Usage In SQLite 3.32.1" How sad that CVE politics have degenerated to the point that I feel the need to do that.... [1]: https://www.sqlite.org/src/info/1cb248a3fc4c35c5