I would agree that the treatment of invalid arguments could be better documented. By reading the code, (less than 40 lines), it becomes apparent that: 1. Passing a NULL sqlite3_stmt pointer is an error, leading to undefined behavior unless the library is built with SQLITE_ENABLE_API_ARMOR #define'd. Then the behavior is to return 0, but I don't think that should be documented. The doc need only say that the pointer must be a valid ..prepare.. return, not yet finalized.<sup><b>a</b></sup> 2. Passing an invalid column index into the API (as coded today) causes 0 to be returned instead of producing a crash or returning something else that cannot be dereferenced, regardless of whether SQLITE_ENABLE_API_ARMOR is #define'd. This should be documented, IMO, because of the confusion you evince. This slight deficiency in the documentation has probably survived for so many years because most API users understand that random indexes are not going to lead to anything good and use sqlite3_column_count() to limit index values. > ... argument value errors also leads to sqlite3_column_name() returning NULL. This (obvious) fact is not mentioned in the docs, something I read as "I cannot trust the documentation". That fact is not obvious without reading the code or experimenting. Anybody who programs much in C quickly learns that argument errors often lead to undefined behavior. I think your mistrust is not well founded on the (present) fact that the contours of the "correct argument" space are not precisely or completely spelled out in the place(s) you expect.<sup><b>b</b></sup> Such facts are normally left unstated in most contexts where they might be relevant to the more adventurous programmer, to the benefit of those who want/need to understand the API's useful functionality rather than the limits and effects of useless calls into it. I would also make this point of English semantics: To say "if X then Y happens" is not a statement about any result for conditions other than X. You should not read "If \<X\> fails ... then a NULL pointer is returned" to restrict the return of NULL pointers to other, non-\<X\> conditions. To convey such restriction, we say "If and only if \<X\> then ...".<sup><b>c</b></sup> So your citing this as a misleading doc assertion, leading to mistrust, is erroneous IMHO. At worst, the doc is silent on something, but it is obviously so. > Are there other cases not mentioned? Probably. Can you point to a few important omissions? The SQLite dev team is pretty good about improving doc defects that make it harder for SQLite library users to use it. ---- <b>a.</b> It would dilute the docs horribly to mention, at every location where a pointer is passed into or out of an API function, that either it must be a valid pointer or undefined behavior may result. <b>b.</b> At the [sqlite3_prepare() doc](https://sqlite.org/c3ref/prepare.html), one learns that the ubiquitously used sqlite3_stmt object should ultimately be deleted. <b>c.</b> This construct is shortened in mathematics-speak to: Iff <X> then ...". This should be in the common lexicon.