I32 varints should be (de)serialized as 10 bytes of all-1s, not 5.

[hans-tvs]

I submitted a PR recently to convert the problem from a panic to a runtime error, but I was under the mistaken impression that the protobuf data we were being given was occasionally broken. Instead, the Python and C++ canonical implementations, along with the docs, indicate that the appropriate order of operations is something like the following:

// potential_varint: []const u8 -- valid if at most 10 bytes have 1 as the MSB
const decoded_x: u64 = try decode_varint(potential_varint);
const interpreted_x: i32 = @intCast(@as(i64, @bitCast(decoded_x)));

As opposed to the current logic, which either truncates the extra 4 bytes of decoded data, or fails when any of those extra 4 bytes are 0.

This is likely a (small) problem throughout the codebase, not isolated to enums or any one feature.

[hans-tvs]

Sorry about the issue noise; I misread several things when posting this.

[menduz]

false alarm?