The official implementations do NOT accept multiple encodings, but it would
theoretically be possible for them to do so.  This wasn't implemented mainly
because code size bloat is a big problem and accepting multiple encodings
would increase code size -- even users who don't even use [packed=true]
would be affected, since they'd still need to generate code which accepts
That said, I'm up for reconsidering this decision.

On Sun, May 31, 2009 at 10:37 PM, Joshua Haberman <>wrote:

> I was reading the documentation about packed encoding [0] (haven't dug
> into the code), and was wondering if parsers are expected to be able
> to read packed encoding whether or not [packed=true] is specified.
> Unlike any other option (AFAIK), [packed=true] actually changes the
> bytes that encoders will output.  It seems like decoders must be
> prepared to read either packed or non-packed encoding of repeated
> fields.  Is this the case?  The alternative (that [packed=true] is not
> interoperable with [packed=false]) seems undesirable.
> Josh
> [0]
> >

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to