Why use a 10 byte array in the write_varint method?

[SumitPatel12]

I've read the SQLite docs and their flavour of varint says it can span a maximum of 9 bytes.

I looked over the original SQLite implementation, and tursos and both use a 10 byte buffer when writing a varint. If the size is guaranteed to be at most 9, why is the additional byte required?

I tried writing a version with a 9 bytes allocation and ran it through a fuzzer ( it matched the output of the 10 byte version with the 9 bytes version), and it ran for like 10 mins without any errors.

So, my question is why do both of them use a 10 byte buffer when 9 does the job. I may be overlooking something obvious 😅. But this has been bugging me for the longest of times and I'd love to know why it is 10.

Also, if we somehow end up writing to the 10th byte isn't that likely a scenario where we want it logged or alerted of, 10 byte varint violates the original constraint. Isn't that likely to corrupt things downstream? (Not sure of the corruption thing, just throwing it out there)

[apoorva-01]

The 10 is just the naive worst case for a 7-bits-per-byte encoder over a u64: ceil(64/7) = 10. It's scratch-buffer headroom, not a length the format can actually produce.

The key thing is nothing ever writes to that 10th byte. Look at the two paths in putVarint64:

• The 9-byte case is the if( v & (((u64)0xff000000)<<32) ) branch. It writes the 9 bytes straight into p and returns 9. It never touches buf at all.
• The generic do/while loop is only reached when those top 8 bits are zero, i.e. v < 2^56, which encodes in at most ceil(56/7) = 8 bytes. That's why the assert( n<=9 ) sits right after the loop and never trips.

So buf[8] and buf[9] are dead space. Your fuzzer found exactly that: shrink it to 9 (or even 8) and the output is identical, because the only path that uses buf never needs more than 8, and the real 9-byte case bypasses buf entirely. Turso already trimmed it, current write_varint uses [u8; 9].

Which also answers the second part: no corruption risk and nothing to log, because there's no input that reaches a 10th byte. It's an over-sized stack array, not a reachable code path. Whoever wrote the original just rounded up to the theoretical LEB128 max and moved on.