Inconsistent use of precompiler symbol SQLITE_HAS_CODEC

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Inconsistent use of precompiler symbol SQLITE_HAS_CODEC

Ulrich Telle
In most places in the SQLite source code the check

#ifdef SQLITE_HAS_CODEC

is used. However, at 4 places (1 in btree.c, 1 in ctime.c, and 2 in
pager.c) the check

#if SQLITE_HAS_CODEC

is used. The latter can fail to be correctly evaluated, if one only
defines the symbol, but doesn't set a value.

Yes, the problem can be overcome by defining the symbol with a value like

#define SQLITE_HAS_CODEC 1

but obviously not all developers are aware of this (i.e., see projects
SQLCipher or wxSQLite3).

In fact, I find the inconsistent use a bit dangerous, since defining

#define SQLITE_HAS_CODEC 0

would NOT disable this option completely, but would compile partial
support for encryption - maybe causing obscure problems.

Therefore I would suggest to either not relying on a symbol value but to
check always for the definition of the symbol only using

#ifdef SQLITE_HAS_CODEC

or to assume that SQLITE_HAS_CODEC always has a value and check using

#if SQLITE_HAS_CODEC

everywhere.

Regards,

Ulrich

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