2015-12-03 12:54:54 -08:00
|
|
|
# This is the list of conformance tests that are known to fail for the
|
|
|
|
|
# Python/C++ implementation right now. These should be fixed.
|
|
|
|
|
#
|
|
|
|
|
# By listing them here we can keep tabs on which ones are failing and be sure
|
|
|
|
|
# that we don't introduce regressions in other tests.
|
|
|
|
|
#
|
2023-09-18 15:13:49 -07:00
|
|
|
# TODO: insert links to corresponding bugs tracking the issue.
|
2015-12-03 12:54:54 -08:00
|
|
|
# Should we use GitHub issues or the Google-internal bug tracker?
|
2025-06-20 17:03:09 -07:00
|
|
|
|
|
|
|
|
Recommended.*.JsonInput.FieldNameDuplicateDifferentCasing1 # Should have failed to parse, but didn't.
|
|
|
|
|
Recommended.*.JsonInput.FieldNameDuplicateDifferentCasing2 # Should have failed to parse, but didn't.
|
Add conformance tests for overlong varints as tags.
No wire format should ever contain an overlong varint, so the topic here is only how to react to non-standard and potentially corrupted data.
The situation today is that there's 4 main ways that implementations deal when parsing tags:
1) parse up to 10 bytes, cast to uint32
2) parse up to 10 bytes, reject if it is above uint32_max
3) parse up to 5 bytes, cast to uint32
4) parse up to 5 bytes, reject if it is above uint32_max
Of our primary supported implementations, these four strategies are used by Java, Go, C++ and upb correspondingly.
Based on examining the situation, the decision taken is that:
- Coercing down silently ignoring bits in the tag is dangerous to interpretation-confusion / silent misparsing, which means Java approach is dangerous.
- Needing to support parsing up to 10 bytes (even when they may just be all 0x80 and no content) would have real performance implications on the upb and C++ parsers. Since it should really never happen taking any performance hit on all parses based on a hypothetical is considered undesirable.
For that reason, the conformance test is set to match upb's behavior, which is slight mismatch to C++ and Go behavior today (in different ways), and larger mismatch to the Java behavior today.
Because fixing this 'bug' may be disruptive to a customer in theory (though it would probably mean they have some bad data that was accidentally parsing), we may hold back fixing the behavior to a breaking change release; this change to the conformance suite only establishes the decision on preferred behavior.
PiperOrigin-RevId: 841856475
2025-12-08 11:49:28 -08:00
|
|
|
Required.*.ProtobufInput.BadTag_FieldNumberSlightlyTooHigh # Should have failed to parse, but didn't.
|
2026-01-20 21:27:58 -08:00
|
|
|
# TODO: Uncomment once conformance tests can express failures that are not expected to be fixed.
|
|
|
|
|
# Recommended.Editions_Proto2.ProtobufInput.RejectInvalidUtf8.String.MapKey # Should have failed to parse, but didn't.
|
|
|
|
|
# Recommended.Editions_Proto2.ProtobufInput.RejectInvalidUtf8.String.MapValue # Should have failed to parse, but didn't.
|
|
|
|
|
# Recommended.Editions_Proto2.ProtobufInput.RejectInvalidUtf8.String.Oneof # Should have failed to parse, but didn't.
|
|
|
|
|
# Recommended.Editions_Proto2.ProtobufInput.RejectInvalidUtf8.String.Repeated # Should have failed to parse, but didn't.
|
|
|
|
|
# Recommended.Editions_Proto2.ProtobufInput.RejectInvalidUtf8.String.Singular # Should have failed to parse, but didn't.
|
|
|
|
|
# Recommended.Proto2.ProtobufInput.RejectInvalidUtf8.String.MapKey # Should have failed to parse, but didn't.
|
|
|
|
|
# Recommended.Proto2.ProtobufInput.RejectInvalidUtf8.String.MapValue # Should have failed to parse, but didn't.
|
|
|
|
|
# Recommended.Proto2.ProtobufInput.RejectInvalidUtf8.String.Oneof # Should have failed to parse, but didn't.
|
|
|
|
|
# Recommended.Proto2.ProtobufInput.RejectInvalidUtf8.String.Repeated # Should have failed to parse, but didn't.
|
|
|
|
|
# Recommended.Proto2.ProtobufInput.RejectInvalidUtf8.String.Singular # Should have failed to parse, but didn't.
|