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.