SQLite Forum

Timeline
Login

6 forum posts by user sbooth

2020-08-24
12:01 Reply: Weird warning on the Xcode/OSX (artifact: 265e77a99e user: sbooth)

To see the commands issued by Xcode, go to the Report Navigator (Command-9), find the latest build command, and click the expansion icon next to to the entry called "Compile sqlite3.c".

In my Swift package the (abbreviated) build command is:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c -target x86_64-apple-macos10.12 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -std=gnu11 -fmodules -gmodules -fmodules-cache-path=/xxx/Library/Developer/Xcode/DerivedData/ModuleCache.noindex -fmodules-prune-interval=86400 -fmodules-prune-after=345600 -fbuild-session-file=/xxx/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/Session.modulevalidation -fmodules-validate-once-per-build-session -Wnon-modular-include-in-framework-module -Werror=non-modular-include-in-framework-module -fmodule-name=yyy -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-float-conversion -Wno-non-literal-null-conversion -Wno-objc-literal-conversion -Wno-shorten-64-to-32 -Wpointer-sign -Wno-newline-eof -DSWIFT_PACKAGE -DDEBUG=1 -DSQLITE_DQS=0 -DSQLITE_THREADSAFE=0 -DSQLITE_DEFAULT_MEMSTATUS=0 -DSQLITE_DEFAULT_WAL_SYNCHRONOUS=1 -DSQLITE_LIKE_DOESNT_MATCH_BLOBS -DSQLITE_MAX_EXPR_DEPTH=0 -DSQLITE_OMIT_DECLTYPE=1 -DSQLITE_OMIT_DEPRECATED=1 -DSQLITE_OMIT_PROGRESS_CALLBACK=1 -DSQLITE_OMIT_SHARED_CACHE=1 -DSQLITE_USE_ALLOCA=1 -DSQLITE_OMIT_DEPRECATED=1 -DSQLITE_ENABLE_FTS5=1 -DSQLITE_ENABLE_RTREE=1 -DSQLITE_ENABLE_STAT4=1 -DSQLITE_ENABLE_SNAPSHOT=1 -DSQLITE_ENABLE_JSON1=1 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -g -Wno-sign-conversion -Wno-infinite-recursion -Wno-comma -Wno-block-capture-autoreleasing -Wno-strict-prototypes -Wno-semicolon-before-method-body

and I see the same warnings:

/xxx/Sources/sqlite3.c:28742:25: warning: ambiguous expansion of macro 'MAX' [-Wambiguous-macro]
          szBufNeeded = MAX(e2,0)+(i64)precision+(i64)width+15;
                        ^
In module 'Darwin' imported from /xxx/Sources/sqlite3.c:1083:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/param.h:218:9: note: expanding this definition of 'MAX'
#define MAX(a, b) (((a)>(b))?(a):(b))

sys/param.h contains the block:

/* Macros for min/max. */
#ifndef MIN
#define MIN(a, b) (((a)<(b))?(a):(b))
#endif /* MIN */
#ifndef MAX
#define MAX(a, b) (((a)>(b))?(a):(b))
#endif  /* MAX */

so the declarations there have proper guards. It seems possible this is a clang issue.

2020-07-02
11:32 Reply: _vconfig variants taking ap_list (artifact: d680623113 user: sbooth)

In case there is any interest here is a proof-of-concept change implementing the above:

Index: src/main.c
==================================================================
--- src/main.c
+++ src/main.c
@@ -427,19 +427,17 @@
 ** This routine should only be called when there are no outstanding
 ** database connections or memory allocations.  This routine is not
 ** threadsafe.  Failure to heed these warnings can lead to unpredictable
 ** behavior.
 */
