I'd be careful about this. Currently parsers will accept it, but there are good arguments for why perhaps they should not. In UTF-8, overlong byte sequences are rejected for security reasons. The same security reasons don't quite apply to protobufs but nevertheless, relying on this seems like a bad idea.
The output of your serializer will no longer be canonical. People won't be able to, say, used serialized messages as map keys or to compute hash values. That alone is probably enough reason not to do this. On Wed, Mar 10, 2010 at 7:48 AM, Marc Gravell <[email protected]>wrote: > The variable-length encoding allows multiple representations of the > same value - for example, 1 could be written as: > > 0000 0001 > > or it could be (I believe): > > 1000 0001 1000 0000 0000 0000 > > Is there anything in the core (or other) implementations that would > object to this second form? > > In particular, the scenario I'm thinking about is where a message is > know to be pretty deep - for example: > > A > > B > > C > > D > > D > > C > > D > > D > > At the moment, my code leaves an optimistic single-byte dummy-value > for the prefix, and then backfills this value when the length is known > (i.e. after writing this subtree), shuffling the data if needed. > > I'm toying with making this voluntarily lossy; for example it might > (in some cases) decide to leave a longer (2-5) dummy value, and write > the alternative form if the value turns out to be small (i.e. if > actually only 4 bytes were written). This would reduce the number of > times I need to block-copy the data (noting that it might have to copy > the same data multiple times - potentially every non-root object might > be more than 127 bytes). > > I'm tempted to spike it (to gauge the performance benefit), but I > don't want to waste my time if this is going to make it incompatible > with the core implementations (i.e. if they would actively spot this > and cause an error). And if it *is* valid, would it be possible to > make it explicit in the encoding spec? (or indeed, if it *isn't* valid > make it explicit in the encoding spec). > > Thanks, > > Marc Gravell > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<protobuf%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/protobuf?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
