[protobuf] Timeline for next release?

2021-01-08 Thread Tom Walder
Hello, I hope this is the most useful place to ask this. I'm keen to build protobuf for PHP 8, which has been fixed (and merged) here: https://github.com/protocolbuffers/protobuf/pull/8105 Is there a timeline for the next release? v3.15.0? I checked GitHub in case there were release milestones

Re: [protobuf] key/tag encoding when message types > 31

2021-01-08 Thread 'emaz...@cisco.com' via Protocol Buffers
Ok yes... varint wire type so the 0x4c is 0x260. then it turns into 0xe004. Thanks, Ed On Friday, January 8, 2021 at 1:51:13 PM UTC-5 marc.g...@gmail.com wrote: > Field number 76 with which wire type? The lowest 3 bits are the wire-type, > then the field number is whacked on the end. Then spli

Re: [protobuf] key/tag encoding when message types > 31

2021-01-08 Thread Marc Gravell
Field number 76 with which wire type? The lowest 3 bits are the wire-type, then the field number is whacked on the end. Then split into groups of 7 bits for varint encoding. On Fri, 8 Jan 2021, 14:05 'emaz...@cisco.com' via Protocol Buffers, < protobuf@googlegroups.com> wrote: > Hi Marc, > > OK t

Re: [protobuf] Use of non-standard values for index

2021-01-08 Thread peo stri tise safe
More info-- when the "header" is set with an index of >= 16, the encoding process appears to insert an extra byte in the encoded value, and a decode attempt will fail, here is an example where an index of 15 can allow for an encode and subsequent decode, but an index of 16 fails at the subsequen

Re: [protobuf] key/tag encoding when message types > 31

2021-01-08 Thread 'emaz...@cisco.com' via Protocol Buffers
Hi Marc, OK thanks. 4 bits... Right. So for 76 it would look like 0xe004 in a wireshark trace ? Thanks, Ed On Friday, January 8, 2021 at 8:59:52 AM UTC-5 marc.g...@gmail.com wrote: > The composed wire-type and field number are treated as a varint. And since > the MSB is reserved for continuat

Re: [protobuf] key/tag encoding when message types > 31

2021-01-08 Thread Marc Gravell
The composed wire-type and field number are treated as a varint. And since the MSB is reserved for continuation, after the 3-bit wire type that only leaves 4 bits of field number, not 5, for single-byte field headers. On Fri, 8 Jan 2021, 12:47 'emaz...@cisco.com' via Protocol Buffers, < protobuf@g

Re: [protobuf] Use of non-standard values for index

2021-01-08 Thread peo stri tise safe
Gotcha, so the index value of 100 is not a non-standard value. So I'm seeing "invalid wire type" when using the decode method of protobuf.js of an AMQ body. This is in a Node using the protobuf.js, stomp-client.js and an AMQ broker. The GPB that I'm using has a basic format of this: syntax =

[protobuf] key/tag encoding when message types > 31

2021-01-08 Thread 'emaz...@cisco.com' via Protocol Buffers
Hello... I appreciate the clear documentation on encoding here: https://developers.google.com/protocol-buffers/docs/encoding However it doesn't discuss how the key/tag is encoded when the number of message types exceeds 5 bits (31). Each key in the streamed message is a varint with the value (