The way the Range<Int> were used in the implementation of subscript made them in practice be interpreted as ClosedRange<Int>, including the upper bound
The amount of bytes read from the FileHandle to constitute each part were thus 1 byte more than the partSize we computed
Red/Green/Refactoring
I approached this using some R/G/R:
Red: Add (failing) tests to cover those cases — 3a225361ba48b2b40ea86b96dfd93c3a896b7cbe
Green: Fix implementation to pass the added tests — 154de58748f936f3891d57080148cfe9d412af97
Refactoring: Simplify slicing implementation using the stdlib's stride(…) method — f129e7cbbaea4863424f6ef88008a061cc3e6d13
This PR builds on top of https://github.com/Automattic/hostmgr/pull/92 and is a followup of https://github.com/Automattic/hostmgr/pull/92#discussion_r1550266186, which made me notice that there was an off-by-one error in the logic slicing the data into parts.
The off-by-one error
Range<Int>were used in the implementation ofsubscriptmade them in practice be interpreted asClosedRange<Int>, including the upper boundFileHandleto constitute each part were thus 1 byte more than thepartSizewe computedRed/Green/Refactoring
I approached this using some R/G/R:
stride(…)method — f129e7cbbaea4863424f6ef88008a061cc3e6d13