2012/4/4 Rafael Ávila de Espíndola <respind...@mozilla.com> > Currently if the call > > p->zSql = sqlite3DbStrNDup(p->db, z, n); > > fails, zSql will stay null without the caller being notified that it > failed. sqlite3VdbeSetSql should probably return a bool. With that, > sqlite3Prepare could check it and return SQLITE_NOMEM. >
When sqlite3DbStrNDup() fails, it sets the mallocFailed flag in p->db. This later gets translated into an SQLITE_NOMEM error which is returned by sqlite3_prepare(). We have test cases for this very occurrence. In fact, during out-of-memory (OOM) testing<http://www.sqlite.org/testing.html#oomtesting>, our test harnesses verify that every simulated OOM error does in fact result in an SQLITE_NOMEM error (or at least some kind of error). There are a few places in the code where a memory allocation is merely an optimization and is not required for correctness. (For example here<http://www.sqlite.org/src/artifact/458488dcc159c30?ln=114-120>.) In those places, a failed allocation does not result in an error. But those cases are surrounded by calls to sqlite3BeginBenignMalloc() and sqlite3EndBenignMalloc(), which disable the logic in the test harnesses that verify that all OOM errors are detected. The allocation of the zSql string is not one of those places, however. I have just now double-checked that it is not by running one of our test programs in a debugger. > > Cheers, > Rafael > ______________________________**_________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users<http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users> > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
