Fix large field number parsing by using unsigned right shift

[xi0yu]

This fixes an issue where Wire fails to parse protobuf data when encountering very large field numbers (for example, 290,848,974).
The failure is caused by using a signed right shift (shr), which introduces sign extension for large values, leading to incorrect tag extraction.
Changed shr to ushr in nextTag() and skipGroup() methods to ensure proper handling of large field numbers.

Only two lines modified:

• Line 184: tag = tagAndFieldEncoding shr TAG_FIELD_ENCODING_BITS -> tag = (tagAndFieldEncoding ushr TAG_FIELD_ENCODING_BITS)
• Line 250: val tag = tagAndFieldEncoding shr TAG_FIELD_ENCODING_BITS -> val tag = (tagAndFieldEncoding ushr TAG_FIELD_ENCODING_BITS)

[oldergod]

Thanks for the PR. Is writing a test for this gonna be difficult?

[xi0yu]

Thanks! I’ve confirmed locally that the issue occurs when field numbers are >= 0x10000000. Using signed right shift (shr) causes sign extension, which makes tag/tagAndField decode incorrectly. This is exactly what the PR fixes by switching to unsigned right shift (ushr).

I’ve also added a unit test specifically covering field numbers >= 0x10000000 to verify the fix.

[oldergod]

Thank you!
We'd need you to sign our CLA at https://docs.google.com/forms/d/e/1FAIpQLSeRVQ35-gq2vdSxD1kdh7CJwRdjmUA0EZ9gRXaWYoUeKPZEQQ/viewform?formkey=dDViT2xzUHAwRkI3X3k5Z0lQM091OGc6MQ&ndplr=1

and I'll be able to merge it 👍

[oldergod]

You could access the generated adapter as well, I think?

Suggested change

	private val adapter = createRuntimeMessageAdapter(
	LargeFieldMessage::class.java,
	"square.github.io/wire/unknown",
	Syntax.PROTO_2,
	LargeFieldNumberTest::class.java.classLoader,
	)
	private val adapter = LargeFieldMessage.ADAPTER

[xi0yu]

It's done! Thanks for the opportunity. I'm really happy to contribute to this project. :P

[oldergod]

Hmm, is this actually a problem? It looks like this PR addresses a tag value which is outside of the supported bound for the wire format anyway?

https://github.com/protocolbuffers/protobuf/blob/6fcc1b6d16db029c219083042fd9e4238d32faf3/src/google/protobuf/edition_unittest.proto#L615-L618

[xi0yu]

Hmm, is this actually a problem? It looks like this PR addresses a tag value which is outside of the supported bound for the wire format anyway?

https://github.com/protocolbuffers/protobuf/blob/6fcc1b6d16db029c219083042fd9e4238d32faf3/src/google/protobuf/edition_unittest.proto#L615-L618

Thanks for raising the important question about large field number support. You noticed the Google documentation limit comments, which prompted me to investigate deeply.

I found some key points:

1. Calculation error in Google's comment: The comment says "The largest possible tag number is 2^28 - 1, since the wire format uses three bits to communicate wire type" - the basic principle is correct (reserving three bits for wire type), but the calculated value is wrong. Actually, in 32 bits, 3 bits are reserved for wire type, leaving 29 bits for field numbers, so the maximum should be 0x1FFFFFFF (i.e., 2^29-1 = 536870911), not 2^28-1 (268435455).

2. Legitimacy of field number 290848974: This field number (hexadecimal: 0x115600CE) falls within the valid range of 2^29-1, making it a legitimate Protobuf field number.

3. Hard limit verification: I confirmed that field numbers exceeding 2^29-1 (such as 2^29 = 536870912) are rejected by the compiler, confirming that 2^29-1 (536870911) is the true hard limit. Actually, the Wire project itself defines the same limit in Util.kt#L88: MAX_TAG_VALUE = (1 shl 29) - 1 // 536,870,911

So your question is very valuable, it helped me discover that Google's own comments contain calculation errors. The actual limit is 2^29-1, not 2^28-1, so our fix is reasonable.

[xi0yu]

@oldergod Hi! Just checking whether you had a chance to look at the latest updates.
All review comments have been addressed.

Let me know if anything else needs improvement.

[oldergod]

@xi0yu in total honesty, I felt a cold shower reading an LLM text.

We have some interop tests in wire-protoc-compatibility-tests and I would want to see a test with the biggest allowed tag number per your PR work between Wire and protoc. I gave it a quick try and tests didn't pass.

[xi0yu]

Thanks for the feedback. To be honest, because my English isn't very strong, I used an AI tool to help polish the wording to make it clearer. I'll review and rewrite it to make sure it sounds more natural.More importantly, I'll look into the failing interop test regarding the max tag number right away and get back to you with a fix.

[xi0yu]

@oldergod I've added the interop test in wire-protoc-compatibility-tests. Tests pass on my machine.

Could you share what error you saw when you tested? Want to make sure I haven't missed anything.

[xi0yu]

Hey, any thoughts on this when you get a chance?
Happy to tweak anything.

[oldergod]

Thank you 👍