Fix escaping in part name normalization #20
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The iteration of reading the input string of the function was problematic. When finding a pre-encoded character, for instance
%28
(which is an open bracket -'('
), all three characters were written in the destination string, but the reading of the input string continued with the character after'%'
, which was'2'
. The correct behavior is for the reading to continue with the character after'8'
.The writing in the destination also had a bug. Instead of writing the 3 characters (
'%'
,'2'
and'8'
) one after another, the first two were written correctly, namely at positionj
andj+1
in the destination string, but the third character was written atj+3
instead of atj+2
.This problem had not appeared before in the tests in
part_test.go
, because there was no test case that has both a pre-encoded character and a character to be encoded. When there are no characters to be encoded in the input string, the string is returned as it was given in the input. Such a test case would have resulted in an index out of range error.