libsqlite3-sys 0.39.1

Source: https://github.com/rusqlite/rusqlite
Artifact scanned: libsqlite3-sys-0.39.1.crate (crate · 2.6 MB · SHA-256 14a5f01b87b9…)
Compared with: libsqlite3-sys-0.39.0.crate (0 signals introduced since)
Files: 16 scanned, 6 skipped (binary, oversized, or unrecognised)
Signals: 0 critical · 0 warn · 14 info
Scan time: 13.9 s
LLM review: Reviewed by claude-haiku-5-5 (Anthropic): 13 of 13 warn and critical signals; 13 demoted to info.
Disclude version: 4.3.0
Scanned (UTC): 2026-10-26 07:27

Signals

Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.

info encoding-base64 build.rs:277:41

base64-like blob (84 bytes, compression ratio 0.95) (in comment) (raw pass, confidence 0.36)

        // the bundled sqlite on android also uses `SQLITE_TEMP_STORE=3`.
        // https://android.googlesource.com/platform/external/sqlite/+/2c8c9ae3b7e6f340a19a0001c2a889a211c9d8b2/dist/Android.mk
        if super::android_target() {
            cfg.flag("-DSQLITE_TEMP_STORE=3");

info ~~warn~~ → info by review macro-keyword-override sqlite3/sqlite3.c:636:1

`#define double` rebinds the reserved C keyword `double` (token pass, confidence 0.85)
```
#ifdef SQLITE_OMIT_FLOATING_POINT
# define double sqlite3_int64
#endif
```
dismissed LLM, confidence 0.95 Conditional macro remapping double to a 64-bit integer type when floating point is omitted.
Reasoning
This is the standard SQLite compatibility block that maps double to sqlite3_int64 only when SQLITE_OMIT_FLOATING_POINT is defined. It is a deliberate build-time configuration, not obfuscation.
info ~~warn~~ → info by review identifier-confusable-collision sqlite3/sqlite3.c:11510:21

two identifiers collapse to visual skeleton `p|` (0/O/o and 1/l/I are confusable) (token pass, confidence 0.80)
```
SQLITE_API int sqlite3_snapshot_cmp(
  sqlite3_snapshot *p1,
  sqlite3_snapshot *p2
);
```
dismissed LLM, confidence 0.95 Function parameters p1 and p2 in sqlite3_snapshot_cmp prototype.
Reasoning
The flagged identifiers p1 and p2 are ordinary parameter names. The skeleton collision comes from the digit 1 looking like l, which is a generic false positive on short identifiers in a large C source.
info ~~warn~~ → info by review macro-keyword-override sqlite3/sqlite3.c:15856:1

`#define double` rebinds the reserved C keyword `double` (token pass, confidence 0.85)
```
#ifdef SQLITE_OMIT_FLOATING_POINT
# define double sqlite_int64
# define float sqlite_int64
# define fabs(X) ((X)<0?-(X):(X))
```
dismissed LLM, confidence 0.95 Conditional macro remapping double and float to sqlite_int64 when floating point is omitted.
Reasoning
Same SQLITE_OMIT_FLOATING_POINT compatibility block as the other double remapping. It is legitimate, documented SQLite configuration code.
info ~~warn~~ → info by review macro-keyword-override sqlite3/sqlite3.c:15857:1

`#define float` rebinds the reserved C keyword `float` (token pass, confidence 0.85)
```
# define double sqlite_int64
# define float sqlite_int64
# define fabs(X) ((X)<0?-(X):(X))
# define sqlite3IsOverflow(X) 0
```
dismissed LLM, confidence 0.95 Conditional macro remapping float to sqlite_int64 when floating point is omitted.
Reasoning
The float redefinition is part of the same legitimate SQLITE_OMIT_FLOATING_POINT block, which also defines a software fabs replacement. No malicious behavior is present.
info ~~warn~~ → info by review identifier-confusable-collision sqlite3/sqlite3.c:22246:70

two identifiers collapse to visual skeleton `zCo||` (0/O/o and 1/l/I are confusable) (token pass, confidence 0.80)
```
SQLITE_PRIVATE Expr *sqlite3ColumnExprAuth(Table*,Column*,Parse*);
SQLITE_PRIVATE void sqlite3ColumnSetColl(sqlite3*,Column*,const char*zColl);
SQLITE_PRIVATE const char *sqlite3ColumnColl(Column*);
SQLITE_PRIVATE void sqlite3DeleteColumnNames(sqlite3*,Table*);
```
dismissed LLM, confidence 0.93 Function prototype declarations with parameters such as zColl.
Reasoning
The skeleton collision is between zColl-style parameter names in a prototype list. This is a visual-similarity false positive with no code-level concern.
info ~~warn~~ → info by review embedded-nul-in-string sqlite3/sqlite3.c:32823:35

string literal contains an embedded NUL followed by 2 more bytes of source (token pass, confidence 0.85)
```
static const char aHex[]    = "0123456789abcdef";
static const char aPrefix[] = "-x0\000X0";
static const et_info fmtinfo[25] = {
  /*  0 */  {  'd', 10, 1, etDECIMAL,    0,  0,  0 },
```
dismissed LLM, confidence 0.93 Static prefix string used by SQLite's printf formatter for hex prefixes.
Reasoning
The string "-x0\000X0" is a deliberate prefix table for printf hex formatting, where the NUL terminates the string early. This is a known SQLite idiom, not hidden payload.
info ~~warn~~ → info by review dynamic-import sqlite3/sqlite3.c:47700:10

`dlopen` called with a non-literal path (ast pass, confidence 0.75)
```
  UNUSED_PARAMETER(NotUsed);
  return dlopen(zFilename, RTLD_NOW | RTLD_GLOBAL);
}
```
likely benign LLM, confidence 0.85 Wrapper around dlopen implementing SQLite's runtime extension loading.
Reasoning
SQLite's sqlite3_load_extension path on POSIX calls dlopen with a caller-supplied filename by design. The path is a runtime parameter that the application is expected to control, so this is the expected extension-loading API, not a dropper.
info ~~warn~~ → info by review identifier-confusable-collision sqlite3/sqlite3.c:108607:7

two identifiers collapse to visual skeleton `i|` (0/O/o and 1/l/I are confusable) (token pass, confidence 0.80)
```
){
  int i1;
  int i2;
  int iRes;
```
dismissed LLM, confidence 0.93 Local integer variables i1, i2 and iRes in a SQLite routine.
Reasoning
The identifiers i1 and i2 are ordinary integer locals. The skeleton match is a digit-to-letter confusability artifact with no security relevance.
info ~~warn~~ → info by review embedded-nul-in-string sqlite3/sqlite3.c:118018:40

string literal contains an embedded NUL followed by 16 more bytes of source (token pass, confidence 0.85)
```
        if( aff>SQLITE_AFF_BLOB ){
          static const char zAff[] = "B\000C\000D\000E\000F";
          assert( SQLITE_AFF_BLOB=='A' );
          assert( SQLITE_AFF_TEXT=='B' );
```
dismissed LLM, confidence 0.93 Static affinity character table encoded with embedded NUL bytes.
Reasoning
The static zAff array with embedded NULs is a deliberate UTF-16-style affinity string table in SQLite's VDBE code. It is data encoding for a known API, not obfuscated code.
info ~~warn~~ → info by review identifier-confusable-collision sqlite3/sqlite3.c:150354:14

two identifiers collapse to visual skeleton `pK|` (0/O/o and 1/l/I are confusable) (token pass, confidence 0.80)
```
    int nKey;         /* Number of sorting key columns, including OP_Sequence */
    KeyInfo *pKI;     /* Original KeyInfo on the sorter table */

    regRecord = makeSorterRecord(pParse, pSort, pSelect, regBase, nBase);
```
dismissed LLM, confidence 0.93 Sorter-related local variables pKI and nKey in query planner code.
Reasoning
The identifiers pKI and nKey are ordinary sorter variables. The collision is a confusability artifact from the same naming style used throughout the file.
info ~~warn~~ → info by review identifier-confusable-collision sqlite3/sqlite3.c:156889:34

two identifiers collapse to visual skeleton `po` (0/O/o and 1/l/I are confusable) (token pass, confidence 0.80)
```
*/
static int sameSrcAlias(SrcItem *p0, SrcList *pSrc){
  int i;
  for(i=0; i<pSrc->nSrc; i++){
```
dismissed LLM, confidence 0.93 Function sameSrcAlias with parameters p0 and pSrc.
Reasoning
The parameters p0 and p1-style names in sameSrcAlias are ordinary. The skeleton collision is from digit-to-letter similarity and carries no meaning.
info ~~warn~~ → info by review identifier-confusable-collision sqlite3/sqlite3.c:193132:12

two identifiers collapse to visual skeleton `p||` (0/O/o and 1/l/I are confusable) (token pass, confidence 0.80)
```
      LogEst rLogEst = sqlite3LogEstFromDouble(rIn);
      int *pI1 = va_arg(ap,int*);
      u64 *pU64 = va_arg(ap,u64*);
      int *pI2 = va_arg(ap,int*);
```
dismissed LLM, confidence 0.93 Pointer locals pI1, pI2 and pU64 pulled from a va_list in a SQLite routine.
Reasoning
The variables pI1, pI2 and pU64 are ordinary pointer locals retrieved via va_arg in SQLite's printf-style handler. The collision is a naming false positive.
info ~~warn~~ → info by review macro-keyword-override sqlite3/sqlite3.h:315:1

`#define double` rebinds the reserved C keyword `double` (token pass, confidence 0.85)
```
#ifdef SQLITE_OMIT_FLOATING_POINT
# define double sqlite3_int64
#endif
```
dismissed LLM, confidence 0.95 Conditional macro remapping double to sqlite3_int64 in the public header.
Reasoning
This is the same SQLITE_OMIT_FLOATING_POINT configuration block that appears in the amalgamation, with no malicious intent.

Reproduce This Scan

Run disclude locally to verify. These commands scan the published file; the "new in this release" marks come from comparing it with the previous release's file, which they don't repeat. Add --format sarif for SARIF output. Add --llm (with an API key in the environment) to include the LLM review.

cargo install disclude --version 4.3.0
curl -fsSL -o libsqlite3-sys-0.39.1.crate 'https://static.crates.io/crates/libsqlite3%2Dsys/libsqlite3%2Dsys-0%2E39%2E1.crate'
printf '%s  %s\n' 14a5f01b87b92705d07b433c06f96cbc764637d81a0bffb5734ce17cf0f9a2b3 libsqlite3-sys-0.39.1.crate | shasum -a 256 -c -
mkdir pkg && tar -xzf libsqlite3-sys-0.39.1.crate -C pkg --strip-components 1
disclude scan --untrusted --severity info pkg