Compile error when symbols SQLITE_OMIT_SHARED_CACHE and SQLITE_USER_AUTHENTICATION=1 are both defined

(1) By Aloys (aloys) on 2021-07-22 11:59:01 [link] [source]

If the preprocessor symbol SQLITE_OMIT_SHARED_CACHE is defined, the member nTableLock is not defined in the structure Parse.

If the preprocessor symbol SQLITE_USER_AUTHENTICATION=1 is also defined, the compiler emits an error message for the line

    if( pParse->nTableLock>0 && db->init.busy==0 ){

in function sqlite3FinishCoding (line 112602 in the SQLite amalgamation for version 3.36.0), because the undefined member nTableLock is referenced in this statement.

It would be nice if this issue could be fixed for the next SQLite version.

Thanks in advance.

(2.1) By TripeHound on 2021-07-22 22:06:00 edited from 2.0 in reply to 1 [link] [source]

Are you building from the amalgamation, or the full sources? Some options (including many of the ..._OMIT_... ones) only work when building from the full sources. See Options To Omit Features in the SQLite docs.

(3) By Aloys (aloys) on 2021-07-23 07:36:27 in reply to 2.1 [link] [source]

I'm building from the amalgamation. I'm aware of the fact that not all _OMIT_ options work as expected when building from the amalgamation. However, the option SQLITE_OMIT_SHARED_CACHE has no influence on the lemon-generated parser. Therefore I suppose that building from the amalgamation with this option enabled should work.

In the light of DRH's comment regarding shared cache mode about a year ago I would almost call it good practice to omit shared cache mode.

As far as I can tell using option SQLITE_OMIT_SHARED_CACHE seems to work properly when compiling from the amalgamation.

However, it's not a question of working at runtime. If the combination of the options SQLITE_OMIT_SHARED_CACHE and SQLITE_USER_AUTHENTICATION is used the code does not compile, because the compiler complains about the missing definition for nTableLock (in line 188 of build.c). That is, the problem exists also when building from canonical sources. The reason is simply that the use of the member nTableLock is not guarded by some #ifndef SQLITE_OMIT_SHARED_CACHE preprocessor instruction, as it most likeley should.

(4) By Aloys (aloys) on 2021-07-26 11:42:16 in reply to 1 [source]

After inspecting the code in more detail, I get the impression that the fix for the compile issue I have is rather simple. If SQLITE_OMIT_SHARED_CACHE is not defined, then no tables will be locked and therefore the member nTableLock would be always 0. That is, lines 187 ff in build.c would not be executed at all:

#if SQLITE_USER_AUTHENTICATION
    if( pParse->nTableLock>0 && db->init.busy==0 ){
      sqlite3UserAuthInit(db);
      if( db->auth.authLevel<UAUTH_User ){
        sqlite3ErrorMsg(pParse, "user not authenticated");
        pParse->rc = SQLITE_AUTH_USER;
        return;
      }
    }
#endif

That is, adding a check for symbol SQLITE_OMIT_SHARED_CACHE should fix the issue:

#ifndef SQLITE_OMIT_SHARED_CACHE
#if SQLITE_USER_AUTHENTICATION
    if( pParse->nTableLock>0 && db->init.busy==0 ){
      sqlite3UserAuthInit(db);
      if( db->auth.authLevel<UAUTH_User ){
        sqlite3ErrorMsg(pParse, "user not authenticated");
        pParse->rc = SQLITE_AUTH_USER;
        return;
      }
    }
#endif
#endif

It would be nice if the SQLite developer would consider to apply this modification for the next SQLite version. Thanks in advance.

(5) By Nuno Cruces (ncruces) on 2024-01-22 12:01:55 in reply to 4 [link] [source]

Can any of the developers chime in and validate this fix?

SQLITE_OMIT_SHARED_CACHE is a recommended compile time option.

Is it really supposed to be incompatible with SQLITE_USER_AUTHENTICATION?

(6) By Nuno Cruces (ncruces) on 2024-01-22 22:29:31 in reply to 5 [link] [source]

So it seems the extension is formally deprecated: https://www.sqlite.org/src/info/249048b0cbc37058

That settles my use case, I won't be wrapping this API.