-int sqlite3_config(int op, ...){
-  va_list ap;
+int sqlite3_vconfig(int op, va_list ap){
   int rc = SQLITE_OK;
 
   /* sqlite3_config() shall return SQLITE_MISUSE if it is invoked while
   ** the SQLite library is in use. */
   if( sqlite3GlobalConfig.isInit ) return SQLITE_MISUSE_BKPT;
 
-  va_start(ap, op);
   switch( op ){
 
     /* Mutex configuration options are only available in a threadsafe
     ** compile.
     */
@@ -730,10 +728,18 @@
     default: {
       rc = SQLITE_ERROR;
       break;
     }
   }
+  return rc;
+}
+
+int sqlite3_config(int op, ...){
+  va_list ap;
+  int rc;
+  va_start(ap, op);
+  rc = sqlite3_vconfig(op, ap);
   va_end(ap);
   return rc;
 }
 
 /*
@@ -912,14 +918,12 @@
 }
 
 /*
 ** Configuration settings for an individual database connection
 */
-int sqlite3_db_config(sqlite3 *db, int op, ...){
-  va_list ap;
+int sqlite3_db_vconfig(sqlite3 *db, int op, va_list ap){
   int rc;
-  va_start(ap, op);
   switch( op ){
     case SQLITE_DBCONFIG_MAINDBNAME: {
       /* IMP: R-06824-28531 */
       /* IMP: R-36257-52125 */
       db->aDb[0].zDbSName = va_arg(ap,char*);
@@ -979,10 +983,18 @@
         }
       }
       break;
     }
   }
+  return rc;
+}
+
+int sqlite3_db_config(sqlite3 *db, int op, ...){
+  va_list ap;
+  int rc;
+  va_start(ap, op);
+  rc = sqlite3_db_vconfig(db, op, ap);
   va_end(ap);
   return rc;
 }
 
 /*

2020-06-23
19:10 Edit: _vconfig variants taking ap_list (artifact: a98f6c346a user: sbooth)

Swift generally supports calling C functions but does not support C variadic functions. Swift does, however, support a type called CVarArg which is basically a va_list.

The current implementation of sqlite3_config in main.c looks like:

int sqlite3_config(int op, ...){
  va_list ap;
  int rc = SQLITE_OK;

  /* sqlite3_config() shall return SQLITE_MISUSE if it is invoked while
  ** the SQLite library is in use. */
  if( sqlite3GlobalConfig.isInit ) return SQLITE_MISUSE_BKPT;

  va_start(ap, op);
  /* implementation is here */
  va_end(ap);
  return rc;
}

It would be beneficial for using SQLite from Swift (and possibly other languages that don't support calling C variadic functions) if there were versions of the _config functions (sqlite3_config and sqlite3_db_config) that took a va_list, much like vprintf. A possible implementation could look like:

int sqlite3_config(int op, ...){
  va_list ap;
  va_start(ap, op);
  int rc = sqlite3_vconfig(op, ap);
  va_end(ap);
  return rc;
}

int sqlite3_vconfig(int op, va_list ap){
  /* existing implementation of sqlite3_config minus the va_start()/va_end() portion*/
}

I'm happy to submit a patch if this is something that would be considered.

19:06 Edit: _vconfig variants taking ap_list (artifact: 2318ae7d68 user: sbooth)

Swift generally supports calling C functions but does not support C variadic functions. Swift does, however, support a type called CVarArg which is basically a va_list.

The current implementation of sqlite3_config in main.c looks like:

int sqlite3_config(int op, ...){
  va_list ap;
  int rc = SQLITE_OK;

  /* sqlite3_config() shall return SQLITE_MISUSE if it is invoked while
  ** the SQLite library is in use. */
  if( sqlite3GlobalConfig.isInit ) return SQLITE_MISUSE_BKPT;

  va_start(ap, op);
  /* implementation is here */
}

It would be beneficial for using SQLite from Swift (and possibly other languages that don't support calling C variadic functions) if there were versions of the _config functions (sqlite3_config and sqlite3_db_config) that took a va_list, much like vprintf. A possible implementation could look like:

int sqlite3_config(int op, ...){
  va_list ap;
  va_start(ap, op);
  return sqlite3_vconfig(op, ap);
}

int sqlite3_vconfig(int op, va_list ap){
  /* existing implementation of sqlite3_config minus the va_start() portion*/
}

I'm happy to submit a patch if this is something that would be considered.

16:07 Post: _vconfig variants taking ap_list (artifact: 88ba59a43c user: sbooth)

The current implementation of sqlite3_config in main.c looks like:

int sqlite3_config(int op, ...){
  va_list ap;
  int rc = SQLITE_OK;

  /* sqlite3_config() shall return SQLITE_MISUSE if it is invoked while
  ** the SQLite library is in use. */
  if( sqlite3GlobalConfig.isInit ) return SQLITE_MISUSE_BKPT;

  va_start(ap, op);
  /* implementation is here */
}

Swift generally supports calling C functions but does not support C variadic functions. Swift does, however, support a type called CVarArg which is basically a va_list.

It would be beneficial for using SQLite from Swift (and possibly other languages that don't support calling C variadic functions) if there were versions of the _config functions (sqlite3_config and sqlite3_db_config) that took a va_list, much like vprintf. A possible implementation could look like:

int sqlite3_config(int op, ...){
  va_list ap;
  va_start(ap, op);
  return sqlite3_vconfig(op, ap);
}

int sqlite3_vconfig(int op, va_list ap){
  /* existing implementation of sqlite3_config minus the va_start() portion*/
}

I'm happy to submit a patch if this is something that would be considered.

2020-06-12
16:10 Reply: DROP VIEW IF EXISTS failure (artifact: 8963bd67ee user: sbooth)

Advantages of "DROP VIEW IF EXISTS" raising an error: ?? (I would say: none; those who want errors simply leave out the "IF EXISTS" clause)

I think it would be more counter-intuitive for CREATE VIEW x to fail after DROP VIEW IF EXISTS x returned no error than for DROP VIEW IF EXISTS x to fail even though x is a table and not a view.