> It seems like maybe the documentation needs to be updated Looks like it, yes: /** Enable hash probing to tolerate 32-bit hash collisions. Hash pr

> It seems like maybe the documentation needs to be updated Looks like it, yes: /** Enable hash probing to tolerate 32-bit hash collisions. Hash probing configuration (quadratic open addressing for 32-bit hashes: h_i = h_0 + i^2) Limit attempts with `LITE3_HASH_PROBE_MAX` (defaults to 128). Probing cannot be disabled. */ #ifndef LITE3_HASH_PROBE_MAX #define LITE3_HASH_PROBE_MAX 128U #endif #if LITE3_HASH_PROBE_MAX < 2 #error "LITE3_HASH_PROBE_MAX must be >= 2" #endif > It also means that the spec will ossify around a specific hash function It is a bit ugly, and will break backwards compatibility, but supporting a second hash function isn’t too hard. You can, on load, hash a few keys, compare them to the hashes, and, from that, if the input has many keys with high probability, infer which hash function was used. There also might be spare bit somewhere to indicate ‘use the alternative hash function’. Reading the code (nice-looking, BTW, for C code, but since it is C code, also full of warnings that other languages can protect you from) I spotted this (https://github.com/fastserial/lite3/blob/acbb97984eca1183ddcc76cd7413dc388062b171/include/lite3.h#L698 https://github.com/fastserial/lite3/blob/acbb97984eca1183ddc...): > The JSON standard requires that the root-level type always be an ‘object' > or 'array'. This also applies to Lite³. I don’t think that is true, and https://www.json.org/json-en.html https://www.json.org/json-en.html agrees with that. Single values (numbers, strings, booleans, null) also are valid json.