Fix creation of IPS patches with records beginning at 454F46 #314
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.
When a ROM has a change that begins at address 454F46 (ASCII
EOF), it can't normally be encoded in an IPS file, because that offset value is used to mark the end of the patch. CoilSnake did have code to catch that case, but it seems like it was never tested, at least not in any recent version of Python... it caused a singleintto be inserted as the change to make to an offset, rather than abytesobject. All of the other code was based onbytesobjects being appended together, so the next loop iteration would raise a TypeError (unsupported operand type(s) for +=: 'int' and 'bytes')Changes were tested by changing an all-zeroes file to have the bytes
DE ADat offset 454F46 and confirming that the IPS patch contained a 3-byte change beginning at offset 454F45 consisting of00 DE AD.The design of this patch creation loop is... kinda weird, with how it processes -1 or 0 or 1 bytes each loop iteration (this PR fixes the only -1 case), and how it manually calls methods like
__len__()and__getitem__(index). But it doesn't seem buggy apart from this one thing.