There is a small problem building recent SQLite versions with NDEBUG ...

Can you expand on how you're reproducing this? It's not reproducing for me with gcc or clang using the current trunk, despite having the ostensibly malformed macros:

$ grep -A1 'define AggInfo' sqlite3.c
#define AggInfoColumnReg(A,I)  (assert((A)->iFirstReg),(A)->iFirstReg+(I))
#define AggInfoFuncReg(A,I)    \
                      (assert((A)->iFirstReg),(A)->iFirstReg+(A)->nColumn+(I))...

$ gcc -c sqlite3.c -DNDEBUG -DSQLITE_DEBUG
$ clang -c sqlite3.c -DNDEBUG -DSQLITE_DEBUG
$ gcc -c sqlite3.c -DNDEBUG
$ clang -c sqlite3.c -DNDEBUG 

Both (somewhat curiously) complete without complaint.

Edit: i now see the explanation with -Wunused-value at the top of your github link but still can't reproduce it with gcc or clang:

$ clang -c -DNDEBUG  sqlite3.c -Wall -Wextra -Wunused-value
$ gcc -c -DNDEBUG  sqlite3.c -Wall -Wextra -Wunused-value

both complete without complaint.

Edit: it turns out that C89, C99, and C11 all require that assert() have a value when NDEBUG is defined. All three of those standards say that assert must be ((void)0) in that case.

Ergo: this is not a bug in sqlite, but in the assert() impl your compiler is using.

Edit again: Richard checked in a workaround for this case but it really is a bug in the complaining compiler's assert()!

Hello!

Thanks for giving a look at this and sorry if it turns out to be a problem of the compiler/setup actually and not your codebase! And sorry for the late response!

The setup this is reproduced is inside the ESP-IDF (the ESP32 chips development environment) version 5.2.1. This uses underneath seemingly a standard GCC, this:

Using built-in specs.
COLLECT_GCC=/home/foo/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/xtensa-esp-elf-gcc
COLLECT_LTO_WRAPPER=/home/foo/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/../libexec/gcc/xtensa-esp-elf/13.2.0/lto-wrapper
Target: xtensa-esp-elf
Configured with: /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/gcc/configure --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu --target=xtensa-esp-elf --prefix=/builds/idf/crosstool-NG/builds/xtensa-esp-elf --exec_prefix=/builds/idf/crosstool-NG/builds/xtensa-esp-elf --with-local-prefix=/builds/idf/crosstool-NG/builds/xtensa-esp-elf/xtensa-esp-elf --with-headers=/builds/idf/crosstool-NG/builds/xtensa-esp-elf/xtensa-esp-elf/include --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG esp-13.2.0_20230928' --disable-__cxa_atexit --enable-cxx-flags=-ffunction-sections --disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp --disable-libquadmath --disable-libquadmath-support --disable-libstdcxx-verbose --with-gmp=/builds/idf/crosstool-NG/.build/xtensa-esp-elf/buildtools --with-mpfr=/builds/idf/crosstool-NG/.build/xtensa-esp-elf/buildtools --with-mpc=/builds/idf/crosstool-NG/.build/xtensa-esp-elf/buildtools --with-isl=/builds/idf/crosstool-NG/.build/xtensa-esp-elf/buildtools --enable-lto --enable-target-optspace --without-long-double-128 --disable-nls --enable-multiarch --enable-languages=c,c++ --disable-libstdcxx-verbose --enable-threads=posix --enable-gcov-custom-rtio --enable-libstdcxx-time=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (crosstool-NG esp-13.2.0_20230928)

Beside include paths and such, that I tried to remove, the flags I see passed if any may ring a bell are:

-D_GLIBCXX_HAVE_POSIX_SEMAPHORE -D_GLIBCXX_USE_POSIX_SEMAPHORE -D_GNU_SOURCE -D_POSIX_READER_WRITER_LOCKS -mlongcalls  -fdiagnostics-color=always -ffunction-sections -fdata-sections -Wall -Werror=all -Wno-error=unused-function -Wno-error=unused-variable -Wno-error=unused-but-set-variable -Wno-error=deprecated-declarations -Wextra -Wno-unused-parameter -Wno-sign-compare -Wno-enum-conversion -gdwarf-4 -ggdb -Og -fno-shrink-wrap -fstrict-volatile-bitfields -fno-jump-tables -fno-tree-switch-conversion -std=gnu17 -Wno-old-style-declaration -std=gnu99 -g3 -fno-stack-protector -mlongcalls -nostdlib -Wpointer-arith -Wno-error=unused-value -Wno-error=unused-label -Wno-error=char-subscripts -Wno-error=maybe-uninitialized -MMD -c -DF_CPU=240000000L -DESP32 -DCORE_DEBUG_LEVEL=0 -DNDEBUG -MD -MT esp-idf/esp32-idf-sqlite3/CMakeFiles/__idf_esp32-idf-sqlite3.dir/sqlite3.c.obj -MF esp-idf/esp32-idf-sqlite3/CMakeFiles/__idf_esp32-idf-sqlite3.dir/sqlite3.c.obj.d -o esp-idf/esp32-idf-sqlite3/CMakeFiles/__idf_esp32-idf-sqlite3.dir/sqlite3.c.obj -c /home/foo/esp/sqlite/esp32-idf-sqlite3/examples/esp32-idf-sqlite3-examples/spiffs/esp32-idf-sqlite3/sqlite3.c

I will try to give it a look more later on based on your feedback and thanks a lot for the workaround committed!

Cheers,

F.

use comma separated statements but have an assert() on the left side, which with NDEBUG generates no code

I don't think it's true in general that the assert macro generates no code with NDEBUG defined. Certainly it's not what gcc¹ does in my environment:

$ printf "#include <assert.h>\nassert(1234 == 1000+200+30+4);\n" | cc -E - |tail -n1
((1234 == 1000+200+30+4) ? (void) (0) : __assert_fail ("1234 == 1000+200+30+4", "<stdin>", 2, __PRETTY_FUNCTION__));

$ printf "#include <assert.h>\nassert(1234 == 1000+200+30+4);\n" | cc -DNDEBUG -E - |tail -n1
((void) (0));

¹ tested against gcc 4.8.5 and gcc 9.2.0, but whatever libc header files are in use is probably more relevant than the compiler version here

Thanks everyone for the heads up and details! After further research it was indeed a local library wrapper that was redefining (when in NDEBUG) the assert() in the non standard (void(x)) way and creating the whole problem.

Sorry again for rising this before checking those in detail!

Many thanks!

Just to elaborate a bit more in detail (I owe it since I made you guys lose time):

In the ESP-IDF library the assert when NDEBUG is defined as:

#define assert(__e) ((void)(__e))

This created originally a problem since the SQLite was also built without SQLITE_DEBUG so the assert would be replaced but still reference those functions (ie. assert( sqlite3PcachePageSanity(pPg) ); would become ((void) (sqlite3PcachePageSanity(pPg)) which would not build).

The person that wrapped then the library to ESP workarounded this with defining:

#define assert(__e)

But this then brought out the problem described due to the comma separated statement, due to now indeed having an empty statement.

So in short: it should be fixed upstream in the library the definition of assert not to use __e so we are probably protected on other similar corner cases: I will try to do that!

Just last in this series: upstream was already notified and is aware of problem, will likely be fixed in next major version: https://github.com/espressif/esp-idf/issues/10136

Thanks again for all the help and sorry for rising it on SQLite side before checking more in detail the development environment!

Cheers!