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
