The documentation also says (http://sqlite.org/c3ref/open.html):
If the 3rd parameter to sqlite3_open_v2() is not one of the combinations shown above optionally combined with other SQLITE_OPEN_* bits then the behavior is undefined. Seems like the undefined behavior was non-dangerous. That sqlite3_errmsg() had to guess and guessed wrong is not surprising. --David Garfield Krystian Bigaj writes: > Hi, > > Documentation says that: > > "The only exception is that if SQLite is unable to allocate memory to hold > the sqlite3 object, a NULL will be written into *ppDb instead of a pointer > to the sqlite3 object" > > but I see it's not entirely true. This example below stores NULL in *ppDb > even when (I think) no memory allocation problems occurs: > > void TestOpenMisuse(void) > { > sqlite3 *ppDb; > int err = sqlite3_open_v2("whatever", &ppDb, SQLITE_OPEN_CREATE , 0); > if (ppDb == NULL) > { > printf("ppDb==NULL, but err==%d, sqlite3_errmsg(ppDb)==%s", > err, sqlite3_errmsg(ppDb)); > } > } > > > Error code in this case will be err==21 (SQLITE_MISUSE) because > flag SQLITE_OPEN_CREATE cannot be there without SQLITE_OPEN_READWRITE - > which is docummented. > But sqlite3_errmsg(ppDb) will return "out of memory" (because ppDb==NULL), > which can be sometimes little misleading (for me as a SQLite newbie it was > ;). > > SQLite 3.7.8 (amalgamation) > > -- > Best regards, > Krystian Bigaj > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users