Something probably not particularly important to the author (given that he&#x27;s just using these essentially as a serial number), but worth mentioning for general use:<p>&gt; Varints can represent negative numbers too, by casting them to unsigned numbers first.<p>But, assuming you&#x27;re working with twos-complement numbers, it&#x27;s going to be really inefficient, because small negative numbers are going to end up represented as extremely large positive numbers (e.g. -1 will map to MAX_INT - 1, where MAX_INT is the largest unsigned value representable in your underlying integer type).<p>You also lose the unlimited length property if you need to handle twos-complement integers, and your encoding is dependent on the underlying integer type you&#x27;re serializing from&#x2F;deserializing to (especially problematic in languages where types are architecture-dependent, like C&#x2F;C++).<p>Protobuf handles this by doing what they call &quot;ZigZag encoding&quot; if you declare a value as a signed integer type.  This maps small negative numbers to small positive numbers, alternating back and forth like so:<p><pre><code>    Original    Encoded
       0          0
      -1          1
       1          2
      -2          3
       2          4
</code></pre>
and so on.<p>The catch is that you lose sortability if you do this...  if you&#x27;re going to have a bunch of negative numbers and need their encoded versions to sort correctly, you&#x27;ll need to do something else.  (Of course, you&#x27;ll need to with twos-complement numbers, too, given that -1 will appear to be greater than 1).<p>Protobuf documentation on ZigZag encoding:  <a href="https:&#x2F;&#x2F;developers.google.com&#x2F;protocol-buffers&#x2F;docs&#x2F;encoding#signed-integers" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;protocol-buffers&#x2F;docs&#x2F;encoding...</a>