v0.0.5

Bug fix

Fixes a thread panic (integer overflow) when uvarint() is fed 10+ continuation bytes (e.g. 1024 bytes of 0xef from a malformed gossip payload).

thread 64 panic: integer overflow
snappy.zig:73:11 in uvarint     s += 7;
snappy.zig:105:27 in decodedLen
snappy.zig:265:33 in decodeWithMax

The shift counter s: u6 reached 63 after 9 iterations, and s += 7 on the 10th iteration overflowed the u6.

Fix

• Restructured the uvarint loop to iterate buf[0..@min(buf.len, 10)] so the 10-byte budget is encoded in the loop bound itself; s += 7 can no longer push s:u6 past 63 by construction.
• Added a doc block on Varint calling out the overloaded bytesRead == 0 sentinel and the upgrade path if uvarint ever goes pub.
• Bumped build.zig.zon version to 0.0.5 (0.0.4 tag already exists pointing at the decodeWithMax commit).

Edge cases covered (tests in snappy.zig)

• 1024 bytes of 0xef (the original malformed-gossip payload) → Corrupt, no panic
• Exactly 10 continuation bytes, no terminator → corrupt
• Exactly 9 continuation bytes, no 10th byte (truncated input) → bytesRead == 0
• 11 continuation bytes followed by a valid terminator → corrupt
• 10th byte with continuation bit clear and value > 1 (overflow) → corrupt
• 10th byte with value == 1 (max u64 = 0xffff_ffff_ffff_ffff) → 10 bytes consumed, valid
• Empty buffer → bytesRead == 0
• Non-canonical [0x80, 0x00] encoding of zero → 2 bytes consumed, value 0
• decode and decodeWithMax on the 1024×0xef payload → error.Corrupt

zig build test: 9/9 passing.

Consumers

If you depend on this package, bump to commit 050f529bc5fa11242140312ecf550c186f05af1e or tag v0.0.5. The default branch (master) also points at this commit.

PR

Merged in #9. Reviewed and revised against feedback before tagging.