Error message for nonsensical flags.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Error message for nonsensical flags.

Dan Ackroyd
Hi,

I'm passing on an error report from a downstream library that uses
SQLite -  https://bugs.php.net/bug.php?id=74883 - without having
tested that it is an accurate bug report. Apologies in advance if it
is a spurious bug report, however I don't currently have an
environment to test it trivially.

It seems that trying to open a database with the flags
SQLITE3_OPEN_READONLY | SQLITE3_OPEN_CREATE set leads to a very
non-intuitive error message of "out of memory".

Those two flags are probably nonsensical to be used together, however
the alleged error message points the user in the wrong direction to
look for the error.

Would it be possible for either incompatible flags like this to be
detected, or for the error message to be improved for this scenario?

cheers
Dan
Ack
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error message for nonsensical flags.

Rowan Worth-2
On 10 July 2017 at 00:22, Dan Ackroyd <[hidden email]> wrote:

> Hi,
>
> I'm passing on an error report from a downstream library that uses
> SQLite -  https://bugs.php.net/bug.php?id=74883 - without having
> tested that it is an accurate bug report. Apologies in advance if it
> is a spurious bug report, however I don't currently have an
> environment to test it trivially.
>
> It seems that trying to open a database with the flags
> SQLITE3_OPEN_READONLY | SQLITE3_OPEN_CREATE set leads to a very
> non-intuitive error message of "out of memory".
>

I'm not sure the report is accurate. The very first thing that
openDatabase() does is check that the flags make sense; if the following
condition is true then SQLITE_MISUSE is returned:

    ((1<<(flags&7)) & 0x46)==0

The flags themselves are defined thusly:

#define SQLITE_OPEN_READONLY         0x00000001
#define SQLITE_OPEN_READWRITE        0x00000002
#define SQLITE_OPEN_CREATE           0x00000004

With SQLITE_OPEN_READONLY | SQLITE_OPEN_CREATE, (flags&7) = 5 and thus:

1 << 5 = 32 = 0x20,  0x20 & 0x46 = 0

Looking at the other cases...

SQLITE_OPEN_READONLY
1 << 1 = 0x02,  0x02 & 0x46 = 0x02

SQLITE_OPEN_READWRITE
1 << 2 = 0x04,  0x04 & 0x46 = 0x04

SQLITE_OPEN_READONLY | SQLITE_OPEN_READWRITE
1 << 3 = 0x08,  0x08 & 0x46 = 0

SQLITE_OPEN_CREATE
1 << 4 = 0x10,  0x10 & 0x46 = 0

SQLITE_OPEN_CREATE | SQLITE_OPEN_READWRITE
1 << 6 = 0x40,  0x40 & 0x46 = 0x40

SQLITE_OPEN_CREATE | SQLITE_OPEN_READWRITE | SQLITE_OPEN_READONLY
1 << 7 = 0x80,  0x80 & 0x46 = 0

So you should get SQLITE_MISUSE unless flags&7 is one of the three sensible
states:

SQLITE_OPEN_READONLY
SQLITE_OPEN_READWRITE
SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE

I don't think sqlite is giving you SQLITE_NOMEM here. This is based on code
analysis of versions 3.8.1 and 3.18.0 (it's identical in both; I haven't
checked inbetween versions).

-Rowan
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Loading...