when sqlite3 built with -DSQLITE_ENABLE_API_ARMOR...

Other development priorities are currently occupying the team but we've noted your API_ARMOR posts for addressing as bandwidth allows, and i've added an audit of such use to my personal TODO list.

PS: note that application of API_ARMOR in any given call is not an API guaranty, so the current lack of it in some places is not a violation of any library/user contract. It is a "defense in depth" measure and its depth will be improved as time and energy allow.

Thanks for you early reply.

The application of API_ARMOR certainly helps to use the sqlite3 APIs, though it is not a complete safety guaranty now.

But as https://www.sqlite.org/forum/forumpost/e77a5c3445 mentioned, the inconsistent behaviors between APIs also confuse us to use them.

I will be appreciate if you can fix that inconsistency. Thanks again.

when sqlite3 built with -DSQLITE_ENABLE_API_ARMOR, sqlite3_db_config() crashed if passed with NULL db.

FYI: the three functions you reported have been patched for API_ARMOR, but this is currently in a branch, pending completion of a larger audit of functions which may be missing that feature. Once that audit is done (probably in the next two days) and reviewed (possibly early next week), that will be merged. In any case, it will be part of the 3.44 release but not the 3.43.x patch releases.

FYI: the three functions you reported have been patched for API_ARMOR, but this is currently in a branch,

Those are now in the trunk and include the functions you reported and many more.

Some functions, namely the sqlite3_value_...() family, was not extended with this support because (A) those can be (depending on how they're used) highly performance-relevant and (B) it would be quite unusual to get a NULL sqlite3_value pointer without very specifically wanting to¹. In debug builds, most or all of those functions will fail an assert() if passed a NULL.

1. ^{^} The purpose of API_ARMOR is to help avoid crashes for accidental misuse, not intentional misuse.