You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Regression in 3.12: toString() returns incorrect ascii when there are duplicate keys in a map #7505
Prior to protobuf 3.12, when parsing a map using TextFormat:
If there are duplicate map keys, the last key seen is used.
toString emits the duplicate keys in the original order, so if the ascii representation was parsed again, the same last key will be used, and the original message will be preserved.
In 3.12.0-rc-1 and 3.12.0-rc-2:
The last key seen is used.
toString does not retain the original order. In some cases, the last value printed for a key, is not necessarily the value that is being used in a message. As a result, parsing again the output of toString results in a different message.
In other words, m.toString() is producing a text representation that when parsed does not give the original m back.
What version of protobuf and what language are you using?
Version: 3.12.0-rc-2
Language: Java What operating system (Linux, Windows, ...) and version?
Ubuntu 19.10
Activity
haberman commentedon May 14, 2020
What is the output of the
p.toString()call here?haberman commentedon May 14, 2020
I was able to reproduce, I see the output:
haberman commentedon May 14, 2020
I think the subtraction here is overflowing:
https://github.com/protocolbuffers/protobuf/blob/master/java/core/src/main/java/com/google/protobuf/TextFormat.java#L513
If I change this to use
Integer.compare((int) getKey(), (int) b.getKey())your test passes.Thanks for the report. I'll make sure this is fixed before 3.12.0 is released.
Fixed bug in map key sorting for Java TextFormat.
Fixed bug in map key sorting for Java TextFormat. (#7508)
haberman commentedon May 16, 2020
The fix is released in 3.12.0.
Merge release branch into master. (#7517)
Merge release branch into master. (#7517)