Differences between MiniPB and Official Protobuf

Despite being mostly compatible with Protobuf, there are several cases where MiniPB works differently than Google's Protobuf implementation. Some of these differences or incompatibilities might be temporary.

No support for .proto files

Probably the most obvious one. MiniPB only supports the more light-weight format strings and key-value format list natively. Although adding protoc support is theoretically possible it is not yet implemented.

Packed and non-packed repeated fields are not interchangable

As per the official Protobuf documentation on encoding, packed and non-packed repeated fields must be cross-compatible. Due to implementation constraints this is not yet possible with MiniPB and attempting to deserialize such messages will result in an error condition.

Packed strings/bytes

This is not possible on Google's Protobuf due to cross-compatibility between packed and non-packed repeated fields. Otherwise there will be no way to differentiate between a packed field that has multiple values and a non-packed field that has multiple values. This is however currently possible on MiniPB. Use of this "feature" is discouraged.

Over-sized vint

In MiniPB, all vint-based types except for signed 2's complement (type t) can have arbitrary length. Meaning you can theoretically store things like an RSA 2048 public key inside type V fields. This is, however, obviously not supported on Protobuf since Protobuf attempts to map vints to native integer types. Handling of over-sized integers also does not seem to be well defined in official Protobuf documentation. Therefore when maximum compatibility with Protobuf is desired, it is recommended to use only 32-bit or 64-bit numbers or bitmask the numbers to be within 32-bit or 64-bit range before serializing.