Encoding: Inconsistent example for packed repeated fields in Test4 message

Open

#282 opened on Sep 21, 2025 1 comment 0 reactions 1 assignee View on GitHub

@jguamie is already working on this.

Since Oct 17, 2025.

Assessment

This issue has not been assessed yet.

Description

In the documentation section about packed repeated fields, the following example is given:

message Test4 {
string d = 4;
repeated int32 e = 6;
}

The text says:

“… and we construct a Test4 message with d set to "hello", and e set to 1, 2, and 3, this could be encoded as 3206038e029ea705, or written out as Protoscope,

4: {"hello"}
6: {3 270 86942}”

Problem:
The encoding 3206038e029ea705 corresponds to e = [3, 270, 86942], not [1, 2, 3].

If e = [1, 2, 3], the correct encoding should be:

32 03 01 02 03

which expands to:

32 → field 6, wire type = length-delimited

03 → length = 3 bytes

01 02 03 → values [1, 2, 3]

The given encoding 3206038e029ea705 decodes as:

32 → field 6, wire type = length-delimited

06 → length = 6 bytes

03 → value = 3

8e 02 → value = 270

9e a7 05 → value = 86942

So the example text and the provided encoding are inconsistent.

Suggested fix:
Update the documentation so that either:

The example values match the provided encoding (e = [3, 270, 86942]), or

The encoded hex string is corrected to match the described values (e = [1, 2, 3]).

Dominant language: HTML
Stars: 69
Forks: 179
PR merge metrics: No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

Read the whole issue, then the project's contributing guide.
Comment on the issue to say you are picking it up — it saves two people doing the same work.
Fork the repository and make your change on a branch.
Open a pull request that references the issue number.

Encoding: Inconsistent example for packed repeated fields in Test4 message

Assessment

Description

Contributor guide

First steps

More from protocolbuffers/protocolbuffers.github.io

Get new issues in your inbox